Collaboration-Protocol Profile and Agreement Specification ...68 conducting electronic business. Another target audience is the people in each enterprise who are 69 responsible for

ebXML Trading-Partners Team 2 March, 2001

Collaboration-Protocol Profile and Agreement Page 1 of 74Copyright © ebXML 2001. All Rights Reserved.

Collaboration-Protocol Profile and AgreementSpecificationVersion 0.911

ebXML Trading-Partners Team

03/02/01 3:54 PM

1 Status of this Document

This Document specifies an ebXML WORK IN PROGRESS for the eBusiness community.

Distribution of this Document is unlimited.

The Document formatting is based on the Internet Society’s Standard RFC format.

This version:http://www.ebxml.org/project_teams/trade_partner/private/cpa-cpp-spec-0.91-qr.doc

Latest version:

http://www.ebxml.org/project_teams/trade_partner/private/cpa-cpp-spec-0.91-qr.doc

Previous version:

http:// http://www.ebxml.org/project_teams/trade_partner/private/cpa-cpp-spec-0.9-qr.doc



2 ebXML participantsThe authors wish to recognize the following for their significant participation to the developmentof this Document.

David Burdett, CommerceOneTim Chiou, United World Chinese Commercial BankChris Ferris, SunScott Hinkelman, IBMMaryann Hondo, IBMSam Hunting, ECOM XMLJohn Ibbotson, IBMKenji Itoh, JASTPRORavi Kacker, eXcelon Corp.Thomas Limanek, iPlanetDaniel Ling, VCHEQHenry Lowe, OMGDale Moberg, Sterling CommerceDuane Nickull, XMLGlobal TechnologiesStefano Pogliani, SunRebecca Reed, MercatorKarsten Riemer, SunMarty Sachs, IBMYukinori Saito, ECOMTony Weida, Edifecs



3 Table of Contents1 Status of this Document ........................................................................................................................................ 12 ebXML participants .............................................................................................................................................. 23 Table of Contents .................................................................................................................................................. 34 Introduction........................................................................................................................................................... 5

4.1 Summary of Contents of Document .................................................................................................................... 54.2 Document Conventions ....................................................................................................................................... 54.3 Definitions........................................................................................................................................................... 64.4 Audience ............................................................................................................................................................. 64.5 Assumptions........................................................................................................................................................ 64.6 Related Documents ............................................................................................................................................. 6

5 Design Objectives ................................................................................................................................................. 86 System Overview .................................................................................................................................................. 9

6.1 What This Specification Does............................................................................................................................. 96.2 Forming a CPA from Two CPPs....................................................................................................................... 106.3 How the CPA Works........................................................................................................................................ 136.4 Where the CPA May Be Implemented.............................................................................................................. 136.5 Definition and Scope......................................................................................................................................... 14

7 CPP Definition .................................................................................................................................................... 157.1 CPP Structure.................................................................................................................................................... 157.2 PartyInfo Element ............................................................................................................................................. 16

7.2.1 PartyId element .......................................................................................................................................... 177.2.2 PartyRef element........................................................................................................................................ 187.2.3 CollaborationRole element......................................................................................................................... 197.2.4 ProcessSpecification Element .................................................................................................................... 207.2.5 Role element .............................................................................................................................................. 217.2.6 ServiceBinding element ............................................................................................................................. 227.2.7 Override element........................................................................................................................................ 227.2.8 Certificate element ..................................................................................................................................... 237.2.9 DeliveryChannel element........................................................................................................................... 247.2.10 Characteristics element ............................................................................................................................ 257.2.11 Transport element..................................................................................................................................... 267.2.12 Transport Protocol and Version ............................................................................................................... 277.2.13 Endpoint Element..................................................................................................................................... 277.2.14 Transport Protocols .................................................................................................................................. 277.2.15 Transport Security.................................................................................................................................... 29

7.3 DocExchange element....................................................................................................................................... 307.3.1 docExchangeId attribute............................................................................................................................. 307.3.2 ebXMLBinding element............................................................................................................................. 317.3.3 version attribute.......................................................................................................................................... 317.3.4 MessageEncoding element......................................................................................................................... 317.3.5 ReliableMessaging element........................................................................................................................ 317.3.6 NonRepudiation element............................................................................................................................ 337.3.7 DigitalEnvelope element ............................................................................................................................ 347.3.8 Namespaces Supported .............................................................................................................................. 34

7.4 ds:Signature element ......................................................................................................................................... 347.5 Comment element ............................................................................................................................................. 35

8 CPA Definition ................................................................................................................................................... 368.1 CPA Structure ................................................................................................................................................... 368.2 CollaborationProtocolAgreement element ........................................................................................................ 368.3 CPAType element ............................................................................................................................................. 378.4 Status element ................................................................................................................................................... 388.5 CPA Lifetime .................................................................................................................................................... 38



8.5.1 Start element .............................................................................................................................................. 388.5.2 End element................................................................................................................................................ 38

8.6 ConversationConstraints element...................................................................................................................... 398.6.1 invocationLimit attribute............................................................................................................................ 398.6.2 concurrentConversations attribute.............................................................................................................. 39

8.7 PartyInfo element .............................................................................................................................................. 408.7.1 ProcessSpecification element..................................................................................................................... 40

8.8 ds:Signature element ......................................................................................................................................... 408.8.1 Persistent Digital Signature........................................................................................................................ 41

8.9 Comment element ............................................................................................................................................. 428.10 Security Considerations for the CPA .............................................................................................................. 428.11 Composing a CPA from Two CPPs ................................................................................................................ 42

8.11.1 ID Attribute Duplication .......................................................................................................................... 428.12 Modifying Parameters of the Process Specification Document Based on Information in the CPA ................ 43

9 References........................................................................................................................................................... 4410 Disclaimer ....................................................................................................................................................... 46Contact Information .................................................................................................................................................... 47Copyright Statement ................................................................................................................................................... 48Appendix A Example of CPP Document (Non-normative)........................................................................................ 49Appendix B Example of CPA Document (Non-normative) ........................................................................................ 51Appendix C DTD Corresponding to Complete CPP/CPA Definition (Normative)................................................... 55Appendix D XML Schema Document Corresponding to Complete CPA Definition (Normative)............................. 58Appendix E Formats of Information in the CPP and CPA (Normative)..................................................................... 65Appendix F Composing a CPA from Two CPPs (Non-Normative) ........................................................................... 66Appendix G Mapping of CPA Constructs to ebXML Message Header (Normative) ................................................. 74



4 Introduction1

2

4.1 Summary of Contents of Document3

4As defined in the ebXML Business-Process Model [BPMSPEC], a Business Partner is an entity5that engages in Business Transactions with another Business Partner(s). Each Partner's6capabilities (both commercial/business and technical) to engage in electronic Message exchanges7with other Partners MAY be described by a Document called a Trading-Partner Profile (TPP).8The agreed interactions between two Partners MAY be documented in a Document called a9Trading-Partner Agreement (TPA). A TPA MAY be created by computing the intersection of the10two Partners' TPPs.11

12The message-exchange capabilities of a Party MAY be described by a Collaboration-Protocol13Profile (CPP) within the TPP. The message-exchange agreement between two Parties MAY be14described by a Collaboration-Protocol Agreement (CPA) within the TPA. Included in the CPP15and CPA are details of transport, Messaging, security constraints, and bindings to a Process-16Specification Document that contains the definition of the interactions between the two Parties17while engaging in a specified electronic business process.18

19This specification is a draft standard for trial implementation. This specification contains the20detailed definitions of the Collaboration Protocol Profile (CPP) and the Collaboration Protocol21Agreement (CPA).22

23This specification is a component of the suite of ebXML specifications. An overview of the24ebXML specifications and their interrelations can be found in [TECHARCH].25

26This specification is organized as follows:27

• Section 5 defines the objectives of this specification.28• Section 6 provides a system overview.29• Section 7 contains the definition of the CPP, identifying the structure and all30

necessary fields.31• Section 8 contains the definition of the CPA.32• The appendices include examples of XML CPP and CPA Documents, the DTD, an33

XML Schema Document equivalent to the DTD, formats of information in the CPP34and CPA, Composing a CPA from two CPPs, and the mapping of CPA constructs to35fields in the ebXML Header Document [MSSPEC].36

37

4.2 Document Conventions38

Terms in Italics are defined in the ebXML Glossary of Terms [EBXMLGLOSS]. Terms listed in39Bold Italics represent the element and/or attribute content of the XML CPP or CPA definitions.40

41In this specification, indented paragraphs beginning with "NOTE:" provide non-normative42



explanations or suggestions that are not required by the standard.4344

References to external Documents are represented with BLOCK text enclosed in brackets, e.g.45[RFC2396]. The references are listed in Section 9, "References".46

47The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD48NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this Document, are to be49interpreted as described in [RFC 2119].50

51NOTE: Vendors should carefully consider support of "optional" elements, i.e. those with52cardinalities (0 or 1) or (0 or more). Support of such an element means that the element is53processed appropriately for its defined function and not just recognized and ignored. A54given Party MAY use these elements in some CPPs or CPAs and not in others. Some of55these elements define parameters or operating modes and should be implemented by all56vendors. It may be appropriate to implement optional elements that represent major run-57time functions, such as various alternative communication protocols or security functions,58by means of plug-ins so that a given Party may acquire only the needed functions rather59than having to install all of them.60

61

4.3 Definitions62

Technical terms in this specification are defined in the ebXML Glossary [EBXMLGLOSS].6364

4.4 Audience65

One target audience for this specification is implementers of ebXML services and other66designers and developers of middleware and application software that is to be used for67conducting electronic business. Another target audience is the people in each enterprise who are68responsible for creating CPPs and CPAs.69

70

4.5 Assumptions71

It is expected that the reader has an understanding of [XML] and is familiar with the concepts of72electronic business (e-business).73

74

4.6 Related Documents75

Related Documents include ebXML Specifications on the following topics:76• ebXML Technical Architecture Specification [TECHARCH]77• ebXML Message Service Specification [MSSPEC]78• ebXML Business Process Specification Schema [BPMSPEC]79• ebXML Glossary [EBXMLGLOSS]80• ebXML Core Components Specification [EBXMLCC]81• ebXML Registry and Repository Specification [REGREP]82• ebXML Glossary [EBXMLGLOSS]83

84See Section 9 for the complete list of references.85



86



5 Design Objectives87

The objective of this specification is to ensure interoperability between two Parties even though88they may procure application software and run-time support software from different vendors.89The CPA defines the way two Parties will interact in performing the chosen collaborative90process. Both Parties SHALL use identical copies of the CPA to configure their run-time91systems. This assures that they are compatibly configured to exchange messages whether or not92they have obtained their run-time systems from the same vendor. The configuration process93MAY be automated by means of a suitable tool that reads the CPA and performs the94configuration process.95

96It is an objective of this specification that a CPA SHALL be capable of being composed by97intersecting the respective CPPs of the Parties involved. The resulting CPA SHALL contain98only those elements that are in common, or compatible, between the two parties. Variable99parameters, such as number of retries of errors, are then negotiated between the two Parties. The100design of the CPP and CPA schemata facilitates this composition/negotiation process. However,101the composition and negotatiation processes themselves are outside the scope of this102specification.103



6 System Overview104

6.1 What This Specification Does105

The exchange of information between two Parties requires each Party to know the other Party's106supported Collaborative Processes, the other Party's role in the Collaborative Process, and the107technology details about how the other Party sends and receives messages. In some cases, it is108necessary for the two Parties to reach agreement on some of the details.109

110The way each Party can exchange information, in the context of a Collaborative Process, can be111described by a Collaboration-Protocol Profile (CPP). The agreement between the Parties can be112expressed as a Collaboration-Protocol Agreement (CPA)113

114To enable Parties wishing to do business to find other Parties that are suitable Business115Partners, CPPs MAY be stored in a repository such as is provided by the ebXML Registry and116Repository[REGREP]. Using a discovery process provided as part of the specifications of a117repository, a Party MAY then use the facilities of the repository to find Business Partners.118

119The document that defines the interactions between two Parties is an [XML] document called a120Process-Specification Document that conforms to the ebXML Business Process Specification121Schema specification [BPMSPEC]. The CPP and CPA include references to this Process122Specification Document. The Process-Specification Document may also be stored in a repository123such as the ebXMP Registry and Repository.124

125Figure 1 illustrates the relationships between a CPP and two Process-Specification Documents in126

F ig u re 1 : S tru ctu re of C P P & B u sin ess P rocess S p ecificatio n inR ep ository

R e po sitory

B u sinessco llab o ra tio n

pro to co l

< P arty Info P a r ty Id = “ N 0 1” > < P ro cessS p ec ifica tio n x lin k:h ref= “ h ttp :/ /

< P a rty Info P a r ty Id = “ N 0 2” > < P ro cessS p ec ifica tio n x lin k:h ref= “ h ttp :/ /

C P P (A )

P rocess S p ecif ica tion (A 1 )

P rocess S p ecif ica tion (A 2 )

B u sinessco llab o ra tio n

pro to co l



an ebXML registry. On the left is a CPP that includes information about two parts of an127enterprise that are represented as different Parties. On the right are shown two Process-128Specification Documents. Each of the PartyInfo elements in the CPP contains an XML xlink129reference to one of the Process-Specification Documents.130

131This specification defines the markup language vocabulary for creating electronic CPPs and132CPAs. CPPs and CPAs are [XML] Documents. In the appendices of this specification are a133sample CPP, a sample CPA, the DTD, and the corresponding XML Schema Document.134

135The CPP describes the capabilities of an individual Party. A CPA describes the capabilites that136two Parties have agreed to use to perform a particular business process. Like the Trading-137Partner Agreements used in Electronic Data Interchange (EDI), these CPAs define the138"information technology terms and conditions" that enable Business Documents to be139electronically interchanged between Partners. However, these CPAs are not paper Documents.140Rather, they are electronic documents that can be processed by computers at the Partners' sites141in order to set up and then execute the desired business information exchanges. The "legal" terms142and conditions of a business agreement are outside the scope of this specification and therefore143are not included in the CPP and CPA.144

145In general, the Parties to a CPA can have both client and server characteristics. A client requests146services and a server provides services to the Party requesting services. In some applications,147one Party only requests services and one Party only provides services. These applications have148some resemblance to traditional client-server applications. In other applications, each Party may149request services of the other.150

151

6.2 Forming a CPA from Two CPPs152

This section summarizes the process of discovering a Party to do business with and forming a153CPA from the two Parties' CPPs. See Appendix F "Composing a CPA from Two CPPs (Non-154Normative)" for more information.155

156Figure 2 illustrates forming a CPP. Party A tabulates the information to be placed in a157repository for the discovery process, constructs a CPP that contains this information, and enters158it into an ebXML Repository.159

160



161In figure 3, Party A and Party B use their CPPs to construct a CPA by calculating the162intersection of the information in their CPPs. The resulting CPA defines how the two parties will163behave in performing their collaborative process.164

165Figure 4 illustrates the entire process. The steps are listed at the left.166

Figure 2: Overview of Collaboration-Protocol Profiles(CPP)

What BusinessCapabilitiesIt“CAN DO”When conductingBusiness Processwith other parties

Party A

Party’s information- Party name- contact infoTransport ProtocolTransport Security ProtocolMessaging ProtocolLink to Process-Specification documentTime out/Retry-etc.

CPP

(Example of CPP)

Describe Build

Figure 3, Overview of Collaboration-Protocol Agreements(CPA)

CPA IDParty’s information- Party A- Party BTransport ProtocolTransport Security PDocExchange ProtocolLink to Process-Specification Doc.Time out/Retry-etc.

CPPFor

Party-A

CPPFor

Party-B

CPA

AgreedCPA

AgreedCPA

1

negotiate

2

negotiate

3Agree-ment onCPA hasarrived.

3

Agree-ment onCPA hasarrived.

4 Start Business activities with each other



167

Figure 4: Overview of W orking Architecture of CPP/CPA withRepository

Repository

Company B(Buyer,Server)

Company A(Seller,Server)

CPP(A)

CPP(B)

CPP(X)

CPP(Y)

CPP(Z)

CPP(A)CPA(A,B)CPA(A,B)

(Document)(Exe. Code)

CPA(A,B)CPA(A,B)

(Document)(Exe. Code)

1. Any company may register itsCPPs to a Repository.

2. Company B discovers tradingpartner A (Seller) by searchingCPPs in the Repository anddownloads CPP(A) to Company-B’sserver.

3. Company B makes CPA(A,B) andsends CPA(A,B) to Company A .

4. Companies A and B negotiate andstore identical copies of thecom pleted CPA as a document inboth servers. This process is donemanually or automatically.

5. Companies A and B configuretheir runtime systems with theinformation in the CPA.

6. Do Business (e.g. submit purchaseorders)

2.6.

5.

5.

3.4.

1.

1.



6.3 How the CPA Works168

A CPA describes all the valid visible, and hence enforceable, interactions between the Parties169and the way these interactions are carried out. It is independent of the internal processes executed170at each Party. Each Party executes its own internal processes and interfaces them with the171Collaborative Process described by the CPA. The CPA does not expose details of a Party's172internal processes to the other Party. The intent of the CPA is to provide a high-level173specification that can be easily comprehended by humans and yet is precise enough for174enforcement by computers.175

176The CPA and the Process-Specification Document that it references define a Conversation177between the two Parties. The Conversation represents a single unit of business as defined by the178Binary-Collaboration component of the Process-Specification Document. The Conversation179consists of one or more Business Transactions, each of which is a request Message from one180Party and a response Message from the other Party. The Process-Specification Document181defines, among other things, the request and response Messages for each Business Transaction182and the order in which the Business Transactions are required to occur.183

184The CPA MAY actually reference more than one Process-Specification Document. When a CPA185references more than one Process-Specification Document, each Process-Specification186Document defines a distinct type of Conversation. Any one Conversation involves only a single187Process-Specification Document.188

189A new Conversation is started each time a new unit of business is started. The business process190also determines when the Conversation ends. From the viewpoint of a CPA between Party 1 and191Party 2, the Conversation starts at Party 1 when Party 1 sends the first request Message to Party1922. At Party 2, the Conversation starts when it receives the first request of the unit of business193from Party 1. A Conversation ends when the Parties have completed the unit of business.194

195NOTE: An implementation SHOULD provide means for the Process-Specification196implementation to signal to the runtime software that a Conversation is ended.197

198NOTE: The runtime system MAY provide an interface by which the business application199requests initiation and ending of Conversations.200

201

6.4 Where the CPA May Be Implemented202

Conceptually, the CPA and Process-Specification Document are implemented by a business to203business (B2B) server at each Party's site. The B2B server provides the code for the services204needed to support the CPA. This code includes the middleware that supports communication205with the other Party, execution of the functions specified in the CPA, interfacing to each Party's206back-end processes, and logging the interactions between the Parties for purposes such as audit207and recovery. The middleware might support the concept of a long-running Conversation as the208embodiment of a single unit of business between the Parties. To configure the two Parties'209systems for business to business operations, the information in the copy of the CPA and Process-210Specification Documents at each Party's site is installed in the runtime system. The static211information MAY be recorded in a local database and other information in the CPA and Process-212



Specification Document MAY be used in generating or customizing the necessary code to213support the CPA.214

215NOTE: It is possible to provide a graphic CPP/CPA-authoring tool that understands both216the semantics of the CPP/CPA and the XML syntax. Equally important, the definitions in217this specification make it feasible to automatically generate, at each Party's site, the code218needed to execute the CPA, enforce its rules, and interface with the Party's back-end219processes.220

221

6.5 Definition and Scope222

223This specification defines and explains the contents of the CPP and CPA XML Documents. Its224scope is limited to these definitions. It does not define how to compose a CPA from two CPPs225nor does it define anything related to run-time support for the CPP and CPA. It does include226some non-normative suggestions and recommendations regarding run-time support where these227notes serve to clarify the CPP and CPA definitions.228



7 CPP Definition229

A CPP defines the capabilities of a Party to engage in electronic business with other Parties.230These capabilities include both "technology" capabilities such as supported communication and231Messaging protocols, and "business capabilities" in terms of what business processes it supports.232This section defines and discusses the details in the CPP in terms of the individual XML233elements. The discussion is illustrated with some XML fragments and reference should be made234to the DTD and sample CPP in the appendices.235

236The ProcessSpecification, DeliveryChannel, DocExchange, and Transport elements of the237CPP describe the processing of a unit of business (Conversation). These elements form a238layered structure somewhat analogous to a layered communication model. The remainder of this239section describes both the above-mentioned elements and the corresponding run-time processing.240

241Process-Specification layer - The Process-Specification layer defines the heart of the business242agreement between the Parties: the services (Business Transactions) which Parties to the CPA243can request of each other and transition rules that determine the order of requests. This layer is244defined by the separate Process-Specification Document that is referenced by the CPP and CPA.245

246Delivery Channels - A delivery channel describes a Party's Message-receiving characteristics. It247consists of one Document-exchange definition and one transport definition. Several delivery248channels can be defined in one CPP.249

250Document-Exchange layer - The Document-Exchange layer accepts a business document from251the Process-Specification layer at one Party, encrypts it if specified, adds a digital signature for252nonrepudiation if specified, and passes it to the transport layer for transmission to the other253Party. It performs the inverse steps for received Messages. The options selected for the254Document-Exchange layer are complementary to those selected for the Transport layer. For255example, if Message security is desired and the selected transport protocol does not provide256Message encryption then it must be specified at the Document-Exchange layer. The protocol for257exchanging Messages between two Parties is defined by the ebXML Messaging Service258Specification [MSSPEC] or other similar Messaging service.259

260Transport layer - The transport layer is responsible for Message delivery using the selected261transport protocol. The selected protocol affects the choices selected for the Document-262Exchange layer. For example, some transport-layer protocols may provide encryption and263authentication while others have no such facility.264

265It should be understood that the functional layers encompassed by the CPP have no266understanding of the contents of the payload of the business Documents.267

268

7.1 CPP Structure269

270



This section describes the overall structure of the CPP. Unless otherwise noted, CPP elements271MUST be in the order shown here. Subsequent sections describe each of the elements in greater272detail.273

274<CollaborationProtocolProfile275

xmlns="http://www.ebxml.org/namespaces/tradePartner"276xmlns:bpm="http://www.ebxml.org/namespaces/businessProcess"277xmlns:ds="http://www.w3.org/2000/09/xmldsig#"278xmlns:xlink="http://www.w3.org/1999/xlink">279<PartyInfo> 280...281

</PartyInfo>282<ds:Signature> 283...284</ds:Signature>285<Comment>text</Comment> 286</CollaborationProtocolProfile>287

2887.1.1.1 CollaborationProtocolPr ofile element289The CollaborationProtocolProfile element is the root element of the CPP XML Document. The290REQUIRED [XML] Namespace [XMLNS] declarations for the basic Document are as follows:291

• The default namespace: xmlns="http://www.ebxml.org/namespaces/tradePartner"292• the Busines Process Model namespace:293

xmlns:bpm="http://www.ebxml.org/namespaces/businessProcess",294• XML Digital Signature namespace:295

xmlns:ds="http://www.w3.org/2000/09/xmldsig#",296• and the XLINK namespace: xmlns:xlink="http://www.w3.org/1999/xlink".297

298The CollaborationProtocolProfile element SHALL consist of the following child elements:299

• One or more REQUIRED PartyInfo elements that identify the organization (or parts300of the organization) whose capabilities are described by the CPP.301

• Zero or one ds:Signature elements that contain the digital signature that signs the302CPP Document.303

• Zero or more Comment elements.304305

A CPP document MAY be digitally signed so as to provide for a means of ensuring that the306Document has not been altered (integrity) and to provide for a means of authenticating the author307of the Document. A digitally signed CPP SHALL be signed using technology that conforms to308the joint W3C/IETF XML Digital Signature specification [XMLDSIG].309

310

7.2 PartyInfo Element311

The PartyInfo element identifies the organization whose capabilities are described in this CPP312and includes all the details about this Party. More than one PartyInfo element may be provided313in a CPP if the organization chooses to represent itself as subdivisions with different314characteristics. Each of the subelements of PartyInfo is discussed later. The overall structure of315the PartyInfo element is as follows:316

317<PartyInfo>318

<PartyId> 319



...320</PartyId>321<PartyRef>322...323</PartyRef>324<CollaborationRole> 325

...326</CollaborationRole>327<Certificate> 328

...329</Certificate>330<DeliveryChannel> 331...332</DeliveryChannel>333<Transport> 334...335</Transport>336<DocExchange> 337...338</DocExchange>339

</PartyInfo>340341

The PartyInfo element consists of the following child elements:342• One or more REQUIRED PartyId elements that provide a logical identifier for the343

organization.344• A REQUIRED PartyRef element that provides a pointer to more information about345

the Party.346• One or more REQUIRED CollaborationRole elements that identify the roles that this347

Party can play in the context of a Process Specification.348• One or more REQUIRED Certificate elements that identify the certificates used by349

this Party in security functions.350• One or more REQUIRED DeliveryChannel elements that define the characteristics of351

each delivery channel that the Party can use to receive Messages. It includes both the352transport level (e.g. HTTP) and the messaging protocol (e.g. ebXML Message353Service).354

• One or more REQUIRED Transport elements that define the characteristics of the355transport protocol(s) that the Party can support to receive messages.356

• One or more REQUIRED DocExchange elements that define the Message-exchange357characteristics, such as the Message-exchange protocol, that the Party can support.358

359

7.2.1 PartyId element360

361The REQUIRED PartyId element provides a logical identifier that MAY be used to logically362identify the Party. Additional PartyId elements MAY be present so as to provide for alternative363logical identifiers for the Party. This permits a large organization, for example, to have different364identifiers for different purposes. The value of the PartyId element is any string that provides a365unique identifier. The identifier MAY be any identifier that is understood by both Parties to a366CPA. Typically, the identifier would be listed in a well-known directory such as DUNS or in any367naming system specified by [ISO6523].368

369The PartyId element has a single attribute: type that has a string value.370



371If the type attribute is present, then it provides a scope or namespace for the content of the372PartyId element.373

374If the type attribute is not present, the content of the PartyId element MUST be a URI that375conforms to [RFC2396]. It is RECOMMENDED that the value of the type attribute be an URN376that defines a namespace for the value of the PartyId element. Typically, the URN would be377registered as a well-known directory of organization identifiers.378

379The following example illustrates two URI references.380

381<PartyId type = "uriReference">urn:duns.com:duns:1234567890123</PartyId>382<PartyId type = "uriReference">urn:www.example.com</PartyId>383

384The first example is the URN for the Party's DUNS number, assuming that Dun and Bradstreet385has registered an URN for DUNS numbers with the Internet Assigned Numbers Authority. The386last field is the DUNS number of the organization.387

388The second example shows an arbitrary URN. This might be a URN that the Party has389registered with the Internet Assigned Numbers Authority (IANA) to identify itself directly.390

391

7.2.2 PartyRef element392

393The PartyRef element provides a link, in the form of a URI, to additional information about the394Party. Typically, this would be the URL from which the information can be obtained. The395information might be at the Party's web site or in a publicly accessible repository such as an396ebXML repository, a UDDI repository, or an LDAP directory. Information available at that URI397MAY include contact names, addresses, and phone numbers, and perhaps more information398about the business processes that it supports. This information MAY be in the form of an399ebXML Core Component [EBXMLCC]. It is not within the scope of this specification to define400the content or format of the information at that URI.401

402An example of the PartyRef element is:403

404<PartyRef xlink:type="simple"405

xlink:href="http://example2.com/example.com"/>406407

The PartyRef element is an [XLINK] simple link. It has two attributes as follows:408• a REQUIRED xlink:type attribute409• a REQUIRED xlink:href attribute410

4117.2.2.1 xlink:type attribute412The xlink:type attribute SHALL have a FIXED value of 'simple'. This identifies the element as413being an [XLINK] simple link.414

4157.2.2.2 xlink:href attribute416The REQUIRED xlink:href attribute SHALL have a value that is an URI that conforms to417



[RFC2396] that identifies the location of the external information about the Party.418419

7.2.3 CollaborationRole eleme nt420

<CollaborationRole id="N11" >421<CertificateRef certId = "N03">422<ProcessSpecification name="BuySell" version="1.0" xlink:href="..."/>423<Role name="buyer" xlink:href="..."/>424425<ServiceBinding name="some process" channelId="N02">426

427<Override action="OrderAck" channelId="N05"428

xlink:type="locator"429xlink:href="..."/>430

</ServiceBinding>431432<ServiceBinding channelId="N04">433

<Override action="OrderAck" channelId="N05"434xlink:type="locator"435

xlink:href="..."/>436</ServiceBinding>437

</CollaborationRole>438439

The CollaborationRole element associates a Party with a specific role in the Business Process440that is defined in the Process-Specification Document. Generally, the Process Specification is441defined in terms of roles such as "buyer" and "seller". The association between a specific Party442and the role(s) it is capable of fulfilling within the context of a Process Specification is defined443in both the CPP and CPA documents. In a CPP, the CollaborationRole element identifies which444role the Party is capable of playing in each Process Specification referenced by the CPP.445

446The CollaborationRole element SHALL consist of a CertificateRef element, a447ProcessSpecification element, a Role element and one or more ServiceBinding child elements.448The CertificateRef element identifies the certificate to be used. The ProcessSpecification449element identifies the Business Process that is described in the Process-Specification450Document that defines such role. The Role element identifies which role the Party is capable of451supporting. Each ServiceBinding element provides a binding of the role to a default452DeliveryChannel. The default DeliveryChannel describes the receive properties of all Message453traffic that is to be received by the Party within the context of the role in the identified Process-454Specification Document. Alternative DeliveryChannels may be specified for specific purposes,455using Override elements as described below.456

457When there are more than one ServiceBinding child elements of a CollaborationRole, then the458order of the ServiceBinding elements SHALL be treated as signifying the Party's preference459starting with highest and working towards lowest. The default delivery channel for a given460Process Dis the delivery channel identified by the highest-preference ServiceBinding element461that references the particular Process-Specification document.462.463

NOTE: When a CPA is composed, only ServiceBinding elements that are compatible464between the two Parties are retained. Each Party has a default delivery channel for each465Process Specification Document referenced in the CPA. For each Process-Specification466Document, the default delivery channel for each Party is the delivery channel that is467



indicated by the channelId attribute in the highest-preference ServiceBinding element468that references that Process-Specification Document.469

470NOTE: The ServiceBinding preferences are applied in choosing the highest-preference471delivery channels that are compatible between the two Parties when composing a CPA.472

473NOTE: An implementation MAY provide the capability of dynamically assigning474delivery channels on a per Message basis during performance of the Process475Specification. The delivery channel selected would be chosen, based on present476conditions, from those identified by ServiceBinding elements that refer to the Process477Specification that is sending the Message. If more than one delivery channel is478applicable, the one referred to by the highest-preference ServiceBinding element is used.479

480The CollaborationRole element has the following attribute:481

• A REQUIRED roleId attribute,482483

7.2.3.1 id attribute484The REQUIRED id attribute is an [XML] ID attribute by which this CollaborationRole element485can be referenced from elsewhere in the CPP document.486

4877.2.3.2 CertificateRef element488The CertificateRef element contains an IDREF attribute, certId that identifies the certificate to489be used by referring to the Certificate element (under PartyInfo) that has the matching ID490attribute value.491

4927.2.3.3 certId attribute493The certId attribute is an [XML] IDREF that associates the CollaborationRole with a494Certificate.495

496NOTE: This certID attribute relates to the authorizing role in the Process Specification497while the certificates identified in the delivery-channel description relate to Message498exchanges.499

500

7.2.4 ProcessSpecification Ele ment501

The ProcessSpecification element provides the link to the Process-Specification Document that502defines the interactions between the two Parties. This document is prepared in accord with the503ebXML Business Process Specification Schema specification [BPMSPEC]. The Process-504Specification Document MAY be kept in an ebXML Repository.505

506More than one ProcessSpecification element MAY be provided in a CPP Document so that a507Party can indicate its capability for performing multiple Business Brocesses. The syntax is as508follows:509

510<ProcessSpecification version="1.0" name="Buy and Sell"511

xlink:type="locator"512xlink:href="http://www.ebxml.org/services/purchasing.xml"/>513



514The ProcessSpecification element has the following attributes:515

• a REQUIRED name attribute,516• a version attribute,517• a FIXED xlink:type attribute,518• a REQUIRED xlink:href attribute.519

5207.2.4.1 name attribute521The value of the name attribute is the name of the role and is matched to the corresponding role522name in the Process-Specification Document.523

5247.2.4.2 version attribute525The ProcessSpecification element MAY include a version attribute to identify the version of the526Process-Specification Document that is referenced by the xlink:href attribute.527

5287.2.4.3 xlink:type attribute529The xlink:type attribute has a FIXED value of 'locator'. This identifies the element as being an530[XLINK] locator.531

5327.2.4.4 xlink:href attribute533The REQUIRED xlink:href attribute SHALL have a value that is an URI that conforms to534[RFC2396]. It identifies the location of the element or attribute within the Process Specification535that defines the role in the context of the business process.536

537

7.2.5 Role element538

The REQUIRED Role element identifies which role in the Process Specification the Party is539capable of supporting via the ServiceBinding element(s) siblings within this CollaborationRole540element.541

542The Role element has three attributes as follows:543

• a REQUIRED name attribute,544• a FIXED xlink:type attribute,545• a REQUIRED xlink:href attribute.546

5477.2.5.1 name attribute548The REQUIRED name attribute is a string that gives a name to the Role. Its value is taken from549one of the following sources in the Process Specification [BPMSPEC] that is referenced by the550ProcessSpecification element depending upon which element is the "root" (highest order) of the551process referenced:552

