OASIS ebXML Collaboration Protocol Profile and Agreement TC
ebXML CPPA Technical Committee Teleconference
September 20, 2001
David Fischer (guest)
Grandfathering of ebXML 1.0 specs
Dale told us that he'd raised the question of grandfathering the approved ebXML 1.0 specifications at OASIS and reported Karl Best's response that there is no avenue for grandfathering and that the established OASIS process should be followed, starting with submission of specifications by the technical committees. Dale reminded us that we've already voted not to pursue that process. While we could take grandfathering up with other OASIS people, considering the lobbying effort and politics involved, Dale prefers to focus for now on preparation for the F2F. He suggested that we could reconsider the matter at the F2 if anyone is interested.
We discussed the potential impact of corporate travel restrictions on the upcoming F2F. It doesn't seem to be a widespread problem, although several people may have to dial in rather than traveling. Also, the Messaging committee is apparently going ahead with their co-located meeting. Dale will try to structure the agenda so that people can dial in for topics of particular interest. He expects that messaging-related issues will take highest priority for version 1.1, followed by BPSS issues and use of Service and Action. Everyone is urged to reconfirm travel reservations.
Arvola reported a fair amount of list traffic on RM and whether end-to-end transmission should be specified. He asked if version 1.1 would deal with forwarding intermediaries appropriately. Dale distinguished between two cases: forwarding intermediaries, where a CPA isn't needed, and multiparty cases, which is in the scope of version 2.0. He opined that the approach taken in the proof-of-concept demo is probably sufficient for forwarding intermediaries (the intermediary is only involved in the CPA as a transport endpoint). Arvola questioned whether that made the Via (messaging) element unnecessary. Dale responded that it wasn't necessary for the forwarding case, and would be used at the discretion of the originating MSH. Our commitment is to support the endpoint mechanism, and exactly what else is needed is unclear. We may recommend that CPA software check the coherence of values given for timeouts, retries, etc. According to Tim, that assumes the same security and transport on both sides of the intermediary. Dale said we're assuming that the intermediary doesn't alter packaging and security - to the extent that the Via element or the TraceHeaderList impacts such things, it will be reflected in an agreement. Regarding the question of whether the intermediary can pass through transport level security info (specifically about how to handle the certificates if the intermediary has HTTPS on one side and SMTP on the other side), Marty suspects we're into a multiparty situation. Jamie questioned whether the Via element could potentially thwart the policy intentions of a party if it resulted in changed messaging settings. Dale recalled "case 1.5" of a forwarding intermediary that restructures or re-encapsulates the message/payload in some manner - a CPA may be needed then. Tim proposed acknowledging that such cases exist but are not supported for 1.1. David stated that the Messaging committee considers intermediaries out of scope for their version 1.1. Jamie asked if an intermediary is considered to be a pure forwarder bound to respect the CPA between two end parties; we then discussed advantages of keeping CPA content technical in nature from the standpoint of expediting agreement and implementation. Tim asked about how non-repudiation and error propagation happen with intermediaries. We discussed that some errors may come from the endpoint and others from an intermediary, and David (?) thought that in any case they're just ebXML messages. Arvola asked if an intermediary would have to identify itself as the end party if it's not explicitly identified in the CPA.
Tim doesn't know of new issues since last week
Jamie noted that the UN/CEFACT ebTWG now has about 15 proposals to sort out.
More than one prospective core components group has come forward. It seems almost certain that one or more panels will inherit BPSS. There has been vigorous discussion on the role of UML modeling in the BP work.
Nothing new to report.
Version 1.1 Authoring
Dale noted that Hima has volunteered for the version 1.1 authoring team. He called for volunteers to express interest in participating by emailing either him or the list.
Further Discussion of Messaging
Returning to intermediaries, Dale asked if we need to get into the "case 1.5" area. Marty felt that even the forwarding function goes beyond the domain of the messaging service and that the Messaging committee should just make end-to-end messaging working for their version 1.1. Dale felt that focusing on forwarding would be fine, but the messaging group is unlikely to reach consensus on "gateways" by December so that our team would be able to address that by January. Jamie suggested that as a short-term solution, a principal could wholly turn over the reins to the intermediary who enters into a CPA, then signs and responds (etc.) on behalf of the principal.
Dale indicated that someone should focus on laying out messaging issues at the F2F; Arvola agreed to do some research and make a presentation.
Marty thinks the relation between reliable messaging and intermediary issues is the main problem. David Fischer mentioned that the messaging team has agreed not to do end-to-end reliable messaging in the case of intermediaries. Marty stated that there are two things needed for reliable messaging: once-and-only-once delivery and guaranteed notification to the from application if the message could not be sent -- which is more complicated when intermediaries are introduced. Marty noted that if all hops use ebXML messaging, then it may be simply a matter of stating that each intermediary must be able to forward reliably, but difficulties may occur if other protocols are used. Dale proposed requiring that before any forwarding intermediary sends an ack it must receive an ack on the other side. Marty considered that an outstanding idea, since that enables a chain of MSHs to demonstrate persistence at the to MSH. In that case, Dale agreed there's no need for rollback of an "optimistic" ack. David asked why not do an end-to-end ack in that case, which Dale though might be equivalent. Dale believes that more involved intermediaries such as a "signing MSH" should be modeled in the business process. David mentioned the possible need for the from MSH to retry and asked what happens with duplicate messages when intermediaries do duplicate detection. According to Arvola, if it's stipulated that none of the intermediaries do duplicate detection or implement reliable messaging, then end-to-end should work fine. Jamie asked if it's realistic to identify some such basic principles for discussion with the Messaging committee. Peter suggested that the current MSH is well suited to point-to-point communication, but perhaps intermediate hops, end-to-end communication, and reliable messaging would be better placed in another layer above the MSH. With reference to layering, Jamie expressed surprise at how RosettaNet had recently moved their business signals into the MSH layer.
Dale announced that dial-in lines would be available at the F2F. Anyone who expects to call in is urged to notify Dale to that effect.
There will be a non-voting meeting next week on Thursday, September 27, 11:00 am - 12:00 pm Eastern time (USA).