RE: Review of ordering draft, version 05

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

   > From:  Clemm, Geoff

   > > 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.  ...

   Of course they are meant to be atomic. In fact, I don't agree that
   this needs to be clarified.

   RFC3253 says:

	   'A "postcondition" of a method describes the state of the
   server that must be true after that method has been completed.'

This implicitly meant "completed successfully".  If the method fails,
all bets are off.  By "partially succeed", I meant "made only some of
the changes that the postconditions require" (and therefore returns a
"failure" status).  An example of such a method is MOVE or DELETE on a
collection, which is allowed to move or delete some of the members
even if it fails (i.e. only "partially succeeds").

   Having a *set* of postconditions simply means that the state
   changes have been broken down into separate items, it does *not*
   mean that some of them are optional.

But without an explicit declaration of atomicity, a failure might
indicate "partial success" (i.e. some of the postconditions were
produced).

   The ordering spec uses the same structure as RFC3253 here, and
   RFC3253 doesn't seem to use the term "atomic" anywhere when
   specifying multiple postconditions. So if this really is an issue,
   I think it applies to all specs using this terminology, not only
   the ordering spec.

There were various debates about what "atomic" means, so the terminology
used in RFC3253 to indicate atomicity is:

"If an XXX request fails, the server state preceding the request MUST
 be restored."

Cheers,
Geoff

Received on Wednesday, 26 February 2003 17:51:20 UTC