Marty asked about IPR. Karl responded that the IPR
policy is on the OASIS website -- all work must be freely
available to the public; all submissions should be free
from encumbrances or at least those things should be
identified upon submission. (Marty later quoted from
the IPR policy to the effect that patents must be made
available on reasonable, non-discriminatory terms.)
Jamie asked (how) does inheritance from the ebXML organization
and the OASIS/CEFACT MOU affect the usual operation
of technical committees. Karl responded that OASIS committees
will be governed by OASIS procedure and that the MOU
doesn't give CEFACT any rights to intervene in the OASIS
Jamie inquired about coordination with UN/CEFACT. Karl
answered that relations are expected to be informal
and are encouraged.
Karsten asked about membership and the possibility
of substitutes. Membership is individual.
Charter and Scope
Dale reviewed our committee's charter. For details:
Regarding item 5 on design, Brian remarked that Business
Service Interface (BSI) design may be outside our scope,
but statement of BSI requirements may be in.
Tim asked when we'd consider our scope closed, given
the 18-month time frame envisioned in the charter. Dale
suggested 6 months from now.
Regarding coordination with other ebXML teams, Jamie
pointed out the natural tension between fixing inconsistencies
and ambiguities between different version 1.0 specs,
and the fact that the CPPA spec itself will be a moving
target. He asked whether there's so much "churn"
on the table that it doesn't make sense to isolate differences
between version 1.0 specs. Marty responded that we've
identified lots of loose ends; it's not just an issue
of repairing specs, but lots of work is needed to ensure
that version 2.0 specs are aligned.
Tony F. inquired if we will address Trading Partner
Profiles (TPPs as opposed to CPPs) during this phase.
Marty replied that the subject would come up later during
It was unanimously agreed that the charter looks good.
Dale proposed Tony W. to act as coordinating editor,
take minutes, and track issues across all specs, Marty
seconded, and approval was unanimous.
Introduction to CPP/CPA
Marty presented an introduction to the version 1.0
CPP / CPA specification. For details:
Dale mentioned the OASIS BTP team and the possibility
of addressing two-phase commits and long running transactions
- is it feasible to accommodate them? Marty answered
that we have very little about conversations in version
1.0; he suspects that we need much more for two-phase
commit. In terms of scope, we must decide if it's likely
to become important in the next 18 months.
Karsten characterized a CPP as a commercial (in terms
of semantics) version of a WSDL service Description.
Marty disagreed, saying that WSEL is more related to
CPP than WSDL.
It was noted that the version 1.0 spec has the (unintended)
effect of embedding certificates in CPAs.
Pete W. pointed out that RNIF 2.0 uses S/MIME digital
Dale suggested that references to business transactions
within BPSS documents could be XPointers; he and Marty
agreed that work remains to be done in that area.
Paul gave an overview of security issues for ebXML
messaging and their relationship to CPP/CPA elements.
Paul noted PKI issues that must be addressed to facilitate
interoperability and suggested that the key is understanding
X.509 certificates - creation, issuance, and management.
Jamie pointed out that the PKI and Certificate Authority
(CA) approach is not the only way; that peer-to-peer
and PGP are also good; we may not want to marry ourselves
Marty mentioned that version 1.0 stops at the point
of identifying the certificate and doesn't get into
other PKI issues. It was observed that the spec doesn't
talk about CA at all.
Dale asked: do people need to advertise whether they
do or do not check the certificate chain?
Peter O. said "you don't announce that you don't
lock the door." Marty said that a party could advertise
what it expects from the other party. Dale observed
that a CPP usually advertises a party's capabilities,
not what is required of the other party. Marty was concerned
that processing overhead may be a big issue.
Kartha thought we might separate out security. Marty
noted we might take an approach similar to what we did
for packaging in version 1.0. Tony F. felt it was sensible
to refer out to a security policy document as we do
for BPSS documents.
Dale asked why one party would care if the other party
checks his/her own security. Marty responded that one
would want to know if the other party checks his subcontractors.
Paul suggested looking at Identrus.
Abdel said that SPKI could specify a security profile
for each partner.
Tim felt this area is broad enough to require another
OASIS TC to address security profiles. Jamie felt that
a lot of time would be lost getting another group up
to speed; this group's conversation already evidences
The question was raised: is the security team continuing
and can they do this work?
Dale mentioned that one possible place to look is XKMS.
Tony F. suggested distinguishing between the first
time using a CPA with brand new partner and subsequent
Tony W. mentioned that we could define a policy for
caching certificate management information.
Peter Ogden stated that we need to give this area due
consideration; our efforts could be hurt as a standard
if we just wave our hands at security.
Possible New Work Items
Marty gave a detailed presentation on possible new
work items. For details:
Marty strongly emphasized the importance of having
the ebXML messaging service specification require
reliable delivery failure notification.
Arvola asked about synchronizing our version 1.1 with
that of the Messaging team. Dale is in the process of
contacting Ian Jones.
Aug 17 is the Messaging team's deadline for public
input on their 1.1 spec.
Tim thought it might be good to specify an (additional)
alternative to the ebXML Messaging Service.
Dale proposed that we consider the impact of IETF's
peer-to-peer BEEP protocol in relation to our current
client-server approach - we should ensure that our future
revisions are consistent with BEEP.
Tony F. pointed out that the XLINK spec has just changed
status; so we need to reexamine its usage in our spec.
Tim asked if, with the move to OASIS, we'd retain ebXML
namespace in examples.
Karsten would like to see a separate BSI team that
would take requirements from the other three groups
-- CPPA, BPSS, and MS.
Abdel felt it would be useful to have a white paper
on how to use CPP and CPA.
Karsten presented an overview of the version 1.0 BPSS
spec. (Dale hopes to post Karsten's presentation on
Karsten mentioned that a CPP could be the configuration
file for a BSI.
Tim asked if a BPSS document is executable in the sense
of being deterministic. Karsten answered that sequencing
rules are the closest they come to business rules; they
assume that all sequencing rules are based on the exchanged
BPSS Substitution Mechanism
Karsten gave a second presentation focused on the substitution
mechanism added to the BPSS spec at the Vienna meeting
of ebXML. (Dale also hopes to post that presentation
on the website.)
Tony W. proposed allowing XSLT transforms of BPSS (and
other) specifications of business processes referenced
by a CPP or CPA to meet the following criteria:
Reference the original BP specification
Clearly document changes to the originalPermit
Validate all changes
Allow changes to be suitably constrained
Simplify and generalize CPP / CPA spec
Support BPSS as well as any alternativesLeverage
Jamie asked if this proposal (and similarly, I believe,
the substitution mechanism) is vendor or customer driven.
Dale pointed out that experience with EDI demonstrates
lots of customization of guidelines. Jamie asked if
people might be discouraged from putting new variants
in registries. Tony W. responded that the proposal doesn't
preclude them from doing so; Pete (?) indicated that
the transforms themselves could be put in registries.
Marty gave an overview presentation on CPA negotiation:
Dale suggested that one could generate a CPP as part
of B2BI software installation process. Tony W. mentioned
the complication that in general a CPP could represent
capabilities implemented by multiple software systems
(which might yield to a CPP merger tool).
We discussed the prospects for partner discovery via
profiles stored in registries. One caller thought the
prospects were very long term. Dale mentioned the prospective
use for spontaneous e-commerce. Tony W. mentioned the
case where discovery of capabilities takes place within
reasonably large, closed communities of partners already
generally known to each other (such as RosettaNet IT
A caller asked about the use case for creating a CPA
from a CPP. Marty thought it was possible, but not so
interesting since a dominant partner is more likely
to use a CPA template.
Brian felt we'd be well served to have more than one
default negotiation process: one based on the ebXML
message protocol, and others based on something light
weight such as email.
The group enjoyed an excellent dinner at Mondo's courtesy
of Dale Moberg and Cyclone Commerce.
Wednesday, July 25, 2001
We agreed on several teams to track and liaison with
related efforts. Your correspondent has taken the liberty
of grouping the results together at this point for convenient
Members: Arvola, Pete W., Sinisa
Lead contact: Arvola
Members: Karsten, Kartha, Tim, Pallavi
Lead contact: Karsten
Members: Dale, Suresh, Tim, Peter Ogden
Lead contact: Tim
Members: Abdel, Dale, Engkee, Jean, Marty, Pallavi,
Peter Ogden, Suresh, Tim, Lead contact: Marty
Dale will address IETF BEEP, BTP, and Relax NG.
Pallavi will address OASIS IIC (Son of POC).
Pete W. will address RosettaNet.
Looking forward, other teams may address BPML, XLANG,
Teams will be responsible for issuing monthly reports
to Tony W. (who would encourage brief reports focused
directly on CPPA-related issues with simple references
other significant developments).
We consider our relation with BTP. Might we use BPSS,
XLANG, WSFL or similar specs together with BTP? Tim
cited a difficulty with BTP: it dictates the message
sequence, e.g., certain timeouts.
Dale is interested in Relax NG as a possible way to
extend the packaging mechanism.
Karsten understands that W3C is evaluating whether
to get involved in business process specifications.
Marty thought that would be the "hole" for
We discussed several messaging-related issues brought
up by Arvola in recent messages to the list.
The Messaging Service's mshTimeAccuracy
parameter isn't found in our spec; where does it come
from? Perhaps it's no longer needed? This issue will
first be raised as a comment to the Messaging committee.
It's not clear how a sender would choose an appropriate
value for the Messaging Service header's TimeToLive
and persistDuration values. From the
CPA or the BPSS? Arvola will seek clarification from
the Messaging committee. Marty noted that if there's
good reason for specifying those values, then partners
may need to agree on them.
Regarding retries, retry interval, and persist duration,
there may be minor misalignment between the Messaging
and CPPA specs due to spelling (capitalization).
Is use of CPA mandatory? According to Dale, a CPAid
value is mandatory; use of a CPA is optional.
The Messaging Service's acknowledgement of receipt
is supposed to be at the business level -- how does
it relate to business signals? Karsten said that in
BPSS signals are supposed to support non-repudiation;
BPSS is concerned with acknowledgement of receipt
of the business document.
Marty cited as an issue the question: does an intermediary
need to understand a CPAid? Arvola continued that there
are lots of ambiguities in the MS spec about intermediaries.
Marty suggested asking Maryann Hondo to at least consult
with us on security issues.
We discussed having multiple bindings for different
messaging services. Tony W. said we could provide an
extension mechanism. Karsten said that the principle
approach should be extensions.
Regarding the possibility of a separate BSI team, Marty
suggested that the three OASIS ebXML team leads (Dale,
Karsten, and Ian) discuss needs for BSI.
The negotiation group will draft a white paper, considerations,
and tasks list to follow up on the presentations from
Dale and Marty.
Dale favors doing most of our work by email. He suggested
starting with half hour weekly phone calls. The calls
would be used to discuss issues from the past week's
A motion was offered by Karsten to hold weekly phone
meetings on Thursdays at 11:30 am Eastern (USA) time,
with the second weekly meeting of every month being
an official (voting) meeting. Peter Ogden seconded the
motion, Kartha called for a vote, and approval was unanimous.
There was informal agreement to look into co-locating
our next face-to-face meeting with a meeting of the
OASIS ebXML Messaging TC, and to decide about co-locating
future meetings later on a case-by-case basis.
Marty will update and post his issues list shortly.
Karsten inquired about "WSxL" and where CPP
might fit in. Marty mentioned that little has been said
publicly about (IBM's) WSEL which is supposed to describe
endpoint properties from a technical point of view;
CPP as now constituted doesn't fit neatly into WSxL,
but hopefully WSEL will be inspired by what's in CPP.
Karsten thought a collaboration protocol could be thought
of as some amalgamation of two WSDL documents -- by
building on WSDL, one could get to more natural way
of describing one side of a BPSS. Karsten raised the
possibility that WSFL might be merged with XLANG. Abdel
said that IBM and HP are working to put WSDL and CDL
together. The question was asked: Should we invest time
in these "private" languages?
We briefly discussed the scope of the committee as
far as promoting our spec, not just publishing it. Marty
did not believe that this team has standing to make
statements about comparison of CPP-CPA with WSxL because
Web Services (except for SOAP) is still a private matter
of a few companies and has not yet started activities
in a public standards body. He suggested that individuals
might want to make comparisons in their own names. Brian
noted that we could list unique features in our document.
Dale called for a motion to adjourn that was offered
by Tony, seconded by Karsten, and unanimously approved.