On Jul 17, Subramaniam, Ravi modulated: ...

Would it be accurate to observe that where the disconnect here is that the view taken in the thread is that the establishment is the key and hence having that bi-party is desired but I have taken the "binding/honoring view" where the referenced parties define the agreement?

Unfortunately, I don't think that is the disconnect. Apologies for this long e-mail, but I want to recap some of the issues which have haunted WS-Agreement. There are three different relationships, as you mention. This same debate was had regarding WS-Agreement, and it wasn't merely an issue of feature minimization, but also a philosophical issue: 1. The communicating parties in the "establishment" of the agreement, obviously important in WS-Agreement. These are the "initiator" and "responder" roles in our protocol. One can actually design multi-party protocols here, but the debate is whether this is desirable---whether it models the underlying relationships and decision-making that is to be exposed. 2. The obligated parties of the agreement. We basically map these to the protocol roles in WS-Agreement, but we recognize that they can be delegated relationships... this is part of the internal logic of the service to either make decisions or "broker" decisions. As you said, the communicating parties "represent" the obligating parties during the establishment of the agreement. This obligating relationship is actually what people are referring to when they say that, in practice, real world agreements that "appear" multi-party are really sets of bilateral agreements. This boils down to how the obligated parties can reconcile things with an auditer or within a legal system. This is complicated by the fact that new entities are sometimes introduced, e.g. a set of members agreeing bilaterally with an "association" over which the entities will also gain fractional control. 3. The services which are the subject of obligations. It sounds like everyone here is seeing this the same way, so I won't belabor the point. The two philosophical debates to be had are regarding the cardinality of these obligating relationships (2) and also whether the obligating relationships are important to informing the communication patterns and semantics of the protocol. I think the best reason to investigate real-world agreements/contracts is to see what we can learn from them about practical solutions that have been found. For example, this can inform us on the important differences between negotiation+agreement, performance, and reconciliation which may occur in different overlapping but not equal time periods. (For example, one might legally resolve a contract dispute after the "service period" is over, but before the contract has become legally irrelevant.) This has helped GRAAP-WG to delineate the function of WS-Agreement service representations: our service represents a basic negotiation and agreed-service monitoring infrastructure, but retires agreements to some presumed external entity for audit and reconciliation. Our agreement language is (hopefully) complete enough to guide the reconciliation phase, as well as to guide the actual negotiation and performance phases. However, I personally belong to the school which sees this as just a useful model for automated agreement patterns. It makes the distributed architecture more understandable to follow the social idioms used for human-based agreements and contracts. There are those who even question the legality of things like digital signature and non-repudiation. I do not want adaptive computing systems to really be forming legally binding obligations. With their problems, digital signatures are still much easier to justify than the idea that we can delegate legal responsibilities to a machine-driven decision process! I think there are examples of machine-driven, binding decisions out there, e.g. in the financial trading sector. But, I think many computer systems operators/owners will be scared away from Grid technologies if they are told that their computer will now begin signing contracts which bind the owner... I think we need a lower barrier to entry into this field. karl -- Karl Czajkowski karlcz@univa.com