Re: Phases of CPA formation or levels of interoperability.

[christopher ferris <chris.ferris@east.sun.com>]

Dale,

If we assume that we can register the packaging profiles
and assign them with specific URIs (which we can explicitly
identify in the specs) then it would seem to me that
matching on a profile URI would be sufficient. Barring that,
then it would seem to me that there would need to be
some deep diving required to match profiles at the leaf
nodes (a difficult task I might add)

Other than that point, I think that I concur with your 
observations.

Cheers,

Chris

"Moberg, Dale" wrote:
> 
> 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.
begin:vcard 
n:Ferris;Christopher
tel;cell:508-667-0402
tel;work:781-442-3063
x-mozilla-html:FALSE
org:Sun Microsystems, Inc;XTC Advanced Development
adr:;;;;;;
version:2.1
email;internet:chris.ferris@east.sun.com
title:Sr. Staff Engineer
fn:Christopher Ferris
end:vcard