• initiator attribute of the binary-collaboration element553• responder attribute of the binary-collaboration element554• from attribute of the business-transaction-activity element555• to attribute of the business-transaction-activity element556• from attribute of the collaboration-activity element557• to attribute of the collaboration-activity element558



• name attribute of the business-partner-role element559560


5647.2.5.3 xlink:href attribute565The REQUIRED xlink:href attribute SHALL have a value that identifies the Process-566Specification Document and is an URI that conforms to [RFC2396].567

568

7.2.6 ServiceBinding element569

570The ServiceBinding element identifies a DeliveryChannel element for all of the Message traffic571that is to be sent to the Party within the context of the identified Process-Specification572Document. An example of the ServiceBinding element is:573

574<ServiceBinding name="SomeProcess" channelId="X03"/>575

576The ServiceBinding element MAY have zero or more Override child elements. Each Override577element SHALL specify a different DeliveryChannel for selected Messages that are to be578received by the Party in the context of the Process Specification that is associated with the parent579ServiceBinding element.580

581The ServiceBinding element has three attributes as follows:582

• a REQUIRED name attribute,583• a REQUIRED channelId attribute.584

5857.2.6.1 name attribute586The value of the name attribute is a string value that labels the ServiceBinding element. The587value of the Name attribute SHALL be used as the value of the Service element in an ebXML588Message-Header Document.589

5907.2.6.2 channelId attribute591The channelId attribute is an [XML] IDREF that identifies the DeliveryChannel that SHALL592provide a default technical binding for all of the message traffic that is received for the Process593Specification that is referenced by the ProcessSpecification element.594

7.2.7 Override element595

The Override element provides a Party with the ability to map, or bind, a different596DeliveryChannel to selected Messages that are to be received by the Party within the context of597the parent ServiceBinding element.598The Override element has the following attributes:599

• a REQUIRED action attribute,600• a REQUIRED channelId attribute,601• a FIXED xlink:type attribute,602• an xlink:href attribute603



604Under a given ServiceBinding element, there SHALL be only one Override element whose605action attribute has a given value.606

607NOTE: It is possible that when a CPA is composed from two CPPs, a delivery channel in608one CPP with an Override element will not be compatible with the other Party. This609incompatibility must be resolved either by negotiation or by reverting to a compatible default610delivery channel.611

6127.2.7.1 action attribute613The REQUIRED action attribute is a string that identifies the message that is to be associated614with the DeliveryChannel that is identified by the channelId attribute. The value of the action615attribute MUST match the corresponding request or response element/attribute in the Process-616Specification Document that is referenced by the ProcessSpecification element.617

6187.2.7.2 channelId attribute619The REQUIRED channelId attribute is an [XML] IDREF that identifies the DeliveryChannel620element that is to be associated with the Message that is identified by the action attribute.621


6267.2.7.4 xlink:href attribute627The xlink:href attribute MAY be present. If present, it SHALL provide an absolute [XPointer]628URI expression that specifically identifies the business-transaction within the associated629Process-Specification Document [BPMSPEC] that is identified by the ProcessSpecification630element.631

632

7.2.8 Certificate element633

634The Certificate element defines certificate information for use in this CPP. One or more635certificates may be defined for use in the various security functions in the CPP. An example of636the Certificate element is:637

638<Certificate certId = "N03">639

<ds:KeyInfo>. . .</ds:KeyInfo>640</Certificate>641

642The Certificate element has a single REQUIRED attribute: certId. The Certificate element has a643single child element: ds:KeyInfo.644

6457.2.8.1 certId attribute646The certId attribute is an ID attribute. Its is referred to in a CertificateRef element, using an647IDREF attribute, where a certificate is specified elsewhere in the CPP. For example:648

649<CertificateRef certId = "N03"/>650



6517.2.8.2 ds:KeyInfo element652The ds:KeyInfo element defines the certificate information. The content of this element and any653subelements are defined by the XML Digital Signature specification [XMLDSIG].654

655NOTE: Software for creation of CPPs and CPAs may recognize the ds:KeyInfo element656and insert the subelement structure necessary to define the certificate.657

658

7.2.9 DeliveryChannel elemen t659

A delivery channel is a combination of a Transport element and a DocExchange element that660describes the Party's Message-receiving characteristics. The CPP SHALL contain one or more661DeliveryChannel elements, one or more Transport elements, and one or more DocExchange662elements. Each delivery channel can refer to any combination of a DocExchange element and a663Transport element. The same DocExchange element or the same Transport element can be664referred to by more than one delivery channel. Two delivery channels may use the same665transport protocol and the same document-exchange protocol and differ only in details such as666communication addresses or security definitions. The following figure illustrates three delivery667channels.668

669The delivery channels have ID attributes with values "DC1", "DC2", and "DC3". Each delivery670channel contains one transport definition and one document-exchange definition. Each transport671definition and each document-exchange definition also has a name as shown.672

673A specific delivery channel may be associated with each ServiceBinding element or Override674element (Action attribute). Following is the delivery-channel syntax.675

676<DeliveryChannel channelId="N04" transportId="N05" docExchangeId="N06">677

<Characteristics678nonrepudiationOfOrigin = "true"679nonrepudiationOfReceipt = "true"680

D e l i v e r y C h a n n e lD C 1

T r a n s p o r tT 1

D o c . E x c h .D 1



D o c . E x c h .D 2



D o c . E x c h .I D = D 3



secureTransport = "true"681confidentiality = "true"682authenticated = "true"683authorized = "true"/>684

</DeliveryChannel>685686

Each DeliveryChannel element identifies one Transport element and one DocExchange element687that make up a single delivery channel definition.688

689The DeliveryChannel element has the following attributes:690

• A REQUIRED channelId attribute691• A REQUIRED transportId attribute692• A REQUIRED docExchangeId attribute693

694The DeliveryChannel element has one required child element, Characteristics.695

6967.2.9.1 channelId attribute697The ChannelId element is an [XML] ID attribute that uniquely identifies the DeliveryChannel698element for reference, using ID REF attributes, from other parts of the CPP or CPA.699

7007.2.9.2 transportId attribute701The transportId attribute is an [XML] IDREF that identifies the Transport element that defines702the transport characteristics of the delivery channel. It MUST have a value that is equal to the703value of a transportId attribute of a Transport element elsewhere within the CPP Document.704

7057.2.9.3 docExchangeId attribute706The docExchangeId attribute is an [XML] IDREF that identifies the DocExchange element that707defines the Document-exchange characteristics of the delivery channel. It MUST have a value708that is equal to the value of a docExchangeId attribute of a DocExchange element elsewhere709within the CPP Document.710

711

7.2.10 Characteristics element712

The Characteristics element describes the security characteristics provided by the delivery713channel. The Characteristics element has the following attributes:714

• a nonrepudiationOfOrigin attribute715• a nonrepudiationOfReceipt attribute716• a secureTransport attribute717• a confidentiality attribute718• an authenticated attribute719• an authorized attribute720

7217.2.10.1 nonrepudiationOfOrigin attribute722The nonrepudiationOfOrigin attribute is a Boolean with possible values "true" and "false". If723the value is "true" then the delivery channel REQUIRES the message to be digitally signed by724the certificate of the Party that sent the message.725

726



7.2.10.2 nonrepudiationOfReceip t attribute727The nonrepudiationOfReceipt attribute is a Boolean with possible values of "true" and "false".728If the value is "true" then the delivery channel REQUIRES that the message be acknowledged by729a digitally signed message, signed by the certificate of the Party that received the message, that730includes the digest of the message being acknowledged.731

7327.2.10.3 secureTransport attribute733The secureTransport attribute is a Boolean with possible values "true" and "false". If the value734is "true" then it indicates that the delivery channel uses a secure transport protocol such as [SSL]735or [IPSEC].736

7377.2.10.4 confidentiality attribute738The confidentiality attribute is a Boolean with possible values "true" and "false". If the value is739"true" then it indicates that the delivery channel REQUIRES that the message be encrypted in a740persistent manner. It MUST be encrypted above the level of the transport and delivered,741encrypted, to the application.742

7437.2.10.5 authenticated attribute744The authenticated attribute is a Boolean with possible values "true" and "false". If the value is745"true" then it indicates that the delivery channel REQUIRES that the sender of the message be746authenticated before delivery to the application.747

7487.2.10.6 authorized attribute749The authorized attribute is a Boolean with possible of values "true" and "false". If the value is750"true" then it indicates that the delivery channel REQUIRES that the sender of the message be751authorized before delivery to the application.752

753

7.2.11 Transport element754

The Transport element of the CPP defines the Party's capabilities with regard to communication755protocol, encoding, and transport security information.756

757The overall structure of the Transport element is as follows:758

759<Transport transportId = "N05">760

761<Protocol version = "1.1">HTTP</Protocol>762763<Endpoint uri="http://example.com/servlet/ebxmlhandler"764

type = "request"/>765<TransportSecurity> 766

<Protocol version = "3.0">SSL</Protocol>767<CertificateRef certId = "N03"/>768

</TransportSecurity>769</Transport>770

7717.2.11.1 TransportId attribute772The Transport element has a single REQUIRED transportId attribute, of type [XML] ID, that773provides a unique identifier for each Transport element, which SHALL be referred to by the774



transportId IDREF attribute in a DeliveryChannel element elsewhere within the CPP or CPA775document.776

777

7.2.12 Transport Protocol and Version778

Supported communication protocols are HTTP, SMTP, and FTP. The CPP can specify as many779protocols as the Party is capable of supporting. The Version attribute identifies the specific780version of the protocol.781

782NOTE: It is the aim of this specification to enable any transport capable of carrying783MIME content to be described using the vocabulary defined herein.784

785

7.2.13 Endpoint Element786

The uri attribute of the Endpoint element specifies the Party's communication addressing787information. One or more Endpoint elements SHALL be provided for each Transport element in788order to provide different addresses for different purposes. The value of the uri attribute is an789URI that contains the electronic address of the Party in the form required for the selected790protocol. The value of the uri attribute SHALL conform to the syntax for expressing URIs as791defined in [RFC2396].792

793The type attribute identifies the purpose of this endpoint. The value of type is an enumeration;794permissible values are "login", "request", "response", "error", and "allPurpose". There can be, at795most, one of each. The type attribute MAY be omitted. If it is omitted, its value defaults to796"allPurpose". The "login" endpoint MAY be used for the address for the initial Message between797the two Parties. The "request" and "response" endpoints are used for request and response798Messages, respectively. The "error" endpoint MAY be used as the address for error messages799issued by the Messaging service. If no "error" endpoint is defined, these error messages SHALL800be sent to the "response" address, if defined, or to the "allPurpose" endpoint. To enable error801Messages to be received, each Transport element SHALL contain at least one endpoint of type802"error", "response", or "allPurpose".803

804

7.2.14 Transport Protocols805

In the following sections, we discuss the specific details of each supported transport protocol.806807

7.2.14.1 HTTP808HTTP is Hypertext Transfer Protocol [HTTP]. For HTTP, the address is an URI that SHALL809conform to [RFC2396]. Depending on the application, there MAY be one or more endpoints,810whose use is determined by the application.811

812Following is an example of an HTTP endpoint:813

814<Endpoint uri="http://example.com/servlet/ebxmlhandler"815

type = "request"/>816817



The request and response endpoints MAY be dynamically overridden for a particular818request or asynchronous response by application-specified URIs exchanged in business819Documents exchanged under the CPA.820

821For a synchronous response, the response endpoint is ignored if present. A synchronous822response is always returned on the existing connection, i.e. to the URI that is identified as the823source of the connection.824

8257.2.14.2 SMTP826SMTP is Simple Mail Transfer Protocol[SMTP]. For use with this standard, Multipurpose827Internet Mail Extensions [MIME] MUST be supported. The MIME media type used by the828SMTP transport layer is Application with a sub-type of octet-stream.829

830For SMTP, the communication address is the fully qualified mail address of the destination Party831as defined by [RFC822]. Following is an example of an SMTP endpoint:832

833<Endpoint uri="mailto:[email protected]"834


SMTP with MIME automatically encodes or decodes the Document as required, on a link-by-837link basis, and presents the decoded Document to the destination document-exchange function. If838the application design is such that the choices in the DocumentExchange element and the839ProcessSpecification element are intended to be independent of the choice of transport protocol,840it is permissible to specify a MessageEncoding element under the DocExchange element.841

842NOTE: The SMTP mail transfer agent encodes binary data (i.e. data that are not 7-bit843ASCII) unless it is aware that the upper level (mail user agent) has already encoded the844data. If the data are encoded in the document-exchange level (MessageEncoding), the845information that the data are already encoded SHOULD be passed to the mail user agent.846

847NOTE: SMTP by itself (without any authentication or encryption) is subject to denial of848service and masquerading by unknown Parties. It is strongly suggested that those849Partners who choose SMTP as their transport layer also choose a suitable means of850encryption and authentication either in the document-exchange layer or in the transport851layer (S/MIME).852

853NOTE: SMTP is an asynchronous protocol that does not guarantee a particular quality of854service. A transport-layer acknowledgment (i.e. an SMTP acknowledgment) to the855receipt of a mail Message constitutes an assertion on the part of the SMTP server that it856knows how to deliver the mail Message and will attempt to do so at some point in the857future. However, the Message is not hardened and may never be delivered to the858recipient. Furthermore, the sender will see a transport-layer acknowledgment only from859the nearest node. If the Message passes through intermediate nodes, SMTP does not860provide an end-to-end acknowledgment. Therefore receipt of an SMTP861acknowledgement does not guarantee that the Message will be delivered to the862application and failure to receive an SMTP acknowledgment is not evidence that the863Message was not delivered. It is recommended that the reliable Messaging protocol in864



the ebXML Messaging Service be used with SMTP.865866

7.2.14.3 FTP867868

