RE: comment/questions on protocol-03

403 - Ahh I see. You have hit on a topic that is still uncertain around
these parts. There has been a lot of arguments about how much error
information to return. General experience seems to be that there are
really only two errors in the world "Something went wrong" or "It
worked." The "Something went wrong" sometimes gets subdivided into two
or three different categories for any particular operation but that is
about it. In fact some people have even suggested getting rid of
multiresponse all together for things like PROPPATCH and just returning
either success (which means all the changes were made) or failure
(meaning something went wrong with one of the requested changes but not
specifying what). I can see good cases for both. The current policy
seems to be to give the general "flavor" of what went wrong and then to
see what push back we get from people actually writing client code.

Default properties - In DAV a legal value for a property is "empty".
This translates to a response body of <prop><random-property/></prop>.
So in so far as the DAV protocol is concerned the previous is a
completely legal value, it has no special status and so is not treated
specially by the protocol. That is why we don't have to put in any
special language to explain how it interacts with any of the methods.

Token Extension - A token is a BNF construct defined in RFC 2068. The
reference to token has been previously referenced in the DAV spec so we
didn't repeat the reference on this particular example. A token is
simply a string of characters which identifies, in this case, an
extension to the functionality of the Destroy header. Any RFC can be
used to define such a token. The purpose in requiring tokens to be
defined in an RFC is to ensure that namespace collisions do not occur.
As for the Mandatory header, it only specifies that if the server does
not understand a particular header then it MUST NOT process the message.
That way you can put "Mandatory: destroy" on a DELETE request and know
that the server will only process the request if it understands what the
destroy header is.

	Hope that helps clarify matters,
			Yaron

> -----Original Message-----
> From:	John Turner [SMTP:johnt@cgocable.net]
> Sent:	Tuesday, October 07, 1997 6:56 AM
> To:	Yaron Goland; w3c-dist-auth@w3.org
> Subject:	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:24:41 UTC