[ebxml-iic] CTTF Messaging requirements

[Matthew MacKenzie <matt@xmlglobal.com>]

Group,

Attached are three HTML files generated from our Requirements XML 
instances, where messaging conformance requirements have been defined.  
The file "ebxml-iic-msg-reqs-l1.html" is required reading for the 
meeting later this week.

We made a choice to separate conformance into multiple levels, with the 
bulk of the requirements falling into level one, which focuses mostly on 
the structure and content of ebxml messages.  This has been a big job, 
so most of the focus is on level one at this time.

Levels two and three are also represented here, but very little work has 
been done to organize or verify wording.  I include them here in the 
hopes that any comments or suggestions made about this work also take 
into account the larger picture.

We need everyone in this TC's help in identifying errors or problems 
with these requirements.  If you do decide to help, please join our 
mailing list (ebxml-iic-msg) and send us any issues.  Make sure to 
reference the requirement id(s) in the subject of your message which you 
are commenting on.

Thanks.

Title: Requirements

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).

Title: Requirements

Requirement ID	Name	Function	Specification Ref	Condition	Assertion
r2.1	Reliable Messaging	reliable messaging	ebMS-2#6
r2.1.1	NAME		ebMS-2#6		OPTIONAL:Failure to receive an Acknowledgment message from a receiving MSH by the sending MSH results in successive retries until an Acknowledgment is received or a predetermined number of retries is exceeded.
r2.1.2	NAME		ebMS-2#6		REQUIRED:If the predetermined number of retries is exceeded the sending MSH notifies the From Party of the probable delivery failure.
r2.1.3	NAME		ebMS-2#6.1		REQUIRED:All messages sent or received reliably are kept in persistent storage.
r2.1.4	NAME		ebMS-2#6.1		REQUIRED:After a system failure the MSH ensures that all messages in persistent storage are processed as if the system failure or interruption had not occured.
r2.1.5	NAME		ebMS-2#6.1		REQUIRED:The MessageId of any received messaged is recorded in persistent storage.
r2.1.6	NAME		ebMS-2#6.1		RECOMMENDED:A received message is recorded in its entirety at least until the information in the message has been passed to the application needing to process it.
r2.1.7	NAME		ebMS-2#6.1		RECOMMENDED:The time at which a message is received is recorded in persistent storage.
r2.1.8	NAME		ebMS-2#6.1		RECOMMENDED:Each response message is stored in its entirety in persistent storage.
r2.1.9	NAME		ebMS-2#6.3.1		REQUIRED:An acknowledgment can be requested from a downstream MSH by inserting the AckRequested element in the SOAP Header of an outbound message.
r2.1.10	NAME		ebMS-2#6.3.1		REQUIRED:If there are two AckRequested elements in a generated message Header then they do not specify the same value for their respective SOAP actor attributes.
r2.1.11	NAME		ebMS-2#6.3.1		REQUIRED:At most one AckRequested element may be targeted at the actor URI for the Next MSH and at most one AckRequested element may be targeted at the actor URI for the To Party MSH in a given message.
r2.1.12	NAME		ebMS-2#6.3.1.1		REQUIRED:The AckRequested element can only be targeted at either the Next MSH or the To Party MSH.
r2.1.13	NAME		ebMS-2#6.3.1.2		REQUIRED:The From Party MSH may explicitly request that an acknowledgment message be either signed or unsigned by setting the signed attribute of the AckRequested element appropriately.
r2.1.14	NAME		ebMS-2#6.3.1.2		OPTIONAL:Before setting the value of the signed attribute on an outgoing message the Sending MSH checks if the Receiving MSH supports acknowledgment messages of the type requested.
r2.1.15	NAME		ebMS-2#6.3.1.2		REQUIRED:If an Acknowledgment Message of the type requested on an inbound message can be produced then a message containing an Acknowlegment element is returned the to the Sending MSH.
r2.1.16	NAME		ebMS-2#6.3.1.2		REQUIRED:If an Acknowledgment Message of the type requested cannot be produced then an error is reported to the Sending MSH. The error is Inconsistent/Error if the request in inconsistent with the relevant CPA, or Inconsistent/Warning if the mode is not supported.
r2.1.17	NAME		ebMS-2#6.3.1.3		REQUIRED:If an Acknowledgment Message is requested of the MSH node acting in the role of To Party then the Acknowledgment element generated is targeted to the MSH node acting in the role of From Party.
r2.1.18	NAME		ebMS-2#6.3.1.4		REQUIRED:A pure Acknowledgment Message (with no payload) does not include an AckRequested element.
r2.1.19	NAME		ebMS-2#6.3.1.4		REQUIRED:Any generated error message will not include an AckRequested element.
r2.1.20	NAME		ebMS-2#6.3.2.1		STRONGLY RECOMMENDED:The SOAP actor attribute in a generated Acknowledgment element is either not specified or has a value corresponding to the AckRequested element of the message being acknowledged.
r2.1.21	NAME		ebMS-2#6.3.2.2		REQUIRED:The Timestamp element is present within any generated Acknowledgment element. The value is in XML Schema dateTime format in the UTC timezone and represents the time at which the message being acknowledged was received by the MSH generating the Ackowledgement Message.
r2.1.22	NAME		ebMS-2#6.3.2.3		REQUIRED:The RefToMessageId element contains the MessageId of the message whose delivery is being acknowledged.
r2.1.23	NAME		ebMS-2#6.3.2.4		REQUIRED:If present, the From element in a generated Acknowledgment element identifies the party sending the Acknowledgment Message.
r2.1.24	NAME		ebMS-2#6.3.2.4		REQUIRED:If the From element is omitted from the Acknowledgment element on an inbound message then the value of the From element in the MessageHeader is used to identify the party sending the acknowledgment.
r2.1.25	NAME		ebMS-2#6.3.2.5		REQUIRED:If the message being acknowledged contains an AckRequested element with the signed attribute set to true then one or more Reference elements are included in the generated Acknowledgment element.
r2.1.26	NAME		ebMS-2#6.3.2.5		REQUIRED:Any Reference elements included in a generated Acknowledgment element are namespace qualified to the XML Signature namespace and conform to the XML Signature specification.
r2.1.27	NAME		ebMS-2#6.3.2.5		OPTIONAL:Upon receipt of an end-to-end acknowledgment message the From Party MSH notifies the client application of successful delivery of the referenced message.
r2.1.28	NAME		ebMS-2#6.2.2.5		OPTIONAL:Any subsequent inbound Error or Acknowledgment messages with a RefToMessageId value equal to an already received Acknowledgment Message are ignored.
r2.1.29	NAME		ebMS-2#6.3.2.7		REQUIRED:If no errors were detected in the message received and the Acknowledgment Message is being sent with no payload data then the Service and Action values are: Service - urn:oasis:names:tc:ebxml-msg:service Action - Acknowledgment
r2.1.30	NAME		ebMS-2#6.4.1		REQUIRED:The DuplicateElimination element can be included in an outbound message to indicate to a Receiving MSH that it must eliminate duplicates.
r2.1.31	NAME		ebMS-2#6.4.1		REQUIRED:If the value of duplicateElimination in the CPA is never the DuplicateElimination element will not be included in outbound messages.
r2.1.32	NAME		ebMS-2#6.4.1		REQUIRED:If DuplicateElimination element is present on an inbound message then that message is persisted in a persistent store and presented to the To Party Application at-most-once.
r2.1.33	NAME		ebMS-2#6.4.1		OPTIONAL:If duplicate elimination is not supported or if the value of duplicateElimination in the CPA does not match the implied value of the DuplicateElimination on an inbound message then an error is reported to the From Party (Inconsistent/Error).
r2.1.34	NAME		ebMS-2#6.4.3		OPTIONAL:If a message that requested acknowledgment is not acknowledged within the RetryInterval then the message is redelivered up to a maximum number of retries as specified by the Retries parameter in the relevent CPA.
r2.1.35	NAME		ebMS-2#6.4.4		OPTIONAL:The minimum time elapsed between re-sends of the same message is dictated by the RetryInterval parameter from the relevent CPA.
r2.1.36	NAME		ebMS-2#6.4.5		REQUIRED:TimeToLive > Timestamp + ((Retries + 1) * RetryInterval)
r2.1.37	NAME		ebMS-2#6.4.6		REQUIRED:A received reliably sent message is kept in persistent storage for at least the length of time specified by the PersistDuration parameter in the relevant CPA.
r2.1.38	NAME		ebMS-2#6.4.6		OPTIONAL:If the length of time specified by the PersistDuration parameter in the relevant CPA has passed since a message was first sent then a message with the same MessageId will not not sent again.
r2.1.39	NAME		ebMS-2#6.4.6		OPTIONAL:If a message cannot be successfully delivered before expiry of the PersistDuration period then a delivery failure is reported.
r2.1.40	NAME		ebMS-2#6.4.4		REQUIRED:The TimeToLive of a reliably sent message is always less than the sum of the message TimeStamp and the PersistDuration period (as defined in the relevant CPA).
r2.1.41	NAME		ebMS-2#6.4.7		REQUIRED:If the communications protocol is not synchronous then the value of the syncReplyMode in the relevant CPA is ignored.
r2.1.42	NAME		ebMS-2#6.4.7		REQUIRED:If the syncReplyMode in the relevant CPA is not none then a SyncReply element is required in an inbound message and the MSH returns any response from the application or business process in the payload of the synchronous reply message.
r2.1.43	NAME		ebMS-2#6.5.2		REQUIRED:When acting as an intermediary node the MSH does not filter out perceived duplicate messages.
r2.1.44	NAME		ebMS-2#6.5.3		REQUIRED:An Acknowledgment Message is generated whenever a message is received with an AckRequested element that has a SOAP actor URI targeting the MSH.
r2.1.45	NAME		ebMS-2#6.5.3		REQUIRED:Any Acknowledgment Message is placed in persistent storage with the same PersistDuration as the original message.
r2.1.46	NAME		ebMS-2#6.5.3		REQUIRED:An Acknowledgment Message can be delivered as part of the normal response to the received message.
r2.1.47	NAME		ebMS-2#6.5.4		REQUIRED:If there is a communications protocol error during a message send then the message is resent as if the MSH had not received an Acknowledgment Message.
r2.1.48	NAME		ebMS-2#6.5.5		OPTIONAL:If a duplicate message is received and the original acknowledgment is still present in the persistent store then this original Acknowledgment Message is resent.
r2.1.49	NAME		ebMS-2#6.5.5		OPTIONAL:If a duplicatge message is received and the original acknowledgment is not present in the persistent store, and the syncReplyMode is set to none, and the CPA indicates that an application response is included, then a response from the application is gathered by the MSH and returned synchronously.
r2.1.50	NAME		ebMS-2#6.5.5		OPTIONAL:If a duplicate message is received and the original acknowledgment is not present in the persistent store, and the syncReplyMode is not none, then a new Acknowledgment Message is generated and sent.
r2.1.51	NAME		ebMS-2#6.5.7		STRONGLY RECOMMENDED:If a message sent with AckRequested element cannot be delivered then an error message is sent to the From Party. If the delivery failure arose because the message could not be transmitted then the reported error is DeliveryFailure/Error. If the message was transmitted however no acknowledgment was received then the reported error is DeliveryFailure/Warning.
r2.1.52	NAME		ebMS-2#6.5.7		REQUIRED:If an Error Message with an error code set to DeliveryFailure cannot be delivered successfully then the ultimate destination of the error message is informed of the failure by some undefined means.
r2.2	Message Order	reliable messaging	ebMS-2#9
r2.2.1	NAME		ebMS-2#9		REQUIRED:MessageOrder functionality is only used in conjunction with the Reliable Messaging Module configured for Once-And-Only-Once delivery (thereby requiring at least DuplicateElimination and AckRequested directed to the To Party MSH).
r2.2.2	NAME		ebMS-2#9.1		REQUIRED:When the MessageOrder element is present the DuplicateElimination element is always present and the SyncReply element is never present.
r2.2.3	NAME		ebMS-2#9.1.1		REQUIRED:When receiving ordered messages the MSH processes messages only in the sequence indicated by the SequenceNumber element.
r2.2.4	NAME		ebMS-2#9.1.1		REQUIRED:A received ordered message is not passed to the destination application until all messages with a lower (earlier) SequenceNumber have previously been passed.
r2.2.5	NAME		ebMS-2#9.1.1		REQUIRED:If the maximum number of out-of-sequence ordered messages have been received then the Sending MSH is sent an error (DeliveryFailure/Error).
r2.2.6	NAME		ebMS-2#9.1.1		REQUIRED:The SequenceNumber element has value of 0 in each of the following cases: 1) It is the first ordered message from the Sending MSH within the conversation. 2) It is the first ordered message after a reset instruction is sent by the Sending MSH. 3. It is the first ordered message after the sequence wrapped at value 99999999.
r2.2.7	NAME		ebMS-2#9.1.1		REQUIRED:When the SequenceNumber element has been set to a value of 0 for either of the first two reasons noted in the previous requirement the status attribute of the message is set to Reset.
r2.2.8	NAME		ebMS-2#9.1.1		REQUIRED:In all case where the status attribute is not set to Reset it is set to Continue.
r2.2.9	NAME		ebMS-2#9.1.1		REQUIRED:When acting as the Sending MSH the SequenceNumber for a conversation is only reset when all previously sent messages have been accounted for.
r2.2.10	NAME		ebMS-2#9.2		REQUIRED:A MessageOrder element is never included in the same message as a SyncReply element.
r2.2.11	NAME		ebMS-2#9.2		OPTIONAL:If a message is received in which the MessageOrder element is included with a SyncReply element an error is reported (Inconsistent/Error).
r2.3	Multi-Hop Module	reliable messaging	ebMS-2#10
r2.3.1	NAME		ebMS-2#10.1		OPTIONAL:Multi-hop reliable messaging can be used between intermediary MSH nodes by applying the AckRequested and Acknowledgment elements with the SOAP actor attribute set to NextMSH (urn:oasis:names:tc:ebxml-msg:actor:nextMSH).
r2.3.2	NAME		ebMS-2#10.1.1		REQUIRED:When acting as an intermediary the node removes any AckRequested element with a SOAP actor attribute of NextMSH.
r2.3.3	NAME		ebMS-2#10.1.1		OPTIONAL:When acting as an intermediary the node can insert a single AckRequested element with a SOAP actor attribute of NextMSH.
r2.3.4	NAME		ebMS-2#10.1.1		REQUIRED:There are no situations in which two AckRequested elements are generated in the same message with a SOAP actor attribute value targetting the NextMSH.
r2.3.5	NAME		ebMS-2#10.1.1		REQUIRED:If a SyncReply element is present in a message then an AckRequested element with SOAP actor attribute targetting the NextMSH is never included.
r2.3.6	NAME		ebMS-2#10.1.1		REQUIRED:If the SyncReply and AckRequested elements are received in the same message then an error is reported (Inconsistent/Error).
r2.3.7	NAME		ebMS-2#10.1.1		OPTIONAL:When acting in the role of intermediary a node may synchronously return an intermediate Acknowledgment Message to the Sending MSH if no SyncReply element is specified.
r2.3.8	NAME		ebMS-2#10.1.3		REQUIRED:If an inbound message contains two AckRequested elements (one addressing NextMSH, one addressing ToPartyMSH), and the MSH node is in the combined role of Next and To Party MSH, then that node is able to differentiate the acknowledgment requests based upon the actor attribute and then send acknowledgments as applicable.
r2.3.9	NAME		ebMS-2#10.1.3		REQUIRED:A reliable message received by an MSH node in the role of intermediary is not acknowledged until the message is both persisted and delivered to the Next MSH.
r2.3.10	NAME		ebMS-2#10.1.4		REQUIRED:When a signed Acknowledgment Message is requested by an intermediate node it is only generated as a standalone message and is not bundled with any other data (payload).
r2.3.11	NAME		ebMS-2#10.2		REQUIRED:When acting in the role of intermediary the MSH does not attempt to participate in Message Order processing.

