New appendix format for extensiblity framework application to EDIINT col

The following is to replace the earlier material illustrating the extensibility framework, so it mainly corrects and updates earlier draft material.

The appendix for WSDL 1.1, 2.0 and WS-Policy based Policy is the last one currently planned for version 3.0. It may be ready early next week.

The following is then a “preview” of what the editor’s draft may look like for this material in version 3.0.

A. Using CPPA for EDIINT Configuration

The CPPA extensibility framework can be used in creating CPPs and CPAs for the EDIINT (AS1, AS2, and AS3) collaboration protocols [RFC3335],[RFC4130] [AS3] [Compression]

EDIINT protocols are peer-to-peer collaboration protocols using IETF transfer protocols (SMTP, HTTP, FTP), S/MIME security [S/MIME][CMS], and acknowledgments using Message Disposition Notifications [RFC3798].

EDIINT messaging defines its own (signed) acknowledgment message (MDN) and defines a compression option. Because these features are not found in ebXML 2.0 Messaging, it is necessary to add “modules” that document configuration details for these features.

Two new DocExchange binding elements are introduced for the senders and receivers of EDIINT messages, called EdiintReceiverBinding and EdiintSenderBinding. Each of these elements contain the new modules mentioned above as well as modules also used for other messaging protocols, such as in ebXML Messaging.

*EdiintSenderBinding/@version*	The value of this attribute identifies the version of the EDIINT specification being used. These values include: 1.0, 1.1, and 1.2 and are used in the ASx-Version header. It has a default value of 1.1, which is the ASx-Version value for compression support. The 1.2 value is used when the EDIINT-Features header is supported. Use of EDIINT-Features is intended to announce supported features instead of using values greater than 1.2
*PartyInfo/PartyId*	The AS2 and AS3 protocols have special headers (“AS2-To”, “AS2-From”, “AS3-To”, “AS3-From”) that identify the participants. The *PartyInfo/PartyId* values supply these values. In AS1, the *Endpoint/@uri* values will also contain the identifying email addresses of the parties within the mailto: URLs.
*SenderCompression/@mechanismType*	The mechanismType attribute has a default value of “zlib,” which is the value defined by the compression I-D. Any other value is implementation dependent. In a CPA, this value matches *ReceiverCompression/@mechanismType.*
*SenderCompression/@version*	Used to declare the version of compression support, relevant should future versions emerge. It has a default value of 1.1, which is the ASx-Version value indicating support for compression. In a CPA, this value matches *ReceiverCompression/@version.*
*SenderRequestedMDNStyle/HashFunction*	The value used in the transfer protocol header Disposition-notification-options: signed-receipt-protocol=optional,pkcs7-signature; signed-receipt-micalg=optional,sha1 In a CPA, the value matches the value in *ReceiverRequestedMDNStyle/HashFunction*. There can be comma separated list of acceptable hashes as in the parameter: signed-receipt-micalg=optional,sha1,md5.
*SenderRequestedMDNStyle/@receiptStyle*	The receiptType attribute with values “signed” or “unsigned” that indicate whether the MDN is to be signed. If the attribute is omitted, no receipt should be requested, and so no Disposition-notification-to header should be included in the transfer protocol headers. In CPAs, matches value in *ReceiverRequestedMDNStyle/@receiptStyle*
*SenderRequestedMDNStyle/@mdnRequested*	The attribute mdnRequested is used to indicate whether an MDN is always, never, or sent on a perMessage basis. The default is “perMessage” For the AS2 protocol, if the MDN is to be sent on a separate TCP connection, the “Disposition-Notification-To” header should be included, with values from the mdnDestination attribute below. In CPAs, matches value in *ReceiverRequestedMDNStyle/@mdnRequested*
*SenderRequestedMDNStyle/@mdnDestination*	The mdnDestination attribute’s value is a URL or email address that indicates where the MDN is to be sent, and the value for a header: Receipt-delivery-option: http://www.example.com When asynchronous MDNs are used, the value of the attribute “mdnDestination” is the proposed or agreed upon destination. In CPAs, matches value in *ReceiverRequestedMDNStyle/@mdnDestination*
*ServiceBinding/ActionBinding/-BusinessTransaction-Characteristics/@isConfidential*	Support for or agreement upon an encrypting digital envelope is declared by setting to a value of either “persistent” or “transient-and-persistent”. Either value indicates use of [S/MIME]. The use of SSL/TLS data protection would be indicated by “transient-and-persistent” instead of simply “persistent”.
*EdiintReceiverBinding/-ReceiverDigitalEnvelope/-EncryptionCertificateRef*	The encryption certificate that can be or will be used is found by matching this IDREF value to the element whose ID value it equals.
*EdiintSenderBinding/-SenderDigitalEnvelope/EncryptionSecurity-DetailsRef*	Trust anchors for checking the encryption certificate can be located using the *EncryptionSecurityDetailsRef* IDREF value as part of the *SecurityDetails* element having an ID value equal to the IDREF value.
*EdiintReceiverBinding/-ReceiverDigitalEnvelope/Encryption-Algorithm/@oid* or *EdiintReceiverBinding/-ReceiverDigitalEnvelope/Encryption-Algorithm/@w3c*.	The encryption symmetric encryption algorithm is declared using one or more of these attributes; the oid syntax is preferable. In a CPA, these Receiver values need to match values found at: *DocExchange/EdiintSenderBinding/-* *SenderDigitalEnvelope/EncryptionAlgorithm/@oid* or *DocExchange/EdiintSenderBinding/-* *SenderDigitalEnvelope/EncryptionAlgorithm /@w3c* Example: <EncryptionAlgorithm oid="1.2.840.113549.3.7">DES-EDE3-CBC</EncryptionAlgorithm>
*EdiintReceiverBinding/-ReceiverDigitalEnvelope/EncryptionAlgorithm/@minimumStrength*	The digital envelope’s encryption strength supported or agreed upon is indicated using *@minimumStrength* value.
*ServiceBinding/ActionBinding/Business-TransactionCharacteristics/-@isNonRepudiationRequired*	Digital signature capabilities or agreements for data origin authentication are declared using a “true” value for *@isNonRepudiationRequired*.
*ServiceBinding/ActionBinding/Business-TransactionCharacteristics/-@isNonRepudiationReceiptRequired*	A true value indicates support for or agreement to use a signed MDN and conducting checks on the returned hash value for the sent message.
*EdiintSenderBinding/-SenderNonRepudiation/SigningCertificateRef*	The SigningCertificate used in data origin authentication is found by finding the *Certificate* element whose ID equals the IDREF value in this element.
*EdiintReceiverBinding/-ReceiverNonRepudiation/Signing-SecurityDetailsRef*	The receiver indicates trust anchors used in validating trust in the sender’s signing certificate.
*EdiintSenderBinding/SenderNonRepudiation/-HashFunction*	Example would be: <HashFunction>SHA1</HashFunction>
*EdiintSenderBinding/SenderNonRepudiation/-SignatureAlgorithm*	Example would be: <SignatureAlgorithm oid="1.2.840.113549.1.1.5">RSA-SHA1</SignatureAlgorithm>
*EdiintSenderBinding/SenderNonRepudiation-/NonRepudiationProtocol*	Example might be: <NonRepudiationProtocol>EDIINT</NonRepudiationProtocol> or <NonRepudiationProtocol>AS2</NonRepudiationProtocol>
*MessagingCharacteristics/@syncReplyMode*	The MDN is viewed as a business acknowledgement or signal, and not as a MSH signal response. For this reason, when MDNs are returned synchronously in AS2, the value for *@syncReplyMode* should be either “responseOnly” or better “signalsAndResponse” When the MDN is returned in a separate connection, *@syncReplyMode* should be “none”.

