Requirement ID

Name

Function

Specification Ref

Condition

Assertion

r1.1 Packaging Specification packaging ebMS-2#2
r1.1.1 SOAP 1.1 Conformance ebMS-2#2.1.1 REQUIRED:All generated ebXML messages conform to SOAP 1.1 and the SOAP Messages with Attachments specification.
r1.1.2 SwA MIME Headers ebMS-2#2.1.2 REQUIRED:All MIME headers generated for each Message Package are in conformance with the SOAP Messages with Attachments Specification.
r1.1.3 Message Package Content-Type ebMS-2#2.1.2 REQUIRED:The Content-Type MIME header in the Message Package contains a type attribute of "text/xml".
r1.1.4 Content-ID "start" attribute ebMS-2#2.1.2 RECOMMENDED:The Content-ID MIME header in any generated Message Package contains a start attribute identifying the first MIME part.
r1.1.5 Non-Multipart Messages ebMS-2#2.1.2 REQUIRED:Non-Multipart SOAP messages are supported in instances where there are no payload sections.
r1.1.6 SOAP Message Content Type ebMS-2#2.1.3.1 REQUIRED:The MIME Content-Type header for each generated SOAP Message has the value "text/xml".
r1.1.7 SOAP Message Character set ebMS-2#2.1.3.1 OPTIONAL:The MIME Content-Type header of each generated SOAP Message specifies the character set used to generate the message.
r1.1.8 Suggested Character set ebMS-2#2.1.3.2 RECOMMENDED:The UTF-8 character set is used by default when encoding each SOAP Message.
r1.1.9 No Application Payload ebMS-2#2.1.4 (If there are no application payloads) REQUIRED:There must not be any MIME parts
r1.1.10 Manifest ebMS-2#2.1.4 REQUIRED:The contents of each payload MIME part are identified in the Manifest element within any generated SOAP body
r1.1.11 Unrecognized MIME headers ebMS-2#2.1.5 REQUIRED:Unrecognized MIME headers in any incoming MIME part are ignored
r1.1.12 MIME error reporting ebMS-2#2.1.6 REQUIRED:If there are MIME errors in an incoming ebXML message, they should be reported as per the SOAP w/ Attachments specification.
r1.1.13 Version in XML Prolog ebMS-2#2.2.1 (XML Prolog exists in the SOAP message) REQUIRED:XML version is declared
r1.1.14 Encoding matches Prolog declaration ebMS-2#2.2.2 (XML Prolog exists in SOAP message AND Encoding is declared in the XML Prolog) REQUIRED:The encoding declaration matches the charset attribute of the Content-Type MIME header in the Header Container.
r1.1.15 Namespace qualification of ebXML extension elements ebMS-2#2.3 REQUIRED:All ebXML extension elements included within generated SOAP Envelope, Header and Body elements are namespace qualified to: "http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd"
r1.1.16 Envelope schema location ebMS-2#2.3.2 RECOMMENDED:Generated SOAP Envelope elements include the XMLSchema-instance namespace qualified schemaLocation attribute indicating the extended ebXML envelope schema: "http://www.oasis-open.org/committees/ebxml-msg/schema/envelope.xsd"
r1.1.17 SOAP Header and body namespace ebMS-2#2.3.2 RECOMMENDED:Generated SOAP Header and Body attributes both include a XMLSchema-instance namespace qualified schemaLocation attribute indicating the extended ebXML Msg Header schema "http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd"
r1.1.18 SOAP Header element namespace ebMS-2#2.3.3 REQUIRED:A generated SOAP Header element is namespace qualified as per the SOAP namespace declaration in the SOAP Envelope element.
r1.1.19 SOAP Body element namespace ebMS-2#2.3.4 REQUIRED:A generated SOAP Body element is namespace qualified as per the SOAP namespace declaration in the SOAP Envelope element.
r1.1.20 SOAP header contains a MessageHeader element ebMS-2#2.3.5.1 REQUIRED:A generated SOAP Header element always contains one ebXML MessageHeader element.
r1.1.21 Namespace of foreign elements ebMS-2#2.3.6 REQUIRED:Any foreign namespace qualified elements present within generated ebXML extension elements are namespace qualified with a namespace that is not "http://www.oasis-open.org/committees/ebxml-msg/schema/msg-header-2_0.xsd".
r1.1.22 XML ID attribute ebMS-2#2.3.7 OPTIONAL:An XML ID attribute is supplied for each generated ebXML element (to assist with such tasks as specifying elements included in a digital signature).
r1.1.23 MessageHeader@version value ebXML-2#2.3.8 REQUIRED:A generated ebXML MessageHeader element always contains a version attribute with a value of "2.0". If a message is received with a version that is not recognised by the MSH then the MSH responds with an error.
r1.1.24 SOAP mustUnderstand attribute & ebXML extensions ebMS-2#2.3.9 REQUIRED:All ebXML extensions of the SOAP Header element (MessageHeader, SyncReply, MessageOrder, ...) contain the mustUnderstand attribute namespace qualified to the SOAP namespace (http://schemas.xmlsoap.org/soap/envelope).
r1.1.24-a1 Message Rejection ebMS-2#2.3.9 REQUIRED:Any SOAP Header extension with a mustUnderstand attribute set to "1" that is not understood by the MSH will result in the message being rejected.
r1.2 Core Extension Elements packaging ebMS-2#3
r1.2.1 From & To element presence ebMS-2#3.1.1 REQUIRED:From and To elements are always present as the children of a generated MessageHeader element and identify the parties that originated/are-intended-to-receive the message respectively.
r1.2.2 To & From element content ebMS-2#3.1.1 REQUIRED:Generated From and To elements each contain one or more PartyId elements and zero or one Role element.
r1.2.3 Handling of multiple PartyId elements in To or From ebMS-2#3.1.1 REQUIRED:When generated From or To elements contain multiple PartyId elements the PartyId values are treated as identifying the same organisation.
r1.2.4 Role element location ebMS-2#3.1.1 (If there is a Role element in a To or From element) REQUIRED:Role element must follow the last PartyId element.
r1.2.5 Error in PartyId content ebMS-2#3.1.1.1 (PartyId does not contain a type attribute AND PartyId text node is not a URI) STRONGLY RECOMMENDED:MSH responds with an error (Inconsistent/Error)
r1.2.6 CPA resolution error ebMS-2#3.1.2 REQUIRED:If value of the CPAId element on an inbound message cannot be resolves then the MSH responds with an error (NotRecognized/Error).
r1.2.7 CPA / Message disagreement ebMS-2#3.2.1 REQUIRED:If the receiving MSH detects an inconsistency between an incoming message and the relevant CPA then it responds with an error (Inconsistent/Error)
r1.2.8 ConversationId content uniqueness ebMS-2#3.1.3 REQUIRED:Generated ConversationId element values are strings that are unique within the context of a the specified CPAId.
r1.2.9 ConversationId value presence and consistency ebMS-2#3.1.3 REQUIRED:The generated ConversationId will be present in all messages pertaining to the given conversation.
r1.2.10 Service element content ebMS-2#3.1.4.1 (If the "type" attribute is not set. AND If the content is not a URI.) REQUIRED:MSH Responds with an error (Inconsistent/Error)
r1.2.11 Unrecognized Service and/or Action ebMS-2#3.1.5 REQUIRED:If the receiving MSH does not recognize both the Service and Action values of an incoming message then it responds with an error (NotRecognised/Error).
r1.2.12 MessageId presence and format ebMS-2#3.1.6.1 REQUIRED:The MessageId element within the MessageData element is always present and its value is generated as a globally unique identifier.
r1.2.13 Timestamp presence and format ebMS-2#3.1.6.2 REQUIRED:The Timestamp element within the MessageData element is always present and indicates the time at which the message header was generated. The element value is expressed according to the dateTime XMLSchema datatype in the UTC timezone.
r1.2.14 RefToMessageId content ebMS-2#3.1.6.3 REQUIRED:The RefToMessageId element within the MessageData element, if present, contains the MessageId value of an earlier ebXML Message to which this message relates.
r1.2.15 RefToMessageId existence ebMS-2#3.1.6.3 REQUIRED:If there is no earlier related message then the RefToMessageId element is never present.
r1.2.16 RefToMessageId existence in error messages ebMS-2#3.1.6.3 REQUIRED:For a generated error message the RefToMessageId element is always present with a value indicating the message in error.
r1.2.17 TimeToLive Existence and Format ebMS-2#3.1.6.4 REQUIRED:If a TimeToLive element is present within the MessageData element then it represents the time by which the message should be delivered to the To Party MSH. The element value is expressed according to the XML Schema dateTime datatype in the UTC timezone.
r1.2.18 TTL validation by To Party ebMS-2#3.1.6.4 REQUIRED:If the MSH receives a message for which it is the To Party MSH and the TimeToLive is greater than the time of the internal clock (adjusted for UTC) then an error message is returned to the To Party MSH (TimeToLiveExpired/Error).
r1.2.19 Duplicate Elimination ebMS-2#3.1.7 REQUIRED:If the DuplicateElimination element is present within the MessageHeader of an inbound message then the MSH elimates duplicate messages.
r1.2.20 Duplicate elimination not allowed when CPA#duplicateElimination=never ebMS-2#3.1.7 REQUIRED:If the relevant CPA specifies a duplicateElimination value of never then the DuplicateElimination element must not be present.
r1.2.21 xml:lang is set in Description element ebMS-2#3.1.8 REQUIRED:When a Description element is generated the language of the free form description is specified via the xml:lang attribute.
r1.2.22 Payload/Application data in SOAP:Body or ebXML:Manifest ebMS-2#3.2 RECOMMENDED:No payload/application data is present in generated SOAP Body / ebXML Manifest elements.
r1.2.23 MIME parts required when Manifest/Reference refers to a content id. ebMS-2#3.2.2 REQUIRED:If the xlink:href element of a generated Manifest/Reference element specifies a URI via content id ("cid:") then a MIME part with a matching content-id exists in the payload container of the message. If there is no matching payload then an error message is directed to the From Party MSH (MimeProblem/Error).
r1.2.24 Error reporting of bad href in Manifest/Reference ebMS-2#3.2.2 OPTIONAL:If the xlink:href element of a Manifest/Reference element on an inbound message specifies a URI that is not a content id (not "cid:"), and that cannot be resolved, then the MSH reports an error to the From Party MSH (MimeProblem/Error)
r1.2.25 Unreferenced payloads should be discarded ebMS-2#3.2.2 STRONGLY RECOMMENDED:If a MIME payload part exists on an incoming message that is not referenced by a Manifest/Reference element then it is discarded.
r1.3 Security & Communication Channels security ebMS-2#4
r1.3.1 Signature elements ebMS-2#4.1 REQUIRED:Zero or more Signature elements belonging to the XML Signature namespace may be included to digitally sign an outbound message.
r1.3.2 Attribution of multiple Signature elements ebMS-2#4.1 REQUIRED:If there is more than one Signature element within the SOAP Header then it is the first signature that represents digital signing of the message by the From Party MSH.
r1.3.3 Security utility services ebMS-2#4.1.2.1 OPTIONAL:The MSH offers security utility services with regard to message payload items according to the Document Exchange section of the relevant CPA.
r1.3.4 Security measure application based on CPA contents. ebMS-2#4.1.2.1 REQUIRED:The MSH applies security measures to an ebXML message (as a whole) based upon the Transport section of the relevent CPA.
r1.3.5 XML DSIG conformance of Signature elements. ebMS-2#4.1.3 REQUIRED:Digital signatures are generated and rendered according the XML Signature specification (XMLDSIG). The SignedInfo element has a CanonicalizationMethod, SignatureMethod and one or more Reference elements.
r1.3.6 Signature canonicalization method. ebMS-2#4.1.3 RECOMMENDED:The canonicalization method applied to the data to be signed is Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"
r1.3.7 SignatureMethod and Algorithm attribute. ebMS-2#4.1.3 REQUIRED:The SignatureMethod element is present and has an Algorithm attribute on any generated digitally signed message.
r1.3.8 SignatureMethod@Algorithm attribute value. ebMS-2#4.1.3 RECOMMENDED:The value of the Algorithm attribute is Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1"
r1.3.9 Support for DSA-SHA1 algorithm. ebMS-2#4.1.3 REQUIRED:The MSH supports the signature algorithm DSA-SHA1.
r1.3.10 A Signature/Reference element for the SOAP message. ebMS-2#4.1.3 STRONGLY RECOMMENDED:The generated XML Signature Reference element has a URI attribute value of "" (indicating that the signature is to be applied to the document that contains the Signature element).
r1.3.11 Optional Reference@Type attribute. ebMS-2#4.1.3 STRONGLY RECOMMENDED:The MSH supports the optional addition of the informative Type attribute with value "http://www.w3.org/2000/09/xmldsig#Object" on the XML Signature Reference element.
r1.3.12 Mandatory Transform element in References to an indicate enveloped signature. ebMS-2#4.1.3 STRONGLY RECOMMENDED:Any generated XML Signature Reference element includes a child Transforms element which in turn includes a first Transform element with an Algorithm attribute of value "http://www.w3.org/2000/09/xmldsig#enveloped-signature".
r1.3.13 Mandatory Transform element to exclude SOAP:Actor and other dynamic information used in routing. ebMS-2#4.1.3 REQUIRED:A second Transform element is generated with the requisite XPath element exluding all elements with SOAP actor attributes targetting the nextMSH or next SOAP node.
r1.3.14 Proper handling of messages by intermediaries. ebMS-2#4.1.3 REQUIRED:The MSH when acting in an intermediary role does not change, format or in any way modify any element not tagetted at that intermediary MSH. The MSH does not add or delete white space.
r1.3.15 Canonicalization Transform element. ebMS-2#4.1.3 OPTIONAL:The last generated Transfom element has an Algorithm attribute with a value of "http://www.w3.org/TR/2001/REC-xml-c14n-20010315".
r1.3.16 Reference elements for signed payloads. ebMS-2#4.1.3 REQUIRED:Any payload data requiring digital signature is identified by an XML Signature Reference element that has a URI attribute resolving to the location of that data.
r1.3.17 URI attribute of a Reference element should match equivalent Manifest entries. ebMS-2#4.1.3 RECOMMENDED:The value of the URI attribute of a generated XML Signature Reference element matches the xlink:href URI value present in the Manifest/Reference element corresponding to that same payload.
r1.3.18 Signature generation before transfer encoding. ebMS-2#4.1.3 REQUIRED:Signature generation takes place before any transfer encoding (eg base64) is applied to the SOAP Envelope or payload MIME parts.
r1.3.19 Digitally signed acknowledgements. ebMS-2#4.1.3.2 REQUIRED:A digitally signed inbound message may be acknowledged with a digitally signed acknowledgement. Any such acknowledgement message contains an XML Signature Reference element list corresponding to the Reference elements contained in the original message.
r1.3.20 Party authentication is possible over communication channel. ebMS-2#4.1.4.3 OPTIONAL:The communication channel used to transport the ebXML message can be used to provide uni or bi-directional party authentication (eg TLS over TCP/IP).
r1.3.21 Data integrity provided by communication channel. ebMS-2#4.1.4.4 OPTIONAL:The communication channel used to transport the ebXML message can be used to provide data integrity of the message content (eg TLS over TCP/IP).
r1.3.22 Signing must take place prior to any encryption. ebMS-2#4.1.4.5 REQUIRED:If signature and encryption of a message component is requested of the MSH, signing takes place prior to encryption.
r1.3.23 Data confidentiality provided by communication channel. ebMS-2#4.1.4.6 REQUIRED:The communication channel used to transport the ebXML message can be used to provide data confidentiality for the message content (eg TLS over TCP/IP).
r1.3.24 Bilateral authentication by communication channel. ebMS-2#4.1.4.8 OPTIONAL:The source of an ebXML message can be authorised by using a secure network protocol for bilateral authentication of certificates prior to establishing a session (eg TLS over TCP/IP).
r1.4 Error Handling other ebMS-2#4.2
r1.4.1 SOAP Faults from downstream processor. ebMS-2#4.2 REQUIRED:When sending messages the MSH can accept and process SOAP Fault values from a downstream SOAP processor.
r1.4.2 SOAP Faults comply with SOAP specification. ebMS-2#4.2 REQUIRED:If an MSH returns a SOAP Fault message to the sender of a SOAP message then this returned message conforms to the SOAP specification guidelines for SOAP Fault values.
r1.4.3 Errors with highestSeverity of Warning shouldn't use SOAP Fault. ebMS-2#4.2 STRONGLY RECOMMENDED:When an ebXML message is reporting an error with a highestSeverity value of 'Warning' it is not reported or returned as a SOAP Fault.
r1.4.4 Data communication errors use native reporting methods. ebMS-2#4.2.2 STRONGLY RECOMMENDED:Errors associated with data communications protocols are detected and reported using the standard mechanisms supported by that protocol and do not use ebXML reporting mechanisms.
r1.4.5 ErrorList presence. ebMS-2#4.2.3 REQUIRED:The ErrorList extension element of the SOAP Header element is never present if there are no errors to be reported.
r1.4.6 ErrorList@highestSeverity contains the highest severity value of all enclosed Error elements. ebMS-2#4.2.3.1 REQUIRED:The highestSeverity attribute contains the highest severity of any Error elements generated in an outbound message.
r1.4.7 Error@codeContext is always a URI. ebMS-2#4.2.3.2.2 REQUIRED:The codeContext attribute of any generated Error element is always a URI.
r1.4.8 Namespace/scheme for codeContext values. ebMS-2#4.2.3.2.2 RECOMMENDED:The namespace/scheme specified by codeContext for identifying errorCodes is the default value of urn:oasis:names:tc:ebxml-msg:service:errors.
r1.4.9 Error@errorCode presence. ebMS-2#4.2.3.2.3 REQUIRED:For each Error element the errorCode attribute is present and indicates the nature of the error.
r1.4.10 Error@severity content. ebMS-2#4.2.3.2.4 REQUIRED:For each Error element generated the severity attribute has the value of Warning or Error indicating the severity of the error.
r1.4.11 XPointer use for pinpointing message errors. ebMS-2#4.2.3.2.5 REQUIRED:If an error exists in an ebXML element and the containing document is well-formed then the location attribute of the Error element is an XPointer to the erroneous element.
r1.4.12 Referencing an error with a MIME part. ebMS-2#4.2.3.2.5 REQUIRED:If an error exists in a payload MIME part then the location attribute of the generated Error element contains the content-id (via "cid:") of the erroroneous MIME part.
r1.4.13 Short Description text for an error code presence. ebMS-2#4.2.3.4 REQUIRED:The "Short Description" text for each error code provided by the Message Service Specification does not appear in any relevant Error element.
r1.4.14 Error reporting to message origin. ebMS-2#4.2.4.1 RECOMMENDED:When an MSH detects an error in a message the error is reported to the MSH that sent the original message in error.
r1.4.15 No error reporting location, or ErrorList@highestSeverity == "Error" action. ebMS-2#4.2.4.1 RECOMMENDED:If the error reporting location cannot be found or the message in error has an ErrorList element with highestSeverity set to Error the error is: Logged; Resolved by other means; and, No further action is taken.
r1.4.16 CPP/A#ErrorURI use. ebMS-2#4.2.4.2 OPTIONAL:If the ErrorURI is implied in the relevant CPA then this is used as the Error Reporting Location.
r1.4.17 If CPP/A#ErrorURI is undefined. ebMS-2#4.2.4.2 OPTIONAL:If the ErrorURI is unavailable in the relevant CPA then a URI specified in the From Party of the message is used as the Error Reporting Location.
r1.4.18 ErrorList sent as a result of message processing. ebMS-2#4.2.4.3 REQUIRED:If an ErrorList is included as part of a message being sent as a result of processing an earlier message and the Service and Action values are set as specified by the service enacted, then highestSeverity will not be Error.
r1.4.19 Independent ErrorList messages, service and action definition. ebMS-2#4.2.4.3 REQUIRED:If an ErrorList is included as part of an independent message then the values of Service and Action are; Service: urn:oasis:names:tc:ebxml-msg:service Action: MessageError
r1.5 SynchReply other ebMS-24.3
r1.5.1 General effect of SyncReply presence. ebMS-2#4.3.1 OPTIONAL:If a SyncReply element is present in a message received over a synchronous communications protocol then that connection is kept open in expectation of the response message using the same connection.
r1.5.2 CPA holds higher precedence than SyncReply element. ebMS-2#4.3.1 REQUIRED:The SyncReply element may not be used to override the syncReplyMode in the CPA.
r1.5.3 SyncReply element conflict with CPA triggers an error. ebMS-2#4.3.1 OPTIONAL:If the CPA syncReplyMode is set to none and a SyncReply element is present in an inbound message then the MSH issues an error (Inconsistent/Error).