OASIS ebXML Collaboration Protocol Profile and Agreement TC
ebXML CPPA Technical Committee Teleconference
November 8, 2001
Dale advised us that the MSG committee will meet face-to-face next week, when they intend to wrap up their issues for version 1.1 and pretty much complete their final draft. He wants to identify anything we need to know from MSG, apart from Arvola's list of interlock issues. Arvola reminded us of his query about whether sync reply belongs in BPSS. Jamie responded that BPSS, MSG and CPPA must all be aligned. David Smiley added that he has volunteered to head up version 1.1 issues for BPSS, working with Brian and Pallavi. Jamie inquired about timing. The following dates were reported in subsequent email from Pallavi:
November 30th, 2001 -- Last day for comments and issues for BPSS 1.1.
December 23rd, 2001 -- Last day to resolution/recommended changes for BPSS 1.1
January 14th, 2002 -- BPSS 1.1 draft release for eBTWG review
Arvola added that MSG plans to submit their version 1.1 to Karl Best on Dec. 4.
Dale asked whether QualityOfServiceInfo is stable and will remain in the MSG spec. Arvola thinks it will stay. David Fischer is questioning whether the Via element is still needed since they're possibly dropping TraceHeaderList, which would leave only SyncReply (which is needed for intermediaries that have no CPA to refer to). Dale and Arvola agreed that we need not worry about that, nor about use of sync replies on a per message basis, since that usage must agree with the governing CPA. Arvola feels that MSG and CPPA should specify sync replies the same way -- Dale spelled out that MSG uses Booleans, while we use an enumerated value. Arvola pointed out that another big issue is the interpretation of non-repudiation. He raised the question: How is it decided whether to ask for a signed or unsigned acknowledgement -- is it governed by explicit information in the CPA? Kartha asked if we need an AckRequested element in the CPA; Arvola feels the answer is essentially yes. On a related note, he's suggested that we separate Characteristics into BPCharacteristics and MSGCharacteristics. Marty has agreed and has suggested putting syncReplyMode under MSGCharacteristics. Dale and Tony also spoke in favor of the suggestion. Tony proposed checking with Brian Hayes to ensure that BPCharacteristics is (and remains) in sync with the BPSS spec. Jamie asked whether a value in a message could override the BPCharacteristics in the agreed CPA. Dale thought not. Jamie encouraged us to draw up a draft and offered to review it. Dale was unclear why we need two non-repudiation mechanisms, at the MSG and BP levels. Arvola though we could discuss with MSG whether to combine the mechanisms. He mentioned that MSG will vote at their F2F whether to drop their delivery receipt altogether. Arvola also mentioned that if the BPSS isIntelligibleCheckRequired attribute is true, the [BPSS level] receipt acknowledgement should only be returned after successfully checking the message syntax. Dale posed the possibility that a CPA might only agree on a signed acknowledgement, dropping the syntax check. He then pointed out the recommendation of the ebXML Security Risk Assessment team that we spell out what mechanism implements Characteristics, especially those related to security. Dale feels that fulfilling the recommendation will be tricky.
Marty reported that he had sent the negotiation sub-team an email request to schedule conference calls, but had only received three responses, so he urged the others to respond.
PartyName and PartyRef
Jean told us that she proposed the PartyName element as a simple way to directly identify a party by its common name (rather than by a code such as DUNS number). Kartha asked why the information couldn't be provided by the PartyRef element. Jean responded that PartyRef is an URL, and the type of the dereferenced URL is unconstrained. Dale elaborated that we do have a type attribute for PartyRef, but its values are unspecified. Jamie raised a legal question about a case where the persistent record of a message exchange goes to court. He suggested that if one party specifies a contact to call for help (a human "out") then the exchange could be repudiated if the other party failed to call for help. Marty was not concerned about that since use of PartyRef is non-normative. Jamie will review the relevant text. Marty raised an issue: our specification should non-normatively warn readers that the contents of the URL referenced by PartyRef are subject to change at any time, so PartyRef should be de-referenced only when needed, and not cached. After lengthy discussion, we agreed without objection to add partyName as a required attribute of PartyInfo that identifies the party by its familiar, well-known name.
ServiceBinding, ActionBinding and MSH-to-MSH Signals
Dale summarized recent list discussion as agreeing that ActionBinding will go under ServiceBinding, and that its purpose is (at least) to mark the actions that are BP signals. He noted that MSH-to-MSH messages must also be modeled. Arvola spoke in favor of Marty's suggestion to put an element under PartyInfo to indicate the delivery channel to be used for all MSH-to-MSH messages directed to that party. Arvola also remarked that reliable messaging SHALL NOT be used for such messages since they are not to be acknowledged. Following Kartha's query about possible use of secure channels, Marty suggested allowing multiple delivery channels under PartyInfo. Arvola concurred.
There will be another teleconference next week on November 15.