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

RE: How Clients find out if they can perform a checkout

From: Stefan Eissing <stefan.eissing@greenbytes.de>
Date: Tue, 24 Jul 2001 10:48:13 +0200
To: "Clemm, Geoff" <gclemm@rational.com>, <ietf-dav-versioning@w3.org>
Message-ID: <NDBBKJABLJNMLJELONBKKEEMCPAA.stefan.eissing@greenbytes.de>
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
>
>    From: Lisa Dusseault [mailto:lisa@xythos.com]
> [...]
>
>    Digression: If supported-method-set only shows CHECKOUT if a
>    checkout is in theory possible, then this might make things a lot
easier for
>    the client. I had thought that supported-method-set should show the
methods
>    that may be allowed on a resource depending on the server's
functionality and the
>    resource's type.  However, it occurs to me that it's also reasonable to
>    say that the supported-method-set should depend on the resource's
state.
>    This amounts to the question:  if a resource is unlocked, should
>    supported-method-set show UNLOCK or not?  I've brought this up
>    before and haven't seen an answer.
>
> It's deliberately vague to give the server some leeway, but in
> general "supported" means that the method might succeed on some
> state of the resource, while the Allow set indicates whether
> the method might succeed on the current state of the resource.
> I agree this is worth stating in the protocol (if people agree
> with this characterization).

Oh, let's not be too subtle in DeltaV, please.

From RFC 2616, Ch. 14.7 "Allow", first sentence:
"The Allow entity-header field lists the set of methods supported by the
resource identified by the Request-URI."

Now, how could that be different from a "supported-method-set"?

//Stefan
Received on Tuesday, 24 July 2001 04:48:39 GMT

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