Subject: RE: Phases of CPA formation or levels of interoperability.
If, when you say "for a desired BP", you imply an agreed-upon choreography, I think that is is enough. /Stefano > -----Original Message----- > From: Moberg, Dale [mailto:Dale_Moberg@stercomm.com] > Sent: Thursday, December 14, 2000 11:25 PM > To: 'Christopher Ferris'; ebxml-tp@lists.ebxml.org > Cc: 'Martin W Sachs' > Subject: Phases of CPA formation or levels of interoperability. > > > I want to raise again a general question > about how the CPA formation process is to be > understood so that I can begin to comment > on the CPP proposal in more detail. > > It is fairly clear that arriving at some > way to collaborate is the pragmatic payoff > for the CPP to CPA formation process in that > lowering the technical barriers to begin > collaboration is one main thrust of ebXML. > > Minimally this would mean that there is some > interoperable pair of transport capabilities > that provides a > way to move the payloads > back and forth. > > Beyond this is a very large realm of > nice to haves (which may be must-haves > for some fussy collaborators.) > > These include: > compatible document packaging, > compatible security approaches, > compatible reliable transport modes, > compatible time out values > support for all the desired signals > and error conditions > requirements for concurrency , sequencing etc. > > I have been including compatible document packaging > approaches as one thing that needs to match up in > that a mismatch in these capabilities tends to > severely frustrate getting the payload from > its source to its consumer in a digestible way. > (manual processing by cutting out MIME parts > is not reducing barriers to entry...) > > Security mismatches can prevent delivery in some cases > (and perhaps are intended to do so!) and for that > reason I have been including these as part of > what needs checking for the capabilities to match up. > > At the f2f, we agreed that there was a base level > "operational" match that could then produce > candidates that could be checked off against > additional requirements or desired features. > The formation process would then be conceptually > broken into "phases" in which the main phase > established a robust transport/packaging interoperable > delivery while the later phase tried to optimize > over the known additional "requirements". > > Is this approach one that we should follow? Should > the main thrust of the initial match (baseline > interoperable collaboration) be to check that, > for a desired BP, we can find complementary > transport and packaging (including security?) > Is there anything else that should be in the > baseline match? (Signaling patterns? Timeouts?) > > In addition to the question of how to demarcate > the boundary between the baseline match and the > requirements checking, there is another question > of how deeply to go into the match, especially > on the packaging and security. I am going > to put some questions on this in a separate > message. > >
Powered by
eList eXpress LLC