*Packaging*	Packaging formats will conform with the specifications for MIME formats of the offered cryptographic services [RFC3335] and other relevant specifications [RFC3798, S/MIME]. Examples are presented in discussion at end of this table.
*SimplePart/NamespaceSupported*	Available for use with XML payloads..
*PersistDuration*	This element can be used when there is an agreement on checking for duplicates when using the Message-Id value. This feature is outside of the core EDIINT specifications but is often supported.
*Transport/TransportReceiver/Endpoint/@uri*	Example: <Endpoint uri="https://www.CompanyB.com/AS2" type="allPurpose"/> AS1: The URL uses the “mailto:“ scheme to exchange RFC 2822 adresses. AS2: The URL uses either “http:” or “https:” schemes. AS3: The URL uses “ftp:” or “ftps:” to indicate the scheme.
*Transport/TransportSender/Transport-Protocol/@method*	Example: <TransportProtocol version="1.1" method="POST">HTTP</TransportProtocol> POST method is what AS2 uses. For AS3, the method might be STOR or RETR.

The EDIINT collaboration messaging protocol is specified in three application statements, AS1, AS2 and AS3, that differ primarily in which IETF transfer protocol is used. AS1, AS2, and AS3 use SMTP, HTTP/HTTPS, and FTP/FTP-over-SSL respectively. Similar Packaging documentation is used for all transfer protocols. The details of packaging depend upon the specific security and mdn response modes of operation that are selected.

Some simple types referenced in Packaging could be:

A signed MDN Packaging element could be then documented as:

<Composite id="MdnComposite" mimeparameters="report-type=disposition-notification"

mimetype="multipart/report">

<Constituent excludedFromSignature="false" idref="MdnText" maxOccurs="1"

minOccurs="1"/>

<Constituent excludedFromSignature="false" idref="MdnMessage" maxOccurs="1"

minOccurs="1"/>

</Composite>

<Constituent excludedFromSignature="false" idref="MdnComposite" maxOccurs="1"

minOccurs="1"/>

</Encapsulation>

<Composite id="DefaultComposite4"

mimeparameters="protocol="application/pkcs7-signature""

mimetype="multipart/signed">

<Constituent excludedFromSignature="false" idref="DefaultEncapsulation3"

maxOccurs="1" minOccurs="1"/>

</Composite>

</CompositeList>

</Packaging>

Examples of packaging are included in the package of examples and sample referenced business process descriptions accompanying this specification.

SSL and PKI aspects for Transport Security are documented by means of components of the TransportServerSecurity or TransportClientSecurity, such as ServerCertificateRef, ClientCertificateRef, ClientSecurityDetailsRef, ServerSecurityDetailsRef.

Examples of this standard PKI documentation are included in the package of examples and sample referenced business process descriptions accompanying this specification.

ebxml-cppa message