[FTP is File Transfer Protocol [FTP].869870

Since a delivery channel specifies receive characteristics, Each Party sends a Message using FTP871PUT. The endpoint specifies the user id and input directory path (for PUTs to this Party). An872example of an FTP endpoint is:873

874<Endpoint uri="ftp://[email protected]"875


NOTE: It is assumed that the FTP implementation will automatically set transfer type878(binary or ASCII), passive mode if needed, and passive mode control port number if needed.879

880

7.2.15 Transport Security881

The TransportSecurity element provides the Party's security specifications for the transport882layer of the CPP. It may be omitted if transport security will not be used for any CPAs883composed from this CPP. Unless otherwise specified below, transport security applies to884Messages in both directions.885

886Following is the syntax:887

888<TransportSecurity>889

<Protocol version = "3.0">SSL</Protocol>890<CertificateRef certId = "N03"/>891

</TransportSecurity>892893894

7.2.15.1 Protocol element895The value of the Protocol element can identify any transport security protocol that the Party is896prepared to support. The version attribute identifies the version of the specified protocol.897

898The specific security properties depend on the services provided by the identified protocol. For899example, SSL performs certificate-based encryption and certificate-based authentication.900

9017.2.15.2 CertificateRef element902The REQUIRED CertificateRef element contains an ID REF attribute, certId that identifies the903certificate to be used by referring to the Certificate element (under PartyInfo) that has the904matching ID attribute value.905

9067.2.15.3 Specifics for HTTP907For encryption with HTTP, the protocol is SSL[SSL] (Secure Socket Layer) Version 3.0, which908uses public-key encryption.909

910Authentication of the client to the server may be either by password or by certificate. Certificate911



authentication is SSL version 3.0. If each Party may act as a server at times and a client at other912times, the CPA must specify certificates for both Parties.913

914The password algorithm is HTTPAuthentication. The server presents a certificate to the client915that authenticates the server. The client uses that certificate to encrypt the password. If each916Party may act as a client at times and as a server at other times, the CPA must specify password917authentication and certificate authentication for both Parties.918

919

7.3 DocExchange element920

The DocExchange element provides information that the Parties must agree on regarding921exchange of Documents between them. This information includes the Messaging service922properties (e.g. ebXML Messaging Service[MSSPEC]).923

924Following is the structure of the DocExchange element of the CPP. Subsequent sections925describe each child element in greater detail.926

927<DocExchange docExchangeId = "N06">928

<ebXMLBinding version = "0.92">929<MessageEncoding> 930...931</MessageEncoding>932<ReliableMessaging> 933...934</ReliableMessaging>935<NonRepudiation> 936

...937</NonRepudiation>938<DigitalEnvelope> 939

...940</DigitalEnvelope>941<NamespaceSupported> 942

...943</NamespaceSupported>944

</ebXMLBinding>945</DocExchange>946

947The DocExchange element of the CPP defines the properties of the Messaging service to be948used with CPAs composed from the CPP.949

950The DocExchange element is comprised of a single ebXMLBinding child element.951

952NOTE: The document-exchange section can be extended to other Messaging services by953adding additional xxxBinding elements that describe the other services.954

955

7.3.1 docExchangeId attribute956

The DocExchange element has a single docExchangeId attribute that is an [XML] ID that957provides an unique identifier which may be referenced from elsewhere within the CPP958document.959

960



7.3.2 ebXMLBinding element961

The ebXMLBinding element describes properties specific to the ebXML Message Service962[MSSPEC] The ebXMLBinding element is comprised of the following child elements:963

• Zero or one MessageEncoding element which specifies how Messages are to be964encoded by the document-exchange layer.965

• Zero or one ReliableMessaging element which specifies the characteristics of reliable966Messaging.967

• Zero or one NonRepudiation element which specifies the requirements for signing968the Message.969

• Zero or one DigitalEnvelope element which specifies the requirements for encryption970by the digital-envelope[DIGENV] method.971

• Zero or more NamespaceSupported elementswhich identify any namespace972extensions supported by the Messaging service implementation.973

974

7.3.3 version attribute975

The ebXMLBinding element has a single REQUIRED version attribute that refers to the version976of the specification of the messaging service being used.977

978

7.3.4 MessageEncoding eleme nt979

The MessageEncoding element specifies how the Messages are to be encoded by the document-980exchange layer for transmission. Encoding choices depend on the properties of the Message-981exchange protocol specified by the ebXMLBinding element. An example for BASE64 [MIME]982is:983

984<MessageEncoding>BASE64</MessageEncoding>985

986If the MessageEncoding element is omitted, there is no document-exchange encoding.987

988

7.3.5 ReliableMessaging element989

The ReliableMessaging element specifies the properties of reliable ebXML Message exchange.990The default that applies if the ReliableMessaging element is omitted is "BestEffort". See991Section 7.3.5.1. The following is the element structure:992

993<ReliableMessaging deliverySemantics="OnceAndOnlyOnce"994

idempotency="false"995persistDuration="30S">996

998

<Retries>5</Retries>999<RetryInterval>60</RetryInterval> 1000

</ReliableMessaging>10011002

The ReliableMessaging element is comprised of the following child elements:1003• a Retries element1004• a RetryInterval element1005

1006



The ReliableMessaging element has attributes as follows:1007• a REQUIRED deliverySemantics attribute and1008• a REQUIRED idempotency attribute1009• a REQUIRED persistDuration element1010

10117.3.5.1 deliverySemantics attribute1012The deliverySemantics attribute of the ReliableMessaging element specifies the degree of1013reliability of Message delivery. This attribute is an enumeration of possible values that include1014the following:1015

• OnceAndOnlyOnce1016• BestEffort1017

1018A value of "OnceAndOnlyOnce" specifies that a Message must be delivered exactly once.1019"BestEffort" specifies that reliable Messaging semantics are not to be used.1020

10217.3.5.2 idempotency attribute1022The idempotency attribute of the ReliableMessaging element specifies whether the Party1023requires that all Messages exchanged be subject to an idempotency test (detection and discard of1024duplicate messages) in the document-exchange layer. The attribute is a Boolean with possible1025values "true" and "false". If the value of the attribute is "true", all Messages are subject to the1026test. If the value is "false", messages are not subject to an idempotency test in the document-1027exchange layer. Testing for duplicates is based on the Message identifier; other information that1028is carried in the Message header MAY also be tested, depending on the context.1029

1030NOTE: Additional testing for duplicates may take place in the business application based1031on application information in the Messages (e.g. purchase order number).1032

1033The idempotency test checks whether a Message duplicates a prior message between the same1034client and server. If the idempotency test is requested, the receiving Messaging service passes a1035duplicate Message to the recipient Business Process with a "duplicate" indication. The receiving1036Messaging service also returns a "duplicate" indication to the sender of the duplicate. One of the1037main purposes of this test is to aid in retry following timeouts and in recovery following node1038failures. In these cases, the sending Party MAY have sent request Messages and not received1039responses. The sending Party MAY re-send such a Message. If the original Message had been1040received, the receiving server discards the duplicate Message and re-sends the original results to1041the requester.1042

1043If a communication protocol always checks for duplicate Messages, the check in the1044communication protocol overrides any idempotency specifications in the CPA.1045

10467.3.5.3 persistDuration attribut e1047The value of the persistDuration attribute is the minimum length of time, expressed as a1048[XMLSchema] timeDuration, that data from a Message that is sent reliably is kept in Persistent1049Storage by an ebXML Messaging-service implementation that receives that Message.1050

1051



7.3.5.4 Retries and RetryInterv al elements1052The Retries and RetryInterval elements specify the permitted number of retries and interval1053between retries (in seconds) of a request following a timeout. The purpose of the RetryInterval1054element is to improve the likelihood of success on retry be deferring the retry until any1055temporary conditions that caused the error might be corrected.1056

1057The Retries and RetryInterval elements MUST be included together or MAY be omitted1058together. If they are omitted, the values of the corresponding quantities (number of retries retry1059interval) are a local matter at each Party.1060

1061

7.3.6 NonRepudiation elemen t1062

Non-repudiation both proves who sent a Message and prevents later repudiation of the contents1063of the Message. Non-repudiation is based on signing the Message using XML Digital Signature1064[XMLDSIG]. The element structure is as follows:1065

1066<NonRepudiation>1067

<Protocol version = "1.0">XMLDSIG</Protocol>1068<HashFunction>sha1</HashFunction>1069<SignatureAlgorithm>rsa</SignatureAlgorithm>1070<CertificateRef certId = "N03"/>1071

</NonRepudiation>10721073

If the NonRepudiation element is omitted, the Messages are not digitally signed.10741075

The NonRepudiation element is comprised of the following child elements:1076• The REQUIRED Protocol element,1077• the REQUIRED HashFunction (e.g. SHA1, MD5) element,1078• the REQUIRED SignatureAlgorithm element,1079• and theREQUIRED Certificate element.1080

10817.3.6.1 Protocol element1082The Protocol element identifies the technology that will be used to digitally sign a Message. It1083has a single REQUIRED version attribute that is a string that identifies the version of the1084specified technology. An example of the Protocol element follows:1085

1086<Protocol version="2000/10/31">http://www.w3.org/2000/09/xmldsig#1087</Protocol>1088

10897.3.6.2 HashFunction element1090The HashFunction element identifies the algorithm that is used to compute the digest of the1091Message being signed.1092

10937.3.6.3 SignatureAlgorithm element1094The SignatureAlgorithm element identifies the algorithm that is used to compute the value of the1095digital signature.1096

1097



7.3.6.4 CertificateRef element1098The CertificateRef element refers to one of the Certificate elements elsewhere within the CPP1099document, using the certId IDREF attribute.1100

1101

7.3.7 DigitalEnvelope element1102

The DigitalEnvelope element [DIGENV] is an encryption procedure in which the Message is1103encrypted by symmetric encryption (shared secret key) and the secret key is sent to the Message1104recipient encrypted with the recipient's public key. The element structure is:1105

1106<DigitalEnvelope>1107

<Protocol version = "2.0">S/MIME</Protocol>1108<EncryptionAlgorithm>rsa</EncryptionAlgorithm>1109<CertificateRef certId = "N03"/>1110

</DigitalEnvelope>11111112

7.3.7.1 Protocol element1113The Protocol element identifies the security protocol to be used. The version attribute identifies1114the version of the protocol.1115

11167.3.7.2 EncryptionAlgorithm el ement1117The EncryptionAlgorithm element identifies the encryption algorithm to be used.1118

11197.3.7.3 CertificateRef element1120The CertificateRef element identifies the certificate to be used by means of its certId attribute.1121The certId attribute is an attribute of type [XML] ID REF, which refers to a matching ID1122attribute in a Certificate element elsewhere in the CPP or CPA.1123

1124

7.3.8 Namespaces Supported1125

The NamespaceSupported element identifies any namespace extensions supported by the1126Messaging service implementation. Examples are Security Services Markup Language [S2ML]1127and Transaction Authority Markup Language [XAML]. For example, support for the S2ML1128namespace would be defined as follows:1129

1130<NamespaceSupported schemaLocation = "http://www.s2ml.org/s2ml.xsd"1131version = "0.8">http://www.s2ml.org/s2ml</NamespaceSupported>1132

1133

7.4 ds:Signature element1134

The CPP MAY be digitally signed using technology that conforms with the XML Digital1135Signature specification [XMLDSIG]. The ds:Signature element is the root of a subtree of1136elements that MAY be used for signing the CPP. The syntax is:1137

1138<ds:Signature>...</ds:Signature>1139

1140The content of this element and any subelements are defined by the XML Digital Signature1141specification. See section 8.8 for a detailed discussion.1142

1143



NOTE: Software for creation of CPPs and CPAs may recognize ds:Signature and1144automatically insert the element structure necessary to define signing of the CPP and CPA.1145Signature creation itself is a cryptographic process that is outside the scope of this1146specification.1147

1148

7.5 Comment element1149

The CollaborationProtocolProfile element MAY contain zero or more Comment elements. The1150Comment element is a textual note that MAY be added to serve any purpose the author desires.1151The language of the Comment is identified by a REQUIRED xml:lang attribute. The xml:lang1152attribute MUST comply with the rules for identifying languages specified in [XML]. If multiple1153Comment elements are present, each SHOULD have a unique xml:lang attribute value. An1154example of a Comment element follows:1155

1156<Comment xml:lang=”en-gb”>yadda yadda, blah blah</Comment>1157

11581159



8 CPA Definition1160

A CPA defines the capabilities that two Parties must agree to enable them to engage in electronic1161business. These capabilities include both "technology" capabilities such as supported1162communication and Messaging protocols, and "business capabilities" in terms of what business1163processes they jointly support for the purposes of the particular CPA. This section defines and1164discusses the details of the CPA. The discussion is illustrated with some XML fragments and1165reference should be made to the DTD and sample CPA in the appendices.1166

1167Most of the XML elements in this section are described in detail in section 7, "CPP Definition".1168In general, this section does not repeat that information. The discussions in this section are1169limited to those elements that are not in the CPP or for which additional discussion is required in1170the CPA context. Reference should also be made to the DTD and sample CPA in the appendices.1171

1172

8.1 CPA Structure1173

1174<CollaborationProtocolAgreement id = "N01"1175

xmlns="http://www.ebxml.org/namespaces/tradePartner"1176xmlns:bpm="http://www.ebxml.org/namespaces/businessProcess"1177xmlns:ds = "http://www.w3.org/2000/09/xmldsig#"1178xmlns:xlink = "http://www.w3.org/1999/xlink">1179<CPAType> 1180

…1181</CPAType>1182<Status value = "proposed"/>1183<Start>1988-04-07T18:39:09</Start>1184<End>1990-04-07T18:40:00</End>11851186<ConversationConstraints invocationLimit = "100"1187

concurrentConversations = "4"/>1188<PartyInfo>1189

…1190</PartyInfo>1191<PartyInfo>1192

…1193</PartyInfo>11941195<ds:Signature>any combination of text and elements1196</ds:Signature>1197<Comment xml:lang=”en-gb">any text</Comment> 1198

</CollaborationProtocolAgreement>11991200

8.2 CollaborationProtocol Agreement element1201

The CollaborationProtocolAgreement element is the root element of a collaboration protocol1202agreement document or CPA. It has a required id attribute of type [XML] CDATA that supplies1203a unique idenfier for the Document. The value of the id attribute is assigned by one Party and1204used by both. The value of the id attribute is used as the value of the CPAId element in the1205



ebXML Message header [MSSPEC].12061207

NOTE: Each Party MAY associate a local identifier with the id attribute.12081209

The CollaborationProtocolAgreement element has REQUIRED [XML] Namespace [XMLNS]1210declarations that are defined in Section 7, "CPP Definition".1211

1212The CPA is comprised of the following child elements, each of which is described in greater1213detail in subsequent sections:1214

• a CPAType element that provides information about the general nature of the CPA1215• a REQUIRED Status element that identifies the state of the process that creates the1216

CPA1217• a REQUIRED Start element that records the date and time that the CPA goes into1218

effect1219• a REQUIRED End element that records the date and time after which the CPA must1220

be renegotiated by the Parties1221• a ConversationConstraints element documents certain agreements about1222

Conversation processing1223• two REQUIRED PartyInfo elements, one for each Party to the CPA1224• one or more ds:Signature elements that provide signing of the CPA using the XML1225

Digital Signature [XMLDSIG] standard12261227

8.3 CPAType element1228

1229The CPAType element MAY be present in a CPA Document. It provides information about the1230general nature of the CPA. An example of this element follows:1231

1232<CPAType>1233

<Protocol version = "1.1">PIP3A4</Protocol>1234<Type>RNIF</Type>1235

</CPAType>12361237

The CPAType element is comprised of the following child elements:1238• a REQUIRED Protocol element identifies the business-level protocol. An example is1239

PIP3A4, a RosettaNet™ Partner Interface Process.1240• a REQUIRED Type element provides additional information about the business1241

protocol. Specific values depend on the particular protocol and its optional features.1242An example is RNIF (RosettaNet Implementation Framework).1243

1244The Protocol element has a required attribute, version, whose value specifies the version of the1245protocol that is to be used.1246

1247NOTE: An implementation may use the CPAType element to determine whether it1248already has the code to support this particular protocol.1249

1250



8.4 Status element1251

1252The Status element records the state of the composition/negotiation process that creates the CPA.1253An example of the Status element follows:1254

1255<Status value = "proposed"/>1256

1257The Status element has a value attribute that records the current state of composition of the CPA.1258The value of this attribute is an enumeration of the following possible values:1259

• proposed - meaning that the CPA is still being negotiated by the Parties1260• signed - meaning that the CPA has been "signed" by the Parties. This "signing" MAY1261

take the form of a digital signature that is described in section 8.8 below.12621263

NOTE: The Status element MAY be used by a CPA composition and negotiation tool to1264assist in the process of building a CPA.1265

1266

8.5 CPA Lifetime1267

The lifetime of the CPA is given by the Start and End elements. The syntax is:12681269

<Start>1988-04-07T18:39:09</Start>1270<End>1990-04-07T18:40:00</End>1271

1272

8.5.1 Start element1273

The Start element specifies the starting date and time of the CPA. The Start element SHALL be1274a string value that conforms to the content model of a canonical timeInstant as defined in the1275XML Schema Datatypes Specification [XMLSCHEMA-2]. For example, to indicate 1:20 pm1276UTC (Coordinated Universal Time) on May 31, 1999, a Start element would have the following1277value:1278

12791999-05-31T13:20:00Z1280

1281The Start element SHALL be represented as Coordinated Universal Time (UTC).1282

1283

8.5.2 End element1284

The End element specifies the ending date and time of the CPA. The End element SHALL be a1285string value that conforms to the content model of a canonical timeInstant as defined in the XML1286Schema Datatypes Specification [XMLSCHEMA-2]. For example, to indicate 1:20 pm UTC1287(Coordinated Universal Time) on May 31, 1999, an End element would have the following1288value:1289

12901999-05-31T13:20:00Z1291

1292The End element SHALL be represented as Coordinated Universal Time (UTC).1293

1294



When the end of the CPA's lifetime is reached, any Business Transactions that are still in1295progress SHALL be allowed to complete and no new Business Transactions SHALL be started.1296When all in-progress Business Transactions on each Conversation are completed, the1297Conversation shall be terminated whether or not it was completed.1298

1299NOTE: It should be understood that if an application defines a Conversation as consisting1300of multiple Business Transactions, such a Conversation may be terminated with no error1301indication when the end of the lifetime is reached. The runtime could provide an error1302indication to the application.1303

1304NOTE: It should be understood that it may not be feasible to wait for outstanding1305Conversations to terminate before ending the CPA since there is no limit on how long a1306Conversation may last.1307

1308NOTE: The runtime SHOULD return an error indication to both Parties when a new1309Business Transaction is started under this CPA after the date and time specified in the1310End element.1311

1312

8.6 ConversationConstraints element1313

1314The ConversationConstraints element places limits on the number of Conversations under the1315CPA. An example of this element follows:1316

1317<ConversationConstraints invocationLimit = "100"1318

concurrentConversations = "4"/>13191320

The ConversationConstraints has two attributes as follows:1321• the invocationLimit attribute1322• the concurrentConversations attribute1323

1324

8.6.1 invocationLimit attribut e1325

The invocationLimit attribute defines the maximum number of Conversations that can be1326processed under the CPA. When this number has been reached, the CPA is terminated and must1327be renegotiated. If no value is specified, there is no upper limit on the number of Conversations1328and the lifetime of the CPA is controlled solely by the End element.1329

1330

8.6.2 concurrentConversations attribute1331

The concurrentConversations attribute defines the maximum number of Conversations that can1332be in process under this CPA at the same time. If no value is specified, processing of concurrent1333Conversations is strictly a local matter.1334

1335NOTE: The concurrentConversations attribute provides a parameter for the Parties to use1336when it is necessary to limit the number of Conversations that can be concurrently processed1337under a particular CPA. For example, the back-end process might only support a limited1338



number of concurrent Conversations. If a request for a new conversation is received when1339the maximum number of conversations allowed under this CPA is already in process, an1340implementation MAY reject the new Conversation or may enqueue the request until an1341existing Conversation ends. If no value is given for concurrentConversations, how to1342handle a request for a new Conversation for which there is no capacity is a local1343implementation matter.1344

1345

8.7 PartyInfo element1346

The general characteristics of the PartyInfo element are discussed in sections 7.2 and 7.2.1 .13471348

The CPA SHALL have one PartyInfo element for each Party to the CPA. The PartyInfo1349element specifies the Parties' agreed terms for engaging in a the Business Process defined by the1350Process-Specification Document referenced by the CPA. If a CPP has more than one PartyInfo1351element, the appropriate PartyInfo element SHALL be selected from each CPP when composing1352a CPA.1353

1354In the CPA, there SHALL be one PartyId element under each PartyInfo element. The value of1355this element is the same as the value of the PartyId element in the ebXML Messaging Service1356specification [MSSPEC]. One PartyId element SHALL be used within a To or From header1357element of an ebXML Message.1358

1359

8.7.1 ProcessSpecification element1360

The ProcessSpecification element identifies the business process that the two Parties have1361agreed to perform. There MAY be one or more ProcessSpecification elements in a CPA. See the1362discussion in Section 7.2.4.1363

1364

8.8 ds:Signature element1365

A CPA Document MAY be digitally signed by one or more of the Parties as a means of ensuring1366its integrity as well as a means of expressing the agreement just as a corporate officer's signature1367would do for a paper Document. If signatures are being used to digitally sign an ebXML CPA or1368CPP Document, then it is strongly RECOMMENDED that [XMLDSIG] be used to digitally sign1369the Document. The ds:Signature element is the root of a subtree of elements that MAY be used1370for signing the CPP. The syntax is:1371

1372<ds:Signature>...</ds:Signature>1373

1374The content of this element and any subelements are defined by the XML Digital Signature1375specification.1376

1377NOTE: Software for creation of CPPs and CPAs MAY recognize ds:Signature and1378automatically insert the element structure necessary to define signing of the CPP and CPA.1379Signature creation itself is a cryptographic process that is outside the scope of this1380specification.1381

1382



8.8.1 Persistent Digital Signature1383

If [XMLDSIG] is used to sign an ebXML CPP or CPA, the process defined in this section of the1384specification SHALL be used.1385

13868.8.1.1 Signature Generation1387

1)Create a SignedInfo element, a child element of ds:signature. SignedInfo SHALL have child1388elements SignatureMethod, CanonicalizationMethod, and Reference as prescribed by1389[XMLDSIG].1390

