On Feb 20, Karl Czajkowski loaded a tape reading: ...
Just based on the above summary, I would say that I am proposing we drop the createAgreementGetResult operation in favor of an equivalent binding-level behavior to reliably get (or "re-get" by polling) the result of the existing createAgreement call in case it takes too long for the baseline bindings. I am also proposing that we attempt to incorporate his notion of a "reverse direction" createAgreementResult operation (which I separated as acceptAgreement and rejectAgreement) into a repair for the now underspecified and broken symmetric agreement pattern.
Thanks to all who pointed out that the GGF site does indeed have an archive for the GRAAP-WG mailing list. :-) After reviewing the proposed changes, I think the above comments still stand. The only additional "async" interface proposal was for termination, and I would also suggest dropping that because it is my belief that there is no implication of long delays in this operation. Termination is an inherently asynchronous mechanism by which the client requests termination and finds out if his request is acceptable or not; he does not get some response synchronized to happen "after" termination but he should assume the resource is not to be accessed if the response is successful. This is a point that I think was argued extensively (and convincingly, to me) in the OGSI and WSRF work groups. I actually would question why we have a wsag:Terminate instead of just using the WS-ResourceLifetime mechanism. I cannot see what value it adds or what would be different about the semantics. The text in the Agreement Context section is hardly convincing on this point. :-( Is it supposed to I am afraid I must have been absent during the time when this was decided... karl -- Karl Czajkowski karlcz@univa.com