current status ebxml cppa tc

50 %
50 %
Information about current status ebxml cppa tc

Published on October 29, 2007

Author: WoodRock


Slide1:  April 18th, 2002 Electronic Commerce Promotion Council of Japan (ECOM) 5th ebXML Asia Committee Taipei meeting Current Status of OASIS ebXML CPPA TC Slide2:  General Report of the latest OASIS ebXML CPPA F2F Meeting (January 28-30 2002, San Francisco in USA) (1/2) 1. Participants (13 people) ・Dale Moberg Cyclone Commerce, Leader of CPPA TC ・Marty Sachs IBM, Leader of previous ebXML Initiative TP team ・Arvola Chan TIBCO, Member of RosettaNet, ebXML MSG TC ・Brian Hayes Commerce One, Leader of ebTWG BPSS group ・Himagiri Mukkamura SYBASE ・Peter Ogden Cyclone Commerce ・Kevin Liu SAP ・Selim Aissi Intel ・Pallavi Malu Intel, Member of ebTWG BPSS group ・Jean Zheng Vitria ・Yukinori Saito ECOM (Remote) ・David Fisher Drumond Gr. Key member of ebXML MSG TC ・Jamie 2. General Proceedings (1/2) (1) Main discussion points are examination and confirmation about next version of CPPA specification. There are about 230 issue items (Issue List), and all the items were reviewed. (2) CPPA spec. is closely related to MSG (Messaging service) and BPSS (Business process specification schema). Descriptions of relationship with these specifications are described in CPPA spec. (3) The next official version number of CPPA will be V2.0. Reason: -Version no. of MSG and Registry is V2.0. -There are many changes in next version of CPPA. Slide3:  (4) Negotiation specification ・Draft of Requirement specification was made already. ・Planning of making specification and confirmed who will be charged. -Specification of the negotiation process (Definition of the negotiation verbs, Message envelope structure, Message Schema) -Sample NCPA NCPA: CPA for negotiation -Sample NDD NDD (Negotiation Data Descriptor): CPP for negotiation -Tutorial for implementers -Best-Practice document if appropriate (5) Future Development items (supposed to be V3.0) ・Study specifications about security and involve them in CPPA -SAML (OASIS), XML encryption (W3C), XACML (OASIS), XKMS (W3C) ・Context and BP level agreement ・WSDL convergence ・Intermediaries and Multiparty ・Supporting Specifications e.g. Tutorial and Implementation guide ・SME simplification e.g. Dynamic negotiation, Template of CPA ・BSI (Business Service Interface) efforts. This will be proposed to W3C. General Report of the latest OASIS ebXML CPPA F2F Meeting (January 28-30 2002, San Francisco in USA) (2/2) 2. General Proceedings (2/2) Slide4:  The Latest Status of OASIS ebXML CPPA TC (CPPA TC Teleconference, April 5, 2002) 1. Coordination with WSDL Karl Best (OASIS) asked CPPA TC to consider what coordination between our activities and W3C activities might be beneficial. Dale noted that we have explicit dependencies on XMLDsig, Xlink (and its dependencies, such as XPath), and of course on XML and XML Schema specifications. No special need for coordination was identified for these dependencies. CPPA TC agreed that it might be beneficial if CPPA and WSDL were in some way coordinated or put together. It was noted that there is a sub team pursuing research on how that integration can occur, and several CPPA members (Kevin, Pallavi, and Dale) participate in the WSDL WG.   Arvola also noted that the Architecture WG within the Web Services activity is also relevant to CPPA, and there was agreement that we should monitor developments in that group also. 3. Next F2F meeting ・Possibly June 3-5 2. Schedule of CPPA Spec. ・Reviewing current draft (V1.11) within CPPA TC members until April 19, 2002 ・Public review (Supposed to be May, 2002) ・Submit to OASIS for approval (Supposed to be early June) ・90 days Official Review in OASIS organization  (Supposed to be July, August, and September) Slide5:  Information of CPPA TC Activities 1. Specification 2. XML Schema and Examples ・The latest Version is V1.11. ・Everyone can see the current draft in CPPA Web site. ・The latest schema and example files are available to see in the following page. -XML Schema of ebXML BPSS -XML Schema of ebXML CPPA -Example of Process-Specification Document, CPP (Company A and B), and CPA 4. E-mail lists ・In keeping with OASIS' policy of open discussions, the archives of all TC lists may be viewed by the public; go to 3. Meeting Minutes General Explanation of CPPA Specification and related Specifications:  General Explanation of CPPA Specification and related Specifications ・CPPA (Collaboration-Protocol Profile and Agreement Specification) V1.11 (draft-bpss-example-017) (draft-cpp-example-companyA-017.xml) (draft-cpp-example-companyB-017.xml) (draft-cpa-example-017.xml) ・MSG (Message Service Specification) V2.0 ・BPSS (Business Process Specification Schema) V1.02 April 10, 2002 Based on: Relationship between BPSS, CPPA, and MSG Examples of BPSS, CPP/CPA, and MSG Header Slide7:  Business Process and Information Model ebXML Process-Specification Document ebXML CPP/CPA ebXML Business Service Interface Configuration Process-Specification Document and Business Service Interface Configuration Using Business Process Modeling, a user may create a complete Business Process and Information Model. Based on this Business Process and Information Model and using the ebXML Business Process Specification Schema the user will then extract and format the nominal set of elements necessary to configure an ebXML runtime system in order to execute a set of ebXML business transactions. The result is an ebXML Process-Specification Document. Alternatively the ebXML Process-Specification Document may be created directly, without prior explicit business process modeling. An ebXML Process-Specification Document contains the specification of Business Transactions and the choreography of Business Transactions into Business Collaborations. This ebXML Process-Specification Document is then the input to the formation of ebXML Collaboration-Protocol Profiles and Collaboration-Protocol Agreements. These ebXML Collaboration-Protocol Profiles and Collaboration-Protocol Agreements in turn serve as configuration files (e.g. Messaging Header) for ebXML Business Service Interface software. Slide8:  An user create Process-Specification Document supposed to be used some Buyers and Sellers. Usually, Process-Specification Document is created by Service unit. (e.g. each RosettaNet PIP) Process-Specification Document describes choreography of Business Transactions and role of Parties. Creation of Process-Specification Document Creation of CPP(Company A) and CPP(Company B) A buyer creates CPP (Company A) based on ebXML CPPA Specification, In case of Business process scenarios, CPP points Process-Specification Document by URI. (Head of Process-Specification Document and position of Role element) And the buyer describe many CPP information. (ServiceBinding, DeliveryChannel, Transport, DocExchange, Packaging) Also, a Seller create CPP (Company B) like the same way. Creation of CPA between Company A and B In usual case, The buyer creates CPA together with CPP (A) and CPP (B). The relationship between CPA and Process-Specification Document is same as CPP. That is, some URI under ProcessSpecification element and Role element point to suitable position of Process-Specification Document General Procedure to create Process-Specification Document, CPP, and CPA Slide9:  Relationship between Process-Specification Document, CPP, and CPA <ProcessSpecification uuid= <BusinessDocument name= <BusinessTransaction name= <RequestingBusinessActivity <RespondingBusinessActivity <BinaryCollaboration name=“Request Purchase Order” <InitiationgRole name=“Buyer” <RespondingRole name=“Seller” Process-Specification Document (RosettaNet PIP3A4) <PartyInfo partyname=“CompanyA” <ProcessSpecification name=“PIP3A4 xlink:href=“ <Role name=“Buyer” xlink:href=://www-- <ServiceBinding <DeliveryChannel <PartyInfo partyname=“CompanyB” <ProcessSpecification name=“PIP3A4 xlink:href=“ <Role name=“Seller” xlink:href=://www-- <ServiceBinding <DeliveryChannel <PartyInfo partyname=“CompanyA” <ProcessSpecification name=“PIP3A4 xlink:href=“ <Role name=“Buyer” xlink:href=://www-- <ServiceBinding <DeliveryChannel <PartyInfo partyname=“CompanyB” <ProcessSpecification name=“PIP3A4 xlink:href=“ <Role name=“Seller” xlink:href=://www-- <ServiceBinding <DeliveryChannel CPP(CompanyA) CPP(CompanyB) CPA(CompanyA,B) Slide10:  Modifying Parameters of PSD (Process-Specification Document) based on information in the CPA A Process-Specification Document and CPP/CPA has same kinds of parameters. An example is Security attributes that are counterparts of the attributes of the CPA BusinessProcessSpecification element. When a CPA created, the Parties may decide to accept different value of these parameters. In this case, these parameters shall override the original values expressed in the Process-Specification Document. In this case, overridden Process-Specification Document should be a copy of the original Process-Specification Document. Because the original Process-Specification Document may be used some different parties. original Process-Specification Document Customized Process-Specification Document Public PSD for every party For special parties (e.g. company A,B) Customize CPA (A,B) Copy Slide11:  Examples of Process-Specification Document, CPP, and CPA These examples are supposed to be followings. ・Binary collaboration between 2 companies. (‘CompanyA’, and ‘CompanyB’) ・These companies do collaboration using the RosettaNet PIP3A4 as Business Process Scenarios. -PIP3A4 is recognized as ‘Service’ in the view point of BPSS. -PIP3A4 has two business actions. These are recognized as ‘Action’ in the view point of BPSS. ‘Purchase Order Request Action’ and ‘Purchase Order Confirmation Action’. Slide12:  Business Transaction Dialog of RosettaNet PIP3A4: Request Purchase Order (V02.00) Slide13:  Message Exchange Controls of RosettaNet PIP3A4 Slide14:  <ProcessSpecification xmlns= name="PIP3A4RequestPurchaseOrder"> <BusinessDocument name="Puchase Order Request“ nameID="Pip3A4PurchaseOrderRequest“ specificationLocation="PurchaseOrderRequest.xsd"> </BusinessDocument> <BusinessDocument name="Puchase Order Confirmation" nameID="Pip3A4PurchaseOrderConfirmation“ specificationLocation="PurchaseOrderConfirmation.xsd"> </BusinessDocument> <BusinessTransaction name="Request Purchase Order" nameID="RequestPurchaseOrder_BT"> <RequestingBusinessActivity name="Purchase Order Request Action" nameID="PurchaseOrderRequestAction“ isAuthorizationRequired="true" isNonRepudiationRequired="true"       timeToAcknowledgeReceipt="P0Y0M0DT2H0M0S"> <DocumentEnvelope businessDocument="Puchase OrderRequest“ businessDocumentIDRef="Pip3A4PurchaseOrderRequest" /> </RequestingBusinessActivity> <RespondingBusinessActivity name="Purchase Order Confirmation Action“ nameID="PurchaseOrderConfirmationAction" isAuthorizationRequired="true" isNonRepudiationRequired="true“ timeToAcknowledgeReceipt="P0Y0M0DT2H0M0S">   <DocumentEnvelope businessDocument="Purchase Order Confirmation“ businessDocumentIDRef="Pip3A4PurchaseOrderConfirmation" />   </RespondingBusinessActivity> </BusinessTransaction> <BinaryCollaboration name="Request Purchase Order" nameID="RequestPurchaseOrder_BC">   <InitiatingRole name="Buyer" nameID="BuyerId" />   <RespondingRole name="Seller" nameID="SellerId" />   <Start toBusinessState="Request Purchase Order" />   <BusinessTransactionActivity name="Request Purchase Order" nameID="RequestPurchaseOrder_BTA“ businessTransaction="Request Purchase Order"businessTransactionIDRef="RequestPurchaseOrder_BT“ fromAuthorizedRole="Buyer" fromAuthorizedRoleIDRef="BuyerId" toAuthorizedRole="Seller" toAuthorizedRoleIDRef="SellerId" timeToPerform="P0Y0M0DT24H0M0S"/>   </BinaryCollaboration> </ProcessSpecification> Example of Process-Specification Document (RosettaNet PIP3A4) ←Definition of Business Document (P.O.R.) ←Definition of Business Document (P.O.C.) Slide15:  This Process-Specification Document has 3 parts contents. (1)Business Document ・Two Business Documents are defined named ’Purchase Order Request’ and ‘Purchase Order Confirmation’. (2)Business Transaction ・One Business Transaction is defined named ‘Request Purchase Order’ in this Process-Specification Document. ・This Business Transaction has two actions named ’Purchase Order Request Action’ and ‘Purchase Order Confirmation Action’ under RequestingBusinessActivity element and RespondingBusinessActivity element. ・These BusinessActivity elements define associated Business Documents under DocumentEnvelope element. ・Some security parameters are defined under these BusinessActivity elements. e.g. isAuthorizationRequired, isNonRepudiationRequired, timeToAcknowledgeReceipt (3)Binary Collaboration ・One Binary Collaboration is defined named ‘Request Purchase Order’ in this Process-Specification Document. ・BinaryCollaboration element defines associated Business Transaction. -Under this element, Roles (‘Buyer’ and ‘Seller’) are defined. Some parameters related collaboration are defined. e.g. timeToPerform, isConcurrent Explanation of Example of Process-Specification Document Slide16:  <tp:CollaborationProtocolProfile xmlns:tp=""> <tp:PartyInfo tp:partyName="CompanyA" tp:defaultMshChannelId="asyncChannelA1"> <tp:PartyId tp:type="urn:oasis:names:tc:ebxml-cppa:partyid-type:duns">123456789</tp:PartyId> <tp:PartyRef xlink:href="" /> <tp:CollaborationRole tp:id="BuyerId"> <tp:ProcessSpecification tp:version="2.0" tp:name="PIP3A4RequestPurchaseOrder"xlink:type="simple“ xlink:href="" />   <tp:Role tp:name="Buyer" xlink:href="" /> <tp:ServiceBinding><tp:Service>$2.0</tp:Service> <tp:CanSend> <tp:ThisPartyActionBinding tp:id="companyA_ABID1" tp:action="Purchase Order Request Action“ tp:packageId="CompanyA_RequestPackage"><tp:ChannelId>asyncChannelA1</tp:ChannelId> <tp:BusinessTransactionCharacteristics tp:isNonRepudiationRequired="true“ tp:isSecureTransportRequired="true“ tp:isAuthorizationRequired="true" tp:timeToAcknowledgeReceipt="PT2H" tp:timeToPerform="P1D" /> </tp:ThisPartyActionBinding> </tp:CanSend> </tp:ServiceBinding> </tp:CollaborationRole> <tp:DeliveryChannel tp:channelId="asyncChannelA1" tp:transportId="transportA2“tp:docExchangeId="docExchangeA1"> <tp:MessagingCharacteristics tp:syncReplyMode="none" tp:ackRequested="always" tp:ackSignatureRequested="always" tp:duplicateElimination="always" /> </tp:DeliveryChannel> Example of CPP Document (Company A) (1/2) ↓Definition of Company A’s ID ←Link to Company A’s details Info. ←Definition of Collaboration Spec. ↑Definition of Service Binding ・Link to Packaging and Delivery Channel ・Definition of Business Transaction Characteristics ←Definition of Delivery Channel ・Link to TransportID and docExchange ・Definition of Messaging Characteristics Slide17:  <tp:Transport tp:transportId="transportA2"> <tp:TransportSender> <tp:TransportProtocol tp:version="1.1">HTTP</tp:TransportProtocol> <tp:TransportClientSecurity>   <tp:TransportSecurityProtocol tp:version="3.0">SSL</tp:TransportSecurityProtocol>     </tp:TransportClientSecurity> </tp:TransportSender> </tp:Transport> <tp:DocExchange tp:docExchangeId="docExchangeA1"> <tp:ebXMLSenderBinding tp:version="2.0"> <tp:ReliableMessaging> <tp:Retries>3</tp:Retries> <tp:RetryInterval>PT2H</tp:RetryInterval> <tp:MessageOrderSemantics>Guaranteed</tp:MessageOrderSemantics>   </tp:ReliableMessaging>   <tp:SenderNonRepudiation>   <tp:NonRepudiationProtocol></tp:NonRepudiationProtocol>   <tp:HashFunction></tp:HashFunction>   <tp:SignatureAlgorithm></tp:SignatureAlgorithm>     </tp:SenderNonRepudiation> <tp:SenderDigitalEnvelope> <tp:DigitalEnvelopeProtocol tp:version="2.0">S/MIME</tp:DigitalEnvelopeProtocol>   <tp:EncryptionAlgorithm>DES-CBC</tp:EncryptionAlgorithm>     </tp:SenderDigitalEnvelope>   </tp:ebXMLSenderBinding> </tp:DocExchange> </tp:PartyInfo> </tp:CollaborationProtocolProfile> ←Definition of Transportation Spec. ←Definition of Reliable Messaging Spec. ←Definition of Non Repudiation Spec. ←Definition of Digital Envelope Spec. Example of CPP Document (Company A) (2/2) Slide18:  Explanation of Example of CPP (CompanyA) ・’CompanyA’ is supposed to be a buyer, and ‘CompanyB’ is supposed to be a seller. ・These companies adopted DUNS number as a party identification. [ProcessSpecification element] ・ProcessSpecification element specifies URI of associated Process-Specification Document. [Role element] ・Role element specifies role of party. ・The role of CompanyA is defined as buyer by Role element (‘name’ and ‘xlink:href’ attributes) Slide19:  [ServiceBinding element] ・ServiceBinding element defines Delivery Channels and Packaging by each Action. And also Delivery Channels and Packaging are specified by sending action or receiving action. e.g. CanSend element (for sending action), CanReceive element (for receiving action) ・In this example, CPP(A) has one ServiceBinding element. And this ServiceBinding element has several CanSend elements and CanReceive elements. ・The value of Service element ‘$2.0’ will be used as the value of the Service element in the ebXML Message Header. [Certificate element] ・In case of certification under CPPA specification, All Business documents are digitally signed based on XML Digital Signature specification [XMLDSIG]. ・Certification information is defined by Certificate element. These certificate information are referred elsewhere in the CPP. Certificate information is able to be defined independently by using certID or securityId attributes. ・TrustAnchors element represents a root certificate trusted by this party. Slide20:  Definition of Delivery Cannel and Packaging by using ActionBinding element [DeliveryChannel element] ・Delivery Channel and Packaging are able to be defined by separately and independently using ActionBinding element and DeliveryChannel element. ・DeliveryChannel element has a function to determine Messaging characteristics. BusinessTransactionCharacteristics MessageingCharacteristics (asyncChannelA1) (asyncChannelA1) -isNonRepudiationRequired: true -syncReplyMode: none -isNonRepudiationReceiptRequired: true -ackRequested: always -isSecureTransportRequired: true -ackSignatureRequested: always -isConfidential: transient -dupulicateElimination: always -isAuthenticated: persistent -isAuthorizationRequired: true Slide21:  [DeliveryChannel element] ・Delivery Channel also defines Transport and docExchange. [Transport element] ・Transport element defines the party’s network communication capabilities. ・Communication capabilities are able to be defined by every sending and receiving action. Slide22:  [docExchange element] ・docExchange element defines characteristics regarding exchange of business documents. ・These characteristics are able to be defined by sending and receiving action. [Packaging element] ・Packaging element provides specific information about how the Message Header and payload constituent(s) are packaged for transmittal over the transport. ・The Packaging element provides information about MIME content types, XML namespaces, security parameters, and MIME structure. ・These information are capable to be defined by each sending and receiving action. docExchangeA1 Slide23:  <?xml version="1.0" ?> - <!-- Copyright UN/CEFACT and OASIS, 2001. All Rights Reserved.   --> - <tp:CollaborationProtocolAgreement xmlns:tp="" xmlns:xsi="" xmlns:xlink="" xmlns:ds="" xmlns:xsd="" xsi:schemaLocation=" draft-cpp-cpa-017.xsd" tp:cpaid="uri:companyA-and-companyB-cpa" tp:version="017">  <tp:Status tp:value="proposed" />   <tp:Start>2001-05-20T07:21:00Z</tp:Start>   <tp:End>2002-05-20T07:21:00Z</tp:End>   <tp:ConversationConstraints tp:invocationLimit="100" tp:concurrentConversations="10" /> - <!-- Party info for CompanyA   --> - <tp:PartyInfo tp:partyName="CompanyA" tp:defaultMshChannelId="asyncChannelA1" tp:defaultMshPackageId="CompanyA_MshSignalPackage"> <!-- Party info for CompanyB   --> - <tp:PartyInfo tp:partyName="CompanyB" tp:defaultMshChannelId="asyncChannelB1" tp:defaultMshPackageId="CompanyB_MshSignalPackage"> <!-- An ebXML message with a SOAP Envelope only   --> - <tp:Packaging tp:id="CompanyA_MshSignalPackage">  <tp:ProcessingCapabilities tp:parse="true" tp:generate="true" /> Example of CPA Document (Company A and B) Slide24:  Explanation of Example of CPA This CPA has two PartyInfo elements. One is information for CompanyA (DUNS ’123456789’), the other one is information for CompanyB (DUNS ’987654321’). The role of CompanyA is buyer; this is specified by Role element under PartInfo element. The role of CompanyB is seller. [Status element] The value ‘proposed’ means that the status of this CPA is under negotiation between two companies. The other value ‘agreed’ and ‘signed’ are capable. [Start element] ‘2001-05-20T07:21:00Z’ means that this CPA will be valid from the time of 7:21 am UTC (Coordinated Universal Time) on May 5, 2001. [End element] ‘2002-05-20T07:21:00Z’ means that this CPA will be invalid from the time of 7:21 am UTC (Coordinated Universal Time) on May 5, 2002. [ConversationConstraints element] ‘100’ of invocationLimit attribute means that if the number of conversations is reached to 100 times, this CPA is terminated and must be renegotiated. ‘10’ of concurrentConversations attribute means that 10 conversations can be in process at the same time. The meaning of number as the content of this element is number of business transaction (e.g. Purchase order), is not a performance parameter. Slide25:  Relationship between CPA and Messaging Header CPA (A,B) Business Document Message Header Header Envelope Payload Envelope Payload ・When the Business Document is composed by middleware above the Message Service Interface (MSI), Some parameters are referred and implemented in the Message Header in the Business Document. Slide26:  Example of Message Header of ‘Purchase Order Request’ Document <SOAP:Envelope xmlns:SOAP=> <SOAP:Header xmlns:eb=“http//”> <eb:MessageHeader id="…" eb:version="2.0" SOAP:mustUnderstand="1"> <eb:From><eb:PartyId>123456789</eb:PartyId></eb:From> <eb:To> <eb:PartyId eb:type="someType">987654321</eb:PartyId> <eb:Role></eb:Role> </eb:To> <eb:CPAId>uri:companyA-and-companyB-cpa</eb:CPAId> <eb:ConversationId>987654321</eb:ConversationId> <eb:Service eb:type=“anyURI">$2.0</eb:Service> <eb:Action>Purchase Order Request Action</eb:Action> <eb:MessageData> <eb:MessageId>UUID-2</eb:MessageId> <eb:Timestamp>2000-07-25T12:19:05</eb:Timestamp> <eb:RefToMessageId>UUID-1</eb:RefToMessageId> </eb:MessageData> <eb:DuplicateElimination/> </eb:MessageHeader> </SOAP:Header> <SOAP:Body xmlns:eb=“http//”> <eb:Manifest eb:version=“2.0”> ---- </eb:Manifast> </SOAP:Body> </SOAP:Envelope> ←Definition of ebXML Message Header ←Description of IDs of From and To ↓Description of corresponding Service ←Description of corresponding Action

