AW: Re: What is a supported property?

I think we agree to disagree on the complexity issues of
extending DAV:resourcetype as compared to DAV:supported-live-
property-set.

> [mailto:ietf-dav-versioning-request@w3.org]Im Auftrag von Tim Ellison
>
> "Stefan Eissing" <stefan.eissing@greenbytes.de> wrote:
> [...]
> I mean that if a client or server is allowed to set, say
> DAV:getcontentlength, it had better mean what RFC2518 says it means.
>
> > This is done, IMHO, for DAV:resourcetype and especially for
> > DAV:supported-live-property-set. DeltaV explicitly proposes that
> > semantics for DAV:supported-live-property-set does change with
> > every addition or removal in its content.
>
> I don't understand this.

DAV:supported-live-property-set will by definition be extended
by every future extension to the DAV protocol family. That means
it will automatically have new members with every extension.

These new members will change the way how clients interpret
the value of DAV:supported-live-property-set, e.g. its semantics.

Thus, it is an example of a property which implied semantic will be changed
by future extensions, hopefully in a way backward compatible with
current deltaV definition.

> > The difference between changes of DAV:resourcetype and
> > DAV:supported-live-property-set is that the latter requires
> > set operations to discover the semantics.
>
> I suggest that since the DAV:resourcetype will be multi-valued, clients
> will be required to perform the set operations either way.
>
> > When a client discovers DAV:collection in DAV:resourcetype, it
> > is safe to assume that it can treat the resource as a collection.
>
> Agreed.  It can treat it as a collection as defined by RFC2518.
>
> > When a client discovers DAV:checked-in in
> DAV:supported-live-property-set
> > it has to look for the appearance or absence of other properties in
> > this set in order to know what it can do with the resource.
>
> How much more difficult is it to look for multiple values than single
> values?

Real world example: my client has to detect and work with lock-null
resources.
They have no special resource type in RFC 2518. So I have to look at the
properties:
- resourcetype: not collection
- lockdiscovery: a lock-null resource should have a write lock.
- getcontentlength: present, but without a value.

According to spec: this should work. However

1) IIS pretends to implement lock-null. It creates empty files which
   do not vanish when the lock expires. Detection of the resource my
   client creates (successfully according to response code) fails, since
   the getcontentlength is 0. But I would like to do MKCOL on it...

2) moddav supports lock-null with some special quirks: at first, the
PROPFIND
   response is OK, but the resource does not expire when the lock timeout
   says it should. Instead it hangs around for a while afterwards and
   the timeout value reported in seconds is bigger than 2^31-1. Oops,
   can this be a valid lock?

3) Some servers do not accept certain HTTP requests, others produce invalid
   (e.g. not well-formed) xml and some throw a whole range of nowhere
   defined properties in the DAV: namespace at a client.

Does my client have to work with those servers? It sure does!

Would I be glad for a resource type lock-null? Take a wild guess.

Stefan

Received on Friday, 22 June 2001 10:24:57 UTC