AW: Re: What is a supported property?

Geoff,

I totally agree that it is _possible_ to solve all future interop
and extension problems with the DAV:supported-*-sets. The question
is: will it be _likely_?

The lock-null resource is an example of a resource which a client
can only tell apart by looking at a certain set of properties, as
I described. As you can see, this is very "brittle".

I would like to emphasize the case of moddav (very well compliant
server, thanks Greg) which bends the definition of lock-null
and its timeouts intentionally to please people with MS Office.

Certainly, moddav does not violate 2518 there, but it still comes
as a little surprise to clients like mine. It would be easier to
cope with this if the protocol would allow for a little bit more
redundancy, to allow moddav to say: "dear client, this really is
a lock-null resource, even though the lock timeout might look
strange. Trust me, I know what I'm doing."

I expect the same to happen with DAV:suported-*-set. 
1. It is not trivial to understand and implement correctly
2. Some servers will err, some clients will err. Depending on market
   share, all other will have to cope with those errors.

To repeat: I think the likelihood and amount of such errors will
be higher with the DAV:supported-*-set than a DAV:resourcetype. 

And now let's talk about something else. How's the wheather at
the west coast?

Stefan

> [mailto:ietf-dav-versioning-request@w3.org]Im Auftrag von Clemm, Geoff
> 
> 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 Saturday, 23 June 2001 04:07:07 UTC