RE: comment/questions on protocol-03

Supported Properties - Ahh, I think I finally understand. "Supporting" a
property in DAV only means that the server supports the property's
schema. The schema can say any number of things. For example, the schema
can say "The author property contains a first name and last name
element" or it could say "The date-created property MUST be defined when
the resource is created and MUST be set to the date of the resource's
creation." If the server supports both the author and date-created
properties then when the resource is created it will have a date-created
property defined on it. The resource will not necessarily have an author
property defined on it. However if the client tries to create an author
property and doesn't use a "first name" and "last name" element the
server will reject the property value as illegally formatted. On the
other hand, the client could try to create the "foobar" property which
the server does not support the schema for. In such a case, unless the
server refuses to accept any property it doesn't support, the server
will dutifully record the value for the foobar property and return it if
asked. However the server can do no more as it does not enforce the
schema for the property.

Supporting a property only means that the schema is supported, the
schema is the one which decides if the property is defined when the
resource is created, what legal values it may have, etc. Servers can
also record properties whose schemas they do not enforce, in which case
the property becomes nothing more than a bag of bits.

Token -Yikes, our screw up. I apologize. Del, can you please put in the
reference to section 2.2 of RFC 2068 in our first reference to the Token
BNF?

Mandatory - I believe the next version of the draft contains the
appropriate language. Del, did we include the section on Mandatory?

BTW Del refers to Del Jensen, the editor of the DAV draft.

		As always,
			Yaron

> -----Original Message-----
> From:	John Turner [SMTP:johnt@cgocable.net]
> Sent:	Tuesday, October 07, 1997 8:22 AM
> To:	Yaron Goland; w3c-dist-auth@w3.org
> Subject:	RE: comment/questions on protocol-03
> 
> 
> 
> >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
> johnt@cgocable.net

Received on Wednesday, 8 October 1997 00:14:20 UTC