ebXML CPPA Technical Committee Teleconference
(Non Voting)
February 7, 2002
Attendees
Arvola Chan
David Fischer
Dale Moberg
Himagiri Mukkamala
Marty Sachs
Pete Wenzel
Tony Weida
Minutes
We discussed issues 200 and above, with significant changes or observations as follows. During the process, we agreed that all database issues targeted for version 1.1 with a status of "Deferred" would be retargeted for version 2.0 with a status of "Open". [The F2F decision that the next version will be labeled 2.0 rather than 1.1 is not yet reflected in the database.]
200 IMPLIED vs. REQUIRED version attributes (inconsistency?)
We resolved that all version attributes are to be REQUIRED as decided at the F2F, except that the version attribute of the NonRepudiationProtocol element will be IMPLIED.
201 Duplicate sections (or lack thereof) for attributes/elements that reoccur
Dale asked that everyone help to identify such instances. Hima suggested splitting up the spec for review, and Dale accepted that as an action item.
202 Order of presentation for attributes and subelements
This is a pending editorial matter.
203 Need SecurityPolicy for Certificates as well as TrustAnchors
204 "Definition of ""application"""
Tony will add a definition to the glossary, although Marty noted that the definition was an "unsolvable problem" and in particular that the upper interface of the MSH is undefined.
205 Use of terms: requester, sender, client, responder, receiver, server
Tony will add definitions to the glossary. Marty suggested also discussing such terms up front in the spec.
206 Separate chapters in spec for large complex elements
207 Spontaneous business process interactions and SMEs
Left open for 2.0. Marty thought this could be discussed in a best practices document.
208 Need for trusted clients and trusted domains
Dale noted that SecurityDetails can specify TrustAnchors for clients and servers and that the level of CA CPS trust is a local policy matter.
210 Editorial: Delivery channel describes both sending and receiving characteristics
211 Usage of PartyID type attribute
Dale will consult with Brian Hayes and send a proposal to the list by early next week.
212 Editorial: Reference to eBPSS
213 Editorial: ActionContext affected by alternate process specification schemas
214 Significance of different Service Bindings in Collaboration Role
Hima will send a draft to Tony and Dale.
215 Is name attribute of ProcessSpecification element tied to BPSS?
A UUID attribute will be added as part of Arvola's version 1.07 changes. The name attribute will be IMPLIED and will be considered informative only.
216 ServiceBinding example is missing the defaultSignalChannelID attribute
This attribute will be removed in version 1.07, and then the issue will be closed.
217 Editorial: italicization of element names
218 Business signals: incorrect usage and missing instance
Hima withdrew this issue for version 1.1 and it will be closed.
219 Need for delivery channel and service binding with notification pattern
220 Editorial: BusinessProcessCharacteristic no longer has syncReply attribute
221 nonRepudiationOfOrigin attribute concerns business level ack
Tony will change the issue to refer to nonRepudiationOfReceipt. Hima will submit a paragraph to the list for inclusion in the BusinessProcessCharacteristics section.
222 MSH level ack not possible in sync reply mode
Tony will note in the spec that while this is possible, it takes advantage of the HTTP 1.1 feature not to close connections, so implementers need to make sure that their environment supports that feature.
223 location of SimplePart in spec consistent with schema
224 Why not multiple PartyIds for each PartyInfo?
Although this issue is resolved, Dale asked if there's a need to say anything in the CPPA/MSG correspondence table. Arvola will look into it.
225 Reflect new schema for Transport element
226 Certifcate Expiration and CPA expiration
Tony will work on the text. This issue will be combined with 227, and one will be closed as a duplicate.
227 CPA and Certificate Expiration
228 Rename or restructure BusinessProcessCharacteristics
Arvola and Tony will be responsible for changes to the schema and text, respectively.
229 Add ApplicationSecurityDetailsRef element to example for CollaborationRole
Arvola pointed out that the sections on the subelements are very sketchy and Hima agreed that much more work needs to be done. Arvola thought it might be more expedient to remove these two elements for the next version. Dale will try to come up with more details, but it's still possible that we'll defer the matter until the next version.
230 ds:Keyinfo subelement structure handled implicitly by deployment tool?
Tony will change the section header from "element" to "attribute" and shift its location accordingly. The section will say that XML DSIG SHALL be used for signing, and that DSIG-aware tools will take care of what's called for. Will note that tools that do signing need to be DSIG aware.
231 Add version numbers to references for ebBPSS, ebMS, and ebRS
Arvola is making some updates. We'll refer to ebMS 2.0 and ebRS 2.0. We can contact Brian or Pallavi about the status/plans for BPSS.
232 Copyright statement
Tony mentioned that he's sent an inquiry to Jamie Clark and is awaiting a reply.
233 Delete Appendix on Formats of Information in the CPP and CPA
We agreed to delete this appendix.
234 Glossary terms primarily defined in other ebXML specs
After some discussion, we agreed to decline the issue.
235 Cardinality of TrustAnchors element under SecurityDetails
We agreed to have at most one TrustAnchors element. Hima will draft some text and send it to the list.
236 Cardinality of SecurityPolicy element under SecurityDetails
We agreed to have at most one SecurityPolicy element.
237 Placeholder values in CPA templates
We agreed to defer this for the next version. Tony recalled that XSD has a special provision for NULL values and agreed to post details on the list.
Next Meeting
There will be another teleconference next week on February 14.
[Note: Dale subsequently posted an inquiry about rescheduling our calls, but no definitive resolution has been announced as of this writing.]
Metadata
Please send additions and corrections to Tony Weida (rweida@hotmail.com).
Respectfully submitted,
Tony Weida
|
