Minutes of CPPA Negotiation Discussion
at CPPA Face to Face Meeting,
Attendees: See minutes of CPPA Face to Face meeting.
Marty Sachs opened the negotiation discussion with a presentation that introduced the work of the automated negotiation subteam to the others in the room and described status and work to be done. He pointed out in particular that design of a negotiation algorithm is necessary in addition to choreography, document design, and identifying what is negotiable. This work has not been started yet.
We started working on the details of element and attribute negotiability, using Dale Moberg’s in-progress spreadsheet. Dale documented most of this discussion by making entries in the spreadsheet. The following significant points were discussed.
Whether a third party has to sign the CPA is negotiable.
The values of the Start and End elements have to match certificate validity times (especially the end element) and the start time must precede end time. The rules in this paragraph are not really negotiation points but they do bear on the composition process and the validity of the CPA.
NOTE: At this stage, we are not necessarily distinguishing between negotiability and validity since the result of the composition and negotiation process must be a valid CPA and the composition process is within the scope of the subteam.
DefaultMSHChannelID: since a delivery channel contains both parties’ properties, the two parties have to agree on both parties’ default channels. More discussion is needed.
DefaultMSHPackageID: Use case needed.
PartyId type: The type attribute of PartyId identifies the naming system to which the PartyId belongs (e.g. DUNS). The negotiation process should select one possible PartyId type for each party and eliminate any others that are in the CPPs. Each party’s PartyId type must be understandable by the other party. Eliminating the others ensures that each party will always use the same PartyId for the other party.
The type attribute of PartyRef needs a use case for negotiability. One possible reason to negotiate is that a party may not be able to understand the other party’s PartyRef document. For example, the geographical contexts might not match. While negotiating the contents of the PartyRef document is out of scope for the CPPA team, negotiating the contents might lead to negotiating the schema (type), which is in scope for the CPPA team.
CollaborationRole: the cardinality is one or more. We need use cases for having more than one per party in the CPA.
Version attribute of ProcessSpecification: The two parties’ CPPs might specify the same BPSS instance but different versions of it.
Name attribute of ProcessSpecification. This is not negotiable unless the BPSS team intends to provide more than one ProcessSpecification element in a BPSS instance document.
ds:Reference child of ProcessSpecification: We discussed whether both parties have ds:Reference if either has it. Arvola Chan suggested that this is necessary so that if either party validates the BPSS instance using ds:Reference, both parties should validate.
Role: The two parties have to have opposite roles in a collaboration. This should be validated but there is no known use case for negotiating it.
ApplicationCertificateRef: This is negotiable because one party’s certificate authority might not be acceptable to the other party. certId could be an enumeration of possible certificates. There can be zero or more ApplicationCertificateRefs.
ThisPartyActionBinding: PackageId might be negotiable. Brian Hayes said out that in general, each party has to know the name that the other party uses for each action but they don’t need to negotiate since there is no reason for the names to match.
ActionContext: This is not negotiable. If BPSS is not being used, ignore ActionContext.
CollaborationActivity: Arvola explained that this allows a party to specify a complete path inside the BPSS instance document. It is not usually changed.
ChannelId: The parties can negotiate which channels to use or even add new ones.
Certificate: Enumeration of keyinfo types might be useful to help decide which certificates are acceptable.
certId: This may have to be corrected if there is more than one certificate with the same certId value. This is not really a negotiation but it is a condition that can occur during composition of a CPA from two CPPs and is therefore in scope for the CPPA team. (MWS reminder: This can happen with any ID attribute.)
DeliveryChannel: Cardinality is negotiable. Its attributes are correctable (ID and IDREF attributes). It was suggested that a new delivery channel be created rather than modifying an existing one.
CPPA F2F SUMMATION SESSION
During the CPPA F2F summation session, Marty pointed out that the autonegotiation subteam is suffering from lack of critical mass for making progress on many conference calls. It is therefore uncertain whether the subteam will complete a specification by December. The following work still must be done:
- Complete the element and attribute negotiability spreadsheet.
- Resume work on the BPSS instance definition.
- Resume work on message content.
- Resume work on the NDD. This will follow from the negotiability spreadsheet.
As indicated above, work is also needed to define a negotiation algorithm.
Respectfully submitted,
Marty Sachs