2)Canonicalize and then calculate the SignatureValue over SignedInfo based on algorithms1391specified in SignedInfo as specified in [XMLDSIG].1392

3)Construct the Signature element that includes the SignedInfo, KeyInfo (RECOMMENDED),1393and SignatureValue elements as specified in [XMLDSIG].1394

4)Include the namespace qualified Signature element in the Document just signed, following the1395last PartyInfo element.1396

13978.8.1.2 ds:SignedInfo element1398The ds:SignedInfo element SHALL be comprised of zero or one ds:CanonicalizationMethod1399element, the ds:SignatureMethod element, and one or more ds:Reference elements.1400

14018.8.1.3 Ds:CanonicalizationMethod element1402The ds:CanonicalizationMethod element is defined as OPTIONAL in [XMLDSIG], meaning1403that the element need not appear in an instance of a ds:SignedInfo element. The default1404canonicalization method that is applied to the data to be signed is [XMLC14N] in the absence of1405a ds:Canonicalization element that specifies otherwise. This default SHALL also serve as the1406default canonicalization method for the ebXML CPP and CPA Documents.1407

14088.8.1.4 ds:SignatureMethod element1409The ds:SignatureMethod element SHALL be present and SHALL have an Algorithm attribute.1410The RECOMMENDED value for the Algorithm attribute is:1411

1412http://www.w3.org/2000/02/xmldsig#sha11413

1414This RECOMMENDED value SHALL be supported by all compliant ebXML CPP or CPA1415software implementations.1416

14178.8.1.5 ds:Reference element1418The ds:Reference element for the CPP or CPA Document SHALL have an URI attribute value1419of "" to provide for the signature to be applied to the Document that contains the ds:Signature1420element (the CPA or CPP Document). The ds:Reference element for the CPP or CPA Document1421MAY include a Type attribute that has a value of:1422

1423"http://www.w3.org/2000/02/xmldsig#Object"1424

1425in accordance with [XMLDSIG]. This attribute is purely informative. It MAY be omitted.1426



Implementations of software designed to author or process an ebXML CPA or CPP Document1427SHALL be prepared to handle either case. The ds:Reference element MAY include the optional1428id attribute.1429

14308.8.1.6 ds:Transform element1431The ds:Reference element for the CPA or CPP Document SHALL include a child ds:Transform1432element that excludes the containing ds:Signature element and all its descendants.1433

14348.8.1.7 s:Xpath element1435The ds:Transform element SHALL include a child ds:XPath element that has a value of:1436

1437/descendant-or-self::node()[not(ancestor-or-self::ds:Signature[@id='S1'])]1438

1439NOTE: When digitally signing a CPA, it is RECOMMENDED that each Party sign the1440Document in accordance with the process described above. The first Party that signs the1441CPA will sign only the CPA contents, excluding their own signature. The second party1442signs over the contents of the CPA as well as the Signature element that contains the first1443Party's signature. It MAY be necessary that a notary sign over both signatures so as to1444provide for cryptographic closure.1445

1446

8.9 Comment element1447

The CollaborationProtocolAgreement element MAY contain zero or more Comment elements.1448See section 7.5 for details of the syntax of the Comment element.1449

1450

8.10 Security Considerations for the CPA1451

Authentication is bi-directional if each Party has to authenticate to the other during a given1452message exchange. The alternative is that the client authenticates to the server but not vice-1453versa. In most cases, the choice is determined by other factors. If SSL Ver. 3 is specified for1454encryption, authentication is always bi-directional.1455

1456It should be understood that in a CPA in which each Party can act as either a server or a client1457for different BusinessTtransactions, the security definitions must enable each Party to1458authenticate to the other, though not necessarily in the same Message exchange.1459

1460Security at the document-exchange level applies to all Messages in both directions for Business1461Transactions for which security is enabled.1462

1463

8.11 Composing a CPA from Two CPPs1464

This section discusses normative issues in composing a CPA from two CPPs. See also Appendix1465F, "Composing a CPA from Two CPPs (Non-Normative)".1466

1467

8.11.1 ID Attribute Duplication1468

In composing a CPA from two CPPs, there is a hazard that ID attributes from the two CPPs1469



might have duplicate values. When a CPA is composed from two CPPs, duplicate ID attribute1470values SHALL be tested for. If a duplicate ID attribute value is present, one of the duplicates1471shall be given a new value and the corresponding IDREF attribute values SHALL be corrected.1472

1473

8.12 Modifying Parameters of the Process Specification Document Based on1474Information in the CPA1475

A Process-Specification Document contains a number of parameters, expressed as XML1476attributes. An example is the security attributes that are counterparts of the attributes of the CPA1477Characteristics element. The values of these attributes can be considered to be default values or1478recommendations. When a CPA is created, the Parties MAY decide to accept the1479recommendations in the Process-Specification Document or they MAY agree on values of these1480parameters that better reflect their needs.1481

1482When a CPA is used to configure a run-time system, choices specified in the CPA MUST always1483assume precedence over choices specified in the referenced Process-Specification Document. In1484particular, all choices expressed in a CPA’s Characteristics and Packaging elements MUST be1485implemented as agreed to by the Parties. These choices MUST override the default values1486expressed in the Process-Specification Document. The process of installing the information from1487the CPA and Process-Specification Document MUST verify that all of the resulting choices are1488mutually consistent and MUST signal an error if they are not.1489

1490NOTE: There are several ways of overriding the information in the Process-1491Specification Document by information from the CPA. For example:1492

1493• A separate copy of the Process-Specification document can be created by the CPA1494

composition tool. The tool can then directly modify the Process-Specification1495Document with information from the CPA. One advantage of this method is that the1496override process is performed entirely by the CPA composition tool. A second1497advantage is that with a separate copy of the Process-Specification Document1498associated with the particular CPA, there is no exposure to modifications of the1499Process-Specification Document between the time that the CPA is created and the1500time it is installed in the Parties' systems.1501

• A CPA installation tool can dynamically override parameters in the Process-1502Specification Document with information from the corresponding parameters from1503the CPA at the time the CPA and Process-Specification Document are installed in the1504Parties' systems. This eliminates the need to create a separate copy of the Process-1505Specification Document. One disadvantage is that it requires the two Parties to use1506the same or compatible CPA installation tools in their systems. A second1507disadvantage is that it requires testing that theProcess-Specification Document has not1508been altered between CPA composition and CPA installation.1509

• Other possible methods might be based on XSLT transformations of the parameter1510information in the CPA and/or the Process-Specification Document.1511

1512



9 References1513

Some references listed below specify functions for which specific XML definitions are provided1514in the CPP and CPA. Other specifications are referred to in this specification in the sense that1515they are represented by keywords for which the Parties to the CPA may obtain plug-ins or write1516custom support software but do not require specific XML element sets in the CPP and CPA.1517

1518In a few cases, the only available specification for a function is a proprietary specification.1519These are indicated by notes within the citations below.1520

15211522

[BPMSPEC] ebXML Business Process Specification Schema specification,1523http://www.ebxml.org.1524

1525[DIGENV] Digital Envelope, RSA Laboratories, http://www.rsasecurity.com/rsalabs/. NOTE:1526At this time, the only available specification for digital envelope appears to be the RSA1527Laboratories specification.1528

1529[EBXMLCC] ebXML Core Components Specification, http://www.ebxml.org.1530

1531[EBXMLGLOSS] ebXML Glossary, http://www.ebxml.org.1532

1533[FTP] File Transfer Protocol (FTP), Internet Engineering Task Force RFC 959.1534

1535[HTMLENC] HTML ver. 4.0 specification, World Wide WebConsortium,1536http://www.w3.org/TR/html4/. See section 5.3, Character References.1537

1538[HTTP] Hypertext Transfer Protocol, Internet Engineering Task Force RFC2616.1539

1540[IPSEC] IP Security Document Roadmap, Internet Engineering Task Force RFC 2411.1541

1542[ISO6523] Structure for the Identification of Organizations and Organization Parts, International1543Standards Organization ISO-6523.1544

1545[MIME] MIME (Multipurpose Internet Mail Extensions) Part One: Mechanisms for Specifying1546and Describing the Format of Internet Message Bodies. Internet Engineering Task Force RFC15471521.1548

1549[MSSPEC] ebXML Messaging Service Specification, http://www.ebxml.org1550

1551[REGREP] ebXML Registry and Repository Specification, http://www.ebxml.org1552

1553[RFC822] Standard for the Format of ARPA Internet Text Messages, Internet Engineering Task1554Force RFC 822.1555

1556



[RFC2015] MIME Security with Pretty Good Privacy, M. Elkins, Internet Engineering Task1557Force, RFC 2015.1558

1559[RFC2119] Key Words for use in RFCs to Indicate Requirement Levels, Internet Engineering1560Task Force RFC 2119.1561

1562[RFC2396] Uniform Resource Identifiers (URI): Generic Syntax; T. Berners-Lee, R. Fielding, L.1563Masinter - August 19981564

1565[S/MIME] S/MIME Version 3 Message Specification, Internet Engineering Task Force RFC15662633.1567

1568[S2ML] Security Services Markup Language, http://s2ml.org/1569

1570[SMTP] Simple Mail Transfer Protocol, Internet Engineering Task Force RFC 821.1571

1572[SSL] Secure Sockets Layer, Netscape Communications Corp. http://developer.netscape.com.1573NOTE: At this time, it appears that the Netscape specification is the only available specification1574of SSL. Work is in progress in IETF on "Transport Layer Security", which is intended as a1575replacement for SSL.1576

1577[TECHARCH] ebXML Technical Architecture Specification, http://www.ebxml.org.1578

1579[XAML] Transaction Authority Markup Language, http://xaml.org/1580

1581[XLINK] XML Linking Language, http://www.w3.org/TR/xlink/1582

1583[XML] Extensible Markup Language (XML), World Wide Web Consortium,1584http://www.w3.org.1585

1586[XMLC14N] Canonical XML, Ver. 1.0, http://www.w3.org/TR/XML-C14N/1587

1588[XMLDSIG] XML Signature Syntax and Processing, Worldwide Web Consortium,1589http://www.w3.org/TR/xmldsig-core/1590

1591 [XMLNS] Namespaces in XML, T. Bray, D. Hollander, and A. Layman, Jan. 1999,1592http://www.w3.org/TR/REC-xml-names/.1593

1594[XMLSCHEMA-2] XML Schema Datatypes Specification,1595http://www.w3.org/TR/xmlschema-2/1596



10 Disclaimer1597

The views and specification expressed in this Document are those of the authors and are not1598necessarily those of their employers. The authors and their employers specifically disclaim1599responsibility for any problems arising from correct or incorrect implementation or use of this1600design.1601



Contact Information1602

16031604

Martin W. Sachs (Team Leader)1605 IBM T. J. Watson Research Center1606 P.O.B. 7041607 Yorktown Hts, NY 105981608 USA1609 Phone: 914-784-72871610 email: [email protected]

16121613

Chris Ferris1614 XML Technology Development1615 Sun Microsystems, Inc1616 One Network Drive1617 Burlington, Ma 01824-09031618 USA1619 781-442-30631620 email: [email protected]

16221623

Dale W. Moberg1624 Sterling Commerce1625 4600 Lakehurst Ct.1626 Dublin, OH 430161627 USA1628 Phone: 614-793-50151629 email: [email protected]

1631



Copyright Statement1632

Copyright © ebXML 2001. All Rights Reserved.16331634

This document and translations of it MAY be copied and furnished to others, and derivative1635works that comment on or otherwise explain it or assist in its implementation MAY be prepared,1636copied, published and distributed, in whole or in part, without restriction of any kind, provided1637that the above copyright notice and this paragraph are included on all such copies and derivative1638works. However, this document itself MAY not be modified in any way, such as by removing1639the copyright notice or references to ebXML, UN/CEFACT, or OASIS, except as required to1640translate it into languages other than English.1641

1642The limited permissions granted above are perpetual and will not be revoked by ebXML or its1643successors or assigns.1644

1645This document and the information contained herein is provided on an "AS IS" basis and1646ebXML DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT1647NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN1648WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF1649MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.1650

1651



Appendix A Example of CPP D ocument (Non-normative)1652

1653This example is out of date and will be replaced before the next round of public review.1654

1655<?xml version = "1.0"?>1656<!DOCTYPE CollaborationProtocolProfile SYSTEM "cppml%2cv0.23.dtd">16571658<CollaborationProtocolProfile id = "id"1659

xmlns="http://www.ebxml.org/namespaces/tradePartner"1660xmlns:bpm = "http://www /namespaces/businessProcess"1661xmlns:ds = "http://www.w3.org/2000/09/xmldsig#"1662xmlns:xlink = "http://www.w3.org/1999/xlink">16631665<Party partyId = "N01">1666

1668

<PartyId type = "uriReference">urn:duns.com:duns:1234567890123</PartyId>1669<PartyId type = "uriReference">urn:www.example.com</PartyId>1670<PartyDetails xlink:type="simple"1671

xlink:href="http://example2.com/example.com"/>1672<CollaborationRole roleId="N07" certId="N03">1673

<CollaborationProtocol name = "Buy Sell" version = "1.0"1674xlink:type = "locator"1675xlink:href = "http://www.example.com/services/purchasing.xml"/>1676

<Role name = "buyer" certId = "N03"1677xlink:href="http://www.example.com/services/purchasing.xml"/>1678

1679 <ServiceBinding name="MyShopper" channelId="N04"/>1680

</CollaborationRole>1681<CollaborationRole roleId="N12" certId="N03">1682

1683</CollaborationRole>1684<Certificate certId = "N03">1685

1686<ds:KeyInfo>REFERENCE [XMLDSIG]</ds:KeyInfo>1687

</Certificate>1688<DeliveryChannel channelId = "N04"1689

transportId = "N05" docExchangeId = "N06">16901691<Characteristics nonrepudiationOfOrigin = "true"1692

nonrepudiationOfReceipt = "true" secureTransport = "true" confidentiality = "true"1693authenticated = "true" authorized = "true"/>1694

1695</DeliveryChannel>1696<Transport transportId = "N05">1697

1699

<Protocol version = "1.1">HTTP</Protocol>1700<Endpoint uri = "http://example.com/servlet/ebxmlhandler" type =1701



"request"/>1702<TransportSecurity>1703

1704<Protocol version = "3.0">SSL</Protocol>1705<CertificateRef certId = "N03"/>1706

</TransportSecurity>1707</Transport>1708<DocExchange docExchangeId = "N06">1709

1710<ebXMLBinding version = "0.9">1711

1713

<MessageEncoding version = "base64" packagingType = "need to1714discuss">only text</MessageEncoding>1715

<ReliableMessaging deliverySemantics = "BestEffort"1716idempotency = "false">1717

