ebXML CPPA Technical Committee Teleconference
(Non Voting)
September 6, 2001
Attendees
Arvola Chan
David Fischer
Brian Hayes
Neelakantan Kartha
Engkee Kwang
Dale Moberg
Himagiri Mukkamala
Peter Ogden
Marty Sachs
David Smiley
Tony Weida
Minutes
Announcements
Dale is postponing most administrative matters until
our voting meeting for next week.
Dale wants us to plan for our next F2F. He noted the
Messaging committee's newly released issues document
and suggested that people from our team with particular
interest in messaging review it. There are numerous
issues of common interest.
Open Discussion
We had a lengthy conversation about reliable messaging
and non-repudiation of receipt (NRR). Key issues included
the scope of the ebXML Message Service Handler and the
nature of NRR.
Marty feels there is confusion about whether or not
the MSH is the endpoint for NRR functionality. That
impacts where NRR information belongs in a CPP/A.
Dale thought that NRR might be a good service for MSH
to offer. Arvola mentioned that the MSH specification
specifically states that they're not doing validation
of payloads, e.g., for syntactic correctness.
Marty wants to make sure that we distinguish between
the formal definition of MSH [editorial: which is not
entirely clear] and related middleware.
Dale believes a crucial issue is how much work the
MSH does when generating NRR. For example, invoking
an XML parser extends its scope from an architectural
point of view. In the case of NRR for RosettaNet, MSH
alone is not sufficient; cooperation of another middleware
component is needed -- maybe we should undertake to
specify division of labor in this area. Arvola observed
that our specification is currently tied to BPSS. Marty
elaborated that we have links for BPSS instance documents
and roles, along with a set of security attributes to
override information in a BPSS instance, but we say
little about those attributes in terms of what functionality
must be where.
(It was mentioned that in the Messaging specification,
the deliveryReceiptRequested attribute of the QualityOfServiceInfo
element allows three values: "signed", "unsigned", or
"none", but they're talking about doing away with "none".)
We discussed the relation between NRR and once-and-only-once
delivery. Dale stated that one could have both an acknowledgement
[signal] and a delivery receipt for NRR. David F. asked
why the delivery receipt couldn't perform double duty.
In a digression, Peter O. asked about tracking and
identification of relevant issues being addressed by
the Messaging committee. Tony indicated that we could
use their issue identification numbers in case they
commit to not change the numbers (from their Access
database). Tony agreed to discuss the matter with David
Burdett [who did agree that we can rely on the immutability
of the identification number associated with an issue;
Tony offered the same commitment to the Messaging team].
Dale discussed the importance of RosettaNet PIP specifications
mapping cleanly onto BPSS. Arvola responded that BPSS
borrows lot of ideas from RosettaNet, so if we achieve
good alignment between our spec and BPSS then we should
be in good shape overall.
The BPSS specification has a Boolean isIntelligibleCheckRequired
property associated with receipt acknowledgement to
indicate if a syntax check is entailed. Marty wasn't
sure if not sure if we have that in our version 1.0
[we don't] and opined that it's starting to look like
it ought to be included.
Arvola inquired if there is any plan for our committee
to meet with the BPSS group. Marty was assuming that
Karsten Riemer was the contact point and suggested talking
to him. Brian said that he's involved with BPSS too
and can handle liaison along with Karsten.
Returning to syntax checking as part of receipt acknowledgement,
it was mentioned that the MSH could provide a plug in.
This again raises questions about the scope of MSH and
division of labor among middleware components. Someone
(Engkee?) asked if the Interoperability committee might
address such matters. Marty felt it should be an agenda
item for our joint F2F with Messaging. He also urged
separate agendas for our own F2F and for the joint F2F.
In addition, we might want to consider a technical report
on interoperability across the Messaging, BPSS and CPPA
specifications. Dale agreed with the idea and felt that
someone needs to draft it, but wasn't sure who.
David S. raised the issue of multi-hop messaging. Marty
stated that where the CPPA specification talks about
message transfer functions, it's talking about end to
end (for now at least). Dale posed the question: will
we get into true multiparty cases, or just treat intermediaries
as forwarders that we don't need to explicitly model.
Marty told us that the multiparty case involves major
issues about which party is privy to what information;
what state has to be tracked by who, etc. He said that
while BPSS has some provision for multiparty collaboration,
it really just amounts to a set of binary collaborations.
In his opinion, we should steer clear of multipart collaborations
until we have more immediate issues under control -
meanwhile we can get away with sets of binary collaborations.
Dale pointed out that the ebXML POC showed multiparty
collaboration, but all CPPA properties pertained to
end-to-end interaction, which Marty characterized as
a case of passive store and forward intermediaries.
Dale suggested that if an intermediary's role is important
to a business process, that should be captured via BPSS.
Arvola mentioned the CPAId in the Messaging header.
One can also specify a CPA between the sender and (the
first) intermediary, probably using the Messaging specification's
via element, which Arvola thinks has its own Service
and Action elements [it does]. Dale suspects a gap between
BPSS and intermediary provisions in MSH. Brian will
work with David Burdett on that. One point of view was
expressed that if Party A says to send to a 3rd party
and Party B does send it there, that's sufficient -
Party B has fulfilled its obligation under a CPPA. Another
case occurs when Party A can only send to an intermediary
such as Commerce One, but has an obligation (under a
CPA) to send it to the ultimate recipient. Dale expressed
the view that the whole area of "interconnects" is out
of scope for version 1.1 - we don't even provide for
VANs as transports. Although VANs showed up in tpaML,
Marty advised that it was merely as a placeholder.
Brian pointed out that there are two BPSS proposals
for eBTWG: one from him and the other from Karsten Riemer.
There's also a proposal on interoperability from Nita
Sharma.
Next Meeting
There will be a voting meeting next week on Thursday,
September 13, 11:00 am - 12:00 pm Eastern time (USA).
Metadata
Please send additions and corrections to Tony Weida
(rweida@hotmail.com).
Respectfully Submitted,
Tony Weida
|
