W3C home > Mailing lists > Public > w3c-dist-auth@w3.org > October to December 1997

RE: comment/questions on protocol-03

From: John Turner <johnt@cgocable.net>
Date: Tue, 07 Oct 1997 21:21:56 +0600
Message-Id: <199710080133.VAA09132@mail.cgocable.net>
To: Yaron Goland <yarong@microsoft.com>, w3c-dist-auth@w3.org

>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.

So there are no properties that are "supported but not set"?  All properties
that are supported have a value by default?  Does this mean then, that all
properties in all supported schema will be returned (name and value as
appropriate) when PROPFIND is made with either allprop or propname?

>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.

Thanks got it.

Other than the table of contents, this section has the first use of the term
token in the document.  This will make it difficult for new readers.  Also,
the Mandatory header is not described here, and I could not find it in
RFC2068, is it defined somewhere else?

>                Hope that helps clarify matters,
>			Yaron

Yes things are getting much clearer, thanks

John Turner
Received on Tuesday, 7 October 1997 21:34:32 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 15:01:16 UTC