Minutes of CPPA Conference Call Nov. 29, 2001
Peter Ogden and Dale Moberg
Nov. 29, 2001
Attendance:
Kevin Liu
Pallavi Malu
Peter Ogden
Hima Mukamala
Brian Hayes
Pete Wenzel
Marty Sachs
Dale Moberg
David Smiley
Jean Zheng
David Fischer
Arvola Chan
Jamie Clark
Administrative items:
Dale provided some news items: Jacques Durand is doing a study on BTP and how transaction role agreements might be added to future CPAs. Watch the list for its appearance.
Wrote to XACML about using their notation for our security policy notation; does NOT think it's ready yet. Will reconsider it for 2.0.
JSR 157 (Java API for CPPA) expert team has critical mass, and is moving along at expected pace, says Hima and Dale.
Negotiation: Line-by-line review of original white paper continues. Marty stated that only about half of those who originally expressed interest in negotiation have signed up for the new Negotiation mailing list.
Hima: As liaison to Conformance Committee, Hima wonders whether we have a conformance clause in our spec. Dale/Marty stated that we have one, suggested that Hima review it (along with Conf. Comm.) and suggest any necessary improvements.
Dale: re January F2F meeting: Given that we hope to have a merged 1.1 draft ready in January, thinks a F2F might be useful. Marty wants to have a Negotation F2F either before or after. Suggested 1/28-30.
December conference calls: 12/6, 13, 20.
Here are version 1.1 work commitments so far:
Peter will write up CertificateRef enhancements needed for alignment, such as client side SSL.
Dale will write up Security Details element description.
Jean will write up PartyName/PartyRef.
Arvola will work on Schema, Normative Appendix, and identify added elements and documentation needing modifications. For the central changes, like ActionBinding, will draft new comments.
Hima will work on Service/Action binding.
Brian will review Service/Action
Marty will review everything (as time permits!)
Added later: Jamie will review/contributes to Service/Action edits and additions.
Everyone encouraged to decide what they can commit to
drafting, reviewing, for the mid-December target of
starting a merge for version 1.1. This timing is subject
to Tony's agreement and availability.
Discussion of BPSS work related to action naming. There
will be a way to explicitly identify all services and
actions. All supported actions will be enumerated, with
both the "long" hierarchical name, and its short
name, scoped by CPAId, that would provide the value
used to populate the message field. This will replace
the 1.0 default behavior that all actions (with the
indicated role) are referenced under ServiceBinding.
ServiceBinding will still make the connection to a BPSS
(or other BP level choreography document). Arvola provided
a summary of the advantages.
Discussion of alternative (non BPSS-based) collaboration protocols. The new text surrounding this will need to point out that the spec was developed with BPSS in mind, but that other protocols should be allowed/supported, and we may want to give advice to anyone attempting to use them. Hima agreed to draft language for this.
Discussion of per-message parameters. Arvola sent out new proposal yesterday.
Some consensus that the new elements under MessagingCharacteristics-Ack, AckSignature, DuplicateElimination, and MessageOrder-seem to be able to express the needed distinctions. The enumeration is in perMessageCharacteristics.type and is to have a range of true, false, and perMessage. (Added while writing -- Version Dale has cpp-cpa-03 seems to have a different enumeration range. Will check with Arvola whether I misrecorded enumeration range values...) Marty indicated that MessageOrder seemed more a channel characteristic, than a perMessage selectable choice. Marty noted that ConversationId and Request/Response sequencing provide an ordering already. Several concurred that MessageOrder seemed even less well motivated than the others to be selectable on a perMessage basis. But Messaging alignment remains a priority. Jamie selected that possibly deprecating language could be provided to discourage certain perMessage agreements, especially when BPSS in the ServiceBinding might have characateristics in conflict with variable perMessage choice.
|