In particular, Tony moved that we adopt the following schedule for version 1.01:
Obtain commitments by EOD Friday, Dec. 14 (U.S.)
Resolve any conflicts by EOD Monday, Dec. 17
Accept changes against 1.0 until EOD Friday, Dec. 21
Produce version 1.01 over the weekend of Dec. 22 - 23
The motion was approved by unanimous consent.
We also informally discussed the following schedule for version 1.02:
Obtain commitments by EOD Friday Dec. 28 (U.S.)
Resolve any conflicts by EOD Tuesday Jan. 02
Accept changes against 1.01 until EOD Friday Jan. 4
Produce version 1.02 over the weekend of Jan. 5 - 6
CPA and Messaging Service
Marty urged that everyone review Arvola's draft on how the messaging service should use the CPA. Dale will talk Karl Best and IIC about the appropriate "home" for the document, e.g., as an appendix of one document or perhaps a separate, jointly approved and published document. Dale feels it's important to ensure that the table is normative.
Brian reported that several BPSS voting issues related to CPPA have been cross-posted to our list by David Smiley and requested that CPPA members respond to David.
Brian said that their goal is to have a "pre 1.1" draft version out for comment in mid to late January.
Arvola told us that MSG has good agreement about all outstanding issues. They have a teleconference next Monday to discuss duplicate elimination, message order, reliable messaging, etc.
Hima reported that he distributed the CPPA conformance clause to IIC members.
Marty stated that the sub-team is continuing to work through the negotiation white paper to turn it into a requirements document. He has raised two matters on the negotiation list: Duane Nickull's recently re-posted negotiation proposal from last Spring, and the negotiation patterns from a BP technical report pointed out by Bob Haugen.
Hima mentioned the ebXML-dev thread on context rules for negotiation. Dale noted that CPPA is not targeting alignment with core components for version 1.1.
Peter Ogden is digesting security-related issues from the issues DB and has reviewed Arvola's schema changes.
Dale raised the question of confusion among developers reading a CPA to understand where the controlling semantic elements are. Feedback suggests that the most confusing parts have to do with NRR and digital envelopes, e.g., delivery channels under different PartyInfo elements, each with their own Characteristics elements. Marty explain that the intent behind having receive-only characteristics in a delivery channel was to disentangle the two parties' properties in comparison with tpaML and to make it easy to compose a CPA from two CPPs. In retrospect, parties' send properties should be captured with their own information. For example, a CPP needs to contain information about the certificate that a party uses when it sends. We discussed the prospect of moving more send information into the Characteristics element. Dale wants to get the consensus of the group for such a change.
Dale suggested moving to 90-minute meetings in January.
There will be another teleconference on January 3, 2002.