|
Modify paragraph in subsection 8.4.43 to read:
The SenderNonRepudiation element is comprised of the following child elements:
- a REQUIRED NonRepudiationProtocol element,
- a REQUIRED HashFunction (e.g. SHA1, MD5) element,
- one or more REQUIRED SignatureAlgorithm element,
- a REQUIRED SigningCertificateRef element
When used within a CPP, the SignatureAlgorithm element can be repeated to indicate supported capabilities. The order within a repeated list of elements indicates comparative preference, from most to least preferred. When used within a CPA, the SignatureAlgorithm value is the agreed upon signature algorithm.
Modify paragraph in subsection 8.4.54 to read:
The ReceiverNonRepudiation element is comprised of the following child elements:
- a REQUIRED NonRepudiationProtocol element (see Section 8.4.44),
- a REQUIRED HashFunction (e.g. SHA1, MD5) element (see Section 8.4.45),
- one or more REQUIRED SignatureAlgorithm element (see Section 8.4.46),
- zero or one SigningSecurityDetailsRef element
When used within a CPP, the SignatureAlgorithm element can be repeated to indicate supported capabilities. The order within a repeated list of elements indicates comparative preference, from most to least preferred. When used within a CPA, the SignatureAlgorithm value is the agreed upon signature algorithm.
[Note: in the ebXML CPPA 2.1 maintenance version, additional subsections within the CPA section will contain the CPA specific information that:
A CPA shall have exactly one SignatureAlgorithm element whose value is the agreed upon signature algorithm.
These sections will be referenced from the above subsections that are numbered 8.4.43 and 8.4.54 in the 2.0 release.]
In section 8.4.13, replace the statement:
"The OtherPartyActionBinding element is only used in the case of CPAs." by the statement:
"The OtherPartyActionBinding element is REQUIRED in CPAs and CPA templates and SHALL NOT be used in a CPP."
The string values for the ReceiptAcknowledgment action on lines 3583, 3675, 4086, and 4136 should all be spelled "ReceiptAcknowledgment". Therefore, line 3583 should read: tp:action="ReceiptAcknowledgment" and line 4086 should read: tp:action="ReceiptAcknowledgment"
The second row item for "Role" in Appendix F, Correspondence Between CPA and ebXML Messaging Parameters, should indicate that the value for the "Role" element in the ebXML Messaging v 2.0 header corresponds to the value found in the Role/@name attribute in the CPA.
Convention for indicating Packaging consisting of a single MIME entity of a non-composite, non-encapsulating type:
Until the OASIS ebXML TC approves an updated version of the version 2.0 CPPA core specification, the convention for indicating Packaging that consists of one SimplePart will be as follows: The mimetype value for the Composite and the mimetype value of the SimplePart referred to by the Constitutent shall be identical. In that case, there will be only one Constituent element in the Composite, and only one Composite in the CompositeList. The mimeparameters attribute on the Composite element would typically then be omitted.
In Section 8.6.2 of the specification version 2.0, the following changes apply:
The mimetype attribute provides the value of the MIME content-type for this Message part, and this will be some MIME composite type, such as "multipart/related" or "multipart/signed".
When the preceding convention is used, the Composite mimetype attribute can have simple mime types, such as "text/xml," "application/xml," and others as appropriate.
When the mimetype value for the Composite is a composite type (such as "multipart/*" or "message/*"), then the Packaging element indicates that a composite type includes Constituents of SimpleParts (and possibly other parts) as is typical when using MIME for attachments.
Future direction:
When updates to the version 2.0 CPPA core specification are made, it is expected that the schema for the Packaging element will be updated to allow a choice over CompositeList and Constituent. When a Constituent occurs, the Packaging is just the SimplePart to which the Constituent refers. The convention introduced above will, however, be retained, although deprecated for new applications.
The anticipated schema change in updates to 2.0 will be from:
<element name="Packaging">
<complexType>
<sequence>
<element name="ProcessingCapabilities">
<complexType>
<attribute name="parse" type="boolean" use="required"/>
<attribute name="generate" type="boolean" use="required"/>
</complexType>
</element>
<element name="CompositeList" maxOccurs="unbounded">
<complexType>
<choice maxOccurs="unbounded">
<element name="Encapsulation">
<complexType>
<sequence>
<element ref="tns:Constituent"/>
</sequence>
<attributeGroup ref="tns:pkg.grp"/>
</complexType>
</element>
<element name="Composite">
<complexType>
<sequence>
<element ref="tns:Constituent" maxOccurs="unbounded"/>
</sequence>
<attributeGroup ref="tns:pkg.grp"/>
</complexType>
</element>
</choice>
</complexType>
</element>
</sequence>
<attribute ref="tns:id" use="required"/>
</complexType>
</element>
to
<element name="Packaging">
<complexType>
<sequence>
<element name="ProcessingCapabilities">
<complexType>
<attribute name="parse" type="boolean" use="required"/>
<attribute name="generate" type="boolean" use="required"/>
</complexType>
</element>
<choice>
<element name="CompositeList" maxOccurs="unbounded">
<complexType>
<choice maxOccurs="unbounded">
<element name="Encapsulation">
<complexType>
<sequence>
<element ref="tns:Constituent"/>
</sequence>
<attributeGroup ref="tns:pkg.grp"/>
</complexType>
</element>
<element name="Composite">
<complexType>
<sequence>
<element ref="tns:Constituent" maxOccurs="unbounded"/>
</sequence>
<attributeGroup ref="tns:pkg.grp"/>
</complexType>
</element>
</choice>
</complexType>
</element>
<element ref="tns:Constituent"/>
</choice>
</sequence>
<attribute ref="tns:id" use="required"/>
</complexType>
</element>
Non-normative Appendices A and B of Collaboration-Protocol Profile and Agreement Specification , Version 2.0 contain sample CPP and CPA instance documents. These appendices were also made available in files at:
http://www.oasis-open.org/committees/ebxml-cppa/schema/cpp-example-companyA-2_0b.xml
http://www.oasis-open.org/committees/ebxml-cppa/schema/cpp-example-companyB-2_0b.xml
http://www.oasis-open.org/committee/ebxml-cppa/schema/cpa-example-2_0b.xml
Both the appendices and the files that extract the sample data contain several small errors. Files that provide corrections to these errors will be made available at the following locations as follows:
- an updated sample CPP A
http://www.oasis-open.org/committees/ebxml-cppa/schema/cpp-example-companyA-2_0c.xml
- an updated sample CPP B
http://www.oasis-open.org/committees/ebxml-cppa/schema/cpp-example-companyB-2_0c.xml
- an updated sample CPA
http://www.oasis-open.org/committees/ebxml-cppa/schema/cpa-example-2_0c.xml
In the difference files listed next, lines beginning with "-" indicate that the line is removed by the following line beginning with "+".
- a file showing the difference between updated CPP A and original CPP A
http://www.oasis-open.org/committees/ebxml-cppa/schema/cpp-example-companyA-2_0bc.diff
- a file showing the difference between updated CPP B and original CPP B
http://www.oasis-open.org/committees/ebxml-cppa/schema/cpp-example-companyB-2_0bc.diff
- a file showing the difference between updated CPA and original CPA
http://www.oasis-open.org/committees/ebxml-cppa/schema/cpa-example-2_0bc.diff
|
