OASIS ebXML Collaboration Protocol Profile and Agreement TC
ebXML CPPA Technical Committee Teleconference
October 11, 2001
Minutes for 9/27 teleconference were approved.
Dale asked for updates to the membership list, and said he will accept email updates for a period of time.
Dale asked for volunteers to serve as liasons to Joint Committee within OASIS that coordinates efforts across ebXML TCs and related groups. This group will take up such issues as whether we should spin off an Architecture TC. Aynur Unal (not present on this call) had previously volunteered and Brian Hayes did too. So they will be JC liason members to the ebXML JC.
Hima, who is already the liason from the IIC TC to CPPA TC, volunteered to be the liason from CPPA to IIC, in addition to his heading up version 1.1 improvements related to BP and CPPA alignment on service and action values.
Submitted an initial position document for review by CPPA. MSG team added a new to/from element, which will reference collaboration role name already present. Brian Hayes asked about relation between role and security (i.e., does receiver need to ensure that role specified in a message is valid for the signature). Marty stated that role is really intended to facilitate routing of the message to the appropriate application "entry point".
Security (Dale for Tim C.)
Dale has a new proposal to address security risk issues and SSL client issues. A draft of the proposal is being prepared. A high level overview is that our current certifcateRefs and certificate (ds:KeyInfo) approach is incomplete; for example, we don't have enough stuff in them to support trust anchors. Proposes to add a new securityRef element, which would point to a either a certRef or a securityDetails element. This new element would contain a new subtree containing new elements, such as trust anchors, security policy, and certificate usage (and wihin it, CertificateRefs as needed.) Marty Sachs pointed out that he might want to continue to use both certificateRef with securityRefs. Dale agreed that this would probably be useful.
Dale will be sending out the proposal as soon as he gets it finished.
Arvola discussed his proposal for the interpretation of synchronous reply mode. Currently, three modes: signals only, signals and response, response only. There was some discussion about the case where the responder requests a receipt acknowledgment from the sender and whether or not that message would be sent over a new connection. Moberg mentioned that "pipelining" (i.e., multiple back-forth message exchanges over the same HTTP connection) is supported in 1.1, but not often used. Dale suggested looking at the scope of this proposal, it will probably be usefule to revisit the way we've linked together transports, packaging.
Distributed updated whitepaper during F2F, no feedback yet. Beginning in November, will start conference calls to pare down the list of things we're going to tackle for the first version of the Negotiation spec.
6-7 participants showing up daily to BPSS F2F meetings. Feedback, especially from tool vendor(s), has been valuable WRT to the "usability" of the BPSS spec. There was some discussion about schedule alignment between the BPSS 1.1 effort and the CPPA/MSG v1.1 efforts. Brian believed that they could have a new maintenance version available for the first quarter of 2002, along with CPPA's version 1.1.
MSG F2F highlights:
CPAId removed from VIA element.
MSG has moved to a "modular" approach using SOAP modules ("Must Understand" blocks in envelope header). If one end can't understand, a SOAP fault is thrown.
Dale noted that corresponding to these MustUnderstand modules, there could be in CPPs, a listing of CanUnderstand modules. Their presence could facilitate configuration-time agreement on what modules are to be employed at runtime. Dale thought that avoiding SOAP faults in advance, by means of agreeing on modules, is to be preferred over just letting runtimes report errors.
But Dale was also concerned that this may be too ambitious to get done. Marty asked whether this should be part of the packaging element in CPPA; Dale suggested the ebXML binding element. The advantages and disadvantages of various placements needs further study. Arvola not sure whether this is too much to handle, waiting to see proposal from MSG (David F.), which is to be done on Friday. (Editor's Note: a version was sent to list Friday.)
Side discussion on CPA schema: Marty pointed out that currently, CPA DTD/Schema allows 0 or more signatures on the CPA. Understands that there will never be more than three (one for each party, and one for a "notary"), but that due to limitations in DTD this was not specifiable. Suggested that now that we've dropped the DTD, we should change cardinality of this element in schema to be 0-3. Chan will update schema accordingly.
Discussion of intermediary retries occurred, but notes are insufficient to reconstruct. Probably nothing definitive was resolved on this one!