- From: Jim Whitehead <ejw@ics.uci.edu>
- Date: Tue, 19 Aug 1997 17:21:43 -0700
- To: "'Dylan Barrell'" <dbarrell@bb.opentext.com>, "'w3c-dist-auth@w3.org'" <w3c-dist-auth@w3.org>
Dylan, Thank you for your feedback on the draft. My replies to your comments are below, my apologies for the delay in getting them to you. On Monday, August 04, 1997 1:21 AM, Dylan Barrell [SMTP:dbarrell@bb.opentext.com] wrote: > Here some comments on the current draft (excluding locking) > > 2.2.1 Overview > > The DAV property model is based on name/value/attribute triples. > The name of a property identifies the property's syntax and > semantics, and provides an address with which to refer to a > property. The value of a property is an octet stream. The > attributes of a property are a set of name/value pairs that are > not directly addressable. Attributes are retrieved in conjunction > with retrieving a property, and are set when changing a property's > value. This specification defines two attributes, live, which > indicates if the property's syntax and semantics is enforced by > the server, and readonly, which indicates that the property's > value may be retrieved but not set. > > [Comment] The above paragraph implies that it is not possible to change a property's attributes if the property is readonly. Is this intentional? > This is definitely intentional. An example of a readonly property is the size of a resource, which can only be set by re-writing the contents of a resource. The size of a resource is also live, since the server maintains the syntax and semantics of the property. > Last paragraph in 2.2.3 > > If a client submits an attribute when setting a property > then the server MUST NOT record the property unless it > accepts the values specified for the corresponding > attributes. Thus, if a property value is submitted with a > live attribute then the server MUST NOT record the value > unless the server understands and enforces the syntax and > semantics of the property. > > [Comment] Can someone explain this paragraph to me? It seems to me that the paragraph only makes sense if you replace the final "property" with "attribute". The wording is correct, however it is now moot, since at the Munich IETF we decided against allowing the client to specify attributes of a property when setting the value of a property (If the server doesn't know how to enforce the syntax and semantics, a client can't ask the server to do this. On the flip side, if the server already does enforce the syntax and semantics, then the client shouldn't have to ask for this behavior explicitly). Likewise, for a client to discover the live and readonly attributes of a property, it must perform schema discovery on the server. > Last paragraph in 2.3.2 contains the following sentence > > ...If this attribute is included when setting the > value of a property, the request MUST be rejected since > accepting the value would violate ReadOnly attribute..... > > [Comment] How does one set a property to be readonly if including it in the setting of the property will cause the operation to fail and this is the only way to change the attribute? See above. Live and readonly can no longer be set by the client, they are qualities of the property determined by the server. > > 2.5.1 > > [Comment] What is the distinction between source of the link and destination of the link? I haven't been able to think of an example where one would require this distinction. In fact in the example in section 2.5.6 the sources and the destinations are always the same so it seems as though the authors weren't able to think of one either. When dealing with the is-derived-from relationship, it is necessary to distinguish between the source and the destination. If the relationship is defined as (destination) is-derived-from (source) then this has a different meaning than (source) is-derived-from (destination). For example, 1.1 is-derived-from 1.0 is different from 1.0 is-derived-from 1.1. > 2.6.5.2.6 Match-String XML element > > [Comment] The above heading should read "2.6.5.2.6 Match-Stream XML element" > > .... Description: This element provides a template against which > anything that can be expressed as an octet stream may be > compared. "*" is a wildcard that matches zero or more > unspecified contiguous octets. "?" is a wildcard that > matches exactly one unspecified octet. ...... > > [Comment] This paragraph is not reconcilable with ISO 10646 because an international character could be more than one octet wide. Good point. This was also rendered moot at Munich, since the capability of the SEARCH method was reduced to being just "return the values of the following properties," and was renamed to PROPGET accordingly. There is currently no wildcard (or perhaps a single, match-all-names wildcard) in the PROPGET method. > 3.1.3 > > ....... In the general case, a large number of source resources can > comprise a data-producing process that generates many output > resources, creating a many-to-many relationship between > output resources and source resources. If each output > resource had links back to every source resource in the > data-producing process, there can be a potentially large > number of such links. Due to the potentially large number of > links, and the lack of a policy for ordering access to > multiple sources, explicit storage of source relationships > is limited to cases with only a single source resource. ....... > > [Comment] The above is too restrictive to be useful. This means we cannot even use this mechanism for linking the output resource to the corresponding language versions so I have to ask what the point is in having this feature at all? Another good point. This link is useful for cases like server-side-include content, CGI scripts, or .asp resources, but it doesn't handle linking to multiple language sources. Although isn't it more likely to be the case that an author would be going from a particular language version and following the source link to the one primary document from which all the translations have been made? In this case, the source link would work. > 3.2.4 > > [Comment] Which response does one get if one does not have permission to perform this operation? In this case, the proper response is an HTTP/1.1 "401 Unauthorized" status code. > > 3.5.3.3 > > .... A Depth of "0" indicates the collection MUST duplicate all > of its external members in a new collection at the > Destination. Since the COPY method is not propagated to its > members, no internal member resource is duplicated. .... > > [Comment] Why the distinction between internal and external members? I find this a bit ideosynchratic. Depth 0 should simply not do anything for collections. I agree. I believe the proper action to take here is to duplicate the collection and its properties, but to not duplicate any of the internal or external members. The rationale behind duplicating the external members was that the state of these links was being kept inside the collection, and hence a duplication of the state of the collection would entail duplicating the external member links. > [Comment] When duplicating external members, does the server copy the reference to them or their content (I assume it is the reference)? Just the reference (unless they are propagate links, which is moot, since at Orem it was decided to no longer have propagate and no-propagate links). > 3.5.3.4 > > .... If the destination resource identifies a collection and the > Overwrite header is "true," prior to performing the copy, > the server MUST perform a DELETE operation on the > collection. .... > > [Comment] Deleting a collection before overwriting it (or stipulating that this should be done) will cause all the previous versions of the members of the collection to be lost. Is this really the intention of the Overwrite header? As specified, yes. There is a Destroy header, which hasn't been discussed much, which allows you to specify options like "undelete" if the resources should be left in such a state that they could be undeleted. However, this header is problematic, since there is currently no way to undelete a resource via WebDAV or HTTP/1.1. > 3.5.5.1 > > [Comment] In this example, Destination is fully qualified. Why? Is this intentional? May it be relative to the Host? Is the host in Destination allowed to be different from the source host? Yes. While we're explicitly not considering server-to-server protocol issues in WebDAV, one goal is to specify operations in WebDAV so that web servers which did support a server-to-server protocol would be able to handle a COPY or a MOVE of a resource from one server to another. Initially, if a client specified a server-to-server copy, a web server would fail the request. In the future, once a server-to-server protocol were in place, the server would attempt to perform the copy or move to a remove server. > 3.6.1 > > .... The move operation on a resource is the logical equivalent > of a copy followed by a delete. .... > > [Comment] The above paragraph should read "The move operation on a resource is the logical equivalent of a copy with depth infinity followed by a delete." Hmmm. At Munich it was decided to move recursive semantics into a separate specification, leaving the base specification to define Depth 0 semantics. Since this doesn't really work for moving collections, I suspect that a Depth 0 move of a collection will fail. > 3.11 > > [Comment] What are the defaults for all the headers specified here. Good point. This is currently underspecified in the specification. - Jim
Received on Tuesday, 19 August 1997 20:28:39 UTC