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