1718<Timeout>30</Timeout>1719<Retries>5</Retries>1720<RetryInterval>60</RetryInterval>1721

</ReliableMessaging>1722<NonRepudiation>1723

1725

<Protocol version = "2.0">S/MIME</Protocol>1726<HashFunction>sha1</HashFunction>1727<SignatureAlgorithm>rsa</SignatureAlgorithm>1728<CertificateRef certId = "N03"/>1729

</NonRepudiation>1730<DigitalEnvelope>1731

1733


</DigitalEnvelope>1737<NamespaceSupported schemaLocation =1738

"http://www.s2ml.org/s2ml.xsd" version =1739"0.7a">http://www.s2ml.org/s2ml/</NamespaceSupported>1740


</Party>1743<ds:Signature>any combination of text and elements</ds:Signature>1744

</CollaborationProtocolProfile>1745



Appendix BAppendix BAppendix BAppendix B Example of CPA Document (Non-normative)1746

1747This example is out of date and will be replaced before the next round of public review.1748

1749<?xml version = "1.0"?>1750<!DOCTYPE CollaborationProtocolAgreement SYSTEM "cppml%2cv0.23.dtd">17511752<CollaborationProtocolAgreement id = "N01"1753

xmlns="http://www.ebxml.org/namespaces/tradePartner"1754xmlns:bpm = "http://www.ebxml.org/namespaces/businessProcess"1755xmlns:ds = "http://www.w3.org/2000/09/xmldsig#"1756xmlns:xlink = "http://www.w3.org/1999/xlink">17571760

<CPAType>17611762<Protocol version = "1.1">PIP3A4</Protocol>1763<Type>RNIF</Type>1764

</CPAType>1765<Status value = "proposed"/>1766<Start>1988-04-07T18:39:09</Start>1767<Duration>124</Duration>1768<ConversationConstraints invocationLimit = "100" concurrentConversations = "4"/>1769<Party partyId = "N01">1770

1772

<PartyId type = "uriReference">urn:duns.com:duns:1234567890123</PartyId>1773<PartyId type = "uriReference">urn:www.example.com</PartyId>1774<PartyDetails xlink:type="simple"1775

xlink:href="http://example.com/example2.com"/>1776<CollaborationRole roleId="N07" certId="N03">1777

<CollaborationProtocol name = "Buy Sell" version = "1.0"1778xlink:type = "locator"1779xlink:href = "http://www.example.com/services/purchasing.xml"/>1780

<Role name = "buyer" certId = "N03"1781xlink:href="http://www.example.com/services/purchasing.xml"/>1782

1783<ServiceBinding name="MyShopper" channelId="N04"/>1784

</CollaborationRole>1785<Certificate certId = "N03">1786


</Certificate>1789<DeliveryChannel channelId = "N04" transportId = "N05" docExchangeId =1790

"N06">17911792<Characteristics nonrepudiationOfOrigin = "true"1793


</DeliveryChannel>1796



<Transport transportId = "N05">17971799<Protocol version = "1.1">HTTP</Protocol>1800<Endpoint uri = "http://example2.com/servlet/ebxmlhandler" type =1801

"request"/>18021803

<TransportSecurity>18041805<Protocol version = "3.0">SSL</Protocol>1806<CertificateRef certId = "N03"/>1807






1819<Timeout>30</Timeout>1820<Retries>5</Retries>1821<RetryInterval>60</RetryInterval>1822

</ReliableMessaging>1823<NonRepudiation>1824









</Party>1844<Party partyId = "N01">1845

1847

<PartyId type = "uriReference">urn:duns.com:duns:1234567890123</PartyId>1848<PartyId type = "uriReference">urn:www.example.com</PartyId>1849



<PartyDetails xlink:type="simple"1850xlink:href="http://example2.com/example.com"/>1851

<Role certId = "N03" roleId = "N08" name = "seller">18521853<ServiceBinding collaborationId="N09" channelId="N04"/>1854

1855</Role>1856<CollaborationRole roleId="N07" certId="N03">1857

<CollaborationProtocol name = "Buy Sell" version = "1.0"1858xlink:type = "locator"1859xlink:href = "http://www.example.com/services/purchasing.xml"/>1860<Role name = "buyer"1861

xlink:href="http://www.example.com/services/purchasing.xml"/>18621863

<ServiceBinding name="MyShopper" channelId="N04"/>1864</CollaborationRole>1865<Certificate certId = "N03">1866


</Certificate>1869<DeliveryChannel channelId = "N04" transportId = "N05" docExchangeId =1870

"N06">18711872<Characteristics nonrepudiationOfOrigin = "true"1873


1876</DeliveryChannel>1877<Transport transportId = "N05">1878

1880

<Protocol version = "1.1">HTTP</Protocol>1881<Endpoint uri = "http://example.com/servlet/ebxmlhandler" type =1882

"request"/>18831884

<TransportSecurity>18851886<Protocol version = "3.0">SSL</Protocol>1887<CertificateRef certId = "N03"/>1888






1900<Timeout>30</Timeout>1901<Retries>5</Retries>1902



<RetryInterval>60</RetryInterval>1903</ReliableMessaging>1904<NonRepudiation>1905









</Party>1925<CollaborationProtocol version = "1.0" id = "N07" xlink:type = "locator"1926

xlink:href = "http://www.example.com/services/purchasing.xml">Buy and Sell1927</CollaborationProtocol>1928<ds:Signature>any combination of text and elements</ds:Signature>1929

</CollaborationProtocolAgreement>19301931193219331934



Appendix C DTD Correspond ing to Complete CPP/CPA1935

Definition (Normative)1936

This DTD is out of date and will be replaced before the next round of public review.19371938

<?xml version='1.0' encoding='UTF-8' ?>19391940

19411942

<!ELEMENT CollaborationProtocolAgreement (CPAType? , Status , Start , End ,1943ConversationConstraints? , PartyInfo* , ds:Signature+ , Comment*)>1944<!ATTLIST CollaborationProtocolAgreement id CDATA #IMPLIED >1945<!ELEMENT CollaborationProtocolProfile (PartyInfo+ , ds:Signature? , Comment*)>1946<!ELEMENT ReceivingProtocol (#PCDATA)>1947<!ATTLIST ReceivingProtocol version CDATA #IMPLIED1948

e-dtype NMTOKEN #FIXED 'string' >1949<!ELEMENT SendingProtocol (#PCDATA)>1950<!ATTLIST SendingProtocol version CDATA #IMPLIED1951

e-dtype NMTOKEN #FIXED 'string' >1952<!ELEMENT Protocol (#PCDATA)>1953<!ATTLIST Protocol e-dtype NMTOKEN #FIXED 'string' >1954<!ELEMENT CollaborationRole (ProcessSpecification+ , Role , CertificateRef? , ServiceBinding+)>1955<!ATTLIST CollaborationRole id ID #REQUIRED >1956<!ELEMENT PartyInfo (PartyId+ , PartyRef , CollaborationRole+ , Certificate+ , DeliveryChannel+ ,1957Transport+ , DocExchange+)>1958<!ELEMENT PartyId (#PCDATA)>1959<!ATTLIST PartyId type CDATA #IMPLIED1960

e-dtype NMTOKEN #FIXED 'string' >1961<!ELEMENT PartyRef EMPTY>1962<!ATTLIST PartyRef xlink:type (simple ) #FIXED 'simple'1963

xlink:href CDATA #REQUIRED >1964<!ELEMENT DeliveryChannel (Characteristics)>1965<!ATTLIST DeliveryChannel channelId ID #REQUIRED1966

transportId IDREF #REQUIRED1967docExchangeId IDREF #IMPLIED >1968

<!ELEMENT Transport (SendingProtocol , ReceivingProtocol , Endpoint+ , TransportSecurity?)>1969<!ATTLIST Transport transportId ID #REQUIRED >1970<!ELEMENT Endpoint EMPTY>1971<!ATTLIST Endpoint uri CDATA #REQUIRED1972

type (login | request | response | error | allPurpose ) 'allPurpose'1973a-dtype NMTOKENS 'uri uri' >1974

