OASIS ebXML Collaboration Protocol Profile and Agreement TC
ebXML CPPA Technical Committee Teleconference
November 15, 2001
Dale pointed out that he sent a message to the list yesterday about developments at the MSG team's F2F.
Marty stated that the negotiation team will hold a conference call next Wednesday, 3:00 - 4:00 pm Eastern (USA) time.
Dale mentioned a proposed compromise that could reduce or eliminate ongoing efforts to allow message header contents to override aspects of a CPA. He considers it important to avoid such overrides. For details, see:
Several header elements have been eliminated: TraceHeadersList,DeliveryReceipt and DeliveryReceiptRequested. The Via element became SyncReply [formerly an attribute within Via].
David Burdett's reverse path issue was deferred until version 2.0.
In a major decision, the version 1.1 specification will preclude spontaneous communication without prior agreement - there must be either an explicit CPA or a suitable system configuration, i.e. a virtual CPA. In the latter case, Brian suggested guideline text pointing out that there is an implied CPA. Marty agreed, saying that CPPA had been trying to prevail on that point for a year. Brian noted that if there's no keyword for "implied CPA" or "none" then one can't do an "off contract" spot buy or asynchronous freight tracking request with FedEx.
The MSG committee has agreed on a strong recommendation that MSG implementers should read and understand the implications of the CPPA spec.
The proposition that CPPA parameters should override any conflicting message header parameters was voted down. The question of whether message parameters should be allowed to override CPPA parameters was deferred until the next day of the meeting.
Marty commented that the preclusion of spontaneous communication without prior agreement for version 1.1 should mean that message header parameters do not conflict with the CPPA - nothing should appear in both places. Dale replied that MSG does in fact have things like ackRequested, which should also be in the CPA to support agreements about reliable messaging. Dale said that MSG agreed on the second day that any message header conflicts with the CPA would generate errors, and that discussion of dynamically overriding CPAs will be eliminated. Marty agreed that was reasonable. Dale pointed out the consequence that it's now possible for parties to "agree to not agree" [up front]. Thongs like duplicate elimination could therefore be specified in the CPA as per message. In response to a query from Marty, Dale expressed doubts about implementability of that facility.
We discussed a family of use cases such as an application that uses reliable messaging for amounts over (say) $10,000, and not otherwise. Several people expressed doubt that anyone will want such uses cases in practice. Dale, Marty and Brian agreed that separate business processes could be used instead. Still, Dale wants us to be able to align with whatever MSG decides. Marty expressed concern that allowing per-message choices in the message header will increase the perceived and actual complexity of ebXML specifications, to the detriment of their acceptance. Dale responded that while some MSG members agree, that view didn't prevail. Jamie was concerned (1) that the MSG group was interested in specifying matters within the purview of CPPA, and (2) that they were inclined to put things in the message header as a matter of implementation expedience. He suggested that it would be reasonable for CPPA to either decide not to conform on the grounds that it's out of scope, or (Jamie's preference) say that we're accommodating MSG for compatibility purposes but at the same time deprecate such usage. It was noted that MSG owes us a list of affected dynamic items such as ackRequested. Dale recommended that we all review Section 11.4 of the MSG spec, version 1.08, for our next teleconference. David will send that version to our list.
The MSG committee adopted a proposal from Chris Ferris that the value of TimeToLive in the message header, if present, must be less than the timestamp found in the message header plus the PersistDuration found in the CPA (or equivalent configuration information).
Marty expressed several concerns about MSG timing parameters, but MSG representatives seem to feel that they've been successfully resolved.
The period for internal MSG TC comments ends today or tomorrow. The public comment period will start on January 1. Nonetheless, Dale recommended sending comments to MSG ASAP. David Fischer offered to receive and post comments from those who can't post directly to the MSG list.
The MSG committee has discussed all issues in their database and reached resolutions.
Dale reported that a MIME header problem [not otherwise described] was resolved for purposes of 1.1 - Arvola elaborated that Chris has a motion to identify the risk in the spec and outline possible countermeasures, and Jim Galvin will prepare text.
Marty expected that the messaging service would put packages together, while Hima noted that the ebXML MSG committee decided yesterday not to provide for packaging in their spec. Dale commented that other aspects of a messaging service (beyond the MSG spec) could still provide for packaging. In that case, however, Hima observed that it doesn't make sense for the CPPA spec to have DigitalEnvelope under ebXMLBinding. Hima suggested another subdivision of DocExchange to cover such things. Dale and Marty felt that was beyond the scope of version 1.1.
Hima remarked that Service names must be unique across the CPA, but we don't state that fact. Dale responded that we had talked about obtaining the value from the BPSS. Brian noted there isn't any Service element per se in BPSS. He contrasted possible definitions of Service as (1) a software entity that processes documents or (2) performing a service such as processing an order or performing a price check. In the latter case, you can just use the Transaction from BPSS. We discussed the idea that hierarchical naming would be needed since a transaction can be reused in BPSS. There seemed to be some consensus for giving services consistent, logical names (e.g., what BPSS or transaction within a BPSS is supported) that are shared by both parties to a CPA. Brian felt that we should be able to agree on how to extract such names from a BPSS. Hima suggested discussing that at the next BPSS conference.
We will not meet next week. The next teleconference will take place the following week, on November 29.