This list is a composite list of attendance reflecting
some period of participation either in person or by
teleconference.
There were two intervals, one on Monday, January 28
and one on Wednesday, January 30 in which motions were
discussed and voted upon.
On January 28, Peter Ogden moved to accept the January
10 minutes. Hima Mukkamala seconded. The motion passed
unanimously.
On January 30, Hima Mukkamala moved to allow voting
by email ballot. Arvola Chan seconded. After some discussion
in which procedures for balloting were clarified, the
motion passed unanimously.l The procedures will be that
the Chair will send an email message to Voting Members
with "VOTE" in the subject line. Votes will be saved
by the Chair in an archive for documentation. Votes
can be copied to the list if so desired.
Also on January 30, Marty Sachs moved to make the version
of the next CPPA specification "2.0." Arvola Chan seconded
the motion. Kevin Liu asked what features warranted
raising the version to a higher major version number.
Schema rewrites would make conformance to the original
version no guarantee of conformance to new version.
A number of changes were detailed. After this discussion,
the TC voted unanimously to move the version to "2.0."
The above minutes document the official TC decisions
at the Face-To-Face
The remainder of these minutes provide an overview
of the TC meeting. Detailed records of decisions on
issues within the issues database are recorded in that
database.
Peter Ogden, Arvola Chan, and Himagiri Mukkamala presented
an overview of changes that had been made already to
the 1.0 version. This presentation is available on the
web site for review.
The issues report consisting of issues with NULL target
versions was examined, and target versions assigned
[1.1] 210, 211, 212, 213, 214, 215, 216, 217, 218,
219, 220, 221, 222, 223, 224, 225
See Report on Disposition and Notes in Appendix.
The session Tuesday was devoted to reviewing issues
and deciding on their resolution or disposition.
See Report on Disposition and Notes in Appendix.
Reviewed issues to issue 208.
Time was allotted for motions and votes.
Candidate future topics were presented.
Session ended at 11:40.
See Report on Disposition and Notes in Appendix.
The OASIS ebXML-CPPA TC wishes to thank Brian Hayes
and Commerce One for hosting our face-to-face meeting
at the Commerce One Market Street facility. The spectacular
views did not discourage productivity, and the issues
list was largely covered and found resolved or resolvable
for the next release.
Issue ID
|
Issue
|
Disposition
|
Notes
|
Responsible Party
|
1
|
Technical Architecture Risk Assessment
|
Partly treated, and partly awaiting supporting
specifications such as xmlenc.
|
Mostly addressed but should be reviewed. Scope
is omitting authorization credential handling,
security policy such as CRL not handled. Algorithm
choice and strength recommendations not addressed--possibly
in a best practices from the ebxml-iic group.
Should we add PGP or SMIME enveloping examples
now? Arvola will try to include a digital envelope
packaging example in the CPP and CPA examples.
|
Ogden and Moberg
|
2
|
Security profile
|
Reflected in version 1.03
|
Peter notes that our SecurityDetails element
is really like the SecurityProfile element in
the TA document. We use SecurityPolicy for system
PKI policies such as CRL checking schedules. And
so forth. The Messaging idea of a profile may
be captured under BusinessProcessCharacteristics
in part (omit timestamp)
|
Ogden
|
3
|
Security policy element
|
Peter Ogden: "RESOLVED, sort of. We didn't
add anything specific under SecurityPolicy, but
we did put a wild card place holder into SecurityDetails."
|
Captured elsewhere.
|
Moberg and Ogden
|
4
|
Public-Key Infrastructure
|
Reflected in version 1.03.�The SecurityDetails
element now may carry 0 or more TrustAnchors elements.
(Of course, more detailed PKI issues may remain.)
|
Trust anchors
|
Moberg/Ogden
|
5
|
Packaging
|
Will investigate a placeholder for capturing
agreements on what is signed over...
|
May be deferred on or before March 1
|
Moberg and Ogden and Chan
|
6
|
NonRepudiation element improvements
|
Covered under issue 5
|
MSG Interlock issue
|
Moberg and Ogden
|
7
|
Nonrepudiation of receipt
|
Arvola noted that at f2f we agreed on language
to clarify the MSG NRR and business signal NRR
|
MSG Interlock issue
|
Chan
|
8
|
Signing of payload and header
|
|
|
|
9
|
Certificates
|
Af f2f agreed to add language warning of possible
need to synch. CPA expiration and cert. Expiration.
Keyinfo already has a ref mechanism so we can
use it. We declined to require that by- value
inclusion be prohibited.
|
|
Moberg, Ogden, and Sachs
|
10
|
Security attributes under Characteristics element
|
Arvola will add some text on "isTamperProof"
and on "isInteliigibleCheckRequired"
and Dale will review. "IsGuaranteedDeliveryRequired"
corresponds with RM. "TimeToAcknowledgeReceipt"
,"TimeToAcknowledgePerform" see also
issue 19
|
Omit "isConcurrent", "isLegallyBinding",
and "isPositiveResponse"
|
Chan and Moberg
|
11
|
Third-party security services
|
|
MSG Interlock. Timestamps and ???
|
|
12
|
Negotiation of CPA contents
|
|
|
|
13
|
Negotiation of Business-level parameters
|
|
|
|
14
|
CPP and CPA tools
|
|
|
|
15
|
Business collaboration specifications besides
BPSS
|
|
|
|
16
|
Middleware interoperability
|
|
|
|
17
|
Timeouts, number of retries, and retry interval
|
|
|
|
18
|
BPSS timeToPerform for BusinessTransactionActivity
and related CPPA parameters
|
|
Recommend clarifications in BPSS as needed
|
|
19
|
BPSS timeToPerform for Binary Collaboration and
related CPPA parameters
|
Added for sake of agreement on override. Does
not correspond with a messaging or security layer
implementation.
|
Consider override; Add to implementers guide
|
Hayes
|
20
|
BPSS timeToAcknowledgeReceipt and timeToAcknowledgeAcceptance
|
|
May deal with retries part in 2.0
|
Hayes
|
21
|
Consistency of timeouts and installation tools
|
|
Not sure if CPPA changes are needed
|
Hayes
|
22
|
Alternative message services
|
|
|
|
23
|
�Intermediaries and Multihop Scenarios
|
|
MSG Interlock.� Relates to use cases document:
issue 27.
|
|
24
|
TPA reference element
|
|
Interlock issue with BPSS to clarify isLegallyBinding.
|
Moberg
|
25
|
Specializations of generic business processes
for specific partners
|
|
Related to issue 46
|
|
26
|
Composition of Services
|
|
A BPSS issue.
|
|
27
|
CPA Use Cases
|
|
Clarify intent. Vision for uses, e.g., marketplaces
|
|
28
|
Nonrepudiation of message parts
|
|
Subsumed by work on SimplePart
|
Moberg, Ogden and Chan
|
29
|
Signed delivery receipt
|
Superceded. No delivery receipts.
|
MSG Interlock issue. Noted as done during 01/24/2002
call.
|
|
30
|
SOAP-SEC extensions and signatures in ebXML messages
|
|
SOAP-SEC is currently a W3C note.� Defer until
status progresses.
|
|
31
|
Trust anchor
|
Reflected in version 1.03.� The SecurityDetails
element now may carry 0 or more TrustAnchors elements.�
(Of course, more detailed PKI issues may remain.)
|
|
Ogden
|
32
|
Public key policies
|
Peter Ogden to review; noted as done during 01/24/2002
call
|
|
Ogden
|
33
|
Minimum requirement for security
|
Negotiation NDD governs ranges and preferences
|
Negotiation related
|
Ogden, Sachs, Mukkamala, Malu, Fischer
|
34
|
Policy conditionals for security
|
|
|
|
35
|
Grammars for packaging
|
|
|
|
36
|
Virtual Packaging
|
|
|
Ogden and Moberg and Chan
|
37
|
Direct selection of binary collaborations
|
|
|
|
38
|
Better way of specifying combinations of characteristics
|
|
|
|
39
|
Link from action attribute to matching business
transaction
|
ActionBinding related changes and ActionContext
and other changes have rendered this solved.
|
Need to clarify language about Characteristic
element's action attribute andits values
|
Mukkamala and Chan
|
40
|
BPSS isNonrepudiationRequired attribute and CPPA
Nonrepudiation element
|
BPSS is working on a NRR and NRO that implies
"isTamperProof"
|
Tools should warn of override; Align terminology
with BPSS
|
Chan, Malu and Mukkamala
|
41
|
Nonrepudiation of business signals
|
There are elements in the DC already there and
it is a future topic to establish any linkages
to the precise implementations underlying the
characteristic features.
|
Clarify NRR with Messaging team
|
Ogden
|
42
|
Guaranteed Delivery
|
If BPSS retains this defintion, it is questionable
that reliable messaging and guaranteed delivery
are alike.
|
We believe this to be a request to MSH for guaranteed
delivery. Seekconfirmation from BPSS team.
|
Malu
|
43
|
Binary Collaboration with more than one business
transaction
|
|
|
|
44
|
Other BPSS attributes to be reflected in CPPA?
|
|
|
Chan and Malu
|
45
|
"Optional" attributes
|
Does this arise? Is there an implied value when
missing? If it is missing then we are overriding
in some sense. No problem is consensus.
|
BPSS interlock
|
Chan and Malu
|
46
|
Overrides of details in BPSS Instance Document
(Process Specification Document)
|
|
|
|
47
|
Normative Appendix on Use of the CPA with the
ebXML Message Service
|
|
MSG Interlock issue
|
Chan
|
48
|
Possible need for TimeAccuracy and TimeToLive
|
Agreed during call that these are not needed
in CPPA
|
TimeAccuracy not needed.�TimeToLive is MSG Interlock
issue.
|
|
49
|
PersistDuration
|
Element retained.�Updated text in version 1.04.
|
MSG Interlock issue
|
Chan
|
50
|
Delivery failure negotiation
|
Try again. We have 1 more chance for the 2.1
version
|
Section 7.5.7 ebMSH, Sending MSH SHALL notify
the application also needed.
|
arvola
|
51
|
Timeout for delivery failure notification
|
Left as implementation decision
|
MSG Interlock issue
|
Chan and Moberg
|
52
|
Clarity re Routing of Response Messages to the
Correct Software Entry Point
|
|
|
Mukkamala
|
53
|
Ambiguity re Routing of Response Messages to
the Correct Software Entry Point
|
|
Same as 130.
|
Mukkamala
|
54
|
RefToMessageId element in Message Header
|
Arvola will add language to the Appendix on use
of CPA in Messaging indicating usage of RefToMessageId.
|
MSG Interlock issue
|
Moberg and Mukkamala
|
55
|
FTP definition
|
|
MSG Interlock - bring to their attention now
|
|
56
|
PartyId definition and example
|
|
|
Weida
|
57
|
PartyId type
|
|
|
|
58
|
Digests of Other External Documents
|
|
|
|
59
|
Publishing Party capabilities with a CPA template
instead of a CPP
|
Small business CPA template usage. Add to main
body at place near introduction-- where relation
of CPPs and CPAs discussed. Section 6.1 in the
vicinity of 430 to 441. See also old appendix
on cpa formation for some sample language.
|
Review text for clarity.
|
Weida
|
60
|
XML namespace usage
|
Removed in version 1.04
|
|
Chan
|
61
|
Optional messageOrderSemantics attribute with
value in XSD
|
Fixed in version 1.01
|
Arvola to fix schema (cited syntax is from Candidate
Recommendation)
|
Chan
|
62
|
Errors in CPA example
|
Fixed
|
|
Chan / Unal
|
63
|
"generated by XML Authority" in DTD
|
DTD is no longer used as of version 1.01
|
Already done in Arvola's working version.
|
Chan
|
64
|
Title of XSD Appendix
|
Changed in version 1.03
|
|
Weida
|
65
|
Namespace Definitions
|
The new namespace is http://www.oasis-open.org/committees/ebxml-cppa/schema/cpp-cpa-1_1.xsd.
|
Yes. See recommendation from Chris Ferris.�
Group to review.
|
Chan
|
66
|
Interaction between configuration inside a Party
and the CPA
|
|
Tony to review changes already made
|
Weida
|
67
|
Multiparty CPAs
|
|
|
|
68
|
Additional Transport Protocols
|
|
|
|
69
|
Payload Compression:
|
Can be handled under packaging as a bilateral
extension using application/gzip or related.
|
Consult MSG.� For 1.1, transport level compression,
e.g. gzip; describe inPackaging?
|
Chan
|
70
|
Include higher-level abstractions in the CPA
|
|
|
|
71
|
Figures in version 1.0 specification
|
Use paste special and uncheck float over text
in 97.
|
|
Weida
|
72
|
Definitions of terms (post Vienna)
|
Agreed during� Jan 10, 2002 call to have a glossary
within CPPA version 1.1.� Marty suggested starting
by pasting the glossary from the 1.0 requirements
document.
|
Determine plans for ebXML glossary
|
Weida
|
73
|
Publication of text forms of the DTD and XSD
files
|
Selected versions of the XSD will be posted to
http://www.oasis-open.org/committees/ebxml-cppa/schema/.
|
|
Chan
|
74
|
Business Service Interface
|
|
|
|
75
|
Clarification of syncReplyMode Attribute and
proposal for "mshSignalsOnly" value
|
Clarification provided and mshSignalsOnly introduced
in version 1.01
|
MSG Interlock issue
|
Chan
|
76
|
Minor inconsistency in Section 8 of the CPPA
spec
|
Reflected in version 1.02
|
|
Weida
|
77
|
Idempotency attribute
|
Not needed in CPP/A (per Arvola)
|
MSG Interlock issue.� Probably should be omitted
from 1.1.
|
Chan
|
78
|
Relationship between Acknowledgement, DeliveryReceipt,and
BPSS Business Signals
|
Delivery receipt gone.
|
MSG and BPSS interlock
|
Ogden
|
79
|
NonRepudiation tags
|
Yes in a sense characteristic element attributes
are redundant, yet serve to mark variations from
BPSS values. Also they abstract over alternative
choices of implementation.
|
For 1.1: Ack need for consistency. They express
summary information and enableBPSS independence.
|
Malu, Ogden and Moberg
|
80
|
Advertise use of of NTP,� XNTP etc. in CPP
|
|
Generally agreed mshTimeAccuracy is out.� Considered
a BP layer concern, not MSG.
|
|
81
|
Overlapping endpoint types
|
We need to disallow use of allPurpose when using
any of the other more restricted types.
|
Yes and no, respectively. (F2f consensus was
that these answers seemed mistaken.)
|
Weida
|
82
|
SimplePart and NamespaceSupported elements
|
Reflected in 1.01 (resolved by Arvola's changes)
|
|
Weida
|
83
|
Are signals meaningful in case syncReplyMode
is not set to none?
|
|
BPSS interlock issue
|
Chan
|
84
|
ackRequested attribute in Via element (of MSH)
and QOS
|
Fixed per Arvola.
|
MSG Interlock issue
|
Chan
|
85
|
Primer on message construction
|
|
Aynur and others; scope TBD
|
Unal
|
86
|
Designation of mutually trusted third party
|
|
e2Open will try to identify a contributor
|
Unal
|
87
|
RosettaNet Retry Parameter not Expressible in
BPSS or CPP/A
|
CPA could be extended to� handle special values
by using wildcards. BPSS will� eventually express
BP level retry. Residual issue is whether an override
of this BP param can be made within CPA. Hayes
writes text Arvola adds to 0.12
|
Brian to clarify w/ BPSS if retries expressible
in their spec.
|
Hayes and Arvola
|
88
|
Piggybacking of signals on application level
messages via packaging
|
Fixed per Arvola.
|
|
Chan
|
89
|
Linkage of SimplePart element to BusinessDocument
at the BPSS level
|
1.05 line 2375, xlink:role can be used to fulfil
this idea of the connection. Possible textual
elaboration for how the BPSS BusinessDocumentEnvelope
can be pointed at...
|
MSG/BPSS interlock issue; need some textual description
|
Chan and Malu
|
90
|
T2 Non repudiation and MSG, CPP/A, BPSS spec
alignment
|
RM Acknowledgment governed by MessagingCharacteristics
element; non repudiation governed by DeliveryChannel
and DocExchange elements.
|
|
Chan
|
91
|
Delivery Receipt, NRR and MSG/CPPA/BPSS (mis-)alignment
and thelayering mishmash
|
|
See issue 134
|
Chan
|
92
|
Dependency on ebXML Requirements spec.
|
Unknown whether we have taken these references
out. Check with Tony. We suspect it has been done.
|
Expunge any references
|
Weida
|
93
|
Clarity of text re NRR / Delivery Channel and/or
separate send delivery channel
|
Reflected in version 1.03
|
|
Ogden
|
94
|
Signature Method Element
|
1.05, section 7.5.52 Essential question may be
whether we need an additional negotiable parameter
to match xmldsig signatures.
|
|
Moberg and Hima
|
95
|
Lack of processing rules
|
Closed during 01/10/2001 teleconference -- not
a CPPA issue
|
See issue 85.
|
|
96
|
Key Management
|
|
"IIC best practices"
|
|
97
|
Encouragement of selected protocols
|
Ask IIC about this...
|
Out of scope; forward to suitable group such
as IIC
|
Moberg, Ogden and Mukkamala
|
98
|
Transport compression
|
Wait until messaging does something on this
|
See issue 69
|
Chan
|
99
|
Signing Message Parts
|
Packaging does SMIME the xmldsig reference question
is elsewhere deferred.
|
|
Moberg & Ogden
|
100
|
Use of Schema: Application to individual elements
|
|
|
|
101
|
Super schema for CPP + CPA
|
|
Deferred pending motivation
|
|
102
|
Nonrepudiation in the delivery channel vs. the
certificate in the role tag.
|
Reflected in version 1.03
|
Originated from the financial community.� Should
the MSH be used as a proxy forthe end app?
|
Ogden
|
103
|
non-repudiation of receipt (NRR) at the message
level
|
sounds like a question for messaging
|
MSG Interlock issue
|
Chan
|
104
|
Nonrepudiation archival
|
|
May belong in TPA; useful for configuration
|
Clark, Malu and Hayes
|
105
|
Non Meaningful Example of a Packaging element
|
Fixed in version 1.01
|
|
Chan
|
106
|
Incorrect cross-reference to BPSS element
|
Reflected in version 1.02 Need to get rid 7.5.5.1
last line because that element only used in multiparty
BPs.Need reopening now for deletion.
|
|
Weida
|
107
|
Inconsistent spelling of uriReference
|
Reflected in version 1.01
|
|
Chan
|
108
|
cpp-cpa-v1_0.xsd cannot be read by Internet Explorer
5.0
|
Fixed
|
|
Chan
|
109
|
Appendix D is out of date
|
Fixed
|
|
Chan
|
110
|
Appendix D: Retries, RetryInterval, and PersistDuration
|
Appropriate data types are now used for these
elements.
|
|
Chan
|
111
|
Overriding Timing Parameters Specified in a Business
Process
|
|
On list for negotiation team
|
|
112
|
All examples that refer to tp:version="0.98b"
should be updated.
|
Reflected in version 1.01
|
|
Chan
|
113
|
Clarification of NamespaceSupported element advertising
in CPP
|
Add text that explains that under ../EbXMLBinding/NamespaceSupported we are only listing namespaces not required by
Messaging. Second, for all NamespaceSupported
add location Third add text explaining convention
that first namespace supported is the primary
namespace for that implePart.
|
Clarify text, e.g., to omit common namespaces
|
chan and moberg
|
114
|
Protocol element's version attribute should not
be FIXED
|
Reflected in version 1.01, where the text of
the section specifies "required" (while
the attribute remains optional in the schema)
|
Artifact of DTD; Arvola to ensure schema is correct;
Weida to ensure consistenttext
|
Chan and Weida
|
115
|
cpaid is not of type CDATA
|
Reflected in version 1.01
|
|
Weida
|
116
|
attributeFormDefault in Appendix D incompatible
with examples in Appendix A & B
|
Fixed
|
|
Chan
|
117
|
Clarify and detail support of SSL mutual authentication
|
Changes to Transport handle Client and Server
side SSL authentication explicitly as of 0.12
schema and 1.05 text.
|
MSG Interlock wrt basic authentication in/out
1.1;Fix CertRef; permit CertRefin other locations
|
|
118
|
Problem with Non Repudiation over a Synchronous
Delivery Channel
|
Reflected in version 1.03
|
|
Ogden
|
119
|
name attribute in ProcessSpecification
|
Reflected in version 1.01
|
Text to follow Appendix D
|
Weida
|
120
|
action attribute in section 7.5.8.1and xlink:href
attribute� in section 7.3.7.4
|
fixed
|
|
Chan
|
121
|
Business rules and constraints
|
|
|
|
122
|
Generalized credential container
|
|
|
|
123
|
Indicate use of� basic authentication
|
Under Transport elements, add element for AccessAuthentication
with an attribute� for type, "basic"
or "digest" Have placeholder for future
agreements on pointers to a credential document.
|
Boolean for 1.1
|
Ogden
|
124
|
Possible addition of CipherSuites element under
TransportSecurity
|
Reconsider for next enhancements to security
support.
|
MSG Interlock issue (consider in light of SSL
negotiation)
|
|
125
|
Spelling of NonRepudiation element
|
Reflected in version 1.01
|
|
Chan
|
126
|
SMTP Delivery Status Notification and Message
Disposition Notification
|
|
DSNs are part of the SMTP and MTA defined behavior
and nothing really to agree upon. MDNs could be
a subject to an agreement.
|
|
127
|
Specializations of generic business messages
for specific partners
|
|
May slip to 2.0 Noticed that these agreements
are about BOD or BIE details and we may subsume
under next version's treatment of� suport for
agreement on Context negotiation.
|
|
128
|
Two-phase commit and long-running transactions
|
|
|
|
129
|
Non-PKI security
|
SecurityDetails is consistent with self-signed.
PGP keyrings can be exchanged using KeyInfo.
|
Ensure that trust anchors are optional and/or
provide PGP example
|
Ogden
|
130
|
Routing ambiguity when two different BPSS instancedocuments
are used at once
|
Messaging header has role element. Actions different
for request and response
|
|
|
131
|
MSH timeout
|
fixed per Arvola
|
Start of interval must be defined for 1.1.� Overall,
an MSG Interlock issue.
|
Chan
|
132
|
Is MSH the endpoint for Nonrepudiation of receipt?
|
Two flavors of NRR.One is signal and at business
level and the other is the signed Ack. Signed
ack may or may not be archived. Also NRR may involve
a content check semantics. For us, NRR really
implies archiving. For Messaging, signed ack has
no archiving defined. If you assert a DC has NRO/NRR
then some upper service MUST archive.
|
MSG Interlock issue
|
|
133
|
Clarify MSH, Middleware, and their relationship
|
|
BSI needs to be defined.
|
|
134
|
isIntelligibleCheckRequired property from BPSS
|
Attribute is being added under another open issue
heading, number 10
|
Should this be overridable?
|
|
135
|
Technical report on interoperability across Messaging,
BPSS and CPPA specs
|
Brian is writing up a doc on BPSS and CPPA mapping.
Arvola's appendix handles Message header element
mapping.
|
Contribute to work of IIC (M. Wang)
|
Hayes
|
136
|
Use the (only)� digest algorithm mentioned in
the XML DSig specification
|
Reflected in version 1.02
|
|
Weida
|
140
|
invocationLimit attribute appears to be a CPA
Lifetime attribute
|
invocationLimit pertains to CPA renegotiation.
|
|
|
141
|
State that a modified Process Spec should be
registered in a Business Library.
|
Action Item: find lines or sections where this
insertion was to occur. Decided nothing to do
at this point
|
Informational text to be added
|
Hayes
|
142
|
Remove or elaborate on description of process
specification modification
|
|
Section 8 in the context of a CPA composition
tool. Lines 2905 through 2909. Possibly a nonissue
if process specification versions are always uniquely
identified.
|
Weida
|
143
|
Adding a ccpid element to the CollaborationProtocolProfile.
|
Arvola will add cppid for version schema version
0.13
|
Independent of any registry-assigned identifier.
Still looking for use cases.
|
Chan
|
144
|
CPP Categories
|
|
Potentially supports automatic classification
in a registry.
|
|
145
|
CPA Categories
|
|
|
|
146
|
Format of URI PartyID reference
|
Reflected in version 1.02 New naming scheme to
be provided by Brian Hayes for version 1.07
|
|
Weida
|
148
|
ProcessSpecification xlink:href attribute.
|
Arvola adds optional attribute for UUID of the
BPSS. Hima adds text for attribute.
|
|
Hima
|
149
|
Explicitly identify/discuss ds:URI and ds:Digest
elements (of ds:Reference)
|
Reflected in version 1.04
|
Add backpointer to spec.
|
Weida
|
150
|
CPP/CPA Worksheets Proposal
|
|
|
|
151
|
Specify type for PartyRef
|
f2f adding schema location attribute.� Moving
toward a standardized way of registering URNs
used in "type" attributes. Dale continues
to check with Karl on URN namespace
|
Non-normative statement suggesting XML schema.�
Jean to research possibleexamples.
|
Chan and Moberg
|
152
|
Need for packageId attribute if there is only
one Package per CPP/CPA
|
|
|
|
153
|
Cardinality of PartyRef and PartyInfo in the
XSD
|
Fixed
|
|
Chan
|
154
|
Type of PersistDuration element
|
fixed
|
|
Chan
|
155
|
SSL details and location
|
See also issue 124. This refers to lines 1861
to 1869 in version 1.05 and changes the subhead
as suggested.
|
It would be useful to indicate that a high key
strength is required.
|
Weida
|
156
|
Reliable messaging changes in the MSG team's
1.1 spec
|
fixed per Arvola
|
|
Chan
|
157
|
Reliable-messaging retries based on Acknowledgment
or DeliveryReceipt?
|
DeliveryReceipt is no longer used in the Messaging
spec.
|
|
|
158
|
Separate SOAP modules for reliable messaging
with and without intermediaries
|
Actor attribute takes care of this agreement
dimension.
|
|
Chan
|
159
|
Reorganization of SendingProtocol and ReceivingProtocol
elements
|
Fixed in version 1.03.
|
|
Ogden
|
160
|
TLS support
|
|
|
|
161
|
Numbering of subsections within section 7.5.8
|
Reflected in version 1.01
|
|
Chan
|
162
|
Indicate reliable messaging method
|
Irrelevant because ebxml and transport not distinguished
anymore.
|
|
|
163
|
Disposition of synchReplyMode attribute of Characteristics
element
|
Fixed. The syncReplyMode attribute is now under
the MessagingCharacteristics element.
|
|
Chan
|
165
|
Cardinality of CPA signatures
|
Clarified in version 1.04 that the maximum is
3.
|
|
Chan
|
166
|
Multiple Packaging elements per ServiceBinding
|
Resolved in version 1.01 - each ActionBinding
has its own packaging
|
|
Chan
|
167
|
Identify action for business Receipt Acknowledgment
or Acceptance Acknowledgment
|
Fixed in version 1.04: 1. Clarify that ReceiptAcknowledgment,
AcceptanceAcknowledgment, and Exception are the
values for the action attribute that should be
used for business signals.
|
BPSS interlock
|
Chan
|
168
|
Multiple schemas per SimplePart
|
Resolved by finer grained actionbindings
|
Arvola to investigate and report during January
2002 F2F
|
Chan
|
169
|
Handling exceptions when synchronous messaging
connection is lost
|
Businesses will have to solve this one.
|
|
Chan
|
170
|
Synch and asynch override of the same action
|
ActionBindings now can specify several DCs under
one service binding for a given action. For schema
version 0.13.
|
|
Chan
|
171
|
Should a SimplePart be reusable?
|
Reflected in version 1.01
|
|
Chan
|
172
|
DeliveryChannel selection
|
Fixed. DeliveryChannel now refers to Transport
and DocExchange elements which have sender and
receiver specific sub-elements.
|
|
|
173
|
CPAId SHALL be used in message header
|
Clarify that cpaid attribute in CollaborationProtocolAgreement
element MUST be used as CPAId in ebXML Message
Header.
|
|
Chan
|
174
|
Implementation timeouts
|
"TimeToPerform" attribute� is to be
clarified to use that value to timeout a synchronous
connection.
|
|
Chan
|
175
|
End-to-end encryption between persons/applications
|
The version 1.0 "confidentiality" attribute
of the BusinessProcessCharacteristics element
provides for this.
|
Arvola feels wording too strong.� Several of
us discussed finer-grained alternatives.� See
issue XXX
|
Weida
|
176
|
PartyName element
|
Reflected in version 1.01
|
|
Zheng
|
177
|
Quality of Service for messaging
|
Fixed with Characteristics changes
|
|
Chan
|
178
|
Delivery channel for errors must not specify
reliable messaging
|
Arvola note "This constraint is no longer
valid." Stay tuned. There is still a dispute
in Messaging
|
|
Chan
|
179
|
Clarify that RetryInterval applies after original
message and subsequent retries
|
Fixed in version 1.04
|
|
Chan
|
180
|
BPSS & CPP/A alignment issue: synchronous
vs asynchronous flow of control
|
Closed per Jan. 10, 2002 teleconference, along
with creation of separate issue 180.
|
|
|
181
|
SimplePart should capture schema for payload
as given in the messaging Manifest
|
Reflected in version 1.01 - the NameSpaceSupported
element contains a tp:location attribute
|
|
Chan
|
182
|
Replace Characteristicswith BPCharacteristics
and MSGCharacteristics ...
|
Fixed
|
|
Chan
|
183
|
Should CPA indicate agreement on honoring MSG's
syncReply boolean?
|
Closed during 01/10/2001 teleconference -- no
longer needed for alignment
|
|
|
184
|
Interpretation of MSG's syncReply boolean
|
Closed during 01/10/2001 teleconference -- no
longer needed for alignment
|
|
|
185
|
Warn readers about non-normative nature of PartyRef
|
Reflected in version 1.01
|
|
Zheng
|
186
|
PerMessage messaging attributes
|
"perMessage" value introduced in version
1.01
|
|
Chan
|
187
|
Messaging vs. BPSS/Application level functionality
|
|
|
|
188
|
Clarification of PersistDuration
|
Clarified in version 1.04Move persistDuration
into MessagingCharacteristics Words will be fixed
or moved in 1.07
|
|
Chan
|
189
|
BPSS and business level retry counts
|
|
|
|
191
|
SMTP e-mail addresses and certificates
|
|
|
Moberg
|
192
|
Names and usage of BusinessProcessCharacteristics
attributes
|
|
|
Chan
|
193
|
Enumerated types and unique identifiers for PartyID
|
b
|
|
Moberg
|
194
|
Interpretation of confidentiality attribute in
DeliveryChannel
|
Persistent confidentiality is not yet described
enough to rule on Arvola's question. BPSS may
clarify this for us.Remove sentence from spec
until settled.
|
|
Chan/Mukkamala/Ogden/Weida
|
195
|
Require that Service value in message header
agree with CPA
|
Version 1.0 and later stated "The value
of the Service element is a string that SHALL
be used as the value of the Service element in
the ebXML Message Header[ebMS] or a similar element
in the Message Header of an alternative message
service. " Can be submitted to Messaging
spec issues list....
|
|
|
196
|
Text about intermediaries specifically for version
1.1
|
Statement removed� in version 1.04
|
|
Weida
|
197
|
Context for interpretation/execution of BPSS
|
|
|
|
199
|
Use of enumerations
|
URNs for constants need to be defined. Explain
how the URN registries would work to add interoperably
add new values without schema changes.� This may
fall into a later version ...
|
Similar work in XCBL
|
Hayes/Moberg
|
200
|
IMPLIED vs. REQUIRED version attributes (inconsistency?)
|
Make version attributes required
|
|
Chan
|
201
|
Duplicate sections (or lack thereof) for attributes/elements
that reoccur
|
Refer back to main common discussion and add
any contextual qualifications needed. Check for
real duplicates
|
|
Weida
|
202
|
Order of presentation for attributes and subelements
|
Sense of team during 01/24/2002 call was to present
attributes first
|
|
Weida
|
203
|
Need SecurityPolicy for Certificates as well
as TrustAnchors
|
Use cases unclear here.
|
|
Ogden and Moberg
|
204
|
Definition of "application"
|
|
Peter Ogden will send out email
|
All
|
205
|
Use of terms: requester, sender, client, responder,
receiver, server
|
|
terms to be entered in glossary
|
Weida
|
206
|
Separate chapters in spec for large complex elements
|
|
Sense of 01/24 call was to clean the existing
scheme rather than rearranging everything.� TBD
@ F2F
|
Ogden and Weida
|
207
|
Spontaneous business process interactions and
SMEs
|
|
|
Moberg (with D. Burdett)
|
208
|
Need for trusted clients and trusted domains
|
|
|
Moberg
|
210
|
Editorial: Delivery channel describes both sending
and receiving characteristics
|
|
Similar to Marty Sachs Editorial
|
Weida
|
211
|
Usage of PartyID type attribute
|
|
Notes We would like the values used for the type
attribute.
URN: Oasis:Names:[specifcation� -or- tc� -or-�
technical] DefiningAgency
URN:OASIS:[Names or Members]:tc:ebxml-cppa:PartyIdtype:DUNS
This identifier serves to indicate classification
scheme PartyId value belongs to.��������������������
IPR issues?���������������������� URN:OASIS:Names:tc:ebxml-cppa:PartyIdtype:OID:dun.dot.oid��������������������
URN:OASIS:Names:tc:ebxml-cppa:PartyRefType Tp:type
is the schema's (resolvable) URI for the data
pointed to by the xlink href. Do we need the schema
location also? Endpoint and Service have types
too.� Compare with RFC 3151 on public identifiers.
|
Moberg
|
212
|
Editorial: Reference to eBPSS
|
|
Consensus yes
|
Weida
|
213
|
Editorial: ActionContext affected by alternate
process specification schemas
|
|
Yes include in list
|
Weida
|
214
|
Significance of different Service Bindings in
Collaboration Role
|
|
|
Mukkamala
|
215
|
Is name attribute of ProcessSpecification element
tied to BPSS?
|
|
Name attribute to be removed
|
Chan
|
216
|
ServiceBinding example is missing the defaultSignalChannelID
attribute
|
|
Name attribute not needed here.Revise check accordingly.
Chan to remove from schema by 1.07 draft
|
Weida
|
217
|
Editorial: italicization of element names
|
|
|
Weida
|
218
|
Business signals: incorrect usage and missing
instance
|
|
Notes� Terminology difference: are exceptions
business signals?� Needs BPSS alignment
|
Hayes
|
219
|
Need for delivery channel and service binding
with notification pattern
|
|
Remove
|
Weida
|
220
|
Editorial: BusinessProcessCharacteristic no longer
has syncReply attribute
|
Remove
|
|
Weida
|
221
|
nonRepudiationOfOrigin attribute concerns business
level ack
|
|
No consensus on this yet
|
Mukkamala
|
222
|
MSH level ack not possible in sync reply mode
|
|
Notes It is possible for HTTP 1.1 clients and
servers, Two HTTP requests and replies will be
sent and received. A warning or note needs to
be added. Also change that business signals are
likewise technically possible, but warn implementers.
|
Weida
|
223
|
location of SimplePart in spec consistent with
schema
|
|
Consensus to shift to follow schema ordering
as Hima notes
|
Weida
|
224
|
Why not multiple PartyIds for each PartyInfo?
|
|
Messaging allows multiple partyIds, so we will
follow themFriday
|
Weida
|
225
|
Reflect new schema for Transport element
|
|
CPA formation appendix to be rewritten in early
February
|
Moberg
|
226
|
Certifcate Expiration and CPA expiration
|
|
|
|
227
|
CPA and Certificate Expiration
|
|
Marty S, Chris F and others contributed to the
email thread
|
Moberg
|