RE: Comments on the current draft

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