(by Jean Zheng)

Brian Hayes (Commerce One)

Heiko Ludwig (IBM)

Pallavi Malu (Intel)

Dale Moberg (Cyclone)

Peter Ogden (Cyclone)

Marty Sachs (IBM)

Jean Zheng (Vitria)

Dale has received ftp information regarding Negotiation web spaces, Marty will put past minutes and Requirement document on the web soon.

March Conference calls will be hosted by Hima(Sybase). Details TBD.

Brian pointed out that Negotiation transactions is similar to BPSS’s PurchaseOrder/OrderChange transaction model. For negotiation, transaction boundary needs to be defined when multiple counter proposal are proposed. Collaboration can go on forever, no boundary is required. But transaction must have a boundary. In a simplistic approach, we could mandate that the same side initiate all transactions within one negotiation.

Heiko thought it is too limiting to restrict counterproposal to be made by one party only.

Brian pointed out that using PurchaseOrder style transaction to model negotiation will cause race condition.

Brian proposed that each transaction to be limited to Proposal->CounterProposal->reject/accept. If another proposal must be sent, than a new transaction must be started. Heiko thought that will make the concept of "transaction" meaningless.

Marty suggested to use "Extended Transaction". Brian clarified that "extended transaction" in essence is equivalent to a binary collaboration, which can be choreographed. Marty suggested that promoting all current "Transactions" (e.g. Initial Proposal, Counter Proposal, Accept, Reject, etc.) to the binary collaboration level, and utilize choreography to model the transaction might be one alternative.

Pallavi suggested using one transaction within another transaction. If the transaction is of the same type, you can start one underneath another. There is a "OnInitiation" flag in Transaction Element can be set. All agree that could be an interesting alternative.

So currently we have two possible approaches for negotiation process definition: utilizing OnInitiation Flag to start nested transactions; or promote all transaction up one level to binary collaboration and cerography all the individual binary collaborations.

Marty also suggested that Brian and Jean could work off-line on the process definition since message content is tightly related to the process definition.

Jean has received comments from Heiko regarding "signing of CPA" and "CPPID".

2a. Signature on CPA (proposal, counterproposal):

Marty pointed out that there are multiple signatures involved in the negotiation process. In addition to signing the final CPA as a legal contract (Legal Signing), there are also signatures used for Integrity Check and Non-repudiation purposes (Message Signing).

For Legal Signing:

Marty and Brian suggested that intermediary documents not to be signed because it doesn’t even contain a full CPA document. The very first document that proposing party sent over, does it need to be signed? The answer is no, since it is still not final.

Group consensus was not to perform the legal signing till the very end. Ask Jamie for legal advice.

For Message Signing:

Signing of intermediate message should be described in NCPA.

Dale and Peter mentioned that signing of intermediate msg might be a bootstrapping issue. Unable to handle proposed trust model could be a reason for rejection. Peter pointed out that if both parties have the same PKI models, then the negotiation process can recognize that similarity in trust model and all negotiation can proceed in a secure fashion.

Jean suggested adding trust model/security information in the initial message that is sent from party A to Party B, during the initial information exchange. Marty agreed that dynamically exchange these information might be easier than to incorporating them into the NCPA process.

Dale pointed out that in this case, there might be some delay between party B receives proposal and party B responses because Party B will need to determine whether to accept the proposed security model and possibly to reconfigure Party B’s security model, all these will very likely involve human intervention.

All agreed that such delay is probably acceptable during negotiation setup.

Conclusion: Two parties need to setup their trust model(for example: party B needs to add a new trust anchor proposed by party A) during initial stage of negotiation.

2b. CPP ID in the initiating message is acceptable.

(Jean’s side note: What if PartyB wants to use a different CPP instead of used CPPID. Maybe demands another "REJECTION" reason: expired CPP or something like that).

Brian asked whether CPA ID is a UUID? Or URN? It is suggested it could be either as long as the ID is unique for both parties inside this particular negotiation process.

Jean will update the message content based on today’s discussion.

Heiko will update the Glossary based on Peter’s comment.

N/A since Kartha is absent.