OASIS ebXML Collaboration Protocol Profile and Agreement TC
ebXML CPPA Technical Committee Teleconference
August 23, 2001
Dale announced that Karl Best of OASIS has advised
him that by the beginning of September, we need to take
several steps in order for the ebXML CPPA 1.0 specification
to be moved over into OASIS. The most important step
is that three member organizations must say they're
are using the specification. Marty asked about the definition
of "using" for this purpose, and Dale reported that
Karl said it was entirely open. Tony W. asked whether
OASIS is seeking a verbal statement, a letter, or something
else and Dale thought that at least email to him (Dale)
would be in order, with details to be learned from Karl.
On that basis, Cyclone (Dale), Vitria (Engkee), and
Edifecs (Tony) verbally offered to be listed as users.
Tim pointed out that one of the responses to Marty's
listserv query about existing BPSS tools also indicated
some support for CPPA.
Next Face to face Meeting
As noted in Dale's listserv posting, Sinisa Zimek from
SAP will host our next in-person meeting. Dale reported
the address as 3475 Deer Creek Road; Palo Alto, CA 94304
Arvola reported no team calls since last time. The
preliminary issues database from the OASIS messaging
committee has not been published yet.
Tim noted lots of security-related discussion on the
listserv. He hopes to start this weekend on a list of
security items for version 1.1, especially ones related
So far, no comments have been posted in response to
Marty's draft white paper - discussion is encouraged!
Tim reported that three projects were approved for
the UN/CEFACT ebTWG, which will meet the week after
our face-to-face meeting. Tim will forward the call
for participation to our list. Tony F. noted that the
three projects are Core Components, Business Collaboration
Patterns and Monitored Commitments, and eBusiness Architecture.
Dale remarked that Arvola and Himagiri are sending
the list many useful comments - they're much appreciated.
Dale identified a couple large issues from recent discussion
on the list that he favors prioritizing, the first being
SSL client side authentication as raised by Arvola -
Dale feels it can probably be taken care on in the version1.1
time frame. Tim inquired whether a "dot one" release
is for adding functionality. Dale replied that the ebXML
team always intended to capture SSL and that one feature
of SSL is whether you do client side authentication
or not. Someone suggested that we might need to embellish
certificate reference with a key usage field. Marty
thought that since SSL is a well-understood protocol,
we should be able to address this for version 1.1.
Marty asked whether version 1.1 should be updated for
the final approved version of XSD. Dale responded that
we might as well. Arvola added that the messaging committee
plans to do so.
Tim asked Arvola if client side authentication would
pose a problem for messaging in version 1.1. Arvola
was unsure [but see his posting today Re: SSL Mutual
Authentication and the Message Service Spec]. Dale thought
it might be covered in the "binding" Appendix.
Dale feels that the largest issue for version 1.1 involves
acknowledgements and delivery receipts. There was much
discussion on this topic, including:
We tried to track all the changes in the 1.0 messaging
spec, but some things may have slipped in there at
the end that we didn't catch up on.
Possible conflict or confusion between the business
level and message level regarding receipts.
Dale was unclear about when to use an acknowledgement
signal for non-repudiation of receipt and when to
use a separate delivery receipt.
Similarly, Arvola noted a separate business signal
with a DTD that includes an original message digest.
Dale said that with asynchronous reply we really
have two separate ways of responding -an ack on the
HTTP connection, and a separate connection opened
for a response, and that we have no way of modeling
packaging for that.
Marty thought that as of last April, our position
was that signals were strictly for middleware and
thus not in scope for CPPA.
Arvola pointed out that there is much disagreement
within the messaging committee about the meaning of
Tim asked if anybody has a good description of how
all this is really used; none was identified.
Dale felt that we must to work with the messaging
committee in this area; it's also a BPSS interface
issue since a lot of the requirements came from them.
Tony W. stated that there was also disagreement
within the BPSS team in this area.
Dale felt that proper support for RosettaNet, at
least, is a requirement.
Marty felt that while some of it may not be a CPPA
matter, the rest is not necessarily a messaging matter
either - it could be an issue for some other middleware
Dale announced two volunteers for hosting upcoming
calls: David Smiley of Mercator for September and Brian
Hayes of Commerce One for October.
We will have a non-voting meeting next week on Thursday,
11:30 am - 12:00 Eastern time (USA).