OASIS ebXML Collaboration Protocol Profile
and Agreement TC
Attendees
Arvola Chan, Tibco / RosettaNet
Aynur Ünal, E2open
Brian Hayes, Commerce One
Dale Moberg, Cyclone Commerce
Dan Gannon, Commerce One
David Smiley, Mercator (phone)
Himagiri Mukkamala, Sybase
James Bryce Clark, McLure Moynihan (phone)
Jean Zheng, Vitria
Kevin Liu, SAP
Marty Sachs, IBM
Neelakantan Kartha, Sterling Commerce (phone)
Nita Sharma, IONA
Pallavi Malu, Intel (phone)
Pete Wenzel, RosettaNet / SeeBeyond
Peter Ogden, Cyclone Commerce
Sinisa Zimek, SAP
Suresh Damodaran, Sterling Commerce (phone)
Tony Weida
Yukinori Saito, ECOM
Monday, October 1, 2001
Announcements
Dale called for volunteers to take on writing assignments for version 1.1, noting that Hima and Arvola have already volunteered for portions of the work.
Dale thanked SAP for their generosity in hosting our meeting.
Issues Triage
We reviewed each issue in the database and targeted most issues for version 1.1 or 2.0 (or later). In some cases, the decision was deferred pending discussions with other committees, particularly the joint meeting with the OASIS ebXML Messaging committee on Wednesday.
Tuesday, October 2, 2001
Inventory of Expressive Enhancements
The following list was projected and edited by Dale at the meeting:
Inventory of Potential 1.1 Expressive Enhancements (by XML Element)
1. CertificateRef usage, places where CertificateRef element can go such as TransportSecurity, (also TLS addition)
1.5 Authentication Basic & Digest
2. TrustAnchors and SecurityPolicy-where to go open.
3. Characteristics, and idref backpointers.
4. Sending & Receiving Protocol elements: Sending needs a connection to the signing function.
Subordination of element issue.
TransportSecurity may need to be related to both sending and receiving.
Sending may need a DocExchange section.
How about MDNs, DSNs (RosettaNet)5.SynchReplyMode and how to capture the cases in Packaging and Transport and also under DeliveryChannel Characteristics (for the DeliveryReceipt agreement, for example).
6. XMLDSIG URI references within the Packaging Element URI based "inclusion" or elsewhere.
7. RM related parameters
8.VIA support elements/parameters
9-10 Message/CPPA interactions. Security (SSL Client, CertificateRef changes)
Authentication issue
CertificateRef for SSL
Receiver and Sender.11. ebXMLBinding (or Packaging)
Home for SOAP Module functionality of ebXML Messaging CanUnderstand correlatives of MustUnderstand?
Regarding item 5, Dale would like to see a simple notation to describe channels and indicate contents Via packaging. He thinks this may call for a special task force under the messaging team. Hima, Dale, Brian, Jean, Arvola, and Tony will look into this matter. Hima suggested coming up with use cases, e.g., an acknowledgement coming back synchronously over an HTTP connection followed by a response coming back over SMTP.]
Marty raised an issue for version 2: is it time to add support for TLS as a non-proprietary alternative to SSL? Dale thought that would probably not be a problem if only used for HTTP, but other transport protocols such as SMTP would be more work.
Reliable Messaging
Marty gave a presentation on reliable messaging, available Via:
http://www.oasis-open.org/committees/ebxml-cppa/documents/rel_msg_overview.doc
Brian suggested defining what's acceptable processing by an intermediary and what's not.
Hima questioned whether acks should be signed. Marty responded that combining reliable messaging with NRR is likely to be "a disaster." Acks contains no business content.
Pete W. said that it seems impossible for the ultimate recipient to know if the originator has seen its ack. Tony noted a similar phenomenon with the NRR handshake.
Jamie proposed that when a message is delivered to the URL identified in a CPA, the message sender has fulfilled its commitment. He suggested that the receiver defines the endpoint, which may be outside the firewall, at an intermediary, etc. This view seemed to enjoy general agreement.
Dale asked: would we want to define a special CPA for the store-and-forward intermediary case? Marty answered that a standard CPA should handle that case. Dale wants to handle the intermediate case of a simple transport level agreement. Marty felt that the solution is to create a tri Via l BPSS for such agreements.
Brian described how Commerce One handles intermediaries. A sender uses a "logical" address - if the recipient is connected to the marketplace, the message is sent directly. Otherwise it's passed along Via routing tables (UDDI). We may want to specify acceptable intermediaries in a CPA due to criteria such as price or trusted ability to provide reliable messaging. Dale thought we might consider an extension of endpoint to specify a path over intermediaries. Marty reported that as an experiment, IBM wrote a tpaML agreement between two endpoints on the Ariba network just using Ariba addresses. Arvola opined that if both parties are clients of Ariba's network, it's sufficient for the first party to send messages to the Ariba address. However, Messaging committee people want to go all the way to receiving party. Marty suggested parties could get a contract with Ariba guaranteeing that Ariba will forward reliably.
The preceding discussion led to the following conclusion: we will lobby for transparent forwarding at most, or else full-scale ebXML node status for intermediates. Transparent forwarding means that intermediaries don't emit acks on their own and won't send an ack downstream until a corresponding ack is received from upstream.
David asked: why is a simple forwarding intermediary considered different from any other endpoint. Marty thinks such intermediaries need not be treated specially if they are committed to forwarding reliably.
Brian was not sure he's in agreement yet about when intermediaries are modeled and when they're not. For example, he wasn't convinced that a timestamp service en route must be an endpoint. In the case of a marketplace, Jamie said: if I'm buying a product but don't know who to buy from, then I'm doing business with the marketplace. Brian felt it was key to decide when an intermediary is really a business service and suggested that examples are needed.
Service and Action
Arvola pointed out that the messaging specification doesn't clearly specify how values for service and action are chosen. [Notes are unclear on the following point, but] Dale is looking for a version1.1 change: according to our version 1.0 specification, action values correspond with requesting/responding business activities...
Intermediaries
Brian gave a presentation on High-Level Use Cases for Intermediaries, available as:
http://www.oasis-open.org/committees/ebxml-cppa/documents/intermediaries-usecases.ppt
Via Element (Part 1 of 2)
We discussed the Via (messaging) element in preparation for our joint meeting with the Messaging committee. Arvola felt that if intermediaries are used for transparent forwarding, then there's no need for the Via element.
We talked about information in a CPA versus information in a message header. Dale asked why SyncReply is in the header, given that it doesn't vary from message to message. Arvola responded that [for a message] it could vary from hop to hop. Brian said that an intermediary mediates the difference from one hop to the next. According to Arvola, that's governed by agreements between each pair along the path.
Peter O. suggested that Via may be useful in version 2.0 for multi-party scenarios and allows for more dynamic routing.
Arvola proposed that the Messaging team should construct an example of a CPA between a from party and an intermediary to see if our existing schema is sufficient.
It was noted that according to the Messaging specification, the CPAId in Via overrides the CPAId in the message header. Tony commented that unless the intermediaries are all known and agreed to by the from and to parties, this poses a problem, e.g., an intermediary must not be allowed to override security (by using a CPAId that references message handling parameters contrary to what the from and to parties have agreed on).
Nita asked whether an intermediary could override policy and not send an ack. Dale thought not.
It was asked: what will the second CPAId do? Arvola thought reliable messaging parameters could be different, e.g. retries and retry interval. Marty felt that intermediaries shouldn't be retrying [on their own].
Dale mentioned that one could use an XML transform for those things that differ in the intermediary CPA. He stated that we must analyze what things in the intermediary CPA can differ from the end-to-end CPA and thought we might solicit help from Messaging. Marty thought that differences should be limited to things for the next hop - things the to party doesn't really care about.
Negotiation White Paper (Marty)
Marty gave a status report on the negotiation white paper, having electronically distributing a new version Monday night that was revised to account for all received comments. He requested comments on the latest version in the next two weeks. If substantive comments ensue, Marty will put out new version. Otherwise, he'll schedule sub-team calls to resolve issues and generate a requirements document. Marty's team at IBM is planning to bring forward a proposal for a negotiation protocol that we can choose to accept.
Via Element (Part 2 of 2)
We held a phone conversation with David Burdett regarding use of the Via element, especially its CPAId, Service and Action elements. He stated that the purpose of the Via element is to record information that varies from hop to hop. Via is populated even in the one hop case. The CPAID element references an existing agreement. Dale asked who fills in the Via element, for example in the case of a purchase order with one intermediary. David B. responded that the original sender does. He suggested that for re-use, we could have both transport level CPAs and business process CPAs that reference transport level CPAs. In particular, he raised the cases of marketplaces and communications hubs. Dale asked if there would there be a BPSS schema reference in a CPA with an intermediary.
David B. observed that an intermediary might need to change the reliable messaging method in order to forward a message. The question was asked: why isn't Via information stored at the hub; and not a concern of the messaging layer? David B. said that a sending app shouldn't have to know about intermediate hops after the first hop.
Peter O asked: is it appropriate to override any aspect of a CPA in a message header? David B. replied that Via just overrides messaging stuff independent of payload. Peter O. thought we should be explicit about what can/can't be overridden, for example ackRequested. Dale remarked that an intermediary should not ack back on its own, only when an ack is received from upstream. David B. cited the problem of two hops, e.g., A-B-C, where A-B is HTTP and B-C is SMTP. He suggested that an ack is for the next hop, whereas delivery receipt is for end to end. According to Arvola, most of the Messaging team thinks intermediary acks are desirable, but the CPPA team thinks they're too complex and prefers just end-to-end acks.
Jamie asked: what are the implications for a to party when receiving from an intermediary rather than directly? He feels the to party would like to be indifferent. David B. thought that would indeed be the case if the originator signs everything apart from Via. Jamie then asked: what about the inverse case - can I ignore anything not signed? David B. thought yes, though one might not want to.
Service and Action
We discussed where the name of a service comes from. Arvola quoted the CPPA spec line 1000 as saying "The value of the Service element is a string that SHALL be used as the value of the Service element in the ebXML Message Header[ebMS] or a similar element in the Message Header of an alternative message service." Tony responded that in contrast, according to line 758 of the Messaging spec, the provider of a service identifies the service name. Arvola thought we should be able to pick it out from a BPSS specification. Dale indicated that's what we aspire to; we should identify candidates in BPSS and worry about RosettaNet later - there is a problem of matching because RosettaNet uses complementary service names for two sides, whereas BPSS has one unified name.
Action item: we need to find candidate sources for the action attribute from BPSS. Hima suggested using a path expression; he will propose a sentence describing this.
Issue: we need to document how CPPA information goes into a messaging header. A conversation ID identifies all state information about the corresponding conversation, including what role a party is playing - that resolves ambiguity in case a party can play both roles in a given type of collaboration (e.g., buyer and seller).
Issue: Marty pointed out that in the current draft, section number 7.5.8.3 is followed by 7.4.7.4. Apparently just the section numbers are wrong; Tony W. will fix the problem.
Administration
Dale raised the question: should we allow any OASIS member to read our list? He noted that membership is not required in order to read the archive. We agreed to an affirmative answer without objection.
Several writing assignments were made:
Wednesday, October 3, 2001
Joint Meeting with Messaging Committee
Attendance for the joint meeting is recorded in David Fischer's minutes at:
http://lists.oasis-open.org/archives/ebxml-msg/200110/doc00006.doc
Messaging 1.1
David B. stated that the intent is to provide clarifications and bug fixes with no new functionality; the concentration will be on reliable messaging and intermediaries. The Messaging team will fix their plans in the next few days; in 3 weeks, a new version that reflects all changes can go out for review. Ian stated the intent to submit for the OASIS approval process by "early December."
Dale stated that the CPPA team needs a clear, shared understanding with Messaging in the area of intermediaries, reliable messaging and related matters -- this area is complicated, but we want people to implement and adopt ebXML, so we want to avoid special cases and complexities. He cited three possibilities:
David B. advocated viewing an intermediary as a "mail room" being operated by the toparty. Consider the analogy of a mailroom that signs certified mail receipts. Marty pointed out that the IBM mail room figures out how to deliver mail to his office without any help from the sender. Bob Miller noted one reason for an intermediary - to act as a gateway where part of the network is not ebXML. David Fischer thinks anything between to and from is a store-and-forward intermediary for version 1.1. Maybe the mailing room really is a router and should be out of scope for 1.1. Dale wants the mailroom to be the to. Then, David F. says everything beyond the mailroom is out of scope. David B. says the mailroom needs to preserve everything to do with the message, only one might want to change transport level stuff for the next hop. Thus Via . Otherwise, one must change the message header and potentially destroy a digital signature. Brian thought it matters where you define your business boundary in terms of the BPSS. David Smiley replied that from a business perspective "I tell my business partner where to send the message. The rest is in his business domain and literally his business. The onus is on him to provide all the other things that must be supported such as persisting the message. Dale remarked that in the POC, they left everything the same and just put the intermediary's URL in as the to party. David F. thought there should be one CPA for every hop and one for end-to-end. For that approach, Tony emphasized the importance of ensuring consistency between the end-to-end and intermediary CPAs. Dale stated that multiparty CPAs will be considered for CPPA version 2.0; multiple CPAs are the temporary working solution. Chris Ferris doesn't think we need Via . Dale agreed - it leads to too much complexity in the specs. Our protocol design is too complicated because we haven't stuck to peer-to-peer. David B. countered that it would be a lot of work for Messaging to take Via out; a lot of work for CPPA if it's left in. According to Dale, we'd need a clean explanation of how an intermediary draws its information from CPAs. He asked what would happen if we drop CPAId from Via ? David F. responded that we'd then drop Via , trace header list and one or the other ack. Dale observed that it would result in a simpler spec.
[Break.]
David B. suggested we could take CPAId out of Via , but say that values in Via override the CPA - a sending party (A) has to fill out the message as if they were ready to deliver it to the to party (C). However, since they are unable, they must send it to an intermediary (B). Problem: if negotiating a CPA between A and C, C will say send a message to "this" URL, but A can't - it has to send the message somewhere else. Is that just an implementation detail for the sending party? Doug commented that such an intermediary is slightly rewriting the CPA, exactly analogous to DNS routing tables. There's no one answer for sending to www.microsoft.com. It depends on where you are on the net. In the case of a marketplace, the sender doesn't know who's on the other end, just the intermediary. Chris commented that the intermediary is then clearly part of the business process. Dale asked if/when the intermediary is considered to be a full-fledged ebXML node. David B. suggested just putting Via information in the header without CPAId and ruling that header information overrides the CPA. Dale asked, if B can get a message to C based on its configuration info, why is the info needed in the header? David F. raised the case where A and C want to do SyncReply = true. How does B know? Doug proposed that the only reason for a full-blown CPAId at the Via level is for third party business functionality. Dale urged leaving that for later - show how to do it in BPSS.
David proposed that business process modeling be used for any new intermediary functions such as time stamping. That leaves only forwarding which must be taken care of in 1.1. David F. proposed that the Messaging group to take CPAId out of Via. Chris said it's already optional - why not leave it? He also said it's not clear that anything in Via works.
Issue: David B. thinks we need a ReliableMessagingMethod element under ebXML bindings.
Issue: Brian quoted Jim Clark as saying that synch reply doesn't come from BPSS -therefore to be removed?
After lunch, David Fischer moved as follows, both seconded by David Burdett:
Chris Ferris then moved to amend the first motion as follows:
Ian seconded Chris' amendment with additional support from Colleen and Jamie. David B. objected. The amendment passed with two abstentions.
David F.'s first motion was approved as amended: 10 yes, 1 abstention.
David F's second motion, amended by him as "Motion for version 1.1 to limit the described features and functions of intermediaries to forwarding only. This is a declaration of intent." was seconded by David Burdett and approved by a vote of 9 yes, 1 no, 2 abstentions.
Messaging and CPPA Issues
Dale led us in reviewing Arvola's table of "ebXML Message and CPP/A Specifications Issues that may require discussion in joint meeting" dated September 24, 2001 and posted in Arvola's message to the list:
http://lists.oasis-open.org/archives/ebxml-cppa/200109/msg00052.html
Please refer to that table for the context of the following notes.
MSG-2: For version 1.1, we've agreed to model the XML DSIG portion. Multiple signatures may be tricky.
MSG-4: This is not our charter; we'll help Messaging to identify what is needed.
MSG-5, CPPA-69: This is for our version 1.1. Dale stated that MSG must keep us posted. Ian stated that compression is out of scope for MSG version 1.1.
MSG-9: Chris questioned why this is a joint issue. Arvola noted the alternatives of signals only, signals and response, etc. Arvola asked if reliable messaging acks must be returned synchronously? Dale stated that the matter is complicated with respect to packaging schemes, etc., so this is potentially one of biggest changes we're taking on.
MSG-20, MSG-53, CPPA-49: Chris F. noted that TimeToLive is based on BPSS. Chris thinks it may be tied to the message, not the delivery channel. Dale remarked that we need MSG input here so we can verify that the CPPA specification is right.
MSG-26, MSG-51: We agreed to drop the third 'e'.
MSG-55: The "if" is to be discussed by MSG this week
MSG-72, CPPA-75, CPPA-83: Chris F. said that syncReplyMode is in the Via element and its purpose is to inform the intermediary. Arvola believes this requires mostly clarification on the part of the messaging spec. Dale suggested that we all reread both specs. David F. thinks the matter is already fixed.
MSG-74, CPPA-117: Chris and David F. both think this should be removed from the Messaging spec.
CPPA-23: A CPA is not going to be used with intermediaries, at least for our next version.
CPPA-47: David B. stated that this should be recorded in the CPPA spec. David F. agreed.
CPPA-54: Chris said "sure". According to Marty, it doesn't say so in the Messaging spec; it needs to be made clear that this is an acceptable use and should be a normative statement. There was consensus for a textual change in the Messaging spec.
CPPA-88: Arvola observed that this is mostly a CPPA issue.
CPPA-78, CPPA-90, CPPA-132: The Messaging group will work on it this week.
Service and Action (David Burdett)
David Burdett presented his paper posted on Oct. 2:
http://lists.oasis-open.org/archives/ebxml-cppa/200110/doc00001.doc
He also posted a subsequent revision:
http://lists.oasis-open.org/archives/ebxml-cppa/200110/doc00002.doc
Dale observed the need to ensure that request and response actions have different names; we should try to get all groups to agree to that convention. David B. agreed. Dale further noted that we'd like service name to be obtainable from the BPSS. Marty and Dan Weinreb agreed. There can be different service names on each side. Dale made an analogy from service and action to object and method in OOP. Issue (from Marty): the service name sent to another party must be the one that's meaningful to the other side. Dan said that each service has a namespace of actions. Doug thought that service identification is through a hierarchy: CPAId / to service / action. We seemed to have consensus on that point. Marty felt that BPSS must have appropriate uniqueness of its names.
We considered the RosettaNet "Request Purchase Order" transaction and discussed naming of actions - is it the action you are doing or the action you are invoking on the other side, i.e., "Request PO" or "confirm PO"? According to Marty, the BPSS specification says that for an action you should use the name of the requesting business activity. Tony noted that the names are derived from the request-confirm pattern. There was general consensus that when requesting, the action name is the name of the requesting business activity, and when responding, the name of the responding business activity.
We talked about adding role (perhaps as an element) to the message header along with service and action. Chris wanted to put it under from, to make it clear. He thinks we'll need from and to roles when we get into multiparty scenarios.
Tony felt that service names should be unique per service provider and that it should be possible to compose services from more than one BPSS instance. He noted that the BPSS team is focused on defining business collaborations and processes, not necessarily services. Chris F. thought that a service can only (now) point to one BPSS.
Metadata
Please send additions and corrections to Tony Weida (rweida@hotmail.com).
Respectfully submitted,
Tony Weida