From w3c-dist-auth-request@w3.org Mon Apr 3 13:46:02 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA20564 for ; Mon, 3 Apr 2000 13:46:01 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA03102; Mon, 3 Apr 2000 13:43:12 -0400 (EDT) Resent-Date: Mon, 3 Apr 2000 13:43:12 -0400 (EDT) Resent-Message-Id: <200004031743.NAA03102@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3c.org Message-ID: <852568B6.006147A8.00@d54mta03.raleigh.ibm.com> Date: Mon, 3 Apr 2000 13:40:34 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id NAA03082 Subject: RE: ACLs Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4230 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 8bit Jim, I think you misunderstood this statement. The question we are answering is, how many ACEs are allowed in a particular ACL. We didn't address the lower bound (which is clearly 0), but rather the upper bound. Clearly each server will have some maximum number of ACEs that it can handle. For interoperability, we need to have a mimimum value for this maximum that all servers must implement. The current proposal is that we have two limits (one for users & one for groups) and that the minimum number of supportable ACEs is 1. For example, if you tried to store an ACL with 3 ACEs, you could not count on a particular server supporting that, and could get a "Too many ACEs" error. The benefit to treating the ACL as a property of the resource, is that it allows a WebDAV client to implement things like "ls -l", where you could see all of the resources in a collection: names, access rights, owner, etc. A single PROPFIND call could do all of that. Issuing a separate ACL request for each item in the collection would be a lot slower. I see you're point. I could be convinced ACLs as live properties is OK. Don't like using PROPPATCH to update them though. It would be nice if the protocol provided an ACL method that supported the semantics instead of PROPPATCH with a lot of possible errors returned. Don't you mean No, I meant: ?checkPermissions? method:  ?do I have rights to do the following operation if I tried it? HTTP is a "try it and see what happens" or challenge response paradigm. This has worked well so far for access control. If the operation works, a client wouldn't want to waste the time checking ahead of time. If it fails due to access control, the client will know from the returned status code and can do whatever it would have done after a "checkPermissions" method. I don't see the need. The method that you try might be destructive (eg. a DELETE method). You might want to find out if you can delete it without doing so, and without implementing the ACL resolution mechanism in the client. That's the request we're considering. What difference does it make if the method is destructive or not? Say you want to do a DELETE. If you have permission, asking first will return true and you'll do the delete. Not asking first will just do the delete - same result in both cases. If you don't have permission, asking first will return false and the client won't do the delete. Not asking first the delete will fail - same result in both cases. So it seems to me the checkPermissions() method wouldn't add anything. Am I missing something? From w3c-dist-auth-request@w3.org Mon Apr 3 14:01:42 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA20794 for ; Mon, 3 Apr 2000 14:01:42 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA04512; Mon, 3 Apr 2000 14:00:30 -0400 (EDT) Resent-Date: Mon, 3 Apr 2000 14:00:30 -0400 (EDT) Resent-Message-Id: <200004031800.OAA04512@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3c.org Message-ID: <852568B6.00620752.00@d54mta03.raleigh.ibm.com> Date: Mon, 3 Apr 2000 13:50:06 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id OAA04479 Subject: RE: [ACL] Conference call notes, Mar. 31 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4231 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 8bit All, upon further thought, I don't feel that authentication should ever come into the realm of ACLs, since (I'd hope) any authentication is performed at the HTTP/WebDAV level before any ACL is examinedand that the ACL "engine" should trust the identity performing operations. In other words, any principal information in the ACL should be compared against the principal information for the request (which should already have been authenticated as a valid principal or re-assigned as an invalid one) without trying to communicate to an owning "domain server" of that principal's domain. I agree with this. From w3c-dist-auth-request@w3.org Mon Apr 3 14:21:09 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA21120 for ; Mon, 3 Apr 2000 14:21:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA05392; Mon, 3 Apr 2000 14:18:53 -0400 (EDT) Resent-Date: Mon, 3 Apr 2000 14:18:53 -0400 (EDT) Resent-Message-Id: <200004031818.OAA05392@www19.w3.org> Date: Mon, 3 Apr 2000 11:24:05 -0700 (PDT) From: Greg Stein To: acl@webdav.org, w3c-dist-auth@w3.org cc: jamsden@us.ibm.com In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by www19.w3.org id OAA05368 Subject: Re: FW: [ACL] Conference call notes, Mar. 31 Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4232 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 8bit Simple solution: stop cross-posting, and have ACL discussions on the ACL mailing list. Not a big deal, but I think people just aren't used to the presence of a new list. Same issue probably happened with the deltav and dasl lists :-) Cheers, -g On Mon, 3 Apr 2000, Kevin Wiggen wrote: > > Don't think these are making it over..... (in case someone is on one and not > the other) > > Kevin > > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of jamsden@us.ibm.com > Sent: Monday, April 03, 2000 10:50 AM > To: w3c-dist-auth@w3c.org > Subject: RE: [ACL] Conference call notes, Mar. 31 > > > > > All, upon further thought, I don't feel that authentication should ever > come into the realm of ACLs, since (I'd hope) any authentication is > performed at the HTTP/WebDAV level before any ACL is examinedand that the > ACL "engine" should trust the identity performing operations. In other > words, any principal information in the ACL should be compared against the > principal information for the request (which should already have been > authenticated as a valid principal or re-assigned as an invalid one) > without trying to communicate to an owning "domain server" of that > principal's domain. > > I agree with this. > > > > > _______________________________________________ > acl mailing list > acl@webdav.org > http://mailman.webdav.org/mailman/listinfo/acl > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon Apr 3 17:34:35 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA25161 for ; Mon, 3 Apr 2000 17:34:34 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA11886; Mon, 3 Apr 2000 17:33:21 -0400 (EDT) Resent-Date: Mon, 3 Apr 2000 17:33:21 -0400 (EDT) Resent-Message-Id: <200004032133.RAA11886@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3c.org Message-ID: <852568B6.00766351.00@d54mta03.raleigh.ibm.com> Date: Mon, 3 Apr 2000 17:29:20 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: COPY semantics Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4233 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list COPY has to depend on what you requested to copy. If its a working resource, you should get a new, unversioned resource. If its a revision, you should get a new unversioned resource of that revision. If its a versioned resource, you should probably get the whole history. But that maybe we should dissallow copy on versioned resources? |--------+----------------------------------> | | "Tim Ellison/OTT/OTI" | | | | | | Sent by: | | | ietf-dav-versioning-requ| | | est@w3.org | | | | | | | | | 04/03/2000 03:15 PM | | | | |--------+----------------------------------> >---------------------------------------------------------------------| | | | To: ietf-dav-versioning@w3.org | | cc: | | Subject: COPY semantics | >---------------------------------------------------------------------| (I've posed this question before, but it didn't get much discussion...) What does COPY mean for a versioned resource? Options might be: (1) create a new versioned resource at the destination whose initial revision is the same as the revision selected by the source, (2) copy all the history of the source to a new versioned resource at the destination, (3) make a new unversioned resource that has looks like the selected source (i.e., looses it's versioned status). Then how does that differ if the selected resource is a working resource? We disallow a working resource without a corresponding versioned resource with at least an initial revision. Option (1) seems the most likely candidate to me. Tim From w3c-dist-auth-request@w3.org Tue Apr 4 10:07:12 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA03893 for ; Tue, 4 Apr 2000 10:07:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA29913; Tue, 4 Apr 2000 10:02:19 -0400 (EDT) Resent-Date: Tue, 4 Apr 2000 10:02:19 -0400 (EDT) Resent-Message-Id: <200004041402.KAA29913@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC025F9B37@chef.lex.rational.com> From: "Clemm, Geoff" To: w3c-dist-auth@w3c.org Date: Tue, 4 Apr 2000 09:59:36 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="ISO-8859-1" Subject: RE: COPY semantics Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4234 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list I agree with Jim. When a COPY is applied to a revision or a working resource, it has the same semantics as if it were applied to an unversioned resource of that type. When the Target-Selector:metadata header is used, I believe the COPY MUST fail, because it is not feasible to COPY all the versioning metadata relationships (such as activity and baseline membership). Any objections? Cheers, Geoff -----Original Message----- From: jamsden@us.ibm.com [mailto:jamsden@us.ibm.com] Sent: Monday, April 03, 2000 5:29 PM To: w3c-dist-auth@w3c.org Subject: Re: COPY semantics COPY has to depend on what you requested to copy. If its a working resource, you should get a new, unversioned resource. If its a revision, you should get a new unversioned resource of that revision. If its a versioned resource, you should probably get the whole history. But that maybe we should dissallow copy on versioned resources? |--------+----------------------------------> | | "Tim Ellison/OTT/OTI" | | | | | | Sent by: | | | ietf-dav-versioning-requ| | | est@w3.org | | | | | | | | | 04/03/2000 03:15 PM | | | | |--------+----------------------------------> >---------------------------------------------------------------------| | | | To: ietf-dav-versioning@w3.org | | cc: | | Subject: COPY semantics | >---------------------------------------------------------------------| (I've posed this question before, but it didn't get much discussion...) What does COPY mean for a versioned resource? Options might be: (1) create a new versioned resource at the destination whose initial revision is the same as the revision selected by the source, (2) copy all the history of the source to a new versioned resource at the destination, (3) make a new unversioned resource that has looks like the selected source (i.e., looses it's versioned status). Then how does that differ if the selected resource is a working resource? We disallow a working resource without a corresponding versioned resource with at least an initial revision. Option (1) seems the most likely candidate to me. Tim From w3c-dist-auth-request@w3.org Sat Apr 8 07:57:26 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA09889 for ; Sat, 8 Apr 2000 07:57:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA20019; Sat, 8 Apr 2000 07:56:00 -0400 (EDT) Resent-Date: Sat, 8 Apr 2000 07:56:00 -0400 (EDT) Resent-Message-Id: <200004081156.HAA20019@www19.w3.org> Date: Sat, 8 Apr 2000 05:01:29 -0700 (PDT) From: Greg Stein To: w3c-dist-auth@w3.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: DAV: header values Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4235 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Hi all, In section 9.1 of RFC 2518, the spec states that 1#extend should be used for adding tokens. Two problems: 1) the RFC doesn't have a "*" to indicate any number of extensions 2) "extend" is never specified. Specifically, what is the set of valid characters? I plan to have some mod_dav-specific properties, and I'd like to note their existence in the DAV: field. The identifier could also be used by clients to detect the mod_dav version to work around problems or whatever. Anyhow... I want to return something like: DAV: 1,2, Does anybody have an issue with defining "extend" to contain at least the characters which are valid in a Coded-URL? thx, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Sat Apr 8 12:47:45 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA11799 for ; Sat, 8 Apr 2000 12:47:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA24484; Sat, 8 Apr 2000 12:46:40 -0400 (EDT) Resent-Date: Sat, 8 Apr 2000 12:46:40 -0400 (EDT) Resent-Message-Id: <200004081646.MAA24484@www19.w3.org> To: Greg Stein cc: w3c-dist-auth@w3.org, jjh@ira.uka.de, reuterj@ira.uka.de In-reply-to: Your message of "Sat, 08 Apr 2000 05:01:29 PDT." Date: Sat, 08 Apr 2000 18:46:28 +0200 From: Juergen Reuter Message-ID: <"iraun1.ira.0054401:000408.164632"@ira.uka.de> Subject: Re: DAV: header values Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4236 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Greg Stein wrote: > Hi all, > > In section 9.1 of RFC 2518, the spec states that 1#extend should be used > for adding tokens. Two problems: > > 1) the RFC doesn't have a "*" to indicate any number of extensions The "1#element" rule in RFC 2068, section 2.1 indicates a list of at least 1 element, separated by one or more commas and with optional linear white space. > 2) "extend" is never specified. Specifically, what is the set of valid > characters? See issue EXTEND_UNDEFINED on the WebDAV issues list at http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html (BTW., Greg, I could not find any hyper link on www.webdav.org that points to this page.) Jim Whitehead proposed to define: > extend = token ; token is defined in [HTTP]. (see http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0199.html). > I plan to have some mod_dav-specific properties, and I'd like to note > their existence in the DAV: field. The identifier could also be used by > clients to detect the mod_dav version to work around problems or whatever. > Anyhow... I want to return something like: > > DAV: 1,2, > > Does anybody have an issue with defining "extend" to contain at least the > characters which are valid in a Coded-URL? Section 2.2 of RFC 2068 defines: token = 1* tspecials = "(" | ")" | "<" | ">" | "@" | "," | ";" | ":" | "\" | <"> | "/" | "[" | "]" | "?" | "=" | "{" | "}" | SP | HT Hence, the above would be illegal, as it contains "<", ">", ":" and "/". But one could propose to define (as I already did): extend = token | quoted-string ; token and quoted-string are defined in [HTTP]. That would allow to put a URL into double-quotes. Bye, Juergen From w3c-dist-auth-request@w3.org Mon Apr 10 07:29:21 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA05224 for ; Mon, 10 Apr 2000 07:29:20 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA00701; Mon, 10 Apr 2000 07:27:47 -0400 (EDT) Resent-Date: Mon, 10 Apr 2000 07:27:47 -0400 (EDT) Resent-Message-Id: <200004101127.HAA00701@www19.w3.org> Date: Mon, 10 Apr 2000 04:33:15 -0700 (PDT) From: Greg Stein To: Juergen Reuter cc: w3c-dist-auth@w3.org, jjh@ira.uka.de In-Reply-To: <"iraun1.ira.0054401:000408.164632"@ira.uka.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: DAV: header values Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4237 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Sat, 8 Apr 2000, Juergen Reuter wrote: > Greg Stein wrote: > > Hi all, > > > > In section 9.1 of RFC 2518, the spec states that 1#extend should be used > > for adding tokens. Two problems: > > > > 1) the RFC doesn't have a "*" to indicate any number of extensions > > The "1#element" rule in RFC 2068, section 2.1 indicates a list of at > least 1 element, separated by one or more commas and with optional > linear white space. Oh, right. *forehead slap* Silly me :-) > > 2) "extend" is never specified. Specifically, what is the set of valid > > characters? > > See issue EXTEND_UNDEFINED on the WebDAV issues list at > http://www.ics.uci.edu/pub/ietf/webdav/protocol/issues.html > (BTW., Greg, I could not find any hyper link on www.webdav.org that > points to this page.) I've added this to the specs page. Thx for the idea! And yes. I see that you found the problem already :-) > Jim Whitehead proposed to define: > > extend = token ; token is defined in [HTTP]. > (see > http://lists.w3.org/Archives/Public/w3c-dist-auth/1999OctDec/0199.html). > > > I plan to have some mod_dav-specific properties, and I'd like to note > > their existence in the DAV: field. The identifier could also be used by > > clients to detect the mod_dav version to work around problems or whatever. > > Anyhow... I want to return something like: > > > > DAV: 1,2, > > > > Does anybody have an issue with defining "extend" to contain at least the > > characters which are valid in a Coded-URL? > > Section 2.2 of RFC 2068 defines: >... [ defn of token ] ... > Hence, the above would be illegal, as it contains "<", ">", ":" and "/". > But one could propose to define (as I already did): > > extend = token | quoted-string ; token and quoted-string are > defined in [HTTP]. > > That would allow to put a URL into double-quotes. Hrm. I don't like that idea. I'd much rather see it be a URI explicitly. A quoted string doesn't help to prevent conflicts since you could simply place anything in there (same with tokens). And if servers are to use that field to express their own capabilities, then we should have a way to prevent conflicts. Specifically, I recommend: extend = absoluteURI Further, each of the WebDAV extension specs should alter their use of the DAV: header to use URIs for their items. For example: DAV:bindings or DAV:redirectrefs. Using "extend = Coded-URL" would also be fine, if people think the brackets are needed. (although it doesn't have to be a URL...) Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon Apr 10 15:51:05 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA01789 for ; Mon, 10 Apr 2000 15:51:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA17748; Mon, 10 Apr 2000 15:48:29 -0400 (EDT) Resent-Date: Mon, 10 Apr 2000 15:48:29 -0400 (EDT) Resent-Message-Id: <200004101948.PAA17748@www19.w3.org> To: Greg Stein cc: reuterj@ira.uka.de, jjh@ira.uka.de, w3c-dist-auth@w3.org In-reply-to: Your message of "Mon, 10 Apr 2000 04:33:15 PDT." Date: Mon, 10 Apr 2000 21:47:44 +0200 From: Juergen Reuter Message-ID: <"iraun1.ira.0089001:000410.194749"@ira.uka.de> Subject: Re: DAV: header values Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4238 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Greg Stein wrote: > Specifically, I recommend: > > extend = absoluteURI Unfortunately, this would make the lexical analysis ambigous, as, according to RFC 2068, an absoluteURI may contain a ",": absoluteURI = scheme ":" *( uchar | reserved ) uchar = unreserved | escape unreserved = ALPHA | DIGIT | safe | extra | national extra = "!" | "*" | "'" | "(" | ")" | "," Hence, when encountering a ",", you do not know if this is part of the absoluteURI, or if it is used to separate two absoluteURIs from each other as to the 1#extend rule. :-( Bye, Juergen From w3c-dist-auth-request@w3.org Mon Apr 10 17:25:10 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA04952 for ; Mon, 10 Apr 2000 17:25:10 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA20975; Mon, 10 Apr 2000 17:23:56 -0400 (EDT) Resent-Date: Mon, 10 Apr 2000 17:23:56 -0400 (EDT) Resent-Message-Id: <200004102123.RAA20975@www19.w3.org> To: reuterj@ira.uka.de cc: Greg Stein , jjh@ira.uka.de, w3c-dist-auth@w3.org In-reply-to: Your message of "Mon, 10 Apr 2000 21:47:44 +0200." <"iraun1.ira.0089001:000410.194749"@ira.uka.de> Date: Mon, 10 Apr 2000 23:23:36 +0200 From: Juergen Reuter Message-ID: <"iraun1.ira.0047201:000410.212348"@ira.uka.de> Subject: Re: DAV: header values Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4239 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list P.S.: However, the rule extend = Coded-URL should be fine, because the rule Coded-URL = "<" absoluteURI ">" implies that, as soon as you have encountered a "<", you can accept as many "," as you find, belonging all to the absoluteURI, until you finally reach a ">". (I suppose that is the reason why people think that the brackets are needed. :-)) Bye, Juergen From w3c-dist-auth-request@w3.org Mon Apr 10 17:32:45 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id RAA05116 for ; Mon, 10 Apr 2000 17:32:45 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA21309; Mon, 10 Apr 2000 17:31:14 -0400 (EDT) Resent-Date: Mon, 10 Apr 2000 17:31:14 -0400 (EDT) Resent-Message-Id: <200004102131.RAA21309@www19.w3.org> Date: Mon, 10 Apr 2000 14:36:50 -0700 (PDT) From: Greg Stein To: Juergen Reuter cc: jjh@ira.uka.de, w3c-dist-auth@w3.org In-Reply-To: <"iraun1.ira.0047201:000410.212348"@ira.uka.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: DAV: header values Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4240 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Mon, 10 Apr 2000, Juergen Reuter wrote: > P.S.: > > However, the rule > > extend = Coded-URL > > should be fine, because the rule > > Coded-URL = "<" absoluteURI ">" > > implies that, as soon as you have encountered a "<", you can > accept as many "," as you find, belonging all to the absoluteURI, > until you finally reach a ">". (I suppose that is the reason why > people think that the brackets are needed. :-)) Exactly! All righty then... I'll resubmit my proposal: extend = "<" absoluteURI ">" For semantic purposes, I expanded Coded-URL since we will certainly have URI values in there (e.g. DAV:bindings) rather than URLs. In an If: header, the "URL" term makes sense. Back to my original point, then: does anybody see a problem if I updated mod_dav to use the following DAV: header: DAV: 1,2, ?? Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon Apr 10 19:19:29 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA06497 for ; Mon, 10 Apr 2000 19:19:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA25932; Mon, 10 Apr 2000 19:17:48 -0400 (EDT) Resent-Date: Mon, 10 Apr 2000 19:17:48 -0400 (EDT) Resent-Message-Id: <200004102317.TAA25932@www19.w3.org> To: w3c-dist-auth@w3.org cc: reuterj@ira.uka.de, jjh@ira.uka.de Date: Tue, 11 Apr 2000 01:17:26 +0200 From: Juergen Reuter Message-ID: <"iraun1.ira.0089001:000410.231738"@ira.uka.de> Subject: Lock Tokens Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4241 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Hi, all! Section 12.1.2 of WebDAV defines: and says: "The href contains one or more opaque lock token URIs which all refer to the same lock (i.e., the OpaqueLockToken-URI production in section 6.4)." I wonder, in what cases there could actually occur multiple href elements and how they could be useful: * Section 6.3: "A lock token is a type of state token, represented as a [single?] URI, which identifies a particular lock." This contradicts the above definition. * Section 9.5: 'Lock-Token = "Lock-Token" ":" Coded-URL' ... "The Lock-Token response header is used with the LOCK method to indicate the lock token created as a result of a successful LOCK request to create a new lock." In other words, a server will return a *single* lock token URI as Coded-URL in the Lock-Token header. But what will be returned in the locktoken XML element of the corresponding response message body? The same single URI? Or all URIs? Section 6.3 says: "A lock token is returned by every successful LOCK operation in the lockdiscovery property in the response body ..." So, is the Lock-Token header needed at all? Anyway, what are multiple URIs for a single lock token useful for? * Section 13.8: Does the lockdiscovery property contain all URIs of a lock token? * Example 8.9.6: "In this example the client has submitted a number of lock tokens with the request." For better understanding, I propose to change the wording, maybe into something like: "In this example the client has submitted a number of lock token URIs with the request, where each URI represents a lock token." Otherwise, all the URIs could refer to the same, single lock token. * Section 8.10.4: "A successful result MUST return a single lock token ...", but this single lock token may contain multiple URIs, right? Comments? Bye, Juergen From w3c-dist-auth-request@w3.org Mon Apr 10 21:36:08 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA08449 for ; Mon, 10 Apr 2000 21:36:08 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA29519; Mon, 10 Apr 2000 21:34:55 -0400 (EDT) Resent-Date: Mon, 10 Apr 2000 21:34:55 -0400 (EDT) Resent-Message-Id: <200004110134.VAA29519@www19.w3.org> Date: Mon, 10 Apr 2000 18:40:37 -0700 (PDT) From: Greg Stein To: Juergen Reuter cc: w3c-dist-auth@w3.org, jjh@ira.uka.de In-Reply-To: <"iraun1.ira.0089001:000410.231738"@ira.uka.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Lock Tokens Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4242 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list IMO, a locktoken should be equivalent to a *single* URI. Of course, a given resource may have multiple tokens, but I see no reason to allow or provide for multiple URIs "in" a locktoken. I would agree/vote to remove all language in the spec dealing with multiple URIs in a locktoken. As a followup question: are any servers out there returning multiple URIs? [ note that we wouldn't break on the client side since we are simply stating that no more than one will ever be present -- we aren't changing the format in any way. ] Cheers, -g On Tue, 11 Apr 2000, Juergen Reuter wrote: > Hi, all! > > Section 12.1.2 of WebDAV defines: > > > > and says: > > "The href contains one or more opaque lock token URIs which all > refer to the same lock (i.e., the OpaqueLockToken-URI production in > section 6.4)." > > I wonder, in what cases there could actually occur multiple href > elements and how they could be useful: > > * Section 6.3: > "A lock token is a type of state token, represented as a [single?] URI, > which identifies a particular lock." > This contradicts the above definition. > > * Section 9.5: > 'Lock-Token = "Lock-Token" ":" Coded-URL' > ... > "The Lock-Token response header is used with the LOCK method to > indicate the lock token created as a result of a successful LOCK > request to create a new lock." > > In other words, a server will return a *single* lock token URI as > Coded-URL in the Lock-Token header. But what will be returned in > the locktoken XML element of the corresponding response message body? > The same single URI? Or all URIs? Section 6.3 says: "A lock token > is returned by every successful LOCK operation in the lockdiscovery > property in the response body ..." So, is the Lock-Token header > needed at all? Anyway, what are multiple URIs for a single lock token > useful for? > > * Section 13.8: > Does the lockdiscovery property contain all URIs of a lock token? > > * Example 8.9.6: > "In this example the client has submitted a number of lock tokens with > the request." > For better understanding, I propose to change the wording, maybe > into something like: > "In this example the client has submitted a number of lock token URIs > with the request, where each URI represents a lock token." > Otherwise, all the URIs could refer to the same, single lock token. > > * Section 8.10.4: "A successful result MUST return a single lock > token ...", but this single lock token may contain multiple URIs, > right? > > Comments? > > Bye, > Juergen > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue Apr 11 09:30:00 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA03187 for ; Tue, 11 Apr 2000 09:29:59 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA14996; Tue, 11 Apr 2000 09:28:43 -0400 (EDT) Resent-Date: Tue, 11 Apr 2000 09:28:43 -0400 (EDT) Resent-Message-Id: <200004111328.JAA14996@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA14964 for ; Tue, 11 Apr 2000 09:28:38 -0400 (EDT) Received: from e23.nc.us.ibm.com (e23.nc.us.ibm.com [32.97.136.229]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA04007 for ; Tue, 11 Apr 2000 09:28:39 -0400 From: jamsden@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e23.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA18936 for ; Tue, 11 Apr 2000 09:10:50 -0500 Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35]) by southrelay02.raleigh.ibm.com (8.8.8m3/NCO v2.07) with SMTP id JAA42862 for ; Tue, 11 Apr 2000 09:28:35 -0400 Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568BE.004A06D7 ; Tue, 11 Apr 2000 09:28:34 -0400 X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3c.org Message-ID: <852568BE.004A0375.00@d54mta03.raleigh.ibm.com> Date: Tue, 11 Apr 2000 09:23:52 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Lock Tokens Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4243 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Juergen, These are common locking problems. See some comments below in tags. |--------+----------------------------> | | Juergen Reuter | | | | | | Sent by: | | | w3c-dist-auth-requ| | | est@w3.org | | | | | | | | | 04/10/2000 07:17 | | | PM | | | | |--------+----------------------------> >----------------------------------------------------------------------| | | | To: w3c-dist-auth@w3.org | | cc: reuterj@ira.uka.de, jjh@ira.uka.de | | Subject: Lock Tokens | >----------------------------------------------------------------------| Hi, all! Section 12.1.2 of WebDAV defines: and says: "The href contains one or more opaque lock token URIs which all refer to the same lock (i.e., the OpaqueLockToken-URI production in section 6.4)." DAV4J only supports one at the moment, but I have a bug entry to fix this. Don't know when it will get done though. I wonder, in what cases there could actually occur multiple href elements and how they could be useful: I couldn't think of any. * Section 6.3: "A lock token is a type of state token, represented as a [single?] URI, which identifies a particular lock." This contradicts the above definition. * Section 9.5: 'Lock-Token = "Lock-Token" ":" Coded-URL' ... "The Lock-Token response header is used with the LOCK method to indicate the lock token created as a result of a successful LOCK request to create a new lock." In other words, a server will return a *single* lock token URI as Coded-URL in the Lock-Token header. But what will be returned in the locktoken XML element of the corresponding response message body? The same single URI? Or all URIs? Section 6.3 says: "A lock token is returned by every successful LOCK operation in the lockdiscovery property in the response body ..." So, is the Lock-Token header needed at all? Anyway, what are multiple URIs for a single lock token useful for? The Lock-Token header contains the lock just granted by the LOCK method. The XML element returns a lockdiscovery that contains all the (shared) lock tokens for the target resource. The Lock-Token header is needed because the activelock element of the lockdiscovery does not identify the principal owning the lock. The owner element is not an authentication id or principal. * Section 13.8: Does the lockdiscovery property contain all URIs of a lock token? It does. The question is, does an individual lock token entry contain more than one href. I don't see why. * Example 8.9.6: "In this example the client has submitted a number of lock tokens with the request." For better understanding, I propose to change the wording, maybe into something like: "In this example the client has submitted a number of lock token URIs with the request, where each URI represents a lock token." Otherwise, all the URIs could refer to the same, single lock token. * Section 8.10.4: "A successful result MUST return a single lock token ...", but this single lock token may contain multiple URIs, right? Comments? Bye, Juergen From w3c-dist-auth-request@w3.org Wed Apr 12 09:33:24 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA19532 for ; Wed, 12 Apr 2000 09:33:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA22384; Wed, 12 Apr 2000 09:28:50 -0400 (EDT) Resent-Date: Wed, 12 Apr 2000 09:28:50 -0400 (EDT) Resent-Message-Id: <200004121328.JAA22384@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id JAA22361 for ; Wed, 12 Apr 2000 09:28:45 -0400 (EDT) Received: from gw.atria.com (gw.atria.com [192.88.237.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id JAA02859 for ; Wed, 12 Apr 2000 09:28:45 -0400 Received: from 204.167.8.157 (tantalum.atria.com) by gw.atria.com id Wed, 12 Apr 2000 09:28:44 -0400 (EDT) Received: (from gclemm@localhost) by tantalum.atria.com (8.8.8+Sun/8.8.8) id JAA12379; Wed, 12 Apr 2000 09:28:38 -0400 (EDT) Date: Wed, 12 Apr 2000 09:28:38 -0400 (EDT) Message-Id: <200004121328.JAA12379@tantalum.atria.com> X-Authentication-Warning: tantalum.atria.com: gclemm set sender to geoffrey.clemm@rational.com using -f From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3c.org In-reply-to: <852568BE.004A0375.00@d54mta03.raleigh.ibm.com> (jamsden@us.ibm.com) References: <852568BE.004A0375.00@d54mta03.raleigh.ibm.com> Subject: Re: Lock Tokens Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4244 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: From: jamsden@us.ibm.com ... a server will return a *single* lock token URI as Coded-URL in the Lock-Token header. But what will be returned in the locktoken XML element of the corresponding response message body? The same single URI? Or all URIs? Section 6.3 says: "A lock token is returned by every successful LOCK operation in the lockdiscovery property in the response body ..." So, is the Lock-Token header needed at all? Anyway, what are multiple URIs for a single lock token useful for? The Lock-Token header contains the lock just granted by the LOCK method. The XML element returns a lockdiscovery that contains all the (shared) lock tokens for the target resource. The Lock-Token header is needed because the activelock element of the lockdiscovery does not identify the principal owning the lock. The owner element is not an authentication id or principal. The request principal could have several locks on the same resource, so the Lock-Token header would be needed whether or not the activelock element of the lockdiscovery identified the principal owning the lock. Cheers, Geoff From w3c-dist-auth-request@w3.org Thu Apr 13 07:52:06 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id HAA27435 for ; Thu, 13 Apr 2000 07:52:06 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA24639; Thu, 13 Apr 2000 07:46:11 -0400 (EDT) Resent-Date: Thu, 13 Apr 2000 07:46:11 -0400 (EDT) Resent-Message-Id: <200004131146.HAA24639@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id HAA24619 for ; Thu, 13 Apr 2000 07:46:07 -0400 (EDT) Received: from nebula.lyra.org (IDENT:gstein@nebula.lyra.org [216.98.236.100]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id HAA25369 for ; Thu, 13 Apr 2000 07:46:07 -0400 Received: from localhost (gstein@localhost) by nebula.lyra.org (8.9.3/8.9.3) with ESMTP id EAA06760 for ; Thu, 13 Apr 2000 04:51:59 -0700 Date: Thu, 13 Apr 2000 04:51:59 -0700 (PDT) From: Greg Stein To: w3c-dist-auth@w3.org Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Puzzle: DELETE of a locked collection Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4245 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Consider the following directory structure: Collection [locked with token A, depth=0] \ SubCollection [locked with token B, depth=infinity] \ File1 File2 [these inherit token B] ... FileN Now, how do you delete SubCollection? Note that you must provide token A to remove SubCollection from Collection. Also, you must provide token B for SubCollection *and* File1..N. What's the IF: header look like? (presume that you cannot delineate all the (recursive) members of SubCollection and insert them *all* into the IF: header) I can't see a way to do it. Normally, no-tag-lists are used for specifying locks for a hierarchy. But you must use a tagged-list to specify token A. Ideas? Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Apr 13 10:14:26 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id KAA02731 for ; Thu, 13 Apr 2000 10:14:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA00746; Thu, 13 Apr 2000 10:01:13 -0400 (EDT) Resent-Date: Thu, 13 Apr 2000 10:01:13 -0400 (EDT) Resent-Message-Id: <200004131401.KAA00746@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id KAA00725 for ; Thu, 13 Apr 2000 10:01:09 -0400 (EDT) Received: from e21.nc.us.ibm.com (e21.nc.us.ibm.com [32.97.136.227]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id KAA06434 for ; Thu, 13 Apr 2000 10:01:09 -0400 From: jamsden@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e21.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id JAA37280 for ; Thu, 13 Apr 2000 09:52:29 -0500 Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.06) with SMTP id KAA46598 for ; Thu, 13 Apr 2000 10:01:07 -0400 Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568C0.004D00DA ; Thu, 13 Apr 2000 10:01:04 -0400 X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3c.org Message-ID: <852568C0.004C2030.00@d54mta03.raleigh.ibm.com> Date: Thu, 13 Apr 2000 09:51:30 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Puzzle: DELETE of a locked collection Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4246 X-Loop: w3c-dist-auth@w3.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 guess it depends on what it means to delete a collection with a depth infinity lock. You could specify a tagged list in the If header containing a token for A and B. Then when deleting B, you'll get a match on the lock tokin in the tagged If header. So the question is, will you also have to provide tagged lock tokens for all the files in B in order to match on them, or is the match implicit because the match occurred on the same lock token on the parent collection. I don't know the answer. DAV4J would probably fail unless you had all the locktokens for all the items to be deleted in tagged If headers. That's because 1) you can't mix tagged and non-tagged lists in the same If header and 2) if a tag is specified, it must match. |--------+----------------------------> | | Greg Stein | | | | | | Sent by: | | | w3c-dist-auth-requ| | | est@w3.org | | | | | | | | | 04/13/2000 07:51 | | | AM | | | | |--------+----------------------------> >-----------------------------------------------------------------------| | | | To: w3c-dist-auth@w3.org | | cc: | | Subject: Puzzle: DELETE of a locked collection | >-----------------------------------------------------------------------| Consider the following directory structure: Collection [locked with token A, depth=0] \ SubCollection [locked with token B, depth=infinity] \ File1 File2 [these inherit token B] ... FileN Now, how do you delete SubCollection? Note that you must provide token A to remove SubCollection from Collection. Also, you must provide token B for SubCollection *and* File1..N. What's the IF: header look like? (presume that you cannot delineate all the (recursive) members of SubCollection and insert them *all* into the IF: header) I can't see a way to do it. Normally, no-tag-lists are used for specifying locks for a hierarchy. But you must use a tagged-list to specify token A. Ideas? Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Apr 13 11:20:56 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id LAA04480 for ; Thu, 13 Apr 2000 11:20:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA06914; Thu, 13 Apr 2000 11:19:21 -0400 (EDT) Resent-Date: Thu, 13 Apr 2000 11:19:21 -0400 (EDT) Resent-Message-Id: <200004131519.LAA06914@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id LAA06894 for ; Thu, 13 Apr 2000 11:19:17 -0400 (EDT) Received: from gw.atria.com (gw.atria.com [192.88.237.2]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id LAA20489 for ; Thu, 13 Apr 2000 11:19:17 -0400 Received: from 204.167.8.157 (tantalum.atria.com) by gw.atria.com id Thu, 13 Apr 2000 11:19:16 -0400 (EDT) Received: (from gclemm@localhost) by tantalum.atria.com (8.8.8+Sun/8.8.8) id LAA13908; Thu, 13 Apr 2000 11:19:10 -0400 (EDT) Date: Thu, 13 Apr 2000 11:19:10 -0400 (EDT) Message-Id: <200004131519.LAA13908@tantalum.atria.com> X-Authentication-Warning: tantalum.atria.com: gclemm set sender to geoffrey.clemm@rational.com using -f From: "Geoffrey M. Clemm" To: w3c-dist-auth@w3.org In-reply-to: (message from Greg Stein on Thu, 13 Apr 2000 04:51:59 -0700 (PDT)) References: Subject: Re: Puzzle: DELETE of a locked collection Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4247 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Greg's question illustrates something that I believe is inherently broken in the current WebDAV approach to operating against write-locked resources. When you are performing an operation against write-locked resources, all you should be required to do is to include the appropriate list of lock-tokens with your request. The semantics is then very simple: If any of the resources that your request attempts to modify is locked with a lock token not in your list, the request fails. Instead of this simple list, 2518 gives us the wonderfully baroque (pronounced "broke" :-) If header, which lets us do ands and ors and nots of state tokens and entity tags, and even tag the expressions with the resource it should apply to, but does not in fact let us do the one thing we really want to do, namely identify a list of lock tokens. The answer I'd like us to make is that you can include an arbitrary number of Lock-Token headers with a request, and this defines the lock token list for your request (no If header required). Until then, as far as I can tell, 2518 requires Greg to do the obviously non-scalable insertion of a tagged list for *every* member of the collection being moved in the If header. Cheers, Geoff Date: Thu, 13 Apr 2000 04:51:59 -0700 (PDT) From: Greg Stein Consider the following directory structure: Collection [locked with token A, depth=0] \ SubCollection [locked with token B, depth=infinity] \ File1 File2 [these inherit token B] ... FileN Now, how do you delete SubCollection? Note that you must provide token A to remove SubCollection from Collection. Also, you must provide token B for SubCollection *and* File1..N. What's the IF: header look like? (presume that you cannot delineate all the (recursive) members of SubCollection and insert them *all* into the IF: header) I can't see a way to do it. Normally, no-tag-lists are used for specifying locks for a hierarchy. But you must use a tagged-list to specify token A. Ideas? Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Apr 13 16:18:02 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13073 for ; Thu, 13 Apr 2000 16:18:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA20630; Thu, 13 Apr 2000 16:13:05 -0400 (EDT) Resent-Date: Thu, 13 Apr 2000 16:13:05 -0400 (EDT) Resent-Message-Id: <200004132013.QAA20630@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA20606 for ; Thu, 13 Apr 2000 16:13:00 -0400 (EDT) Received: from nebula.lyra.org (IDENT:gstein@nebula.lyra.org [216.98.236.100]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA30944 for ; Thu, 13 Apr 2000 16:12:59 -0400 Received: from localhost (gstein@localhost) by nebula.lyra.org (8.9.3/8.9.3) with ESMTP id NAA11773 for ; Thu, 13 Apr 2000 13:18:59 -0700 Date: Thu, 13 Apr 2000 13:18:59 -0700 (PDT) From: Greg Stein To: w3c-dist-auth@w3.org In-Reply-To: <200004131519.LAA13908@tantalum.atria.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Puzzle: DELETE of a locked collection Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4248 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Thu, 13 Apr 2000, Geoffrey M. Clemm wrote: >... > The answer I'd like us to make is that you can include an arbitrary > number of Lock-Token headers with a request, and this defines the > lock token list for your request (no If header required). Agreed. Go one step further, then: if you do not use IF: to specify lock tokens, it is only good for etags. If that is the case, then we have If-Match in HTTP/1.1. Why keep the IF: header? :-) > Until then, as far as I can tell, 2518 requires Greg to do the > obviously non-scalable insertion of a tagged list for *every* member > of the collection being moved in the If header. Based on feedback from some people on the dav-dev mailing list, I'm going to do the following: *) if a tagged-list state-list specifies a URL and its locktoken, then the state-list will be applied to the internal members (to the extend of the lock depth). this will effectively replicate the state list down to all affected members. (any existing tagged-list for an internal member will override this implied state-list) This should solve the problem, even if it isn't "strictly" by-the-book. I have no idea how hard this will be, but I'll dig in and try it... Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Apr 13 16:34:27 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA13463 for ; Thu, 13 Apr 2000 16:34:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA21464; Thu, 13 Apr 2000 16:29:13 -0400 (EDT) Resent-Date: Thu, 13 Apr 2000 16:29:13 -0400 (EDT) Resent-Message-Id: <200004132029.QAA21464@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id QAA21442 for ; Thu, 13 Apr 2000 16:29:08 -0400 (EDT) Received: from iraun1.ira.uka.de (iraun1.ira.uka.de [129.13.10.90]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id QAA00566 for ; Thu, 13 Apr 2000 16:29:08 -0400 Received: from ira.uka.de (actually i43fs2.ira.uka.de) by iraun1 (PP) with ESMTP; Thu, 13 Apr 2000 22:29:04 +0200 To: w3c-dist-auth@w3c.org cc: reuterj@ira.uka.de, jjh@ira.uka.de In-reply-to: Your message of "Thu, 13 Apr 2000 11:19:10 EDT." <200004131519.LAA13908@tantalum.atria.com> Date: Thu, 13 Apr 2000 22:29:00 +0200 From: Juergen Reuter Message-ID: <"iraun1.ira.0021601:000413.202905"@ira.uka.de> Subject: Re: Puzzle: DELETE of a locked collection Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4249 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Please, remember that: "Multiple message-header fields with the same field-name may be present in a message if and only if the entire field-value for that header field is defined as a comma-separated list [i.e., #(values)]" (RFC 2068, section 4.2). Hence, following Geoffrey's thoughts, it may be reasonable to redefine the Lock-Token header as follows: Lock-Token = "Lock-Token" ":" 1#Coded-URL Bye, Juergen Geoffrey M. Clemm wrote: > The answer I'd like us to make is that you can include an arbitrary > number of Lock-Token headers with a request > ... jamsden@us.ibm.com wrote: > That's because 1) you can't mix tagged and > non-tagged lists in the same If header > ... From w3c-dist-auth-request@w3.org Thu Apr 13 19:03:22 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15605 for ; Thu, 13 Apr 2000 19:03:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA28100; Thu, 13 Apr 2000 18:59:02 -0400 (EDT) Resent-Date: Thu, 13 Apr 2000 18:59:02 -0400 (EDT) Resent-Message-Id: <200004132259.SAA28100@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id SAA28080 for ; Thu, 13 Apr 2000 18:58:58 -0400 (EDT) Received: from nebula.lyra.org (IDENT:gstein@nebula.lyra.org [216.98.236.100]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id SAA19724 for ; Thu, 13 Apr 2000 18:58:58 -0400 Received: from localhost (gstein@localhost) by nebula.lyra.org (8.9.3/8.9.3) with ESMTP id QAA15120 for ; Thu, 13 Apr 2000 16:05:01 -0700 Date: Thu, 13 Apr 2000 16:05:00 -0700 (PDT) From: Greg Stein To: w3c-dist-auth@w3.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Puzzle: DELETE of a locked collection Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4250 X-Loop: w3c-dist-auth@w3.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 believe that I have an answer to this. The trick is to realize that a no-tag-list can specify a set of OR'd states. So the answer is: If: () () (Not ) (Not ) Ugly, but it basically means that every resource will match something, and that the lock token is provided to navigate through the lock. Eek. -g On Thu, 13 Apr 2000, Greg Stein wrote: > Consider the following directory structure: > > Collection [locked with token A, depth=0] > \ > SubCollection [locked with token B, depth=infinity] > \ > File1 > File2 [these inherit token B] > ... > FileN > > > Now, how do you delete SubCollection? > > Note that you must provide token A to remove SubCollection from > Collection. Also, you must provide token B for SubCollection *and* > File1..N. > > What's the IF: header look like? > > (presume that you cannot delineate all the (recursive) members of > SubCollection and insert them *all* into the IF: header) > > I can't see a way to do it. Normally, no-tag-lists are used for specifying > locks for a hierarchy. But you must use a tagged-list to specify token A. > > Ideas? > > Cheers, > -g > > -- > Greg Stein, http://www.lyra.org/ > > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Apr 13 19:21:13 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA15707 for ; Thu, 13 Apr 2000 19:21:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA28562; Thu, 13 Apr 2000 19:11:01 -0400 (EDT) Resent-Date: Thu, 13 Apr 2000 19:11:01 -0400 (EDT) Resent-Message-Id: <200004132311.TAA28562@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id TAA28539 for ; Thu, 13 Apr 2000 19:10:57 -0400 (EDT) Received: from nebula.lyra.org (IDENT:gstein@nebula.lyra.org [216.98.236.100]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id TAA21157 for ; Thu, 13 Apr 2000 19:10:57 -0400 Received: from localhost (gstein@localhost) by nebula.lyra.org (8.9.3/8.9.3) with ESMTP id QAA16108; Thu, 13 Apr 2000 16:17:00 -0700 Date: Thu, 13 Apr 2000 16:17:00 -0700 (PDT) From: Greg Stein To: w3c-dist-auth@w3.org cc: dav-dev@lyra.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Puzzle: DELETE of a locked collection Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4251 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: Oh. I found Yet Another Bastard Solution. S9.4.2 specifies that if no Tagged-list matches the resource [URI], then the If: header should be ignored. S7.6 simply states that lock tokens must be supplied in an If: header. It says nothing about them being supplied in a *matching* Tagged-list or No-tag-list. Therefore, the following If: header should *always* succeed: If: ( ) Good fun, huh? Okay. So we have found a way to circumvent the *intent* of the spec, but what is the true answer here? What *should* be the specification? IMO, the above form is just like submitting a Lock-Token header with a list of locktokens. We should use the Lock-Token header. This is not required, but I highly recommend it: also throw out the If: header. The damn thing is complicated as all hell. I've got a couple thousand lines of code just to deal with the bugger. And it is *still* not processing it correctly despite many revisions, refinements, and a couple people working on it. Call us bad coders, but I like to think it is just because the thing is too complex and possibly unclearly specified. Cheers, -g On Thu, 13 Apr 2000, Greg Stein wrote: > I believe that I have an answer to this. The trick is to realize that a > no-tag-list can specify a set of OR'd states. So the answer is: > > If: () () (Not ) (Not ) > > Ugly, but it basically means that every resource will match something, and > that the lock token is provided to navigate through the lock. > > Eek. > > -g > > > On Thu, 13 Apr 2000, Greg Stein wrote: > > Consider the following directory structure: > > > > Collection [locked with token A, depth=0] > > \ > > SubCollection [locked with token B, depth=infinity] > > \ > > File1 > > File2 [these inherit token B] > > ... > > FileN > > > > > > Now, how do you delete SubCollection? > > > > Note that you must provide token A to remove SubCollection from > > Collection. Also, you must provide token B for SubCollection *and* > > File1..N. > > > > What's the IF: header look like? > > > > (presume that you cannot delineate all the (recursive) members of > > SubCollection and insert them *all* into the IF: header) > > > > I can't see a way to do it. Normally, no-tag-lists are used for specifying > > locks for a hierarchy. But you must use a tagged-list to specify token A. > > > > Ideas? > > > > Cheers, > > -g > > > > -- > > Greg Stein, http://www.lyra.org/ > > > > > > > > -- > Greg Stein, http://www.lyra.org/ > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu Apr 13 20:39:07 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16506 for ; Thu, 13 Apr 2000 20:39:07 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA00283; Thu, 13 Apr 2000 20:37:05 -0400 (EDT) Resent-Date: Thu, 13 Apr 2000 20:37:05 -0400 (EDT) Resent-Message-Id: <200004140037.UAA00283@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA00255 for ; Thu, 13 Apr 2000 20:36:59 -0400 (EDT) Received: from e24.nc.us.ibm.com (e24.nc.us.ibm.com [32.97.136.230]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA28008 for ; Thu, 13 Apr 2000 20:36:59 -0400 From: jamsden@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e24.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id UAA31266 for ; Thu, 13 Apr 2000 20:24:49 -0500 Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.06) with SMTP id UAA48986 for ; Thu, 13 Apr 2000 20:36:57 -0400 Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568C1.00035E79 ; Thu, 13 Apr 2000 20:36:47 -0400 X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3c.org Message-ID: <852568C1.00035D18.00@d54mta03.raleigh.ibm.com> Date: Thu, 13 Apr 2000 20:36:16 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Puzzle: DELETE of a locked collection Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4252 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: *) if a tagged-list state-list specifies a URL and its locktoken, then the state-list will be applied to the internal members (to the extend of the lock depth). this will effectively replicate the state list down to all affected members. (any existing tagged-list for an internal member will override this implied state-list) I think this is a bad thing as it will result in lots of confusion about what token is supposed to match with what resource. It is possible that this will result in overwrite conflicts when applied to depth locks on collections. I think the If header does work as I suggested in a previous email. You'll have to know the members that are to be targeted by the tag list ahead of time, and suffer the inconvenience of putting them all in a potentially long If header, but computers are good at handling such things. It might also not be such a bad idea to know exactly, and proactively, what you're doing when dealing with locked resources. But I'm happy to use the Lock-Token header for lock tokens too. I think it will have similar problems though. The problem is really with those pesky depth locks. From w3c-dist-auth-request@w3.org Thu Apr 13 20:55:28 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id UAA16654 for ; Thu, 13 Apr 2000 20:55:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA00915; Thu, 13 Apr 2000 20:54:21 -0400 (EDT) Resent-Date: Thu, 13 Apr 2000 20:54:21 -0400 (EDT) Resent-Message-Id: <200004140054.UAA00915@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id UAA00894 for ; Thu, 13 Apr 2000 20:54:17 -0400 (EDT) Received: from nebula.lyra.org (IDENT:gstein@nebula.lyra.org [216.98.236.100]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id UAA29998 for ; Thu, 13 Apr 2000 20:54:17 -0400 Received: from localhost (gstein@localhost) by nebula.lyra.org (8.9.3/8.9.3) with ESMTP id SAA19879; Thu, 13 Apr 2000 18:00:20 -0700 Date: Thu, 13 Apr 2000 18:00:20 -0700 (PDT) From: Greg Stein To: jamsden@us.ibm.com cc: w3c-dist-auth@w3.org In-Reply-To: <852568C1.00035D18.00@d54mta03.raleigh.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Puzzle: DELETE of a locked collection Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4253 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list List-Id: List-Help: List-Unsubscribe: On Thu, 13 Apr 2000 jamsden@us.ibm.com wrote: > > *) if a tagged-list state-list specifies a URL and its locktoken, then the > state-list will be applied to the internal members (to the extend of > the lock depth). this will effectively replicate the state list down to > all affected members. > (any existing tagged-list for an internal member will override this > implied state-list) > > > I think this is a bad thing as it will result in lots of confusion about > what token is supposed to match with what resource. It is possible that > this will result in overwrite conflicts when applied to depth locks on > collections. Sorry, but this whole thing is confusing in the first place. Moreover, the spec simply states that I need to pass along the proper lock tokens. It says nothing about associating those tokens appropriately with each resource that I'm going to modify. Further, I don't see the possible overwrite conflict you're talking about. The algorithm that I stated above simply says that File1..N (from my example) will implicitly have an assertion about Token B. Not Token A. > I think the If header does work as I suggested in a previous email. You'll > have to know the members that are to be targeted by the tag list ahead of > time, and suffer the inconvenience of putting them all in a potentially > long If header, but computers are good at handling such things. I refuse this concept absolutely. There is no way that I will force a client to know all members recursively before they issue a DELETE of a locked collection. That is positively ridiculous. It is no big deal, though. I've already found other mechanisms that work around the current specification. To eliminate this "nasty work around", it looks like there is a consensus building for a Lock-Token header that contains the union of all tokens in the affected resources. > It might > also not be such a bad idea to know exactly, and proactively, what you're > doing when dealing with locked resources. I think it's a bad idea, and I'll advocate that clients use one of the If: header hacks that I've posted, rather than delineating all members. Heck, it seems like I recall hearing that some proxies even have limits on the size of the headers that they will process. > But I'm happy to use the Lock-Token header for lock tokens too. I think it > will have similar problems though. The problem is really with those pesky > depth locks. Partly. It is also partly caused by an unclear spec. We've been assuming that you must associate the locktoken with the appropriate resource. This isn't necessarily true. Of course, a person *does* want to assert they still hold a lock on a particular resource when they do an operation, so a Tagged-list is usually a good idea. But they can handle that with: If: () () In this case, none of the productions will match File1..N, so the If: header assertions are ignored for those resources. But: the necessary tokens for File1..N is present (B), so the operation succeeds. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Apr 14 14:40:05 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA12782 for ; Fri, 14 Apr 2000 14:40:05 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA26585; Fri, 14 Apr 2000 14:34:55 -0400 (EDT) Resent-Date: Fri, 14 Apr 2000 14:34:55 -0400 (EDT) Resent-Message-Id: <200004141834.OAA26585@www19.w3.org> Received: from tux.w3.org (tux.w3.org [18.29.0.27]) by www19.w3.org (8.9.0/8.9.0) with ESMTP id OAA26561 for ; Fri, 14 Apr 2000 14:34:50 -0400 (EDT) Received: from e22.nc.us.ibm.com (e22.nc.us.ibm.com [32.97.136.228]) by tux.w3.org (8.9.3/8.9.3) with ESMTP id OAA25840 for ; Fri, 14 Apr 2000 14:34:51 -0400 From: jamsden@us.ibm.com Received: from southrelay02.raleigh.ibm.com (southrelay02.raleigh.ibm.com [9.37.3.209]) by e22.nc.us.ibm.com (8.9.3/8.9.3) with ESMTP id OAA11460 for ; Fri, 14 Apr 2000 14:15:53 -0500 Received: from d54mta03.raleigh.ibm.com (d54mta03.raleigh.ibm.com [9.67.228.35]) by southrelay02.raleigh.ibm.com (8.8.8m2/NCO v2.06) with SMTP id OAA40458 for ; Fri, 14 Apr 2000 14:34:48 -0400 Received: by d54mta03.raleigh.ibm.com(Lotus SMTP MTA v4.6.5 (863.2 5-20-1999)) id 852568C1.00660EAF ; Fri, 14 Apr 2000 14:34:44 -0400 X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3c.org Message-ID: <852568C1.00660B28.00@d54mta03.raleigh.ibm.com> Date: Fri, 14 Apr 2000 14:34:11 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: RE: [ACL] Where are we here? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4254 X-Loop: w3c-dist-auth@w3.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: Thanks for the update. I now propose: 1) that ACLs are not needed to ADMINISTER (isn't this what you mean by authoring?) access. Interoperability for getting and setting ACLs will improve the ability of many client applications to interact with many repository managers through WebDAV. I think we do need interoperable administration, but this does not mean that this is the only thing WebDAV ACLs could do. 2) that relying on the "handslap" approach (the server refuses to perform the requested operation) as the main approach to authoring operations is wrong. WebDAV is extensions to HTTP which already uses a challenge/response paradigm. Changing this will significantly delay acceptance of the WebDAV spec. However, this does not mean that challenge/response cannot be augmented by proactive access management by clients based on available ACL information. What it means is that no matter what the client might think at the moment, the server will always use challenge/response. That is, a client might discover (doesn't matter how) the current permissions on a resource, adjust its UI accordingly, subsequently attempt to access the resource, and have the request refused because the ACLs on the resource have changed since the client did the discovery. 3) we bring the permission scheme forward. I'm not against additional methods to provide more proactive access management in clients, but 1)I don't think it is necessary, ACL queries provide the capability although not in the most convenient manner, 2) proactive ACL management with additional methods or using ACL discovery cannot eliminate the challenge/response behavior of the server as this is fundamental to a distributed environment where information is cached and can become stale, 3) I don't think it is advisable to hold up the ACL spec to resolve these non-fundamental issues. ============================================================================ 1) I suggest that administration of access can be performed by a write-only operation. This means that I request to set the access level/rights for a principal, and get only a set/refused response. This hides who has what rights to the document (otherwise a security breach). If you like the image of writing an ACL as the way to model this operation, I can live with that. It also removes the need for a client app. to decode the list. Reading the ACL may be supported (or not) if the server wishes to permit the client to display the information, but is not required, and has no connection to setting access. This permits incomplete ACLs to be returned as well. This is an interesting idea and does resolve some important issues. I believe that the meaning of the principal identifier (group, individual, network service, ...) should be tied to directory and authentication standards. Once again, a client would not be required or expected to see any or all principle identifiers. I agree with this. 2) A WEBDAV client must handle rejection but does not expect it as the common case. I look to applications setting appropriate expectations, within the validity of asynchronous changes (after I look, someone else changes the state). Agreed 3) Since business demands forced me to miss the last 2 calls, I would just like to know that permissions are not optional, and will be addressed before we submit a draft. Thanks folks Bernard Chester -----Original Message----- From: acl-admin@webdav.org [mailto:acl-admin@webdav.org]On Behalf Of Geoffrey M. Clemm Sent: Friday, April 14, 2000 8:48 AM To: acl@webdav.org Subject: Re: [ACL] Where are we here? From: "Bernard Chester" I thought we had a majority agreed on a "Train 1" approach which does not require ACLs, but does require describing the Boolean data and/or functions to set/get rights on the resource. The general philosophy was for the server to tell us what was possible (or not) and not to compute it on the client. I still see comments about expanding group ACEs. What's up? Train #1 did not remove ACL's. It just said that the purpose of reading an ACL was only for "ACL authoring", i.e. for clients that want to modify the ACL of a resource. This is in contrast to Train#2 which said that ACL's were also to be read/understandable by clients that wanted to know "what am I allowed to do with this resource. So we appear to be agreed that we will focus initially on authoring ACL's, and leave it up to the server for applying the ACL's appropriately, and conveying information back to the user when an ACL is violated. So reading ACL's (and understanding owners and principals) are of interest to the extent that they support authoring of the ACL's. As for a client finding out what it can do, I believe we agreed to defer that. The main use cases are: - client wants to modify an ACL (and may need to read the ACL to figure out how to set it). - client does some operation and the ACL's are enforced by the server. Cheers, Geoff _______________________________________________ acl mailing list acl@webdav.org http://mailman.webdav.org/mailman/listinfo/acl _______________________________________________ acl mailing list acl@webdav.org http://mailman.webdav.org/mailman/listinfo/acl From w3c-dist-auth-request@w3.org Mon Apr 17 13:12:55 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA06137 for ; Mon, 17 Apr 2000 13:12:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA07719; Mon, 17 Apr 2000 13:10:56 -0400 (EDT) Resent-Date: Mon, 17 Apr 2000 13:10:56 -0400 (EDT) Resent-Message-Id: <200004171710.NAA07719@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Mon, 17 Apr 2000 13:10:12 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: Call for volunteers: DAV Searching and Locating Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4255 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Given the number of people on this mailing list, there are undoubtedly some that haven't heard about the DAV Searching and Locating (DASL) group. I'm writing to let you know a little bit about the group, and to encourage you to sign up for the mailing list, and to participate in the development of the DASL protocol. The goal of DASL is to develop a protocol for remotely searching WebDAV repositories. The DASL protocol will provide a new navigation mechanism, adding to the existing hypertext point-and-click navigation, and hierarchical collection navigation (introduced by WebDAV), for getting to the resources you want to remotely author. It differs from search engines in that a search against an Internet search engine typically searches a cached, and often stale view of the Internet, while DASL searches a single repository (or group of cooperating repositories) using the exact contents as of the moment of the search, providing a very fresh search result. DASL becomes increasingly important as DAV repositories start to hold large numbers of documents (tens, hundreds, and millions of documents), where hypertext and hierarchical navigation do not work as effectively. Thus, DASL is a critical piece of technology as WebDAV matures, and more documents are available via WebDAV. Furthermore, DASL enables new kinds of applications to be created using WebDAV. Consider the Napster program. Napster, using a proprietary, non-open network protocol, provides a centralized metadata database, which remote clients search to find the location of a MP3 (or other) file. Once the file is found, the Napster client downloads the file from the same machine running the client, using the Napster protocol. Using DASL, it would be possible to construct a Napster clone using off-the-shelf DAV technology -- we could call it "DAVster". A DAVster client would register the resources (MP3 songs) it wanted to share with a remote DAV server, storing only metadata on the remote server -- the shared resource (song) itself would be located on an HTTP server someplace on the net, either on the user's local machine, or, better yet, on a remote Web server. When it wanted to see what else was available, the DAVster client would perform a DASL search against the metadata server. The search response would give the locations, as URLs, of the resources (songs) matching the query. The DAVster client would then do an HTTP GET against the returned URL(s) to retrieve the desired resource (MP3 song). Since HTTP is being used, it is possible to take advantage of HTTP caching as well, reducing bandwidth consumption, a current problem with Napster. For more information on DASL, you can consult the DASL home page: http://www.webdav.org/dasl/ The DASL mailing list is: www-webdav-dasl@w3.org To join the mailing list, send a message to www-webdav-dasl-request@w3.org (that is, the name of the list address, with "-request" added), with a message subject of "subscribe" (that is, the subject line in your mail software should say "subscribe"). Much work has already taken place on DASL, but recently this work has slowed down. We need just a few more volunteers to help resolve a relatively small set of open issues, and to review the protocol specification. I think it's pretty close to completion, and the work will go much faster once you add your efforts to this cause. So, if you have a few spare cycles, please consider joining the DASL working group, and helping this protocol to completion. - Jim From w3c-dist-auth-request@w3.org Mon Apr 17 16:05:25 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA08801 for ; Mon, 17 Apr 2000 16:05:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA11564; Mon, 17 Apr 2000 16:03:04 -0400 (EDT) Resent-Date: Mon, 17 Apr 2000 16:03:04 -0400 (EDT) Resent-Message-Id: <200004172003.QAA11564@www19.w3.org> Date: Mon, 17 Apr 2000 13:09:03 -0700 (PDT) From: Greg Stein To: "Hall, Shaun" cc: "'Mod_dav Mailing List'" , w3c-dist-auth@w3.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RE: [dav-dev] Deleting a locked collection Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4256 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Mon, 17 Apr 2000, Hall, Shaun wrote: >... > >> IF (lock token A) > >> (lock token B) >... > >Actually, this should succeed :-) > > >If there are no matching tagged-list productions, then the server should > >act as if the If: header is not present (S9.4.2, 2nd Para, 2nd sentence). > >S7.6 states that the locktoken (B in this case) must be submitted in the > >If: header. It was, so the children pass. > > My interpretation is that it should fail. Agreed about the IF header is not > present, it will be ignored. However, when the children are tested for a > corresponding lock token for the operation (DELETE), there is no matching > lock token (as effectively there is no IF) and therefore the operation > (DELETE) would fail. It should act as if it wasn't present, but I'm interpreting it to mean that it won't use it for precondition checking. But: that it is available for looking for locktokens. The whole point of submitting a locktoken is to show that you "know" the correct locktoken for the resource. Consider the scenario presented in S7.6. There are two operations that are occurring: 1) assertions are made about specified resources (Parent and Target in this case) 2) locktokens are provided for the relevant locks, to show that the client is aware of what they are doing Since there were no matching productions for the children, there are no assertions (1) to be made about them. We must still satisfy (2) and looking into that If: header is sufficient. > Looking at the W3C list as well, why are people suggesting to extend the > Lock-Token header to support multiple lock tokens when the no-tag-list does > exactly this (it is the same principle in my opinion)? Am I missing > something here (please correct me if I am)? You are quite correct. The If: header with a no-tag-list does most of the work. But if Target had a depth==0, then the If: header would also need some "Not" productions in there (per one of my posts to w3c-dist-auth). I think the Lock-Token header thing was possible a reaction/solution to the If: problem. Breaking the problem into the two parts that I list above, it becomes *very* apparent that we want to make the Lock-Token header change. 1) assertions -- handled by If: 2) provisions -- handled by Lock-Token: >... > PS I'm not trying to argue with all these emails, just trying to clarify the > RFC. Me neither :-) ... yes, this stuff is complicated and unclear. These emails are great for elucidating the spec. I believe we are just about there. > PPS Perhaps these things should just be discussed on the W3C-dist-auth list > and taken off this list as these are RFC clarifications, not mod_dav > specific. What do you think? I've CC'd the main list. Conversation is fine here, as long we present some final data to the main list along with background/conclusions/etc. Specifically, if we recommend changing the Lock-Token header then that conversation should occur on w3c-dist-auth. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed Apr 19 12:38:19 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id MAA09687 for ; Wed, 19 Apr 2000 12:38:18 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA20168; Wed, 19 Apr 2000 12:34:16 -0400 (EDT) Resent-Date: Wed, 19 Apr 2000 12:34:16 -0400 (EDT) Resent-Message-Id: <200004191634.MAA20168@www19.w3.org> Message-ID: From: "Hall, Shaun" To: "'W3C WebDAV List'" Date: Wed, 19 Apr 2000 17:29:25 +0100 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: WebDAV COPY/MOVE Question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4257 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Greetings, I have a couple of questions regarding the WebDAV RFC 2518, specifically the COPY (and MOVE) operations for collections. I'll just refer to the COPY sections in the RFC, but Question 1) is applicable for MOVE as well. Question 1) COPY (and MOVE) with infinite Depth: a) Section 8.8.3: i) 2nd para, 1st sentence states "A COPY of depth infinity instructs that the collection resource identified by the Request-URI is to be copied to the location identified by the URI in the Destination header, and all its internal member resources...". ii) 5th para, 2nd sentence states "When applied to members of the collection identified by the Request-URI the value of the Destination is to be modified to reflect the current location in the hierarchy." The example shows source is /a, destination is /b, when copying /a/c/d, the destination is /b/c/d. b) Section 8.8.8 Example of a COPY of a collection appears to perform in principle the example in a) ii) above. We interpret a) i) to mean that the source collection and its members are copied to the destination. Taking the RFC example in a) ii), i.e. the source is /a/c/d and destination is /b. Possible outcomes we can think are: c) Destination of /b/a and /b/c/d. Doesn't make a lot of sense. d) Destination of /b/c/d i.e. no /b/a. Doesn't appear to meet a) i) because the source collection /a is not copied. e) Destination of /b/a/c/d. This is "logical", but doesn't match RFC examples in a) ii) and b). Side note, two implementations we've tested performed d) i.e. they appeared to perform a) ii). Our opinion is that e) should be correct, but obviously, our opinion could be wrong (please correct us if we are). However, neither the examples in the RFC as listed in a) ii) and b) appear to meet 1) a) i) because the source collection itself is not copied. Maybe our interpretation is wrong, but what exactly does the RFC mean? Question 2) COPY with Depth 0 The RFC section 8.8.3 3rd para states that the collection and its properties are copied, but no resources. We tested COPY with a Depth 0 using source of /a to destination /d on two implementations. Both implementations tested did not appear to copy the source collection. Our interpretation is that the source collection /a should have been copied to the destination i.e. resulting in /a/d. Is our interpretation wrong ? Regards Shaun Hall Xerox Europe The opinions are my own and not necessarily those of my employer From w3c-dist-auth-request@w3.org Wed Apr 19 13:16:54 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA10307 for ; Wed, 19 Apr 2000 13:16:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA22196; Wed, 19 Apr 2000 13:13:14 -0400 (EDT) Resent-Date: Wed, 19 Apr 2000 13:13:14 -0400 (EDT) Resent-Message-Id: <200004191713.NAA22196@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Wed, 19 Apr 2000 13:12:25 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: RE: WebDAV COPY/MOVE Question Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4258 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Hal Shaum writes: > I have a couple of questions regarding the WebDAV RFC 2518, > specifically the COPY (and MOVE) operations for collections. > I'll just refer to the COPY sections in the RFC, but Question > 1) is applicable for MOVE as well. > > Question 1) COPY (and MOVE) with infinite Depth: > > a) Section 8.8.3: > > i) 2nd para, 1st sentence states "A COPY of depth infinity > instructs that the collection resource identified by the > Request-URI is to be copied to the location identified by > the URI in the Destination header, and all its internal > member resources...". > > ii) 5th para, 2nd sentence states "When applied to members > of the collection identified by the Request-URI the value of > the Destination is to be modified to reflect the current > location in the hierarchy." The example shows source > is /a, destination is /b, when copying /a/c/d, the > destination is /b/c/d. > > b) Section 8.8.8 Example of a COPY of a collection appears to > perform in principle the example in a) ii) above. > > We interpret a) i) to mean that the source collection and its members are > copied to the destination. That is correct. > Taking the RFC example in a) ii), i.e. the source is /a/c/d and > destination is /b. Possible outcomes we can think are: > > c) Destination of /b/a and /b/c/d. Doesn't make a lot of sense. > d) Destination of /b/c/d i.e. no /b/a. Doesn't appear to meet a) i) > because the source collection /a is not copied. > e) Destination of /b/a/c/d. This is "logical", but doesn't match RFC > examples in a) ii) and b). > > Side note, two implementations we've tested performed d) i.e. > they appeared to perform a) ii). > > Our opinion is that e) should be correct, but obviously, our opinion could > be wrong (please correct us if we are). Actually, d) is correct. When writing the spec, the conceptual model we had in mind for all depth infinity operations (which was not intended to normatively specify exactly how implementations should perform the actual opertion) is that the method is submitted to the collection resource, and then executed by the collection. The collection then submits the method to all its member resources, and each of the member resources executes the method in turn. If one of these resources is a collection, then it would repeat the process. In this model, we wanted all of the parameters (HTTP headers) that are applied to each member to be the same. However, this doesn't work for the Destination header, since the destination header gives the top of the new hierarchy. As a result, the destination header needs to be changed for each member resource to correctly state the new destination for that resource. For example, if you have a collection, a, with members x and y, and you are copying a with depth infinity to g, the destination headers for each resource are: a: Destination: g a/x: Destination: g/x a/y: Destination: g/y Without the Destination rewriting, the destination header would always be g: a: Destination: g a/x: Destination: g a/y: Destination: g In this case, each copy would overwrite the previous resource. Avoiding this situation is the reason we added para 5, "The Destination header only specifies the destination URI for the Request-URI..." Note that your implementation does not need to actually use this model for recursing the method invocations from resource to resource. If you have a repository that has a deep copy operation already within it, you will probably be able to implement a depth COPY using this function. > Question 2) COPY with Depth 0 > > The RFC section 8.8.3 3rd para states that the collection and its > properties are copied, but no resources. We tested COPY with a > Depth 0 using source of /a to destination /d on two implementations. > Both implementations tested did not appear to copy the source collection. > Our interpretation is that the source collection /a should have been > copied to the destination i.e. resulting in /a/d. Hmm, well, after the copy, there should have been two collections, /a, and its copy, /d. You would only have a collection /a/d if the destination was a/d. Does this affect the results of your test? It is also possible that these implementations aren't compliant with the spec. (perhaps the spec. itself needs to be changed). - Jim From w3c-dist-auth-request@w3.org Tue Apr 25 16:02:28 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id QAA24662 for ; Tue, 25 Apr 2000 16:02:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA07574; Tue, 25 Apr 2000 15:58:20 -0400 (EDT) Resent-Date: Tue, 25 Apr 2000 15:58:20 -0400 (EDT) Resent-Message-Id: <200004251958.PAA07574@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Tue, 25 Apr 2000 12:57:11 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: FW: I-D ACTION:draft-christian-prop-semantics-00.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4259 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit FYI. - Jim -----Original Message----- From: nsyracus@cnri.reston.va.us [mailto:nsyracus@cnri.reston.va.us]On Behalf Of Internet-Drafts@ietf.org Sent: Tuesday, April 25, 2000 3:44 AM To: IETF-Announce: ; Subject: I-D ACTION:draft-christian-prop-semantics-00.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. Title : Use of a Semantics Register with WebDAV Properties Author(s) : E. Christian Filename : draft-christian-prop-semantics-00.txt Pages : 5 Date : 24-Apr-00 This document specifies a mechanism to associate a WebDAV ([WEBDAV]) property with an entry in a Semantics Register. A Semantics Register documents the meaning of properties in a formal manner and may be implemented with schema technologies such as Extensible Markup Language (XML) Schema ([XMLSCHEMA]) or Resource Description Framework (RDF) Schema ([RDFS]). Schema technologies expose the derivation of complex properties from simpler concepts, as demonstrated in the Basic Semantics Register ([BSR]) for data elements used in Electronic Data Interchange. Registering the meanings of properties in this manner can enhance interoperability across systems and throughout the long-term information life cycle. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-christian-prop-semantics-00.txt 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-christian-prop-semantics-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-christian-prop-semantics-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. From w3c-dist-auth-request@w3.org Wed Apr 26 03:40:23 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id DAA21153 for ; Wed, 26 Apr 2000 03:40:23 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id DAA21699; Wed, 26 Apr 2000 03:38:53 -0400 (EDT) Resent-Date: Wed, 26 Apr 2000 03:38:53 -0400 (EDT) Resent-Message-Id: <200004260738.DAA21699@www19.w3.org> Message-ID: <416D15B30EBDD211B32C0060974D231F20C065@respons.site.se> From: Martin Hallerdal To: "'w3c-dist-auth@w3.org'" Date: Wed, 26 Apr 2000 09:40:18 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" Subject: WebFolders case sensitive Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4260 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Hi! When trying out my DAV server I noticed that Microsofts Web Folders had problems when I sent "HTTP/1.1 200 Ok" as status line in a PROFIND response, e.g. HTTP/1.1 200 Ok But when I use upper case characters everything works nicely, e.g. HTTP/1.1 200 OK Can anyone confirm this? This is bad behaviour by Web Folders is it not? Martin Hallerdal SITE Scandinavian Internet Technology marty@site.se From w3c-dist-auth-request@w3.org Wed Apr 26 21:23:37 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id VAA07712 for ; Wed, 26 Apr 2000 21:23:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA17663; Wed, 26 Apr 2000 21:21:06 -0400 (EDT) Resent-Date: Wed, 26 Apr 2000 21:21:06 -0400 (EDT) Resent-Message-Id: <200004270121.VAA17663@www19.w3.org> From: Jim Whitehead To: Martin Hallerdal , w3c-dist-auth@w3.org MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Wed, 26 Apr 2000 18:19:46 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <416D15B30EBDD211B32C0060974D231F20C065@respons.site.se> Subject: RE: WebFolders case sensitive Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4261 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit Hi Martin, > When trying out my DAV server I noticed that Microsofts Web Folders had > problems when I sent "HTTP/1.1 200 Ok" as status line in a PROFIND > response, e.g. > > HTTP/1.1 200 Ok > > But when I use upper case characters everything works nicely, e.g. > > HTTP/1.1 200 OK > > Can anyone confirm this? This is bad behaviour by Web Folders is it not? Well, I can't confirm the behavior, but if this is indeed what is going on, then it's non-compliant behavior. The status XML element is defined as "status-line", which is defined in HTTP/1.1, and status-line will accept any text except for CR and LF. So lower case should have been fine. In fact, anything there should have been fine -- the "OK" isn't meaningful to the protocol. - Jim From w3c-dist-auth-request@w3.org Fri Apr 28 09:09:58 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id JAA00328 for ; Fri, 28 Apr 2000 09:09:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA11414; Fri, 28 Apr 2000 08:06:03 -0400 (EDT) Resent-Date: Fri, 28 Apr 2000 08:06:03 -0400 (EDT) Resent-Message-Id: <200004281206.IAA11414@www19.w3.org> Date: Fri, 28 Apr 2000 05:12:35 -0700 (PDT) From: Greg Stein To: Jim Whitehead cc: Martin Hallerdal , w3c-dist-auth@w3.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: RE: WebFolders case sensitive Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4262 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Wed, 26 Apr 2000, Jim Whitehead wrote: > > When trying out my DAV server I noticed that Microsofts Web Folders had > > problems when I sent "HTTP/1.1 200 Ok" as status line in a PROFIND > > response, e.g. > > > > HTTP/1.1 200 Ok > > > > But when I use upper case characters everything works nicely, e.g. > > > > HTTP/1.1 200 OK > > > > Can anyone confirm this? This is bad behaviour by Web Folders is it not? > > Well, I can't confirm the behavior, but if this is indeed what is going on, > then it's non-compliant behavior. The status XML element is defined as > "status-line", which is defined in HTTP/1.1, and status-line will accept any > text except for CR and LF. So lower case should have been fine. In fact, > anything there should have been fine -- the "OK" isn't meaningful to the > protocol. I'm only here for about five more hours before leaving for the weekend (and still getting out from a couple days of email while I was gone :-( ), so I haven't done testing on the above problem. But I can echo what Jim says: it shouldn't be looking at that text. In fact, mod_dav regularly issues status line like this: HTTP/1.1 424 status text goes here (Apache doesn't provide a way to get standard text for error codes) I haven't heard or seen any problem related to this. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Apr 28 13:51:48 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07180 for ; Fri, 28 Apr 2000 13:51:47 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA21812; Fri, 28 Apr 2000 13:46:23 -0400 (EDT) Resent-Date: Fri, 28 Apr 2000 13:46:23 -0400 (EDT) Resent-Message-Id: <200004281746.NAA21812@www19.w3.org> To: w3c-dist-auth@w3.org Cc: ejw@ics.uci.edu, marty@site.se, Greg Stein X-Mailer: Lotus Notes Release 5.0.1a (Intl) 17 August 1999 Message-ID: From: "Tim Ellison/OTT/OTI" Date: Fri, 28 Apr 2000 13:41:43 -0400 X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on OTT1M/A/OTI(Release 5.0.1a (Intl)|17 August 1999) at 04/28/2000 01:41:44 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: RE: WebFolders case sensitive Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4264 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Martin is right. I tried with "OK" and "Ok" in the propstat status element. When the status was HTTP/1.1 200 OK then webfolders was 'OK', however, when the status was HTTP/1.1 200 Ok then webfolders was not 'Ok' (sic), and the results were displayed as nameless icons (in the details view). When the first line (of the response) status message is changed, the webfolders continue to work ok. Regards, Tim ----------------------------- Here's the breaking interaction (Webfolders request folled by the server's response): PROPFIND /dav HTTP/1.1 Accept-Language: en-us Content-Type: text/xml Translate: f Content-Length: 380 Depth: 1 User-Agent: Microsoft Data Access Internet Publishing Provider DAV Host: localhost:8080 Connection: Keep-Alive HTTP/1.0 207 Ok content-type: text/xml;;charset=UTF8 Date: Fri, 28 Apr 2000 13:32:32 GMT Server: DAV4JV/Europa Connection: close HTTP/1.1 404 Not Found 2000-04-12T16:19:00-04:00 2000-04-12T16:19:00-04:00 0 A WebDAV resource. HTTP/1.1 200 Ok /dav/default-workspace HTTP/1.1 404 Not Found 2000-04-17T10:18:21-04:00 2000-04-17T10:18:21-04:00 0 A WebDAV resource. HTTP/1.1 200 Ok /dav/New%20Folder/ HTTP/1.1 404 Not Found 2000-04-13T10:00:07-04:00 2000-04-13T10:01:58-04:00 0 A WebDAV resource. HTTP/1.1 200 Ok /dav/gifs/ HTTP/1.1 404 Not Found 2000-04-27T12:05:34-04:00 2000-04-27T12:05:35-04:00 272 A WebDAV resource. HTTP/1.1 200 Ok /dav/index.html HTTP/1.1 404 Not Found 2000-04-12T16:18:59-04:00 2000-04-28T13:27:05-04:00 0 A WebDAV resource. HTTP/1.1 200 Ok /dav From w3c-dist-auth-request@w3.org Fri Apr 28 13:51:52 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA07198 for ; Fri, 28 Apr 2000 13:51:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA21796; Fri, 28 Apr 2000 13:46:14 -0400 (EDT) Resent-Date: Fri, 28 Apr 2000 13:46:14 -0400 (EDT) Resent-Message-Id: <200004281746.NAA21796@www19.w3.org> To: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.1a (Intl) 17 August 1999 Message-ID: From: "Tim Ellison/OTT/OTI" Date: Fri, 28 Apr 2000 13:44:07 -0400 X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on OTT1M/A/OTI(Release 5.0.1a (Intl)|17 August 1999) at 04/28/2000 01:44:09 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Webfolders and URL encoding Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4263 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list While we are on the subject of webfolders, can anyone provide insight as to why WebFolders does not use '+' to encode the space character when doing URL encoding, and fails to recognise it on responses from the server? WebFolders appear to consistently use %20 for the space char, and don't decode '+' when one is returned. Regards, Tim From w3c-dist-auth-request@w3.org Fri Apr 28 14:10:25 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA07765 for ; Fri, 28 Apr 2000 14:10:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA22861; Fri, 28 Apr 2000 14:05:34 -0400 (EDT) Resent-Date: Fri, 28 Apr 2000 14:05:34 -0400 (EDT) Resent-Message-Id: <200004281805.OAA22861@www19.w3.org> Date: Fri, 28 Apr 2000 11:12:34 -0700 (PDT) From: Greg Stein To: Tim Ellison/OTT/OTI cc: w3c-dist-auth@w3.org In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Webfolders and URL encoding Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4265 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list On Fri, 28 Apr 2000, Tim Ellison/OTT/OTI wrote: > While we are on the subject of webfolders, can anyone provide insight as to > why WebFolders does not use '+' to encode the space character when doing > URL encoding, and fails to recognise it on responses from the server? > > WebFolders appear to consistently use %20 for the space char, and don't > decode '+' when one is returned. '+' is not a valid encoding for 'space'. Some clients and servers do it for parts of a URL (particularly within the 'query' section), but it is not standard. Refer to RFC 2396 (URLs) and RFC 2616 (HTTP), Section 3.2. http://andrew2.andrew.cmu.edu/rfc/rfc2396.html http://andrew2.andrew.cmu.edu/rfc/rfc2616.html Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Apr 28 14:24:51 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08239 for ; Fri, 28 Apr 2000 14:24:49 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA23256; Fri, 28 Apr 2000 14:20:58 -0400 (EDT) Resent-Date: Fri, 28 Apr 2000 14:20:58 -0400 (EDT) Resent-Message-Id: <200004281820.OAA23256@www19.w3.org> Date: Fri, 28 Apr 2000 11:12:26 -0700 Message-ID: <1597-Fri28Apr2000111226-0700-bill@carpenter.ORG> X-Mailer: 20.4 "Emerald" XEmacs Lucid (via feedmail 9-beta-10 I) wjc loop; VM 6.71 under 20.4 "Emerald" XEmacs Lucid MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit From: bill@carpenter.ORG (WJCarpenter) To: w3c-dist-auth@w3.org In-Reply-To: References: Subject: RE: WebFolders case sensitive Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4266 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 7bit tim> Martin is right. I tried with "OK" and "Ok" in the propstat tim> status element. I believe (but haven't confirmed) this whole "text stuff" problem is fixed if the client is Windows2000. Might also be fixed if the client machine runs Office2000 with the ill-fated SR1 installed. I don't know if there is (yet) a fix if you aren't in one of those buckets (if, for example, you get your Web Folders by virtue of using a recent MSIE). -- bill@carpenter.ORG (WJCarpenter) PGP 0x91865119 38 95 1B 69 C9 C6 3D 25 73 46 32 04 69 D6 ED F3 From w3c-dist-auth-request@w3.org Fri Apr 28 14:48:42 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA08759 for ; Fri, 28 Apr 2000 14:48:39 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA23991; Fri, 28 Apr 2000 14:44:18 -0400 (EDT) Resent-Date: Fri, 28 Apr 2000 14:44:18 -0400 (EDT) Resent-Message-Id: <200004281844.OAA23991@www19.w3.org> To: Greg Stein Cc: w3c-dist-auth@w3.org X-Mailer: Lotus Notes Release 5.0.1a (Intl) 17 August 1999 Message-ID: From: "Tim Ellison/OTT/OTI" Date: Fri, 28 Apr 2000 14:42:58 -0400 X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on OTT1M/A/OTI(Release 5.0.1a (Intl)|17 August 1999) at 04/28/2000 02:43:04 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii Subject: Re: Webfolders and URL encoding Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4267 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list This is true (see also http://andrew2.andrew.cmu.edu/rfc/rfc1738.html). So this format is different to the MIME format called "application/ x-www-form-urlencoded", (ref. http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.4.1) and in particular is different to the java.net.URLEncoder behaviour. This will likely cause 'interesting' incompatibilities with many Java based clients. Thanks for pointing this out. Tim Greg Stein org> cc: w3c-dist-auth@w3.org Subject: Re: Webfolders and URL encoding 28-04-00 02:12 PM On Fri, 28 Apr 2000, Tim Ellison/OTT/OTI wrote: > While we are on the subject of webfolders, can anyone provide insight as to > why WebFolders does not use '+' to encode the space character when doing > URL encoding, and fails to recognise it on responses from the server? > > WebFolders appear to consistently use %20 for the space char, and don't > decode '+' when one is returned. '+' is not a valid encoding for 'space'. Some clients and servers do it for parts of a URL (particularly within the 'query' section), but it is not standard. Refer to RFC 2396 (URLs) and RFC 2616 (HTTP), Section 3.2. http://andrew2.andrew.cmu.edu/rfc/rfc2396.html http://andrew2.andrew.cmu.edu/rfc/rfc2616.html Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Apr 28 15:22:14 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id PAA09908 for ; Fri, 28 Apr 2000 15:22:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA24779; Fri, 28 Apr 2000 15:17:01 -0400 (EDT) Resent-Date: Fri, 28 Apr 2000 15:17:01 -0400 (EDT) Resent-Message-Id: <200004281917.PAA24779@www19.w3.org> Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Fri, 28 Apr 2000 13:16:16 -0600 From: "Dan Burton" To: Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Disposition: inline Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from quoted-printable to 8bit by www19.w3.org id PAA24755 Subject: Re: Webfolders and URL encoding Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4268 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Content-Transfer-Encoding: 8bit Hopefully I'm not out of place with this question. Talking about URL encoding and webfolders, how should non-ASCII characters be encoded? It looks like the Microsoft webfolders encodes them based on the Windows code page. There is a setting in IE5 that says "Always send URLs as UTF-8". However WebFolders ignores this setting and never sends the URLs as UTF-8. The problem I have is that I can not reliably determine what a character is when it is encoded using code pages. Thanks, Dan >>> "Tim Ellison/OTT/OTI" 04/28/00 12:44PM >>> This is true (see also http://andrew2.andrew.cmu.edu/rfc/rfc1738.html). So this format is different to the MIME format called "application/ x-www-form-urlencoded", (ref. http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.4.1) and in particular is different to the java.net.URLEncoder behaviour. This will likely cause 'interesting' incompatibilities with many Java based clients. Thanks for pointing this out. Tim Greg Stein org> cc: w3c-dist-auth@w3.org Subject: Re: Webfolders and URL encoding 28-04-00 02:12 PM On Fri, 28 Apr 2000, Tim Ellison/OTT/OTI wrote: > While we are on the subject of webfolders, can anyone provide insight as to > why WebFolders does not use '+' to encode the space character when doing > URL encoding, and fails to recognise it on responses from the server? > > WebFolders appear to consistently use %20 for the space char, and don't > decode '+' when one is returned. '+' is not a valid encoding for 'space'. Some clients and servers do it for parts of a URL (particularly within the 'query' section), but it is not standard. Refer to RFC 2396 (URLs) and RFC 2616 (HTTP), Section 3.2. http://andrew2.andrew.cmu.edu/rfc/rfc2396.html http://andrew2.andrew.cmu.edu/rfc/rfc2616.html Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri Apr 28 19:24:29 2000 Received: from www19.w3.org (www19.w3.org [18.29.0.19]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id TAA19643 for ; Fri, 28 Apr 2000 19:24:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA01015; Fri, 28 Apr 2000 19:17:25 -0400 (EDT) Resent-Date: Fri, 28 Apr 2000 19:17:25 -0400 (EDT) Resent-Message-Id: <200004282317.TAA01015@www19.w3.org> Message-ID: <9BDBBF9512077F48ABBDFB197908A9610C91C6@red-pt-01.redmond.corp.microsoft.com> From: Brian Morin To: "'Dan Burton'" , w3c-dist-auth@w3.org Date: Fri, 28 Apr 2000 16:16:35 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Subject: RE: Webfolders and URL encoding Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4269 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list The part of this that throws me for a loop is that web folders expects UTF-8 encoded URLs in the href field of the PropFind response, but it does not send the same URLs back to you and instead goes out of its way to use local encoding. My observations working with web folders is that the input URL is based on the local codepage, and that accept-language is the best way I've found to guess what that code page is. Also, when web folders sees characters outside of the range of the local codepage these render as ? and you can not operate on them. Brian Morin Software Development Engineer MSN Communities -----Original Message----- From: Dan Burton [mailto:DPBURTON@novell.com] Sent: Friday, April 28, 2000 12:16 PM To: w3c-dist-auth@w3.org Subject: Re: Webfolders and URL encoding Hopefully I'm not out of place with this question. Talking about URL encoding and webfolders, how should non-ASCII characters be encoded? It looks like the Microsoft webfolders encodes them based on the Windows code page. There is a setting in IE5 that says "Always send URLs as UTF-8". However WebFolders ignores this setting and never sends the URLs as UTF-8. The problem I have is that I can not reliably determine what a character is when it is encoded using code pages. Thanks, Dan >>> "Tim Ellison/OTT/OTI" 04/28/00 12:44PM >>> This is true (see also http://andrew2.andrew.cmu.edu/rfc/rfc1738.html). So this format is different to the MIME format called "application/ x-www-form-urlencoded", (ref. http://www.w3.org/TR/REC-html40/interact/forms.html#h-17.13.4.1) and in particular is different to the java.net.URLEncoder behaviour. This will likely cause 'interesting' incompatibilities with many Java based clients. Thanks for pointing this out. Tim Greg Stein org> cc: w3c-dist-auth@w3.org Subject: Re: Webfolders and URL encoding 28-04-00 02:12 PM On Fri, 28 Apr 2000, Tim Ellison/OTT/OTI wrote: > While we are on the subject of webfolders, can anyone provide insight as to > why WebFolders does not use '+' to encode the space character when doing > URL encoding, and fails to recognise it on responses from the server? > > WebFolders appear to consistently use %20 for the space char, and don't > decode '+' when one is returned. '+' is not a valid encoding for 'space'. Some clients and servers do it for parts of a URL (particularly within the 'query' section), but it is not standard. Refer to RFC 2396 (URLs) and RFC 2616 (HTTP), Section 3.2. http://andrew2.andrew.cmu.edu/rfc/rfc2396.html http://andrew2.andrew.cmu.edu/rfc/rfc2616.html Cheers, -g -- Greg Stein, http://www.lyra.org/