The whole idea of an abstract "agreement" that is separable from the Agreement resource is troublesome. In order to make sense of it, I have taken to understanding the "agreement" word to mean "the obligations to which the parties are bound as a result of this WS-Agreement interaction." I cannot readily accept the idea that the Agreement resource can be destroyed and yet the "agreement" still exists in some state other than "all obligations are now historical and let's balance the accounting." If the agreement terms have obligations that are still within scope, I think it should be impossible to destroy the Agreement resource which represents the management interface to those active/pending behavioral obligations. The spec currently says, I think, that the resource SHOULD outlast the agreement and I think the spec should read that the resource MUST outlast any obligations denoted in the agreement. I think, but am not sure, that Heiko's idea of terminating an agreement (not the Agreement resource) is to release the parties from these obligations. If I understand Jon's objection, I think it is that such a notion is not really well defined. Releasing parties from the obligation can mean a number of different things: a) Truncate the scope of obligations and resolve accounting as if the obligations had been scoped from their original start time until the time of this truncation. b) Act as if the obligations never existed, and each party absorbs their own costs incurred so far. c) Form a new Agreement which amends the obligations of the old; resolve accounting based on the new terms, which could encode a detailed transitional cost model, etc. d) Trigger some existing "escape" clause in the agreement terms which specified how to amend the obligations as in (c). Of course, in all of these there is an assumed change in behavior of the parties to coincide with these changes in obligation. I think it is a fair point that one cannot simply talk about terminating the Agreement resource or its represented obligations without identifying which of these avenues (or some other) are to be followed. In the real world of contracts and agreement, things are not destroyed so much as ammended and obsoleted. The old stuff is never forgotten, and in fact can be dragged in to court as evidence to help resolve later conflicts. At the same time, we have practical use for cancelling the obligations in some domains, e.g. cancel a job halfway through the run. What we need to do is capture the right form of ammendment. I think for jobs, the flavor (a) is about right; the job execution gets truncated and the user gets billed for time spent so far. If we get into fancier resources or advance reservation, we might need some additional penalty clause to be triggered as in (d). The general case is (c) where another offer/accept cycle can explicitly "ammend" or "obsolete" an existing agreement. I don't know if this should always create a new Agreement resource or simply operate on the existing one. In practice when two people decide to "tear up" a contract they are really making a token gesture that destroys some physical records and creates a new verbal agreement that they will ammend the old agreement as described above in (b)! What I think all of this gets at is that the Agreement resource universe of WS-Agreement is a subset of the "agreement" universe where our WS-Agreement parties live. An Agreement resource MAY be retired because its agreement obligations have become historical curiosity. The various actions that can cause obligations to become "past tense" range from timer expiration, to explicit destroy-resource requests or replacement Agreement creation. When this happens, history is not erased but rather system management state is ammended and pertinent information is recorded into audit and accounting systems. Do we need more explicit Agreement content to denote what forms of ammendment can (or have) been applied to the obligations of an Agreement? Or can that be implicit in the domain-specific terms? karl -- Karl Czajkowski karlcz@univa.com