" rel="home">

ebXML CPPA Technical Committee Teleconference

(Non Voting)

October 18, 2001

Attendees

Arvola Chan
Brian Hayes
Neelakantan Kartha
Pallavi Malu
Dale Moberg
Himagiri Mukkamala
Peter Ogden
Marty Sachs
David Smiley
Tony Weida
Jean Zheng

Minutes

Announcements

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.

Committees

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.

Negotiation

Marty reminded us that he put out an updated draft before the Palo Alto. So far, he's only received feedback from Yukinori Saito.

BPSS

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.

Security

Dale is working on a document concerning suggested changes for the security elements. A draft will be out soon.

Messaging

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

Sync Rely

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.

Next Meeting

There will be another teleconference next week on October 25.

Metadata

Please send additions and corrections to Tony Weida (rweida@hotmail.com).

Respectfully Submitted,
Tony Weida