RE: Semantics of supported-*

   From: Lisa Dusseault [mailto:lisa@xythos.com]

   I'll take the definition of supported-method-set for an example:

   "This property identifies the methods that are supported by the
   resource.  A method is supported by a resource if an application of
   that method to that resource has the semantics defined by the
   features supported by that resource."

   This is better than it used to be, but it's still not clear to me whether
   this is dependent on state (which can get us into the ugly state vs. type
   debate).

There have been some comments on this topic in another thread, but
I'll switch over to this thread since it has a better subject line.

Although the spec is currently (deliberately) silent on this issue, if
we were to say something, I'd advocate saying that whether or not a
method appears in the DAV:supported-method-set of a resource MUST
not depend on the state of the resource.

Stefan objected to this, and I responded, so clearly there is not
yet consensus on this issue (which is why the spec is currently
silent).  If consensus is achieved, I'd be happy to add the 
appropriate language to the spec.

Note though that whatever we say, there is always an opportunity for a
server implementor doing something silly, i.e. by indicating that a
method is supported, but *always* returning a failure of one of the
postconditions.  There is no way to legislate against such an
implementation, but there also is no need to, because the users will
rapidly convey their views on such a server back to the server
implementor.

   E.g.  does CHECKIN show up for a checked-in VCR, or only for a
   checked-out VCR?  Does LOCK show up for a locked VCR, or only an
   unlocked VCR?

The rule I suggest above would imply that CHECKIN would show
up in the DAV:supported-method-set of a VCR, whether or not it
was checked out (but would not appear in the list returned in
an Allow header if the VCR was already checked in).

   I assume that the answer to this will be consistent for
   supported-live-property-set and supported-report-set.

Yes, I would advocate the answer being consistent, and would advocate
the "not based on the state of the resource" being the consistent
answer.

Cheers,
Geoff

Received on Wednesday, 25 July 2001 02:26:14 UTC