<!ELEMENT Retries (#PCDATA)>1975<!ATTLIST Retries e-dtype NMTOKEN #FIXED 'string' >1976<!ELEMENT RetryInterval (#PCDATA)>1977<!ATTLIST RetryInterval e-dtype NMTOKEN #FIXED 'string' >1978<!ELEMENT TransportSecurity (Protocol , CertificateRef)>1979<!ELEMENT Certificate (ds:KeyInfo)>1980<!ATTLIST Certificate certId ID #REQUIRED >1981<!ELEMENT DocExchange (ebXMLBinding)>1982<!ATTLIST DocExchange docExchangeId ID #IMPLIED >1983<!ELEMENT ReliableMessaging (Retries , RetryInterval)?>1984<!ATTLIST ReliableMessaging deliverySemantics (OnceAndOnlyOnce | BestEffort ) #REQUIRED1985

idempotency CDATA #REQUIRED1986persistDuration CDATA #REQUIRED1987a-dtype NMTOKENS 'idempotency boolean'1988e-dtype NMTOKEN #FIXED 'timeDuration' >1989

<!ELEMENT NonRepudiation (Protocol , HashFunction , SignatureAlgorithm , CertificateRef)>1990<!ELEMENT HashFunction (#PCDATA)>1991<!ATTLIST HashFunction e-dtype NMTOKEN #FIXED 'string' >1992<!ELEMENT EncryptionAlgorithm (#PCDATA)>1993<!ATTLIST EncryptionAlgorithm e-dtype NMTOKEN #FIXED 'string' >1994<!ELEMENT SignatureAlgorithm (#PCDATA)>1995<!ATTLIST SignatureAlgorithm e-dtype NMTOKEN #FIXED 'string' >1996<!ELEMENT DigitalEnvelope (Protocol , EncryptionAlgorithm , CertificateRef)>1997<!ELEMENT ProcessSpecification (ds:Reference)>1998<!ATTLIST ProcessSpecification version CDATA #REQUIRED1999



name CDATA #REQUIRED >2000<!ELEMENT CertificateRef (#PCDATA)>2001<!ATTLIST CertificateRef certId IDREF #IMPLIED2002

e-dtype NMTOKEN #FIXED 'string' >2003<!ELEMENT MessageEncoding (#PCDATA)>2004<!ATTLIST MessageEncoding version CDATA #REQUIRED2005

packagingType CDATA #IMPLIED2006e-dtype NMTOKEN #FIXED 'string' >2007

<!ELEMENT ebXMLBinding (MessageEncoding? , ReliableMessaging? , NonRepudiation? ,2008DigitalEnvelope? , NamespaceSupported+)>2009<!ATTLIST ebXMLBinding version CDATA #REQUIRED >2010<!ELEMENT ds:KeyInfo EMPTY>2011<!ELEMENT ds:Signature EMPTY>2012<!ELEMENT NamespaceSupported (#PCDATA)>2013<!ATTLIST NamespaceSupported schemaLocation CDATA #IMPLIED2014

version CDATA #REQUIRED2015e-dtype NMTOKEN #FIXED 'uri'2016a-dtype NMTOKENS 'schemaLocation uri' >2017

<!ELEMENT EMPTY>2018<!ATTLIST Characteristics nonrepudiationOfOrigin CDATA #IMPLIED2019

nonrepudiationOfReceipt CDATA #IMPLIED2020secureTransport CDATA #IMPLIED2021confidentiality CDATA #IMPLIED2022authenticated CDATA #IMPLIED2023authorized CDATA #IMPLIED2024a-dtype NMTOKENS 'nonrepudiationOfOrigin boolean2025

nonrepudiationOfReceipt boolean2026secureTransport boolean2027confidentiality boolean2028authenticated boolean2029authorized boolean' >2030

<!ELEMENT ServiceBinding (Packaging+ , Override*)>2031<!ATTLIST ServiceBinding channelId ID REF #REQUIRED2032

name CDATA #IMPLIED >2033<!ELEMENT CPAType (Protocol , Type)>2034<!ELEMENT Status EMPTY>2035<!ATTLIST Status value (signed | proposed ) #REQUIRED >2036<!ELEMENT Start (#PCDATA)>2037<!ATTLIST Start e-dtype NMTOKEN #FIXED 'timeInstant' >2038<!ELEMENT End (#PCDATA)>2039<!ATTLIST End e-dtype NMTOKEN #FIXED 'timeInstant' >2040<!ELEMENT Type (#PCDATA)>2041<!ATTLIST Type e-dtype NMTOKEN #FIXED 'string' >2042<!ELEMENT ConversationConstraints EMPTY>2043<!ATTLIST ConversationConstraints invocationLimit CDATA #IMPLIED2044

concurrentConversations CDATA #IMPLIED2045a-dtype NMTOKENS2046

'invocationLimit i42047concurrentConversations i4' >2048

<!ELEMENT Override EMPTY>2049<!ATTLIST Override action CDATA #REQUIRED2050

channelId ID #REQUIRED2051xlink:href CDATA #IMPLIED2052xlink:type (simple ) #FIXED 'simple' >2053

<!ELEMENT Role (#PCDATA)>2054<!ATTLIST Role name CDATA #IMPLIED2055

xlink:href CDATA #IMPLIED2056xlink:type (simple ) #FIXED 'simple' >2057

<!ELEMENT SecurityRisks (#PCDATA)>2058<!ELEMENT SecurityBenefits (#PCDATA)>2059<!ELEMENT Packaging (ProcessingCapabilities , SimplePart+ , CompositeList?)+>2060<!ELEMENT Comment ANY>2061<!ELEMENT Composite (Constituent+)>2062<!ATTLIST Composite mimetype CDATA #REQUIRED2063

id CDATA #REQUIRED2064mimeparameters CDATA #IMPLIED >2065

<!ELEMENT Constituent EMPTY>2066<!ATTLIST Constituent idref CDATA #REQUIRED >2067<!ELEMENT Encapsulation (Constituent)>2068<!ATTLIST Encapsulation mimetype CDATA #REQUIRED2069

id CDATA #REQUIRED2070



mimeparameters CDATA #IMPLIED >2071<!ELEMENT CompositeList (Encapsulation | Composite)+>2072<!ELEMENT XMLMetaDataInformation EMPTY>2073<!ATTLIST XMLMetaDataInformation URI CDATA #IMPLIED2074

MetaDataDescriptionType (dtd | xsd ) #REQUIRED >2075<!ELEMENT MimeHeader EMPTY>2076<!ATTLIST MimeHeader HeaderName CDATA #REQUIRED >2077<!ELEMENT MimeParameter EMPTY>2078<!ATTLIST MimeParameter parameterAttribute CDATA #REQUIRED2079

parameterValue CDATA #IMPLIED >2080<!ELEMENT SimplePart EMPTY>2081<!ATTLIST SimplePart id CDATA #REQUIRED2082

mimetype CDATA #REQUIRED >2083<!ELEMENT ProcessingCapabilities EMPTY>2084<!ATTLIST ProcessingCapabilities parse CDATA #REQUIRED2085

generate CDATA #REQUIRED >2086<!ELEMENT ds:Reference EMPTY>2087

20882089

2090



Appendix D XML Schema Do cument Corresponding to2091

Complete CPA Definition (Normative)2092

2093This schema is out of date and will be replaced for the next round of public review.2094

2095<?xml version = "1.0" encoding = "UTF-8"?>20962097<xsd:schema xmlns:xlink = "http://www.w3.org/1999/xlink"2098

xmlns:ds = "http://www.w3.org/2000/09/xmldsig#"2099xmlns:xsd = "http://www.w3.org/2000/10/XMLSchema">2100<xsd:import namespace = "http://www.w3.org/1999/xlink" schemaLocation =2101

"http://www.w3.org/1999/xlink"/>2102<xsd:import namespace = "http://www.w3.org/2000/09/xmldsig#" schemaLocation =2103

"file:///C:/My%20Documents/ebXML/xmldsig-core-schema.xsd"/>2104<xsd:element name = "CollaborationProtocolAgreement">2105

<xsd:complexType>2106<xsd:sequence>2107

<xsd:element ref = "CPAType" minOccurs = "0"/>2108<xsd:element ref = "Status"/>2109<xsd:element ref = "Start"/>2110<xsd:element ref = "Duration"/>2111<xsd:element ref = "ConversationConstraints" minOccurs = "0"/>2112<xsd:element ref = "PartyInfo" minOccurs = "0" maxOccurs =2113

"unbounded"/>2114<xsd:element ref = "ds:Signature" minOccurs = "0"/>2115<xsd:element ref = "Comment" minOccurs = "0" maxOccurs =2116

"unbounded"/>2117</xsd:sequence>2118<xsd:attribute name = "id" type = "xsd:string"/>2119

</xsd:complexType>2120</xsd:element>2121<xsd:element name = "CollaborationProtocolProfile">2122


<xsd:element ref = "PartyInfo" maxOccurs = "unbounded"/>2125<xsd:element ref = "ds:Signature" minOccurs = "0"/>2126<xsd:element ref = "Comment" minOccurs = "0" maxOccurs =2127

"unbounded"/>2128</xsd:sequence>2129

</xsd:complexType>2130</xsd:element>2131<xsd:element name = "ReceivingProtocol">2132

<xsd:complexType>2133<xsd:simpleContent>2134

<xsd:extension base = "xsd:string">2135<xsd:attribute name = "version" type = "xsd:string"/>2136

</xsd:extension>2137</xsd:simpleContent>2138

</xsd:complexType>2139</xsd:element>2140<xsd:element name = "SendingProtocol">2141


<xsd:extension base = "xsd:string">2144<xsd:attribute name = "version" type = "xsd:string"/>2145


</xsd:complexType>2148</xsd:element>2149<xsd:element name = "Protocol" type = "xsd:string"/>2150<xsd:element name = "CollaborationRole">2151


<xsd:element ref = "ProcessSpecification"/>2154



<xsd:element ref = "Role"/>2155<xsd:element ref = "CertificateRef" minOccurs = "0"/>2156<xsd:element ref = "ServiceBinding" maxOccurs = "unbounded"/>2157

</xsd:sequence>2158<xsd:attribute name = "roleId" use = "required" type = "xsd:ID"/>2159

</xsd:complexType>2160</xsd:element>2161<xsd:element name = "PartyInfo">2162


<xsd:element ref = "PartyId" maxOccurs = "unbounded"/>2165<xsd:element ref = "PartyRef"/>2166<xsd:element ref = "CollaborationRole" maxOccurs = "unbounded"/>2167<xsd:element ref = "Certificate" maxOccurs = "unbounded"/>2168<xsd:element ref = "DeliveryChannel" maxOccurs = "unbounded"/>2169<xsd:element ref = "Transport" maxOccurs = "unbounded"/>2170<xsd:element ref = "DocExchange" maxOccurs = "unbounded"/>2171

</xsd:sequence>2172</xsd:complexType>2173

</xsd:element>2174<xsd:element name = "PartyId">2175


<xsd:extension base = "xsd:string">2178<xsd:attribute name = "type" type = "xsd:string"/>2179


</xsd:complexType>2182</xsd:element>2183<xsd:element name = "PartyRef">2184

<xsd:complexType>2185<xsd:sequence/>2186<xsd:attribute name = "xlink:type" use = "fixed" value = "simple">2187

<xsd:simpleType>2188<xsd:restriction base = "xsd:NMTOKEN">2189

<xsd:enumeration value = "simple"/>2190</xsd:restriction>2191

</xsd:simpleType>2192</xsd:attribute>2193<xsd:attribute name = "xlink:href" use = "required" type = "xsd:string"/>2194

</xsd:complexType>2195</xsd:element>2196<xsd:element name = "DeliveryChannel">2197


<xsd:element ref = "Characteristics"/>2200</xsd:sequence>2201<xsd:attribute name = "channelId" use = "required" type = "xsd:ID"/>2202<xsd:attribute name = "transportId" use = "required" type = "xsd:IDREF"/>2203<xsd:attribute name = "docExchangeId" type = "xsd:IDREF"/>2204

</xsd:complexType>2205</xsd:element>2206<xsd:element name = "Transport">2207


<xsd:element ref = "SendingProtocol"/>2210<xsd:element ref = "ReceivingProtocol"/>2211<xsd:element ref = "Endpoint" maxOccurs = "unbounded"/>2212<xsd:element ref = "TransportSecurity" minOccurs = "0"/>2213

</xsd:sequence>2214<xsd:attribute name = "transportId" use = "required" type = "xsd:ID"/>2215

</xsd:complexType>2216</xsd:element>2217<xsd:element name = "Endpoint">2218

<xsd:complexType>2219<xsd:sequence/>2220<xsd:attribute name = "uri" use = "required" type = "xsd:uriReference"/>2221<xsd:attribute name = "type" use = "default" value = "allPurpose">2222


<xsd:enumeration value = "login"/>2225



<xsd:enumeration value = "request"/>2226<xsd:enumeration value = "response"/>2227<xsd:enumeration value = "error"/>2228<xsd:enumeration value = "allPurpose"/>2229

</xsd:restriction>2230</xsd:simpleType>2231

</xsd:attribute>2232</xsd:complexType>2233

</xsd:element>2234<xsd:element name = "TransportEncoding" type = "xsd:string"/>2235<xsd:element name = "Retries" type = "xsd:string"/>2236<xsd:element name = "RetryInterval" type = "xsd:timePeriod"/>2237<xsd:element name = "TransportSecurity">2238


<xsd:element ref = "Protocol"/>2241<xsd:element ref = "CertificateRef" minOccurs = "0"/>2242


</xsd:element>2245<xsd:element name = "Certificate">2246


<xsd:element ref = "ds:KeyInfo"/>2249</xsd:sequence>2250<xsd:attribute name = "certId" use = "required" type = "xsd:ID"/>2251

</xsd:complexType>2252</xsd:element>2253<xsd:element name = "DocExchange">2254


<xsd:element ref = "ebXMLBinding"/>2257</xsd:sequence>2258<xsd:attribute name = "docExchangeId" type = "xsd:ID"/>2259

</xsd:complexType>2260</xsd:element>2261<xsd:element name = "ReliableMessaging">2262

<xsd:complexType>2263<xsd:sequence minOccurs = "0">2264

<xsd:element ref = "Retries"/>2265<xsd:element ref = "RetryInterval"/>2266

</xsd:sequence>2267<xsd:attribute name = "deliverySemantics" use = "required">2268


<xsd:enumeration value = "OnceAndOnlyOnce"/>2271<xsd:enumeration value = "BestEffort"/>2272


</xsd:attribute>2275<xsd:attribute name = "idempotency" use = "required" type =2276

"xsd:boolean"/>2277</xsd:complexType>2278

</xsd:element>2279<xsd:element name = "NonRepudiation">2280


<xsd:element ref = "Protocol"/>2283<xsd:element ref = "HashFunction"/>2284<xsd:element ref = "SignatureAlgorithm"/>2285<xsd:element ref = "CertificateRef"/>2286


</xsd:element>2289<xsd:element name = "HashFunction" type = "xsd:string"/>2290<xsd:element name = "EncryptionAlgorithm" type = "xsd:string"/>2291<xsd:element name = "SignatureAlgorithm" type = "xsd:string"/>2292<xsd:element name = "DigitalEnvelope">2293


<xsd:element ref = "Protocol"/>2296



<xsd:element ref = "EncryptionAlgorithm"/>2297<xsd:element ref = "CertificateRef"/>2298


</xsd:element>2301<xsd:element name = "ProcessSpecification">2302


<xsd:element ref = "ds:Reference"/>2305</xsd:sequence>2306<xsd:attribute name = "version" use = "required" type = "xsd:string"/>2307<xsd:attribute name = "name" use = "required" type = "xsd:string"/>2308

</xsd:complexType>2309</xsd:element>2310<xsd:element name = "CertificateRef">2311


<xsd:extension base = "xsd:string">2314<xsd:attribute name = "certId" type = "xsd:IDREF"/>2315


</xsd:complexType>2318</xsd:element>2319<xsd:element name = "MessageEncoding">2320


<xsd:extension base = "xsd:string">2323<xsd:attribute name = "version" use = "required" type =2324

"xsd:string"/>2325<xsd:attribute name = "packagingType" type = "xsd:string"/>2326


</xsd:complexType>2329</xsd:element>2330<xsd:element name = "ebXMLBinding">2331


<xsd:element ref = "MessageEncoding" minOccurs = "0"/>2334<xsd:element ref = "ReliableMessaging" minOccurs = "0"/>2335<xsd:element ref = "NonRepudiation" minOccurs = "0"/>2336<xsd:element ref = "DigitalEnvelope" minOccurs = "0"/>2337<xsd:element ref = "NamespaceSupported" maxOccurs = "unbounded"/>2338

</xsd:sequence>2339<xsd:attribute name = "version" use = "required" type = "xsd:string"/>2340

</xsd:complexType>2341</xsd:element>2342<xsd:element name = "ds:KeyInfo">2343

<xsd:complexType>2344<xsd:sequence/>2345

</xsd:complexType>2346</xsd:element>2347<xsd:element name = "ds:Signature">2348


</xsd:complexType>2351</xsd:element>2352<xsd:element name = "NamespaceSupported">2353


<xsd:extension base = "xsd:uriReference">2356<xsd:attribute name = "schemaLocation" type =2357

"xsd:uriReference"/>2358<xsd:attribute name = "version" use = "required" type =2359

"xsd:string"/>2360</xsd:extension>2361

</xsd:simpleContent>2362</xsd:complexType>2363

</xsd:element>2364<xsd:element name = "Characteristics">2365




<xsd:attribute name = "nonrepudiationOfOrigin" type = "xsd:boolean"/>2368<xsd:attribute name = "nonrepudiationOfReceipt" type = "xsd:boolean"/>2369<xsd:attribute name = "secureTransport" type = "xsd:boolean"/>2370<xsd:attribute name = "confidentiality" type = "xsd:boolean"/>2371<xsd:attribute name = "authenticated" type = "xsd:boolean"/>2372<xsd:attribute name = "authorized" type = "xsd:boolean"/>2373

</xsd:complexType>2374</xsd:element>2375<xsd:element name = "ServiceBinding">2376


<xsd:element ref = "Packaging" maxOccurs = "unbounded"/>2379<xsd:element ref = "Override" minOccurs = "0"/>2380

</xsd:sequence>2381<xsd:attribute name = "channelId" use = "required" type = "xsd:ID"/>2382<xsd:attribute name = "name" type = "xsd:string"/>2383

</xsd:complexType>2384</xsd:element>2385<xsd:element name = "CPAType">2386


<xsd:element ref = "Protocol"/>2389<xsd:element ref = "Type"/>2390


</xsd:element>2393<xsd:element name = "Status">2394

<xsd:complexType>2395<xsd:sequence/>2396<xsd:attribute name = "value" use = "required">2397


<xsd:enumeration value = "signed"/>2400<xsd:enumeration value = "proposed"/>2401


</xsd:attribute>2404</xsd:complexType>2405

</xsd:element>2406<xsd:element name = "Start" type = "xsd:timeInstant"/>2407<xsd:element name = "Duration" type = "xsd:timePeriod"/>2408<xsd:element name = "Type" type = "xsd:string"/>2409<xsd:element name = "ConversationConstraints">2410

<xsd:complexType>2411<xsd:sequence/>2412<xsd:attribute name = "invocationLimit" type = "xsd:int"/>2413<xsd:attribute name = "concurrentConversations" type = "xsd:int"/>2414

</xsd:complexType>2415</xsd:element>2416<xsd:element name = "Override">2417

<xsd:complexType>2418<xsd:sequence/>2419<xsd:attribute name = "action" type = "xsd:string"/>2420<xsd:attribute name = "channelId" use = "required" type = "xsd:ID"/>2421<xsd:attribute name = "xlink:href" type = "xsd:string"/>2422<xsd:attribute name = "xlink:type" use = "fixed" value = "simple">2423


<xsd:enumeration value = "simple"/>2426</xsd:restriction>2427

</xsd:simpleType>2428</xsd:attribute>2429

</xsd:complexType>2430</xsd:element>2431<xsd:element name = "Role">2432


<xsd:extension base = "xsd:string">2435<xsd:attribute name = "name" type = "xsd:string"/>2436<xsd:attribute name = "xlink:href" type = "xsd:string"/>2437<xsd:attribute name = "xlink:type" use = "fixed" value =2438



"simple">2439<xsd:simpleType>2440

<xsd:restriction base = "xsd:NMTOKEN">2441<xsd:enumeration value = "simple"/>2442


</xsd:attribute>2445</xsd:extension>2446

</xsd:simpleContent>2447</xsd:complexType>2448

</xsd:element>2449<xsd:element name = "SecurityRisks" type = "xsd:string"/>2450<xsd:element name = "SecurityBenefits" type = "xsd:string"/>2451<xsd:element name = "Packaging">2452

<xsd:complexType>2453<xsd:sequence maxOccurs = "unbounded">2454

<xsd:element ref = "ProcessingCapabilities"/>2455<xsd:element ref = "SimplePart" maxOccurs = "unbounded"/>2456<xsd:element ref = "CompositeList" minOccurs = "0"/>2457


</xsd:element>2460<xsd:element name = "Comment">2461


</xsd:complexType>2464</xsd:element>2465<xsd:element name = "Composite">2466


<xsd:element ref = "Constituent" maxOccurs = "unbounded"/>2469</xsd:sequence>2470<xsd:attribute name = "mimetype" use = "required" type = "xsd:string"/>2471<xsd:attribute name = "id" use = "required" type = "xsd:string"/>2472<xsd:attribute name = "mimeparameters" type = "xsd:string"/>2473

</xsd:complexType>2474</xsd:element>2475<xsd:element name = "Constituent">2476

<xsd:complexType>2477<xsd:sequence/>2478<xsd:attribute name = "idref" use = "required" type = "xsd:string"/>2479

</xsd:complexType>2480</xsd:element>2481<xsd:element name = "Encapsulation">2482


<xsd:element ref = "Constituent"/>2485</xsd:sequence>2486<xsd:attribute name = "mimetype" use = "required" type = "xsd:string"/>2487<xsd:attribute name = "id" use = "required" type = "xsd:string"/>2488<xsd:attribute name = "mimeparameters" type = "xsd:string"/>2489

</xsd:complexType>2490</xsd:element>2491<xsd:element name = "CompositeList">2492

<xsd:complexType>2493<xsd:choice maxOccurs = "unbounded">2494

<xsd:element ref = "Encapsulation"/>2495<xsd:element ref = "Composite"/>2496

</xsd:choice>2497</xsd:complexType>2498

</xsd:element>2499<xsd:element name = "XMLMetaDataInformation">2500

<xsd:complexType>2501<xsd:sequence/>2502<xsd:attribute name = "URI" type = "xsd:string"/>2503<xsd:attribute name = "MetaDataDescriptionType" use = "required">2504


<xsd:enumeration value = "dtd"/>2507<xsd:enumeration value = "xsd"/>2508

</xsd:restriction>2509



</xsd:simpleType>2510</xsd:attribute>2511

</xsd:complexType>2512</xsd:element>2513<xsd:element name = "MimeHeader">2514

<xsd:complexType>2515<xsd:sequence/>2516<xsd:attribute name = "HeaderName" use = "required" type = "xsd:string"/>2517

</xsd:complexType>2518</xsd:element>2519<xsd:element name = "MimeParameter">2520

<xsd:complexType>2521<xsd:sequence/>2522<xsd:attribute name = "parameterAttribute" use = "required" type =2523

"xsd:string"/>2524<xsd:attribute name = "parameterValue" type = "xsd:string"/>2525

</xsd:complexType>2526</xsd:element>2527<xsd:element name = "SimplePart">2528

<xsd:complexType>2529<xsd:sequence/>2530<xsd:attribute name = "id" use = "required" type = "xsd:string"/>2531<xsd:attribute name = "mimetype" use = "required" type = "xsd:string"/>2532

</xsd:complexType>2533</xsd:element>2534<xsd:element name = "ProcessingCapabilities">2535

<xsd:complexType>2536<xsd:sequence/>2537<xsd:attribute name = "parse" use = "required" type = "xsd:string"/>2538<xsd:attribute name = "generate" use = "required" type = "xsd:string"/>2539

</xsd:complexType>2540</xsd:element>2541<xsd:element name = "ds:Reference">2542


</xsd:complexType>2545</xsd:element>2546

</xsd:schema>2547



Appendix E Formats of Infor mation in the CPP and CPA2548

(Normative)2549

This section defines format information that is not defined by the [XML] specification and is not2550defined in the descriptions of specific elements.2551

2552Formats of Character Strings2553

2554Protocol and Version Elements2555

2556Values of Protocol, Version, and similar elements are flexible. In general, any protocol and2557version for which the support software is available to both Parties to a CPA may be selected as2558long as the choice does not require changes to the DTD or schema and therefore a change to this2559specification.2560

2561NOTE: A possible implementation may be based on the use of plug-ins or exits to2562support the values of these elements.2563

2564Alphanumeric Strings2565

2566Alphanumeric strings not further defined in this section follow these rules unless otherwise2567stated in the description of an individual element:2568

2569� Values of elements are case insensitive unless otherwise stated.2570� Strings which represent file or directory names are case sensitive to ensure that they are2571

acceptable to both UNIX and Windows systems.25722573

Numeric Strings25742575

A numeric string is a signed or unsigned decimal integer in the range imposed by a 32-bit binary2576number, i.e. -2,147,483,648 to +2,417,483,647. Negative numbers may or may not be permitted2577in particular elements.2578



Appendix F Composing a CPA from Two CPPs (Non-2579

Normative)2580

2581Overview and Limitations2582

2583In this appendix, we discuss the tasks involved in CPA formation from CPPs. The detailed2584procedures for CPA formation are currently left for implementers. Therefore, no normative2585specification is provided for algorithms for CPA formation. In this initial section, we provide2586some background on CPA formation tasks.2587

2588There are three basic reasons why we prefer to provide information about the component tasks2589involved in CPA formation rather than attempt to provide an algorithm for CPA formation:2590

25911. The precise informational inputs to the CPA formation procedure vary.25922. There exist at least two distinct approaches to CPA formation. One useful approach for2593

certain situations involves basing CPA formation from a CPA template; the other approach2594involves composition from CPPs.2595

3. The conditions for output of a given CPA given two CPPs can involve different levels and2596extents of interoperability. In other words, when an optimal solution that satisfies every level2597of requirement and every other additional constraint does not exist, a Party may propose a2598CPA that satisfies enough of the requirements for “a good enough” implementation. User2599input may be solicited to determine what is a good enough implementation, and so may be as2600varied as there are user configuration options to express preferences. In practice,2601compromises may be made on security, reliable Messaging, levels of signals and2602acknowledgements, and other matters in order to find some acceptable means of doing2603business.2604

2605Each of these reasons is elaborated in greater detail in the following sections.2606

26072608

Variability in Inputs26092610

User preferences provide one source of variability in the inputs to the CPA formation process.2611Let us suppose in this section that each of the Parties has made its CPP available to potential2612collaborators. Normally one Party will have a desired Collaboration Protocol (defined in a2613Process-Specification Document) to implement with its intended collaborator. So the information2614inputs will normally involve a user preference about intended Collaboration Protocols in2615addition to just the CPPs.2616

2617A CPA formation tool may have access to local user information not advertised in the CPP that2618may contribute to the CPA that is formed. A user may have chosen to only advertise those2619system capabilities that reflect nondeprecated capabilities. For example, a user may only2620advertize HTTP and omit FTP, even when capable of using FTP, because of concerns about the2621scalability of managing user accounts, directories, and passwords for FTP sessions. Despite not2622



advertising a FTP capability, configuration software may use tacit knowledge about its own FTP2623capability to form a CPA with an intended collaborator who happens to have only a FTP2624capability for implementing a desired business collaboration. In other words, business interests2625may, in this case, override the deprecation policy. Both tacit knowledge as well as detailed2626preference information account for variability in inputs into the CPA formation process.2627

26282629

Different Approaches26302631

When a CPA is formed from a CPA template, it is typically because the capabilities of one of the2632Parties are limited, and already tacitly known. For example, if a CPA template were implicitly2633presented to a Web browser for use in an implementation using browser based forms capabilities,2634then the template maker can assume that the other Party has suitable web capabilities (or is about2635to download them). Therefore, all that really needs to be done is to supply PartyRef, Certificate,2636and similar items for substitution into a CPA template. The CPA template will already have all2637the capabilities of both Parties specified at the various levels, and will have placeholders for2638values to be supplied by one of the Partners. A simple form might be adequate to gather the2639needed information and produce a CPA.2640

26412642

Variable Output “Satisficing” Policies26432644

A CPA can support a fully interoperable configuration in which agreement has been reached on2645all technical levels needed for business collaboration. In such a case, matches in capabilities will2646have been found in all relevant technical levels.2647

2648However, there can be interoperable configurations agreed to in a CPA in which not all aspects2649of a business collaboration match. Gaps may exist in packaging, security, signaling, reliable2650Messaging and other areas and yet the systems can still transport the business data, and special2651means can be employed to handle the exceptions. In such situations, a CPA may reflect2652configured policies or expressly solicited user permission to ignore some shortcomings in2653configurations. A system may not be capable of responding in a business collaboration so as to2654support a recommended ability to supply nonrepudiation of receipt, but might still be acceptable2655for business reasons. A system might not be able to handle all the processing required to support2656“multipart/related” processing with a type value of “application/vnd.eb+xml,” and yet still be2657able to treat the multipart according to “multipart/mixed” handling and allow business2658collaboration to take place. In fact, short of a failure to be able to transport data and a failure to2659be able to provide data relevant to the business process, there are few features that might not be2660temporarily or indefinitely compromised about, given overriding business interests. This2661situation of “partial interoperability” is to be expected to persist for some time, and so interferes2662with formulating a “clean” algorithm for deciding on what is sufficient for interoperability.2663

2664In summary, the previous considerations indicate that at the present it is at best premature to seek2665a simple algorithm for CPA formation from CPPs. It is to be expected that as capability2666characterization and exchange becomes a more refined subject, that advances will be made in2667characterizing CPA formation and negotiation.2668



2669Despite it being too soon to propose a simple algorithm for CPA formation that covers all the2670above variations, it is currently possible to enumerate the basic tasks involved in matching2671capabilities within CPPs. This information MAY assist the software implementer in designing a2672partially automated and partially interactive software system useful for configuring business2673collaboration so as to arrive at satisfactorily complete levels of interoperability. To understand2674the context for characterizing the constituent tasks, the general perspective on CPPs and CPAs2675needs to be briefly recalled.2676

26772678

CPA Formation Component Tasks26792680

Technically viewed, a CPA provides “bindings” between business process (BP) specifications (as2681defined in the Process-Specification Document) and those services and protocols that are used to2682implement these BP specifications. The implementation takes place at several levels and2683involves varied services at these levels. A CPA that arrives at a fully interoperable binding of a2684BP to its implementing services and protocols can be thought of as arriving at interoperable,2685application-to-application integration. CPAs may fall short of this goal and still be useful and2686acceptable to the collaborating Parties. Certainly, if no matching data transport capabilities can2687be discovered, a CPA would not provide much in the way of interoperable business-to-business2688integration. Likewise, partial CPAs will leave significant system work to be done before a2689completely satisfactory application to application level integration is realized. Even so, partial2690integration may be sufficient to allow collaboration, and to enjoy payoffs from increased levels2691of automation.2692

2693In practice, the CPA formation process may produce a complete CPA, a failure result, a gap list2694that drives a dialog with the user, or perhaps even a CPA that implements partial interoperability2695“good enough” for the business collaborators. Because both matching capabilities and2696interoperability can be matters of degree, the constituent tasks are finding the matches in2697capabilities at different levels and for different services. We next proceed to characterize many2698of these constituent tasks.2699

27002701

CPA Formation from CPPs: Enumeration of Tasks27022703

To simplify discussion, assume in the following that we are viewing the tasks faced by a2704software agent when:2705

1. an intended collaborator is known and the collaborator's CPP has been retrieved,27062. the business process between us and our intended collaborator has been selected,27073. the specific role that our software agent is to play in the BP is known, and27084. the capabilities that are to be advertised in our CPP are known.2709

2710For vividness, we will suppose that our example agent wishes to play the role of supplier and2711seeks to find one of its current customers to begin a Purchase Order business process in which2712the intended player plays a complementary role. For simplicity, we assume that the information2713about capabilities is restricted to what is available in our agent’s CPP and in the CPP of its2714



intended collaborator.27152716

In general, the constituent tasks consist of finding “matches” between our capabilities and our2717intended collaborator’s at the various levels of the protocol stacks and with respect to the2718services supplied at these various levels.2719

2720The first task to be considered is certainly the most basic: finding that our intended collaborator2721and ourselves have matching role capabilities.2722

27232724

Matching Roles27252726

Our agent has its role already selected in the BP. So it now begins to check the Roles in its2727collaborator’s CPP. The first element to examine is the PartyInfo element that contains a subtree2728of elements called CollaborationRole. This set is searched to discover a role that complements2729the role of our agent within the BP that we have chosen. For simple binary collaboration cases, it2730is typically sufficient to find our intended collaborator’s CollaborationRole set contains2731ProcessSpecification elements that we intend to implement and where the role is not identical to2732our role. For more general collaborations, we would need to know the list of roles available2733within the process, and keep track that for each of the collaborators, the roles chosen instantiate2734those that have been specified within the Process-Specification Document. Collaborations2735involving more than two roles are not discussed further.2736

27372738

Matching Transport27392740

We now have available a list of candidate CollaborationRole elements with the desired2741ProcessSpecification element(Purchase Ordering) and where our intended collaborator plays the2742buyer role. For simplicity, we shall suppose just one CollaborationRole element meets these2743conditions within each of the relevant CPPs and not discuss iterating over lists. (Within these2744remarks, where repetition is possible, we will frame the discussion by assuming that just one2745element is present.)2746

2747Matching transport first means matching the SendingProtocol capabilities of our intended2748collaborator with the ReceivingProtocol capabilities found on our side. Perusal of the CPP DTD2749or Schemas will reveal that the ServiceBinding element provides the doorway to the relevant2750information from each side’s CollaborationRole element with the channelId attribute. This2751channelId attribute’s value allows us to find DeliveryChannels within each CPP. The2752DeliveryChannel has a transportId attribute that allows us to find the relevant Transport2753subtrees.2754

2755For example, suppose that our intended buyer has a Tranport entry:2756

2757<Transport transportId = "buyerid001">2758

<SendingProtocol>HTTP</SendingProtocol>2759<ReceivingProtocol>2760HTTP2761



</ReceivingProtocol>2762<Endpoint uri = "https://www.buyername.com/po-response"2763

type = "allPurpose"/>27642765

<TransportSecurity>2766<Protocol version = "1.0">TLS</Protocol>2767<CertificateRef certId = certid001">BuyerName</CertificateRef>2768


2771and our seller has a Transport entry:2772

2773<Transport transportId = "sellid001">2774

<SendingProtocol>HTTP</SendingProtocol>2775<ReceivingProtocol>2776HTTP2777</ReceivingProtocol>2778<Endpoint uri = "https://www.sellername.com/pos_here"2779

type = "allPurpose"/>2780<TransportSecurity>2781

<Protocol version = "1.0">TLS</Protocol>2782<CertificateRef certId =”certid002">Sellername</CertificateRef>2783


2786A transport match for requests involves finding the initiator role or buyer has a SendingProtocol2787that matches one of our ReceivingProtocols. So here, “HTTP” provides a match. A transport2788match for responses involves finding the responder role or seller has a SendingProtocol that2789matches one of the buyer’s ReceivingProtocols. So in the above example, “HTTP” again2790provides a match. When such matches exist, we then have discovered an interoperable solution at2791the transport level. If not, no CPA will be available, and a high-priority gap has been identified2792that will need to be remedied by whatever exception handling procedures are in place.2793

27942795

Matching Transport Security27962797

Matches in transport security, such as in the above, will reflect agreement in versions and values2798of protocols. Software can supply some knowledge here so that if one side has SSL-3 and the2799other TLS-1, it can guess that security is available by means of a fallback of TLS to SSL.2800

28012802

Matching Document Packaging28032804

Probably one of the most complex matching problems arises when it comes to finding whether2805there are matches in Document packaging capabilities. Here both security and other MIME2806handling capabilities can combine to create complexity for appraising whether full2807interoperability can be attained.2808

2809Access to the information needed for undertaking this task is found under the ServiceBinding2810elements, and again we suppose that each side has just one ServiceBinding entry. However, we2811



will initially suppose that two Packaging elements are available to consider under each role.2812Several quite different ways of thinking about the matching task are available, and several2813methods for the tasks may be performed when assessing whether a good enough match exists.2814

2815To continue our previous purchase-ordering example, we recall that the packaging is the2816particular combination of body parts, XML instances (headers and payloads), and security2817encapsulations used in assembling the Message from its data sources. Both requests and2818responses will have packaging. The most complete specification of packaging, which may not2819always be needed, would consist of:2820

28211. the buyer asserting what packaging it can generate for its purchase order, and what2822

packaging it can parse for its purchase order response Messages.28232. the seller asserting what packaging it can generate for its purchase order responses and2824

what packaging it can parse for received purchase orders.28252826

Matching by structural comparison would then involve comparing the packaging details of the2827purchase orders generated by the seller with the purchase orders parsable by the buyer. The2828comparison would seek to establish that the MIME types of the SimpleParts of corresponding2829subtrees match and would then proceed to check that the CompositeList matched in MIME types2830and in sequence of composition.2831

2832For example, if each CPP contained the packaging subtrees below, and under the appropriate2833ServiceBindings, then there would be a straightforward match by structural comparison:2834

2835<Packaging>2836

<ProcessingCapabilities parse = "true" generate = "true"/>2837<SimplePart id = "P1" mimetype = "application/vnd.eb+xml"/>2838<SimplePart id = "P2" mimetype = "application/po+xml"/>2839<CompositeList>2840

<Composite mimetype = "multipart/related" id = "P3"2841mimeparameters = "type=application/eb+xml">2842<Constituent idref = "P1"/>2843<Constituent idref = "P2"/>2844

</Composite>2845</CompositeList>2846

</Packaging>2847<Packaging>2848

<ProcessingCapabilities parse = "true" generate = "true"/>2849<SimplePart id = "P11" mimetype = "application/vnd.eb+xml"/>2850<SimplePart id = "P12" mimetype = "application/po-ack+xml"/>2851<CompositeList>2852

<Composite mimetype = "multipart/related" id = "P13"2853mimeparameters = "type=application/eb+xml">2854<Constituent idref = "P11"/>2855<Constituent idref = "P12"/>2856

</Composite>2857</CompositeList>2858

</Packaging>28592860

However, it is to be expected that over time it may become possible to only assert what2861packaging is generated within each ServiceBinding for the requester and responder roles. This2862



simplification assumes that each side has knowledge of what MIME types it handles correctly,2863what encapsulations it handles correctly, and what composition modes it handles correctly. By2864scanning the packaging specifications against its lists of internal capabilities, it can then look up2865whether other side's generated packaging scheme is one it can process and accept it under those2866conditions. Knowing what generated packaging style was produced by the other side could2867enable the software agent to propose a packaging scheme using only the MIME types and2868packaging styles used in the incoming Message. Such a packaging scheme would be likely to be2869acceptable to the other side when included within a proposed CPA. Over time, and as proposal2870and negotiation conventions get established, it is to be expected that the methods used for2871determining a match in packaging capabilities will move away from structural comparison to2872simpler methods, using more economical representations.2873

2874In the near term, however, more explicit specifications and the more elaborate structural2875comparisons will be most likely to give trustworthy matching assessments.2876

28772878

Matching Document-Level Security28792880

Although the matching task for Document-level security is a subtask of the Packaging-matching2881task, it is useful to discuss some specifics tied to the three major Document-level security2882approaches found in [S/MIME], OpenPGP[RFC2015], and XMLDsig[XMLDSIG].2883

2884XMLDsig matching capability can be inferred from Document-matching capabilities when the2885use of ebXML TRP-style[MSSPEC] packaging is present. However, there are other sources that2886should be checked to confirm this match. The DeliveryChannel has a subtree under the2887DocExchange element that, for the ebXMLBinding element, has a NameSpacesSupported2888element. XMLDsig capability should be found there. Likewise, a detailed check on this match2889should examine the information under NonRepudiation to check for compatibility in hash2890functions and algorithms.2891

2892The existence of several radically different approaches to Document-level security, together with2893the fact that it is unusual at present for a given Party to commit to more than one form of such2894security, means that there can be basic failures to match security frameworks. Therefore, no2895match in capabilities that supports full interoperability at all levels. For the moment, we assume2896that Document-level security matches will require both sides able to handle the same security2897composites (multipart/signed using S/MIME, for example.)2898

2899However, suppose that there are matches at the transport and transport layer security levels, but2900that the two sides have failures at the Document security level because one side makes use of2901PGP signatures while the other uses S/MIME. Does this mean that no CPA can be proposed?2902That is not necessarily the case.2903

2904Both S/MIME and OpenPGP permit signatures to be packaged within “multipart/signed”2905composites. In such a case, it may be possible to extract the data and arrive at a partial2906implementation that falls short with respect to nonrepudiation. While neither side could check2907the other's signatures, it might still be possible to have confidential document transmission and2908



transport-level authentication for the business data. Eventually CPA-formation software may be2909created that is able to identify these exceptional situations and “salvage” a proposed CPA with2910downgraded security features. Whether the other side would accept such a proposed CPA would,2911naturally, involve what their preferences are with respect to initiating a business collaboration2912and sacrificing some security features. CPA-formation software may eventually be capable of2913these adaptations, but it is to be expected that human assistance will be required for such2914situations in the near term.2915

2916Of course, an implementation may simply decide to terminate looking for a CPA when a match2917fails in any crucial factor for an interoperable implementation. At the very least, the users should2918be warned that the only CPAs that can be proposed will be missing security or other normally2919desirable features or features recommended by the BP’s Process Specification.2920

2921Other Considerations2922

2923Handling Preferences among Multiple Matching Capabilities.2924

29251. Tiebreaker on preferences needed.29262. Ranking: can convert ranks to numerical order, add values, lowest value wins, and tie2927

values goes to that one of the lowest value that reflects the BP responder values.29282929293029312932



Appendix G Mapping of CPA Constructs to ebXML Message2933

Header (Normative)2934

This appendix will describe how specific constructs defined in the CPA are mapped to the2935ebXML Message header defined by the ebXML Messaging Service Specification [MSSPEC].2936

2937The contents of this appendix will be supplied for the next round of public review.2938