W3C home > Mailing lists > Public > ietf-dav-versioning@w3.org > April to June 2001

RE: Re: What is a supported property?

From: Clemm, Geoff <gclemm@rational.com>
Date: Fri, 22 Jun 2001 16:59:30 -0400
Message-ID: <3906C56A7BD1F54593344C05BD1374B1018E24D1@SUS-MA1IT01>
To: Ietf-Dav-Versioning <ietf-dav-versioning@w3.org>
Stefan:

These kinds of concrete examples are great!  I believe it leads to
a different conclusion than you perhaps intended, but this allows
the discussion to be grounded in concrete interoperability issues,
which I think are far more constructive than the somewhat 
metaphysical directions which I and others have been guilty of in
other postings.

Comments below ...

   From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]

   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.

Well, actually, you would look for the properties and methods that
you are going to use, and see if the resource supports them.

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

With the DAV:supported-*-set approach, if you want to do a MKCOL, you
would check whether MKCOL was in the DAV:supported-method-set.  IIS
has the opportunity here to tell you what is going on, by *not*
putting MKCOL in the DAV:supported-method-set.

Contrast this with the DAV:resourcetype approach (i.e. having the
client check for the presence of "DAV:lock-null-resource" in
DAV:resourcetype).  If IIS set this value, and based on it you tried
the MKCOL operation (which should work, according to the protocol),
you would be disappointed.  If IIS was "honest" and left this out
of the DAV:resourcetype, then your client would have to assume
this resource has *none* of the methods or properties of a
lock null resource.  Now I'm not in favor of buggy non-compliant
servers, but they are there, and it sure looks like we'd be
better of using DAV:supported-method-set to deal with this.

   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?

And if you looked at the actual properties and methods supported by
that resource, you'd have a reasonable chance of interoperating with
it, as opposed to trying to rely on the meaningfulness of
"DAV:lock-null-resource" in the DAV:resourcetype field.

   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.

And if you looked at the DAV:supported-method-set, you would
know whether or not a server accepted those certain HTTP requests
or not.  Not much you can do about a server that produces invalid
XML ... if it does that, it is unlikely you will be able to put
much faith in its correctly returning any property value,
including DAV:resourcetype or DAV:supported-*-set.

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

And it would work even better if it had DAV:supported-*-set
to tell it what was really going with the resources on at that server.

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

Not if you had the option of using DAV:supported-*-set (:-).

Cheers,
Geoff
Received on Friday, 22 June 2001 16:53:47 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 13:57:41 GMT