- 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>
> [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 UTC