From w3c-dist-auth-request@w3.org Tue Oct 1 07:38:01 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09524 for ; Tue, 1 Oct 2002 07:38:01 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g91BcRC29187; Tue, 1 Oct 2002 07:38:27 -0400 (EDT) Resent-Date: Tue, 1 Oct 2002 07:38:27 -0400 (EDT) Resent-Message-Id: <200210011138.g91BcRC29187@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g91BcQB29157 for ; Tue, 1 Oct 2002 07:38:26 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA07061 for ; Tue, 1 Oct 2002 07:38:26 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09379; Tue, 1 Oct 2002 07:36:27 -0400 (EDT) Message-Id: <200210011136.HAA09379@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, 01 Oct 2002 07:36:27 -0400 Subject: I-D ACTION:draft-ietf-webdav-ordering-protocol-03.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6762 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --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 Ordered Collections Protocol Author(s) : J. Slein, E. Whitehead et al. Filename : draft-ietf-webdav-ordering-protocol-03.txt Pages : 41 Date : 2002-9-30 This specification extends the WebDAV Distributed Authoring Protocol to support server-side ordering of collection members. Of particular interest are orderings that are not based on property values, and so cannot be achieved using a search protocol's ordering option and cannot be maintained automatically by the server. Protocol elements are defined to let clients specify the position in the ordering of each collection member, as well as the semantics governing the ordering. Distribution of this document is unlimited. Please send comments to the Distributed Authoring and Versioning (WebDAV) working group at w3c-dist-auth@w3.org, which may be joined by sending a message with subject 'subscribe' to w3c-dist-auth-request@w3.org. 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-ordering-protocol-03.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-ordering-protocol-03.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-ordering-protocol-03.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <2002-9-30144729.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-ordering-protocol-03.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-ordering-protocol-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-9-30144729.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Wed Oct 2 00:56:20 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA15917 for ; Wed, 2 Oct 2002 00:56:20 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g924ujg07393; Wed, 2 Oct 2002 00:56:45 -0400 (EDT) Resent-Date: Wed, 2 Oct 2002 00:56:45 -0400 (EDT) Resent-Message-Id: <200210020456.g924ujg07393@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g924uhB07367 for ; Wed, 2 Oct 2002 00:56:43 -0400 (EDT) Received: from sunbelt.seagull.net ([199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA09053 for ; Wed, 2 Oct 2002 00:56:42 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id VAA05928 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Tue, 1 Oct 2002 21:56:40 -0700 Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by sunbelt.seagull.net (8.9.3) with ESMTP id VAA05911 sender obsfucated@us.ibm.com; Tue, 1 Oct 2002 21:56:38 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g924u7hG255242; Wed, 2 Oct 2002 00:56:07 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g924u6t7079250; Wed, 2 Oct 2002 00:56:06 -0400 To: Stefan Eissing Cc: "'Webdav WG'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Jason Crawford Date: Wed, 2 Oct 2002 00:36:50 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0|September 26, 2002) at 10/02/2002 00:56:06 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Re: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6763 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << In the light of this, is it useful to add another header where lock token can also be supplied? What do client implementors say? >> In light of that and everything else I said of course. :-) Boy the discussion on this topic seems light.... Anyway, I'll continue... Stephan, for me the issue is about good design, not ease for the client. We'll make sure it's easy for the client to do the basics, but right the use of the If: header is not fully and clearly defined in the spec. Before 2518bis the spec suggests that the If: header can be used for three purposes: (1) Client driven verification checks, (2) submission of lock tokens for server side locking checks and (3) lock refresh token submission. The spec only goes in to any detail and explicitly mentions (1). In regard to (3), 2518bis moved that function in to a seperate header. And (2) is not defined in any spec;... only mentioned. Now that (3) is largely solved, it's (2) that concerns me. It makes it impossible for the server writers to *always* get it "right" because "right" isn't clearly defined. We need to come up with a way to describe what activity in the If: header constitutes token submission. We could have a rule like, "if the token is mentioned in the If: header, then the server can assume that the client is submitting the token". But what if the client checks a resource that is locked by that lock but that is not relevant to the operation? What if the client checks that the lock is not applied to a resource that indeed it is not, then should that be considered submitting the lock? And if our If: headers become more sophisticated, then what? If the client asserts that either or both of two tokens are applied to a resource, is that a submission? We really need to seperate and clearly define the mechanism for token submission. It's not just a matter of affecting our ability to submit lock tokens. It also affects a client's ability to fully and confidently use the If: header to check assertions. The mix of purposes is already is affecting our current design. See the following paragraph from 9.5.1.1 When the If header is applied to a particular resource, the Tagged- list productions MUST be searched to determine if any of the listed resources match the operand resource(s) for the current method. If none of the resource productions match the current resource then the header MUST be ignored. If one of the resource productions does match the name of the resource under consideration then the list productions following the resource production MUST be applied to the resource in the manner specified in the previous section. So I believe this is saying that the server should only check the If header for resources that the server feels are relevant to the operation. I'm guessing this was placed in the spec to support the checking of locks by the server, but it impacts a client's ability to check assertions on other resources that the server might not think are relevant and are in scope for the If: header. It also makes the semantics of the If: header simply difficult to understand. We faced a similar problem when it came to refreshing locks in 2518. One had to use the If: header in that spec to submit locks for refreshing. After some discussion we decided to use a Lock-Token header for the purpose of submitting a token to be refreshed. 2518bis.2 reflects this change. I'm suggesting that we do the same thing for client driven assertion checking. This will give us one purpose for each header. Then we can clearly define the semantics of each header and only face design constraints that are relevant to the purpose of that header. J. ------------------------------------------ Phone: 914-784-7569 From w3c-dist-auth-request@w3.org Wed Oct 2 05:24:27 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA13098 for ; Wed, 2 Oct 2002 05:24:27 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g929Ois06101; Wed, 2 Oct 2002 05:24:44 -0400 (EDT) Resent-Date: Wed, 2 Oct 2002 05:24:44 -0400 (EDT) Resent-Message-Id: <200210020924.g929Ois06101@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g929OYB06040 for ; Wed, 2 Oct 2002 05:24:34 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA15135 for ; Wed, 2 Oct 2002 05:24:33 -0400 Received: from greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Wed, 02 Oct 2002 11:24:31 +0200 Date: Wed, 2 Oct 2002 11:24:31 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "'Webdav WG'" To: Jason Crawford From: Stefan Eissing In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: Re: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6764 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit This was written after having made the comments below. To me it is becoming unclear what exactly we are disucssing here. In http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0275.html I read three proposals: 1. more clearly define the If header and its scope. 2. Introduce an additional request header for relaxed lock checking. The client says: " this is the bag of lock tokens I have, server, take your pick." 3. Introduce an additional response header where the server can indicated which token from the bag are no longer valid. I am all for (1). Regarding (2) and (3) I argued that, as we still need the If header, is it really worth it to add a new header with related semantics? Especially in your original mail (http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0398.html) you said: > It's not really the length that's the problem in my mind. It's > the fact that we have to define what it means for the If: > header to have *submitted* the token. The If: header > can be quite sophisticated and we might choose to make > it even more sophisticated as we discover more requirements. > If we combine the functionality, then it constrains how much > we can extend the If: header. > > Yes, we could say that clients can support multiple If: > headers. (I forget if we already do.) But we'd end up > defining two types of If: headers for the two purposes. > > I'd prefer to seperate those explicitly. WebDAV is only > in version 1 now and hopefully a design decision like > this will clarify the protocol now and avoid specification > headaches down the road. If I understand you correctly, you seem to extend Lisa's original proposal. Do you think 2518bis should remove lock tokens from the If header completely? //Stefan Am Mittwoch, 02.10.02, um 06:36 Uhr (Europe/Berlin) schrieb Jason Crawford: > << > In the light of this, is it useful to add another header where lock > token can also be supplied? What do client implementors say? >>> > In light of that and everything else I said of course. :-) Must be the language barrier. I never meant to say that your arguments should not be considered. > Boy the discussion on this topic seems light.... > > Anyway, I'll continue... > > Stephan, for me the issue is about good design, not ease for the > client. We'll make sure it's easy for the client to do the basics, > but right the use of the If: header is not fully and clearly defined > in the spec. Before 2518bis the spec suggests that the If: header can > be > used > for three purposes: (1) Client driven verification checks, (2) > submission of lock tokens for server side locking checks and (3) lock > refresh token submission. The spec only goes in to any detail and > explicitly mentions (1). In regard to (3), 2518bis moved that function > in to a seperate header. And (2) is not defined in any spec;... only > mentioned. Now that (3) is largely Unless I do not fully understand your point, (2) is defined by me in 2518 ch. 7.6: "In order to prevent these collisions a lock token MUST be submitted by an authorized principal in the If header for all locked resources that a method may interact with or the method MUST fail." Now, I fully agree to your point that the set of affected resources is not clearly defined for all methods. Particularly it is not clearly defined what the untagged production applies to and how deep locks are handled. I'm all for clarifying in 2518bis how the If header should be used and what it should look like, so clients and servers implementations do not have to guess. > solved, it's (2) that concerns me. It makes it impossible for the > server writers to *always* get it "right" because "right" isn't clearly > defined. We need to come up with a way to describe what activity in > the If: header constitutes token submission. We could have a rule > like, "if the token is mentioned in the If: header, then the server > can assume that the client is submitting the token". But what if > the client checks a resource that is locked by that lock but that is > not relevant to the operation? What if the client checks that the lock > is not applied to a resource that indeed it is not, then should that > be considered submitting the lock? And if our If: headers become Those are all good questions. Do you think this needs to be defined in 2518bis or is this an argument for dropping lock-tokens from the If header because it is impossible to get it right? > more sophisticated, then what? If the client asserts that either > or both of two tokens are applied to a resource, is that a submission? > We really need to seperate and clearly define the mechanism for token > submission. Agreed. > It's not just a matter of affecting our ability to submit lock tokens. > It also affects a client's ability to fully and confidently use the If: > header to check assertions. The mix of purposes is already is affecting > our current design. See the following paragraph from 9.5.1.1 > > When the If header is applied to a particular resource, the Tagged- > list productions MUST be searched to determine if any of the listed > resources match the operand resource(s) for the current method. If > none of the resource productions match the current resource then the > header MUST be ignored. If one of the resource productions does > match the name of the resource under consideration then the list > productions following the resource production MUST be applied to the > resource in the manner specified in the previous section. > > So I believe this is saying that the server should only check the If > header > for resources that the server feels are relevant to the operation. I'm > guessing > this was placed in the spec to support the checking of locks by the > server, but it impacts a client's ability to check assertions on other > resources > that the server might not think are relevant and are in scope for the > If: > header. It also makes the semantics of the If: header simply > difficult to > understand. Again, I agree that it is not easy to understand. As you say, this is partly due to the current wording in the spec. The other complexity is due to the use cases it tries to solve. > > We faced a similar problem when it came to refreshing locks in 2518. > One > had to use the If: header in that spec to submit locks for refreshing. > After some discussion we decided to use a Lock-Token header for the > purpose > of submitting a token to be refreshed. 2518bis.2 reflects this > change. > > I'm suggesting that we do the same thing for client driven assertion > checking. This will give us one purpose for each header. Then we can > clearly define the semantics of each header and only face design > constraints that are relevant to the purpose of that header. > > J. > > ------------------------------------------ > Phone: 914-784-7569 > From w3c-dist-auth-request@w3.org Wed Oct 2 11:27:00 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24577 for ; Wed, 2 Oct 2002 11:26:59 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g92FQtm14725; Wed, 2 Oct 2002 11:26:55 -0400 (EDT) Resent-Date: Wed, 2 Oct 2002 11:26:55 -0400 (EDT) Resent-Message-Id: <200210021526.g92FQtm14725@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g92FQsB14699 for ; Wed, 2 Oct 2002 11:26:54 -0400 (EDT) Received: from sunbelt.seagull.net ([199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA21930 for ; Wed, 2 Oct 2002 11:26:52 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id IAA22521 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Wed, 2 Oct 2002 08:26:41 -0700 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by sunbelt.seagull.net (8.9.3) with ESMTP id IAA22498 sender obsfucated@us.ibm.com; Wed, 2 Oct 2002 08:26:35 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g92FQ2kC133126; Wed, 2 Oct 2002 11:26:02 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g92FPwl3020004; Wed, 2 Oct 2002 11:25:58 -0400 To: Stefan Eissing Cc: "'Webdav WG'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Jason Crawford Date: Wed, 2 Oct 2002 11:12:12 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0|September 26, 2002) at 10/02/2002 11:25:58 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Re: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6765 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: << I read three proposals: 1. more clearly define the If header and its scope. 2. Introduce an additional request header for relaxed lock checking. The client says: " this is the bag of lock tokens I have, server, take your pick." 3. Introduce an additional response header where the server can indicated which token from the bag are no longer valid. I am all for (1). >> Good :-) << Regarding (2) and (3) I argued that, as we still need the If header, is it really worth it to add a new header with related semantics? >> I wasn't really talking about (3). I was planning to cover that in a seperate thread. I don't want to tie (3) to the issue of (2). (3) is an optimization that only becomes realistic if you have (2). If people didn't accept (2), there is no point in talking about (3). Regarding "related semantics"... one of my points is that their semantics would not be related. Each header would work independently of the other and the functions that each would perform would not overlap the functionality of the other. I think this would be important to make sure the spec is clear and simple. << If I understand you correctly, you seem to extend Lisa's original proposal. Do you think 2518bis should remove lock tokens from the If header completely? >> I propose that lock tokens remain in If: headers. The If: header would continue to be a list of assertions by the client that must be true before the server performs the request. Those assertions could continue to mention etag and also lock tokens. None of that would change, but... The spec speaks of the need for a client to "submit" a lock-token to be able to do operations on a resource that is locked. That is a good thing, but I propose (2a) that the mentioning of a lock-token in an If: header not be considered a "submission" of a lock token. There would be a seperate header whose only purpose is to allow the client to submit lock tokens to satisfy the server's need to make sure that only the principal that holds the lock can operate on a locked resource. I also propose, (2b) that we not *require* that a client check if a lock is on a resource (with the If: header) when submitting the token with the new header. But we can *recommend* it for compatibility reasons and because in many situations it's the only way a client can be certain that there is no lost-update situation on that resource. That is a simplified explanation. The original proposal (2) above mentions relaxed lock checking on that new header. I support that and can make a small case for that, but I realize others might not support that. I could also accept a situation where the new header doesn't just list a bag of tokens but also says something about the location of those locks. If we have to do that, my only request on that point is that we be very clear and thoughtful about how we specify that. If we can't specify that clearly and thoughtfully, then I prefer we use the "bag of tokens" approach. I find that approach acceptable because in most cases the client has plenty of motivation to use the If: header to check if the lock is still there. If they are going to check that anyway, I don't see a lot of point in complicating the definition of the new header. Another thing I'd like to propose is that the paragraph I mentioned about the server only checking the If: clauses that it wanted to check be removed. If not now, then later. That paragraph limits the possible use of the If: header. Anyway... I don't want to talk about this much. It's just another improvement that becomes possible if we do move lock token submission to a new header. I hope this is clearer. J. ------------------------------------------ Phone: 914-784-7569 From w3c-dist-auth-request@w3.org Wed Oct 2 12:35:28 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA27442 for ; Wed, 2 Oct 2002 12:35:27 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g92GXvj23905; Wed, 2 Oct 2002 12:33:57 -0400 (EDT) Resent-Date: Wed, 2 Oct 2002 12:33:57 -0400 (EDT) Resent-Message-Id: <200210021633.g92GXvj23905@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g92GXuB23879 for ; Wed, 2 Oct 2002 12:33:56 -0400 (EDT) Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA06508 for ; Wed, 2 Oct 2002 12:33:56 -0400 Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Wed, 02 Oct 2002 12:29:32 -0400 (Eastern Daylight Time) Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453); Wed, 2 Oct 2002 12:29:31 -0400 Received: from xythoslap ([198.144.203.248]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453); Wed, 2 Oct 2002 12:29:29 -0400 From: "Lisa Dusseault" To: "'Stefan Eissing'" , "'Jason Crawford'" Cc: "'Webdav WG'" Date: Wed, 2 Oct 2002 09:29:27 -0700 Message-ID: <00c801c26a30$e33ff830$b701a8c0@xythoslap> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: X-OriginalArrivalTime: 02 Oct 2002 16:29:30.0228 (UTC) FILETIME=[E1FDDB40:01C26A30] Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6766 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > I read three proposals: > 1. more clearly define the If header and its scope. > 2. Introduce an additional request header for relaxed lock > checking. The client says: " this is the bag of lock tokens > I have, server, take your pick." > 3. Introduce an additional response header where the server > can indicated which token from the bag are no longer valid. > > I am all for (1). > > Regarding (2) and (3) I argued that, as we still need the If header, is > it really worth it to add a new header with related semantics? I am now convinced (I wasn't before the interop events) that it is worthwhile to add a new and simple header. Although we could spend a lot of time defining the IF header more carefully (and may need to anyway), and we could also document how to use the IF header to supply lock tokens without causing the request to fail because of condition matching, we have continued interoperability problems with every new client implementation when they encounter odd situations and different server implementations. Because the IF header is so verbose, some of the solutions are not feasible in practice. A simple (comma-delimitered) header for providing lock tokens would vastly improve interoperability, and that's after all the goal for RFC2518 bis. The original lock/if design had a lot of good ideas and definitely good intentions, but with any complex design, the Law of Unintended Consequences means there will be Unintended Consequences. After implementation experience, we know what those are. Maybe we can fix them. That was the summary, here are the details. Note that I do not mention authentication below, in order to keep the discussion simple. Any time I discuss using a lock token to see if the write operation is allowed, assume the server may also apply authentication checks to make sure the user can use the lock. A. What are the continued interoperability problems? Basically, clients find their requests failing because of two major cases: (1) they do not supply all the correct lock tokens (not knowing exactly which lock tokens need to be supplied) (2) when they do supply all the correct lock tokens, the server applies them to resources that are not locked with those lock tokens, and the request fails because conditions must be met. Clients find it difficult to know what resources the server considers "are affected by" a request. Much of this is due to the ambiguous sentence in section 9.4.1, "If a method, due to the presence of a Depth or Destination header, is applied to multiple resources then the No-tag-list production MUST be applied to each resource the method is applied to." Examples of (1): (I'm not asking for answers, I'm asking the questions clients must ask themselves) - Basically, what defines "resources the method is applied to"? What resource is a DELETE request applied to? - When you MOVE a resource into a locked collection, do you have to supply the target collection's lock token? - When you MOVE a resource from a locked collection, do you have to supply the source collection's lock token? - When you COPY a resource from one locked collection to another, which lock token do you have to supply, or both? - What happens when a collection is locked with depth 0? What operations are affected? How is this handled differently than a depth infinity lock on the same collection? (Hint: depends on the server implementation!) Examples of (2): - When you DELETE a resource that's in a locked collection, can you simply send the IF header with an untagged lock token? No, on *some* servers the token must be tagged with the parent collection (the root of the lock). - Any MOVE request where locks are involved cannot use untagged lock tokens. - Some servers allow a lock token to be tagged with any resource-URL that the lock scope includes. Other servers require that the lock token be tagged with the URL for the resource at the root of the lock. Basically, a careful client eventually learns to always tag every lock token. This results in a very large If header value already. B. Why does the current situation guarantee additional roundtrips, but not additional security? A careful client (one that has learned the lessons from section A) that is asked to do a write operation will attempt to include a tagged (with the root-of-lock URL) lock token for every lock that could possibly be considered to "affect" the operation. So far so good -- as long as those locks still exist, the request should succeed. However, if any of those locks has been timed out or removed, the request will fail because that lock token is no longer valid. Now the client must decide whether they want to try again to make the request succeed, or not. However, it's not necessarily clear from the response which condition failed. It's possible for the server to respond simply with "precondition failed" and give no information which one failed. An error to the user is typically undesirable. Therefore, if the client is a reasonably sophisticated client, they will typically try again. Even if the user is consulted, the user will typically try again. The client will send the write operation again without the lock token. A good (well-behaved) client doing a write operation that will overwrite a regular resource should provide the ETAG to make sure that the resource hasn't changed since the GET operation. However, there's no guarantee that a client MUST do that; a client can overwrite the resource without checking the ETAG, simply by retrying the original write request without the lock token that failed. Thus, the current design requires an extra round-trip whenever the client misunderstood the lock situation, but it does not guarantee any additional protection because a poorly-behaved client can simply reissue the request without the offending token and overwrite the resource. Note in the case of large PUT requests the roundtrip may be particularly time-consuming and resource-consuming. C. Why does the current situation simply annoy a well-behaved client, without particularly helping it? A well-behaved client should always provide the ETAG when overwriting a regular resource. This is a good idea if the resource is locked or not. When a resource is locked, and the client expects it has remained locked, it may still be appropriate to overwrite the resource -- providing the ETAG has not changed. It doesn't particularly matter if the lock has gone away unexpectedly, as long as the resource is still the same resource. Thus, a PUT (or other write) request with an ETAG condition and a lock token should be able to succeed if the ETAG is correct and the lock token matches the current lock, BUT ALSO the request should succeed if the ETAG is correct and the lock no longer exists. Since the well-behaved client should be using ETAGs anyway, the failure of the request when the lock has gone away provides no help and instead is simply annoying. D. How could this situation be solved with the existing header, and why is that solution poor? Somebody suggested that the client can provide a IF header clause that is guaranteed to succeed, but will also contain the lock token. Here's how it would work: IF URL-A matches (lock-token-A OR NOT lock-token-A) This header contains the lock token, so the request would succeed if the resource is locked. However, it has an OR clause, so the request would succeed also if the resource is not locked. PROBLEM #1: Servers may not support the OR, and the NOT, correctly, because most clients don't currently use this. This solution HAS NOT been proven, it is only theoretical. It might not work. PROBLEM #2: What if multiple locks are required (e.g. moving a collection that has multiple locked resources? What if the URLs are long? The IF header becomes very long and may be truncated by some proxies. E.g. If: ( NOT ) ( NOT ) ( NOT ) PROBLEM #3: Uck, this is really complicated. While it's useful to know that a client can do this with some existing servers, provided they handle it correctly, surely we can do this in a simpler mechanism that is less prone to interoperability problems. A simple header that allows the client to supply lock tokens to use is semantically equivalent to the above example, but shorter, simpler, and easier to implement. Also it can be split across multiple lines. Use-Lock-Tokens: , Use-Lock-Tokens: E. How could this work better? Servers could do a much better job of helping clients use write operations and locks, rather than get in the way. Some ideas: 1. Allow write operations to succeed if the correct lock token is provided in a "use these lock tokens" (comma-separated) header. The client would be able to make the write operation 2. Tell clients exactly what lock tokens are no longer valid. 3. Tell clients exactly what resources are locked, when the client asks for a write operation that affects resources that are locked without providing the lock token. Much of this can be (and needs to be) better specified within the existing framework. However, it's my opinion the existing framework can be simplified, and that simplification would provide greater interoperability. F. Why is simplicity so important? When a request/response protocol is needlessly complex, client implementers have several problems: 1. First of all, complexity is just hard for the client to implement, let alone implement correctly. 2. Not only must the client deal with complexity, it must explain things to users. WebDAV clients have to make complex things simple in order to handle the typical user of a productivity or browser application. How is the client supposed to explain that a lock that may have been there before may not be there now, and that it may or may not be OK to overwrite the resource anyway? It's not acceptable to explain that to most users. 3. Servers may implement the complex stuff differently. It becomes increasingly difficult to handle multiple server implementations and their vagaries, as the complexity goes up. 4. Clients have so much else to worry about (usability, backward compatibility, installation, multiple OS, GUIs) it's no surprise to find that the protocol implementation team in a product like Office is a tiny part of the team (or maybe even a library provided by a separate tiny team). The protocol is just another minor tool, not the main value of an application like Word or Photoshop. The client must be able to take the protocol working correctly for granted. WebDAV does a good job in most cases of allowing clients to deal with simple stuff first. E.g. it's quite possible for a client to implement only some methods and not others. That's a great benefit: it allows a client to spread an extended WebDAV-support effort over several releases. However, since other clients can lock resources, all clients that do write operations must deal with much of the complexity of handling locks. Now that WebDAV has many server implementations which are fairly reliable, fully featured and interoperable, the continued and growing success of WebDAV depends on good, usable and ubiquitous client implementations. If we wish large vendors with existing productivity applications to support WebDAV, including locks of regular resources and collections, then it would be a great benefit to simplify the things that have been found to be overly complex. To me, that's worthwhile. Lisa From w3c-dist-auth-request@w3.org Thu Oct 3 14:10:20 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28588 for ; Thu, 3 Oct 2002 14:10:19 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g93I8mp01996; Thu, 3 Oct 2002 14:08:48 -0400 (EDT) Resent-Date: Thu, 3 Oct 2002 14:08:48 -0400 (EDT) Resent-Message-Id: <200210031808.g93I8mp01996@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g93I8lB01970 for ; Thu, 3 Oct 2002 14:08:47 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA02052 for ; Thu, 3 Oct 2002 14:08:46 -0400 Received: (qmail 23701 invoked by uid 0); 3 Oct 2002 18:08:15 -0000 Received: from p3ee24739.dip.t-dialin.net (HELO lisa) (62.226.71.57) by mail.gmx.net (mp004-rz3) with SMTP; 3 Oct 2002 18:08:15 -0000 From: "Julian Reschke" To: "'Webdav WG'" Date: Thu, 3 Oct 2002 20:08:11 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <00c801c26a30$e33ff830$b701a8c0@xythoslap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: Variant Support for WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6767 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit (Geoff has posted an initial draft at [1], here are some comments) Geoff, I see that you are approaching variant handling from a versioning point of view -- at least you are re-using RFC3253 as framework (which I think makes sense). In my point of view, variant handling extensions to WebDAV need to be compatible with RFC2616 (HTTP), so I was trying to approach the problem from a lower level. Let's take a look at a very simple use case that doesn't involve any extensions of HTTP(1.1) at all: - Discover a resource through GET or HEAD. - Through the "vary" header, the server announces that the representation (variant) it sent varies on one or several of the request headers, such as "accept-language". - It may also send a "content-location" header, giving the URI of the possibly authorable variant of the requested resource. - Client can then discover that variant, and if this does not vary on any request header, PUT to it's URI. How does this translate to WebDAV: - clarify that PROPFIND acts regarding variants the same way as GET and HEAD - the information from the vary header should be available as live property - there should be a generic way to express HTTP headers as WebDAV properties (RFC2518's approach is broken, because there's no obvious mapping from HTTP header names to WebDAV properties) The next step would be to consider - copy and move behaviour - authoring of the varying resource - direct discovery of variants - define how variants move with the varying resource (I think this is something you're planning to handle with the variant controller resource, right?) Do we have agreement on the goals, or do you really have a different idea of variant handling? Julian [1] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Oct 4 19:15:08 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA25560 for ; Fri, 4 Oct 2002 19:15:07 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g94NCPG01463; Fri, 4 Oct 2002 19:12:25 -0400 (EDT) Resent-Date: Fri, 4 Oct 2002 19:12:25 -0400 (EDT) Resent-Message-Id: <200210042312.g94NCPG01463@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g94NCMB01434 for ; Fri, 4 Oct 2002 19:12:22 -0400 (EDT) Received: from sunbelt.seagull.net ([199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA14844 for ; Fri, 4 Oct 2002 19:12:21 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id QAA12949 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Fri, 4 Oct 2002 16:12:13 -0700 Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by sunbelt.seagull.net (8.9.3) with ESMTP id QAA12926 sender obsfucated@us.ibm.com; Fri, 4 Oct 2002 16:12:12 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g94NBfVL161152; Fri, 4 Oct 2002 19:11:41 -0400 Received: from d01ml233.pok.ibm.com (d01ml233.pok.ibm.com [9.56.224.56]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g94NBcab041832; Fri, 4 Oct 2002 19:11:38 -0400 To: "Lisa Dusseault" Cc: "'Stefan Eissing'" , "'Webdav WG'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: "Jason Crawford" Date: Fri, 4 Oct 2002 19:06:06 -0400 X-MIMETrack: Serialize by Router on D01ML233/01/M/IBM(Release 5.0.10 |March 22, 2002) at 10/04/2002 07:11:38 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6768 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: We need to hear more from folks. Things have been unusually quiet on this subject. Jason and Lisa have spoken up in favor of splitting the functionality. http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0397.html (and previous postings) http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0003.html http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0004.html Stefan has spoken against it before that time, but it is unclear if he understood the proposal. Hopefully the proposal is clearer now. Let's hear from you folks... J. ------------------------------------------ Phone: 914-784-7569 From w3c-dist-auth-request@w3.org Fri Oct 4 22:34:49 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA28692 for ; Fri, 4 Oct 2002 22:34:48 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g952WXT27416; Fri, 4 Oct 2002 22:32:33 -0400 (EDT) Resent-Date: Fri, 4 Oct 2002 22:32:33 -0400 (EDT) Resent-Message-Id: <200210050232.g952WXT27416@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g952WWB27390 for ; Fri, 4 Oct 2002 22:32:32 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA08214 for ; Fri, 4 Oct 2002 22:32:32 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 04 Oct 2002 22:21:16 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Fri, 4 Oct 2002 22:31:45 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Fri, 4 Oct 2002 22:31:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26C17.58278DB0" Subject: RE: Variant Support for WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6769 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26C17.58278DB0 Content-Type: text/plain From: Julian Reschke [mailto:julian.reschke@gmx.de] I see that you are approaching variant handling from a versioning point of view -- at least you are re-using RFC3253 as framework (which I think makes sense). Yes, I wanted to make sure that variants and versions interoperated in a sensible way. Now that this has been separated from the versioning protocol though, we should probably reword some of it in a more generic way, so that the interaction with versioning is clear, but that a server can support variants without supporting other aspects of versioning. In my point of view, variant handling extensions to WebDAV need to be compatible with RFC2616 (HTTP), I agree. so I was trying to approach the problem from a lower level. Let's take a look at a very simple use case that doesn't involve any extensions of HTTP(1.1) at all: - Discover a resource through GET or HEAD. - Through the "vary" header, the server announces that the representation (variant) it sent varies on one or several of the request headers, such as "accept-language". - It may also send a "content-location" header, giving the URI of the possibly authorable variant of the requested resource. - Client can then discover that variant, and if this does not vary on any request header, PUT to it's URI. That all works for me. How does this translate to WebDAV: - clarify that PROPFIND acts regarding variants the same way as GET and HEAD Agree. - the information from the vary header should be available as live property Agree (this is just an important subcase of the next bullet, true?). - there should be a generic way to express HTTP headers as WebDAV properties (RFC2518's approach is broken, because there's no obvious mapping from HTTP header names to WebDAV properties) Agree. Do you have anything particular in mind here? The next step would be to consider - copy and move behaviour - authoring of the varying resource - direct discovery of variants - define how variants move with the varying resource (I think this is something you're planning to handle with the variant controller resource, right?) I believe the semantics for these items all follow from the current variants draft, do they not? Do we have agreement on the goals, or do you really have a different idea of variant handling? I certainly agree with the goals that you've stated here. Cheers, Geoff ------_=_NextPart_001_01C26C17.58278DB0 Content-Type: text/html RE: Variant Support for WebDAV

   From: Julian Reschke [mailto:julian.reschke@gmx.de]

   I see that you are approaching variant handling from a versioning
   point of view -- at least you are re-using RFC3253 as framework
   (which I think makes sense).

Yes, I wanted to make sure that variants and versions interoperated
in a sensible way.  Now that this has been separated from the
versioning protocol though, we should probably reword some of it
in a more generic way, so that the interaction with versioning is
clear, but that a server can support variants without supporting
other aspects of versioning.

   In my point of view, variant handling extensions to WebDAV need to
   be compatible with RFC2616 (HTTP),

I agree.

   so I was trying to approach the  problem from a lower level.
   Let's take a look at a very simple use case that doesn't involve any
   extensions of HTTP(1.1) at all:

   - Discover a resource through GET or HEAD.

   - Through the "vary" header, the server announces that the
   representation (variant) it sent varies on one or several of the
   request headers, such as "accept-language".

   - It may also send a "content-location" header, giving the URI of the
   possibly authorable variant of the requested resource.

   - Client can then discover that variant, and if this does not vary
   on any request header, PUT to it's URI.

That all works for me.

   How does this translate to WebDAV:

   - clarify that PROPFIND acts regarding variants the same way as GET
     and HEAD

Agree.

   - the information from the vary header should be available as live
     property

Agree (this is just an important subcase of the next bullet, true?).

   - there should be a generic way to express HTTP headers as WebDAV
   properties (RFC2518's approach is broken, because there's no
   obvious mapping from HTTP header names to WebDAV properties)

Agree.  Do you have anything particular in mind here?

   The next step would be to consider

   - copy and move behaviour

   - authoring of the varying resource

   - direct discovery of variants

   - define how variants move with the varying resource (I think this
   is something you're planning to handle with the variant controller
   resource, right?)

I believe the semantics for these items all follow from the current
variants draft, do they not?

   Do we have agreement on the goals, or do you really have a
   different idea of variant handling?

I certainly agree with the goals that you've stated here.

Cheers,
Geoff

------_=_NextPart_001_01C26C17.58278DB0-- From w3c-dist-auth-request@w3.org Sat Oct 5 04:40:12 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12324 for ; Sat, 5 Oct 2002 04:40:12 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g958bYd23876; Sat, 5 Oct 2002 04:37:34 -0400 (EDT) Resent-Date: Sat, 5 Oct 2002 04:37:34 -0400 (EDT) Resent-Message-Id: <200210050837.g958bYd23876@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g958bXB23850 for ; Sat, 5 Oct 2002 04:37:33 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA13480 for ; Sat, 5 Oct 2002 04:37:32 -0400 Received: (qmail 10001 invoked by uid 0); 5 Oct 2002 08:37:31 -0000 Received: from pd950c3c4.dip.t-dialin.net (HELO lisa) (217.80.195.196) by mail.gmx.net (mp013-rz3) with SMTP; 5 Oct 2002 08:37:31 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'Webdav WG'" Date: Sat, 5 Oct 2002 10:37:30 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Subject: RE: Variant Support for WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6770 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff > Sent: Saturday, October 05, 2002 4:32 AM > To: 'Webdav WG' > Subject: RE: Variant Support for WebDAV > > I see that you are approaching variant handling from a versioning > point of view -- at least you are re-using RFC3253 as framework > (which I think makes sense). > Yes, I wanted to make sure that variants and versions interoperated > in a sensible way. Now that this has been separated from the > versioning protocol though, we should probably reword some of it > in a more generic way, so that the interaction with versioning is > clear, but that a server can support variants without supporting > other aspects of versioning. Sounds good. > In my point of view, variant handling extensions to WebDAV need to > be compatible with RFC2616 (HTTP), > I agree. > so I was trying to approach the problem from a lower level. > Let's take a look at a very simple use case that doesn't involve any > extensions of HTTP(1.1) at all: > - Discover a resource through GET or HEAD. > - Through the "vary" header, the server announces that the > representation (variant) it sent varies on one or several of the > request headers, such as "accept-language". > - It may also send a "content-location" header, giving the URI of the > possibly authorable variant of the requested resource. > - Client can then discover that variant, and if this does not vary > on any request header, PUT to it's URI. > That all works for me. > How does this translate to WebDAV: > - clarify that PROPFIND acts regarding variants the same way as GET > and HEAD > Agree. > - the information from the vary header should be available as live > property > Agree (this is just an important subcase of the next bullet, true?). Yes. > - there should be a generic way to express HTTP headers as WebDAV > properties (RFC2518's approach is broken, because there's no > obvious mapping from HTTP header names to WebDAV properties) > Agree. Do you have anything particular in mind here? - An unambigouos mapping algorithm from HTTP header names to WebDAV property QNames. As as matter of fact, the HTTP extension framework (RFC2774) defines URIs as namespace names for headers in HTTP extensions. I think we want to include RFC2774-compatible headers, and the obvious way to map them is to use a canonical mapping. This leaves us with the problem of choosing a namespace name for non-RFC2774-compatible "plain" header names. Some choices would be: a) no namespace, b) something like "urn:ietf:rfc:2616" (but we don't control this namespace) or c) "DAV:http-header". See also dicussion in [1]. - Having a QName may not be sufficient -- we may also have to think about datatypes. The Vary header lists other header names, so a WebDAV property probably should enumerate QNames of other WebDAV properties, such as > The next step would be to consider > - copy and move behaviour > - authoring of the varying resource > - direct discovery of variants > - define how variants move with the varying resource (I think this > is something you're planning to handle with the variant controller > resource, right?) > I believe the semantics for these items all follow from the current > variants draft, do they not? Do they? They say that I can't move a variant, but they don't say how a move on the variant controller affects the variants. Maybe you could give an example for a very simple use case such as two variants (HTML and PDF) -- how would the variant controller and the variant URLs look like? > Do we have agreement on the goals, or do you really have a > different idea of variant handling? > I certainly agree with the goals that you've stated here. [1] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Oct 5 14:48:55 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21367 for ; Sat, 5 Oct 2002 14:48:55 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g95Ikf425967; Sat, 5 Oct 2002 14:46:41 -0400 (EDT) Resent-Date: Sat, 5 Oct 2002 14:46:41 -0400 (EDT) Resent-Message-Id: <200210051846.g95Ikf425967@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g95IkdB25941 for ; Sat, 5 Oct 2002 14:46:39 -0400 (EDT) Received: from sunbelt.seagull.net ([199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA06920 for ; Sat, 5 Oct 2002 14:46:39 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id LAA17479 sender ccjason@us.ibm.com for w3c-dist-auth@w3c.org; Sat, 5 Oct 2002 11:46:38 -0700 Received: from over.ny.us.ibm.com (over.ny.us.ibm.com [32.97.182.111]) by sunbelt.seagull.net (8.9.3) with ESMTP id LAA17468 sender ccjason@us.ibm.com; Sat, 5 Oct 2002 11:46:37 -0700 Received: from e4.ny.us.ibm.com (e4.esmtp.ibm.com [9.14.6.104]) by pokfb.esmtp.ibm.com (8.12.2/8.12.2) with ESMTP id g95IHaqw124800 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=OK); Sat, 5 Oct 2002 14:17:37 -0400 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g95IBrc9080572; Sat, 5 Oct 2002 14:11:53 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g95IBpM6167242; Sat, 5 Oct 2002 14:11:51 -0400 To: "'Webdav WG'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Jason Crawford Date: Sat, 5 Oct 2002 13:55:14 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0|September 26, 2002) at 10/05/2002 14:11:51 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Section 7.5, lock semantics Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6771 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: In section 7.5 we read... 7.5 Write Locks and Collections A write lock on a collection, whether created by a "Depth: 0" or "Depth: infinity" lock request, prevents the addition or removal of member URIs of the collection by non-lock owners. As a consequence, when a principal issues a PUT or POST request to create a new resource under a URI which needs to be an internal member of a write locked collection to maintain HTTP namespace consistency, or issues a DELETE to remove a resource which has a URI which is an existing internal member URI of a write locked collection, this request MUST fail if the principal does not have a write lock on the collection. However, if a write lock request is issued to a collection containing member URIs identifying resources that are currently locked in a manner which conflicts with the write lock, the request MUST fail with a 423 (Locked) status code. If a lock owner causes the URI of a resource to be added as an internal member URI of a depth-infinity locked collection then the new resource MUST be automatically added to the lock. This is the only mechanism that allows a resource to be added to a write lock. Thus, for example, if the collection /a/b/ is write locked and the resource /c is moved to /a/b/c then resource /a/b/c will be added to the write lock. I think the second paragraph is only true if we're talking about a depth infinity lock. The paragraph doesn't mention that though. Another set of eyes should read this though and see if I'm just being dense... J. ------------------------------------------ Phone: 914-784-7569 From w3c-dist-auth-request@w3.org Sat Oct 5 15:21:07 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA21769 for ; Sat, 5 Oct 2002 15:21:07 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g95JJ7E29721; Sat, 5 Oct 2002 15:19:07 -0400 (EDT) Resent-Date: Sat, 5 Oct 2002 15:19:07 -0400 (EDT) Resent-Message-Id: <200210051919.g95JJ7E29721@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g95JJ6B29690 for ; Sat, 5 Oct 2002 15:19:06 -0400 (EDT) Received: from sunbelt.seagull.net ([199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA12034 for ; Sat, 5 Oct 2002 15:19:06 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id MAA20213 sender julian.reschke@gmx.de for w3c-dist-auth@w3c.org; Sat, 5 Oct 2002 12:19:05 -0700 Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by sunbelt.seagull.net (8.9.3) with SMTP id MAA20202 sender julian.reschke@gmx.de for ; Sat, 5 Oct 2002 12:19:03 -0700 Received: (qmail 27745 invoked by uid 0); 5 Oct 2002 19:18:30 -0000 Received: from pd950c3e6.dip.t-dialin.net (HELO lisa) (217.80.195.230) by mail.gmx.net (mp007-rz3) with SMTP; 5 Oct 2002 19:18:30 -0000 From: "Julian Reschke" To: "Jason Crawford" , "'Webdav WG'" Date: Sat, 5 Oct 2002 21:18:26 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Subject: RE: Section 7.5, lock semantics Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6772 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I agree that the scenario described in the 2nd paragraph can only occur when it's a deep lock. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Saturday, October 05, 2002 7:55 PM > To: 'Webdav WG' > Subject: Section 7.5, lock semantics > > > > > > > In section 7.5 we read... > > 7.5 Write Locks and Collections > > A write lock on a collection, whether created by a "Depth: 0" or > "Depth: infinity" lock request, prevents the addition or removal of > member URIs of the collection by non-lock owners. As a consequence, > when a principal issues a PUT or POST request to create a new > resource under a URI which needs to be an internal member of a write > locked collection to maintain HTTP namespace consistency, or issues > a DELETE to remove a resource which has a URI which is an existing > internal member URI of a write locked collection, this request MUST > fail if the principal does not have a write lock on the collection. > > However, if a write lock request is issued to a collection > containing member URIs identifying resources that are currently > locked in a manner which conflicts with the write lock, the request > MUST fail with a 423 (Locked) status code. > > If a lock owner causes the URI of a resource to be added as an > internal member URI of a depth-infinity locked collection then the > new resource MUST be automatically added to the lock. This is the > only mechanism that allows a resource to be added to a write lock. > Thus, for example, if the collection /a/b/ is write locked and the > resource /c is moved to /a/b/c then resource /a/b/c will be added to > the write lock. > > I think the second paragraph is only true if we're talking about a depth > infinity lock. The paragraph doesn't mention that though. > > Another set > of eyes should read this though and see if I'm just being dense... > > J. > > ------------------------------------------ > Phone: 914-784-7569 > From w3c-dist-auth-request@w3.org Sat Oct 5 17:51:44 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25947 for ; Sat, 5 Oct 2002 17:49:34 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g95KvtC07809; Sat, 5 Oct 2002 16:57:55 -0400 (EDT) Resent-Date: Sat, 5 Oct 2002 16:57:55 -0400 (EDT) Resent-Message-Id: <200210052057.g95KvtC07809@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g95KvsB07783 for ; Sat, 5 Oct 2002 16:57:54 -0400 (EDT) Received: from sunbelt.seagull.net ([199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA23273 for ; Sat, 5 Oct 2002 16:57:46 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id NAA29244 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Sat, 5 Oct 2002 13:57:40 -0700 Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by sunbelt.seagull.net (8.9.3) with ESMTP id NAA29227 sender obsfucated@us.ibm.com; Sat, 5 Oct 2002 13:57:39 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g95Kv7hG096702; Sat, 5 Oct 2002 16:57:07 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g95Kv59o135462; Sat, 5 Oct 2002 16:57:05 -0400 To: "Julian Reschke" Cc: "'Webdav WG'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Jason Crawford Date: Sat, 5 Oct 2002 16:38:58 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0|September 26, 2002) at 10/05/2002 16:57:05 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: Section 7.5, lock semantics Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6773 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I see this is already issue LOCK_INHERITANCE. I'll make it as approved awaiting inclusion in the spec. ------------------------------------------ Phone: 914-784-7569 From w3c-dist-auth-request@w3.org Mon Oct 7 05:04:46 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10919 for ; Mon, 7 Oct 2002 05:04:46 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9792J226041; Mon, 7 Oct 2002 05:02:19 -0400 (EDT) Resent-Date: Mon, 7 Oct 2002 05:02:19 -0400 (EDT) Resent-Message-Id: <200210070902.g9792J226041@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9792HB26012 for ; Mon, 7 Oct 2002 05:02:17 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA28144 for ; Mon, 7 Oct 2002 05:02:16 -0400 Received: from greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Mon, 07 Oct 2002 11:01:25 +0200 Date: Mon, 7 Oct 2002 11:01:28 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "Lisa Dusseault" , "'Webdav WG'" To: "Jason Crawford" From: Stefan Eissing In-Reply-To: Message-Id: <5DA6C024-D9D3-11D6-8D7B-00039384827E@greenbytes.de> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: Re: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6774 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Am Samstag, 05.10.02, um 01:06 Uhr (Europe/Berlin) schrieb Jason Crawford: > We need to hear more from folks. Things have been unusually quiet on > this > subject. > > Jason and Lisa have spoken up in favor of splitting the functionality. > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0397.html > (and > previous postings) > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0003.html > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0004.html > > Stefan has spoken against it before that time, but it is unclear if he > understood the proposal. Hopefully the proposal is clearer now. I try to summarize the proposal in my own wording. Let's see if we have a common understanding of the proposal: a) the If header is used for checking state of resource(s) as in 2518. ETags and lock tokens can be used for state checking. b) on modifications of resources, the server is required (as stated in 2518) to check if the client "submitted" the necessary tokens. A new header is introduced which keeps untagged lock tokens. Those lock tokens are regarded as "submitted by the client". c) lock tokens in If headers are not considered as "submitted by the client" d) all state productions in a If header are checked, not only those that apply to "affected" resources by the operation. I have further questions to this, but they can wait. Currently I am interested to know if this is a good summary of the key points of the proposal. //Stefan From w3c-dist-auth-request@w3.org Mon Oct 7 08:55:17 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA16749 for ; Mon, 7 Oct 2002 08:55:17 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g97CpWm27278; Mon, 7 Oct 2002 08:51:32 -0400 (EDT) Resent-Date: Mon, 7 Oct 2002 08:51:32 -0400 (EDT) Resent-Message-Id: <200210071251.g97CpWm27278@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g97CpVB27251 for ; Mon, 7 Oct 2002 08:51:31 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA01794 for ; Mon, 7 Oct 2002 08:51:31 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 07 Oct 2002 08:40:20 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 7 Oct 2002 08:50:55 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Mon, 7 Oct 2002 08:50:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26E00.287B9BC0" Subject: GULP (version 4) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6775 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26E00.287B9BC0 Content-Type: text/plain We are about to submit a new ID for the BIND extension, and as part of that work, we are verifying that locking semantics is clearly defined in the presence of multiple bindings to a single resource. The last time we were working on locking for the bind proposal (about 2.5 years ago :-), I submitted a series of GULPs (Grand Unified Locking Proposals), the last of which was V3: . The most complex part of this proposal was capturing the semantics of lock-null resources (and was a significant factor in my crusade agains them :-). Happily, now that we have cleaned up locking by removing lock-null resources, we can also significantly simplify the description of write-lock semantics: ************************** Grand Unified Lock Proposal (V4) - A lock is either direct or indirect. - A LOCK request places a direct lock on the resource identified by the request-URL. The "lock-root" of the new lock is the request-URL. - If a request causes a resource with a direct lock to no longer be mapped to the lock-root of that lock, then that lock MUST be removed from that resource. - If a collection has a direct depth:infinity lock with token X, all members of that collection (other than the collection itself) will have an indirect depth:infinity lock with token X. In particular, if a binding to a resource is added to a collection with a depth:infinity lock with token X, and if the resource does not have a lock with token X, then an indirect lock with token X is added to the resource. Conversely, if a resource has an indirect lock with token X, and if the result of removing a binding to the resource is that the resource is no longer a member of the collection with the direct lock with token X, then the lock with token X is removed from the resource. - If a request would modify the content, dead properties, or bindings of a locked resource, the request MUST fail unless the lock-token for that lock is specified in the request. - If a request would remove a lock from a resource, the request MUST fail unless the lock-token for that lock is specified in the request. - If a request would cause two different exclusive locks to appear on the same resource, the request MUST fail. ************************** If you have any locking use cases (no matter how obscure or unlikely) that are not properly covered by this proposal, please let me know. We're especially interested in obscure multiple binding use cases, such as cyclic bindings. Cheers, Geoff ------_=_NextPart_001_01C26E00.287B9BC0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable GULP (version 4)

We are about to submit a new ID for the BIND = extension, and as part of
that work, we are verifying that locking semantics = is clearly defined
in the presence of multiple bindings to a single = resource.  The last
time we were working on locking for the bind = proposal (about 2.5 years
ago :-), I submitted a series of GULPs (Grand = Unified Locking
Proposals), the last of which was V3:
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2000= JanMar/0061.html>.
The most complex part of this proposal was capturing = the semantics
of lock-null resources (and was a significant factor = in my crusade
agains them :-).  Happily, now that we have = cleaned up locking by
removing lock-null resources, we can also = significantly simplify
the description of write-lock semantics:

**************************

Grand Unified Lock Proposal (V4)

- A lock is either direct or indirect.

- A LOCK request places a direct lock on the resource = identified by
  the request-URL.  The = "lock-root" of the new lock is the request-URL.

- If a request causes a resource with a direct lock = to no longer be
  mapped to the lock-root of that lock, then = that lock MUST be removed
  from that resource.

- If a collection has a direct depth:infinity lock = with token X, all
  members of that collection (other than the = collection itself) will
  have an indirect depth:infinity lock with = token X.  In particular,
  if a binding to a resource is added to a = collection with a
  depth:infinity lock with token X, and if the = resource does not have
  a lock with token X, then an indirect lock = with token X is added to
  the resource.  Conversely, if a resource = has an indirect lock with
  token X, and if the result of removing a = binding to the resource is
  that the resource is no longer a member of = the collection with the
  direct lock with token X, then the lock with = token X is removed from
  the resource.

- If a request would modify the content, dead = properties, or bindings
  of a locked resource, the request MUST fail = unless the lock-token
  for that lock is specified in the = request.

- If a request would remove a lock from a resource, = the request MUST
  fail unless the lock-token for that lock is = specified in the
  request.

- If a request would cause two different exclusive = locks to appear on
  the same resource, the request MUST = fail.

**************************

If you have any locking use cases (no matter how = obscure or unlikely)
that are not properly covered by this proposal, = please let me know.
We're especially interested in obscure multiple = binding use cases,
such as cyclic bindings.

Cheers,
Geoff

------_=_NextPart_001_01C26E00.287B9BC0-- From w3c-dist-auth-request@w3.org Mon Oct 7 09:10:25 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA17239 for ; Mon, 7 Oct 2002 09:10:24 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g97D7XV00044; Mon, 7 Oct 2002 09:07:33 -0400 (EDT) Resent-Date: Mon, 7 Oct 2002 09:07:33 -0400 (EDT) Resent-Message-Id: <200210071307.g97D7XV00044@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g97D7WB00018 for ; Mon, 7 Oct 2002 09:07:32 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA06713 for ; Mon, 7 Oct 2002 09:07:30 -0400 Received: (qmail 8444 invoked by uid 0); 7 Oct 2002 13:06:58 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp014-rz3) with SMTP; 7 Oct 2002 13:06:58 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'Webdav WG'" Date: Mon, 7 Oct 2002 15:06:58 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_000F_01C26E13.2E6D8A80" 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.1106 In-Reply-To: Importance: Normal Subject: RE: GULP (version 4) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6776 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_000F_01C26E13.2E6D8A80 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit GULP (version 4)Geoff, maybe now it's *too* simple... I am missing rules that tell me which request URIs I can submit an UNLOCK request to. For instance, let /a and /b bindings to the same resource, which was exclusively locked on the URI /a. Can I unlock /b (using the lock token I get via DAV:lockdiscovery)? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff Sent: Monday, October 07, 2002 2:51 PM To: 'Webdav WG' Subject: GULP (version 4) We are about to submit a new ID for the BIND extension, and as part of that work, we are verifying that locking semantics is clearly defined in the presence of multiple bindings to a single resource. The last time we were working on locking for the bind proposal (about 2.5 years ago :-), I submitted a series of GULPs (Grand Unified Locking Proposals), the last of which was V3: . The most complex part of this proposal was capturing the semantics of lock-null resources (and was a significant factor in my crusade agains them :-). Happily, now that we have cleaned up locking by removing lock-null resources, we can also significantly simplify the description of write-lock semantics: ************************** Grand Unified Lock Proposal (V4) - A lock is either direct or indirect. - A LOCK request places a direct lock on the resource identified by the request-URL. The "lock-root" of the new lock is the request-URL. - If a request causes a resource with a direct lock to no longer be mapped to the lock-root of that lock, then that lock MUST be removed from that resource. - If a collection has a direct depth:infinity lock with token X, all members of that collection (other than the collection itself) will have an indirect depth:infinity lock with token X. In particular, if a binding to a resource is added to a collection with a depth:infinity lock with token X, and if the resource does not have a lock with token X, then an indirect lock with token X is added to the resource. Conversely, if a resource has an indirect lock with token X, and if the result of removing a binding to the resource is that the resource is no longer a member of the collection with the direct lock with token X, then the lock with token X is removed from the resource. - If a request would modify the content, dead properties, or bindings of a locked resource, the request MUST fail unless the lock-token for that lock is specified in the request. - If a request would remove a lock from a resource, the request MUST fail unless the lock-token for that lock is specified in the request. - If a request would cause two different exclusive locks to appear on the same resource, the request MUST fail. ************************** If you have any locking use cases (no matter how obscure or unlikely) that are not properly covered by this proposal, please let me know. We're especially interested in obscure multiple binding use cases, such as cyclic bindings. Cheers, Geoff ------=_NextPart_000_000F_01C26E13.2E6D8A80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable GULP (version 4)
Geoff,
 
maybe=20 now it's *too* simple...
 
I am=20 missing rules that tell me which request URIs I can submit an UNLOCK = request=20 to.
 
For=20 instance,  let /a and /b bindings to the same resource, which was=20 exclusively locked on the URI /a. Can I unlock /b (using the lock token = I get=20 via DAV:lockdiscovery)?
 
Julian

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

-----Original Message-----
From: = w3c-dist-auth-request@w3.org=20 [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm,=20 Geoff
Sent: Monday, October 07, 2002 2:51 PM
To: = 'Webdav=20 WG'
Subject: GULP (version 4)

We are about to submit a new ID for the BIND = extension, and as=20 part of
that work, we are verifying that = locking=20 semantics is clearly defined
in the presence = of=20 multiple bindings to a single resource.  The last =
time we were working on locking for the bind proposal (about = 2.5=20 years
ago :-), I submitted a series of GULPs = (Grand=20 Unified Locking
Proposals), the last of = which was=20 V3:
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2000Jan= Mar/0061.html>.=20
The most complex part of this proposal was = capturing the=20 semantics
of lock-null resources (and was a=20 significant factor in my crusade
agains them = :-).  Happily, now that we have cleaned up locking by =
removing lock-null resources, we can also significantly = simplify=20
the description of write-lock semantics: =

**************************

Grand Unified Lock Proposal (V4)

- A lock is either direct or indirect.

- A LOCK request places a direct lock on the = resource=20 identified by
  the request-URL.  = The=20 "lock-root" of the new lock is the request-URL.

- If a request causes a resource with a direct lock = to no=20 longer be
  mapped to the lock-root of = that lock,=20 then that lock MUST be removed
  from = that=20 resource.

- If a collection has a direct depth:infinity lock = with token=20 X, all
  members of that collection = (other than=20 the collection itself) will
  have an = indirect=20 depth:infinity lock with token X.  In particular, =
  if a binding to a resource is added to a collection = with=20 a
  depth:infinity lock with token X, = and if the=20 resource does not have
  a lock with = token X,=20 then an indirect lock with token X is added to
 =20 the resource.  Conversely, if a resource has an indirect lock = with=20
  token X, and if the result of removing a = binding to=20 the resource is
  that the resource is = no longer=20 a member of the collection with the
  = direct lock=20 with token X, then the lock with token X is removed from =
  the resource.

- If a request would modify the content, dead = properties, or=20 bindings
  of a locked resource, the = request MUST=20 fail unless the lock-token
  for that = lock is=20 specified in the request.

- If a request would remove a lock from a resource, = the=20 request MUST
  fail unless the = lock-token for=20 that lock is specified in the
  = request.=20

- If a request would cause two different exclusive = locks to=20 appear on
  the same resource, the = request MUST=20 fail.

**************************

If you have any locking use cases (no matter how = obscure or=20 unlikely)
that are not properly covered by = this=20 proposal, please let me know.
We're = especially=20 interested in obscure multiple binding use cases,
such=20 as cyclic bindings.

Cheers,
Geoff=20

------=_NextPart_000_000F_01C26E13.2E6D8A80-- From w3c-dist-auth-request@w3.org Mon Oct 7 09:35:40 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18001 for ; Mon, 7 Oct 2002 09:35:40 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g97DWML04603; Mon, 7 Oct 2002 09:32:22 -0400 (EDT) Resent-Date: Mon, 7 Oct 2002 09:32:22 -0400 (EDT) Resent-Message-Id: <200210071332.g97DWML04603@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g97DWMB04577 for ; Mon, 7 Oct 2002 09:32:22 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA12725 for ; Mon, 7 Oct 2002 09:32:20 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 07 Oct 2002 09:21:15 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 7 Oct 2002 09:31:50 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Mon, 7 Oct 2002 09:31:39 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26E05.DDFF8EC0" Subject: RE: GULP (version 4) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6777 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26E05.DDFF8EC0 Content-Type: text/plain; charset="iso-8859-1" That is covered by the rule: - If a request would remove a lock from a resource, the request MUST fail unless the lock-token for that lock is specified in the request. So, yes, you can use /b is the request-URL for the UNLOCK, as long as you submit the lock-token for the lock. Did you want to require that the request-URL of the UNLOCK be /a? Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Geoff, maybe now it's *too* simple... I am missing rules that tell me which request URIs I can submit an UNLOCK request to. For instance, let /a and /b bindings to the same resource, which was exclusively locked on the URI /a. Can I unlock /b (using the lock token I get via DAV:lockdiscovery)? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff Sent: Monday, October 07, 2002 2:51 PM To: 'Webdav WG' Subject: GULP (version 4) We are about to submit a new ID for the BIND extension, and as part of that work, we are verifying that locking semantics is clearly defined in the presence of multiple bindings to a single resource. The last time we were working on locking for the bind proposal (about 2.5 years ago :-), I submitted a series of GULPs (Grand Unified Locking Proposals), the last of which was V3: . The most complex part of this proposal was capturing the semantics of lock-null resources (and was a significant factor in my crusade agains them :-). Happily, now that we have cleaned up locking by removing lock-null resources, we can also significantly simplify the description of write-lock semantics: ************************** Grand Unified Lock Proposal (V4) - A lock is either direct or indirect. - A LOCK request places a direct lock on the resource identified by the request-URL. The "lock-root" of the new lock is the request-URL. - If a request causes a resource with a direct lock to no longer be mapped to the lock-root of that lock, then that lock MUST be removed from that resource. - If a collection has a direct depth:infinity lock with token X, all members of that collection (other than the collection itself) will have an indirect depth:infinity lock with token X. In particular, if a binding to a resource is added to a collection with a depth:infinity lock with token X, and if the resource does not have a lock with token X, then an indirect lock with token X is added to the resource. Conversely, if a resource has an indirect lock with token X, and if the result of removing a binding to the resource is that the resource is no longer a member of the collection with the direct lock with token X, then the lock with token X is removed from the resource. - If a request would modify the content, dead properties, or bindings of a locked resource, the request MUST fail unless the lock-token for that lock is specified in the request. - If a request would remove a lock from a resource, the request MUST fail unless the lock-token for that lock is specified in the request. - If a request would cause two different exclusive locks to appear on the same resource, the request MUST fail. ************************** If you have any locking use cases (no matter how obscure or unlikely) that are not properly covered by this proposal, please let me know. We're especially interested in obscure multiple binding use cases, such as cyclic bindings. Cheers, Geoff ------_=_NextPart_001_01C26E05.DDFF8EC0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: GULP (version 4)

That is covered by the rule:
- If a request would remove a lock from a resource, = the request MUST
  fail unless the lock-token for that lock is = specified in the
  request.

So, yes, you can use /b is the request-URL for the = UNLOCK, as long
as you submit the lock-token for the lock.

Did you want to require that the request-URL of the = UNLOCK be /a?

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]<= /FONT>

Geoff,

maybe now it's *too* simple...

I am missing rules that tell me which request URIs I = can submit an UNLOCK request to.

For instance,  let /a and /b bindings to the = same resource, which was exclusively locked on the URI /a. Can I unlock = /b (using the lock token I get via DAV:lockdiscovery)?

Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 =
-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-reques= t@w3.org]On Behalf Of Clemm, Geoff
Sent: Monday, October 07, 2002 2:51 PM
To: 'Webdav WG'
Subject: GULP (version 4)


We are about to submit a new ID for the BIND = extension, and as part of
that work, we are verifying that locking semantics = is clearly defined
in the presence of multiple bindings to a single = resource.  The last
time we were working on locking for the bind = proposal (about 2.5 years
ago :-), I submitted a series of GULPs (Grand = Unified Locking
Proposals), the last of which was V3:
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2000= JanMar/0061.html>.
The most complex part of this proposal was capturing = the semantics
of lock-null resources (and was a significant factor = in my crusade
agains them :-).  Happily, now that we have = cleaned up locking by
removing lock-null resources, we can also = significantly simplify
the description of write-lock semantics:
**************************
Grand Unified Lock Proposal (V4)
- A lock is either direct or indirect.
- A LOCK request places a direct lock on the = resource identified by
  the request-URL.  The = "lock-root" of the new lock is the request-URL.
- If a request causes a resource with a direct lock = to no longer be
  mapped to the lock-root of that lock, then = that lock MUST be removed
  from that resource.
- If a collection has a direct depth:infinity lock = with token X, all
  members of that collection (other than the = collection itself) will
  have an indirect depth:infinity lock with = token X.  In particular,
  if a binding to a resource is added to a = collection with a
  depth:infinity lock with token X, and if the = resource does not have
  a lock with token X, then an indirect lock = with token X is added to
  the resource.  Conversely, if a resource = has an indirect lock with
  token X, and if the result of removing a = binding to the resource is
  that the resource is no longer a member of = the collection with the
  direct lock with token X, then the lock with = token X is removed from
  the resource.
- If a request would modify the content, dead = properties, or bindings
  of a locked resource, the request MUST fail = unless the lock-token
  for that lock is specified in the request. =
- If a request would remove a lock from a resource, = the request MUST
  fail unless the lock-token for that lock is = specified in the
  request.
- If a request would cause two different exclusive = locks to appear on
  the same resource, the request MUST fail. =
**************************
If you have any locking use cases (no matter how = obscure or unlikely)
that are not properly covered by this proposal, = please let me know.
We're especially interested in obscure multiple = binding use cases,
such as cyclic bindings.
Cheers,
Geoff

------_=_NextPart_001_01C26E05.DDFF8EC0-- From w3c-dist-auth-request@w3.org Mon Oct 7 09:49:18 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA18605 for ; Mon, 7 Oct 2002 09:49:18 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g97Dj6T06610; Mon, 7 Oct 2002 09:45:06 -0400 (EDT) Resent-Date: Mon, 7 Oct 2002 09:45:06 -0400 (EDT) Resent-Message-Id: <200210071345.g97Dj6T06610@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g97Dj5B06581 for ; Mon, 7 Oct 2002 09:45:05 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA16854 for ; Mon, 7 Oct 2002 09:45:03 -0400 Received: (qmail 17450 invoked by uid 0); 7 Oct 2002 13:44:32 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp020-rz3) with SMTP; 7 Oct 2002 13:44:32 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'Webdav WG'" Date: Mon, 7 Oct 2002 15:44:31 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_001E_01C26E18.6D706C70" 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.1106 In-Reply-To: Importance: Normal Subject: RE: GULP (version 4) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6778 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_001E_01C26E18.6D706C70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: GULP (version 4)Geoff, yes, that's what I wanted. At least it seemed to me that we had agreed on that. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff Sent: Monday, October 07, 2002 3:32 PM To: 'Webdav WG' Subject: RE: GULP (version 4) That is covered by the rule: - If a request would remove a lock from a resource, the request MUST fail unless the lock-token for that lock is specified in the request. So, yes, you can use /b is the request-URL for the UNLOCK, as long as you submit the lock-token for the lock. Did you want to require that the request-URL of the UNLOCK be /a? Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Geoff, maybe now it's *too* simple... I am missing rules that tell me which request URIs I can submit an UNLOCK request to. For instance, let /a and /b bindings to the same resource, which was exclusively locked on the URI /a. Can I unlock /b (using the lock token I get via DAV:lockdiscovery)? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff Sent: Monday, October 07, 2002 2:51 PM To: 'Webdav WG' Subject: GULP (version 4) We are about to submit a new ID for the BIND extension, and as part of that work, we are verifying that locking semantics is clearly defined in the presence of multiple bindings to a single resource. The last time we were working on locking for the bind proposal (about 2.5 years ago :-), I submitted a series of GULPs (Grand Unified Locking Proposals), the last of which was V3: . The most complex part of this proposal was capturing the semantics of lock-null resources (and was a significant factor in my crusade agains them :-). Happily, now that we have cleaned up locking by removing lock-null resources, we can also significantly simplify the description of write-lock semantics: ************************** Grand Unified Lock Proposal (V4) - A lock is either direct or indirect. - A LOCK request places a direct lock on the resource identified by the request-URL. The "lock-root" of the new lock is the request-URL. - If a request causes a resource with a direct lock to no longer be mapped to the lock-root of that lock, then that lock MUST be removed from that resource. - If a collection has a direct depth:infinity lock with token X, all members of that collection (other than the collection itself) will have an indirect depth:infinity lock with token X. In particular, if a binding to a resource is added to a collection with a depth:infinity lock with token X, and if the resource does not have a lock with token X, then an indirect lock with token X is added to the resource. Conversely, if a resource has an indirect lock with token X, and if the result of removing a binding to the resource is that the resource is no longer a member of the collection with the direct lock with token X, then the lock with token X is removed from the resource. - If a request would modify the content, dead properties, or bindings of a locked resource, the request MUST fail unless the lock-token for that lock is specified in the request. - If a request would remove a lock from a resource, the request MUST fail unless the lock-token for that lock is specified in the request. - If a request would cause two different exclusive locks to appear on the same resource, the request MUST fail. ************************** If you have any locking use cases (no matter how obscure or unlikely) that are not properly covered by this proposal, please let me know. We're especially interested in obscure multiple binding use cases, such as cyclic bindings. Cheers, Geoff ------=_NextPart_000_001E_01C26E18.6D706C70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: GULP (version 4)
Geoff,
 
yes,=20 that's what I wanted. At least it seemed to me that we had agreed on=20 that.
 
Julian

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

-----Original Message-----
From: = w3c-dist-auth-request@w3.org=20 [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm,=20 Geoff
Sent: Monday, October 07, 2002 3:32 PM
To: = 'Webdav=20 WG'
Subject: RE: GULP (version 4)

That is covered by the rule:
- If a=20 request would remove a lock from a resource, the request MUST =
  fail unless the lock-token for that lock is specified = in the=20
  request.

So, yes, you can use /b is the request-URL for the = UNLOCK, as=20 long
as you submit the lock-token for the = lock.=20

Did you want to require that the request-URL of the = UNLOCK be=20 /a?

Cheers,
Geoff

-----Original Message-----
From:=20 Julian Reschke [mailto:julian.reschke@gmx.de]=20

Geoff,

maybe now it's *too* simple...

I am missing rules that tell me which request URIs I = can=20 submit an UNLOCK request to.

For instance,  let /a and /b bindings to the = same=20 resource, which was exclusively locked on the URI /a. Can I unlock /b = (using=20 the lock token I get via DAV:lockdiscovery)?

Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760=20
-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request= @w3.org]On=20 Behalf Of Clemm, Geoff
Sent: Monday, October = 07, 2002=20 2:51 PM
To: 'Webdav WG'
Subject: GULP (version 4)


We are about to submit a new ID for the BIND = extension, and as=20 part of
that work, we are verifying that = locking=20 semantics is clearly defined
in the presence = of=20 multiple bindings to a single resource.  The last =
time we were working on locking for the bind proposal (about = 2.5 years=20
ago :-), I submitted a series of GULPs = (Grand Unified=20 Locking
Proposals), the last of which was = V3:=20
<http://lists.w3.org/Archives/Public/w3c-dist-auth/2000Jan= Mar/0061.html>.=20
The most complex part of this proposal was = capturing=20 the semantics
of lock-null resources (and = was a=20 significant factor in my crusade
agains them = :-).  Happily, now that we have cleaned up locking by =
removing lock-null resources, we can also significantly = simplify=20
the description of write-lock semantics:=20
**************************
Grand Unified Lock Proposal (V4)
- = A lock is=20 either direct or indirect.
- A LOCK request = places a=20 direct lock on the resource identified by
  the=20 request-URL.  The "lock-root" of the new lock is the request-URL. =
- If a request causes a resource with a = direct lock to=20 no longer be
  mapped to the lock-root = of that=20 lock, then that lock MUST be removed
  = from that=20 resource.
- If a collection has a direct=20 depth:infinity lock with token X, all
  = members=20 of that collection (other than the collection itself) will =
  have an indirect depth:infinity lock with token = X.  In=20 particular,
  if a binding to a = resource is added=20 to a collection with a
  depth:infinity = lock with=20 token X, and if the resource does not have
  a=20 lock with token X, then an indirect lock with token X is added to=20
  the resource.  Conversely, if a = resource=20 has an indirect lock with
  token X, = and if the=20 result of removing a binding to the resource is
 =20 that the resource is no longer a member of the collection with the=20
  direct lock with token X, then the = lock with=20 token X is removed from
  the resource. =
- If a request would modify the content, = dead=20 properties, or bindings
  of a locked = resource,=20 the request MUST fail unless the lock-token
  for=20 that lock is specified in the request.
- If = a request=20 would remove a lock from a resource, the request MUST
  fail unless the lock-token for that lock is specified = in the=20
  request.
- = If a request=20 would cause two different exclusive locks to appear on =
  the same resource, the request MUST fail. =
**************************
If you = have any=20 locking use cases (no matter how obscure or unlikely)
that are not properly covered by this proposal, please let me = know.=20
We're especially interested in obscure = multiple=20 binding use cases,
such as cyclic bindings.=20
Cheers,
Geoff=20

------=_NextPart_000_001E_01C26E18.6D706C70-- From w3c-dist-auth-request@w3.org Mon Oct 7 10:28:29 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA20615 for ; Mon, 7 Oct 2002 10:28:27 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g97EQDf12946; Mon, 7 Oct 2002 10:26:13 -0400 (EDT) Resent-Date: Mon, 7 Oct 2002 10:26:13 -0400 (EDT) Resent-Message-Id: <200210071426.g97EQDf12946@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g97EQCB12908 for ; Mon, 7 Oct 2002 10:26:12 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA31626 for ; Mon, 7 Oct 2002 10:26:12 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 07 Oct 2002 10:15:06 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 7 Oct 2002 10:25:41 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Mon, 7 Oct 2002 10:25:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26E0D.6768D930" Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6779 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26E0D.6768D930 Content-Type: text/plain I continue to be strongly against splitting the If header functionality, primarily to maintain interoperability between new clients and old servers, and between old clients and new servers. Any new client that sends just the new header, without also sending the same information in the If header, will fail against all old servers. A client could put in logic to send the new header to new servers and the If header to old servers, but then you've just increased the interoperation complexity of clients, not decreased it. Similarly, any new server that only accepts the lock token list from the new header, and not from the If header, will fail against all old clients. A server could put in logic to handle both the old and the new headers, but again, you've just increased the interoperation complexity of servers, not decreased it. There is another question, which is that even if we leave the semantics of the If header alone (to maintain interoperability between new clients and old servers, and old clients and new servers), should we introduce a new header that gives the client the ability to submit a no longer valid lock token, and still have the request succeed. I am against the addition of this new header, because I believe the arguments in favor of it confuse the purpose of a lock and the purpose of an etag. An etag prevents lost updates. You will be notified if you are about to overwrite some other user's update, but you are then left with a merge situation. A lock prevents merge situations (and thereby also prevents lost updates). If you only care about lost updates, then you can just use etags. The only reason to use locks is if: (1) you want to prevent merge situations, or (2) the resource supports locks but not etags. In either case, you always need to know about lost locks because in case (1), you are no longer protected against merge situations, or in case (2), you no longer are protected against lost updates. As a general principle, I believe that unless there is no alternative, we should do all we can to reward implementors that have fully and correctly implemented the specification, by maximizing the likelihood that new clients and new servers will interoperate successfully with those correctly and fully implemented old clients and servers. Therefore, I believe that the use of the If header should be clarified in RFC2518 bis (and in particular, guidance for how to use it to submit lock tokens), but that the If semantics should remain unchanged, and a new header which allows the submission of invalid lock tokens should not be added. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:nn683849@smallcue.com] Sent: Friday, October 04, 2002 7:06 PM To: Lisa Dusseault Cc: 'Stefan Eissing'; 'Webdav WG' Subject: RE: Interop issue: Proposal for fixing lock token provision We need to hear more from folks. Things have been unusually quiet on this subject. Jason and Lisa have spoken up in favor of splitting the functionality. http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0397.html (and previous postings) http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0003.html http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0004.html Stefan has spoken against it before that time, but it is unclear if he understood the proposal. Hopefully the proposal is clearer now. Let's hear from you folks... J. ------------------------------------------ Phone: 914-784-7569 ------_=_NextPart_001_01C26E0D.6768D930 Content-Type: text/html RE: Interop issue: Proposal for fixing lock token provision

I continue to be strongly against splitting the If header
functionality, primarily to maintain interoperability between new
clients and old servers, and between old clients and new servers.

Any new client that sends just the new header, without also sending
the same information in the If header, will fail against all old
servers.  A client could put in logic to send the new header to new
servers and the If header to old servers, but then you've just
increased the interoperation complexity of clients, not decreased it.

Similarly, any new server that only accepts the lock token list from
the new header, and not from the If header, will fail against all old
clients.  A server could put in logic to handle both the old and the
new headers, but again, you've just increased the interoperation
complexity of servers, not decreased it.

There is another question, which is that even if we leave the
semantics of the If header alone (to maintain interoperability between
new clients and old servers, and old clients and new servers), should
we introduce a new header that gives the client the ability to submit
a no longer valid lock token, and still have the request succeed.

I am against the addition of this new header, because I believe the
arguments in favor of it confuse the purpose of a lock and the purpose
of an etag.  An etag prevents lost updates.  You will be notified if
you are about to overwrite some other user's update, but you are then
left with a merge situation.  A lock prevents merge situations (and
thereby also prevents lost updates).  If you only care about lost
updates, then you can just use etags.  The only reason to use locks is
if: (1) you want to prevent merge situations, or (2) the resource
supports locks but not etags.  In either case, you always need to know
about lost locks because in case (1), you are no longer protected
against merge situations, or in case (2), you no longer are protected
against lost updates.

As a general principle, I believe that unless there is no alternative,
we should do all we can to reward implementors that have fully and
correctly implemented the specification, by maximizing the likelihood
that new clients and new servers will interoperate successfully with
those correctly and fully implemented old clients and servers.
Therefore, I believe that the use of the If header should be clarified
in RFC2518 bis (and in particular, guidance for how to use it to
submit lock tokens), but that the If semantics should remain
unchanged, and a new header which allows the submission of invalid
lock tokens should not be added.

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:nn683849@smallcue.com]
Sent: Friday, October 04, 2002 7:06 PM
To: Lisa Dusseault
Cc: 'Stefan Eissing'; 'Webdav WG'
Subject: RE: Interop issue: Proposal for fixing lock token provision







We need to hear more from folks.  Things have been unusually quiet on this
subject.

Jason and Lisa have spoken up in favor of splitting the functionality.

http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0397.html (and
previous postings)
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0003.html
http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0004.html

Stefan has spoken against it before that time, but it is unclear if he
understood the
proposal.  Hopefully the proposal is clearer now.

Let's hear from you folks...

J.

------------------------------------------
Phone: 914-784-7569

------_=_NextPart_001_01C26E0D.6768D930-- From w3c-dist-auth-request@w3.org Mon Oct 7 10:38:03 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21209 for ; Mon, 7 Oct 2002 10:38:03 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g97EZsU15345; Mon, 7 Oct 2002 10:35:54 -0400 (EDT) Resent-Date: Mon, 7 Oct 2002 10:35:54 -0400 (EDT) Resent-Message-Id: <200210071435.g97EZsU15345@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g97EZrB15308 for ; Mon, 7 Oct 2002 10:35:53 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA01920 for ; Mon, 7 Oct 2002 10:35:53 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 07 Oct 2002 10:24:47 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 7 Oct 2002 10:35:22 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Mon, 7 Oct 2002 10:35:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26E0E.C20944A0" Subject: RE: GULP (version 4) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6780 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26E0E.C20944A0 Content-Type: text/plain; charset="iso-8859-1" Either way is fine with me. But note that I consider that to be a marshalling detail of the UNLOCK request (since the server will be maintaining the lock-root, why would it care?) ... the GULP lock semantics should apply however we decide to marshall UNLOCK. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] yes, that's what I wanted. At least it seemed to me that we had agreed on that. -----Original Message----- From: Clemm, Geoff That is covered by the rule: - If a request would remove a lock from a resource, the request MUST fail unless the lock-token for that lock is specified in the request. So, yes, you can use /b is the request-URL for the UNLOCK, as long as you submit the lock-token for the lock. Did you want to require that the request-URL of the UNLOCK be /a? -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] maybe now it's *too* simple... I am missing rules that tell me which request URIs I can submit an UNLOCK request to. For instance, let /a and /b bindings to the same resource, which was exclusively locked on the URI /a. Can I unlock /b (using the lock token I get via DAV:lockdiscovery)? -----Original Message----- From: Clemm, Geoff ************************** Grand Unified Lock Proposal (V4) - A lock is either direct or indirect. - A LOCK request places a direct lock on the resource identified by the request-URL. The "lock-root" of the new lock is the request-URL. - If a request causes a resource with a direct lock to no longer be mapped to the lock-root of that lock, then that lock MUST be removed from that resource. - If a collection has a direct depth:infinity lock with token X, all members of that collection (other than the collection itself) will have an indirect depth:infinity lock with token X. In particular, if a binding to a resource is added to a collection with a depth:infinity lock with token X, and if the resource does not have a lock with token X, then an indirect lock with token X is added to the resource. Conversely, if a resource has an indirect lock with token X, and if the result of removing a binding to the resource is that the resource is no longer a member of the collection with the direct lock with token X, then the lock with token X is removed from the resource. - If a request would modify the content, dead properties, or bindings of a locked resource, the request MUST fail unless the lock-token for that lock is specified in the request. - If a request would remove a lock from a resource, the request MUST fail unless the lock-token for that lock is specified in the request. - If a request would cause two different exclusive locks to appear on the same resource, the request MUST fail. ************************** ------_=_NextPart_001_01C26E0E.C20944A0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: GULP (version 4)

Either way is fine with me.  But note that I = consider that to
be a marshalling detail of the UNLOCK request (since = the server
will be maintaining the lock-root, why would it = care?) ... the GULP
lock semantics should apply however we decide to = marshall UNLOCK.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]<= /FONT>

yes, that's what I wanted. At least it seemed to me = that we had agreed on that.


-----Original Message-----
From:  Clemm, Geoff

That is covered by the rule:
- If a request would remove a lock from a resource, = the request MUST
  fail unless the lock-token for that lock is = specified in the
  request.
So, yes, you can use /b is the request-URL for the = UNLOCK, as long
as you submit the lock-token for the lock.
Did you want to require that the request-URL of the = UNLOCK be /a?

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de] =

maybe now it's *too* simple...
I am missing rules that tell me which request URIs I = can submit an UNLOCK request to.
For instance,  let /a and /b bindings to the = same resource, which was exclusively locked on the URI /a. Can I unlock = /b (using the lock token I get via DAV:lockdiscovery)?

-----Original Message-----
From:  Clemm, Geoff

**************************
Grand Unified Lock Proposal (V4)
- A lock is either direct or indirect.
- A LOCK request places a direct lock on the = resource identified by
  the request-URL.  The = "lock-root" of the new lock is the request-URL.
- If a request causes a resource with a direct lock = to no longer be
  mapped to the lock-root of that lock, then = that lock MUST be removed
  from that resource.
- If a collection has a direct depth:infinity lock = with token X, all
  members of that collection (other than the = collection itself) will
  have an indirect depth:infinity lock with = token X.  In particular,
  if a binding to a resource is added to a = collection with a
  depth:infinity lock with token X, and if the = resource does not have
  a lock with token X, then an indirect lock = with token X is added to
  the resource.  Conversely, if a resource = has an indirect lock with
  token X, and if the result of removing a = binding to the resource is
  that the resource is no longer a member of = the collection with the
  direct lock with token X, then the lock with = token X is removed from
  the resource.
- If a request would modify the content, dead = properties, or bindings
  of a locked resource, the request MUST fail = unless the lock-token
  for that lock is specified in the request. =
- If a request would remove a lock from a resource, = the request MUST
  fail unless the lock-token for that lock is = specified in the
  request.
- If a request would cause two different exclusive = locks to appear on
  the same resource, the request MUST fail. =
**************************

------_=_NextPart_001_01C26E0E.C20944A0-- From w3c-dist-auth-request@w3.org Mon Oct 7 11:07:25 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA22328 for ; Mon, 7 Oct 2002 11:07:24 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g97F4c519655; Mon, 7 Oct 2002 11:04:38 -0400 (EDT) Resent-Date: Mon, 7 Oct 2002 11:04:38 -0400 (EDT) Resent-Message-Id: <200210071504.g97F4c519655@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g97F4cB19629 for ; Mon, 7 Oct 2002 11:04:38 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with SMTP id LAA08864 for ; Mon, 7 Oct 2002 11:04:37 -0400 Received: from greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Mon, 07 Oct 2002 17:03:45 +0200 Date: Mon, 7 Oct 2002 17:03:42 +0200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "'Webdav WG'" To: "Clemm, Geoff" From: Stefan Eissing In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.546) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g97F4cB19629 Subject: Re: GULP (version 4) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6781 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Am Montag, 07.10.02, um 16:35 Uhr (Europe/Berlin) schrieb Clemm, Geoff: > Either way is fine with me.  But note that I consider that to > be a marshalling detail of the UNLOCK request (since the server > will be maintaining the lock-root, why would it care?) ... the GULP > lock semantics should apply however we decide to marshall UNLOCK. Unless shown any benefit in this restriction of UNLOCK, I favor that the "correct" URI of the request does not matter. The primary function is to unlock the resource, not the URI. //Stefan > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > yes, that's what I wanted. At least it seemed to me that we had agreed > on that. > > > -----Original Message----- > From:  Clemm, Geoff > > That is covered by the rule: > - If a request would remove a lock from a resource, the request MUST >   fail unless the lock-token for that lock is specified in the >   request. > So, yes, you can use /b is the request-URL for the UNLOCK, as long > as you submit the lock-token for the lock. > Did you want to require that the request-URL of the UNLOCK be /a? > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > maybe now it's *too* simple... > I am missing rules that tell me which request URIs I can submit an > UNLOCK request to. > For instance,  let /a and /b bindings to the same resource, which was > exclusively locked on the URI /a. Can I unlock /b (using the lock > token I get via DAV:lockdiscovery)? > > -----Original Message----- > From:  Clemm, Geoff > > ************************** > Grand Unified Lock Proposal (V4) > - A lock is either direct or indirect. > - A LOCK request places a direct lock on the resource identified by >   the request-URL.  The "lock-root" of the new lock is the request-URL. > - If a request causes a resource with a direct lock to no longer be >   mapped to the lock-root of that lock, then that lock MUST be removed >   from that resource. > - If a collection has a direct depth:infinity lock with token X, all >   members of that collection (other than the collection itself) will >   have an indirect depth:infinity lock with token X.  In particular, >   if a binding to a resource is added to a collection with a >   depth:infinity lock with token X, and if the resource does not have >   a lock with token X, then an indirect lock with token X is added to >   the resource.  Conversely, if a resource has an indirect lock with >   token X, and if the result of removing a binding to the resource is >   that the resource is no longer a member of the collection with the >   direct lock with token X, then the lock with token X is removed from >   the resource. > - If a request would modify the content, dead properties, or bindings >   of a locked resource, the request MUST fail unless the lock-token >   for that lock is specified in the request. > - If a request would remove a lock from a resource, the request MUST >   fail unless the lock-token for that lock is specified in the >   request. > - If a request would cause two different exclusive locks to appear on >   the same resource, the request MUST fail. > ************************** > From w3c-dist-auth-request@w3.org Mon Oct 7 11:27:43 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA23054 for ; Mon, 7 Oct 2002 11:27:42 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g97FPK722794; Mon, 7 Oct 2002 11:25:20 -0400 (EDT) Resent-Date: Mon, 7 Oct 2002 11:25:20 -0400 (EDT) Resent-Message-Id: <200210071525.g97FPK722794@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g97FPJB22765 for ; Mon, 7 Oct 2002 11:25:19 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA14482 for ; Mon, 7 Oct 2002 11:25:19 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 07 Oct 2002 11:14:13 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 7 Oct 2002 11:24:48 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Mon, 7 Oct 2002 11:24:35 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26E15.A472F100" Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6782 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26E15.A472F100 Content-Type: text/plain From: Clemm, Geoff [mailto:gclemm@Rational.Com] ... Therefore, I believe that the use of the If header should be clarified in RFC2518 bis (and in particular, guidance for how to use it to submit lock tokens), but that the If semantics should remain unchanged, and a new header which allows the submission of invalid lock tokens should not be added. As an example of clarifying how to use the If header to submit lock tokens, we could say: "When submitting multiple lock tokens, clients SHOULD use the tagged-list production of the If header". Cheers, Geoff ------_=_NextPart_001_01C26E15.A472F100 Content-Type: text/html RE: Interop issue: Proposal for fixing lock token provision

   From: Clemm, Geoff [mailto:gclemm@Rational.Com]

   ...
   Therefore, I believe that the use of the If header should be
   clarified in RFC2518 bis (and in particular, guidance for how to
   use it to submit lock tokens), but that the If semantics should
   remain unchanged, and a new header which allows the submission of
   invalid lock tokens should not be added.

As an example of clarifying how to use the If header to
submit lock tokens, we could say:

"When submitting multiple lock tokens, clients SHOULD use
the tagged-list production of the If header".

Cheers,
Geoff

------_=_NextPart_001_01C26E15.A472F100-- From w3c-dist-auth-request@w3.org Mon Oct 7 11:51:14 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA24043 for ; Mon, 7 Oct 2002 11:51:14 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g97FmEV00226; Mon, 7 Oct 2002 11:48:14 -0400 (EDT) Resent-Date: Mon, 7 Oct 2002 11:48:14 -0400 (EDT) Resent-Message-Id: <200210071548.g97FmEV00226@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g97FmEB00196 for ; Mon, 7 Oct 2002 11:48:14 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA21883 for ; Mon, 7 Oct 2002 11:48:06 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id IAA27174 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Mon, 7 Oct 2002 08:47:53 -0700 Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by sunbelt.seagull.net (8.9.3) with ESMTP id IAA27148 sender obsfucated@us.ibm.com; Mon, 7 Oct 2002 08:47:50 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g97FlJDn118666; Mon, 7 Oct 2002 11:47:19 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g97FlHOB117048; Mon, 7 Oct 2002 11:47:17 -0400 To: Stefan Eissing Cc: "Lisa Dusseault" , "'Webdav WG'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Jason Crawford Date: Mon, 7 Oct 2002 11:27:44 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0|September 26, 2002) at 10/07/2002 11:47:16 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: Re: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6783 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Monday, 10/07/2002 at 11:01 ZE2, Stefan Eissing wrote: > Am Samstag, 05.10.02, um 01:06 Uhr (Europe/Berlin) schrieb Jason > Crawford: > > > We need to hear more from folks. Things have been unusually quiet on > > this > > subject. > > > > Jason and Lisa have spoken up in favor of splitting the functionality. > > > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002JulSep/0397.html > > (and > > previous postings) > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0003.html > > http://lists.w3.org/Archives/Public/w3c-dist-auth/2002OctDec/0004.html > > > > Stefan has spoken against it before that time, but it is unclear if he > > understood the proposal. Hopefully the proposal is clearer now. > > I try to summarize the proposal in my own wording. Let's see if we > have a common understanding of the proposal: > > a) the If header is used for checking state of resource(s) as in 2518. > ETags and lock tokens can be used for state checking. Yes. > b) on modifications of resources, the server is required (as stated in > 2518) to check if the client "submitted" the necessary tokens. > A new header is introduced which keeps untagged lock tokens. Those > lock tokens are regarded as "submitted by the client". Yes. I'd prefer that it be untagged, but that's negotiable. > c) lock tokens in If headers are not considered as "submitted by the > client" Yes, but for compatibility reasons, if the client didn't provide the new submit header, the server prudently can be expected to check the If: header using whatever semantics that it thinks 2518 specifies regarding token submission. Similarly, for compatibility reasons (in addition to any correctness reasons) we might expect the client to continue to submit If headers. For compatibility reasons a production client wouldn't depend on the server checking conditions on resources other than ones the server thinks are pertinent, but we can begin to test interoperability of that. Eventually though clients would only submit the If: header for correctness reasons and will feel free to do checks on any resource it feels is appropriate. > d) all state productions in a If header are checked, not only those that > apply to "affected" resources by the operation. Yes, Initially clients that are spamming the If: header will pay a price for that. But as they eventually move to the new header or stop spamming the If: header, that price will no longer be paid. The tact that can be taken in production systems is... New clients can submit the new header and only the If: clauses that it feels it wants tested. If the LOCKED error code is returned, they can resubmit to check if the error is just a problem with an old server. This means there will be a price for using an old server, but things will still work and it will be an incentive to upgrade. New clients can submit If: clauses for extra resources, but they will not be written to be dependent on submitting extra If: clauses to achieve correctness. Not unless they have a way to verify that the server supports this. I don't see this as a problem since we aren't emphasizing this feature yet. But eventually it becomes a possibility. New servers will know that if a client submits a new header, that it should process that new header. In that case it will also process *all* of the If: header clauses and we can test servers to verify that they support this even if production clients don't exercise this feature. If new servers receive a request that does not have the new header, they will fall back on whatever code they currently use for If: headers submitting lock tokens. That's what productions systems could do. Testing systems and tightly integrated systems could actually fully exercise the new features. J. ------------------------------------------ Phone: 914-784-7569 From w3c-dist-auth-request@w3.org Mon Oct 7 13:41:18 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA28236 for ; Mon, 7 Oct 2002 13:41:18 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g97HcnH25564; Mon, 7 Oct 2002 13:38:49 -0400 (EDT) Resent-Date: Mon, 7 Oct 2002 13:38:49 -0400 (EDT) Resent-Message-Id: <200210071738.g97HcnH25564@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g97HclB25534 for ; Mon, 7 Oct 2002 13:38:47 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA17241 for ; Mon, 7 Oct 2002 13:38:47 -0400 Received: (qmail 31874 invoked by uid 0); 7 Oct 2002 17:38:16 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp020-rz3) with SMTP; 7 Oct 2002 17:38:16 -0000 From: "Julian Reschke" To: "'Webdav WG'" Date: Mon, 7 Oct 2002 19:38:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: Microsoft Content Management System vs. WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6784 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, does anybody know whether this thing... http://www.microsoft.com/cmserver/ speaks WebDAV? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Oct 7 14:17:18 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29553 for ; Mon, 7 Oct 2002 14:17:18 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g97IF1o29679; Mon, 7 Oct 2002 14:15:01 -0400 (EDT) Resent-Date: Mon, 7 Oct 2002 14:15:01 -0400 (EDT) Resent-Message-Id: <200210071815.g97IF1o29679@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g97IF0B29624 for ; Mon, 7 Oct 2002 14:15:00 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA23535 for ; Mon, 7 Oct 2002 14:15:00 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 07 Oct 2002 14:03:51 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 7 Oct 2002 14:14:27 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Mon, 7 Oct 2002 14:14:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26E2D.5D3540F0" Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6785 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26E2D.5D3540F0 Content-Type: text/plain Alternatively, we could just say: "A client MUST submit a tagged-list If header, using the DAV:lock-root of the lock as the tag for that lock token." A simple rule for new clients, that will interoperate with all correctly implemented old and new servers. If any of the tagged-list productions fail, the resource that is no longer locked will be indicated with a 412 in the multistatus return, telling the client to either remove that lock from its table, or request a new lock for that resource. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:nn683849@smallcue.com] for compatibility reasons, if the client didn't provide the new submit header, the server prudently can be expected to check the If: header using whatever semantics that it thinks 2518 specifies regarding token submission. Similarly, for compatibility reasons (in addition to any correctness reasons) we might expect the client to continue to submit If headers. For compatibility reasons a production client wouldn't depend on the server checking conditions on resources other than ones the server thinks are pertinent, but we can begin to test interoperability of that. Eventually though clients would only submit the If: header for correctness reasons and will feel free to do checks on any resource it feels is appropriate. > d) all state productions in a If header are checked, not only those that > apply to "affected" resources by the operation. Yes, Initially clients that are spamming the If: header will pay a price for that. But as they eventually move to the new header or stop spamming the If: header, that price will no longer be paid. The tact that can be taken in production systems is... New clients can submit the new header and only the If: clauses that it feels it wants tested. If the LOCKED error code is returned, they can resubmit to check if the error is just a problem with an old server. This means there will be a price for using an old server, but things will still work and it will be an incentive to upgrade. New clients can submit If: clauses for extra resources, but they will not be written to be dependent on submitting extra If: clauses to achieve correctness. Not unless they have a way to verify that the server supports this. I don't see this as a problem since we aren't emphasizing this feature yet. But eventually it becomes a possibility. New servers will know that if a client submits a new header, that it should process that new header. In that case it will also process *all* of the If: header clauses and we can test servers to verify that they support this even if production clients don't exercise this feature. If new servers receive a request that does not have the new header, they will fall back on whatever code they currently use for If: headers submitting lock tokens. That's what productions systems could do. Testing systems and tightly integrated systems could actually fully exercise the new features. J. ------------------------------------------ Phone: 914-784-7569 ------_=_NextPart_001_01C26E2D.5D3540F0 Content-Type: text/html RE: Interop issue: Proposal for fixing lock token provision

Alternatively, we could just say:

"A client MUST submit a tagged-list If header, using the
DAV:lock-root of the lock as the tag for that lock token."

A simple rule for new clients, that will interoperate with
all correctly implemented old and new servers.

If any of the tagged-list productions fail, the resource
that is no longer locked will be indicated with a 412 in
the multistatus return, telling the client to either remove
that lock from its table, or request a new lock for that
resource.

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:nn683849@smallcue.com]

for compatibility reasons, if the client didn't provide the new submit
header, the server prudently can be expected to check the If: header
using whatever semantics that it thinks 2518 specifies regarding
token submission.

Similarly, for compatibility reasons (in addition to any correctness
reasons)
we might expect the client to continue to submit If headers.  For
compatibility
reasons a production client wouldn't depend on the server checking
conditions on
resources other than ones the server thinks are pertinent, but we can begin
to
test interoperability of that.   Eventually though clients would only
submit
the If: header for correctness reasons and will feel free to do checks on
any resource it feels is appropriate.

> d) all state productions in a If header are checked, not only those that
>    apply to "affected" resources by the operation.
Yes,  Initially clients that are spamming the If: header will pay a price
for that.  But as they eventually move to the new header or stop
spamming the If: header, that price will no longer be paid.


The tact that can be taken in production systems is...

New clients can submit the new header and only the If: clauses that it
feels
it wants tested.  If the LOCKED error code is returned, they can resubmit
to check if the error is just a problem with an old server.   This means
there
will be a price for using an old server, but things will still work and it
will be
an incentive to upgrade.

New clients can submit If: clauses for extra resources, but they will not
be
written to be dependent on submitting extra If: clauses to achieve
correctness.  Not unless they have a way to verify that the server
supports this.  I don't see this as a problem since we aren't emphasizing
this feature yet.  But eventually it becomes a possibility.

New servers will know that if a client submits a new header, that it should
process that new header.   In that case it will also process *all* of the
If: header
clauses and we can test servers to verify that they support this even if
production clients don't exercise this feature.

If new servers receive a request that does not have the new header, they
will fall back on whatever code they currently use for If: headers
submitting
lock tokens.

That's what productions systems could do.  Testing systems and tightly
integrated systems could actually fully exercise the new features.

J.

------------------------------------------
Phone: 914-784-7569

------_=_NextPart_001_01C26E2D.5D3540F0-- From w3c-dist-auth-request@w3.org Mon Oct 7 15:20:45 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01935 for ; Mon, 7 Oct 2002 15:20:44 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g97JIVF07269; Mon, 7 Oct 2002 15:18:31 -0400 (EDT) Resent-Date: Mon, 7 Oct 2002 15:18:31 -0400 (EDT) Resent-Message-Id: <200210071918.g97JIVF07269@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g97JITB07228 for ; Mon, 7 Oct 2002 15:18:29 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA03302 for ; Mon, 7 Oct 2002 15:18:29 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 07 Oct 2002 15:07:22 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 7 Oct 2002 15:17:58 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Mon, 7 Oct 2002 15:17:54 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26E36.3C6497F0" Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6786 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26E36.3C6497F0 Content-Type: text/plain From: Lisa Dusseault [mailto:lisa@xythos.com] The proposal to require tagged-lists would not fix everything: - The IF header, particularly with URL tagging, is very long and can't be split up over several lines. I'd be happy to extend the syntax of the If header to allow a "," to separate the productions. RFC2518 authors: was it just a blunder (:-) that "," is not the separator, or was there some good reason why it wasn't used? Server writers: what would your server do today if it received multiple If headers in a single request? - If a lock disappears, the request will fail, even if the client wants it to succeed anyway. Round-trip required. As indicated in my previous message, I need to see some explanation for why clients that don't care about merge prevention are using locks in the first place? Why aren't they just using etags? - The client doesn't always know which locks are required (e.g. DELETE a resource in collection with depth-0 lock). Round-trip required. I don't see any connection between this issue and whether or not to use a separate header. If they don't have the right list of tokens in the new header, they will still get a failure and the same extra round-trip is required. Note that if we went with the proposal simply to require tagged lists, then the untagged list production should be 'deprecated', probably by telling clients they MUST NOT use untagged list productions. The untagged syntax becomes useless and should eventually be removed, though servers must continue to support the syntax as long as they want to interoperate with pre-existing clients. If the untagged syntax becomes useless, I'm happy to deprecate it. I'm always happy to delete/deprecate things from the spec if they turned out to not be useful ... that simplifies the spec, rather than making it more complex. I know the proposal to required tagged lists has been considered by client developers, and it was considered inferior to the proposal for a new header. In practice, it's the situation they currently experience - although the specification doesn't say the client MUST use tagged-lists, clients eventually come to that realization. And still, after programming the client to work that way, they find it's complicated and sometimes doesn't work in practice. Why is it complicated to create a tagged list? And I'm not sure what you mean by "in practice". If you mean "against existing servers", then you certainly aren't going to fix things by adding a new header that those servers are not expecting. My impression from what is being reported is that clients aren't aware they should be sending a tagged list, and some servers aren't aware that tagged lists need to be implemented. This is simplest to fix by making clients aware that they should be sending tagged lists, and making servers aware that they should be implementing tagged lists. Client implementers aren't the largest active constituency on this mailing list, and I'm not sure why, because I would guess they are the largest constituency of WebDAV implementers. When we do hear a solid consistent opinion from the client implementers, I believe it should be taken very seriously. For there to be demonstrable solid consistent opinions from client implementers, we need to see it documented in the mailing list, since that is where working group consensus is formed. If client implementers feel this is an important issue, it is imperative that they participate in this discussion. It's like democracy ... you don't get to complain if you don't vote. Cheers, Geoff From: Clemm, Geoff Alternatively, we could just say: "A client MUST submit a tagged-list If header, using the DAV:lock-root of the lock as the tag for that lock token." A simple rule for new clients, that will interoperate with all correctly implemented old and new servers. If any of the tagged-list productions fail, the resource that is no longer locked will be indicated with a 412 in the multistatus return, telling the client to either remove that lock from its table, or request a new lock for that resource. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:nn683849@smallcue.com] for compatibility reasons, if the client didn't provide the new submit header, the server prudently can be expected to check the If: header using whatever semantics that it thinks 2518 specifies regarding token submission. Similarly, for compatibility reasons (in addition to any correctness reasons) we might expect the client to continue to submit If headers. For compatibility reasons a production client wouldn't depend on the server checking conditions on resources other than ones the server thinks are pertinent, but we can begin to test interoperability of that. Eventually though clients would only submit the If: header for correctness reasons and will feel free to do checks on any resource it feels is appropriate. > d) all state productions in a If header are checked, not only those that > apply to "affected" resources by the operation. Yes, Initially clients that are spamming the If: header will pay a price for that. But as they eventually move to the new header or stop spamming the If: header, that price will no longer be paid. The tact that can be taken in production systems is... New clients can submit the new header and only the If: clauses that it feels it wants tested. If the LOCKED error code is returned, they can resubmit to check if the error is just a problem with an old server. This means there will be a price for using an old server, but things will still work and it will be an incentive to upgrade. New clients can submit If: clauses for extra resources, but they will not be written to be dependent on submitting extra If: clauses to achieve correctness. Not unless they have a way to verify that the server supports this. I don't see this as a problem since we aren't emphasizing this feature yet. But eventually it becomes a possibility. New servers will know that if a client submits a new header, that it should process that new header. In that case it will also process *all* of the If: header clauses and we can test servers to verify that they support this even if production clients don't exercise this feature. If new servers receive a request that does not have the new header, they will fall back on whatever code they currently use for If: headers submitting lock tokens. That's what productions systems could do. Testing systems and tightly integrated systems could actually fully exercise the new features. ------_=_NextPart_001_01C26E36.3C6497F0 Content-Type: text/html RE: Interop issue: Proposal for fixing lock token provision

   From: Lisa Dusseault [mailto:lisa@xythos.com]

   The proposal to require tagged-lists would not fix everything:

   - The IF header, particularly with URL tagging, is very long and
   can't be split up over several lines.

I'd be happy to extend the syntax of the If header to allow a ","
to separate the productions.

RFC2518 authors: was it just a blunder (:-) that "," is not
the separator, or was there some good reason why it wasn't used?

Server writers: what would your server do today if it received
multiple If headers in a single request?

   - If a lock disappears, the request will fail, even if the client
   wants it to succeed anyway. Round-trip required.

As indicated in my previous message, I need to see some explanation
for why clients that don't care about merge prevention are using locks
in the first place?  Why aren't they just using etags?

   - The client doesn't always know which locks are required
   (e.g. DELETE a resource in collection with depth-0
   lock). Round-trip required.

I don't see any connection between this issue and whether or
not to use a separate header.  If they don't have the right
list of tokens in the new header, they will still get a failure
and the same extra round-trip is required.

   Note that if we went with the proposal simply to require tagged
   lists, then the untagged list production should be
   'deprecated', probably by telling clients they MUST NOT use
   untagged list productions.  The untagged syntax becomes useless and
   should eventually be removed, though servers must continue to
   support the syntax as long as they want to interoperate with
   pre-existing clients.

If the untagged syntax becomes useless, I'm happy to deprecate it.
I'm always happy to delete/deprecate things from the spec if they
turned out to not be useful ... that simplifies the spec, rather than
making it more complex.

   I know the proposal to required tagged lists has been considered by
   client developers, and it was considered inferior to the proposal
   for a new header.  In practice, it's the situation they currently
   experience - although the specification doesn't say the client
   MUST use tagged-lists, clients eventually come to that realization.
   And still, after programming the client to work that way, they find
   it's complicated and sometimes doesn't work in practice.

Why is it complicated to create a tagged list?  And I'm not sure what
you mean by "in practice".  If you mean "against existing servers",
then you certainly aren't going to fix things by adding a new header
that those servers are not expecting.

My impression from what is being reported is that clients aren't
aware they should be sending a tagged list, and some servers aren't
aware that tagged lists need to be implemented.  This is simplest
to fix by making clients aware that they should be sending tagged
lists, and making servers aware that they should be implementing
tagged lists.

   Client implementers aren't the largest active constituency on this
   mailing list, and I'm not sure why, because I would guess they are
   the largest constituency of WebDAV implementers. When we do hear a
   solid consistent opinion from the client implementers, I believe it
   should be taken very seriously.

For there to be demonstrable solid consistent opinions from client
implementers, we need to see it documented in the mailing list, since
that is where working group consensus is formed.  If client implementers
feel this is an important issue, it is imperative that they participate
in this discussion.  It's like democracy ... you don't get to complain
if you don't vote.

Cheers,
Geoff


   From: Clemm, Geoff

   Alternatively, we could just say:

   "A client MUST submit a tagged-list If header, using the
   DAV:lock-root of the lock as the tag for that lock token."

   A simple rule for new clients, that will interoperate with
   all correctly implemented old and new servers.

   If any of the tagged-list productions fail, the resource
   that is no longer locked will be indicated with a 412 in
   the multistatus return, telling the client to either remove
   that lock from its table, or request a new lock for that
   resource.

   Cheers,
   Geoff

   -----Original Message-----
   From: Jason Crawford [mailto:nn683849@smallcue.com]

   for compatibility reasons, if the client didn't provide the new submit
   header, the server prudently can be expected to check the If: header
   using whatever semantics that it thinks 2518 specifies regarding
   token submission.

   Similarly, for compatibility reasons (in addition to any correctness
   reasons)
   we might expect the client to continue to submit If headers.  For
   compatibility
   reasons a production client wouldn't depend on the server checking
   conditions on
   resources other than ones the server thinks are pertinent, but we can begin
   to
   test interoperability of that.   Eventually though clients would only
   submit
   the If: header for correctness reasons and will feel free to do checks on
   any resource it feels is appropriate.

   > d) all state productions in a If header are checked, not only those that
   >    apply to "affected" resources by the operation.
   Yes,  Initially clients that are spamming the If: header will pay a price
   for that.  But as they eventually move to the new header or stop
   spamming the If: header, that price will no longer be paid.



   The tact that can be taken in production systems is...

   New clients can submit the new header and only the If: clauses that it
   feels
   it wants tested.  If the LOCKED error code is returned, they can resubmit
   to check if the error is just a problem with an old server.   This means
   there
   will be a price for using an old server, but things will still work and it
   will be
   an incentive to upgrade.

   New clients can submit If: clauses for extra resources, but they will not
   be
   written to be dependent on submitting extra If: clauses to achieve
   correctness.  Not unless they have a way to verify that the server
   supports this.  I don't see this as a problem since we aren't emphasizing
   this feature yet.  But eventually it becomes a possibility.

   New servers will know that if a client submits a new header, that it should
   process that new header.   In that case it will also process *all* of the
   If: header
   clauses and we can test servers to verify that they support this even if
   production clients don't exercise this feature.

   If new servers receive a request that does not have the new header, they
   will fall back on whatever code they currently use for If: headers
   submitting
   lock tokens.

   That's what productions systems could do.  Testing systems and tightly
   integrated systems could actually fully exercise the new features.

------_=_NextPart_001_01C26E36.3C6497F0-- From w3c-dist-auth-request@w3.org Mon Oct 7 19:26:00 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA09655 for ; Mon, 7 Oct 2002 19:25:59 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g97NMhm12672; Mon, 7 Oct 2002 19:22:43 -0400 (EDT) Resent-Date: Mon, 7 Oct 2002 19:22:43 -0400 (EDT) Resent-Message-Id: <200210072322.g97NMhm12672@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g97NMgB12646 for ; Mon, 7 Oct 2002 19:22:42 -0400 (EDT) Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23]) by tux.w3.org (8.9.3/8.9.3) with SMTP id TAA14995 for ; Mon, 7 Oct 2002 19:22:42 -0400 Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Mon, 07 Oct 2002 14:44:46 -0400 (Eastern Daylight Time) Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453); Mon, 7 Oct 2002 14:44:46 -0400 Received: from xythoslap ([216.36.77.241]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453); Mon, 7 Oct 2002 14:44:22 -0400 From: "Lisa Dusseault" To: "'Clemm, Geoff'" , "'Webdav WG'" Date: Mon, 7 Oct 2002 11:44:21 -0700 Message-ID: <001201c26e31$8d441f60$29c4fea9@xythoslap> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 07 Oct 2002 18:44:22.0635 (UTC) FILETIME=[8D81EBB0:01C26E31] Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6787 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----=_NextPart_000_0013_01C26DF6.E0E54760" ------=_NextPart_000_0013_01C26DF6.E0E54760 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The proposal to require tagged-lists would not fix everything: - The IF header, particularly with URL tagging, is very long and can't be split up over several lines. - If a lock disappears, the request will fail, even if the client wants it to succeed anyway. Round-trip required. - The client doesn't always know which locks are required (e.g. DELETE a resource in collection with depth-0 lock). Round-trip required. Note that if we went with the proposal simply to require tagged lists, then the untagged list production should be "deprecated", probably by telling clients they MUST NOT use untagged list productions. The untagged syntax becomes useless and should eventually be removed, though servers must continue to support the syntax as long as they want to interoperate with pre-existing clients. I know the proposal to required tagged lists has been considered by client developers, and it was considered inferior to the proposal for a new header. In practice, it's the situation they currently experience - although the specification doesn't say the client MUST use tagged-lists, clients eventually come to that realization. And still, after programming the client to work that way, they find it's complicated and sometimes doesn't work in practice. Client implementers aren't the largest active constituency on this mailing list, and I'm not sure why, because I would guess they are the largest constituency of WebDAV implementers. When we do hear a solid consistent opinion from the client implementers, I believe it should be taken very seriously. Lisa -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff Sent: Monday, October 07, 2002 11:14 AM To: 'Webdav WG' Subject: RE: Interop issue: Proposal for fixing lock token provision Alternatively, we could just say: "A client MUST submit a tagged-list If header, using the DAV:lock-root of the lock as the tag for that lock token." A simple rule for new clients, that will interoperate with all correctly implemented old and new servers. If any of the tagged-list productions fail, the resource that is no longer locked will be indicated with a 412 in the multistatus return, telling the client to either remove that lock from its table, or request a new lock for that resource. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:nn683849@smallcue.com] for compatibility reasons, if the client didn't provide the new submit header, the server prudently can be expected to check the If: header using whatever semantics that it thinks 2518 specifies regarding token submission. Similarly, for compatibility reasons (in addition to any correctness reasons) we might expect the client to continue to submit If headers. For compatibility reasons a production client wouldn't depend on the server checking conditions on resources other than ones the server thinks are pertinent, but we can begin to test interoperability of that. Eventually though clients would only submit the If: header for correctness reasons and will feel free to do checks on any resource it feels is appropriate. > d) all state productions in a If header are checked, not only those that > apply to "affected" resources by the operation. Yes, Initially clients that are spamming the If: header will pay a price for that. But as they eventually move to the new header or stop spamming the If: header, that price will no longer be paid. The tact that can be taken in production systems is... New clients can submit the new header and only the If: clauses that it feels it wants tested. If the LOCKED error code is returned, they can resubmit to check if the error is just a problem with an old server. This means there will be a price for using an old server, but things will still work and it will be an incentive to upgrade. New clients can submit If: clauses for extra resources, but they will not be written to be dependent on submitting extra If: clauses to achieve correctness. Not unless they have a way to verify that the server supports this. I don't see this as a problem since we aren't emphasizing this feature yet. But eventually it becomes a possibility. New servers will know that if a client submits a new header, that it should process that new header. In that case it will also process *all* of the If: header clauses and we can test servers to verify that they support this even if production clients don't exercise this feature. If new servers receive a request that does not have the new header, they will fall back on whatever code they currently use for If: headers submitting lock tokens. That's what productions systems could do. Testing systems and tightly integrated systems could actually fully exercise the new features. J. ------------------------------------------ Phone: 914-784-7569 ------=_NextPart_000_0013_01C26DF6.E0E54760 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: Interop issue: Proposal for fixing lock token = provision

The proposal to require = tagged-lists would not fix everything:

-          The IF header, particularly with URL tagging, is very long and can’t be split up = over several lines.

-          If a lock = disappears, the request will fail, even if the client wants it to succeed anyway. = Round-trip required.

-          The client = doesn’t always know which locks are required (e.g. DELETE a resource in = collection with depth-0 lock). Round-trip required.

 

Note that if we went with the = proposal simply to require tagged lists, then the untagged list production should = be “deprecated”, probably by telling clients they MUST NOT use untagged list = productions.  The untagged syntax becomes useless and should eventually be removed, though servers must continue to support the syntax as long as they want to interoperate with pre-existing clients.

 

I know the proposal to required = tagged lists has been considered by client developers, and it was considered = inferior to the proposal for a new header.  In practice, it’s the = situation they currently experience – although the specification = doesn’t say the client MUST use tagged-lists, clients eventually come to that realization.  And still, after programming the client to work that = way, they find it’s complicated and sometimes doesn’t work in = practice.

 

Client implementers aren’t = the largest active constituency on this mailing list, and I’m not sure = why, because I would guess they are the largest constituency of WebDAV = implementers. When we do hear a solid consistent opinion from the client implementers, = I believe it should be taken very seriously.

 

Lisa

 

-----Original Message-----
From: = w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff
Sent: Monday, October 07, = 2002 11:14 AM
To: 'Webdav WG'
Subject: RE: Interop = issue: Proposal for fixing lock token provision

 

Alternatively, we could just say:

"A client MUST submit a tagged-list If header, using the
DAV:lock-root of the = lock as the tag for that lock token."

A simple rule for new clients, that will interoperate with
all correctly = implemented old and new servers.

If any of the tagged-list productions fail, the resource
that is no longer locked = will be indicated with a 412 in
the multistatus return, = telling the client to either remove
that lock from its = table, or request a new lock for that
resource. =

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:nn683849@smallcue.com]

for compatibility reasons, if the client didn't provide the new = submit
header, the server = prudently can be expected to check the If: header
using whatever semantics = that it thinks 2518 specifies regarding
token = submission.

Similarly, for compatibility reasons (in addition to any correctness =
reasons) =
we might expect the = client to continue to submit If headers.  For
compatibility
reasons a production = client wouldn't depend on the server checking
conditions = on
resources other than = ones the server thinks are pertinent, but we can begin
to
test interoperability of that.   Eventually though clients would only =
submit =
the If: header for = correctness reasons and will feel free to do checks on
any resource it feels is appropriate.

> d) all state productions in a If header are checked, not only those = that
>    = apply to "affected" resources by the operation.
Yes,  Initially = clients that are spamming the If: header will pay a price
for that.  But as = they eventually move to the new header or stop
spamming the If: header, = that price will no longer be paid.

 

The tact that can be taken in production systems is...

New clients can submit the new header and only the If: clauses that = it
feels
it wants tested.  = If the LOCKED error code is returned, they can resubmit
to check if the error is = just a problem with an old server.   This means
there
will be a price for = using an old server, but things will still work and it
will be =
an incentive to = upgrade.

New clients can submit If: clauses for extra resources, but they will = not
be
written to be dependent = on submitting extra If: clauses to achieve
correctness.  Not = unless they have a way to verify that the server
supports this.  I = don't see this as a problem since we aren't emphasizing
this feature yet.  = But eventually it becomes a possibility.

New servers will know that if a client submits a new header, that it = should
process that new header.   In that case it will also process *all* of = the
If: header =
clauses and we can test = servers to verify that they support this even if
production clients don't = exercise this feature.

If new servers receive a request that does not have the new header, = they
will fall back on = whatever code they currently use for If: headers
submitting =
lock = tokens.

That's what productions systems could do.  Testing systems and = tightly
integrated systems could = actually fully exercise the new features.

J.

------------------------------------------
Phone: = 914-784-7569

------=_NextPart_000_0013_01C26DF6.E0E54760-- --------------InterScan_NT_MIME_Boundary-- From w3c-dist-auth-request@w3.org Tue Oct 8 02:50:05 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA01856 for ; Tue, 8 Oct 2002 02:50:05 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g986lY015897; Tue, 8 Oct 2002 02:47:34 -0400 (EDT) Resent-Date: Tue, 8 Oct 2002 02:47:34 -0400 (EDT) Resent-Message-Id: <200210080647.g986lY015897@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g986lXB15867 for ; Tue, 8 Oct 2002 02:47:33 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA24595 for ; Tue, 8 Oct 2002 02:47:32 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id XAA04165 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Mon, 7 Oct 2002 23:47:31 -0700 Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by sunbelt.seagull.net (8.9.3) with ESMTP id XAA04149 sender obsfucated@us.ibm.com; Mon, 7 Oct 2002 23:47:30 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g986kxDn009002; Tue, 8 Oct 2002 02:46:59 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g986kwOB143004; Tue, 8 Oct 2002 02:46:59 -0400 To: "Clemm, Geoff" Cc: "'Webdav WG'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Jason Crawford Date: Tue, 8 Oct 2002 01:59:06 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0|September 26, 2002) at 10/08/2002 02:46:58 MIME-Version: 1.0 Content-type: text/plain; charset=ISO-8859-1 Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6788 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Monday, 10/07/2002 at 10:25 AST, "Clemm, Geoff" wrote: > I continue to be strongly against splitting the If header > functionality, primarily to maintain interoperability between new > clients and old servers, and between old clients and new servers. > > Any new client that sends just the new header, without also sending > the same information in the If header, will fail against all old > servers.=A0 A client could put in logic to send the new header to new= > servers and the If header to old servers, but then you've just > increased the interoperation complexity of clients, not decreased it.= > > Similarly, any new server that only accepts the lock token list from > the new header, and not from the If header, will fail against all old= > clients.=A0 A server could put in logic to handle both the old and th= e > new headers, but again, you've just increased the interoperation > complexity of servers, not decreased it. I hope my posting to Stefan's note addressed this for you. > There is another question, which is that even if we leave the > semantics of the If header alone (to maintain interoperability betwee= n > new clients and old servers, and old clients and new servers), should= > we introduce a new header that gives the client the ability to submit= > a no longer valid lock token, and still have the request succeed. An earlier posting already indicated a case where that was inefficient and suggested that because the client knows when this is appropriate and has plenty of motivation to check it, we don't need to specify that= the server check this without being prompted by the client. > I am against the addition of this new header, because I believe the > arguments in favor of it confuse the purpose of a lock and the purpos= e > of an etag.=A0 An etag prevents lost updates.=A0 You will be notified= if > you are about to overwrite some other user's update, but you are then= > left with a merge situation.=A0 A lock prevents merge situations (and= > thereby also prevents lost updates).=A0 If you only care about lost > updates, then you can just use etags.=A0 The only reason to use locks= is > if: (1) you want to prevent merge situations, or (2) the resource > supports locks but not etags. Right... > In either case, you always need to know > about lost locks because in case (1), you are no longer protected > against merge situations, or in case (2), you no longer are protected= > against lost updates. Right. And if it has Etag support and it's the last PUT, you might not care care if you've lost the lock as long as the content has not been updated. There's no point in checking for the lock in that situation and spec'ing that the check be done anyway, just causes needless delay. Only the client knows if this is that last PUT. Let the client decide if the check is done. It's not as if the client doesn't have plenty of= motivation to get this right. > As a general principle, I believe that unless there is no alternative= , > we should do all we can to reward implementors that have fully and > correctly implemented the specification, by maximizing the likelihood= > that new clients and new servers will interoperate successfully with > those correctly and fully implemented old clients and servers. I hope my posting on compatibility covered that for you. Old and new would continue to interoperate and new would perform better than old. > Therefore, I believe that the use of the If header should be clarifie= d > in RFC2518 bis (and in particular, guidance for how to use it to > submit lock tokens), > but that the If semantics should remain > unchanged, > lock tokens should not be added. This proposal is an attempt to clarify how to both use and process the If: header as well as to clarify how to submit tokens and how they should be checked. In fact it seems to do a very good job of that which should alleviate all the interop problems that Lisa indicated in her posting. It does seperate the functionality in to two headers, but without giving up compatibility and while increasing performance in some situations. It's more than reasonable to come up with an alternate proposal though. It sounds like we're trying to do that now. We'll see how that goes. J. ------------------------------------------ Phone: 914-784-7569= From w3c-dist-auth-request@w3.org Tue Oct 8 03:28:17 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA02540 for ; Tue, 8 Oct 2002 03:28:17 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g987Q6W21348; Tue, 8 Oct 2002 03:26:06 -0400 (EDT) Resent-Date: Tue, 8 Oct 2002 03:26:06 -0400 (EDT) Resent-Message-Id: <200210080726.g987Q6W21348@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g987Q4B21322 for ; Tue, 8 Oct 2002 03:26:04 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA29901 for ; Tue, 8 Oct 2002 03:26:04 -0400 Received: (qmail 22859 invoked by uid 0); 8 Oct 2002 07:25:33 -0000 Received: from pd950c3c2.dip.t-dialin.net (HELO lisa) (217.80.195.194) by mail.gmx.net (mp014-rz3) with SMTP; 8 Oct 2002 07:25:33 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Clemm, Geoff" Cc: "'Webdav WG'" Date: Tue, 8 Oct 2002 09:25:26 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-reply-to: Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6789 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Tuesday, October 08, 2002 7:59 AM > To: Clemm, Geoff > Cc: 'Webdav WG' > Subject: RE: Interop issue: Proposal for fixing lock token provision > > ... > And if it has Etag support and it's the last PUT, you might not care > care if you've lost the lock as long as the content has not > been updated. There's no point in checking for the lock in that > situation and spec'ing that the check be done anyway, just causes > needless delay. > ... Wouldn't that mean to optimize for a *really* uncommon case? How frequently does that happen? Does is really require special handling? -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Oct 8 05:32:35 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA04337 for ; Tue, 8 Oct 2002 05:32:35 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g989U8505617; Tue, 8 Oct 2002 05:30:08 -0400 (EDT) Resent-Date: Tue, 8 Oct 2002 05:30:08 -0400 (EDT) Resent-Message-Id: <200210080930.g989U8505617@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g989U7B05591 for ; Tue, 8 Oct 2002 05:30:07 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA15712 for ; Tue, 8 Oct 2002 05:30:06 -0400 Received: (qmail 3228 invoked by uid 0); 8 Oct 2002 09:30:03 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp020-rz3) with SMTP; 8 Oct 2002 09:30:03 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'Webdav WG'" Date: Tue, 8 Oct 2002 11:30:01 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C26EBE.0AFBA220" 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.1106 In-Reply-To: Importance: Normal Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6790 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C26EBE.0AFBA220 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: Interop issue: Proposal for fixing lock token provisionI agree with Geoff. If there's an interoperability problem, I'd like to see a precise description, preferrably from the client implementors. The scenario of a client having a lock token and the etag trying to PUT, and the server rejecting the request because the lock was lost doesn't really seem to be a case that needs special treatment. If this is happening frequently, it's a client (wrong timeout) or server bug that needs to be fixed. If it doesn't happen frequently, there's no reason to add special optimzations in RFC2518bis. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff Sent: Monday, October 07, 2002 9:18 PM To: 'Webdav WG' Subject: RE: Interop issue: Proposal for fixing lock token provision From: Lisa Dusseault [mailto:lisa@xythos.com] The proposal to require tagged-lists would not fix everything: - The IF header, particularly with URL tagging, is very long and can't be split up over several lines. I'd be happy to extend the syntax of the If header to allow a "," to separate the productions. RFC2518 authors: was it just a blunder (:-) that "," is not the separator, or was there some good reason why it wasn't used? Server writers: what would your server do today if it received multiple If headers in a single request? - If a lock disappears, the request will fail, even if the client wants it to succeed anyway. Round-trip required. As indicated in my previous message, I need to see some explanation for why clients that don't care about merge prevention are using locks in the first place? Why aren't they just using etags? - The client doesn't always know which locks are required (e.g. DELETE a resource in collection with depth-0 lock). Round-trip required. I don't see any connection between this issue and whether or not to use a separate header. If they don't have the right list of tokens in the new header, they will still get a failure and the same extra round-trip is required. Note that if we went with the proposal simply to require tagged lists, then the untagged list production should be 'deprecated', probably by telling clients they MUST NOT use untagged list productions. The untagged syntax becomes useless and should eventually be removed, though servers must continue to support the syntax as long as they want to interoperate with pre-existing clients. If the untagged syntax becomes useless, I'm happy to deprecate it. I'm always happy to delete/deprecate things from the spec if they turned out to not be useful ... that simplifies the spec, rather than making it more complex. I know the proposal to required tagged lists has been considered by client developers, and it was considered inferior to the proposal for a new header. In practice, it's the situation they currently experience - although the specification doesn't say the client MUST use tagged-lists, clients eventually come to that realization. And still, after programming the client to work that way, they find it's complicated and sometimes doesn't work in practice. Why is it complicated to create a tagged list? And I'm not sure what you mean by "in practice". If you mean "against existing servers", then you certainly aren't going to fix things by adding a new header that those servers are not expecting. My impression from what is being reported is that clients aren't aware they should be sending a tagged list, and some servers aren't aware that tagged lists need to be implemented. This is simplest to fix by making clients aware that they should be sending tagged lists, and making servers aware that they should be implementing tagged lists. Client implementers aren't the largest active constituency on this mailing list, and I'm not sure why, because I would guess they are the largest constituency of WebDAV implementers. When we do hear a solid consistent opinion from the client implementers, I believe it should be taken very seriously. For there to be demonstrable solid consistent opinions from client implementers, we need to see it documented in the mailing list, since that is where working group consensus is formed. If client implementers feel this is an important issue, it is imperative that they participate in this discussion. It's like democracy ... you don't get to complain if you don't vote. Cheers, Geoff From: Clemm, Geoff Alternatively, we could just say: "A client MUST submit a tagged-list If header, using the DAV:lock-root of the lock as the tag for that lock token." A simple rule for new clients, that will interoperate with all correctly implemented old and new servers. If any of the tagged-list productions fail, the resource that is no longer locked will be indicated with a 412 in the multistatus return, telling the client to either remove that lock from its table, or request a new lock for that resource. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:nn683849@smallcue.com] for compatibility reasons, if the client didn't provide the new submit header, the server prudently can be expected to check the If: header using whatever semantics that it thinks 2518 specifies regarding token submission. Similarly, for compatibility reasons (in addition to any correctness reasons) we might expect the client to continue to submit If headers. For compatibility reasons a production client wouldn't depend on the server checking conditions on resources other than ones the server thinks are pertinent, but we can begin to test interoperability of that. Eventually though clients would only submit the If: header for correctness reasons and will feel free to do checks on any resource it feels is appropriate. > d) all state productions in a If header are checked, not only those that > apply to "affected" resources by the operation. Yes, Initially clients that are spamming the If: header will pay a price for that. But as they eventually move to the new header or stop spamming the If: header, that price will no longer be paid. The tact that can be taken in production systems is... New clients can submit the new header and only the If: clauses that it feels it wants tested. If the LOCKED error code is returned, they can resubmit to check if the error is just a problem with an old server. This means there will be a price for using an old server, but things will still work and it will be an incentive to upgrade. New clients can submit If: clauses for extra resources, but they will not be written to be dependent on submitting extra If: clauses to achieve correctness. Not unless they have a way to verify that the server supports this. I don't see this as a problem since we aren't emphasizing this feature yet. But eventually it becomes a possibility. New servers will know that if a client submits a new header, that it should process that new header. In that case it will also process *all* of the If: header clauses and we can test servers to verify that they support this even if production clients don't exercise this feature. If new servers receive a request that does not have the new header, they will fall back on whatever code they currently use for If: headers submitting lock tokens. That's what productions systems could do. Testing systems and tightly integrated systems could actually fully exercise the new features. ------=_NextPart_000_0000_01C26EBE.0AFBA220 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Interop issue: Proposal for fixing lock token = provision
I=20 agree with Geoff.
 
If=20 there's an interoperability problem, I'd like to see a precise = description,=20 preferrably from the client implementors.
 
The=20 scenario of a client having a lock token and the etag trying to PUT, and = the=20 server rejecting the request because the lock was lost doesn't really = seem to be=20 a case that needs special treatment. If this is happening frequently, = it's a=20 client (wrong timeout) or server bug that needs to be fixed. If it = doesn't=20 happen frequently, there's no reason to add special optimzations in=20 RFC2518bis.
 
Julian

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

-----Original Message-----
From: = w3c-dist-auth-request@w3.org=20 [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm,=20 Geoff
Sent: Monday, October 07, 2002 9:18 PM
To: = 'Webdav=20 WG'
Subject: RE: Interop issue: Proposal for fixing lock = token=20 provision

   From: Lisa Dusseault [mailto:lisa@xythos.com] =

   The proposal to require tagged-lists = would not=20 fix everything:

   - The IF header, particularly with URL = tagging,=20 is very long and
   can't be split = up over=20 several lines.

I'd be happy to extend the syntax of the If header = to allow a=20 ","
to separate the productions.

RFC2518 authors: was it just a blunder (:-) that "," = is=20 not
the separator, or was there some good = reason why=20 it wasn't used?

Server writers: what would your server do today if = it=20 received
multiple If headers in a single=20 request?

   - If a lock disappears, the request = will fail,=20 even if the client
   wants it to = succeed=20 anyway. Round-trip required.

As indicated in my previous message, I need to see = some=20 explanation
for why clients that don't care = about=20 merge prevention are using locks
in the = first=20 place?  Why aren't they just using etags?

   - The client doesn't always know which = locks are=20 required
   (e.g. DELETE a = resource in=20 collection with depth-0
   lock). = Round-trip=20 required.

I don't see any connection between this issue and = whether=20 or
not to use a separate header.  If = they don't=20 have the right
list of tokens in the new = header, they=20 will still get a failure
and the same extra = round-trip=20 is required.

   Note that if we went with the proposal = simply to=20 require tagged
   lists, then the = untagged=20 list production should be
   = 'deprecated',=20 probably by telling clients they MUST NOT use
   untagged list productions.  The untagged = syntax=20 becomes useless and
   should = eventually be=20 removed, though servers must continue to
  =20 support the syntax as long as they want to interoperate with =
   pre-existing clients.

If the untagged syntax becomes useless, I'm happy to = deprecate=20 it.
I'm always happy to delete/deprecate = things from=20 the spec if they
turned out to not be useful = ... that=20 simplifies the spec, rather than
making it = more=20 complex.

   I know the proposal to required tagged = lists has=20 been considered by
   client = developers, and=20 it was considered inferior to the proposal
   for a new header.  In practice, it's the = situation=20 they currently
   experience - = although the=20 specification doesn't say the client
   MUST=20 use tagged-lists, clients eventually come to that realization.=20
   And still, after programming the = client to work=20 that way, they find
   it's = complicated and=20 sometimes doesn't work in practice.

Why is it complicated to create a tagged list?  = And I'm=20 not sure what
you mean by "in = practice".  If you=20 mean "against existing servers",
then you = certainly=20 aren't going to fix things by adding a new header
that=20 those servers are not expecting.

My impression from what is being reported is that = clients=20 aren't
aware they should be sending a tagged = list, and=20 some servers aren't
aware that tagged lists = need to be=20 implemented.  This is simplest
to fix = by making=20 clients aware that they should be sending tagged
lists, and making servers aware that they should be = implementing=20
tagged lists.

   Client implementers aren't the largest = active=20 constituency on this
   mailing = list, and=20 I'm not sure why, because I would guess they are
   the largest constituency of WebDAV implementers. = When we=20 do hear a
   solid consistent = opinion from=20 the client implementers, I believe it
  =20 should be taken very seriously.

For there to be demonstrable solid consistent = opinions from=20 client
implementers, we need to see it = documented in=20 the mailing list, since
that is where = working group=20 consensus is formed.  If client implementers
feel=20 this is an important issue, it is imperative that they = participate=20
in this discussion.  It's like democracy ... = you don't=20 get to complain
if you don't vote. =

Cheers,
Geoff =


   From: Clemm, Geoff

   Alternatively, we could just say: =

   "A client MUST submit a tagged-list If = header,=20 using the
   DAV:lock-root of the = lock as=20 the tag for that lock token."

   A simple rule for new clients, that = will=20 interoperate with
   all correctly = implemented old and new servers.

   If any of the tagged-list productions = fail, the=20 resource
   that is no longer = locked will be=20 indicated with a 412 in
   the = multistatus=20 return, telling the client to either remove
   that lock from its table, or request a new lock = for that=20
   resource.

   Cheers,
  =20 Geoff

   -----Original Message----- =
   From: Jason Crawford [mailto:nn683849@smallcue.com]=20

   for compatibility reasons, if the = client didn't=20 provide the new submit
   header, = the server=20 prudently can be expected to check the If: header
   using whatever semantics that it thinks 2518 = specifies=20 regarding
   token submission. =

   Similarly, for compatibility reasons = (in addition=20 to any correctness
   reasons)=20
   we might expect the client to = continue to=20 submit If headers.  For
  =20 compatibility
   reasons a = production client=20 wouldn't depend on the server checking
  =20 conditions on
   resources other = than ones=20 the server thinks are pertinent, but we can begin
   to
   test=20 interoperability of that.   Eventually though clients would = only=20
   submit
   the If: header for correctness reasons and will = feel free=20 to do checks on
   any resource it = feels is=20 appropriate.

   > d) all state productions in a If = header are=20 checked, not only those that
  =20 >    apply to "affected" resources by the operation. =
   Yes,  Initially clients = that are=20 spamming the If: header will pay a price
  =20 for that.  But as they eventually move to the new header or stop=20
   spamming the If: header, that = price will=20 no longer be paid.



   The tact that can be taken in = production systems=20 is...

   New clients can submit the new header = and only=20 the If: clauses that it
   feels=20
   it wants tested.  If the = LOCKED=20 error code is returned, they can resubmit
  =20 to check if the error is just a problem with an old = server.   This=20 means
   there
   will be a price for using an old server, but = things will=20 still work and it
   will be=20
   an incentive to upgrade. =

   New clients can submit If: clauses for = extra=20 resources, but they will not
   be =
   written to be dependent on = submitting=20 extra If: clauses to achieve
  =20 correctness.  Not unless they have a way to verify that the = server=20
   supports this.  I don't = see this as=20 a problem since we aren't emphasizing
  =20 this feature yet.  But eventually it becomes a possibility. =

   New servers will know that if a client = submits a=20 new header, that it should
   = process that=20 new header.   In that case it will also process *all* of the =
   If: header
   clauses and we can test servers to verify that = they=20 support this even if
   production = clients=20 don't exercise this feature.

   If new servers receive a request that = does not=20 have the new header, they
   will = fall back=20 on whatever code they currently use for If: headers
   submitting
   lock=20 tokens.

   That's what productions systems could = do. =20 Testing systems and tightly
   = integrated=20 systems could actually fully exercise the new features.=20

------=_NextPart_000_0000_01C26EBE.0AFBA220-- From w3c-dist-auth-request@w3.org Tue Oct 8 09:11:43 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA10804 for ; Tue, 8 Oct 2002 09:11:43 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g98D8rV03309; Tue, 8 Oct 2002 09:08:53 -0400 (EDT) Resent-Date: Tue, 8 Oct 2002 09:08:53 -0400 (EDT) Resent-Message-Id: <200210081308.g98D8rV03309@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g98D8qB03283 for ; Tue, 8 Oct 2002 09:08:52 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA21013 for ; Tue, 8 Oct 2002 09:08:52 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 08 Oct 2002 08:57:44 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Tue, 8 Oct 2002 09:08:21 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Tue, 8 Oct 2002 09:08:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26ECB.C51EC620" Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6791 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26ECB.C51EC620 Content-Type: text/plain; charset="iso-8859-1" From: Jason Crawford [mailto:nn683849@smallcue.com] On Monday, 10/07/2002 at 10:25 AST, "Clemm, Geoff" wrote: > I continue to be strongly against splitting the If header > functionality, primarily to maintain interoperability between new > clients and old servers, and between old clients and new servers. I hope my posting to Stefan's note addressed this for you. Actually, it further convinced me that attempting to maintain interoperability between old/new client/server with the new header would be unacceptably complex, compared to just saying "use tagged-list in the If header". An earlier posting already indicated a case where that was inefficient and suggested that because the client knows when this is appropriate and has plenty of motivation to check it, we don't need to specify that the server check this without being prompted by the client. If one really feels this optimization is needed, then one could add an "Ignore-Expired-Lock" header, without causing the interoperability issues that result from splitting the header. But like Julian, I believe that one would be optimizing an uncommon case, and that it is not worth doing so unless there is compelling evidence that this is a significant performance issue. I hope my posting on compatibility covered that for you. Old and new would continue to interoperate and new would perform better than old. I believe the complexity of the solution you described would significantly decrease the interoperability between old and new implementations. > Therefore, I believe that the use of the If header should be > clarified in RFC2518 bis (and in particular, guidance for how to > use it to submit lock tokens), but that the If semantics should > remain unchanged, and a new header which allows the submission of > invalid lock tokens should not be added. It's more than reasonable to come up with an alternate proposal though. It sounds like we're trying to do that now. We'll see how that goes. In particular, the alternate proposal I'd like to offer is: "A client MUST submit lock tokens in a tagged-list If header, with the lock-root of the lock as the tag". If line length is a problem, we would supplement that by allowing a client to submit multiple If headers, and allowing "," as a separator between If productions. Cheers, Geoff ------_=_NextPart_001_01C26ECB.C51EC620 Content-Type: text/html; charset="iso-8859-1" RE: Interop issue: Proposal for fixing lock token provision

   From: Jason Crawford [mailto:nn683849@smallcue.com]

   On Monday, 10/07/2002 at 10:25 AST, "Clemm, Geoff"  wrote:
   > I continue to be strongly against splitting the If header
   > functionality, primarily to maintain interoperability between new
   > clients and old servers, and between old clients and new servers.

   I hope my posting to Stefan's note addressed this for you.

Actually, it further convinced me that attempting to maintain
interoperability between old/new client/server with the new header
would be unacceptably complex, compared to just saying "use
tagged-list in the If header".

   An earlier posting already indicated a case where that was
   inefficient and suggested that because the client knows when this
   is appropriate and has plenty of motivation to check it, we don't
   need to specify that the server check this without being prompted
   by the client.

If one really feels this optimization is needed, then one could add an
"Ignore-Expired-Lock" header, without causing the interoperability
issues that result from splitting the header.  But like Julian, I
believe that one would be optimizing an uncommon case, and that it is
not worth doing so unless there is compelling evidence that this is a
significant performance issue.

   I hope my posting on compatibility covered that for you.  Old and
   new would continue to interoperate and new would perform better
   than old.

I believe the complexity of the solution you described would
significantly decrease the interoperability between old and
new implementations.

   > Therefore, I believe that the use of the If header should be
   > clarified in RFC2518 bis (and in particular, guidance for how to
   > use it to submit lock tokens), but that the If semantics should
   > remain unchanged, and a new header which allows the submission of
   > invalid lock tokens should not be added.

   It's more than reasonable to come up with an alternate proposal
   though.  It sounds like we're trying to do that now.  We'll see how
   that goes.

In particular, the alternate proposal I'd like to offer is:

"A client MUST submit lock tokens in a tagged-list If header,
with the lock-root of the lock as the tag".

If line length is a problem, we would supplement that by allowing
a client to submit multiple If headers, and allowing "," as a
separator between If productions.

Cheers,
Geoff

------_=_NextPart_001_01C26ECB.C51EC620-- From w3c-dist-auth-request@w3.org Tue Oct 8 10:25:16 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA14860 for ; Tue, 8 Oct 2002 10:25:15 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g98EN2X20437; Tue, 8 Oct 2002 10:23:02 -0400 (EDT) Resent-Date: Tue, 8 Oct 2002 10:23:02 -0400 (EDT) Resent-Message-Id: <200210081423.g98EN2X20437@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g98EN1B20406 for ; Tue, 8 Oct 2002 10:23:01 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA17267 for ; Tue, 8 Oct 2002 10:23:01 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id HAA20299 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Tue, 8 Oct 2002 07:22:59 -0700 Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by sunbelt.seagull.net (8.9.3) with ESMTP id HAA20271 sender obsfucated@us.ibm.com; Tue, 8 Oct 2002 07:22:55 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g98EMNxw006664; Tue, 8 Oct 2002 10:22:23 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g98EMLtN073802; Tue, 8 Oct 2002 10:22:21 -0400 To: "Clemm, Geoff" Cc: "'Webdav WG'" X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 Message-ID: From: Jason Crawford Date: Tue, 8 Oct 2002 10:16:39 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0|September 26, 2002) at 10/08/2002 10:22:21 MIME-Version: 1.0 Content-type: text/plain; charset=US-ASCII Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6792 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Monday, 10/07/2002 at 02:14 AST, "Clemm, Geoff" wrote: > Alternatively, we could just say: > > "A client MUST submit a tagged-list If header, using the > DAV:lock-root of the lock as the tag for that lock token." > > A simple rule for new clients, that will interoperate with > all correctly implemented old and new servers. > > If any of the tagged-list productions fail, the resource > that is no longer locked will be indicated with a 412 in > the multistatus return, telling the client to either remove > that lock from its table, or request a new lock for that > resource. And ALL tag list productions would be evaluated, so that even if the server didn't think it was relevant, it still would be checked. So for example I can do a GET on a resource with an IF: header and the IF: header would be checked despite the server thinking it is unnecessary to check for locks on a GET request. Does this sound fine? And the client is required to submit a tag list for every URL/resource that the server thinks is relevant in order to submit the token. And we're going to have to define what URL's are relevant. And define what constitutes submission. So for a situation where a token needs to be submitted to allow a protected URL from being broken (lock destroyed), the root URL of the lock in question needs to be submitted. And in a situation where a token is needed to allow a write locked resource to be modified, the URL of the root of that resource needs to be specified. And what is "modifying"? A PUT/PROPPATCH to an ordinary resouce modifies it. Also operations that add or remove children of a collection are considered to modify the collection. The client is free to test any other resources it wants to test beyond the one's the server requires. We need a spec'ing of what tag list entries are sufficient to be considered a submission. That has to deal with NOT and any other expression constructs we might come up with. BTW... yes, I know earlier tonight I said that it's okay to test against any resource locked by a resource in order to submit the lock, but I'm guessing the definition of "submit" will be easier if we are as specific as possible about what it means to submit a token and specifying what URL is definitely something that will help. Also, in the case of 2518-style DELETE where lots of bindings get destoryed and they probably get destroyed bottom up, I'd think it would be best (or at least equal) in some server implementations if the URL you specified for the submisssion was the one that got destoryed last. J. From w3c-dist-auth-request@w3.org Tue Oct 8 11:18:20 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17761 for ; Tue, 8 Oct 2002 11:18:19 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g98FFok27867; Tue, 8 Oct 2002 11:15:50 -0400 (EDT) Resent-Date: Tue, 8 Oct 2002 11:15:50 -0400 (EDT) Resent-Message-Id: <200210081515.g98FFok27867@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g98FFnB27841 for ; Tue, 8 Oct 2002 11:15:49 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA06897 for ; Tue, 8 Oct 2002 11:15:50 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 08 Oct 2002 11:04:41 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Tue, 8 Oct 2002 11:15:19 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Tue, 8 Oct 2002 11:15:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26EDD.7F7420E0" Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6793 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26EDD.7F7420E0 Content-Type: text/plain From: Jason Crawford [mailto:nn683849@smallcue.com] On Monday, 10/07/2002 "Clemm, Geoff" wrote: > Alternatively, we could just say: > > "A client MUST submit a tagged-list If header, using the > DAV:lock-root of the lock as the tag for that lock token." > > A simple rule for new clients, that will interoperate with > all correctly implemented old and new servers. > > If any of the tagged-list productions fail, the resource > that is no longer locked will be indicated with a 412 in > the multistatus return, telling the client to either remove > that lock from its table, or request a new lock for that > resource. And ALL tag list productions would be evaluated, so that even if the server didn't think it was relevant, it still would be checked. So for example I can do a GET on a resource with an IF: header and the IF: header would be checked despite the server thinking it is unnecessary to check for locks on a GET request. Does this sound fine? If the client submitted an If header, then the server must check it, yes. But a client will not submit an If header with lock tokens for a GET request, so I don't see how this is relevant to this thread. And the client is required to submit a tag list for every URL/resource that the server thinks is relevant in order to submit the token. And we're going to have to define what URL's are relevant. And define what constitutes submission. Using a different header to submit tokens doesn't make it any easier for a client to decide what tokens to submit in the header. And yes, we do need to define what constitutes submission. I propose that keep the semantics as stated in 2518, i.e. submission means appearance in the If header. So for a situation where a token needs to be submitted to allow a protected URL from being broken (lock destroyed), the root URL of the lock in question needs to be submitted. And in a situation where a token is needed to allow a write locked resource to be modified, the URL of the root of that resource needs to be specified. Yes, the client always remembers both the root of the lock and the lock token of the lock, and submits them together in the tagged list. And what is "modifying"? A PUT/PROPPATCH to an ordinary resouce modifies it. Also operations that add or remove children of a collection are considered to modify the collection. This question has to be asked/answered, whether we use the If header or some new header. The client is free to test any other resources it wants to test beyond the one's the server requires. True. We need a spec'ing of what tag list entries are sufficient to be considered a submission. That has to deal with NOT and any other expression constructs we might come up with. I disagree that we will be adding any new constructs to the If header (at least, I do not plan on supporting any new constructs). If we need new constructs, we should define a new header, for interoperability reasons, if nothing else. So all we need to deal with is NOT. I'm happy to keep things simple, and state that the appearance of the lock token anywhere in the tagged list for the resource is sufficient. BTW... yes, I know earlier tonight I said that it's okay to test against any resource locked by a resource in order to submit the lock, but I'm guessing the definition of "submit" will be easier if we are as specific as possible about what it means to submit a token and specifying what URL is definitely something that will help. I agree that we need to clarify in 2518 bis how to submit a lock token, but I think it is sufficient to state that the lock token must appear somewhere in the tagged list for the resource. Also, in the case of 2518-style DELETE where lots of bindings get destoryed and they probably get destroyed bottom up, I'd think it would be best (or at least equal) in some server implementations if the URL you specified for the submisssion was the one that got destoryed last. The BIND protocol "clarifies" the 2518 DELETE semantics, to state that it is the "mappings" to all the members that are removed by the DELETE of a collection, not the bindings. I believe this clarification should appear in 2518bis. But even if some (misguided :-) server did destroy all the bindings, the last one destroyed will be the lock-root, which is what we're proposing to be the required tag for that token. Cheers, Geoff ------_=_NextPart_001_01C26EDD.7F7420E0 Content-Type: text/html RE: Interop issue: Proposal for fixing lock token provision

   From: Jason Crawford [mailto:nn683849@smallcue.com]

   On Monday, 10/07/2002 "Clemm, Geoff" wrote:
   > Alternatively, we could just say:
   >
   > "A client MUST submit a tagged-list If header, using the
   > DAV:lock-root of the lock as the tag for that lock token."
   >
   > A simple rule for new clients, that will interoperate with
   > all correctly implemented old and new servers.
   >
   > If any of the tagged-list productions fail, the resource
   > that is no longer locked will be indicated with a 412 in
   > the multistatus return, telling the client to either remove
   > that lock from its table, or request a new lock for that
   > resource.

   And ALL tag list productions would be evaluated, so that even if
   the server didn't think it was relevant, it still would be checked.
   So for example I can do a GET on a resource with an IF: header and
   the IF: header would be checked despite the server thinking it is
   unnecessary to check for locks on a GET request.  Does this sound
   fine?

If the client submitted an If header, then the server must check it,
yes.  But a client will not submit an If header with lock tokens for a
GET request, so I don't see how this is relevant to this thread.

   And the client is required to submit a tag list for every URL/resource
   that the server thinks is relevant in order to submit the token.
   And we're going to have to define what URL's are relevant.  And
   define what constitutes submission.

Using a different header to submit tokens doesn't make it any easier
for a client to decide what tokens to submit in the header.  And yes,
we do need to define what constitutes submission.  I propose that
keep the semantics as stated in 2518, i.e. submission means appearance
in the If header.

   So for a situation where a token needs to be submitted to allow a
   protected URL from being broken (lock destroyed), the root URL of
   the lock in question needs to be submitted.

   And in a situation where a token is needed to allow a write locked
   resource to be modified, the URL of the root of that resource needs
   to be specified.

Yes, the client always remembers both the root of the lock and the
lock token of the lock, and submits them together in the tagged list.

   And what is "modifying"? A PUT/PROPPATCH to an ordinary
   resouce modifies it.   Also operations that add or remove children
   of a collection are considered to modify the collection.

This question has to be asked/answered, whether we use the If
header or some new header.

   The client is free to test any other resources it wants to test
   beyond the one's the server requires.

True.

   We need a spec'ing of what tag list entries are sufficient to be
   considered a submission.  That has to deal with NOT and any other
   expression constructs we might come up with.

I disagree that we will be adding any new constructs to the If
header (at least, I do not plan on supporting any new constructs).
If we need new constructs, we should define a new header, for
interoperability reasons, if nothing else.  So all we need to deal
with is NOT.  I'm happy to keep things simple, and state that the
appearance of the lock token anywhere in the tagged list for the
resource is sufficient.

   BTW... yes, I know earlier tonight I said that it's okay to test
   against any resource locked by a resource in order to submit the
   lock, but I'm guessing the definition of "submit" will be easier if
   we are as specific as possible about what it means to submit a
   token and specifying what URL is definitely something that will
   help.

I agree that we need to clarify in 2518 bis how to submit a lock
token, but I think it is sufficient to state that the lock token
must appear somewhere in the tagged list for the resource.

   Also, in the case of 2518-style DELETE where lots of bindings get
   destoryed and they probably get destroyed bottom up, I'd think it
   would be best (or at least equal) in some server implementations if
   the URL you specified for the submisssion was the one that got
   destoryed last.

The BIND protocol "clarifies" the 2518 DELETE semantics, to
state that it is the "mappings" to all the members that are
removed by the DELETE of a collection, not the bindings.
I believe this clarification should appear in 2518bis.
But even if some (misguided :-) server did destroy all the
bindings, the last one destroyed will be the lock-root, which
is what we're proposing to be the required tag for that token.

Cheers,
Geoff


------_=_NextPart_001_01C26EDD.7F7420E0-- From w3c-dist-auth-request@w3.org Tue Oct 8 12:08:06 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA19653 for ; Tue, 8 Oct 2002 12:08:04 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g98G5dd06403; Tue, 8 Oct 2002 12:05:39 -0400 (EDT) Resent-Date: Tue, 8 Oct 2002 12:05:39 -0400 (EDT) Resent-Message-Id: <200210081605.g98G5dd06403@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g98G5cB06373 for ; Tue, 8 Oct 2002 12:05:38 -0400 (EDT) Received: from hestia.email.starband.net (smtp2.starband.net [148.78.247.23]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA27160 for ; Tue, 8 Oct 2002 12:05:38 -0400 Received: from lodestone (vsat-148-64-162-83.c005.g4.mrt.starband.net [148.64.162.83]) (authenticated bits=0) by hestia.email.starband.net (8.12.4/8.12.4) with ESMTP id g98G4xr8025062 for ; Tue, 8 Oct 2002 12:05:06 -0400 Message-ID: <016b01c26ee4$79e6c180$9d00a8c0@lodestone> Reply-To: "Bob Stucky" From: "Bob Stucky" To: Date: Tue, 8 Oct 2002 09:05:00 -0700 Organization: mbandbob.com 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: [w3c-dist-auth] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6794 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit unsubscribe From w3c-dist-auth-request@w3.org Tue Oct 8 12:46:53 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA21220 for ; Tue, 8 Oct 2002 12:46:53 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g98Gim618095; Tue, 8 Oct 2002 12:44:48 -0400 (EDT) Resent-Date: Tue, 8 Oct 2002 12:44:48 -0400 (EDT) Resent-Message-Id: <200210081644.g98Gim618095@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g98GilB18069 for ; Tue, 8 Oct 2002 12:44:47 -0400 (EDT) Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA05631 for ; Tue, 8 Oct 2002 12:44:47 -0400 Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Tue, 08 Oct 2002 12:44:03 -0400 (Eastern Daylight Time) Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453); Tue, 8 Oct 2002 12:44:02 -0400 Received: from xythoslap ([216.36.77.241]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453); Tue, 8 Oct 2002 12:44:02 -0400 From: "Lisa Dusseault" To: "'Clemm, Geoff'" , "'Webdav WG'" Date: Tue, 8 Oct 2002 09:44:00 -0700 Message-ID: <003001c26ee9$e82688b0$b701a8c0@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 08 Oct 2002 16:44:02.0476 (UTC) FILETIME=[E85ED6C0:01C26EE9] Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g98GilB18069 Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6795 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit > Using a different header to submit tokens doesn't make it any easier > for a client to decide what tokens to submit in the header.  Yes it does, which is one of the major reasons client developers have asked for this to be fixed: it makes it possible for clients to submit a bunch of lock tokens for the same "area" of the namespace, even if the client is not sure whether the server would require each lock token. Since servers are different in how they require lock tokens for various operations, this allows clients to submit as many lock tokens as they believe they need, without failing on some servers. lisa From w3c-dist-auth-request@w3.org Tue Oct 8 13:19:59 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22752 for ; Tue, 8 Oct 2002 13:19:58 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g98HHZp23054; Tue, 8 Oct 2002 13:17:35 -0400 (EDT) Resent-Date: Tue, 8 Oct 2002 13:17:35 -0400 (EDT) Resent-Message-Id: <200210081717.g98HHZp23054@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g98HHXB23011 for ; Tue, 8 Oct 2002 13:17:33 -0400 (EDT) Received: from mail.lightsurf.com ([65.223.110.138]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA11819 for ; Tue, 8 Oct 2002 13:17:33 -0400 Received: from AFREEMANWXP (afreeman-wxp.office.lightsurf.com [10.10.10.133]) by mail.lightsurf.com (Mirapoint) with SMTP id ACJ69031; Tue, 8 Oct 2002 10:17:31 -0700 (PDT) From: "Adam Freeman" To: "Bob Stucky" , Date: Tue, 8 Oct 2002 10:17:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <016b01c26ee4$79e6c180$9d00a8c0@lodestone> Subject: RE: [w3c-dist-auth] Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6796 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit unsubscribe -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Bob Stucky Sent: Tuesday, October 08, 2002 9:05 AM To: w3c-dist-auth@w3c.org Subject: [w3c-dist-auth] unsubscribe From w3c-dist-auth-request@w3.org Tue Oct 8 13:46:51 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA23616 for ; Tue, 8 Oct 2002 13:46:51 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g98HiTE26076; Tue, 8 Oct 2002 13:44:29 -0400 (EDT) Resent-Date: Tue, 8 Oct 2002 13:44:29 -0400 (EDT) Resent-Message-Id: <200210081744.g98HiTE26076@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g98HiSB26050 for ; Tue, 8 Oct 2002 13:44:28 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA16847 for ; Tue, 8 Oct 2002 13:44:27 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 08 Oct 2002 13:33:19 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Tue, 8 Oct 2002 13:43:57 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Tue, 8 Oct 2002 13:43:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26EF2.44005A50" Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6797 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26EF2.44005A50 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Perhaps you could explain this with an example? In particular, whenever you would have a client submit: New-If-Header: token-1 token-2 I would have that client submit: If: () () Other than the minor syntactic swill, and the addition of the lockroot tag, what is the difference in terms of client effort? (Semantically of course there is a difference, in that you cannot submit invalid lock tokens in If, but that is a separate issue).=20 Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Tuesday, October 08, 2002 12:44 PM To: 'Clemm, Geoff'; 'Webdav WG' Subject: RE: Interop issue: Proposal for fixing lock token provision > Using a different header to submit tokens doesn't make it any easier=20 > for a client to decide what tokens to submit in the header.=A0=20 Yes it does, which is one of the major reasons client developers have asked for this to be fixed: it makes it possible for clients to submit = a bunch of lock tokens for the same "area" of the namespace, even if the client is not sure whether the server would require each lock token. Since servers are different in how they require lock tokens for various operations, this allows clients to submit as many lock tokens as they believe they need, without failing on some servers. lisa ------_=_NextPart_001_01C26EF2.44005A50 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Interop issue: Proposal for fixing lock token = provision

Perhaps you could explain this with an = example?

In particular, whenever you would have a client = submit:

New-If-Header: token-1 token-2

I would have that client submit:

If: <lockroot-1> (<token1>) = <lockroot-2> (<token-2>)

Other than the minor syntactic swill, and the = addition of the
lockroot tag, what is the difference in terms of = client effort?
(Semantically of course there is a difference, in = that
you cannot submit invalid lock tokens in If, = but
that is a separate issue).

Cheers,
Geoff



-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Sent: Tuesday, October 08, 2002 12:44 PM
To: 'Clemm, Geoff'; 'Webdav WG'
Subject: RE: Interop issue: Proposal for fixing lock = token provision


> Using a different header to submit tokens = doesn't make it any easier
> for a client to decide what tokens to submit in = the header.=A0

Yes it does, which is one of the major reasons client = developers have
asked for this to be fixed: it makes it possible for = clients to submit a
bunch of lock tokens for the same "area" = of the namespace, even if the
client is not sure whether the server would require = each lock token.

Since servers are different in how they require lock = tokens for various
operations, this allows clients to submit as many = lock tokens as they
believe they need, without failing on some = servers.

lisa

------_=_NextPart_001_01C26EF2.44005A50-- From w3c-dist-auth-request@w3.org Tue Oct 8 14:22:50 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25089 for ; Tue, 8 Oct 2002 14:22:50 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g98IDHa00361; Tue, 8 Oct 2002 14:13:17 -0400 (EDT) Resent-Date: Tue, 8 Oct 2002 14:13:17 -0400 (EDT) Resent-Message-Id: <200210081813.g98IDHa00361@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g98IDGB00298 for ; Tue, 8 Oct 2002 14:13:16 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA23491 for ; Tue, 8 Oct 2002 14:13:13 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 08 Oct 2002 14:02:05 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Tue, 8 Oct 2002 14:12:43 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Tue, 8 Oct 2002 14:12:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26EF6.47C5C9F0" Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6798 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26EF6.47C5C9F0 Content-Type: text/plain Jason pointed out to me in some private email that the questions in his last posting were not rhetorical questions advocating one proposal or another, but rather real questions that he thought we need to answer. I'd like to apologize to Jason for misreading his message, and try to answer them properly this time. From: Jason Crawford [mailto:nn683849@smallcue.com] On Monday, 10/07/2002 "Clemm, Geoff" wrote: > Alternatively, we could just say: > > "A client MUST submit a tagged-list If header, using the > DAV:lock-root of the lock as the tag for that lock token." > > If any of the tagged-list productions fail, the resource > that is no longer locked will be indicated with a 412 in > the multistatus return, telling the client to either remove > that lock from its table, or request a new lock for that > resource. And ALL tag list productions would be evaluated, so that even if the server didn't think it was relevant, it still would be checked. So for example I can do a GET on a resource with an IF: header and the IF: header would be checked despite the server thinking it is unnecessary to check for locks on a GET request. Does this sound fine? If a server knows that no condition specifiable in an If can cause a GET to fail, then it can skip the If check. But if it is not absolutely sure, then yes, it has to check the If header. And the client is required to submit a tag list for every URL/resource that the server thinks is relevant in order to submit the token. And we're going to have to define what URL's are relevant. Whether we can define what URLs are relevant will depend somewhat on whether we can get server consensus on that question. We may need to have a few "MAY depend" clauses. But optimally, we can avoid that and make everything a MUST. And define what constitutes submission. Yes, we definitely have to clearly define what constitutes submission. So for a situation where a token needs to be submitted to allow a protected URL from being broken (lock destroyed), the root URL of the lock in question needs to be submitted. Yes. (I assume you meant "to be broken" rather than "from being broken"). And in a situation where a token is needed to allow a write locked resource to be modified, the URL of the root of that resource needs to be specified. Yes. We have been discussing whether to make a special case for the UNLOCK request, but this may end up being decided more on interoperability grounds (i.e. if existing servers require the request-URL to be the lock-root, then for interoperability, we should at least advise clients that they should use the lock-root for interoperability). And what is "modifying"? A PUT/PROPPATCH to an ordinary resouce modifies it. Yes, in this case, I think we can clearly state that only the lock on the resource specified by the request-URL must be submitted. Also operations that add or remove children of a collection are considered to modify the collection. To add a child, you would have to submit tokens for any locks on the collection. To remove a child you would have to submit tokens for any locks on the collection, any locks on the child being removed, and if the child is a collection, any locks on any member of the child collection. The client is free to test any other resources it wants to test beyond the one's the server requires. Yes. We need a spec'ing of what tag list entries are sufficient to be considered a submission. That has to deal with NOT and any other expression constructs we might come up with. I think it is simplest to just state that the appearance of the lock token anywhere in the tagged list for the resource is sufficient. BTW... yes, I know earlier tonight I said that it's okay to test against any resource locked by a resource in order to submit the lock, but I'm guessing the definition of "submit" will be easier if we are as specific as possible about what it means to submit a token and specifying what URL is definitely something that will help. I agree. Also, in the case of 2518-style DELETE where lots of bindings get destoryed and they probably get destroyed bottom up, I'd think it would be best (or at least equal) in some server implementations if the URL you specified for the submisssion was the one that got destoryed last. This raises a good (although tangential) point. The BIND protocol "clarifies" the 2518 DELETE semantics, to state that it is the "mappings" to all the members that are removed by the DELETE of a collection, not the bindings. I believe this clarification should appear in 2518bis. But even if some (misguided :-) server did destroy all the bindings, the last one destroyed will be the lock-root, so I think we're OK here to require that the lock-root be the tag for the submitted token. Cheers, Geoff ------_=_NextPart_001_01C26EF6.47C5C9F0 Content-Type: text/html RE: Interop issue: Proposal for fixing lock token provision

Jason pointed out to me in some private email that the questions in
his last posting were not rhetorical questions advocating one proposal
or another, but rather real questions that he thought we need to
answer.  I'd like to apologize to Jason for misreading his message,
and try to answer them properly this time.

   From: Jason Crawford [mailto:nn683849@smallcue.com]

   On Monday, 10/07/2002 "Clemm, Geoff" wrote:
   > Alternatively, we could just say:
   >
   > "A client MUST submit a tagged-list If header, using the
   > DAV:lock-root of the lock as the tag for that lock token."
   >
   > If any of the tagged-list productions fail, the resource
   > that is no longer locked will be indicated with a 412 in
   > the multistatus return, telling the client to either remove
   > that lock from its table, or request a new lock for that
   > resource.

   And ALL tag list productions would be evaluated, so that even if
   the server didn't think it was relevant, it still would be checked.
   So for example I can do a GET on a resource with an IF: header and
   the IF: header would be checked despite the server thinking it is
   unnecessary to check for locks on a GET request.  Does this sound
   fine?

If a server knows that no condition specifiable in an If can cause a
GET to fail, then it can skip the If check.  But if it is not
absolutely sure, then yes, it has to check the If header.

   And the client is required to submit a tag list for every
   URL/resource that the server thinks is relevant in order to submit
   the token.  And we're going to have to define what URL's are
   relevant.

Whether we can define what URLs are relevant will depend somewhat on
whether we can get server consensus on that question.  We may need to
have a few "MAY depend" clauses.  But optimally, we can avoid that
and make everything a MUST.

   And define what constitutes submission.

Yes, we definitely have to clearly define what constitutes submission.

   So for a situation where a token needs to be submitted to allow a
   protected URL from being broken (lock destroyed), the root URL of
   the lock in question needs to be submitted.

Yes.  (I assume you meant "to be broken" rather than "from being broken").

   And in a situation where a token is needed to allow a write locked
   resource to be modified, the URL of the root of that resource needs
   to be specified.

Yes.  We have been discussing whether to make a special case for the
UNLOCK request, but this may end up being decided more on
interoperability grounds (i.e. if existing servers require the
request-URL to be the lock-root, then for interoperability, we should
at least advise clients that they should use the lock-root for
interoperability).

   And what is "modifying"? A PUT/PROPPATCH to an ordinary
   resouce modifies it.

Yes, in this case, I think we can clearly state that only the
lock on the resource specified by the request-URL must be
submitted.

   Also operations that add or remove children
   of a collection are considered to modify the collection.

To add a child, you would have to submit tokens for any locks
on the collection.  To remove a child you would have to submit
tokens for any locks on the collection, any locks on the child
being removed, and if the child is a collection, any locks on
any member of the child collection.

   The client is free to test any other resources it wants to test
   beyond the one's the server requires.

Yes.

   We need a spec'ing of what tag list entries are sufficient to be
   considered a submission.  That has to deal with NOT and any other
   expression constructs we might come up with.

I think it is simplest to just state that the appearance of the lock
token anywhere in the tagged list for the resource is sufficient.

   BTW... yes, I know earlier tonight I said that it's okay to test
   against any resource locked by a resource in order to submit the
   lock, but I'm guessing the definition of "submit" will be easier if
   we are as specific as possible about what it means to submit a
   token and specifying what URL is definitely something that will
   help.

I agree.

   Also, in the case of 2518-style DELETE where lots of bindings get
   destoryed and they probably get destroyed bottom up, I'd think it
   would be best (or at least equal) in some server implementations if
   the URL you specified for the submisssion was the one that got
   destoryed last.

This raises a good (although tangential) point.
The BIND protocol "clarifies" the 2518 DELETE semantics, to
state that it is the "mappings" to all the members that are
removed by the DELETE of a collection, not the bindings.
I believe this clarification should appear in 2518bis.

But even if some (misguided :-) server did destroy all the
bindings, the last one destroyed will be the lock-root, so
I think we're OK here to require that the lock-root be the
tag for the submitted token.

Cheers,
Geoff

------_=_NextPart_001_01C26EF6.47C5C9F0-- From w3c-dist-auth-request@w3.org Tue Oct 8 14:48:17 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA25943 for ; Tue, 8 Oct 2002 14:48:16 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g98Iflp07568; Tue, 8 Oct 2002 14:41:47 -0400 (EDT) Resent-Date: Tue, 8 Oct 2002 14:41:47 -0400 (EDT) Resent-Message-Id: <200210081841.g98Iflp07568@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g98IfkB07541 for ; Tue, 8 Oct 2002 14:41:46 -0400 (EDT) Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA32683 for ; Tue, 8 Oct 2002 14:41:45 -0400 Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Tue, 08 Oct 2002 14:40:59 -0400 (Eastern Daylight Time) Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453); Tue, 8 Oct 2002 14:40:59 -0400 Received: from xythoslap ([216.36.77.241]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453); Tue, 8 Oct 2002 14:40:35 -0400 From: "Lisa Dusseault" To: "'Clemm, Geoff'" , "'Webdav WG'" Date: Tue, 8 Oct 2002 11:40:34 -0700 Message-ID: <003a01c26efa$306a08d0$b701a8c0@xythoslap> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Importance: Normal X-OriginalArrivalTime: 08 Oct 2002 18:40:35.0746 (UTC) FILETIME=[30AF2820:01C26EFA] Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6799 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----=_NextPart_000_003B_01C26EBF.840B30D0" ------=_NextPart_000_003B_01C26EBF.840B30D0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit The client should be able to choose either of the headers you use as examples, depending on whether they want the request to succeed even if lock tokens are invalid. When the client submits "New-If-Header: token-1, token-2" (note the comma) the client wants the request to succeed, as can be seen by the fact that it is not issuing a conditional request. So: 1. If token-1 is not needed, or doesn't correspond to a live lock, the request doesn't fail. 2. Same for token-1. When the client submits "If: () ()", the client is forcing the request to fail if the conditions aren't met. If that's what the client wants, then fine. But if the client wants the request to succeed, I would hope the client could use something else, because: 1. If token1 is invalid, or doesn't match lockroot-1, the request fails. 2. Same for token2 Syntactic "swill" is important in this case because when moving a directory with a bunch of locked files, the syntactic "swill" of the existing if header can result in a request that is impossible to successfully convey to the server because of bad support (in proxies, firewalls or servers) for very long header values. Client effort may or may not be reduced. Client effort is definitely reduced in these cases: 1. The client has been able to put all their lock tokens in the "New-If-Header" value without having to sort which ones apply to which URLs and which ones are "required" for this operation. 2. If a lock has gone away, the client is not forced to (a) parse the error and (b) reformat request without offending tokens and (c) reissue the request, which they want to work, just in order for it to work. I fail to understand how these are "separate issues". The proposal has several advantages described. It can be interoperable with the existing client/server deployed base because nobody has to change how they send/handle the existing IF header. Perhaps you want to compare this to another proposal that would solve some of the same problems, but if that's the case, then I cannot answer because I do not understand what the alternate proposal is. Lisa -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff Sent: Tuesday, October 08, 2002 10:44 AM To: 'Webdav WG' Subject: RE: Interop issue: Proposal for fixing lock token provision Perhaps you could explain this with an example? In particular, whenever you would have a client submit: New-If-Header: token-1 token-2 I would have that client submit: If: () () Other than the minor syntactic swill, and the addition of the lockroot tag, what is the difference in terms of client effort? (Semantically of course there is a difference, in that you cannot submit invalid lock tokens in If, but that is a separate issue). Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Tuesday, October 08, 2002 12:44 PM To: 'Clemm, Geoff'; 'Webdav WG' Subject: RE: Interop issue: Proposal for fixing lock token provision > Using a different header to submit tokens doesn't make it any easier > for a client to decide what tokens to submit in the header. Yes it does, which is one of the major reasons client developers have asked for this to be fixed: it makes it possible for clients to submit a bunch of lock tokens for the same "area" of the namespace, even if the client is not sure whether the server would require each lock token. Since servers are different in how they require lock tokens for various operations, this allows clients to submit as many lock tokens as they believe they need, without failing on some servers. lisa ------=_NextPart_000_003B_01C26EBF.840B30D0 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable RE: Interop issue: Proposal for fixing lock token = provision

The client should be able to choose = either of the headers you use as examples, depending on whether they want the = request to succeed even if lock tokens are invalid.

 

When the client submits = “New-If-Header: token-1, token-2” (note the comma) the client wants the request to succeed, as can be seen by the fact that it is not issuing a conditional request.  So:

1.       If token-1 is = not needed, or doesn’t correspond to a live lock, the request doesn’t = fail.

2.       Same for = token-1.

 

When the client submits = “If:<lockroot-1> (<token1>) <lockroot-2> (<token-2>)”, the client is forcing the request to fail if = the conditions aren’t met.  If that’s what the client = wants, then fine.  But if the client wants the request to succeed, I would hope = the client could use something else, because:

1.       If token1 is = invalid, or doesn’t match lockroot-1, the request fails.

2.       Same for = token2

 

Syntactic “swill” is = important in this case because when moving a directory with a bunch of locked = files, the syntactic “swill” of the existing if header can result in a = request that is impossible to successfully convey to the server because of bad = support (in proxies, firewalls or servers) for very long header = values.

 

Client effort may or may not be = reduced.  Client effort is definitely reduced in these cases:

1.       The client has = been able to put all their lock tokens in the “New-If-Header” value = without having to sort which ones apply to which URLs and which ones are = “required” for this operation.

2.       If a lock has = gone away, the client is not forced to (a) parse the error and (b) reformat request without offending tokens and (c) reissue the request, which they want to = work, just in order for it to work.

 

I fail to understand how these are = “separate issues”.  The proposal has several advantages described. It = can be interoperable with the existing client/server deployed base because = nobody has to change how they send/handle the existing IF header.  Perhaps you = want to compare this to another proposal that would solve some of the same = problems, but if that’s the case, then I cannot answer because I do not = understand what the alternate proposal is.

 

Lisa

 

-----Original Message-----
From: = w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff
Sent: Tuesday, October 08, 2002 10:44 = AM
To: 'Webdav WG'
Subject: RE: Interop = issue: Proposal for fixing lock token provision

 

Perhaps you could explain this with an example?

In particular, whenever you would have a client submit:

New-If-Header: token-1 token-2

I would have that client submit:

If: <lockroot-1> (<token1>) <lockroot-2> = (<token-2>)

Other than the minor syntactic swill, and the addition of the =
lockroot tag, what is = the difference in terms of client effort?
(Semantically of course = there is a difference, in that
you cannot submit = invalid lock tokens in If, but
that is a separate = issue).

Cheers,
Geoff

 

-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]=
Sent: Tuesday, October = 08, 2002 12:44 PM
To: 'Clemm, Geoff'; = 'Webdav WG'
Subject: RE: Interop = issue: Proposal for fixing lock token provision

 

> Using a different header to submit tokens doesn't make it any easier =
> for a client to = decide what tokens to submit in the header. 

Yes it does, which is one of the major reasons client developers = have
asked for this to be = fixed: it makes it possible for clients to submit a
bunch of lock tokens for = the same "area" of the namespace, even if the
client is not sure = whether the server would require each lock token.

Since servers are different in how they require lock tokens for = various
operations, this allows = clients to submit as many lock tokens as they
believe they need, = without failing on some servers.

lisa

------=_NextPart_000_003B_01C26EBF.840B30D0-- --------------InterScan_NT_MIME_Boundary-- From w3c-dist-auth-request@w3.org Tue Oct 8 15:16:40 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA27234 for ; Tue, 8 Oct 2002 15:16:39 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g98JA3u11424; Tue, 8 Oct 2002 15:10:03 -0400 (EDT) Resent-Date: Tue, 8 Oct 2002 15:10:03 -0400 (EDT) Resent-Message-Id: <200210081910.g98JA3u11424@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g98JA1B11388 for ; Tue, 8 Oct 2002 15:10:01 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA07109 for ; Tue, 8 Oct 2002 15:10:01 -0400 Received: (qmail 28128 invoked by uid 0); 8 Oct 2002 19:09:58 -0000 Received: from p3ee24718.dip.t-dialin.net (HELO lisa) (62.226.71.24) by mail.gmx.net (mp002-rz3) with SMTP; 8 Oct 2002 19:09:58 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Clemm, Geoff'" , "'Webdav WG'" Date: Tue, 8 Oct 2002 21:09:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0019_01C26F0F.0D0D6750" 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.1106 Importance: Normal In-Reply-To: <003a01c26efa$306a08d0$b701a8c0@xythoslap> Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6800 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0019_01C26F0F.0D0D6750 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit RE: Interop issue: Proposal for fixing lock token provisionSome thoughts: - it doesn't make sense to raise the header length problem as argument in favor of adding a new header. If the If header length is a problem, it needs to be fixed anyway -- no matter how the other issues are treated - As far as I now understand the client issue (BTW: why aren't the developers of this or these clients not participating in this dicussion??), they want to avoid to re-issue a request that specified a lock token just because the lock went away in the meantime. I *still* don't see why this is a problem -- if the lock was theirs, it's not supposed to go away without reason (such as bad timeout value). If the lock *wasn't* theirs, this is a case of "lock stealing", which certainly doesn't require to be optimized, right? - if a client really really wants the request to succeed either case (lock being present or not), can't he simply submit an If header production such as: If: ()(Not )) ? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault Sent: Tuesday, October 08, 2002 8:41 PM To: 'Clemm, Geoff'; 'Webdav WG' Subject: RE: Interop issue: Proposal for fixing lock token provision The client should be able to choose either of the headers you use as examples, depending on whether they want the request to succeed even if lock tokens are invalid. When the client submits "New-If-Header: token-1, token-2" (note the comma) the client wants the request to succeed, as can be seen by the fact that it is not issuing a conditional request. So: 1. If token-1 is not needed, or doesn't correspond to a live lock, the request doesn't fail. 2. Same for token-1. When the client submits "If: () ()", the client is forcing the request to fail if the conditions aren't met. If that's what the client wants, then fine. But if the client wants the request to succeed, I would hope the client could use something else, because: 1. If token1 is invalid, or doesn't match lockroot-1, the request fails. 2. Same for token2 Syntactic "swill" is important in this case because when moving a directory with a bunch of locked files, the syntactic "swill" of the existing if header can result in a request that is impossible to successfully convey to the server because of bad support (in proxies, firewalls or servers) for very long header values. Client effort may or may not be reduced. Client effort is definitely reduced in these cases: 1. The client has been able to put all their lock tokens in the "New-If-Header" value without having to sort which ones apply to which URLs and which ones are "required" for this operation. 2. If a lock has gone away, the client is not forced to (a) parse the error and (b) reformat request without offending tokens and (c) reissue the request, which they want to work, just in order for it to work. I fail to understand how these are "separate issues". The proposal has several advantages described. It can be interoperable with the existing client/server deployed base because nobody has to change how they send/handle the existing IF header. Perhaps you want to compare this to another proposal that would solve some of the same problems, but if that's the case, then I cannot answer because I do not understand what the alternate proposal is. Lisa -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] On Behalf Of Clemm, Geoff Sent: Tuesday, October 08, 2002 10:44 AM To: 'Webdav WG' Subject: RE: Interop issue: Proposal for fixing lock token provision Perhaps you could explain this with an example? In particular, whenever you would have a client submit: New-If-Header: token-1 token-2 I would have that client submit: If: () () Other than the minor syntactic swill, and the addition of the lockroot tag, what is the difference in terms of client effort? (Semantically of course there is a difference, in that you cannot submit invalid lock tokens in If, but that is a separate issue). Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Tuesday, October 08, 2002 12:44 PM To: 'Clemm, Geoff'; 'Webdav WG' Subject: RE: Interop issue: Proposal for fixing lock token provision > Using a different header to submit tokens doesn't make it any easier > for a client to decide what tokens to submit in the header. Yes it does, which is one of the major reasons client developers have asked for this to be fixed: it makes it possible for clients to submit a bunch of lock tokens for the same "area" of the namespace, even if the client is not sure whether the server would require each lock token. Since servers are different in how they require lock tokens for various operations, this allows clients to submit as many lock tokens as they believe they need, without failing on some servers. lisa ------=_NextPart_000_0019_01C26F0F.0D0D6750 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable RE: Interop issue: Proposal for fixing lock token = provision
Some=20 thoughts:
 
- it=20 doesn't make sense to raise the header length problem as argument in = favor of=20 adding a new header. If the If header length is a problem, it needs = to be=20 fixed anyway -- no matter how the other issues are = treated
 
- As=20 far as I now understand the client issue (BTW: why aren't the developers = of this=20 or these clients not participating in this dicussion??), they want to = avoid to=20 re-issue a request that specified a lock token just because the lock = went away=20 in the meantime. I *still* don't see why this is a problem -- if the = lock was=20 theirs, it's not supposed to go away without reason (such as bad timeout = value).=20 If the lock *wasn't* theirs, this is a case of "lock stealing", which = certainly=20 doesn't require to be optimized, right?
 
- if a=20 client really really wants the request to succeed either case (lock = being=20 present or not), can't he simply submit an If header production such=20 as:
 
If:=20 <http://www.foo.bar/resource1> = (<locktoken:a-write-lock-token>)(Not=20 <locktoken:a-write-lock-token>))
?
 
Julian

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

-----Original Message-----
From: = w3c-dist-auth-request@w3.org=20 [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa=20 Dusseault
Sent: Tuesday, October 08, 2002 8:41 = PM
To:=20 'Clemm, Geoff'; 'Webdav WG'
Subject: RE: Interop issue: = Proposal for=20 fixing lock token provision

The client = should be=20 able to choose either of the headers you use as examples, depending on = whether=20 they want the request to succeed even if lock tokens are=20 invalid.

 

When the = client=20 submits “New-If-Header: token-1, token-2” (note the comma) = the client wants=20 the request to succeed, as can be seen by the fact that it is not = issuing a=20 conditional request.  So:

1.      =20 If token-1 = is not=20 needed, or doesn’t correspond to a live lock, the request = doesn’t=20 fail.

2.      =20 Same for=20 token-1.

 

When the = client=20 submits “If:<lockroot-1> (<token1>)=20 <lockroot-2> (<token-2>)”, the client is forcing the = request to=20 fail if the conditions aren’t met.  If that’s what = the client wants, then=20 fine.  But if the client wants the request to succeed, I would = hope the=20 client could use something else, because:

1.      =20 If token1 = is invalid,=20 or doesn’t match lockroot-1, the request = fails.

2.      =20 Same for=20 token2

 

Syntactic = “swill” is=20 important in this case because when moving a directory with a bunch of = locked=20 files, the syntactic “swill” of the existing if header can = result in a request=20 that is impossible to successfully convey to the server because of bad = support=20 (in proxies, firewalls or servers) for very long header=20 values.

 

Client = effort may or=20 may not be reduced.  Client effort is definitely reduced in these = cases:

1.      =20 The client = has been=20 able to put all their lock tokens in the “New-If-Header” = value without having=20 to sort which ones apply to which URLs and which ones are = “required” for this=20 operation.

2.      =20 If a lock = has gone=20 away, the client is not forced to (a) parse the error and (b) reformat = request=20 without offending tokens and (c) reissue the request, which they want = to work,=20 just in order for it to work.

 

I fail to = understand=20 how these are “separate issues”.  The proposal has = several advantages=20 described. It can be interoperable with the existing client/server = deployed=20 base because nobody has to change how they send/handle the existing IF = header.  Perhaps you want to compare this to another proposal = that would=20 solve some of the same problems, but if that’s the case, then I = cannot answer=20 because I do not understand what the alternate proposal = is.

 

Lisa

 

-----Original=20 Message-----
From:=20 w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] = On Behalf Of Clemm, = Geoff
Sent: Tuesday, = October 08,=20 2002 10:44=20 AM
To: 'Webdav WG'
Subject: RE: Interop issue: = Proposal for=20 fixing lock token provision

 

Perhaps=20 you could explain this with an example?

In=20 particular, whenever you would have a client submit: =

New-If-Header: token-1 token-2 =

I would=20 have that client submit:

If:=20 <lockroot-1> (<token1>) <lockroot-2>=20 (<token-2>)

Other=20 than the minor syntactic swill, and the addition of the=20
lockroot tag, what = is the=20 difference in terms of client effort?
(Semantically of course there is a = difference, in=20 that
you cannot=20 submit invalid lock tokens in If, but
that is a separate issue). =

Cheers,
Geoff

 

-----Original Message----- =
From: Lisa Dusseault [mailto:lisa@xythos.com]= =20
Sent: Tuesday, = October 08, 2002=20 12:44 PM
To:=20 'Clemm, Geoff'; 'Webdav WG'
Subject: RE: Interop issue: Proposal for = fixing lock=20 token provision

 

>=20 Using a different header to submit tokens doesn't make it any easier=20
> = for a client=20 to decide what tokens to submit in the header.  =

Yes it=20 does, which is one of the major reasons client developers = have=20
asked for this to = be fixed: it=20 makes it possible for clients to submit a
bunch of lock tokens for the same "area" of = the=20 namespace, even if the
client is not sure whether the server would = require=20 each lock token.

Since=20 servers are different in how they require lock tokens for=20 various
operations, this allows clients to submit as = many lock=20 tokens as they
believe they need, without failing on some=20 servers.

lisa=20

------=_NextPart_000_0019_01C26F0F.0D0D6750-- From w3c-dist-auth-request@w3.org Tue Oct 8 17:25:19 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA01354 for ; Tue, 8 Oct 2002 17:25:19 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g98LIvK27709; Tue, 8 Oct 2002 17:18:57 -0400 (EDT) Resent-Date: Tue, 8 Oct 2002 17:18:57 -0400 (EDT) Resent-Message-Id: <200210082118.g98LIvK27709@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g98LIuB27683 for ; Tue, 8 Oct 2002 17:18:56 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA00690 for ; Tue, 8 Oct 2002 17:18:56 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Tue, 08 Oct 2002 17:07:36 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Tue, 8 Oct 2002 17:18:14 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Tue, 8 Oct 2002 17:18:12 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26F10.359A9C00" Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6801 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26F10.359A9C00 Content-Type: text/plain Julian makes several good points. One is that we need to address the If header length problem in 2518bis in any case. Even if we did provide a separate header that allowed invalid lock tokens, we still need to use the If header when we want to check for a list of valid lock tokens, or when we want to check for a list of etags. Another good point is that we don't have to argue about whether a client should be allowed to submit invalid lock tokens, because once the If header length problem is addressed (which we have to do anyway), then the "If: ()(Not )" provides this functionality without defining a header with new semantics. In an earlier message in this thread, the following points were raised as being problems with the "If:...Not..." approach: PROBLEM #1: Servers may not support the OR, and the NOT, correctly, because most clients don't currently use this. This solution HAS NOT been proven, it is only theoretical. It might not work. It will work against all existing servers that are correctly implemented and that don't have an If header length problem, unlike the "new header" approach, which is guaranteed to fail against all existing servers. If the servers are going to be updated, updating them to correctly implement existing semantics seems like a sensible approach to take, especially when the existing semantics are a "logical or" and a "logical not", built-in operators in most programming languages. PROBLEM #2: What if multiple locks are required (e.g. moving a collection that has multiple locked resources? What if the URLs are long? The IF header becomes very long and may be truncated by some proxies. E.g. If: ( NOT ) ( NOT ) ( NOT ) This is the If header length problem. Once we fix the If header problem (which we have to do anyway), there no longer is a need for a new header to get this functionality. PROBLEM #3: Uck, this is really complicated. While it's useful to know that a client can do this with some existing servers, provided they handle it correctly, surely we can do this in a simpler mechanism that is less prone to interoperability problems. A simple header that allows the client to supply lock tokens to use is semantically equivalent to the above example, but shorter, simpler, and easier to implement. Also it can be split across multiple lines. Use-Lock-Tokens: , Use-Lock-Tokens: Computer programs are really good at spitting out the same string twice, surrounded by some constant characters. Given the verbosity of XML, and the fact that the Internet is used to stream video, cutting down the number of characters required to identify lock tokens does not strike me as a high priority task. And since any client that wants to interoperate with an existing server has to be able to generate the If form of the request anyway, this is no simplification for an interoperable client that has to be able to generate both forms of the request. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Some thoughts: - it doesn't make sense to raise the header length problem as argument in favor of adding a new header. If the If header length is a problem, it needs to be fixed anyway -- no matter how the other issues are treated - As far as I now understand the client issue (BTW: why aren't the developers of this or these clients not participating in this dicussion??), they want to avoid to re-issue a request that specified a lock token just because the lock went away in the meantime. I *still* don't see why this is a problem -- if the lock was theirs, it's not supposed to go away without reason (such as bad timeout value). If the lock *wasn't* theirs, this is a case of "lock stealing", which certainly doesn't require to be optimized, right? - if a client really really wants the request to succeed either case (lock being present or not), can't he simply submit an If header production such as: If: ()(Not )) ? ------_=_NextPart_001_01C26F10.359A9C00 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Interop issue: Proposal for fixing lock token = provision

Julian makes several good points.

One is that we need to address the If header length = problem in 2518bis
in any case.  Even if we did provide a separate = header that allowed
invalid lock tokens, we still need to use the If = header when we want
to check for a list of valid lock tokens, or when we = want to check for
a list of etags.

Another good point is that we don't have to argue = about whether a
client should be allowed to submit invalid lock = tokens, because once
the If header length problem is addressed (which we = have to do
anyway), then the "If: <tag> = (<token>)(Not <token>)" provides this
functionality without defining a header with new = semantics.

In an earlier message in this thread, the following = points were raised
as being problems with the = "If:...Not..."  approach:

   PROBLEM #1: Servers may not support the = OR, and the NOT, correctly,
   because most clients don't currently = use this. This solution HAS NOT
   been proven, it is only theoretical. It = might not work.

It will work against all existing servers that are = correctly
implemented and that don't have an If header length = problem, unlike
the "new header" approach, which is = guaranteed to fail against all
existing servers.  If the servers are going to = be updated,
updating them to correctly implement existing = semantics seems
like a sensible approach to take, especially when = the existing
semantics are a "logical or" and a = "logical not", built-in operators
in most programming languages.

   PROBLEM #2: What if multiple locks are = required (e.g. moving a
   collection that has multiple locked = resources? What if the URLs are
   long? The IF header becomes very long = and may be truncated by some
   proxies. E.g.

   If: <http://www.ics.uci.edu/users/f/fielding/index.html= >
   = (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>
   NOT = <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>)
   <http:// = www.ics.uci.edu/users/f/fielding/anotherfile.html>
   = (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf7>
   NOT = <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf7>)
   <http:// = www.ics.uci.edu/users/f/fielding/thirdfile.html>
   = (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8>
   NOT = <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8>)

This is the If header length problem.  Once we = fix the If header
problem (which we have to do anyway), there no = longer is a need
for a new header to get this functionality.

   PROBLEM #3: Uck, this is really = complicated. While it's useful to know
   that a client can do this with some = existing servers, provided they
   handle it correctly, surely we can do = this in a simpler mechanism that
   is less prone to interoperability = problems. A simple header that allows
   the client to supply lock tokens to use = is semantically equivalent to
   the above example, but shorter, = simpler, and easier to implement. Also
   it can be split across multiple = lines.
   Use-Lock-Tokens:
   = <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>,
   = <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf7>
   Use-Lock-Tokens:
   = <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8>

Computer programs are really good at spitting out the = same string
twice, surrounded by some constant characters.  = Given the verbosity of
XML, and the fact that the Internet is used to = stream video, cutting
down the number of characters required to identify = lock tokens does
not strike me as a high priority task.  And = since any client that
wants to interoperate with an existing server has to = be able to
generate the If form of the request anyway, this is = no simplification
for an interoperable client that has to be able to = generate both forms
of the request.

Cheers,
Geoff


-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]<= /FONT>

Some thoughts:

- it doesn't make sense to raise the header length = problem as argument
  in favor of adding a new header. If the If = header length is a
  problem, it needs to be fixed anyway -- no = matter how the other
  issues are treated

- As far as I now understand the client issue (BTW: = why aren't the
  developers of this or these clients not = participating in this
  dicussion??), they want to avoid to re-issue = a request that
  specified a lock token just because the lock = went away in the
  meantime. I *still* don't see why this is a = problem -- if the lock
  was theirs, it's not supposed to go away = without reason (such as bad
  timeout value). If the lock *wasn't* theirs, = this is a case of "lock
  stealing", which certainly doesn't = require to be optimized, right?

- if a client really really wants the request to = succeed either case
  (lock being present or not), can't he simply = submit an If header
  production such as:

If: <http://www.foo.bar/resource1> = (<locktoken:a-write-lock-token>)(Not = <locktoken:a-write-lock-token>))

?

------_=_NextPart_001_01C26F10.359A9C00-- From w3c-dist-auth-request@w3.org Tue Oct 8 20:05:42 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA04386 for ; Tue, 8 Oct 2002 20:05:42 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g98Np4313054; Tue, 8 Oct 2002 19:51:04 -0400 (EDT) Resent-Date: Tue, 8 Oct 2002 19:51:04 -0400 (EDT) Resent-Message-Id: <200210082351.g98Np4313054@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g98Np3B13025 for ; Tue, 8 Oct 2002 19:51:03 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id TAA23972 for ; Tue, 8 Oct 2002 19:51:02 -0400 Received: (qmail 4999 invoked by uid 0); 8 Oct 2002 23:50:27 -0000 Received: from p3ee24718.dip.t-dialin.net (HELO lisa) (62.226.71.24) by mail.gmx.net (mp002-rz3) with SMTP; 8 Oct 2002 23:50:27 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'Webdav WG'" Date: Wed, 9 Oct 2002 01:50:23 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_002D_01C26F36.3B96C950" 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.1106 Importance: Normal In-Reply-To: Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6802 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_002D_01C26F36.3B96C950 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: Interop issue: Proposal for fixing lock token provisionObviously I agree with Geoff. I'd like to underline that I'm *really* interested to understand why a client would *ever* want a request to succeed if a lock which is supposed to be present unexpectedly disappeared. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff Sent: Tuesday, October 08, 2002 11:18 PM To: 'Webdav WG' Subject: RE: Interop issue: Proposal for fixing lock token provision Julian makes several good points. One is that we need to address the If header length problem in 2518bis in any case. Even if we did provide a separate header that allowed invalid lock tokens, we still need to use the If header when we want to check for a list of valid lock tokens, or when we want to check for a list of etags. Another good point is that we don't have to argue about whether a client should be allowed to submit invalid lock tokens, because once the If header length problem is addressed (which we have to do anyway), then the "If: ()(Not )" provides this functionality without defining a header with new semantics. In an earlier message in this thread, the following points were raised as being problems with the "If:...Not..." approach: PROBLEM #1: Servers may not support the OR, and the NOT, correctly, because most clients don't currently use this. This solution HAS NOT been proven, it is only theoretical. It might not work. It will work against all existing servers that are correctly implemented and that don't have an If header length problem, unlike the "new header" approach, which is guaranteed to fail against all existing servers. If the servers are going to be updated, updating them to correctly implement existing semantics seems like a sensible approach to take, especially when the existing semantics are a "logical or" and a "logical not", built-in operators in most programming languages. PROBLEM #2: What if multiple locks are required (e.g. moving a collection that has multiple locked resources? What if the URLs are long? The IF header becomes very long and may be truncated by some proxies. E.g. If: ( NOT ) ( NOT ) ( NOT ) This is the If header length problem. Once we fix the If header problem (which we have to do anyway), there no longer is a need for a new header to get this functionality. PROBLEM #3: Uck, this is really complicated. While it's useful to know that a client can do this with some existing servers, provided they handle it correctly, surely we can do this in a simpler mechanism that is less prone to interoperability problems. A simple header that allows the client to supply lock tokens to use is semantically equivalent to the above example, but shorter, simpler, and easier to implement. Also it can be split across multiple lines. Use-Lock-Tokens: , Use-Lock-Tokens: Computer programs are really good at spitting out the same string twice, surrounded by some constant characters. Given the verbosity of XML, and the fact that the Internet is used to stream video, cutting down the number of characters required to identify lock tokens does not strike me as a high priority task. And since any client that wants to interoperate with an existing server has to be able to generate the If form of the request anyway, this is no simplification for an interoperable client that has to be able to generate both forms of the request. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Some thoughts: - it doesn't make sense to raise the header length problem as argument in favor of adding a new header. If the If header length is a problem, it needs to be fixed anyway -- no matter how the other issues are treated - As far as I now understand the client issue (BTW: why aren't the developers of this or these clients not participating in this dicussion??), they want to avoid to re-issue a request that specified a lock token just because the lock went away in the meantime. I *still* don't see why this is a problem -- if the lock was theirs, it's not supposed to go away without reason (such as bad timeout value). If the lock *wasn't* theirs, this is a case of "lock stealing", which certainly doesn't require to be optimized, right? - if a client really really wants the request to succeed either case (lock being present or not), can't he simply submit an If header production such as: If: ()(Not )) ? ------=_NextPart_000_002D_01C26F36.3B96C950 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Interop issue: Proposal for fixing lock token = provision
Obviously I agree with Geoff.
 
I'd=20 like to underline that I'm *really* interested to understand why a = client would=20 *ever* want a request to succeed if a lock which is supposed to be = present=20 unexpectedly disappeared.
 
Julian

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

-----Original Message-----
From: = w3c-dist-auth-request@w3.org=20 [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm,=20 Geoff
Sent: Tuesday, October 08, 2002 11:18 PM
To: = 'Webdav=20 WG'
Subject: RE: Interop issue: Proposal for fixing lock = token=20 provision

Julian makes several good points.

One is that we need to address the If header length = problem in=20 2518bis
in any case.  Even if we did = provide a=20 separate header that allowed
invalid lock = tokens, we=20 still need to use the If header when we want
to check=20 for a list of valid lock tokens, or when we want to check for =
a list of etags.

Another good point is that we don't have to argue = about=20 whether a
client should be allowed to submit = invalid=20 lock tokens, because once
the If header = length problem=20 is addressed (which we have to do
anyway), = then the=20 "If: <tag> (<token>)(Not <token>)" provides = this=20
functionality without defining a header with new=20 semantics.

In an earlier message in this thread, the following = points=20 were raised
as being problems with the=20 "If:...Not..."  approach:

   PROBLEM #1: Servers may not support the = OR, and=20 the NOT, correctly,
   because = most clients=20 don't currently use this. This solution HAS NOT
   been proven, it is only theoretical. It might = not=20 work.

It will work against all existing servers that are=20 correctly
implemented and that don't have an = If header=20 length problem, unlike
the "new header" = approach,=20 which is guaranteed to fail against all
existing=20 servers.  If the servers are going to be updated, =
updating them to correctly implement existing semantics = seems=20
like a sensible approach to take, especially when = the=20 existing
semantics are a "logical or" and a = "logical=20 not", built-in operators
in most programming = languages.

   PROBLEM #2: What if multiple locks are = required=20 (e.g. moving a
   collection that = has=20 multiple locked resources? What if the URLs are
   long? The IF header becomes very long and may be = truncated=20 by some
   proxies. E.g. =

   If: <http://www.ics.uci.edu/users/f/fielding/index.html>= ;=20
  =20 (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6> =
   NOT=20 <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>) =
   <http://=20 www.ics.uci.edu/users/f/fielding/anotherfile.html>
  =20 (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf7> =
   NOT=20 <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf7>) =
   <http://=20 www.ics.uci.edu/users/f/fielding/thirdfile.html>
  =20 (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8> =
   NOT=20 <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8>) =

This is the If header length problem.  Once we = fix the If=20 header
problem (which we have to do anyway), = there no=20 longer is a need
for a new header to get = this=20 functionality.

   PROBLEM #3: Uck, this is really = complicated.=20 While it's useful to know
   that = a client=20 can do this with some existing servers, provided they
   handle it correctly, surely we can do this in a = simpler=20 mechanism that
   is less prone to = interoperability problems. A simple header that allows =
   the client to supply lock tokens to use is = semantically=20 equivalent to
   the above = example, but=20 shorter, simpler, and easier to implement. Also
   it can be split across multiple lines. =
   Use-Lock-Tokens:
  =20 <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>, =
  =20 <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf7> =
   Use-Lock-Tokens:
  =20 <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8> =

Computer programs are really good at spitting out = the same=20 string
twice, surrounded by some constant=20 characters.  Given the verbosity of
XML, and the=20 fact that the Internet is used to stream video, cutting =
down the number of characters required to identify lock = tokens=20 does
not strike me as a high priority = task.  And=20 since any client that
wants to interoperate = with an=20 existing server has to be able to
generate = the If form=20 of the request anyway, this is no simplification
for=20 an interoperable client that has to be able to generate both = forms=20
of the request.

Cheers,
Geoff =


-----Original Message-----
From:=20 Julian Reschke [mailto:julian.reschke@gmx.de]=20

Some thoughts:

- it doesn't make sense to raise the header length = problem as=20 argument
  in favor of adding a new = header. If=20 the If header length is a
  problem, it = needs to=20 be fixed anyway -- no matter how the other
 =20 issues are treated

- As far as I now understand the client issue (BTW: = why aren't=20 the
  developers of this or these = clients not=20 participating in this
  dicussion??), = they want=20 to avoid to re-issue a request that
  = specified a=20 lock token just because the lock went away in the
  meantime. I *still* don't see why this is a problem -- = if the=20 lock
  was theirs, it's not supposed to = go away=20 without reason (such as bad
  timeout = value). If=20 the lock *wasn't* theirs, this is a case of "lock
  stealing", which certainly doesn't require to be = optimized,=20 right?

- if a client really really wants the request to = succeed=20 either case
  (lock being present or = not), can't=20 he simply submit an If header
  = production such=20 as:

If: <http://www.foo.bar/resource1>=20 (<locktoken:a-write-lock-token>)(Not=20 <locktoken:a-write-lock-token>))

?

------=_NextPart_000_002D_01C26F36.3B96C950-- From w3c-dist-auth-request@w3.org Wed Oct 9 00:09:41 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA08915 for ; Wed, 9 Oct 2002 00:09:41 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g993roi07941; Tue, 8 Oct 2002 23:53:50 -0400 (EDT) Resent-Date: Tue, 8 Oct 2002 23:53:50 -0400 (EDT) Resent-Message-Id: <200210090353.g993roi07941@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g993rnB07915 for ; Tue, 8 Oct 2002 23:53:49 -0400 (EDT) Received: from mail.ipicorp.com ([209.208.199.81]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA29522 for ; Tue, 8 Oct 2002 23:53:48 -0400 From: "Seth Osher" To: "Webdav WG" Date: Tue, 8 Oct 2002 23:53:42 -0400 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0000_01C26F25.EEA2B970" In-Reply-To: Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6803 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0000_01C26F25.EEA2B970 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: Interop issue: Proposal for fixing lock token provisionFor example a long running folder copy, move or delete. If the operation takes long enough that locks might expire during the operation, then the semantic might not even be really enforceable. Particularly, it servers is incapable of checking the locks in advance, or to do so might be expensive from a time perspective (say an operation on a optical-archive, where the full set of resources is only known on the media). In these cases you want the copy or move to perform "as much work as possible" so you just want to provide a list of all your current tokens. A second example is where a server provides multiple views of the same data. A client may not know for certain what resources it has locked and are going to participate in a copy, move or delete operation. Rather than fully enumerating the set of resources to be operated on, presenting "all-my-tokens" would be useful, if not critical. A third case is where a user wants the operation to succeed, even if etags for the locked resources have changed (perhaps a shared-write has updated the resource, changing its etag). In this case, we want to present the lock, and don't want to worry about the etag. It might even have be deleted by the shared-write lock so the token is no longer valid. Perhaps it is possible to construct an If: header that handles these cases, but a shorthand that avoids recursive introspection on the server would be useful, particularly in low-bandwidth environments. - Seth Osher -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke Sent: Tuesday, October 08, 2002 7:50 PM To: Clemm, Geoff; 'Webdav WG' Subject: RE: Interop issue: Proposal for fixing lock token provision Obviously I agree with Geoff. I'd like to underline that I'm *really* interested to understand why a client would *ever* want a request to succeed if a lock which is supposed to be present unexpectedly disappeared. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff Sent: Tuesday, October 08, 2002 11:18 PM To: 'Webdav WG' Subject: RE: Interop issue: Proposal for fixing lock token provision Julian makes several good points. One is that we need to address the If header length problem in 2518bis in any case. Even if we did provide a separate header that allowed invalid lock tokens, we still need to use the If header when we want to check for a list of valid lock tokens, or when we want to check for a list of etags. Another good point is that we don't have to argue about whether a client should be allowed to submit invalid lock tokens, because once the If header length problem is addressed (which we have to do anyway), then the "If: ()(Not )" provides this functionality without defining a header with new semantics. In an earlier message in this thread, the following points were raised as being problems with the "If:...Not..." approach: PROBLEM #1: Servers may not support the OR, and the NOT, correctly, because most clients don't currently use this. This solution HAS NOT been proven, it is only theoretical. It might not work. It will work against all existing servers that are correctly implemented and that don't have an If header length problem, unlike the "new header" approach, which is guaranteed to fail against all existing servers. If the servers are going to be updated, updating them to correctly implement existing semantics seems like a sensible approach to take, especially when the existing semantics are a "logical or" and a "logical not", built-in operators in most programming languages. PROBLEM #2: What if multiple locks are required (e.g. moving a collection that has multiple locked resources? What if the URLs are long? The IF header becomes very long and may be truncated by some proxies. E.g. If: ( NOT ) ( NOT ) ( NOT ) This is the If header length problem. Once we fix the If header problem (which we have to do anyway), there no longer is a need for a new header to get this functionality. PROBLEM #3: Uck, this is really complicated. While it's useful to know that a client can do this with some existing servers, provided they handle it correctly, surely we can do this in a simpler mechanism that is less prone to interoperability problems. A simple header that allows the client to supply lock tokens to use is semantically equivalent to the above example, but shorter, simpler, and easier to implement. Also it can be split across multiple lines. Use-Lock-Tokens: , Use-Lock-Tokens: Computer programs are really good at spitting out the same string twice, surrounded by some constant characters. Given the verbosity of XML, and the fact that the Internet is used to stream video, cutting down the number of characters required to identify lock tokens does not strike me as a high priority task. And since any client that wants to interoperate with an existing server has to be able to generate the If form of the request anyway, this is no simplification for an interoperable client that has to be able to generate both forms of the request. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Some thoughts: - it doesn't make sense to raise the header length problem as argument in favor of adding a new header. If the If header length is a problem, it needs to be fixed anyway -- no matter how the other issues are treated - As far as I now understand the client issue (BTW: why aren't the developers of this or these clients not participating in this dicussion??), they want to avoid to re-issue a request that specified a lock token just because the lock went away in the meantime. I *still* don't see why this is a problem -- if the lock was theirs, it's not supposed to go away without reason (such as bad timeout value). If the lock *wasn't* theirs, this is a case of "lock stealing", which certainly doesn't require to be optimized, right? - if a client really really wants the request to succeed either case (lock being present or not), can't he simply submit an If header production such as: If: ()(Not )) ? ------=_NextPart_000_0000_01C26F25.EEA2B970 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Interop issue: Proposal for fixing lock token = provision
For=20 example a long running folder copy, move or delete.
 
If the=20 operation takes long enough that locks might expire
during=20 the operation, then the semantic might not even be
really=20 enforceable. Particularly, it servers is incapable of checking = the
locks=20 in advance, or to do so might be expensive from a time =
perspective (say an operation on a = optical-archive,=20 where the full set
of=20 resources is only known on the media).
 
In=20 these cases you want the copy or move to perform "as much=20 work
as=20 possible" so you just want to provide a list of all your current = tokens. =20
 
A=20 second example is where a server provides multiple views of the=20 same
data.  A client may not know for = certain what=20 resources it has locked
and=20 are going to participate in a copy, = move or delete=20 operation. 
Rather=20 than fully enumerating the set of resources to be = operated on,=20
presenting "all-my-tokens" would be = useful, if not=20 critical.
 
A third case is where a user wants the = operation=20 to succeed, even
if=20 etags for the locked resources have changed (perhaps a=20 shared-write
has=20 updated the resource, changing its etag).  In this case, we want=20 to
present the lock, and don't want to worry = about the=20 etag.  It might even
have=20 be deleted by the shared-write lock so the token is no longer=20 valid.
 
Perhaps it is possible to construct an If: = header that=20 handles these
cases,=20 but a shorthand that avoids recursive introspection on the=20 server
would=20 be useful, particularly in low-bandwidth = environments.
 
- Seth=20 Osher
 
 
-----Original Message-----
From: = w3c-dist-auth-request@w3.org=20 [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian=20 Reschke
Sent: Tuesday, October 08, 2002 7:50 = PM
To: Clemm,=20 Geoff; 'Webdav WG'
Subject: RE: Interop issue: Proposal for = fixing=20 lock token provision

Obviously I agree with Geoff.
 
I'd=20 like to underline that I'm *really* interested to understand why a = client=20 would *ever* want a request to succeed if a lock which is supposed to = be=20 present unexpectedly disappeared.
 
Julian

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

-----Original Message-----
From:=20 w3c-dist-auth-request@w3.org = [mailto:w3c-dist-auth-request@w3.org]On=20 Behalf Of Clemm, Geoff
Sent: Tuesday, October 08, 2002 = 11:18=20 PM
To: 'Webdav WG'
Subject: RE: Interop issue: = Proposal=20 for fixing lock token provision

Julian makes several good points.

One is that we need to address the If header = length problem=20 in 2518bis
in any case.  Even if we = did provide=20 a separate header that allowed
invalid = lock tokens,=20 we still need to use the If header when we want
to=20 check for a list of valid lock tokens, or when we want to check = for=20
a list of etags.

Another good point is that we don't have to argue = about=20 whether a
client should be allowed to = submit invalid=20 lock tokens, because once
the If header = length=20 problem is addressed (which we have to do
anyway),=20 then the "If: <tag> (<token>)(Not <token>)" = provides=20 this
functionality without defining a = header with=20 new semantics.

In an earlier message in this thread, the = following points=20 were raised
as being problems with the=20 "If:...Not..."  approach:

   PROBLEM #1: Servers may not support = the OR, and=20 the NOT, correctly,
   because = most=20 clients don't currently use this. This solution HAS NOT =
   been proven, it is only theoretical. It might = not=20 work.

It will work against all existing servers that are = correctly
implemented and that don't have = an If=20 header length problem, unlike
the "new = header"=20 approach, which is guaranteed to fail against all
existing servers.  If the servers are going to be=20 updated,
updating them to correctly = implement=20 existing semantics seems
like a sensible = approach to=20 take, especially when the existing
semantics are a=20 "logical or" and a "logical not", built-in operators =
in most programming languages.

   PROBLEM #2: What if multiple locks = are required=20 (e.g. moving a
   collection = that has=20 multiple locked resources? What if the URLs are
   long? The IF header becomes very long and may = be=20 truncated by some
   proxies. = E.g.=20

   If: <http://www.ics.uci.edu/users/f/fielding/index.html>= ;=20
  =20 (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6> =
   NOT=20 <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>) =
   <http://=20 www.ics.uci.edu/users/f/fielding/anotherfile.html> =
  =20 (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf7> =
   NOT=20 <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf7>) =
   <http://=20 www.ics.uci.edu/users/f/fielding/thirdfile.html>
  =20 (<opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8> =
   NOT=20 <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8>) =

This is the If header length problem.  Once = we fix the=20 If header
problem (which we have to do = anyway),=20 there no longer is a need
for a new header = to get=20 this functionality.

   PROBLEM #3: Uck, this is really = complicated.=20 While it's useful to know
   = that a client=20 can do this with some existing servers, provided they =
   handle it correctly, surely we can do this in = a simpler=20 mechanism that
   is less prone = to=20 interoperability problems. A simple header that allows =
   the client to supply lock tokens to use is = semantically=20 equivalent to
   the above = example, but=20 shorter, simpler, and easier to implement. Also
   it can be split across multiple lines. =
   Use-Lock-Tokens:
  =20 <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf6>,=20
  =20 <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf7>=20
   Use-Lock-Tokens:
  =20 <opaquelocktoken:f81d4fae-7dec-11d0-a765-00a0c91e6bf8> =

Computer programs are really good at spitting out = the same=20 string
twice, surrounded by some constant=20 characters.  Given the verbosity of
XML, and=20 the fact that the Internet is used to stream video, cutting =
down the number of characters required to identify lock = tokens=20 does
not strike me as a high priority = task. =20 And since any client that
wants to = interoperate with=20 an existing server has to be able to
generate the If=20 form of the request anyway, this is no simplification =
for an interoperable client that has to be able to generate = both=20 forms
of the request.

Cheers,
Geoff =


-----Original Message-----
From:=20 Julian Reschke [mailto:julian.reschke@gmx.de]=20

Some thoughts:

- it doesn't make sense to raise the header length = problem=20 as argument
  in favor of adding a = new header.=20 If the If header length is a
  = problem, it=20 needs to be fixed anyway -- no matter how the other
  issues are treated

- As far as I now understand the client issue = (BTW: why=20 aren't the
  developers of this or = these=20 clients not participating in this
 =20 dicussion??), they want to avoid to re-issue a request that =
  specified a lock token just because the lock went = away in=20 the
  meantime. I *still* don't see = why this is=20 a problem -- if the lock
  was = theirs, it's not=20 supposed to go away without reason (such as bad
  timeout value). If the lock *wasn't* theirs, this is = a case of=20 "lock
  stealing", which certainly = doesn't=20 require to be optimized, right?

- if a client really really wants the request to = succeed=20 either case
  (lock being present or = not),=20 can't he simply submit an If header
  = production such as:

If: <http://www.foo.bar/resource1>=20 (<locktoken:a-write-lock-token>)(Not=20 <locktoken:a-write-lock-token>))

? =

------=_NextPart_000_0000_01C26F25.EEA2B970-- From w3c-dist-auth-request@w3.org Wed Oct 9 02:57:01 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id CAA05533 for ; Wed, 9 Oct 2002 02:57:01 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g996hDi27542; Wed, 9 Oct 2002 02:43:13 -0400 (EDT) Resent-Date: Wed, 9 Oct 2002 02:43:13 -0400 (EDT) Resent-Message-Id: <200210090643.g996hDi27542@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g996hBB27512 for ; Wed, 9 Oct 2002 02:43:11 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id CAA26214 for ; Wed, 9 Oct 2002 02:43:11 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id XAA01721 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Tue, 8 Oct 2002 23:43:09 -0700 Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by sunbelt.seagull.net (8.9.3) with ESMTP id XAA01705 sender obsfucated@us.ibm.com; Tue, 8 Oct 2002 23:43:07 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g996gaxw058712; Wed, 9 Oct 2002 02:42:36 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g996gZtN020948; Wed, 9 Oct 2002 02:42:35 -0400 To: "Clemm, Geoff" Cc: "'Webdav WG'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Jason Crawford Message-ID: Date: Wed, 9 Oct 2002 02:42:28 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0|September 26, 2002) at 10/09/2002 02:42:34, Serialize complete at 10/09/2002 02:42:34 Content-Type: text/plain; charset="us-ascii" Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6804 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: > And ALL tag list productions would be evaluated, so that even if > the server didn't think it was relevant, it still would be checked. > So for example I can do a GET on a resource with an IF: header and > the IF: header would be checked despite the server thinking it is > unnecessary to check for locks on a GET request. Does this sound > fine? > > If a server knows that no condition specifiable in an If can cause a > GET to fail, then it can skip the If check. But if it is not > absolutely sure, then yes, it has to check the If header. I don't understand that answer. It sounds like you're saying that it's up to the server to decide what clauses should be checked. Could you explain more? > And the client is required to submit a tag list for every > URL/resource that the server thinks is relevant in order to submit > the token. And we're going to have to define what URL's are > relevant. > > Whether we can define what URLs are relevant will depend somewhat on > whether we can get server consensus on that question. We may need to > have a few "MAY depend" clauses. But optimally, we can avoid that > and make everything a MUST. OK. Sounds right to me. > So for a situation where a token needs to be submitted to allow a > protected URL from being broken (lock destroyed), the root URL of > the lock in question needs to be submitted. > > Yes. (I assume you meant "to be broken" rather than "from being broken"). Yes, that's what I meant. > And in a situation where a token is needed to allow a write locked > resource to be modified, the URL of the root of that resource needs > to be specified. > > Yes. We have been discussing whether to make a special case for the > UNLOCK request, but this may end up being decided more on > interoperability grounds (i.e. if existing servers require the > request-URL to be the lock-root, then for interoperability, we should > at least advise clients that they should use the lock-root for > interoperability). BTW... I meant the URL of the root of the *lock*. :-) Sounds fair enough. We aren't using the If: header of UNLOCK now anyway and this discussion is about the If: header. > > And what is "modifying"? A PUT/PROPPATCH to an ordinary > resouce modifies it. > > Yes, in this case, I think we can clearly state that only the > lock on the resource specified by the request-URL must be > submitted. The request URL? I guess that's okay. I had actually proposed the root of the lock rather than the request URL. I think lower in this note you also said it should be the root of the lock. > Also operations that add or remove children > of a collection are considered to modify the collection. > > To add a child, you would have to submit tokens for any locks > on the collection. To remove a child you would have to submit > tokens for any locks on the collection, any locks on the child > being removed, and if the child is a collection, any locks on > any member of the child collection. Sounds right. > The client is free to test any other resources it wants to test > beyond the one's the server requires. > > Yes. Okay, but you should clarify what you said near the top of this note because it sounded to me like you said the server might not evaluate the assertions for some resources specified in the If: header. > We need a spec'ing of what tag list entries are sufficient to be > considered a submission. That has to deal with NOT and any other > expression constructs we might come up with. > > I think it is simplest to just state that the appearance of the lock > token anywhere in the tagged list for the resource is sufficient. And what do we have to say anything about NOT in an IF: header or does that work out? > Also, in the case of 2518-style DELETE where lots of bindings get > destoryed and they probably get destroyed bottom up, I'd think it > would be best (or at least equal) in some server implementations if > the URL you specified for the submisssion was the one that got > destoryed last. > > This raises a good (although tangential) point. > The BIND protocol "clarifies" the 2518 DELETE semantics, to > state that it is the "mappings" to all the members that are > removed by the DELETE of a collection, not the bindings. > I believe this clarification should appear in 2518bis. You might want to say more about this in a newly named thread. It will be lost in this thread. :-) (I'd start the thread but I don't want to misstate what you just tried to say. ) > > But even if some (misguided :-) server did destroy all the > bindings, the last one destroyed will be the lock-root, so > I think we're OK here to require that the lock-root be the > tag for the submitted token. Okay... but I think a few paragraphs ago you suggested it be on the request URI. Do you want to alter that statement when you reply? ------------------------------------------ Phone: 914-784-7569 From w3c-dist-auth-request@w3.org Wed Oct 9 04:54:10 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA07538 for ; Wed, 9 Oct 2002 04:54:10 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g998eT822644; Wed, 9 Oct 2002 04:40:29 -0400 (EDT) Resent-Date: Wed, 9 Oct 2002 04:40:29 -0400 (EDT) Resent-Message-Id: <200210090840.g998eT822644@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g998eSB22618 for ; Wed, 9 Oct 2002 04:40:28 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA21862 for ; Wed, 9 Oct 2002 04:40:28 -0400 Received: (qmail 30703 invoked by uid 0); 9 Oct 2002 08:40:06 -0000 Received: from p3ee24718.dip.t-dialin.net (HELO lisa) (62.226.71.24) by mail.gmx.net (mp002-rz3) with SMTP; 9 Oct 2002 08:40:06 -0000 From: "Julian Reschke" To: "Seth Osher" , "Webdav WG" Date: Wed, 9 Oct 2002 10:40:00 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6805 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Seth Osher > Sent: Wednesday, October 09, 2002 5:54 AM > To: Webdav WG > Subject: RE: Interop issue: Proposal for fixing lock token provision > > > For example a long running folder copy, move or delete. > > If the operation takes long enough that locks might expire > during the operation, then the semantic might not even be > really enforceable. Particularly, it servers is incapable of checking the > locks in advance, or to do so might be expensive from a time > perspective (say an operation on a optical-archive, where the full set > of resources is only known on the media). ...in which case I'd say that the locks should have had a longer timeout in the first place. Why bother locking, if you're unsure that the timeout is long enough to protect the subsequent request? > In these cases you want the copy or move to perform "as much work > as possible" so you just want to provide a list of all your > current tokens. Really? Again -- if it's irrelevant whether the lock is still there, why was it made in the first place? > A second example is where a server provides multiple views of the same > data. A client may not know for certain what resources it has locked > and are going to participate in a copy, move or delete operation. > Rather than fully enumerating the set of resources to be operated on, > presenting "all-my-tokens" would be useful, if not critical. I don't understand this scenario. Could you please define what a "view" technically is on your system? Is it an additional binding to the same resource? Every lock that the client made has been made on a particular request URI -- and that's the URI that needs to be submitted alongside with the lock token (in the If header). > A third case is where a user wants the operation to succeed, even > if etags for the locked resources have changed (perhaps a shared-write > has updated the resource, changing its etag). In this case, we want to > present the lock, and don't want to worry about the etag. It might even Why do you submit the etag if you don't want it to be enforced? > have be deleted by the shared-write lock so the token is no longer valid. Why would the resource be deleted if you still have a shared-lock on it? > Perhaps it is possible to construct an If: header that handles these > cases, but a shorthand that avoids recursive introspection on the server > would be useful, particularly in low-bandwidth environments. As shown in yesterday's mail, it is possible. It's just syntactically different. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Oct 9 05:50:15 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA08173 for ; Wed, 9 Oct 2002 05:50:14 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g999aTV02401; Wed, 9 Oct 2002 05:36:29 -0400 (EDT) Resent-Date: Wed, 9 Oct 2002 05:36:29 -0400 (EDT) Resent-Message-Id: <200210090936.g999aTV02401@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g999aSB02375 for ; Wed, 9 Oct 2002 05:36:28 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA04007 for ; Wed, 9 Oct 2002 05:36:27 -0400 Received: (qmail 25312 invoked by uid 0); 9 Oct 2002 09:35:56 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp016-rz3) with SMTP; 9 Oct 2002 09:35:56 -0000 From: "Julian Reschke" To: "Webdav WG" Date: Wed, 9 Oct 2002 11:35:54 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Subject: Datatypes for WebDAV properties Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6806 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, a new version of our proposal for datatype handling for WebDAV properties is available at [1] and [2]. In addition to the marshalling of type information, it now also covers - marshalling of "protected" flag (signals the user client not to allow editing of this property) - marshalling of "hidden" flag (signals the user client not to display this property) - displaynames for properties At this point, it would be interesting to receive feedback from developers of generic WebDAV clients (such as KCura or Xythos). Julian [1] [2] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Oct 9 07:23:33 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10155 for ; Wed, 9 Oct 2002 07:23:33 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g99BHAE13011; Wed, 9 Oct 2002 07:17:10 -0400 (EDT) Resent-Date: Wed, 9 Oct 2002 07:17:10 -0400 (EDT) Resent-Message-Id: <200210091117.g99BHAE13011@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g99BH8B12985 for ; Wed, 9 Oct 2002 07:17:08 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA26810 for ; Wed, 9 Oct 2002 07:17:04 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA10026; Wed, 9 Oct 2002 07:14:57 -0400 (EDT) Message-Id: <200210091114.HAA10026@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: Wed, 09 Oct 2002 07:14:57 -0400 Subject: I-D ACTION:draft-ietf-webdav-bind-00.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6807 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : Binding Extensions to WebDAV Author(s) : G. Clemm, J. Crawford Filename : draft-ietf-webdav-bind-00.txt Pages : 18 Date : 2002-10-8 This specification defines bindings, and the BIND method for creating multiple bindings to the same resource. Creating a new binding to a resource causes at least one new URI to be mapped to that resource. Servers are required to insure the integrity of any bindings that they allow to be created. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-bind-00.txt To remove yourself from the IETF Announcement list, send a message to ietf-announce-request with the word unsubscribe in the body of the message. Internet-Drafts are also available by anonymous FTP. Login with the username "anonymous" and a password of your e-mail address. After logging in, type "cd internet-drafts" and then "get draft-ietf-webdav-bind-00.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-bind-00.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: <2002-10-8154108.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-bind-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-bind-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-8154108.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Wed Oct 9 08:28:11 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA12593 for ; Wed, 9 Oct 2002 08:28:10 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g99CTIV27241; Wed, 9 Oct 2002 08:29:18 -0400 (EDT) Resent-Date: Wed, 9 Oct 2002 08:29:18 -0400 (EDT) Resent-Message-Id: <200210091229.g99CTIV27241@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g99CTHB27212 for ; Wed, 9 Oct 2002 08:29:17 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA13869 for ; Wed, 9 Oct 2002 08:29:17 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 09 Oct 2002 08:18:06 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Wed, 9 Oct 2002 08:28:45 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Wed, 9 Oct 2002 08:28:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26F8F.660BA1C0" Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6808 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26F8F.660BA1C0 Content-Type: text/plain From: Jason Crawford [mailto:nn683849@smallcue.com] > And ALL tag list productions would be evaluated, so that even > if the server didn't think it was relevant, it still would be > checked. So for example I can do a GET on a resource with an > IF: header and the IF: header would be checked despite the > server thinking it is unnecessary to check for locks on a GET > request. Does this sound fine? > > If a server knows that no condition specifiable in an If can > cause a GET to fail, then it can skip the If check. But if it is > not absolutely sure, then yes, it has to check the If header. I don't understand that answer. It sounds like you're saying that it's up to the server to decide what clauses should be checked. Could you explain more? My answer was poorly worded. I meant to say that if the server can tell just by scanning the If header that it doesn't apply to the GET, then it can skip the If header. For example, if the If is a tagged list, and the tag did not identify the request-URL, since a GET only applies to the request-URL, it can ignore that If header. > And what is "modifying"? A PUT/PROPPATCH to an ordinary > resouce modifies it. > > Yes, in this case, I think we can clearly state that only the > lock on the resource specified by the request-URL must be > submitted. The request URL? I guess that's okay. I had actually proposed the root of the lock rather than the request URL. I think lower in this note you also said it should be the root of the lock. Parsing problem (:-). I meant: "the lock on (the resource specified by the request-URL) must be submitted", not "(the lock on the resource) specified by the request-URL must be submitted". So yes, to address some interoperability problems that have been reported, the proposal is to require that the tag in the If header be the lock-root of the lock. > The client is free to test any other resources it wants to test > beyond the one's the server requires. > > Yes. Okay, but you should clarify what you said near the top of this note because it sounded to me like you said the server might not evaluate the assertions for some resources specified in the If: header. I meant that it might be sufficient for the server to just parse the If: header, and not actually evaluate them against any resources. > We need a spec'ing of what tag list entries are sufficient to > be considered a submission. That has to deal with NOT and any > other expression constructs we might come up with. > > I think it is simplest to just state that the appearance of the > lock token anywhere in the tagged list for the resource is > sufficient. And what do we have to say anything about NOT in an IF: header or does that work out? I could go either way, but I'd probably be inclined to not say anything special about the NOT. This means that putting a NOT around a lock token is guaranteed to fail (i.e. because either it is locked with that token, so the NOT fails, or it is not locked with that token, so it is an invalid lock token, and it fails). Alternatively, we could say that it is only a submission of the lock token if it does not appear in a NOT, but all that buys the client is the ability to have a request succeed only if the resource is not locked by a particular lock token, which seems like a pretty pointless semantics to support. But I'm happy to do it either way. > This raises a good (although tangential) point. > The BIND protocol "clarifies" the 2518 DELETE semantics, to > state that it is the "mappings" to all the members that are > removed by the DELETE of a collection, not the bindings. > I believe this clarification should appear in 2518bis. You might want to say more about this in a newly named thread. It will be lost in this thread. :-) (I'd start the thread but I don't want to misstate what you just tried to say. ) Good point. Will do. > But even if some (misguided :-) server did destroy all the > bindings, the last one destroyed will be the lock-root, so > I think we're OK here to require that the lock-root be the > tag for the submitted token. Okay... but I think a few paragraphs ago you suggested it be on the request URI. Do you want to alter that statement when you reply? I'll keep the statement but clarify the parsing of the earlier paragraph (:-). Cheers, Geoff ------_=_NextPart_001_01C26F8F.660BA1C0 Content-Type: text/html RE: Interop issue: Proposal for fixing lock token provision

   From: Jason Crawford [mailto:nn683849@smallcue.com]

   >    And ALL tag list productions would be evaluated, so that even
   >    if the server didn't think it was relevant, it still would be
   >    checked.  So for example I can do a GET on a resource with an
   >    IF: header and the IF: header would be checked despite the
   >    server thinking it is unnecessary to check for locks on a GET
   >    request.  Does this sound fine?
   >
   > If a server knows that no condition specifiable in an If can
   > cause a GET to fail, then it can skip the If check.  But if it is
   > not absolutely sure, then yes, it has to check the If header.

   I don't understand that answer.  It sounds like you're saying
   that it's up to the server to decide what clauses should be
   checked.   Could you explain more?

My answer was poorly worded.  I meant to say that if the server can
tell just by scanning the If header that it doesn't apply to the GET,
then it can skip the If header.  For example, if the If is a tagged
list, and the tag did not identify the request-URL, since a GET only
applies to the request-URL, it can ignore that If header.

   >    And what is "modifying"? A PUT/PROPPATCH to an ordinary
   >    resouce modifies it.
   >
   > Yes, in this case, I think we can clearly state that only the
   > lock on the resource specified by the request-URL must be
   > submitted.

   The request URL?  I guess that's okay.  I had actually proposed the
   root of the lock rather than the request URL.  I think lower in
   this note you also said it should be the root of the lock.

Parsing problem (:-).  I meant: "the lock on (the resource specified by
the request-URL) must be submitted", not "(the lock on the resource)
specified by the request-URL must be submitted".

So yes, to address some interoperability problems that have been
reported, the proposal is to require that the tag in the If header be
the lock-root of the lock.

   >    The client is free to test any other resources it wants to test
   >    beyond the one's the server requires.
   >
   > Yes.

   Okay, but you should clarify what you said near the top of this
   note because it sounded to me like you said the server might not
   evaluate the assertions for some resources specified in the If:
   header.

I meant that it might be sufficient for the server to just
parse the If: header, and not actually evaluate them against
any resources.

   >    We need a spec'ing of what tag list entries are sufficient to
   >    be considered a submission.  That has to deal with NOT and any
   >    other expression constructs we might come up with.
   >
   > I think it is simplest to just state that the appearance of the
   > lock token anywhere in the tagged list for the resource is
   > sufficient.

   And what do we have to say anything about  NOT in an IF: header
   or does that work out?

I could go either way, but I'd probably be inclined to not say
anything special about the NOT.  This means that putting a NOT
around a lock token is guaranteed to fail (i.e. because either it
is locked with that token, so the NOT fails, or it is not locked
with that token, so it is an invalid lock token, and it fails).
Alternatively, we could say that it is only a submission of the
lock token if it does not appear in a NOT, but all that buys the
client is the ability to have a request succeed only if the
resource is not locked by a particular lock token, which seems
like a pretty pointless semantics to support.  But I'm happy
to do it either way.

   > This raises a good (although tangential) point.
   > The BIND protocol "clarifies" the 2518 DELETE semantics, to
   > state that it is the "mappings" to all the members that are
   > removed by the DELETE of a collection, not the bindings.
   > I believe this clarification should appear in 2518bis.

   You might want to say more about this in a newly named thread.  It
   will be lost in this thread. :-) (I'd start the thread but I don't
   want to misstate what you just tried to say. )

Good point.  Will do.

   > But even if some (misguided :-) server did destroy all the
   > bindings, the last one destroyed will be the lock-root, so
   > I think we're OK here to require that the lock-root be the
   > tag for the submitted token.

   Okay... but I think a few paragraphs ago you suggested it
   be on the request URI.  Do you want to alter that statement
   when you reply?

I'll keep the statement but clarify the parsing of the earlier
paragraph (:-).

Cheers,
Geoff

------_=_NextPart_001_01C26F8F.660BA1C0-- From w3c-dist-auth-request@w3.org Wed Oct 9 12:46:39 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25154 for ; Wed, 9 Oct 2002 12:46:39 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g99GklC04887; Wed, 9 Oct 2002 12:46:47 -0400 (EDT) Resent-Date: Wed, 9 Oct 2002 12:46:47 -0400 (EDT) Resent-Message-Id: <200210091646.g99GklC04887@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g99GkjB04860 for ; Wed, 9 Oct 2002 12:46:45 -0400 (EDT) Received: from gcsu.edu (vir.gcsu.edu [168.16.214.18]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA16306 for ; Wed, 9 Oct 2002 12:46:40 -0400 Received: by gcsu.edu; id MAA19959; Wed, 9 Oct 2002 12:48:51 -0400 (EDT) Received: from gcsu211076.gcsu.edu(168.16.211.76) by vir.gcsu.edu via csmap (V4.1) id srcAAA8JaOXM; Wed, 9 Oct 02 12:48:37 -0400 Mime-Version: 1.0 Message-Id: Date: Wed, 9 Oct 2002 12:44:10 -0400 To: w3c-dist-auth@w3.org From: Frank Lowney Content-Type: text/plain; charset="us-ascii" ; format="flowed" Subject: Enabling WebDAV for home folder web sites Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6809 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Environment: MacOS X 10.2.1 (Apache w/ Mod_DAV) Following the Admin Guide PDF for MacOS X Server 10.2.1, I note that turning on the webserver will enable BOTH a general web site (http://aladdin.gcsu.edu:8080) and web sites for all account holders (http://aladdin.gcsu.edu:8080/~flowney). I am using port 80 in conjunction with QTSS so must use another port for the webserver but that's not relevant to my question. My goal is to enable WebDAV realms for all users and this works fine on the general webserver (Library/Webserver/Documents/ ... ) but apparently not for home directories (Users/flowney/Sites/). When I attempt to set a realm to a home directory, I get an error message as follows: The folder entered for this realm is not within the site's Web folder. Please enter or select another folder that is part of the site's Web folder and try saving again. Is it that WebDAV cannot work within the context of a home folder web site or is it that Apple has decided not to implement WebDAV for user folders at this time? Clearly, the GUI disallows this but could I not manually implement WebDAV for home folder web sites in some way? If so, please point me to any supporting documentation on how to do this. We have a lot of faculty who would very much prefer to use WebDAV in conjunction with Dreamweaver, GoLive and FrontPage 2002. Please CC any replies and thanks in advance for any illumination. -- ===================================================================== Dr. Frank Lowney flowney@mail.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. From w3c-dist-auth-request@w3.org Wed Oct 9 13:59:25 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27565 for ; Wed, 9 Oct 2002 13:59:25 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g99I0B815828; Wed, 9 Oct 2002 14:00:11 -0400 (EDT) Resent-Date: Wed, 9 Oct 2002 14:00:11 -0400 (EDT) Resent-Message-Id: <200210091800.g99I0B815828@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g99I09B15799 for ; Wed, 9 Oct 2002 14:00:09 -0400 (EDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA31934 for ; Wed, 9 Oct 2002 14:00:09 -0400 Received: from xp1700 ([66.229.4.108]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20021009175939.DVNT20316.sccrmhc03.attbi.com@xp1700> for ; Wed, 9 Oct 2002 17:59:39 +0000 Message-ID: <009f01c26fbd$9142a040$6401a8c0@xp1700> From: "Matthew Murphy" To: Date: Wed, 9 Oct 2002 10:59:09 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_009C_01C26F82.E4913B70" X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: Thinking about deploying WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6810 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_009C_01C26F82.E4913B70 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hello, I was wondering if I could get some help. My office has a mac, = and it has several PC's, running Mac OS X.2.1, XP Pro, Win 2K Pro, Win = 98 and FreeBSD I'd like to set up my server on XP Pro, I store highly confidential = information on XP Pro, I have a firewall, and really tight security. My needs are. I send multipage tiff files. Ranging from 20K up to 20MB, = I send anywhere from 1 a day to 100's a day. I'm sick and tired of = errors saying mail boxes are full and my clients calling me and = screaming at me because I havent emailed it to them, even though i = request a reciept when they get the email, 15 emails later they finally = get it and i have 15 reciepts telling me they got it every single time. Someone told me I should try WebDAV instead of a ftpd. Beings I need = each clients information secured from the other. I cant have A even = seeing who B is. I need A and B to each have there own login and = passwords. That way instead of them calling me they can just login and = get there files themselves. If anyone can help me. Thanks Matthew Murphy Cop N Proc 1528 N Williams St Stockton, Ca. 95205 209.271.6639 Fax 209.464.0381 ------=_NextPart_000_009C_01C26F82.E4913B70 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hello, I was wondering if I could get = some help. My=20 office has a mac, and it has several PC's, running Mac OS X.2.1, XP Pro, = Win 2K=20 Pro, Win 98 and FreeBSD
 
I'd like to set up my server on XP Pro, = I store=20 highly confidential information on XP Pro, I have a firewall, and really = tight=20 security.
 
My needs are. I send multipage tiff = files. Ranging=20 from 20K up to 20MB, I send anywhere from 1 a day to 100's a day. I'm = sick and=20 tired of errors saying mail boxes are full and my clients calling me and = screaming at me because I havent emailed it to them, even though i = request a=20 reciept when they get the email, 15 emails later they finally get it and = i have=20 15 reciepts telling me they got it every single time.
 
Someone told me I should try WebDAV = instead of a=20 ftpd. Beings I need each clients information secured from the other. I = cant have=20 A even seeing who B is. I need A and B to each have there own login and=20 passwords. That way instead of them calling me they can just login and = get there=20 files themselves. If anyone can help me. Thanks
 
 
Matthew Murphy
Cop N Proc
1528 N = Williams=20 St
Stockton, Ca. 95205
209.271.6639 Fax=20 209.464.0381
------=_NextPart_000_009C_01C26F82.E4913B70-- From w3c-dist-auth-request@w3.org Wed Oct 9 14:54:42 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29662 for ; Wed, 9 Oct 2002 14:54:41 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g99ItDQ24624; Wed, 9 Oct 2002 14:55:13 -0400 (EDT) Resent-Date: Wed, 9 Oct 2002 14:55:13 -0400 (EDT) Resent-Message-Id: <200210091855.g99ItDQ24624@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g99ItCB24596 for ; Wed, 9 Oct 2002 14:55:12 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA11710 for ; Wed, 9 Oct 2002 14:55:11 -0400 Received: (qmail 31615 invoked by uid 0); 9 Oct 2002 18:54:40 -0000 Received: from p3ee24767.dip.t-dialin.net (HELO lisa) (62.226.71.103) by mail.gmx.net (mp020-rz3) with SMTP; 9 Oct 2002 18:54:40 -0000 From: "Julian Reschke" To: Date: Wed, 9 Oct 2002 20:54:38 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200210091114.HAA10026@ietf.org> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: BIND method response codes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6811 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, similarily to the PUT method, I'd like to be able to distinguish between - a new BIND was created (201) - an existing BIND was overwritten (200) Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Oct 9 16:19:01 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03075 for ; Wed, 9 Oct 2002 16:19:01 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g99KKIR05393; Wed, 9 Oct 2002 16:20:18 -0400 (EDT) Resent-Date: Wed, 9 Oct 2002 16:20:18 -0400 (EDT) Resent-Message-Id: <200210092020.g99KKIR05393@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g99KKGB05363 for ; Wed, 9 Oct 2002 16:20:16 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA29333 for ; Wed, 9 Oct 2002 16:20:16 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 09 Oct 2002 16:09:05 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Wed, 9 Oct 2002 16:19:45 -0400 Message-ID: From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Wed, 9 Oct 2002 16:19:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26FD1.308EFB40" Subject: RE: BIND method response codes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6812 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26FD1.308EFB40 Content-Type: text/plain; charset="iso-8859-1" A problem with 200/201, is that 201 means "a new resource was created", but a BIND never creates a new resource, but just creates a new binding to an existing resource. We could of course still use 200/201, but I'd be concerned that it would be misleading. If a client has asked that BIND overwrite any existing binding for that segment, why would it care whether or not there was already a binding there? Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Wednesday, October 09, 2002 2:55 PM To: w3c-dist-auth@w3.org Subject: BIND method response codes Hi, similarily to the PUT method, I'd like to be able to distinguish between - a new BIND was created (201) - an existing BIND was overwritten (200) Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 ------_=_NextPart_001_01C26FD1.308EFB40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: BIND method response codes

A problem with 200/201, is that 201 means "a new = resource
was created", but a BIND never creates a new = resource, but
just creates a new binding to an existing = resource.  We could
of course still use 200/201, but I'd be concerned = that it would
be misleading.

If a client has asked that BIND overwrite any = existing binding
for that segment, why would it care whether or not = there was
already a binding there?

Cheers,
Geoff


-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]<= /FONT>
Sent: Wednesday, October 09, 2002 2:55 PM
To: w3c-dist-auth@w3.org
Subject: BIND method response codes



Hi,

similarily to the PUT method, I'd like to be able to = distinguish between

- a new BIND was created (201)
- an existing BIND was overwritten (200)


Julian

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

------_=_NextPart_001_01C26FD1.308EFB40-- From w3c-dist-auth-request@w3.org Wed Oct 9 16:50:02 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03971 for ; Wed, 9 Oct 2002 16:50:01 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g99Kong07604; Wed, 9 Oct 2002 16:50:49 -0400 (EDT) Resent-Date: Wed, 9 Oct 2002 16:50:49 -0400 (EDT) Resent-Message-Id: <200210092050.g99Kong07604@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g99KomB07578 for ; Wed, 9 Oct 2002 16:50:48 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA03106 for ; Wed, 9 Oct 2002 16:50:48 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 09 Oct 2002 16:39:36 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Wed, 9 Oct 2002 16:50:17 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Wed, 9 Oct 2002 16:50:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C26FD5.77FDE3C0" Subject: RE: GULP (version 4) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6813 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C26FD5.77FDE3C0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] > > Geoff, you say in GULP4: > > > > - If a request would modify the content, dead properties, or > > bindings of a locked resource, the request MUST fail unless the > > lock-token for that lock is specified in the request. > > > > What are the "bindings of a locked resource"? The complete=A0 > > DAV:parent-set of the resource or a specific binding or the > > bindings of the resource=A0 and all its parents? > The bindings of a resource identify its internal members (and > therefore only a collection has bindings). The bindings "to" a > resource would be identified in the DAV:parent-set.=A0 I should > reword this to make sure nobody is confused ... any suggestions? How about: "If a request would modify the content, dead properties, or the set of bindings to children of a locked resource, the request MUST fail unless the lock-token for that lock is specified in the request." Or how about: "If a request would modify the content or dead properties of a locked resource, or would modify the bindings of a locked collection, the request MUST fail unless the lock-token for that lock is specified in the request." Cheers, Geoff ------_=_NextPart_001_01C26FD5.77FDE3C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: GULP (version 4)

   From: Stefan Eissing [mailto:stefan.eissing@green= bytes.de]

   > > Geoff, you say in = GULP4:
   > >
   > > - If a request would modify = the content, dead properties, or
   > > bindings of a locked = resource, the request MUST fail unless the
   > > lock-token for that lock is = specified in the request.
   > >
   > > What are the "bindings = of a locked resource"? The complete=A0
   > > DAV:parent-set of the = resource or a specific binding or the
   > > bindings of the resource=A0 = and all its parents?

   > The bindings of a resource identify = its internal members (and
   > therefore only a collection has = bindings).  The bindings "to" a
   > resource would be identified in = the DAV:parent-set.=A0 I should
   > reword this to make sure nobody is = confused ... any suggestions?

   How about:

   "If a request would modify the = content, dead properties, or the set
   of bindings to children of a locked = resource, the request MUST fail
   unless the lock-token for that lock is = specified in the request."

Or how about:

"If a request would modify the content or dead = properties of a locked
resource, or would modify the bindings of a locked = collection, the
request MUST fail unless the lock-token for that = lock is specified in
the request."

Cheers,
Geoff

------_=_NextPart_001_01C26FD5.77FDE3C0-- From w3c-dist-auth-request@w3.org Wed Oct 9 20:22:29 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08440 for ; Wed, 9 Oct 2002 20:22:29 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9A0Nlu00929; Wed, 9 Oct 2002 20:23:47 -0400 (EDT) Resent-Date: Wed, 9 Oct 2002 20:23:47 -0400 (EDT) Resent-Message-Id: <200210100023.g9A0Nlu00929@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9A0NkB00898 for ; Wed, 9 Oct 2002 20:23:46 -0400 (EDT) Received: from cats.ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA06891 for ; Wed, 9 Oct 2002 20:23:45 -0400 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by cats.ucsc.edu (8.10.1/8.10.1) with SMTP id g9A06x512680 for ; Wed, 9 Oct 2002 17:06:59 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 9 Oct 2002 17:04:10 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-UCSC-CATS-MailScanner: Found to be clean Subject: FW: Digest auth the wrong solution? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6814 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. I have added to the accept2 list. - Jim -----Original Message----- From: Daniel Stone [mailto:dstone@trinity.unimelb.edu.au] Sent: Wednesday, October 09, 2002 4:46 PM To: w3c-dist-auth@w3.org Subject: [Moderator Action] Digest auth the wrong solution? Hi all, I'm writing MoulDAVia, a Python-based WebDAV server. Basically, it has interchangable backends for both authentication and retreiving/storing files/properties; the end aim is to have the configurable per-location (e.g. a shared area with no authentication and a home directory-based area with LDAP auth, depending on path, etc). Anyway, I've hit a bit of a snag trying to stay RFC-compliant: digest authentication. As far as I can tell, there's no real way to do digest authentication, without knowing the password server-side. For the LDAP backend, which will be the default (the default mode of operation will be home directories until I get the whole per-location thing sorted), authentication is performed by attempting to bind to LDAP as the given user/password pair, and seeing if that succeeds or not. At no stage does the server know the *real* password, only what the client gives it. Which, as far as I can tell, leaves me in a bit of a quandary trying to implement digest authentication. Is there any real way to do this without knowing the passwords server-side? I'm beginning to think that requiring digest auth is the wrong solution, and requiring a method of authentication stronger than base64 (e.g. digest or SSL), would be better. SSL isn't an issue to provide, but digest - now that's a snag. :) Any ideas? -d -- Daniel Stone Developer, Trinity College, University of Melbourne From w3c-dist-auth-request@w3.org Wed Oct 9 21:05:37 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA09282 for ; Wed, 9 Oct 2002 21:05:36 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9A16nm06375; Wed, 9 Oct 2002 21:06:49 -0400 (EDT) Resent-Date: Wed, 9 Oct 2002 21:06:49 -0400 (EDT) Resent-Message-Id: <200210100106.g9A16nm06375@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9A16lB06349 for ; Wed, 9 Oct 2002 21:06:48 -0400 (EDT) Received: from nwkea-mail-2.sun.com (nwkea-mail-2.sun.com [192.18.42.14]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA15330 for ; Wed, 9 Oct 2002 21:06:47 -0400 Received: from dm-usca15-11.red.iplanet.com (host-185-56-18-192.iplanet.com [192.18.56.185] (may be forged)) by nwkea-mail-2.sun.com (8.9.3+Sun/8.9.3) with ESMTP id SAA22790; Wed, 9 Oct 2002 18:06:17 -0700 (PDT) Received: from ms-usca15-11.red.iplanet.com (ms-usca15-11.red.iplanet.com [192.18.56.153]) by dm-usca15-11.red.iplanet.com (8.10.2+Sun/8.10.2/IPLANET,v1.1) with ESMTP id g9A15u929018; Wed, 9 Oct 2002 18:05:57 -0700 (PDT) Received: from sun.com (h-192-18-177-216.red.iplanet.com [192.18.177.216]) by ipost.red.iplanet.com (iPlanet Messaging Server 5.2 (built Feb 21 2002)) with ESMTP id <0H3Q00GU8R2GT4@ipost.red.iplanet.com>; Wed, 09 Oct 2002 18:06:16 -0700 (PDT) Date: Wed, 09 Oct 2002 18:05:47 -0700 From: Murthy Chintalapati To: Jim Whitehead Cc: WebDAV Message-id: <3DA4D26B.4040808@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.4.1) Gecko/20020508 Netscape6/6.2.3 References: Subject: Re: FW: Digest auth the wrong solution? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6815 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Daniel, You are absolutely right in that the server-side need to know the real password to be able to the digest auth. However, this doesn't necessarily mean that the passwords are stored in clear text. For instance, LDAP servers (the Sun ONE Directory Server that I know for sure) support the notion of reversable password plugin -- where by server uses symmetric key algorithm (such as DES) to store password in an encrypted form. regards. -cvr Jim Whitehead wrote: >Accidentally caught by the spam filter. I have added > to the accept2 list. > >- Jim > >-----Original Message----- >From: Daniel Stone [mailto:dstone@trinity.unimelb.edu.au] >Sent: Wednesday, October 09, 2002 4:46 PM >To: w3c-dist-auth@w3.org >Subject: [Moderator Action] Digest auth the wrong solution? > >Hi all, >I'm writing MoulDAVia, a Python-based WebDAV server. Basically, it has >interchangable backends for both authentication and retreiving/storing >files/properties; the end aim is to have the configurable per-location >(e.g. a shared area with no authentication and a home directory-based area >with LDAP auth, depending on path, etc). >Anyway, I've hit a bit of a snag trying to stay RFC-compliant: digest >authentication. >As far as I can tell, there's no real way to do digest authentication, >without knowing the password server-side. For the LDAP backend, which will >be the default (the default mode of operation will be home directories >until I get the whole per-location thing sorted), authentication is >performed by attempting to bind to LDAP as the given user/password pair, >and seeing if that succeeds or not. At no stage does the server know the >*real* password, only what the client gives it. >Which, as far as I can tell, leaves me in a bit of a quandary trying to >implement digest authentication. Is there any real way to do this without >knowing the passwords server-side? >I'm beginning to think that requiring digest auth is the wrong solution, >and requiring a method of authentication stronger than base64 (e.g. digest >or SSL), would be better. SSL isn't an issue to provide, but digest - now >that's a snag. :) >Any ideas? >-d > >-- >Daniel Stone >Developer, Trinity College, University of Melbourne > From w3c-dist-auth-request@w3.org Thu Oct 10 00:33:03 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA13142 for ; Thu, 10 Oct 2002 00:33:03 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9A4RpH27373; Thu, 10 Oct 2002 00:27:51 -0400 (EDT) Resent-Date: Thu, 10 Oct 2002 00:27:51 -0400 (EDT) Resent-Message-Id: <200210100427.g9A4RpH27373@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9A4RnB27347 for ; Thu, 10 Oct 2002 00:27:49 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA18987 for ; Thu, 10 Oct 2002 00:27:49 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id VAA00724 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Wed, 9 Oct 2002 21:27:30 -0700 Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by sunbelt.seagull.net (8.9.3) with ESMTP id VAA00701 sender obsfucated@us.ibm.com; Wed, 9 Oct 2002 21:27:28 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9A4QrDn136568; Thu, 10 Oct 2002 00:26:53 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9A4QqRT121748; Thu, 10 Oct 2002 00:26:52 -0400 To: "Clemm, Geoff" Cc: "'Webdav WG'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Jason Crawford Message-ID: Date: Thu, 10 Oct 2002 00:26:46 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0|September 26, 2002) at 10/10/2002 00:26:51, Serialize complete at 10/10/2002 00:26:51 Content-Type: text/plain; charset="us-ascii" Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6816 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Wednesday, 10/09/2002 at 08:28 AST, "Clemm, Geoff" wrote: > From: Jason Crawford [mailto:nn683849@smallcue.com] > > > And ALL tag list productions would be evaluated, so that even > > if the server didn't think it was relevant, it still would be > > checked. So for example I can do a GET on a resource with an > > IF: header and the IF: header would be checked despite the > > server thinking it is unnecessary to check for locks on a GET > > request. Does this sound fine? > > > > If a server knows that no condition specifiable in an If can > > cause a GET to fail, then it can skip the If check. But if it is > > not absolutely sure, then yes, it has to check the If header. > > I don't understand that answer. It sounds like you're saying > that it's up to the server to decide what clauses should be > checked. Could you explain more? > > My answer was poorly worded. I meant to say that if the server can > tell just by scanning the If header that it doesn't apply to the GET, > then it can skip the If header. For example, if the If is a tagged > list, and the tag did not identify the request-URL, since a GET only > applies to the request-URL, it can ignore that If header. Wow. I wouldn't have expected this as an answer. It sounds like the purpose of the If: header becomes for the server to verify what it wants to. That seems like a signficant change in philosophy from 2518. 2518 seems to spend a lot of time talking about If: header and all it's details but not about how it's used to submit lock tokens. It's use for lock token submission seems to simply be an afterthought. It even says the following when it begins to talk about the If; header. The If header is intended to have similar functionality to the If- Match header defined in section 14.24 of [RFC2616]. However the If header is intended for use with any URI which represents state information, referred to as a state token, about a resource as well as ETags. A typical example of a state token is a lock token, and lock tokens are the only state tokens defined in this specification. And I've taken this opening statement, and the fact that it never talks about lock token submission in this section, to mean that the primary purpose of the If: header was for a client to verify various aspects of server state (like If-Match) before doing an operation. I'm not saying that you're wrong to want to specify what you just have, but it seems to me that you are suggesting is a change in purpose/philosophy because the client can no longer really fully use it for verifying server state. I want to bring attention to that to be sure that's what you really want. I'm going to stray a bit and say a bit about 2518 and say what I've said above in a different way... Above I outlined what I thought the *primary* purpose of the If: header was in 2518. But there are stray comments in the 2518 that make the If; header's purpose confused. We've fixed one of those in 2518bis. But 2518bis still has the statement that the server will only check the assertions on the URL's it chooses. With that statement, the semantics and purpose of the If; header gets confusing. It's like the server saying, "you can ask me questions, but I'll only answer the one's I want, and I'll only cooperate with your request if you ask all the questions I want you to ask me." It (2518) just doesn't make sense. It makes it hard for us and readers to figure out how to fill in gaps in the spec. There is no guiding philosophy and purpose. It's difficult to build on that. The proposal by Lisa and the interop folks, which I tried to clearly guess at and describe, does fix this. It provides a clear purpose and semantics for the headers. And it does a good job achieving compatibility. As an alternative to that proposal, I think it's possible that you can achieve much of that by saying that the client can submit assertions against whatever resource it likes in the If: header, and the server will evaluate all of the If: header, and the server does also require that the client ask a few particular questions against particular resources. It's not as simple as Lisa's solution, but it's at least an improvement over 2518. But if you say that the server only evalutes some of what the client submits, then you might as well abandon what appeared to be the primary purpose of the If: header in 2518. If we do that, we should be aware the we're doing that and make sure we're comfortable with that. > > > And what is "modifying"? A PUT/PROPPATCH to an ordinary > > resouce modifies it. > > > > Yes, in this case, I think we can clearly state that only the > > lock on the resource specified by the request-URL must be > > submitted. > > The request URL? I guess that's okay. I had actually proposed the > root of the lock rather than the request URL. I think lower in > this note you also said it should be the root of the lock. > > Parsing problem (:-). I meant: "the lock on (the resource specified by > the request-URL) must be submitted", not "(the lock on the resource) > specified by the request-URL must be submitted". I think you didn't understand my question... A (depth) lock can lock many resources. Which locked resource/URL should be specified when submitting the lock token? You've suggested both (1) the root and (2) the request resource. Another option is to just submit it on the resource whose being locked poses an impediment, but there can be zillions of those in the case of operations like the 2518-style DELETE in the presence of depth locks. That leaves the first two options and I think only (1) can work universally. > I could go either way, but I'd probably be inclined to not say > anything special about the NOT. This means that putting a NOT > around a lock token is guaranteed to fail (i.e. because either it > is locked with that token, so the NOT fails, or it is not locked > with that token, so it is an invalid lock token, and it fails). > Alternatively, we could say that it is only a submission of the > lock token if it does not appear in a NOT, but all that buys the > client is the ability to have a request succeed only if the > resource is not locked by a particular lock token, which seems > like a pretty pointless semantics to support. But I'm happy > to do it either way. I suspect that's the best approach. So I'd say... All of the If; header is evaluated, and the token(s) in question must be "mentioned". And I suspect we need resolve on what resource it should be mentioned. I'm voting tor the resource that is the root of the lock. Am I nutz? :-) J. ------------------------------------------ Phone: 914-784-7569 From w3c-dist-auth-request@w3.org Thu Oct 10 04:04:57 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA25168 for ; Thu, 10 Oct 2002 04:04:57 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9A7S4020956; Thu, 10 Oct 2002 03:28:04 -0400 (EDT) Resent-Date: Thu, 10 Oct 2002 03:28:04 -0400 (EDT) Resent-Message-Id: <200210100728.g9A7S4020956@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9A7RvB20930 for ; Thu, 10 Oct 2002 03:27:57 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA16668 for ; Thu, 10 Oct 2002 03:27:50 -0400 Received: from greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Thu, 10 Oct 2002 09:24:40 +0200 Date: Thu, 10 Oct 2002 09:24:40 +0200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "'Webdav WG'" To: "Clemm, Geoff" From: Stefan Eissing In-Reply-To: Message-Id: <56C20FBC-DC21-11D6-9950-00039384827E@greenbytes.de> X-Mailer: Apple Mail (2.546) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g9A7RvB20930 Subject: Re: GULP (version 4) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6817 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Sounds good. Am Mittwoch, 09.10.02, um 22:50 Uhr (Europe/Berlin) schrieb Clemm, Geoff: >    From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] > >    > > Geoff, you say in GULP4: >    > > >    > > - If a request would modify the content, dead properties, or >    > > bindings of a locked resource, the request MUST fail unless the >    > > lock-token for that lock is specified in the request. >    > > >    > > What are the "bindings of a locked resource"? The complete  >    > > DAV:parent-set of the resource or a specific binding or the >    > > bindings of the resource  and all its parents? > >    > The bindings of a resource identify its internal members (and >    > therefore only a collection has bindings).  The bindings "to" a >    > resource would be identified in the DAV:parent-set.  I should >    > reword this to make sure nobody is confused ... any suggestions? > >    How about: > >    "If a request would modify the content, dead properties, or the set >    of bindings to children of a locked resource, the request MUST fail >    unless the lock-token for that lock is specified in the request." > > Or how about: > > "If a request would modify the content or dead properties of a locked > resource, or would modify the bindings of a locked collection, the > request MUST fail unless the lock-token for that lock is specified in > the request." > > Cheers, > Geoff > From w3c-dist-auth-request@w3.org Thu Oct 10 05:49:19 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26751 for ; Thu, 10 Oct 2002 05:48:07 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9A8JSj01899; Thu, 10 Oct 2002 04:19:28 -0400 (EDT) Resent-Date: Thu, 10 Oct 2002 04:19:28 -0400 (EDT) Resent-Message-Id: <200210100819.g9A8JSj01899@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9A8JRB01869 for ; Thu, 10 Oct 2002 04:19:27 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id EAA27961 for ; Thu, 10 Oct 2002 04:19:27 -0400 Received: from greenbytes.de ([217.5.201.10]) by frink.w3.org (8.11.6+Sun/8.11.6) with SMTP id g9A8JLB01783 for ; Thu, 10 Oct 2002 04:19:21 -0400 (EDT) Received: from greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Thu, 10 Oct 2002 10:05:55 +0200 Date: Thu, 10 Oct 2002 10:05:55 +0200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: w3c-dist-auth@w3.org To: "Clemm, Geoff" From: Stefan Eissing In-Reply-To: Message-Id: <19E1A629-DC27-11D6-9950-00039384827E@greenbytes.de> X-Mailer: Apple Mail (2.546) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g9A8JRB01869 Subject: Re: BIND method response codes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6818 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Maybe it would be more appropriate to reuse the response codes as defined for MOVE in RFC 2518: 201: newly created 204: replaced existing resource etc. //Stefan Am Mittwoch, 09.10.02, um 22:19 Uhr (Europe/Berlin) schrieb Clemm, Geoff: > A problem with 200/201, is that 201 means "a new resource > was created", but a BIND never creates a new resource, but > just creates a new binding to an existing resource.  We could > of course still use 200/201, but I'd be concerned that it would > be misleading. Ohoh. resources, uris and representations. That's www-tag ground we're treating on here. I think one needs at least 8 years experience in HTTP and Apache development to talk about that topic... ;) Anyway: a BIND creates a mapping for an URI to a representation exactly like PUT does. That the representation is not supplied by the client, but reused from another URI, is not relevant. > If a client has asked that BIND overwrite any existing binding > for that segment, why would it care whether or not there was > already a binding there? > > Cheers, > Geoff > > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Wednesday, October 09, 2002 2:55 PM > To: w3c-dist-auth@w3.org > Subject: BIND method response codes > > > > Hi, > > similarily to the PUT method, I'd like to be able to distinguish > between > > - a new BIND was created (201) > - an existing BIND was overwritten (200) > > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Thu Oct 10 05:57:10 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26860 for ; Thu, 10 Oct 2002 05:57:10 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9A9Ihw07051; Thu, 10 Oct 2002 05:18:43 -0400 (EDT) Resent-Date: Thu, 10 Oct 2002 05:18:43 -0400 (EDT) Resent-Message-Id: <200210100918.g9A9Ihw07051@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9A9IcB07025 for ; Thu, 10 Oct 2002 05:18:38 -0400 (EDT) Received: from w3c2.w3.org (w3c2.w3.org [193.51.208.66]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA03439 for ; Thu, 10 Oct 2002 05:17:58 -0400 Received: from mail.gmx.net (sproxy.gmx.de [213.165.64.20]) by w3c2.w3.org (Postfix) with SMTP id 74B8514094 for ; Thu, 10 Oct 2002 10:39:06 +0200 (MEST) Received: (qmail 9010 invoked by uid 0); 10 Oct 2002 08:37:05 -0000 Received: from p3ee24767.dip.t-dialin.net (HELO lisa) (62.226.71.103) by mail.gmx.net (mp001-rz3) with SMTP; 10 Oct 2002 08:37:05 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , Date: Thu, 10 Oct 2002 10:37:01 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: BIND method response codes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6820 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Clemm, Geoff > Sent: Wednesday, October 09, 2002 10:20 PM > To: w3c-dist-auth@w3.org > Subject: RE: BIND method response codes > > > A problem with 200/201, is that 201 means "a new resource > was created", but a BIND never creates a new resource, but > just creates a new binding to an existing resource. We could That's correct with the WebDAV/BIND definition of a resource, but not with the generic (RFC2396) one -- the binding itself has a unique identifier (and thus has identity), therefore *can* be considered a resource. > of course still use 200/201, but I'd be concerned that it would > be misleading. > If a client has asked that BIND overwrite any existing binding > for that segment, why would it care whether or not there was > already a binding there? Well, why would it care in the case of PUT or MOVE? I'm just looking for consistency with other methods. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Oct 10 05:58:26 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA26906 for ; Thu, 10 Oct 2002 05:58:13 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9A8PMo02592; Thu, 10 Oct 2002 04:25:22 -0400 (EDT) Resent-Date: Thu, 10 Oct 2002 04:25:22 -0400 (EDT) Resent-Message-Id: <200210100825.g9A8PMo02592@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9A8PLB02566 for ; Thu, 10 Oct 2002 04:25:21 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA28732 for ; Thu, 10 Oct 2002 04:25:17 -0400 Received: (qmail 28169 invoked by uid 0); 10 Oct 2002 08:24:45 -0000 Received: from p3ee24767.dip.t-dialin.net (HELO lisa) (62.226.71.103) by mail.gmx.net (mp016-rz3) with SMTP; 10 Oct 2002 08:24:45 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'Webdav WG'" Date: Thu, 10 Oct 2002 10:24:41 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: GULP (version 4) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6819 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Clemm, Geoff > Sent: Wednesday, October 09, 2002 10:50 PM > To: 'Webdav WG' > Subject: RE: GULP (version 4) > > > From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] > > > Geoff, you say in GULP4: > > > > > > - If a request would modify the content, dead properties, or > > > bindings of a locked resource, the request MUST fail unless the > > > lock-token for that lock is specified in the request. > > > > > > What are the "bindings of a locked resource"? The complete > > > DAV:parent-set of the resource or a specific binding or the > > > bindings of the resource and all its parents? > > The bindings of a resource identify its internal members (and > > therefore only a collection has bindings). The bindings "to" a > > resource would be identified in the DAV:parent-set. I should > > reword this to make sure nobody is confused ... any suggestions? > How about: > "If a request would modify the content, dead properties, or the set > of bindings to children of a locked resource, the request MUST fail > unless the lock-token for that lock is specified in the request." > Or how about: > "If a request would modify the content or dead properties of a locked > resource, or would modify the bindings of a locked collection, the > request MUST fail unless the lock-token for that lock is specified in > the request." One more thing that comes to mind are locks on the resource. Are we missing something else? Proposal: split into two sentences, one defining the "state" of a resource, the other saying: "If a request would modify the state of a resource, the request MUST fail unless the lock-token for that lock is specified in the request." -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Oct 10 06:32:12 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA27435 for ; Thu, 10 Oct 2002 06:32:11 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9A9dx512254; Thu, 10 Oct 2002 05:39:59 -0400 (EDT) Resent-Date: Thu, 10 Oct 2002 05:39:59 -0400 (EDT) Resent-Message-Id: <200210100939.g9A9dx512254@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9A9dwB12228 for ; Thu, 10 Oct 2002 05:39:58 -0400 (EDT) Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id FAA08706 for ; Thu, 10 Oct 2002 05:39:58 -0400 Received: from epistula.trinity.unimelb.edu.au (epistula.trinity.unimelb.edu.au [203.28.240.16]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9A9dsB12224 for ; Thu, 10 Oct 2002 05:39:57 -0400 (EDT) Received: by epistula.trinity.unimelb.edu.au (Postfix, from userid 105) id 0834A1801D; Thu, 10 Oct 2002 19:34:29 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by epistula.trinity.unimelb.edu.au (Postfix) with ESMTP id B21471801E; Thu, 10 Oct 2002 19:34:27 +1000 (EST) Received: from roger.trinity.unimelb.edu.au (roger.trinity.unimelb.edu.au [203.28.240.3]) by epistula.trinity.unimelb.edu.au (Postfix) with ESMTP id 1D9741801D; Thu, 10 Oct 2002 19:34:24 +1000 (EST) Received: by roger.trinity.unimelb.edu.au (Postfix, from userid 1280) id 7120D17F04; Thu, 10 Oct 2002 19:34:23 +1000 (EST) Date: Thu, 10 Oct 2002 19:34:23 +1000 From: Daniel Stone To: Murthy Chintalapati Cc: Jim Whitehead , WebDAV Message-ID: <20021010093423.GG22562@trinity.unimelb.edu.au> References: <3DA4D26B.4040808@sun.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3DA4D26B.4040808@sun.com> User-Agent: Mutt/1.3.28i X-GnuPG-Key: 3CED7EFD X-Message-Flag: Magic 8-Ball say Outlook Not Good. X-Reading-Headers-Makes-You: Hyper-l33t X-Virus-Scanned: by AMaViS snapshot-20020316 Subject: Re: FW: Digest auth the wrong solution? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6821 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Wed, Oct 09, 2002 at 06:05:47PM -0700, Brother Murthy Chintalapati preached da werd, yo: > You are absolutely right in that the server-side need to know the real > password to be able to the digest auth. However, this doesn't > necessarily mean that the passwords are stored in clear text. For > instance, LDAP servers (the Sun ONE Directory Server that I know for > sure) support the notion of reversable password plugin -- where by > server uses symmetric key algorithm (such as DES) to store password in > an encrypted form. Hmm ... does OpenLDAP support this? That's what we're using, and we would expect most implementations of MoulDAVia to be in capital-F-Free/capital-O-Open environments, so I'm not too keen to hobble it by restricting LDAP access to those with proprietary servers ... thanks for the heads-up! > Jim Whitehead wrote: > >Accidentally caught by the spam filter. I have added > > to the accept2 list. Cheers. :) -- Daniel Stone Developer, Trinity College, University of Melbourne From w3c-dist-auth-request@w3.org Thu Oct 10 10:54:30 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA06777 for ; Thu, 10 Oct 2002 10:54:30 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9AEsuQ06799; Thu, 10 Oct 2002 10:54:56 -0400 (EDT) Resent-Date: Thu, 10 Oct 2002 10:54:56 -0400 (EDT) Resent-Message-Id: <200210101454.g9AEsuQ06799@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9AEssB06769 for ; Thu, 10 Oct 2002 10:54:54 -0400 (EDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA13837 for ; Thu, 10 Oct 2002 10:54:54 -0400 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g9AEsqs24118 for ; Thu, 10 Oct 2002 07:54:53 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id ; Thu, 10 Oct 2002 07:54:43 -0700 Received: from apple.com (luthji.apple.com [17.202.43.76]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id g9AEsq315722; Thu, 10 Oct 2002 07:54:52 -0700 (PDT) Date: Thu, 10 Oct 2002 07:54:52 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: w3c-dist-auth@w3.org To: Frank Lowney From: Jim Luther In-Reply-To: Message-Id: <3B2214B8-DC60-11D6-906E-0003934B6A22@apple.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Subject: Re: Enabling WebDAV for home folder web sites Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6822 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Frank, I suggest you take this question to the Apple Support discussions area at . The links you want to follow from there to get to the BBS where the Mac OS X Server's web services are discussed are: Mac OS X Server Mac OS X Server 10.2 Web Services - Jim On Wednesday, October 9, 2002, at 09:44 AM, Frank Lowney wrote: > > Environment: MacOS X 10.2.1 (Apache w/ Mod_DAV) > > Following the Admin Guide PDF for MacOS X Server 10.2.1, I note that > turning on the webserver will enable BOTH a general web site > (http://aladdin.gcsu.edu:8080) and web sites for all account holders > (http://aladdin.gcsu.edu:8080/~flowney). I am using port 80 in > conjunction with QTSS so must use another port for the webserver but > that's not relevant to my question. > > My goal is to enable WebDAV realms for all users and this works fine > on the general webserver (Library/Webserver/Documents/ ... ) but > apparently not for home directories (Users/flowney/Sites/). When I > attempt to set a realm to a home directory, I get an error message as > follows: > > The folder entered for this realm is not within the site's Web folder. > Please enter or select another folder that is part of the site's Web > folder and try saving again. > > Is it that WebDAV cannot work within the context of a home folder web > site or is it that Apple has decided not to implement WebDAV for user > folders at this time? Clearly, the GUI disallows this but could I not > manually implement WebDAV for home folder web sites in some way? If > so, please point me to any supporting documentation on how to do this. > We have a lot of faculty who would very much prefer to use WebDAV in > conjunction with Dreamweaver, GoLive and FrontPage 2002. > > Please CC any replies and thanks in advance for any illumination. > -- > ===================================================================== > Dr. Frank Lowney flowney@mail.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. > From w3c-dist-auth-request@w3.org Thu Oct 10 11:05:30 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA07123 for ; Thu, 10 Oct 2002 11:05:30 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9AF6mB09283; Thu, 10 Oct 2002 11:06:48 -0400 (EDT) Resent-Date: Thu, 10 Oct 2002 11:06:48 -0400 (EDT) Resent-Message-Id: <200210101506.g9AF6mB09283@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9AF6kB09228 for ; Thu, 10 Oct 2002 11:06:46 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA16561 for ; Thu, 10 Oct 2002 11:06:45 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id IAA13160 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Thu, 10 Oct 2002 08:06:43 -0700 Received: from e4.ny.us.ibm.com (e4.ny.us.ibm.com [32.97.182.104]) by sunbelt.seagull.net (8.9.3) with ESMTP id IAA13135 sender obsfucated@us.ibm.com; Thu, 10 Oct 2002 08:06:41 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e4.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9AF69c9009148; Thu, 10 Oct 2002 11:06:09 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9AF67Kf117074; Thu, 10 Oct 2002 11:06:07 -0400 To: Stefan Eissing Cc: "Clemm, Geoff" , w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Jason Crawford Message-ID: Date: Thu, 10 Oct 2002 11:06:04 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0|September 26, 2002) at 10/10/2002 11:06:06, Serialize complete at 10/10/2002 11:06:06 Content-Type: text/plain; charset="us-ascii" Subject: Re: BIND method response codes, new header? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6823 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Or.... how about.... (get your tomatoes ready...) A new header, whereby the client can submit assertions that it wants the server to test. These tests need not prevent an operation from occuring, but they can inform the user of the situation just before (or after) the operation occured. It could test for things like etags and locks. And in this case it could test if a resource existed. This header would not be bind specific. And it need not go in the spec now. But if we are anticipating something like this, we wouldn't need to spend time defining a new status code now or even debating which one to use. J. ------------------------------------------ Phone: 914-784-7569 From w3c-dist-auth-request@w3.org Thu Oct 10 11:45:53 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA08727 for ; Thu, 10 Oct 2002 11:45:52 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9AFl6121990; Thu, 10 Oct 2002 11:47:06 -0400 (EDT) Resent-Date: Thu, 10 Oct 2002 11:47:06 -0400 (EDT) Resent-Message-Id: <200210101547.g9AFl6121990@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9AFl5B21960 for ; Thu, 10 Oct 2002 11:47:05 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA27353 for ; Thu, 10 Oct 2002 11:47:04 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 10 Oct 2002 11:35:51 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Thu, 10 Oct 2002 11:46:34 -0400 Message-ID: From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Thu, 10 Oct 2002 11:46:33 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27074.35600E40" Subject: RE: BIND method response codes, new header? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6824 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27074.35600E40 Content-Type: text/plain I'm still looking for a compelling reason to do anything about this at all. So far, the only argument is for "consistency". Since these are different methods with different semantics, I find "consistency" arguments less compelling than simplicity arguments (i.e. it simpler to just always return 200 if there are no errors). So what is the compelling use case for a client knowing whether the new binding is replacing an old binding or not? Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:nn683849@smallcue.com] Sent: Thursday, October 10, 2002 11:06 AM To: Stefan Eissing Cc: Clemm, Geoff; w3c-dist-auth@w3.org Subject: Re: BIND method response codes, new header? Or.... how about.... (get your tomatoes ready...) A new header, whereby the client can submit assertions that it wants the server to test. These tests need not prevent an operation from occuring, but they can inform the user of the situation just before (or after) the operation occured. It could test for things like etags and locks. And in this case it could test if a resource existed. This header would not be bind specific. And it need not go in the spec now. But if we are anticipating something like this, we wouldn't need to spend time defining a new status code now or even debating which one to use. J. ------------------------------------------ Phone: 914-784-7569 ------_=_NextPart_001_01C27074.35600E40 Content-Type: text/html RE: BIND method response codes, new header?

I'm still looking for a compelling reason to do anything
about this at all.  So far, the only argument is for
"consistency".  Since these are different methods with
different semantics, I find "consistency" arguments less
compelling than simplicity arguments (i.e. it simpler to
just always return 200 if there are no errors).

So what is the compelling use case for a client knowing
whether the new binding is replacing an old binding or not?

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:nn683849@smallcue.com]
Sent: Thursday, October 10, 2002 11:06 AM
To: Stefan Eissing
Cc: Clemm, Geoff; w3c-dist-auth@w3.org
Subject: Re: BIND method response codes, new header?


Or.... how about....  (get your tomatoes ready...)

A new header, whereby the client can submit
assertions that it wants the server to test.  These tests
need not prevent an operation from occuring, but
they can inform the user of the situation just before
(or after) the operation occured.   It could test for things
like etags and locks.  And in this case it could test if
a resource existed.

This header would not be bind specific.  And it
need not go in the spec now.  But if we are anticipating
something like this, we wouldn't need to spend time defining
a new status code now or even debating which one to use.

J.

------------------------------------------
Phone: 914-784-7569

------_=_NextPart_001_01C27074.35600E40-- From w3c-dist-auth-request@w3.org Thu Oct 10 11:56:33 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA10744 for ; Thu, 10 Oct 2002 11:56:33 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9AFvvb23259; Thu, 10 Oct 2002 11:57:57 -0400 (EDT) Resent-Date: Thu, 10 Oct 2002 11:57:57 -0400 (EDT) Resent-Message-Id: <200210101557.g9AFvvb23259@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9AFvuB23233 for ; Thu, 10 Oct 2002 11:57:56 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id LAA30029 for ; Thu, 10 Oct 2002 11:57:55 -0400 Received: (qmail 15657 invoked by uid 0); 10 Oct 2002 15:57:24 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp008-rz3) with SMTP; 10 Oct 2002 15:57:24 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , Date: Thu, 10 Oct 2002 17:57:21 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: BIND method response codes, new header? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6825 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Geoff, > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Clemm, Geoff > Sent: Thursday, October 10, 2002 5:47 PM > To: w3c-dist-auth@w3.org > Subject: RE: BIND method response codes, new header? > > > I'm still looking for a compelling reason to do anything > about this at all. So far, the only argument is for > "consistency". Since these are different methods with > different semantics, I find "consistency" arguments less > compelling than simplicity arguments (i.e. it simpler to > just always return 200 if there are no errors). > So what is the compelling use case for a client knowing > whether the new binding is replacing an old binding or not? > Cheers, > Geoff as you said, it's a tradeoff between consistency and simplicity. Making BIND simpler may make implementations and clients actually more complicated, because they will have to use different code for similar purposes. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Oct 10 12:46:42 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14530 for ; Thu, 10 Oct 2002 12:46:42 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9AGlPK03642; Thu, 10 Oct 2002 12:47:25 -0400 (EDT) Resent-Date: Thu, 10 Oct 2002 12:47:25 -0400 (EDT) Resent-Message-Id: <200210101647.g9AGlPK03642@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9AGlOB03616 for ; Thu, 10 Oct 2002 12:47:24 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA11729 for ; Thu, 10 Oct 2002 12:47:22 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 10 Oct 2002 12:36:08 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Thu, 10 Oct 2002 12:46:50 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Thu, 10 Oct 2002 12:46:50 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2707C.A13FBE00" Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6826 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2707C.A13FBE00 Content-Type: text/plain From: Jason Crawford [mailto:nn683849@smallcue.com] On Wednesday, 10/09/2002 at 08:28 AST, "Clemm, Geoff" wrote: > if the server can tell just by scanning the If header that it > doesn't apply to the GET, then it can skip the If header. For > example, if the If is a tagged list, and the tag did not identify > the request-URL, since a GET only applies to the request-URL, it > can ignore that If header. Wow. I wouldn't have expected this as an answer. It sounds like the purpose of the If: header becomes for the server to verify what it wants to. That's certainly not what I meant to imply. Let's try a specific scenario. A client does a "GET /coll/foo.html", with a tagged list If header. My server scans the If header, and determines that none of the tags match "/coll/foo.html". By section 9.4.2: "If none of the resource productions match the current resource then the header MUST be ignored." So my server correctly ignores the If header, i.e. it ignores what 2518 requires it to ignore. There is of course some wiggle room around the term "match the current resource", but I believe that "the current resource" and "match" is reasonably clear for the GET method (i.e. write locks are ignored, and the only resource being read is the one identified by the request-URL). That seems like a signficant change in philosophy from 2518. 2518 seems to spend a lot of time talking about If: header and all it's details but not about how it's used to submit lock tokens. It's use for lock token submission seems to simply be an afterthought. I completely agree that we need to clarify exactly how the If header should be used to submit lock tokens (in particular, to maximize interoperability with existing servers). It even says the following when it begins to talk about the If; header. The If header is intended to have similar functionality to the If-Match header defined in section 14.24 of [RFC2616]. However the If header is intended for use with any URI which represents state information, referred to as a state token, about a resource as well as ETags. A typical example of a state token is a lock token, and lock tokens are the only state tokens defined in this specification. And I've taken this opening statement, and the fact that it never talks about lock token submission in this section, to mean that the primary purpose of the If: header was for a client to verify various aspects of server state (like If-Match) before doing an operation. I'm not saying that you're wrong to want to specify what you just have, but it seems to me that you are suggesting is a change in purpose/philosophy because the client can no longer really fully use it for verifying server state. I want to bring attention to that to be sure that's what you really want. Did my example above clarify that I was just talking about the defined semantics of a tagged list? I'm going to stray a bit and say a bit about 2518 and say what I've said above in a different way... Above I outlined what I thought the *primary* purpose of the If: header was in 2518. But there are stray comments in the 2518 that make the If; header's purpose confused. We've fixed one of those in 2518bis. But 2518bis still has the statement that the server will only check the assertions on the URL's it chooses. With that statement, the semantics and purpose of the If; header gets confusing. It's like the server saying, "you can ask me questions, but I'll only answer the one's I want, and I'll only cooperate with your request if you ask all the questions I want you to ask me." It (2518) just doesn't make sense. It makes it hard for us and readers to figure out how to fill in gaps in the spec. There is no guiding philosophy and purpose. It's difficult to build on that. This probably should go in a separate thread, since I believe what you are questioning is the fact that 2518 says that in a tagged list production, the conditions are only checked if the request is "applied to" the resource identified by the tag. This means we need to carefully define what resources a given method "applies" to, so that we can get consistent behavior across different servers. One simple alternative is to declare that "all methods apply to all resources" (for the purpose of the If header), which then would force a server to verify every tag list in the If header. Just for interests sake, would any existing clients break if a server implemented the If header in this way? Does anyone have an important use case where they want to submit If header entries that they expect/want the server to ignore if the current request is not "applied" to those resources? The proposal by Lisa and the interop folks, which I tried to clearly guess at and describe, does fix this. It provides a clear purpose and semantics for the headers. And it does a good job achieving compatibility. If by "fix this", you mean clarify how to submit tokens, I agree, but I think that it is easy to clarify this without creating a new header. And I totally disagree that the new-header proposal does a good job of achieving compatibility (with existing clients and servers). As an alternative to that proposal, I think it's possible that you can achieve much of that by saying that the client can submit assertions against whatever resource it likes in the If: header, and the server will evaluate all of the If: header, and the server does also require that the client ask a few particular questions against particular resources. It's not as simple as Lisa's solution, but it's at least an improvement over 2518. Note that this does change the If header semantics defined in 2518 (which pretty clearly imply that a request does not "apply" to all resources), but if this semantic change is not a problem for existing clients and servers (e.g. if they don't really use the tagged list form of the If anyway), then it is fine with me. But if you say that the server only evalutes some of what the client submits, then you might as well abandon what appeared to be the primary purpose of the If: header in 2518. If we do that, we should be aware the we're doing that and make sure we're comfortable with that. It appeared to me that the section 9.4.2 of 2518 intended that a server only apply a subset (possibly empty) of the If header, namely, the subset for the resources to which the method is being "applied". So I'd turn it around, and say, if we are changing the semantics of the If header so that it applies to all tagged lists, then we need to be aware that we are doing that and comfortable with doing so. > > And what is "modifying"? A PUT/PROPPATCH to an ordinary > > resouce modifies it. > > > > Yes, in this case, I think we can clearly state that only the > > lock on the resource specified by the request-URL must be > > submitted. > > The request URL? I guess that's okay. I had actually > proposed the root of the lock rather than the request URL. I > think lower in this note you also said it should be the root > of the lock. > > Parsing problem (:-). I meant: "the lock on (the resource > specified by the request-URL) must be submitted", not "(the lock > on the resource) specified by the request-URL must be submitted". I think you didn't understand my question... A (depth) lock can lock many resources. Agreed. Which locked resource/URL should be specified when submitting the lock token? You submit the lock-root of the lock as the tag. You've suggested both (1) the root and (2) the request resource. No, I've only suggested (1). The sequence is: - find the resource that the request-URL is mapped to. - find the lock on that resource. - submit the lock token with the lock-root of that lock as the tag. So there are two URL's here ... the request-URL, and the lock-root URL. With a depth lock, the two URLs can be different. Note that there is a somewhat subtle point here; namely, for If header purposes, one of the resources to which an "update" operation "applies" will always be the resource identified by the lock-root of any lock on the resource. Another option is to just submit it on the resource whose being locked poses an impediment, but there can be zillions of those in the case of operations like the 2518-style DELETE in the presence of depth locks. That leaves the first two options and I think only (1) can work universally. I agree. > I could go either way, but I'd probably be inclined to not say > anything special about the NOT. This means that putting a NOT > around a lock token is guaranteed to fail (i.e. because either it > is locked with that token, so the NOT fails, or it is not locked > with that token, so it is an invalid lock token, and it fails). > Alternatively, we could say that it is only a submission of the > lock token if it does not appear in a NOT, but all that buys the > client is the ability to have a request succeed only if the > resource is not locked by a particular lock token, which seems > like a pretty pointless semantics to support. But I'm happy > to do it either way. I suspect that's the best approach. So I'd say... All of the If; header is evaluated, and the token(s) in question must be "mentioned". And I suspect we need resolve on what resource it should be mentioned. I'm voting for the resource that is the root of the lock. It sounds like we are in violent agreement that the lock-root URL should be the tag for the If clause that mentions a particular lock token. It also sounds like we still need to spend some time discussing what resources a method "applies" to, for If header purposes. Cheers, Geoff ------_=_NextPart_001_01C2707C.A13FBE00 Content-Type: text/html RE: Interop issue: Proposal for fixing lock token provision

   From: Jason Crawford [mailto:nn683849@smallcue.com]

   On Wednesday, 10/09/2002 at 08:28 AST, "Clemm, Geoff" wrote:

   > if the server can tell just by scanning the If header that it
   > doesn't apply to the GET, then it can skip the If header.  For
   > example, if the If is a tagged list, and the tag did not identify
   > the request-URL, since a GET only applies to the request-URL, it
   > can ignore that If header.

   Wow.  I wouldn't have expected this as an answer.  It sounds like
   the purpose of the If: header becomes for the server to verify what
   it wants to.

That's certainly not what I meant to imply.  Let's try a
specific scenario.  A client does a "GET /coll/foo.html", with
a tagged list If header.  My server scans the If header,
and determines that none of the tags match "/coll/foo.html".
By section 9.4.2:

"If none of the resource productions match the current resource then
the header MUST be ignored."

So my server correctly ignores the If header, i.e. it ignores what
2518 requires it to ignore.  There is of course some wiggle room
around the term "match the current resource", but I believe that "the
current resource" and "match" is reasonably clear for the GET method
(i.e. write locks are ignored, and the only resource being read is the
one identified by the request-URL).

   That seems like a signficant change in philosophy from 2518.  2518
   seems to spend a lot of time talking about If: header and all it's
   details but not about how it's used to submit lock tokens.  It's
   use for lock token submission seems to simply be an afterthought.

I completely agree that we need to clarify exactly how the If header
should be used to submit lock tokens (in particular, to maximize
interoperability with existing servers).

   It even says the following when it begins to talk about the If;
   header.

      The If header is intended to have similar functionality to the
      If-Match header defined in section 14.24 of [RFC2616].  However
      the If header is intended for use with any URI which represents
      state information, referred to as a state token, about a
      resource as well as ETags.  A typical example of a state token
      is a lock token, and lock tokens are the only state tokens
      defined in this specification.

   And I've taken this opening statement, and the fact that it never
   talks about lock token submission in this section, to mean that the
   primary purpose of the If: header was for a client to verify
   various aspects of server state (like If-Match) before doing an
   operation.  I'm not saying that you're wrong to want to specify
   what you just have, but it seems to me that you are suggesting is a
   change in purpose/philosophy because the client can no longer
   really fully use it for verifying server state.  I want to bring
   attention to that to be sure that's what you really want.

Did my example above clarify that I was just talking about the
defined semantics of a tagged list?

   I'm going to stray a bit and say a bit about 2518 and say what I've
   said above in a different way...

   Above I outlined what I thought the *primary* purpose of the If:
   header was in 2518.   But there are stray comments in the 2518
   that make the If; header's purpose confused.  We've fixed one
   of those in 2518bis.  But 2518bis still has the statement that the
   server will only check the assertions on the URL's it chooses.
   With that statement, the semantics and purpose of the If; header
   gets confusing.   It's like the server saying,
      "you can ask me questions, but I'll only answer the one's
      I want, and I'll only cooperate with your request if you ask
      all the questions I want you to ask me."
   It (2518) just doesn't make sense.  It makes it hard for us
   and readers to figure out how to fill in gaps in the spec.  There
   is no guiding philosophy and purpose.  It's difficult to build on
   that.

This probably should go in a separate thread, since I believe what you
are questioning is the fact that 2518 says that in a tagged list
production, the conditions are only checked if the request is "applied
to" the resource identified by the tag.  This means we need to
carefully define what resources a given method "applies" to, so that
we can get consistent behavior across different servers.

One simple alternative is to declare that "all methods apply to
all resources" (for the purpose of the If header), which then
would force a server to verify every tag list in the If header.

Just for interests sake, would any existing clients break if
a server implemented the If header in this way?  Does anyone
have an important use case where they want to submit If header
entries that they expect/want the server to ignore if the
current request is not "applied" to those resources?

   The proposal by Lisa and the interop folks, which I tried to
   clearly guess at and describe, does fix this.  It provides
   a clear purpose and semantics for the headers.  And it does
   a good job achieving compatibility.

If by "fix this", you mean clarify how to submit tokens, I agree, but
I think that it is easy to clarify this without creating a new header.
And I totally disagree that the new-header proposal does a good job of
achieving compatibility (with existing clients and servers).

   As an alternative to that proposal, I think it's possible that
   you can achieve much of that by saying that the client can
   submit assertions against whatever resource it likes in
   the If: header, and the server will evaluate all of the If: header,
   and the server does also require that the client ask a few
   particular questions against particular resources.  It's not
   as simple as Lisa's solution, but it's at least an improvement
   over 2518.

Note that this does change the If header semantics defined in 2518
(which pretty clearly imply that a request does not "apply" to all
resources), but if this semantic change is not a problem for existing
clients and servers (e.g. if they don't really use the tagged list
form of the If anyway), then it is fine with me.

   But if you say that the server only evalutes some of what the
   client submits, then you might as well abandon what appeared to be
   the primary purpose of the If: header in 2518.  If we do that, we
   should be aware the we're doing that and make sure we're
   comfortable with that.

It appeared to me that the section 9.4.2 of 2518 intended that a
server only apply a subset (possibly empty) of the If header, namely,
the subset for the resources to which the method is being "applied".
So I'd turn it around, and say, if we are changing the semantics
of the If header so that it applies to all tagged lists, then we
need to be aware that we are doing that and comfortable with doing so.

   >    >    And what is "modifying"? A PUT/PROPPATCH to an ordinary
   >    >    resouce modifies it.
   >    >
   >    > Yes, in this case, I think we can clearly state that only the
   >    > lock on the resource specified by the request-URL must be
   >    > submitted.
   >
   >    The request URL?  I guess that's okay.  I had actually
   >    proposed the root of the lock rather than the request URL.  I
   >    think lower in this note you also said it should be the root
   >    of the lock.
   >
   > Parsing problem (:-).  I meant: "the lock on (the resource
   > specified by the request-URL) must be submitted", not "(the lock
   > on the resource) specified by the request-URL must be submitted".

   I think you didn't understand my question...

   A (depth) lock can lock many resources.

Agreed.

   Which locked resource/URL
   should be specified when submitting the lock token?

You submit the lock-root of the lock as the tag.

   You've
   suggested both (1) the root and (2) the request resource.

No, I've only suggested (1).  The sequence is:
- find the resource that the request-URL is mapped to.
- find the lock on that resource.
- submit the lock token with the lock-root of that lock as the tag.

So there are two URL's here ... the request-URL, and the
lock-root URL.  With a depth lock, the two URLs can be different.

Note that there is a somewhat subtle point here; namely, for If header
purposes, one of the resources to which an "update" operation
"applies" will always be the resource identified by the lock-root of
any lock on the resource.

   Another option is to just submit it on the resource whose being
   locked poses an impediment, but there can be zillions of those in
   the case of operations like the 2518-style DELETE in the presence
   of depth locks.  That leaves the first two options and I think only
   (1) can work universally.

I agree.

   > I could go either way, but I'd probably be inclined to not say
   > anything special about the NOT.  This means that putting a NOT
   > around a lock token is guaranteed to fail (i.e. because either it
   > is locked with that token, so the NOT fails, or it is not locked
   > with that token, so it is an invalid lock token, and it fails).
   > Alternatively, we could say that it is only a submission of the
   > lock token if it does not appear in a NOT, but all that buys the
   > client is the ability to have a request succeed only if the
   > resource is not locked by a particular lock token, which seems
   > like a pretty pointless semantics to support.  But I'm happy
   > to do it either way.

   I suspect that's the best approach.

   So I'd say...

   All of the If; header is evaluated, and the token(s) in question
   must be "mentioned".  And I suspect we need resolve on what
   resource it should be mentioned.  I'm voting for the resource that
   is the root of the lock.

It sounds like we are in violent agreement that the lock-root
URL should be the tag for the If clause that mentions a particular
lock token.  It also sounds like we still need to spend some time
discussing what resources a method "applies" to, for If header
purposes.

Cheers,
Geoff

------_=_NextPart_001_01C2707C.A13FBE00-- From w3c-dist-auth-request@w3.org Thu Oct 10 13:23:30 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16118 for ; Thu, 10 Oct 2002 13:23:30 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9AHOjh10686; Thu, 10 Oct 2002 13:24:45 -0400 (EDT) Resent-Date: Thu, 10 Oct 2002 13:24:45 -0400 (EDT) Resent-Message-Id: <200210101724.g9AHOjh10686@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9AHOgB10573 for ; Thu, 10 Oct 2002 13:24:42 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA22329 for ; Thu, 10 Oct 2002 13:24:42 -0400 Received: (qmail 31636 invoked by uid 0); 10 Oct 2002 17:24:11 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp015-rz3) with SMTP; 10 Oct 2002 17:24:11 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'Clemm, Geoff'" , "'Webdav WG'" Date: Thu, 10 Oct 2002 19:24:07 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <000001c27081$33e6a1c0$b701a8c0@xythoslap> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: GULP (version 4) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6827 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Lisa, please re-read my mail. I was saying that we need to define what the state of a resource is. In particular its - content - internal members (depth 0 lock on collections) - dead properties - locks - *some* live properties (such as DAV:label) -- this is where it'll get hairy, I guess Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > Sent: Thursday, October 10, 2002 7:20 PM > To: 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG' > Subject: RE: GULP (version 4) > > > > > "If a request would modify the state of a resource, the request MUST > fail > > unless the lock-token for that lock is specified in the request." > > This isn't much more specific than the current "is affected by" > language. It leaves it entirely up to the server to decide what > modifying the state of a resource is. Does modifying membership count? > (Is modifying membership blocked by a depth 0 lock?) Does modifying > property values count? > > This is exactly where clients have had problems submitting simple > requests to server implementations that each have a different idea what > resources have state modified by the request. > > lisa > From w3c-dist-auth-request@w3.org Thu Oct 10 14:09:51 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18289 for ; Thu, 10 Oct 2002 14:09:51 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9AIB1917254; Thu, 10 Oct 2002 14:11:01 -0400 (EDT) Resent-Date: Thu, 10 Oct 2002 14:11:01 -0400 (EDT) Resent-Message-Id: <200210101811.g9AIB1917254@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9AIAxB17224 for ; Thu, 10 Oct 2002 14:10:59 -0400 (EDT) Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA32517 for ; Thu, 10 Oct 2002 14:10:59 -0400 Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Thu, 10 Oct 2002 13:19:49 -0400 (Eastern Daylight Time) Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453); Thu, 10 Oct 2002 13:19:49 -0400 Received: from xythoslap ([216.36.77.241]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453); Thu, 10 Oct 2002 13:19:37 -0400 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Clemm, Geoff'" , "'Webdav WG'" Date: Thu, 10 Oct 2002 10:19:33 -0700 Message-ID: <000001c27081$33e6a1c0$b701a8c0@xythoslap> 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.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 10 Oct 2002 17:19:37.0476 (UTC) FILETIME=[35C17C40:01C27081] Subject: RE: GULP (version 4) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6828 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > "If a request would modify the state of a resource, the request MUST fail > unless the lock-token for that lock is specified in the request." This isn't much more specific than the current "is affected by" language. It leaves it entirely up to the server to decide what modifying the state of a resource is. Does modifying membership count? (Is modifying membership blocked by a depth 0 lock?) Does modifying property values count? This is exactly where clients have had problems submitting simple requests to server implementations that each have a different idea what resources have state modified by the request. lisa From w3c-dist-auth-request@w3.org Thu Oct 10 16:40:00 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA23330 for ; Thu, 10 Oct 2002 16:39:59 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9AKf0N10694; Thu, 10 Oct 2002 16:41:00 -0400 (EDT) Resent-Date: Thu, 10 Oct 2002 16:41:00 -0400 (EDT) Resent-Message-Id: <200210102041.g9AKf0N10694@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9AKexB10668 for ; Thu, 10 Oct 2002 16:40:59 -0400 (EDT) Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA03296 for ; Thu, 10 Oct 2002 16:40:58 -0400 Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Thu, 10 Oct 2002 16:40:07 -0400 (Eastern Daylight Time) Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453); Thu, 10 Oct 2002 16:40:06 -0400 Received: from xythoslap ([216.36.77.241]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453); Thu, 10 Oct 2002 16:40:06 -0400 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Clemm, Geoff'" , "'Webdav WG'" Date: Thu, 10 Oct 2002 13:40:02 -0700 Message-ID: <003d01c2709d$359ad0b0$b701a8c0@xythoslap> 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.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 10 Oct 2002 20:40:06.0369 (UTC) FILETIME=[3788E510:01C2709D] Subject: RE: GULP (version 4) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6829 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Yes. I'm saying that even if we define what the state of a resource is, servers will handle things differently and clients will constantly have to reissue requests in order to get the right lock tokens. lisa > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Thursday, October 10, 2002 10:24 AM > To: Lisa Dusseault; 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG' > Subject: RE: GULP (version 4) > > Lisa, > > please re-read my mail. > > I was saying that we need to define what the state of a resource is. > > In particular its > > - content > - internal members (depth 0 lock on collections) > - dead properties > - locks > - *some* live properties (such as DAV:label) -- this is where it'll get > hairy, I guess > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > -----Original Message----- > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > Sent: Thursday, October 10, 2002 7:20 PM > > To: 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG' > > Subject: RE: GULP (version 4) > > > > > > > > > "If a request would modify the state of a resource, the request MUST > > fail > > > unless the lock-token for that lock is specified in the request." > > > > This isn't much more specific than the current "is affected by" > > language. It leaves it entirely up to the server to decide what > > modifying the state of a resource is. Does modifying membership count? > > (Is modifying membership blocked by a depth 0 lock?) Does modifying > > property values count? > > > > This is exactly where clients have had problems submitting simple > > requests to server implementations that each have a different idea what > > resources have state modified by the request. > > > > lisa > > From w3c-dist-auth-request@w3.org Thu Oct 10 17:02:25 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24127 for ; Thu, 10 Oct 2002 17:02:25 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9AL0Ll15464; Thu, 10 Oct 2002 17:00:21 -0400 (EDT) Resent-Date: Thu, 10 Oct 2002 17:00:21 -0400 (EDT) Resent-Message-Id: <200210102100.g9AL0Ll15464@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9AL0LB15438 for ; Thu, 10 Oct 2002 17:00:21 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA07763 for ; Thu, 10 Oct 2002 17:00:21 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 10 Oct 2002 16:49:06 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Thu, 10 Oct 2002 16:59:49 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Thu, 10 Oct 2002 16:59:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2709F.F8943A50" Subject: GULP (version 5) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6830 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2709F.F8943A50 Content-Type: text/plain; charset="iso-8859-1" Here is a new GULP, that tries to address the points raised in the mailing list (i.e. UNLOCK, lock state clarification, submission of lock tokens). ************************** Grand Unified Lock Proposal (V5) - A lock is either direct or indirect. - A LOCK request places a direct lock on the resource identified by the request-URL. The "lock-root" of the new lock is the request-URL. - If a collection has a direct depth:infinity lock with token X, all members of that collection (other than the collection itself) will have an indirect depth:infinity lock with token X. In particular, if a binding to a resource is added to a collection with a depth:infinity lock with token X, and if the resource does not have a lock with token X, then an indirect lock with token X is added to the resource. Conversely, if a resource has an indirect lock with token X, and if the result of removing a binding to the resource is that the resource is no longer a member of the collection with the direct lock with token X, then the lock with token X is removed from the resource. - An UNLOCK request removes all locks (both direct and indirect) that have the lock token specified in the Lock-Token header of the request. The request-URL of the request MUST identify a resource that has a lock (either direct or indirect) with the specified lock token. - 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. - If a request would modify the content or dead properties of a locked resource, or would modify the bindings of a locked collection, the request MUST fail unless the lock-token for that lock is submitted in the request. - If a request causes a resource with a direct lock 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 removed from that resource by that request. - If a request would cause two different exclusive locks to appear on the same resource, the request MUST fail. ************************** ------_=_NextPart_001_01C2709F.F8943A50 Content-Type: text/html; charset="iso-8859-1" GULP (version 5)

Here is a new GULP, that tries to address the points raised in the
mailing list (i.e. UNLOCK, lock state clarification, submission of
lock tokens).

**************************

Grand Unified Lock Proposal (V5)

- A lock is either direct or indirect.

- A LOCK request places a direct lock on the resource identified by
  the request-URL.  The "lock-root" of the new lock is the request-URL.

- If a collection has a direct depth:infinity lock with token X, all
  members of that collection (other than the collection itself) will
  have an indirect depth:infinity lock with token X.  In particular,
  if a binding to a resource is added to a collection with a
  depth:infinity lock with token X, and if the resource does not have
  a lock with token X, then an indirect lock with token X is added to
  the resource.  Conversely, if a resource has an indirect lock with
  token X, and if the result of removing a binding to the resource is
  that the resource is no longer a member of the collection with the
  direct lock with token X, then the lock with token X is removed from
  the resource.

- An UNLOCK request removes all locks (both direct and indirect) that
  have the lock token specified in the Lock-Token header of the request.
  The request-URL of the request MUST identify a resource that
  has a lock (either direct or indirect) with the specified lock token.

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

- If a request would modify the content or dead properties of a locked
  resource, or would modify the bindings of a locked collection, the
  request MUST fail unless the lock-token for that lock is submitted in
  the request.

- If a request causes a resource with a direct lock 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
 removed from that resource by that request.

- If a request would cause two different exclusive locks to appear on
  the same resource, the request MUST fail.

**************************

------_=_NextPart_001_01C2709F.F8943A50-- From w3c-dist-auth-request@w3.org Thu Oct 10 17:21:04 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA24483 for ; Thu, 10 Oct 2002 17:21:04 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9ALLOP19289; Thu, 10 Oct 2002 17:21:24 -0400 (EDT) Resent-Date: Thu, 10 Oct 2002 17:21:24 -0400 (EDT) Resent-Message-Id: <200210102121.g9ALLOP19289@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9ALLNB19263 for ; Thu, 10 Oct 2002 17:21:23 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA12151 for ; Thu, 10 Oct 2002 17:21:23 -0400 Received: (qmail 29546 invoked by uid 0); 10 Oct 2002 21:20:50 -0000 Received: from p3ee24712.dip.t-dialin.net (HELO lisa) (62.226.71.18) by mail.gmx.net (mp009-rz3) with SMTP; 10 Oct 2002 21:20:50 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , "'Clemm, Geoff'" , "'Webdav WG'" Date: Thu, 10 Oct 2002 23:20:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <003d01c2709d$359ad0b0$b701a8c0@xythoslap> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: GULP (version 4) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6831 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Lisa, > Yes. I'm saying that even if we define what the state of a resource is, > servers will handle things differently and clients will constantly have > to reissue requests in order to get the right lock tokens. Why that? If we get the clarification right, the only issue would be non-conforming implementations. And obviously there's no way we can guarantee interoperability if implementations do not comply with the spec. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Thursday, October 10, 2002 10:40 PM > To: 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG' > Subject: RE: GULP (version 4) > > > > > lisa > > > -----Original Message----- > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > Sent: Thursday, October 10, 2002 10:24 AM > > To: Lisa Dusseault; 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG' > > Subject: RE: GULP (version 4) > > > > Lisa, > > > > please re-read my mail. > > > > I was saying that we need to define what the state of a resource is. > > > > In particular its > > > > - content > > - internal members (depth 0 lock on collections) > > - dead properties > > - locks > > - *some* live properties (such as DAV:label) -- this is where it'll > get > > hairy, I guess > > > > Julian > > > > -- > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > > -----Original Message----- > > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > > Sent: Thursday, October 10, 2002 7:20 PM > > > To: 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG' > > > Subject: RE: GULP (version 4) > > > > > > > > > > > > > "If a request would modify the state of a resource, the request > MUST > > > fail > > > > unless the lock-token for that lock is specified in the request." > > > > > > This isn't much more specific than the current "is affected by" > > > language. It leaves it entirely up to the server to decide what > > > modifying the state of a resource is. Does modifying membership > count? > > > (Is modifying membership blocked by a depth 0 lock?) Does modifying > > > property values count? > > > > > > This is exactly where clients have had problems submitting simple > > > requests to server implementations that each have a different idea > what > > > resources have state modified by the request. > > > > > > lisa > > > > From w3c-dist-auth-request@w3.org Thu Oct 10 17:57:16 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25453 for ; Thu, 10 Oct 2002 17:57:16 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9ALvpq24156; Thu, 10 Oct 2002 17:57:51 -0400 (EDT) Resent-Date: Thu, 10 Oct 2002 17:57:51 -0400 (EDT) Resent-Message-Id: <200210102157.g9ALvpq24156@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9ALvnB24095 for ; Thu, 10 Oct 2002 17:57:49 -0400 (EDT) Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA19590 for ; Thu, 10 Oct 2002 17:57:49 -0400 Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Thu, 10 Oct 2002 17:57:14 -0400 (Eastern Daylight Time) Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453); Thu, 10 Oct 2002 17:57:13 -0400 Received: from xythoslap ([216.36.77.241]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453); Thu, 10 Oct 2002 17:57:13 -0400 From: "Lisa Dusseault" To: "'Webdav WG'" Date: Thu, 10 Oct 2002 14:57:08 -0700 Message-ID: <004901c270a7$fb5ed260$b701a8c0@xythoslap> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------InterScan_NT_MIME_Boundary" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 10 Oct 2002 21:57:13.0200 (UTC) FILETIME=[FD574700:01C270A7] Subject: RE: GULP (version 4) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6832 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. --------------InterScan_NT_MIME_Boundary Content-Type: multipart/alternative; boundary="----=_NextPart_000_004A_01C2706D.4EFFFA60" ------=_NextPart_000_004A_01C2706D.4EFFFA60 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit "If we get the clarification right"? A definition that involves discussing properties, locks, and content in a way that is generic, will result in a different conclusion for servers that do things differently. The model can be 'clarified' for years and still be interpreted differently. Imagine we try to define a model for what constitutes a state change. - What if a server, when you issue a DELETE, actually moves a file to the trash can folder? What if the trash can folder is locked? Clearly, it requires that lock token. - What a particular implementation decides that add a file to /mydir/sub/dir actually changes a property value on /mydir? - What if the contents of a file are defined to import the contents of another file? The server implementation might define that as a content change. - Does a collection's members state change if a file is renamed? - Does a collection's members state change if a file is overwritten? My point is that models are hard to do right. It's very tempting to work on tweaking the model, when that might not be as effective as simply specifying exactly what's supposed to happen in a particular case. In contrast, let's examine another way of "fixing" this problem by putting additional specification requirements on the server. Rather than say a lock affects changing state in certain ways (the 'generic' approach), we could define for each method what locks must be had. For example: - For DELETE requests, if the DELETE target is locked, or the DELETE target parent is locked, those locks are affected. - For COPY requests, if the COPY target is locked, or the COPY target parent is locked and the COPY target does not exist, those locks are affected. - etc. Let's go meta for a minute anyway. There are at least two ways that have been discussed to approach this "problem". One way is to give the client more leeway. The other is to make things more restrictive for the server - either through the generic approach of defining state, the specific approach of describing requests. Client implementers encountering this problem have asked for more client leeway, NOT for more server restrictions. I consider it perfectly valid to restate the problem and try to find a different solution -- I do this often and consider it a good design habit. However, one must always be careful to make sure one is really solving the right problem when one does this. lisa > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Thursday, October 10, 2002 2:21 PM > To: Lisa Dusseault; 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG' > Subject: RE: GULP (version 4) > > Lisa, > > > Yes. I'm saying that even if we define what the state of a resource is, > > servers will handle things differently and clients will constantly have > > to reissue requests in order to get the right lock tokens. > > Why that? If we get the clarification right, the only issue would be > non-conforming implementations. And obviously there's no way we can > guarantee interoperability if implementations do not comply with the spec. > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > Sent: Thursday, October 10, 2002 10:40 PM > > To: 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG' > > Subject: RE: GULP (version 4) > > > > > > > > > > > lisa > > > > > -----Original Message----- > > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > > Sent: Thursday, October 10, 2002 10:24 AM > > > To: Lisa Dusseault; 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG' > > > Subject: RE: GULP (version 4) > > > > > > Lisa, > > > > > > please re-read my mail. > > > > > > I was saying that we need to define what the state of a resource is. > > > > > > In particular its > > > > > > - content > > > - internal members (depth 0 lock on collections) > > > - dead properties > > > - locks > > > - *some* live properties (such as DAV:label) -- this is where it'll > > get > > > hairy, I guess > > > > > > Julian > > > > > > -- > > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > > > > -----Original Message----- > > > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > > > Sent: Thursday, October 10, 2002 7:20 PM > > > > To: 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav WG' > > > > Subject: RE: GULP (version 4) > > > > > > > > > > > > > > > > > "If a request would modify the state of a resource, the request > > MUST > > > > fail > > > > > unless the lock-token for that lock is specified in the request." > > > > > > > > This isn't much more specific than the current "is affected by" > > > > language. It leaves it entirely up to the server to decide what > > > > modifying the state of a resource is. Does modifying membership > > count? > > > > (Is modifying membership blocked by a depth 0 lock?) Does modifying > > > > property values count? > > > > > > > > This is exactly where clients have had problems submitting simple > > > > requests to server implementations that each have a different idea > > what > > > > resources have state modified by the request. > > > > > > > > lisa > > > > > > ------=_NextPart_000_004A_01C2706D.4EFFFA60 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

"If we get the clarification right"?  A = definition that involves discussing properties, locks, and content in a way that is = generic, will result in a different conclusion for servers that do things = differently.  The model can be 'clarified' for years and still be interpreted = differently.

 

Imagine we try to define a model for what constitutes a state = change.

 - What if a server, when you issue a DELETE, actually = moves a file to the trash can folder? What if the trash can folder is locked? Clearly, = it requires that lock token.

 - What a particular implementation decides that add a file = to /mydir/sub/dir actually changes a property value on /mydir?

 - What if the contents of a file are defined to import the = contents of another file?  The server implementation might define that as a = content change.

 - Does a collection's members state change if a file is = renamed?

 - Does a collection's members state change if a file is = overwritten? 

My point is that models are hard to do right.  It's very = tempting to work on tweaking the model, when that might not be as effective as = simply specifying exactly what's supposed to happen in a particular = case.

 

In contrast, let's examine another way of "fixing" = this problem by putting additional specification requirements on the = server.  Rather than say a lock affects changing state in certain ways (the 'generic' approach), we could define for each method what locks must be had.  = For example:

 - For DELETE requests, if the DELETE target is locked, or = the DELETE target parent is locked, those locks are affected.

 - For COPY requests, if the COPY target is locked, or the = COPY target parent is locked and the COPY target does not exist, those locks are = affected.

 - etc.

 

Let's go meta for a minute anyway.  There are at least two = ways that have been discussed to approach this "problem".  One way = is to give the client more leeway.  The other is to make things more = restrictive for the server - either through the generic approach of defining state, the = specific approach of describing requests.

 

Client implementers encountering this problem have asked for = more client leeway, NOT for more server restrictions.  I consider it perfectly = valid to restate the problem and try to find a different solution -- I do this often and consider it a good design habit.  However, one must always be = careful to make sure one is really solving the right problem when one does = this.

 

lisa

 

> -----Original Message-----

> From: Julian Reschke = [mailto:julian.reschke@gmx.de]

> Sent: Thursday, October 10, 2002 2:21 PM

> To: Lisa Dusseault; 'Julian Reschke'; 'Clemm, Geoff'; = 'Webdav WG'

> Subject: RE: GULP (version 4)

>

> Lisa,

>

> > Yes.  I'm saying that even if we define what the = state of a resource is,

> > servers will handle things differently and clients = will constantly have

> > to reissue requests in order to get the right lock = tokens.

>

> Why that? If we get the clarification right, the only issue = would be

> non-conforming implementations. And obviously there's no = way we can

> guarantee interoperability if implementations do not comply = with the spec.

>

> Julian

>

> --

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

>

> > -----Original Message-----

> > From: w3c-dist-auth-request@w3.org

> > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault

> > Sent: Thursday, October 10, 2002 10:40 = PM

> > To: 'Julian Reschke'; 'Clemm, Geoff'; 'Webdav = WG'

> > Subject: RE: GULP (version 4)

> >

> >

> >

>

> >

> > lisa

> >

> > > -----Original Message-----

> > > From: Julian Reschke = [mailto:julian.reschke@gmx.de]

> > > Sent: Thursday, October 10, 2002 = 10:24 AM

> > > To: Lisa Dusseault; 'Julian Reschke'; 'Clemm, = Geoff'; 'Webdav WG'

> > > Subject: RE: GULP (version 4)

> > >

> > > Lisa,

> > >

> > > please re-read my mail.

> > >

> > > I was saying that we need to define what the = state of a resource is.

> > >

> > > In particular its

> > >

> > > - content

> > > - internal members (depth 0 lock on = collections)

> > > - dead properties

> > > - locks

> > > - *some* live properties (such as DAV:label) -- = this is where it'll

> > get

> > > hairy, I guess

> > >

> > > Julian

> > >

> > > --

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

> > >

> > > > -----Original Message-----

> > > > From: Lisa Dusseault = [mailto:lisa@xythos.com]

> > > > Sent: Thursday, October 10, = 2002 7:20 PM

> > > > To: 'Julian Reschke'; 'Clemm, Geoff'; = 'Webdav WG'

> > > > Subject: RE: GULP (version = 4)

> > > >

> > > >

> > > >

> > > > > "If a request would modify the = state of a resource, the request

> > MUST

> > > > fail

> > > > > unless the lock-token for that lock is specified in the request."

> > > >

> > > > This isn't much more specific than the = current "is affected by"

> > > > language.  It leaves it entirely up to = the server to decide what

> > > > modifying the state of a resource is.  = Does modifying membership

> > count?

> > > > (Is modifying membership blocked by a depth = 0 lock?)  Does modifying

> > > > property values count?

> > > >

> > > > This is exactly where clients have had = problems submitting simple

> > > > requests to server implementations that each = have a different idea

> > what

> > > > resources have state modified by the = request.

> > > >

> > > > lisa

> > > >

> >

------=_NextPart_000_004A_01C2706D.4EFFFA60-- --------------InterScan_NT_MIME_Boundary-- From w3c-dist-auth-request@w3.org Thu Oct 10 21:07:15 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA27905 for ; Thu, 10 Oct 2002 21:07:14 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9B181T21974; Thu, 10 Oct 2002 21:08:01 -0400 (EDT) Resent-Date: Thu, 10 Oct 2002 21:08:01 -0400 (EDT) Resent-Message-Id: <200210110108.g9B181T21974@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9B17wB21947 for ; Thu, 10 Oct 2002 21:07:59 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA21804 for ; Thu, 10 Oct 2002 21:07:58 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id SAA12360 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Thu, 10 Oct 2002 18:07:57 -0700 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by sunbelt.seagull.net (8.9.3) with ESMTP id SAA12336 sender obsfucated@us.ibm.com; Thu, 10 Oct 2002 18:07:54 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9B17MkC163192; Thu, 10 Oct 2002 21:07:22 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9B17JGE102152; Thu, 10 Oct 2002 21:07:19 -0400 To: "Clemm, Geoff" Cc: "'Webdav WG'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Jason Crawford Message-ID: Date: Thu, 10 Oct 2002 21:07:17 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0|September 26, 2002) at 10/10/2002 21:07:19, Serialize complete at 10/10/2002 21:07:19 Content-Type: text/plain; charset="us-ascii" Subject: Re: GULP (version 5) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6833 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Thursday, 10/10/2002 at 04:59 AST, "Clemm, Geoff" wrote: > Here is a new GULP, that tries to address the points raised in the > mailing list (i.e. UNLOCK, lock state clarification, submission of > lock tokens). > > ************************** > > Grand Unified Lock Proposal (V5) > > - A lock is either direct or indirect. > > - A LOCK request places a direct lock on the resource identified by > the request-URL. The "lock-root" of the new lock is the request-URL. > > - If a collection has a direct depth:infinity lock with token X, all Actually it doesn't matter if it's direct or not in this sentence.... or is "members" a recursive term? > members of that collection (other than the collection itself) will > have an indirect depth:infinity lock with token X. In particular, > if a binding to a resource is added to a collection with a > depth:infinity lock with token X, and if the resource does not have > a lock with token X, then an indirect lock with token X is added to > the resource. Conversely, if a resource has an indirect lock with > token X, and if the result of removing a binding to the resource is > that the resource is no longer a member of the collection with the > direct lock with token X, then the lock with token X is removed from > the resource. Again, it doesn't need to be direct at the parent, just the ancestor unless "members" is recursive. > - An UNLOCK request removes all locks (both direct and indirect) that > have the lock token specified in the Lock-Token header of the request. > The request-URL of the request MUST identify a resource that > has a lock (either direct or indirect) with the specified lock token. I am uncomfortable refering to multiple locks. I've always thought of it as one lock that affects multiple resources. I'm also uncomfortable saying a resource *has* as lock as opposed to saying it *is* locked. But I have to admit that how you're saying it so far is very easy to understand. > - 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. > > - If a request would modify the content or dead properties of a locked > resource, or would modify the bindings of a locked collection, the > request MUST fail unless the lock-token for that lock is submitted in > the request. > > - If a request causes a resource with a direct lock 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 > removed from that resource by that request. > > - If a request would cause two different exclusive locks to appear on > the same resource, the request MUST fail. > > ************************** > Good stuff. Do you want to say what happens if you lock an unmapped URL? That leaves the issue of how much of the If header is evaluated. I'll start a seperate thread on that as Geoff requested. ------------------------------------------ Phone: 914-784-7569 From w3c-dist-auth-request@w3.org Fri Oct 11 03:42:21 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13683 for ; Fri, 11 Oct 2002 03:42:20 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9B7hTs13360; Fri, 11 Oct 2002 03:43:29 -0400 (EDT) Resent-Date: Fri, 11 Oct 2002 03:43:29 -0400 (EDT) Resent-Message-Id: <200210110743.g9B7hTs13360@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9B7hQB13330 for ; Fri, 11 Oct 2002 03:43:26 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA21142 for ; Fri, 11 Oct 2002 03:43:26 -0400 Received: (qmail 32122 invoked by uid 0); 11 Oct 2002 07:43:16 -0000 Received: from p3ee24807.dip.t-dialin.net (HELO lisa) (62.226.72.7) by mail.gmx.net (mp018-rz3) with SMTP; 11 Oct 2002 07:43:16 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Clemm, Geoff" Cc: "'Webdav WG'" Date: Fri, 11 Oct 2002 09:43:13 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: RE: GULP (version 5) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6834 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Friday, October 11, 2002 3:07 AM > To: Clemm, Geoff > Cc: 'Webdav WG' > Subject: Re: GULP (version 5) > .. > > > The request-URL of the request MUST identify a resource that > > has a lock (either direct or indirect) with the specified lock token. > > I am uncomfortable refering to multiple locks. I've always thought of it > as one lock that affects multiple resources. I'm also uncomfortable > saying I agree. Like it or not, a lock has a unique URI and identity, thus it is a resource (it may even be a WebDAV resource :-). > a resource *has* as lock as opposed to saying it *is* locked. > But I have to admit that how you're saying it so far > is very easy to understand. > > ... How about saying "is affected by a lock"? -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Oct 11 03:47:09 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA13765 for ; Fri, 11 Oct 2002 03:47:08 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9B7mWJ13886; Fri, 11 Oct 2002 03:48:32 -0400 (EDT) Resent-Date: Fri, 11 Oct 2002 03:48:32 -0400 (EDT) Resent-Message-Id: <200210110748.g9B7mWJ13886@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9B7mVB13860 for ; Fri, 11 Oct 2002 03:48:31 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA21874 for ; Fri, 11 Oct 2002 03:48:29 -0400 Received: (qmail 28997 invoked by uid 0); 11 Oct 2002 07:47:58 -0000 Received: from p3ee24807.dip.t-dialin.net (HELO lisa) (62.226.72.7) by mail.gmx.net (mp016-rz3) with SMTP; 11 Oct 2002 07:47:58 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'Webdav WG'" Date: Fri, 11 Oct 2002 09:47:56 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: RE: GULP (version 5) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6835 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Clemm, Geoff > Sent: Thursday, October 10, 2002 11:00 PM > To: 'Webdav WG' > Subject: GULP (version 5) > > .. > > - If a request would modify the content or dead properties of a locked > resource, or would modify the bindings of a locked collection, the > request MUST fail unless the lock-token for that lock is submitted in > the request. > > ... Again, this is incomplete. We really need to get to a proper definition about what the state of a resource is. At a minimun, it consists of: - content - dead properties - internal members (for collections) and - *some* live properties (DAV:lockdiscovery, DAV:getcontenttype, DAV:label-set, DAV:checked-in...) Not that I like it but maybe any definition of live properties will have to specify whether the property would be proteced by a lock? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Oct 11 04:03:05 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA13944 for ; Fri, 11 Oct 2002 04:03:05 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9B84QO15869; Fri, 11 Oct 2002 04:04:26 -0400 (EDT) Resent-Date: Fri, 11 Oct 2002 04:04:26 -0400 (EDT) Resent-Message-Id: <200210110804.g9B84QO15869@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9B84PB15841 for ; Fri, 11 Oct 2002 04:04:25 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA24972 for ; Fri, 11 Oct 2002 04:04:24 -0400 Received: (qmail 12926 invoked by uid 0); 11 Oct 2002 08:03:50 -0000 Received: from p3ee24807.dip.t-dialin.net (HELO lisa) (62.226.72.7) by mail.gmx.net (mp011-rz3) with SMTP; 11 Oct 2002 08:03:50 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Webdav WG'" Date: Fri, 11 Oct 2002 10:03:46 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <004901c270a7$fb5ed260$b701a8c0@xythoslap> Importance: Normal Subject: RE: GULP (version 4) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6836 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Lisa Dusseault > Sent: Thursday, October 10, 2002 11:57 PM > To: 'Webdav WG' > Subject: RE: GULP (version 4) > > > "If we get the clarification right"? A definition that involves > discussing > properties, locks, and content in a way that is generic, will result in a > different conclusion for servers that do things differently. The > model can > be 'clarified' for years and still be interpreted differently. Then is hasn't been clarified. If a specification defines locking, but doesn't define what operations on locked resources require submission of the lock token, then in doubt a client always has the choice of submitting the lock token. Servers that don't require it will just ignore it. So where's the big issue with that? > Imagine we try to define a model for what constitutes a state change. > - What if a server, when you issue a DELETE, actually moves a file to the > trash can folder? What if the trash can folder is locked? Clearly, it > requires that lock token. Yes. Bad design. I don't see how anything you are proposing would help with that problem? Either you need the lock token or not. I though the discussion was about the topic on *how* to submit it. Obviously, there always can be hidden server-specific dependencies on other resources that may be locked. If the server wants to enforce these locks, there's obviously no simple way for non-proprietary clients to interact with it. > - What a particular implementation decides that add a file to > /mydir/sub/dir actually changes a property value on /mydir? That would be a computed live property that would better be not lock-protected. If it is, generic clients will have a problem because they won't expect this. > - What if the contents of a file are defined to import the contents of > another file? The server implementation might define that as a content > change. That would be a bug (IMHO). > - Does a collection's members state change if a file is renamed? The state of the collection changes. The state of the member doesn't. > - Does a collection's members state change if a file is overwritten? The state of the collection doesn't change. The state of the member does. > My point is that models are hard to do right. It's very tempting to work on > tweaking the model, when that might not be as effective as simply specifying > exactly what's supposed to happen in a particular case. I think we don't have a choice but to define the model. > In contrast, let's examine another way of "fixing" this problem by putting > additional specification requirements on the server. Rather than say a lock > affects changing state in certain ways (the 'generic' approach), we could > define for each method what locks must be had. For example: > - For DELETE requests, if the DELETE target is locked, or the DELETE target > parent is locked, those locks are affected. > - For COPY requests, if the COPY target is locked, or the COPY target > parent is locked and the COPY target does not exist, those locks are > affected. > - etc. I'd prefer to have a generic model that explains all these requirements, because it would also automatically apply to new methods. However, it surely makes sense -- after getting the generic model right -- to write down what this actually means for all specific methods. The important point is to get the underlying model right first. > Let's go meta for a minute anyway. There are at least two ways that have > been discussed to approach this "problem". One way is to give the client > more leeway. The other is to make things more restrictive for the server - > either through the generic approach of defining state, the specific approach > of describing requests. I don't agree. If you're talking about the "new" header, it doesn't give the client any new freedom. It just allows a simpler syntax. It could use the If header instead. > Client implementers encountering this problem have asked for more client > leeway, NOT for more server restrictions. I consider it perfectly valid to > restate the problem and try to find a different solution -- I do this often > and consider it a good design habit. However, one must always be careful to > make sure one is really solving the right problem when one does this. Yes. But the outcome might as well be that some existing protocol element hasn't been understood properly and already does what the client implementor is asking for. In particular, you *can* use the If header to submit any number of lock tokens you have -- no matter whether they are required or even in effect. If this doesn't work yet in practice, let's clarify the spec and fix the implementations instead of inventing something new. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Oct 11 05:15:57 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA14819 for ; Fri, 11 Oct 2002 05:15:57 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9B9HB124995; Fri, 11 Oct 2002 05:17:11 -0400 (EDT) Resent-Date: Fri, 11 Oct 2002 05:17:11 -0400 (EDT) Resent-Message-Id: <200210110917.g9B9HB124995@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9B9HAB24969 for ; Fri, 11 Oct 2002 05:17:10 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA04775 for ; Fri, 11 Oct 2002 05:17:10 -0400 Received: from greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Fri, 11 Oct 2002 11:16:14 +0200 Date: Fri, 11 Oct 2002 11:16:13 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "Clemm, Geoff" , w3c-dist-auth@w3.org To: Jason Crawford From: Stefan Eissing In-Reply-To: Message-Id: <16D78662-DCFA-11D6-9950-00039384827E@greenbytes.de> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3.org Subject: Re: BIND method response codes, new header? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6837 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Am Donnerstag, 10.10.02, um 17:06 Uhr (Europe/Berlin) schrieb Jason Crawford: > Or.... how about.... (get your tomatoes ready...) I prefer eggs. Old eggs. ;) > A new header, whereby the client can submit > assertions that it wants the server to test. These tests > need not prevent an operation from occuring, but > they can inform the user of the situation just before > (or after) the operation occured. It could test for things > like etags and locks. And in this case it could test if > a resource existed. > > This header would not be bind specific. And it > need not go in the spec now. But if we are anticipating > something like this, we wouldn't need to spend time defining > a new status code now or even debating which one to use. If it affects the response, but not the spec, any result of the test would need to be returned in a specific response header, right? So, you'd introduce a separate communication channel on top of/ sideways to HTTP. This is... let's say, hummm,... interesting. I wouldn't bet my money on its success, though. //Stefan From w3c-dist-auth-request@w3.org Fri Oct 11 09:28:29 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20842 for ; Fri, 11 Oct 2002 09:28:29 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9BDKJ008230; Fri, 11 Oct 2002 09:20:19 -0400 (EDT) Resent-Date: Fri, 11 Oct 2002 09:20:19 -0400 (EDT) Resent-Message-Id: <200210111320.g9BDKJ008230@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9BDKHB08189 for ; Fri, 11 Oct 2002 09:20:17 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA26824 for ; Fri, 11 Oct 2002 09:20:18 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 11 Oct 2002 09:09:02 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Fri, 11 Oct 2002 09:19:46 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Fri, 11 Oct 2002 09:19:45 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27128.DE0BA1D0" Subject: GULP (version 5.1) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6838 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27128.DE0BA1D0 Content-Type: text/plain; charset="iso-8859-1" Reworded, to emphasize that an indirect lock is not a separate lock, to handle LOCKing an unmapped resource, and to handle locking live properties. ************************** Grand Unified Lock Proposal (V5.1) - 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. 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. The "lock-root" of the new lock is the request-URL. - 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 a binding to a 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 removing a binding to the resource 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. - 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. - 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. - 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 a binding of a locked collection, the request MUST fail unless the lock-token for that lock is submitted in the request. - 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. ************************** ------_=_NextPart_001_01C27128.DE0BA1D0 Content-Type: text/html; charset="iso-8859-1" GULP (version 5.1)

Reworded, to emphasize that an indirect lock is not a separate lock,
to handle LOCKing an unmapped resource, and to handle locking live
properties.

**************************

Grand Unified Lock Proposal (V5.1)

- 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.  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.  The
  "lock-root" of the new lock is the request-URL.

- 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 a binding to a
  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 removing a binding to the resource 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.

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

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

- 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 a binding of a locked collection,
  the request MUST fail unless the lock-token for that lock is
  submitted in the request.

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

**************************

------_=_NextPart_001_01C27128.DE0BA1D0-- From w3c-dist-auth-request@w3.org Fri Oct 11 09:28:32 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20866 for ; Fri, 11 Oct 2002 09:28:32 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9BDKK208286; Fri, 11 Oct 2002 09:20:20 -0400 (EDT) Resent-Date: Fri, 11 Oct 2002 09:20:20 -0400 (EDT) Resent-Message-Id: <200210111320.g9BDKK208286@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9BDKJB08219 for ; Fri, 11 Oct 2002 09:20:19 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA26831 for ; Fri, 11 Oct 2002 09:20:19 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 11 Oct 2002 09:09:03 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Fri, 11 Oct 2002 09:19:48 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Fri, 11 Oct 2002 09:19:48 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27128.DF8B6400" Subject: RE: GULP (version 5) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6839 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27128.DF8B6400 Content-Type: text/plain; charset="iso-8859-1" From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: Clemm, Geoff > > - If a request would modify the content or dead properties of a > locked resource, or would modify the bindings of a locked > collection, the request MUST fail unless the lock-token for that > lock is submitted in the request. Again, this is incomplete. We really need to get to a proper definition about what the state of a resource is. At a minimun, it consists of: - content - dead properties - internal members (for collections) and - *some* live properties (DAV:lockdiscovery, DAV:getcontenttype, DAV:label-set, DAV:checked-in...) Yes, you did already point that out, and I meant to add that. Sorry about the omission. Not that I like it but maybe any definition of live properties will have to specify whether the property would be proteced by a lock? Yes, I think that is our only alternative. (RFC-3253 does so). Cheers, Geoff ------_=_NextPart_001_01C27128.DF8B6400 Content-Type: text/html; charset="iso-8859-1" RE: GULP (version 5)

   From: Julian Reschke [mailto:julian.reschke@gmx.de]

   > From: Clemm, Geoff
   >
   > - If a request would modify the content or dead properties of a
   > locked resource, or would modify the bindings of a locked
   > collection, the request MUST fail unless the lock-token for that
   > lock is submitted in the request.

   Again, this is incomplete. We really need to get to a proper
   definition about what the state of a resource is.  At a minimun, it
   consists of:
   - content
   - dead properties
   - internal members (for collections)
   and
   - *some* live properties (DAV:lockdiscovery, DAV:getcontenttype,
   DAV:label-set, DAV:checked-in...)

Yes, you did already point that out, and I meant to add that.  Sorry
about the omission.

   Not that I like it but maybe any definition of live properties will
   have to specify whether the property would be proteced by a lock?

Yes, I think that is our only alternative.  (RFC-3253 does so).

Cheers,
Geoff

------_=_NextPart_001_01C27128.DF8B6400-- From w3c-dist-auth-request@w3.org Fri Oct 11 10:27:02 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20841 for ; Fri, 11 Oct 2002 09:28:29 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9BDKSX08308; Fri, 11 Oct 2002 09:20:28 -0400 (EDT) Resent-Date: Fri, 11 Oct 2002 09:20:28 -0400 (EDT) Resent-Message-Id: <200210111320.g9BDKSX08308@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9BDKJB08224 for ; Fri, 11 Oct 2002 09:20:19 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA26833 for ; Fri, 11 Oct 2002 09:20:19 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 11 Oct 2002 09:09:03 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Fri, 11 Oct 2002 09:19:48 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Fri, 11 Oct 2002 09:19:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27128.DEF7AF80" Subject: RE: GULP (version 5) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6840 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27128.DEF7AF80 Content-Type: text/plain From: Jason Crawford [mailto:nn683849@smallcue.com] On Thursday, 10/10/2002 at 04:59 AST, "Clemm, Geoff" wrote: > - If a collection has a direct depth:infinity lock with token X, > - all Actually it doesn't matter if it's direct or not in this sentence.... or is "members" a recursive term? Yes, members is a recursive term ("internal member" is the non-recursive term). > members of that collection (other than the collection itself) > will have an indirect depth:infinity lock with token X. In > particular, if a binding to a resource is added to a collection > with a depth:infinity lock with token X, and if the resource > does not have a lock with token X, then an indirect lock with > token X is added to the resource. Conversely, if a resource > has an indirect lock with token X, and if the result of > removing a binding to the resource is that the resource is no > longer a member of the collection with the direct lock with > token X, then the lock with token X is removed from the > resource. Again, it doesn't need to be direct at the parent, just the ancestor unless "members" is recursive. Think about recursive bindings, where A is locked and A contains a binding to B, B contains a binding to C, and C contains a binding to B. If you remove the binding in A to B, you don't want B or C to continue being locked (gotta handle those edge cases :-). > - An UNLOCK request removes all locks (both direct and indirect) > that have the lock token specified in the Lock-Token header of > the request. > The request-URL of the request MUST identify a resource that > has a lock (either direct or indirect) with the specified lock > token. I am uncomfortable refering to multiple locks. I've always thought of it as one lock that affects multiple resources. I'm also uncomfortable saying a resource *has* as lock as opposed to saying it *is* locked. But I have to admit that how you're saying it so far is very easy to understand. I agree with you that we need to emphasize that a LOCK creates a single lock that can protect the state of multiple resources. I will reword the proposal to do so. Do you want to say what happens if you lock an unmapped URL? Yeah, I guess we should add that (:-). That leaves the issue of how much of the If header is evaluated. I'll start a seperate thread on that as Geoff requested. Great! Cheers, Geoff ------_=_NextPart_001_01C27128.DEF7AF80 Content-Type: text/html RE: GULP (version 5)

   From: Jason Crawford [mailto:nn683849@smallcue.com]

   On Thursday, 10/10/2002 at 04:59 AST, "Clemm, Geoff" wrote:

   > - If a collection has a direct depth:infinity lock with token X,
   > - all

   Actually it doesn't matter if it's direct or not in this
   sentence.... or is "members" a recursive term?

Yes, members is a recursive term ("internal member" is the
non-recursive term).

   >   members of that collection (other than the collection itself)
   >   will have an indirect depth:infinity lock with token X.  In
   >   particular, if a binding to a resource is added to a collection
   >   with a depth:infinity lock with token X, and if the resource
   >   does not have a lock with token X, then an indirect lock with
   >   token X is added to the resource.  Conversely, if a resource
   >   has an indirect lock with token X, and if the result of
   >   removing a binding to the resource is that the resource is no
   >   longer a member of the collection with the direct lock with
   >   token X, then the lock with token X is removed from the
   >   resource.

   Again, it doesn't need to be direct at the parent, just the ancestor
   unless "members" is recursive.

Think about recursive bindings, where A is locked and A contains
a binding to B, B contains a binding to C, and C contains a binding
to B. If you remove the binding in A to B, you don't want B or
C to continue being locked (gotta handle those edge cases :-).

   > - An UNLOCK request removes all locks (both direct and indirect)
   > that have the lock token specified in the Lock-Token header of
   > the request.

   >   The request-URL of the request MUST identify a resource that
   >   has a lock (either direct or indirect) with the specified lock
   >   token.

   I am uncomfortable refering to multiple locks.  I've always thought
   of it as one lock that affects multiple resources.  I'm also
   uncomfortable saying a resource *has* as lock as opposed to saying
   it *is* locked.  But I have to admit that how you're saying it so
   far is very easy to understand.

I agree with you that we need to emphasize that a LOCK creates a
single lock that can protect the state of multiple resources.  I will
reword the proposal to do so.

   Do you want to say what happens if you lock an unmapped URL?

Yeah, I guess we should add that (:-).

    That leaves the issue of how much of the If header is evaluated.
    I'll start a seperate thread on that as Geoff requested.

Great!

Cheers,
Geoff

------_=_NextPart_001_01C27128.DEF7AF80-- From w3c-dist-auth-request@w3.org Fri Oct 11 14:56:56 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA02318 for ; Fri, 11 Oct 2002 14:56:55 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9BIvqM13987; Fri, 11 Oct 2002 14:57:52 -0400 (EDT) Resent-Date: Fri, 11 Oct 2002 14:57:52 -0400 (EDT) Resent-Message-Id: <200210111857.g9BIvqM13987@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9BIvpB13959 for ; Fri, 11 Oct 2002 14:57:51 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA22537 for ; Fri, 11 Oct 2002 14:57:51 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 11 Oct 2002 14:46:35 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Fri, 11 Oct 2002 14:57:21 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Fri, 11 Oct 2002 14:57:18 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27158.05DFD0D0" Subject: RE: GULP (version 5.2) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6841 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27158.05DFD0D0 Content-Type: text/plain; charset="iso-8859-1" Jason suggested switching the sentence order in the second section. ************************** Grand Unified Lock Proposal (V5.2) - 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. - 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 a binding to a 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 removing a binding to the resource 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. - 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. - 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. - 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 a binding of a locked collection, the request MUST fail unless the lock-token for that lock is submitted in the request. - 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. ************************** ------_=_NextPart_001_01C27158.05DFD0D0 Content-Type: text/html; charset="iso-8859-1" RE: GULP (version 5.2)

Jason suggested switching the sentence order in the second section.

**************************
Grand Unified Lock Proposal (V5.2)

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

- 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 a binding to a
  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 removing a binding to the resource 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.

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

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

- 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 a binding of a locked collection,
  the request MUST fail unless the lock-token for that lock is
  submitted in the request.

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

------_=_NextPart_001_01C27158.05DFD0D0-- From w3c-dist-auth-request@w3.org Fri Oct 11 15:30:26 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03206 for ; Fri, 11 Oct 2002 15:30:26 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9BJVTU16864; Fri, 11 Oct 2002 15:31:29 -0400 (EDT) Resent-Date: Fri, 11 Oct 2002 15:31:29 -0400 (EDT) Resent-Message-Id: <200210111931.g9BJVTU16864@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9BJVSB16833 for ; Fri, 11 Oct 2002 15:31:28 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA28376 for ; Fri, 11 Oct 2002 15:31:28 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 11 Oct 2002 15:20:12 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Fri, 11 Oct 2002 15:30:57 -0400 Message-ID: From: "Clemm, Geoff" To: "WebDAV (E-mail)" Date: Fri, 11 Oct 2002 15:30:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2715C.B8A29D70" Subject: BIND 506 status Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6842 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2715C.B8A29D70 Content-Type: text/plain -----Original Message----- From: Julian Reschke [mailto:julian.reschke@greenbytes.de] I think the following rules must be obeyed: - for any given HTTP GET header, PROPFIND depth 0 must return the same values as DAV properties as a HEAD (with the same request headers) would have - PROPFIND depth 1 must produce the union of response elements of a) the request URI and b) -- if the request URI identifies a WebDAV collection -- all it's internal direct members - Any response element appearing in a multistatus response for depth > 1 should be the same if a PROPFIND depth 0 is made directly on it's URL So, - as there's really no problem with the resource http://www.somehost.com/Coll/Bar, it should be reported as OK (200) or with no status (this really is a multistatus minimization for the case where properties are reported) - equally, there's really no problem with the properties on the resource -- for instance, I should be able to PROPFIND the DAV:getlastmodified date even if the collection contains a bind to itself Basically, this is a problem similar to the one that has been discussed before: what to do when PROPFIND wants to traverse a collection, but doesn't have the access rights to do so: there is simply no spec-compliant way to report that problem, so the consensus was not to report it at all. In this case, I now lean to an extension that would be invisible to "old" clients, and that also could be used to indicate the ACL problem mentioned above. For instance we could define preconditions for the traversal of the children: DAV:resource-must-only-occur-once: in a multistatus response body, each resource must be only reported once And then use a new element to marshall this kind of information http://www.somehost.com/Coll/Bar/ Loop Demo HTTP/1.1 200 OK http://www.somehost.com/Coll/ -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 ------_=_NextPart_001_01C2715C.B8A29D70 Content-Type: text/html Content-Transfer-Encoding: quoted-printable BIND 506 status

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@green= bytes.de]

I think the following rules must be obeyed:

- for any given HTTP GET header, PROPFIND depth 0 = must return the same
values as DAV properties as a HEAD (with the same = request headers) would
have

- PROPFIND depth 1 must produce the union of response = elements of a) the
request URI and b) -- if the request URI identifies = a WebDAV collection --
all it's internal direct members

- Any response element appearing in a multistatus = response for depth > 1
should be the same if a PROPFIND depth 0 is made = directly on it's URL

So,

- as there's really no problem with the = resource
http://www.somehost.com/Coll/Bar, it should be = reported as OK (200) or with
no status (this really is a multistatus minimization = for the case where
properties are reported)

- equally, there's really no problem with the = properties on the resource --
for instance, I should be able to PROPFIND the = DAV:getlastmodified date even
if the collection contains a bind to itself

Basically, this is a problem similar to the one that = has been discussed
before: what to do when PROPFIND wants to traverse a = collection, but doesn't
have the access rights to do so: there is simply no = spec-compliant way to
report that problem, so the consensus was not to = report it at all.

In this case, I now lean to an extension that would = be invisible to "old"
clients, and that also could be used to indicate the = ACL problem mentioned
above.

For instance we could define preconditions for the = traversal of the
children:

DAV:resource-must-only-occur-once: in a multistatus = response body, each
resource must be only reported once

And then use a new element to marshall this kind of = information

  <D:response>
      <D:href>http://www.somehost.com/Coll/Bar/</D:href>
      = <D:propstat>
         = <D:prop>
          &nb= sp; <D:displayname>Loop Demo</D:displayname>
         = </D:prop>
         = <D:status>HTTP/1.1 200 OK</D:status>
      = </D:propstat>
      = <D:child-status>

<D:resource-must-only-occur-once><D:href>http://www.somehost.com/Coll/</D:hr
ef></D:resource-must-only-occur-once>
      = </D:child-status>
   </D:response>


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

------_=_NextPart_001_01C2715C.B8A29D70-- From w3c-dist-auth-request@w3.org Fri Oct 11 15:41:43 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03450 for ; Fri, 11 Oct 2002 15:41:43 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9BJgvK20497; Fri, 11 Oct 2002 15:42:57 -0400 (EDT) Resent-Date: Fri, 11 Oct 2002 15:42:57 -0400 (EDT) Resent-Message-Id: <200210111942.g9BJgvK20497@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9BJguB20469 for ; Fri, 11 Oct 2002 15:42:56 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA31353 for ; Fri, 11 Oct 2002 15:42:56 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 11 Oct 2002 15:31:40 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Fri, 11 Oct 2002 15:42:25 -0400 Message-ID: From: "Clemm, Geoff" To: "WebDAV (E-mail)" Date: Fri, 11 Oct 2002 15:42:23 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2715E.51F35040" Subject: RE: BIND 506 status Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6843 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2715E.51F35040 Content-Type: text/plain If we handled it the way proposed below, the old clients will just ignore the new element, and the user will incorrectly conclude that the collection had no child by that name. With the original proposal, users of old clients will be told that there is a child, and will get the error message that they've already seen that child, so it is being left out of the report. I think the later is preferable. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@greenbytes.de] I think the following rules must be obeyed: - for any given HTTP GET header, PROPFIND depth 0 must return the same values as DAV properties as a HEAD (with the same request headers) would have - PROPFIND depth 1 must produce the union of response elements of a) the request URI and b) -- if the request URI identifies a WebDAV collection -- all it's internal direct members - Any response element appearing in a multistatus response for depth > 1 should be the same if a PROPFIND depth 0 is made directly on it's URL So, - as there's really no problem with the resource http://www.somehost.com/Coll/Bar, it should be reported as OK (200) or with no status (this really is a multistatus minimization for the case where properties are reported) - equally, there's really no problem with the properties on the resource -- for instance, I should be able to PROPFIND the DAV:getlastmodified date even if the collection contains a bind to itself Basically, this is a problem similar to the one that has been discussed before: what to do when PROPFIND wants to traverse a collection, but doesn't have the access rights to do so: there is simply no spec-compliant way to report that problem, so the consensus was not to report it at all. In this case, I now lean to an extension that would be invisible to "old" clients, and that also could be used to indicate the ACL problem mentioned above. For instance we could define preconditions for the traversal of the children: DAV:resource-must-only-occur-once: in a multistatus response body, each resource must be only reported once And then use a new element to marshall this kind of information http://www.somehost.com/Coll/Bar/ Loop Demo HTTP/1.1 200 OK http://www.somehost.com/Coll/ -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 ------_=_NextPart_001_01C2715E.51F35040 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: BIND 506 status

If we handled it the way proposed below, the old = clients will just ignore
the new element, and the user will incorrectly = conclude that the collection
had no child by that name.  With the original = proposal, users of
old clients will be told that there is a child, and = will get the
error message that they've already seen that child, = so it is
being left out of the report.  I think the = later is preferable.

Cheers,
Geoff



-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@green= bytes.de]
I think the following rules must be obeyed:
- for any given HTTP GET header, PROPFIND depth 0 = must return the same
values as DAV properties as a HEAD (with the same = request headers) would
have
- PROPFIND depth 1 must produce the union of = response elements of a) the
request URI and b) -- if the request URI identifies = a WebDAV collection --
all it's internal direct members
- Any response element appearing in a multistatus = response for depth > 1
should be the same if a PROPFIND depth 0 is made = directly on it's URL
So,
- as there's really no problem with the resource =
http://www.somehost.com/Coll/Bar, it should be = reported as OK (200) or with
no status (this really is a multistatus minimization = for the case where
properties are reported)
- equally, there's really no problem with the = properties on the resource --
for instance, I should be able to PROPFIND the = DAV:getlastmodified date even
if the collection contains a bind to itself
Basically, this is a problem similar to the one that = has been discussed
before: what to do when PROPFIND wants to traverse a = collection, but doesn't
have the access rights to do so: there is simply no = spec-compliant way to
report that problem, so the consensus was not to = report it at all.
In this case, I now lean to an extension that would = be invisible to "old"
clients, and that also could be used to indicate the = ACL problem mentioned
above.
For instance we could define preconditions for the = traversal of the
children:
DAV:resource-must-only-occur-once: in a multistatus = response body, each
resource must be only reported once
And then use a new element to marshall this kind of = information
  <D:response>
      <D:href>http://www.somehost.com/Coll/Bar/</D:href> =
      <D:propstat> =
         = <D:prop>
          &nb= sp; <D:displayname>Loop Demo</D:displayname>
         = </D:prop>
         = <D:status>HTTP/1.1 200 OK</D:status>
      </D:propstat> =
      = <D:child-status>
<D:resource-must-only-occur-once><D:href>http://www.somehost.com/Coll/</D:hr
ef></D:resource-must-only-occur-once> =
      = </D:child-status>
   </D:response>


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

------_=_NextPart_001_01C2715E.51F35040-- From w3c-dist-auth-request@w3.org Fri Oct 11 16:18:33 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA04271 for ; Fri, 11 Oct 2002 16:18:32 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9BKJai23734; Fri, 11 Oct 2002 16:19:36 -0400 (EDT) Resent-Date: Fri, 11 Oct 2002 16:19:36 -0400 (EDT) Resent-Message-Id: <200210112019.g9BKJai23734@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9BKJZB23704 for ; Fri, 11 Oct 2002 16:19:35 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA06115 for ; Fri, 11 Oct 2002 16:19:32 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 11 Oct 2002 16:08:14 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Fri, 11 Oct 2002 16:19:00 -0400 Message-ID: From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Fri, 11 Oct 2002 16:18:59 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27163.6F086F80" Subject: RE: BIND method response codes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6844 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27163.6F086F80 Content-Type: text/plain; charset="iso-8859-1" From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: Clemm, Geoff > > A problem with 200/201, is that 201 means "a new resource > was created", but a BIND never creates a new resource, but > just creates a new binding to an existing resource. That's correct with the WebDAV/BIND definition of a resource, but not with the generic (RFC2396) one -- the binding itself has a unique identifier (and thus has identity), therefore *can* be considered a resource. The binding does not have a unique identifier and does not have identity. In particular, if you delete a binding from a collection, and then create a new binding in that collection with the same segment and same bound resource, the new binding is indistinguishable from the old binding. Theoretically of course, a binding is a resource because you can imagine having a URL that identifies it. But we have not defined any such URL mapping (the mappings that a binding introduces are to the bound resources, not to the bindings themselves). > You could of course still use 200/201, but I'd be concerned that > it would be misleading. If a client has asked that BIND > overwrite any existing binding for that segment, why would it > care whether or not there was already a binding there? Well, why would it care in the case of PUT or MOVE? I'm just looking for consistency with other methods. Since BIND has different semantics from PUT or MOVE, I don't find a consistency argument sufficient reason to make this distinction. As for why it would care in the case of PUT or MOVE, I'd be interested in hearing an answer to that as well. Cheers, Geoff ------_=_NextPart_001_01C27163.6F086F80 Content-Type: text/html; charset="iso-8859-1" RE: BIND method response codes

   From: Julian Reschke [mailto:julian.reschke@gmx.de]

   > From: Clemm, Geoff
   >
   > A problem with 200/201, is that 201 means "a new resource
   > was created", but a BIND never creates a new resource, but
   > just creates a new binding to an existing resource.

   That's correct with the WebDAV/BIND definition of a resource, but
   not with the generic (RFC2396) one -- the binding itself has a
   unique identifier (and thus has identity), therefore *can* be
   considered a resource.

The binding does not have a unique identifier and does not have
identity.  In particular, if you delete a binding from a collection,
and then create a new binding in that collection with the same segment
and same bound resource, the new binding is indistinguishable from the
old binding.  Theoretically of course, a binding is a resource because
you can imagine having a URL that identifies it.  But we have not
defined any such URL mapping (the mappings that a binding introduces
are to the bound resources, not to the bindings themselves).

   > You could of course still use 200/201, but I'd be concerned that
   > it would be misleading.  If a client has asked that BIND
   > overwrite any existing binding for that segment, why would it
   > care whether or not there was already a binding there?

   Well, why would it care in the case of PUT or MOVE? I'm just
   looking for consistency with other methods.

Since BIND has different semantics from PUT or MOVE, I don't
find a consistency argument sufficient reason to make this
distinction.  As for why it would care in the case of PUT or
MOVE, I'd be interested in hearing an answer to that as well.

Cheers,
Geoff

------_=_NextPart_001_01C27163.6F086F80-- From w3c-dist-auth-request@w3.org Sun Oct 13 01:05:55 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA05407 for ; Sun, 13 Oct 2002 01:05:55 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9D56Zf05924; Sun, 13 Oct 2002 01:06:35 -0400 (EDT) Resent-Date: Sun, 13 Oct 2002 01:06:35 -0400 (EDT) Resent-Message-Id: <200210130506.g9D56Zf05924@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9D56YB05898 for ; Sun, 13 Oct 2002 01:06:34 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA09690 for ; Sun, 13 Oct 2002 01:06:33 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id WAA11993 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Sat, 12 Oct 2002 22:06:15 -0700 Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by sunbelt.seagull.net (8.9.3) with ESMTP id WAA11977 sender obsfucated@us.ibm.com; Sat, 12 Oct 2002 22:06:14 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9D55gxw151746; Sun, 13 Oct 2002 01:05:43 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9D55f40082346; Sun, 13 Oct 2002 01:05:41 -0400 To: "Clemm, Geoff" Cc: "'Webdav WG'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Jason Crawford Message-ID: Date: Sun, 13 Oct 2002 01:05:37 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0|September 26, 2002) at 10/13/2002 01:05:41, Serialize complete at 10/13/2002 01:05:41 Content-Type: text/plain; charset="us-ascii" Subject: RE: If Header: evaluation of all assertions Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6845 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Geoff suggested I start a new thread... I'm going to propose that ALL of the IF: header be evaluated by the server the server. I've actually said much of this in a recent posting on a different topic, and I doubt it got read because it was buried. I also probably say it a bit better here this time anyway... RFC2518 seems to spend a lot of time talking about If: header and all it's details but not about how it's used to submit lock tokens. It's use for lock token submission seems to simply be an afterthought. It even says the following when it begins to talk about the If; header. The If header is intended to have similar functionality to the If- Match header defined in section 14.24 of [RFC2616]. However the If header is intended for use with any URI which represents state information, referred to as a state token, about a resource as well as ETags. A typical example of a state token is a lock token, and lock tokens are the only state tokens defined in this specification. And I've taken this opening statement, and the fact that it never talks about lock token submission in the "IF Header" section, to mean that the primary purpose of the If: header was for a client to verify various aspects of server state (like If-Match) before doing an operation. Above I outlined what I thought the *primary* purpose of the If: header was in 2518. But there are stray comments in the 2518 that make the If; header's purpose confused. We've fixed one of those in 2518bis. But 2518bis still has the statement that the server will only check the assertions on the URL's it chooses: When the If header is applied to a particular resource, the Tagged- list productions MUST be searched to determine if any of the listed resources match the operand resource(s) for the current method. If none of the resource productions match the current resource then the header MUST be ignored. If one of the resource productions does match the name of the resource under consideration then the list productions following the resource production MUST be applied to the resource in the manner specified in the previous section. With that statement, the semantics and purpose of the If: header gets confusing. It's like the server saying, "you can ask me to check somethings, and I'll only check the one's I want, and I won't tell you which one's I didn't check" It (2518) just doesn't make sense. I undermines what was presented as the primary purpose of that header: For the client to be able to request that the request be contingent on assertions that he submits. A trivial, but non fatal, example of the problem the partial evaluation creates for the client. Let's say a client has locked a subtree of the URL space and is working with various resources in it. He/She/It GET's and PUT's a lot of resources. Perhaps it's making sure all the pages fit some corporate guidelines and tries to correct mistakes. To be careful, it uses the IF: header to make sure the resources are still locked as it progresses. But unfortunately the server will only evaluate that request if thinks it needs to. And for example, it might not evaluate it for GET requests. If the resource is a large resource, a lot of time and bandwidth could be wasted getting the resource if the operation is later aborted/restarted when the client later finds out that the lock has gone away. If the server had respected the check in the first place, the client could have corrected the situation more quickly. Again, it's not a fatal example, but I think it points out the problem this can pose for the client. Another more significant example might be a COPY command where one wants to make sure the copy of the file one copies is the one that matches an ETAG or is still locked. But the server might not even make that check before doing the operation. I'd like to propose that we change the spec to say ALL of the tagged assertions that the client submits in the IF: header be evaluated by the server. This proposal is not contingent on any of the current IF: header related proposals. All proposals should be able to benefit from this change. Interoperability... if there are clients out there that submit assertions on secondary resource that are actually false but never evaluated by current servers, then those clients will break, but that seems highly unlikely. Similarly, because it's unlikely that clients are currently submitting assertions on secondary resources that actually would evaluate to false but passing through, servers can feel safe going ahead and evaluating the whole If: header. The only compatibility issue is transitional. New clients can submit extra assertions, but they don't know if the server is evaluating all of them because the server might be following 2518 rather than a new spec. This means that for a while, clients can only take advantage of this for helpful checks, not critical checks. Thoughts? J. ------------------------------------------ Phone: 914-784-7569 From w3c-dist-auth-request@w3.org Sun Oct 13 11:19:03 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA20646 for ; Sun, 13 Oct 2002 11:19:02 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9DFES907460; Sun, 13 Oct 2002 11:14:28 -0400 (EDT) Resent-Date: Sun, 13 Oct 2002 11:14:28 -0400 (EDT) Resent-Message-Id: <200210131514.g9DFES907460@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9DFERB07433 for ; Sun, 13 Oct 2002 11:14:27 -0400 (EDT) Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23]) by tux.w3.org (8.9.3/8.9.3) with SMTP id LAA31560 for ; Sun, 13 Oct 2002 11:14:27 -0400 Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Sun, 13 Oct 2002 11:12:47 -0400 (Eastern Daylight Time) Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453); Sun, 13 Oct 2002 11:12:46 -0400 Received: from xythoslap ([198.144.203.248]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453); Sun, 13 Oct 2002 11:12:45 -0400 From: "Lisa Dusseault" To: "'Jason Crawford'" , "'Clemm, Geoff'" Cc: "'Webdav WG'" Date: Sun, 13 Oct 2002 08:12:38 -0700 Message-ID: <000101c272ca$f9202970$29c4fea9@xythoslap> 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.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 13 Oct 2002 15:12:46.0183 (UTC) FILETIME=[FC4F9770:01C272CA] Subject: RE: If Header: evaluation of all assertions Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6846 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is an excellent clarification. Also, I would clarify what the untagged if production refers to, and it should probably refer only to the resource named in the Request-URI. lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] > On Behalf Of Jason Crawford > Sent: Saturday, October 12, 2002 10:06 PM > To: Clemm, Geoff > Cc: 'Webdav WG' > Subject: RE: If Header: evaluation of all assertions > > > Geoff suggested I start a new thread... > > I'm going to propose that ALL of the IF: header be evaluated by the server > the server. I've actually said much of this in a recent > posting on a different topic, and I doubt it got read because > it was buried. I also probably say it a bit better here this > time anyway... > > > RFC2518 seems > to spend a lot of time talking about If: header and all it's > details but not about how it's used to submit lock tokens. It's use > for lock token submission seems to simply be an afterthought. It even > says the following when it begins to talk about the If; header. > > The If header is intended to have similar functionality to the If- > Match header defined in section 14.24 of [RFC2616]. However the If > header is intended for use with any URI which represents state > information, referred to as a state token, about a resource as well > as ETags. A typical example of a state token is a lock token, and > lock tokens are the only state tokens defined in this specification. > > And I've taken this opening statement, and the fact that it never talks > about lock token submission in the "IF Header" section, to mean that > the primary purpose of the If: header was for a client to verify various > aspects of server state (like If-Match) before doing an operation. > > Above I outlined what I thought the *primary* purpose of the If: > header was in 2518. But there are stray comments in the 2518 > that make the If; header's purpose confused. We've fixed one > of those in 2518bis. But 2518bis still has the statement that the > server will only check the assertions on the URL's it chooses: > > When the If header is applied to a particular resource, the Tagged- > list productions MUST be searched to determine if any of the listed > resources match the operand resource(s) for the current method. If > none of the resource productions match the current resource then the > header MUST be ignored. If one of the resource productions does > match the name of the resource under consideration then the list > productions following the resource production MUST be applied to the > resource in the manner specified in the previous section. > > With that statement, the semantics and purpose of the If: header > gets confusing. It's like the server saying, > "you can ask me to check somethings, and I'll only check > the one's I want, and I won't tell you which one's I > didn't check" > It (2518) just doesn't make sense. I undermines what was > presented as the primary purpose of that header: For the client > to be able to request that the request be contingent on assertions > that he submits. > > A trivial, but non fatal, example of the problem the partial > evaluation creates for the client. Let's say a client has locked > a subtree of the URL space and is working with various resources > in it. He/She/It GET's and PUT's a lot of resources. Perhaps it's > making sure all the pages fit some corporate guidelines and tries > to correct mistakes. To be careful, it uses the IF: header to make > sure the resources are still locked as it progresses. But > unfortunately the server will only evaluate that request if thinks > it needs to. And for example, it might not evaluate it for GET > requests. If the resource is a large resource, a lot of time > and bandwidth could be wasted getting the resource if the > operation is later aborted/restarted when the client later finds > out that the lock has gone away. If the server had respected > the check in the first place, the client could have corrected > the situation more quickly. > > Again, it's not a fatal example, but I think it points out the > problem this can pose for the client. Another more significant > example might be a COPY command where one wants to make sure the > copy of the file one copies is the one that matches an ETAG or > is still locked. But the server might not even make that > check before doing the operation. > > I'd like to propose that we change the spec to say ALL of the > tagged assertions that the client submits in the IF: header be > evaluated by the server. > > This proposal is not contingent on any of the current IF: header > related proposals. All proposals should be able to benefit from > this change. > > Interoperability... if there are clients out there that submit > assertions on secondary resource that are actually false but > never evaluated by current servers, then those clients will > break, but that seems highly unlikely. > > Similarly, because it's unlikely that clients are currently > submitting assertions on secondary resources that actually > would evaluate to false but passing through, servers can > feel safe going ahead and evaluating the whole If: header. > > The only compatibility issue is transitional. New clients > can submit extra assertions, but they don't know if the > server is evaluating all of them because the server might > be following 2518 rather than a new spec. This means that > for a while, clients can only take advantage of this for > helpful checks, not critical checks. > > Thoughts? > > J. > > ------------------------------------------ > Phone: 914-784-7569 From w3c-dist-auth-request@w3.org Sun Oct 13 13:35:33 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22438 for ; Sun, 13 Oct 2002 13:35:33 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9DHaco23237; Sun, 13 Oct 2002 13:36:38 -0400 (EDT) Resent-Date: Sun, 13 Oct 2002 13:36:38 -0400 (EDT) Resent-Message-Id: <200210131736.g9DHaco23237@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9DHabB23211 for ; Sun, 13 Oct 2002 13:36:37 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA18140 for ; Sun, 13 Oct 2002 13:36:37 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Sun, 13 Oct 2002 13:25:15 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Sun, 13 Oct 2002 13:36:05 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Sun, 13 Oct 2002 13:36:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C272DF.013243A0" Subject: RE: If Header: evaluation of all assertions Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6847 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C272DF.013243A0 Content-Type: text/plain I agree that we should make this change, to simplify and clarify the semantics of the If header. I also agree with Jason that it is unlikely that any current client depends on the server not evaluating clauses in a tagged list (because they don't match operands of the request method), but it would be good to verify this. Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:nn683849@smallcue.com] Geoff suggested I start a new thread... I'm going to propose that ALL of the IF: header be evaluated by the server. ------_=_NextPart_001_01C272DF.013243A0 Content-Type: text/html RE: If Header: evaluation of all assertions

I agree that we should make this change, to simplify and
clarify the semantics of the If header.  I also agree with
Jason that it is unlikely that any current client depends
on the server not evaluating clauses in a tagged list
(because they don't match operands of the request method),
but it would be good to verify this.

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:nn683849@smallcue.com]

Geoff suggested I start a new thread...

I'm going to propose that ALL of the IF: header be evaluated
by the server. 

------_=_NextPart_001_01C272DF.013243A0-- From w3c-dist-auth-request@w3.org Sun Oct 13 14:27:18 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA22437 for ; Sun, 13 Oct 2002 13:35:33 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9DHalJ23289; Sun, 13 Oct 2002 13:36:47 -0400 (EDT) Resent-Date: Sun, 13 Oct 2002 13:36:47 -0400 (EDT) Resent-Message-Id: <200210131736.g9DHalJ23289@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9DHalB23259 for ; Sun, 13 Oct 2002 13:36:47 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA18145 for ; Sun, 13 Oct 2002 13:36:46 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Sun, 13 Oct 2002 13:25:26 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Sun, 13 Oct 2002 13:36:16 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Sun, 13 Oct 2002 13:36:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C272DF.07B74540" Subject: RE: Limiting the scope of an untagged If Header production (was: RE: If Header: evaluation of all assertions) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6848 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C272DF.07B74540 Content-Type: text/plain I am somewhat concerned about the effect of this change on the semantics of existing clients. For example, do any clients today submit the etag of both the source and the destination resource of a MOVE in an untagged If production? If so, this change would remove the etag check on the Destination, and thereby break the overwrite protection for that request. But if we won't be breaking existing clients, I fully support this change, since it simplifies and clarifies the semantics of the If header. Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Also, I would clarify what the untagged if production refers to, and it should probably refer only to the resource named in the Request-URI. ------_=_NextPart_001_01C272DF.07B74540 Content-Type: text/html RE: Limiting the scope of an untagged If Header production (was: RE: If Header: evaluation of all assertions)

I am somewhat concerned about the effect of this change on
the semantics of existing clients.

For example, do any clients today submit the etag of both the source
and the destination resource of a MOVE in an untagged If production?
If so, this change would remove the etag check on the Destination,
and thereby break the overwrite protection for that request.

But if we won't be breaking existing clients, I fully support this
change, since it simplifies and clarifies the semantics of the
If header.

Cheers,
Geoff 

-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]

Also, I would clarify what the untagged if production refers to, and it
should probably refer only to the resource named in the Request-URI.

------_=_NextPart_001_01C272DF.07B74540-- From w3c-dist-auth-request@w3.org Sun Oct 13 14:36:40 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA23296 for ; Sun, 13 Oct 2002 14:36:40 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9DIbnH26469; Sun, 13 Oct 2002 14:37:49 -0400 (EDT) Resent-Date: Sun, 13 Oct 2002 14:37:49 -0400 (EDT) Resent-Message-Id: <200210131837.g9DIbnH26469@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9DIbmB26442 for ; Sun, 13 Oct 2002 14:37:48 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA26247 for ; Sun, 13 Oct 2002 14:37:46 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id LAA02928 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Sun, 13 Oct 2002 11:37:45 -0700 Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by sunbelt.seagull.net (8.9.3) with ESMTP id LAA02912 sender obsfucated@us.ibm.com; Sun, 13 Oct 2002 11:37:44 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9DIbCDn274754; Sun, 13 Oct 2002 14:37:13 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9DIbAoM027758; Sun, 13 Oct 2002 14:37:10 -0400 To: "Clemm, Geoff" Cc: "'Webdav WG'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Jason Crawford Message-ID: Date: Sun, 13 Oct 2002 14:37:08 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0|September 26, 2002) at 10/13/2002 14:37:10, Serialize complete at 10/13/2002 14:37:10 Content-Type: text/plain; charset="us-ascii" Subject: RE: Limiting the scope of an untagged If Header production Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6849 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I also support redefining the untagged if: header to only apply to the request URL. FWIW I'd also support removing support for untagged headers... but that's not the proposal on the table. As you indicated though, I'd like to know how this would affect current clients. ------------------------------------------ Phone: 914-784-7569 From w3c-dist-auth-request@w3.org Mon Oct 14 01:28:41 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id BAA00742 for ; Mon, 14 Oct 2002 01:28:40 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9E5T6c08226; Mon, 14 Oct 2002 01:29:06 -0400 (EDT) Resent-Date: Mon, 14 Oct 2002 01:29:06 -0400 (EDT) Resent-Message-Id: <200210140529.g9E5T6c08226@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9E5T3B08196 for ; Mon, 14 Oct 2002 01:29:03 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id BAA22989 for ; Mon, 14 Oct 2002 01:29:02 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id WAA21126 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Sun, 13 Oct 2002 22:29:00 -0700 Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by sunbelt.seagull.net (8.9.3) with ESMTP id WAA21103 sender obsfucated@us.ibm.com; Sun, 13 Oct 2002 22:28:58 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9E5SRxw122206; Mon, 14 Oct 2002 01:28:27 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9E5SQoN036650; Mon, 14 Oct 2002 01:28:26 -0400 To: "Julian Reschke" Cc: "Clemm, Geoff" , "'Webdav WG'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Jason Crawford Message-ID: Date: Mon, 14 Oct 2002 01:28:21 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0|September 26, 2002) at 10/14/2002 01:28:25, Serialize complete at 10/14/2002 01:28:25 Content-Type: text/plain; charset="us-ascii" Subject: RE: Variant Support for WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6850 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I don't have a lot of time to spend on this given how many discussion threads we have alive right now, but just a quick comment... Could we possibly implement this in a way that meshes with how we handle other live resources? Perhaps with the dav:source property? It can just tell you at what URL's to find the variants and optionally give clues about how the variants are selected? This might actually be a good defining use-case for the dav:source property. Also, what is our target document for this? Should I add an issue for this so that it doesn't get lost? J. ------------------------------------------ Phone: 914-784-7569 From w3c-dist-auth-request@w3.org Mon Oct 14 04:37:30 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12261 for ; Mon, 14 Oct 2002 04:37:30 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9E8cbJ06165; Mon, 14 Oct 2002 04:38:37 -0400 (EDT) Resent-Date: Mon, 14 Oct 2002 04:38:37 -0400 (EDT) Resent-Message-Id: <200210140838.g9E8cbJ06165@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9E8caB06139 for ; Mon, 14 Oct 2002 04:38:36 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA21852 for ; Mon, 14 Oct 2002 04:38:35 -0400 Received: from greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Mon, 14 Oct 2002 10:37:33 +0200 Date: Mon, 14 Oct 2002 10:37:35 +0200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v546) From: Stefan Eissing To: "'Webdav WG'" In-Reply-To: Message-Id: <308E23B7-DF50-11D6-9950-00039384827E@greenbytes.de> X-Mailer: Apple Mail (2.546) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g9E8caB06139 Subject: Re: If Header: evaluation of all assertions Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6851 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit I agree that we should make the change proposed by Jason. As to verification: we could encourage people on the interop list to verify, once we have updated test servers. How would the litmus test be affected by the change? //Stefan Am Sonntag, 13.10.02, um 19:36 Uhr (Europe/Berlin) schrieb Clemm, Geoff: > I agree that we should make this change, to simplify and > clarify the semantics of the If header.  I also agree with > Jason that it is unlikely that any current client depends > on the server not evaluating clauses in a tagged list > (because they don't match operands of the request method), > but it would be good to verify this. > > Cheers, > Geoff > > -----Original Message----- > From: Jason Crawford [mailto:nn683849@smallcue.com] > > Geoff suggested I start a new thread... > > I'm going to propose that ALL of the IF: header be evaluated > by the server.  > From w3c-dist-auth-request@w3.org Mon Oct 14 04:42:37 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA12405 for ; Mon, 14 Oct 2002 04:42:37 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9E8hxP06913; Mon, 14 Oct 2002 04:43:59 -0400 (EDT) Resent-Date: Mon, 14 Oct 2002 04:43:59 -0400 (EDT) Resent-Message-Id: <200210140843.g9E8hxP06913@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9E8hwB06883 for ; Mon, 14 Oct 2002 04:43:58 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA22875 for ; Mon, 14 Oct 2002 04:43:57 -0400 Received: from greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Mon, 14 Oct 2002 10:43:43 +0200 Date: Mon, 14 Oct 2002 10:43:46 +0200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "'Webdav WG'" To: "Clemm, Geoff" From: Stefan Eissing In-Reply-To: Message-Id: <0D66F312-DF51-11D6-9950-00039384827E@greenbytes.de> X-Mailer: Apple Mail (2.546) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g9E8hwB06883 Subject: Re: Limiting the scope of an untagged If Header production (was: RE: If Header: evaluation of all assertions) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6852 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Another possible "breakage" is use of the untagged if header for PUT on unmapped resources. At least our server uses then the untagged production to check the parent resource. //Stefan Am Sonntag, 13.10.02, um 19:36 Uhr (Europe/Berlin) schrieb Clemm, Geoff: > I am somewhat concerned about the effect of this change on > the semantics of existing clients. > > For example, do any clients today submit the etag of both the source > and the destination resource of a MOVE in an untagged If production? > If so, this change would remove the etag check on the Destination, > and thereby break the overwrite protection for that request. > > But if we won't be breaking existing clients, I fully support this > change, since it simplifies and clarifies the semantics of the > If header. > > Cheers, > Geoff  > > -----Original Message----- > From: Lisa Dusseault [mailto:lisa@xythos.com] > > Also, I would clarify what the untagged if production refers to, and it > should probably refer only to the resource named in the Request-URI. > From w3c-dist-auth-request@w3.org Mon Oct 14 09:22:47 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19172 for ; Mon, 14 Oct 2002 09:22:46 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9ED8d405414; Mon, 14 Oct 2002 09:08:39 -0400 (EDT) Resent-Date: Mon, 14 Oct 2002 09:08:39 -0400 (EDT) Resent-Message-Id: <200210141308.g9ED8d405414@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9ED8cB05388 for ; Mon, 14 Oct 2002 09:08:38 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA09665 for ; Mon, 14 Oct 2002 09:08:38 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 14 Oct 2002 08:57:15 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 14 Oct 2002 09:08:07 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Mon, 14 Oct 2002 09:08:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27382.B9DE94F0" Subject: RE: Variant Support for WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6853 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27382.B9DE94F0 Content-Type: text/plain I believe that is what the Variant draft does; in particular, the DAV:variant-set live property contains the URLs of the variants and the DAV:default-variant indicates which of those is the default. I'm not quite sure about what you have in mind by a clue how to select a variant ... they can do a PROPFIND on the various variants and see how they differ ... As for what is the target document, when it was stripped out of 3253, some folks thought it should be a separate draft, and others thought it should be in the next revision of 3253. Adding an issue for it in the 2518 issues list would be good as well, since it is likely to be of interest to folks that are not concerned with versioning, and therefore might be appropriate for a follow-on draft to 2518 (that introduces new generic authoring functionality). Cheers, Geoff -----Original Message----- From: Jason Crawford [mailto:nn683849@smallcue.com] Sent: Monday, October 14, 2002 1:28 AM To: Julian Reschke Cc: Clemm, Geoff; 'Webdav WG' Subject: RE: Variant Support for WebDAV I don't have a lot of time to spend on this given how many discussion threads we have alive right now, but just a quick comment... Could we possibly implement this in a way that meshes with how we handle other live resources? Perhaps with the dav:source property? It can just tell you at what URL's to find the variants and optionally give clues about how the variants are selected? This might actually be a good defining use-case for the dav:source property. Also, what is our target document for this? Should I add an issue for this so that it doesn't get lost? J. ------------------------------------------ Phone: 914-784-7569 ------_=_NextPart_001_01C27382.B9DE94F0 Content-Type: text/html RE: Variant Support for WebDAV

I believe that is what the Variant draft does; in particular,
the DAV:variant-set live property contains the URLs of the variants
and the DAV:default-variant indicates which of those is the default.
I'm not quite sure about what you have in mind by a clue how to
select a variant ... they can do a PROPFIND on the various variants
and see how they differ ...

As for what is the target document, when it was stripped out of
3253, some folks thought it should be a separate draft, and others
thought it should be in the next revision of 3253.  Adding an
issue for it in the 2518 issues list would be good as well, since
it is likely to be of interest to folks that are not concerned with
versioning, and therefore might be appropriate for a follow-on
draft to 2518 (that introduces new generic authoring functionality).

Cheers,
Geoff

-----Original Message-----
From: Jason Crawford [mailto:nn683849@smallcue.com]
Sent: Monday, October 14, 2002 1:28 AM
To: Julian Reschke
Cc: Clemm, Geoff; 'Webdav WG'
Subject: RE: Variant Support for WebDAV


I don't have a lot of time to spend on this given how many discussion
threads we have
alive right now, but just a quick comment...

Could we possibly implement this in a way that meshes with how we handle
other
live resources?   Perhaps with the dav:source property?   It can just tell
you at what
URL's to find the variants and optionally give clues about how the
variants are
selected?   This might actually be a good defining use-case for the
dav:source
property.

Also, what is our target document for this?   Should I add an issue for
this so that
it doesn't get lost?

J.

------------------------------------------
Phone: 914-784-7569

------_=_NextPart_001_01C27382.B9DE94F0-- From w3c-dist-auth-request@w3.org Mon Oct 14 09:22:49 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19186 for ; Mon, 14 Oct 2002 09:22:49 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9ED8m605570; Mon, 14 Oct 2002 09:08:48 -0400 (EDT) Resent-Date: Mon, 14 Oct 2002 09:08:48 -0400 (EDT) Resent-Message-Id: <200210141308.g9ED8m605570@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9ED8mB05541 for ; Mon, 14 Oct 2002 09:08:48 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA09684 for ; Mon, 14 Oct 2002 09:08:48 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 14 Oct 2002 08:57:25 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 14 Oct 2002 09:08:17 -0400 Message-ID: From: "Clemm, Geoff" To: "WebDAV (E-mail)" Date: Mon, 14 Oct 2002 09:08:08 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27382.BD984190" Subject: RE: DAV:can-overwrite Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6854 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27382.BD984190 Content-Type: text/plain From: Julian Reschke [mailto:julian.reschke@greenbytes.de] ... the binding draft borrows it's error handling from RFC3253, but it's Overwrite header handling from RFC2518 -- but a server can't do both. An RFC2518 compliant server would return a 412 (Precondition failed), an RFC3253 compliant server would return 403/409 with DAV:error/DAV:can-overwrite. This isn't a severe problem, but it's annyoing. I think a possible way out of this dilemma is to extend the RFC3253 rules by saying that the DAV:error response may also be used for HTTP status 412 (por possibly more or all error codes). We could then have the BIND-enhanced server return HTTP/1.1 412 Precondition Failed Content-Type: text/xml; charset="utf-8" Content-Length: xxxx At least for our client this would make it much easier to continue to have a *generic* method of mapping responses to Java exceptions. [1] [2] I'd be happy to allow error codes for 412, or to use a DAV:overwrite tag in the BIND request body, instead of the Overwrite header. I'm slightly more inclined to do the latter, since bundling all the parameters into the request body seems like a more meaningful "unification" than re-using the Overwrite header, but either way is fine with me. Cheers, Geoff ------_=_NextPart_001_01C27382.BD984190 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: DAV:can-overwrite

   From: Julian Reschke [mailto:julian.reschke@green= bytes.de]

   ... the binding draft borrows it's error = handling from RFC3253, but
   it's Overwrite header handling from = RFC2518 -- but a server can't
   do both. An RFC2518 compliant server = would return a 412
   (Precondition failed), an RFC3253 = compliant server would return
   403/409 with = DAV:error/DAV:can-overwrite.

   This isn't a severe problem, but it's = annyoing.

   I think a possible way out of this = dilemma is to extend the RFC3253
   rules by saying that the DAV:error = response may also be used for
   HTTP status 412 (por possibly more or = all error codes). We could
   then have the BIND-enhanced server = return

   HTTP/1.1 412 Precondition Failed
   Content-Type: text/xml; = charset=3D"utf-8"
   Content-Length: xxxx

   <?xml version=3D"1.0" = encoding=3D"utf-8" ?>
   <D:error = xmlns:D=3D"DAV:">
    <D:can-overwrite/>
   </D:error>

   At least for our client this would make = it much easier to continue
   to have a *generic* method of mapping = responses to Java exceptions.

   [1] <http://greenbytes.de/tech/webdav/rfc2518.html#HEADER_O= verwrite>
   [2] <http://greenbytes.de/tech/webdav/rfc3253.html#rfc.sect= ion.1.6>

I'd be happy to allow error codes for 412, or to use = a
DAV:overwrite tag in the BIND request body, instead = of the
Overwrite header.  I'm slightly more inclined = to do the
latter, since bundling all the parameters into the = request
body seems like a more meaningful = "unification" than re-using
the Overwrite header, but either way is fine with = me.

Cheers,
Geoff

------_=_NextPart_001_01C27382.BD984190-- From w3c-dist-auth-request@w3.org Mon Oct 14 09:35:59 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19710 for ; Mon, 14 Oct 2002 09:35:59 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9EDMDA08449; Mon, 14 Oct 2002 09:22:13 -0400 (EDT) Resent-Date: Mon, 14 Oct 2002 09:22:13 -0400 (EDT) Resent-Message-Id: <200210141322.g9EDMDA08449@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9EDMCB08423 for ; Mon, 14 Oct 2002 09:22:12 -0400 (EDT) Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA12978 for ; Mon, 14 Oct 2002 09:22:11 -0400 Received: from daehub01.software-ag.de by server8a.software-ag.de; (8.11.6/8.9.3) id g9EDM7809495; Mon, 14 Oct 2002 15:22:07 +0200 Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2653.19) id ; Mon, 14 Oct 2002 15:21:30 +0200 Message-ID: From: "Nevermann, Dr., Peter" To: "'slide-user@jakarta.apache.org'" , "'w3c-dist-auth@w3c.org'" Date: Mon, 14 Oct 2002 15:22:04 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: Looking for a client for testing WebDAV (+DeltaV +DASL +ACL) serv ers? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6855 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Try NetTool 1.0.4, created by Neil O'Toole, downloadable from http://www.nettool.org. It was originally meant for developers dealing with SOAP but now it became useful for developers in the WebDAV area too. Regards, Peter From w3c-dist-auth-request@w3.org Mon Oct 14 09:58:55 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA20608 for ; Mon, 14 Oct 2002 09:58:54 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9EDisb12395; Mon, 14 Oct 2002 09:44:54 -0400 (EDT) Resent-Date: Mon, 14 Oct 2002 09:44:54 -0400 (EDT) Resent-Message-Id: <200210141344.g9EDisb12395@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9EDirB12369 for ; Mon, 14 Oct 2002 09:44:53 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA21133 for ; Mon, 14 Oct 2002 09:44:53 -0400 Received: (qmail 28664 invoked by uid 0); 14 Oct 2002 13:44:22 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp015-rz3) with SMTP; 14 Oct 2002 13:44:22 -0000 From: "Julian Reschke" To: "WebDAV \(E-mail\)" Date: Mon, 14 Oct 2002 15:44:21 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: BIND draft -- error conditions Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6856 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit 1) What is the expected response for the case where the request URI is not mapped? 1a) 404 NOT FOUND? 1b) 409 Conflict with DAV:error/DAV:bind-into-collection? 2) What is the expected response code for the case where the resource to be bound does not exist (DAV:href in the request is unmapped)? 2a) 404 NOT FOUND? 1b) 409 Conflict with DAV:error/DAV:??? Obviously, I'd prefer not to have 1a) and 2a). Julian From w3c-dist-auth-request@w3.org Mon Oct 14 10:21:28 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21499 for ; Mon, 14 Oct 2002 10:21:27 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9EE9VV16387; Mon, 14 Oct 2002 10:09:31 -0400 (EDT) Resent-Date: Mon, 14 Oct 2002 10:09:31 -0400 (EDT) Resent-Message-Id: <200210141409.g9EE9VV16387@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9EE9UB16360 for ; Mon, 14 Oct 2002 10:09:30 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA26777 for ; Mon, 14 Oct 2002 10:09:30 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 14 Oct 2002 09:58:07 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id ; Mon, 14 Oct 2002 10:09:00 -0400 Message-ID: From: "Clemm, Geoff" To: "WebDAV (E-mail)" Date: Mon, 14 Oct 2002 10:08:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2738B.37E83B50" Subject: RE: BIND draft -- error conditions Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6857 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2738B.37E83B50 Content-Type: text/plain; charset="iso-8859-1" Good catch. We are missing a DAV:bound-resource-exists condition (I'll add one). The 404 refers to the request-URL not existing, so that clearly does not apply to this case. As for case (1), 404 seems to be the most meaningful status to return. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Monday, October 14, 2002 9:44 AM To: WebDAV (E-mail) Subject: BIND draft -- error conditions 1) What is the expected response for the case where the request URI is not mapped? 1a) 404 NOT FOUND? 1b) 409 Conflict with DAV:error/DAV:bind-into-collection? 2) What is the expected response code for the case where the resource to be bound does not exist (DAV:href in the request is unmapped)? 2a) 404 NOT FOUND? 1b) 409 Conflict with DAV:error/DAV:??? Obviously, I'd prefer not to have 1a) and 2a). Julian ------_=_NextPart_001_01C2738B.37E83B50 Content-Type: text/html; charset="iso-8859-1" RE: BIND draft -- error conditions

Good catch.  We are missing a DAV:bound-resource-exists
condition (I'll add one).  The 404 refers to the request-URL
not existing, so that clearly does not apply to this case.
As for case (1), 404 seems to be the most meaningful status
to return.

Cheers,
Geoff



-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Monday, October 14, 2002 9:44 AM
To: WebDAV (E-mail)
Subject: BIND draft -- error conditions



1) What is the expected response for the case where the request URI is not
mapped?

1a) 404 NOT FOUND?
1b) 409 Conflict with DAV:error/DAV:bind-into-collection?

2) What is the expected response code for the case where the resource to be
bound does not exist (DAV:href in the request is unmapped)?

2a) 404 NOT FOUND?
1b) 409 Conflict with DAV:error/DAV:???

Obviously, I'd prefer not to have 1a) and 2a).

Julian

------_=_NextPart_001_01C2738B.37E83B50-- From w3c-dist-auth-request@w3.org Mon Oct 14 10:31:48 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA21783 for ; Mon, 14 Oct 2002 10:31:48 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9EEWlA19074; Mon, 14 Oct 2002 10:32:47 -0400 (EDT) Resent-Date: Mon, 14 Oct 2002 10:32:47 -0400 (EDT) Resent-Message-Id: <200210141432.g9EEWlA19074@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9EEWkB19044 for ; Mon, 14 Oct 2002 10:32:46 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA31488 for ; Mon, 14 Oct 2002 10:32:45 -0400 Received: (qmail 18082 invoked by uid 0); 14 Oct 2002 14:32:14 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp006-rz3) with SMTP; 14 Oct 2002 14:32:14 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "WebDAV \(E-mail\)" Date: Mon, 14 Oct 2002 16:32:14 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: BIND draft -- error conditions Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6858 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Clemm, Geoff > Sent: Monday, October 14, 2002 4:09 PM > To: WebDAV (E-mail) > Subject: RE: BIND draft -- error conditions > > > Good catch. We are missing a DAV:bound-resource-exists > condition (I'll add one). The 404 refers to the request-URL > not existing, so that clearly does not apply to this case. > As for case (1), 404 seems to be the most meaningful status > to return. Perfect. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Oct 14 13:10:07 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26653 for ; Mon, 14 Oct 2002 13:10:07 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9EHASp14142; Mon, 14 Oct 2002 13:10:28 -0400 (EDT) Resent-Date: Mon, 14 Oct 2002 13:10:28 -0400 (EDT) Resent-Message-Id: <200210141710.g9EHASp14142@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9EHARB14116 for ; Mon, 14 Oct 2002 13:10:27 -0400 (EDT) Received: from out001.iad.hostedmail.net (out001.iad.hostedmail.net [209.225.56.23]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA03825 for ; Mon, 14 Oct 2002 13:10:27 -0400 Received: from 10.158.10.13 by out001.iad.hostedmail.net (InterScan E-Mail VirusWall NT); Mon, 14 Oct 2002 13:09:35 -0400 (Eastern Daylight Time) Received: from in001.iad.hostedmail.net ([10.158.14.181]) by atl1simr001.tco.tc with Microsoft SMTPSVC(5.0.2195.4453); Mon, 14 Oct 2002 13:09:34 -0400 Received: from xythoslap ([216.36.77.241]) by in001.iad.hostedmail.net with Microsoft SMTPSVC(5.0.2195.4453); Mon, 14 Oct 2002 13:09:34 -0400 From: "Lisa Dusseault" To: "'Stefan Eissing'" , "'Clemm, Geoff'" Cc: "'Webdav WG'" Date: Mon, 14 Oct 2002 10:09:25 -0700 Message-ID: <000001c273a4$73b137e0$b701a8c0@xythoslap> 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.3416 Importance: Normal In-Reply-To: <0D66F312-DF51-11D6-9950-00039384827E@greenbytes.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 X-OriginalArrivalTime: 14 Oct 2002 17:09:34.0298 (UTC) FILETIME=[77E2D3A0:01C273A4] Subject: RE: Limiting the scope of an untagged If Header production (was: RE: If Header: evaluation of all assertions) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6859 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit That wouldn't necessarily break, depending on what you're checking. I assume you're checking a lock token because etags aren't defined for collections. E.g we could also make RFC2518bis clear on whether you can apply a lock token (for a depth infinity lock) to any URL included in the scope of the lock. If we require servers to accept this as a valid use of the lock token, then the untagged production applying to the Request-URI still works in this case. lisa > -----Original Message----- > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org] > On Behalf Of Stefan Eissing > Sent: Monday, October 14, 2002 1:44 AM > To: Clemm, Geoff > Cc: 'Webdav WG' > Subject: Re: Limiting the scope of an untagged If Header production (was: > RE: If Header: evaluation of all assertions) > > > Another possible "breakage" is use of the untagged if header for > PUT on unmapped resources. At least our server uses then the > untagged production to check the parent resource. > > //Stefan > > Am Sonntag, 13.10.02, um 19:36 Uhr (Europe/Berlin) schrieb Clemm, Geoff: > > > I am somewhat concerned about the effect of this change on > > the semantics of existing clients. > > > > For example, do any clients today submit the etag of both the source > > and the destination resource of a MOVE in an untagged If production? > > If so, this change would remove the etag check on the Destination, > > and thereby break the overwrite protection for that request. > > > > But if we won't be breaking existing clients, I fully support this > > change, since it simplifies and clarifies the semantics of the > > If header. > > > > Cheers, > > Geoff > > > > -----Original Message----- > > From: Lisa Dusseault [mailto:lisa@xythos.com] > > > > Also, I would clarify what the untagged if production refers to, and it > > should probably refer only to the resource named in the Request-URI. > > > From w3c-dist-auth-request@w3.org Mon Oct 14 13:20:25 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26860 for ; Mon, 14 Oct 2002 13:20:25 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9EHLTs15737; Mon, 14 Oct 2002 13:21:29 -0400 (EDT) Resent-Date: Mon, 14 Oct 2002 13:21:29 -0400 (EDT) Resent-Message-Id: <200210141721.g9EHLTs15737@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9EHLSB15711 for ; Mon, 14 Oct 2002 13:21:28 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA08918 for ; Mon, 14 Oct 2002 13:21:27 -0400 Received: from greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Mon, 14 Oct 2002 19:20:54 +0200 Date: Mon, 14 Oct 2002 19:20:50 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "'Clemm, Geoff'" , "'Webdav WG'" To: "Lisa Dusseault" From: Stefan Eissing In-Reply-To: <000001c273a4$73b137e0$b701a8c0@xythoslap> Message-Id: <48E73B17-DF99-11D6-9950-00039384827E@greenbytes.de> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: Re: Limiting the scope of an untagged If Header production (was: RE: If Header: evaluation of all assertions) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6860 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Lisa, good idea. However this does not cover the case where the collection has a shallow, exclusive lock. I don't know now relevant/important this case is. Our client does, for example, not use the untagged production, exactly because server implementation differ most on this feature. //Stefan Am Montag, 14.10.02, um 19:09 Uhr (Europe/Berlin) schrieb Lisa Dusseault: > That wouldn't necessarily break, depending on what you're checking. I > assume you're checking a lock token because etags aren't defined for > collections. > > E.g we could also make RFC2518bis clear on whether you can apply a lock > token (for a depth infinity lock) to any URL included in the scope of > the lock. If we require servers to accept this as a valid use of the > lock token, then the untagged production applying to the Request-URI > still works in this case. > > lisa > >> -----Original Message----- >> From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org] >> On Behalf Of Stefan Eissing >> Sent: Monday, October 14, 2002 1:44 AM >> To: Clemm, Geoff >> Cc: 'Webdav WG' >> Subject: Re: Limiting the scope of an untagged If Header production > (was: >> RE: If Header: evaluation of all assertions) >> >> >> Another possible "breakage" is use of the untagged if header for >> PUT on unmapped resources. At least our server uses then the >> untagged production to check the parent resource. >> >> //Stefan >> >> Am Sonntag, 13.10.02, um 19:36 Uhr (Europe/Berlin) schrieb Clemm, > Geoff: >> >>> I am somewhat concerned about the effect of this change on >>> the semantics of existing clients. >>> >>> For example, do any clients today submit the etag of both the source >>> and the destination resource of a MOVE in an untagged If production? >>> If so, this change would remove the etag check on the Destination, >>> and thereby break the overwrite protection for that request. >>> >>> But if we won't be breaking existing clients, I fully support this >>> change, since it simplifies and clarifies the semantics of the >>> If header. >>> >>> Cheers, >>> Geoff >>> >>> -----Original Message----- >>> From: Lisa Dusseault [mailto:lisa@xythos.com] >>> >>> Also, I would clarify what the untagged if production refers to, and > it >>> should probably refer only to the resource named in the Request-URI. >>> >> > From w3c-dist-auth-request@w3.org Mon Oct 14 13:38:59 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA27329 for ; Mon, 14 Oct 2002 13:38:59 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9EHeBc18527; Mon, 14 Oct 2002 13:40:11 -0400 (EDT) Resent-Date: Mon, 14 Oct 2002 13:40:11 -0400 (EDT) Resent-Message-Id: <200210141740.g9EHeBc18527@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9EHe9B18499 for ; Mon, 14 Oct 2002 13:40:09 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA17190 for ; Mon, 14 Oct 2002 13:40:08 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id KAA19252 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Mon, 14 Oct 2002 10:40:05 -0700 Received: from e5.ny.us.ibm.com (e5.ny.us.ibm.com [32.97.182.105]) by sunbelt.seagull.net (8.9.3) with ESMTP id KAA19141 sender obsfucated@us.ibm.com; Mon, 14 Oct 2002 10:40:01 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e5.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9EHdThG098092; Mon, 14 Oct 2002 13:39:29 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9EHdRnc142862; Mon, 14 Oct 2002 13:39:28 -0400 To: "Lisa Dusseault" Cc: "'Clemm, Geoff'" , "'Stefan Eissing'" , "'Webdav WG'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Jason Crawford Message-ID: Date: Mon, 14 Oct 2002 13:39:27 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0|September 26, 2002) at 10/14/2002 13:39:27, Serialize complete at 10/14/2002 13:39:27 Content-Type: text/plain; charset="us-ascii" Subject: RE: Limiting the scope of an untagged If Header production (was: RE: If Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6861 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I suspect there are a number of situations in which this change could break a client, but do we actually know how clients are using untagged If: header productions? The compatibility issue might be moot. Client writers, do you use untagged IF: header productions? If so, how? J. ------------------------------------------ Phone: 914-784-7569 From w3c-dist-auth-request@w3.org Mon Oct 14 16:29:02 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA01903 for ; Mon, 14 Oct 2002 16:29:01 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9EKPgT19867; Mon, 14 Oct 2002 16:25:42 -0400 (EDT) Resent-Date: Mon, 14 Oct 2002 16:25:42 -0400 (EDT) Resent-Message-Id: <200210142025.g9EKPgT19867@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9EKPfB19832 for ; Mon, 14 Oct 2002 16:25:41 -0400 (EDT) Received: from dream.darwin.nasa.gov (betlik.darwin.nasa.gov [198.123.160.11]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA04077 for ; Mon, 14 Oct 2002 16:25:40 -0400 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 g9EKPIh10840 for ; Mon, 14 Oct 2002 13:25:20 -0700 (PDT) Message-ID: <3DAB282E.2090301@cse.ucsc.edu> Date: Mon, 14 Oct 2002 13:25:18 -0700 From: Elias Sinderson Reply-To: "'Webdav WG'" User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.4.1) Gecko/20020518 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: "'Webdav WG'" References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: If Header: evaluation of all assertions Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6862 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit This is a sensible proposal - If a client submits an IF: header with a request then the server should check the conditions regardless of whether it thinks the conditions apply. As Jasons' example showed, there may be client application sematics which are unknown to the server, hence the server should not make any assumptions about whether the IF: header applies to a given request. Elias Jason Crawford wrote: >[...] >I'd like to propose that we change the spec to say ALL of the >tagged assertions that the client submits in the IF: header be >evaluated by the server. >[...] > From w3c-dist-auth-request@w3.org Tue Oct 15 04:34:36 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA23735 for ; Tue, 15 Oct 2002 04:34:36 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9F8Z1V29755; Tue, 15 Oct 2002 04:35:01 -0400 (EDT) Resent-Date: Tue, 15 Oct 2002 04:35:01 -0400 (EDT) Resent-Message-Id: <200210150835.g9F8Z1V29755@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9F8Z0B29687 for ; Tue, 15 Oct 2002 04:35:00 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA28087 for ; Tue, 15 Oct 2002 04:34:59 -0400 Received: (qmail 7345 invoked by uid 0); 15 Oct 2002 08:34:28 -0000 Received: from pd950c3ed.dip.t-dialin.net (HELO lisa) (217.80.195.237) by mail.gmx.net (mp004-rz3) with SMTP; 15 Oct 2002 08:34:28 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "WebDAV \(E-mail\)" Date: Tue, 15 Oct 2002 10:34:26 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Subject: RE: DAV:can-overwrite Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6863 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Clemm, Geoff > Sent: Monday, October 14, 2002 3:08 PM > To: WebDAV (E-mail) > Subject: RE: DAV:can-overwrite > > > From: Julian Reschke [mailto:julian.reschke@greenbytes.de] > ... the binding draft borrows it's error handling from RFC3253, but > it's Overwrite header handling from RFC2518 -- but a server can't > do both. An RFC2518 compliant server would return a 412 > (Precondition failed), an RFC3253 compliant server would return > 403/409 with DAV:error/DAV:can-overwrite. > This isn't a severe problem, but it's annyoing. > I think a possible way out of this dilemma is to extend the RFC3253 > rules by saying that the DAV:error response may also be used for > HTTP status 412 (por possibly more or all error codes). We could > then have the BIND-enhanced server return > HTTP/1.1 412 Precondition Failed > Content-Type: text/xml; charset="utf-8" > Content-Length: xxxx > > > > > At least for our client this would make it much easier to continue > to have a *generic* method of mapping responses to Java exceptions. > [1] > [2] > > I'd be happy to allow error codes for 412, or to use a > DAV:overwrite tag in the BIND request body, instead of the > Overwrite header. I'm slightly more inclined to do the > latter, since bundling all the parameters into the request > body seems like a more meaningful "unification" than re-using > the Overwrite header, but either way is fine with me. I think I prefer the former -- obviously we have to choose between - making it as simple as possible for BIND - making it as consistent as possible for RFC2518 Moving the overwrite flag into the request body solves just one problem -- allowing the DAV:error element (or actually *specifying* it) for response codes != 403/409 simplifies the error mapping in other cases as well. So my vote would be to leave the BIND spec as it is, and to add an entry to the RFC2518 issues list saying that 4xx/5xx response bodies MAY use the DAV:error format defined in RFC3253. We could then start a separate activity to specify precondition names for common RFC2518 error conditions (such as parent collection must exist). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Oct 15 04:53:43 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA24002 for ; Tue, 15 Oct 2002 04:53:42 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9F8qPX01584; Tue, 15 Oct 2002 04:52:25 -0400 (EDT) Resent-Date: Tue, 15 Oct 2002 04:52:25 -0400 (EDT) Resent-Message-Id: <200210150852.g9F8qPX01584@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9F8qOB01554 for ; Tue, 15 Oct 2002 04:52:24 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA31241 for ; Tue, 15 Oct 2002 04:52:24 -0400 Received: (qmail 2547 invoked by uid 0); 15 Oct 2002 08:51:53 -0000 Received: from pd950c3ed.dip.t-dialin.net (HELO lisa) (217.80.195.237) by mail.gmx.net (mp001-rz3) with SMTP; 15 Oct 2002 08:51:53 -0000 From: "Julian Reschke" To: "Jason Crawford" , "'Webdav WG'" Date: Tue, 15 Oct 2002 10:51:46 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Subject: RE: Variant Support for WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6864 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Monday, October 14, 2002 7:28 AM > To: Julian Reschke > Cc: Clemm, Geoff; 'Webdav WG' > Subject: RE: Variant Support for WebDAV > > > > I don't have a lot of time to spend on this given how many discussion > threads we have > alive right now, but just a quick comment... > > Could we possibly implement this in a way that meshes with how we handle other > live resources? Perhaps with the dav:source property? It can just tell you at what > URL's to find the variants and optionally give clues about how the variants are > selected? This might actually be a good defining use-case for the dav:source > property. > ... I think variants and sources are clearly different things. In HTTP, "Variant" is a synonym for "representation" -- a resource can have many representations, and HTTP already defines how a server can signal depending on which request criteria a particular variant was chosen ("variant" header), and optionally what the more specific URI for this representation is ("content-location" header). Alternatively, a source of a resource is *not* a variant of the resource, and thus should not be treated as such. So at a minimum, a spec about variant handling in WebDAV must - be compatible with the terminology in RFC2616 - should elevate the vary header and the content location headers to live WebDAV properties - should clarify the semantics variant-selection-relevant request headers for the various WebDAV methods On the other hand, it may also provide a framework for authoring varying resources (and I think this is the primary target of Geoff's draft). Last but not least: we should keep in mind that right now proper variant handling is only possible if ugly workarounds are use if the client uses IE as a browser (see bug report at [1] -- note that the bug is *still* present in IE6). Julian [1] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Oct 15 08:39:06 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA28984 for ; Tue, 15 Oct 2002 08:39:05 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9FCdh109408; Tue, 15 Oct 2002 08:39:43 -0400 (EDT) Resent-Date: Tue, 15 Oct 2002 08:39:43 -0400 (EDT) Resent-Message-Id: <200210151239.g9FCdh109408@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9FCdgB09381 for ; Tue, 15 Oct 2002 08:39:42 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id IAA10898 for ; Tue, 15 Oct 2002 08:39:41 -0400 Received: (qmail 22540 invoked by uid 0); 15 Oct 2002 12:39:10 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp017-rz3) with SMTP; 15 Oct 2002 12:39:10 -0000 From: "Julian Reschke" To: "'Webdav WG'" Date: Tue, 15 Oct 2002 14:39:09 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Subject: BIND response codes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6865 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, would it possibly make sense to define the BIND response for the case where the client attempts to create a new binding to a collection, but the server only supports bindings to non-collections? -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Oct 15 13:40:34 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08934 for ; Tue, 15 Oct 2002 13:40:34 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9FHfA828195; Tue, 15 Oct 2002 13:41:10 -0400 (EDT) Resent-Date: Tue, 15 Oct 2002 13:41:10 -0400 (EDT) Resent-Message-Id: <200210151741.g9FHfA828195@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9FHf8B28168 for ; Tue, 15 Oct 2002 13:41:09 -0400 (EDT) Received: from mail.cruzio.com (root@mail.cruzio.com [63.249.95.37]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA25937 for ; Tue, 15 Oct 2002 13:41:08 -0400 Received: from Tycho (dsl3-63-249-68-7.cruzio.com [63.249.68.7]) by mail.cruzio.com with SMTP id KAA24181 for ; Tue, 15 Oct 2002 10:41:01 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV \(E-mail\)" Date: Tue, 15 Oct 2002 10:38:08 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Subject: RE: BIND draft -- error conditions Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6866 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sounds good to me as well. - Jim > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: Monday, October 14, 2002 7:32 AM > To: Clemm, Geoff; WebDAV (E-mail) > Subject: RE: BIND draft -- error conditions > > > > > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On > > Behalf Of Clemm, Geoff > > Sent: Monday, October 14, 2002 4:09 PM > > To: WebDAV (E-mail) > > Subject: RE: BIND draft -- error conditions > > > > > > Good catch. We are missing a DAV:bound-resource-exists > > condition (I'll add one). The 404 refers to the request-URL > > not existing, so that clearly does not apply to this case. > > As for case (1), 404 seems to be the most meaningful status > > to return. > > Perfect. > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Oct 15 13:41:50 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA08981 for ; Tue, 15 Oct 2002 13:41:49 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9FHhG928398; Tue, 15 Oct 2002 13:43:16 -0400 (EDT) Resent-Date: Tue, 15 Oct 2002 13:43:16 -0400 (EDT) Resent-Message-Id: <200210151743.g9FHhG928398@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9FHhFB28372 for ; Tue, 15 Oct 2002 13:43:15 -0400 (EDT) Received: from mail.cruzio.com (root@mail.cruzio.com [63.249.95.37]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA26588 for ; Tue, 15 Oct 2002 13:43:15 -0400 Received: from Tycho (dsl3-63-249-68-7.cruzio.com [63.249.68.7]) by mail.cruzio.com with SMTP id KAA27725 for ; Tue, 15 Oct 2002 10:43:14 -0700 (PDT) From: "Jim Whitehead" To: "'Webdav WG'" Date: Tue, 15 Oct 2002 10:40:20 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Subject: RE: BIND response codes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6867 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I don't understand why a server would want to do one, but not the other. - Jim > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > Sent: Tuesday, October 15, 2002 5:39 AM > To: 'Webdav WG' > Subject: BIND response codes > > > > Hi, > > would it possibly make sense to define the BIND response for the > case where > the client attempts to create a new binding to a collection, but > the server > only supports bindings to non-collections? > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Oct 15 13:51:00 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA09435 for ; Tue, 15 Oct 2002 13:50:59 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9FHoI328982; Tue, 15 Oct 2002 13:50:18 -0400 (EDT) Resent-Date: Tue, 15 Oct 2002 13:50:18 -0400 (EDT) Resent-Message-Id: <200210151750.g9FHoI328982@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9FHoGB28932 for ; Tue, 15 Oct 2002 13:50:16 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA28347 for ; Tue, 15 Oct 2002 13:50:16 -0400 Received: (qmail 12798 invoked by uid 0); 15 Oct 2002 17:49:45 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp004-rz3) with SMTP; 15 Oct 2002 17:49:45 -0000 From: "Julian Reschke" To: "Jim Whitehead" , "'Webdav WG'" Date: Tue, 15 Oct 2002 19:49:43 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Subject: RE: BIND response codes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6868 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit For the same reason a Unix file system by default behaves this way. Hard links to collections are dangerous (loops) and in most cases required (symlinks aka redirect refs to collections in most cases are all that's required). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Tuesday, October 15, 2002 7:40 PM > To: 'Webdav WG' > Subject: RE: BIND response codes > > > > I don't understand why a server would want to do one, but not the other. > > - Jim > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Julian Reschke > > Sent: Tuesday, October 15, 2002 5:39 AM > > To: 'Webdav WG' > > Subject: BIND response codes > > > > > > > > Hi, > > > > would it possibly make sense to define the BIND response for the > > case where > > the client attempts to create a new binding to a collection, but > > the server > > only supports bindings to non-collections? > > > > -- > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Tue Oct 15 14:28:55 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA10865 for ; Tue, 15 Oct 2002 14:28:55 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9FITrp06572; Tue, 15 Oct 2002 14:29:53 -0400 (EDT) Resent-Date: Tue, 15 Oct 2002 14:29:53 -0400 (EDT) Resent-Message-Id: <200210151829.g9FITrp06572@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9FITqB06546 for ; Tue, 15 Oct 2002 14:29:52 -0400 (EDT) Received: from mail.cruzio.com (root@mail.cruzio.com [63.249.95.37]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA16506 for ; Tue, 15 Oct 2002 14:29:51 -0400 Received: from Tycho (dsl3-63-249-68-7.cruzio.com [63.249.68.7]) by mail.cruzio.com with SMTP id LAA14090 for ; Tue, 15 Oct 2002 11:29:50 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 15 Oct 2002 11:26:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Subject: Atlanta IETF WEBDAV WG meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6869 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit As of the most recent IETF Agenda, the WebDAV WG is scheduled to meet on Tuesday, November 19, 2002, from 15:45-16:45 and 17:00-18:00. Note that this schedule is subject to change (but typically does not affect WebDAV WG when it does, though this has been known to happen). - Jim From w3c-dist-auth-request@w3.org Tue Oct 15 16:44:29 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15279 for ; Tue, 15 Oct 2002 16:44:29 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9FKe6J05685; Tue, 15 Oct 2002 16:40:06 -0400 (EDT) Resent-Date: Tue, 15 Oct 2002 16:40:06 -0400 (EDT) Resent-Message-Id: <200210152040.g9FKe6J05685@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9FKe5B05659 for ; Tue, 15 Oct 2002 16:40:05 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA17192 for ; Tue, 15 Oct 2002 16:40:03 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id NAA20112 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Tue, 15 Oct 2002 13:39:57 -0700 Received: from e3.ny.us.ibm.com (e3.ny.us.ibm.com [32.97.182.103]) by sunbelt.seagull.net (8.9.3) with ESMTP id NAA20084 sender obsfucated@us.ibm.com; Tue, 15 Oct 2002 13:39:52 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e3.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9FKdK0j183408; Tue, 15 Oct 2002 16:39:20 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9FKdH4i030280; Tue, 15 Oct 2002 16:39:17 -0400 To: "Julian Reschke" Cc: "Jim Whitehead" , "'Webdav WG'" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Jason Crawford Message-ID: Date: Tue, 15 Oct 2002 16:39:16 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0|September 26, 2002) at 10/15/2002 16:39:17, Serialize complete at 10/15/2002 16:39:17 Content-Type: text/plain; charset="us-ascii" Subject: RE: BIND response codes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6870 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Tuesday, 10/15/2002 at 07:49 ZE2, "Julian Reschke" wrote: > For the same reason a Unix file system by default behaves this way. > > Hard links to collections are dangerous (loops) and in most cases required > (symlinks aka redirect refs to collections in most cases are all that's > required). For example, garbage collecting a file system in the presence of loops can be relatively expensive. I really don't want a new status code, but if we can't find an appropriate existing one, I'm tentatively supportive of Julian's proposal to add one. From w3c-dist-auth-request@w3.org Tue Oct 15 16:52:23 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA15495 for ; Tue, 15 Oct 2002 16:52:23 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9FKpQg06965; Tue, 15 Oct 2002 16:51:26 -0400 (EDT) Resent-Date: Tue, 15 Oct 2002 16:51:26 -0400 (EDT) Resent-Message-Id: <200210152051.g9FKpQg06965@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9FKpQB06939 for ; Tue, 15 Oct 2002 16:51:26 -0400 (EDT) Received: from sccrmhc03.attbi.com (sccrmhc03.attbi.com [204.127.202.63]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA20149 for ; Tue, 15 Oct 2002 16:51:25 -0400 Received: from xp1700 ([66.229.4.108]) by sccrmhc03.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with SMTP id <20021015205055.MBNU24958.sccrmhc03.attbi.com@xp1700> for ; Tue, 15 Oct 2002 20:50:55 +0000 Message-ID: <00e501c2748c$88456d50$6401a8c0@xp1700> From: "Matthew Murphy" To: References: Date: Tue, 15 Oct 2002 13:50:44 -0700 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.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: remove me Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6871 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit How can I get off this list? Its not what I thought it would be about. Matthew Murphy Cop N Proc 1528 N Williams St Stockton, Ca. 95205 209.271.6639 Fax 209.464.0381 ----- Original Message ----- From: "Jason Crawford" To: "Julian Reschke" Cc: "Jim Whitehead" ; "'Webdav WG'" Sent: Tuesday, October 15, 2002 1:39 PM Subject: RE: BIND response codes > > On Tuesday, 10/15/2002 at 07:49 ZE2, "Julian Reschke" wrote: > > For the same reason a Unix file system by default behaves this way. > > > > Hard links to collections are dangerous (loops) and in most cases > required > > (symlinks aka redirect refs to collections in most cases are all that's > > required). > > For example, garbage collecting a file system in the presence of > loops can be relatively expensive. > > I really don't want a new status code, but if we can't find an appropriate > > existing one, I'm tentatively supportive of Julian's proposal to add one. > > > From w3c-dist-auth-request@w3.org Tue Oct 15 17:05:10 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA15999 for ; Tue, 15 Oct 2002 17:05:10 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9FL6Ul10550; Tue, 15 Oct 2002 17:06:30 -0400 (EDT) Resent-Date: Tue, 15 Oct 2002 17:06:30 -0400 (EDT) Resent-Message-Id: <200210152106.g9FL6Ul10550@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9FL6TB10520 for ; Tue, 15 Oct 2002 17:06:29 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA24323 for ; Tue, 15 Oct 2002 17:06:28 -0400 Received: (qmail 7052 invoked by uid 0); 15 Oct 2002 21:05:57 -0000 Received: from p3ee24724.dip.t-dialin.net (HELO lisa) (62.226.71.36) by mail.gmx.net (mp020-rz3) with SMTP; 15 Oct 2002 21:05:57 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Julian Reschke" Cc: "Jim Whitehead" , "'Webdav WG'" Date: Tue, 15 Oct 2002 23:05:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: BIND response codes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6872 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Tuesday, October 15, 2002 10:39 PM > To: Julian Reschke > Cc: Jim Whitehead; 'Webdav WG' > Subject: RE: BIND response codes > > > > On Tuesday, 10/15/2002 at 07:49 ZE2, "Julian Reschke" wrote: > > For the same reason a Unix file system by default behaves this way. > > > > Hard links to collections are dangerous (loops) and in most cases > required > > (symlinks aka redirect refs to collections in most cases are all that's > > required). > > For example, garbage collecting a file system in the presence of > loops can be relatively expensive. > > I really don't want a new status code, but if we can't find an > appropriate > > existing one, I'm tentatively supportive of Julian's proposal to add one. I think it's clear that there *will* be implementations that do not allow additional bindings on collections (for instance those that are Unix-filesystem based). We don't need a new status code, I was just trying to figure out whether to return 405 (not allowed) or 403 (forbidden) with a well-defined pre-condition (DAV:collection-binds-supported?). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Oct 15 21:06:11 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA20234 for ; Tue, 15 Oct 2002 21:06:11 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9G17PY01114; Tue, 15 Oct 2002 21:07:25 -0400 (EDT) Resent-Date: Tue, 15 Oct 2002 21:07:25 -0400 (EDT) Resent-Message-Id: <200210160107.g9G17PY01114@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9G17NB01088 for ; Tue, 15 Oct 2002 21:07:23 -0400 (EDT) Received: from MX1 ([202.75.160.16]) by tux.w3.org (8.9.3/8.9.3) with SMTP id VAA29233 for ; Tue, 15 Oct 2002 21:07:21 -0400 Received: from 202.75.160.17 by MX1 (InterScan E-Mail VirusWall NT); Wed, 16 Oct 2002 09:07:37 +0800 Received: from SUBGGD-Message_Server by SGBSS001.MEN.MAXIS.COM.MY with Novell_GroupWise; Wed, 16 Oct 2002 09:06:42 +0800 Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.5.1 Date: Wed, 16 Oct 2002 09:06:26 +0800 From: "Bala Murali" To: Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPartTM-000-01337dd9-753c-4b4c-be6c-579878662567" Content-Disposition: inline Subject: Re: remove me Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6873 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPartTM-000-01337dd9-753c-4b4c-be6c-579878662567 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable Pls remove me too..... >>> "Matthew Murphy" 10/16/02 04:50AM >>> How can I get off this list? Its not what I thought it would be about. Matthew Murphy Cop N Proc 1528 N Williams St Stockton, Ca. 95205 209.271.6639 Fax 209.464.0381 ----- Original Message ----- From: "Jason Crawford" To: "Julian Reschke" Cc: "Jim Whitehead" ; "'Webdav WG'" Sent: Tuesday, October 15, 2002 1:39 PM Subject: RE: BIND response codes > > On Tuesday, 10/15/2002 at 07:49 ZE2, "Julian Reschke" wrote: > > For the same reason a Unix file system by default behaves this way. > > > > Hard links to collections are dangerous (loops) and in most cases > required > > (symlinks aka redirect refs to collections in most cases are all = that's > > required). > > For example, garbage collecting a file system in the presence of > loops can be relatively expensive. > > I really don't want a new status code, but if we can't find an appropriat= e > > existing one, I'm tentatively supportive of Julian's proposal to add = one. > > > ------=_NextPartTM-000-01337dd9-753c-4b4c-be6c-579878662567 Content-Type: text/plain; name="Maxis_Disclaimer_Note.txt" Content-Disposition: attachment; filename="Maxis_Disclaimer_Note.txt" Content-Transfer-Encoding: 7bit Confidential information may be contained in this e-mail and any files transmitted with it ('Message'). If you are not the addressee indicated in this Message (or responsible for delivery of this Message to such person), you are hereby notified that any dissemination, distribution, printing or copying of this Message or any part thereof is strictly prohibited. In such a case, you should delete this Message immediately and advise the sender by return e-mail. Opinions, conclusions and other information in this Message that do not relate to the official business of Maxis shall be understood as neither given nor endorsed by Maxis. ------=_NextPartTM-000-01337dd9-753c-4b4c-be6c-579878662567-- From w3c-dist-auth-request@w3.org Tue Oct 15 23:47:28 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA22979 for ; Tue, 15 Oct 2002 23:47:28 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9G3mAn19989; Tue, 15 Oct 2002 23:48:10 -0400 (EDT) Resent-Date: Tue, 15 Oct 2002 23:48:10 -0400 (EDT) Resent-Message-Id: <200210160348.g9G3mAn19989@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9G3m7B19959 for ; Tue, 15 Oct 2002 23:48:07 -0400 (EDT) Received: from mail_server.eth.net ([61.11.73.40]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA23982 for ; Tue, 15 Oct 2002 23:48:04 -0400 Received: from MEENA ([192.168.0.15]) by mail_server.eth.net with SMTP (Microsoft Exchange Internet Mail Service Version 5.5.2448.0) id 406CW428; Wed, 16 Oct 2002 09:31:47 +0530 Message-ID: <00bd01c274c7$cb165eb0$0f00a8c0@meena> From: "Meena" To: "Bala Murali" , References: Date: Tue, 15 Oct 2002 22:54:42 -0500 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 5.50.4807.1700 X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4807.1700 Subject: Re: remove me Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6874 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Remove me too ----- Original Message ----- From: "Bala Murali" To: Sent: Tuesday, October 15, 2002 8:06 PM Subject: Re: remove me Pls remove me too..... >>> "Matthew Murphy" 10/16/02 04:50AM >>> How can I get off this list? Its not what I thought it would be about. Matthew Murphy Cop N Proc 1528 N Williams St Stockton, Ca. 95205 209.271.6639 Fax 209.464.0381 ----- Original Message ----- From: "Jason Crawford" To: "Julian Reschke" Cc: "Jim Whitehead" ; "'Webdav WG'" Sent: Tuesday, October 15, 2002 1:39 PM Subject: RE: BIND response codes > > On Tuesday, 10/15/2002 at 07:49 ZE2, "Julian Reschke" wrote: > > For the same reason a Unix file system by default behaves this way. > > > > Hard links to collections are dangerous (loops) and in most cases > required > > (symlinks aka redirect refs to collections in most cases are all that's > > required). > > For example, garbage collecting a file system in the presence of > loops can be relatively expensive. > > I really don't want a new status code, but if we can't find an appropriate > > existing one, I'm tentatively supportive of Julian's proposal to add one. > > > From w3c-dist-auth-request@w3.org Tue Oct 15 23:59:56 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA23232 for ; Tue, 15 Oct 2002 23:59:56 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9G41KI21483; Wed, 16 Oct 2002 00:01:20 -0400 (EDT) Resent-Date: Wed, 16 Oct 2002 00:01:20 -0400 (EDT) Resent-Message-Id: <200210160401.g9G41KI21483@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9G41KB21457 for ; Wed, 16 Oct 2002 00:01:20 -0400 (EDT) Received: from dns2.ggn.hcltech.com ([202.54.24.132]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA25634 for ; Wed, 16 Oct 2002 00:01:19 -0400 Received: from mail.ggn.hcltech.com (mail.ggn.hcltech.com [204.160.249.8]) by dns2.ggn.hcltech.com (8.11.2/8.11.2) with ESMTP id g9G411S23133 for ; Wed, 16 Oct 2002 09:31:01 +0530 Received: by mail.ggn.hcltech.com with Internet Mail Service (5.5.2653.19) id <49GFMD7S>; Wed, 16 Oct 2002 09:29:43 +0530 Message-ID: <4F57655597CDD6119F730002A544342F3D0B93@mail.ggn.hcltech.com> From: "Sekhar Babu, Gurgaon" To: "'w3c-dist-auth@w3c.org '" Date: Wed, 16 Oct 2002 09:29:42 +0530 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: remove me Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6875 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: remove me too -----Original Message----- From: Meena To: Bala Murali; w3c-dist-auth@w3c.org Sent: 10/16/02 9:24 AM Subject: Re: remove me Remove me too ----- Original Message ----- From: "Bala Murali" To: Sent: Tuesday, October 15, 2002 8:06 PM Subject: Re: remove me Pls remove me too..... >>> "Matthew Murphy" 10/16/02 04:50AM >>> How can I get off this list? Its not what I thought it would be about. Matthew Murphy Cop N Proc 1528 N Williams St Stockton, Ca. 95205 209.271.6639 Fax 209.464.0381 ----- Original Message ----- From: "Jason Crawford" To: "Julian Reschke" Cc: "Jim Whitehead" ; "'Webdav WG'" Sent: Tuesday, October 15, 2002 1:39 PM Subject: RE: BIND response codes > > On Tuesday, 10/15/2002 at 07:49 ZE2, "Julian Reschke" wrote: > > For the same reason a Unix file system by default behaves this way. > > > > Hard links to collections are dangerous (loops) and in most cases > required > > (symlinks aka redirect refs to collections in most cases are all that's > > required). > > For example, garbage collecting a file system in the presence of > loops can be relatively expensive. > > I really don't want a new status code, but if we can't find an appropriate > > existing one, I'm tentatively supportive of Julian's proposal to add one. > > > From w3c-dist-auth-request@w3.org Wed Oct 16 00:13:17 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23451 for ; Wed, 16 Oct 2002 00:13:17 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9G4EiN23815; Wed, 16 Oct 2002 00:14:44 -0400 (EDT) Resent-Date: Wed, 16 Oct 2002 00:14:44 -0400 (EDT) Resent-Message-Id: <200210160414.g9G4EiN23815@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9G4EiB23789 for ; Wed, 16 Oct 2002 00:14:44 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA27877 for ; Wed, 16 Oct 2002 00:14:44 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 16 Oct 2002 00:03:17 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403XZJ9N>; Wed, 16 Oct 2002 00:14:13 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Wed, 16 Oct 2002 00:14:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C274CA.76A55E00" Subject: RE: BIND response codes Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6877 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C274CA.76A55E00 Content-Type: text/plain I vote for 403 FORBIDDEN with a new DAV:error code. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: Jason Crawford > > > On Tuesday, 10/15/2002 at 07:49 ZE2, "Julian Reschke" wrote: > > For the same reason a Unix file system by default behaves this way. > > > > Hard links to collections are dangerous (loops) and in most cases > required > > (symlinks aka redirect refs to collections in most cases are all that's > > required). > > For example, garbage collecting a file system in the presence of > loops can be relatively expensive. > > I really don't want a new status code, but if we can't find an > appropriate > > existing one, I'm tentatively supportive of Julian's proposal to add one. I think it's clear that there *will* be implementations that do not allow additional bindings on collections (for instance those that are Unix-filesystem based). We don't need a new status code, I was just trying to figure out whether to return 405 (not allowed) or 403 (forbidden) with a well-defined pre-condition (DAV:collection-binds-supported?). ------_=_NextPart_001_01C274CA.76A55E00 Content-Type: text/html RE: BIND response codes

I vote for 403 FORBIDDEN with a new DAV:error code.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]

> From:  Jason Crawford
>
>
> On Tuesday, 10/15/2002 at 07:49 ZE2, "Julian Reschke"  wrote:
> > For the same reason a Unix file system by default behaves this way.
> >
> > Hard links to collections are dangerous (loops) and in most cases
> required
> > (symlinks aka redirect refs to collections in most cases are all that's
> > required).
>
> For example, garbage collecting a file system in the presence of
> loops can be relatively expensive.
>
> I really don't want a new status code, but if we can't find an
> appropriate
>
> existing one, I'm tentatively supportive of Julian's proposal to add one.

I think it's clear that there *will* be implementations that do not allow
additional bindings on collections (for instance those that are
Unix-filesystem based).

We don't need a new status code, I was just trying to figure out whether to
return 405 (not allowed) or 403 (forbidden) with a well-defined
pre-condition (DAV:collection-binds-supported?).

------_=_NextPart_001_01C274CA.76A55E00-- From w3c-dist-auth-request@w3.org Wed Oct 16 01:12:42 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id AAA23452 for ; Wed, 16 Oct 2002 00:13:17 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9G4EZP23761; Wed, 16 Oct 2002 00:14:35 -0400 (EDT) Resent-Date: Wed, 16 Oct 2002 00:14:35 -0400 (EDT) Resent-Message-Id: <200210160414.g9G4EZP23761@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9G4EYB23735 for ; Wed, 16 Oct 2002 00:14:34 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id AAA27847 for ; Wed, 16 Oct 2002 00:14:34 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 16 Oct 2002 00:03:07 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403XZJ92>; Wed, 16 Oct 2002 00:14:03 -0400 Message-ID: From: "Clemm, Geoff" To: "WebDAV (E-mail)" Date: Wed, 16 Oct 2002 00:13:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C274CA.717EDAF0" Subject: RE: DAV:can-overwrite Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6876 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C274CA.717EDAF0 Content-Type: text/plain; charset="iso-8859-1" That works for me. Jason: Can you add this to the 2518 issues list? Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] So my vote would be to leave the BIND spec as it is, and to add an entry to the RFC2518 issues list saying that 4xx/5xx response bodies MAY use the DAV:error format defined in RFC3253. We could then start a separate activity to specify precondition names for common RFC2518 error conditions (such as parent collection must exist). ------_=_NextPart_001_01C274CA.717EDAF0 Content-Type: text/html; charset="iso-8859-1" RE: DAV:can-overwrite

That works for me.

Jason: Can you add this to the 2518 issues list?

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]


So my vote would be to leave the BIND spec as it is, and to add an entry to
the RFC2518 issues list saying that 4xx/5xx response bodies MAY use the
DAV:error format defined in RFC3253. We could then start a separate activity
to specify precondition names for common RFC2518 error conditions (such as
parent collection must exist).

------_=_NextPart_001_01C274CA.717EDAF0-- From w3c-dist-auth-request@w3.org Wed Oct 16 03:39:52 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21246 for ; Wed, 16 Oct 2002 03:39:52 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9G7f1c04992; Wed, 16 Oct 2002 03:41:01 -0400 (EDT) Resent-Date: Wed, 16 Oct 2002 03:41:01 -0400 (EDT) Resent-Message-Id: <200210160741.g9G7f1c04992@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9G7evB04961 for ; Wed, 16 Oct 2002 03:40:57 -0400 (EDT) Received: from zur3-2.relay.mail.uu.net (zur3-2.relay.mail.uu.net [195.129.12.91]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA25155 for ; Wed, 16 Oct 2002 03:40:56 -0400 From: may@latimertechnologies.co.uk Received: from www.latimertechnologies.co.uk by zur3eusosrv13.zur.ops.eu.uu.net with ESMTP (peer crosschecked as: [195.217.123.82]) id QQnkug29626; Wed, 16 Oct 2002 07:40:47 GMT Received: from 192.9.200.203 by www.latimertechnologies.co.uk ([192.9.200.120] running VPOP3) with SMTP; Wed, 16 Oct 2002 08:54:27 +0100 To: "Meena" , "Bala Murali" , Date: Wed, 16 Oct 2002 08:40:22 +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.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Importance: Normal In-Reply-To: <00bd01c274c7$cb165eb0$0f00a8c0@meena> X-Server: VPOP3 V1.4.0e - Registered to: latman man Subject: RE: remove me Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6878 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit PLease remove me -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Meena Sent: Wednesday, October 16, 2002 4:55 AM To: Bala Murali; w3c-dist-auth@w3c.org Subject: Re: remove me Remove me too ----- Original Message ----- From: "Bala Murali" To: Sent: Tuesday, October 15, 2002 8:06 PM Subject: Re: remove me Pls remove me too..... >>> "Matthew Murphy" 10/16/02 04:50AM >>> How can I get off this list? Its not what I thought it would be about. Matthew Murphy Cop N Proc 1528 N Williams St Stockton, Ca. 95205 209.271.6639 Fax 209.464.0381 ----- Original Message ----- From: "Jason Crawford" To: "Julian Reschke" Cc: "Jim Whitehead" ; "'Webdav WG'" Sent: Tuesday, October 15, 2002 1:39 PM Subject: RE: BIND response codes > > On Tuesday, 10/15/2002 at 07:49 ZE2, "Julian Reschke" wrote: > > For the same reason a Unix file system by default behaves this way. > > > > Hard links to collections are dangerous (loops) and in most cases > required > > (symlinks aka redirect refs to collections in most cases are all that's > > required). > > For example, garbage collecting a file system in the presence of > loops can be relatively expensive. > > I really don't want a new status code, but if we can't find an appropriate > > existing one, I'm tentatively supportive of Julian's proposal to add one. > > > From w3c-dist-auth-request@w3.org Wed Oct 16 11:41:25 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA03780 for ; Wed, 16 Oct 2002 11:41:25 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9GFg6E14089; Wed, 16 Oct 2002 11:42:06 -0400 (EDT) Resent-Date: Wed, 16 Oct 2002 11:42:06 -0400 (EDT) Resent-Message-Id: <200210161542.g9GFg6E14089@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9GFg2B14063 for ; Wed, 16 Oct 2002 11:42:02 -0400 (EDT) Received: from scheduler.ACL.COM ([208.181.174.231]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA23856 for ; Wed, 16 Oct 2002 11:42:02 -0400 Received: from acl2.acl.com (acl2.acl.com) by scheduler.ACL.COM (Content Technologies SMTPRS 4.2.5) with SMTP id for ; Wed, 16 Oct 2002 08:42:00 -0700 Received: from ACLVanDm-Message_Server by acl2.acl.com with Novell_GroupWise; Wed, 16 Oct 2002 08:41:38 -0700 Message-Id: X-Mailer: Novell GroupWise 5.5.5 Date: Wed, 16 Oct 2002 08:41:09 -0700 From: "Harb Parhar" To: , , , Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=_D28E4FA2.BEDFB8DD" Subject: RE: remove me Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6879 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a MIME message. If you are reading this text, you may want to consider changing to a mail reader or gateway that understands how to properly handle MIME multipart messages. --=_D28E4FA2.BEDFB8DD Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline Content-Transfer-Encoding: quoted-printable PLEASE PLEASE remove me too.. >>> 10/16/02 12:41AM >>>=20 PLease remove me=20 -----Original Message-----=20 From: w3c-dist-auth-request@w3.org=20 [ mailto:w3c-dist-auth-request@w3.org]On Behalf Of Meena=20 Sent: Wednesday, October 16, 2002 4:55 AM=20 To: Bala Murali; w3c-dist-auth@w3c.org=20 Subject: Re: remove me=20 Remove me too=20 ----- Original Message -----=20 From: "Bala Murali" < BALAM@maxis.com.my >=20 To: < w3c-dist-auth@w3c.org >=20 Sent: Tuesday, October 15, 2002 8:06 PM=20 Subject: Re: remove me=20 Pls remove me too.....=20 >>> "Matthew Murphy" < thenextbyte@attbi.com > 10/16/02 04:50AM >>>=20 How can I get off this list? Its not what I thought it would be about.=20 Matthew Murphy=20 Cop N Proc=20 1528 N Williams St=20 Stockton, Ca. 95205=20 209.271.6639 Fax 209.464.0381=20 ----- Original Message -----=20 From: "Jason Crawford" < nn683849@smallcue.com >=20 To: "Julian Reschke" < julian.reschke@gmx.de >=20 Cc: "Jim Whitehead" < ejw@cse.ucsc.edu >; "'Webdav WG'"=20 < w3c-dist-auth@w3c.org >=20 Sent: Tuesday, October 15, 2002 1:39 PM=20 Subject: RE: BIND response codes=20 >=20 > On Tuesday, 10/15/2002 at 07:49 ZE2, "Julian Reschke" wrote:=20 > > For the same reason a Unix file system by default behaves this way.=20 > >=20 > > Hard links to collections are dangerous (loops) and in most cases=20 > required=20 > > (symlinks aka redirect refs to collections in most cases are all that's= > > required).=20 >=20 > For example, garbage collecting a file system in the presence of=20 > loops can be relatively expensive.=20 >=20 > I really don't want a new status code, but if we can't find an appropriat= e=20 >=20 > existing one, I'm tentatively supportive of Julian's proposal to add one.= >=20 >=20 >=20 --=_D28E4FA2.BEDFB8DD Content-Type: text/plain Content-Disposition: attachment; filename="TEXT.htm" PLEASE PLEASE remove me too..

>>> <may@latimertechnologies.co.uk> 10/16/02 12:41AM >>>

PLease remove me


-----Original Message-----
From: w3c-dist-auth-request@w3.org
[ mailto:w3c-dist-auth-request@w3.org]On Behalf Of Meena
Sent: Wednesday, October 16, 2002 4:55 AM
To: Bala Murali; w3c-dist-auth@w3c.org
Subject: Re: remove me



Remove me too

----- Original Message -----
From: "Bala Murali" < BALAM@maxis.com.my >
To: < w3c-dist-auth@w3c.org >
Sent: Tuesday, October 15, 2002 8:06 PM
Subject: Re: remove me


Pls remove me too.....

>>> "Matthew Murphy" < thenextbyte@attbi.com > 10/16/02 04:50AM >>>

How can I get off this list? Its not what I thought it would be about.

Matthew Murphy
Cop N Proc
1528 N Williams St
Stockton, Ca. 95205
209.271.6639 Fax 209.464.0381
----- Original Message -----
From: "Jason Crawford" < nn683849@smallcue.com >
To: "Julian Reschke" < julian.reschke@gmx.de >
Cc: "Jim Whitehead" < ejw@cse.ucsc.edu >; "'Webdav WG'"
< w3c-dist-auth@w3c.org >
Sent: Tuesday, October 15, 2002 1:39 PM
Subject: RE: BIND response codes


>
> On Tuesday, 10/15/2002 at 07:49 ZE2, "Julian Reschke" wrote:
> > For the same reason a Unix file system by default behaves this way.
> >
> > Hard links to collections are dangerous (loops) and in most cases
> required
> > (symlinks aka redirect refs to collections in most cases are all that's
> > required).
>
> For example, garbage collecting a file system in the presence of
> loops can be relatively expensive.
>
> I really don't want a new status code, but if we can't find an appropriate
>
> existing one, I'm tentatively supportive of Julian's proposal to add one.
>
>
>




--=_D28E4FA2.BEDFB8DD-- From w3c-dist-auth-request@w3.org Wed Oct 16 11:47:09 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04062 for ; Wed, 16 Oct 2002 11:47:09 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9GFmKw14782; Wed, 16 Oct 2002 11:48:20 -0400 (EDT) Resent-Date: Wed, 16 Oct 2002 11:48:20 -0400 (EDT) Resent-Message-Id: <200210161548.g9GFmKw14782@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9GFmJB14754 for ; Wed, 16 Oct 2002 11:48:19 -0400 (EDT) Received: from smtp-relay-2.adobe.com (smtp-relay-2.adobe.com [192.150.11.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA25749 for ; Wed, 16 Oct 2002 11:48:19 -0400 Received: from inner-relay-2.corp.adobe.com (inner-relay-2 [153.32.1.52]) by smtp-relay-2.adobe.com (8.12.3/8.12.3) with ESMTP id g9GFisUi002574 for ; Wed, 16 Oct 2002 08:44:55 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-2.corp.adobe.com (8.12.3/8.12.3) with ESMTP id g9GFj6AW025174 for ; Wed, 16 Oct 2002 08:45:06 -0700 (PDT) Received: from adobe.com ([130.248.188.158]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id H42ZVH00.15N; Wed, 16 Oct 2002 08:47:41 -0700 Date: Wed, 16 Oct 2002 08:47:49 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: Dan Brotsky To: w3c-dist-auth@w3.org From: Dan Brotsky In-Reply-To: Message-Id: <9FC23704-E11E-11D6-8202-0003931036B4@adobe.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Subject: Re: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6880 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Sorry not to have weighed in on any of the interop issues since then. Things have been a bit busy :^). On Tuesday, October 8, 2002, at 12:25 AM, Julian Reschke wrote: >> And if it has Etag support and it's the last PUT, you might not care >> care if you've lost the lock as long as the content has not >> been updated. There's no point in checking for the lock in that >> situation and spec'ing that the check be done anyway, just causes >> needless delay. >> ... > > Wouldn't that mean to optimize for a *really* uncommon case? How > frequently > does that happen? Does is really require special handling? In the real world this happens constantly. Servers can make locks go away whenever they want, and clients have no way of learning why or what the implications are for edit state. Workflow administrators remove them, thinking they're inactive. They expire because the client is idle for reasons beyond its control (sleeping a machine). Server administrators do lock cleanups because their database seems corrupt. The fact of the matter is that, the way the spec is written, real-world clients constantly have to be doing rediscovery of what's happening on the server so they can "convince" the server they know exactly what's going on, and in fact they often have to figure out from a particular series of rejected requests how that *particular* server models things. (temperature rises) Sorry if this sounds like a flame, but it's really just a heartfelt complaint about the state of the spec from a client's point of view. Until you've tried to write an expensive, production-quality client used by a naive user that interoperates in a wide range of authoring situations with 20 different servers, each of which takes a defensible but slightly different interpretation of the spec, and each of whose "easy to handle edge cases" mean something completely different coming from another server, it's hard to have a good idea about how narrow a guaranteed-successful path through the spec's garden path of "defensible interpretations" is (hint: how small is epsilon :^), or how hard it is to discover a path that will work for a particular server. I believe that all the client-side spec requests that came out of the interop (detailed below) come from high-quality implementation teams that have watched their code devolve into a series of spaghetti strands each of which knows how to talk to one particular server. As only a slight exaggeration, we might as well be supporting different protocols against each one. I've even had one of my lead implementors seriously suggest that we implement our client API as an abstract object which first does an OPTIONS call to see (from the "Server:" header) which server we're talking to and then load the appropriate concrete provider! (temperature falls) So let me go through the various proposals floating around with an eye not towards clarifying their details or fixing them but just motivating them from a client point of view. First, some basic requirements that underly this discussion, which I believe were in the original requirements doc that Judy wrote a long time ago: R1. distributed authoring clients are very concerned about the lost update problem. (clients A and B read the same version of a doc, make separate changes and then each save back not knowing the other has. Whoever saved first loses.) R2. distributed authoring clients are very concerned about their users not wasting time working on something they can't save. (a variant of the lost update problem, in which clients can discover that the doc has been updated but not that it's going to be updated.) R3. distributed authoring clients want to be able to offer their users a consistent least-common-denominator model of the server's hierarchy, even though the actual situation may be far more complex than that model suggests. R4. distributed authoring clients want to make the same sequence of calls against all compliant servers, and know that they can rely on differences in result to be due to server policy or differing conditions, NOT on different server interpretations of the meaning of the request. In the light of these, here's the motivation for a number of the client requests (no pun intended) that Lisa mentioned in her summary message from the last interop: 1. require etag support (when feasible). Without strong (or at least weak) validators, there's really no way to address the lost-update problem. Mod dates are too randomly defined, which is why etags made it into HTTP 1.1 in the first place, but even when a server's mod dates really are weak validators there's no reason for clients to have to figure out whether to use mod dates or etags on a server-by-server basis (see R4). 2. Provide a lock-state-checking-less way of doing an operation on a locked resource. In my experience with multiple server implementations, LOCK is simply unreliable as anything other than a way to satisfy R2: warn other users that I'm going to update the resource. This is because, the way the spec is written, locks are simply a gating factor on the succcess of certain client requests, not a reliable, precise declaration of write capabilities on a resource. Locks certainly don't guarantee that a resource hasn't been updated, because there's absolutely nothing in the spec that keeps the server from doing that behind my back (even leaving the lock in place!), and I can show you servers that do this defensibly and routinely. Nor is loss of lock a way to find out that my ability to update has changed, because locks go away for any number of random reasons having nothing to do with me (and I can show you servers that defensibly and routinely do that, as well). From a client's point of view, I do LOCK GET PUT UNLOCK so that YOU can know not to start editing the same resource until the UNLOCK is done. But I really don't care whether you do or not, and I really don't care whether my lock goes away or not, because I'm going to use etags to make sure to avoid lost updates (and so should you). (By the way, from this point of view shared write locks are interoperable, even when used by the same principal; consider a user of two clients having them warn each other that they're both in use.) 3. provide a way of forcing authentication. If I'm a distributed authoring client using a server, then I expect (in the course of an update) to do a LOCK (if the server supports it), then a GET and/or some PROPPATCHs, then some PUTs and/or PROPPATCHs (with the PUT protected by an IF: etag condition, and yes I wish there were there were a similar thing for properties), and then finally (if supported) an UNLOCK (or maybe a DELETE, which will do the UNLOCK very effectively :^). I want to know when I start that I have the authority to do all of these calls, and I want to know right in the beginning what identity I will use to do that so I can properly put some info about it in the LOCK owner field. So I want some way of forcing the server to challenge me to authenticate as someone who can do this sequence, and I want it even before the LOCK starts (especially cause I can't always do a LOCK). 4. require servers to be consistent about specifying slashes in responses to propfind requests that enumerate a tree. (and, by the way, require clients always to use slashes when referring to what they believe is a collection...) This is motivated by a combination of R3 and R4. I need to be able to show my users a consistent view of the server's hierarchy, separating collections (which appear to contain other resources) from non-collections (which don't). When the server responds to a PROPFIND enumerating a tree, I need not to be guessing why this collection had a slash on the end whereas this other one didn't, and I really need to know which ones of these returnees can themselves be enumerated (which, by the way, is allowed to be a VERY different piece of information than I get back from asking about the resource type, although I don't think it was meant to be - another problem :^). 5. that the *same* pair of clients and servers interoperate over all features before we believe we have interoperability. The motivation for this should be obvious by now: you can get pairwise interoperability between DIFFERENT pairs without any guarantee that you can write a generic client which is anything other than the "union" client my lead implementor was proposing. 6. only allow one kind of TIME in lock expiry. this is R4. 7. require PROPFIND results to use a single base URL, and that the URL either be the returned content-location header URL or the one the client used. This is R3 and R4. You may expect clients to be able to keep referring to different elements of collections with different preferred paths, but I can't expect my user to, and I can't hide that from him. 8. servers can't withhold lock owner info. R4: it's mine, don't force me to work around you withholding it. That's it for rationale. I'll gradually be sending around proposals on resolving a number of these specific issues, hopefully ones that reflect the discussion so far and are acceptable to the group :^). If you got this far, thanks for your attention to such a long message. dan From w3c-dist-auth-request@w3.org Wed Oct 16 11:48:19 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04117 for ; Wed, 16 Oct 2002 11:48:18 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9GFnTS15229; Wed, 16 Oct 2002 11:49:29 -0400 (EDT) Resent-Date: Wed, 16 Oct 2002 11:49:29 -0400 (EDT) Resent-Message-Id: <200210161549.g9GFnTS15229@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9GFnSB15203 for ; Wed, 16 Oct 2002 11:49:28 -0400 (EDT) Received: from smtp-relay-1.adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA26436 for ; Wed, 16 Oct 2002 11:49:28 -0400 Received: from inner-relay-2.corp.adobe.com (inner-relay-2 [153.32.1.52]) by smtp-relay-1.adobe.com (8.12.3/8.12.3) with ESMTP id g9GFpUsm024625 for ; Wed, 16 Oct 2002 08:51:30 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-2.corp.adobe.com (8.12.3/8.12.3) with ESMTP id g9GFkDAW025318 for ; Wed, 16 Oct 2002 08:46:13 -0700 (PDT) Received: from adobe.com ([130.248.188.158]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id H42ZXC00.40K; Wed, 16 Oct 2002 08:48:48 -0700 Date: Wed, 16 Oct 2002 08:48:56 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: Dan Brotsky To: w3c-dist-auth@w3.org From: Dan Brotsky In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Subject: Re: ETags, was: Issues from Interop/Interim WG Meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6881 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Once again, sorry for being so long about joining this thread. I'll try to phrase this proposal in a way that I think addresses all the issues that have been raised. I excerpt arguments from various pieces of mail in what follows, and I apologize in advance if you feel I do not do your point justice. Proposal: Add the following language (adapted from 2616 and 2518) to 2518-bis: WebDAV origin servers: - MUST send an entity tag validator unless it is not feasible to generate one. - MAY send a weak entity tag instead of a strong entity tag, if performance considerations support the use of weak entity tags, or if it is unfeasible to send a strong entity tag. - MUST NOT send either a strong or weak entity tag in response to any request on a resource unless it ALWAYS sends such a tag in response to every such request. - MUST define the DAV:getetag property for any DAV-compliant resource if and only if it responds to GET requests with strong or weak entity tags. WebDAV clients: - SHOULD use a PROPFIND on the DAV:getetag property of a resource in order to determine whether that resource supports entity tags. - MAY choose not to support authoring of a resource that does not support entity tags - MAY warn users, when authoring resources that do not support entity tags, that they cannot be protected from lost updates. I think this addresses the following issues which came up in the discussion: 1. Servers are not required to support etags for resources for which it is infeasible to do so. However, they are required to be completely consistent about whether they do or not for a given resource, so that clients can be assured from the results of just one call what the situation is. 2. Julian's excellent suggestion for how clients should figure this out is made a SHOULD, and the loopholes that might have made clients nervous about using it are closed. 3. In moving from DRAFT to PROPOSED standard, we are simply strengthening a SHOULD clause to a MUST. (The SHOULD clause, by the way, was in 2616, not 2518, but since every 2518 server MUST also be a 2616 server this still counts.) 4. Geoff eloquently raised the issue that we should not suddenly make compliant servers into non-compliant servers unless we have compelling reason to do so. I believe that what we are doing here is to force consistent support for etags (as opposed to last mod dates, or some other mechanism) by those servers WHICH ARE CAPABLE OF IT. I believe there are servers out there which could support etags (because, for example, they support last-mod dates) but which do not support them simply because the spec does not require them to. I believe we have a very compelling reason to require those server implementations to meet the higher standard of compliance: it allows clients to know, in a consistent manner, whether they can support the avoidance of lost updates when authoring against that server, and exactly how they can do it. This is a primary goal of the protocol. 5. Geoff also pointed out: > On a related topic, working to marshall new functionality through > existing machinery rewards an implementor for going to the effort of > being > fully compliant, and increases the likelihood that implementors will > bother > to do so. I believe that this is exactly an effort to marshall new functionality (allowing clients to avoid lost updates) through existing machinery (etags, which were already in 1.1) and that we will, in fact, be rewarding those implementors who went to the effort of being fully compliant with 1.1. 6. Jason was concerned that we not require something which may be infeasible, but was in favor of making it "very clear that [etags] do provide value and should be implemented if possible." I hope he can support this proposal as meeting both those goals. 7. Julian was concerned that servers which, for example, simply serve simple filesystems (using no additinal machinery) might not be able to meet this requirement, and that in their desire to meet it they would accidentally produce buggy implementations. I think his more general point (that people sometimes produce buggy implementations when specs get more stringent or require new features) is unassailable, but in this particular case: - if they don't see how they can't support etags then they're OK, cause they don't have to. They just have to NOT support etags consistently :^). - I believe that, in such a case, the filesystem's internal timestamp is arguably a fine thing to use as an etag. If the DAV server in question doesn't allow changes except to content (which presumably it doesn't because it has no other machinery to store properties with, and the filesystem properties are not generally mutable), then using the timestamp as an etag is quite reliable, the server simply has to ensure that no two PUT requests are processed within the resolution of a single filesystem timestamp value. And, as Geoff would say :^), how hard could this be? (Sorry, couldn't resist...) dan From w3c-dist-auth-request@w3.org Wed Oct 16 11:50:40 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04163 for ; Wed, 16 Oct 2002 11:50:39 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9GFpRj16580; Wed, 16 Oct 2002 11:51:27 -0400 (EDT) Resent-Date: Wed, 16 Oct 2002 11:51:27 -0400 (EDT) Resent-Message-Id: <200210161551.g9GFpRj16580@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9GFpQB16512 for ; Wed, 16 Oct 2002 11:51:26 -0400 (EDT) Received: from smtp-relay-3.sea.adobe.com (smtp-relay-3.adobe.com [192.150.22.10]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA27770 for ; Wed, 16 Oct 2002 11:51:12 -0400 Received: from inner-relay-3.corp.adobe.com (inner-relay-3 [153.32.251.51]) by smtp-relay-3.sea.adobe.com (8.12.3/8.12.3) with ESMTP id g9GFnVAI013249 for ; Wed, 16 Oct 2002 08:49:31 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-3.corp.adobe.com (8.12.3/8.12.3) with ESMTP id g9GFks8d010664 for ; Wed, 16 Oct 2002 08:46:54 -0700 (PDT) Received: from adobe.com ([130.248.188.158]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id H4300D00.OZJ; Wed, 16 Oct 2002 08:50:37 -0700 Date: Wed, 16 Oct 2002 08:50:45 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: Dan Brotsky To: w3c-dist-auth@w3.org From: Dan Brotsky In-Reply-To: <3906C56A7BD1F54593344C05BD1374B10841DD95@SUS-MA1IT01> Message-Id: <08815398-E11F-11D6-8202-0003931036B4@adobe.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Subject: Re: Interop issue: how can clients force authentication? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6882 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit As usual, sorry for letting so much time pass before jumping in. On Friday, September 20, 2002, at 05:39 AM, Clemm, Geoff wrote: > I believe the problem statement is: > > The problem: A client wants to check if the current user is > authenticated to do an operation before it has that user provide the > input for that operation, and before it performs expensive > computations to set up the input for that request. Almost. As you can see from my other message, I believe it's actually more: The problem: Before starting a sequence of requests on a resource, a client wants to ensure that it is authenticated as a principal who is authorized to perform all the various methods in the sequence. If it is not so authenticated, it wants to be rechallenged so it can reauthenticate. > The proposal: Document in the 2518bis that the authentication check > SHOULD be performed before the If header check (so that a simple > contradictory If header can be used to check the authentication for > "dummy version" of the operation, i.e. one with dummy values that did > not require user input or expensive calculations on the client). Unfortunately this (a) doesn't allow checking for a number of different methods in a single call, and (b) doesn't require the server to check authorization, just authentication. What's wanted is for the server to return 401 unless the user is actually authorized to perform all those methods, not simply authenticated. I don't believe it's actually reasonable to require servers to perform authorization checks before they perform IF checks (consider that IF checks may be much cheaper to perform than going to some back-end LDAP database to get ACL info). In addition, many servers are going to want to simply return 403 to the request (indicating that the current user is not authorized for that) rather than to re-challenge, which is what the client wants to happen. I'm afraid that the extensive discussion around this is causing me to believe that it's beyond the scope of what we can cover in 2518-bis, and quite possibly what we can cover in any extension of DAV. But there's a proposal of Julian's (do PROPPATCH on a specially known live property) that I believe has some chance of doing what we want, and I'll send another message with just that revised proposal. dan From w3c-dist-auth-request@w3.org Wed Oct 16 11:52:03 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04255 for ; Wed, 16 Oct 2002 11:52:03 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9GFqtY18585; Wed, 16 Oct 2002 11:52:55 -0400 (EDT) Resent-Date: Wed, 16 Oct 2002 11:52:55 -0400 (EDT) Resent-Message-Id: <200210161552.g9GFqtY18585@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9GFqsB18558 for ; Wed, 16 Oct 2002 11:52:54 -0400 (EDT) Received: from smtp-relay-1.adobe.com (smtp-relay-1.adobe.com [192.150.11.1]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA29137 for ; Wed, 16 Oct 2002 11:52:53 -0400 Received: from inner-relay-2.corp.adobe.com (inner-relay-2 [153.32.1.52]) by smtp-relay-1.adobe.com (8.12.3/8.12.3) with ESMTP id g9GFsssm025479 for ; Wed, 16 Oct 2002 08:54:54 -0700 (PDT) Received: from mailsj-v1.corp.adobe.com (mailsj-dev.corp.adobe.com [153.32.1.192]) by inner-relay-2.corp.adobe.com (8.12.3/8.12.3) with ESMTP id g9GFnaAW025743 for ; Wed, 16 Oct 2002 08:49:36 -0700 (PDT) Received: from adobe.com ([130.248.188.158]) by mailsj-v1.corp.adobe.com (Netscape Messaging Server 4.15 v1 Jul 11 2001 16:32:57) with ESMTP id H4302Z00.6QR; Wed, 16 Oct 2002 08:52:11 -0700 Date: Wed, 16 Oct 2002 08:52:19 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: Dan Brotsky To: w3c-dist-auth@w3.org From: Dan Brotsky In-Reply-To: <3906C56A7BD1F54593344C05BD1374B10841DD95@SUS-MA1IT01> Message-Id: <4073DA40-E11F-11D6-8202-0003931036B4@adobe.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Subject: Re: Interop issue: how can clients force authentication? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6883 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The problem: Before starting a sequence of requests on a resource, a client wants to ensure that it is authenticated as a principal who is authorized to perform all the various methods in the sequence. If it is not so authenticated, it wants to be rechallenged so it can reauthenticate. The proposal (with thanks but no blame to Julian): The client sends a (probably unauthorized) request to PROPPATCH the DAV:authorized-methods property of the resource with an methods element containing a checkauthorization element and elements for each of the methods it wishes to use. ... (extra credit: guess who desperately needs Julian, Stefan, and Geoff to fix his XML...) In the wonderfully-future-compliant case: the server actually looks at the value of the property specified, and continues to challenge (401) the client until the client authenticates as a user who is actually authorized to perform all those methods on that resource. At that point the server return 409 because (ha!) DAV:authorized-methods is actually a read-only property. In the currently compliant server case: the server just authenticates/authorizes the user for the PROPPATCH on the resource, and then either sets the (dead) property or refuses the request (403, presumably), because the user is trying to set a property in the DAV: space that's not mentioned in the current version of the spec. :^) ---------- PROPOSED LANGUAGE (first shot, sort of): - Define the property DAV:authorized-methods as a live property whose value is a methods element. - A server SHOULD return, as the result of a PROPFIND on DAV:authorized-methods, EITHER the set of methods that the requesting principal is authorized for over that resource OR 404 Not Found (meaning the server doesn't want to or is unable to tell you). - A server MAY treat DAV:authorized-methods as a dead property (for backward compatibility). - If a client attempts to PROPPATCH the value of DAV:authorized-methods, it MUST use a checkauthorization element as the first member of the property, and it MUST include all the methods that it want to check authorization for. - Servers SHOULD respond to client attempts to PROPPATCH the value of DAV:authorized-methods by responding with 401 until the client authenticates as a principal authorized to perform all such methods on the target resource (if there were a target resource). - Servers MAY respond to client attempts to PROPPATCH the value of DAV:authorized-methods as if DAV:authorized-methods were a dead property. ---------- Some impressions and issues: 1. Sheesh. What a hack. But at least it covers the fairly common case of servers that authorize LOCK, PUT, PROPPATCH, UNLOCK (and usually DELETE) the same way. Those servers just treat the new property as dead, and clients get what they want. 2. What exactly happens if you PROPPATCH an URL that's not bound to a resource, anyway? That's going to be a very common case if you were planning to LOCK the resource first, and you probably don't want the server creating the resource on the PROPPATCH. OK, folks, have at it! :^) dan From w3c-dist-auth-request@w3.org Wed Oct 16 12:34:58 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05041 for ; Wed, 16 Oct 2002 12:34:58 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9GG2RJ20587; Wed, 16 Oct 2002 12:02:27 -0400 (EDT) Resent-Date: Wed, 16 Oct 2002 12:02:27 -0400 (EDT) Resent-Message-Id: <200210161602.g9GG2RJ20587@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9GG2RB20558 for ; Wed, 16 Oct 2002 12:02:27 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA03030 for ; Wed, 16 Oct 2002 12:02:24 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id JAA27158 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Wed, 16 Oct 2002 09:02:19 -0700 Received: from e1.ny.us.ibm.com (e1.ny.us.ibm.com [32.97.182.101]) by sunbelt.seagull.net (8.9.3) with ESMTP id JAA27134 sender obsfucated@us.ibm.com; Wed, 16 Oct 2002 09:02:14 -0700 Received: from northrelay04.pok.ibm.com (northrelay04.pok.ibm.com [9.56.224.206]) by e1.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9GG1btB286390; Wed, 16 Oct 2002 12:01:42 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay04.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9GG1HCM055106; Wed, 16 Oct 2002 12:01:25 -0400 To: "Clemm, Geoff" Cc: "WebDAV (E-mail)" MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Jason Crawford Message-ID: Date: Wed, 16 Oct 2002 12:01:13 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0|September 26, 2002) at 10/16/2002 12:01:24, Serialize complete at 10/16/2002 12:01:24 Content-Type: text/plain; charset="us-ascii" Subject: RE: DAV:can-overwrite Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6884 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Wednesday, 10/16/2002 at 12:13 AST, "Clemm, Geoff" wrote: > That works for me. > > Jason: Can you add this to the 2518 issues list? Done From w3c-dist-auth-request@w3.org Wed Oct 16 13:31:03 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06863 for ; Wed, 16 Oct 2002 13:31:03 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9GHWMk13049; Wed, 16 Oct 2002 13:32:22 -0400 (EDT) Resent-Date: Wed, 16 Oct 2002 13:32:22 -0400 (EDT) Resent-Message-Id: <200210161732.g9GHWMk13049@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9GHWLB13019 for ; Wed, 16 Oct 2002 13:32:21 -0400 (EDT) Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA20125 for ; Wed, 16 Oct 2002 13:32:21 -0400 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id g9GHVXk00029 for ; Wed, 16 Oct 2002 10:31:33 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 16 Oct 2002 10:28:41 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-UCSC-CATS-MailScanner: Found to be clean Subject: CFP: WWW 2003 conference Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6885 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The WWW 2003 conference is being held May 20-24, 2003, in Budapest, Hungary. There are several tracks in this conference that might be of interest to members of this list, including the Applications, Hypermedia, Search and Data Mining, Web Engineering, and Web Services tracks. The full call for participation can be found at: http://www2003.org/cfp.htm Papers are due November 15. The Applications track in particular is well suited for discussion of WebDAV technology, since it focuses on innovative uses of Web technology. I think many of the projects in this community (including commercial, open source, and research) would have a reasonable chance of acceptance if written up and submitted to this track. I'd be happy to answer any questions you might have if you're interested in submitting a paper to this conference. - Jim From w3c-dist-auth-request@w3.org Wed Oct 16 13:46:39 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07253 for ; Wed, 16 Oct 2002 13:46:39 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9GHlh516465; Wed, 16 Oct 2002 13:47:43 -0400 (EDT) Resent-Date: Wed, 16 Oct 2002 13:47:43 -0400 (EDT) Resent-Message-Id: <200210161747.g9GHlh516465@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9GHlfB16439 for ; Wed, 16 Oct 2002 13:47:41 -0400 (EDT) Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA25089 for ; Wed, 16 Oct 2002 13:47:41 -0400 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id g9GHlOk04304 for ; Wed, 16 Oct 2002 10:47:24 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Wed, 16 Oct 2002 10:44:33 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-UCSC-CATS-MailScanner: Found to be clean Subject: How to exit this list Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6886 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit There have been several "take me off this list" messages recently. If you want to be removed from this list, the process is simple. Send an email message to w3c-dist-auth-request@w3.org with a subject line of unsubscribe You will then be automatically removed from the list. - Jim From w3c-dist-auth-request@w3.org Wed Oct 16 21:16:17 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA17382 for ; Wed, 16 Oct 2002 21:16:17 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9H1HfA12686; Wed, 16 Oct 2002 21:17:41 -0400 (EDT) Resent-Date: Wed, 16 Oct 2002 21:17:41 -0400 (EDT) Resent-Message-Id: <200210170117.g9H1HfA12686@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9H1HeB12659 for ; Wed, 16 Oct 2002 21:17:40 -0400 (EDT) Received: from ariel.eastgw.xerox.com (ariel.xerox.com [208.140.33.25]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id VAA24555 for ; Wed, 16 Oct 2002 21:17:35 -0400 Received: from dnsmaster.sgp.xerox.com (dnsmaster.sgp.xerox.com [13.198.80.2]) by ariel.eastgw.xerox.com (8.9.3/8.9.3) with ESMTP id VAA09848 for ; Wed, 16 Oct 2002 21:17:22 -0400 (EDT) Received: from dns-master.sgp.xerox.com (dns-cache1.sgp.xerox.com [13.198.8.2]) by dnsmaster.sgp.xerox.com (8.9.1a/8.9.1) with ESMTP id JAA24799 for ; Thu, 17 Oct 2002 09:17:29 +0800 (SGT) Received: from sgpxsscexch1.xssc.sgp.xerox.com (sgpxsscexch1.xssc.sgp.xerox.com [13.198.32.88]) by dns-master.sgp.xerox.com (8.11.6+Sun/8.11.6) with SMTP id g9H1Gat21322 for ; Thu, 17 Oct 2002 09:16:37 +0800 (SGT) Received: by SGPXSSCEXCH1 with Internet Mail Service (5.5.2653.19) id <4DR9FFRD>; Thu, 17 Oct 2002 09:16:48 +0800 Message-ID: From: "Jiang, Chuan Wei (XSSC SGP)" To: "'w3c-dist-auth@w3c.org '" Date: Thu, 17 Oct 2002 09:16:46 +0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: remove me Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6887 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: remove me too , thank you. -----Original Message----- From: Sekhar Babu, Gurgaon [mailto:sekhar@ggn.hcltech.com] Sent: 2002?10?16? 12:00 To: 'w3c-dist-auth@w3c.org ' Subject: RE: remove me remove me too -----Original Message----- From: Meena To: Bala Murali; w3c-dist-auth@w3c.org Sent: 10/16/02 9:24 AM Subject: Re: remove me Remove me too ----- Original Message ----- From: "Bala Murali" To: Sent: Tuesday, October 15, 2002 8:06 PM Subject: Re: remove me Pls remove me too..... >>> "Matthew Murphy" 10/16/02 04:50AM >>> How can I get off this list? Its not what I thought it would be about. Matthew Murphy Cop N Proc 1528 N Williams St Stockton, Ca. 95205 209.271.6639 Fax 209.464.0381 ----- Original Message ----- From: "Jason Crawford" To: "Julian Reschke" Cc: "Jim Whitehead" ; "'Webdav WG'" Sent: Tuesday, October 15, 2002 1:39 PM Subject: RE: BIND response codes > > On Tuesday, 10/15/2002 at 07:49 ZE2, "Julian Reschke" wrote: > > For the same reason a Unix file system by default behaves this way. > > > > Hard links to collections are dangerous (loops) and in most cases > required > > (symlinks aka redirect refs to collections in most cases are all that's > > required). > > For example, garbage collecting a file system in the presence of > loops can be relatively expensive. > > I really don't want a new status code, but if we can't find an appropriate > > existing one, I'm tentatively supportive of Julian's proposal to add one. > > > From w3c-dist-auth-request@w3.org Fri Oct 18 03:54:45 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA18076 for ; Fri, 18 Oct 2002 03:54:45 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9I7tvE20968; Fri, 18 Oct 2002 03:55:57 -0400 (EDT) Resent-Date: Fri, 18 Oct 2002 03:55:57 -0400 (EDT) Resent-Message-Id: <200210180755.g9I7tvE20968@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9I7ttB20938 for ; Fri, 18 Oct 2002 03:55:55 -0400 (EDT) Received: from server8a.software-ag.de (server8a.software-ag.de [193.26.193.47]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id DAA06544 for ; Fri, 18 Oct 2002 03:55:54 -0400 Received: from daehub01.software-ag.de by server8a.software-ag.de; (8.11.6/8.9.3) id g9I7tqj16794; Fri, 18 Oct 2002 09:55:52 +0200 Received: by daehub01.software-ag.de with Internet Mail Service (5.5.2653.19) id ; Fri, 18 Oct 2002 09:55:11 +0200 Message-ID: From: "Nevermann, Dr., Peter" To: "'w3c-dist-auth@w3.org'" , "'slide-user@jakarta.apache.org'" Date: Fri, 18 Oct 2002 09:55:51 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Subject: Free client for testing WebDAV, DeltaV, DASL, ACL !!! Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6888 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Hi, the Tamino WebDAV BasicClient 1.1.1 is a GUI tool to issue WebDAV commands on the protocol level (+DeltaV +DASL +ACL +any_forthcoming_extensions). It is *the* ideal tool for developers and testers. It is also great for demos. Written in Java, it is downloadable currently for Windows and Solaris. Special features: - BASIC Authentication - Chunking - Powerful response content viewing (html, xml, image and binary) - Request history - Requests can be saved to a file for later reuse - and more ... *FREE* download at: http://developer.softwareag.com/tamino/webdav/default.htm Regards, Peter From w3c-dist-auth-request@w3.org Fri Oct 18 13:42:17 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA04561 for ; Fri, 18 Oct 2002 13:42:17 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9IHhFr22324; Fri, 18 Oct 2002 13:43:15 -0400 (EDT) Resent-Date: Fri, 18 Oct 2002 13:43:15 -0400 (EDT) Resent-Message-Id: <200210181743.g9IHhFr22324@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9IHhEB22298 for ; Fri, 18 Oct 2002 13:43:14 -0400 (EDT) Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA10991 for ; Fri, 18 Oct 2002 13:43:13 -0400 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id g9IHgmk24789; Fri, 18 Oct 2002 10:42:49 -0700 (PDT) From: "Jim Whitehead" To: "Nevermann, Dr., Peter" , Date: Fri, 18 Oct 2002 10:39:56 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-Reply-To: Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: RE: Free client for testing WebDAV, DeltaV, DASL, ACL !!! Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6889 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Peter, Thank you for making this testing tool available to the WebDAV community! - Jim > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Nevermann, Dr., Peter > Sent: Friday, October 18, 2002 12:56 AM > To: 'w3c-dist-auth@w3.org'; 'slide-user@jakarta.apache.org' > Subject: Free client for testing WebDAV, DeltaV, DASL, ACL !!! > > > > Hi, > > the Tamino WebDAV BasicClient 1.1.1 is a GUI tool to issue WebDAV commands > on the protocol level (+DeltaV +DASL +ACL +any_forthcoming_extensions). It > is *the* ideal tool for developers and testers. It is also great > for demos. > Written in Java, it is downloadable currently for Windows and Solaris. > > Special features: > - BASIC Authentication > - Chunking > - Powerful response content viewing (html, xml, image and binary) > - Request history > - Requests can be saved to a file for later reuse > - and more ... > > *FREE* download at: > http://developer.softwareag.com/tamino/webdav/default.htm > > Regards, > Peter > From w3c-dist-auth-request@w3.org Sun Oct 20 06:18:41 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA24888 for ; Sun, 20 Oct 2002 06:18:41 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9KAJNx12504; Sun, 20 Oct 2002 06:19:23 -0400 (EDT) Resent-Date: Sun, 20 Oct 2002 06:19:23 -0400 (EDT) Resent-Message-Id: <200210201019.g9KAJNx12504@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9KAJMB12478 for ; Sun, 20 Oct 2002 06:19:22 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id GAA20337 for ; Sun, 20 Oct 2002 06:19:21 -0400 Received: (qmail 31023 invoked by uid 0); 20 Oct 2002 10:18:50 -0000 Received: from pd950c3f4.dip.t-dialin.net (HELO lisa) (217.80.195.244) by mail.gmx.net (mp020-rz3) with SMTP; 20 Oct 2002 10:18:50 -0000 From: "Julian Reschke" To: "'Webdav WG'" Date: Sun, 20 Oct 2002 12:18:47 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6890 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, RFC3253 defines several kinds of resources that MUST NOT be moved, for instance version resources ([1]) and version history resources ([2]). How does this impact the ability to create additional bindings? a) You can't (so do we need additional preconditions)? b) You can, but you can't delete the original binding (so do we need to extend the DELETE semantics)? c) We don't care -- BIND/DELETE may work, although MOVE is forbidden (in which case I'd like zo understand why). Julian [1] [2] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Oct 21 04:40:49 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21708 for ; Mon, 21 Oct 2002 04:40:49 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9L8fUU18938; Mon, 21 Oct 2002 04:41:30 -0400 (EDT) Resent-Date: Mon, 21 Oct 2002 04:41:30 -0400 (EDT) Resent-Message-Id: <200210210841.g9L8fUU18938@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9L8fTB18835 for ; Mon, 21 Oct 2002 04:41:29 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA18581 for ; Mon, 21 Oct 2002 04:41:28 -0400 Received: (qmail 17722 invoked by uid 0); 21 Oct 2002 08:40:57 -0000 Received: from p3ee24735.dip.t-dialin.net (HELO lisa) (62.226.71.53) by mail.gmx.net (mp015-rz3) with SMTP; 21 Oct 2002 08:40:57 -0000 From: "Julian Reschke" To: Date: Mon, 21 Oct 2002 10:40:43 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <9FC23704-E11E-11D6-8202-0003931036B4@adobe.com> Subject: RE: Interop issue: Proposal for fixing lock token provision Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6891 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dan, you have raised a lot of issues here -- for now I'd prefer just to concentrate on: > In the real world this happens constantly. Servers can make locks go > away whenever they want, and clients have no way of learning why or > what the implications are for edit state. Workflow administrators > remove them, thinking they're inactive. They expire because the client > is idle for reasons beyond its control (sleeping a machine). Server > administrators do lock cleanups because their database seems corrupt. > The fact of the matter is that, the way the spec is written, real-world > clients constantly have to be doing rediscovery of what's happening on > the server so they can "convince" the server they know exactly what's > going on, and in fact they often have to figure out from a particular > series of rejected requests how that *particular* server models things. Basically you're saying "in the real world, locking doesn't work". The reasons being a) servers with reduced functionality (locking not supported) b) broken servers (locking is supported, but locks do not work as expected or go away for no apparent reason) c) locks are "stolen" d) administrators remove locks to "cleanup" the system For a) and b), there's obviously little we can do, except for clarifying the spec where it's not clear enough. As far as I understand, all current issues about creating, refreshing, discovering and destroying locks are resolved (minus error marshalling for deep locks). Furthermore, I'm not aware of any a)- or b)-type issues with IIS and/or Apache/moddav. So if you experienced problems and didn't get the expected feedback from the server implementors, you *should* describe the problem here in detail. As for c) -- that's by design. If it happens frequently, there may be a problem with the lock timeouts that are set. Regarding d) -- obviously that's a problem with how the server is run. "Cleaning up" locks for no good reason obviously is wrong, and there's little an RFC can do to prevent that (maybe except telling operators not to do that). However if a lock that a client created goes away this is a *severe* problem within a sequence of method invocations. It shouldn't normally happen, so there's absolutely no reason to define protocol workarounds for that situation. If it happens frequently, the server needs to be fixed, or the administrator needs to be educated. Finally, I understand your frustration with trying to deal with server bugs. As our product contains both client and server components, I'm aware of many issues, and the most frustrating part is that bug reports are just ignored, accepted (but no bug fix is made available) or rejected (although the WG agrees that it is a bug). Some of my favorite bugs are: - incapability to handle UTF-8-URL encoded characters in resource names - buggy parsing of response bodies when extension elements are present (for instance, in DAV:lockdiscovery) - incapability to handle chunked encoding - usage of non-registered URI or URN schemes for lock tokens - advertising support for deltaV, but not supporting even the most basic live properties - advertising support for DASL, but not supporting the DAV:basicsearch grammar - advertising support for ACLs, but not implementing the latest draft - sending malformed XML entities upon a simple PROPFIND/allprop - - ... Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Oct 21 04:46:26 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA21789 for ; Mon, 21 Oct 2002 04:46:26 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9L8luL20121; Mon, 21 Oct 2002 04:47:56 -0400 (EDT) Resent-Date: Mon, 21 Oct 2002 04:47:56 -0400 (EDT) Resent-Message-Id: <200210210847.g9L8luL20121@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9L8ltB20092 for ; Mon, 21 Oct 2002 04:47:55 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA19916 for ; Mon, 21 Oct 2002 04:47:55 -0400 Received: (qmail 7903 invoked by uid 0); 21 Oct 2002 08:47:24 -0000 Received: from p3ee24735.dip.t-dialin.net (HELO lisa) (62.226.71.53) by mail.gmx.net (mp010-rz3) with SMTP; 21 Oct 2002 08:47:24 -0000 From: "Julian Reschke" To: Date: Mon, 21 Oct 2002 10:47:10 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <4073DA40-E11F-11D6-8202-0003931036B4@adobe.com> Subject: RE: Interop issue: how can clients force authentication? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6892 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Dan, a few comments: - trying to set a dead property before going on with resource modifications certainly is interoperable, - I don't think that the information "which methods can I invoke with the current credentials" belongs into a live property -- it certainly sounds like an additional optional REPORT (for which support can be detected using DAV:supported-report-set), - I've got the feeling that this isn't how authentication should work in HTTP. Either you are authenticated, or you aren't. If your current privileges are not sufficient for a specific method, you'll get a 403. IMHO, if a client thinks that it might succeed with different credentials, it should be initiate the new authentication itself. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dan Brotsky > Sent: Wednesday, October 16, 2002 5:52 PM > To: w3c-dist-auth@w3.org > Cc: Dan Brotsky > Subject: Re: Interop issue: how can clients force authentication? > > > > The problem: Before starting a sequence of requests on a resource, a > client wants to ensure that it is authenticated as a principal who is > authorized to perform all the various methods in the sequence. If it > is not so authenticated, it wants to be rechallenged so it can > reauthenticate. > > The proposal (with thanks but no blame to Julian): The client sends a > (probably unauthorized) request to PROPPATCH the DAV:authorized-methods > property of the resource with an methods element containing a > checkauthorization element and elements for each of the methods it > wishes to use. > > lock? ...) > > > > > ... > (extra credit: guess who desperately needs Julian, Stefan, and Geoff > to fix his XML...) > > In the wonderfully-future-compliant case: the server actually looks at > the value of the property specified, and continues to challenge (401) > the client until the client authenticates as a user who is actually > authorized to perform all those methods on that resource. At that > point the server return 409 because (ha!) DAV:authorized-methods is > actually a read-only property. > > In the currently compliant server case: the server just > authenticates/authorizes the user for the PROPPATCH on the resource, > and then either sets the (dead) property or refuses the request (403, > presumably), because the user is trying to set a property in the DAV: > space that's not mentioned in the current version of the spec. :^) > > ---------- > > PROPOSED LANGUAGE (first shot, sort of): > > - Define the property DAV:authorized-methods as a live property whose > value is a methods element. > > - A server SHOULD return, as the result of a PROPFIND on > DAV:authorized-methods, EITHER the set of methods that the requesting > principal is authorized for over that resource OR 404 Not Found > (meaning the server doesn't want to or is unable to tell you). > > - A server MAY treat DAV:authorized-methods as a dead property (for > backward compatibility). > > - If a client attempts to PROPPATCH the value of > DAV:authorized-methods, it MUST use a checkauthorization element as the > first member of the property, and it MUST include all the methods that > it want to check authorization for. > > - Servers SHOULD respond to client attempts to PROPPATCH the value of > DAV:authorized-methods by responding with 401 until the client > authenticates as a principal authorized to perform all such methods on > the target resource (if there were a target resource). > > - Servers MAY respond to client attempts to PROPPATCH the value of > DAV:authorized-methods as if DAV:authorized-methods were a dead > property. > > ---------- > > Some impressions and issues: > > 1. Sheesh. What a hack. But at least it covers the fairly common case > of servers that authorize LOCK, PUT, PROPPATCH, UNLOCK (and usually > DELETE) the same way. Those servers just treat the new property as > dead, and clients get what they want. > > 2. What exactly happens if you PROPPATCH an URL that's not bound to a > resource, anyway? That's going to be a very common case if you were > planning to LOCK the resource first, and you probably don't want the > server creating the resource on the PROPPATCH. > > OK, folks, have at it! :^) > > dan > From w3c-dist-auth-request@w3.org Mon Oct 21 08:33:37 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA25533 for ; Mon, 21 Oct 2002 08:33:36 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9LCYW622887; Mon, 21 Oct 2002 08:34:32 -0400 (EDT) Resent-Date: Mon, 21 Oct 2002 08:34:32 -0400 (EDT) Resent-Message-Id: <200210211234.g9LCYW622887@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9LCYSB22860 for ; Mon, 21 Oct 2002 08:34:28 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA01782 for ; Mon, 21 Oct 2002 08:34:28 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 21 Oct 2002 08:22:48 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403YBM38>; Mon, 21 Oct 2002 08:33:57 -0400 Message-ID: From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Mon, 21 Oct 2002 08:33:53 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C278FE.1D7246D0" Subject: RE: Interop issue: how can clients force authentication? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6893 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C278FE.1D7246D0 Content-Type: text/plain A couple of comments: - Many servers will not be able to perform "what if" calculations, or will only be able to perform them on a limited set of (probably less interesting) methods. - Even if the server comes back and says "yes, you could do that", by the time you get around to trying it, it may fail because the state on the server has changed, so a client needs to be prepared to handle the "not authorized" response in the middle of a stream of requests anyway. - And assuming the preceding reasons haven't convinced you that this isn't worth doing (:-), I'd suggest the alternative proposal, which says that a server that wants to provide this capability does two things: - Do authentication checks before "If" header checks - Correctly support the "If" header (in particular, support "Not") Then a client just submits the sequence of requests it wants the server to pre-authenticate, but includes with each request the header: If: ("A" Not "A") Then if you get an authentication error, you know you are not authenticated, but if you get a precondition-failed error, you know you are authenticated. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Monday, October 21, 2002 4:47 AM To: w3c-dist-auth@w3.org Subject: RE: Interop issue: how can clients force authentication? Dan, a few comments: - trying to set a dead property before going on with resource modifications certainly is interoperable, - I don't think that the information "which methods can I invoke with the current credentials" belongs into a live property -- it certainly sounds like an additional optional REPORT (for which support can be detected using DAV:supported-report-set), - I've got the feeling that this isn't how authentication should work in HTTP. Either you are authenticated, or you aren't. If your current privileges are not sufficient for a specific method, you'll get a 403. IMHO, if a client thinks that it might succeed with different credentials, it should be initiate the new authentication itself. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dan Brotsky > Sent: Wednesday, October 16, 2002 5:52 PM > To: w3c-dist-auth@w3.org > Cc: Dan Brotsky > Subject: Re: Interop issue: how can clients force authentication? > > > > The problem: Before starting a sequence of requests on a resource, a > client wants to ensure that it is authenticated as a principal who is > authorized to perform all the various methods in the sequence. If it > is not so authenticated, it wants to be rechallenged so it can > reauthenticate. > > The proposal (with thanks but no blame to Julian): The client sends a > (probably unauthorized) request to PROPPATCH the DAV:authorized-methods > property of the resource with an methods element containing a > checkauthorization element and elements for each of the methods it > wishes to use. > > lock? ...) > > > > > ... > (extra credit: guess who desperately needs Julian, Stefan, and Geoff > to fix his XML...) > > In the wonderfully-future-compliant case: the server actually looks at > the value of the property specified, and continues to challenge (401) > the client until the client authenticates as a user who is actually > authorized to perform all those methods on that resource. At that > point the server return 409 because (ha!) DAV:authorized-methods is > actually a read-only property. > > In the currently compliant server case: the server just > authenticates/authorizes the user for the PROPPATCH on the resource, > and then either sets the (dead) property or refuses the request (403, > presumably), because the user is trying to set a property in the DAV: > space that's not mentioned in the current version of the spec. :^) > > ---------- > > PROPOSED LANGUAGE (first shot, sort of): > > - Define the property DAV:authorized-methods as a live property whose > value is a methods element. > > - A server SHOULD return, as the result of a PROPFIND on > DAV:authorized-methods, EITHER the set of methods that the requesting > principal is authorized for over that resource OR 404 Not Found > (meaning the server doesn't want to or is unable to tell you). > > - A server MAY treat DAV:authorized-methods as a dead property (for > backward compatibility). > > - If a client attempts to PROPPATCH the value of > DAV:authorized-methods, it MUST use a checkauthorization element as the > first member of the property, and it MUST include all the methods that > it want to check authorization for. > > - Servers SHOULD respond to client attempts to PROPPATCH the value of > DAV:authorized-methods by responding with 401 until the client > authenticates as a principal authorized to perform all such methods on > the target resource (if there were a target resource). > > - Servers MAY respond to client attempts to PROPPATCH the value of > DAV:authorized-methods as if DAV:authorized-methods were a dead > property. > > ---------- > > Some impressions and issues: > > 1. Sheesh. What a hack. But at least it covers the fairly common case > of servers that authorize LOCK, PUT, PROPPATCH, UNLOCK (and usually > DELETE) the same way. Those servers just treat the new property as > dead, and clients get what they want. > > 2. What exactly happens if you PROPPATCH an URL that's not bound to a > resource, anyway? That's going to be a very common case if you were > planning to LOCK the resource first, and you probably don't want the > server creating the resource on the PROPPATCH. > > OK, folks, have at it! :^) > > dan > ------_=_NextPart_001_01C278FE.1D7246D0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: Interop issue: how can clients force authentication?

A couple of comments:

- Many servers will not be able to perform "what = if" calculations,
or will only be able to perform them on a limited = set of (probably
less interesting) methods.

- Even if the server comes back and says "yes, = you could do that",
by the time you get around to trying it, it may fail = because the
state on the server has changed, so a client needs = to be prepared
to handle the "not authorized" response in = the middle of a stream
of requests anyway.

- And assuming the preceding reasons haven't = convinced you that this
isn't worth doing (:-), I'd suggest the alternative = proposal, which
says that a server that wants to provide this = capability does two
things:

 - Do authentication checks before = "If" header checks
 - Correctly support the "If" header = (in particular, support "Not")

Then a client just submits the sequence of requests = it wants the
server to pre-authenticate, but includes with each = request the header:
 If: ("A" Not "A")
Then if you get an authentication error, you know = you are not
authenticated, but if you get a precondition-failed = error, you
know you are authenticated.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]<= /FONT>
Sent: Monday, October 21, 2002 4:47 AM
To: w3c-dist-auth@w3.org
Subject: RE: Interop issue: how can clients force = authentication?



Dan,

a few comments:

- trying to set a dead property before going on with = resource modifications
certainly is interoperable,

- I don't think that the information "which = methods can I invoke with the
current credentials" belongs into a live = property -- it certainly sounds
like an additional optional REPORT (for which = support can be detected using
DAV:supported-report-set),

- I've got the feeling that this isn't how = authentication should work in
HTTP. Either you are authenticated, or you aren't. = If your current
privileges are not sufficient for a specific method, = you'll get a 403. IMHO,
if a client thinks that it might succeed with = different credentials, it
should be initiate the new authentication = itself.

Julian

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

> -----Original Message-----
> From: w3c-dist-auth-request@w3.org
> [mailto:w3c-dist-auth-reques= t@w3.org]On Behalf Of Dan Brotsky
> Sent: Wednesday, October 16, 2002 5:52 = PM
> To: w3c-dist-auth@w3.org
> Cc: Dan Brotsky
> Subject: Re: Interop issue: how can clients = force authentication?
>
>
>
> The problem: Before starting a sequence of = requests on a resource, a
> client wants to ensure that it is authenticated = as a principal who is
> authorized to perform all the various methods = in the sequence.  If it
> is not so authenticated, it wants to be = rechallenged so it can
> reauthenticate.
>
> The proposal (with thanks but no blame to = Julian): The client sends a
> (probably unauthorized) request to PROPPATCH = the DAV:authorized-methods
> property of the resource with an methods = element containing a
> checkauthorization element and elements for = each of the methods it
> wishes to use.
>
>    <!ELEMENT methods = (checkauthorization? options? get? put? mkcol?
> lock? ...) >
>    <!ELEMENT = checkauthorization EMPTY >
>    <!ELEMENT options EMPTY = >
>    <!ELEMENT get EMPTY = >
>    ...
>    (extra credit: guess who = desperately needs Julian, Stefan, and Geoff
> to fix his XML...)
>
> In the wonderfully-future-compliant case: the = server actually looks at
> the value of the property specified, and = continues to challenge (401)
> the client until the client authenticates as a = user who is actually
> authorized to perform all those methods on that = resource.  At that
> point the server return 409 because (ha!) = DAV:authorized-methods is
> actually a read-only property.
>
> In the currently compliant server case: the = server just
> authenticates/authorizes the user for the = PROPPATCH on the resource,
> and then either sets the (dead) property or = refuses the request (403,
> presumably), because the user is trying to set = a property in the DAV:
> space that's not mentioned in the current = version of the spec. :^)
>
> ----------
>
> PROPOSED LANGUAGE (first shot, sort of):
>
> - Define the property DAV:authorized-methods as = a live property whose
> value is a methods element.
>
> - A server SHOULD return, as the result of a = PROPFIND on
> DAV:authorized-methods, EITHER the set of = methods that the requesting
> principal is authorized for over that resource = OR 404 Not Found
> (meaning the server doesn't want to or is = unable to tell you).
>
> - A server MAY treat DAV:authorized-methods as = a dead property (for
> backward compatibility).
>
> - If a client attempts to PROPPATCH the value = of
> DAV:authorized-methods, it MUST use a = checkauthorization element as the
> first member of the property, and it MUST = include all the methods that
> it want to check authorization for.
>
> - Servers SHOULD respond to client attempts to = PROPPATCH the value of
> DAV:authorized-methods by responding with 401 = until the client
> authenticates as a principal authorized to = perform all such methods on
> the target resource (if there were a target = resource).
>
> - Servers MAY respond to client attempts to = PROPPATCH the value of
> DAV:authorized-methods as if = DAV:authorized-methods were a dead
> property.
>
> ----------
>
> Some impressions and issues:
>
> 1. Sheesh.  What a hack.  But at = least it covers the fairly common case
> of servers that authorize LOCK, PUT, PROPPATCH, = UNLOCK (and usually
> DELETE) the same way.  Those servers just = treat the new property as
> dead, and clients get what they want.
>
> 2. What exactly happens if you PROPPATCH an URL = that's not bound to a
> resource, anyway?  That's going to be a = very common case if you were
> planning to LOCK the resource first, and you = probably don't want the
> server creating the resource on the = PROPPATCH.
>
> OK, folks, have at it! :^)
>
>      dan
>

------_=_NextPart_001_01C278FE.1D7246D0-- From w3c-dist-auth-request@w3.org Mon Oct 21 09:31:23 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA27885 for ; Mon, 21 Oct 2002 09:31:23 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9LDWcF00192; Mon, 21 Oct 2002 09:32:38 -0400 (EDT) Resent-Date: Mon, 21 Oct 2002 09:32:38 -0400 (EDT) Resent-Message-Id: <200210211332.g9LDWcF00192@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9LDWaB00160 for ; Mon, 21 Oct 2002 09:32:36 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA21197 for ; Mon, 21 Oct 2002 09:32:36 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 21 Oct 2002 09:20:56 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403YBPF6>; Mon, 21 Oct 2002 09:32:05 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Mon, 21 Oct 2002 09:31:55 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27906.3930A850" Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6894 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27906.3930A850 Content-Type: text/plain I believe the answer should be (c). The original binding to a version or a version history has special semantics (i.e. if you delete it, the resource is destroyed, and all bindings to it are destroyed), while additional bindings (such as those in a working collection) just have normal DELETE semantics, i.e. just that binding is deleted. So MOVE would not be allowed on the original binding, but is allowed on any other bindings. And yes, once the BIND protocol is standardized, the next revision of the DeltaV protocol should add the appropriate preconditions to handle BIND semantics. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Sunday, October 20, 2002 6:19 AM To: 'Webdav WG' Subject: BIND vs. non-movable resources in RFC3253 Hi, RFC3253 defines several kinds of resources that MUST NOT be moved, for instance version resources ([1]) and version history resources ([2]). How does this impact the ability to create additional bindings? a) You can't (so do we need additional preconditions)? b) You can, but you can't delete the original binding (so do we need to extend the DELETE semantics)? c) We don't care -- BIND/DELETE may work, although MOVE is forbidden (in which case I'd like zo understand why). Julian [1] [2] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 ------_=_NextPart_001_01C27906.3930A850 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: BIND vs. non-movable resources in RFC3253

I believe the answer should be (c).

The original binding to a version or a version
history has special semantics (i.e. if you
delete it, the resource is destroyed, and all = bindings
to it are destroyed), while additional bindings = (such
as those in a working collection) just have normal = DELETE
semantics, i.e. just that binding is deleted. =

So MOVE would not be allowed on the original = binding,
but is allowed on any other bindings.

And yes, once the BIND protocol is standardized, = the
next revision of the DeltaV protocol should add the = appropriate
preconditions to handle BIND semantics.

Cheers,
Geoff


-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]<= /FONT>
Sent: Sunday, October 20, 2002 6:19 AM
To: 'Webdav WG'
Subject: BIND vs. non-movable resources in = RFC3253



Hi,

RFC3253 defines several kinds of resources that MUST = NOT be moved, for
instance version resources ([1]) and version history = resources ([2]).

How does this impact the ability to create additional = bindings?

a) You can't (so do we need additional = preconditions)?
b) You can, but you can't delete the original = binding (so do we need to
extend the DELETE semantics)?
c) We don't care -- BIND/DELETE may work, although = MOVE is forbidden (in
which case I'd like zo understand why).

Julian

[1] <http://greenbytes.de/tech/webdav/rfc3253.html#rfc.sect= ion.3.15>
[2] <http://greenbytes.de/tech/webdav/rfc3253.html#rfc.sect= ion.5.8>

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

------_=_NextPart_001_01C27906.3930A850-- From w3c-dist-auth-request@w3.org Mon Oct 21 10:20:18 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA29819 for ; Mon, 21 Oct 2002 10:20:18 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9LELJI08445; Mon, 21 Oct 2002 10:21:19 -0400 (EDT) Resent-Date: Mon, 21 Oct 2002 10:21:19 -0400 (EDT) Resent-Message-Id: <200210211421.g9LELJI08445@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9LELIB08419 for ; Mon, 21 Oct 2002 10:21:18 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA10729 for ; Mon, 21 Oct 2002 10:21:17 -0400 Received: (qmail 23541 invoked by uid 0); 21 Oct 2002 14:20:46 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp004-rz3) with SMTP; 21 Oct 2002 14:20:46 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'Webdav WG'" Date: Mon, 21 Oct 2002 16:20:44 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6895 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Clemm, Geoff > Sent: Monday, October 21, 2002 3:32 PM > To: 'Webdav WG' > Subject: RE: BIND vs. non-movable resources in RFC3253 > > > I believe the answer should be (c). > The original binding to a version or a version > history has special semantics (i.e. if you > delete it, the resource is destroyed, and all bindings > to it are destroyed), while additional bindings (such > as those in a working collection) just have normal DELETE > semantics, i.e. just that binding is deleted. > So MOVE would not be allowed on the original binding, > but is allowed on any other bindings. > And yes, once the BIND protocol is standardized, the > next revision of the DeltaV protocol should add the appropriate > preconditions to handle BIND semantics. I really have a problem with this approach. The BIND spec just clarified DELETE to mean: "The DELETE method requests that the server remove the binding between the resource identified by the Request-URI and the binding name, the last path segment of the Request-URI. The binding MUST be removed from its parent collection, identified by the Request-URI minus its trailing slash (if present) and final segment. Once a resource is unreachable by any URI mapping, the server MAY reclaim system resources associated with that resource. If DELETE removes a binding to a resource, but there remain URI mappings to that resource, the server MUST NOT reclaim system resources associated with the resource." You seem to say that other specs are allowed to override this definition. In which case I'd claim that the model that the BIND spec tries to establish isn't correct, and that we shouldn't attempt to establish this definition for deletes of bindings. IMHO, - up until now, specs usually defined DELETE as *both* removing the URI mapping and the destruction of resources, - the BIND spec changes this view so that the resource MAY be destroyed when the last binding disappears, - therefore, DELETE behaviour defined in old specs should now be understood as definining what may occur when the last binding disappears. In this particular case, I'd like to understand why we actually want to forbid MOVE on versions and version histories. I understand that once a URI has been allocated for a version or a VHR, it should never identity anything else. So the defined contract basically guarantees that upon GET/PROPFIND on this URI, I will either - access the very same resource or - that I'll get a 404. I don't think that we need the special MOVE conditions to guarantee this. From a client's point of view, it's irrelevant whether the resource is gone or is now "somewhere else" (yes, servers may want to forbid the MOVE for other reasons). Julian From w3c-dist-auth-request@w3.org Mon Oct 21 10:30:43 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA00562 for ; Mon, 21 Oct 2002 10:30:43 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9LEWDP09921; Mon, 21 Oct 2002 10:32:13 -0400 (EDT) Resent-Date: Mon, 21 Oct 2002 10:32:13 -0400 (EDT) Resent-Message-Id: <200210211432.g9LEWDP09921@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9LEWCB09895 for ; Mon, 21 Oct 2002 10:32:12 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with SMTP id KAA14259 for ; Mon, 21 Oct 2002 10:32:11 -0400 Received: from greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Mon, 21 Oct 2002 16:31:33 +0200 Date: Mon, 21 Oct 2002 16:31:29 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "Clemm, Geoff" , "'Webdav WG'" To: "Julian Reschke" From: Stefan Eissing In-Reply-To: Message-Id: Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: Re: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6896 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The conformant behaviour would be to disallow DELETE on "the" uri of a version/version history unless the uri is already the last bindung to the resource. This would avoid the requirement that *all other* binding must be removed which is exactly the opposite of what the binding spec (currently) says. //Stefan Am Montag, 21.10.02, um 16:20 Uhr (Europe/Berlin) schrieb Julian Reschke: > >> From: w3c-dist-auth-request@w3.org >> [mailto:w3c-dist-auth-request@w3.org]On >> Behalf Of Clemm, Geoff >> Sent: Monday, October 21, 2002 3:32 PM >> To: 'Webdav WG' >> Subject: RE: BIND vs. non-movable resources in RFC3253 >> >> >> I believe the answer should be (c). >> The original binding to a version or a version >> history has special semantics (i.e. if you >> delete it, the resource is destroyed, and all bindings >> to it are destroyed), while additional bindings (such >> as those in a working collection) just have normal DELETE >> semantics, i.e. just that binding is deleted. >> So MOVE would not be allowed on the original binding, >> but is allowed on any other bindings. >> And yes, once the BIND protocol is standardized, the >> next revision of the DeltaV protocol should add the appropriate >> preconditions to handle BIND semantics. > > I really have a problem with this approach. The BIND spec just > clarified > DELETE to mean: > > "The DELETE method requests that the server remove the binding between > the > resource identified by the Request-URI and the binding name, the last > path > segment of the Request-URI. The binding MUST be removed from its parent > collection, identified by the Request-URI minus its trailing slash (if > present) and final segment. > > Once a resource is unreachable by any URI mapping, the server MAY > reclaim > system resources associated with that resource. If DELETE removes a > binding > to a resource, but there remain URI mappings to that resource, the > server > MUST NOT reclaim system resources associated with the resource." > > You seem to say that other specs are allowed to override this > definition. In > which case I'd claim that the model that the BIND spec tries to > establish > isn't correct, and that we shouldn't attempt to establish this > definition > for deletes of bindings. > > IMHO, > > - up until now, specs usually defined DELETE as *both* removing the URI > mapping and the destruction of resources, > > - the BIND spec changes this view so that the resource MAY be > destroyed when > the last binding disappears, > > - therefore, DELETE behaviour defined in old specs should now be > understood > as definining what may occur when the last binding disappears. > > In this particular case, I'd like to understand why we actually want to > forbid MOVE on versions and version histories. I understand that once > a URI > has been allocated for a version or a VHR, it should never identity > anything > else. So the defined contract basically guarantees that upon > GET/PROPFIND on > this URI, I will either > > - access the very same resource or > - that I'll get a 404. > > I don't think that we need the special MOVE conditions to guarantee > this. > From a client's point of view, it's irrelevant whether the resource is > gone > or is now "somewhere else" (yes, servers may want to forbid the MOVE > for > other reasons). > > Julian > > From w3c-dist-auth-request@w3.org Mon Oct 21 10:42:13 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA01184 for ; Mon, 21 Oct 2002 10:42:12 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9LEh1b11037; Mon, 21 Oct 2002 10:43:01 -0400 (EDT) Resent-Date: Mon, 21 Oct 2002 10:43:01 -0400 (EDT) Resent-Message-Id: <200210211443.g9LEh1b11037@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9LEh1B11011 for ; Mon, 21 Oct 2002 10:43:01 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA19411 for ; Mon, 21 Oct 2002 10:43:01 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 21 Oct 2002 10:31:20 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403YBTY1>; Mon, 21 Oct 2002 10:42:29 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Mon, 21 Oct 2002 10:42:26 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27910.13474270" Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6897 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27910.13474270 Content-Type: text/plain I agree with Stefan's proposal. The key semantics that we wanted to maintain is that "if the resource exists, it exists at the original URL". Stefan's proposal maintains this semantics, without the complexity that could result from a "delete all the bindings" approach. With the DAV:parent-set property, a client can try to delete all the bindings, if it wants to do so, and can deal with any deletion failures as they arise. Note that 3253 does not have any "delete all the bindings" wording, so his proposal is consistent with 3253. Cheers, Geoff -----Original Message----- From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] The conformant behaviour would be to disallow DELETE on "the" uri of a version/version history unless the uri is already the last bindung to the resource. This would avoid the requirement that *all other* binding must be removed which is exactly the opposite of what the binding spec (currently) says. //Stefan Am Montag, 21.10.02, um 16:20 Uhr (Europe/Berlin) schrieb Julian Reschke: > >> Clemm, Geoff >> >> I believe the answer should be (c). >> The original binding to a version or a version >> history has special semantics (i.e. if you >> delete it, the resource is destroyed, and all bindings >> to it are destroyed), while additional bindings (such >> as those in a working collection) just have normal DELETE >> semantics, i.e. just that binding is deleted. >> So MOVE would not be allowed on the original binding, >> but is allowed on any other bindings. >> And yes, once the BIND protocol is standardized, the >> next revision of the DeltaV protocol should add the appropriate >> preconditions to handle BIND semantics. > > I really have a problem with this approach. The BIND spec just > clarified > DELETE to mean: > > "The DELETE method requests that the server remove the binding between > the > resource identified by the Request-URI and the binding name, the last > path > segment of the Request-URI. The binding MUST be removed from its parent > collection, identified by the Request-URI minus its trailing slash (if > present) and final segment. > > Once a resource is unreachable by any URI mapping, the server MAY > reclaim > system resources associated with that resource. If DELETE removes a > binding > to a resource, but there remain URI mappings to that resource, the > server > MUST NOT reclaim system resources associated with the resource." > > You seem to say that other specs are allowed to override this > definition. In > which case I'd claim that the model that the BIND spec tries to > establish > isn't correct, and that we shouldn't attempt to establish this > definition > for deletes of bindings. > > IMHO, > > - up until now, specs usually defined DELETE as *both* removing the URI > mapping and the destruction of resources, > > - the BIND spec changes this view so that the resource MAY be > destroyed when > the last binding disappears, > > - therefore, DELETE behaviour defined in old specs should now be > understood > as definining what may occur when the last binding disappears. > > In this particular case, I'd like to understand why we actually want to > forbid MOVE on versions and version histories. I understand that once > a URI > has been allocated for a version or a VHR, it should never identity > anything > else. So the defined contract basically guarantees that upon > GET/PROPFIND on > this URI, I will either > > - access the very same resource or > - that I'll get a 404. > > I don't think that we need the special MOVE conditions to guarantee > this. > From a client's point of view, it's irrelevant whether the resource is > gone > or is now "somewhere else" (yes, servers may want to forbid the MOVE > for > other reasons). > > Julian > > ------_=_NextPart_001_01C27910.13474270 Content-Type: text/html RE: BIND vs. non-movable resources in RFC3253

I agree with Stefan's proposal.

The key semantics that we wanted to maintain is that "if the
resource exists, it exists at the original URL".  Stefan's
proposal maintains this semantics, without the complexity that
could result from a "delete all the bindings" approach.
With the DAV:parent-set property, a client can try to delete
all the bindings, if it wants to do so, and can deal with any
deletion failures as they arise.

Note that 3253 does not have any "delete all the bindings"
wording, so his proposal is consistent with 3253.

Cheers,
Geoff

-----Original Message-----
From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]

The conformant behaviour would be to disallow DELETE on "the" uri of a
version/version history unless the uri is already the last bindung to
the
resource.

This would avoid the requirement that *all other* binding must be
removed
which is exactly the opposite of what the binding spec (currently) says.

//Stefan

Am Montag, 21.10.02, um 16:20 Uhr (Europe/Berlin) schrieb Julian
Reschke:

>
>> Clemm, Geoff
>>
>> I believe the answer should be (c).
>> The original binding to a version or a version
>> history has special semantics (i.e. if you
>> delete it, the resource is destroyed, and all bindings
>> to it are destroyed), while additional bindings (such
>> as those in a working collection) just have normal DELETE
>> semantics, i.e. just that binding is deleted.
>> So MOVE would not be allowed on the original binding,
>> but is allowed on any other bindings.
>> And yes, once the BIND protocol is standardized, the
>> next revision of the DeltaV protocol should add the appropriate
>> preconditions to handle BIND semantics.
>
> I really have a problem with this approach. The BIND spec just
> clarified
> DELETE to mean:
>
> "The DELETE method requests that the server remove the binding between
> the
> resource identified by the Request-URI and the binding name, the last
> path
> segment of the Request-URI. The binding MUST be removed from its parent
> collection, identified by the Request-URI minus its trailing slash (if
> present) and final segment.
>
> Once a resource is unreachable by any URI mapping, the server MAY
> reclaim
> system resources associated with that resource. If DELETE removes a
> binding
> to a resource, but there remain URI mappings to that resource, the
> server
> MUST NOT reclaim system resources associated with the resource."
>
> You seem to say that other specs are allowed to override this
> definition. In
> which case I'd claim that the model that the BIND spec tries to
> establish
> isn't correct, and that we shouldn't attempt to establish this
> definition
> for deletes of bindings.
>
> IMHO,
>
> - up until now, specs usually defined DELETE as *both* removing the URI
> mapping and the destruction of resources,
>
> - the BIND spec changes this view so that the resource MAY be
> destroyed when
> the last binding disappears,
>
> - therefore, DELETE behaviour defined in old specs should now be
> understood
> as definining what may occur when the last binding disappears.
>
> In this particular case, I'd like to understand why we actually want to
> forbid MOVE on versions and version histories. I understand that once
> a URI
> has been allocated for a version or a VHR, it should never identity
> anything
> else. So the defined contract basically guarantees that upon
> GET/PROPFIND on
> this URI, I will either
>
> - access the very same resource or
> - that I'll get a 404.
>
> I don't think that we need the special MOVE conditions to guarantee
> this.
> From a client's point of view, it's irrelevant whether the resource is
> gone
> or is now "somewhere else" (yes, servers may want to forbid the MOVE
> for
> other reasons).
>
> Julian
>
>


------_=_NextPart_001_01C27910.13474270-- From w3c-dist-auth-request@w3.org Mon Oct 21 11:14:27 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA02429 for ; Mon, 21 Oct 2002 11:14:27 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9LFFZV16814; Mon, 21 Oct 2002 11:15:35 -0400 (EDT) Resent-Date: Mon, 21 Oct 2002 11:15:35 -0400 (EDT) Resent-Message-Id: <200210211515.g9LFFZV16814@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9LFFXB16782 for ; Mon, 21 Oct 2002 11:15:34 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id LAA30988 for ; Mon, 21 Oct 2002 11:15:33 -0400 Received: (qmail 18544 invoked by uid 0); 21 Oct 2002 15:15:02 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp016-rz3) with SMTP; 21 Oct 2002 15:15:02 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'Webdav WG'" Date: Mon, 21 Oct 2002 17:15:01 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6898 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Clemm, Geoff > Sent: Monday, October 21, 2002 4:42 PM > To: 'Webdav WG' > Subject: RE: BIND vs. non-movable resources in RFC3253 > > > I agree with Stefan's proposal. > The key semantics that we wanted to maintain is that "if the > resource exists, it exists at the original URL". Stefan's Do we agree that *the* key semantics is that a URL that has been assigned to a version or a VHR never is assigned to anything else? In which case I don't understand why the special MOVE semantics (that we're causing me to start this thread) are relevant. Why don't we gust get rid of them? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Oct 21 12:41:52 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05504 for ; Mon, 21 Oct 2002 12:41:52 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9LGbwG01718; Mon, 21 Oct 2002 12:37:58 -0400 (EDT) Resent-Date: Mon, 21 Oct 2002 12:37:58 -0400 (EDT) Resent-Message-Id: <200210211637.g9LGbwG01718@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9LGbuB01677 for ; Mon, 21 Oct 2002 12:37:56 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA21866 for ; Mon, 21 Oct 2002 12:37:55 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 21 Oct 2002 12:26:14 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403YB7PM>; Mon, 21 Oct 2002 12:37:23 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Mon, 21 Oct 2002 12:37:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27920.1D024E80" Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6899 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27920.1D024E80 Content-Type: text/plain; charset="iso-8859-1" It is also desireable that a client be able to use the original URL as long as that resource exists. Stefan's proposal ensures that is the case. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Monday, October 21, 2002 11:15 AM To: Clemm, Geoff; 'Webdav WG' Subject: RE: BIND vs. non-movable resources in RFC3253 > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Clemm, Geoff > Sent: Monday, October 21, 2002 4:42 PM > To: 'Webdav WG' > Subject: RE: BIND vs. non-movable resources in RFC3253 > > > I agree with Stefan's proposal. > The key semantics that we wanted to maintain is that "if the > resource exists, it exists at the original URL". Stefan's Do we agree that *the* key semantics is that a URL that has been assigned to a version or a VHR never is assigned to anything else? In which case I don't understand why the special MOVE semantics (that we're causing me to start this thread) are relevant. Why don't we gust get rid of them? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 ------_=_NextPart_001_01C27920.1D024E80 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: BIND vs. non-movable resources in RFC3253

It is also desireable that a client be able to = use
the original URL as long as that resource = exists.

Stefan's proposal ensures that is the case.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]<= /FONT>
Sent: Monday, October 21, 2002 11:15 AM
To: Clemm, Geoff; 'Webdav WG'
Subject: RE: BIND vs. non-movable resources in = RFC3253


> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-reques= t@w3.org]On
> Behalf Of Clemm, Geoff
> Sent: Monday, October 21, 2002 4:42 PM
> To: 'Webdav WG'
> Subject: RE: BIND vs. non-movable resources in = RFC3253
>
>
> I agree with Stefan's proposal.
> The key semantics that we wanted to maintain is = that "if the
> resource exists, it exists at the original = URL".  Stefan's

Do we agree that *the* key semantics is that a URL = that has been assigned to
a version or a VHR never is assigned to anything = else?

In which case I don't understand why the special MOVE = semantics (that we're
causing me to start this thread) are relevant. Why = don't we gust get rid of
them?

Julian

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

------_=_NextPart_001_01C27920.1D024E80-- From w3c-dist-auth-request@w3.org Mon Oct 21 12:56:21 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA05846 for ; Mon, 21 Oct 2002 12:56:21 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9LGvsF06085; Mon, 21 Oct 2002 12:57:54 -0400 (EDT) Resent-Date: Mon, 21 Oct 2002 12:57:54 -0400 (EDT) Resent-Message-Id: <200210211657.g9LGvsF06085@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9LGvrB06059 for ; Mon, 21 Oct 2002 12:57:53 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA28203 for ; Mon, 21 Oct 2002 12:57:51 -0400 Received: (qmail 5094 invoked by uid 0); 21 Oct 2002 16:57:20 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp004-rz3) with SMTP; 21 Oct 2002 16:57:20 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'Webdav WG'" Date: Mon, 21 Oct 2002 18:57:19 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6900 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Clemm, Geoff > Sent: Monday, October 21, 2002 6:37 PM > To: 'Webdav WG' > Subject: RE: BIND vs. non-movable resources in RFC3253 > > > It is also desireable that a client be able to use > the original URL as long as that resource exists. But why? It *is* allowed to delete the resource, so there's no guarantee that the version/VHR will be kept eternally. From a client's point of view, it's completely irrelevant whether it's getting the 404 because the resource was deleted or because it was moved. > Stefan's proposal ensures that is the case. Yes, but it makes the model more complicated with little benefit. Forbidding a DELETE on a binding just because other bindings continue to exist seems to contradict the intent of the BIND spec. Therefore I'd like to see better reasons why we really need that. In doubt, we should *simplify* things, not make them more complicated. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Oct 21 13:26:43 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07042 for ; Mon, 21 Oct 2002 13:26:42 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9LHRdG09929; Mon, 21 Oct 2002 13:27:39 -0400 (EDT) Resent-Date: Mon, 21 Oct 2002 13:27:39 -0400 (EDT) Resent-Message-Id: <200210211727.g9LHRdG09929@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9LHRbB09903 for ; Mon, 21 Oct 2002 13:27:37 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA03556 for ; Mon, 21 Oct 2002 13:27:37 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 21 Oct 2002 13:15:56 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403YCBHM>; Mon, 21 Oct 2002 13:27:06 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Mon, 21 Oct 2002 13:27:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27927.11715280" Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6901 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27927.11715280 Content-Type: text/plain; charset="iso-8859-1" The purpose of a stable URL for a version and a version history is to guarantee that that URL will always identify that resource. This provides the client with two benefits: The first is that it can just pass that URL around and not have to worry about getting the wrong resource because that URL has been remapped to another resource. The second is to give the client a "reliable" way to locate the resource (i.e. a mapping that only goes away when the resource no longer exists). I believe the second benefit is worth the added complexity of saying "the stable binding cannot be deleted if there are multiple entries in the DAV:parent-set". Whether or not this is a a significant benefit of course depends on whether your client takes advantage of it, but I think the cost is minimal, especially since these kinds of bindings are already constrained to never be remapped to another resource. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Monday, October 21, 2002 12:57 PM To: Clemm, Geoff; 'Webdav WG' Subject: RE: BIND vs. non-movable resources in RFC3253 > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Clemm, Geoff > Sent: Monday, October 21, 2002 6:37 PM > To: 'Webdav WG' > Subject: RE: BIND vs. non-movable resources in RFC3253 > > > It is also desireable that a client be able to use > the original URL as long as that resource exists. But why? It *is* allowed to delete the resource, so there's no guarantee that the version/VHR will be kept eternally. From a client's point of view, it's completely irrelevant whether it's getting the 404 because the resource was deleted or because it was moved. > Stefan's proposal ensures that is the case. Yes, but it makes the model more complicated with little benefit. Forbidding a DELETE on a binding just because other bindings continue to exist seems to contradict the intent of the BIND spec. Therefore I'd like to see better reasons why we really need that. In doubt, we should *simplify* things, not make them more complicated. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 ------_=_NextPart_001_01C27927.11715280 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: BIND vs. non-movable resources in RFC3253

The purpose of a stable URL for a version and a = version
history is to guarantee that that URL will always = identify
that resource.  This provides the client with = two benefits:

The first is that it can just pass that URL = around
and not have to worry about getting the wrong
resource because that URL has been remapped to = another
resource.

The second is to give the client a = "reliable" way to locate
the resource (i.e. a mapping that only goes away = when the
resource no longer exists).

I believe the second benefit is worth the added = complexity
of saying "the stable binding cannot be deleted = if there
are multiple entries in the = DAV:parent-set".

Whether or not this is a a significant benefit of = course
depends on whether your client takes advantage of = it, but I
think the cost is minimal, especially since these = kinds of
bindings are already constrained to never be = remapped to
another resource.

Cheers,
Geoff
 

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]<= /FONT>
Sent: Monday, October 21, 2002 12:57 PM
To: Clemm, Geoff; 'Webdav WG'
Subject: RE: BIND vs. non-movable resources in = RFC3253


> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-reques= t@w3.org]On
> Behalf Of Clemm, Geoff
> Sent: Monday, October 21, 2002 6:37 PM
> To: 'Webdav WG'
> Subject: RE: BIND vs. non-movable resources in = RFC3253
>
>
> It is also desireable that a client be able to = use
> the original URL as long as that resource = exists.

But why? It *is* allowed to delete the resource, so = there's no guarantee
that the version/VHR will be kept eternally. From a = client's point of view,
it's completely irrelevant whether it's getting the = 404 because the resource
was deleted or because it was moved.

> Stefan's proposal ensures that is the = case.

Yes, but it makes the model more complicated with = little benefit. Forbidding
a DELETE on a binding just because other bindings = continue to exist seems to
contradict the intent of the BIND spec. Therefore = I'd like to see better
reasons why we really need that. In doubt, we should = *simplify* things, not
make them more complicated.

Julian

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

------_=_NextPart_001_01C27927.11715280-- From w3c-dist-auth-request@w3.org Mon Oct 21 13:47:30 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07861 for ; Mon, 21 Oct 2002 13:47:30 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9LHmeA14191; Mon, 21 Oct 2002 13:48:40 -0400 (EDT) Resent-Date: Mon, 21 Oct 2002 13:48:40 -0400 (EDT) Resent-Message-Id: <200210211748.g9LHmeA14191@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9LHmcB14161 for ; Mon, 21 Oct 2002 13:48:38 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA07838 for ; Mon, 21 Oct 2002 13:48:37 -0400 Received: (qmail 31467 invoked by uid 0); 21 Oct 2002 17:48:06 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp003-rz3) with SMTP; 21 Oct 2002 17:48:06 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'Webdav WG'" Date: Mon, 21 Oct 2002 19:48:06 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6902 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Clemm, Geoff > Sent: Monday, October 21, 2002 7:27 PM > To: 'Webdav WG' > Subject: RE: BIND vs. non-movable resources in RFC3253 > > > The purpose of a stable URL for a version and a version > history is to guarantee that that URL will always identify > that resource. This provides the client with two benefits: > The first is that it can just pass that URL around > and not have to worry about getting the wrong > resource because that URL has been remapped to another > resource. Agreed and not controversial. > The second is to give the client a "reliable" way to locate > the resource (i.e. a mapping that only goes away when the > resource no longer exists). And here I still don't see the benefit. Forbidding MOVE just to achieve this seems to be unnecessarily restrictive. The client can't rely on the resource being available anyway -- what difference does it make *why* it's not available anymore behind the request URI? > I believe the second benefit is worth the added complexity > of saying "the stable binding cannot be deleted if there > are multiple entries in the DAV:parent-set". You just introduced the new term "the stable binding" :-) Again: if there's a choice between simplying and complicating things, we should try to simplify the model, unless an *essential* feature requires this. I fail to see why the second benefit would be essential. > Whether or not this is a a significant benefit of course > depends on whether your client takes advantage of it, but I (*) *How* would a client take advantage of this benefit? > think the cost is minimal, especially since these kinds of > bindings are already constrained to never be remapped to > another resource. Why is this relevant? The ability not to re-use a previously assigned binding is a property of the collection containing the binding. If my server allows deletion of VHRs and/or versions, it will have to be able to take care of this anyway -- it doesn't matter at all whether the binding disappeared because of a DELETE or a MOVE. So, I'm still unconvinced. Can we concentrate on the question marked (*)? -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Oct 21 15:23:53 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12287 for ; Mon, 21 Oct 2002 15:23:53 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9LJP6g07230; Mon, 21 Oct 2002 15:25:06 -0400 (EDT) Resent-Date: Mon, 21 Oct 2002 15:25:06 -0400 (EDT) Resent-Message-Id: <200210211925.g9LJP6g07230@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9LJP5B07203 for ; Mon, 21 Oct 2002 15:25:05 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA04585 for ; Mon, 21 Oct 2002 15:25:05 -0400 Received: (qmail 1005 invoked by uid 0); 21 Oct 2002 19:24:33 -0000 Received: from p3ee24750.dip.t-dialin.net (HELO lisa) (62.226.71.80) by mail.gmx.net (mp010-rz3) with SMTP; 21 Oct 2002 19:24:33 -0000 From: "Julian Reschke" To: "Dan Brotsky" , Date: Mon, 21 Oct 2002 21:24:32 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: ETags, was: Issues from Interop/Interim WG Meeting Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6903 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think we are in violent agreement. Some comments inline. > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Dan Brotsky > Sent: Wednesday, October 16, 2002 5:49 PM > To: w3c-dist-auth@w3.org > Cc: Dan Brotsky > Subject: Re: ETags, was: Issues from Interop/Interim WG Meeting > > > > Once again, sorry for being so long about joining this thread. I'll > try to phrase this proposal in a way that I think addresses all the > issues that have been raised. I excerpt arguments from various pieces > of mail in what follows, and I apologize in advance if you feel I do > not do your point justice. > > Proposal: Add the following language (adapted from 2616 and 2518) to > 2518-bis: > > WebDAV origin servers: > > - MUST send an entity tag validator unless it is not feasible to > generate one. > > - MAY send a weak entity tag instead of a strong entity tag, if > performance considerations support the use of weak entity tags, > or if it is unfeasible to send a strong entity tag. > > - MUST NOT send either a strong or weak entity tag in response > to any request on a resource unless it ALWAYS sends such a tag > in response to every such request. I'm not sure about what this means. A variant may or may not have an entity tag. If it does, it MUST be reported. > - MUST define the DAV:getetag property for any DAV-compliant > resource if and only if it responds to GET requests with > strong or weak entity tags. Clarification. The DAV:getetag property MUST be *present* on a resource (for a particular PROPFIND request), if a HEAD or GET request with the same request headers would return an etag header. Otherwise, it MUST not be present. We may have to discuss whether it may be reported in DAV:supported-live-property-set, though. Generally, all DAV:get* properties MUST be present if they would be returned in a HEAD/GET with the same request headers, and MUST NOT be returned otherwise. In particular, DAV:getcontentlength MUST NOT be returned as empty if the content length is unknown (instead, it should not be present at all). Similarily, properties such as DAV:getcontentlanguage must only be present if the content language actually is *known*. > WebDAV clients: > > - SHOULD use a PROPFIND on the DAV:getetag property of a resource > in order to determine whether that resource supports entity tags. ETag is an entity header, so it doesn't apply to an abstract resource -- it applies to a specific variant. We must be careful here -- there may be cases where some of the variants of a resource have entity tags while others don't. > - MAY choose not to support authoring of a resource that does not > support entity tags Sure. > - MAY warn users, when authoring resources that do not support > entity tags, that they cannot be protected from lost updates. Sure. Although RFC2518-compliant locks should work as well :-) > I think this addresses the following issues which came up in the > discussion: > > 1. Servers are not required to support etags for resources for which it > is infeasible to do so. However, they are required to be completely > consistent about whether they do or not for a given resource, so that > clients can be assured from the results of just one call what the > situation is. See above. I think we need to be careful to distinguish between the resource and its representations (the latter have entity tags, the former don't). Note that Roy F. says that authorable (PUTtable) resources always have exactly one variant (but this is just one opinion :-). > 2. Julian's excellent suggestion for how clients should figure this out > is made a SHOULD, and the loopholes that might have made clients > nervous about using it are closed. I think these are caused by - fuzzy wording in RFC2518 and - particulary broken clients that *require* the presence of all DAV:get* properties (even when they do not exist). > ... > 7. Julian was concerned that servers which, for example, simply serve > simple filesystems (using no additinal machinery) might not be able to > meet this requirement, and that in their desire to meet it they would > accidentally produce buggy implementations. I think his more general > point (that people sometimes produce buggy implementations when specs > get more stringent or require new features) is unassailable, but in > this particular case: > > - if they don't see how they can't support etags then they're OK, cause > they don't have to. They just have to NOT support etags consistently > :^). > > - I believe that, in such a case, the filesystem's internal timestamp > is arguably a fine thing to use as an etag. If the DAV server in > question doesn't allow changes except to content (which presumably it > doesn't because it has no other machinery to store properties with, and > the filesystem properties are not generally mutable), then using the > timestamp as an etag is quite reliable, the server simply has to ensure > that no two PUT requests are processed within the resolution of a > single filesystem timestamp value. And, as Geoff would say :^), how > hard could this be? (Sorry, couldn't resist...) That sure is a valid workaround, but it may not be always practical: - performance for frequent updates will be bad and - you may use a filesystem that also has alternate access paths (for instance as a network mount) -- in this case, you can't guarantee that nobody *else* is modifiying the content more than once per second Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Oct 21 15:28:18 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA12445 for ; Mon, 21 Oct 2002 15:28:18 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9LJTI207712; Mon, 21 Oct 2002 15:29:18 -0400 (EDT) Resent-Date: Mon, 21 Oct 2002 15:29:18 -0400 (EDT) Resent-Message-Id: <200210211929.g9LJTI207712@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9LJTHB07683 for ; Mon, 21 Oct 2002 15:29:17 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA05590 for ; Mon, 21 Oct 2002 15:29:16 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 21 Oct 2002 15:17:35 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403YC26J>; Mon, 21 Oct 2002 15:28:45 -0400 Message-ID: From: "Clemm, Geoff" To: "'Webdav WG'" Date: Mon, 21 Oct 2002 15:28:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27938.0CE726C0" Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6904 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27938.0CE726C0 Content-Type: text/plain; charset="iso-8859-1" The benefit that I want us to provide is giving the client the ability to store away a URL in a text file (or in some email) with the confidence that this URL will continue to work, short of the complete destruction/disappearance of the resource. If another client is allowed to remap this resource to a different URL, the original URL no longer provides this service. It's very analagous to making a version immutable. It would be simpler (and more "flexible") to allow any client to change the content of a version, and just depend on "convention" to leave the version content alone. But then a client can't count on this being true, and has to figure out some way to workaround the lack of enforced semantics. (This is just an analogy, so if it doesn't work for you, please just ignore it, rather than try to prove it "wrong" :-). BTW, the term "stable" is used in section 1 of RFC3253, to describe this desireale characteristic of a version URL. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Monday, October 21, 2002 1:48 PM To: Clemm, Geoff; 'Webdav WG' Subject: RE: BIND vs. non-movable resources in RFC3253 > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Clemm, Geoff > Sent: Monday, October 21, 2002 7:27 PM > To: 'Webdav WG' > Subject: RE: BIND vs. non-movable resources in RFC3253 > > > The purpose of a stable URL for a version and a version > history is to guarantee that that URL will always identify > that resource. This provides the client with two benefits: > The first is that it can just pass that URL around > and not have to worry about getting the wrong > resource because that URL has been remapped to another > resource. Agreed and not controversial. > The second is to give the client a "reliable" way to locate > the resource (i.e. a mapping that only goes away when the > resource no longer exists). And here I still don't see the benefit. Forbidding MOVE just to achieve this seems to be unnecessarily restrictive. The client can't rely on the resource being available anyway -- what difference does it make *why* it's not available anymore behind the request URI? > I believe the second benefit is worth the added complexity > of saying "the stable binding cannot be deleted if there > are multiple entries in the DAV:parent-set". You just introduced the new term "the stable binding" :-) Again: if there's a choice between simplying and complicating things, we should try to simplify the model, unless an *essential* feature requires this. I fail to see why the second benefit would be essential. > Whether or not this is a a significant benefit of course > depends on whether your client takes advantage of it, but I (*) *How* would a client take advantage of this benefit? > think the cost is minimal, especially since these kinds of > bindings are already constrained to never be remapped to > another resource. Why is this relevant? The ability not to re-use a previously assigned binding is a property of the collection containing the binding. If my server allows deletion of VHRs and/or versions, it will have to be able to take care of this anyway -- it doesn't matter at all whether the binding disappeared because of a DELETE or a MOVE. So, I'm still unconvinced. Can we concentrate on the question marked (*)? -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 ------_=_NextPart_001_01C27938.0CE726C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: BIND vs. non-movable resources in RFC3253

The benefit that I want us to provide is giving = the
client the ability to store away a URL in a text = file (or
in some email) with the confidence that this URL = will continue
to work, short of the complete = destruction/disappearance of
the resource.  If another client is allowed to = remap this
resource to a different URL, the original URL no = longer
provides this service.

It's very analagous to making a version = immutable.  It would
be simpler (and more "flexible") to allow = any client to change
the content of a version, and just depend on = "convention" to
leave the version content alone.  But then a = client can't count
on this being true, and has to figure out some way = to workaround
the lack of enforced semantics.  (This is just = an analogy, so
if it doesn't work for you, please just ignore it, = rather than
try to prove it "wrong" :-).

BTW, the term "stable" is used in section 1 = of RFC3253, to
describe this desireale characteristic of a version = URL.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]<= /FONT>
Sent: Monday, October 21, 2002 1:48 PM
To: Clemm, Geoff; 'Webdav WG'
Subject: RE: BIND vs. non-movable resources in = RFC3253


> From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-reques= t@w3.org]On
> Behalf Of Clemm, Geoff
> Sent: Monday, October 21, 2002 7:27 PM
> To: 'Webdav WG'
> Subject: RE: BIND vs. non-movable resources in = RFC3253
>
>
> The purpose of a stable URL for a version and a = version
> history is to guarantee that that URL will = always identify
> that resource.  This provides the client = with two benefits:
> The first is that it can just pass that URL = around
> and not have to worry about getting the = wrong
> resource because that URL has been remapped to = another
> resource.

Agreed and not controversial.

> The second is to give the client a = "reliable" way to locate
> the resource (i.e. a mapping that only goes = away when the
> resource no longer exists).

And here I still don't see the benefit. Forbidding = MOVE just to achieve this
seems to be unnecessarily restrictive. The client = can't rely on the resource
being available anyway -- what difference does it = make *why* it's not
available anymore behind the request URI?

> I believe the second benefit is worth the added = complexity
> of saying "the stable binding cannot be = deleted if there
> are multiple entries in the = DAV:parent-set".

You just introduced the new term "the stable = binding" :-)

Again: if there's a choice between simplying and = complicating things, we
should try to simplify the model, unless an = *essential* feature requires
this. I fail to see why the second benefit would be = essential.

> Whether or not this is a a significant benefit = of course
> depends on whether your client takes advantage = of it, but I

(*) *How* would a client take advantage of this = benefit?

> think the cost is minimal, especially since = these kinds of
> bindings are already constrained to never be = remapped to
> another resource.

Why is this relevant? The ability not to re-use a = previously assigned
binding is a property of the collection containing = the binding. If my server
allows deletion of VHRs and/or versions, it will = have to be able to take
care of this anyway -- it doesn't matter at all = whether the binding
disappeared because of a DELETE or a MOVE.

So, I'm still unconvinced.

Can we concentrate on the question marked (*)?

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

------_=_NextPart_001_01C27938.0CE726C0-- From w3c-dist-auth-request@w3.org Mon Oct 21 16:23:24 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13953 for ; Mon, 21 Oct 2002 16:23:24 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9LKOdQ18332; Mon, 21 Oct 2002 16:24:39 -0400 (EDT) Resent-Date: Mon, 21 Oct 2002 16:24:39 -0400 (EDT) Resent-Message-Id: <200210212024.g9LKOdQ18332@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9LKOcB18306 for ; Mon, 21 Oct 2002 16:24:38 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA15919 for ; Mon, 21 Oct 2002 16:24:37 -0400 Received: (qmail 19600 invoked by uid 0); 21 Oct 2002 20:24:06 -0000 Received: from p3ee2480e.dip.t-dialin.net (HELO lisa) (62.226.72.14) by mail.gmx.net (mp005-rz3) with SMTP; 21 Oct 2002 20:24:06 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "'Webdav WG'" Date: Mon, 21 Oct 2002 22:24:05 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6905 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Clemm, Geoff > Sent: Monday, October 21, 2002 9:29 PM > To: 'Webdav WG' > Subject: RE: BIND vs. non-movable resources in RFC3253 > > > The benefit that I want us to provide is giving the > client the ability to store away a URL in a text file (or > in some email) with the confidence that this URL will continue > to work, short of the complete destruction/disappearance of > the resource. If another client is allowed to remap this So do I. The only difference is that I think that it's irrelevant whether the resource was deleted or moved away. Could you please explain why this would affect a client? The consequence (the prior URI not being mapped to a resource anymore) is the same. > resource to a different URL, the original URL no longer > provides this service. It still can be used the same way as described by you. The only difference is that if the URI mapping is removed, a client can not assume that the resource itself was removed. But why would that matter? Could you please state a use case where this really makes a difference? And if it really does matter, where does this leave us with the BIND spec (see below)? > It's very analagous to making a version immutable. It would > be simpler (and more "flexible") to allow any client to change > the content of a version, and just depend on "convention" to > leave the version content alone. But then a client can't count > on this being true, and has to figure out some way to workaround > the lack of enforced semantics. (This is just an analogy, so > if it doesn't work for you, please just ignore it, rather than > try to prove it "wrong" :-). Hm. I'll only state that I'm *not* proposing to make a version mutable. I just think that making it *movable* makes the model much simpler and avoids making special workarounds for bindings (note that this doesn'r *require* a server to allow MOVE on it). The intent of the BIND spec is to decouple names (bindings) from resources. I think we should try to adhere to it. In particular, if existing protocols need to be fixed to account for bindings, I fear that we're doing something wrong. > BTW, the term "stable" is used in section 1 of RFC3253, to > describe this desireale characteristic of a version URL. Agreed (although it is "stable name" in RFC3253). -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Oct 21 16:34:48 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA14417 for ; Mon, 21 Oct 2002 16:34:48 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9LKSKZ19065; Mon, 21 Oct 2002 16:28:20 -0400 (EDT) Resent-Date: Mon, 21 Oct 2002 16:28:20 -0400 (EDT) Resent-Message-Id: <200210212028.g9LKSKZ19065@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9LKSJB19039 for ; Mon, 21 Oct 2002 16:28:19 -0400 (EDT) Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA16997 for ; Mon, 21 Oct 2002 16:28:18 -0400 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id g9LKRr210524 for ; Mon, 21 Oct 2002 13:27:54 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Mon, 21 Oct 2002 13:24:52 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6906 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Perhaps what's lying at the core of this issue is a difference in assumption over who controls the namespace. The binding specification assumes that in WebDAV-compliant portions of the namespace, the client has a large degree of control over naming and deletion. Resources are created at locations the client specifies, can be moved to places the client wants, and rebound to new names at will. The non-movable resources in DeltaV are typically created by the server, at names the server chooses. Often these resources won't be represented the same way as "file-like" resources, and will instead be acting as the handle for a computational process that queries the versioned repository to return property data. That is, they act more like a servlet or a CGI. In this case, it's important for the server to have these resources at the place where it created them, since that's where its software expects queries against those resources to be directed. (It's additionally important that they stay in the same place for the indentification usability issues Geoff outlined). IMO, accommodating this difference requires explicitly acknowledging the two different classes of resource binding behavior (fixed vs. free) and then explicitly adding language describing the behavior of fixed types to the binding specification (something similar to Stephan's language would probably work). Revisions to DeltaV can indicate, for all DeltaV resource types, what kind of binding behavior they exhibit. As for why we should add this language -- the idea is to make it so that a client, when encountering resources of both types, can behave intelligently, without having to perform trial and error to accomplish useful tasks. - Jim From w3c-dist-auth-request@w3.org Mon Oct 21 17:37:31 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA16325 for ; Mon, 21 Oct 2002 17:37:31 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9LLciO28405; Mon, 21 Oct 2002 17:38:44 -0400 (EDT) Resent-Date: Mon, 21 Oct 2002 17:38:44 -0400 (EDT) Resent-Message-Id: <200210212138.g9LLciO28405@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9LLcgB28379 for ; Mon, 21 Oct 2002 17:38:42 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA30699 for ; Mon, 21 Oct 2002 17:38:42 -0400 Received: (qmail 2014 invoked by uid 0); 21 Oct 2002 21:38:11 -0000 Received: from p3ee2480e.dip.t-dialin.net (HELO lisa) (62.226.72.14) by mail.gmx.net (mp016-rz3) with SMTP; 21 Oct 2002 21:38:11 -0000 From: "Julian Reschke" To: "Jim Whitehead" , "WebDAV" Date: Mon, 21 Oct 2002 23:38:09 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6907 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Monday, October 21, 2002 10:25 PM > To: WebDAV > Subject: RE: BIND vs. non-movable resources in RFC3253 > > > > Perhaps what's lying at the core of this issue is a difference in assumption > over who controls the namespace. The binding specification assumes that in > WebDAV-compliant portions of the namespace, the client has a large degree of > control over naming and deletion. Resources are created at locations the > client specifies, can be moved to places the client wants, and rebound to > new names at will. > > The non-movable resources in DeltaV are typically created by the server, at > names the server chooses. Often these resources won't be represented the > same way as "file-like" resources, and will instead be acting as the handle > for a computational process that queries the versioned repository > to return property data. That is, they act more like a servlet or a CGI. In > this case, it's important for the server to have these resources at the place where it > created them, since that's where its software expects queries against those Jim, nobody is saying that this is a non-compliant way to implement RFC3253. The point is -- just because some servers choose to implement RFC3253 this way, should this prevent other implementors to implement "full" namespace control (except of re-use of assigned version and VHR URIs)? > resources to be directed. (It's additionally important that they stay in the > same place for the indentification usability issues Geoff outlined). Again, no. It's important that a URI that has once been assigned to a version or VHR never is assigned to anything else. However, for a client it is clearly not relevant whether it's getting a 404 because the resource was destroyed or because it was moved away (or for that matter, just the binding was deleted and the resource was moved to non-accessible storage). I'd like to hear why this is relevant, because it demonstratibly causes a conflict between the RFC3253 and the BIND spec. > IMO, accommodating this difference requires explicitly acknowledging the two > different classes of resource binding behavior (fixed vs. free) and then > explicitly adding language describing the behavior of fixed types to the > binding specification (something similar to Stephan's language would > probably work). Revisions to DeltaV can indicate, for all DeltaV resource > types, what kind of binding behavior they exhibit. Yes, the BIND spec should say something about these kind of resources. No, RFC3253 should not require implementors to actually restrict themselves to this kind of implementation. Trouble is, RFC3253 already talks about bindings to non-movable resources (for instance, a working collection contains bindings to version history resources). So we need to define what happens when you apply DELETE to a VHR-URI while another binding still appears somewhere else. Stefan's proposal works fine if your VHR resources are restricted in the way you explained. However, I'd strongly object to *requiring* this kind of implementation. Again, the primary and uncontroversial goal is that a version or VHR URI is never assigned to a different resource. This takes care of all the use cases I heard. I've yet to hear why it would be a problem if it's moved away. Why would it matter to a client? > As for why we should add this language -- the idea is to make it so that a > client, when encountering resources of both types, can behave intelligently, > without having to perform trial and error to accomplish useful tasks. Sure. Whatever a server implements, a client should be able to discover. To start with, BIND will need a precondition such as DAV:member-name-available - the member name to be created is available for use (because although not in use, it may be unusable because it already identified a VHR or a version) Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Mon Oct 21 18:27:24 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA17452 for ; Mon, 21 Oct 2002 18:27:24 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9LMSaJ05115; Mon, 21 Oct 2002 18:28:36 -0400 (EDT) Resent-Date: Mon, 21 Oct 2002 18:28:36 -0400 (EDT) Resent-Message-Id: <200210212228.g9LMSaJ05115@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9LMSZB05085 for ; Mon, 21 Oct 2002 18:28:35 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA08038 for ; Mon, 21 Oct 2002 18:28:35 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 21 Oct 2002 18:16:53 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403YCTWP>; Mon, 21 Oct 2002 18:28:03 -0400 Message-ID: From: "Clemm, Geoff" To: WebDAV Date: Mon, 21 Oct 2002 18:27:56 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27951.1A7544C0" Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6908 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27951.1A7544C0 Content-Type: text/plain; charset="iso-8859-1" From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: Jim Whitehead > > Perhaps what's lying at the core of this issue is a difference in > assumption over who controls the namespace. The binding > specification assumes that in WebDAV-compliant portions of the > namespace, the client has a large degree of control over naming > and deletion. Resources are created at locations the client > specifies, can be moved to places the client wants, and rebound > to new names at will. > > The non-movable resources in DeltaV are typically created by the > server, at names the server chooses. Often these resources won't > be represented the same way as "file-like" resources, and will > instead be acting as the handle for a computational process that > queries the versioned repository to return property data. That > is, they act more like a servlet or a CGI. In this case, it's > important for the server to have these resources at the place > where it created them, since that's where its software expects > queries against those nobody is saying that this is a non-compliant way to implement RFC3253. The point is -- just because some servers choose to implement RFC3253 this way, should this prevent other implementors to implement "full" namespace control (except of re-use of assigned version and VHR URIs)? Yes, I believe that is precisely what RFC3253 should say. To refer to my earlier analogy, just because some clients want immutable content, should this prevent implementors from implementing "full" content control (i.e. allowing modification to checked in versions). The answer here is also, "yes". > resources to be directed. (It's additionally important that they > stay in the same place for the indentification usability issues > Geoff outlined). Again, no. I disagree. It's important that a URI that has once been assigned to a version or VHR never is assigned to anything else. We all agree on that. But the fact that a stable URI should have this characteristic, does not imply that it should not also have the other characteristic we are discussion in this thread. However, for a client it is clearly not relevant whether it's getting a 404 because the resource was destroyed or because it was moved away (or for that matter, just the binding was deleted and the resource was moved to non-accessible storage). I'd like to hear why this is relevant, because it demonstratibly causes a conflict between the RFC3253 and the BIND spec. The fact that a particular resource has additional restrictions in no way "conflicts" with the BIND spec. There will be a variety of reasons why a DELETE request will fail (authorization, locking, etc.). This is just another reason that applies to this particular binding. The condition is easy to specify and easy to understand (i.e. the DAV:parent-set must have only one member for DELETE to succeed on this URI). > IMO, accommodating this difference requires explicitly > acknowledging the two different classes of resource binding > behavior (fixed vs. free) and then explicitly adding language > describing the behavior of fixed types to the binding > specification (something similar to Stephan's language would > probably work). Revisions to DeltaV can indicate, for all DeltaV > resource types, what kind of binding behavior they exhibit. Yes, the BIND spec should say something about these kind of resources. No, RFC3253 should not require implementors to actually restrict themselves to this kind of implementation. I disagree. It is not an implementation issue, it is a client visible semantics issue. Is another client allowed to "hide" the resource at some other URL? No, and neither should it be able to change the "stable URL" for a version or version history. Trouble is, RFC3253 already talks about bindings to non-movable resources (for instance, a working collection contains bindings to version history resources). So we need to define what happens when you apply DELETE to a VHR-URI while another binding still appears somewhere else. Stefan's proposal works fine if your VHR resources are restricted in the way you explained. However, I'd strongly object to *requiring* this kind of implementation. This is a client semantics issue, not an implementation issue. Again, the primary and uncontroversial goal is that a version or VHR URI is never assigned to a different resource. This takes care of all the use cases I heard. I've yet to hear why it would be a problem if it's moved away. Why would it matter to a client? This is only one of the goals, and the additional goal we are discussing in this thread is consistent with this other goal. > As for why we should add this language -- the idea is to make it > so that a client, when encountering resources of both types, can > behave intelligently, without having to perform trial and error > to accomplish useful tasks. Sure. Whatever a server implements, a client should be able to discover. Querying a server to find out what it implements is the trial and error that we want the client to not have to do in this case. To start with, BIND will need a precondition such as DAV:member-name-available - the member name to be created is available for use (because although not in use, it may be unusable because it already identified a VHR or a version) It is more likely that the server will not support a BIND into that version or version history namespace, since as Jim pointed out, commonly this namespace is a computation based on the state of the resource, and not an actual directory or folder. But we could certainly add such a precondition if that error code is important. Cheers, Geoff ------_=_NextPart_001_01C27951.1A7544C0 Content-Type: text/html; charset="iso-8859-1" RE: BIND vs. non-movable resources in RFC3253

   From: Julian Reschke [mailto:julian.reschke@gmx.de]

   > From: Jim Whitehead
   >
   > Perhaps what's lying at the core of this issue is a difference in
   > assumption over who controls the namespace. The binding
   > specification assumes that in WebDAV-compliant portions of the
   > namespace, the client has a large degree of control over naming
   > and deletion. Resources are created at locations the client
   > specifies, can be moved to places the client wants, and rebound
   > to new names at will.
   >
   > The non-movable resources in DeltaV are typically created by the
   > server, at names the server chooses. Often these resources won't
   > be represented the same way as "file-like" resources, and will
   > instead be acting as the handle for a computational process that
   > queries the versioned repository to return property data. That
   > is, they act more like a servlet or a CGI.  In this case, it's
   > important for the server to have these resources at the place
   > where it created them, since that's where its software expects
   > queries against those

   nobody is saying that this is a non-compliant way to implement
   RFC3253. The point is -- just because some servers choose to
   implement RFC3253 this way, should this prevent other implementors
   to implement "full" namespace control (except of re-use of assigned
   version and VHR URIs)?

Yes, I believe that is precisely what RFC3253 should say.  To refer to
my earlier analogy, just because some clients want immutable content,
should this prevent implementors from implementing "full" content
control (i.e. allowing modification to checked in versions).  The
answer here is also, "yes".

   > resources to be directed. (It's additionally important that they
   > stay in the same place for the indentification usability issues
   > Geoff outlined).

   Again, no.

I disagree.

   It's important that a URI that has once been assigned to a version
   or VHR never is assigned to anything else.

We all agree on that.  But the fact that a stable URI should have this
characteristic, does not imply that it should not also have the other
characteristic we are discussion in this thread.

   However, for a client it is clearly not relevant whether it's
   getting a 404 because the resource was destroyed or because it was
   moved away (or for that matter, just the binding was deleted and
   the resource was moved to non-accessible storage). I'd like to hear
   why this is relevant, because it demonstratibly causes a conflict
   between the RFC3253 and the BIND spec.

The fact that a particular resource has additional restrictions
in no way "conflicts" with the BIND spec.  There will be a variety
of reasons why a DELETE request will fail (authorization, locking,
etc.).  This is just another reason that applies to this particular
binding.  The condition is easy to specify and easy to understand
(i.e. the DAV:parent-set must have only one member for DELETE to
succeed on this URI).

   > IMO, accommodating this difference requires explicitly
   > acknowledging the two different classes of resource binding
   > behavior (fixed vs. free) and then explicitly adding language
   > describing the behavior of fixed types to the binding
   > specification (something similar to Stephan's language would
   > probably work). Revisions to DeltaV can indicate, for all DeltaV
   > resource types, what kind of binding behavior they exhibit.

   Yes, the BIND spec should say something about these kind of
   resources. No, RFC3253 should not require implementors to actually
   restrict themselves to this kind of implementation.

I disagree.  It is not an implementation issue,
it is a client visible semantics issue.  Is another client allowed to
"hide" the resource at some other URL?  No, and neither should it
be able to change the "stable URL" for a version or version history.

   Trouble is, RFC3253 already talks about bindings to non-movable
   resources (for instance, a working collection contains bindings to
   version history resources). So we need to define what happens when
   you apply DELETE to a VHR-URI while another binding still appears
   somewhere else. Stefan's proposal works fine if your VHR resources
   are restricted in the way you explained. However, I'd strongly
   object to *requiring* this kind of implementation.

This is a client semantics issue, not an implementation issue.

   Again, the primary and uncontroversial goal is that a version or
   VHR URI is never assigned to a different resource. This takes care
   of all the use cases I heard. I've yet to hear why it would be a
   problem if it's moved away. Why would it matter to a client?

This is only one of the goals, and the additional goal
we are discussing in this thread is consistent with this other goal.

   > As for why we should add this language -- the idea is to make it
   > so that a client, when encountering resources of both types, can
   > behave intelligently, without having to perform trial and error
   > to accomplish useful tasks.

   Sure. Whatever a server implements, a client should be able to
   discover.

Querying a server to find out what it implements is the trial and
error that we want the client to not have to do in this case.

   To start with, BIND will need a precondition such as
   DAV:member-name-available - the member name to be created is
   available for use (because although not in use, it may be unusable
   because it already identified a VHR or a version)

It is more likely that the server will not support a BIND into
that version or version history namespace, since as Jim pointed out,
commonly this namespace is a computation based on the state of the
resource, and not an actual directory or folder.  But we could
certainly add such a precondition if that error code is important.

Cheers,
Geoff

------_=_NextPart_001_01C27951.1A7544C0-- From w3c-dist-auth-request@w3.org Mon Oct 21 19:16:22 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA18746 for ; Mon, 21 Oct 2002 19:16:22 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9LNGj008950; Mon, 21 Oct 2002 19:16:45 -0400 (EDT) Resent-Date: Mon, 21 Oct 2002 19:16:45 -0400 (EDT) Resent-Message-Id: <200210212316.g9LNGj008950@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9LNGiB08924 for ; Mon, 21 Oct 2002 19:16:44 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id TAA15500 for ; Mon, 21 Oct 2002 19:16:43 -0400 Received: (qmail 24422 invoked by uid 0); 21 Oct 2002 23:16:12 -0000 Received: from p3ee2480e.dip.t-dialin.net (HELO lisa) (62.226.72.14) by mail.gmx.net (mp003-rz3) with SMTP; 21 Oct 2002 23:16:12 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "WebDAV" Date: Tue, 22 Oct 2002 01:16:10 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6909 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Clemm, Geoff > Sent: Tuesday, October 22, 2002 12:28 AM > To: WebDAV > Subject: RE: BIND vs. non-movable resources in RFC3253 > > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > From: Jim Whitehead > > > > Perhaps what's lying at the core of this issue is a difference in > > assumption over who controls the namespace. The binding > > specification assumes that in WebDAV-compliant portions of the > > namespace, the client has a large degree of control over naming > > and deletion. Resources are created at locations the client > > specifies, can be moved to places the client wants, and rebound > > to new names at will. > > > > The non-movable resources in DeltaV are typically created by the > > server, at names the server chooses. Often these resources won't > > be represented the same way as "file-like" resources, and will > > instead be acting as the handle for a computational process that > > queries the versioned repository to return property data. That > > is, they act more like a servlet or a CGI. In this case, it's > > important for the server to have these resources at the place > > where it created them, since that's where its software expects > > queries against those > nobody is saying that this is a non-compliant way to implement > RFC3253. The point is -- just because some servers choose to > implement RFC3253 this way, should this prevent other implementors > to implement "full" namespace control (except of re-use of assigned > version and VHR URIs)? > Yes, I believe that is precisely what RFC3253 should say. To refer to > my earlier analogy, just because some clients want immutable content, > should this prevent implementors from implementing "full" content > control (i.e. allowing modification to checked in versions). The > answer here is also, "yes". The answer is yes, but for a different reason. It is a stated goal of the spec that versions have stable URIs and that they are immutable. Nobody wants to change that. > > resources to be directed. (It's additionally important that they > > stay in the same place for the indentification usability issues > > Geoff outlined). > Again, no. > I disagree. > It's important that a URI that has once been assigned to a version > or VHR never is assigned to anything else. > We all agree on that. But the fact that a stable URI should have this > characteristic, does not imply that it should not also have the other > characteristic we are discussion in this thread. And I didn't say that. I'm just saying but both goals are independant of each other, or, more precisely, that the first one doesn't require the second one. I wrote: > However, for a client it is clearly not relevant whether it's > getting a 404 because the resource was destroyed or because it was > moved away (or for that matter, just the binding was deleted and > the resource was moved to non-accessible storage). I'd like to hear > why this is relevant, because it demonstratibly causes a conflict > between the RFC3253 and the BIND spec. So again -- why is this relevant? I'd really like to understand this. > The fact that a particular resource has additional restrictions > in no way "conflicts" with the BIND spec. There will be a variety > of reasons why a DELETE request will fail (authorization, locking, > etc.). This is just another reason that applies to this particular > binding. The condition is easy to specify and easy to understand > (i.e. the DAV:parent-set must have only one member for DELETE to > succeed on this URI). It's not the resource that has additional restrictions, it's a particular binding to that resource. And this IMHO clearly contradicts the BIND spec. Quoting: "A BIND request does not create a new resource, but simply makes available a new URI for submitting requests to an existing resource. The new URI is indistinguishable from any other URI when submitting a request to a resource." BTW: this sentence doesn't take into account that access rights may depend on the collection containing the binding, and on the fact that different bindings to the same resource may be subject to protection by different locks. So we may need to rephrase this anyway. "Bindings are added and removed by a variety of existing HTTP methods. A method that creates a new resource, such as PUT, COPY, and MKCOL, adds a binding. A method that deletes a resource, such as DELETE, removes a binding. A method that moves a resource (e.g. MOVE) both adds a binding (in the destination collection) and removes a binding (in the source collection). The BIND method introduced here provides a mechanism for adding a second binding to an existing resource. There is no difference between an initial binding added by PUT, COPY, or MKCOL, and additional bindings added with BIND." So MOVE should be the same as BIND/DELETE. If you can BIND/DELETE, you should be able to do MOVE as well. > > IMO, accommodating this difference requires explicitly > > acknowledging the two different classes of resource binding > > behavior (fixed vs. free) and then explicitly adding language > > describing the behavior of fixed types to the binding > > specification (something similar to Stephan's language would > > probably work). Revisions to DeltaV can indicate, for all DeltaV > > resource types, what kind of binding behavior they exhibit. > Yes, the BIND spec should say something about these kind of > resources. No, RFC3253 should not require implementors to actually > restrict themselves to this kind of implementation. > I disagree. It is not an implementation issue, > it is a client visible semantics issue. Is another client allowed to > "hide" the resource at some other URL? No, and neither should it > be able to change the "stable URL" for a version or version history. Again, I didn't say that. But: if clients are allowed to DELETE a version, I fail to see why moving it to somewhere else is a problem. It won't be available anymore at it's "stable" URI in both cases. Both the BIND spec and HTTP clearly say that a client can not rely on the resource actually being destroyed: http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.9.7: "The DELETE method requests that the origin server delete the resource identified by the Request-URI. This method MAY be overridden by human intervention (or other means) on the origin server. The client cannot be guaranteed that the operation has been carried out, even if the status code returned from the origin server indicates that the action has been completed successfully. However, the server SHOULD NOT indicate success unless, at the time the response is given, it intends to delete the resource or move it to an inaccessible location." and BIND...: "Once a resource is unreachable by any URI mapping, the server MAY reclaim system resources associated with that resource. If DELETE removes a binding to a resource, but there remain URI mappings to that resource, the server MUST NOT reclaim system resources associated with the resource." And no, I didn't say that the stable URI may be changed. Only the URI assigned at resource creation time has the "stability" property, and the fact that the resource can be moved away doesn't conflict with this more than the resource being deletable. The client-observable will be the same: 1) The resource at the stable URI is gone and 2) The stable URI will never be mapped to a different resource. > Trouble is, RFC3253 already talks about bindings to non-movable > resources (for instance, a working collection contains bindings to > version history resources). So we need to define what happens when > you apply DELETE to a VHR-URI while another binding still appears > somewhere else. Stefan's proposal works fine if your VHR resources > are restricted in the way you explained. However, I'd strongly > object to *requiring* this kind of implementation. > This is a client semantics issue, not an implementation issue. So please state what should happen when the VHR is deleted while a working collection exists that contains a binding to the VHR. > Again, the primary and uncontroversial goal is that a version or > VHR URI is never assigned to a different resource. This takes care > of all the use cases I heard. I've yet to hear why it would be a > problem if it's moved away. Why would it matter to a client? > This is only one of the goals, and the additional goal > we are discussing in this thread is consistent with this other goal. Yes. And again, for client-observable stability of the original URI the second goal is not required. If you have a use case in mind where this really makes a difference to a client, please state it. > > As for why we should add this language -- the idea is to make it > > so that a client, when encountering resources of both types, can > > behave intelligently, without having to perform trial and error > > to accomplish useful tasks. > Sure. Whatever a server implements, a client should be able to > discover. > Querying a server to find out what it implements is the trial and > error that we want the client to not have to do in this case. Yes. I didn't say that. In particular, I proposed a precondition name (which is used in response bodies). It still allows the client to discover what went wrong when it attempted the BIND. > To start with, BIND will need a precondition such as > DAV:member-name-available - the member name to be created is > available for use (because although not in use, it may be unusable > because it already identified a VHR or a version) > It is more likely that the server will not support a BIND into > that version or version history namespace, since as Jim pointed out, > commonly this namespace is a computation based on the state of the > resource, and not an actual directory or folder. But we could > certainly add such a precondition if that error code is important. I think we need it for completeness. A server may very well allow bindings into this part of the namespace. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Oct 22 04:03:40 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA08389 for ; Tue, 22 Oct 2002 04:03:40 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9M855u16031; Tue, 22 Oct 2002 04:05:05 -0400 (EDT) Resent-Date: Tue, 22 Oct 2002 04:05:05 -0400 (EDT) Resent-Message-Id: <200210220805.g9M855u16031@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9M853B16005 for ; Tue, 22 Oct 2002 04:05:03 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA04832 for ; Tue, 22 Oct 2002 04:05:03 -0400 Received: (qmail 16349 invoked by uid 0); 22 Oct 2002 08:04:32 -0000 Received: from p3ee24831.dip.t-dialin.net (HELO lisa) (62.226.72.49) by mail.gmx.net (mp017-rz3) with SMTP; 22 Oct 2002 08:04:32 -0000 From: "Julian Reschke" To: "WebDAV" Date: Tue, 22 Oct 2002 10:04:29 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: Subject: Impact of XML 1.1 and namespaces 1.1 on WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6910 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi, as the W3C is finishing these specs, I'd like to make the WG aware of the questions we'll have to answer about how these changes impact WebDAV. Changes that are IMHO relevant to WebDAV are: 1) The set of characters that can appear in an XML name has been extended (it now includes more Unicode characters). 2) The set of characters that can be marshalled as text data has been extended to include the control characters 1..31 (although only as character reference; null is still forbidden) 3) XML 1.1 processors may reject documents if they contain non-normalized Unicode (yers, this is optional). 4) Namespaces 1.1 allows IRIs rather than only URIs as namespace names. One possible position would be that we just ignore it. Nothing would change immediately. However we lose the ability to marshall "any" kind of XML through WebDAV properties. Allowing XML 1.1 request bodies for PROPPATCH *will* have a big impact. For instance, properties are identified by QNames, and with XML 1.1 both the valid character sets for the namespace name (can now be a IRI and thus contain non.quoted non-ASCII characters) and the local name (just a bigger subset of Unicode) will change. It may not be possible to marshall these "extended" property names back to a client that only understands XML 1.0. Similar problems appear with control characters in property values -- once they appear in a property value, the property can only be marshalled back to clients with XML-1.1 compliant parsers. At this point, I don't have a recommendation how to treat this, but maybe some more WG members should take a look at the current drafts. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Tue Oct 22 05:03:09 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA09281 for ; Tue, 22 Oct 2002 05:03:08 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9M94VO23108; Tue, 22 Oct 2002 05:04:31 -0400 (EDT) Resent-Date: Tue, 22 Oct 2002 05:04:31 -0400 (EDT) Resent-Message-Id: <200210220904.g9M94VO23108@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9M94TB23028 for ; Tue, 22 Oct 2002 05:04:29 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA15793 for ; Tue, 22 Oct 2002 05:04:28 -0400 Received: from greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Tue, 22 Oct 2002 11:03:58 +0200 Date: Tue, 22 Oct 2002 11:03:56 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) From: Stefan Eissing To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <31F089C2-E59D-11D6-9950-00039384827E@greenbytes.de> X-Mailer: Apple Mail (2.546) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: Re: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6911 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit As I interpret RFC 3253, the "stable URL"'s purpose is a) to give each version and VHR a permanent identifier b) to allow clients to retrieve content and properties with this identifier. The BIND resourceid could be used for (a). To achieve (b), the resource id needs to be a URL. Similar to the BIND spec, where the resource id is never altered or lost, the "stable URL" is never altered or lost for a given version/VHR. Therefore: The "stable URL" can only go away, when the resource ceases to exist (from RFC 2518/3253 point of view). Otherwise: Allowing DELETE/MOVE to succeed on the "stable URL" would allow the following case: A client DELETEs/MOVEs a "stable URL" successfully, although other bindings like 'xxx' to the version still exists. A client PROPFINDs 'xxx'. Will it see a version resource? Assuming 'no' is not to be considered. A client makes a version tree REPORT on the VHR of 'xxx'. Under which URL will the version be reported? The "stable URL" is gone. However, 'xxx' cannot be used: If you use 'xxx' for reporting that version in the version tree, clients will assume that 'xxx' is a "stable URL" and, possibly, embed 'xxx' into documents or mails as pointing to *the* version. But 'xxx' is not specially protected and can be bound to any resource in the future. Summary: URLs for versions/version histories, etc., when placed in deltav live properties and reports *must* be "stable URL"s. They are http identifiers which are bound to the lifetime of the resource. //Stefan From w3c-dist-auth-request@w3.org Tue Oct 22 05:53:09 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA10107 for ; Tue, 22 Oct 2002 05:53:08 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9M9sWB27861; Tue, 22 Oct 2002 05:54:32 -0400 (EDT) Resent-Date: Tue, 22 Oct 2002 05:54:32 -0400 (EDT) Resent-Message-Id: <200210220954.g9M9sWB27861@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9M9sVB27830 for ; Tue, 22 Oct 2002 05:54:31 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA24323 for ; Tue, 22 Oct 2002 05:54:30 -0400 Received: (qmail 6232 invoked by uid 0); 22 Oct 2002 09:53:59 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp005-rz3) with SMTP; 22 Oct 2002 09:53:59 -0000 From: "Julian Reschke" To: "Stefan Eissing" , Date: Tue, 22 Oct 2002 11:53:58 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal In-Reply-To: <31F089C2-E59D-11D6-9950-00039384827E@greenbytes.de> Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6912 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit That's an interesting issue. To answer that, we'll have to finally decide which URIs an RFC3253 server should report (for instance for DAV:version-history) when there are multiple bindings. Possible answers are: a) any b) all c) the stable If the answer is a) or b), this isn't an issue. If the answer is c), then just continue to report it. It's perfectly legal to return a URI that isn't mapped anymore (for instance, VHRs and versions may be stored on a separate server, and there's no way to guarantee consistency with the server the VCR is on). Proposal: let's try to clarify how the bindings introduced by RFC3253 actually work (DELETE semantics, reporting of URIs in live properties, ...). Then we'll have to figure out whether this is compatible with the current BIND draft. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing > Sent: Tuesday, October 22, 2002 11:04 AM > To: w3c-dist-auth@w3c.org > Subject: Re: BIND vs. non-movable resources in RFC3253 > > > > As I interpret RFC 3253, the "stable URL"'s purpose is > a) to give each version and VHR a permanent identifier > b) to allow clients to retrieve content and properties with > this identifier. > > The BIND resourceid could be used for (a). To achieve (b), the > resource id needs to be a URL. > > Similar to the BIND spec, where the resource id is never altered > or lost, the "stable URL" is never altered or lost for a given > version/VHR. > > Therefore: > The "stable URL" can only go away, when the resource ceases > to exist (from RFC 2518/3253 point of view). > > Otherwise: > Allowing DELETE/MOVE to succeed on the "stable URL" would > allow the following case: > > A client DELETEs/MOVEs a "stable URL" successfully, although > other bindings like 'xxx' to the version still exists. > > A client PROPFINDs 'xxx'. Will it see a version resource? > > Assuming 'no' is not to be considered. > A client makes a version tree REPORT on the VHR of 'xxx'. Under > which URL will the version be reported? The "stable URL" is > gone. However, 'xxx' cannot be used: > > If you use 'xxx' for reporting that version in the version tree, clients > will assume that 'xxx' is a "stable URL" and, possibly, embed 'xxx' > into documents or mails as pointing to *the* version. But 'xxx' > is not specially protected and can be bound to any resource in > the future. > > Summary: > URLs for versions/version histories, etc., when placed in deltav > live properties and reports *must* be "stable URL"s. They are > http identifiers which are bound to the lifetime of the resource. > > //Stefan > > From w3c-dist-auth-request@w3.org Tue Oct 22 07:17:35 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA11350 for ; Tue, 22 Oct 2002 07:17:35 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9MBIjm04512; Tue, 22 Oct 2002 07:18:45 -0400 (EDT) Resent-Date: Tue, 22 Oct 2002 07:18:45 -0400 (EDT) Resent-Message-Id: <200210221118.g9MBIjm04512@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9MBIhB04442 for ; Tue, 22 Oct 2002 07:18:43 -0400 (EDT) Received: from matrixmail.matrixone.net (mail.matrix-one.com [4.17.165.4]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA05231 for ; Tue, 22 Oct 2002 07:18:43 -0400 Received: from msx2am.matrixone.net by matrixmail.matrixone.net (8.10.1/8.10.1) with ESMTP id g9MBIBi09359 for ; Tue, 22 Oct 2002 07:18:12 -0400 (EDT) Received: by msx2am.matrixone.net with Internet Mail Service (5.5.2653.19) id <4C93676S>; Tue, 22 Oct 2002 07:18:11 -0400 Message-ID: <9150DCE0CCB4D411A7DB00508BB0DBF202E5C9BF@msx1am.matrixone.net> From: "Dyer, Kevin" To: w3c-dist-auth@w3.org Date: Tue, 22 Oct 2002 07:16:49 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C279BC.83F02080" Subject: RE: Interop issue: how can clients force authentication? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6913 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C279BC.83F02080 Content-Type: text/plain; charset="iso-8859-1" I would like to add to Geoff response about timing. Depending on what type of authorization credentials the user is attempting to enter there can be short windows to the client and server as to the half-life of the credentials. So a "not authorized" would be mandatory from the server as the credentials have aged beyond their usable window. Any further use of the credentials should constitute a replay attack. As for the language Dan proposed. There needs to a limit for the number of times a userid can attempt authentication/authorization, the spec should not allow "and continues to challenge (401) the client until the client authenticates as a user who is actually authorized to perform all those methods on that resource", otherwise it opens the door wide open for the abuse. IMHO, Dan's comment about clients forcing re-authentication is outside of the DAV spec is correct. There are a number of topics around distributed authentication/authorization that need to be addressed and the DAV spec should work within the framework started by other WGs. - Even if the server comes back and says "yes, you could do that", by the time you get around to trying it, it may fail because the state on the server has changed, so a client needs to be prepared to handle the "not authorized" response in the middle of a stream of requests anyway. > In the wonderfully-future-compliant case: the server actually looks at > the value of the property specified, and continues to challenge (401) > the client until the client authenticates as a user who is actually > authorized to perform all those methods on that resource. At that > point the server return 409 because (ha!) DAV:authorized-methods is > actually a read-only property. > > In the currently compliant server case: the server just > authenticates/authorizes the user for the PROPPATCH on the resource, > and then either sets the (dead) property or refuses the request (403, > presumably), because the user is trying to set a property in the DAV: > space that's not mentioned in the current version of the spec. :^) > ------_=_NextPart_001_01C279BC.83F02080 Content-Type: text/html; charset="iso-8859-1" RE: Interop issue: how can clients force authentication?
I would like to add to Geoff response about timing. Depending on what type of authorization credentials the user is attempting to enter there can be short windows to the client and server as to the half-life of the credentials. So a "not authorized" would be mandatory from the server as the credentials have aged beyond their usable window. Any further use of the credentials should constitute a replay attack.
 
As for the language Dan proposed. There needs to a limit for the number of times a userid can attempt authentication/authorization, the spec should not allow "and continues to challenge (401) the client until the client authenticates as a user who is actually authorized to perform all those methods on that resource", otherwise it opens the door wide open for the abuse.
 
IMHO, Dan's comment about clients forcing re-authentication is outside of the DAV spec is correct. There are a number of topics around distributed authentication/authorization that need to be addressed and the DAV spec should work within the framework started by other WGs. 
 
 

- Even if the server comes back and says "yes, you could do that",
by the time you get around to trying it, it may fail because the
state on the server has changed, so a client needs to be prepared
to handle the "not authorized" response in the middle of a stream
of requests anyway.

<snip> 

 > In the wonderfully-future-compliant case: the server actually looks at
> the value of the property specified, and continues to challenge (401)
> the client until the client authenticates as a user who is actually
> authorized to perform all those methods on that resource.  At that
> point the server return 409 because (ha!) DAV:authorized-methods is
> actually a read-only property.
>
> In the currently compliant server case: the server just
> authenticates/authorizes the user for the PROPPATCH on the resource,
> and then either sets the (dead) property or refuses the request (403,
> presumably), because the user is trying to set a property in the DAV:
> space that's not mentioned in the current version of the spec. :^)
>

------_=_NextPart_001_01C279BC.83F02080-- From w3c-dist-auth-request@w3.org Tue Oct 22 07:42:20 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12431 for ; Tue, 22 Oct 2002 07:42:19 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9MBhLr08739; Tue, 22 Oct 2002 07:43:21 -0400 (EDT) Resent-Date: Tue, 22 Oct 2002 07:43:21 -0400 (EDT) Resent-Message-Id: <200210221143.g9MBhLr08739@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9MBhJB08703 for ; Tue, 22 Oct 2002 07:43:19 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA10054 for ; Tue, 22 Oct 2002 07:43:14 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA12307; Tue, 22 Oct 2002 07:40:58 -0400 (EDT) Message-Id: <200210221140.HAA12307@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, 22 Oct 2002 07:40:58 -0400 Subject: I-D ACTION:draft-ietf-webdav-quota-00.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6914 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --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 : Quota and Size Properties for DAV Collections Author(s) : L. Dusseault, C. Warner Filename : draft-ietf-webdav-quota-00.txt Pages : 8 Date : 2002-10-21 WebDAV servers are frequently deployed with collection quota (size) limitations. This Internet-Draft discusses the two properties and minor behaviors needed for clients to interoperate with quota implementations on WebDAV repositories. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-quota-00.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-quota-00.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-quota-00.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: <2002-10-21143350.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-quota-00.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-quota-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2002-10-21143350.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Tue Oct 22 12:45:55 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25690 for ; Tue, 22 Oct 2002 12:45:55 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9MGl4P02239; Tue, 22 Oct 2002 12:47:04 -0400 (EDT) Resent-Date: Tue, 22 Oct 2002 12:47:04 -0400 (EDT) Resent-Message-Id: <200210221647.g9MGl4P02239@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9MGl2B02213 for ; Tue, 22 Oct 2002 12:47:02 -0400 (EDT) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA17379 for ; Tue, 22 Oct 2002 12:47:01 -0400 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id JAA25346 sender nn683849@smallcue.com for w3c-dist-auth@w3c.org; Tue, 22 Oct 2002 09:46:53 -0700 Received: from e6.ny.us.ibm.com (e6.ny.us.ibm.com [32.97.182.106]) by sunbelt.seagull.net (8.9.3) with ESMTP id JAA25320 sender obsfucated@us.ibm.com; Tue, 22 Oct 2002 09:46:52 -0700 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e6.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id g9MGkKUF063804; Tue, 22 Oct 2002 12:46:20 -0400 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id g9MGkJfN024042; Tue, 22 Oct 2002 12:46:19 -0400 To: "Julian Reschke" Cc: "Stefan Eissing" , w3c-dist-auth@w3c.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Jason Crawford Message-ID: Date: Tue, 22 Oct 2002 12:46:18 -0400 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0|September 26, 2002) at 10/22/2002 12:46:19, Serialize complete at 10/22/2002 12:46:19 Content-Type: text/plain; charset="us-ascii" Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6915 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This seems to be a discussion of "bindings and versioning", not bindings. I think the binding spec should allow servers to reject DELETE/MOVE requests. The binding spec should not be concerned about all the possible reasons a server might reject a request, and in particular it shouldn't devote any time to versioning specific reasons a server might reject a request. If a particular spec, like the versioning spec, has a particular semantic constraints that it wants to support, it can spec that DELETE/MOVE should not be supported in the situations where DELETE/MOVE would break those semantic constraints. Can we agree that servers can reject DELETE/MOVE requests and move the versioning specific discussion to the versioning mailing list? J. ------------------------------------------ Phone: 914-784-7569 From w3c-dist-auth-request@w3.org Tue Oct 22 12:48:47 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25798 for ; Tue, 22 Oct 2002 12:48:47 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9MGoLj02869; Tue, 22 Oct 2002 12:50:21 -0400 (EDT) Resent-Date: Tue, 22 Oct 2002 12:50:21 -0400 (EDT) Resent-Message-Id: <200210221650.g9MGoLj02869@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9MGoKB02843 for ; Tue, 22 Oct 2002 12:50:20 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA18253 for ; Tue, 22 Oct 2002 12:50:19 -0400 Received: from greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Tue, 22 Oct 2002 18:49:36 +0200 Date: Tue, 22 Oct 2002 18:49:27 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "Julian Reschke" , w3c-dist-auth@w3c.org To: Jason Crawford From: Stefan Eissing In-Reply-To: Message-Id: <39E69588-E5DE-11D6-9950-00039384827E@greenbytes.de> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: Re: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6916 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit +1 //Stefan Am Dienstag, 22.10.02, um 18:46 Uhr (Europe/Berlin) schrieb Jason Crawford: > This seems to be a discussion of "bindings and versioning", not > bindings. > > I think the binding spec should allow servers to reject DELETE/MOVE > requests. > The binding spec should not be concerned about all the possible > reasons a > server might reject a request, and in particular it shouldn't devote > any > time to > versioning specific reasons a server might reject a request. > > If a particular spec, like the versioning spec, has a particular > semantic > constraints > that it wants to support, it can spec that DELETE/MOVE should not be > supported > in the situations where DELETE/MOVE would break those semantic > constraints. > > Can we agree that servers can reject DELETE/MOVE requests and move the > versioning specific discussion to the versioning mailing list? > > J. > > ------------------------------------------ > Phone: 914-784-7569 > > From w3c-dist-auth-request@w3.org Tue Oct 22 15:19:39 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01207 for ; Tue, 22 Oct 2002 15:19:38 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9MJKgB03776; Tue, 22 Oct 2002 15:20:42 -0400 (EDT) Resent-Date: Tue, 22 Oct 2002 15:20:42 -0400 (EDT) Resent-Message-Id: <200210221920.g9MJKgB03776@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9MJKfB03749 for ; Tue, 22 Oct 2002 15:20:41 -0400 (EDT) Received: from ietf.org (odin.ietf.org [132.151.1.176]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA11161 for ; Tue, 22 Oct 2002 15:20:41 -0400 Received: from CNRI.Reston.VA.US (localhost [127.0.0.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01171; Tue, 22 Oct 2002 15:18:23 -0400 (EDT) Message-Id: <200210221918.PAA01171@ietf.org> To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: The IESG Reply-to: iesg@ietf.org Date: Tue, 22 Oct 2002 15:18:23 -0400 Subject: Last Call: WebDAV Access Control Protocol to Proposed Standard Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6917 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: The IESG has received a request from the WWW Distributed Authoring and Versioning Working Group to consider WebDAV Access Control Protocol as a Proposed Standard. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send any comments to the iesg@ietf.org or ietf@ietf.org mailing lists by 2002-11-5. Files can be obtained via http://www.ietf.org/internet-drafts/draft-ietf-webdav-acl-09.txt From w3c-dist-auth-request@w3.org Tue Oct 22 16:26:50 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03273 for ; Tue, 22 Oct 2002 16:26:50 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9MKS5W16448; Tue, 22 Oct 2002 16:28:05 -0400 (EDT) Resent-Date: Tue, 22 Oct 2002 16:28:05 -0400 (EDT) Resent-Message-Id: <200210222028.g9MKS5W16448@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9MKS3B16418 for ; Tue, 22 Oct 2002 16:28:03 -0400 (EDT) Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA01529 for ; Tue, 22 Oct 2002 16:28:03 -0400 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id g9MKRTk19624 for ; Tue, 22 Oct 2002 13:27:29 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Tue, 22 Oct 2002 13:24:28 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: FW: How to pronounce DAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6918 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Accidentally caught by the spam filter. - Jim -----Original Message----- From: shebuskijohn@netscape.net [mailto:shebuskijohn@netscape.net] Sent: Tuesday, October 22, 2002 11:17 AM To: w3c-dist-auth@w3.org Subject: [Moderator Action] How to pronounce DAV An even more basic question than what is it? How do you say it? Is it Dave as in David, or Web D then A then V(Web Dee A(braham) Vee) or is it DAV like in dav(enport)? Midwest version preferred. __________________________________________________________________ The NEW Netscape 7.0 browser is now available. Upgrade now! http://channels.netscape.com/ns/browsers/download.jsp Get your own FREE, personal Netscape Mail account today at http://webmail.netscape.com/ From w3c-dist-auth-request@w3.org Tue Oct 22 16:30:02 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03489 for ; Tue, 22 Oct 2002 16:30:02 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9MKVam16853; Tue, 22 Oct 2002 16:31:36 -0400 (EDT) Resent-Date: Tue, 22 Oct 2002 16:31:36 -0400 (EDT) Resent-Message-Id: <200210222031.g9MKVam16853@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9MKVZB16827 for ; Tue, 22 Oct 2002 16:31:35 -0400 (EDT) Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA02410 for ; Tue, 22 Oct 2002 16:31:35 -0400 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id g9MKVFk20648; Tue, 22 Oct 2002 13:31:15 -0700 (PDT) From: "Jim Whitehead" To: , Date: Tue, 22 Oct 2002 13:28:14 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal In-Reply-To: <52A16D27.1687ED85.99F24B95@netscape.net> X-UCSC-CATS-MailScanner: Found to be clean Subject: RE: How to pronounce DAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6919 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > How do you say it? > > Is it Dave as in David, or Web D then A then V(Web Dee A(braham) Vee) > or is it DAV like in dav(enport)? It's "DAV" like in "cadaver" (or, yes, Davenport). Not too surprisingly, people named Dave think it's WebDAVe. - Jim From w3c-dist-auth-request@w3.org Tue Oct 22 22:23:17 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA12430 for ; Tue, 22 Oct 2002 22:23:16 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9N2OWu25023; Tue, 22 Oct 2002 22:24:32 -0400 (EDT) Resent-Date: Tue, 22 Oct 2002 22:24:32 -0400 (EDT) Resent-Message-Id: <200210230224.g9N2OWu25023@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9N2OUB24996 for ; Tue, 22 Oct 2002 22:24:30 -0400 (EDT) Received: from epistula.trinity.unimelb.edu.au (postfix@epistula.trinity.unimelb.edu.au [203.28.240.16]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA07157 for ; Tue, 22 Oct 2002 22:24:30 -0400 Received: by epistula.trinity.unimelb.edu.au (Postfix, from userid 105) id E1CF51801D; Wed, 23 Oct 2002 12:24:27 +1000 (EST) Received: from localhost (localhost [127.0.0.1]) by epistula.trinity.unimelb.edu.au (Postfix) with ESMTP id 968F51801E; Wed, 23 Oct 2002 12:24:23 +1000 (EST) Received: from roger.trinity.unimelb.edu.au (roger.trinity.unimelb.edu.au [203.28.240.3]) by epistula.trinity.unimelb.edu.au (Postfix) with ESMTP id 120AB1801D; Wed, 23 Oct 2002 12:24:20 +1000 (EST) Received: by roger.trinity.unimelb.edu.au (Postfix, from userid 1280) id 844A117F08; Wed, 23 Oct 2002 12:24:19 +1000 (EST) Date: Wed, 23 Oct 2002 12:24:19 +1000 From: Daniel Stone To: Jim Whitehead Cc: shebuskijohn@netscape.net, w3c-dist-auth@w3.org Message-ID: <20021023022419.GA19645@trinity.unimelb.edu.au> References: <52A16D27.1687ED85.99F24B95@netscape.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="uAKRQypu60I7Lcqm" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.28i X-GnuPG-Key: 3CED7EFD X-Virus-Scanned: by AMaViS snapshot-20020316 Subject: Re: How to pronounce DAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6920 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --uAKRQypu60I7Lcqm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 22, 2002 at 01:28:14PM -0700, Jim Whitehead scrawled: > > How do you say it? > >=20 > > Is it Dave as in David, or Web D then A then V(Web Dee A(braham) Vee) > > or is it DAV like in dav(enport)? >=20 > It's "DAV" like in "cadaver" (or, yes, Davenport). Depends how you pronounce "cadaver", tho. :) I pronounce cadaver kuh-dar-vuh, and DAV d(uh)av. --=20 Daniel Stone Developer - http://kopete.kde.org, http://www.kde.org Proof BitMover are community-focussed: http://marc.theaimsgroup.com/?l=3Dlinux-kernel&m=3D103384262016750&w=3D2 --uAKRQypu60I7Lcqm Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (GNU/Linux) iD8DBQE9tghTcPClnTztfv0RAjRaAJ9Kh94H67jIludLpnycD8a1Z7GHdQCfVxOc t8FefaT+pglRLtm2PPB8+1M= =S2z4 -----END PGP SIGNATURE----- --uAKRQypu60I7Lcqm-- From w3c-dist-auth-request@w3.org Wed Oct 23 07:01:56 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA13557 for ; Wed, 23 Oct 2002 07:01:56 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NAx7E01500; Wed, 23 Oct 2002 06:59:07 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 06:59:07 -0400 (EDT) Resent-Message-Id: <200210231059.g9NAx7E01500@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NAx3B01388 for ; Wed, 23 Oct 2002 06:59:03 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id GAA32290 for ; Wed, 23 Oct 2002 06:59:03 -0400 Received: (qmail 19320 invoked by uid 0); 23 Oct 2002 10:58:31 -0000 Received: from p3ee24826.dip.t-dialin.net (HELO lisa) (62.226.72.38) by mail.gmx.net (mp009-rz3) with SMTP; 23 Oct 2002 10:58:31 -0000 From: "Julian Reschke" To: "Jason Crawford" , "Julian Reschke" Cc: "Stefan Eissing" , Date: Wed, 23 Oct 2002 12:58:30 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6921 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jason Crawford > Sent: Tuesday, October 22, 2002 6:46 PM > To: Julian Reschke > Cc: Stefan Eissing; w3c-dist-auth@w3c.org > Subject: RE: BIND vs. non-movable resources in RFC3253 > > > > This seems to be a discussion of "bindings and versioning", not bindings. Yes and no. It certainly is an issue with the versioning spec, and it needs to be resolved independantly of what BIND says. However, it proves that the real world can be much more complicated than what the BIND spec suggests, and I think the spec should reflect that. In particular, not all of the bindings to a resource are indeed equal, and the order of DELETE requests on several binds to the same resource may affect the results (for instance, because a server fails the DELETE to the last binding because the user doesn't have the privilege to destroy the resource). > I think the binding spec should allow servers to reject DELETE/MOVE requests. Yes. > The binding spec should not be concerned about all the possible reasons a > server might reject a request, and in particular it shouldn't devote any time to > versioning specific reasons a server might reject a request. For interoperability, we may need to define how a client can find out why a DELETE failed. For instance, *if* we allow a model where a particular binding must be removed last, there should be a way for the client to find out about that. > If a particular spec, like the versioning spec, has a particular semantic constraints > that it wants to support, it can spec that DELETE/MOVE should not be supported > in the situations where DELETE/MOVE would break those semantic > constraints. The issue here is that if we allow a DELETE to fail because other bindings exist, a client may never be able to delete a binding (because due to race conditions, there will always be additional bindings left). I'm not saying that this can be avoided, however it *really* sounds ugly. As I said, I haven't seen a convincing argument why we need this restriction in RFC3253 (and yes, this discussion should be moved to the other mailing list). > Can we agree that servers can reject DELETE/MOVE requests and move the > versioning specific discussion to the versioning mailing list? Yes. Still, we may have to define additional precondition values for - resource does not support additional bindings - new member name can't be used (in deltav: because it was already used for a stable URI) Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Oct 23 12:47:32 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25119 for ; Wed, 23 Oct 2002 12:47:31 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NGmW806889; Wed, 23 Oct 2002 12:48:32 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 12:48:32 -0400 (EDT) Resent-Message-Id: <200210231648.g9NGmW806889@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NGmTB06857 for ; Wed, 23 Oct 2002 12:48:29 -0400 (EDT) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA09946 for ; Wed, 23 Oct 2002 12:48:29 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 184Og2-0007Gu-00; Wed, 23 Oct 2002 16:48:14 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 184Og1-0007Gj-00; Wed, 23 Oct 2002 16:48:13 +0000 From: "Lisa Dusseault" To: "'Erik Seaberg'" , Cc: "Lisa Dusseault"@xythos.com Date: Wed, 23 Oct 2002 09:48:15 -0700 Message-ID: <000f01c27ab3$fbdd8a90$620afea9@xythoslap> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <86lmf5u01x.fsf@unx51.staff.flyingcroc.net> Old-X-Envelope-To: erk@flyingcroc.com, w3c-dist-auth@w3c.org Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6922 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit The new draft of quota is out, but I never responded directly to these comments (sorry). > -----Original Message----- > From: erk@unx51.staff.flyingcroc.net > [mailto:erk@unx51.staff.flyingcroc.net] On Behalf Of Erik Seaberg > Sent: Thursday, January 10, 2002 5:52 PM > To: w3c-dist-auth@w3c.org > Cc: Lisa Dusseault > Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > A client that wants to know how much storage is actually available in > a collection has to PROPFIND each parent up to "/" looking for the > minimum (quota-bytes - space-used-bytes) value. That number should be > a live property, since any server enforcing quotas must be able to > produce it fairly efficiently. That's true, but even knowing that the client can't necessary assure their request will succeed. I suspect that if the client just PROPFINDs the current collection and subtracts space-used-bytes from quota-bytes, the client will get an answer that works just as well 99% of the time. If implementation experience suggests otherwise, I'd support this live property as well. > It's natural to want to handle this through quotactl(2) on Unix, but > the draft says {DAV:}space-used-bytes "MUST include child collections > and all resources inside those child collections" without regard for > who created them. Is the intent that all users MUST (or SHOULD) see > identical {DAV:}quota-bytes and {DAV:}space-used-bytes values, or may > an admin reveal quotas they've assigned to particular users? It didn't say that it is without regard for who created them. The server is free to count any resource as 0 bytes against space-used for all kinds of reasons (e.g. the resource is a binding). The sentence was intended to ensure that quota was understood to be recursive by clients and servers. Do you have better wording? > Should a client be able to atomically reserve some of a collection's > storage so expensive requests don't have to race with others to claim > the last bytes? It could be a header like > > Expect: 100-continue, reserve; content-length="999999" > > in a large PUT for example, or a live property on a collection > allowing a reservation for several smaller resources or properties. > In theory this would work already. However I suspect servers implementation of the Expect header is poor in reality. Lisa From w3c-dist-auth-request@w3.org Wed Oct 23 12:54:38 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA25276 for ; Wed, 23 Oct 2002 12:54:38 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NGuC509492; Wed, 23 Oct 2002 12:56:12 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 12:56:12 -0400 (EDT) Resent-Message-Id: <200210231656.g9NGuC509492@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NGuAB09465 for ; Wed, 23 Oct 2002 12:56:10 -0400 (EDT) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA12767 for ; Wed, 23 Oct 2002 12:56:10 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 184OnT-0007LL-00; Wed, 23 Oct 2002 16:55:55 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 184OnT-0007LA-00; Wed, 23 Oct 2002 16:55:55 +0000 From: "Lisa Dusseault" To: "'Stefan Eissing'" , "Webdav WG" Date: Wed, 23 Oct 2002 09:55:56 -0700 Message-ID: <001001c27ab5$0ed451a0$620afea9@xythoslap> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Old-X-Envelope-To: stefan.eissing@greenbytes.de, w3c-dist-auth@w3c.org Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6923 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Stefan asked (a while ago, sorry to be so late): > I can see how this draft is applied to servers like Sharemation > which have a separate collection hierarchy for each user. Sharemation does have a separate collection hierarchy for each user, but many other Xythos WebFile Server installations have users share collections with common names like "sales", "marketing", "hr". The same quota system applies to both models, as I hope I'll be able to explain. > I have more trouble applying it to servers where it is common > that more than one user has write access to collections. Imagine > that Sharemation has a collection containing all your user > collections. How would the quota properties appear on that > collection? Quota is applied to a collection, *not* a user, specifically because of the model where a user doesn't just put documents in their own home directory. That's explicit in the draft, and it's an important feature to allow directories to be shared by many users and still have quota applied. So if a quota of 1000MB is applied to the "/sales/" collection, the server is free to report that quota, and count space consumed by resources in the "/sales/" collection in whatever way its policy decides. > Where I see a real problem is a server supporting bindings. It's specifically left up to the server to figure out how to support bindings -- it would be impossible for the draft to enforce how to count space used, when it's a matter of policy and the interaction of many potential features. The server may: - count the space used by a binding as 0 bytes, - count the bytes used to store the binding only and not the length of the resource it points to - divide the size of the target resource among all its bindings, - count the full size of the target resource against every binding. That's why the draft requires the server to show how space is used -- it is not possible for the standard to decide these policy matters. Lisa From w3c-dist-auth-request@w3.org Wed Oct 23 13:05:01 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA25683 for ; Wed, 23 Oct 2002 13:05:01 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NH6J911374; Wed, 23 Oct 2002 13:06:19 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 13:06:19 -0400 (EDT) Resent-Message-Id: <200210231706.g9NH6J911374@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NH6IB11344 for ; Wed, 23 Oct 2002 13:06:18 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA15538 for ; Wed, 23 Oct 2002 13:06:17 -0400 Received: (qmail 14624 invoked by uid 0); 23 Oct 2002 17:05:46 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp001-rz3) with SMTP; 23 Oct 2002 17:05:46 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Stefan Eissing'" , "Webdav WG" Date: Wed, 23 Oct 2002 19:05:45 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <001001c27ab5$0ed451a0$620afea9@xythoslap> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6924 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, October 23, 2002 6:56 PM > To: 'Stefan Eissing'; Webdav WG > Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > ... > > Quota is applied to a collection, *not* a user, specifically because of > the model where a user doesn't just put documents in their own home > directory. That's explicit in the draft, and it's an important feature > to allow directories to be shared by many users and still have quota > applied. So if a quota of 1000MB is applied to the "/sales/" > collection, the server is free to report that quota, and count space > consumed by resources in the "/sales/" collection in whatever way its > policy decides. This kind of quota system is incompatible with the quota system in a Unix filesystem (where AFAIK it's per user) -- a standard proposal must be able to handle these kinds of systems as well. > ... Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Oct 23 13:21:57 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26130 for ; Wed, 23 Oct 2002 13:21:57 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NHNJO15130; Wed, 23 Oct 2002 13:23:19 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 13:23:19 -0400 (EDT) Resent-Message-Id: <200210231723.g9NHNJO15130@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NHNHB15102 for ; Wed, 23 Oct 2002 13:23:17 -0400 (EDT) Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA21768 for ; Wed, 23 Oct 2002 13:23:17 -0400 Received: from inet-mail3.oracle.com (localhost [127.0.0.1]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9NHMfU26529 for ; Wed, 23 Oct 2002 10:22:41 -0700 (PDT) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9NHMeI26511 for ; Wed, 23 Oct 2002 10:22:40 -0700 (PDT) Received: from rgmum4.us.oracle.com (rgmum4.us.oracle.com [138.1.191.25]) by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9NHMet06708 for ; Wed, 23 Oct 2002 11:22:40 -0600 (MDT) Received: from 152.68.17.155 by rgmum4.us.oracle.com with ESMTP id 88984251035393733; Wed, 23 Oct 2002 11:22:13 -0600 Message-ID: <000301c27ab8$ac7ba270$9b114498@esedlar> From: "Eric Sedlar" To: "Julian Reschke" , "Lisa Dusseault" , "'Stefan Eissing'" , "Webdav WG" References: Date: Wed, 23 Oct 2002 10:21:06 -0700 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: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6925 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit It seems like this draft is fine with a user-based rather than a collection-based system--the server will report the same usage & quota for any collection, but will return different results depending on who is authenticated, no? ----- Original Message ----- From: "Julian Reschke" To: "Lisa Dusseault" ; "'Stefan Eissing'" ; "Webdav WG" Sent: Wednesday, October 23, 2002 10:05 AM Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > Sent: Wednesday, October 23, 2002 6:56 PM > > To: 'Stefan Eissing'; Webdav WG > > Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > > ... > > > > Quota is applied to a collection, *not* a user, specifically because of > > the model where a user doesn't just put documents in their own home > > directory. That's explicit in the draft, and it's an important feature > > to allow directories to be shared by many users and still have quota > > applied. So if a quota of 1000MB is applied to the "/sales/" > > collection, the server is free to report that quota, and count space > > consumed by resources in the "/sales/" collection in whatever way its > > policy decides. > > This kind of quota system is incompatible with the quota system in a Unix > filesystem (where AFAIK it's per user) -- a standard proposal must be able > to handle these kinds of systems as well. > > > ... > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > From w3c-dist-auth-request@w3.org Wed Oct 23 13:31:28 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA26544 for ; Wed, 23 Oct 2002 13:31:28 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NHWqH16673; Wed, 23 Oct 2002 13:32:52 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 13:32:52 -0400 (EDT) Resent-Message-Id: <200210231732.g9NHWqH16673@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NHWoB16628 for ; Wed, 23 Oct 2002 13:32:50 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA24606 for ; Wed, 23 Oct 2002 13:32:50 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 23 Oct 2002 13:21:00 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403YGW8H>; Wed, 23 Oct 2002 13:32:14 -0400 Message-ID: From: "Clemm, Geoff" To: Webdav WG Date: Wed, 23 Oct 2002 13:32:13 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27ABA.1FEC49C0" Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6926 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27ABA.1FEC49C0 Content-Type: text/plain; charset="iso-8859-1" The current draft states that the quota values do not vary by user. I believe that this should be changed to explicitly state that they *are* per user quota values. A server that only maintains global quotas would then just return the same value for every authenticated user. Cheers, Geoff -----Original Message----- From: Eric Sedlar [mailto:eric.sedlar@oracle.com] Sent: Wednesday, October 23, 2002 1:21 PM To: Julian Reschke; Lisa Dusseault; 'Stefan Eissing'; Webdav WG Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt It seems like this draft is fine with a user-based rather than a collection-based system--the server will report the same usage & quota for any collection, but will return different results depending on who is authenticated, no? ----- Original Message ----- From: "Julian Reschke" To: "Lisa Dusseault" ; "'Stefan Eissing'" ; "Webdav WG" Sent: Wednesday, October 23, 2002 10:05 AM Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > Sent: Wednesday, October 23, 2002 6:56 PM > > To: 'Stefan Eissing'; Webdav WG > > Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > > ... > > > > Quota is applied to a collection, *not* a user, specifically because of > > the model where a user doesn't just put documents in their own home > > directory. That's explicit in the draft, and it's an important feature > > to allow directories to be shared by many users and still have quota > > applied. So if a quota of 1000MB is applied to the "/sales/" > > collection, the server is free to report that quota, and count space > > consumed by resources in the "/sales/" collection in whatever way its > > policy decides. > > This kind of quota system is incompatible with the quota system in a Unix > filesystem (where AFAIK it's per user) -- a standard proposal must be able > to handle these kinds of systems as well. > > > ... > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > ------_=_NextPart_001_01C27ABA.1FEC49C0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt

The current draft states that the
quota values do not vary by user.  I believe = that this
should be changed to explicitly state that they = *are* per
user quota values.  A server that only = maintains global
quotas would then just return the same value for = every
authenticated user.

Cheers,
Geoff

-----Original Message-----
From: Eric Sedlar [mailto:eric.sedlar@oracle.com= ]
Sent: Wednesday, October 23, 2002 1:21 PM
To: Julian Reschke; Lisa Dusseault; 'Stefan = Eissing'; Webdav WG
Subject: Re: FW: I-D = ACTION:draft-dusseault-dav-quota-01.txt



It seems like this draft is fine with a user-based = rather than a
collection-based
system--the server will report the same usage & = quota for any collection,
but
will return different results depending on who is = authenticated, no?

----- Original Message -----
From: "Julian Reschke" = <julian.reschke@gmx.de>
To: "Lisa Dusseault" = <lisa@xythos.com>; "'Stefan Eissing'"
<stefan.eissing@greenbytes.de>; "Webdav = WG" <w3c-dist-auth@w3c.org>
Sent: Wednesday, October 23, 2002 10:05 AM
Subject: RE: FW: I-D = ACTION:draft-dusseault-dav-quota-01.txt


>
> > From: w3c-dist-auth-request@w3.org
> > [mailto:w3c-dist-auth-reques= t@w3.org]On Behalf Of Lisa Dusseault
> > Sent: Wednesday, October 23, 2002 6:56 = PM
> > To: 'Stefan Eissing'; Webdav WG
> > Subject: Re: FW: I-D = ACTION:draft-dusseault-dav-quota-01.txt
> >
> > ...
> >
> > Quota is applied to a collection, *not* a = user, specifically because of
> > the model where a user doesn't just put = documents in their own home
> > directory.  That's explicit in the = draft, and it's an important feature
> > to allow directories to be shared by many = users and still have quota
> > applied.  So if a quota of 1000MB is = applied to the "/sales/"
> > collection, the server is free to report = that quota, and count space
> > consumed by resources in the = "/sales/" collection in whatever way its
> > policy decides.
>
> This kind of quota system is incompatible with = the quota system in a Unix
> filesystem (where AFAIK it's per user) -- a = standard proposal must be able
> to handle these kinds of systems as well.=
>
> > ...
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- = tel:+492512807760
>
>

------_=_NextPart_001_01C27ABA.1FEC49C0-- From w3c-dist-auth-request@w3.org Wed Oct 23 14:05:36 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27626 for ; Wed, 23 Oct 2002 14:05:35 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NI7As25029; Wed, 23 Oct 2002 14:07:10 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 14:07:10 -0400 (EDT) Resent-Message-Id: <200210231807.g9NI7As25029@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NI76B24909 for ; Wed, 23 Oct 2002 14:07:06 -0400 (EDT) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA03544 for ; Wed, 23 Oct 2002 14:07:05 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 184Pu6-00084G-00; Wed, 23 Oct 2002 18:06:50 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 184Pu6-000845-00; Wed, 23 Oct 2002 18:06:50 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , "'Stefan Eissing'" , "'Webdav WG'" Date: Wed, 23 Oct 2002 11:06:51 -0700 Message-ID: <001301c27abe$f6c5faa0$620afea9@xythoslap> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Old-X-Envelope-To: julian.reschke@gmx.de, stefan.eissing@greenbytes.de, w3c-dist-auth@w3c.org Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6927 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > This kind of quota system is incompatible with the quota system in a Unix > filesystem (where AFAIK it's per user) -- a standard proposal must be able > to handle these kinds of systems as well. I haven't heard of anybody implementing a WebDAV server with quota that needed to solve this problem. Is there an actual implementation need for this? From w3c-dist-auth-request@w3.org Wed Oct 23 14:08:53 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27807 for ; Wed, 23 Oct 2002 14:08:53 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NI9uX25522; Wed, 23 Oct 2002 14:09:56 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 14:09:56 -0400 (EDT) Resent-Message-Id: <200210231809.g9NI9uX25522@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NI9sB25492 for ; Wed, 23 Oct 2002 14:09:54 -0400 (EDT) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA04518 for ; Wed, 23 Oct 2002 14:09:54 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 184Pwp-00086J-00; Wed, 23 Oct 2002 18:09:39 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 184Pwp-000868-00; Wed, 23 Oct 2002 18:09:39 +0000 From: "Lisa Dusseault" To: "'Clemm, Geoff'" , "'Webdav WG'" Date: Wed, 23 Oct 2002 11:09:40 -0700 Message-ID: <001401c27abf$5b603890$620afea9@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Old-X-Envelope-To: gclemm@rational.com, w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g9NI9sB25492 Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6928 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit 1. Is there general consensus to agree with Geoff? 2. Is there actually an implementation need for this? I'm a little dubious about altering the draft to say this, because it starts to get really unclear what space-used-bytes means when it can vary from user to user. lisa -----Original Message----- From: Clemm, Geoff [mailto:gclemm@rational.com] Sent: Wednesday, October 23, 2002 10:32 AM To: Webdav WG Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt The current draft states that the quota values do not vary by user.  I believe that this should be changed to explicitly state that they *are* per user quota values.  A server that only maintains global quotas would then just return the same value for every authenticated user. Cheers, Geoff -----Original Message----- From: Eric Sedlar [mailto:eric.sedlar@oracle.com] Sent: Wednesday, October 23, 2002 1:21 PM To: Julian Reschke; Lisa Dusseault; 'Stefan Eissing'; Webdav WG Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt It seems like this draft is fine with a user-based rather than a collection-based system--the server will report the same usage & quota for any collection, but will return different results depending on who is authenticated, no? ----- Original Message ----- From: "Julian Reschke" To: "Lisa Dusseault" ; "'Stefan Eissing'" ; "Webdav WG" Sent: Wednesday, October 23, 2002 10:05 AM Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > > Sent: Wednesday, October 23, 2002 6:56 PM > > To: 'Stefan Eissing'; Webdav WG > > Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > > ... > > > > Quota is applied to a collection, *not* a user, specifically because of > > the model where a user doesn't just put documents in their own home > > directory.  That's explicit in the draft, and it's an important feature > > to allow directories to be shared by many users and still have quota > > applied.  So if a quota of 1000MB is applied to the "/sales/" > > collection, the server is free to report that quota, and count space > > consumed by resources in the "/sales/" collection in whatever way its > > policy decides. > > This kind of quota system is incompatible with the quota system in a Unix > filesystem (where AFAIK it's per user) -- a standard proposal must be able > to handle these kinds of systems as well. > > > ... > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > From w3c-dist-auth-request@w3.org Wed Oct 23 14:10:59 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA27862 for ; Wed, 23 Oct 2002 14:10:59 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NICFA26051; Wed, 23 Oct 2002 14:12:15 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 14:12:15 -0400 (EDT) Resent-Message-Id: <200210231812.g9NICFA26051@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NICEB26023 for ; Wed, 23 Oct 2002 14:12:14 -0400 (EDT) Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA05410 for ; Wed, 23 Oct 2002 14:12:14 -0400 Received: from inet-mail3.oracle.com (localhost [127.0.0.1]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9NIBhU22335 for ; Wed, 23 Oct 2002 11:11:43 -0700 (PDT) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9NIBgI22325 for ; Wed, 23 Oct 2002 11:11:42 -0700 (PDT) Received: from rgmum3.us.oracle.com (rgmum3.us.oracle.com [138.1.191.24]) by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9NIBgt11493 for ; Wed, 23 Oct 2002 12:11:42 -0600 (MDT) Received: from 152.68.17.155 by rgmum1.us.oracle.com with ESMTP id 89028561035396628; Wed, 23 Oct 2002 12:10:28 -0600 Message-ID: <007a01c27abf$6a3c63c0$9b114498@esedlar> From: "Eric Sedlar" To: "Lisa Dusseault" , "'Julian Reschke'" , "'Stefan Eissing'" , "'Webdav WG'" References: <001301c27abe$f6c5faa0$620afea9@xythoslap> Date: Wed, 23 Oct 2002 11:10:05 -0700 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: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6929 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit We keep track of quota per-user, not per-collection. ----- Original Message ----- From: "Lisa Dusseault" To: "'Julian Reschke'" ; "'Stefan Eissing'" ; "'Webdav WG'" Sent: Wednesday, October 23, 2002 11:06 AM Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > > > This kind of quota system is incompatible with the quota system in a > Unix > > filesystem (where AFAIK it's per user) -- a standard proposal must be > able > > to handle these kinds of systems as well. > > I haven't heard of anybody implementing a WebDAV server with quota that > needed to solve this problem. Is there an actual implementation need > for this? > > > From w3c-dist-auth-request@w3.org Wed Oct 23 14:23:13 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA28343 for ; Wed, 23 Oct 2002 14:23:13 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NIGsN26989; Wed, 23 Oct 2002 14:16:54 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 14:16:54 -0400 (EDT) Resent-Message-Id: <200210231816.g9NIGsN26989@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NIGlB26927 for ; Wed, 23 Oct 2002 14:16:47 -0400 (EDT) Received: from ucsc.edu (cats-mx2.ucsc.edu [128.114.129.35]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA07148 for ; Wed, 23 Oct 2002 14:16:47 -0400 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id g9NIGNk21801; Wed, 23 Oct 2002 11:16:24 -0700 (PDT) From: "Jim Whitehead" To: , "WebDAV" Date: Wed, 23 Oct 2002 11:13:26 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 X-UCSC-CATS-MailScanner: Found to be clean Subject: FW: Last call for ACL document, changes to WebDAV management Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6930 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit As you witnessed on the mailing list yesterday, the WebDAV Access Control protocol has now been reviewed by the WebDAV WG's area director (now Ned Freed, see below), and has begun an IETF-wide last call for comments. This is a chance for people outside the WebDAV working group to submit comments on the specification. The IETF-wide last call goes for two weeks. At the end of this period, we'll issue a new ACL specification incorporating comments from the IETF last call, the Area Director (see below), as well as any issues brought up on the mailing list since the -09 specification was submitted. After the -10 specification is submitted, at a future meeting the IESG will consider the specification, and will (hopefully) approve it as a Proposed Standard. So, ideally, we'll have an RFC number for the ACL specification by year's end. - Jim -----Original Message----- From: ned.freed@mrochek.com [mailto:ned.freed@mrochek.com] Sent: Tuesday, October 22, 2002 5:55 PM To: Lisa Dusseault Cc: ned.freed@mrochek.com; paf@cisco.com; 'Jim Whitehead' Subject: Last call for ACL document, changes to WebDAV management Patrik and I have agreed that I will take over as Applications Area advisor for the WebDAV group. (In case you care, Patrik is taking over as advisor for GeoPriv). My first action as advisor has been to review and issue a last call for draft-ietf-webdav-acl-09.txt. I didn't find any substantive problems with the document when I reviewed it, although I must say it has one of the most, if not the most, complex ACL models I've ever seen, and I wonder if all the complexity is needed. I did find a couple of nits during my review: The DAV:all-grant-before-any-deny element defined in section 6.1.2. I think this element is misnamed or the text description is in error. Specifically, the text says (to me at least) that this element specifies a combinding rule where if any ACE denies access the request fails. Ordering therefore has nothing to do with it; the ACE that denies access can appear anywhere in the ACL. Assuming the description is correct, it seems that the use of the word "before" in the element name is a misnomer. I would suggest that the name be changed to something like any-deny-overrides-grant. There's also a bad line wrap on page 66. I'm sure other nits will be found so I figure holding the document until these two could be fixed was pointless. Ned From w3c-dist-auth-request@w3.org Wed Oct 23 14:39:18 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29198 for ; Wed, 23 Oct 2002 14:39:18 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NIXMq29470; Wed, 23 Oct 2002 14:33:22 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 14:33:22 -0400 (EDT) Resent-Message-Id: <200210231833.g9NIXMq29470@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NIXLB29444 for ; Wed, 23 Oct 2002 14:33:21 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA11582 for ; Wed, 23 Oct 2002 14:33:20 -0400 Received: (qmail 7100 invoked by uid 0); 23 Oct 2002 18:32:48 -0000 Received: from p3ee24814.dip.t-dialin.net (HELO lisa) (62.226.72.20) by mail.gmx.net (mp019-rz3) with SMTP; 23 Oct 2002 18:32:48 -0000 From: "Julian Reschke" To: "'Webdav WG'" Date: Wed, 23 Oct 2002 20:32:47 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <001301c27abe$f6c5faa0$620afea9@xythoslap> Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6931 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, October 23, 2002 8:07 PM > To: 'Julian Reschke'; 'Stefan Eissing'; 'Webdav WG' > Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > > > > > This kind of quota system is incompatible with the quota system in a > Unix > > filesystem (where AFAIK it's per user) -- a standard proposal must be > able > > to handle these kinds of systems as well. > > I haven't heard of anybody implementing a WebDAV server with quota that > needed to solve this problem. Is there an actual implementation need > for this? *If* we implement quotas, they will almost certainly be user-based (at least that's the most common quota model I'm aware of). -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Oct 23 14:40:31 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29284 for ; Wed, 23 Oct 2002 14:40:31 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NIZSs29804; Wed, 23 Oct 2002 14:35:28 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 14:35:28 -0400 (EDT) Resent-Message-Id: <200210231835.g9NIZSs29804@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NIZRB29774 for ; Wed, 23 Oct 2002 14:35:27 -0400 (EDT) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA12062 for ; Wed, 23 Oct 2002 14:35:27 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 184QLY-0008QA-00; Wed, 23 Oct 2002 18:35:12 +0000 Received: from [213.165.64.20] (helo=mail.gmx.net) by mail.xythos.com with smtp (Exim 3.36 #3) id 184QLX-0008Q1-00 for "Lisa Dusseault"@xythos.com; Wed, 23 Oct 2002 18:35:11 +0000 Received: (qmail 23144 invoked by uid 0); 23 Oct 2002 18:35:19 -0000 Received: from p3ee24814.dip.t-dialin.net (HELO lisa) (62.226.72.20) by mail.gmx.net (mp013-rz3) with SMTP; 23 Oct 2002 18:35:19 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Erik Seaberg'" , Cc: <"Lisa Dusseault"@xythos.com> Date: Wed, 23 Oct 2002 20:35:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <000f01c27ab3$fbdd8a90$620afea9@xythoslap> Old-X-Envelope-To: "Lisa Dusseault"@xythos.com Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6932 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, October 23, 2002 6:48 PM > To: 'Erik Seaberg'; w3c-dist-auth@w3c.org > Cc: "Lisa Dusseault"@xythos.com > Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > > The new draft of quota is out, but I never responded directly to these > comments (sorry). Actually, Erik also noted: > On style, HTTP seems to use "octets" rather than "bytes" everywhere > other than range requests. I agree with him. Alternatively, one might also just use the term "storage-units" -- that would give servers more freedom with little impact to the clients. [1] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Oct 23 14:41:08 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29315 for ; Wed, 23 Oct 2002 14:41:07 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NIgOx01162; Wed, 23 Oct 2002 14:42:24 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 14:42:24 -0400 (EDT) Resent-Message-Id: <200210231842.g9NIgOx01162@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NIgNB01135 for ; Wed, 23 Oct 2002 14:42:23 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA14087 for ; Wed, 23 Oct 2002 14:42:22 -0400 Received: (qmail 29014 invoked by uid 0); 23 Oct 2002 18:41:50 -0000 Received: from p3ee24814.dip.t-dialin.net (HELO lisa) (62.226.72.20) by mail.gmx.net (mp018-rz3) with SMTP; 23 Oct 2002 18:41:50 -0000 From: "Julian Reschke" To: "Eric Sedlar" , "Julian Reschke" , "Lisa Dusseault" , "'Stefan Eissing'" , "Webdav WG" Date: Wed, 23 Oct 2002 20:41:48 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <000301c27ab8$ac7ba270$9b114498@esedlar> Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6933 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar > Sent: Wednesday, October 23, 2002 7:21 PM > To: Julian Reschke; Lisa Dusseault; 'Stefan Eissing'; Webdav WG > Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > > It seems like this draft is fine with a user-based rather than a collection-based > system--the server will report the same usage & quota for any collection, but > will return different results depending on who is authenticated, no? > ... No. IMHO, the draft describes a very specific quota model, which it shouldn't if it's to be implemented generally. For instance " Quota is not additive. A collection only has the quota assigned to it, not (in addition) the quota assigned to sub collections or any other collections. Sub-collections can have different quota values than parent collections. These ôsub-quotaös may act as additional constraints, or they may be under-constrained and have no effect. This can allow the delegation of quota administration from root administrators to collection owners. " will not work with a quota system that is per user and filesystem/server. To make this proposal work in the general case, it needs to be more generic. For instance, the only questions I can easily answer with a Unix-FS-based quota system are: - the storage limit (for the authenticated user) - the current storage (for the user) and possibly - the amount of storage taken by a particular set of resources (and that may be expensive to compute). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Oct 23 14:51:55 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29692 for ; Wed, 23 Oct 2002 14:51:55 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NIq2Z02487; Wed, 23 Oct 2002 14:52:02 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 14:52:02 -0400 (EDT) Resent-Message-Id: <200210231852.g9NIq2Z02487@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NIq0B02439 for ; Wed, 23 Oct 2002 14:52:00 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA17304 for ; Wed, 23 Oct 2002 14:52:00 -0400 Received: (qmail 15408 invoked by uid 0); 23 Oct 2002 18:51:47 -0000 Received: from p3ee24814.dip.t-dialin.net (HELO lisa) (62.226.72.20) by mail.gmx.net (mp003-rz3) with SMTP; 23 Oct 2002 18:51:47 -0000 From: "Julian Reschke" To: "'Webdav WG'" Date: Wed, 23 Oct 2002 20:51:46 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <001401c27abf$5b603890$620afea9@xythoslap> Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6934 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, October 23, 2002 8:10 PM > To: 'Clemm, Geoff'; 'Webdav WG' > Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > > 1. Is there general consensus to agree with Geoff? > 2. Is there actually an implementation need for this? > > I'm a little dubious about altering the draft to say this, because it > starts to get really unclear what space-used-bytes means when it can > vary from user to user. If it *does* vary by user (and it does in many quota systems), we'll have to live with that. Alternatively, don't make it a live property but define a new report instead. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Oct 23 14:55:29 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29776 for ; Wed, 23 Oct 2002 14:55:28 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NIusR02993; Wed, 23 Oct 2002 14:56:54 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 14:56:54 -0400 (EDT) Resent-Message-Id: <200210231856.g9NIusR02993@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NIurB02962 for ; Wed, 23 Oct 2002 14:56:53 -0400 (EDT) Received: from oe8.briank.com (oe8.briank.com [198.144.201.197]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA18239 for ; Wed, 23 Oct 2002 14:56:52 -0400 Received: from xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by oe8.briank.com (8.12.3/8.12.3) with ESMTP id g9NIu5PV047105; Wed, 23 Oct 2002 11:56:06 -0700 (PDT) (envelope-from briank@xythos.com) Date: Wed, 23 Oct 2002 11:56:06 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "Webdav WG" To: "Julian Reschke" From: Brian Korver In-Reply-To: Message-Id: <1632A380-E6B9-11D6-8799-000393751598@xythos.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6935 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wednesday, October 23, 2002, at 10:05 AM, Julian Reschke wrote: > This kind of quota system is incompatible with the quota system in a > Unix > filesystem (where AFAIK it's per user) -- a standard proposal must be > able > to handle these kinds of systems as well. In BSD anyhow, quotas are applied to users and/or groups. That said, "collection quotas" (if we can even call them that) are generally enforced by mounting appropriately-sized partitions. Just FYI. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Wed Oct 23 14:59:18 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA29964 for ; Wed, 23 Oct 2002 14:59:18 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NJ0nT04637; Wed, 23 Oct 2002 15:00:49 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 15:00:49 -0400 (EDT) Resent-Message-Id: <200210231900.g9NJ0nT04637@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NJ0nB04611 for ; Wed, 23 Oct 2002 15:00:49 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA19878 for ; Wed, 23 Oct 2002 15:00:48 -0400 Received: (qmail 4121 invoked by uid 0); 23 Oct 2002 19:00:17 -0000 Received: from p3ee24814.dip.t-dialin.net (HELO lisa) (62.226.72.20) by mail.gmx.net (mp001-rz3) with SMTP; 23 Oct 2002 19:00:17 -0000 From: "Julian Reschke" To: "Brian Korver" Cc: "Webdav WG" Date: Wed, 23 Oct 2002 21:00:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <1632A380-E6B9-11D6-8799-000393751598@xythos.com> Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6936 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Brian, > From: Brian Korver [mailto:briank@xythos.com] > Sent: Wednesday, October 23, 2002 8:56 PM > To: Julian Reschke > Cc: Webdav WG > Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > On Wednesday, October 23, 2002, at 10:05 AM, Julian Reschke wrote: > > This kind of quota system is incompatible with the quota system in a > > Unix > > filesystem (where AFAIK it's per user) -- a standard proposal must be > > able > > to handle these kinds of systems as well. > > In BSD anyhow, quotas are applied to users and/or groups. That said, > "collection quotas" (if we can even call them that) are generally enforced > by mounting appropriately-sized partitions. Just FYI. Interesting. So if we take groups into account, we'll need a more flexible reporting mechanism, right? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Oct 23 15:05:59 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA00390 for ; Wed, 23 Oct 2002 15:05:59 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NJ7IS05427; Wed, 23 Oct 2002 15:07:18 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 15:07:18 -0400 (EDT) Resent-Message-Id: <200210231907.g9NJ7IS05427@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NJ7HB05401 for ; Wed, 23 Oct 2002 15:07:17 -0400 (EDT) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA21367 for ; Wed, 23 Oct 2002 15:07:17 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 184QqN-0000Nk-00; Wed, 23 Oct 2002 19:07:03 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 184QqM-0000NZ-00; Wed, 23 Oct 2002 19:07:02 +0000 From: "Lisa Dusseault" To: "'Eric Sedlar'" , "'Julian Reschke'" , "'Stefan Eissing'" , "'Webdav WG'" Date: Wed, 23 Oct 2002 12:07:02 -0700 Message-ID: <001c01c27ac7$5f7c7df0$620afea9@xythoslap> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: <007a01c27abf$6a3c63c0$9b114498@esedlar> Old-X-Envelope-To: eric.sedlar@oracle.com, julian.reschke@gmx.de, stefan.eissing@greenbytes.de, w3c-dist-auth@w3c.org Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6937 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > We keep track of quota per-user, not per-collection. And do you think the existing draft satisfies your implementation needs? lisa From w3c-dist-auth-request@w3.org Wed Oct 23 15:39:35 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA02717 for ; Wed, 23 Oct 2002 15:39:34 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NJeQG12746; Wed, 23 Oct 2002 15:40:26 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 15:40:26 -0400 (EDT) Resent-Message-Id: <200210231940.g9NJeQG12746@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NJeOB12716 for ; Wed, 23 Oct 2002 15:40:24 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA29248 for ; Wed, 23 Oct 2002 15:40:24 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 23 Oct 2002 15:28:38 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403YHCFM>; Wed, 23 Oct 2002 15:39:53 -0400 Message-ID: From: "Clemm, Geoff" To: Webdav WG Date: Wed, 23 Oct 2002 15:39:51 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27ACB.F48657F0" Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6938 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27ACB.F48657F0 Content-Type: text/plain Possibly we should have two pairs of standard properties: DAV:quota DAV:quota-used DAV:current-user-quota DAV:current-user-quota-used (analogous to the way the ACL draft as current-user privileges) Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Wednesday, October 23, 2002 3:00 PM To: Brian Korver Cc: Webdav WG Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Brian, > From: Brian Korver [mailto:briank@xythos.com] > Sent: Wednesday, October 23, 2002 8:56 PM > To: Julian Reschke > Cc: Webdav WG > Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > On Wednesday, October 23, 2002, at 10:05 AM, Julian Reschke wrote: > > This kind of quota system is incompatible with the quota system in a > > Unix > > filesystem (where AFAIK it's per user) -- a standard proposal must be > > able > > to handle these kinds of systems as well. > > In BSD anyhow, quotas are applied to users and/or groups. That said, > "collection quotas" (if we can even call them that) are generally enforced > by mounting appropriately-sized partitions. Just FYI. Interesting. So if we take groups into account, we'll need a more flexible reporting mechanism, right? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 ------_=_NextPart_001_01C27ACB.F48657F0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt

Possibly we should have two pairs of standard = properties:

DAV:quota
DAV:quota-used

DAV:current-user-quota
DAV:current-user-quota-used

(analogous to the way the ACL draft as current-user = privileges)

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]<= /FONT>
Sent: Wednesday, October 23, 2002 3:00 PM
To: Brian Korver
Cc: Webdav WG
Subject: RE: FW: I-D = ACTION:draft-dusseault-dav-quota-01.txt



Brian,

> From: Brian Korver [mailto:briank@xythos.com]
> Sent: Wednesday, October 23, 2002 8:56 = PM
> To: Julian Reschke
> Cc: Webdav WG
> Subject: Re: FW: I-D = ACTION:draft-dusseault-dav-quota-01.txt
>
>
> On Wednesday, October 23, 2002, at 10:05 AM, = Julian Reschke wrote:
> > This kind of quota system is incompatible = with the quota system in a
> > Unix
> > filesystem (where AFAIK it's per user) -- = a standard proposal must be
> > able
> > to handle these kinds of systems as = well.
>
> In BSD anyhow, quotas are applied to users = and/or groups.  That said,
> "collection quotas" (if we can even = call them that) are generally enforced
> by mounting appropriately-sized = partitions.  Just FYI.

Interesting. So if we take groups into account, we'll = need a more flexible
reporting mechanism, right?

Julian

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

------_=_NextPart_001_01C27ACB.F48657F0-- From w3c-dist-auth-request@w3.org Wed Oct 23 15:55:42 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA03307 for ; Wed, 23 Oct 2002 15:55:42 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NJutU14946; Wed, 23 Oct 2002 15:56:55 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 15:56:55 -0400 (EDT) Resent-Message-Id: <200210231956.g9NJutU14946@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NJusB14920 for ; Wed, 23 Oct 2002 15:56:54 -0400 (EDT) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA01893 for ; Wed, 23 Oct 2002 15:56:53 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 184RcN-0000td-00; Wed, 23 Oct 2002 19:56:39 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 184RcM-0000tL-00; Wed, 23 Oct 2002 19:56:39 +0000 From: "Lisa Dusseault" To: "'Clemm, Geoff'" , "'Webdav WG'" Date: Wed, 23 Oct 2002 12:56:38 -0700 Message-ID: <001d01c27ace$4d582870$620afea9@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Old-X-Envelope-To: gclemm@rational.com, w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g9NJusB14920 Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6939 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit That's a fine idea, but there's nothing necessarily tying the current-user-quota stuff into the directory quota draft. I generally prefer to write drafts only once implementation is well understood -- one's assumptions tend to have been confirmed or destroyed by then. Is it reasonable to wait until somebody wants to implement user-quota to standardize it? lisa -----Original Message----- From: Clemm, Geoff [mailto:gclemm@rational.com] Sent: Wednesday, October 23, 2002 12:40 PM To: Webdav WG Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Possibly we should have two pairs of standard properties: DAV:quota DAV:quota-used DAV:current-user-quota DAV:current-user-quota-used (analogous to the way the ACL draft as current-user privileges) Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Wednesday, October 23, 2002 3:00 PM To: Brian Korver Cc: Webdav WG Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Brian, > From: Brian Korver [mailto:briank@xythos.com] > Sent: Wednesday, October 23, 2002 8:56 PM > To: Julian Reschke > Cc: Webdav WG > Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > On Wednesday, October 23, 2002, at 10:05 AM, Julian Reschke wrote: > > This kind of quota system is incompatible with the quota system in a > > Unix > > filesystem (where AFAIK it's per user) -- a standard proposal must be > > able > > to handle these kinds of systems as well. > > In BSD anyhow, quotas are applied to users and/or groups.  That said, > "collection quotas" (if we can even call them that) are generally enforced > by mounting appropriately-sized partitions.  Just FYI. Interesting. So if we take groups into account, we'll need a more flexible reporting mechanism, right? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Oct 23 16:13:58 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA03761 for ; Wed, 23 Oct 2002 16:13:57 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NKFED17009; Wed, 23 Oct 2002 16:15:14 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 16:15:14 -0400 (EDT) Resent-Message-Id: <200210232015.g9NKFED17009@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NKFDB16983 for ; Wed, 23 Oct 2002 16:15:13 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA07502 for ; Wed, 23 Oct 2002 16:15:13 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 23 Oct 2002 16:03:27 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403YH1V7>; Wed, 23 Oct 2002 16:14:42 -0400 Message-ID: From: "Clemm, Geoff" To: "WebDAV (E-mail)" Date: Wed, 23 Oct 2002 16:14:37 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27AD0.CFBE59E0" Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6940 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27AD0.CFBE59E0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Since user-based quota systems are common in existing repositories, I'm not sure what you are suggesting we wait for. Also, I agree with the suggestion that we not use the term "bytes" in the property names. Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Wednesday, October 23, 2002 3:57 PM To: 'Clemm, Geoff'; 'Webdav WG' Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt That's a fine idea, but there's nothing necessarily tying the current-user-quota stuff into the directory quota draft. I generally prefer to write drafts only once implementation is well understood -- one's assumptions tend to have been confirmed or destroyed by then. Is it reasonable to wait until somebody wants to implement user-quota to standardize it? lisa -----Original Message----- From: Clemm, Geoff [mailto:gclemm@rational.com]=20 Sent: Wednesday, October 23, 2002 12:40 PM To: Webdav WG Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Possibly we should have two pairs of standard properties: DAV:quota DAV:quota-used DAV:current-user-quota DAV:current-user-quota-used (analogous to the way the ACL draft as current-user privileges) Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Wednesday, October 23, 2002 3:00 PM To: Brian Korver Cc: Webdav WG Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Brian, > From: Brian Korver [mailto:briank@xythos.com] > Sent: Wednesday, October 23, 2002 8:56 PM > To: Julian Reschke > Cc: Webdav WG > Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > On Wednesday, October 23, 2002, at 10:05 AM, Julian Reschke wrote: > > This kind of quota system is incompatible with the quota system in = a > > Unix > > filesystem (where AFAIK it's per user) -- a standard proposal must be > > able > > to handle these kinds of systems as well. > > In BSD anyhow, quotas are applied to users and/or groups.=A0 That = said, > "collection quotas" (if we can even call them that) are generally enforced > by mounting appropriately-sized partitions.=A0 Just FYI. Interesting. So if we take groups into account, we'll need a more flexible reporting mechanism, right? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 ------_=_NextPart_001_01C27AD0.CFBE59E0 Content-Type: text/html; charset="iso-8859-1" RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt

Since user-based quota systems are common in existing repositories,
I'm not sure what you are suggesting we wait for.

Also, I agree with the suggestion that we not use the term "bytes"
in the property names.

Cheers,
Geoff

-----Original Message-----
From: Lisa Dusseault [mailto:lisa@xythos.com]
Sent: Wednesday, October 23, 2002 3:57 PM
To: 'Clemm, Geoff'; 'Webdav WG'
Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt


That's a fine idea, but there's nothing necessarily tying the
current-user-quota stuff into the directory quota draft.  I generally
prefer to write drafts only once implementation is well understood --
one's assumptions tend to have been confirmed or destroyed by then.  Is
it reasonable to wait until somebody wants to implement user-quota to
standardize it?

lisa

-----Original Message-----
From: Clemm, Geoff [mailto:gclemm@rational.com]
Sent: Wednesday, October 23, 2002 12:40 PM
To: Webdav WG
Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt

Possibly we should have two pairs of standard properties:
DAV:quota
DAV:quota-used
DAV:current-user-quota
DAV:current-user-quota-used
(analogous to the way the ACL draft as current-user privileges)
Cheers,
Geoff
-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]
Sent: Wednesday, October 23, 2002 3:00 PM
To: Brian Korver
Cc: Webdav WG
Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt

Brian,
> From: Brian Korver [mailto:briank@xythos.com]
> Sent: Wednesday, October 23, 2002 8:56 PM
> To: Julian Reschke
> Cc: Webdav WG
> Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt
>
>
> On Wednesday, October 23, 2002, at 10:05 AM, Julian Reschke wrote:
> > This kind of quota system is incompatible with the quota system in a
> > Unix
> > filesystem (where AFAIK it's per user) -- a standard proposal must
be
> > able
> > to handle these kinds of systems as well.
>
> In BSD anyhow, quotas are applied to users and/or groups.  That said,
> "collection quotas" (if we can even call them that) are generally
enforced
> by mounting appropriately-sized partitions.  Just FYI.
Interesting. So if we take groups into account, we'll need a more
flexible
reporting mechanism, right?
Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760

------_=_NextPart_001_01C27AD0.CFBE59E0-- From w3c-dist-auth-request@w3.org Wed Oct 23 16:56:15 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA05058 for ; Wed, 23 Oct 2002 16:56:15 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NKviT22186; Wed, 23 Oct 2002 16:57:44 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 16:57:44 -0400 (EDT) Resent-Message-Id: <200210232057.g9NKviT22186@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NKvhB22159 for ; Wed, 23 Oct 2002 16:57:43 -0400 (EDT) Received: from webmail.tiscali.de (webmail.tiscali.de [62.27.55.1] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA20823 for ; Wed, 23 Oct 2002 16:57:42 -0400 Received: from edgarschwarz.de (62.246.97.134) by webmail.tiscali.de (6.0.045) (authenticated as a0281133@addcom.de) id 3D30181F018B385E; Wed, 23 Oct 2002 22:44:36 +0200 Message-ID: <3DB70D5C.1090209@edgarschwarz.de> Date: Wed, 23 Oct 2002 22:58:04 +0200 From: Edgar Schwarz User-Agent: Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.8) Gecko/20020204 X-Accept-Language: en-us MIME-Version: 1.0 To: w3c-dist-auth@w3c.org CC: edgar@edgarschwarz.de Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Subject: Re (2): FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6941 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi Lisa, "Lisa Dusseault" wrote: > > We keep track of quota per-user, not per-collection. > And do you think the existing draft satisfies your implementation > needs? I don't know because I just browsed the draft yet :-) I just want to add that not only Unix has quotas per user. Our IT department in a Windoze world also has user quotas and in addition project (implemented by NTFS groups I guess) quotas. So I feel that user and group quotas are a must. Cheers, Edgar From w3c-dist-auth-request@w3.org Wed Oct 23 17:09:49 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05558 for ; Wed, 23 Oct 2002 17:09:49 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NLBEj25059; Wed, 23 Oct 2002 17:11:14 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 17:11:14 -0400 (EDT) Resent-Message-Id: <200210232111.g9NLBEj25059@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NLBDB25029 for ; Wed, 23 Oct 2002 17:11:13 -0400 (EDT) Received: from inet-mail1.oracle.com (inet-mail1.oracle.com [148.87.2.201]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA24426 for ; Wed, 23 Oct 2002 17:11:13 -0400 Received: from inet-mail1.oracle.com (localhost [127.0.0.1]) by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9NLAb128982 for ; Wed, 23 Oct 2002 14:10:37 -0700 (PDT) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail1.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9NLAaj28968 for ; Wed, 23 Oct 2002 14:10:36 -0700 (PDT) Received: from rgmum1.us.oracle.com (rgmum1.us.oracle.com [138.1.191.22]) by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9NLAat24277 for ; Wed, 23 Oct 2002 15:10:36 -0600 (MDT) Received: from dhcp-4op7-4op8-east-130-35-171-81.us.oracle.com by rgmum4.us.oracle.com with ESMTP id 89212921035407431; Wed, 23 Oct 2002 15:10:31 -0600 Message-ID: <007d01c27ad8$ea7e5e30$51ab2382@us.oracle.com> From: "Eric Sedlar" To: "Webdav WG" References: Date: Wed, 23 Oct 2002 14:12:38 -0700 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_007A_01C27A9E.3DDAB500" 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: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6942 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_007A_01C27A9E.3DDAB500 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txtI don't see what's = wrong with the existing properties. Basically what they tell you is: = if I want to PUT resources into this particular collection (either = directly, or indirectly in some subcollection), here's how much space = the currently authenticated user can take up. You may not be allowed = (for security reasons) to see how much quota other people are using, so = the only number it makes sense to report is how much space is available = for me. All we need to do is loosen up the language of the draft a bit, not = change the properties or implementation. ----- Original Message -----=20 From: Clemm, Geoff=20 To: Webdav WG=20 Sent: Wednesday, October 23, 2002 12:39 PM Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Possibly we should have two pairs of standard properties:=20 DAV:quota=20 DAV:quota-used=20 DAV:current-user-quota=20 DAV:current-user-quota-used=20 (analogous to the way the ACL draft as current-user privileges)=20 Cheers,=20 Geoff=20 -----Original Message-----=20 From: Julian Reschke [mailto:julian.reschke@gmx.de]=20 Sent: Wednesday, October 23, 2002 3:00 PM=20 To: Brian Korver=20 Cc: Webdav WG=20 Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt=20 Brian,=20 > From: Brian Korver [mailto:briank@xythos.com]=20 > Sent: Wednesday, October 23, 2002 8:56 PM=20 > To: Julian Reschke=20 > Cc: Webdav WG=20 > Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt=20 >=20 >=20 > On Wednesday, October 23, 2002, at 10:05 AM, Julian Reschke wrote:=20 > > This kind of quota system is incompatible with the quota system in = a=20 > > Unix=20 > > filesystem (where AFAIK it's per user) -- a standard proposal must = be=20 > > able=20 > > to handle these kinds of systems as well.=20 >=20 > In BSD anyhow, quotas are applied to users and/or groups. That = said,=20 > "collection quotas" (if we can even call them that) are generally = enforced=20 > by mounting appropriately-sized partitions. Just FYI.=20 Interesting. So if we take groups into account, we'll need a more = flexible=20 reporting mechanism, right?=20 Julian=20 --=20 bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760=20 ------=_NextPart_000_007A_01C27A9E.3DDAB500 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: FW: I-D = ACTION:draft-dusseault-dav-quota-01.txt
I don't see what's wrong with the = existing=20 properties.  Basically what they tell you is:  if I want to = PUT=20 resources into this particular collection (either directly, or = indirectly in=20 some subcollection), here's how much space the currently authenticated = user can=20 take up.  You may not be allowed (for security reasons) to see how = much=20 quota other people are using, so the only number it makes sense to = report is how=20 much space is available for me.
 
All we need to do is loosen up the = language of the=20 draft a bit, not change the properties or implementation.
----- Original Message -----
From:=20 Clemm,=20 Geoff
Sent: Wednesday, October 23, = 2002 12:39=20 PM
Subject: RE: FW: I-D=20 ACTION:draft-dusseault-dav-quota-01.txt

Possibly we should have two pairs of standard=20 properties:

DAV:quota
DAV:quota-used

DAV:current-user-quota
DAV:current-user-quota-used

(analogous to the way the ACL draft as current-user=20 privileges)

Cheers,
Geoff

-----Original Message-----
From:=20 Julian Reschke [mailto:julian.reschke@gmx.de]=20
Sent: Wednesday, October 23, 2002 3:00 PM =
To: Brian Korver
Cc: Webdav = WG
Subject: RE: FW: I-D = ACTION:draft-dusseault-dav-quota-01.txt=20



Brian,

> From: Brian Korver [mailto:briank@xythos.com] =
> Sent: Wednesday, October 23, 2002 8:56 PM =
> To: Julian Reschke
> Cc: = Webdav=20 WG
> Subject: Re: FW: I-D=20 ACTION:draft-dusseault-dav-quota-01.txt
>=20
>
> On Wednesday, = October 23,=20 2002, at 10:05 AM, Julian Reschke wrote:
> >=20 This kind of quota system is incompatible with the quota system in = a=20
> > Unix
> > = filesystem=20 (where AFAIK it's per user) -- a standard proposal must be =
> > able
> > to handle = these kinds=20 of systems as well.
>
>=20 In BSD anyhow, quotas are applied to users and/or groups.  That=20 said,
> "collection quotas" (if we can = even call=20 them that) are generally enforced
> by = mounting=20 appropriately-sized partitions.  Just FYI.

Interesting. So if we take groups into account, = we'll need a=20 more flexible
reporting mechanism, = right?

Julian

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

------=_NextPart_000_007A_01C27A9E.3DDAB500-- From w3c-dist-auth-request@w3.org Wed Oct 23 17:10:32 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05572 for ; Wed, 23 Oct 2002 17:10:32 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NLBvH25220; Wed, 23 Oct 2002 17:11:57 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 17:11:57 -0400 (EDT) Resent-Message-Id: <200210232111.g9NLBvH25220@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NLBuB25193 for ; Wed, 23 Oct 2002 17:11:56 -0400 (EDT) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA24649 for ; Wed, 23 Oct 2002 17:11:55 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 184Sn1-0001to-00; Wed, 23 Oct 2002 21:11:43 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 184Sn0-0001tE-00; Wed, 23 Oct 2002 21:11:42 +0000 From: "Lisa Dusseault" To: "'Clemm, Geoff'" , "'WebDAV \(E-mail\)'" Date: Wed, 23 Oct 2002 14:11:40 -0700 Message-ID: <001e01c27ad8$c8ebb3d0$620afea9@xythoslap> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook, Build 10.0.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 In-Reply-To: Old-X-Envelope-To: gclemm@rational.com, w3c-dist-auth@w3.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g9NLBuB25193 Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6943 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit All I'm suggesting we wait for is somebody who's willing to do the work to think through user-based quotas, and has the motivation because they want to implement it, and finally because a client/server pair need to interoperate with user-based quota information. (Note: when I did early thinking about quota, we assumed we wanted user-based quota. That assumption was destroyed when we really thought about different usage scenarios) For the suggestion not to use 'bytes': I'm ok with 'octets' (is there a difference important enough to make the change? ) but I reject the suggestion that it should be an unmeasured unit. It's useless to know that the quota is 33 frobnitzes and 18 frobnitzes have been used up if you want to have some hint if you can upload a 1.5 Mb file. Lisa -----Original Message----- From: Clemm, Geoff [mailto:gclemm@rational.com] Sent: Wednesday, October 23, 2002 1:15 PM To: WebDAV (E-mail) Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Since user-based quota systems are common in existing repositories, I'm not sure what you are suggesting we wait for. Also, I agree with the suggestion that we not use the term "bytes" in the property names. Cheers, Geoff -----Original Message----- From: Lisa Dusseault [mailto:lisa@xythos.com] Sent: Wednesday, October 23, 2002 3:57 PM To: 'Clemm, Geoff'; 'Webdav WG' Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt That's a fine idea, but there's nothing necessarily tying the current-user-quota stuff into the directory quota draft.  I generally prefer to write drafts only once implementation is well understood -- one's assumptions tend to have been confirmed or destroyed by then.  Is it reasonable to wait until somebody wants to implement user-quota to standardize it? lisa -----Original Message----- From: Clemm, Geoff [mailto:gclemm@rational.com] Sent: Wednesday, October 23, 2002 12:40 PM To: Webdav WG Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Possibly we should have two pairs of standard properties: DAV:quota DAV:quota-used DAV:current-user-quota DAV:current-user-quota-used (analogous to the way the ACL draft as current-user privileges) Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Wednesday, October 23, 2002 3:00 PM To: Brian Korver Cc: Webdav WG Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Brian, > From: Brian Korver [mailto:briank@xythos.com] > Sent: Wednesday, October 23, 2002 8:56 PM > To: Julian Reschke > Cc: Webdav WG > Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > On Wednesday, October 23, 2002, at 10:05 AM, Julian Reschke wrote: > > This kind of quota system is incompatible with the quota system in a > > Unix > > filesystem (where AFAIK it's per user) -- a standard proposal must be > > able > > to handle these kinds of systems as well. > > In BSD anyhow, quotas are applied to users and/or groups.  That said, > "collection quotas" (if we can even call them that) are generally enforced > by mounting appropriately-sized partitions.  Just FYI. Interesting. So if we take groups into account, we'll need a more flexible reporting mechanism, right? Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Oct 23 17:13:47 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05648 for ; Wed, 23 Oct 2002 17:13:47 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NLF1725701; Wed, 23 Oct 2002 17:15:01 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 17:15:01 -0400 (EDT) Resent-Message-Id: <200210232115.g9NLF1725701@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NLF0B25636 for ; Wed, 23 Oct 2002 17:15:00 -0400 (EDT) Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA25446 for ; Wed, 23 Oct 2002 17:15:00 -0400 Received: from inet-mail4.oracle.com (localhost [127.0.0.1]) by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9NLETO20646 for ; Wed, 23 Oct 2002 14:14:29 -0700 (PDT) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9NLESk20622 for ; Wed, 23 Oct 2002 14:14:28 -0700 (PDT) Received: from rgmum2.us.oracle.com (rgmum2.us.oracle.com [138.1.191.23]) by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9NLERt28056 for ; Wed, 23 Oct 2002 15:14:27 -0600 (MDT) Received: from dhcp-4op7-4op8-east-130-35-171-81.us.oracle.com by rgmum2.us.oracle.com with ESMTP id 89217071035407580; Wed, 23 Oct 2002 15:13:00 -0600 Message-ID: <009201c27ad9$43827430$51ab2382@us.oracle.com> From: "Eric Sedlar" To: "Lisa Dusseault" , "'Clemm, Geoff'" , "'Webdav WG'" References: <001d01c27ace$4d582870$620afea9@xythoslap> Date: Wed, 23 Oct 2002 14:15:07 -0700 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: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6944 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I don't think it makes sense to force user quotas into another draft, given that they accomplish the same thing. You can't complain about not having implementations of the draft--there's always a chicken & egg problem here. If you make the draft more generally applicable, you will get more implementations, and I don't see why an interoperable client needs to care about why the current user has a space limit. Note that a given user may have different quotas in different collections. --Eric ----- Original Message ----- From: "Lisa Dusseault" To: "'Clemm, Geoff'" ; "'Webdav WG'" Sent: Wednesday, October 23, 2002 12:56 PM Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > That's a fine idea, but there's nothing necessarily tying the > current-user-quota stuff into the directory quota draft. I generally > prefer to write drafts only once implementation is well understood -- > one's assumptions tend to have been confirmed or destroyed by then. Is > it reasonable to wait until somebody wants to implement user-quota to > standardize it? > > lisa > > -----Original Message----- > From: Clemm, Geoff [mailto:gclemm@rational.com] > Sent: Wednesday, October 23, 2002 12:40 PM > To: Webdav WG > Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > Possibly we should have two pairs of standard properties: > DAV:quota > DAV:quota-used > DAV:current-user-quota > DAV:current-user-quota-used > (analogous to the way the ACL draft as current-user privileges) > Cheers, > Geoff > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Wednesday, October 23, 2002 3:00 PM > To: Brian Korver > Cc: Webdav WG > Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > Brian, > > From: Brian Korver [mailto:briank@xythos.com] > > Sent: Wednesday, October 23, 2002 8:56 PM > > To: Julian Reschke > > Cc: Webdav WG > > Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > > > > On Wednesday, October 23, 2002, at 10:05 AM, Julian Reschke wrote: > > > This kind of quota system is incompatible with the quota system in a > > > Unix > > > filesystem (where AFAIK it's per user) -- a standard proposal must > be > > > able > > > to handle these kinds of systems as well. > > > > In BSD anyhow, quotas are applied to users and/or groups. That said, > > "collection quotas" (if we can even call them that) are generally > enforced > > by mounting appropriately-sized partitions. Just FYI. > Interesting. So if we take groups into account, we'll need a more > flexible > reporting mechanism, right? > Julian > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > From w3c-dist-auth-request@w3.org Wed Oct 23 17:14:03 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05662 for ; Wed, 23 Oct 2002 17:14:03 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NLFSj25778; Wed, 23 Oct 2002 17:15:28 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 17:15:28 -0400 (EDT) Resent-Message-Id: <200210232115.g9NLFSj25778@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NLFRB25752 for ; Wed, 23 Oct 2002 17:15:27 -0400 (EDT) Received: from oe8.briank.com (oe8.briank.com [198.144.201.197]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA25514 for ; Wed, 23 Oct 2002 17:15:27 -0400 Received: from xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by oe8.briank.com (8.12.3/8.12.3) with ESMTP id g9NLErPV047682; Wed, 23 Oct 2002 14:14:53 -0700 (PDT) (envelope-from briank@xythos.com) Date: Wed, 23 Oct 2002 14:14:54 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "Webdav WG" To: "Julian Reschke" From: Brian Korver In-Reply-To: Message-Id: <79E9803C-E6CC-11D6-8799-000393751598@xythos.com> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6945 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wednesday, October 23, 2002, at 12:00 PM, Julian Reschke wrote: > Interesting. So if we take groups into account, we'll need a more > flexible > reporting mechanism, right? > > Julian Possibly, although support for groups (or other such quota mechanisms) sounds like an advanced feature, something that might motivate a new "advanced quotas" draft. Quotas on BSD are an optional feature -- I wonder how many boxes even have group quotas configured at all. -brian briank@xythos.com From w3c-dist-auth-request@w3.org Wed Oct 23 17:21:59 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05839 for ; Wed, 23 Oct 2002 17:21:58 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NLNNd26729; Wed, 23 Oct 2002 17:23:23 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 17:23:23 -0400 (EDT) Resent-Message-Id: <200210232123.g9NLNNd26729@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NLNMB26703 for ; Wed, 23 Oct 2002 17:23:22 -0400 (EDT) Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA27383 for ; Wed, 23 Oct 2002 17:23:22 -0400 Received: from inet-mail3.oracle.com (localhost [127.0.0.1]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9NLMpU10303 for ; Wed, 23 Oct 2002 14:22:51 -0700 (PDT) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9NLMoI10287 for ; Wed, 23 Oct 2002 14:22:50 -0700 (PDT) Received: from rgmum4.us.oracle.com (rgmum4.us.oracle.com [138.1.191.25]) by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9NLMnt10055 for ; Wed, 23 Oct 2002 15:22:50 -0600 (MDT) Received: from dhcp-4op7-4op8-east-130-35-171-81.us.oracle.com by rgmum3.us.oracle.com with ESMTP id 89224191035408078; Wed, 23 Oct 2002 15:21:18 -0600 Message-ID: <00f101c27ada$6c1fae70$51ab2382@us.oracle.com> From: "Eric Sedlar" To: "Lisa Dusseault" , "'Webdav WG'" References: <001c01c27ac7$5f7c7df0$620afea9@xythoslap> Date: Wed, 23 Oct 2002 14:23:24 -0700 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: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6946 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit All I want is for interoperable clients to have two properties: * how much junk can I store in this collection * how much junk have I already stored in this collection (and thus could be used if I delete stuff, potentially) I'm happy with the properties--I just think we need to change the text to indicate that the quota only applies to the currently authenticated HTTP user--an interoperable client cannot assume that the quota will be the same if authenticated as somebody else. I don't think we need an ability to find out how much quota other people have. --Eric ----- Original Message ----- From: "Lisa Dusseault" To: "'Eric Sedlar'" ; "'Julian Reschke'" ; "'Stefan Eissing'" ; "'Webdav WG'" Sent: Wednesday, October 23, 2002 12:07 PM Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > We keep track of quota per-user, not per-collection. > > And do you think the existing draft satisfies your implementation needs? > > lisa > > > From w3c-dist-auth-request@w3.org Wed Oct 23 17:26:17 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05933 for ; Wed, 23 Oct 2002 17:26:17 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NLRfk27139; Wed, 23 Oct 2002 17:27:41 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 17:27:41 -0400 (EDT) Resent-Message-Id: <200210232127.g9NLRfk27139@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NLReB27113 for ; Wed, 23 Oct 2002 17:27:40 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA28539 for ; Wed, 23 Oct 2002 17:27:39 -0400 Received: (qmail 2383 invoked by uid 0); 23 Oct 2002 21:27:08 -0000 Received: from p3ee24814.dip.t-dialin.net (HELO lisa) (62.226.72.20) by mail.gmx.net (mp020-rz3) with SMTP; 23 Oct 2002 21:27:08 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Clemm, Geoff'" , "'WebDAV \(E-mail\)'" Date: Wed, 23 Oct 2002 23:27:07 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <001e01c27ad8$c8ebb3d0$620afea9@xythoslap> Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6947 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, October 23, 2002 11:12 PM > To: 'Clemm, Geoff'; 'WebDAV (E-mail)' > Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > > All I'm suggesting we wait for is somebody who's willing to do the work > to think through user-based quotas, and has the motivation because they > want to implement it, and finally because a client/server pair need to > interoperate with user-based quota information. (Note: when I did early > thinking about quota, we assumed we wanted user-based quota. That > assumption was destroyed when we really thought about different usage > scenarios) If everybody says that user quotas are required, and your proposal can't adequately handle this, this should be resolved by - either working on the proposal until it is flexible enough or - acknowledging that it is *not* generic enough and to publish it as what it is -- the description of one particular quota implementation (in which case it shouldn't be "the" WebDAV quota protocol). > For the suggestion not to use 'bytes': I'm ok with 'octets' (is there a > difference important enough to make the change? ) but I reject the Byte size is whatever the machine/CPU/architecture happens to use. An Octet is 8 bits. A Byte MAY be 8 bits. > suggestion that it should be an unmeasured unit. It's useless to know > that the quota is 33 frobnitzes and 18 frobnitzes have been used up if > you want to have some hint if you can upload a 1.5 Mb file. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Oct 23 17:29:27 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06025 for ; Wed, 23 Oct 2002 17:29:27 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NLUxf27320; Wed, 23 Oct 2002 17:30:59 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 17:30:59 -0400 (EDT) Resent-Message-Id: <200210232130.g9NLUxf27320@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NLUwB27290 for ; Wed, 23 Oct 2002 17:30:58 -0400 (EDT) Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA29278 for ; Wed, 23 Oct 2002 17:30:56 -0400 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id g9NLUZ829363 for ; Wed, 23 Oct 2002 14:30:35 -0700 (PDT) From: "Jim Whitehead" To: "'WebDAV \(E-mail\)'" Date: Wed, 23 Oct 2002 14:27:36 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 In-reply-to: <001e01c27ad8$c8ebb3d0$620afea9@xythoslap> X-UCSC-CATS-MailScanner: Found to be clean Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6948 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > For the suggestion not to use 'bytes': I'm ok with 'octets' (is there a > difference important enough to make the change? ) I think the use of octets comes from prior WGs discussing email, where there was a significant difference between 7-bit and 8-bit bytes. "octet" made it clear you were talking about 8-bits. - Jim From w3c-dist-auth-request@w3.org Wed Oct 23 17:30:50 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06072 for ; Wed, 23 Oct 2002 17:30:50 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NLWNM27546; Wed, 23 Oct 2002 17:32:23 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 17:32:23 -0400 (EDT) Resent-Message-Id: <200210232132.g9NLWNM27546@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NLWNB27520 for ; Wed, 23 Oct 2002 17:32:23 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id RAA29711 for ; Wed, 23 Oct 2002 17:32:22 -0400 Received: (qmail 8962 invoked by uid 0); 23 Oct 2002 21:31:51 -0000 Received: from p3ee24814.dip.t-dialin.net (HELO lisa) (62.226.72.20) by mail.gmx.net (mp007-rz3) with SMTP; 23 Oct 2002 21:31:51 -0000 From: "Julian Reschke" To: "Eric Sedlar" , "Lisa Dusseault" , "'Webdav WG'" Date: Wed, 23 Oct 2002 23:31:50 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <00f101c27ada$6c1fae70$51ab2382@us.oracle.com> Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6949 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar > Sent: Wednesday, October 23, 2002 11:23 PM > To: Lisa Dusseault; 'Webdav WG' > Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > > All I want is for interoperable clients to have two properties: > > * how much junk can I store in this collection Yes. > * how much junk have I already stored in this collection (and thus could be > used if I delete stuff, potentially) That's hard to answer in the presence of bindings. It's certainly not a property of a collection. > I'm happy with the properties--I just think we need to change the text to > indicate that the quota only applies to the currently authenticated HTTP > user--an interoperable client cannot assume that the quota will be the same > if authenticated as somebody else. I don't think we need an ability to find > out how much quota other people have. I think that if the proposal is supposed to be generic enough it shouldn't even try to define how quotas work, how nested collections work and so on. Just define one or two live properties (or possible one report) that gives a client the required information. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Oct 23 17:31:41 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06103 for ; Wed, 23 Oct 2002 17:31:41 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NLXBM27671; Wed, 23 Oct 2002 17:33:11 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 17:33:11 -0400 (EDT) Resent-Message-Id: <200210232133.g9NLXBM27671@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NLXBB27645 for ; Wed, 23 Oct 2002 17:33:11 -0400 (EDT) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA30053 for ; Wed, 23 Oct 2002 17:33:10 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 184T7a-0002Bw-00; Wed, 23 Oct 2002 21:32:58 +0000 Received: from [198.144.203.248] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 184T7a-0002Bl-00; Wed, 23 Oct 2002 21:32:58 +0000 From: "Lisa Dusseault" To: "'Eric Sedlar'" , "'Clemm, Geoff'" , "'Webdav WG'" Date: Wed, 23 Oct 2002 14:32:56 -0700 Message-ID: <000001c27adb$c1237c70$620afea9@xythoslap> 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.3416 Importance: Normal In-Reply-To: <009201c27ad9$43827430$51ab2382@us.oracle.com> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Old-X-Envelope-To: eric.sedlar@oracle.com, gclemm@rational.com, w3c-dist-auth@w3c.org Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6950 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit But we *do* have implementations -- Xythos WebFile Server and Apple iDisk both implement quota with WebDAV properties to expose the values. This implementation experience, and the desire to have interoperability between the clients and servers from these two implementers, led to the writing of the draft. Thus, the draft is fairly reliably known to work for - the Sharemation model, where every user is given a quota tied to their home directory but they can assign sub-quotas to sub-directories if they want - the iDisk model, where every user is given a home directory and a single top-level quota - the WFS corporate customer model, where users put their stuff in shared directories like 'dev', 'sales', 'hr' -- and so you can *only* measure quota by directory, not by user. We always have a temptation to make designs "more generally applicable".. However sometimes I fear we fall in the trap of making the designs too extensible, too theoretical, too much like a framework, and in general too complex to actually reasonable accomplish what are sometimes modest goals. Lisa > -----Original Message----- > From: Eric Sedlar [mailto:eric.sedlar@oracle.com] > You can't complain about not having implementations of the draft--there's > always > a chicken & egg problem here. From w3c-dist-auth-request@w3.org Wed Oct 23 17:58:08 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA06677 for ; Wed, 23 Oct 2002 17:58:08 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NLxbq00620; Wed, 23 Oct 2002 17:59:37 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 17:59:37 -0400 (EDT) Resent-Message-Id: <200210232159.g9NLxbq00620@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NLxaB00593 for ; Wed, 23 Oct 2002 17:59:36 -0400 (EDT) Received: from inet-mail3.oracle.com (inet-mail3.oracle.com [148.87.2.203]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA04245 for ; Wed, 23 Oct 2002 17:59:36 -0400 Received: from inet-mail3.oracle.com (localhost [127.0.0.1]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9NLx5U12614 for ; Wed, 23 Oct 2002 14:59:05 -0700 (PDT) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail3.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9NLx4I12599 for ; Wed, 23 Oct 2002 14:59:04 -0700 (PDT) Received: from rgmum3.us.oracle.com (rgmum3.us.oracle.com [138.1.191.24]) by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9NLx4t18742 for ; Wed, 23 Oct 2002 15:59:04 -0600 (MDT) Received: from dhcp-4op7-4op8-east-130-35-171-81.us.oracle.com by rgmum1.us.oracle.com with ESMTP id 89254421035410341; Wed, 23 Oct 2002 15:59:01 -0600 Message-ID: <014e01c27adf$b151d0e0$51ab2382@us.oracle.com> From: "Eric Sedlar" To: "Julian Reschke" , "Lisa Dusseault" , "'Webdav WG'" References: Date: Wed, 23 Oct 2002 15:01:08 -0700 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: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6951 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > > > > All I want is for interoperable clients to have two properties: > > > > * how much junk can I store in this collection > > Yes. > > > * how much junk have I already stored in this collection (and thus could > be > > used if I delete stuff, potentially) > > That's hard to answer in the presence of bindings. It's certainly not a > property of a collection. > That's why I used the word "potentially". It's just a way of giving the user some indication of how much space could be usable in this collection in the best case (where any other space-occupying resources have been deleted). Certainly, if I have one collection mapping to D: and another mapping to E: on a Windows machine, I would have different "used" quotas for different collections. I don't see why it's not a collection property. > > I'm happy with the properties--I just think we need to change the text to > > indicate that the quota only applies to the currently authenticated HTTP > > user--an interoperable client cannot assume that the quota will be the > same > > if authenticated as somebody else. I don't think we need an ability to > find > > out how much quota other people have. > > I think that if the proposal is supposed to be generic enough it shouldn't > even try to define how quotas work, how nested collections work and so on. > Just define one or two live properties (or possible one report) that gives a > client the required information. I agree that there isn't really a need to define how nested collections work. If I have another partition mounted beneath a parent collection, the collection will have no idea how much space is available in that particular child collection. All we need is the two live properties, and language that indicates that the only thing quotas control is how much new content you can create (either in a resource, or by creating new subcollections). --Eric From w3c-dist-auth-request@w3.org Wed Oct 23 18:00:10 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06755 for ; Wed, 23 Oct 2002 18:00:09 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NM1bO00993; Wed, 23 Oct 2002 18:01:37 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 18:01:37 -0400 (EDT) Resent-Message-Id: <200210232201.g9NM1bO00993@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NM1aB00964 for ; Wed, 23 Oct 2002 18:01:36 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id SAA04601 for ; Wed, 23 Oct 2002 18:01:36 -0400 Received: (qmail 847 invoked by uid 0); 23 Oct 2002 22:01:05 -0000 Received: from p3ee24814.dip.t-dialin.net (HELO lisa) (62.226.72.20) by mail.gmx.net (mp009-rz3) with SMTP; 23 Oct 2002 22:01:05 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Eric Sedlar'" , "'Clemm, Geoff'" , "'Webdav WG'" Date: Thu, 24 Oct 2002 00:01:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <000001c27adb$c1237c70$620afea9@xythoslap> Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6952 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Wednesday, October 23, 2002 11:33 PM > To: 'Eric Sedlar'; 'Clemm, Geoff'; 'Webdav WG' > Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > > But we *do* have implementations -- Xythos WebFile Server and Apple > iDisk both implement quota with WebDAV properties to expose the values. I just did PROPFIND/propname on http://idisk.mac.com/interop01/ (doesn't have the properties listed) and on http://www.sharemation.com/~(someusername) (doesn't have them, but does have {http://www.xythos.com/namespaces/StorageServer}quota). > This implementation experience, and the desire to have interoperability > between the clients and servers from these two implementers, led to the > writing of the draft. Which clients support it then? > Thus, the draft is fairly reliably known to work for > - the Sharemation model, where every user is given a quota tied to > their home directory but they can assign sub-quotas to sub-directories > if they want > - the iDisk model, where every user is given a home directory and a > single top-level quota > - the WFS corporate customer model, where users put their stuff in > shared directories like 'dev', 'sales', 'hr' -- and so you can *only* > measure quota by directory, not by user. > > We always have a temptation to make designs "more generally > applicable".. However sometimes I fear we fall in the trap of making the > designs too extensible, too theoretical, too much like a framework, and > in general too complex to actually reasonable accomplish what are > sometimes modest goals. But then we also sometimes fall into the trap of standardizing too early, right? There's nothing wrong in publicly describing a specific extension (actually, that's very good). But it's a big step from having something that seems to satisfy one or two server's needs, and a design that is generic enough to be considered as the generic approach for WebDAV servers. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Oct 23 18:08:22 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA06965 for ; Wed, 23 Oct 2002 18:08:21 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NM9op01967; Wed, 23 Oct 2002 18:09:50 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 18:09:50 -0400 (EDT) Resent-Message-Id: <200210232209.g9NM9op01967@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NM9nB01941 for ; Wed, 23 Oct 2002 18:09:49 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id SAA06939 for ; Wed, 23 Oct 2002 18:09:48 -0400 Received: (qmail 30309 invoked by uid 0); 23 Oct 2002 22:09:17 -0000 Received: from p3ee24814.dip.t-dialin.net (HELO lisa) (62.226.72.20) by mail.gmx.net (mp001-rz3) with SMTP; 23 Oct 2002 22:09:17 -0000 From: "Julian Reschke" To: "Eric Sedlar" , "Lisa Dusseault" , "'Webdav WG'" Date: Thu, 24 Oct 2002 00:09:16 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <014e01c27adf$b151d0e0$51ab2382@us.oracle.com> Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6953 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Eric Sedlar > Sent: Thursday, October 24, 2002 12:01 AM > To: Julian Reschke; Lisa Dusseault; 'Webdav WG' > Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > > > > > > > All I want is for interoperable clients to have two properties: > > > > > > * how much junk can I store in this collection > > > > Yes. > > > > > * how much junk have I already stored in this collection (and > thus could > > be > > > used if I delete stuff, potentially) > > > > That's hard to answer in the presence of bindings. It's certainly not a > > property of a collection. > > > > That's why I used the word "potentially". It's just a way of giving the user some > indication of how much space could be usable in this collection in the best case > (where any other space-occupying resources have been deleted). > > Certainly, if I have one collection mapping to D: and another mapping to E: on > a Windows machine, I would have different "used" quotas for different collections. > I don't see why it's not a collection property. To compute it, you have to access collection and *all* descendants in the namespace. So computing it may require the same amount of effort as doing a PROPFIND with depth infinity. That's why I'd be very hesitant to consider it being the property of a collection (yes, even taking the current allprop semantics into account). The things that *are* easy to answer for any resource (no matter whether collection or plain resource) are: - max. storage available to the user in quota-partition of the namespace in which the collection is allocated - current storage allocated to the user in this partition - storage taken by *one* specific resource Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Wed Oct 23 18:23:05 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA07121 for ; Wed, 23 Oct 2002 18:23:05 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9NMOXr04614; Wed, 23 Oct 2002 18:24:33 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 18:24:33 -0400 (EDT) Resent-Message-Id: <200210232224.g9NMOXr04614@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9NMOWB04584 for ; Wed, 23 Oct 2002 18:24:32 -0400 (EDT) Received: from inet-mail4.oracle.com (inet-mail4.oracle.com [148.87.2.204]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA10195 for ; Wed, 23 Oct 2002 18:24:32 -0400 Received: from inet-mail4.oracle.com (localhost [127.0.0.1]) by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9NMO1O22295 for ; Wed, 23 Oct 2002 15:24:01 -0700 (PDT) Received: from rgmgw5.us.oracle.com (rgmgw5.us.oracle.com [138.1.191.14]) by inet-mail4.oracle.com (Switch-2.2.3/Switch-2.2.3) with ESMTP id g9NMO0k22283 for ; Wed, 23 Oct 2002 15:24:00 -0700 (PDT) Received: from rgmum2.us.oracle.com (rgmum2.us.oracle.com [138.1.191.23]) by rgmgw5.us.oracle.com (Switch-2.1.3/Switch-2.1.0) with ESMTP id g9NMO0t16489 for ; Wed, 23 Oct 2002 16:24:00 -0600 (MDT) Received: from dhcp-4op7-4op8-east-130-35-171-81.us.oracle.com by rgmum4.us.oracle.com with ESMTP id 89272221035411787; Wed, 23 Oct 2002 16:23:07 -0600 Message-ID: <001f01c27ae3$1042e6e0$51ab2382@us.oracle.com> From: "Eric Sedlar" To: "Julian Reschke" , "Lisa Dusseault" , "'Webdav WG'" References: Date: Wed, 23 Oct 2002 15:25:16 -0700 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: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6954 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > - max. storage available to the user in quota-partition of the namespace in > which the collection is allocated > - current storage allocated to the user in this partition Let's redefine the current draft to use these definitions--I'm happy with them, and I think they address Lisa's requirements as well. --Eric From w3c-dist-auth-request@w3.org Wed Oct 23 20:03:04 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA08458 for ; Wed, 23 Oct 2002 20:03:03 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9O04S515990; Wed, 23 Oct 2002 20:04:28 -0400 (EDT) Resent-Date: Wed, 23 Oct 2002 20:04:28 -0400 (EDT) Resent-Message-Id: <200210240004.g9O04S515990@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9O04RB15962 for ; Wed, 23 Oct 2002 20:04:27 -0400 (EDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA31695 for ; Wed, 23 Oct 2002 20:04:27 -0400 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g9O04Q209581 for ; Wed, 23 Oct 2002 17:04:26 -0700 (PDT) Received: from scv3.apple.com (scv3.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Wed, 23 Oct 2002 17:04:13 -0700 Received: from apple.com (luthji.apple.com [17.202.43.76]) by scv3.apple.com (8.11.3/8.11.3) with ESMTP id g9O04PK09546 for ; Wed, 23 Oct 2002 17:04:25 -0700 (PDT) Date: Wed, 23 Oct 2002 17:04:25 -0700 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) From: Jim Luther To: w3c-dist-auth@w3.org Content-Transfer-Encoding: 7bit In-Reply-To: Message-Id: <283C618E-E6E4-11D6-9FDF-0003934B6A22@apple.com> X-Mailer: Apple Mail (2.546) Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6955 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit On Wednesday, October 23, 2002, at 03:01 PM, Julian Reschke wrote: > I just did PROPFIND/propname on > > http://idisk.mac.com/interop01/ > > (doesn't have the properties listed) Apple's iDisk and the Mac OS X WebDAV file system implementations were complete and in use before this document. They use the properties "quota" and "quotaused" and the values returned by those properties are in 512-octet units. Connect to iDisk with the Mac OS X client and the first PROPFIND you see will ask for and receive those properties. When Lisa started working on the current draft and it was obvious that the values returned should be in the same units used by other parts of HTTP (such as Content-Length) instead of 512-byte units, different property names were used. I have no problem with the property names quota-bytes and quota-used-bytes being changed to quota-octets and quota-used-octets. I agree that octet is the accurate term to use since it's well defined in RFC2616, section 2.2. On Wednesday, October 23, 2002, at 02:23 PM, Eric Sedlar wrote: > All I want is for interoperable clients to have two properties: > > * how much junk can I store in this collection > * how much junk have I already stored in this collection (and thus > could be > used if I delete stuff, potentially) > > I'm happy with the properties--I just think we need to change the text > to > indicate that the quota only applies to the currently authenticated > HTTP > user--an interoperable client cannot assume that the quota will be the > same > if authenticated as somebody else. I don't think we need an ability > to find > out how much quota other people have. That's pretty much what the values returned mean to us and how we use them. Since the Mac OS X WebDAV file system mounts a collection as a disk volume, we use the quota values to show the user how big of an iDisk they have and how much of that space is still available. Once this group has determined what the new property names are, it'll be simple to change the iDisk server to use the new property names (as well as the old property names for backwards compatibility with existing Mac OS X clients). Once the changes on the iDisk server are made, it will also be a simple client change to ask only for the new property names. - Jim From w3c-dist-auth-request@w3.org Thu Oct 24 04:35:24 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29228 for ; Thu, 24 Oct 2002 04:35:23 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9O8aam09146; Thu, 24 Oct 2002 04:36:36 -0400 (EDT) Resent-Date: Thu, 24 Oct 2002 04:36:36 -0400 (EDT) Resent-Message-Id: <200210240836.g9O8aam09146@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9O8aYB09118 for ; Thu, 24 Oct 2002 04:36:34 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA19531 for ; Thu, 24 Oct 2002 04:36:33 -0400 Received: from greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Thu, 24 Oct 2002 10:35:56 +0200 Date: Thu, 24 Oct 2002 10:35:56 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "Webdav WG" To: "Lisa Dusseault" From: Stefan Eissing In-Reply-To: <001001c27ab5$0ed451a0$620afea9@xythoslap> Message-Id: <9D96216C-E72B-11D6-9950-00039384827E@greenbytes.de> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6956 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit With the current discussion the quota draft will be able to accomodate the Sharemation model as well as a UNIX quota like system. Without adding any complexity. As Eric pointed out, we basically need new definitions of the properties to clarify the semantics. In detail: Am Mittwoch, 23.10.02, um 18:55 Uhr (Europe/Berlin) schrieb Lisa Dusseault: > > Stefan asked (a while ago, sorry to be so late): > >> I can see how this draft is applied to servers like Sharemation >> which have a separate collection hierarchy for each user. > > Sharemation does have a separate collection hierarchy for each user, > but > many other Xythos WebFile Server installations have users share > collections with common names like "sales", "marketing", "hr". The > same > quota system applies to both models, as I hope I'll be able to explain. With that model, you are - in my view - closer to a partition model than what is called quotas in UNIX. If I understand you correctly, sharemation allocates "storage devices" to collection hierarchies and the quota properities report the "space left on device". That is a valid and useful server model. >> I have more trouble applying it to servers where it is common >> that more than one user has write access to collections. Imagine >> that Sharemation has a collection containing all your user >> collections. How would the quota properties appear on that >> collection? > > Quota is applied to a collection, *not* a user, specifically because of > the model where a user doesn't just put documents in their own home > directory. That's explicit in the draft, and it's an important feature > to allow directories to be shared by many users and still have quota > applied. So if a quota of 1000MB is applied to the "/sales/" > collection, the server is free to report that quota, and count space > consumed by resources in the "/sales/" collection in whatever way its > policy decides. That's ok. But there are other servers with real user quotas which need a more flexible definition of the WebDAV quota properties. > >> Where I see a real problem is a server supporting bindings. > > It's specifically left up to the server to figure out how to support > bindings -- it would be impossible for the draft to enforce how to > count > space used, when it's a matter of policy and the interaction of many > potential features. The server may: > - count the space used by a binding as 0 bytes, Then every collection will use 0 bytes. Remember that a collection only holds bindings and nothing else. > > - count the bytes used to store the binding only and not the length of > the resource it points to Then every collection will use just a few bytes (as compared to the amount taken up by the content of all resources). > - divide the size of the target resource among all its bindings, Assume collections /a/b, /a/c, and two bindings to a 1 megabyte resource in /a/b/x and /a/c/x. Then /a/b has bytes-used of 500 KB (same for /a/c), but the client only sees a single 1MB resource in /a/b. Certainly this bytes-used value is not very helpful for the client in order to know the space taken up by the collection. > - count the full size of the target resource against every binding. Assume again the example from above. Now collection /a will report 2 MB as bytes-used. > That's why the draft requires the server to show how space is used -- > it > is not possible for the standard to decide these policy matters. The solution is not to more strictly define bytes-used, but to relax the definition. From w3c-dist-auth-request@w3.org Thu Oct 24 04:43:46 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA29405 for ; Thu, 24 Oct 2002 04:43:46 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9O8jFC10702; Thu, 24 Oct 2002 04:45:15 -0400 (EDT) Resent-Date: Thu, 24 Oct 2002 04:45:15 -0400 (EDT) Resent-Message-Id: <200210240845.g9O8jFC10702@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9O8jEB10674 for ; Thu, 24 Oct 2002 04:45:14 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA21187 for ; Thu, 24 Oct 2002 04:45:13 -0400 Received: from greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Thu, 24 Oct 2002 10:44:07 +0200 Date: Thu, 24 Oct 2002 10:44:08 +0200 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: Webdav WG To: "Clemm, Geoff" From: Stefan Eissing In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.546) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g9O8jEB10674 Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6957 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit Am Mittwoch, 23.10.02, um 21:39 Uhr (Europe/Berlin) schrieb Clemm, Geoff: > Possibly we should have two pairs of standard properties: > > DAV:quota > DAV:quota-used That would be "space-left-on-device" and not a quota. Certainly every file system has it, but clients are more concerned with the per-user quotas. Do you see a need to define these properties? > DAV:current-user-quota > DAV:current-user-quota-used > > (analogous to the way the ACL draft as current-user privileges) > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Wednesday, October 23, 2002 3:00 PM > To: Brian Korver > Cc: Webdav WG > Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > > Brian, > > > From: Brian Korver [mailto:briank@xythos.com] > > Sent: Wednesday, October 23, 2002 8:56 PM > > To: Julian Reschke > > Cc: Webdav WG > > Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > > > > On Wednesday, October 23, 2002, at 10:05 AM, Julian Reschke wrote: > > > This kind of quota system is incompatible with the quota system in > a > > > Unix > > > filesystem (where AFAIK it's per user) -- a standard proposal must > be > > > able > > > to handle these kinds of systems as well. > > > > In BSD anyhow, quotas are applied to users and/or groups.  That said, > > "collection quotas" (if we can even call them that) are generally > enforced > > by mounting appropriately-sized partitions.  Just FYI. > > Interesting. So if we take groups into account, we'll need a more > flexible > reporting mechanism, right? > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Thu Oct 24 06:25:09 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA01229 for ; Thu, 24 Oct 2002 06:25:09 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9OAFIo08339; Thu, 24 Oct 2002 06:15:18 -0400 (EDT) Resent-Date: Thu, 24 Oct 2002 06:15:18 -0400 (EDT) Resent-Message-Id: <200210241015.g9OAFIo08339@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9OAFGB08309 for ; Thu, 24 Oct 2002 06:15:16 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with SMTP id GAA11872 for ; Thu, 24 Oct 2002 06:15:16 -0400 Received: from greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Thu, 24 Oct 2002 12:14:57 +0200 Date: Thu, 24 Oct 2002 12:14:56 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) From: Stefan Eissing To: w3c-dist-auth@w3c.org Content-Transfer-Encoding: 7bit In-Reply-To: <001f01c27ae3$1042e6e0$51ab2382@us.oracle.com> Message-Id: <71FA0C98-E739-11D6-9950-00039384827E@greenbytes.de> X-Mailer: Apple Mail (2.546) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6958 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Am Donnerstag, 24.10.02, um 00:25 Uhr (Europe/Berlin) schrieb Eric Sedlar: > >> - max. storage available to the user in quota-partition of the >> namespace > in >> which the collection is allocated >> - current storage allocated to the user in this partition > > Let's redefine the current draft to use these definitions--I'm happy > with > them, and I think they address Lisa's requirements as well. Agreed. Let's give it a try: quota space A quota space is a storage area on a WebDAV server where the amount of storage for resources is restricted. The restriction might be due to physical disk size or limited by configuration options of the server. The storage restriction might be enforced the same for all users, letting them share the available space, or configured and enforced differently for each user. A WebDAV collection belongs to at most one quota space. Subcollections might belong to the same or different quota spaces. (Comment: I'm not sure if we need identifier for quota spaces, so that clients could compare if two collections are in the same quota.) A collection belonging to a quota space has the following two live properties: DAV:quota-free The DAV:quota-free property reports the amount of storage in octets available to the current user in the quota space the reporting collection belongs to. The value of this property will usually be protected, although a user with sufficient privileges may be permitted to change the value. The property is useful even if it is protected. A 403 Forbidden response is recommended for attempts to write a protected property. A value of 0 indicates that storage is limited to 0. Users will probably not be able to add resources to the collection. If a collection has no quota enforced, it should not return this property at all. A client cannot entirely assume that there is no quota enforced on a collection that does not have this property, but might as well act as if there is no quota. This property is OPTIONAL on collections and SHOULD NOT exist on non-collection resources. When a new collection is created, it is up to the server to initialize the value appropriately if it chooses to. And DAV:quota-used The DAV:quota-used property reports the amount of storage in octets used by the current user in the quota space the reporting collection belongs to. These values are an approximation and should be treated as such. It is not required that DAV:quota-free and DAV:quota-used always add up to the same value. From w3c-dist-auth-request@w3.org Thu Oct 24 07:55:08 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA02951 for ; Thu, 24 Oct 2002 07:55:08 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9OBuZ725338; Thu, 24 Oct 2002 07:56:35 -0400 (EDT) Resent-Date: Thu, 24 Oct 2002 07:56:35 -0400 (EDT) Resent-Message-Id: <200210241156.g9OBuZ725338@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9OBuYB25312 for ; Thu, 24 Oct 2002 07:56:34 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id HAA31425 for ; Thu, 24 Oct 2002 07:56:33 -0400 Received: (qmail 13348 invoked by uid 0); 24 Oct 2002 11:56:01 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp007-rz3) with SMTP; 24 Oct 2002 11:56:01 -0000 From: "Julian Reschke" To: "Stefan Eissing" , Date: Thu, 24 Oct 2002 13:56:01 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <71FA0C98-E739-11D6-9950-00039384827E@greenbytes.de> X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Importance: Normal Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6959 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing > Sent: Thursday, October 24, 2002 12:15 PM > To: w3c-dist-auth@w3c.org > Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > > > Am Donnerstag, 24.10.02, um 00:25 Uhr (Europe/Berlin) schrieb Eric > Sedlar: > > > > >> - max. storage available to the user in quota-partition of the > >> namespace > > in > >> which the collection is allocated > >> - current storage allocated to the user in this partition > > > > Let's redefine the current draft to use these definitions--I'm happy > > with > > them, and I think they address Lisa's requirements as well. > > Agreed. Let's give it a try: > > quota space > A quota space is a storage area on a WebDAV server where the amount > of storage for resources is restricted. The restriction might be due to > physical disk size or limited by configuration options of the server. > The storage restriction might be enforced the same for all users, letting > them share the available space, or configured and enforced differently > for each user. > A WebDAV collection belongs to at most one quota space. Subcollections > might belong to the same or different quota spaces. If a subcollection can belong to a separate quota space (aka Unix device), can't this also be the case for internal members? I think that the distinction between collections and non-collections is essentially meaningless -- the properties defined here apply to the quota space, not to a particular resource. Therefore they should be defined on all resources that are quota-controlled. > (Comment: I'm not sure if we need identifier for quota spaces, so that > clients could compare if two collections are in the same quota.) May be useful. > A collection belonging to a quota space has the following two live > properties: > > DAV:quota-free > The DAV:quota-free property reports the amount of storage in octets > available to the current user in the quota space the reporting collection > belongs to. ...the reporting resource... > The value of this property will usually be protected, although a user with > sufficient privileges may be permitted to change the value. The > property is useful even if it is protected. A 403 Forbidden response > is recommended for attempts to write a protected property. Remove last two sentences. > A value of 0 indicates that storage is limited to 0. Users will > probably not be able to add resources to the collection. > If a collection has no quota enforced, it should not return this > property at all. A client cannot entirely assume that there is no > quota enforced on a collection that does not have this property, but > might as well act as if there is no quota. Replace "should not return" by something like "MUST NOT be defined on the resource". > This property is OPTIONAL on collections and SHOULD NOT exist on > non-collection resources. When a new collection is created, it is > up to the server to initialize the value appropriately if it chooses > to. Completely remove this paragraph. > And > > DAV:quota-used > The DAV:quota-used property reports the amount of storage in octets > used by the current user in the quota space the reporting collection > belongs to. ... the reporting resource... > These values are an approximation and should be treated as such. > It is not required that DAV:quota-free and DAV:quota-used always add up > to the same value. > > > Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Oct 24 08:53:20 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA04919 for ; Thu, 24 Oct 2002 08:53:20 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9OCrN103052; Thu, 24 Oct 2002 08:53:23 -0400 (EDT) Resent-Date: Thu, 24 Oct 2002 08:53:23 -0400 (EDT) Resent-Message-Id: <200210241253.g9OCrN103052@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9OCrKB03026 for ; Thu, 24 Oct 2002 08:53:20 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA23269 for ; Thu, 24 Oct 2002 08:53:19 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 24 Oct 2002 08:41:31 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403Y2PR0>; Thu, 24 Oct 2002 08:52:48 -0400 Message-ID: From: "Clemm, Geoff" To: Webdav WG Date: Thu, 24 Oct 2002 08:52:47 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27B5C.40ECE5B0" Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6960 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27B5C.40ECE5B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm happy to just have the two properties, and reword the description so that they are clearly the quota for the current user, where a given implementation can choose to have all files (not just the files created by that user) use up that quota. I'd suggest most of the content of the draft just be deleted since I believe its major problem at the moment is overspecification. There is no need for much motivation, since the concept is quite straightforward and familiar to most people. In particular, Stefan's suggested wording is fine with me. I don't think I'd bother with giving the quota space an identifier, but I wouldn't object to defining a property for it. Cheers, Geoff -----Original Message----- From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de] Sent: Thursday, October 24, 2002 4:44 AM To: Clemm, Geoff Cc: Webdav WG Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Am Mittwoch, 23.10.02, um 21:39 Uhr (Europe/Berlin) schrieb Clemm,=20 Geoff: > Possibly we should have two pairs of standard properties: > > DAV:quota > DAV:quota-used That would be "space-left-on-device" and not a quota. Certainly every file system has it, but clients are more concerned with the per-user quotas. Do you see a need to define these properties? > DAV:current-user-quota > DAV:current-user-quota-used > > (analogous to the way the ACL draft as current-user privileges) > > Cheers, > Geoff > > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Wednesday, October 23, 2002 3:00 PM > To: Brian Korver > Cc: Webdav WG > Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > > Brian, > > > From: Brian Korver [mailto:briank@xythos.com] > > Sent: Wednesday, October 23, 2002 8:56 PM > > To: Julian Reschke > > Cc: Webdav WG > > Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > > > > On Wednesday, October 23, 2002, at 10:05 AM, Julian Reschke wrote: > > > This kind of quota system is incompatible with the quota system = in=20 > a > > > Unix > > > filesystem (where AFAIK it's per user) -- a standard proposal = must=20 > be > > > able > > > to handle these kinds of systems as well. > > > > In BSD anyhow, quotas are applied to users and/or groups.=A0 That = said, > > "collection quotas" (if we can even call them that) are generally=20 > enforced > > by mounting appropriately-sized partitions.=A0 Just FYI. > > Interesting. So if we take groups into account, we'll need a more=20 > flexible > reporting mechanism, right? > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > ------_=_NextPart_001_01C27B5C.40ECE5B0 Content-Type: text/html; charset="iso-8859-1" RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt

I'm happy to just have the two properties, and reword the
description so that they are clearly the quota for the
current user,
where a given implementation can choose to have all files
(not just the files created by that user) use up that quota.

I'd suggest most of the content of the draft just be deleted
since I believe its major problem at the moment is overspecification.
There is no need for much motivation, since the concept is
quite straightforward and familiar to most people.  In particular,
Stefan's suggested wording is fine with me.  I don't think I'd
bother with giving the quota space an identifier, but I wouldn't
object to defining a property for it.

Cheers,
Geoff

-----Original Message-----
From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
Sent: Thursday, October 24, 2002 4:44 AM
To: Clemm, Geoff
Cc: Webdav WG
Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt



Am Mittwoch, 23.10.02, um 21:39 Uhr (Europe/Berlin) schrieb Clemm,
Geoff:

> Possibly we should have two pairs of standard properties:
>
> DAV:quota
> DAV:quota-used

That would be "space-left-on-device" and not a quota. Certainly
every file system has it, but clients are more concerned
with the per-user quotas. Do you see a need to define these
properties?

> DAV:current-user-quota
> DAV:current-user-quota-used
>
> (analogous to the way the ACL draft as current-user privileges)
>
> Cheers,
> Geoff
>
> -----Original Message-----
> From: Julian Reschke [mailto:julian.reschke@gmx.de]
> Sent: Wednesday, October 23, 2002 3:00 PM
> To: Brian Korver
> Cc: Webdav WG
> Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt
>
>
>
> Brian,
>
> > From: Brian Korver [mailto:briank@xythos.com]
> > Sent: Wednesday, October 23, 2002 8:56 PM
> > To: Julian Reschke
> > Cc: Webdav WG
> > Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt
> >
> >
> > On Wednesday, October 23, 2002, at 10:05 AM, Julian Reschke wrote:
> > > This kind of quota system is incompatible with the quota system in
> a
> > > Unix
> > > filesystem (where AFAIK it's per user) -- a standard proposal must
> be
> > > able
> > > to handle these kinds of systems as well.
> >
> > In BSD anyhow, quotas are applied to users and/or groups.  That said,
> > "collection quotas" (if we can even call them that) are generally
> enforced
> > by mounting appropriately-sized partitions.  Just FYI.
>
> Interesting. So if we take groups into account, we'll need a more
> flexible
> reporting mechanism, right?
>
> Julian
>
> --
> <green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760
>


------_=_NextPart_001_01C27B5C.40ECE5B0-- From w3c-dist-auth-request@w3.org Thu Oct 24 09:48:06 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA07950 for ; Thu, 24 Oct 2002 09:48:05 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9ODmbV10109; Thu, 24 Oct 2002 09:48:37 -0400 (EDT) Resent-Date: Thu, 24 Oct 2002 09:48:37 -0400 (EDT) Resent-Message-Id: <200210241348.g9ODmbV10109@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9ODmaB10082 for ; Thu, 24 Oct 2002 09:48:36 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA08904 for ; Thu, 24 Oct 2002 09:48:36 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 24 Oct 2002 09:36:48 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403Y245J>; Thu, 24 Oct 2002 09:48:05 -0400 Message-ID: From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Thu, 24 Oct 2002 09:48:04 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27B63.FA0EFC20" Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6961 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27B63.FA0EFC20 Content-Type: text/plain I agree with Julian. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] I think that the distinction between collections and non-collections is essentially meaningless -- the properties defined here apply to the quota space, not to a particular resource. Therefore they should be defined on all resources that are quota-controlled. > This property is OPTIONAL on collections and SHOULD NOT exist on > non-collection resources. When a new collection is created, it is > up to the server to initialize the value appropriately if it chooses > to. Completely remove this paragraph. ------_=_NextPart_001_01C27B63.FA0EFC20 Content-Type: text/html RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt

I agree with Julian.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]

I think that the distinction between collections and non-collections is
essentially meaningless -- the properties defined here apply to the quota
space, not to a particular resource. Therefore they should be defined on all
resources that are quota-controlled.


>     This property is OPTIONAL on collections and SHOULD NOT exist on
>     non-collection resources.  When a new collection is created, it is
>     up to the server to initialize the value appropriately if it chooses
>     to.

Completely remove this paragraph.

------_=_NextPart_001_01C27B63.FA0EFC20-- From w3c-dist-auth-request@w3.org Thu Oct 24 11:18:07 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA11520 for ; Thu, 24 Oct 2002 11:18:07 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9OFJGg28748; Thu, 24 Oct 2002 11:19:16 -0400 (EDT) Resent-Date: Thu, 24 Oct 2002 11:19:16 -0400 (EDT) Resent-Message-Id: <200210241519.g9OFJGg28748@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9OFJEB28716 for ; Thu, 24 Oct 2002 11:19:14 -0400 (EDT) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA08797 for ; Thu, 24 Oct 2002 11:19:14 -0400 Received: from cse.ucsc.edu ([63.194.88.161]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0H4H00G80RW13F@mta5.snfc21.pbi.net> for w3c-dist-auth@w3.org; Thu, 24 Oct 2002 08:19:13 -0700 (PDT) Date: Thu, 24 Oct 2002 08:10:48 -0700 From: Elias To: "'WebDAV (E-mail)'" Reply-to: "'WebDAV (E-mail)'" Message-id: <3DB80D78.4010201@cse.ucsc.edu> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en,pdf User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 References: <001e01c27ad8$c8ebb3d0$620afea9@xythoslap> Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6962 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Hello, I feel pretty strongly that the units should be defined as bytes. This is a widely accepted standard unit of measure when talking about disk space used/available. If the unit is left undefined, the vast majority of servers would use some denomination of bytes as their unit of measure anyway, whether that be individual bytes, Kb, Mb, etc. Allowing this flexibility doesn't buy us much, just more unit conversions. Furthermore, writing a generic client to support multiple units (on different server implementations) would rapidly become an exercise in finding out what unit the server was using. This would, in turn, require either another round trip or, more likely, the introduction of a new header value, thus unnecessarily raising the complexity of the world... Elias Lisa Dusseault wrote: > [...] For the suggestion not to use 'bytes': I'm ok with 'octets' (is there a > difference important enough to make the change? ) but I reject the > suggestion that it should be an unmeasured unit. It's useless to know > that the quota is 33 frobnitzes and 18 frobnitzes have been used up if > you want to have some hint if you can upload a 1.5 Mb file. From w3c-dist-auth-request@w3.org Thu Oct 24 12:23:40 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA14600 for ; Thu, 24 Oct 2002 12:23:40 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9OGOGf10010; Thu, 24 Oct 2002 12:24:16 -0400 (EDT) Resent-Date: Thu, 24 Oct 2002 12:24:16 -0400 (EDT) Resent-Message-Id: <200210241624.g9OGOGf10010@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9OGOFB09984 for ; Thu, 24 Oct 2002 12:24:15 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA29761 for ; Thu, 24 Oct 2002 12:24:15 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 24 Oct 2002 12:12:27 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403Y20HT>; Thu, 24 Oct 2002 12:23:44 -0400 Message-ID: From: "Clemm, Geoff" To: "'WebDAV (E-mail)'" Date: Thu, 24 Oct 2002 12:23:43 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27B79.B845DA00" Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6963 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27B79.B845DA00 Content-Type: text/plain Just to clarify, the proposal I was supporting was to replace bytes with octets, not to leave the units unspecified. I don't think anyone wants to leave the units unspecified. There is a separate question of whether the units should to appear in the property name ... I'd probably leave it off, for uniformity with the rest of HTTP (it is the "Length" header, not the "Octet-Length" header). Cheers, Geoff -----Original Message----- From: Elias [mailto:elias@cse.ucsc.edu] Sent: Thursday, October 24, 2002 11:11 AM To: 'WebDAV (E-mail)' Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Hello, I feel pretty strongly that the units should be defined as bytes. This is a widely accepted standard unit of measure when talking about disk space used/available. If the unit is left undefined, the vast majority of servers would use some denomination of bytes as their unit of measure anyway, whether that be individual bytes, Kb, Mb, etc. Allowing this flexibility doesn't buy us much, just more unit conversions. Furthermore, writing a generic client to support multiple units (on different server implementations) would rapidly become an exercise in finding out what unit the server was using. This would, in turn, require either another round trip or, more likely, the introduction of a new header value, thus unnecessarily raising the complexity of the world... Elias Lisa Dusseault wrote: > [...] For the suggestion not to use 'bytes': I'm ok with 'octets' (is there a > difference important enough to make the change? ) but I reject the > suggestion that it should be an unmeasured unit. It's useless to know > that the quota is 33 frobnitzes and 18 frobnitzes have been used up if > you want to have some hint if you can upload a 1.5 Mb file. ------_=_NextPart_001_01C27B79.B845DA00 Content-Type: text/html RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt

Just to clarify, the proposal I was supporting was to replace
bytes with octets, not to leave the units unspecified.  I don't
think anyone wants to leave the units unspecified.  There is a
separate question of whether the units should to appear in the
property name ... I'd probably leave it off, for uniformity with
the rest of HTTP (it is the "Length" header, not the "Octet-Length"
header).

Cheers,
Geoff

-----Original Message-----
From: Elias [mailto:elias@cse.ucsc.edu]
Sent: Thursday, October 24, 2002 11:11 AM
To: 'WebDAV (E-mail)'
Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt



Hello,

I feel pretty strongly that the units should be defined as bytes. This
is a widely accepted standard unit of measure when talking about disk
space used/available. If the unit is left undefined, the vast majority
of servers would use some denomination of bytes as their unit of measure
anyway, whether that be individual bytes, Kb, Mb, etc. Allowing this
flexibility doesn't buy us much, just more unit conversions.

Furthermore, writing a generic client to support multiple units (on
different server implementations) would rapidly become an exercise in
finding out what unit the server was using. This would, in turn, require
either another round trip or, more likely, the introduction of a new
header value, thus unnecessarily raising the complexity of the world...


Elias


Lisa Dusseault wrote:

> [...] For the suggestion not to use 'bytes': I'm ok with 'octets' (is there a
> difference important enough to make the change? ) but I reject the
> suggestion that it should be an unmeasured unit. It's useless to know
> that the quota is 33 frobnitzes and 18 frobnitzes have been used up if
> you want to have some hint if you can upload a 1.5 Mb file.

------_=_NextPart_001_01C27B79.B845DA00-- From w3c-dist-auth-request@w3.org Thu Oct 24 12:39:32 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA15205 for ; Thu, 24 Oct 2002 12:39:32 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9OGeqb12725; Thu, 24 Oct 2002 12:40:52 -0400 (EDT) Resent-Date: Thu, 24 Oct 2002 12:40:52 -0400 (EDT) Resent-Message-Id: <200210241640.g9OGeqb12725@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9OGeoB12695 for ; Thu, 24 Oct 2002 12:40:50 -0400 (EDT) Received: from mail-out1.apple.com (mail-out1.apple.com [17.254.0.52]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA01593 for ; Thu, 24 Oct 2002 12:40:50 -0400 Received: from mailgate2.apple.com (A17-129-100-225.apple.com [17.129.100.225]) by mail-out1.apple.com (8.11.3/8.11.3) with ESMTP id g9OGemk14217 for ; Thu, 24 Oct 2002 09:40:49 -0700 (PDT) Received: from scv2.apple.com (scv2.apple.com) by mailgate2.apple.com (Content Technologies SMTPRS 4.2.1) with ESMTP id for ; Thu, 24 Oct 2002 09:40:48 -0700 Received: from apple.com (luthji3.apple.com [17.202.43.78]) by scv2.apple.com (8.11.3/8.11.3) with ESMTP id g9OGelZ28069 for ; Thu, 24 Oct 2002 09:40:47 -0700 (PDT) Date: Thu, 24 Oct 2002 09:43:22 -0700 Content-Type: multipart/alternative; boundary=Apple-Mail-2--811456326 Mime-Version: 1.0 (Apple Message framework v546) From: Jim Luther To: In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.546) Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6964 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --Apple-Mail-2--811456326 Content-Type: text/plain; charset=US-ASCII; format=flowed Content-Transfer-Encoding: 7bit On Thursday, October 24, 2002, at 09:23 AM, Clemm, Geoff wrote: > There is a > separate question of whether the units should to appear in the > property name ... I'd probably leave it off, for uniformity with > the rest of HTTP (it is the "Length" header, not the "Octet-Length" > header). I like having the unit type in the name because it makes the purpose of the property more self-described. However, I'm not opposed to removing the unit types from the new property names as long the property names are NOT quota and quotaused -- using quota and quotaused would break Apple's existing server and client implementations. Existing Mac OS X clients use quota and quotaused and expect the unit size to be 512-bytes and that's what the Apple iDisk server returns for quota and quotaused. - Jim --Apple-Mail-2--811456326 Content-Type: text/enriched; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thursday, October 24, 2002, at 09:23 AM, Clemm, Geoff wrote: There is a separate question of whether the units should to appear in the property name ... I'd probably leave it off, for uniformity with the rest of HTTP (it is the "Length" header, not the "Octet-Length" header). I like having the unit type in the name because it makes the purpose of the property more self-described. However, I'm not opposed to removing the unit types from the new property names as long the property names are NOT quota and quotaused -- using quota and quotaused would break Apple's existing server and client implementations. Existing Mac OS X clients use quota and quotaused and expect the unit size to be 512-bytes and that's what the Apple iDisk server returns for quota and quotaused. - Jim --Apple-Mail-2--811456326-- From w3c-dist-auth-request@w3.org Thu Oct 24 13:19:04 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16402 for ; Thu, 24 Oct 2002 13:19:03 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9OHKPd20092; Thu, 24 Oct 2002 13:20:25 -0400 (EDT) Resent-Date: Thu, 24 Oct 2002 13:20:25 -0400 (EDT) Resent-Message-Id: <200210241720.g9OHKPd20092@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9OHKJB19912 for ; Thu, 24 Oct 2002 13:20:19 -0400 (EDT) Received: from dream.darwin.nasa.gov (betlik.darwin.nasa.gov [198.123.160.11]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA13377 for ; Thu, 24 Oct 2002 13:20:18 -0400 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 g9OHJrh19516 for ; Thu, 24 Oct 2002 10:19:56 -0700 (PDT) Message-ID: <3DB82BB9.106@cse.ucsc.edu> Date: Thu, 24 Oct 2002 10:19:53 -0700 From: Elias Sinderson Reply-To: "'WebDAV (E-mail)'" User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.4.1) Gecko/20020518 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: "'WebDAV (E-mail)'" References: Content-Type: multipart/alternative; boundary="------------090302080904080907040808" Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6965 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --------------090302080904080907040808 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit We're in agreement then, both WRT the units used and the property name. When I said 'bytes' in my previous message I meant 8-bit bytes, or more specifically octets. Uniformity is a good thing, provided that the documentation is clear and readily available. Elias Clemm, Geoff wrote: > Just to clarify, the proposal I was supporting was to replace > bytes with octets, not to leave the units unspecified. I don't > think anyone wants to leave the units unspecified. There is a > separate question of whether the units should to appear in the > property name ... I'd probably leave it off, for uniformity with > the rest of HTTP (it is the "Length" header, not the "Octet-Length" > header). > --------------090302080904080907040808 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit We're in agreement then, both WRT the units used and the property name. When I said 'bytes' in my previous message I meant 8-bit bytes, or more specifically octets. Uniformity is a good thing, provided that the documentation is clear and readily available.

Elias


Clemm, Geoff wrote:
RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt

Just to clarify, the proposal I was supporting was to replace
bytes with octets, not to leave the units unspecified.  I don't
think anyone wants to leave the units unspecified.  There is a
separate question of whether the units should to appear in the
property name ... I'd probably leave it off, for uniformity with
the rest of HTTP (it is the "Length" header, not the "Octet-Length"
header).


--------------090302080904080907040808-- From w3c-dist-auth-request@w3.org Thu Oct 24 13:20:06 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16493 for ; Thu, 24 Oct 2002 13:20:06 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9OHLGp21400; Thu, 24 Oct 2002 13:21:16 -0400 (EDT) Resent-Date: Thu, 24 Oct 2002 13:21:16 -0400 (EDT) Resent-Message-Id: <200210241721.g9OHLGp21400@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9OHLEB21354 for ; Thu, 24 Oct 2002 13:21:14 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA13975 for ; Thu, 24 Oct 2002 13:21:15 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 24 Oct 2002 13:09:27 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403YJC04>; Thu, 24 Oct 2002 13:20:44 -0400 Message-ID: From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Thu, 24 Oct 2002 13:20:41 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27B81.ADD4D780" Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6966 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27B81.ADD4D780 Content-Type: text/plain Apple's existing properties should not conflict with DAV:quota or DAV:quotaused, since they shouldn't be in the DAV: namespace (surely Apple would not have defined non-standard properties in the DAV: namespace :-). Cheers, Geoff -----Original Message----- From: Jim Luther [mailto:luther.j@apple.com] Sent: Thursday, October 24, 2002 12:43 PM To: w3c-dist-auth@w3.org Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt On Thursday, October 24, 2002, at 09:23 AM, Clemm, Geoff wrote: There is a separate question of whether the units should to appear in the property name ... I'd probably leave it off, for uniformity with the rest of HTTP (it is the "Length" header, not the "Octet-Length" header). I like having the unit type in the name because it makes the purpose of the property more self-described. However, I'm not opposed to removing the unit types from the new property names as long the property names are NOT quota and quotaused -- using quota and quotaused would break Apple's existing server and client implementations. Existing Mac OS X clients use quota and quotaused and expect the unit size to be 512-bytes and that's what the Apple iDisk server returns for quota and quotaused. - Jim ------_=_NextPart_001_01C27B81.ADD4D780 Content-Type: text/html
Apple's existing properties should not conflict with DAV:quota or DAV:quotaused, since they shouldn't be in the DAV: namespace (surely Apple would not have defined non-standard properties in the DAV: namespace :-).
 
Cheers,
Geoff 
-----Original Message-----
From: Jim Luther [mailto:luther.j@apple.com]
Sent: Thursday, October 24, 2002 12:43 PM
To: w3c-dist-auth@w3.org
Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt

On Thursday, October 24, 2002, at 09:23 AM, Clemm, Geoff wrote:


There is a

separate question of whether the units should to appear in the

property name ... I'd probably leave it off, for uniformity with

the rest of HTTP (it is the "Length" header, not the "Octet-Length"

header).


I like having the unit type in the name because it makes the purpose of the property more self-described.


However, I'm not opposed to removing the unit types from the new property names as long the property names are NOT quota and quotaused -- using quota and quotaused would break Apple's existing server and client implementations. Existing Mac OS X clients use quota and quotaused and expect the unit size to be 512-bytes and that's what the Apple iDisk server returns for quota and quotaused.


- Jim

------_=_NextPart_001_01C27B81.ADD4D780-- From w3c-dist-auth-request@w3.org Thu Oct 24 13:24:29 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16685 for ; Thu, 24 Oct 2002 13:24:29 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9OHPrH25015; Thu, 24 Oct 2002 13:25:53 -0400 (EDT) Resent-Date: Thu, 24 Oct 2002 13:25:53 -0400 (EDT) Resent-Message-Id: <200210241725.g9OHPrH25015@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9OHPpB24988 for ; Thu, 24 Oct 2002 13:25:51 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA16578 for ; Thu, 24 Oct 2002 13:25:50 -0400 Received: (qmail 5227 invoked by uid 0); 24 Oct 2002 17:25:19 -0000 Received: from p3ee24728.dip.t-dialin.net (HELO lisa) (62.226.71.40) by mail.gmx.net (mp015-rz3) with SMTP; 24 Oct 2002 17:25:19 -0000 From: "Julian Reschke" To: "Jim Luther" , Date: Thu, 24 Oct 2002 19:25:18 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6967 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Jim Luther > Sent: Thursday, October 24, 2002 6:43 PM > To: w3c-dist-auth@w3.org > Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > On Thursday, October 24, 2002, at 09:23 AM, Clemm, Geoff wrote: > > > There is a > separate question of whether the units should to appear in the > property name ... I'd probably leave it off, for uniformity with > the rest of HTTP (it is the "Length" header, not the "Octet-Length" > header). > > > I like having the unit type in the name because it makes the purpose of the > property more self-described. > > However, I'm not opposed to removing the unit types from the new property > names as long the property names are NOT quota and quotaused -- > using quota > and quotaused would break Apple's existing server and client > implementations. Existing Mac OS X clients use quota and quotaused and > expect the unit size to be 512-bytes and that's what the Apple > iDisk server > returns for quota and quotaused. Well. WebDAV properties are identified using namespaces. Just do not add properties in namespaces you don't control. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Oct 24 13:30:32 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA16817 for ; Thu, 24 Oct 2002 13:30:32 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9OHW4826708; Thu, 24 Oct 2002 13:32:04 -0400 (EDT) Resent-Date: Thu, 24 Oct 2002 13:32:04 -0400 (EDT) Resent-Message-Id: <200210241732.g9OHW4826708@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9OHW2B26677 for ; Thu, 24 Oct 2002 13:32:02 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id NAA19945 for ; Thu, 24 Oct 2002 13:32:01 -0400 Received: (qmail 23195 invoked by uid 0); 24 Oct 2002 17:31:30 -0000 Received: from p3ee24728.dip.t-dialin.net (HELO lisa) (62.226.71.40) by mail.gmx.net (mp013-rz3) with SMTP; 24 Oct 2002 17:31:30 -0000 From: "Julian Reschke" To: Date: Thu, 24 Oct 2002 19:31:29 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6968 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Here's a proposal for the property names that reduces property clutter (by collapsing evrything into a single property) and possibly allows expressing multiple quota constraints: ... ... .... .... .. The syntax is similar to lockdiscovery, so any self-respecting DAV client should be able to handle this. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Oct 24 14:20:31 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA18441 for ; Thu, 24 Oct 2002 14:20:31 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9OILu203861; Thu, 24 Oct 2002 14:21:56 -0400 (EDT) Resent-Date: Thu, 24 Oct 2002 14:21:56 -0400 (EDT) Resent-Message-Id: <200210241821.g9OILu203861@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9OILtB03835 for ; Thu, 24 Oct 2002 14:21:55 -0400 (EDT) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA00632 for ; Thu, 24 Oct 2002 14:21:54 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 184mcF-0005BV-00; Thu, 24 Oct 2002 18:21:55 +0000 Received: from [216.36.77.241] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 184mcE-0005BK-00; Thu, 24 Oct 2002 18:21:54 +0000 From: "Lisa Dusseault" To: "'Julian Reschke'" , Date: Thu, 24 Oct 2002 11:21:41 -0700 Message-ID: <000401c27b8a$3345a220$b701a8c0@xythoslap> 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.3416 Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Old-X-Envelope-To: julian.reschke@gmx.de, w3c-dist-auth@w3c.org Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6969 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Why do you think this is preferable for the client? Why not keep single-property, single-value? This complicates things even for the server. lisa > -----Original Message----- > From: Julian Reschke [mailto:julian.reschke@gmx.de] > Sent: Thursday, October 24, 2002 10:31 AM > To: w3c-dist-auth@w3c.org > Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > Here's a proposal for the property names that reduces property clutter (by > collapsing evrything into a single property) and possibly allows > expressing > multiple quota constraints: > > > > > > ... > ... > > > .... > > > .... > > > > > .. > > > > The syntax is similar to lockdiscovery, so any self-respecting DAV client > should be able to handle this. > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Thu Oct 24 14:34:38 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19005 for ; Thu, 24 Oct 2002 14:34:37 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9OIZpE05712; Thu, 24 Oct 2002 14:35:51 -0400 (EDT) Resent-Date: Thu, 24 Oct 2002 14:35:51 -0400 (EDT) Resent-Message-Id: <200210241835.g9OIZpE05712@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9OIZoB05686 for ; Thu, 24 Oct 2002 14:35:50 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id OAA04762 for ; Thu, 24 Oct 2002 14:35:49 -0400 Received: (qmail 579 invoked by uid 0); 24 Oct 2002 18:35:18 -0000 Received: from p3ee24728.dip.t-dialin.net (HELO lisa) (62.226.71.40) by mail.gmx.net (mp005-rz3) with SMTP; 24 Oct 2002 18:35:18 -0000 From: "Julian Reschke" To: "Lisa Dusseault" , "'Julian Reschke'" , Date: Thu, 24 Oct 2002 20:35:17 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <000401c27b8a$3345a220$b701a8c0@xythoslap> Importance: Normal Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6970 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > Sent: Thursday, October 24, 2002 8:22 PM > To: 'Julian Reschke'; w3c-dist-auth@w3c.org > Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > > Why do you think this is preferable for the client? Why not keep It allows marshalling of multiple quota constraints (and we know that there may be more than one). > single-property, single-value? This complicates things even for the > server. Why? For a server that enforces only a single constraint, it's just a few more XML tags to add. Where's the problem? Confused, Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Oct 24 14:59:49 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA19847 for ; Thu, 24 Oct 2002 14:59:49 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9OJ19J11580; Thu, 24 Oct 2002 15:01:09 -0400 (EDT) Resent-Date: Thu, 24 Oct 2002 15:01:09 -0400 (EDT) Resent-Message-Id: <200210241901.g9OJ19J11580@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9OJ17B11554 for ; Thu, 24 Oct 2002 15:01:07 -0400 (EDT) Received: from mail-out2.apple.com (mail-out2.apple.com [17.254.0.51]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id PAA11594 for ; Thu, 24 Oct 2002 15:01:07 -0400 Received: from mailgate1.apple.com (A17-128-100-225.apple.com [17.128.100.225]) by mail-out2.apple.com (8.11.3/8.11.3) with ESMTP id g9OJ17I27902 for ; Thu, 24 Oct 2002 12:01:07 -0700 (PDT) Received: from scv1.apple.com (scv1.apple.com) by mailgate1.apple.com (Content Technologies SMTPRS 4.2.5) with ESMTP id for ; Thu, 24 Oct 2002 12:00:53 -0700 Received: from apple.com (luthji.apple.com [17.202.43.76]) by scv1.apple.com (8.11.3/8.11.3) with ESMTP id g9OJ16H04303 for ; Thu, 24 Oct 2002 12:01:06 -0700 (PDT) Date: Thu, 24 Oct 2002 12:01:05 -0700 Content-Type: text/plain; delsp=yes; charset=ISO-8859-1; format=flowed Mime-Version: 1.0 (Apple Message framework v546) From: Jim Luther To: w3c-dist-auth@w3.org In-Reply-To: Message-Id: X-Mailer: Apple Mail (2.546) Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by frink.w3.org id g9OJ17B11554 Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6971 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit On Thursday, October 24, 2002, at 10:20 AM, Clemm, Geoff wrote: > Apple's existing properties should not conflict with DAV:quota or > DAV:quotaused, since they shouldn't be in the DAV: namespace (surely > Apple would not have defined non-standard properties in the DAV: > namespace :-). On Thursday, October 24, 2002, at 10:25 AM, Julian Reschke wrote: > WebDAV properties are identified using namespaces. Just do not add > properties in namespaces you don't control. Surely I wouldn't do that (because I've read the RFC and understand how to add non-standard properties to a namespace Apple owns -- for example, http://www.apple.com/webdav_fs/props/). However, Apple had already shipped products using non-standard properties in the DAV: namespace before I had anything to do with WebDAV. I asked Lisa to revive the "Quota and Size Properties for DAV Collections" draft because: (a) I think quotas are useful and (b) I knew that Apple had done the wrong thing by using quota and quotaused in the DAV: namespace and I want to correct that problem as quickly as possible. So... I'm asking forgiveness and asking that the new names don't conflict with those Apple already uses. As I noted in an earlier message, we fully plan to support the new properties as soon as it looks like they are fully defined and won't change. By the way, you'll find the same problem with the non-standard properties defined by Microsoft including DAV:ishidden which has been recently discussed on this mailing list [1]. Does anyone else have any non-standard properties in the DAV: namespace to pull out of their closets? It would be nice to know about them now rather than later when there's a conflict. - Jim [1] and From w3c-dist-auth-request@w3.org Thu Oct 24 15:16:10 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA20322 for ; Thu, 24 Oct 2002 15:16:10 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9OJHLi13714; Thu, 24 Oct 2002 15:17:21 -0400 (EDT) Resent-Date: Thu, 24 Oct 2002 15:17:21 -0400 (EDT) Resent-Message-Id: <200210241917.g9OJHLi13714@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9OJHJB13684 for ; Thu, 24 Oct 2002 15:17:19 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id PAA15592 for ; Thu, 24 Oct 2002 15:17:19 -0400 Received: (qmail 11711 invoked by uid 0); 24 Oct 2002 19:16:48 -0000 Received: from p3ee24728.dip.t-dialin.net (HELO lisa) (62.226.71.40) by mail.gmx.net (mp016-rz3) with SMTP; 24 Oct 2002 19:16:48 -0000 From: "Julian Reschke" To: "Jim Luther" , Date: Thu, 24 Oct 2002 21:16:46 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit 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.1106 In-Reply-To: Importance: Normal Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6972 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 8bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Luther > Sent: Thursday, October 24, 2002 9:01 PM > To: w3c-dist-auth@w3.org > Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > > On Thursday, October 24, 2002, at 10:20 AM, Clemm, Geoff wrote: > > > Apple's existing properties should not conflict with DAV:quota or > > DAV:quotaused, since they shouldn't be in the DAV: namespace (surely > > Apple would not have defined non-standard properties in the DAV: > > namespace :-). > > On Thursday, October 24, 2002, at 10:25 AM, Julian Reschke wrote: > > > WebDAV properties are identified using namespaces. Just do not add > > properties in namespaces you don't control. > > Surely I wouldn't do that (because I've read the RFC and understand how Jim, I didn't want to imply that it was you who did that. But obviously somebody else did :-) > to add non-standard properties to a namespace Apple owns -- for > example, http://www.apple.com/webdav_fs/props/). However, Apple had > already shipped products using non-standard properties in the DAV: > namespace before I had anything to do with WebDAV. > > I asked Lisa to revive the "Quota and Size Properties for DAV > Collections" draft because: > (a) I think quotas are useful and > (b) I knew that Apple had done the wrong thing by using quota and > quotaused in the DAV: namespace and I want to correct that problem as > quickly as possible. That's a good thing. > So... I'm asking forgiveness and asking that the new names don't > conflict with those Apple already uses. As I noted in an earlier > message, we fully plan to support the new properties as soon as it > looks like they are fully defined and won't change. > > By the way, you'll find the same problem with the non-standard > properties defined by Microsoft including DAV:ishidden which has been > recently discussed on this mailing list [1]. Yes. There are many more in use (or actually not in use, but appearing in PROPFIND requests) at Microsoft. But that shouldn't be an excuse to copy this behaviour. BTW: DAV:ishidden was documented in an Internet Draft that at some point wasn't updated and therefore expired. It probably was intended to be published as WG RFC at a later point of time. Lesson: do not use the DAV: namespace in Internet Drafts, unless they are WebDAV working group drafts (hint hint). [1] > ... Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Oct 24 16:19:07 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA21946 for ; Thu, 24 Oct 2002 16:19:07 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9OKK4X19983; Thu, 24 Oct 2002 16:20:04 -0400 (EDT) Resent-Date: Thu, 24 Oct 2002 16:20:04 -0400 (EDT) Resent-Message-Id: <200210242020.g9OKK4X19983@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9OKK2B19955 for ; Thu, 24 Oct 2002 16:20:02 -0400 (EDT) Received: from ucsc.edu (cats-mx1.ucsc.edu [128.114.129.36]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA29641 for ; Thu, 24 Oct 2002 16:20:02 -0400 Received: from Tycho (dhcp-55-196.cse.ucsc.edu [128.114.55.196]) by ucsc.edu (8.10.1/8.10.1) with SMTP id g9OKJ6828321 for ; Thu, 24 Oct 2002 13:19:06 -0700 (PDT) From: "Jim Whitehead" To: "WebDAV" Date: Thu, 24 Oct 2002 13:16:03 -0700 Message-ID: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_NextPart_000_00B3_01C27B5F.81226620" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400 Importance: Normal X-UCSC-CATS-MailScanner: Found to be clean Subject: FW: text conferencing at the 55th IETF meeting in Atlanta Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6973 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_00B3_01C27B5F.81226620 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit This looks like a useful technology to employ at the Atlanta meeting. - Jim -----Original Message----- From: owner-wgchairs@ietf.org [mailto:owner-wgchairs@ietf.org]On Behalf Of Marshall Rose Sent: Tuesday, October 22, 2002 5:02 PM To: wgchairs@ietf.org; bofchairs@ietf.org; iesg@ietf.org Subject: text conferencing at the 55th IETF meeting in Atlanta hi. attached you will find a file describing how to do text conferencing at the 55th IETF meeting in Atlanta. comments welcome. i suggest that this email get sent to the ietf-announce mailing list after the agenda is finalized. Enjoy, /mtr ------=_NextPart_000_00B3_01C27B5F.81226620 Content-Type: text/plain; name="text-conferencing.txt" Content-Disposition: attachment; filename="text-conferencing.txt" Content-Transfer-Encoding: 7bit Remote Access for the 55th IETF meeting in Atlanta: Text Conferencing At each IETF meeting, two of the working group meeting rooms are equipped for video multicast and remote participation. That is, for every IETF meeting slot, two of the working groups can see and hear the meeting. For the 55th IETF, in *addition* to the usual network A/V, text conferencing will be provided for every working group that meets. All of the conference rooms will be hosted on conference.ietf.jabber.com and each is named using the official IETF abbreviation found in the agenda (e.g., "apparea", "dhc", "forces", and so on -- for all the examples that follow, we'll use "foobar" as the abbreviation). Each conference room also has a 'bot which records everything that gets sent. So, the minute taker can review this information right after the meeting. 1. Before the meeting: 1.1. If you want to participate If you don't already have one, get yourself a Jabber client, here are some suggestions: platform suggestion -------- ---------- win32 http://exodus.jabberstudio.org 'nix http://gabber.sf.net macos http://jabberfox.sf.net When you start the client for the first time, it will eventually ask if you want to register on a public server. Go ahead and do that. If you want to find out more, instead of choosing these defaults, here are pointers to some additional information: list of clients: http://www.jabber.org/user/clientlist.php howto: http://www.jabber.org/user/userguide/ server list: http://www.jabber.org/user/publicservers.php To make sure everything is running ok, do a "Join Group Chat" with your Jabber client: Group/Room: testing Server: conference.ietf.jabber.com This conference room is up and running right now (although probably no one will be in it when you connect). 1.2. What the Chair does If you want to make text conferencing available, you'll need to have a volunteer scribe in the meeting room. The scribe will be typing in a running commentary as to what's going on in the room (who's presenting, what question is being asked, etc.) So, why not send an email out on the mailing list now, before the meeting, to ask for volunteers? 2. At the meeting 2.1. What the Chair does When a session starts, the chair asks if someone in the room is willing to act as "scribe". If no one volunteers, read no further, we're done! Otherwise, the scribe should do a "Join Group Chat" with their Jabber client, e.g., Group/Room: foobar Server: conference.ietf.jabber.com 2.2. What the Scribe does The scribe types in a running commentary as to what's going on in the room. For example, if a speaker makes a presentation, the scribe types in the URL for the presentation (more on this in a bit). Simlarly, during question time, a remote participant can type a question into the room and the scribe can pass it on to the speaker. 2.3. What each Presenter does Each presenter should put a copy of their presentation on a web server somewhere, so remote participants can follow along. If you don't have a server available, email your presentation to To: presentations@ietf.org Subject: foobar and the Secretariat will put the presentation in a server so it can be accessed under: http://atlanta.ietf.org/presentations/foobar/ Don't wait until the last minute to send the email. 2.4. Where to find the conference log http://www.jabber.com/chatbot/logs/conference.ietf.jabber.com/foobar/ (Note: these URLs won't be active until just before the meeting starts!) 2.5. Finally This is an experiment. Let's see how well it works and discuss it after the meeting. ####### ------=_NextPart_000_00B3_01C27B5F.81226620-- From w3c-dist-auth-request@w3.org Thu Oct 24 16:37:27 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA22483 for ; Thu, 24 Oct 2002 16:37:26 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9OKc3021310; Thu, 24 Oct 2002 16:38:03 -0400 (EDT) Resent-Date: Thu, 24 Oct 2002 16:38:03 -0400 (EDT) Resent-Message-Id: <200210242038.g9OKc3021310@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9OKc2B21280 for ; Thu, 24 Oct 2002 16:38:02 -0400 (EDT) Received: from mail.xythos.com (sdsl-216-36-77-241.dsl.sjc.megapath.net [216.36.77.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA00417 for ; Thu, 24 Oct 2002 16:38:01 -0400 Received: from ravms by mail.xythos.com with mail-ok (Exim 3.36 #3) id 184ok0-0006oh-00 for w3c-dist-auth@w3.org; Thu, 24 Oct 2002 20:38:04 +0000 Received: from [216.36.77.241] (helo=xythoslap) by mail.xythos.com with asmtp (Exim 3.36 #3) id 184ok0-0006oW-00 for w3c-dist-auth@w3.org; Thu, 24 Oct 2002 20:38:04 +0000 From: "Lisa Dusseault" To: "'WebDAV \(E-mail\)'" Date: Thu, 24 Oct 2002 13:37:49 -0700 Message-ID: <000e01c27b9d$37bf21b0$b701a8c0@xythoslap> 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.3416 Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000 Old-X-Envelope-To: w3c-dist-auth@w3.org Subject: FW: Protocol Action: Internationalizing Domain Names In Applications (IDNA) to Proposed Standard Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6974 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit FYI -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Thursday, October 24, 2002 11:51 AM Cc: RFC Editor; Internet Architecture Board; idn@ops.ietf.org Subject: Protocol Action: Internationalizing Domain Names In Applications (IDNA) to Proposed Standard The IESG has approved publication of the following Internet-Drafts as Proposed Standards: o Internationalizing Domain Names In Applications (IDNA) as a Proposed Standard. o Nameprep: A Stringprep Profile for Internationalized Domain Names o Punycode: An encoding of Unocode for use with IDNA These documents are the product of the Internationalized Domain Name Working Group. The IESG contact persons are Erik Nordmark and Thomas Narten. Technical Summary This set documents provide the pieces of the IDNA architecture. They consist of the IDNA document itself, a stringprep profile for domain name labels (nameprep), and an encoding of Unicode strings into letter-digit-hyphen ASCII strings (punycode). These documents provide a mechanism to introduce Internationalized Domain Names without requiring any changes in the DNS itself; the IDN labels which contain non-ASCII characters are represented in the DNS using the ASCII compatible encoding (ACE) called Punycode. This representation can also be used when domain names are carried in IDN-unaware application protocols. Applications use the convertion routines specified in the IDNA document for coverting in both directions between the Unicode version of IDNs and the ACE versions of the IDNs. Working Group Summary The working group resolved some major comments in response to the IETF last call (plus minor and editorial comments). The major comments where - change from using Unicode 3.1 to 3.2 - added restrictions for bidirectional characters - making the applicability of IDNA more clear by adding an applicability section to the IDNA document. There was WG rough concensus to advance these document. Protocol Quality This document has been reviewed for the IESG by Erik Nordmark. From w3c-dist-auth-request@w3.org Fri Oct 25 04:29:41 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16011 for ; Fri, 25 Oct 2002 04:29:40 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9P8Uuc15644; Fri, 25 Oct 2002 04:30:56 -0400 (EDT) Resent-Date: Fri, 25 Oct 2002 04:30:56 -0400 (EDT) Resent-Message-Id: <200210250830.g9P8Uuc15644@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9P8UsB15618 for ; Fri, 25 Oct 2002 04:30:55 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA26303 for ; Fri, 25 Oct 2002 04:30:53 -0400 Received: from greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Fri, 25 Oct 2002 10:30:41 +0200 Date: Fri, 25 Oct 2002 10:30:43 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "Lisa Dusseault" , To: "Julian Reschke" From: Stefan Eissing In-Reply-To: Message-Id: <0D83F6C1-E7F4-11D6-9950-00039384827E@greenbytes.de> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6975 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think it's not a good idea to report information about "all" quota spaces in a resource: - the resource might not know all quotas on the server - you need additional information which quota applies to the current resource Since the reported set is likely to be incomplete (and or expensive to compute), I think only one quote should be reported. However, I do think that there is benefit in having one quota-xxx property which has a XML structured value. That makes it easy to extend in the future. //Stefan Am Donnerstag, 24.10.02, um 20:35 Uhr (Europe/Berlin) schrieb Julian Reschke: > >> From: w3c-dist-auth-request@w3.org >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault >> Sent: Thursday, October 24, 2002 8:22 PM >> To: 'Julian Reschke'; w3c-dist-auth@w3c.org >> Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt >> >> >> >> Why do you think this is preferable for the client? Why not keep > > It allows marshalling of multiple quota constraints (and we know that > there > may be more than one). > >> single-property, single-value? This complicates things even for the >> server. > > Why? For a server that enforces only a single constraint, it's just a > few > more XML tags to add. Where's the problem? > > Confused, > > Julian > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > From w3c-dist-auth-request@w3.org Fri Oct 25 04:40:09 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16101 for ; Fri, 25 Oct 2002 04:40:08 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9P8fCL16960; Fri, 25 Oct 2002 04:41:12 -0400 (EDT) Resent-Date: Fri, 25 Oct 2002 04:41:12 -0400 (EDT) Resent-Message-Id: <200210250841.g9P8fCL16960@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9P8fBB16933 for ; Fri, 25 Oct 2002 04:41:11 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA28039 for ; Fri, 25 Oct 2002 04:41:10 -0400 Received: (qmail 20964 invoked by uid 0); 25 Oct 2002 08:41:09 -0000 Received: from p3ee24728.dip.t-dialin.net (HELO lisa) (62.226.71.40) by mail.gmx.net (mp013-rz3) with SMTP; 25 Oct 2002 08:41:09 -0000 From: "Julian Reschke" To: "Stefan Eissing" , "Julian Reschke" Cc: "Lisa Dusseault" , Date: Fri, 25 Oct 2002 10:41:06 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <0D83F6C1-E7F4-11D6-9950-00039384827E@greenbytes.de> Importance: Normal Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6976 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing > Sent: Friday, October 25, 2002 10:31 AM > To: Julian Reschke > Cc: Lisa Dusseault; w3c-dist-auth@w3c.org > Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > > I think it's not a good idea to report information about > "all" quota spaces in a resource: So do I. > - the resource might not know all quotas on the server > - you need additional information which quota applies to the > current resource The intent off my proposal to report exactly the quotas that *do* apply to the resource. > Since the reported set is likely to be incomplete (and or expensive > to compute), I think only one quote should be reported. If it only contains the applicable quotas, it shouldn't be harder to compute than a single quota. > However, I do think that there is benefit in having one quota-xxx > property which has a XML structured value. That makes it easy to > extend in the future. > > //Stefan > > Am Donnerstag, 24.10.02, um 20:35 Uhr (Europe/Berlin) schrieb Julian > Reschke: > > > > >> From: w3c-dist-auth-request@w3.org > >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault > >> Sent: Thursday, October 24, 2002 8:22 PM > >> To: 'Julian Reschke'; w3c-dist-auth@w3c.org > >> Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > >> > >> > >> > >> Why do you think this is preferable for the client? Why not keep > > > > It allows marshalling of multiple quota constraints (and we know that > > there > > may be more than one). > > > >> single-property, single-value? This complicates things even for the > >> server. > > > > Why? For a server that enforces only a single constraint, it's just a > > few > > more XML tags to add. Where's the problem? > > > > Confused, > > > > Julian > > > > -- > > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > > > > > > -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Oct 25 04:45:36 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16144 for ; Fri, 25 Oct 2002 04:45:35 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9P8l4L18940; Fri, 25 Oct 2002 04:47:04 -0400 (EDT) Resent-Date: Fri, 25 Oct 2002 04:47:04 -0400 (EDT) Resent-Message-Id: <200210250847.g9P8l4L18940@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9P8l3B18914 for ; Fri, 25 Oct 2002 04:47:03 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA29925 for ; Fri, 25 Oct 2002 04:47:02 -0400 Received: (qmail 2891 invoked by uid 0); 25 Oct 2002 08:46:58 -0000 Received: from p3ee24728.dip.t-dialin.net (HELO lisa) (62.226.71.40) by mail.gmx.net (mp012-rz3) with SMTP; 25 Oct 2002 08:46:58 -0000 From: "Julian Reschke" To: Date: Fri, 25 Oct 2002 10:46:55 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <0D83F6C1-E7F4-11D6-9950-00039384827E@greenbytes.de> Importance: Normal Subject: 507 response code, was: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6977 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit According to HTTP, 5xx class codes are for server errors: "Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. User agents SHOULD display any included entity to the user. These response codes are applicable to any request method. " I'd say that this is ok for a condition like "disk full", but not necessarily for something like "quota exceeded". This is not a server error, it's just an administrative constraint that was enforced. Proposal: define a precondition DAV:quota-not-exceeded, and let the server return 403 or 409. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Oct 25 04:46:52 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16207 for ; Fri, 25 Oct 2002 04:46:52 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9P8mGk19299; Fri, 25 Oct 2002 04:48:16 -0400 (EDT) Resent-Date: Fri, 25 Oct 2002 04:48:16 -0400 (EDT) Resent-Message-Id: <200210250848.g9P8mGk19299@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9P8mFB19270 for ; Fri, 25 Oct 2002 04:48:15 -0400 (EDT) Received: from greenbytes.de (mail.greenbytes.de [217.5.201.10] (may be forged)) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA30203 for ; Fri, 25 Oct 2002 04:48:14 -0400 Received: from greenbytes.de [192.168.1.23] by greenbytes.de [217.5.201.11] with SMTP (MDaemon.v3.5.3.R) for ; Fri, 25 Oct 2002 10:47:39 +0200 Date: Fri, 25 Oct 2002 10:47:41 +0200 Content-Type: text/plain; charset=US-ASCII; format=flowed Mime-Version: 1.0 (Apple Message framework v546) Cc: "Lisa Dusseault" , To: "Julian Reschke" From: Stefan Eissing In-Reply-To: Message-Id: <6BE9E0CE-E7F6-11D6-9950-00039384827E@greenbytes.de> Content-Transfer-Encoding: 7bit X-Mailer: Apple Mail (2.546) X-MDRemoteIP: 192.168.1.23 X-Return-Path: stefan.eissing@greenbytes.de X-MDaemon-Deliver-To: w3c-dist-auth@w3c.org Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6978 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit I think it is a new model that multiple quotas apply to the current user for a single resource. If I understood you wrong and you want to report all quotas for all users, well, I think that can be: - a very long list - not desirable for security/privacy reasons. //Stefan Am Freitag, 25.10.02, um 10:41 Uhr (Europe/Berlin) schrieb Julian Reschke: >> From: w3c-dist-auth-request@w3.org >> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing >> Sent: Friday, October 25, 2002 10:31 AM >> To: Julian Reschke >> Cc: Lisa Dusseault; w3c-dist-auth@w3c.org >> Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt >> >> >> >> I think it's not a good idea to report information about >> "all" quota spaces in a resource: > > So do I. > >> - the resource might not know all quotas on the server >> - you need additional information which quota applies to the >> current resource > > The intent off my proposal to report exactly the quotas that *do* > apply to > the resource. > >> Since the reported set is likely to be incomplete (and or expensive >> to compute), I think only one quote should be reported. > > If it only contains the applicable quotas, it shouldn't be harder to > compute > than a single quota. > >> However, I do think that there is benefit in having one quota-xxx >> property which has a XML structured value. That makes it easy to >> extend in the future. >> >> //Stefan >> >> Am Donnerstag, 24.10.02, um 20:35 Uhr (Europe/Berlin) schrieb Julian >> Reschke: >> >>> >>>> From: w3c-dist-auth-request@w3.org >>>> [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Lisa Dusseault >>>> Sent: Thursday, October 24, 2002 8:22 PM >>>> To: 'Julian Reschke'; w3c-dist-auth@w3c.org >>>> Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt >>>> >>>> >>>> >>>> Why do you think this is preferable for the client? Why not keep >>> >>> It allows marshalling of multiple quota constraints (and we know that >>> there >>> may be more than one). >>> >>>> single-property, single-value? This complicates things even for the >>>> server. >>> >>> Why? For a server that enforces only a single constraint, it's just a >>> few >>> more XML tags to add. Where's the problem? >>> >>> Confused, >>> >>> Julian >>> >>> -- >>> bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 >>> >>> >> >> > > > > -- > bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 > From w3c-dist-auth-request@w3.org Fri Oct 25 04:55:30 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id EAA16321 for ; Fri, 25 Oct 2002 04:55:30 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9P8v2x20489; Fri, 25 Oct 2002 04:57:02 -0400 (EDT) Resent-Date: Fri, 25 Oct 2002 04:57:02 -0400 (EDT) Resent-Message-Id: <200210250857.g9P8v2x20489@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9P8uxB20461 for ; Fri, 25 Oct 2002 04:56:59 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id EAA31978 for ; Fri, 25 Oct 2002 04:56:59 -0400 Received: (qmail 21461 invoked by uid 0); 25 Oct 2002 08:56:37 -0000 Received: from p3ee24728.dip.t-dialin.net (HELO lisa) (62.226.71.40) by mail.gmx.net (mp001-rz3) with SMTP; 25 Oct 2002 08:56:37 -0000 From: "Julian Reschke" To: "Stefan Eissing" , "Julian Reschke" Cc: "Lisa Dusseault" , Date: Fri, 25 Oct 2002 10:56:33 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <6BE9E0CE-E7F6-11D6-9950-00039384827E@greenbytes.de> Importance: Normal Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6979 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Stefan Eissing > Sent: Friday, October 25, 2002 10:48 AM > To: Julian Reschke > Cc: Lisa Dusseault; w3c-dist-auth@w3c.org > Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > > I think it is a new model that multiple quotas apply to the current user > for a single resource. It's the BSD model, as far as I understood. In particular, there can be separate quotas on the same device: per user and per group. If we can only signal one of these quota, the server would have to choose between - hiding one (making the one that was reported inaccurate) or - computing a summary that describes both quotas (how do you do that?) > If I understood you wrong and you want to report all quotas for all > users, well, I think that can be: > - a very long list > - not desirable for security/privacy reasons. No, that was not the intent of the proposal. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Fri Oct 25 07:56:13 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA21409 for ; Fri, 25 Oct 2002 07:56:13 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9PBuZS19239; Fri, 25 Oct 2002 07:56:35 -0400 (EDT) Resent-Date: Fri, 25 Oct 2002 07:56:35 -0400 (EDT) Resent-Message-Id: <200210251156.g9PBuZS19239@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9PBuYB19211 for ; Fri, 25 Oct 2002 07:56:34 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA04184 for ; Fri, 25 Oct 2002 07:56:34 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 25 Oct 2002 07:44:44 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403YKV9N>; Fri, 25 Oct 2002 07:56:03 -0400 Message-ID: From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Fri, 25 Oct 2002 07:56:02 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27C1D.7DB51370" Subject: RE: 507 response code, was: I-D ACTION:draft-dusseault-dav-quota- 01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6980 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27C1D.7DB51370 Content-Type: text/plain I agree with Julian. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Friday, October 25, 2002 4:47 AM To: w3c-dist-auth@w3c.org Subject: 507 response code, was: I-D ACTION:draft-dusseault-dav-quota-01.txt According to HTTP, 5xx class codes are for server errors: "Response status codes beginning with the digit "5" indicate cases in which the server is aware that it has erred or is incapable of performing the request. Except when responding to a HEAD request, the server SHOULD include an entity containing an explanation of the error situation, and whether it is a temporary or permanent condition. User agents SHOULD display any included entity to the user. These response codes are applicable to any request method. " I'd say that this is ok for a condition like "disk full", but not necessarily for something like "quota exceeded". This is not a server error, it's just an administrative constraint that was enforced. Proposal: define a precondition DAV:quota-not-exceeded, and let the server return 403 or 409. Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 ------_=_NextPart_001_01C27C1D.7DB51370 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: 507 response code, was: I-D = ACTION:draft-dusseault-dav-quota-01.txt

I agree with Julian.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]<= /FONT>
Sent: Friday, October 25, 2002 4:47 AM
To: w3c-dist-auth@w3c.org
Subject: 507 response code, was: I-D
ACTION:draft-dusseault-dav-quota-01.txt



According to HTTP, 5xx class codes are for server = errors:

"Response status codes beginning with the digit = "5" indicate cases in which
the server is aware that it has erred or is = incapable of performing the
request. Except when responding to a HEAD request, = the server SHOULD include
an entity containing an explanation of the error = situation, and whether it
is a temporary or permanent condition. User agents = SHOULD display any
included entity to the user. These response codes = are applicable to any
request method. "

I'd say that this is ok for a condition like = "disk full", but not
necessarily for something like "quota = exceeded". This is not a server error,
it's just an administrative constraint that was = enforced.

Proposal: define a precondition = DAV:quota-not-exceeded, and let the server
return 403 or 409.

Julian

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

------_=_NextPart_001_01C27C1D.7DB51370-- From w3c-dist-auth-request@w3.org Fri Oct 25 16:45:59 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11112 for ; Fri, 25 Oct 2002 16:45:58 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9PKlJ405946; Fri, 25 Oct 2002 16:47:19 -0400 (EDT) Resent-Date: Fri, 25 Oct 2002 16:47:19 -0400 (EDT) Resent-Message-Id: <200210252047.g9PKlJ405946@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9PKlIB05920 for ; Fri, 25 Oct 2002 16:47:18 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA25837 for ; Fri, 25 Oct 2002 16:47:17 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 25 Oct 2002 16:34:56 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403YL7YY>; Fri, 25 Oct 2002 16:46:16 -0400 Message-ID: From: "Clemm, Geoff" To: "DeltaV (E-mail)" , w3c-dist-auth@w3c.org Date: Fri, 25 Oct 2002 16:46:14 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27C67.8F6E9560" Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6981 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27C67.8F6E9560 Content-Type: text/plain It looks like we have finally narrowed down this thread to one issue for 3253, which I've added as 14.4_CLARIFY_VH_DELETE_2 (i.e. can you delete the stable binding to a version history or version, if there are other bindings). Any discussion of 14.4_CLARIFY_VH_DELETE_2 should be mailed to the deltav mailing list, not to the general webdav mailing list. For the binding spec, Julian asks for two new preconditions for BIND, which I will go ahead and add, unless someone objects (they both seem reasonable to me). Any discussion of these two new preconditions for BIND should be mailed to the general webdav mailing list. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] ... The issue here is that if we allow a DELETE to fail because other bindings exist, a client may never be able to delete a binding (because due to race conditions, there will always be additional bindings left). I'm not saying that this can be avoided, however it *really* sounds ugly. As I said, I haven't seen a convincing argument why we need this restriction in RFC3253 (and yes, this discussion should be moved to the other mailing list). > Can we agree that servers can reject DELETE/MOVE requests and move the > versioning specific discussion to the versioning mailing list? Yes. Still, we may have to define additional precondition values for - resource does not support additional bindings - new member name can't be used (in deltav: because it was already used for a stable URI) Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 ------_=_NextPart_001_01C27C67.8F6E9560 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: BIND vs. non-movable resources in RFC3253

It looks like we have finally narrowed down this = thread to
one issue for 3253, which I've added as = 14.4_CLARIFY_VH_DELETE_2
(i.e. can you delete the stable binding to a version = history
or version, if there are other bindings).  Any = discussion of
14.4_CLARIFY_VH_DELETE_2 should be mailed to the = deltav mailing
list, not to the general webdav mailing list.

For the binding spec, Julian asks for two new = preconditions
for BIND, which I will go ahead and add, unless = someone objects
(they both seem reasonable to me).  Any = discussion of these two
new preconditions for BIND should be mailed to the = general
webdav mailing list.

Cheers,
Geoff
 

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]<= /FONT>

...
The issue here is that if we allow a DELETE to fail = because other bindings
exist, a client may never be able to delete a = binding (because due to race
conditions, there will always be additional bindings = left). I'm not saying
that this can be avoided, however it *really* sounds = ugly. As I said, I
haven't seen a convincing argument why we need this = restriction in RFC3253
(and yes, this discussion should be moved to the = other mailing list).

> Can we agree that servers can reject DELETE/MOVE = requests and move the
> versioning specific discussion to the = versioning mailing list?

Yes. Still, we may have to define additional = precondition values for

- resource does not support additional = bindings
- new member name can't be used (in deltav: because = it was already used for
a stable URI)

Julian

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

------_=_NextPart_001_01C27C67.8F6E9560-- From w3c-dist-auth-request@w3.org Fri Oct 25 16:54:05 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA11482 for ; Fri, 25 Oct 2002 16:54:05 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9PKtMA07115; Fri, 25 Oct 2002 16:55:22 -0400 (EDT) Resent-Date: Fri, 25 Oct 2002 16:55:22 -0400 (EDT) Resent-Message-Id: <200210252055.g9PKtMA07115@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9PKtLB07057 for ; Fri, 25 Oct 2002 16:55:21 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id QAA27516 for ; Fri, 25 Oct 2002 16:55:20 -0400 Received: (qmail 27477 invoked by uid 0); 25 Oct 2002 20:54:48 -0000 Received: from pd950c242.dip.t-dialin.net (HELO lisa) (217.80.194.66) by mail.gmx.net (mp020-rz3) with SMTP; 25 Oct 2002 20:54:48 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , "DeltaV \(E-mail\)" , Date: Fri, 25 Oct 2002 22:54:46 +0200 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C27C79.83F2F520" X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6982 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C27C79.83F2F520 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: BIND vs. non-movable resources in RFC3253Geoff, thanks. I think I've got at least one other precondition: DAV:bind-loops-allowed (explanation: we don't want the server to produce a 5xx error code for this case) -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff Sent: Friday, October 25, 2002 10:46 PM To: DeltaV (E-mail); w3c-dist-auth@w3c.org Subject: RE: BIND vs. non-movable resources in RFC3253 It looks like we have finally narrowed down this thread to one issue for 3253, which I've added as 14.4_CLARIFY_VH_DELETE_2 (i.e. can you delete the stable binding to a version history or version, if there are other bindings). Any discussion of 14.4_CLARIFY_VH_DELETE_2 should be mailed to the deltav mailing list, not to the general webdav mailing list. For the binding spec, Julian asks for two new preconditions for BIND, which I will go ahead and add, unless someone objects (they both seem reasonable to me). Any discussion of these two new preconditions for BIND should be mailed to the general webdav mailing list. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] ... The issue here is that if we allow a DELETE to fail because other bindings exist, a client may never be able to delete a binding (because due to race conditions, there will always be additional bindings left). I'm not saying that this can be avoided, however it *really* sounds ugly. As I said, I haven't seen a convincing argument why we need this restriction in RFC3253 (and yes, this discussion should be moved to the other mailing list). > Can we agree that servers can reject DELETE/MOVE requests and move the > versioning specific discussion to the versioning mailing list? Yes. Still, we may have to define additional precondition values for - resource does not support additional bindings - new member name can't be used (in deltav: because it was already used for a stable URI) Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 ------=_NextPart_000_0008_01C27C79.83F2F520 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: BIND vs. non-movable resources in RFC3253
Geoff,
 
thanks. I think I've got at least one other=20 precondition:
 
DAV:bind-loops-allowed
 
(explanation: we don't want the server to produce a 5xx error = code for=20 this case)
 

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

-----Original Message-----
From: = w3c-dist-auth-request@w3.org=20 [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm,=20 Geoff
Sent: Friday, October 25, 2002 10:46 PM
To: = DeltaV=20 (E-mail); w3c-dist-auth@w3c.org
Subject: RE: BIND vs. = non-movable=20 resources in RFC3253

It looks like we have finally narrowed down this = thread=20 to
one issue for 3253, which I've added as=20 14.4_CLARIFY_VH_DELETE_2
(i.e. can you = delete the=20 stable binding to a version history
or = version, if=20 there are other bindings).  Any discussion of
14.4_CLARIFY_VH_DELETE_2 should be mailed to the deltav = mailing=20
list, not to the general webdav mailing = list.

For the binding spec, Julian asks for two new=20 preconditions
for BIND, which I will go = ahead and add,=20 unless someone objects
(they both seem = reasonable to=20 me).  Any discussion of these two
new=20 preconditions for BIND should be mailed to the general =
webdav mailing list.

Cheers,
Geoff =
 

-----Original Message-----
From:=20 Julian Reschke [mailto:julian.reschke@gmx.de]=20

...
The issue here is that = if we allow=20 a DELETE to fail because other bindings
exist, a=20 client may never be able to delete a binding (because due to = race=20
conditions, there will always be additional = bindings left).=20 I'm not saying
that this can be avoided, = however it=20 *really* sounds ugly. As I said, I
haven't = seen a=20 convincing argument why we need this restriction in RFC3253 =
(and yes, this discussion should be moved to the other = mailing=20 list).

> Can we agree that servers can reject = DELETE/MOVE requests=20 and move the
> versioning specific = discussion to=20 the versioning mailing list?

Yes. Still, we may have to define additional = precondition=20 values for

- resource does not support additional = bindings=20
- new member name can't be used (in deltav: because = it was=20 already used for
a stable URI)

Julian

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

------=_NextPart_000_0008_01C27C79.83F2F520-- From w3c-dist-auth-request@w3.org Fri Oct 25 17:20:34 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA12484 for ; Fri, 25 Oct 2002 17:20:34 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9PLLoJ10274; Fri, 25 Oct 2002 17:21:50 -0400 (EDT) Resent-Date: Fri, 25 Oct 2002 17:21:50 -0400 (EDT) Resent-Message-Id: <200210252121.g9PLLoJ10274@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9PLLnB10246 for ; Fri, 25 Oct 2002 17:21:49 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA02242 for ; Fri, 25 Oct 2002 17:21:49 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Fri, 25 Oct 2002 17:08:37 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403YL9XR>; Fri, 25 Oct 2002 17:19:21 -0400 Message-ID: From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Fri, 25 Oct 2002 17:19:17 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27C6C.2CDD7BA0" Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6983 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27C6C.2CDD7BA0 Content-Type: text/plain; charset="iso-8859-1" Note: This precondition actually violates the requirement earlier in the text that a server support cyclic bindings. But probably a server should be allowed to reject cyclic bindings, so I'm happy to add this pre-condition (and remove the current requirement), if nobody objects. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Friday, October 25, 2002 4:55 PM To: Clemm, Geoff; DeltaV (E-mail); w3c-dist-auth@w3c.org Subject: RE: BIND vs. non-movable resources in RFC3253 Geoff, thanks. I think I've got at least one other precondition: DAV:bind-loops-allowed (explanation: we don't want the server to produce a 5xx error code for this case) -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff Sent: Friday, October 25, 2002 10:46 PM To: DeltaV (E-mail); w3c-dist-auth@w3c.org Subject: RE: BIND vs. non-movable resources in RFC3253 It looks like we have finally narrowed down this thread to one issue for 3253, which I've added as 14.4_CLARIFY_VH_DELETE_2 (i.e. can you delete the stable binding to a version history or version, if there are other bindings). Any discussion of 14.4_CLARIFY_VH_DELETE_2 should be mailed to the deltav mailing list, not to the general webdav mailing list. For the binding spec, Julian asks for two new preconditions for BIND, which I will go ahead and add, unless someone objects (they both seem reasonable to me). Any discussion of these two new preconditions for BIND should be mailed to the general webdav mailing list. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] ... The issue here is that if we allow a DELETE to fail because other bindings exist, a client may never be able to delete a binding (because due to race conditions, there will always be additional bindings left). I'm not saying that this can be avoided, however it *really* sounds ugly. As I said, I haven't seen a convincing argument why we need this restriction in RFC3253 (and yes, this discussion should be moved to the other mailing list). > Can we agree that servers can reject DELETE/MOVE requests and move the > versioning specific discussion to the versioning mailing list? Yes. Still, we may have to define additional precondition values for - resource does not support additional bindings - new member name can't be used (in deltav: because it was already used for a stable URI) Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 ------_=_NextPart_001_01C27C6C.2CDD7BA0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: BIND vs. non-movable resources in RFC3253

Note: This precondition actually violates the = requirement
earlier in the text that a server support cyclic = bindings.
But probably a server should be allowed to reject = cyclic
bindings, so I'm happy to add this pre-condition = (and remove
the current requirement), if nobody objects.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]<= /FONT>
Sent: Friday, October 25, 2002 4:55 PM
To: Clemm, Geoff; DeltaV (E-mail); = w3c-dist-auth@w3c.org
Subject: RE: BIND vs. non-movable resources in = RFC3253


Geoff,

thanks. I think I've got at least one other = precondition:

DAV:bind-loops-allowed

(explanation: we don't want the server to produce a = 5xx error code for this case)

--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 =
-----Original Message-----
From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-reques= t@w3.org]On Behalf Of Clemm, Geoff
Sent: Friday, October 25, 2002 10:46 PM
To: DeltaV (E-mail); w3c-dist-auth@w3c.org
Subject: RE: BIND vs. non-movable resources in = RFC3253


It looks like we have finally narrowed down this = thread to
one issue for 3253, which I've added as = 14.4_CLARIFY_VH_DELETE_2
(i.e. can you delete the stable binding to a version = history
or version, if there are other bindings).  Any = discussion of
14.4_CLARIFY_VH_DELETE_2 should be mailed to the = deltav mailing
list, not to the general webdav mailing list. =
For the binding spec, Julian asks for two new = preconditions
for BIND, which I will go ahead and add, unless = someone objects
(they both seem reasonable to me).  Any = discussion of these two
new preconditions for BIND should be mailed to the = general
webdav mailing list.
Cheers,
Geoff
 
-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de] =
...
The issue here is that if we allow a DELETE to fail = because other bindings
exist, a client may never be able to delete a = binding (because due to race
conditions, there will always be additional bindings = left). I'm not saying
that this can be avoided, however it *really* sounds = ugly. As I said, I
haven't seen a convincing argument why we need this = restriction in RFC3253
(and yes, this discussion should be moved to the = other mailing list).
> Can we agree that servers can reject = DELETE/MOVE requests and move the
> versioning specific discussion to the = versioning mailing list?
Yes. Still, we may have to define additional = precondition values for
- resource does not support additional bindings =
- new member name can't be used (in deltav: because = it was already used for
a stable URI)
Julian
--
<green/>bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 =

------_=_NextPart_001_01C27C6C.2CDD7BA0-- From w3c-dist-auth-request@w3.org Sat Oct 26 05:06:16 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id FAA03673 for ; Sat, 26 Oct 2002 05:06:16 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9Q97XN09951; Sat, 26 Oct 2002 05:07:33 -0400 (EDT) Resent-Date: Sat, 26 Oct 2002 05:07:33 -0400 (EDT) Resent-Message-Id: <200210260907.g9Q97XN09951@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9Q97VB09920 for ; Sat, 26 Oct 2002 05:07:32 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id FAA05734 for ; Sat, 26 Oct 2002 05:07:31 -0400 Received: (qmail 962 invoked by uid 0); 26 Oct 2002 09:07:21 -0000 Received: from pd950c242.dip.t-dialin.net (HELO lisa) (217.80.194.66) by mail.gmx.net (mp015-rz3) with SMTP; 26 Oct 2002 09:07:21 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , Date: Sat, 26 Oct 2002 11:07:17 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6984 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Clemm, Geoff > Sent: Friday, October 25, 2002 11:19 PM > To: w3c-dist-auth@w3c.org > Subject: RE: BIND vs. non-movable resources in RFC3253 > > > Note: This precondition actually violates the requirement > earlier in the text that a server support cyclic bindings. I wasn't aware off that being a requirement. I see why a server that *does* support cyclic bindings need to signal them upon depth infinity operations (-> 506), but why would you want to require support for their creation? Actually, I'm tempted to require servers to detect cyclic bindings upon creation and to reject those requests. What's the use case for cyclic bindings? > But probably a server should be allowed to reject cyclic > bindings, so I'm happy to add this pre-condition (and remove > the current requirement), if nobody objects. BTW: this precondition applies to all namespace-manipulating operations (a MOVE of a collection may fail for the same reason). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Oct 26 12:59:41 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09321 for ; Sat, 26 Oct 2002 12:59:41 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9QGxcs27931; Sat, 26 Oct 2002 12:59:38 -0400 (EDT) Resent-Date: Sat, 26 Oct 2002 12:59:38 -0400 (EDT) Resent-Message-Id: <200210261659.g9QGxcs27931@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9QGxaB27905 for ; Sat, 26 Oct 2002 12:59:36 -0400 (EDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id MAA09230 for ; Sat, 26 Oct 2002 12:59:36 -0400 Received: (qmail 16225 invoked by uid 0); 26 Oct 2002 16:59:04 -0000 Received: from p3ee2476c.dip.t-dialin.net (HELO lisa) (62.226.71.108) by mail.gmx.net (mp014-rz3) with SMTP; 26 Oct 2002 16:59:04 -0000 From: "Julian Reschke" To: Date: Sat, 26 Oct 2002 18:59:03 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Importance: Normal Subject: Feedback for allprop/include proposal needed Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6985 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Hi. We recently submitted our internet draft ([1]) to the RFC editor for publication as Informational (non-working-group) RFC. From the abstract: "Recent specifications extending the "Web Distributed Authoring Protocol" (WebDAV, [RFC2518]) like "Versioning Extensions to WebDAV" [RFC3253] and "WebDAV Access Control Protocol" [ACL] restrict the set of properties returned automatically upon a PROPFIND/allprop request in order to avoid the expensive computation of properties that the client in many cases isn't interested in. However, this change from the behaviour defined in WebDAV can lead to situations where clients need to perform two requests to retrieve all properties they are interested in (one using PROPFIND/allprop, then PROPFIND/prop enumerating the new properties that weren't reported upon the first request). This specification defines a backward-compatible extension to add specific properties to the set of properties returned upon PROPFIND/allprop, thus saving at least one PROPFIND request." The proposed solution is to use a backward-compatible extension to the PROPFIND marshalling (old servers if compliant to RFC2518 MUST ignore this element, because it's not define in RFC2518): This instructs the server to return all dead properties, the RFC2518 live properties, and additionally the RFC3253 properties DAV:checked-in and DAV:checked-out. This protocol extension has been implemented in both our client and server for over a year now and solves the issue stated in the abstract for us (when communicating with our own servers, that is). As the Internet Draft has been stable for several months, we feel it is ready for publication as RFC. At this point, we are looking for opinions from the working group about *how* this should proceed in the standards process. I'm aware of the following alternatives: 1) Decide that the problem as stated does not require a generic solution backed by a working group document. In this case, the Internet Draft (after possibly minor editorial changes) should proceed on it's path to publication as Informational RFC (the IETF standards process is defined in RFC2026, [2]). 2) Decide that this problem indeed should be resolved by a change/extension defined by a working group document. 2a) ...for inclusion into RFC2518bis, or 2b) ...to be published as a separate document (probably then as a "proposed standard", as defined in RFC2026, section 4.1.1). Feedback appreciated. Julian [1] [2] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sat Oct 26 22:46:12 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17741 for ; Sat, 26 Oct 2002 22:46:12 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9R2lYn15482; Sat, 26 Oct 2002 22:47:34 -0400 (EDT) Resent-Date: Sat, 26 Oct 2002 22:47:34 -0400 (EDT) Resent-Message-Id: <200210270247.g9R2lYn15482@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9R2lXB15456 for ; Sat, 26 Oct 2002 22:47:33 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id WAA27803 for ; Sat, 26 Oct 2002 22:47:33 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Sat, 26 Oct 2002 22:35:40 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403YM7D4>; Sat, 26 Oct 2002 22:47:02 -0400 Message-ID: From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Sat, 26 Oct 2002 22:47:01 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27D63.205F3560" Subject: RE: Feedback for allprop/include proposal needed Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6986 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27D63.205F3560 Content-Type: text/plain; charset="iso-8859-1" I believe that the allprop/include proposal merits eventually becoming part of the standard WebDAV protocol. I'd support adding it to 2518bis, and when 2518bis is ready to be submitted, if another implementation of this extension is not available to demonstrate interoperability, we could remove it from 2518bis and leave it as its own informational RFC. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Saturday, October 26, 2002 12:59 PM To: w3c-dist-auth@w3c.org Subject: Feedback for allprop/include proposal needed Hi. We recently submitted our internet draft ([1]) to the RFC editor for publication as Informational (non-working-group) RFC. From the abstract: "Recent specifications extending the "Web Distributed Authoring Protocol" (WebDAV, [RFC2518]) like "Versioning Extensions to WebDAV" [RFC3253] and "WebDAV Access Control Protocol" [ACL] restrict the set of properties returned automatically upon a PROPFIND/allprop request in order to avoid the expensive computation of properties that the client in many cases isn't interested in. However, this change from the behaviour defined in WebDAV can lead to situations where clients need to perform two requests to retrieve all properties they are interested in (one using PROPFIND/allprop, then PROPFIND/prop enumerating the new properties that weren't reported upon the first request). This specification defines a backward-compatible extension to add specific properties to the set of properties returned upon PROPFIND/allprop, thus saving at least one PROPFIND request." The proposed solution is to use a backward-compatible extension to the PROPFIND marshalling (old servers if compliant to RFC2518 MUST ignore this element, because it's not define in RFC2518): This instructs the server to return all dead properties, the RFC2518 live properties, and additionally the RFC3253 properties DAV:checked-in and DAV:checked-out. This protocol extension has been implemented in both our client and server for over a year now and solves the issue stated in the abstract for us (when communicating with our own servers, that is). As the Internet Draft has been stable for several months, we feel it is ready for publication as RFC. At this point, we are looking for opinions from the working group about *how* this should proceed in the standards process. I'm aware of the following alternatives: 1) Decide that the problem as stated does not require a generic solution backed by a working group document. In this case, the Internet Draft (after possibly minor editorial changes) should proceed on it's path to publication as Informational RFC (the IETF standards process is defined in RFC2026, [2]). 2) Decide that this problem indeed should be resolved by a change/extension defined by a working group document. 2a) ...for inclusion into RFC2518bis, or 2b) ...to be published as a separate document (probably then as a "proposed standard", as defined in RFC2026, section 4.1.1). Feedback appreciated. Julian [1] [2] -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 ------_=_NextPart_001_01C27D63.205F3560 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Feedback for allprop/include proposal needed

I believe that the allprop/include proposal merits = eventually becoming
part of the standard WebDAV protocol.  I'd = support adding it to 2518bis,
and when 2518bis is ready to be submitted, if = another implementation
of this extension is not available to demonstrate = interoperability,
we could remove it from 2518bis and leave it as its = own informational RFC.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]<= /FONT>
Sent: Saturday, October 26, 2002 12:59 PM
To: w3c-dist-auth@w3c.org
Subject: Feedback for allprop/include proposal = needed



Hi.

We recently submitted our internet draft ([1]) to the = RFC editor for
publication as Informational (non-working-group) = RFC. From the abstract:

"Recent specifications extending the "Web = Distributed Authoring Protocol"
(WebDAV, [RFC2518]) like "Versioning Extensions = to WebDAV" [RFC3253] and
"WebDAV Access Control Protocol" [ACL] = restrict the set of properties
returned automatically upon a PROPFIND/allprop = request in order to avoid the
expensive computation of properties that the client = in many cases isn't
interested in.

However, this change from the behaviour defined in = WebDAV can lead to
situations where clients need to perform two = requests to retrieve all
properties they are interested in (one using = PROPFIND/allprop, then
PROPFIND/prop enumerating the new properties that = weren't reported upon the
first request). This specification defines a = backward-compatible extension
to add specific properties to the set of properties = returned upon
PROPFIND/allprop, thus saving at least one PROPFIND = request."

The proposed solution is to use a backward-compatible = extension to the
PROPFIND marshalling (old servers if compliant to = RFC2518 MUST ignore this
element, because it's not define in RFC2518):


<?xml version=3D"1.0" = encoding=3D"utf-8" ?>
<propfind xmlns=3D"DAV:" = xmlns:in=3D"http://sapportals.com/xmlns/cm/webdav">
  <allprop/>
  <in:include>
    <checked-in/>
    <checked-out/>
  </in:include>
</propfind>

This instructs the server to return all dead = properties, the RFC2518 live
properties, and additionally the RFC3253 properties = DAV:checked-in and
DAV:checked-out.

This protocol extension has been implemented in both = our client and server
for over a year now and solves the issue stated in = the abstract for us (when
communicating with our own servers, that is). As the = Internet Draft has been
stable for several months, we feel it is ready for = publication as RFC.

At this point, we are looking for opinions from the = working group about
*how* this should proceed in the standards process. = I'm aware of the
following alternatives:

1) Decide that the problem as stated does not require = a generic solution
backed by a working group document. In this case, = the Internet Draft (after
possibly minor editorial changes) should proceed on = it's path to publication
as Informational RFC (the IETF standards process is = defined in RFC2026,
[2]).

2) Decide that this problem indeed should be resolved = by a change/extension
defined by a working group document.

2a) ...for inclusion into RFC2518bis, or

2b) ...to be published as a separate document = (probably then as a "proposed
standard", as defined in RFC2026, section = 4.1.1).


Feedback appreciated.

Julian


[1]
<http://greenbytes.de/tech/webdav/draft-reschke-webdav-= allprop-include-02.ht
ml>
[2] <http://www.ietf.org/rfc/rfc2026.txt>

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

------_=_NextPart_001_01C27D63.205F3560-- From w3c-dist-auth-request@w3.org Sat Oct 26 22:59:38 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA17884 for ; Sat, 26 Oct 2002 22:59:38 -0400 (EDT) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9R31Dd16768; Sat, 26 Oct 2002 23:01:13 -0400 (EDT) Resent-Date: Sat, 26 Oct 2002 23:01:13 -0400 (EDT) Resent-Message-Id: <200210270301.g9R31Dd16768@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9R31CB16742 for ; Sat, 26 Oct 2002 23:01:12 -0400 (EDT) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA29800 for ; Sat, 26 Oct 2002 23:01:12 -0400 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Sat, 26 Oct 2002 22:49:19 -0400 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403YM7GV>; Sat, 26 Oct 2002 23:00:41 -0400 Message-ID: From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Sat, 26 Oct 2002 23:00:40 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27D65.082E0DC0" Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6987 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27D65.082E0DC0 Content-Type: text/plain; charset="iso-8859-1" From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: Clemm, Geoff > > Note: This precondition actually violates the requirement > earlier in the text that a server support cyclic bindings. I wasn't aware off that being a requirement. I see why a server that *does* support cyclic bindings need to signal them upon depth infinity operations (-> 506), but why would you want to require support for their creation? Actually, I'm tempted to require servers to detect cyclic bindings upon creation and to reject those requests. What's the use case for cyclic bindings? If you are using bindings to capture some relationship, and that relationship is cyclic, then you can't capture that relationship if you are not allowed to create cyclic bindings. > But probably a server should be allowed to reject cyclic > bindings, so I'm happy to add this pre-condition (and remove > the current requirement), if nobody objects. BTW: this precondition applies to all namespace-manipulating operations (a MOVE of a collection may fail for the same reason). Assuming that the server does not allow you to "move" the root (which no server does), how do you create a cycle with a move operation? Cheers, Geoff ------_=_NextPart_001_01C27D65.082E0DC0 Content-Type: text/html; charset="iso-8859-1" RE: BIND vs. non-movable resources in RFC3253

   From: Julian Reschke [mailto:julian.reschke@gmx.de]

   > From: Clemm, Geoff
   >
   > Note: This precondition actually violates the requirement
   > earlier in the text that a server support cyclic bindings.

   I wasn't aware off that being a requirement. I see why a server
   that *does* support cyclic bindings need to signal them upon depth
   infinity operations (-> 506), but why would you want to require
   support for their creation?

   Actually, I'm tempted to require servers to detect cyclic bindings
   upon creation and to reject those requests. What's the use case for
   cyclic bindings?

If you are using bindings to capture some relationship, and that
relationship is cyclic, then you can't capture that relationship
if you are not allowed to create cyclic bindings.

   > But probably a server should be allowed to reject cyclic
   > bindings, so I'm happy to add this pre-condition (and remove
   > the current requirement), if nobody objects.

   BTW: this precondition applies to all namespace-manipulating
   operations (a MOVE of a collection may fail for the same reason).

Assuming that the server does not allow you to "move" the root
(which no server does), how do you create a cycle with a move
operation?

Cheers,
Geoff

------_=_NextPart_001_01C27D65.082E0DC0-- From w3c-dist-auth-request@w3.org Sun Oct 27 07:53:42 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA03045 for ; Sun, 27 Oct 2002 07:53:42 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9RCknb23841; Sun, 27 Oct 2002 07:46:49 -0500 (EST) Resent-Date: Sun, 27 Oct 2002 07:46:49 -0500 (EST) Resent-Message-Id: <200210271246.g9RCknb23841@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9RCklB23811 for ; Sun, 27 Oct 2002 07:46:47 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id HAA11354 for ; Sun, 27 Oct 2002 07:46:47 -0500 Received: (qmail 9779 invoked by uid 0); 27 Oct 2002 12:46:15 -0000 Received: from p3ee2476c.dip.t-dialin.net (HELO lisa) (62.226.71.108) by mail.gmx.net (mp011-rz3) with SMTP; 27 Oct 2002 12:46:15 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , Date: Sun, 27 Oct 2002 13:46:08 +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.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6988 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Clemm, Geoff > Sent: Sunday, October 27, 2002 4:01 AM > To: w3c-dist-auth@w3c.org > Subject: RE: BIND vs. non-movable resources in RFC3253 > > > From: Julian Reschke [mailto:julian.reschke@gmx.de] > > From: Clemm, Geoff > > > > Note: This precondition actually violates the requirement > > earlier in the text that a server support cyclic bindings. > I wasn't aware off that being a requirement. I see why a server > that *does* support cyclic bindings need to signal them upon depth > infinity operations (-> 506), but why would you want to require > support for their creation? > Actually, I'm tempted to require servers to detect cyclic bindings > upon creation and to reject those requests. What's the use case for > cyclic bindings? > If you are using bindings to capture some relationship, and that > relationship is cyclic, then you can't capture that relationship > if you are not allowed to create cyclic bindings. I'd still feel better if you could give a simple example... > > But probably a server should be allowed to reject cyclic > > bindings, so I'm happy to add this pre-condition (and remove > > the current requirement), if nobody objects. > BTW: this precondition applies to all namespace-manipulating > operations (a MOVE of a collection may fail for the same reason). > Assuming that the server does not allow you to "move" the root > (which no server does), how do you create a cycle with a move > operation? Let /a and /b/c bind to the same collection C. Move /b to /a/b. Result is that both /a and /a/b/c bind to the same collection C. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Oct 27 08:09:09 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03307 for ; Sun, 27 Oct 2002 08:09:09 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9RD35T24538; Sun, 27 Oct 2002 08:03:05 -0500 (EST) Resent-Date: Sun, 27 Oct 2002 08:03:05 -0500 (EST) Resent-Message-Id: <200210271303.g9RD35T24538@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9RD34B24511 for ; Sun, 27 Oct 2002 08:03:04 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id IAA13426 for ; Sun, 27 Oct 2002 08:03:04 -0500 Received: (qmail 12333 invoked by uid 0); 27 Oct 2002 13:02:32 -0000 Received: from p3ee2476c.dip.t-dialin.net (HELO lisa) (62.226.71.108) by mail.gmx.net (mp010-rz3) with SMTP; 27 Oct 2002 13:02:32 -0000 From: "Julian Reschke" To: Date: Sun, 27 Oct 2002 14:02:27 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: Subject: BIND spec, preconditions Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6990 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit Another precondition BIND should specify: DAV:bound-resource-is-mapped: The URL specified by the DAV:href is mapped to a resource. (Explanation: we don't want to return a 404, because that would indicate that the request URL for BIND wasn't mapped). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Sun Oct 27 08:10:55 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA03321 for ; Sun, 27 Oct 2002 08:10:55 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9RCtr224274; Sun, 27 Oct 2002 07:55:53 -0500 (EST) Resent-Date: Sun, 27 Oct 2002 07:55:53 -0500 (EST) Resent-Message-Id: <200210271255.g9RCtr224274@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9RCtrB24228 for ; Sun, 27 Oct 2002 07:55:53 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id HAA12542 for ; Sun, 27 Oct 2002 07:55:52 -0500 Received: (qmail 18949 invoked by uid 0); 27 Oct 2002 12:55:21 -0000 Received: from p3ee2476c.dip.t-dialin.net (HELO lisa) (62.226.71.108) by mail.gmx.net (mp011-rz3) with SMTP; 27 Oct 2002 12:55:21 -0000 From: "Julian Reschke" To: "Jim Luther" , Date: Sun, 27 Oct 2002 13:55:16 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 In-Reply-To: <283C618E-E6E4-11D6-9FDF-0003934B6A22@apple.com> Subject: RE: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6989 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Luther > Sent: Thursday, October 24, 2002 2:04 AM > To: w3c-dist-auth@w3.org > Subject: Re: FW: I-D ACTION:draft-dusseault-dav-quota-01.txt > > > > On Wednesday, October 23, 2002, at 03:01 PM, Julian Reschke wrote: > > > I just did PROPFIND/propname on > > > > http://idisk.mac.com/interop01/ > > > > (doesn't have the properties listed) > > Apple's iDisk and the Mac OS X WebDAV file system implementations were > complete and in use before this document. They use the properties > "quota" and "quotaused" and the values returned by those properties are > in 512-octet units. Connect to iDisk with the Mac OS X client and the > first PROPFIND you see will ask for and receive those properties. > ... Just to clarify: I was mentioning this because propfind/propname does not return any quota-related properties at all. If they are available through propfind/prop, they must show up using propfind/propname as well. Julian From w3c-dist-auth-request@w3.org Mon Oct 28 09:35:48 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA11268 for ; Mon, 28 Oct 2002 09:35:48 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9SEaip11486; Mon, 28 Oct 2002 09:36:44 -0500 (EST) Resent-Date: Mon, 28 Oct 2002 09:36:44 -0500 (EST) Resent-Message-Id: <200210281436.g9SEaip11486@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9SEahB11459 for ; Mon, 28 Oct 2002 09:36:43 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA19040 for ; Mon, 28 Oct 2002 09:36:42 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 28 Oct 2002 09:24:40 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403YN8AD>; Mon, 28 Oct 2002 09:36:06 -0500 Message-ID: From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Mon, 28 Oct 2002 09:36:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27E8F.589702F0" Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6991 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27E8F.589702F0 Content-Type: text/plain; charset="iso-8859-1" From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: Clemm, Geoff > If you are using bindings to capture some relationship, and that > relationship is cyclic, then you can't capture that relationship > if you are not allowed to create cyclic bindings. I'd still feel better if you could give a simple example... Suppose the relationship I'm capturing in a set of collections is the "uses" relationship between software modules. This me to use pathnames like "moda/modb/modc" to refer to the module named modc used by the module named modb which in turn is used by the module named moda. Since the "uses" relationship can be cyclic, I could get a path like "moda/modb/modc/moda/...". > BTW: this precondition applies to all namespace-manipulating > operations (a MOVE of a collection may fail for the same reason). Good point. I'll add the precondition to the MOVE method as well. Cheers, Geoff ------_=_NextPart_001_01C27E8F.589702F0 Content-Type: text/html; charset="iso-8859-1" RE: BIND vs. non-movable resources in RFC3253

   From: Julian Reschke [mailto:julian.reschke@gmx.de]

   > From: Clemm, Geoff
   > If you are using bindings to capture some relationship, and that
   > relationship is cyclic, then you can't capture that relationship
   > if you are not allowed to create cyclic bindings.

   I'd still feel better if you could give a simple example...

Suppose the relationship I'm capturing in a set of collections
is the "uses" relationship between software modules.  This me to
use pathnames like "moda/modb/modc" to refer to the module named
modc used by the module named modb which in turn is used by the
module named moda.  Since the "uses" relationship can be cyclic,
I could get a path like "moda/modb/modc/moda/...".

>    BTW: this precondition applies to all namespace-manipulating
>    operations (a MOVE of a collection may fail for the same reason).

Good point.  I'll add the precondition to the MOVE method as well.

Cheers,
Geoff

------_=_NextPart_001_01C27E8F.589702F0-- From w3c-dist-auth-request@w3.org Mon Oct 28 11:43:15 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA17959 for ; Mon, 28 Oct 2002 11:43:14 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9SGikP01387; Mon, 28 Oct 2002 11:44:46 -0500 (EST) Resent-Date: Mon, 28 Oct 2002 11:44:46 -0500 (EST) Resent-Message-Id: <200210281644.g9SGikP01387@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9SGiiB01357 for ; Mon, 28 Oct 2002 11:44:44 -0500 (EST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA03333 for ; Mon, 28 Oct 2002 11:44:44 -0500 Received: from cse.ucsc.edu ([63.194.88.161]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0H4P00LIZAII3K@mta5.snfc21.pbi.net> for w3c-dist-auth@w3c.org; Mon, 28 Oct 2002 08:44:42 -0800 (PST) Date: Mon, 28 Oct 2002 08:36:15 -0800 From: Elias To: "Clemm, Geoff" Cc: w3c-dist-auth@w3c.org Message-id: <3DBD677F.1050807@cse.ucsc.edu> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en,pdf User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 References: Subject: Re: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6992 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Is there some compelling reason you would use BIND to capture this relationship? It seems like this could be captured just as easily and without losing any expressiveness via the use of a "uses" property instead. Elias Clemm, Geoff wrote: > [...] > Suppose the relationship I'm capturing in a set of collections > is the "uses" relationship between software modules. This me to > use pathnames like "moda/modb/modc" to refer to the module named > modc used by the module named modb which in turn is used by the > module named moda. Since the "uses" relationship can be cyclic, > I could get a path like "moda/modb/modc/moda/...". From w3c-dist-auth-request@w3.org Mon Oct 28 11:52:35 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA18372 for ; Mon, 28 Oct 2002 11:52:34 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9SGrw502784; Mon, 28 Oct 2002 11:53:58 -0500 (EST) Resent-Date: Mon, 28 Oct 2002 11:53:58 -0500 (EST) Resent-Message-Id: <200210281653.g9SGrw502784@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9SGrvB02756 for ; Mon, 28 Oct 2002 11:53:57 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA05528 for ; Mon, 28 Oct 2002 11:53:57 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 28 Oct 2002 11:41:59 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403Y32NP>; Mon, 28 Oct 2002 11:53:26 -0500 Message-ID: From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Mon, 28 Oct 2002 11:53:19 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27EA2.84BB62F0" Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6993 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27EA2.84BB62F0 Content-Type: text/plain Any relationship captured by collection membership can just as easily be captured by a property. The "expressiveness" that you lose is the ability to use URL paths to select a particular path through that relationship. Cheers, Geoff -----Original Message----- From: Elias [mailto:elias@cse.ucsc.edu] Sent: Monday, October 28, 2002 11:36 AM To: Clemm, Geoff Cc: w3c-dist-auth@w3c.org Subject: Re: BIND vs. non-movable resources in RFC3253 Is there some compelling reason you would use BIND to capture this relationship? It seems like this could be captured just as easily and without losing any expressiveness via the use of a "uses" property instead. Elias Clemm, Geoff wrote: > [...] > Suppose the relationship I'm capturing in a set of collections > is the "uses" relationship between software modules. This me to > use pathnames like "moda/modb/modc" to refer to the module named > modc used by the module named modb which in turn is used by the > module named moda. Since the "uses" relationship can be cyclic, > I could get a path like "moda/modb/modc/moda/...". ------_=_NextPart_001_01C27EA2.84BB62F0 Content-Type: text/html RE: BIND vs. non-movable resources in RFC3253

Any relationship captured by collection membership can just
as easily be captured by a property.  The "expressiveness" that
you lose is the ability to use URL paths to select a particular
path through that relationship.

Cheers,
Geoff

-----Original Message-----
From: Elias [mailto:elias@cse.ucsc.edu]
Sent: Monday, October 28, 2002 11:36 AM
To: Clemm, Geoff
Cc: w3c-dist-auth@w3c.org
Subject: Re: BIND vs. non-movable resources in RFC3253


Is there some compelling reason you would use BIND to capture this
relationship? It seems like this could be captured just as easily and
without losing any expressiveness via the use of a "uses" property instead.

Elias

Clemm, Geoff wrote:

> [...]
> Suppose the relationship I'm capturing in a set of collections
> is the "uses" relationship between software modules.  This me to
> use pathnames like "moda/modb/modc" to refer to the module named
> modc used by the module named modb which in turn is used by the
> module named moda.  Since the "uses" relationship can be cyclic,
> I could get a path like "moda/modb/modc/moda/...".

------_=_NextPart_001_01C27EA2.84BB62F0-- From w3c-dist-auth-request@w3.org Mon Oct 28 12:00:38 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA18774 for ; Mon, 28 Oct 2002 12:00:37 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9SH23907664; Mon, 28 Oct 2002 12:02:03 -0500 (EST) Resent-Date: Mon, 28 Oct 2002 12:02:03 -0500 (EST) Resent-Message-Id: <200210281702.g9SH23907664@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9SH21B07632 for ; Mon, 28 Oct 2002 12:02:01 -0500 (EST) Received: from mta5.snfc21.pbi.net (mta5.snfc21.pbi.net [206.13.28.241]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id MAA09659 for ; Mon, 28 Oct 2002 12:02:01 -0500 Received: from cse.ucsc.edu ([63.194.88.161]) by mta5.snfc21.pbi.net (iPlanet Messaging Server 5.1 (built May 7 2001)) with ESMTP id <0H4P00LJUBBC3U@mta5.snfc21.pbi.net> for w3c-dist-auth@w3c.org; Mon, 28 Oct 2002 09:02:01 -0800 (PST) Date: Mon, 28 Oct 2002 08:53:33 -0800 From: Elias To: w3c-dist-auth@w3c.org Reply-to: w3c-dist-auth@w3.org Message-id: <3DBD6B8D.9050102@cse.ucsc.edu> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en,pdf User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2) Gecko/20010726 Netscape6/6.1 References: Subject: Re: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6994 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7BIT Good morning all, Perhaps you're already aware of this, but... The detection of cyclic bindings is reducable to the problem of finding a Hamiltonian Path in a graph, which is NP-Complete. I strongly object to placing any requirements upon a server which are NP-Complete problems. Since detection of cycles is NP-Complete, it shouldn't be a MUST level requirement that servers detect them. Perhaps they SHOULD detect them, but even that seems too strong for my tastes... It's clear that cycles may be caused inadvertently by other namespace operations such as MOVE, so disallowing them also has the effect of making a server detect them. The problem is analogous to that of having cyclic links in the *nix filesystem, is it not? Is there any reason we cannot follow the same approach taken there? The simplest way to avoid the whole mess is to specify that namespace operations do not follow BINDed (bound?) resources since they could end up in a cycle... I'd be interested in seeing a use case for cyclic BINDings that cannot be satisfied with the judicious use of properties... Elias Julian Reschke wrote: > [...] I see why a server that *does* > support cyclic bindings need to signal them upon depth infinity operations > (-> 506), but why would you want to require support for their creation? > > Actually, I'm tempted to require servers to detect cyclic bindings upon > creation and to reject those requests. What's the use case for cyclic > bindings? From w3c-dist-auth-request@w3.org Mon Oct 28 13:08:51 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA21651 for ; Mon, 28 Oct 2002 13:08:50 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9SIA6c17991; Mon, 28 Oct 2002 13:10:06 -0500 (EST) Resent-Date: Mon, 28 Oct 2002 13:10:06 -0500 (EST) Resent-Message-Id: <200210281810.g9SIA6c17991@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9SIA4B17948 for ; Mon, 28 Oct 2002 13:10:04 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id NAA29435 for ; Mon, 28 Oct 2002 13:10:04 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 28 Oct 2002 12:58:07 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403Y33QT>; Mon, 28 Oct 2002 13:09:33 -0500 Message-ID: From: "Clemm, Geoff" To: "'w3c-dist-auth@w3.org'" Date: Mon, 28 Oct 2002 13:09:24 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27EAD.25BED2E0" Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6995 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27EAD.25BED2E0 Content-Type: text/plain Yes, if the "modeling" argument didn't carry the day, I was planning on falling back on the "too expensive" argument (:-). But how does requiring that cyclic relationships be modeled by properties instead of collection membership solve anything, other than pushing the burden of cycle detection onto the client instead of the server? The problem introduced by cyclic bindings was that PROPFIND needs to maintain a "visited resource" list, in order to detect cycles. For a server that supports bindings, maintaining such a list is straightforward (since the DAV:resourceid property is required). And even if one believes that modeling cyclic relationships should be done with properties, in a versioned collection context, there is no way to avoid the cyclic binding problem. A client could create a collection A, add a collection B to A, add a collection C to B, move C to be a member of A, and then move B to be a member of C. None of the states have multiple bindings to a resource, much less a cycle binding. But if a user selects the version of B that contains C, and the version of C that contains B, they have created a configuration with a cyclic binding. Cheers, Geoff -----Original Message----- From: Elias [mailto:elias@cse.ucsc.edu] Sent: Monday, October 28, 2002 11:54 AM To: w3c-dist-auth@w3c.org Subject: Re: BIND vs. non-movable resources in RFC3253 Good morning all, Perhaps you're already aware of this, but... The detection of cyclic bindings is reducable to the problem of finding a Hamiltonian Path in a graph, which is NP-Complete. I strongly object to placing any requirements upon a server which are NP-Complete problems. Since detection of cycles is NP-Complete, it shouldn't be a MUST level requirement that servers detect them. Perhaps they SHOULD detect them, but even that seems too strong for my tastes... It's clear that cycles may be caused inadvertently by other namespace operations such as MOVE, so disallowing them also has the effect of making a server detect them. The problem is analogous to that of having cyclic links in the *nix filesystem, is it not? Is there any reason we cannot follow the same approach taken there? The simplest way to avoid the whole mess is to specify that namespace operations do not follow BINDed (bound?) resources since they could end up in a cycle... I'd be interested in seeing a use case for cyclic BINDings that cannot be satisfied with the judicious use of properties... Elias Julian Reschke wrote: > [...] I see why a server that *does* > support cyclic bindings need to signal them upon depth infinity operations > (-> 506), but why would you want to require support for their creation? > > Actually, I'm tempted to require servers to detect cyclic bindings upon > creation and to reject those requests. What's the use case for cyclic > bindings? ------_=_NextPart_001_01C27EAD.25BED2E0 Content-Type: text/html RE: BIND vs. non-movable resources in RFC3253

Yes, if the "modeling" argument didn't carry the day,
I was planning on falling back on the "too expensive"
argument (:-).

But how does requiring that cyclic relationships be modeled
by properties instead of collection membership solve
anything, other than pushing the burden of cycle detection
onto the client instead of the server?

The problem introduced by cyclic bindings was that
PROPFIND needs to maintain a "visited resource" list,
in order to detect cycles.  For a server that supports
bindings, maintaining such a list is straightforward
(since the DAV:resourceid property is required).

And even if one believes that modeling cyclic relationships
should be done with properties, in a versioned collection
context, there is no way to
avoid the cyclic binding problem.  A client could
create a collection A, add a collection B to A, add a
collection C to B, move C to be a member of A, and then
move B to be a member of C.  None of the states have
multiple bindings to a resource, much less a cycle binding.
But if a user selects the version of B that contains C,
and the version of C that contains B, they have created
a configuration with a cyclic binding.

Cheers,
Geoff

-----Original Message-----
From: Elias [mailto:elias@cse.ucsc.edu]
Sent: Monday, October 28, 2002 11:54 AM
To: w3c-dist-auth@w3c.org
Subject: Re: BIND vs. non-movable resources in RFC3253



Good morning all,

Perhaps you're already aware of this, but... The detection of cyclic
bindings is reducable to the problem of finding a Hamiltonian Path in a
graph, which is NP-Complete. I strongly object to placing any
requirements upon a server which are NP-Complete problems.

Since detection of cycles is NP-Complete, it shouldn't be a MUST level
requirement that servers detect them. Perhaps they SHOULD detect them,
but even that seems too strong for my tastes... It's clear that cycles
may be caused inadvertently by other namespace operations such as MOVE,
so disallowing them also has the effect of making a server detect them.

The problem is analogous to that of having cyclic links in the *nix
filesystem, is it not? Is there any reason we cannot follow the same
approach taken there? The simplest way to avoid the whole mess is to
specify that namespace operations do not follow BINDed (bound?)
resources since they could end up in a cycle...

I'd be interested in seeing a use case for cyclic BINDings that cannot
be satisfied with the judicious use of properties...


Elias


Julian Reschke wrote:

> [...] I see why a server that *does*
> support cyclic bindings need to signal them upon depth infinity operations
> (-> 506), but why would you want to require support for their creation?
>
> Actually, I'm tempted to require servers to detect cyclic bindings upon
> creation and to reject those requests. What's the use case for cyclic
> bindings?

------_=_NextPart_001_01C27EAD.25BED2E0-- From w3c-dist-auth-request@w3.org Mon Oct 28 17:19:28 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA02252 for ; Mon, 28 Oct 2002 17:19:28 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9SMKlG27759; Mon, 28 Oct 2002 17:20:47 -0500 (EST) Resent-Date: Mon, 28 Oct 2002 17:20:47 -0500 (EST) Resent-Message-Id: <200210282220.g9SMKlG27759@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9SMKkB27733 for ; Mon, 28 Oct 2002 17:20:46 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA31682 for ; Mon, 28 Oct 2002 17:20:46 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Mon, 28 Oct 2002 17:08:47 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403YPARR>; Mon, 28 Oct 2002 17:20:15 -0500 Message-ID: From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Mon, 28 Oct 2002 17:20:05 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C27ED0.2AE281E0" Subject: RE: BIND spec, preconditions Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6996 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C27ED0.2AE281E0 Content-Type: text/plain Looks like I neglected to post the most recent copy which had this precondition added ... should now be fixed. Cheers, Geoff -----Original Message----- From: Julian Reschke [mailto:julian.reschke@gmx.de] Sent: Sunday, October 27, 2002 8:02 AM To: w3c-dist-auth@w3c.org Subject: BIND spec, preconditions Another precondition BIND should specify: DAV:bound-resource-is-mapped: The URL specified by the DAV:href is mapped to a resource. (Explanation: we don't want to return a 404, because that would indicate that the request URL for BIND wasn't mapped). Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 ------_=_NextPart_001_01C27ED0.2AE281E0 Content-Type: text/html Content-Transfer-Encoding: quoted-printable RE: BIND spec, preconditions

Looks like I neglected to post the most recent copy = which had
this precondition added ... should now be = fixed.

Cheers,
Geoff

-----Original Message-----
From: Julian Reschke [mailto:julian.reschke@gmx.de]<= /FONT>
Sent: Sunday, October 27, 2002 8:02 AM
To: w3c-dist-auth@w3c.org
Subject: BIND spec, preconditions



Another precondition BIND should specify:

DAV:bound-resource-is-mapped: The URL specified by = the DAV:href is mapped to
a resource.

(Explanation: we don't want to return a 404, because = that would indicate
that the request URL for BIND wasn't mapped).

Julian

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

------_=_NextPart_001_01C27ED0.2AE281E0-- From w3c-dist-auth-request@w3.org Wed Oct 30 08:42:37 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA14458 for ; Wed, 30 Oct 2002 08:42:37 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9UDh1Z19905; Wed, 30 Oct 2002 08:43:01 -0500 (EST) Resent-Date: Wed, 30 Oct 2002 08:43:01 -0500 (EST) Resent-Message-Id: <200210301343.g9UDh1Z19905@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9UDgvB19879 for ; Wed, 30 Oct 2002 08:42:57 -0500 (EST) Received: from sonne.darmstadt.gmd.de (sonne.darmstadt.gmd.de [141.12.62.20]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA07705 for ; Wed, 30 Oct 2002 08:42:53 -0500 Received: from pcxwing (pc-enterprise [141.12.37.101]) by sonne.darmstadt.gmd.de (8.8.8/8.8.5) with SMTP id OAA00802 for ; Wed, 30 Oct 2002 14:42:18 +0100 (MET) Message-ID: <00a801c2705a$e28352e0$65250c8d@pcxwing> From: "Sascha Boehm" To: Date: Thu, 10 Oct 2002 14:45:15 +0200 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_00A5_01C2706B.A5733E40" 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: Automounter-Problem Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6997 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_00A5_01C2706B.A5733E40 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi there, are there any known problems if the dav-directory is mounted over an = automounter? If I use a local directory there=B4s no problem to gain read- or = write-access. But if it comes with the automounter, I=B4m still able to = read, but I if try e.g. mkcol I get an 403-error. Please help, yours Sascha Boehm Fraunhofer-Institut-SIT Germany ------=_NextPart_000_00A5_01C2706B.A5733E40 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Hi there,
 
are there any known problems if the = dav-directory=20 is mounted over an automounter?
 
If I use a local directory there=B4s no = problem to=20 gain read- or write-access. But if it comes with the automounter, I=B4m = still able=20 to read, but I if try e.g. mkcol I get an 403-error.
Please help,
 
yours
 
Sascha Boehm
 
Fraunhofer-Institut-SIT
Germany
 
------=_NextPart_000_00A5_01C2706B.A5733E40-- From w3c-dist-auth-request@w3.org Wed Oct 30 17:48:40 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA17093 for ; Wed, 30 Oct 2002 17:48:40 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9UMo1b15571; Wed, 30 Oct 2002 17:50:01 -0500 (EST) Resent-Date: Wed, 30 Oct 2002 17:50:01 -0500 (EST) Resent-Message-Id: <200210302250.g9UMo1b15571@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9UMnxB15501 for ; Wed, 30 Oct 2002 17:49:59 -0500 (EST) Received: from dream.darwin.nasa.gov (betlik.darwin.nasa.gov [198.123.160.11]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id RAA32344 for ; Wed, 30 Oct 2002 17:49:58 -0500 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 g9UMnQh08023; Wed, 30 Oct 2002 14:49:26 -0800 (PST) Message-ID: <3DC061F6.5070106@cse.ucsc.edu> Date: Wed, 30 Oct 2002 14:49:26 -0800 From: Elias Sinderson Reply-To: "'w3c-dist-auth@w3.org'" User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.4.1) Gecko/20020518 Netscape6/6.2.3 X-Accept-Language: en-us MIME-Version: 1.0 To: "Clemm, Geoff" CC: "'w3c-dist-auth@w3.org'" References: Content-Type: multipart/alternative; boundary="------------070707070605090209090705" Subject: Re: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6998 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: --------------070707070605090209090705 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Clemm, Geoff wrote: > [...] how does requiring that cyclic relationships be modeled > by properties instead of collection membership solve > anything, other than pushing the burden of cycle detection > onto the client instead of the server? > Recursive operations such as a depth infinity MOVE/COPY/PROPFIND will have problems if there is a cycle. I see two possible alternatives to address this problem: a) model cyclic relationships as properties or b) disallow following links during recursive operations in the same way that a filesystem does. > [...] And even if one believes that modeling cyclic relationships > should be done with properties, in a versioned collection > context, there is no way to avoid the cyclic binding problem. [...] > I have no problem with the creation of cyclic bindings. My primary concern is that the server should not be required to detect the existence of a cycle. Since there is no way to avoid the creation of cyclic bindings in a versioned collection context, option (a) won't buy us anything, so option (b) seems to be the only alternative. Is it reasonable to specify that recursive operations treat bindings differently than other resources? Elias --------------070707070605090209090705 Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: 7bit Clemm, Geoff wrote:
RE: BIND vs. non-movable resources in RFC3253

[...] how does requiring that cyclic relationships be modeled
by properties instead of collection membership solve
anything, other than pushing the burden of cycle detection
onto the client instead of the server?

Recursive operations such as a depth infinity MOVE/COPY/PROPFIND will have problems if there is a cycle. I see two possible alternatives to address this problem:
a) model cyclic relationships as properties or
b) disallow following links during recursive operations in the same way that a filesystem does.

[...] And even if one believes that modeling cyclic relationships
should be done with properties, in a versioned collection
context, there is no way to avoid the cyclic binding problem.  [...]

I have no problem with the creation of cyclic bindings. My primary concern is that the server should not be required to detect the existence of a cycle. Since there is no way to avoid the creation of cyclic bindings in a versioned collection context, option (a) won't buy us anything, so option (b) seems to be the only alternative. Is it reasonable to specify that recursive operations treat bindings differently than other resources?


Elias
--------------070707070605090209090705-- From w3c-dist-auth-request@w3.org Wed Oct 30 18:27:04 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA18577 for ; Wed, 30 Oct 2002 18:27:04 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9UNSZk27208; Wed, 30 Oct 2002 18:28:35 -0500 (EST) Resent-Date: Wed, 30 Oct 2002 18:28:35 -0500 (EST) Resent-Message-Id: <200210302328.g9UNSZk27208@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9UNSXB27182 for ; Wed, 30 Oct 2002 18:28:33 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA09885 for ; Wed, 30 Oct 2002 18:28:33 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Wed, 30 Oct 2002 18:16:30 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403YT68W>; Wed, 30 Oct 2002 18:28:02 -0500 Message-ID: From: "Clemm, Geoff" To: "'w3c-dist-auth@w3.org'" Date: Wed, 30 Oct 2002 18:28:02 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C2806B.FDA6D3A0" Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/6999 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C2806B.FDA6D3A0 Content-Type: text/plain From: Elias Sinderson [mailto:elias@cse.ucsc.edu] Recursive operations such as a depth infinity MOVE/COPY/PROPFIND will have problems if there is a cycle. These problems are all solvable in a straightforward fashion. A MOVE has no problems with a cycle (it is just the deletion of one binding and the creation of another). A COPY would have to check for any resource that has multiple entries in its DAV:parent-set, to see if it has already been copied (in which case a second binding to the copy is created). A PROPFIND has to keep track of what resources it has already visited. I see two possible alternatives to address this problem: a) model cyclic relationships as properties or b) disallow following links during recursive operations in the same way that a filesystem does. and: c) handle cycles appropriately when they are encountered I have no problem with the creation of cyclic bindings. My primary concern is that the server should not be required to detect the existence of a cycle. Detection of the existence of a cycle at binding creation time can be hard. Handling the existence of a cycle during the operation of a WebDAV method is straightforward (at least for the currently defined WebDAV methods). Since there is no way to avoid the creation of cyclic bindings in a versioned collection context, option (a) won't buy us anything, Agreed. so option (b) seems to be the only alternative. Is it reasonable to specify that recursive operations treat bindings differently than other resources? In a versioned-collection context, all of the bindings are created by PUT and MKCOL, but with an appropriate set of collection versions, a cycle results. So option b doesn't solve the problem, because even if you marked all the bindings created by BIND as special, all of the bindings may have been created by PUT and MKCOL, and still result in a cycle. So that leaves option (c) as the only alternative. Cheers, Geoff ------_=_NextPart_001_01C2806B.FDA6D3A0 Content-Type: text/html RE: BIND vs. non-movable resources in RFC3253

   From: Elias Sinderson [mailto:elias@cse.ucsc.edu]

   Recursive operations such as a depth infinity MOVE/COPY/PROPFIND
   will have problems if there is a cycle.

These problems are all solvable in a straightforward fashion.  A MOVE
has no problems with a cycle (it is just the deletion of one binding
and the creation of another).  A COPY would have to check for any
resource that has multiple entries in its DAV:parent-set, to see if it
has already been copied (in which case a second binding to the copy is
created).  A PROPFIND has to keep track of what resources it has
already visited.

   I see two possible alternatives to address this problem:

   a) model cyclic relationships as properties or

   b) disallow following links during recursive operations in the same
   way that a filesystem does.

and:

c) handle cycles appropriately when they are encountered

   I have no problem with the creation of cyclic bindings. My primary
   concern is that the server should not be required to detect the
   existence of a cycle.

Detection of the existence of a cycle at binding creation time
can be hard.  Handling the existence of a cycle during the
operation of a WebDAV method is straightforward (at least for
the currently defined WebDAV methods).

   Since there is no way to avoid the creation of cyclic bindings in a
   versioned collection context, option (a) won't buy us anything,

Agreed.

   so option (b) seems to be the only alternative.
   Is it reasonable to specify that recursive operations
   treat bindings differently than other resources?

In a versioned-collection context, all of the bindings are created by
PUT and MKCOL, but with an appropriate set of collection versions, a
cycle results.  So option b doesn't solve the problem, because even if
you marked all the bindings created by BIND as special, all of the
bindings may have been created by PUT and MKCOL, and still result in a
cycle.

So that leaves option (c) as the only alternative.

Cheers,
Geoff

------_=_NextPart_001_01C2806B.FDA6D3A0-- From w3c-dist-auth-request@w3.org Wed Oct 30 18:46:25 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id SAA19103 for ; Wed, 30 Oct 2002 18:46:25 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9UNm5O29660; Wed, 30 Oct 2002 18:48:05 -0500 (EST) Resent-Date: Wed, 30 Oct 2002 18:48:05 -0500 (EST) Resent-Message-Id: <200210302348.g9UNm5O29660@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9UNm4B29634 for ; Wed, 30 Oct 2002 18:48:04 -0500 (EST) Received: from svew1001.statestreet.com (svew1001.statestreet.com [205.181.240.145]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA13470 for ; Wed, 30 Oct 2002 18:48:04 -0500 From: Joe_Kennedy@ssga.com Received: from svew1001.statestreet.com (localhost [127.0.0.1]) by svew1001.statestreet.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g9UNm3H01524 for ; Wed, 30 Oct 2002 18:48:03 -0500 (EST) Received: from waller.ssga.statestreet.com (waller.ssga.statestr.com [147.141.15.163]) by svew1001.statestreet.com (Switch-2.2.2/Switch-2.2.0) with ESMTP id g9UNm3H01520 for ; Wed, 30 Oct 2002 18:48:03 -0500 (EST) To: w3c-dist-auth@w3.org Message-ID: Date: Wed, 30 Oct 2002 18:47:17 -0500 X-MIMETrack: Serialize by Router on SSGA_GateWay/BOSTON/SSGA(Release 5.0.8 |June 18, 2001) at 10/30/2002 06:48:03 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Joe Kennedy/USA/StateStreet is out of the office. Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7000 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: I will be out of the office starting 10/28/2002 and will not return until 11/01/2002. I will be out of the office on business until November 1st. From w3c-dist-auth-request@w3.org Thu Oct 31 03:45:39 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10481 for ; Thu, 31 Oct 2002 03:45:38 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9V8kk926207; Thu, 31 Oct 2002 03:46:46 -0500 (EST) Resent-Date: Thu, 31 Oct 2002 03:46:46 -0500 (EST) Resent-Message-Id: <200210310846.g9V8kk926207@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9V8kgB26162 for ; Thu, 31 Oct 2002 03:46:42 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA11193 for ; Thu, 31 Oct 2002 03:46:42 -0500 Received: (qmail 705 invoked by uid 0); 31 Oct 2002 08:46:11 -0000 Received: from pd950c3a1.dip.t-dialin.net (HELO lisa) (217.80.195.161) by mail.gmx.net (mp018-rz3) with SMTP; 31 Oct 2002 08:46:11 -0000 From: "Julian Reschke" To: Date: Thu, 31 Oct 2002 09:46:00 +0100 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-reply-to: <3DC061F6.5070106@cse.ucsc.edu> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7001 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Elias Sinderson > Sent: Wednesday, October 30, 2002 11:49 PM > To: Clemm, Geoff > Cc: 'w3c-dist-auth@w3.org' > Subject: Re: BIND vs. non-movable resources in RFC3253 > > > ... > > [...] how does requiring that cyclic relationships be modeled > by properties instead of collection membership solve > anything, other than pushing the burden of cycle detection > onto the client instead of the server? > Recursive operations such as a depth infinity MOVE/COPY/PROPFIND will have > problems if there is a cycle. I see two possible alternatives to address > this problem: > a) model cyclic relationships as properties or > b) disallow following links during recursive operations in the same way that > a filesystem does. A binding isn't a link. Filesystems that support the equivalent of bindings (hard links) have the same problem. Programs that do recursive operations need special treatment, that is: - avoid getting into loops when there are multiple bindings to a collection (the solution being to keep track of inode numbers that were visited) (*) - optionally special-case multiple bindings to the same resource (I think "cpio" can do that, but "tar" doesn't) (*) In a Unix filesystem, "." is a binding to the current directory, and ".." is a binding to the parent directory. If you do a "ls -l", you'll the number of hard links to a file/folder, and the number of hard links for a folder always always is something like 2 + the number of direct child collections. > [...] And even if one believes that modeling cyclic relationships > should be done with properties, in a versioned collection > context, there is no way to avoid the cyclic binding problem. [...] > I have no problem with the creation of cyclic bindings. My primary concern > is that the server should not be required to detect the existence of a > cycle. Since there is no way to avoid the creation of cyclic bindings in a > versioned collection context, option (a) won't buy us anything, so option > (b) seems to be the only alternative. Is it reasonable to specify that > recursive operations treat bindings differently than other resources? No. There is no difference (at least not in the general case, your implementation may vary :-). -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Oct 31 03:57:52 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA10709 for ; Thu, 31 Oct 2002 03:57:51 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9V8s6n27046; Thu, 31 Oct 2002 03:54:06 -0500 (EST) Resent-Date: Thu, 31 Oct 2002 03:54:06 -0500 (EST) Resent-Message-Id: <200210310854.g9V8s6n27046@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9V8s3B27016 for ; Thu, 31 Oct 2002 03:54:03 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id DAA12149 for ; Thu, 31 Oct 2002 03:54:02 -0500 Received: (qmail 2753 invoked by uid 0); 31 Oct 2002 08:53:31 -0000 Received: from pd950c3a1.dip.t-dialin.net (HELO lisa) (217.80.195.161) by mail.gmx.net (mp001-rz3) with SMTP; 31 Oct 2002 08:53:31 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , Date: Thu, 31 Oct 2002 09:53:20 +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.2416 (9.0.2911.0) In-reply-to: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7002 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Content-Transfer-Encoding: 7bit > From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On > Behalf Of Clemm, Geoff > Sent: Thursday, October 31, 2002 12:28 AM > To: 'w3c-dist-auth@w3.org' > Subject: RE: BIND vs. non-movable resources in RFC3253 > > > From: Elias Sinderson [mailto:elias@cse.ucsc.edu] > Recursive operations such as a depth infinity MOVE/COPY/PROPFIND > will have problems if there is a cycle. > These problems are all solvable in a straightforward fashion. A MOVE > has no problems with a cycle (it is just the deletion of one binding > and the creation of another). A COPY would have to check for any > resource that has multiple entries in its DAV:parent-set, to see if it > has already been copied (in which case a second binding to the copy is > created). A PROPFIND has to keep track of what resources it has > already visited. This COPY behaviour makes sense, but can we really require it? Right now it seems completely legal to just create multiple plain new resources with same content and dead properties... > ... Julian -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 From w3c-dist-auth-request@w3.org Thu Oct 31 08:56:13 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id IAA19362 for ; Thu, 31 Oct 2002 08:56:10 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9VDvM619641; Thu, 31 Oct 2002 08:57:22 -0500 (EST) Resent-Date: Thu, 31 Oct 2002 08:57:22 -0500 (EST) Resent-Message-Id: <200210311357.g9VDvM619641@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9VDvIB19610 for ; Thu, 31 Oct 2002 08:57:18 -0500 (EST) Received: from sus-ma1it31.rational.com (sus-ma1it31.rational.com [130.213.73.33]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id IAA11292 for ; Thu, 31 Oct 2002 08:57:18 -0500 Received: from sus-ma1it00.rational.com ([10.64.1.25]) by 10.64.1.33 with InterScan Messaging Security Suite; Thu, 31 Oct 2002 08:45:13 -0500 Received: by sus-ma1it00.rational.com with Internet Mail Service (5.5.2656.59) id <403Y4YPP>; Thu, 31 Oct 2002 08:56:46 -0500 Message-ID: From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Thu, 31 Oct 2002 08:56:45 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2656.59) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C280E5.59470D50" Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7003 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01C280E5.59470D50 Content-Type: text/plain; charset="iso-8859-1" From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: Clemm, Geoff > A COPY would have to check for any > resource that has multiple entries in its DAV:parent-set, to see if it > has already been copied (in which case a second binding to the copy is > created). This COPY behaviour makes sense, but can we really require it? Right now it seems completely legal to just create multiple plain new resources with same content and dead properties... If the binding relationships are acyclic, creating multiple plain new resources with the same content and dead properties seems reasonable to me (i.e. I don't think the spec should forbid it), but this would be a somewhat expensive approach if there are cycles (:-). Cheers, Geoff ------_=_NextPart_001_01C280E5.59470D50 Content-Type: text/html; charset="iso-8859-1" RE: BIND vs. non-movable resources in RFC3253

   From: Julian Reschke [mailto:julian.reschke@gmx.de]

   > From: Clemm, Geoff
   > A COPY would have to check for any
   > resource that has multiple entries in its DAV:parent-set, to see if it
   > has already been copied (in which case a second binding to the copy is
   > created).

   This COPY behaviour makes sense, but can we really require it?
   Right now it seems completely legal to just create multiple plain
   new resources with same content and dead properties...

If the binding relationships are acyclic, creating multiple
plain new resources with the same content and dead properties
seems reasonable to me (i.e. I don't think the spec should
forbid it), but this would be a somewhat expensive approach if
there are cycles (:-).

Cheers,
Geoff

------_=_NextPart_001_01C280E5.59470D50-- From w3c-dist-auth-request@w3.org Thu Oct 31 09:06:25 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19768 for ; Thu, 31 Oct 2002 09:06:25 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id g9VE79721343; Thu, 31 Oct 2002 09:07:09 -0500 (EST) Resent-Date: Thu, 31 Oct 2002 09:07:09 -0500 (EST) Resent-Message-Id: <200210311407.g9VE79721343@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id g9VE74B21227 for ; Thu, 31 Oct 2002 09:07:04 -0500 (EST) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by tux.w3.org (8.9.3/8.9.3) with SMTP id JAA14337 for ; Thu, 31 Oct 2002 09:07:04 -0500 Received: (qmail 315 invoked by uid 0); 31 Oct 2002 14:06:32 -0000 Received: from mail.greenbytes.de (HELO lisa) (217.5.201.10) by mail.gmx.net (mp016-rz3) with SMTP; 31 Oct 2002 14:06:32 -0000 From: "Julian Reschke" To: "Clemm, Geoff" , Date: Thu, 31 Oct 2002 15:06:31 +0100 Message-ID: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0008_01C280EF.191AA1B0" 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.1106 Importance: Normal Subject: RE: BIND vs. non-movable resources in RFC3253 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7004 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: This is a multi-part message in MIME format. ------=_NextPart_000_0008_01C280EF.191AA1B0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit RE: BIND vs. non-movable resources in RFC3253On the other hand, doing that would make the question about response codes moot. -- bytes GmbH -- http://www.greenbytes.de -- tel:+492512807760 -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm, Geoff Sent: Thursday, October 31, 2002 2:57 PM To: w3c-dist-auth@w3.org Subject: RE: BIND vs. non-movable resources in RFC3253 From: Julian Reschke [mailto:julian.reschke@gmx.de] > From: Clemm, Geoff > A COPY would have to check for any > resource that has multiple entries in its DAV:parent-set, to see if it > has already been copied (in which case a second binding to the copy is > created). This COPY behaviour makes sense, but can we really require it? Right now it seems completely legal to just create multiple plain new resources with same content and dead properties... If the binding relationships are acyclic, creating multiple plain new resources with the same content and dead properties seems reasonable to me (i.e. I don't think the spec should forbid it), but this would be a somewhat expensive approach if there are cycles (:-). Cheers, Geoff ------=_NextPart_000_0008_01C280EF.191AA1B0 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: BIND vs. non-movable resources in RFC3253
On the=20 other hand, doing that would make the question about response codes=20 moot.
 

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

-----Original Message-----
From: = w3c-dist-auth-request@w3.org=20 [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Clemm,=20 Geoff
Sent: Thursday, October 31, 2002 2:57 PM
To: = w3c-dist-auth@w3.org
Subject: RE: BIND vs. non-movable = resources in=20 RFC3253

   From: Julian Reschke [mailto:julian.reschke@gmx.de]=20

   > From: Clemm, Geoff =
   > A COPY would have to check for any =
   > resource that has multiple entries in its=20 DAV:parent-set, to see if it
   = > has=20 already been copied (in which case a second binding to the copy = is=20
   > created).

   This COPY behaviour makes sense, but = can we=20 really require it?
   Right now it = seems=20 completely legal to just create multiple plain
   new resources with same content and dead=20 properties...

If the binding relationships are acyclic, creating=20 multiple
plain new resources with the same = content and=20 dead properties
seems reasonable to me (i.e. = I don't=20 think the spec should
forbid it), but this = would be a=20 somewhat expensive approach if
there are = cycles=20 (:-).

Cheers,
Geoff=20

------=_NextPart_000_0008_01C280EF.191AA1B0-- From w3c-dist-auth-request@w3.org Thu Oct 31 23:38:35 2002 Received: from frink.w3.org (frink.w3.org [18.29.1.71]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id XAA26865 for ; Thu, 31 Oct 2002 23:38:35 -0500 (EST) Received: (from lists@localhost) by frink.w3.org (8.11.6+Sun/8.11.6) id gA14e7G14094; Thu, 31 Oct 2002 23:40:07 -0500 (EST) Resent-Date: Thu, 31 Oct 2002 23:40:07 -0500 (EST) Resent-Message-Id: <200211010440.gA14e7G14094@frink.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by frink.w3.org (8.11.6+Sun/8.11.6) with ESMTP id gA14e5B14068 for ; Thu, 31 Oct 2002 23:40:05 -0500 (EST) Received: from sunbelt.seagull.net (sunbelt.seagull.net [199.254.168.249]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id XAA21992 for ; Thu, 31 Oct 2002 23:40:04 -0500 Received: (mail@localhost) by sunbelt.seagull.net (8.9.3) id UAA09510 sender nn683849@smallcue.com for w3c-dist-auth@w3.org; Thu, 31 Oct 2002 20:39:58 -0800 Received: from e2.ny.us.ibm.com (e2.ny.us.ibm.com [32.97.182.102]) by sunbelt.seagull.net (8.9.3) with ESMTP id UAA09487 sender obsfucated@us.ibm.com; Thu, 31 Oct 2002 20:39:56 -0800 Received: from northrelay02.pok.ibm.com (northrelay02.pok.ibm.com [9.56.224.150]) by e2.ny.us.ibm.com (8.12.2/8.12.2) with ESMTP id gA14dPgI163122; Thu, 31 Oct 2002 23:39:25 -0500 Received: from d01ml243.pok.ibm.com (d01ml243.pok.ibm.com [9.56.224.77]) by northrelay02.pok.ibm.com (8.12.3/NCO/VER6.4) with ESMTP id gA14dNUk112376; Thu, 31 Oct 2002 23:39:24 -0500 To: "Julian Reschke" Cc: "Clemm, Geoff" , w3c-dist-auth@w3.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 5.0.8 June 18, 2001 From: Jason Crawford Message-ID: Date: Thu, 31 Oct 2002 23:39:21 -0500 X-MIMETrack: Serialize by Router on D01ML243/01/M/IBM(Release 6.0 [IBM]|October 25, 2002) at 10/31/2002 23:39:23, Serialize complete at 10/31/2002 23:39:23 Content-Type: text/plain; charset="us-ascii" Subject: RE: BIND vs. non-movable resources in RFC3253, copy and cycles Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/7005 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Even in the absense of cycles, if you are doing a copy, and there are diamond graphs, a / \ b c \ / d /||\ And d is actually a subtree, if the server does't reconstruct the diamond or flag the duplication, you're going to duplicate the sub tree below d. That might be expensive. Do we have to require folks to reconstruct the graph? Probably not, but we should at least educate them about situations like this and encourage them to recreate the graph. J. ------------------------------------------ Phone: 914-784-7569