OASIS ebXML Collaboration Protocol Profile and Agreement TC
ebXML CPPA Technical Committee Teleconference
January 10, 2002
Minutes of the November and December voting meetings were approved unanimously.
Regarding the team membership list, Dale noted that Yukinori Saito has been unable to attend voting teleconferences due to his location in Japan, but would like to participate in the San Francisco F2F as a voting member. Dale will inquire with Karl Best about whether the team can make an exception to OASIS procedures.
At Dale's request, Arvola and Peter agreed to make presentation(s) at the F2F summarizing their recent schema changes. Dale encouraged them, along with Hima and Tony to coordinate.
Dale proposed to arbitrarily divide issues from the database among F2F participants to ensure that all issues are reviewed, with each participant being responsible for leading discussion of their group of issues. Of course, subject experts and people who have worked on particular issues are encouraged to review relevant issues too. Without exception, it was agreed that Dale and Tony would assign issues to participants along the lines of Dale's proposal.
Dale reported that Registry has already gone to a 2.0 version [without a 1.1 version] and that MSG is following suit, so he suggested that we number our next version 2.0. He noted that thanks to Arvola's work, we're in sync with MSG's forthcoming version 2.0 and suggested that significant changes in our specification merit a new major version number. Marty and Peter Ogden expressed agreement. Pallavi informed us that BP will have a 1.1 version.
Dale requested a volunteer to host teleconferences during February. He'd like to hear from someone by the end of January.
Dale told us that the discussion of enumerated values for Party identification (and similar items) has re-emerged, with the usual participants including Duane Nickull, Dick Brooks, and William Kammerer. Dale is waiting for OASIS to say whether or not they can take in schemes from other standards for identifying organizations and put them under OASIS URNs.
Tony reported that comments against CPPA version 1.02 will be accepted through Friday, and that version 1.03 will be distributed this coming weekend with major contributions from Arvola and Peter.
Tony led a triage discussion for issues with a NULL "target version" in the as follows database (in order of first appearance in the report he distributed on the list).
During that discussion [but reported here for visibility] we agreed that Arvola's table about use of a CPA with MSG should be incorporated in CPPA 1.1 as a normative appendix. Arvola agreed to submit it for version 1.04.
180: BPSS & CPP/A alignment issue: synchronous vs asynchronous flow of control
Pallavi indicated that the BPSS team isn't currently planning to do anything about this. Arvola doesn't expect BPSS to have a parameter saying whether an interaction is synchronous or asynchronous, so specifying that is left for CPPA. We don't have a retry count in the BusinessProcessCharacteristics element. Marty and Dale felt that the BPSS should have specific indications of retry counts where applicable, and that CPPA should not specify a retry count globally -- for now this is a BPSS issue, not a CPPA issue. The team agreed to create a separate version 2.0 issue regarding business level retry counts (depending on what the BPSS team does) and otherwise close this issue. Dale and Marty agreed that we should shift the syncReplyMode attribute from BusinessProcessCharacteristics to MessagingCharacteristics; Arvola agreed to make the change for the next version of the XSD.
167: Identify action for business Receipt Acknowledgment or Acceptance Acknowledgment
Arvola has proposed to use names like ReceiptAcknowledgement, AcceptanceAcknowledgement and Exception. We agreed this is a matter for version 1.1.
170: Synch and asynch override of the same action
Dale suggested that this could be done with the current schema if two different ServiceBinding elements are used; Arvola concurred, noting that this issue concerns the case where one ServiceBinding is used. Peter questioned whether there was a lot to be gained by not requiring two ServiceBinding elements in that case. Hima suggested the alternative of using different ActionBinding elements. We agreed to target this issue for version 1.1 and work out the solution.
183: Should CPA indicate agreement on honoring MSG's syncReply boolean?
We agreed to close this issue since it isn't needed for alignment with MSG.
184: Interpretation of MSG's syncReply boolean
We also agreed to close this issue since it isn't needed for alignment with MSG.
95: Lack of processing rules
We agreed to close this issue on the grounds that it's not applicable for CPPA.
53: Ambiguity re Routing of Response Messages to the Correct Software Entry Point
Arvola suspects that this issue has been superseded by the inclusion of a role under the to and from parties in MSG. Also the CPA has been significantly restructured for Service and Action. We agreed to review this question and verify whether it has indeed been resolved for version 1.1. Hima volunteered to review.
166: Multiple Packaging elements per ServiceBinding
This issue was resolved in version 1.01, where each ActionBinding has its own packaging.
168: Multiple schemas per SimplePart
Arvola believes this is taken care of. He will investigate and report at the F2F.
171: Should a SimplePart be reusable?
This issue was resolved in version 1.01, where SimplePart became reusable.
181: SimplePart should capture schema for payload as given in the messaging Manifest
This was accomplished in version 1.01
175: End-to-end encryption between persons/applications
Tony will close this issue since he's satisfied with the treatment in the current specification, particularly with respect to the confidentiality attribute of the BusinessProcessCharacteristics element. He will open a new issue to address Arvola's concern that the wording is too strong. [For differing viewpoints see the thread starting with http://lists.oasis-open.org/archives/ebxml-cppa/200201/msg00005.html]
Marty opined that when the confidentiality attribute is true, the MSH must not decrypt the message before persisting it. We agreed to target the new issue for version 1.1 and discuss it further at the F2F. Peter thought he'd propose three attributes instead of just confidentiality: secure transport, message privacy, and confidentiality (for what happens to the message after it leaves the MSH).
Marty proposed to define application as the place where the MSH deposits the message.
96: Key Management
We shifted this issue to version 2.0.
101: Super schema for CPP + CPA
We noted that this issue has already been deferred.
We agreed to target the revived party identification issue for version 1.1.
Considering the uncertainty surrounding future ebXML Technical Architecture work and the lack of an OASIS mechanism for committees to jointly publish specifications, we agreed to incorporate a glossary in our version 1.1. Marty suggested starting by pasting the glossary from the ebXML Trading Partners team's version 1.0 requirements document.
There will be another teleconference next week on January 17.