I reviewed all of the comments on the GGF tracker, and I do not see any real surprises relative to the "big issues" that have been in discussion. Here, I want to group together a set of possible resolutions that go together if we accept my earlier proposal to handle "asynchronous agreement" via a new stateful Agreement life-cycle. A. Agreements get a new life-cycle state "Pending" which means that an offer has been made but no obligations are in effect yet. The term-level status is undefined at this point. B. Agreements get a new life-cycle state "Rejected" which means that the offer was rejected and no obligations will ever be in effect. C. Agreements get a new life-cycle state "Observed" which means that an offer has been accepted and all obligations are in effect. The term-level status is meaningful at this point. This state captures the semantics of the entire lifespan of the Dec 2004 draft (module the confusion around termination). 1. The life-cycle model includes transitions Pending->Observed and Pending->Rejected but NOT Observed->Rejected. 2. Additional states may be warranted to try to resolve the many questions surrounding "termination" and "expiration." D. The existing createAgreement operation remains as an interaction where an input offer initiates a synchronous acceptance decision; the response is either a fault for rejection or an EPR to an Agreement that MUST already be in the Observed state. 1. The optional initiatorAgreement EPR is retained but the responder is under no obligation to invoke anything on this service. It is an optional avenue for the responder to monitor the "initiator's view" of their agreement. (And to attempt to initiate other control processes?) E. An optional AgreementAcceptance portType is introduced with two operations: acceptAgreement and rejectAgreement. 1. Both operations accept an empty input, as the association with an agreement is implicit via the WSRF addressing model. 2. An optional fault might be useful on rejectAgreement input to communicate why the offer was rejected? 3. These operations are only meaningful when the AgreementAcceptance service is in a Pending state. The operations synchronously change the service state to Observed or Rejected, respectively. 4. The AgreementAcceptance and Agreement portTypes may be merged to form a single service interface, and the state is shared between them. (What is the right way to do this in WSDL? Provide portType combinations in specification?) F. A new createPendingAgreement operation is introduced where an input offer initiates an asynchronous acceptance decision; the response is either a fault (fatal errors/rejection) or an EPR to an Agreement that MAY be in Pending, Observed, or Rejected state. 1. The responder MUST update its state RP to either Observed or Rejected following its decision. 2. The initiator MAY use alternate mechanisms to determine if and when the Agreement transfers to Observed, including but not limited to the querying of a state RP. Until the initiator determines the state as changed to Observed or Rejected, it SHOULD NOT assume the outcome. 3. An optional initiatorAcceptance EPR MAY appear in the input message, in which case the responder MUST invoke acceptAgreement or rejectAgreement to communicate its decision, in addition to updating its state RP. 4. An optional initiatorAgreement EPR MAY appear as in createAgreement. This EPR MAY be the same as the initiatorAcceptance EPR, if the service implements both interfaces. 5. Should the output allow an optional state indicator? I think it is simpler to say "no" and uniformly assume an interaction after creation. G. Topic "Changing Offers" is resolved as the input offer is accepted or rejected WITHOUT MODIFICATION by the agreement acceptance decision. Because of this, no response Agreement document is required in any of the above mechanisms. 1. Should there be an optional mechanism to retrieve the agreement document from the responder in such a way that it MAY be signed or otherwise held as proof of acceptance for auditing purposes? If so, does a queryable "agreement RP" satisfy this need? karl -- Karl Czajkowski karlcz@univa.com