Title: Requirements

Requirement ID	Name	Function	Specification Ref	Condition	Assertion
r3.1	Message Status Service	packaging	ebMS-2#7
r3.1.1	NAME		ebMS-2#7		OPTIONAL:When a Message Status request message is received that references a previously received message that had been sent reliably and is present in persistent storage then a Message Status Response Message is sent.
r3.1.2	NAME		ebMS-2#7		OPTIONAL:When a Message Status Request Message is received that references a previously received message that had not been sent reliably a Message Status Response is sent.
r3.1.3	NAME		ebMS-2#7		OPTIONAL:The Message Status Request Service is not being used to implement reliable messaging.
r3.1.4	NAME		ebMS-2#7		OPTIONAL:If a Message Status Request Message is received for a service that is not supported then an Error Message is returned (NotSupported/Error).
r3.1.5	NAME		ebMS-2#7.1.1		REQUIRED:A generated Message Status Request Message consists of no payload and the MessageHeader/StatusRequest elements configured as specified in the Message Service Specification.
r3.1.6	NAME		ebMS-2#7.1.2		REQUIRED:A generated Message Status Response Message consists of no payload and MessageHeader/StatusResponse elements configured as specified in the Message Service Specification.
r3.1.7	NAME		ebMS-2#7.1.3		OPTIONAL:When a Message Status Request Message is received from an party deemed to be unauthorised then a response is sent with the messageStatus attribute set to UnAuthorized.
r3.1.8	NAME		ebMS-2#7.2.3		REQUIRED:A StatusRequest element is not included along with any of the Manifest. StatusResponse, or ErrorList elements.
r3.1.9	NAME		ebMS-2#7.3.1		REQUIRED:In a generated Status Response Message the RefToMessageId element child of the MessageData element specifies the MessageId of the message containing the associated StatusRequest element. Conversely, the RefToMessageId element child of the StatusRequest/StatusResponse elements always contains the MessageId of the message whose status is being queried.
r3.1.10	NAME		ebMS-2#7.3.2		REQUIRED:The Timestamp element child of a StatusResponse element contains the time at which the message being reported on was originally received. This element is omitted in the case where the original message was NotRecognised, or the status request is UnAuthorised.
r3.1.11	NAME		ebMS-2#7.3.3		REQUIRED:The messageStatus attribute is only set to one of the following values as dicated by the Message Service Specification: UnAuthorized, NotRecognized, Received, Processed, or Forwaded.
r3.1.12	NAME		ebMS-2#7.3.5		REQUIRED:A StatusResponse element does not get included along with any of the Manifest. StatusRequest, or ErrorList (with highest severity set to Error) elements.
r3.2	Ping Service	reliable messaging	ebMS-2#8
r3.2.2	NAME		ebMS-2#8		OPTIONAL:If a Message Service Handler Ping Message is received but not supported an Error Message is returned (NotSupported/Error)
r3.2.3	NAME		ebMS-2#8.1		REQUIRED:Any generated Message Service Handler Ping Message consists of no payload and the MessageHeader & Signature elements are configured as specified in the Message Service Specification.
r3.2.4	NAME		ebMS-2#8.2		OPTIONAL:When a Message Service Handler Ping Message is received a Message Service Handler Pong Message is returned.
r3.2.5	NAME		ebMS-2#8.2		REQUIRED:Any generated Message Service Handler Pong Message consists of no payload and the MessageHeader & Signature elements are configured as specified in the Message Service Specification.

--
Matthew MacKenzie
XML Global R&D
PGP Key available upon request.