RE: Postconditions with no XML elements defined?

> -----Original Message-----
> From: ietf-dav-versioning-request@w3.org
> [mailto:ietf-dav-versioning-request@w3.org]On Behalf Of Lisa Dusseault
> Sent: 11 July 2001 17:34
> To: Tim Ellison; ietf-dav-versioning@w3.org
> Subject: RE: Postconditions with no XML elements defined?
>
> Please make it simple and normative!

A simple list would suffice, right?

> > The preconditions are statements that must be true for a method to
> succeed,
>
> Sounds like if the precondition is not true the operation is "Forbidden",
>
> > and the postconditions are statements that must be true
> immediately after
> the method has suceeded.
>
> Sounds like there must be a "Conflict" if the postcondition cannot be met.
>
> If there are no strong objections, I propose that we adopt the simple
> normative rule a precondition is returned with 403 and a postcondition is
> returned with 409.

The 403 Forbidden means that you shouldn't bother trying any variations on
this request because they will fail, an example would be trying to MOVE a
version resource, there is nothing a client can do to make the server happy
about this.
A 409 Conflict means the client likely can do something to fix the resource
or server state so that the request will succeed, for example trying to
CHECKOUT a checked-out resource will fail, but can succeed if the resource
is first checked-in.

I don't think it is as simple as saying all preconditions are 403 and all
postconditions are 409 as it would lead to some anomolies, such as the
DAV:preserve-versioning-properties postcondition being a 409!

... but I did say that I wouldn't argue<g>

Tim

Received on Wednesday, 11 July 2001 16:44:44 UTC