RE: comment/questions on protocol-03

>Setting unsupported properties - As currently specified the system would
>return a multiresponse with a 403 for the property in question. I'm not
>clear as to why this is not sufficient. Could you please elaborate?

Not really insufficient, more like unclear from the description of 403:
"The Client, for reasons the server chooses not to specify, can not alter
one of the properties."
My question should really have been more like, "If the server does choose to
specify, how should it do so?".
The obvious  answer is to put a reason in the ResponseDescription, but the
403 description in the WebDAV spec seems to suggest otherwise.  The
description of 403 in the HTML spec (10.4.4) clarified that this is a
reasonable use for the 403.

>allprop and propname - Ahh, I think I see the source of confusion, the
>use of the word "defined". For allprop, for example, how about removing
>the word "defined" so it reads "Its presence in a PROPFIND request
>specifies the name and value of all properties on the resource MUST be
>returned"

Yes, that would make it clearer.


>Prop type of PROPFIND - I'm sorry, I don't understand your point. It
>sounds like you are talking about live and dead properties. Currently
>the server does not return any information in a PROPFIND identifying a
>property as live or dead. At the Orem DAV meeting it was decided that
>live/dead information would be retrieved through schema discovery.

No, not live or dead.  Let me illustrate.  A resource is created, and no
dead properties are set.
Some schema with property A (dead) is supported for the resource.  What
would a prop type of PROPFIND with A return?  (No value has been set yet for
A.)  Similarly, what would a request for property B (not in any of the
schemas supported on the resource) return?  
I am seeing three states for the property (entirely aside from any
access/security cosiderations) unsupported, supported but with no value, and
set.  So I wanted to see how each interacts with the methods defined.


>MKCOL on A/B vs. A/B/ - The next version of the draft will have language
>on this issue. Specifically the following language has been added to
>section 3.1.1 "To support methods which operate on collections, a server
>SHOULD model its collection-like objects with collection resources.  For
>example, a server which is implemented on top of a file system SHOULD
>treat all file system directories exposed by the server as collection
>resources.  The URI for a collection resource SHOULD have its "path"
>component (as defined in [Berners-Lee et al., 1997]) terminate with a
>"/", and references to the collection name where the terminating "/" is
>omitted SHOULD be redirected to the URI with terminal "/"."

Good, I had assumed/hoped that was the case.


>3.6.3.3 - There was some confusion as to what happens to properties that
>already exist on the destination of a copy if none of the properties
>from the source have the same name. The authors agreed that the language
>was unclear and re-wrote it as follows: "A COPY on a collection causes a
>new, empty collection resource to be created at the destination with the
>same properties as the source resource.  All properties on the source
>collection MUST be duplicated on the destination collection, subject to
>modifying headers, following the definition for copying properties.  The
>new collection MUST NOT contain any members, internal or external."
>Notice that the conflict language has been removed. So the answer to the
>question is that any properties that existed on the destination are
>deleted because, as the first sentence says, "a new, empty collection"
>is created.

That is more what I would have expected it to do.

>3.11.4 - The following is the new text that is going into the next
>version of the draft, I believe it addresses your questions:
>When deleting a resource the client often wishes to specify exactly what
>sort of delete is being enacted. The Destroy header, used with the
>Mandatory header, allows the client to specify the end result they
>desire. The Destroy header is specified as follows:
>The Undelete token requests that, if possible, the resource should be
>left in a state such that it can be undeleted. The server is not
>required to honor this request.
>The NoUndelete token requests that the resource MUST NOT be left in a
>state such that it can be undeleted.
>The VersionDestroy token includes the functionality of the NoUndelete
>token and extends it to include having the server remove all versioning
>references to the resource that it has control over.
>		DestroyHeader = "Destroy" ":" #Choices
>Choices = "VersionDestroy" | "NoUndelete" | "Undelete" | token |"<" URI
>">" ; a token extension MUST NOT be used unless it is specified in a
>RFC, otherwise a URI MUST be used for extensions.

What is a token extension?  What kind of RFCs would specify one?
What does a header of "DestroyHeader:<SOMEURI>" mean?

Also, after re-reading the section; what is the Mandatory Header?
If a server cannot guarantee that an undelete is not possible, then does an
operation with a "DestroyHeader:NoUndelete" fail?


>The length and complexity of the DAV drafts makes many people loath to
>review them. So when someone takes the time to read and comment all the
>authors really do appreciate it. We know what kind of effort is
>involved.

Less than the effort to write it and rewrite it and .....
Thanks for the quick response on my comments.


John Turner
johnt@cgocable.net

Received on Tuesday, 7 October 1997 20:08:20 UTC