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

Hi,

My vote is that we specify the behaviour of the Allow header in the
specification.  
If we say nothing then different server vendors may implement this in
different ways.

I am in agreement that Allow should return the same method set as
DAV:supported-method-set.  
If Allow returned the methods possible at the point in time the request was
processed then 
what use would these be, the state of the resource may change by the time
the client goes to 
act on the information returned by the Allow header (unless the resource was
locked).
  
Regards,
--
Peter Raymond - MERANT
Technical Architect (ADM)
Tel: +44 (0)1727 813362
Fax: +44 (0)1727 869804
mailto:Peter.Raymond@merant.com
WWW: http://www.merant.com


-----Original Message-----
From: Clemm, Geoff [mailto:gclemm@rational.com]
Sent: 03 August 2001 14:39
To: ietf-dav-versioning@w3.org
Subject: RE: How Clients find out if they can perform a checkout


I find Stefan's arguments convincing, so I'll switch my vote to
"define supported and allowed to be the same thing".  But I see good
arguments on both sides, so I will defer to whatever the working
group wants to do here.  And if there is no consensus, I'll leave
the spec the way it is (i.e. making no statement on the issue, and
leaving it up to the server implementer).

Cheers,
Geoff

-----Original Message-----
From: Stefan Eissing [mailto:stefan.eissing@greenbytes.de]
Sent: Friday, August 03, 2001 5:12 AM
To: ietf-dav-versioning@w3.org
Subject: RE: How Clients find out if they can perform a checkout


> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Clemm, Geoff
> 
> > From: John Hall [mailto:johnhall@evergo.net] 
> > 
> > > From: Clemm, Geoff
> > 
> [...]
> > > Using just
> > > DAV:supported-method-set and the Allow header is much simpler 
> > > and sufficiently accurate.
> > > 
> > > 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).
> > 
> > I think it is worth stating.
> 
> Yup, but we first have to get Stefan to agree (:-).

Let's see what the "most bang for less bugs" principle can do 
for this discussion:

A client cannot retrieve the Allow header and the DAV:supported-method-set
at the same time. It's always two (most likely three) requests. Depending 
on the usage, not the implementation of the server, the two method sets
 reflect the same state of the resource - or not (I am talking about 
unlocked resources here since clients should not need to lock, just to 
find out what they can do with it).

So, all your client knows after retrieving the two sets, is that at that
point in time it was:
a) possible right now to perform a checkout - or not (from Allow header),
b) generally supported to checkout - or not (from supported-method-set)

My point is that a) is useless in a client-server protocol, and that
b) is very useful. If CHECKOUT is supported, you only _know_ that
it succeeds when you try it out. 

I propose to give the Allow set and the DAV:supported-method-set
the same definition, namely, that they include those methods which
may succeed on some state of the resource (e.g. the current definition
of DAV:supported-method-set), at least for all WebDAV extension methods.

What can be gained by this?
1. Consistency and performance: it is possible to retrieve a consistent
   view of what there is to know about a resource with one PROPFIND, with
   varying depth even for a range of resources.
2. Simpler implementations on server side. Servers do not
   need to implement two sets of methods with one varying on every state
   change.
3. Easier (if that's possible) understanding of the deltaV spec, e.g.
   one feature less.

Point 1. is my wholy grail. It makes clients faster and keeps them
simple. A client does one, single PROPFIND depth 1. Either it fails,
with error to user, or it has the complete information about a
collection and all of its members. This is very powerful use of
WebDAV + XML. Try that with RPC or SOAP.

//Stefan

PS. Before someone asks: I think my definition does comply with Allow 
as described in RFC 2616. There is never a NOT IMPLEMENTED returned 
by a deltaV server on a method from DAV:supported-method-set.