OASIS ebXML Collaboration Protocol Profile and Agreement TC
ebXML CPPA Technical Committee Teleconference
October 18, 2001
Dale reported that OASIS will be at a mid-December
XML Conference in Orlando and that Karl Best has urged
technical committees to have face-to-face meetings there
if it would be useful. Dale feels that we'll be drafting
changes for 1.1 then and is not inclined to hold a F2F
at that time.
Service / Action
Hima will be updating the issues list in his document.
Dale asked what the service and action values in a SOAP
header would be when a message combines an MSH signal
and a business action. Arvola replied that according
to the MSG spec, the service and action for the business
action would be used. Dale then inquired about the case
of both a business signal and business response; in
that case Arvola indicated the answer is unclear. Arvola
noted that BPSS doesn't have the notion of synch reply;
Dale thought that was reasonably an implementation decision
for the CPA. Arvola thought that synch reply was implicitly
overriding some of the timing parameters. Tony responded
that timing and synch reply can be considered independently
- regardless of synch reply, all, some, or none of the
signals and actions will meet the timing constraints
(the fact that some signals and actions may arrive together
doesn't change the assessment of whether or not they
meet their timing constraints). Parties who agree to
use synch reply mode should take that into account when
specifying timing parameters. Agreement authoring tools
might provide advice accordingly.
Dale mentioned that David Fischer is concerned with
cases where the client side closes an HTTP connection,
leaving the server unable to send a response back. Arvola
asked if the client could have a timeout set. Brian
feels we should be able to support this. Marty said
that if at all possible, such implementation timeouts
(e.g., synchronous connection timeout) should be reflected
in the CPPA. Arvola agreed to draw up a proposal, but
may not be able to get to it right away. At Dale's request,
Tony will add implementation timeouts to the issues
DB; whether it's for version 1.1 or later is TBD.
Marty reminded us that he put out an updated draft
before the Palo Alto. So far, he's only received feedback
from Yukinori Saito.
Brian informed us that ebTWG met last week near San Francisco.
The BPSS team had about 6 active participants and 30 or
40 people have subscribed to their mailing list. They're
starting to collect their issues list.
Dale is working on a document concerning suggested
changes for the security elements. A draft will be out
Arvola reported that David Fischer distributed the
MSG version 1.05 draft on Monday (available on their
website). The main question is whether one or two sets
of retry parameters are needed, since the message header
may have two acks requested - one directed to the next
MSH, and one directed to the to-party MSH. The issue
is not completely resolved, but people seemed to favor
the limitation that each MSH can put on at most one
ack requested element into the message. Therefore, from
the point of view of the from-MSH, you can ask for an
end-to-end ack or an intermediate ack, but not both.
Dale assumes that intermediate-to-intermediate MSH acks
are out of scope for CPPA at least in version 1.1. Arvola
responded that the CPA is mostly for governing behavior
of the from-party and the to-party. Marty also agreed
with Dale's position. According to Arvola, the MSG committee
is not expecting the CPPA committee to address intermediaries
in this way for version 1.1.
Kartha asked if delivery receipts are in or not. Arvola
answered that delivery receipts are considered a separate
module; there was a motion to drop it from the MSG spec,
which will be decided at their next voting meeting.
Arvola confirmed that the acks will now serve to do
the non-repudiation (at the MSH level) and he feels
that delivery receipts are now redundant. There is still
the question of whether NRR is carried in the messaging
or business level ack (as in the BPSS point of view).
Brian thinks there are some issues that should be raised
with BPSS. Dale thinks that if MSG drops delivery receipt,
then they will not be doing NRR. Arvola noted the problem
of isIntelligibleCheckRequired, which might require
the recipient to do schema checking (beyond the scope
of MSH). Tony felt that NRR and intelligibility checking
are separate issues. Arvola said that an MSH would send
an exception rather than a delivery receipt in case
the message was unintelligible. Marty asked whether
the exception message has to be non-repudiatable? Brian
asked: if there are several ways to do things like NRR
(e.g., at the business or transport level), can that
be specified in a CPA? Dale thinks this was an issue
raised by the ebXML security risk assessment. He thinks
that in order to meet the security team's objection,
a CPA might have to identify how NRR was to be done.
Arvola doesn't think we can completely rely on a reliable
messaging ack since we don't always use reliable messaging
but may still want NRR. Hima feels there should be both
business and transport levels of NRR. Peter said that
there's a messaging level ack that can serve as intermediate
or end-to-end confirmation of message receipt; he doesn't
see that the MSH should be worried at all about higher
level matters. Dale asked Arvola to clarify with MSG:
does the ebXML MSH layer provide a minimal NRR by means
of its ack. Arvola thinks that was always their intention
as long as the NRR doesn't require schema checking.
Dale responded that we need to hear a vote from them
-- we may have two different ways of NRR- both via a
business signal and an MSH ack, with only the business
signal able to handle isIntelligibleCheck.
Arvola presented the first set of MSG issues covered
in the document attached to his Oct. 17 posting on "[ebxml-cppa]
Issues for discussions". They are reproduced here for
When the HTTP binding is used, but sync reply
is not enabled, Acknowledgment messages are carried
as separate HTTP request messages.
By default, MSH level signals are returned asynchronously.
Add mshSignalsOnly sync reply mode to CPA. (Sync
reply does not apply to SMTP.)
Sync reply should be usable with best effort
Clarify that sync reply can be used with or without
SyncReply and ReliableMessagingMethod should
also be in QualityOfServiceInfo.
SyncReply is already in QualityOfServiceInfo
in the 1.05 draft. ReliableMessagingMethod is
no longer relevant.
SyncReply should be in both header and Via.
Already the case in the 1.05 draft.
SyncReplyMode attribute values are not clearly
MSH should understand mshSignalsOnly as a sync
reply mode. Other clarifications with respect
to the overriding of BPSS level specifications
should go to the CPP/A spec.
Re issue 9, Dale wants the CPA to model things that
are relatively static, not dynamic. He has previously
urged MSG not to do a per message shift on such things.
We need to monitor this area closely.
Re issue 10, it was the sense of the group that the
recommended clarification seems reasonable.
Re issue 72, Dale indicated that we're going to take
the matter up.
There will be another teleconference next week on October