
Minutes are attached. The next telecon will be held on May 3, at the usual Wed. time. At this time, we intend to survey the state of the document, and determine any steps needed to submit back to GGF. --- Jim Minutes from the April 24, 2006 GRAAP Telecon Attendees --------- Toshi Nakata Jim Pruyne Chris Dabrowski Asit Dan Discussion ---------- - Spreadsheet row 41: We'd like Heiko to respond about whether there's still a need for the ContinuingFaultType, if not, we'd like to delete. - Jim to run the schema as defined in the document through the Axis tool chain to verify the correctness. - Jim to make sure that all of the comments in the comment tracker have appropriate responses. - Spreadsheet row 37: We agreed that even if accept fails, the agreement is still accepted, and the initiator must query to find out the status. It would be up to the responder to use other mechanisms like signing or reliable delivery if they do not want to risk accepting an agreement that comes from an invalid source.

Comments List attached. Best Regards Toshi Jim Pruyne wrote:
Minutes are attached. The next telecon will be held on May 3, at the usual Wed. time. At this time, we intend to survey the state of the document, and determine any steps needed to submit back to GGF.
--- Jim

The ContinuingFaultType is the specific WS-Agreement fault that we defined. I don't know anymore the rationale why it was called that name, but we might want to have a sepate fault type. Karl, do you rember the semantics of this name? Heiko ----- Heiko Ludwig, Dr. rer. pol. IBM TJ Watson Research Center, PO Box 704, Yorktown, NY, 10598 hludwig@us.ibm.com, tel. +1 914 784 7160, mob. +1 646 675 8469 http://www.research.ibm.com/people/h/hludwig/ Jim Pruyne <jim_pruyne@hp.com> Sent by: owner-graap-wg@ggf.org 04/24/2006 11:31 AM To GRAAP-WG <graap-wg@gridforum.org> cc Subject [graap-wg] minutes from 4/24 telecon Minutes are attached. The next telecon will be held on May 3, at the usual Wed. time. At this time, we intend to survey the state of the document, and determine any steps needed to submit back to GGF. --- Jim Minutes from the April 24, 2006 GRAAP Telecon Attendees --------- Toshi Nakata Jim Pruyne Chris Dabrowski Asit Dan Discussion ---------- - Spreadsheet row 41: We'd like Heiko to respond about whether there's still a need for the ContinuingFaultType, if not, we'd like to delete. - Jim to run the schema as defined in the document through the Axis tool chain to verify the correctness. - Jim to make sure that all of the comments in the comment tracker have appropriate responses. - Spreadsheet row 37: We agreed that even if accept fails, the agreement is still accepted, and the initiator must query to find out the status. It would be up to the responder to use other mechanisms like signing or reliable delivery if they do not want to risk accepting an agreement that comes from an invalid source.

On Apr 24, Heiko Ludwig modulated:
The ContinuingFaultType is the specific WS-Agreement fault that we defined. I don't know anymore the rationale why it was called that name, but we might want to have a sepate fault type.
Karl, do you rember the semantics of this name?
Heiko
Yes, I think it is obsolete. It had to do with distinguishing continuing or terminal faults in negotiations, i.e. continuing fault is like an E_BUSY etc, temorary failure which cancels an operation while terminal fault would be like a permanent fault on the negotiation (web resource) meaning the resource is no longer useful. I think this is much less important with the current offer/accept handshake, i.e. there is no ongoing conversation of counter-offers that you might or might not want to terminate. For Agreement resources, I think we can leave it up to the individual fault types to define their semantics, and not bother with this. For example, it is going to be underlying WS-Addressing faults that indicate your agreement resource EPR is invalid, right? We don't even specify the important faults. karl -- Karl Czajkowski karlcz@univa.com
participants (4)
-
Heiko Ludwig
-
Jim Pruyne
-
Karl Czajkowski
-
nakata