ebxml-tp message


OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]

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.
> 
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index]
Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC