Draft of Requirements for Intermediary Support for discussion.

Title: RE: PIP IDs

David Burdett has given his permission to repost 
his

suggested requirements for support of 
intermediaries

using CPP and CPA profile exchanges. I 
have

edited out some no longer relevant 
pieces

of the thread that this came from 
(with

David's permission), and think 
that

we should take this as input to 
our

future work on multiparty cpas as 
well

as on intermediary support.

 

I will be commenting on these 
requirements

in a separate message later on this 
week.

 

 

Dale Moberg

  
-----Original Message-----
From: Burdett, David 
  [mailto:]
Sent: Monday, July 30, 2001 
  5:10 PM
To: Dale Moberg; Martin W Sachs
Cc: Arvola Chan; 
  David Fischer; ebXML Msg; Pete Wenzel
Subject: RE: PIP 
  IDs

  
Dale

  
 

  
Here 
  is my first cut of the requirements for CPPA that are needed to support 
  intermediaries. It suggests the development of several different types of 
  CPA/CPP ...

  
1. 
  Transport CPP. This specifies the MSH parameter values that can be applied to 
  the exchange of messages that are independent of the business process, 
  business transaction or the needs of an individual party. A typical use of his 
  would be by a Community of users that agreed to exchange all messages in one 
  (or a few different) ways.

  
2. 
  Business Process CPP, Specifies a way of exchanging data/documents/messages 
  that meets the needs of a specific business process or business transaction. 
  The CPP should omit any data that is specific to any transport or 
  communications protocol. (Is this WSFL?). A typical use of this would be a 
  standards group that wanted to define some standard business processes that 
  they had developed, or a Community of Users that had identified the subset of 
  standard transactions that they would use.

  

  
3. 
  An Endpoint CPP, that identified a series of URLs and Security data that could 
  belonged to a Party to which messages could be sent
4. A Community CPA. This would be a 
  combination of Transport and Business Process CPAs which represented the 
  standard way by which members of that Community would carry out its business. 
  It would omit any specific Party information (e.g. URLs or security 
  information)

  
5. A 
  Party CPP that:

  
  a) Referenced Transport CPPs, Business Process 
  CPPs, and/or Community CPAs and EndPoint CPPs. The EndPoint CPPs could apply 
  to either:

  
     i) all interactions with the 
  Party, or 

  
     ii) one or more combinations 
  of Transport CPPs, Business Process CPPs ro Community CPAs

  
6. A 
  Party-to-Party CPA.. This could either:

  
  a) Reference a Community CPA, excluding any 
  Business Processes/Transactions they did not support, and:

  
     i) add EndPoint CPP 
  information that applies to all Business Processes/Transactions, which could 
  be over-ridden by

  
     ii) adding EndPoint CPP 
  information that applied to individual Business Processes/Transactions, or 
  ...

  
  b) Create a one-off CPA that included 
  Transport and Businss Process level data as well as URL and security data as 
  currently defined.

  
 

  
Intermediaries could then use these CPAs/CPPs as 
  follows:

  
1. 
  The CPAId in the Message Header would reference a Community CPP or a 
  Party-to-Party CPA

  
2. 
  The CPA Id in the Via element would reference an individual EndPoint CPP (or 
  part of a CPP) and optionally a Transport CPP to identify where messages 
  should be sent to.

  
 

  
I am 
  not sure if these ideas are completely baked, but hopefully we can start a 
  useful discussion.

  
 

  
David