RE: Review of ordering draft, version 05

   > From:  Lisa Dusseault
   > Are we possibly making things confusing by introducing a
   > postcondition "code" like (DAV:ordering-type-set) for something that
   > MUST be done?  It makes it seem like the server might choose not to set
   > the ordering type, create the collection anyway, and respond with 409
   > containing <DAV:ordering-type-set/>.

Whether or not a particular request may "partially succeed" is up
to the definition of that request.  Most RFC3253 methods are defined
to be atomic, i.e. they either succeed or they have no effect on
the server state.  The reason that multiple postconditions are
defined for an atomic operation is to allow the server to give the
client a more precise idea about which of the semantics of the
request could not be achieved (the client can then use this
information to give the user a better error message).

WRT to the specific example mentioned here, I agree that this issue
should be addressed by the ordering protocol, by having it state
whether the methods it is defining/extending are atomic, or whether
they are allowed to partially succeed.  I recommend that they be
required to be atomic.

   > Wouldn't a total failure to do
   > some required behavior normally be defined as a 500 response?

The difference between 4xx and 5xx is whether or not it is considered
a "client error" (e.g. an operation was attempted on a resource that
was not in an appropriate state for that operation to succeed) or a
"server error" (e.g. something went wrong on the server such as
running out of virtual memory).  So whether or not this is a 4xx or
5xx depends on whether the method definition allows server state to be
changed when the operation does not fully succeed.

   From: Julian Reschke [mailto:julian.reschke@gmx.de]

   Yes, and I think that's something that should be possibly fixed in
   RFC3253.  Failure to meet a postcondition (after all preconditions
   were verified) always is a server bug and thus would belong into
   the 5xx range.  The main question is: which spec should fix that?
   I'd really like to see RFC2518bis to pick up (and clarify) this
   kind of error typing (maybe in a way that makes it optional?).

Minimally, I agree that RFC3253 should be extended to allow error
tokens to be returned with any 4xx or 5xx response code.  I'll add
this to the issues list, and start a thread on the topic in the
versioning mailing list.  In particular, as Julian points out, this
would allow the more appropriate 5xx response code to be returned when
a postcondition is violated.

As for whether RFC2518bis picks this up, it probably is only useful to
do so if appropriate error tokens are defined.  I believe this would
not only improve interoperable error reporting for 2518, but would
help address some of the vagueness that remains in 2518.

Cheers,
Geoff

Received on Monday, 24 February 2003 09:38:58 UTC