From w3c-dist-auth-request@w3.org Tue May 2 12:41:34 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 MAA04826 for ; Tue, 2 May 2000 12:41:33 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA16537; Tue, 2 May 2000 12:34:53 -0400 (EDT) Resent-Date: Tue, 2 May 2000 12:34:53 -0400 (EDT) Resent-Message-Id: <200005021634.MAA16537@www19.w3.org> To: Greg Stein cc: w3c-dist-auth@w3.org, reuterj@ira.uka.de, jjh@ira.uka.de In-reply-to: Your message of "Fri, 28 Apr 2000 11:12:34 PDT." Date: Tue, 02 May 2000 18:31:22 +0200 From: Juergen Reuter Message-ID: <"iraun1.ira.0002501:000502.163138"@ira.uka.de> Subject: Re: Webfolders and URL encoding Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4270 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: > '+' 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 The '+' encoding is not standard for URL encoding itself, but it *is* standard for form-urlencoded data, as specified in RFC 1866: >8.2.1. The form-urlencoded Media Type > > The default encoding for all forms is `application/x-www-form- > urlencoded'. A form data set is represented in this media type as > follows: > > 1. The form field names and values are escaped: space > characters are replaced by `+', and then reserved characters > are escaped as per [URL]; that is, non-alphanumeric > characters are replaced by `%HH', a percent sign and two > hexadecimal digits representing the ASCII code of the > character. Line breaks, as in multi-line text field values, > are represented as CR LF pairs, i.e. `%0D%0A'. Section 8.2.2 says: > To process a form whose action URL is an HTTP URL and whose method is > `GET', the user agent starts with the action URI and appends a `?' > and the form data set, in `application/x-www-form-urlencoded' format > as above. In other words, the '+' encoding is standard not only in the message body, but even in the request line of a GET request (at least as of HTML/2.0). However, when doing a POST, the form data is put into the message body rather than the request line (section 8.2.3). Bye, Juergen From w3c-dist-auth-request@w3.org Fri May 5 05:50:47 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 FAA12817 for ; Fri, 5 May 2000 05:50:46 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA17642; Fri, 5 May 2000 05:39:09 -0400 (EDT) Resent-Date: Fri, 5 May 2000 05:39:09 -0400 (EDT) Resent-Message-Id: <200005050939.FAA17642@www19.w3.org> From: Jim Whitehead To: WebDAV WG , Roy Fielding Date: Thu, 4 May 2000 22:09:36 -0700 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: Qualities of URLs and Resources (take 2) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4271 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 On Wednesday, February 9, 2000, I wrote, responding to Roy Fielding: > Roy Fielding writes, in his post originally titled, > "draft-ietf-webdav-binding-protocol-02" > : > > > URI Mapping > > > A relation between an absolute URI and a resource. For an > > > absolute URI U and the resource it identifies R, the URI mapping > > > can be thought of as (U => R). Since a resource can represent > > > items that are not network retrievable, as well as those that > > > are, it is possible for a resource to have zero, one, or many > > > URI mappings. Mapping a resource to an "http" scheme URL makes > > > it possible to submit HTTP protocol requests to the resource > > > using the URL. > > > > Actually, it is more like ({U,t} -R-> {V1, V2, ...}), where t is the > > current time, R is the resource, -R-> is a mapping function that has > > been implemented according to the semantics of resource R), and the range > > is a set of values representing that resource at time t. *snip* > So, using your notation, I would re-write the full mapping as: > > {URI1, URI2, ... URIn} -UMap-> resource -RMap-> {V1, V2, ... Vm} > > Where UMap is the URI to resource mapping function, and RMap is > the resource to value mapping function. I omit time since it's really > tangential to our discussion, assuming that the entire set of mappings > occurs at a given time t. In this view, the term "resource" as used in > RFC 2396 is both the output of the UMap function, and the RMap mapping > function, but *not* the set of values. Having thought about this for awhile, I now see that I was using the term "resource" in a different manner than Roy. I had essentially been using "resource" as the name for the set {V1, V2, ... Vm} of values. But, as Roy points out, a resource is an *abstraction*, not a specific set of values, or even the mapping RMap. This is why he stated, on Feb. 10, 2000: > the resource is the concept, not the representation > of that concept and not the URI-to-representation mapping mechanism > on the server. That is, the abstract concept of a particular resource defines to a specific set of values, and a specific resource mapping function. The abstract concept comes first, then from it are derived the values and mapping function. So, when Roy proposed that a binding be treated as a resource, this is an assertion that the values and the mapping function are derived from the definition of the binding resource. Using Roy's notation, a resource's mapping functions and values can be represented as: {U,t} -RMap-> {V1, V2, ... Vm} A binding resource's mapping function and values can be represented as: {U1,t} -RMap-> {V1, V2, ... Vm} > | / | RMap | This mapping function is derived from the {U2,t} / | definition of the abstract binding resource In this case, by definition of the binding resource, the set of values is the same, though the mapping function is different. But, this has the difficulty that no identifier exists for the set of values. This identifier is useful, since it allows the construction of URL to identifier pairs. In cases where the set of values has only one member, and this member can be modified with a PUT or PROPPATCH, these pairs allow a client to determine a priori whether the effect of an action on one URL will be visible via another. This capability is useful in a number of authoring situations. Previously, I wrote: {URI1, URI2, ... URIn} -UMap-> resource -RMap-> {V1, V2, ... Vm} To express going from a URL to the set of values. I still like this diagram, but calling the middle item a "resource" is a mistake, since a resource is an *abstraction*. The middle item is really an identifier for the set of values, what I'll term a resource implementation identifier (RII). That is, it does not identify the resource, only a specific implementation of the resource in the form of the resource mapping function RMap, and the set of values. Rewriting it yields: resource {URI1, URI2, ... URIn} -UMap-> implementation -RMap-> {V1, V2, ... Vm} identifier | <-- affected by bindings --- | ---affected by resource's defintion --> | In this diagram, the abstract concept of the resource has been used to define the resource mapping function, RMap, and the set of values, {V1, V2, ... Vm}, and the RII uniquely identifies this (RMap, Value set) pair. That is, it uniquely identifies this specific implementation of the abstract resource. A single binding can be viewed as an element of the UMap set, that is, a specific (URI, RII) pair. Thus, the effect of the bindings specification is to manage the UMap function, as specified as a mapping from URIs to the RII. By introducing the notion of the resource implementation identifier, it is possible to introduce bindings without having to redefine the notion of a resource, without having to break the resource abstraction layer, and without having to introduce a new kind of resource (a binding resource), while still providing clients with a unique identifier for the *implementation* of the resource. So, Roy, did I set off any mental trip wires this time? :-) - Jim From w3c-dist-auth-request@w3.org Fri May 5 10:51:53 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 KAA20417 for ; Fri, 5 May 2000 10:51:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id KAA29349; Fri, 5 May 2000 10:42:12 -0400 (EDT) Resent-Date: Fri, 5 May 2000 10:42:12 -0400 (EDT) Resent-Message-Id: <200005051442.KAA29349@www19.w3.org> Message-ID: <000e01bfb6a0$74fd8ea0$bc7c5ecc@ruksun.com> From: "Kaushik Sridharan" To: Date: Fri, 5 May 2000 20:14:09 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Subject: Multistatus required in responses? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4272 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 Hello all, I have a question regarding WebDAV responses -- Are responses for specific methods required to be multistatus? I suppose GET or HEAD requests will not result in a multistatus reponse; the RFC even gives examples for LOCK where the response is a 200 OK. But can other requests like PROPFIND result in a non-multistatus response, say in a situation where a single resource is being queried? The PROFIND section 8.1 in the RFC says that "servers MUST support returning a response [..] that contains a multistatus XML element", but later in the same section it says "a request to retrieve the value of a property which does not exist is an error and MUST be noted, **if** the response uses a multistatus XML element..." (emphasis mine). The last "if" makes it unclear whether clients should be prepared to accept PROPFIND (or other) responses that are not multistatus. I apologize if this question has been answered before on this list. Thanks, Kaushik From w3c-dist-auth-request@w3.org Fri May 5 15:44: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 PAA27525 for ; Fri, 5 May 2000 15:44:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA17499; Fri, 5 May 2000 15:22:12 -0400 (EDT) Resent-Date: Fri, 5 May 2000 15:22:12 -0400 (EDT) Resent-Message-Id: <200005051922.PAA17499@www19.w3.org> Message-ID: <27C384A78DFFD311A28B0050DACEDA431F68FF@RAPTOR> From: "Fielding, Roy" To: "'Jim Whitehead'" , WebDAV WG Date: Fri, 5 May 2000 12:22:02 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFB6C7.30EDEF30" Subject: RE: Qualities of URLs and Resources (take 2) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4273 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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFB6C7.30EDEF30 Content-Type: text/plain; charset="iso-8859-1" > Using Roy's notation, a resource's mapping functions and values can be > represented as: > > {U,t} -RMap-> {V1, V2, ... Vm} > > A binding resource's mapping function and values can be > represented as: > > {U1,t} -RMap-> {V1, V2, ... Vm} > > | > / | > RMap | This mapping function is derived from the > {U2,t} / | definition of the abstract binding resource > > In this case, by definition of the binding resource, the set of values is > the same, though the mapping function is different. What is the advantage of the above versus: -> {U1,t} -RMap-> {V1, V2, ... Vm} / / RMap | This mapping function is derived from the {U2,t}- / | definition of the abstract binding resource> This is essentially requiring that, for all things that can be bound, there exists at least one URI representing the target of that binding. Note that this can be a non-public identifier, such as a file URL, that may be ony accessible from within the server. The above is how internal redirects are handled today, which are effectively the same thing as bindings but without a standard for remote configuration authoring. The only real difference between a binding and an HTTP gateway is the location of the target. > But, this has the difficulty that no identifier exists for the set of > values. This identifier is useful, since it allows the construction of URL > to identifier pairs. In cases where the set of values has only one member, > and this member can be modified with a PUT or PROPPATCH, these pairs allow a > client to determine a priori whether the effect of an action on one URL will > be visible via another. This capability is useful in a number of authoring > situations. Ummm, sometimes. Because resource implementations have all the complexity of a turing machine, there is no way to ensure that changes in one will not have an effect on others, particularly since a resource on one machine may be defined in terms of resources on other machines. What you are creating is a situation in which some well-defined dependencies between resources can be discovered and manipulated by the client, which may be a good thing for some authoring situations *provided* that the client never assumes it knows the complete set of dependencies. It is impossible to require the server to manage all of the dependencies, since no single server can know of all the dependencies. This is equivalent to a remote authoring interface to the configuration files used by mod_rewrite (an Apache module), though with a restricted set of features in order to reduce complexity. > Previously, I wrote: > > {URI1, URI2, ... URIn} -UMap-> resource -RMap-> {V1, V2, ... Vm} > > To express going from a URL to the set of values. I still like this > diagram, but calling the middle item a "resource" is a mistake, since a > resource is an *abstraction*. The middle item is really an identifier for > the set of values, what I'll term a resource implementation identifier > (RII). That is, it does not identify the resource, only a specific > implementation of the resource in the form of the resource mapping function > RMap, and the set of values. Rewriting it yields: > > resource > {URI1, URI2, ... URIn} -UMap-> implementation -RMap-> {V1, V2, ... Vm} > identifier > > | > <-- affected by bindings --- | ---affected by resource's defintion --> > | > > In this diagram, the abstract concept of the resource has been used to > define the resource mapping function, RMap, and the set of values, {V1, V2, > ... Vm}, and the RII uniquely identifies this (RMap, Value set) pair. That > is, it uniquely identifies this specific implementation of the abstract > resource. A single binding can be viewed as an element of the UMap set, that > is, a specific (URI, RII) pair. Thus, the effect of the bindings > specification is to manage the UMap function, as specified as a mapping from > URIs to the RII. By introducing the notion of the resource implementation > identifier, it is possible to introduce bindings without having to redefine > the notion of a resource, without having to break the resource abstraction > layer, and without having to introduce a new kind of resource (a binding > resource), while still providing clients with a unique identifier for the > *implementation* of the resource. > > So, Roy, did I set off any mental trip wires this time? :-) Well, assuming that the RII is just another URI, that is fine. In terms of how the abstraction works, you are right on the mark. Cheers, Roy T. Fielding, Chairman, The Apache Software Foundation (www.apache.org) Chief Scientist, eBuilt, Inc. (www.ebuilt.com) ------_=_NextPart_001_01BFB6C7.30EDEF30 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable RE: Qualities of URLs and Resources (take 2)

> Using Roy's notation, a resource's mapping = functions and values can be
> represented as:
>
>  {U,t} -RMap-> {V1, V2, ... Vm}
>
> A binding resource's mapping function and = values can be
> represented as:
>
>  {U1,t} -RMap-> {V1, V2, ... Vm}
>          = ;     >  |
>          = ;    /   |
>          = RMap    | This mapping function is derived from = the
>  {U2,t} = /        | definition of the = abstract binding resource
>
> In this case, by definition of the binding = resource, the set of values is
> the same, though the mapping function is = different.

What is the advantage of the above versus:

          &nb= sp;    -> {U1,t} -RMap-> {V1, V2, ... Vm}
          &nb= sp;   /
          &nb= sp;  /
          = RMap     | This mapping function is derived from = the
  {U2,t}- = /        | definition of the = abstract binding resource>

This is essentially requiring that, for all things = that can be bound,
there exists at least one URI representing the = target of that binding.
Note that this can be a non-public identifier, such = as a file URL,
that may be ony accessible from within the = server.

The above is how internal redirects are handled = today, which are
effectively the same thing as bindings but without a = standard for
remote configuration authoring.  The only real = difference between a
binding and an HTTP gateway is the location of the = target.

> But, this has the difficulty that no identifier = exists for the set of
> values. This identifier is useful, since it = allows the construction of URL
> to identifier pairs.  In cases where the = set of values has only one member,
> and this member can be modified with a PUT or = PROPPATCH, these pairs allow a
> client to determine a priori whether the effect = of an action on one URL will
> be visible via another. This capability is = useful in a number of authoring
> situations.

Ummm, sometimes.  Because resource = implementations have all the complexity
of a turing machine, there is no way to ensure that = changes in one will
not have an effect on others, particularly since a = resource on one machine
may be defined in terms of resources on other = machines.

What you are creating is a situation in which some = well-defined dependencies
between resources can be discovered and manipulated = by the client, which
may be a good thing for some authoring situations = *provided* that the
client never assumes it knows the complete set of = dependencies.  It is
impossible to require the server to manage all of = the dependencies, since
no single server can know of all the = dependencies.

This is equivalent to a remote authoring interface to = the configuration
files used by mod_rewrite (an Apache module), though = with a restricted
set of features in order to reduce = complexity.

> Previously, I wrote:
>
>  {URI1, URI2, ... URIn} -UMap-> = resource -RMap-> {V1, V2, ... Vm}
>
> To express going from a URL to the set of = values.  I still like this
> diagram, but calling the middle item a = "resource" is a mistake, since a
> resource is an *abstraction*.  The middle = item is really an identifier for
> the set of values, what I'll term a resource = implementation identifier
> (RII).  That is, it does not identify the = resource, only a specific
> implementation of the resource in the form of = the resource mapping function
> RMap, and the set of values. Rewriting it = yields:
>
>          = ;            = ;            = resource
> {URI1, URI2, ... URIn} -UMap-> = implementation -RMap-> {V1, V2, ... Vm}
>          = ;            = ;           = identifier
>
>          = ;            = ;          |
>   <-- affected by bindings --- | = ---affected by resource's defintion -->
>          = ;            = ;          |
>
> In this diagram, the abstract concept of the = resource has been used to
> define the resource mapping function, RMap, and = the set of values, {V1, V2,
> ... Vm}, and the RII uniquely identifies this = (RMap, Value set) pair. That
> is, it uniquely identifies this specific = implementation of the abstract
> resource. A single binding can be viewed as an = element of the UMap set, that
> is, a specific (URI, RII) pair. Thus, the = effect of the bindings
> specification is to manage the UMap function, = as specified as a mapping from
> URIs to the RII.  By introducing the = notion of the resource implementation
> identifier, it is possible to introduce = bindings without having to redefine
> the notion of a resource, without having to = break the resource abstraction
> layer, and without having to introduce a new = kind of resource (a binding
> resource), while still providing clients with a = unique identifier for the
> *implementation* of the resource.
>
> So, Roy, did I set off any mental trip wires = this time? :-)

Well, assuming that the RII is just another URI, that = is fine.  In terms
of how the abstraction works, you are right on the = mark.


Cheers,

Roy T. Fielding, Chairman, The Apache Software = Foundation (www.apache.org)
          &nb= sp;      Chief Scientist, eBuilt, = Inc.            = (www.ebuilt.com)

------_=_NextPart_001_01BFB6C7.30EDEF30-- From w3c-dist-auth-request@w3.org Fri May 5 16:36: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 QAA28520 for ; Fri, 5 May 2000 16:36:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA20854; Fri, 5 May 2000 16:23:38 -0400 (EDT) Resent-Date: Fri, 5 May 2000 16:23:38 -0400 (EDT) Resent-Message-Id: <200005052023.QAA20854@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Kaushik Sridharan" cc: w3c-dist-auth@w3.org Message-ID: <852568D6.006FF066.00@D51MTA03.pok.ibm.com> Date: Fri, 5 May 2000 16:21:31 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Multistatus required in responses? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4274 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Are responses for specific methods required to be multistatus? .. I apologize if this question has been answered before on this list. I believe it has been discussed. I believe I brought it up and the conclusion was that PROPPATCH and PROPFIND must return multistatus and take no shortcuts. The reasoning behind this was that it made things more predictable for the client and really wasn't any harder for the server. If it's not already on the issues list, a clarification of this should be added to that list. From w3c-dist-auth-request@w3.org Fri May 5 19:04: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 TAA00914 for ; Fri, 5 May 2000 19:04:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA29345; Fri, 5 May 2000 18:47:31 -0400 (EDT) Resent-Date: Fri, 5 May 2000 18:47:31 -0400 (EDT) Resent-Message-Id: <200005052247.SAA29345@www19.w3.org> Date: Fri, 5 May 2000 15:42:36 -0700 (PDT) From: Greg Stein To: ccjason@us.ibm.com cc: Kaushik Sridharan , w3c-dist-auth@w3.org In-Reply-To: <852568D6.006FF066.00@D51MTA03.pok.ibm.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Multistatus required in responses? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4275 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, 5 May 2000 ccjason@us.ibm.com wrote: > Are responses for specific methods required to be multistatus? > .. > I apologize if this question has been answered before on this list. > > I believe it has been discussed. I believe I brought it up and > the conclusion was that PROPPATCH and PROPFIND must return > multistatus and take no shortcuts. The reasoning behind this > was that it made things more predictable for the client and > really wasn't any harder for the server. > > If it's not already on the issues list, a clarification of this > should be added to that list. I would disagree. I think that it is quite valid to return something like 403 (Forbidden) or 401 (Authorization required) as a response. Heck, you could also return something like 412 or 301, too. In each of these cases, the 3xx or 4xx applies to the Request-URI. If a status code ever applies to a URI *other* than the Request-URI (say, caused by a Depth: header), then a 207 (Multistatus) MUST be returned. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Sat May 6 05:02:01 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 FAA19367 for ; Sat, 6 May 2000 05:02:01 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id EAA06154; Sat, 6 May 2000 04:48:13 -0400 (EDT) Resent-Date: Sat, 6 May 2000 04:48:13 -0400 (EDT) Resent-Message-Id: <200005060848.EAA06154@www19.w3.org> Message-ID: <01be01bfb738$2a30b530$bc7c5ecc@ruksun.com> From: "Kaushik Sridharan" To: References: Date: Sat, 6 May 2000 14:18:43 +0530 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 5.00.2014.211 X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2014.211 Subject: Re: Multistatus required in responses? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4276 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 [Greg Stein wrote:] > I would disagree. I think that it is quite valid to return something like > 403 (Forbidden) or 401 (Authorization required) as a response. Heck, you > could also return something like 412 or 301, too. > > In each of these cases, the 3xx or 4xx applies to the Request-URI. If a > status code ever applies to a URI *other* than the Request-URI (say, > caused by a Depth: header), then a 207 (Multistatus) MUST be returned. In my initial query I had assumed that 4xx or 3xx are valid. I meant to ask about successful responses -- whether they must be 207, or whether a 200 could be expected as well. To paraphrase: Are 200 responses for PROPFIND allowed? Thanks, Kaushik From w3c-dist-auth-request@w3.org Sat May 6 16:59: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 QAA23999 for ; Sat, 6 May 2000 16:59:24 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA14403; Sat, 6 May 2000 16:52:46 -0400 (EDT) Resent-Date: Sat, 6 May 2000 16:52:46 -0400 (EDT) Resent-Message-Id: <200005062052.QAA14403@www19.w3.org> Date: Sat, 6 May 2000 16:52:30 -0400 (EDT) Message-Id: <200005062052.QAA18351@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: <27C384A78DFFD311A28B0050DACEDA431F68FF@RAPTOR> (fielding@eBuilt.com) References: <27C384A78DFFD311A28B0050DACEDA431F68FF@RAPTOR> Subject: Re: Qualities of URLs and Resources (take 2) Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4277 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list It does look we're converging. Just a few comments (to see if I set off any tripwires that Jim managed to avoid :-). Since we're basing the "versioned collection" semantics on the bindings semantics, I want to make sure we're in synch. From: "Fielding, Roy" > Using Roy's notation, a resource's mapping functions and values can be > represented as: > > {U,t} -RMap-> {V1, V2, ... Vm} > > A binding resource's mapping function and values can be > represented as: > > {U1,t} -RMap-> {V1, V2, ... Vm} > > | > / | > RMap | This mapping function is derived from the > {U2,t} / | definition of the abstract binding resource > > In this case, by definition of the binding resource, the set of > values is the same, though the mapping function is different. What is the advantage of the above versus: -> {U1,t} -RMap-> {V1, V2, ... Vm} / / RMap | This mapping function is derived from the {U2,t}- / | definition of the abstract binding resource> I believe what Jim wants to do in his later diagram is to emphasize that there are two different classes of URI's, that participate in two different kinds of mappings. The first (the "UMap") is captured by the union of the "states" of a set of collection resources, and is modified by the BIND and UNBIND requests. The second (the "RMap") is not affected by the BIND and UNBIND requests (and is not necessarily even visible to the client). So in the immediately preceding diagram, the "RMap" between {U1,t} and {V1, ..., Vm} is actually a "UMap". This is essentially requiring that, for all things that can be bound, there exists at least one URI representing the target of that binding. Note that this can be a non-public identifier, such as a file URL, that may be ony accessible from within the server. Sounds right. > But, this has the difficulty that no identifier exists for the > set of values. This identifier is useful, since it allows the > construction of URL to identifier pairs. In cases where the set > of values has only one member, and this member can be modified > with a PUT or PROPPATCH, these pairs allow a client to determine > a priori whether the effect of an action on one URL will be > visible via another. This capability is useful in a number of > authoring situations. Ummm, sometimes. Because resource implementations have all the complexity of a turing machine, there is no way to ensure that changes in one will not have an effect on others, particularly since a resource on one machine may be defined in terms of resources on other machines. What you are creating is a situation in which some well-defined dependencies between resources can be discovered and manipulated by the client, which may be a good thing for some authoring situations *provided* that the client never assumes it knows the complete set of dependencies. It is impossible to require the server to manage all of the dependencies, since no single server can know of all the dependencies. This all sounds right. The latest drafts of the binding semantics don't try to say anything beyond how the various operations affect the bind relationships created and removed by BIND and UNBIND. > Previously, I wrote: > > {URI1, URI2, ... URIn} -UMap-> resource -RMap-> {V1, V2, ... Vm} > > To express going from a URL to the set of values. I still like > this diagram, but calling the middle item a "resource" is a > mistake, since a resource is an *abstraction*. The middle item > is really an identifier for the set of values, what I'll term a > resource implementation identifier > (RII). That is, it does not identify the resource, only a > specific implementation of the resource in the form of the > resource mapping function RMap, and the set of values. Rewriting > it yields: > resource > {URI1, URI2, ... URIn} -UMap-> implementation -RMap-> {V1, V2, ... Vm} > identifier > > | > <-- affected by bindings --- | ---affected by resource's defintion --> > | > In this diagram, the abstract concept of the resource has been > used to define the resource mapping function, RMap, and the set > of values, {V1, V2, ... Vm}, and the RII uniquely identifies this > (RMap, Value set) pair. That is, it uniquely identifies this > specific implementation of the abstract resource. A single > binding can be viewed as an element of the UMap set, that is, a > specific (URI, RII) pair. Thus, the effect of the bindings > specification is to manage the UMap function, as specified as a > mapping from URIs to the RII. By introducing the notion of the > resource implementation identifier, it is possible to introduce > bindings without having to redefine the notion of a resource, > without having to break the resource abstraction layer, and > without having to introduce a new kind of resource (a binding > resource), while still providing clients with a unique identifier > for the *implementation* of the resource. > > So, Roy, did I set off any mental trip wires this time? :-) Well, assuming that the RII is just another URI, that is fine. In terms of how the abstraction works, you are right on the mark. Note that in the binding spec, we allow a server to expose the "RII" in the DAV:urn property, so this is consistent with Roy's description. Cheers, Geoff From w3c-dist-auth-request@w3.org Sun May 7 05:47: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 FAA06537 for ; Sun, 7 May 2000 05:47:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id FAA21046; Sun, 7 May 2000 05:41:30 -0400 (EDT) Resent-Date: Sun, 7 May 2000 05:41:30 -0400 (EDT) Resent-Message-Id: <200005070941.FAA21046@www19.w3.org> Date: Sun, 7 May 2000 02:37:46 -0700 (PDT) From: Greg Stein To: Kaushik Sridharan cc: w3c-dist-auth@w3.org In-Reply-To: <01be01bfb738$2a30b530$bc7c5ecc@ruksun.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Multistatus required in responses? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4278 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, 6 May 2000, Kaushik Sridharan wrote: > [Greg Stein wrote:] > > I would disagree. I think that it is quite valid to return something like > > 403 (Forbidden) or 401 (Authorization required) as a response. Heck, you > > could also return something like 412 or 301, too. > > > > In each of these cases, the 3xx or 4xx applies to the Request-URI. If a > > status code ever applies to a URI *other* than the Request-URI (say, > > caused by a Depth: header), then a 207 (Multistatus) MUST be returned. > > In my initial query I had assumed that 4xx or 3xx are valid. I meant to ask > about successful responses -- whether they must be 207, or whether a 200 > could be expected as well. > > To paraphrase: Are 200 responses for PROPFIND allowed? Nope. If a PROPFIND succeeds, then it is going to be returning properties. Therefore, it must return a 207 which contains the element. Sure, it is theoretically possible to state that the 200 has the XML body, but that's not what was defined. PROPFIND returns 207 on success. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Sun May 7 21:45: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 VAA14977 for ; Sun, 7 May 2000 21:45:22 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA01752; Sun, 7 May 2000 21:37:33 -0400 (EDT) Resent-Date: Sun, 7 May 2000 21:37:33 -0400 (EDT) Resent-Message-Id: <200005080137.VAA01752@www19.w3.org> From: ccjason@us.ibm.com X-Lotus-FromDomain: IBMUS To: Greg Stein cc: Kaushik Sridharan , w3c-dist-auth@w3.org Message-ID: <852568D9.0008CCF6.00@D51MTA03.pok.ibm.com> Date: Sun, 7 May 2000 21:34:52 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: Multistatus required in responses? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4279 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 would disagree. I think that it is quite valid to return something like 403 (Forbidden) or 401 (Authorization required) as a response. Heck, you could also return something like 412 or 301, too. In each of these cases, the 3xx or 4xx applies to the Request-URI. If a status code ever applies to a URI *other* than the Request-URI (say, caused by a Depth: header), then a 207 (Multistatus) MUST be returned. I've jogged my memory a abit. The discussion I mentioned only discussed PROPSTAT responses. As I said, the conclusion was that shortcuts would not be taken. The multistatus had to be fully populated and follow a standard formula. There was a bit of discussion of if a fully populated MULTISTATUS response was really merited for a pure 200 response. (Although consistant, it seemed like a bit of a pain to parse through all the XML just to find out everything was okay.) The thread seemed to conclude mildly in favor of not making an exception for 200. As I said, this was just PROPPATCH. PROPFIND was not discussed in that thread. And it doesn't discredit what Greg says. (It *is* reasonable to just return a single status for some situations.) That thread just valued a predictable response more highly. The conclusion didn't seem to be strongly held. If you're writing a client, you'd better handle it both ways. And we should make sure this hits the issues list and that the issues list gets processed. J. From w3c-dist-auth-request@w3.org Mon May 8 06:47: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 GAA02794 for ; Mon, 8 May 2000 06:47:10 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA08979; Mon, 8 May 2000 06:40:48 -0400 (EDT) Resent-Date: Mon, 8 May 2000 06:40:48 -0400 (EDT) Resent-Message-Id: <200005081040.GAA08979@www19.w3.org> Message-Id: <200005081040.GAA02678@ietf.org> Mime-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" To: IETF-Announce: ; Cc: w3c-dist-auth@w3.org From: Internet-Drafts@ietf.org Reply-to: Internet-Drafts@ietf.org Date: Mon, 08 May 2000 06:40:42 -0400 Subject: I-D ACTION:draft-ietf-webdav-acl-01.txt Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4280 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the WWW Distributed Authoring and Versioning Working Group of the IETF. Title : Access Control Extensions to WebDAV Author(s) : E. Sedlar, G. Clemm Filename : draft-ietf-webdav-acl-01.txt Pages : 14 Date : 05-May-00 This document specifies a set of methods, headers, and resource-types that define the WebDAV Access Control extensions to the HTTP/1.1 protocol. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-webdav-acl-01.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-ietf-webdav-acl-01.txt". A list of Internet-Drafts directories can be found in http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt Internet-Drafts can also be obtained by e-mail. Send a message to: mailserv@ietf.org. In the body type: "FILE /internet-drafts/draft-ietf-webdav-acl-01.txt". NOTE: The mail server at ietf.org can return the document in MIME-encoded form by using the "mpack" utility. To use this feature, insert the command "ENCODING mime" before the "FILE" command. To decode the response(s), you will need "munpack" or a MIME-compliant mail reader. Different MIME-compliant mail readers exhibit different behavior, especially when dealing with "multipart" MIME messages (i.e. documents which have been split up into multiple messages), so check your local documentation on how to manipulate these messages. Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Multipart/Alternative; Boundary="OtherAccess" --OtherAccess Content-Type: Message/External-body; access-type="mail-server"; server="mailserv@ietf.org" Content-Type: text/plain Content-ID: <20000505103923.I-D@ietf.org> ENCODING mime FILE /internet-drafts/draft-ietf-webdav-acl-01.txt --OtherAccess Content-Type: Message/External-body; name="draft-ietf-webdav-acl-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <20000505103923.I-D@ietf.org> --OtherAccess-- --NextPart-- From w3c-dist-auth-request@w3.org Tue May 9 18:00:47 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 SAA01705 for ; Tue, 9 May 2000 18:00:46 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA08497; Tue, 9 May 2000 17:57:57 -0400 (EDT) Resent-Date: Tue, 9 May 2000 17:57:57 -0400 (EDT) Resent-Message-Id: <200005092157.RAA08497@www19.w3.org> Message-ID: <39188A47.389ACA5E@kovair.com> Date: Tue, 09 May 2000 14:59:35 -0700 From: gabe@kovair.com (Gabriel Lawrence) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 To: w3c-dist-auth@w3.org Content-Type: multipart/mixed; boundary="------------2E9DC568DE43D54B15D52FDD" Subject: MS Web Folders and properties... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4281 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 a multi-part message in MIME format. --------------2E9DC568DE43D54B15D52FDD Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Howdy, We are looking to use WebDAV as part of our server to handle the document management ui. One thing we collect in our current HTML version is some meta information for each file. I see the WebDAV protocol supports setting properties for files, but what I dont see anywhere is how the tools available out there work... If I set up our server to ask for a description property, how can a user specifiy that property using MS Web Folders, or any of the other ways? Sorry if this is a common question, I looked around and didn't find anything obvious. Thanx, -gabe --------------2E9DC568DE43D54B15D52FDD Content-Type: text/x-vcard; charset=us-ascii; name="gabe.vcf" Content-Description: Card for Gabriel Lawrence Content-Disposition: attachment; filename="gabe.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Lawrence;Gabriel tel;work:(408) 491-9731 Ext 207 x-mozilla-html:FALSE org:
The power to .wow your customers. version:2.1 email;internet:gabe@kovair.com title:Architect note:The power to .wow your customers. adr;quoted-printable:;;=0D=0A2 North First Street =0D=0ASuite 212;San Jose;Ca;95113-1202;USA x-mozilla-cpt:;-30848 fn:Gabriel Lawrence end:vcard --------------2E9DC568DE43D54B15D52FDD-- From w3c-dist-auth-request@w3.org Fri May 12 20:14: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 UAA18782 for ; Fri, 12 May 2000 20:14:51 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA19831; Fri, 12 May 2000 19:59:50 -0400 (EDT) Resent-Date: Fri, 12 May 2000 19:59:50 -0400 (EDT) Resent-Message-Id: <200005122359.TAA19831@www19.w3.org> From: Jim Whitehead To: Gabriel Lawrence , w3c-dist-auth@w3.org MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Fri, 12 May 2000 16:58:00 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 In-Reply-To: <39188A47.389ACA5E@kovair.com> Importance: Normal Subject: RE: MS Web Folders and properties... Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4282 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 > We are looking to use WebDAV as part of our server to handle the > document management ui. One thing we collect in our current HTML version > is some meta information for each file. I see the WebDAV protocol > supports setting properties for files, but what I dont see anywhere is > how the tools available out there work... If I set up our server to ask > for a description property, how can a user specifiy that property using > MS Web Folders, or any of the other ways? At present, MS Web Folders do not allow you to set arbitrary properties on WebDAV resources. Since Office 2000 uses Web Folders, arbitrary WebDAV properties cannot be set in Office applications. Since many Office applications do allow within-object metadata to be set, it is conceivable that an intelligent WebDAV server could extract this within-object metadata, and expose it as a WebDAV property value. - Jim From w3c-dist-auth-request@w3.org Fri May 12 20:19:17 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 UAA18830 for ; Fri, 12 May 2000 20:19:16 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA20359; Fri, 12 May 2000 20:12:43 -0400 (EDT) Resent-Date: Fri, 12 May 2000 20:12:43 -0400 (EDT) Resent-Message-Id: <200005130012.UAA20359@www19.w3.org> From: Jim Whitehead To: WebDAV WG Date: Fri, 12 May 2000 17:10:54 -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) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal Subject: WebDAV properties: why the lack of support? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4283 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 So, Gabriel Lawrence's email has prompted me to bring up a question I've been mulling for awhile: why have WebDAV applications tended not to provide support for setting arbitrary properties? One hypothesis is that WebDAV tools so far have been interested in the protocol as a form of Web-based network file access protocol. Certainly this is consistent with the way Web Folders, sitecopy, and the WebDAV Explorer view the world, and the main motivation for the Web-based storage sites like Sharemation to provide WebDAV support. Another hypothesis is that the value of properties only emerges once a searching mechanism is available. Since DASL is not complete, there is no reason for users to set metadata, since there is no way to use it. Generalizing, there isn't any use, because there aren't any clients that exploit metadata for their usage. A third hypothesis is that there aren't any current conventions for how to use WebDAV properties. For example, even if you did want to set some bibliographic metadata on a resource, how would you do it? What property name would you use, and how would the data be formatted? It seems to me some standardization effort is needed here. The Internet-Draft submitted by Elliot Christian, draft-christian-prop-semantics-00.txt, available at: http://www.ietf.org/internet-drafts/draft-christian-prop-semantics-00.txt is one example of the kind of work that needs to take place to establish property usage conventions. John Stracke's I-D, "Use of Dublin Core Metadata in WebDAV", draft-ietf-webdav-dublin-core-01.txt, available at: http://www.ics.uci.edu/pub/ietf/webdav/dc/draft-ietf-webdav-dublin-core-01.t xt is another. But, maybe there are other reasons why WebDAV properties have, so far, not been used. Thoughts? - Jim From w3c-dist-auth-request@w3.org Sat May 13 11:49:16 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 LAA09350 for ; Sat, 13 May 2000 11:49:16 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA01083; Sat, 13 May 2000 11:44:38 -0400 (EDT) Resent-Date: Sat, 13 May 2000 11:44:38 -0400 (EDT) Resent-Message-Id: <200005131544.LAA01083@www19.w3.org> Reply-To: From: "John Mott" To: "Jim Whitehead" , "WebDAV WG" Date: Sat, 13 May 2000 10:40:32 -0500 Message-ID: <000d01bfbcf1$92ab3fe0$2800000a@ci70795-a.nash1.tn.home.com> 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 8.5, Build 4.71.2173.0 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.2106.4 In-Reply-To: Importance: Normal Subject: RE: WebDAV properties: why the lack of support? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4284 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 The eKeeper application does precisely this; we store user-defined properties on the server. Those properties are defined within the context of our application, to be sure, but we are using WebDAV as it was intended; to store buckets of arbitrary properties, perhaps from different namespaces, with a resource on the server. John Mott CTO, eKeeper.com > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > Sent: Friday, May 12, 2000 7:11 PM > To: WebDAV WG > Subject: WebDAV properties: why the lack of support? > > > So, Gabriel Lawrence's email has prompted me to bring up a question I've > been mulling for awhile: why have WebDAV applications tended not > to provide > support for setting arbitrary properties? > > One hypothesis is that WebDAV tools so far have been interested in the > protocol as a form of Web-based network file access protocol. Certainly > this is consistent with the way Web Folders, sitecopy, and the WebDAV > Explorer view the world, and the main motivation for the Web-based storage > sites like Sharemation to provide WebDAV support. > > Another hypothesis is that the value of properties only emerges once a > searching mechanism is available. Since DASL is not complete, there is no > reason for users to set metadata, since there is no way to use it. > Generalizing, there isn't any use, because there aren't any clients that > exploit metadata for their usage. > > A third hypothesis is that there aren't any current conventions for how to > use WebDAV properties. For example, even if you did want to set some > bibliographic metadata on a resource, how would you do it? What property > name would you use, and how would the data be formatted? It seems to me > some standardization effort is needed here. The Internet-Draft > submitted by > Elliot Christian, draft-christian-prop-semantics-00.txt, available at: > http://www.ietf.org/internet-drafts/draft-christian-prop-semantics -00.txt is one example of the kind of work that needs to take place to establish property usage conventions. John Stracke's I-D, "Use of Dublin Core Metadata in WebDAV", draft-ietf-webdav-dublin-core-01.txt, available at: http://www.ics.uci.edu/pub/ietf/webdav/dc/draft-ietf-webdav-dublin-core-01.t xt is another. But, maybe there are other reasons why WebDAV properties have, so far, not been used. Thoughts? - Jim From w3c-dist-auth-request@w3.org Tue May 16 12:52:11 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 MAA08860 for ; Tue, 16 May 2000 12:52:11 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA08885; Tue, 16 May 2000 12:45:56 -0400 (EDT) Resent-Date: Tue, 16 May 2000 12:45:56 -0400 (EDT) Resent-Message-Id: <200005161645.MAA08885@www19.w3.org> Message-ID: <39217B8F.CDA77005@kovair.com> Date: Tue, 16 May 2000 09:47:11 -0700 From: gabe@kovair.com (Gabriel Lawrence) X-Mailer: Mozilla 4.72 [en] (WinNT; I) X-Accept-Language: en MIME-Version: 1.0 CC: Jim Whitehead , WebDAV WG References: <000d01bfbcf1$92ab3fe0$2800000a@ci70795-a.nash1.tn.home.com> Content-Type: multipart/mixed; boundary="------------65158DC4351394F8C089F738" Subject: Re: WebDAV properties: why the lack of support? To: w3c-dist-auth@w3.org Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4285 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 a multi-part message in MIME format. --------------65158DC4351394F8C089F738 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Darn.... We have a document repository in our application today. We store simple meta information, name and description....Just enough to give a user a feel for the document before they go through all the trouble to download it. Our users have told us they want tighter integration with the filesystem - WebDAV is perfect for this solution. You'll notice that this use of properties does only a little for searching - most real search would need to look into the content of the document. But browsing is different. This really is a helper for folks browsing the repository. I know that many Office documents have meta information in them - it would be especially cool if that meta information was exposed using WebDAV when they get saved using WebDAV also... The reality is that many servers are coming, and many of them offer different experiences then simple web servers. It would be nice if the fancy clients out there would enable these servers. I cant imagine that the exchange team over at microsoft isn't interested in features like this? It would also make the server generated index page pretty cool in IIS... I'd like to lobby the MS folks on this list hard to consider putting this stuff in. Your leadership could really change the way documents on the web are handled. The lack of solid meta information about a document before it is downloaded is something that the Web has been missing since the very beginning! -gabe John Mott wrote: > The eKeeper application does precisely this; we store user-defined > properties on the server. Those properties are defined within the context of > our application, to be sure, but we are using WebDAV as it was intended; to > store buckets of arbitrary properties, perhaps from different namespaces, > with a resource on the server. > > John Mott > CTO, eKeeper.com > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > > Sent: Friday, May 12, 2000 7:11 PM > > To: WebDAV WG > > Subject: WebDAV properties: why the lack of support? > > > > > > So, Gabriel Lawrence's email has prompted me to bring up a question I've > > been mulling for awhile: why have WebDAV applications tended not > > to provide > > support for setting arbitrary properties? > > > > One hypothesis is that WebDAV tools so far have been interested in the > > protocol as a form of Web-based network file access protocol. Certainly > > this is consistent with the way Web Folders, sitecopy, and the WebDAV > > Explorer view the world, and the main motivation for the Web-based storage > > sites like Sharemation to provide WebDAV support. > > > > Another hypothesis is that the value of properties only emerges once a > > searching mechanism is available. Since DASL is not complete, there is no > > reason for users to set metadata, since there is no way to use it. > > Generalizing, there isn't any use, because there aren't any clients that > > exploit metadata for their usage. > > > > A third hypothesis is that there aren't any current conventions for how to > > use WebDAV properties. For example, even if you did want to set some > > bibliographic metadata on a resource, how would you do it? What property > > name would you use, and how would the data be formatted? It seems to me > > some standardization effort is needed here. The Internet-Draft > > submitted by > > Elliot Christian, draft-christian-prop-semantics-00.txt, available at: > > http://www.ietf.org/internet-drafts/draft-christian-prop-semantics > -00.txt is > one example of the kind of work that needs to take place to establish > property usage conventions. John Stracke's I-D, "Use of Dublin Core Metadata > in WebDAV", draft-ietf-webdav-dublin-core-01.txt, available at: > http://www.ics.uci.edu/pub/ietf/webdav/dc/draft-ietf-webdav-dublin-core-01.t > xt is another. > > But, maybe there are other reasons why WebDAV properties have, so far, not > been used. > > Thoughts? > > - Jim --------------65158DC4351394F8C089F738 Content-Type: text/x-vcard; charset=us-ascii; name="gabe.vcf" Content-Description: Card for Gabriel Lawrence Content-Disposition: attachment; filename="gabe.vcf" Content-Transfer-Encoding: 7bit begin:vcard n:Lawrence;Gabriel tel;work:(408) 491-9731 Ext 207 x-mozilla-html:FALSE org:
The power to .wow your customers. version:2.1 email;internet:gabe@kovair.com title:Architect note:The power to .wow your customers. adr;quoted-printable:;;=0D=0A2 North First Street =0D=0ASuite 212;San Jose;Ca;95113-1202;USA x-mozilla-cpt:;-30848 fn:Gabriel Lawrence end:vcard --------------65158DC4351394F8C089F738-- From w3c-dist-auth-request@w3.org Tue May 16 14:20:31 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 OAA10492 for ; Tue, 16 May 2000 14:20:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA12080; Tue, 16 May 2000 14:14:19 -0400 (EDT) Resent-Date: Tue, 16 May 2000 14:14:19 -0400 (EDT) Resent-Message-Id: <200005161814.OAA12080@www19.w3.org> Message-ID: From: "Meltsner, Kenneth" To: gabe@kovair.com, w3c-dist-auth@w3.org Cc: WebDAV WG Date: Tue, 16 May 2000 14:16:15 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: WebDAV properties: why the lack of support? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4286 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list As an aside, MS Office files have quite a bit of metadata buried in them -- right click on one and use the properties command to view. There's a DLL to access this information as well -- search support.microsoft.com for "dsofile.exe" or references to "document summary". [I used a similar DLL from Microsoft to pull out document properties for a prototype DM system I wrote; I believe there's also a third-party DLL with the ability to write the properties as well.] This isn't generally true, of course -- the metadata is stored as part of the Windows-specific (OLE 2) file format for Office, and doesn't apply to any cross-platform documents. Ken Meltsner -----Original Message----- From: gabe@kovair.com [mailto:gabe@kovair.com] Sent: Tuesday, May 16, 2000 11:47 AM To: w3c-dist-auth@w3.org Cc: Jim Whitehead; WebDAV WG Subject: Re: WebDAV properties: why the lack of support? Darn.... We have a document repository in our application today. We store simple meta information, name and description....Just enough to give a user a feel for the document before they go through all the trouble to download it. Our users have told us they want tighter integration with the filesystem - WebDAV is perfect for this solution. You'll notice that this use of properties does only a little for searching - most real search would need to look into the content of the document. But browsing is different. This really is a helper for folks browsing the repository. I know that many Office documents have meta information in them - it would be especially cool if that meta information was exposed using WebDAV when they get saved using WebDAV also... The reality is that many servers are coming, and many of them offer different experiences then simple web servers. It would be nice if the fancy clients out there would enable these servers. I cant imagine that the exchange team over at microsoft isn't interested in features like this? It would also make the server generated index page pretty cool in IIS... I'd like to lobby the MS folks on this list hard to consider putting this stuff in. Your leadership could really change the way documents on the web are handled. The lack of solid meta information about a document before it is downloaded is something that the Web has been missing since the very beginning! -gabe John Mott wrote: > The eKeeper application does precisely this; we store user-defined > properties on the server. Those properties are defined within the context of > our application, to be sure, but we are using WebDAV as it was intended; to > store buckets of arbitrary properties, perhaps from different namespaces, > with a resource on the server. > > John Mott > CTO, eKeeper.com > > > -----Original Message----- > > From: w3c-dist-auth-request@w3.org > > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Jim Whitehead > > Sent: Friday, May 12, 2000 7:11 PM > > To: WebDAV WG > > Subject: WebDAV properties: why the lack of support? > > > > > > So, Gabriel Lawrence's email has prompted me to bring up a question I've > > been mulling for awhile: why have WebDAV applications tended not > > to provide > > support for setting arbitrary properties? > > > > One hypothesis is that WebDAV tools so far have been interested in the > > protocol as a form of Web-based network file access protocol. Certainly > > this is consistent with the way Web Folders, sitecopy, and the WebDAV > > Explorer view the world, and the main motivation for the Web-based storage > > sites like Sharemation to provide WebDAV support. > > > > Another hypothesis is that the value of properties only emerges once a > > searching mechanism is available. Since DASL is not complete, there is no > > reason for users to set metadata, since there is no way to use it. > > Generalizing, there isn't any use, because there aren't any clients that > > exploit metadata for their usage. > > > > A third hypothesis is that there aren't any current conventions for how to > > use WebDAV properties. For example, even if you did want to set some > > bibliographic metadata on a resource, how would you do it? What property > > name would you use, and how would the data be formatted? It seems to me > > some standardization effort is needed here. The Internet-Draft > > submitted by > > Elliot Christian, draft-christian-prop-semantics-00.txt, available at: > > http://www.ietf.org/internet-drafts/draft-christian-prop-semantics > -00.txt is > one example of the kind of work that needs to take place to establish > property usage conventions. John Stracke's I-D, "Use of Dublin Core Metadata > in WebDAV", draft-ietf-webdav-dublin-core-01.txt, available at: > http://www.ics.uci.edu/pub/ietf/webdav/dc/draft-ietf-webdav-dublin-core-01.t > xt is another. > > But, maybe there are other reasons why WebDAV properties have, so far, not > been used. > > Thoughts? > > - Jim From w3c-dist-auth-request@w3.org Thu May 18 13:01:36 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 NAA10576 for ; Thu, 18 May 2000 13:01:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id MAA13578; Thu, 18 May 2000 12:52:25 -0400 (EDT) Resent-Date: Thu, 18 May 2000 12:52:25 -0400 (EDT) Resent-Message-Id: <200005181652.MAA13578@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC01D4D8B6@chef.lex.rational.com> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Thu, 18 May 2000 12:46:52 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: text/plain; charset="iso-8859-1" Subject: RE: DAV: header values Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4287 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'd probably vote for extend = Coded-URL | token so that standard DAV defined extensions can be specified in a terse form. Cheers, Geoff -----Original Message----- From: Greg Stein [mailto:gstein@lyra.org] Sent: Monday, April 10, 2000 5:37 PM To: Juergen Reuter Cc: jjh@ira.uka.de; w3c-dist-auth@w3.org Subject: Re: DAV: header values 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 Thu May 18 13:31: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 NAA10939 for ; Thu, 18 May 2000 13:31:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA14518; Thu, 18 May 2000 13:26:29 -0400 (EDT) Resent-Date: Thu, 18 May 2000 13:26:29 -0400 (EDT) Resent-Message-Id: <200005181726.NAA14518@www19.w3.org> Date: Thu, 18 May 2000 10:25:14 -0700 (PDT) From: Greg Stein To: "Clemm, Geoff" cc: w3c-dist-auth@w3.org In-Reply-To: <65B141FB11CCD211825700A0C9D609BC01D4D8B6@chef.lex.rational.com> 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/4288 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'm fine with this. Note that mod_dav 0.9.17 (and the next release, 1.0.0) already uses a Coded-URL in the DAV: header. Specifically a mod_dav response looks like: DAV: 1,2, Cheers, -g On Thu, 18 May 2000, Clemm, Geoff wrote: > I'd probably vote for > > extend = Coded-URL | token > > so that standard DAV defined extensions can be specified in a terse form. > > Cheers, > Geoff > > -----Original Message----- > From: Greg Stein [mailto:gstein@lyra.org] > Sent: Monday, April 10, 2000 5:37 PM > To: Juergen Reuter > Cc: jjh@ira.uka.de; w3c-dist-auth@w3.org > Subject: Re: DAV: header values > > > 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/ > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Thu May 18 17:11:31 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 RAA13232 for ; Thu, 18 May 2000 17:11:28 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA19258; Thu, 18 May 2000 17:06:36 -0400 (EDT) Resent-Date: Thu, 18 May 2000 17:06:36 -0400 (EDT) Resent-Message-Id: <200005182106.RAA19258@www19.w3.org> Date: Thu, 18 May 2000 17:06:19 -0400 (EDT) From: "Geoffrey M. Clemm" Message-Id: <200005182106.RAA06050@tantalum.atria.com> To: w3c-dist-auth@w3.org Subject: Status of Pittsburgh IETF meeting??? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4289 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 IETF Meetings page just lists this as happening from July 30 - August 4 Rather than comment on the choice of Pittsburgh in August (:-), I will just ask whether a hotel has been selected yet? If so, anybody know what it is (and why it isn't on the web page)? If not, isn't time getting a bit short? Cheers, Geoff From w3c-dist-auth-request@w3.org Thu May 18 18:49:57 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 SAA13958 for ; Thu, 18 May 2000 18:49:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA21333; Thu, 18 May 2000 18:42:32 -0400 (EDT) Resent-Date: Thu, 18 May 2000 18:42:32 -0400 (EDT) Resent-Message-Id: <200005182242.SAA21333@www19.w3.org> Date: Thu, 18 May 2000 15:41:28 -0700 (PDT) From: Greg Stein To: w3c-dist-auth@w3.org In-Reply-To: <200005182106.RAA06050@tantalum.atria.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Status of Pittsburgh IETF meeting??? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4290 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 Thu, 18 May 2000, Geoffrey M. Clemm wrote: > The IETF Meetings page just lists this as happening from July 30 - August 4 > Rather than comment on the choice of Pittsburgh in August (:-), I will just I'll comment on it. It's friggin miserable. Temperature 95 degrees, humidity 95%. Step outside and you start sweating immediately. Bleck. I went to school in Pgh and spent the summers there. Damned glad to have a CS job where there was air conditioning in the buildings. Geoff's implicit comment is spot on: Pgh is great in the fall or spring. August? Somebody needs a boot to the head for that one. :-) Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri May 19 13:27:44 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 NAA08566 for ; Fri, 19 May 2000 13:27:43 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id NAA13377; Fri, 19 May 2000 13:19:01 -0400 (EDT) Resent-Date: Fri, 19 May 2000 13:19:01 -0400 (EDT) Resent-Message-Id: <200005191719.NAA13377@www19.w3.org> From: Jim Whitehead To: w3c-dist-auth@w3.org MMDF-Warning: Parse error in original version of preceding line at gremlin-relay.ics.uci.edu Date: Fri, 19 May 2000 10:16:53 -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) In-Reply-To: Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Subject: RE: Status of Pittsburgh IETF meeting??? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4291 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 Well, I just asked Patrik Faltrom if he had any additional information on this meeting, and he didn't. Once information becomes available, it will be posted at: http://www.ietf.org/meetings/meetings.html Also, if you're subscribed to the IETF announce mailing list (ietf-announce@ietf.org --> to subscribe, send a message to ietf-announce-request@ietf.org with a subject line of "subscribe") then an announcement usually comes out on that list as well. As for the weather, why should you care? You'll be inside working on specs. the whole time anyway, and when you're sick of that, it'll be 1 or 2 AM anyway, when it's a little cooler :-) - Jim > > The IETF Meetings page just lists this as happening from July 30 - August 4 > > Rather than comment on the choice of Pittsburgh in August (:-), I will just > > I'll comment on it. It's friggin miserable. Temperature 95 degrees, > humidity 95%. Step outside and you start sweating immediately. Bleck. > > I went to school in Pgh and spent the summers there. Damned glad to have a > CS job where there was air conditioning in the buildings. > > Geoff's implicit comment is spot on: Pgh is great in the fall or spring. > August? Somebody needs a boot to the head for that one. > From w3c-dist-auth-request@w3.org Thu May 25 19:29:49 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 TAA22643 for ; Thu, 25 May 2000 19:29:49 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA27465; Thu, 25 May 2000 19:20:12 -0400 (EDT) Resent-Date: Thu, 25 May 2000 19:20:12 -0400 (EDT) Resent-Message-Id: <200005252320.TAA27465@www19.w3.org> Message-Id: X-Mailer: Novell GroupWise Internet Agent 5.5.3.1 Date: Thu, 25 May 2000 16:28:48 -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 TAA27441 Subject: Passwords and WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4292 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 This may be an issue that has scope beyond WebDAV, however the problems we are having are WebDAV related. Also I believe this is an issue that is more important to WebDAV then it is to the http protocol in general. We need to have the ability to expire passwords to force users to change passwords. When a users password is expired they are given a number of grace logins. For normal http access, when a user on grace logins the web server can redirect them to a page that allows them to change their password. However, when using WebDAV clients (in particular web folders, and Office 2000) the redirect to a page to change passwords does not work. Given that a WebDAV client may not be a browser and therefore may not know how to display html there needs to be another solution for expired passwords. It seems to me that this could be something the WebDAV group could address. Maybe an addition to WebDAV that allows for notification that the users account needs to be updated (password changed) and a method of changing updating user account information. From w3c-dist-auth-request@w3.org Thu May 25 19:53: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 TAA23048 for ; Thu, 25 May 2000 19:53:52 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id TAA27994; Thu, 25 May 2000 19:44:49 -0400 (EDT) Resent-Date: Thu, 25 May 2000 19:44:49 -0400 (EDT) Resent-Message-Id: <200005252344.TAA27994@www19.w3.org> Date: Thu, 25 May 2000 16:44:12 -0700 (PDT) From: Greg Stein To: Dan Burton cc: "<" In-Reply-To: Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: Passwords and WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4293 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, changing passwords is out-of-scope of WebDAV. There are too many authentication systems and mechanisms out there, with too many variant requirements for changing passwords. While it would certainly be possible to create an HTTP-based protocol for changing passwords, that seems to be an issue between the client and the authentication system (which is probably separate from the web server). YMMV Cheers, -g On Thu, 25 May 2000, Dan Burton wrote: > This may be an issue that has scope beyond WebDAV, however the > problems we are having are WebDAV related. Also I believe this is an > issue that is more important to WebDAV then it is to the http protocol > in general. > > We need to have the ability to expire passwords to force users to > change passwords. When a users password is expired they are given a > number of grace logins. For normal http access, when a user on grace > logins the web server can redirect them to a page that allows them to > change their password. However, when using WebDAV clients (in > particular web folders, and Office 2000) the redirect to a page to > change passwords does not work. Given that a WebDAV client may not be > a browser and therefore may not know how to display html there needs > to be another solution for expired passwords. > > It seems to me that this could be something the WebDAV group could > address. Maybe an addition to WebDAV that allows for notification that > the users account needs to be updated (password changed) and a method > of changing updating user account information. > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Fri May 26 08:09: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 IAA13027 for ; Fri, 26 May 2000 08:09:13 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id HAA11609; Fri, 26 May 2000 07:57:38 -0400 (EDT) Resent-Date: Fri, 26 May 2000 07:57:38 -0400 (EDT) Resent-Message-Id: <200005261157.HAA11609@www19.w3.org> Reply-To: From: "Kevin Dyer" To: "Greg Stein" , "Dan Burton" Cc: Date: Fri, 26 May 2000 07:56:27 -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.2911.0) X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2314.1300 Importance: Normal In-Reply-To: Subject: RE: Passwords and WebDAV Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4294 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 > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein > Sent: Thursday, May 25, 2000 7:44 PM > To: Dan Burton > Cc: < > Subject: Re: Passwords and WebDAV > > > IMO, changing passwords is out-of-scope of WebDAV. There are too many Changing passwords may be out-of-scope but providing a return code mechanism for revoking credentials, or to inform the user that their password/temporary password must be renewed is not. About a year and a half ago I made a suggestion to the HTTP-WG that we add a return code or set of return codes to do just that. Provide a mechanism to the underlying authentication and authorization systems that allows the system to notify it's users in a standardized manner that something needs to be addressed. The suggestion was tabled due to the timing and where 1.1 was in the loop. As Dan points out most of the new clients that are interfacing with a WebDAV server are not browsers so they are incapable of displaying HTML pages. So what do we put into the protocol to allow such interoperability? > authentication systems and mechanisms out there, with too many variant > requirements for changing passwords. > > While it would certainly be possible to create an HTTP-based protocol for > changing passwords, that seems to be an issue between the client and the > authentication system (which is probably separate from the web server). > > YMMV > > Cheers, > -g > > On Thu, 25 May 2000, Dan Burton wrote: > > This may be an issue that has scope beyond WebDAV, however the > > problems we are having are WebDAV related. Also I believe this is an > > issue that is more important to WebDAV then it is to the http protocol > > in general. > > > > We need to have the ability to expire passwords to force users to > > change passwords. When a users password is expired they are given a [snip Dan's description of non-browser interactions] > > It seems to me that this could be something the WebDAV group could > > address. Maybe an addition to WebDAV that allows for notification that > > the users account needs to be updated (password changed) and a method > > of changing updating user account information. > > From w3c-dist-auth-request@w3.org Sat May 27 16:02:20 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 QAA20895 for ; Sat, 27 May 2000 16:02:19 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA26869; Sat, 27 May 2000 15:56:29 -0400 (EDT) Resent-Date: Sat, 27 May 2000 15:56:29 -0400 (EDT) Resent-Message-Id: <200005271956.PAA26869@www19.w3.org> Date: Sat, 27 May 2000 12:56:06 -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: If: header and "parent" resource checking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4295 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'm going through mod_dav right now and refining/verifying what resources it checks during If: header processing. I'm taking a particular approach that I want to bounce off the group to see if this makes sense and is "proper". Specifically, it revolves around whether we need to check the "parent" resource to see if it is locked and the If: header contains those locks. Say you're doing a MKCOL. The spec states that you must satisfy the locks held on the parent resource. The following cases are a bit less obvious: *) when using LOCK to create a locknull resource, this effectively creates a new resource in the parent collection. ==> parent resource should be checked *) when using UNLOCK on a locknull, this effectively deletes a resource from the parent collection ==> parent resource should be checked *) using MOVE on a resource: this removes the resource from the parent ==> parent resource should be checked *) MOVE and COPY create resources at the Destination ==> parent resource of the Destination should be checked *) MKCOL on a null resource ==> parent resource should be checked *) MKCOL on a locknull resource does not add any resources to the parent collection ==> parent resource SHOULD NOT be checked (the [locknull] resource itself will be checked, however) *) PUT operates similar to MKCOL w.r.t. locknull resources Note that this can be an interoperability item. If one server enforces that conditions be met for the parent, but another doesn't, then a client (that doesn't provide parent conditions) could fail. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Sat May 27 17:02: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 RAA21129 for ; Sat, 27 May 2000 17:02:09 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA28023; Sat, 27 May 2000 16:57:58 -0400 (EDT) Resent-Date: Sat, 27 May 2000 16:57:58 -0400 (EDT) Resent-Message-Id: <200005272057.QAA28023@www19.w3.org> Date: Sat, 27 May 2000 13:57:37 -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: case-sensitivity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4296 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've been assuming that words such as "infinity" and "T" and "F" are case-sensitive, using the case defined in RFC 2518. However, I just found the following in RFC 2616: Section 2.1 (part of the Augmented BNF description): (for literals) ".... Unless stated otherwise, the text is case-insensitive." In RFC 2518, Section 2, we state that WebDAV uses the same conventions as HTTP/1.1. Does that mean that the literals in RFC 2518 should be treated in a case-insensitive manner by the server? Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Sat May 27 18:43:11 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 SAA21641 for ; Sat, 27 May 2000 18:43:11 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA29444; Sat, 27 May 2000 18:38:58 -0400 (EDT) Resent-Date: Sat, 27 May 2000 18:38:58 -0400 (EDT) Resent-Message-Id: <200005272238.SAA29444@www19.w3.org> Message-ID: <9BDBBF9512077F48ABBDFB197908A9610C91E2@red-pt-01.redmond.corp.microsoft.com> From: Brian Morin To: "'Greg Stein'" , w3c-dist-auth@w3.org Date: Sat, 27 May 2000 15:38:14 -0700 X-Mailer: Internet Mail Service (5.5.2651.58) Subject: RE: case-sensitivity Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4297 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 falls under general application robustness, particularly for server implementers. Whether it's written in the spec or not, inevitably someone will build an application that works against server X but not yours (client/server in-breeding) unless you are forgiving about minor details. Here is my short list of deviations I have seen (including my collage work on Fnord Web Server): o Do not assume case on any value that is not explitly case sensitive for functional reasons o Do not assume a particular white space padding o Do not assume anything about the formatting of paths (trailing slashes, / or \, etc.) o Do not assume real CR-LF pairs (accept CR or LF without the other) Your millage may vary. Brian Morin Software Development Engineer MSN Communities -----Original Message----- From: Greg Stein [mailto:gstein@lyra.org] Sent: Saturday, May 27, 2000 1:58 PM To: w3c-dist-auth@w3.org Subject: case-sensitivity I've been assuming that words such as "infinity" and "T" and "F" are case-sensitive, using the case defined in RFC 2518. However, I just found the following in RFC 2616: Section 2.1 (part of the Augmented BNF description): (for literals) ".... Unless stated otherwise, the text is case-insensitive." In RFC 2518, Section 2, we state that WebDAV uses the same conventions as HTTP/1.1. Does that mean that the literals in RFC 2518 should be treated in a case-insensitive manner by the server? Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Sat May 27 23:32:30 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 XAA25636 for ; Sat, 27 May 2000 23:32:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA02373; Sat, 27 May 2000 23:27:46 -0400 (EDT) Resent-Date: Sat, 27 May 2000 23:27:46 -0400 (EDT) Resent-Message-Id: <200005280327.XAA02373@www19.w3.org> Date: Sat, 27 May 2000 23:27:25 -0400 (EDT) Message-Id: <200005280327.XAA19800@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 Sat, 27 May 2000 12:56:06 -0700 (PDT)) References: Subject: Re: If: header and "parent" resource checking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4298 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list What Greg proposes is consistent with what is stated in 2518. But I believe it is also consistent to say that a lock null resource is not treated as a real member of a collection (just as there are various other ways where it doesn't act like a real resource). This is compatible with section 7.5 of 2518, which states that: when a principal issues a PUT or POST request to create a new resource under a URI which needs to be an internal member of a write locked collection to maintain HTTP namespace consistency, or issues a DELETE to remove a resource which has a URI which is an existing internal member URI of a write locked collection, this request MUST fail if the principal does not have a write lock on the collection. i.e. it says nothing about the creation of "lock-null" resources via the LOCK request. Having a LOCK request not interact with locks on a parent collection ensures that a LOCK request has consistent behavior wrt a write-locked parent collection, whether or not a resource currently exists at the LOCK request-URL. It also ensures you do not get the bizarre behavior where the first shared lock on a null resource requires the lock token for a locked parent collection, while all subsequent shared locks do not. So I would defer the need for a lock token for the collection lock until the PUT or MKCOL is made. Similarly, I believe an UNLOCK should *never* require a lock token other than the one being unlocked. With this premise, I'd make the following changes to Greg's proposal: From: Greg Stein *) when using LOCK to create a locknull resource, this effectively creates a new resource in the parent collection. ==> parent resource should be checked I want no parent resource check for this. *) when using UNLOCK on a locknull, this effectively deletes a resource from the parent collection ==> parent resource should be checked I want no parent resource check for this. *) using MOVE on a resource: this removes the resource from the parent ==> parent resource should be checked I agree. *) MOVE and COPY create resources at the Destination ==> parent resource of the Destination should be checked I agree. *) MKCOL on a null resource ==> parent resource should be checked I agree. *) MKCOL on a locknull resource does not add any resources to the parent collection ==> parent resource SHOULD NOT be checked (the [locknull] resource itself will be checked, however) I want the lock token to be required. *) PUT operates similar to MKCOL w.r.t. locknull resources I agree that PUT should operate similar to MKCOL wrt locknull resources (but I would want a lock token to be required). Note that this can be an interoperability item. If one server enforces that conditions be met for the parent, but another doesn't, then a client (that doesn't provide parent conditions) could fail. Cheers, Geoff From w3c-dist-auth-request@w3.org Sun May 28 06:45:44 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 GAA07127 for ; Sun, 28 May 2000 06:45:44 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id GAA06240; Sun, 28 May 2000 06:41:28 -0400 (EDT) Resent-Date: Sun, 28 May 2000 06:41:28 -0400 (EDT) Resent-Message-Id: <200005281041.GAA06240@www19.w3.org> Date: Sun, 28 May 2000 03:41:01 -0700 (PDT) From: Greg Stein To: "Geoffrey M. Clemm" cc: w3c-dist-auth@w3.org In-Reply-To: <200005280327.XAA19800@tantalum.atria.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: If: header and "parent" resource checking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4299 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, 27 May 2000, Geoffrey M. Clemm wrote: > What Greg proposes is consistent with what is stated in 2518. > > But I believe it is also consistent to say that a lock null resource > is not treated as a real member of a collection (just as there are > various other ways where it doesn't act like a real resource). I see no rationale to create more differences :-) > This is compatible with section 7.5 of 2518, which states that: > > when a principal issues a PUT or POST request to create a new > resource under a URI which needs to be an internal member of a write > locked collection to maintain HTTP namespace consistency, or issues a > DELETE to remove a resource which has a URI which is an existing > internal member URI of a write locked collection, this request MUST > fail if the principal does not have a write lock on the collection. > > i.e. it says nothing about the creation of "lock-null" resources via > the LOCK request. I think that you are being too literal in your reading [in order to support your position]. Note that the text in question does not mention MKCOL or BIND, yet we expect the client to provide a locktoken for the parent on those methods. In other words, I am reading S7.5 as a "general description of behavior" rather than a literal/explicit description. As a result, the creation of ANY internal member, by ANY means, should (IMO) require the client to provide locktokens for the [write-locked] parent collection. > Having a LOCK request not interact with locks on a parent collection > ensures that a LOCK request has consistent behavior wrt a write-locked > parent collection, whether or not a resource currently exists at the > LOCK request-URL. It also ensures you do not get the bizarre behavior > where the first shared lock on a null resource requires the lock token > for a locked parent collection, while all subsequent shared locks do not. You can't issue two MKCOL methods for the same resource, so I believe there is precedent for the different behavior. Using lock to create a locknull resource is a state-changing operation of the target resource. It seems quite reasonable to have methods operate differently, based on the different states of that resource. Another counter-example for you: Collection (no internal members) The client issues a PUT to create "Resource" within Collection. Since this is the first PUT (thusly creating the internal member), locktoken A must be provided. Now the client issues a second PUT. But wait! The locktoken DOES NOT need to be provided. Therefore: I submit that your argument does not hold, and that the behavior that I detailed w.r.t. locknull resources is "correct." I'm still quite open to discussion, of course. I don't want to create incompatibilities in behavior. Cheers, -g p.s. of course, IIS5 doesn't even allow collection locks, so clients can simply be screwed anyhow :-) -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Sun May 28 14:20:04 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 OAA09613 for ; Sun, 28 May 2000 14:20:04 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id OAA10525; Sun, 28 May 2000 14:13:19 -0400 (EDT) Resent-Date: Sun, 28 May 2000 14:13:19 -0400 (EDT) Resent-Message-Id: <200005281813.OAA10525@www19.w3.org> Date: Sun, 28 May 2000 14:13:01 -0400 (EDT) Message-Id: <200005281813.OAA20828@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 Sun, 28 May 2000 03:41:01 -0700 (PDT)) References: Subject: Re: If: header and "parent" resource checking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4300 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 believe a "lock-null" resource is best treated as a convenient fiction maintained in order to make it easy to query for the existence of locks. In particular, according to section 7.4 of 2518, a lock null resource acts the same as a null resource for all methods except for PROPFIND and UNLOCK. A DELETE on a lock null resource MUST fail, a MOVE on a lock null resource MUST fail, a COPY on a lock null resource MUST fail, etc. The reason I am particularly concerned that the creation of a lock NOT be treated as a modification of the state of the parent collection is to ensure that effect of creating a lock-null resource is treated consistently in the versioning and the locking protocols. In the versioning protocol, the creation of a lock-null resource cannot be a modification to the state of the collection containing it, because if the collection were versioned, this would then require a new revision of that collection in order to hold the "new resource". But then this lock-null resource could never be removed from this collection revision, because revisions are immutable. On the other hand, if the addition of a lock is not considered a modification to the state of a collection, but rather the modification occurs at the first PUT, then all is well ... no "immutable" locks end up being captured. In this model, a lock is not a modification to the state of a resource (either the resource itself, or the collection containing the lock), but rather "metadata" that controls interactions with the state of the resource. In versioning, this is also how "labels" are handled, i.e. as metadata on a resource that does not modify the state of the resource. I'd *very* much like the versioning protocol and the locking protocol to be consistent as to whether the creation of a lock-null resource modifies the state of the collection containing them. Since I don't see that the versioning protocol has a choice in this regard, I'd like to see the locking protocol handle it the same way, unless there is some serious problem that arises from doing so. So I guess what I'd like to hear is why it is important for the addition of a lock-null resource to be treated as a modification to the state of the collection containing it. Cheers, Geoff Date: Sun, 28 May 2000 03:41:01 -0700 (PDT) From: Greg Stein On Sat, 27 May 2000, Geoffrey M. Clemm wrote: > What Greg proposes is consistent with what is stated in 2518. > > But I believe it is also consistent to say that a lock null resource > is not treated as a real member of a collection (just as there are > various other ways where it doesn't act like a real resource). I see no rationale to create more differences :-) > This is compatible with section 7.5 of 2518, which states that: > > when a principal issues a PUT or POST request to create a new > resource under a URI which needs to be an internal member of a write > locked collection to maintain HTTP namespace consistency, or issues a > DELETE to remove a resource which has a URI which is an existing > internal member URI of a write locked collection, this request MUST > fail if the principal does not have a write lock on the collection. > > i.e. it says nothing about the creation of "lock-null" resources via > the LOCK request. I think that you are being too literal in your reading [in order to support your position]. Note that the text in question does not mention MKCOL or BIND, yet we expect the client to provide a locktoken for the parent on those methods. In other words, I am reading S7.5 as a "general description of behavior" rather than a literal/explicit description. As a result, the creation of ANY internal member, by ANY means, should (IMO) require the client to provide locktokens for the [write-locked] parent collection. > Having a LOCK request not interact with locks on a parent collection > ensures that a LOCK request has consistent behavior wrt a write-locked > parent collection, whether or not a resource currently exists at the > LOCK request-URL. It also ensures you do not get the bizarre behavior > where the first shared lock on a null resource requires the lock token > for a locked parent collection, while all subsequent shared locks do not. You can't issue two MKCOL methods for the same resource, so I believe there is precedent for the different behavior. Using lock to create a locknull resource is a state-changing operation of the target resource. It seems quite reasonable to have methods operate differently, based on the different states of that resource. Another counter-example for you: Collection (no internal members) The client issues a PUT to create "Resource" within Collection. Since this is the first PUT (thusly creating the internal member), locktoken A must be provided. Now the client issues a second PUT. But wait! The locktoken DOES NOT need to be provided. Therefore: I submit that your argument does not hold, and that the behavior that I detailed w.r.t. locknull resources is "correct." I'm still quite open to discussion, of course. I don't want to create incompatibilities in behavior. Cheers, -g p.s. of course, IIS5 doesn't even allow collection locks, so clients can simply be screwed anyhow :-) -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon May 29 09:17: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 JAA00191 for ; Mon, 29 May 2000 09:17:27 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA25184; Mon, 29 May 2000 09:11:43 -0400 (EDT) Resent-Date: Mon, 29 May 2000 09:11:43 -0400 (EDT) Resent-Message-Id: <200005291311.JAA25184@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: Greg Stein cc: w3c-dist-auth@w3.org Message-ID: <852568EE.0048768E.00@d54mta02.raleigh.ibm.com> Date: Mon, 29 May 2000 09:10:47 -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 JAA25160 Subject: Re: If: header and "parent" resource checking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4301 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 Greg, I believe DAV4J behaves as you describe below. I'm going through mod_dav right now and refining/verifying what resources it checks during If: header processing. I'm taking a particular approach that I want to bounce off the group to see if this makes sense and is "proper". Specifically, it revolves around whether we need to check the "parent" resource to see if it is locked and the If: header contains those locks. Say you're doing a MKCOL. The spec states that you must satisfy the locks held on the parent resource. The following cases are a bit less obvious: *) when using LOCK to create a locknull resource, this effectively creates   a new resource in the parent collection.   ==> parent resource should be checked *) when using UNLOCK on a locknull, this effectively deletes a resource   from the parent collection   ==> parent resource should be checked *) using MOVE on a resource: this removes the resource from the parent   ==> parent resource should be checked *) MOVE and COPY create resources at the Destination   ==> parent resource of the Destination should be checked *) MKCOL on a null resource   ==> parent resource should be checked *) MKCOL on a locknull resource does not add any resources to the parent   collection   ==> parent resource SHOULD NOT be checked   (the [locknull] resource itself will be checked, however) *) PUT operates similar to MKCOL w.r.t. locknull resources Note that this can be an interoperability item. If one server enforces that conditions be met for the parent, but another doesn't, then a client (that doesn't provide parent conditions) could fail. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon May 29 09:17:30 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 JAA00204 for ; Mon, 29 May 2000 09:17:29 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id JAA25211; Mon, 29 May 2000 09:11:58 -0400 (EDT) Resent-Date: Mon, 29 May 2000 09:11:58 -0400 (EDT) Resent-Message-Id: <200005291311.JAA25211@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: "Geoffrey M. Clemm" cc: w3c-dist-auth@w3.org Message-ID: <852568EE.00487541.00@d54mta02.raleigh.ibm.com> Date: Mon, 29 May 2000 09:10:42 -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 JAA25162 Subject: Re: If: header and "parent" resource checking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4302 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 See tags below. I believe a "lock-null" resource is best treated as a convenient fiction maintained in order to make it easy to query for the existence of locks. In particular, according to section 7.4 of 2518, a lock null resource acts the same as a null resource for all methods except for PROPFIND and UNLOCK.  A DELETE on a lock null resource MUST fail, a MOVE on a lock null resource MUST fail, a COPY on a lock null resource MUST fail, etc. The reason I am particularly concerned that the creation of a lock NOT be treated as a modification of the state of the parent collection is to ensure that effect of creating a lock-null resource is treated consistently in the versioning and the locking protocols. The lock-null resource appears as a member of its parent collection, so it must modify its state. Otherwise, how would one see the results of the LOCK request? In the versioning protocol, the creation of a lock-null resource cannot be a modification to the state of the collection containing it, because if the collection were versioned, this would then require a new revision of that collection in order to hold the "new resource".  But then this lock-null resource could never be removed from this collection revision, because revisions are immutable. The versioned collection only needs to have a working revision. The lock-null resource may be deleted (with unlock) or converted to a real resource (with put) before the working revision of the versioned collection is checked back in. On the other hand, if the addition of a lock is not considered a modification to the state of a collection, but rather the modification occurs at the first PUT, then all is well ... no "immutable" locks end up being captured. In this model, a lock is not a modification to the state of a resource (either the resource itself, or the collection containing the lock), but rather "metadata" that controls interactions with the state of the resource. In versioning, this is also how "labels" are handled, i.e. as metadata on a resource that does not modify the state of the resource. I'd *very* much like the versioning protocol and the locking protocol to be consistent as to whether the creation of a lock-null resource modifies the state of the collection containing them.  Since I don't see that the versioning protocol has a choice in this regard, I'd like to see the locking protocol handle it the same way, unless there is some serious problem that arises from doing so. So I guess what I'd like to hear is why it is important for the addition of a lock-null resource to be treated as a modification to the state of the collection containing it. Just so you can see the results of the LOCK operation and have a URL to unlock or put. From w3c-dist-auth-request@w3.org Mon May 29 20:39:15 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 UAA05190 for ; Mon, 29 May 2000 20:39:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA06611; Mon, 29 May 2000 20:33:44 -0400 (EDT) Resent-Date: Mon, 29 May 2000 20:33:44 -0400 (EDT) Resent-Message-Id: <200005300033.UAA06611@www19.w3.org> Date: Mon, 29 May 2000 17:33:29 -0700 (PDT) From: Greg Stein To: jamsden@us.ibm.com cc: w3c-dist-auth@w3.org In-Reply-To: <852568EE.0048768E.00@d54mta02.raleigh.ibm.com> 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 UAA06591 Subject: Re: If: header and "parent" resource checking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4303 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 On Mon, 29 May 2000 jamsden@us.ibm.com wrote: > Greg, > I believe DAV4J behaves as you describe below. Great. Well, the details below can also make a good step-by-step review list for DAV4J then. I think that I'll code up some regression tests for these scenarios. The locknull stuff may be changed if consensus goes with Geoff, but heading in that direction will be helpful. Cheers, -g Greg Stein wrote: > > I'm going through mod_dav right now and refining/verifying what resources > it checks during If: header processing. I'm taking a particular approach > that I want to bounce off the group to see if this makes sense and is > "proper". > > Specifically, it revolves around whether we need to check the "parent" > resource to see if it is locked and the If: header contains those locks. > Say you're doing a MKCOL. The spec states that you must satisfy the locks > held on the parent resource. The following cases are a bit less obvious: > > *) when using LOCK to create a locknull resource, this effectively creates >   a new resource in the parent collection. >   ==> parent resource should be checked > > *) when using UNLOCK on a locknull, this effectively deletes a resource >   from the parent collection >   ==> parent resource should be checked > > *) using MOVE on a resource: this removes the resource from the parent >   ==> parent resource should be checked > > *) MOVE and COPY create resources at the Destination >   ==> parent resource of the Destination should be checked > > *) MKCOL on a null resource >   ==> parent resource should be checked > > *) MKCOL on a locknull resource does not add any resources to the parent >   collection >   ==> parent resource SHOULD NOT be checked >   (the [locknull] resource itself will be checked, however) > > *) PUT operates similar to MKCOL w.r.t. locknull resources > > > Note that this can be an interoperability item. If one server enforces > that conditions be met for the parent, but another doesn't, then a client > (that doesn't provide parent conditions) could fail. > > Cheers, > -g > > -- > Greg Stein, http://www.lyra.org/ > > > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon May 29 20:39:17 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 UAA05201 for ; Mon, 29 May 2000 20:39:17 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA06657; Mon, 29 May 2000 20:34:54 -0400 (EDT) Resent-Date: Mon, 29 May 2000 20:34:54 -0400 (EDT) Resent-Message-Id: <200005300034.UAA06657@www19.w3.org> Date: Mon, 29 May 2000 17:34:41 -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: regression/test package? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4304 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list People have mentioned regression and/or testing packages for DAV servers in the past, but nobody has ever posted actual code to do so. Does ANYBODY have code they can post? Needless to say, it would be quite helpful to the whole DAV community to have this. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon May 29 20:44:49 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 UAA05245 for ; Mon, 29 May 2000 20:44:49 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA06789; Mon, 29 May 2000 20:39:28 -0400 (EDT) Resent-Date: Mon, 29 May 2000 20:39:28 -0400 (EDT) Resent-Message-Id: <200005300039.UAA06789@www19.w3.org> Date: Mon, 29 May 2000 17:39:16 -0700 (PDT) From: Greg Stein To: w3c-dist-auth@w3.org In-Reply-To: <852568EE.00487541.00@d54mta02.raleigh.ibm.com> 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 UAA06769 Subject: Re: If: header and "parent" resource checking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4305 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 On Mon, 29 May 2000 jamsden@us.ibm.com wrote: [ rest of quoted post by Geoff Clemm, but Jim's mailer appears incapable of useful quoting :-) ] > See tags below. > > > I believe a "lock-null" resource is best treated as a convenient > fiction maintained in order to make it easy to query for the existence > of locks. > > In particular, according to section 7.4 of 2518, a lock null resource > acts the same as a null resource for all methods except for PROPFIND > and UNLOCK.  A DELETE on a lock null resource MUST fail, a MOVE on a > lock null resource MUST fail, a COPY on a lock null resource MUST > fail, etc. > > The reason I am particularly concerned that the creation of a lock NOT > be treated as a modification of the state of the parent collection is > to ensure that effect of creating a lock-null resource is treated > consistently in the versioning and the locking protocols. > > The lock-null resource appears as a member of its parent collection, so it > must modify its state. Otherwise, how would one see the results of the LOCK > request? > Agreed. No matter what people think of locknull resources, they do exist, and they do modify the parent collection. My previous post went over this, and I see nothing "funny" about different behaviors when different states exist on the server. > In the versioning protocol, the creation of a lock-null resource cannot > be a modification to the state of the collection containing it, because > if the collection were versioned, this would then require a new revision > of that collection in order to hold the "new resource".  But then this > lock-null resource could never be removed from this collection revision, > because revisions are immutable. > > The versioned collection only needs to have a working revision. The > lock-null resource may be deleted (with unlock) or converted to a real > resource (with put) before the working revision of the versioned collection > is checked back in. > Dunno what would be The Right Thing, but maybe a CHECKIN or MERGE (or whatever it is called nowadays) could fail if a locknull existed. Personally, I'd just refuse to create locknull resources in a versioned space. Maybe even disable locking altogether. >... > So I guess what I'd like to hear is why it is important for the addition > of a lock-null resource to be treated as a modification to the state of > the collection containing it. > > Just so you can see the results of the LOCK operation and have a URL to > unlock or put. > Yup. Locknull resources exist to "reserve" a particular member in a parent collection. You have to modify the parent to assert that the member has been reserved. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon May 29 21:16: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 VAA05417 for ; Mon, 29 May 2000 21:16:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA07256; Mon, 29 May 2000 21:12:10 -0400 (EDT) Resent-Date: Mon, 29 May 2000 21:12:10 -0400 (EDT) Resent-Message-Id: <200005300112.VAA07256@www19.w3.org> Message-Id: <4.1.20000529180016.00b4f4a0(null)> X-Sender: contact@pop.lanminds.com X-Mailer: QUALCOMM Windows Eudora Pro Version 4.1 Date: Mon, 29 May 2000 18:00:45 -0700 To: Greg Stein , w3c-dist-auth@w3.org From: Jim Davis In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: regression/test package? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4306 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Yes, I do. I can post it. Give me a day or two. meanwhile is there a server you want me to aim my tester at? From w3c-dist-auth-request@w3.org Mon May 29 21: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 VAA05433 for ; Mon, 29 May 2000 21:18:02 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA07298; Mon, 29 May 2000 21:13:41 -0400 (EDT) Resent-Date: Mon, 29 May 2000 21:13:41 -0400 (EDT) Resent-Message-Id: <200005300113.VAA07298@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: ietf-dav-versioning@w3.org, w3c-dist-auth@w3c.org Message-ID: <852568EF.0006BB10.00@d54mta02.raleigh.ibm.com> Date: Mon, 29 May 2000 21:13:04 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: If: header and "parent" resource checking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4307 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 says: Personally, I'd just refuse to create locknull resources in a versioned space. Maybe even disable locking altogether. What does everyone else think? Do we need locking and versioning together? We're trying to make them work together, and leverage locking semantics whenever possible. But it hasn't been easy, and its cost us some flexibility. From w3c-dist-auth-request@w3.org Mon May 29 21:30: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 VAA05509 for ; Mon, 29 May 2000 21:30:42 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id VAA07967; Mon, 29 May 2000 21:26:17 -0400 (EDT) Resent-Date: Mon, 29 May 2000 21:26:17 -0400 (EDT) Resent-Message-Id: <200005300126.VAA07967@www19.w3.org> Date: Mon, 29 May 2000 18:26:00 -0700 (PDT) From: Greg Stein To: Jim Davis cc: w3c-dist-auth@w3.org In-Reply-To: <4.1.20000529180016.00b4f4a0(null)> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: regression/test package? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4308 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, 29 May 2000, Jim Davis wrote: > Yes, I do. I can post it. Give me a day or two. > > meanwhile is there a server you want me to aim my tester at? Nah. I have to upgrade a couple servers here to the latest. My dev server prevents external access. I'd much rather have the code/tool available to do the testing, so I can run it while developing. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Mon May 29 22:41:32 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 WAA07720 for ; Mon, 29 May 2000 22:41:26 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id WAA09168; Mon, 29 May 2000 22:36:45 -0400 (EDT) Resent-Date: Mon, 29 May 2000 22:36:45 -0400 (EDT) Resent-Message-Id: <200005300236.WAA09168@www19.w3.org> Date: Mon, 29 May 2000 22:36:23 -0400 (EDT) Message-Id: <200005300236.WAA22935@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: <852568EE.00487541.00@d54mta02.raleigh.ibm.com> (jamsden@us.ibm.com) References: <852568EE.00487541.00@d54mta02.raleigh.ibm.com> Subject: Re: If: header and "parent" resource checking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4309 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: jamsden@us.ibm.com I believe a "lock-null" resource is best treated as a convenient fiction maintained in order to make it easy to query for the existence of locks. In particular, according to section 7.4 of 2518, a lock null resource acts the same as a null resource for all methods except for PROPFIND and UNLOCK. A DELETE on a lock null resource MUST fail, a MOVE on a lock null resource MUST fail, a COPY on a lock null resource MUST fail, etc. The reason I am particularly concerned that the creation of a lock NOT be treated as a modification of the state of the parent collection is to ensure that effect of creating a lock-null resource is treated consistently in the versioning and the locking protocols. The lock-null resource appears as a member of its parent collection, so it must modify its state. Otherwise, how would one see the results of the LOCK request? By stating in the protocol that "although a lock null resource shows up in a PROPFIND, adding or removing a lock null resource in a collection has no effect on the lock state of that collection". There is clear precedent for this in the treatment of live properties, which also can be modified without affecting the lock state of the resource containing those properties. In the versioning protocol, the creation of a lock-null resource cannot be a modification to the state of the collection containing it, because if the collection were versioned, this would then require a new revision of that collection in order to hold the "new resource". But then this lock-null resource could never be removed from this collection revision, because revisions are immutable. The versioned collection only needs to have a working revision. The lock-null resource may be deleted (with unlock) or converted to a real resource (with put) before the working revision of the versioned collection is checked back in. When a lock is performed by a versioning unaware client in a versioned collection, the creation of the new collection revision is done automatically as soon as the state of the collection is modified. There is no working revision involved, other than the one that is automatically checked in to create the new revision. And that new revision will contain an immutable "lock-null resource", which would effectively prevent the ability to ever UNLOCK that lock. Not a good thing. On the other hand, if the addition of a lock is not considered a modification to the state of a collection, but rather the modification occurs at the first PUT, then all is well ... no "immutable" locks end up being captured. In this model, a lock is not a modification to the state of a resource (either the resource itself, or the collection containing the lock), but rather "metadata" that controls interactions with the state of the resource. In versioning, this is also how "labels" are handled, i.e. as metadata on a resource that does not modify the state of the resource. I'd *very* much like the versioning protocol and the locking protocol to be consistent as to whether the creation of a lock-null resource modifies the state of the collection containing them. Since I don't see that the versioning protocol has a choice in this regard, I'd like to see the locking protocol handle it the same way, unless there is some serious problem that arises from doing so. So I guess what I'd like to hear is why it is important for the addition of a lock-null resource to be treated as a modification to the state of the collection containing it. Just so you can see the results of the LOCK operation and have a URL to unlock or put. As indicated above, any live properties can be defined as being changeable without affecting the lock state of a resource. Stating that a lock null resource can be added or removed from a collection without affecting the lock state of that collection can be handled in exactly the same way, while keeping the ability to use PROPFIND to locate lock-null resources. Cheers, Geoff From w3c-dist-auth-request@w3.org Mon May 29 23:20: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 XAA07969 for ; Mon, 29 May 2000 23:20:53 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA09756; Mon, 29 May 2000 23:15:57 -0400 (EDT) Resent-Date: Mon, 29 May 2000 23:15:57 -0400 (EDT) Resent-Message-Id: <200005300315.XAA09756@www19.w3.org> Date: Mon, 29 May 2000 23:15:41 -0400 (EDT) Message-Id: <200005300315.XAA23006@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 Mon, 29 May 2000 20:39:16 -0400) References: Subject: Re: If: header and "parent" resource checking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4310 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: Greg Stein No matter what people think of locknull resources, they do exist, and they do modify the parent collection. The fact that they show up in a PROPFIND does not require that their addition and removal from a collection affect the lock state of that collection. I'll appeal again to live properties here. They are properties of a resource, but they can be changed without affecting the lock state of the resource. My previous post went over this, and I see nothing "funny" about different behaviors when different states exist on the server. I'll retract my "acts funny" argument, since "acting funny" will never be more than a subjective criteria. My real concern was the bad interaction with versioning (but I still think locknull resources act funny :-). Personally, I'd just refuse to create locknull resources in a versioned space. Maybe even disable locking altogether. This would mean that all locking clients (such as Office 2000) would fail when applied against a versioned space. I believe this is unacceptable (I know it is unacceptable for my implementation). Yup. Locknull resources exist to "reserve" a particular member in a parent collection. You have to modify the parent to assert that the member has been reserved. But that modification does not have to imply a change that is controlled by a write lock (the live property analogy). Cheers, Geoff From w3c-dist-auth-request@w3.org Mon May 29 23:28: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 XAA08023 for ; Mon, 29 May 2000 23:28:55 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA10103; Mon, 29 May 2000 23:24:32 -0400 (EDT) Resent-Date: Mon, 29 May 2000 23:24:32 -0400 (EDT) Resent-Message-Id: <200005300324.XAA10103@www19.w3.org> Date: Mon, 29 May 2000 23:24:16 -0400 (EDT) Message-Id: <200005300324.XAA23019@tantalum.atria.com> X-Authentication-Warning: tantalum.atria.com: gclemm set sender to geoffrey.clemm@rational.com using -f From: "Geoffrey M. Clemm" To: ietf-dav-versioning@w3.org, w3c-dist-auth@w3c.org In-reply-to: <852568EF.0006BB87.00@d54mta02.raleigh.ibm.com> (jamsden@us.ibm.com) References: <852568EF.0006BB87.00@d54mta02.raleigh.ibm.com> Subject: Re: If: header and "parent" resource checking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4311 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: jamsden@us.ibm.com What does everyone else think? Do we need locking and versioning together? We're trying to make them work together, and leverage locking semantics whenever possible. But it hasn't been easy, and its cost us some flexibility. This question has two parts: - If you are writing a versioning client, do you care whether your versioning server gives you any locking capability (and if so, should it be compatible with locking defined for non-versioning servers)? - If you are writing a versioning server, do you care that versioning unaware locking clients work against your server? In my case, I care about the former, to control access of multiple clients to the same working resource, and I care about the latter, because there are some very important versioning unaware locking clients. Cheers, Geoff From w3c-dist-auth-request@w3.org Mon May 29 23:31: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 XAA08463 for ; Mon, 29 May 2000 23:31:54 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id XAA10234; Mon, 29 May 2000 23:27:38 -0400 (EDT) Resent-Date: Mon, 29 May 2000 23:27:38 -0400 (EDT) Resent-Message-Id: <200005300327.XAA10234@www19.w3.org> From: jamsden@us.ibm.com X-Lotus-FromDomain: IBMUS To: w3c-dist-auth@w3c.org Message-ID: <852568EF.0012FB7D.00@d54mta02.raleigh.ibm.com> Date: Mon, 29 May 2000 23:26:54 -0400 Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Subject: Re: If: header and "parent" resource checking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4312 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 fact that they show up in a PROPFIND does not require that their addition and removal from a collection affect the lock state of that collection. I'll appeal again to live properties here. They are properties of a resource, but they can be changed without affecting the lock state of the resource. But they're not live properties. For example, lock-null resources can be the request-URL of PROPFIND and UNLOCK. The problem is that lock-null resources are only lock-null resources: a bunch of special cases that make sense when you look at them one way and not form another. I think they were a good idea that didn't semantically scale. From w3c-dist-auth-request@w3.org Tue May 30 08:56: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 IAA27592 for ; Tue, 30 May 2000 08:56:21 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id IAA19356; Tue, 30 May 2000 08:45:17 -0400 (EDT) Resent-Date: Tue, 30 May 2000 08:45:17 -0400 (EDT) Resent-Message-Id: <200005301245.IAA19356@www19.w3.org> Date: Tue, 30 May 2000 08:44:53 -0400 (EDT) Message-Id: <200005301244.IAA23646@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: <852568EF.0012FB7D.00@d54mta02.raleigh.ibm.com> (jamsden@us.ibm.com) References: <852568EF.0012FB7D.00@d54mta02.raleigh.ibm.com> Subject: Re: If: header and "parent" resource checking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4313 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list From: jamsden@us.ibm.com The fact that they show up in a PROPFIND does not require that their addition and removal from a collection affect the lock state of that collection. I'll appeal again to live properties here. They are properties of a resource, but they can be changed without affecting the lock state of the resource. But they're not live properties. I didn't mean to imply that they were. I was just using the way we handle live properties as an analogy. A live property appears to be part of the state of a resource, but we allow it to be modified without modifying the lock state of the resource. Analogously, I propose that a lock null resource should appear to be part of the state of a collection, but that we allow them to be added and deleted without modifying the lock state of the resource. For example, lock-null resources can be the request-URL of PROPFIND and UNLOCK. The problem is that lock-null resources are only lock-null resources: a bunch of special cases that make sense when you look at them one way and not form another. I think they were a good idea that didn't semantically scale. I agree that lock-null resources are just a bunch of special cases. What I'd like to do is minimize their impact on the rest of the protocol. One way to do so is to say that only PROPFIND and UNLOCK have to deal with them as a special case, i.e. all other methods do not have to treat them as normal resources (in fact, according to 2518, most other methods are not *allowed* to treat them as normal resources). This then means that only the implementation of PROPFIND and UNLOCK needs to treat a name lock as if it were a resource. All the other methods do not. This I believe is the simplest and cleanest way of handling lock null resources (and is consistent with what 2518 currently says). Cheers, Geoff From w3c-dist-auth-request@w3.org Tue May 30 11:10:50 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 LAA00776 for ; Tue, 30 May 2000 11:10:47 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id LAA25217; Tue, 30 May 2000 11:02:18 -0400 (EDT) Resent-Date: Tue, 30 May 2000 11:02:18 -0400 (EDT) Resent-Message-Id: <200005301502.LAA25217@www19.w3.org> To: ietf-dav-versioning@w3.org, w3c-dist-auth@w3c.org X-Mailer: Lotus Notes Release 5.0.1a (Intl) 17 August 1999 Message-ID: From: "Tim Ellison/OTT/OTI" Date: Tue, 30 May 2000 10:58:27 -0400 X-Priority: 3 (Normal) X-MIMETrack: Serialize by Router on OTT1M/A/OTI(Release 5.0.1a (Intl)|17 August 1999) at 05/30/2000 10:58:26 AM, Serialize complete at 05/30/2000 10:58:26 AM MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Subject: Re: If: header and "parent" resource checking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4314 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 that both of these cases are important. Tim "Geoffrey M. Clemm" Sent by: ietf-dav-versioning-request@w3.org 29-05-00 11:24 PM To: ietf-dav-versioning@w3.org, w3c-dist-auth@w3c.org cc: Subject: Re: If: header and "parent" resource checking From: jamsden@us.ibm.com What does everyone else think? Do we need locking and versioning together? We're trying to make them work together, and leverage locking semantics whenever possible. But it hasn't been easy, and its cost us some flexibility. This question has two parts: - If you are writing a versioning client, do you care whether your versioning server gives you any locking capability (and if so, should it be compatible with locking defined for non-versioning servers)? - If you are writing a versioning server, do you care that versioning unaware locking clients work against your server? In my case, I care about the former, to control access of multiple clients to the same working resource, and I care about the latter, because there are some very important versioning unaware locking clients. Cheers, Geoff From w3c-dist-auth-request@w3.org Tue May 30 16:27:40 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 QAA09666 for ; Tue, 30 May 2000 16:27:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id QAA09613; Tue, 30 May 2000 16:21:22 -0400 (EDT) Resent-Date: Tue, 30 May 2000 16:21:22 -0400 (EDT) Resent-Message-Id: <200005302021.QAA09613@www19.w3.org> Message-ID: From: Henry Harbury To: "'Geoffrey M. Clemm'" , ietf-dav-versioning@w3.org, w3c-dist-auth@w3c.org Date: Tue, 30 May 2000 13:14:50 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCA73.B5FA99D4" Subject: RE: If: header and "parent" resource checking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4315 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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFCA73.B5FA99D4 Content-Type: text/plain; charset="iso-8859-1" I agree with Geoff - we need to respect DAV locking as best we can. -- Henry. -----Original Message----- From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com] Sent: Monday, May 29, 2000 8:24 PM To: ietf-dav-versioning@w3.org; w3c-dist-auth@w3c.org Subject: Re: If: header and "parent" resource checking From: jamsden@us.ibm.com What does everyone else think? Do we need locking and versioning together? We're trying to make them work together, and leverage locking semantics whenever possible. But it hasn't been easy, and its cost us some flexibility. This question has two parts: - If you are writing a versioning client, do you care whether your versioning server gives you any locking capability (and if so, should it be compatible with locking defined for non-versioning servers)? - If you are writing a versioning server, do you care that versioning unaware locking clients work against your server? In my case, I care about the former, to control access of multiple clients to the same working resource, and I care about the latter, because there are some very important versioning unaware locking clients. Cheers, Geoff ------_=_NextPart_001_01BFCA73.B5FA99D4 Content-Type: text/html; charset="iso-8859-1" RE: If: header and "parent" resource checking

I agree with Geoff - we need to respect DAV locking as best we can.
-- Henry.

-----Original Message-----
From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com]
Sent: Monday, May 29, 2000 8:24 PM
To: ietf-dav-versioning@w3.org; w3c-dist-auth@w3c.org
Subject: Re: If: header and "parent" resource checking



   From: jamsden@us.ibm.com

   What does everyone else think? Do we need locking and versioning together?
   We're trying to make them work together, and leverage locking semantics
   whenever possible. But it hasn't been easy, and its cost us some
   flexibility.

This question has two parts:

- If you are writing a versioning client, do you care whether your
versioning server gives you any locking capability (and if so, should
it be compatible with locking defined for non-versioning servers)?

- If you are writing a versioning server, do you care that versioning
unaware locking clients work against your server?

In my case, I care about the former, to control access of multiple
clients to the same working resource, and I care about the latter,
because there are some very important versioning unaware locking clients.

Cheers,
Geoff

------_=_NextPart_001_01BFCA73.B5FA99D4-- From w3c-dist-auth-request@w3.org Tue May 30 18:54: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 SAA12443 for ; Tue, 30 May 2000 18:54:36 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA13325; Tue, 30 May 2000 18:49:52 -0400 (EDT) Resent-Date: Tue, 30 May 2000 18:49:52 -0400 (EDT) Resent-Message-Id: <200005302249.SAA13325@www19.w3.org> Date: Tue, 30 May 2000 15:49:33 -0700 (PDT) From: Greg Stein To: "Geoffrey M. Clemm" cc: ietf-dav-versioning@w3.org, w3c-dist-auth@w3c.org, w3c-dist-auth@w3.org In-Reply-To: <200005300324.XAA23019@tantalum.atria.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: If: header and "parent" resource checking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4316 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, 29 May 2000, Geoffrey M. Clemm wrote: > From: jamsden@us.ibm.com > > What does everyone else think? Do we need locking and versioning together? > We're trying to make them work together, and leverage locking semantics > whenever possible. But it hasn't been easy, and its cost us some > flexibility. > > This question has two parts: > > - If you are writing a versioning client, do you care whether your > versioning server gives you any locking capability (and if so, should > it be compatible with locking defined for non-versioning servers)? > > - If you are writing a versioning server, do you care that versioning > unaware locking clients work against your server? > > In my case, I care about the former, to control access of multiple > clients to the same working resource, and I care about the latter, > because there are some very important versioning unaware locking clients. Okay, fine. It seems there is consensus on both of these. The locknull thing should be solved one direction or another, and I don't see a real consensus there yet. [ followups should be directed at that thread ] Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Tue May 30 20:22: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 UAA13672 for ; Tue, 30 May 2000 20:22:12 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id UAA15246; Tue, 30 May 2000 20:17:23 -0400 (EDT) Resent-Date: Tue, 30 May 2000 20:17:23 -0400 (EDT) Resent-Message-Id: <200005310017.UAA15246@www19.w3.org> Date: Tue, 30 May 2000 17:13:53 -0700 From: Kevin Wiggen In-reply-to: <852568EE.0048768E.00@d54mta02.raleigh.ibm.com> To: jamsden@us.ibm.com, Greg Stein Cc: w3c-dist-auth@w3.org Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset=iso-8859-1 Content-transfer-encoding: 8BIT Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Priority: 3 (Normal) Subject: RE: If: header and "parent" resource checking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4317 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 Xythos also works as Greg has noted.... Thanks, 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, May 29, 2000 6:11 AM To: Greg Stein Cc: w3c-dist-auth@w3.org Subject: Re: If: header and "parent" resource checking Greg, I believe DAV4J behaves as you describe below. I'm going through mod_dav right now and refining/verifying what resources it checks during If: header processing. I'm taking a particular approach that I want to bounce off the group to see if this makes sense and is "proper". Specifically, it revolves around whether we need to check the "parent" resource to see if it is locked and the If: header contains those locks. Say you're doing a MKCOL. The spec states that you must satisfy the locks held on the parent resource. The following cases are a bit less obvious: *) when using LOCK to create a locknull resource, this effectively creates   a new resource in the parent collection.   ==> parent resource should be checked *) when using UNLOCK on a locknull, this effectively deletes a resource   from the parent collection   ==> parent resource should be checked *) using MOVE on a resource: this removes the resource from the parent   ==> parent resource should be checked *) MOVE and COPY create resources at the Destination   ==> parent resource of the Destination should be checked *) MKCOL on a null resource   ==> parent resource should be checked *) MKCOL on a locknull resource does not add any resources to the parent   collection   ==> parent resource SHOULD NOT be checked   (the [locknull] resource itself will be checked, however) *) PUT operates similar to MKCOL w.r.t. locknull resources Note that this can be an interoperability item. If one server enforces that conditions be met for the parent, but another doesn't, then a client (that doesn't provide parent conditions) could fail. Cheers, -g -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed May 31 15:23:16 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 PAA21240 for ; Wed, 31 May 2000 15:23:15 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA15972; Wed, 31 May 2000 15:16:32 -0400 (EDT) Resent-Date: Wed, 31 May 2000 15:16:32 -0400 (EDT) Resent-Message-Id: <200005311916.PAA15972@www19.w3.org> Date: Wed, 31 May 2000 12:16:25 -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: Q: does this use of 424 seem reasonable? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4318 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... One more question: in the current mod_dav architecture, I am unable to do a "best effort" delete/move/copy when a lock exists somewhere in the affected resources. As a result, the only real option available is to fail the entire request. However, this would effectively mean returning a 207 (Multistatus) that contains an entry for every single resource stating (in some way) that it was not deleted/moved/copied. I would much rather do the following: *) return 424 (Failed Dependency) *) include a body in the 424 response, which contains a DAV:multistatus element which refers to the locked resource Does this seem reasonable? Thanx, -g p.s. and no, fixing it to do best-effort is not an option -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed May 31 15:23:43 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 PAA21256 for ; Wed, 31 May 2000 15:23:42 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA16025; Wed, 31 May 2000 15:18:42 -0400 (EDT) Resent-Date: Wed, 31 May 2000 15:18:42 -0400 (EDT) Resent-Message-Id: <200005311918.PAA16025@www19.w3.org> Date: Wed, 31 May 2000 12:18:38 -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=X-UNKNOWN Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from QUOTED-PRINTABLE to 8bit by www19.w3.org id PAA16002 Subject: RE: If: header and "parent" resource checking Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4319 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 Given three servers that operate this way, I am going to interpret this as a consensus for now. I still have a response or two to Geoff's mails (forthcoming), but I feel much better about the approach that I used for mod_dav (and that others used, too). Cheers, -g On Tue, 30 May 2000, Kevin Wiggen wrote: > > Xythos also works as Greg has noted.... > > Thanks, > 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, May 29, 2000 6:11 AM > To: Greg Stein > Cc: w3c-dist-auth@w3.org > Subject: Re: If: header and "parent" resource checking > > > > > > > Greg, > I believe DAV4J behaves as you describe below. > > > > I'm going through mod_dav right now and refining/verifying what resources > it checks during If: header processing. I'm taking a particular approach > that I want to bounce off the group to see if this makes sense and is > "proper". > > Specifically, it revolves around whether we need to check the "parent" > resource to see if it is locked and the If: header contains those locks. > Say you're doing a MKCOL. The spec states that you must satisfy the locks > held on the parent resource. The following cases are a bit less obvious: > > *) when using LOCK to create a locknull resource, this effectively creates >   a new resource in the parent collection. >   ==> parent resource should be checked > > *) when using UNLOCK on a locknull, this effectively deletes a resource >   from the parent collection >   ==> parent resource should be checked > > *) using MOVE on a resource: this removes the resource from the parent >   ==> parent resource should be checked > > *) MOVE and COPY create resources at the Destination >   ==> parent resource of the Destination should be checked > > *) MKCOL on a null resource >   ==> parent resource should be checked > > *) MKCOL on a locknull resource does not add any resources to the parent >   collection >   ==> parent resource SHOULD NOT be checked >   (the [locknull] resource itself will be checked, however) > > *) PUT operates similar to MKCOL w.r.t. locknull resources > > > Note that this can be an interoperability item. If one server enforces > that conditions be met for the parent, but another doesn't, then a client > (that doesn't provide parent conditions) could fail. > > Cheers, > -g > > -- > Greg Stein, http://www.lyra.org/ > > > > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed May 31 15:41: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 PAA21977 for ; Wed, 31 May 2000 15:41:37 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id PAA16742; Wed, 31 May 2000 15:36:02 -0400 (EDT) Resent-Date: Wed, 31 May 2000 15:36:02 -0400 (EDT) Resent-Message-Id: <200005311936.PAA16742@www19.w3.org> Date: Wed, 31 May 2000 12:33:02 -0700 From: Kevin Wiggen In-reply-to: To: Greg Stein , w3c-dist-auth@w3.org Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7bit Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Priority: 3 (Normal) Subject: RE: does this use of 424 seem reasonable? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4320 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 I think that not doing a best effort delete/move (copy should occur even if its locked), is a very valid thing for a server to do. In fact I would argue that if MS could implement a "rollback" during the delete/move, we would make these operations atomic. Since this is true, I would like agree with Greg that a new status code should be created that states the operation failed (do to locks, permissions, etc) and the operation was rolled back. Xythos would then return the new status code for a failed move/copy instead of doing a best effort (along with mod_dav), and MS can return the best-effort status for move/copy. It has been our experience that a best effort delete/move is the WORST thing to do to a user. The XML returned should note ALL resources that are stopping the move/delete and what the problem is (locks, permissions, etc), so that the client can tell the user what is stopping the operation. Thanks, Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein Sent: Wednesday, May 31, 2000 12:16 PM To: w3c-dist-auth@w3.org Subject: Q: does this use of 424 seem reasonable? Hi all... One more question: in the current mod_dav architecture, I am unable to do a "best effort" delete/move/copy when a lock exists somewhere in the affected resources. As a result, the only real option available is to fail the entire request. However, this would effectively mean returning a 207 (Multistatus) that contains an entry for every single resource stating (in some way) that it was not deleted/moved/copied. I would much rather do the following: *) return 424 (Failed Dependency) *) include a body in the 424 response, which contains a DAV:multistatus element which refers to the locked resource Does this seem reasonable? Thanx, -g p.s. and no, fixing it to do best-effort is not an option -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed May 31 18:05: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 SAA25968 for ; Wed, 31 May 2000 18:05:35 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id RAA23560; Wed, 31 May 2000 17:58:42 -0400 (EDT) Resent-Date: Wed, 31 May 2000 17:58:42 -0400 (EDT) Resent-Message-Id: <200005312158.RAA23560@www19.w3.org> Date: Wed, 31 May 2000 17:58:25 -0400 (EDT) Message-Id: <200005312158.RAA25803@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 Kevin Wiggen on Wed, 31 May 2000 12:33:02 -0700) References: Subject: Re: does this use of 424 seem reasonable? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4321 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 heartily concur that atomic delete behavior is far more well behaved from a client's perspective, and should be supported whenever possible (and will even be required in the presence of multiple bindings to a resource). Last time I suggested returning a body with a 4xx status indicating what failed, JimW said this would cause a problem, but unfortunately I never did get what that problem would be. I hope JimW was wrong, because otherwise I see no easy way to avoid running out of 4xx status codes someday soon ... Assuming it is a problem, an alternative marshalling would be to return the 424's in a 207, since currently 528 says that 424's SHOULD NOT be returned in 207's from a DELETE (so we should be able to use the 424 to mean what we want). Cheers, Geoff Date: Wed, 31 May 2000 12:33:02 -0700 From: Kevin Wiggen I think that not doing a best effort delete/move (copy should occur even if its locked), is a very valid thing for a server to do. In fact I would argue that if MS could implement a "rollback" during the delete/move, we would make these operations atomic. Since this is true, I would like agree with Greg that a new status code should be created that states the operation failed (do to locks, permissions, etc) and the operation was rolled back. Xythos would then return the new status code for a failed move/copy instead of doing a best effort (along with mod_dav), and MS can return the best-effort status for move/copy. It has been our experience that a best effort delete/move is the WORST thing to do to a user. The XML returned should note ALL resources that are stopping the move/delete and what the problem is (locks, permissions, etc), so that the client can tell the user what is stopping the operation. Thanks, Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein Sent: Wednesday, May 31, 2000 12:16 PM To: w3c-dist-auth@w3.org Subject: Q: does this use of 424 seem reasonable? Hi all... One more question: in the current mod_dav architecture, I am unable to do a "best effort" delete/move/copy when a lock exists somewhere in the affected resources. As a result, the only real option available is to fail the entire request. However, this would effectively mean returning a 207 (Multistatus) that contains an entry for every single resource stating (in some way) that it was not deleted/moved/copied. I would much rather do the following: *) return 424 (Failed Dependency) *) include a body in the 424 response, which contains a DAV:multistatus element which refers to the locked resource Does this seem reasonable? Thanx, -g p.s. and no, fixing it to do best-effort is not an option -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed May 31 18:11:44 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 SAA26082 for ; Wed, 31 May 2000 18:11:43 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA24144; Wed, 31 May 2000 18:07:17 -0400 (EDT) Resent-Date: Wed, 31 May 2000 18:07:17 -0400 (EDT) Resent-Message-Id: <200005312207.SAA24144@www19.w3.org> Message-ID: <65B141FB11CCD211825700A0C9D609BC01D4D8E7@chef.lex.rational.com> From: "Clemm, Geoff" To: w3c-dist-auth@w3.org Date: Wed, 31 May 2000 18:00:20 -0400 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2650.21) Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01BFCB4B.9D2DE680" Subject: RE: does this use of 424 seem reasonable? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4322 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 message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. ------_=_NextPart_001_01BFCB4B.9D2DE680 Content-Type: text/plain; charset="iso-8859-1" Argh. Just in case anyone wonders what in the world I was referring to by 528, I meant 2518 (which I guess makes me both dyslexic and forgetful :-). Cheers, Geoff -----Original Message----- From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com] Sent: Wednesday, May 31, 2000 5:58 PM To: w3c-dist-auth@w3.org Subject: Re: does this use of 424 seem reasonable? I heartily concur that atomic delete behavior is far more well behaved from a client's perspective, and should be supported whenever possible (and will even be required in the presence of multiple bindings to a resource). Last time I suggested returning a body with a 4xx status indicating what failed, JimW said this would cause a problem, but unfortunately I never did get what that problem would be. I hope JimW was wrong, because otherwise I see no easy way to avoid running out of 4xx status codes someday soon ... Assuming it is a problem, an alternative marshalling would be to return the 424's in a 207, since currently 528 says that 424's SHOULD NOT be returned in 207's from a DELETE (so we should be able to use the 424 to mean what we want). Cheers, Geoff Date: Wed, 31 May 2000 12:33:02 -0700 From: Kevin Wiggen I think that not doing a best effort delete/move (copy should occur even if its locked), is a very valid thing for a server to do. In fact I would argue that if MS could implement a "rollback" during the delete/move, we would make these operations atomic. Since this is true, I would like agree with Greg that a new status code should be created that states the operation failed (do to locks, permissions, etc) and the operation was rolled back. Xythos would then return the new status code for a failed move/copy instead of doing a best effort (along with mod_dav), and MS can return the best-effort status for move/copy. It has been our experience that a best effort delete/move is the WORST thing to do to a user. The XML returned should note ALL resources that are stopping the move/delete and what the problem is (locks, permissions, etc), so that the client can tell the user what is stopping the operation. Thanks, Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein Sent: Wednesday, May 31, 2000 12:16 PM To: w3c-dist-auth@w3.org Subject: Q: does this use of 424 seem reasonable? Hi all... One more question: in the current mod_dav architecture, I am unable to do a "best effort" delete/move/copy when a lock exists somewhere in the affected resources. As a result, the only real option available is to fail the entire request. However, this would effectively mean returning a 207 (Multistatus) that contains an entry for every single resource stating (in some way) that it was not deleted/moved/copied. I would much rather do the following: *) return 424 (Failed Dependency) *) include a body in the 424 response, which contains a DAV:multistatus element which refers to the locked resource Does this seem reasonable? Thanx, -g p.s. and no, fixing it to do best-effort is not an option -- Greg Stein, http://www.lyra.org/ ------_=_NextPart_001_01BFCB4B.9D2DE680 Content-Type: text/html; charset="iso-8859-1" RE: does this use of 424 seem reasonable?

Argh.  Just in case anyone wonders what in the world I was
referring to by 528, I meant 2518 (which I guess makes me
both dyslexic and forgetful :-).

Cheers,
Geoff

-----Original Message-----
From: Geoffrey M. Clemm [mailto:geoffrey.clemm@rational.com]
Sent: Wednesday, May 31, 2000 5:58 PM
To: w3c-dist-auth@w3.org
Subject: Re: does this use of 424 seem reasonable?



I heartily concur that atomic delete behavior is far more well behaved
from a client's perspective, and should be supported whenever possible
(and will even be required in the presence of multiple bindings to a
resource).

Last time I suggested returning a body with a 4xx status indicating
what failed, JimW said this would cause a problem, but unfortunately
I never did get what that problem would be.  I hope JimW was wrong,
because otherwise I see no easy way to avoid running out of 4xx
status codes someday soon ...

Assuming it is a problem, an alternative marshalling would be to return
the 424's in a 207, since currently 528 says that 424's SHOULD NOT be
returned in 207's from a DELETE (so we should be able to use the
424 to mean what we want).

Cheers,
Geoff

   Date: Wed, 31 May 2000 12:33:02 -0700
   From: Kevin Wiggen <wiggs@wiggenout.com>


   I think that not doing a best effort delete/move (copy should occur even if
   its locked), is a very valid thing for a server to do.  In fact I would
   argue that if MS could implement a "rollback" during the delete/move, we
   would make these operations atomic.

   Since this is true, I would like agree with Greg that a new status code
   should be created that states the operation failed (do to locks,
   permissions, etc) and the operation was rolled back.

   Xythos would then return the new status code for a failed move/copy instead
   of doing a best effort (along with mod_dav), and MS can return the
   best-effort status for move/copy.

   It has been our experience that a best effort delete/move is the WORST thing
   to do to a user.  The XML returned should note ALL resources that are
   stopping the move/delete and what the problem is (locks, permissions, etc),
   so that the client can tell the user what is stopping the operation.

   Thanks,
   Kevin

   -----Original Message-----
   From: w3c-dist-auth-request@w3.org
   [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein
   Sent: Wednesday, May 31, 2000 12:16 PM
   To: w3c-dist-auth@w3.org
   Subject: Q: does this use of 424 seem reasonable?


   Hi all...

   One more question: in the current mod_dav architecture, I am unable to do
   a "best effort" delete/move/copy when a lock exists somewhere in the
   affected resources. As a result, the only real option available is to fail
   the entire request.

   However, this would effectively mean returning a 207 (Multistatus) that
   contains an entry for every single resource stating (in some way) that it
   was not deleted/moved/copied.

   I would much rather do the following:

   *) return 424 (Failed Dependency)
   *) include a body in the 424 response, which contains a DAV:multistatus
      element which refers to the locked resource


   Does this seem reasonable?

   Thanx,
   -g

   p.s. and no, fixing it to do best-effort is not an option

   --
   Greg Stein, http://www.lyra.org/

------_=_NextPart_001_01BFCB4B.9D2DE680-- From w3c-dist-auth-request@w3.org Wed May 31 18:27:32 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 SAA26201 for ; Wed, 31 May 2000 18:27:32 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA24678; Wed, 31 May 2000 18:23:13 -0400 (EDT) Resent-Date: Wed, 31 May 2000 18:23:13 -0400 (EDT) Resent-Message-Id: <200005312223.SAA24678@www19.w3.org> Date: Wed, 31 May 2000 15:22:24 -0700 (PDT) From: Greg Stein To: w3c-dist-auth@w3.org In-Reply-To: <200005312158.RAA25803@tantalum.atria.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Subject: Re: does this use of 424 seem reasonable? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4323 X-Loop: w3c-dist-auth@w3.org Sender: w3c-dist-auth-request@w3.org Resent-Sender: w3c-dist-auth-request@w3.org Precedence: list Um. Including 424 into a 207 is legal (since it is only a SHOULD NOT), but it means that I would have to generate a response for all 1000 children of the collection that I'm trying to delete. Each resource would have to say "sorry, I wasn't deleted due to a 424 (Failed Dependency)". I'm seeking to return a single, top-level status that indicates the whole thing failed. 424 seemed most appropriate (4xx meaning the client can fix it, and 424 meaning that it was caused by some other reason). A 409 (Conflict) would also be fine, but I don't think it provides as much information (409 seems to say "problem with resource" while 424 says "problem with resource"). Kevin suggests creating a new 4xx status. I'm not sure that I want to go that far :-). If the body is a problem, then I'll probably just leave out a body. Although... I can't see how that would be a problem... I'm with Geoff on this one -- how does a body in a 424 cause a problem? Okay. Fine-tuning of the response aside, I also get the feeling that nobody is going to pester me saying "you moron, it should be best effort." I'm going to solidify the "single failure response" in mod_dav now, and look for responses to this thread to find the right status code and body contents. Cheers, -g On Wed, 31 May 2000, Geoffrey M. Clemm wrote: > > I heartily concur that atomic delete behavior is far more well behaved > from a client's perspective, and should be supported whenever possible > (and will even be required in the presence of multiple bindings to a > resource). > > Last time I suggested returning a body with a 4xx status indicating > what failed, JimW said this would cause a problem, but unfortunately > I never did get what that problem would be. I hope JimW was wrong, > because otherwise I see no easy way to avoid running out of 4xx > status codes someday soon ... > > Assuming it is a problem, an alternative marshalling would be to return > the 424's in a 207, since currently 528 says that 424's SHOULD NOT be > returned in 207's from a DELETE (so we should be able to use the > 424 to mean what we want). > > Cheers, > Geoff > > Date: Wed, 31 May 2000 12:33:02 -0700 > From: Kevin Wiggen > > > I think that not doing a best effort delete/move (copy should occur even if > its locked), is a very valid thing for a server to do. In fact I would > argue that if MS could implement a "rollback" during the delete/move, we > would make these operations atomic. > > Since this is true, I would like agree with Greg that a new status code > should be created that states the operation failed (do to locks, > permissions, etc) and the operation was rolled back. > > Xythos would then return the new status code for a failed move/copy instead > of doing a best effort (along with mod_dav), and MS can return the > best-effort status for move/copy. > > It has been our experience that a best effort delete/move is the WORST thing > to do to a user. The XML returned should note ALL resources that are > stopping the move/delete and what the problem is (locks, permissions, etc), > so that the client can tell the user what is stopping the operation. > > Thanks, > Kevin > > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein > Sent: Wednesday, May 31, 2000 12:16 PM > To: w3c-dist-auth@w3.org > Subject: Q: does this use of 424 seem reasonable? > > > Hi all... > > One more question: in the current mod_dav architecture, I am unable to do > a "best effort" delete/move/copy when a lock exists somewhere in the > affected resources. As a result, the only real option available is to fail > the entire request. > > However, this would effectively mean returning a 207 (Multistatus) that > contains an entry for every single resource stating (in some way) that it > was not deleted/moved/copied. > > I would much rather do the following: > > *) return 424 (Failed Dependency) > *) include a body in the 424 response, which contains a DAV:multistatus > element which refers to the locked resource > > > Does this seem reasonable? > > Thanx, > -g > > p.s. and no, fixing it to do best-effort is not an option > > -- > Greg Stein, http://www.lyra.org/ > -- Greg Stein, http://www.lyra.org/ From w3c-dist-auth-request@w3.org Wed May 31 18:52:40 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 SAA26570 for ; Wed, 31 May 2000 18:52:40 -0400 (EDT) Received: (from daemon@localhost) by www19.w3.org (8.9.0/8.9.0) id SAA25187; Wed, 31 May 2000 18:47:29 -0400 (EDT) Resent-Date: Wed, 31 May 2000 18:47:29 -0400 (EDT) Resent-Message-Id: <200005312247.SAA25187@www19.w3.org> Date: Wed, 31 May 2000 15:38:47 -0700 From: Kevin Wiggen In-reply-to: To: Greg Stein , w3c-dist-auth@w3.org Message-id: MIME-version: 1.0 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Content-type: text/plain; charset="us-ascii" Content-transfer-encoding: 7bit Importance: Normal X-MSMail-Priority: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 X-Priority: 3 (Normal) Subject: RE: does this use of 424 seem reasonable? Resent-From: w3c-dist-auth@w3.org X-Mailing-List: archive/latest/4324 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 I am fine with the 424 as long as clients expect to see a XML body from a Webdav server. We NEED to have some way of informing the client why the move/delete failed. Again I don't care if its a new status or an existing one, I would just like to make sure that an XML body (without internal 424's as this would be possibly huge) can (and MUST) be returned to the client. Kevin -----Original Message----- From: w3c-dist-auth-request@w3.org [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein Sent: Wednesday, May 31, 2000 3:22 PM To: w3c-dist-auth@w3.org Subject: Re: does this use of 424 seem reasonable? Um. Including 424 into a 207 is legal (since it is only a SHOULD NOT), but it means that I would have to generate a response for all 1000 children of the collection that I'm trying to delete. Each resource would have to say "sorry, I wasn't deleted due to a 424 (Failed Dependency)". I'm seeking to return a single, top-level status that indicates the whole thing failed. 424 seemed most appropriate (4xx meaning the client can fix it, and 424 meaning that it was caused by some other reason). A 409 (Conflict) would also be fine, but I don't think it provides as much information (409 seems to say "problem with resource" while 424 says "problem with resource"). Kevin suggests creating a new 4xx status. I'm not sure that I want to go that far :-). If the body is a problem, then I'll probably just leave out a body. Although... I can't see how that would be a problem... I'm with Geoff on this one -- how does a body in a 424 cause a problem? Okay. Fine-tuning of the response aside, I also get the feeling that nobody is going to pester me saying "you moron, it should be best effort." I'm going to solidify the "single failure response" in mod_dav now, and look for responses to this thread to find the right status code and body contents. Cheers, -g On Wed, 31 May 2000, Geoffrey M. Clemm wrote: > > I heartily concur that atomic delete behavior is far more well behaved > from a client's perspective, and should be supported whenever possible > (and will even be required in the presence of multiple bindings to a > resource). > > Last time I suggested returning a body with a 4xx status indicating > what failed, JimW said this would cause a problem, but unfortunately > I never did get what that problem would be. I hope JimW was wrong, > because otherwise I see no easy way to avoid running out of 4xx > status codes someday soon ... > > Assuming it is a problem, an alternative marshalling would be to return > the 424's in a 207, since currently 528 says that 424's SHOULD NOT be > returned in 207's from a DELETE (so we should be able to use the > 424 to mean what we want). > > Cheers, > Geoff > > Date: Wed, 31 May 2000 12:33:02 -0700 > From: Kevin Wiggen > > > I think that not doing a best effort delete/move (copy should occur even if > its locked), is a very valid thing for a server to do. In fact I would > argue that if MS could implement a "rollback" during the delete/move, we > would make these operations atomic. > > Since this is true, I would like agree with Greg that a new status code > should be created that states the operation failed (do to locks, > permissions, etc) and the operation was rolled back. > > Xythos would then return the new status code for a failed move/copy instead > of doing a best effort (along with mod_dav), and MS can return the > best-effort status for move/copy. > > It has been our experience that a best effort delete/move is the WORST thing > to do to a user. The XML returned should note ALL resources that are > stopping the move/delete and what the problem is (locks, permissions, etc), > so that the client can tell the user what is stopping the operation. > > Thanks, > Kevin > > -----Original Message----- > From: w3c-dist-auth-request@w3.org > [mailto:w3c-dist-auth-request@w3.org]On Behalf Of Greg Stein > Sent: Wednesday, May 31, 2000 12:16 PM > To: w3c-dist-auth@w3.org > Subject: Q: does this use of 424 seem reasonable? > > > Hi all... > > One more question: in the current mod_dav architecture, I am unable to do > a "best effort" delete/move/copy when a lock exists somewhere in the > affected resources. As a result, the only real option available is to fail > the entire request. > > However, this would effectively mean returning a 207 (Multistatus) that > contains an entry for every single resource stating (in some way) that it > was not deleted/moved/copied. > > I would much rather do the following: > > *) return 424 (Failed Dependency) > *) include a body in the 424 response, which contains a DAV:multistatus > element which refers to the locked resource > > > Does this seem reasonable? > > Thanx, > -g > > p.s. and no, fixing it to do best-effort is not an option > > -- > Greg Stein, http://www.lyra.org/ > -- Greg Stein, http://www.lyra.org/