Add a comment

Related presentations

Related pages

OASIS ebXML Collaboration Protocol Profile and Agreement ...

The ebXML Collaboration Protocol Profile and Agreement OASIS Standard provides ... Although not produced by the OASIS ebXML CPPA TC, ... Current List ...
Read more

ebXML Presentations

ebXML Presentations: ebXML Podcasts Conducted by Sacha Schlegel Spring 2006. ... Current Status of OASIS ebXML CPPA TC 5th ebXML Asia Committee Meeting
Read more

PPT - Activities about CPPA in Asia Region PowerPoint ...

4 th OASIS ebXML CPPA TC Reston Meeting. Activities about CPPA in Asia Region. PAA INNODIGITAL NII ... 4 th OASIS ebXML CPPA TC Reston Meeting.
Read more

Introduction to OASIS

TC votes to approve work as an OASIS Committee Specification ...
Read more

... partners to give a global picture of the current status of ebXML ... ebXML Business Process TC opens within ... archives/ebxml-cppa/200205 ...
Read more


Current List; Forming a Member Section; Donations; Policies. Bylaws; Intellectual Property Rights; TC Process; Other policies ... All OASIS lists. Help ...
Read more

CPPA3: A CPPA that supports PModes | EBXML

CPPA3: A CPPA that supports PModes. ... The CPPA TC merged with another ebXML TC to become the ebCore Technical ... The current approach is ...
Read more

ebXML - Enabling A Global Electronic Market

Open Source ebXML Software, Hermes 1.0 and ebMail 1.2, Released and Used by HKSAR Government. ... ebXML CPPA V 2.0 ...
Read more

Deployment Profile Template v1 - OASIS

This document was last revised or approved by the OASIS ebXML IIC TC on ... Check the current ... This Deployment Profile Template for CPPA 2.0 is ...
Read more