[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: [ebxml-iic-conform] Test Requirement Coverage document, first iteration
Jacques and all,
Here is the first version of the Test Requirements Coverage
document. It is annotated using the current
test requirement ID's, and the current "coverage" labels.
Two key points before we submit it to the Messaging TC...
1) We will need to lay down some solid criteria for
defining coverage as "full", "partial" and "none". The major issue ( in my
opinion ) will have to do with how much our
test harness will be able to peer into and manipulate the internals of a
candidate MSH. I think that we need
a list of quantified criteria in order to make these coverage labels more
meaningful.
2) This scheme seems to work well to identify exactly what has ( and has
not ) been covered in the spec. I see
more potential parts of the spec to cover, based upon the annotation. Due
to limited time, it may be best to submit
as is and get feedback from the TC, rather than iterate more on the
requirements. Comments?
Also attached are the updated requirements ( fixed typos, naming, a few
duplicates ). These have been checked into CVS.
Again, "coverage" column will be removed when we've "finalized" the
requirements and pass them on to Matt for merging and
resequencing the numbers. Right now, it is helpful to see the coverage
since we need to finalize that criteria.
My idea for criteria for coverage is pretty simple:
1) "Full" = our test case leaves no doubt that this item in the spec has
been tested fully ( this is where the vast majority of our test
requirements fall )
2) "Partial" = Due to limitations ( either in the test service, the test
party software or rigor in writing a test case for all potential
possibilities ), this requirement could not be completely tested
3) "None" = Due to limitations in the test service, the test party software
we could not test this requirement at all
The main problem that I see is defining just what the capabilities of
the test service and the test party software will be. For example, will we
be performing "interrupts" of
MSH service to test reliable messaging, will we be able to check digital
signatures, will we be able to check message persistence on the candidate
side? These questions,
and more need to be answered before a reliable estimation of coverage can
be made, in my opinion.
Comments?
Mike
Attachment:
ebMS_v2_0.doc
Description: MS-Word document
| ID | Name | Test Coverage | Specification Ref | Precondition | Requirement Level | Assertion |
|---|---|---|---|---|---|---|
| r0.1 | Global Requirements for All Tests | ebMS-2#1.3 | ||||
| r0.1.1 | SchemaValidation | full | ebMS-2#1.3 | ( For each generated message ) | REQUIRED | Supports all mandatory syntax defined in Core plus Additional Features |
| r1.1 | PackagingSpecification | ebMS-2#2 | ||||
| r1.1.2.1 | GenerateConformantSOAPWithAttachMIMEHeaders | partial | ebMS-2#2.1.2 | ( For each generated mesage, if it is multipart MIME or not text/xml ) | REQUIRED | The primary SOAP message is carried in the root body part of the message. |
| r1.1.2.2 | GenerateConformantSOAPWithAttachMIMEHeaders | partial | ebMS-2#2.1.2 | ( For each generated mesage, if it is multipart MIME or not text/xml ) | REQUIRED | The type parameter of the Multipart/Related media header is "text/xml", the MIME parts must contain a CID MIME header or a Content-Location MIME header structured in accordanced with RFC 2557 |
| r1.1.3 | GenerateCorrectMessagePackageContent-Type | full | ebMS-2#2.1.2 | ( For each generated message ) | REQUIRED | The Content-Type MIME header in the Message Package contains a type attribute of "text/xml". |
| r1.1.4 | GenerateContent-IDStartValues | full | ebMS-2#2.1.2 | ( For each generated message ) | RECOMMENDED | The Content-ID MIME header in any generated Message Package contains a start attribute identifying the first MIME part. |
| r1.1.5.1 | ProcessNon-MultipartMessages | full | ebMS-2#2.1.2 | ( the message is not multipart MIME AND the message has no payload ) | REQUIRED | The MSH accepts the message. |
| r1.1.5.2 | GenerateNon-MultipartMessages | full | ebMS-2#2.1.2 | ( For each generated message, if the message is not multipart MIME ) | REQUIRED | It must not have a payload. |
| r1.1.6 | GenerateCorrectSOAPMessageContentType | full | ebMS-2#2.1.3.1 | ( For each generated message ) | REQUIRED | The MIME Content-Type header for each generated SOAP Message has the value "text/xml". |
| r1.1.7 | GenerateSpecificSOAPMessageCharacterSet | partial | ebMS-2#2.1.3.1 | ( For each generated message ) | REQUIRED | The MIME Content-Type header of each generated SOAP Message specifies the character set used to generate the message. |
| r1.1.8 | GenerateDefaultSOAPMessageCharacterSet | none | ebMS-2#2.1.3.2 | ( For each generated message ) | RECOMMENDED | The UTF-8 character set is used by default when encoding each SOAP Message. |
| r1.1.9 | ProvideEmptyManifestAndPayloadIntegrity | full | ebMS-2#2.1.4 | ( For each generated message, if there are no application payloads identified in the message header manifest” ) | REQUIRED | There must not be any payload MIME parts |
| r1.1.10 | ProvideManifestAndPayloadIntegrity | full | ebMS-2#2.1.4 | ( For each generated message ) | REQUIRED | The contents of each payload MIME part are identified in the Manifest element within any generated SOAP body |
| r1.1.11 | ProcessUnrecognizedMIMEHeaders | partial | ebMS-2#2.1.5 | ( For each received message containing unrecognized MIME headers ) | REQUIRED | Unrecognized MIME headers in a MIME part are ignored and no Error message is returned. |
| r1.1.13 | GenerateXMLVersionInProlog | full | ebMS-2#2.2.1 | ( For each generated message, if the XML Prolog exists in the SOAP message ) | REQUIRED | XML version is declared |
| r1.1.14 | ProvideXMLPrologEncodingAndMIMEContent-TypeIntegrity | full | ebMS-2#2.2.2 | ( For each generated message, if the XML Prolog exists in SOAP message AND Encoding is declared in the XML Prolog AND charset attribute is present in SOAP header container ) | REQUIRED | The encoding declaration matches the charset attribute of the Content-Type MIME header in the Header Container. |
| r1.1.15 | GenerateCorrectExtensionElementNamespace | full | ebMS-2#2.3 | ( For each generated message ) | 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 | GenerateCorrectEnvelopeSchemaLocation | full | ebMS-2#2.3.2 | ( For each generated message ) | RECOMMENDED | 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 | GenerateCorrectSOAPHeaderAndBodySchemaLocation | full | ebMS-2#2.3.2 | ( For each generated message ) | RECOMMENDED | 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.19 | GenerateCorrectSOAPBodyNamespace | full | ebMS-2#2.3.4 | ( For each generated message ) | REQUIRED | A SOAP Body element is namespace qualified as per the SOAP namespace declaration in the SOAP Envelope element. |
| r1.1.20 | GenerateMessageHeaderInSOAPHeader | full | ebMS-2#2.3.5.1 | ( For each generated message ) | REQUIRED | A SOAP Header element always contains an ebXML MessageHeader element. |
| r1.1.21 | GenerateCorrectForeignElementNamespaces | full | ebMS-2#2.3.6 | ( For each generated message ) | 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 | GenerateIdAttributeToExtensionElements | full | ebMS-2#2.3.7 | ( For each generated message ) | 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 | GenerateCorrectMessageHeaderVersion | full | ebXML-2#2.3.8 | ( For each generated message ) | RECOMMENDED | An ebXML MessageHeader element always contains a version attribute with a value of "2.0" |
| r1.1.24 | GenerateCorrectSOAPMustUnderstandNamespace | full | ebMS-2#2.3.9 | ( For each generated message ) | 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.25 | ProcessMustUnderstand | partial | ebMS-2#2.3.9 | ( For each received message containing a SOAP Header extension with a mustUnderstand attribute set to "1" and not understood by the MSH. ) | REQUIRED | The message is rejected in accordance with SOAP. |
| r1.2 | CoreExtensionElements | ebMS-2#3.1.1 | ||||
| r1.2.3 | GenerateUniquePartyId | full | ebMS-2#3.1.1 | ( For each generated message, unless a single type value refers to multiple identification systems ) | REQUIRED | The value of any given type attribute must be unique within the list of PartyId elements contained within either the From or To element. |
| r1.2.5 | ReportInconsistentPartyIdContent | full | ebMS-2#3.1.1.1 | ( For each received message, 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.5.1 | GenerateValidPartyIdContent | full | ebMS-2#3.1.1.1 | ( For each generated message, if generated PartyId contains a type attribute ) | RECOMMENDED | Its value is a URI |
| r1.2.5.2 | GenerateValidPartyIdContent | full | ebMS-2#3.1.1.1 | ( For each generated message, if generated PartyId does not contain a type attribute ) | REQUIRED | Text content of the PartyId element must be a URI |
| r1.2.6 | ReportFailedCPAIDResolution | full | ebMS-2#3.1.2 | ( For each received message, if value of the CPAId element on an inbound message cannot be resolved ) | REQUIRED | The MSH responds with an error (ValueNotRecognized/Error). |
| r1.2.9.1 | ProvideConversationIdIntegrity | partial | ebMS-2#3.1.3 | ( For each generated message within the context of the specified CPAId ) | REQUIRED | The generated ConversationId will be present in all messages pertaining to the given conversation. |
| r1.2.9.2 | ReportConversationIdIntegrity | partial | ebMS-2#3.1.3 | ( For each received message, if a message is received that is outside of the context of the specified CPAId ) | RECOMMENDED | An Error message is generated. |
| r1.2.10 | ReportInconsistentServiceElementContent | full | ebMS-2#3.1.4.1 | ( For each received message, if the received "type" attribute is not set. AND If the Service element content is not a URI. ) | REQUIRED | MSH Responds with an error (Inconsistent/Error) |
| r1.2.10.1 | GenerateConsistentServiceElementContent | full | ebMS-2#3.1.4.1 | ( For each generated message, if the generated Service element "type" attribute is not set. ) | REQUIRED | Generated Service element content must be a URI |
| r1.2.11 | ReportUnrecognizedServiceAndOrAction | partial | ebMS-2#3.1.5 | ( For each received message, if the receiving MSH does not recognize both the Service and Action values of an incoming message ) | REQUIRED | It responds with an error (ValueNotRecognised/Error). |
| r1.2.14 | ProvideRefToMessageIdIntegrity | none | ebMS-2#3.1.6.3 | ( For each generated message, if the RefToMessageId element within the MessageData element is present ) | REQUIRED | It contains the MessageId value of an earlier ebXML Message to which this message relates. |
| r1.2.15 | GenerateRefToMessageId | full | ebMS-2#3.1.6.3 | ( For each generated message, if there is no earlier related message ) | REQUIRED | The RefToMessageId element is never present. |
| r1.2.16 | GenerateErrorRefToMessageId | full | ebMS-2#3.1.6.3 | ( For each generated message, if a previous message generated and error ) | REQUIRED | The RefToMessageId element is always present with a value indicating the message in error. |
| r1.2.18 | ProcessTimeToLive | full | ebMS-2#3.1.6.4 | ( For each received message, if the MSH receives a message for which it is the To Party MSH and the time of the internal clock is greater than TimeToLive ( adjusted to UTC ) ) | REQUIRED | An error message is returned to the From Party MSH (TimeToLiveExpired/Error). |
| r1.2.18.1 | GenerateValidUTCTime | full | ebMS-2#3.1.6.4 | ( For each generated message, if a TimeToLive element is present in a generated message. ) | REQUIRED | The TimeToLive element expresses time in UTC, and conform to the XML Schema dateTime. |
| r1.2.21 | GenerateDistinctLangValuesForDescription | full | ebMS-2#3.1.8 | ( For each generated message ) | RECOMMENDED | No two Description elements must have the same xml:lang attribute value |
| r1.2.22 | GenerateNoPayloadOrApplicationDataInBodyOrManifest | full | ebMS-2#3.2 | ( For each generated message ) | RECOMMENDED | No payload/application data is present in generated SOAP Body / ebXML Manifest elements. |
| r1.2.23 | ReportNon-ExistentMIMEPartForManifestReference | full | ebMS-2#3.2.2 | ( For each received message, ff there is not a matching payload for the xlink:href element of a generated Manidfest/Reference element ) | REQUIRED | An error message is directed to the From Party MSH (MimeProblem/Error). |
| r1.2.24 | ReportUnresolvableHREFInManifest | full | ebMS-2#3.2.2 | ( For each received message, 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 ) | OPTIONAL | The MSH reports an error to the From Party MSH (MimeProblem/Error) |
| r1.2.24.1 | GenerateResolvableHREFInManifest | full | ebMS-2#3.2.2 | ( For each generated message ) | OPTIONAL | The xlink:href element of a Manifest/Reference element on an inbound message specifies a URI that is a content id ("cid:"), and can be resolved |
| r1.2.25 | ProcessUnreferencedPayloads | none | ebMS-2#3.2.2 | ( For each received message, if a MIME payload part exists on an incoming message that is not referenced by a Manifest/Reference element ) | STRONGLY RECOMMENDED | It is discarded. |
| r1.4 | ErrorHandling | ebMS-2#4.2 | ||||
| r1.4.1 | ProcessUpstreamSOAPFault | none | ebMS-2#4.2 | ( For each received message ) | REQUIRED | The MSH can accept and process SOAP Fault values from a downstream SOAP processor. |
| r1.4.2 | GenerateCompliantSOAPFaults | full | ebMS-2#4.2 | ( For each generated message, if an MSH returns a SOAP Fault message to the sender of a SOAP message ) | REQUIRED | The returned message conforms to the SOAP specification guidelines for SOAP Fault values. |
| r1.4.3 | GenerateWarnings | full | ebMS-2#4.2 | ( For each generated message, when an ebXML message is reporting an error with a highestSeverity value of 'Warning' ) | STRONGLY RECOMMENDED | It is not reported or returned as a SOAP Fault. |
| r1.4.4 | ReportDataCommunicationErrors | none | ebMS-2#4.2.2 | ( For each received message ) | 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 | GenerateNoErrorList | full | ebMS-2#4.2.3 | ( For each generated message ) | REQUIRED | The ErrorList extension element of the SOAP Header element is never present if there are no errors to be reported. |
| r1.4.6 | ProvideErrorAndHighestSeverityIntegrity | partial | ebMS-2#4.2.3.1 | ( For each generated message ) | REQUIRED | For each generated message, the highestSeverity attribute contains the highest severity of any Error elements generated in an outbound message. |
| r1.4.7 | GenerateCorrectCodeContextValue | full | ebMS-2#4.2.3.2.2 | ( For each generated message ) | REQUIRED | The codeContext attribute of any generated Error element is always a URI. |
| r1.4.8 | GenerateCorrectCodeContextNamespaceValue | full | ebMS-2#4.2.3.2.2 | ( For each generated message ) | 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.10 | GenerateCorrectErrorSeverityValue | full | ebMS-2#4.2.3.2.4 | ( For each generated message ) | REQUIRED | Each Error element severity attribute has the value of Warning or Error indicating the severity of the error. |
| r1.4.11 | ProvideXPointerAndErrorIntegrity | partial | ebMS-2#4.2.3.2.5 | ( For each generated message, if an error exists in an ebXML element ) | REQUIRED | The location attribute of the Error element is an XPointer to the erroneous element. |
| r1.4.12 | GenerateReferencedMIMEPartErrorsWithCID | partial | ebMS-2#4.2.3.2.5 | ( For each generated message, if an error exists in a generated payload MIME part ) | REQUIRED | The location attribute of the generated Error element contains the content-id (via a well-formed "cid:") of the erroroneous MIME part. |
| r1.4.13 | GenerateErrorCodesUsingLongDescription | full | ebMS-2#4.2.3.4 | ( For each generated message ) | REQUIRED | The "Long Description" text for each error code provided by the Message Service Specification appears in any relevant Error element. |
| r1.4.14 | ReportErrorToMessageOrigin | full | ebMS-2#4.2.4.1 | ( For each received message, when an MSH detects an error in a message AND · The Error Reporting Location (see section 4.2.4.2) to which the message reporting the error should be sent can be determined AND · The message in error does not have an ErrorList element with highestSeverity set to Error. ) | RECOMMENDED | The error is reported to the MSH that sent the original message in error. |
| r1.4.15 | ProcessWithNoErrorReportLocation | none | ebMS-2#4.2.4.1 | ( For each received message, if the error reporting location cannot be found ) | RECOMMENDED | The error is: Logged; Resolved by other means; and, No further action is taken. |
| r1.4.16 | ProcessCPPAErrorURI | full | ebMS-2#4.2.4.2 | ( For each received message, if the ErrorURI is implied in the relevant CPPA ) | OPTIONAL | Then this is used as the Error Report Location. |
| r1.4.17 | ProcessWithNoCPPAErrorURIPresent | full | ebMS-2#4.2.4.2 | ( For each received message, if the ErrorURI is unavailable in the relevant CPPA ) | OPTIONAL | A URI specified in the From Party of the message is used as the Error Report Location. |
| r1.4.19 | GenerateServiceAndActionForErrorsFromIndependentMessage | full | ebMS-2#4.2.4.3 | ( For each generated message, if an ErrorList is included as part of an independent message ) | REQUIRED | The values of Service and Action are; Service: urn:oasis:names:tc:ebxml-msg:service Action: MessageError |
| r1.4.20 | ProcessErrorListWhereHighestSeverityEqualsError | none | ebMS-2#4.2.4.1 | ( For each received message, if the message in error has an ErrorList element with highestSeverity set to Error ) | RECOMMENDED | The error is: Logged; Resolved by other means; and, No further action is taken. |
| r1.5 | SynchReply | ebMS-24.3 | ||||
| r1.5.1 | ProcessSyncReply | full | ebMS-2#4.3.1 | ( For each received message, if a SyncReply element is present in a message received over a synchronous communications protocol ) | OPTIONAL | That connection is kept open in expectation of the response message using the same connection. |
| r1.5.3 | ReportMessageAndCPASyncReplyConflict | full | ebMS-2#4.3.1 | ( For each received message, if the CPPA syncReplyMode is set to none AND SyncReply element is present in an inbound message ) | OPTIONAL | The MSH issues an error (Inconsistent/Error). |
| r1.5.4 | GenerateAgreeingMessageAndCPASyncReply | full | ebMS-2#4.3.1 | ( For each generated message, if the CPPA syncReplyMode is set to none ) | OPTIONAL | SyncReply must not be present in generated message. |
| ID | Name | Test Coverage | Specification Ref | Precondition | Requirement Level | Assertion |
|---|---|---|---|---|---|---|
| r2.1 | ReliableMsg | ebMS-2#6 | ||||
| r2.1.1.1 | ResendToAckReceivedOrExceeded | full | ebMS-#6 | ( For each reliably generated message, if the candidate MSH fails to receive an Acknowledgment message from a receiving MSH ) | RECOMMENDED | The candidate sends successive retries until an Acknowledgment is received |
| r2.1.1.2 | ResendToAckReceivedOrExceeded | full | ebMS-#6 | ( For each reliably generated message, if the candidate MSH fails to receive an Acknowledgment mesage from a receiving MSH ) | RECOMMENDED | The candidate sends successive retries until a predetermined number of retries is exceeded. |
| r2.1.1.3 | ResumeAfterAckReceived | full | ebMS-#6 | ( For each reliably generated message, if the candidate MSH receives an Acknowledgment from a receiving MSH ) | RECOMMENDED | The MSH stops resending the message and behaveas as if the message was successfully delivered. |
| r2.1.2 | NotifyDeliveryFailureOnExceed | full | ebMS-#6 | ( For each reliably generated message, if the MSH is configured to resend AND the Sending MSH fails to receive any Acknowledgment message from the receiving MSH ) | REQUIRED | The Sending MSH sends successive retries at expected time intervals, then notifies the From party of delivery failure |
| r2.1.3.1 | PersistReliableSentMsg | partial | ebMS-2#6.1 | ( For each reliably sent message, after a system interruption AND the system recovers within the TimeToLive window. ) | REQUIRED | The message is kept in persistent storage and processsed as if the interruption had not occured. |
| r2.1.3.2 | PersistReliableSentMsgNoAck | partial | ebMS-2#6.1 | ( For each reliably sent message, after a system interruption AND no Ack was received prior to the interruption AND the system recovers within the TimeToLive window. ) | REQUIRED | The message is kept in persistent storage and processsed as if the interruption had not occured. |
| r2.1.3.3 | PersistReliableSentMsg | partial | ebMS-2#6.1 | ( For each reliably sent message, after a system interruption ) | REQUIRED | The message is kept in persistent storage. |
| r2.1.3.4 | PersistReliableReceivedMsg | partial | ebMS-2#6.1 | ( For each reliably received message, after a system interruption AND the system recovers within the TimeToLive window. ) | REQUIRED | The message is kept in persistent storage and processsed as if the interruption had not occured. |
| r2.1.3.5 | PersistReliableReceivedMsgNoAck | partial | ebMS-2#6.1 | ( For each reliably received message, after a system interruption AND no Ack was sent prior to the interruption AND the system recovers within the TimeToLive window. ) | REQUIRED | The message is kept in persistent storage and processsed as if the interruption had not occured. |
| r2.1.3.6 | PersistReliableReceivedMsg | partial | ebMS-2#6.1 | ( For each reliably received message, after a system interruption ) | REQUIRED | The message is kept in persistent storage. |
| r2.1.4.1 | PersistReliableSentMsg | partial | ebMS-2#6.1 | ( For each reliably sent message, after a system failure AND the system recovers within the TimeToLive window. ) | REQUIRED | The message is kept in persistent storage and processsed as if the interruption had not occured. |
| r2.1.4.2 | PersistReliableSentMsg | partial | ebMS-2#6.1 | ( For each reliably sent message, after a system failure AND no Ack was received prior to the interruption AND the system recovers within the TimeToLive window. ) | REQUIRED | The message is kept in persistent storage and processsed as if the interruption had not occured. |
| r2.1.4.3 | PersistReliableReceivedMsg | none | ebMS-2#6.1 | ( For each reliably received message ) | REQUIRED | The complete message is kept in persistent storage. |
| r2.1.5 | PersistReceivedMsgID | none | ebMS-2#6.1 | ( For each reliably received message, in order to support the filtering of duplicate messages ) | REQUIRED | The MessageId of the received messaged is recorded in persistent storage. |
| r2.1.6 | PersistRecdMsg | none | ebMS-2#6.1 | ( For each reliably received message ) | RECOMMENDED | The 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 | PersistReceivedMsgTimestamp | none | ebMS-2#6.1 | ( For each reliably received message ) | RECOMMENDED | The time at which a message is received is recorded in persistent storage. |
| r2.1.8 | PersistResponseMsg | none | ebMS-2#6.1 | ( For each reliably received message ) | RECOMMENDED | Each response message is stored in its entirety in persistent storage. |
| r2.1.12 | TargetAckRequestedToOrNextMSH | full | ebMS-2#6.3.1.1 | ( For each generated non-multi-hop message ) | REQUIRED | The AckRequested element is targeted at the Next MSH or the To Party |
| r2.1.13.2 | SetAckRequestedUnSigned | full | ebMS-2#6.3.1.2 | ( For each received message with an AckRequested with the Signed attribute set to False and consistent with the CPPA, ) | REQUIRED | The Acknowledgment message is unsigned. |
| r2.1.14.1 | SetSignedAttributeAfterVerifyReceivingMSHAckSupport | full | ebMS-2#6.3.1.2 | ( For each received message with an AckRequested with the Signed attribute set to True consistent with the CPPA, if the Receiving MSH supports signed acknowledgment messages of the type requested ) | REQUIRED | The Sending MSH sends back a signed Acknowledgment. |
| r2.1.14.2 | SetSignedAttributeAfterVerifyReceivingMSHAckSupport | full | ebMS-2#6.3.1.2 | ( For each received message with an AckRequested with the Signed attribute set to True consistent with the CPPA, if the Receiving MSH does not support signed acknowledgment messages of the type requested ) | REQUIRED | The MSH generates an Error of type Inconsistent, and severity = Error . |
| r2.1.14.3 | SetSignedAttributeAfterVerifyReceivingMSHAckSupport | full | ebMS-2#6.3.1.2 | ( For each received message with an AckRequested with the Signed attribute set to True and NOT consistent with the CPPA, if the Receiving MSH supports signed acknowledgment messages of the type requested ) | REQUIRED | The MSH generates an Error of type Inconsistent, and severity = Warning . |
| r2.1.17 | SendAckToFromParty | full | ebMS-2#6.3.1.3 | ( For each Acknowledgment request message, If an Acknowledgment is requested of the MSH node acting in the role of To Party ) | REQUIRED | The Acknowledgment element generated is targeted to the MSH node acting in the role of From Party. |
| r2.1.18 | GenererateAckWithNoPayloadAndNoAckRequested | full | ebMS-2#6.3.1.4 | ( For each generated Acknowledgment message, if the message contains no payloads ) | REQUIRED | The message does not include an AckRequested element. |
| r2.1.19 | ReportErrorWithoutAckRequeseted | full | ebMS-2#6.3.1.4 | ( For each Acknowledgment message, if the message contains an ErrorList element ) | REQUIRED | The message does not include an AckRequested element. |
| r2.1.20.1 | SpecifyNoSOAPActorToPartyAck | full | ebMS-2#6.3.2.1 | ( For each generated Acknowledgment message, if there is no SOAP actor atrribute present on an Acknowledgement element ) | STRONGLY RECOMMENDED | The default target is the ToParty MSH. |
| r2.1.20.2 | SpecifySOAPActorToPartyAck | full | ebMS-2#6.3.2.1 | ( For each Acknowledgment message ) | STRONGLY RECOMMENDED | The SOAP actor attribute in a generated Acknowledgment element has a value corresponding to the AckRequested element of the message being acknowledged. |
| r2.1.21 | GenerateAckMsgTimestamp | full | ebMS-2#6.3.2.2 | ( For each generated Acknowledgment message, if the From element is present ) | 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 | GenerateAckUsingMsgIDInRefToMessageID | full | ebMS-2#6.3.2.3 | ( For each generated Acknowledgment message ) | REQUIRED | The RefToMessageId element contains the MessageId of the message whose delivery is being acknowledged. |
| r2.1.23 | IdentifyPartyWithAckFromElement | full | ebMS-2#6.3.2.4 | ( For each generated Acknowledgment message, if the From element is present in an inbound message ) | REQUIRED | The From element in a generated Acknowledgment element contains an identifier of the party sending the Acknowledgment Message. |
| r2.1.24 | IdentifyPartyWithoutAckFromElement | full | ebMS-2#6.3.2.4 | ( For each generated Acknowledgment message, if the From element is omitted in an inbound message ) | REQUIRED | The value of the From element in the MessageHeader is used to identify the party sending the acknowledgment. |
| r2.1.25 | UseSignedAckMustContainRef | full | ebMS-#6.3.2.5 | ( For each generated Acknowledgment message, if the message being acknowledged contains an AckRequested element with the signed attribute set to "true" ) | REQUIRED | One or more Reference elements are included in the generated Acknowledgment element. |
| r2.1.26 | QualifyRefElementByNamespace | full | ebMS-#6.3.2.5 | ( For each generated Acknowledgment message ) | 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 | NotifyClientOfAckDelivery | none | ebMS-#6.3.2.5 | ( For each received Acknowledgment message ) | OPTIONAL | The From Party MSH notifies the client application of successful delivery of the referenced message. |
| r2.1.28 | IgnoreDuplicateRefToMessageID | none | ebMS-#6.2.2.5 | ( For each received Acknowledgment message, if any subsequent Error or Acknowledgment messages with a RefToMessageId value equal to an already received Acknowledgment Message are received ) | OPTIONAL | The messages are ignored. |
| r2.1.29 | SetAckServiceActionValues | full | ebMS-#6.3.2.7 | ( For each generated Acknowledgment message, If no errors were detected in the message received AND the Acknowledgment Message is being sent with no payload data ) | REQUIRED | The Service and Action values are: Service - urn:oasis:names:tc:ebxml-msg:service Action - Acknowledgment |
| r2.1.30.1 | SetDuplicateEliminationAlways | full | ebMS-#6.4.1 | ( For each generated message, if the CPPA DuplicateElimination element = "always" ) | REQUIRED | The DuplicateElimination element is included to indicate to a Receiving MSH that it must eliminate duplicates. |
| r2.1.30.2 | SetDuplicateEliminationtoNever | full | ebMS-#6.4.1 | ( For each generated message, if the CPPA DuplicateElimination element = "never" ) | REQUIRED | The DuplicateElimination element not present. |
| r2.1.30.3 | SetDuplicateEliminationPerMessage | full | ebMS-#6.4.1 | ( For each generated message, if the CPPA DuplicateElimination element = "per message" AND the party requires duplicate elimination ) | REQUIRED | The DuplicateElimination element is present in the header of the message. |
| r2.1.30.4 | ReceiveDuplicateEliminationAlways | full | ebMS-#3.1.2 | ( For each received message, if the CPPA DuplicateElimination element = "always" AND the received message does not contain a DuplicateElimination element ) | RECOMMENDED | The receiving MSH generates an Error message with an errorCode of Inconsistent and a Severity of Error. |
| r2.1.30.5 | ReceiveDuplicateEliminationtoNever | full | ebMS-#3.1.2 | ( For each received message, if the CPPA DuplicateElimination element = "never" AND the received message contains a DuplicateElimination element ) | REQUIRED | The receiving MSH generates an Error message with an errorCode of Inconsistent and a Severity of Error. |
| r2.1.32.1 | PersistMsgWithDuplicateElimination | full | ebMS-#6.4.1 | ( For each reliably sent message, if Duplication element is present on an inbound message ) | REQUIRED | The message is presented to the To Party Application at-most-once. |
| r2.1.32.2 | PersistMsgWithDuplicateEliminationAndInterruption | full | ebMS-#6.4.1 | ( For each reliably sent message, if Duplication element is present on an inbound message AND the system recovers from an interruption within the TimeToLive window. ) | REQUIRED | The message is presented to the To Party Application at-most-once. |
| r2.1.33.1 | ReportErrorIfDuplicateEliminationUnsupported | full | ebMS-#3.1.2 | ( For each received message containing a DuplicationElimination element, if duplicate elimination is not supported ) | RECOMMENDED | An Inconsistent/Error is reported to the From Party. |
| r2.1.33.2 | ReportErrorDuplicateEliminationMsgToCPPA | full | ebMS-#3.1.2 | ( For each reliably received message, if the value of duplicateElimination in the CPPA is "always" AND a DuplicateElimination element is not present in the message ) | RECOMMENDED | An Inconsistent/Error is reported to the From Party. |
| r2.1.33.3 | ReportErrorDuplicateEliminationMsgToCPPA | full | ebMS-#3.1.2 | ( For each reliably received message, if the value of duplicateElimination in the CPPA is "never" AND a DuplicateElimination element is present in the message ) | RECOMMENDED | An Inconsistent/Error is reported to the From Party. |
| r2.1.35 | RetryIntervalMinLapseTime | full | ebMS-#6.4.4 | ( For each reliably re-sent message, if the RetryInterval is present in the CPPA ) | OPTIONAL | The minimum time elapsed between re-sends of the same message is equal to the RetryInterval.. |
| r2.1.36 | SetTimeToLive | full | ebMS-#6.4.5 | ( For each reliably re-sent message, if the RetryInterval element is present in the CPPA ) | REQUIRED | The TimeToLive for the message satisfies the equation: TimeToLive > Timestamp + ((Retries + 1) * RetryInterval) |
| r2.1.37.1 | PersistSentMsgLength | full | ebMS-#6.4.6 | ( For each reliably received message, if the PersistDuration parameter is present in the CPPA AND DuplicationElimination element is present in the messsage AND the message is presented once and only once to the application AND the same message is received again by the MSH before PersistDuration expires ) | REQUIRED | The message is presented only once to the application. |
| r2.1.37.2 | PersistSentMsgLength | full | ebMS-#6.4.6 | ( For each reliably received message, if the PersistDuration parameter is present in the CPPA AND AckRequested element is present in the messsage AND the message is presented once and only once to the application AND the same message is received again by the MSH before PersistDuration expires ) | REQUIRED | An Acknowledgement message is sent back to the sending MSH. |
| r2.1.38 | SendNoMsgWithLapsePersistDurationMsgID | full | ebMS-#6.4.6 | ( For each generated message, if the length of time specified by the PersistDuration parameter in the relevant CPA has passed since a message was first sent ) | OPTIONAL | A message with the same MessageId will not be sent again. |
| r2.1.39 | ReptDeliveryFailureIfPersistDurationExpired | full | ebMS-#6.4.6 | ( For each reliably received message, if a message cannot be successfully delivered before expiry of the PersistDuration period ) | OPTIONAL | A delivery failure is reported. |
| r2.1.40 | TimestampPersistDurationGreaterThanTimeToLive | full | ebMS-#6.4.4 | ( For each reliably sent message ) | REQUIRED | For each reliably sent message, the message satisfies the equation: PersistDuration > TimeStampe + TimeToLive. |
| r2.1.41 | IgnoreSyncReplyMode | none | ebMS-#6.4.7 | ( For each reliablly sent messsage, if the communications protocol is not synchronous ) | REQUIRED | The value of the syncReplyMode in the relevant CPA is ignored. |
| r2.1.42.1 | ReturnSyncReplyElementInResponsePayload | full | ebMS-#6.4.7 | ( For each reliably sent message, if ( in the context of the CPPA ) the syncReplyMode is not none ) | REQUIRED | A SyncReply element is present in the message. |
| r2.1.42.2 | ReturnSyncReplyResponsePayload | full | ebMS-#6.4.7 | ( For each reliably sent message, if ( in the context of the CPPA ) the syncReplyMode is not none ) | REQUIRED | The MSH returns the response on the same synchronous connection. |
| r2.1.44 | GenerateAckWhenAckRequested | full | ebMS-#6.5.3 | ( For each reliably received message, if the AckRequested element that has a SOAP actor URI targeting the MSH ) | REQUIRED | An Acknowledgment Message is generated. |
| r2.1.45 | PersistAckWithOriginalMsg | none | ebMS-#6.5.3 | ( For each received Acknowledgment message ) | REQUIRED | The message is placed in persistent storage with the same PersistDuration as the original message. |
| r2.1.46 | DeliverAckWithResponse | full | ebMS-#6.5.3 | ( For each Acknowledgment message ) | REQUIRED | The message can be delivered as part of the normal response to the received message. |
| r2.1.47 | ResendMsgOnCommError | none | ebMS-#6.5.4 | ( For each reliably sent message, if there is a communications protocol error during a message send ) | REQUIRED | The message is resent as if the MSH had not received an Acknowledgment Message. |
| r2.1.48 | SendOriginalAckOnDuplicateMsg | partial | ebMS-#6.5.5 | ( For each reliably received message, if a duplicate message is received AND the original acknowledgment is still present in the persistent store ) | OPTIONAL | This original Acknowledgment Message is resent. |
| r2.1.49 | GenerateSyncResponseOnDuplicateMsg | partial | ebMS-#6.5.5 | ( For each reliably received message, If a duplicate 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 ) | OPTIONAL | response from the application is gathered by the MSH and returned synchronously. |
| r2.1.50 | GenerateAckMsgOnNonSyncDuplicateMsg | partial | ebMS-#6.5.5 | ( For each reliably received message, if a duplicate message is received AND the original acknowledgment is not present in the persistent store AND the syncReplyMode is not none ) | OPTIONAL | A new Acknowledgment Message is generated and sent. |
| r2.1.51.1 | ReportErrorOnMsgWithAckReqNoTransmit | full | ebMS-#6.5.7 | ( For each reliably received message, if the message contains an AckRequested element AND the message cannot be delivered because the message could not be transmitted ) | STRONGLY RECOMMENDED | An error message is sent to the From Party. The reported error is DeliveryFailure/Error. |
| r2.1.51.2 | GenerateWarningErrorOnMsgWithAckRequested | full | ebMS-#6.5.7 | ( For each reliably received message, if the message contains an AckRequested element AND the message was transmitted but no acknowledgement was received ) | STRONGLY RECOMMENDED | An error message is sent to the From Party. The reported error is DeliveryFailure/Warning. |
| r2.1.52 | NotifyFailureByAlternateMeans | none | ebMS-#6 | ( For each reliably received message, if an Error Message is generated with an error code set to DeliveryFailure AND an Error Message cannot be delivered successfully ) | REQUIRED | The ultimate destination of the error message is informed of the failure by some undefined means. |
| r2.2 | MsgOrder | ebMS-2#9 | ||||
| r2.2.2 | EnableMsgOrderWithReliableMsg | full | ebMS-2#9 | ( For each received message, if the message contains a MessageOrder element ) | REQUIRED | The DuplicateElimination is present and AckRequested directed to the To Party MSH and absence of a SyncReply element. |
| r2.2.3 | ProcessSequenceMsg | full | ebMS-2#9.1.1 | ( For each received message, when two messages are received, each with a MessageOrder element, and the same conversationID ) | REQUIRED | The MSH processes messages only in the sequence indicated by the SequenceNumber element. |
| r2.2.4 | PassOrderedMsgToApplication | full | ebMS-2#9.1.1 | ( For each received message, if the message contains a MessageOrder element AND when receiving ordered messages with the same conversationID out of sequence ) | REQUIRED | The message is not passed to the destination application until all messages with a lower (earlier) SequenceNumber have previously been passed. |
| r2.2.5 | GenerateDeliveryFailureOnOutOfSequMsg | full | ebMS-2#9.1.1 | ( For each received message, if the message contains a MessageOrder element AND if the maximum number of out-of-sequence ordered messages have been received ) | REQUIRED | The Sending MSH is sent an error and the error code is DeliveryFailure and severity set to Error. |
| r2.2.6.1.1 | UseZeroSequenceNoForFirstOrderedMsgForConversation | full | ebMS-2#9.1.1 | ( For each received message, if the message contains a MessageOrder element AND if this is the first ordered message for the ConversationID ) | REQUIRED | The SequenceNumber element has value of 0." |
| r2.2.6.1.2 | UseStatusResetForFirstOrderedMsgForConversation | full | ebMS-2#9.1.1 | ( For each received message, if the message contains a MessageOrder element AND if this is the first ordered message for the ConversationID ) | REQUIRED | The status attribute of the message is set to "Reset". |
| r2.2.6.2.1 | UseZeroSequenceNoForFirstOrderedMsgAfterReset | full | ebMS-2#9.1.1 | ( For each received message, if the message contains a MessageOrder element AND this is the first ordered message after a reset instruction is sent by the Sending MSH ) | REQUIRED | The SequenceNumber element has value of 0 and the status attribute of the message is set to Reset. |
| r2.2.6.2.2 | UseStatusReseetForFirstOrderedMsgAfterReset | full | ebMS-2#9.1.1 | ( For each received message, if the message contains a MessageOrder element AND this is the first ordered message after a reset instruction is sent by the Sending MSH ) | REQUIRED | The message is set to Reset. |
| r2.2.6.3 | UseZeroSequenceNoForFirstOrderedMsgAfterWrap | full | ebMS-2#9.1.1 | ( For each received message, if the message contains a MessageOrder element AND this is the first ordered message after the sequence wrapped at value 99999999 ) | REQUIRED | The SequenceNumber element has value of 0. |
| r2.2.9 | ResetMsgSeqForConversation | partial | ebMS-2#9.1.1 | ( For each generated message, when sending a message with the MessageOrder element AND if the status attribute is set to "Reset" ) | REQUIRED | All previous messages for this conversation must have been accounted for. |
| r2.2.10.2 | SyncReplyMsgNotIncludeMsgOrder | full | ebMS-2#9.2 | ( For each received message, if the message contains a SyncReply element ) | REQUIRED | A MessageOrder element is never included in the same message as a SyncReply element. |
| r2.2.11 | ReportErrorMsgOrderSyncReply | full | ebMS-2#9.2 | ( If a message is received in which the MessageOrder element is included with a SyncReply element ) | RECOMMENDED | An error is reported. The error is Inconsistent/Error. |
| r2.4 | SecurityAndCommunicationChannels | ebMS-2#4 | ||||
| r2.4.1.1 | Signature elements SignOutboundMsg | full | ebMS-2#4.1 | ( For each generated message, when one or more Signature elements is present ) | REQUIRED | It is the child of the SOAP Header. |
| r2.4.1.2 | Signature elements SignOutboundMsg | full | ebMS-2#4.1 | ( For each generated message, when one or more Signature elements is present ) | REQUIRED | It is namespace qualified witih XML Signature. |
| r2.4.1.3 | Signature elements SignOutboundMsg | full | ebMS-2#4.1 | ( For each generated message, when one or more Signature elements is present ) | REQUIRED | Its structure and content conform to the XML Signature specification. |
| r2.4.2 | AttributeSignatureElement | none | ebMS-2#4.1 | ( If there is more than one Signature element within the SOAP Header ) | REQUIRED | It is the first signature that represents digital signing of the message by the From Party MSH. |
| r2.4.4 | ApplySecurityBasedOnTransportOfCPA | full | ebMS-2#4.1.3 | ( For each generated message if,based upon the Transport section of the relevent CPA, a signature is required for the entire message ) | REQUIRED | A Signature element must be present, and its SignedInfo element contains a Reference element to the SOAP envelope which has a URI attribute value of "" |
| r2.4.5.1 | GenerateSignToXMLDSIG | none | ebMS-2#4.1.3 | ( For each signed message ) | REQUIRED | Digital signatures are generated and rendered according the XML Signature specification (XMLDSIG). |
| r2.4.5.2 | GenerateSignToXMLDSIG | full | ebMS-2#4.1.3 | ( For each signed message ) | REQUIRED | The SignedInfo element has a CanonicalizationMethod, SignatureMethod and one or more Reference elements. |
| r2.4.5.3 | GenerateSignToXMLDSIG | full | ebMS-2#4.1.3 | ( For each signed message ) | REQUIRED | The SignatureMethod element is present and has an Algorithm attribute on any generated digitally signed message. |
| r2.4.6 | SignCanonicalMethod | none | ebMS-2#4.1.3 | ( For each generated message with one or more Signature elements ) | RECOMMENDED | The canonicalization method applied to the data to be signed is Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" |
| r2.4.8 | SignatureMethodAlgorithmAttribute | full | ebMS-2#4.1.3 | ( For each generated message with one or more Signature elements ) | RECOMMENDED | The value of the Algorithm attribute is Algorithm="http://www.w3.org/2000/09/xmldsig#dsa-sha1" |
| r2.4.9 | SupportDSA-SHA1SignAlgorithm | none | ebMS-2#4.1.3 | ( For each generated message with one or more Signature elements, ) | REQUIRED | The MSH supports the signature algorithm DSA-SHA1, validates the signature and passes the message to the application. |
| r2.4.11 | AddOptionalReferenceAttribute | full | ebMS-2#4.1.3 | ( For each generated message with one or more Signature elements ) | 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. |
| r2.4.12 | IncludeMandatoryTransformElementToEnvelopedSign | full | ebMS-2#4.1.3 | ( For each generated message with one or more Signature elements ) | REQUIRED | The generated XML Signature Reference element includes a child Transform element which in turn includes a first Transform element with an Algorithm attribute of value "http://www.w3.org/2000/09/xmldsig#enveloped-signature". |
| r2.4.13 | GenerateMandatoryTransformWithExcludeSOAPActor | full | ebMS-2#4.1.3 | ( For each generated message with one or more Signature elements, (CPA, Transport section) that requires signature ) | REQUIRED | A second Transform element is generated with the requisite XPath element excluding all elements with SOAP actor attributes targetting the nextMSH or next SOAP node. |
| r2.4.15 | CanonicalizationTransformElementAlgorithmAttribute | full | ebMS-2#4.1.3 | ( For each generated message with one or more Signature elements ) | OPTIONAL | The last generated Transfom element has an Algorithm attribute with a value of "http://www.w3.org/TR/2001/REC-xml-c14n-20010315". |
| r2.4.16 | XMLSignReferenceURIForPayload | full | ebMS-2#4.1.3 | ( For each generated message with one or more Signature elements ) | 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. |
| r2.4.17 | MapSignReferenceURIToManifestPayload | full | ebMS-2#4.1.3 | ( For each generated message with one or more Signature elements ) | 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. |
| r2.4.18 | GenerateSignPriorToTransferEncoding | none | ebMS-2#4.1.3 | ( For each generated message with one or more Signature elements, and with transfer encoding ) | REQUIRED | Signature generation takes place before any transfer encoding (eg base64) is applied to the SOAP Envelope or payload MIME parts. |
| r2.4.19 | SignAckReferenceElementList | partial | ebMS-2#4.1.3.2 | ( For each received signed message ) | 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. |
| r2.4.20 | AuthenticatePartyByCommunicationChannel | none | ebMS-2#4.1.4.3 | ( For each generated message ) | 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). |
| r2.4.21 | ProvideMsgContentDataIntegrityByCommunicationChannel | none | ebMS-2#4.1.4.4 | ( For each generated message ) | 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). |
| r2.4.22 | SignMsgPriorToEncryption | none | ebMS-2#4.1.4.5 | ( For each generated message if,based upon the Transport section of the relevent CPA, a signature is required for the entire message AND if signature and encryption of a message component is requested of the MSH ) | REQUIRED | Signing takes place prior to encryption. |
| r2.4.23 | ProvideMsgContentDataConfidentialityByCommunicationChannel | none | ebMS-2#4.1.4.6 | ( For each generated message ) | 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). |
| r2.4.24 | AuthorizeMsgWithBilateralAuthenticationByNetworkProtocol | none | ebMS-2#4.1.4.8 | ( For each generated message ) | 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). |
| ID | Name | Test Coverage | Specification Ref | Precondition | Requirement Level | Assertion |
|---|---|---|---|---|---|---|
| r3.1 | MessageStatusService | ebMS-2#7 | ||||
| r3.1.1 | GenerateStatusResponseWithReliableMessaging | full | ebMS-2#7 | ( For each received message, if the message contains a StatusRequest element AND the RefToMessageId child element references a previously received message that had been sent reliably and is present in persistent storage ) | RECOMMENDED | A Message Status Response Message is returned. |
| r3.1.2 | GenerateStatusResponseWithoutReliableMessaging | full | ebMS-2#7 | ( For each received message, if the message contains a StatusRequest element AND the RefToMessageId child element references a previously received message that had not been sent reliably ) | OPTIONAL | A Message Status Response is returned. |
| r3.1.4 | ReportUnsupportedService | full | ebMS-2#7 | ( For each received message, if the message contains a StatusRequest element AND the message is received for a service that is not supported ) | RECOMMENDED | An Error Message is returned with an errorCode of "NotSupported". |
| r3.1.5 | GenerateValidStatusRequestMessage | full | ebMS-2#7.1.1 | ( For each received message, If the MessageHeader child Action element is equal to "StatusRequest" ) | REQUIRED | The message consists of no payload and the MessageHeader/StatusRequest elements configured as specified in the Message Service Specification and is not included along with any of the Manifest, StatusResponse, or ErrorList elements. |
| r3.1.7 | ProcessUnauthorizedStatusRequest | partial | ebMS-2#7.1.3 | ( For each received message, if the message contains a StatusRequest element AND the StatusRequest child RefToMessageId element value is recognized by the MSH AND the message is received from an party deemed to be unauthorised ) | OPTIONAL | A response is sent with the messageStatus attribute set to "UnAuthorized". |
| r3.1.9 | ProvideRefToMessageIdAndMessageIdIntegrity | full | ebMS-2#7.3.1 | ( For each received message, if the message contains a StatusRequest element AND the StatusRequest child RefToMessageId element value is recognized by the MSH AND the message is received from an party deemed to be authorised AND a StatusResponse is generated for this request ) | RECOMMENDED | In the returned StatuResponse element, the RefToMessageId element child of the MessageData element specifies the MessageId of the message containing the associated StatusRequest element. In addition, the RefToMessageId element child of the StatusResponse elements always contains the MessageId of the message whose status is being queried. |
| r3.1.10.1 | SetTimestampRecognizedAndAuthorized | full | ebMS-2#7.3.2 | ( For each received message, if the message contains a StatusRequest element AND the the StatusRequest child RefToMessageId element value is recognized AND the message is received from an party deemed to be authorised ) | REQUIRED | In the response message, the Timestamp child element of the StatusResponse element contains the time at which the message being reported on was originally received. |
| r3.1.10.2 | SetTimestampNotRecognized | full | ebMS-2#7.3.2 | ( For each received message, if the message contains a StatusRequest element AND the the StatusRequest child RefToMessageId element value is not recognized AND the message is received from an party deemed to be authorised ) | REQUIRED | The Timestamp child element of the StatusResponse element is not present in the response message. |
| r3.1.10.3 | SetTimestampNotAuthorized | full | ebMS-2#7.3.2 | ( For each received message, if the message contains a StatusRequest element AND the the StatusRequest child RefToMessageId element value is recognized AND the message is received from an party deemed to be unauthorised ) | REQUIRED | The Timestamp child element of the StatusResponse element is not present in the response message. |
| r3.1.13 | GenerateReceivedMessageStatus | full | ebMS-2#7.3.3 | ( For each received message, if the message contains a StatusRequest element AND the the StatusRequest child RefToMessageId element value is recognized AND the message is received from an party deemed to be authorised ) | REQUIRED | The messageStatus attribute in the StatusResponse element has a value of 'Received'. |
| r3.1.14 | GenerateProcessedMessageStatus | full | ebMS-2#7.3.3 | ( For each received message, if the message contains a StatusRequest element AND the the StatusRequest child RefToMessageId element value is recognized AND the message is received from an party deemed to be authorised ) | REQUIRED | The messageStatus attribute in the StatusResponse element has a value of 'Processed'. |
| r3.1.15 | GenerateReceivedMessageStatus | full | ebMS-2#7.3.3 | ( For each received message, if the message contains a StatusRequest element AND the the StatusRequest child RefToMessageId element value is recognized AND the message is received from an party deemed to be authorised AND the message identified by the RefToMessageId element in the StatusRequest element has been forwarded by the MSH ) | REQUIRED | A StatusResponse with a 'Forwarded' messageStatus is be present in the returned message. |
| r3.2 | PingService | ebMS-2#8 | ||||
| r3.2.2 | ReportServiceNotSupported | full | ebMS-2#8 | ( For each received message, if the message header Action element contains a child Ping element AND the requested service is not supported ) | RECOMMENDED | A message with an Error element is returned with an errorCode of "NotSupported" and a highestSeverity attribute set to "Error". |
| r3.2.3 | GenerateValidPingMessageStructure | full | ebMS-2#8.1 | ( For each generated message, if the message headerAction element contains a child Ping element ) | REQUIRED | The message consists of no payload and the MessageHeader and Signature elements are configured as specified in the Message Service Specification. |
| r3.2.4 | GeneratePongResponse | full | ebMS-2#8.2 | ( For each received message, if the message header Action element contains a child Ping element AND the requested service is supported AND The Ping request is occurring under normally expected conditions, and the the received message is authorized and not interpreted by the Receiving party as part of an attack. ) | OPTIONAL | A message header Action element containing a child Pong element is returned. The message contains no payload and the MessageHeader & Signature elements are configured as specified in the Message Service Specification. |
| r3.3 | MultiHopModule | ebMS-2#10 | ||||
| r3.3.1 | SetMultiHopIntermediaryNextMSH | full | ebMS-2#10.1 | ( For each generated multi-hop message ) | OPTIONAL | The AckRequested and Acknowledgment elements have the SOAP actor attribute set to NextMSH (urn:oasis:names:tc:ebxml-msg:actor:nextMSH). |
| r3.3.2 | RemoveIntermediaryAckRequested | full | ebMS-2#10.1.1 | ( For each received multi-hop message, when a node acts as an intermediary ) | REQUIRED | The node removes any AckRequested element with a SOAP actor attribute of NextMSH. |
| r3.3.3 | InsertIntermediaryAckRequested | none | ebMS-2#10.1.1 | ( For each received multi-hop message, when a node acts as an intermediary ) | OPTIONAL | The node can insert a single AckRequested element with a SOAP actor attribute of NextMSH. |
| r3.3.4 | GenerateSingleAckRequestedForNextMSH | full | ebMS-2#10.1.1 | ( For each generated multi-hop message with the SOAP actor attribute value targetting the NextMSH ) | REQUIRED | There will not be two AckRequested elements in the same message. |
| r3.3.5 | SyncReplyNoAckRequestedForNextMSH | full | ebMS-2#10.1.1 | ( For each generated multi-hop message, if a SyncReply element is present in a message ) | REQUIRED | An AckRequested element with SOAP actor attribute targetting the NextMSH is never included. |
| r3.3.6 | GenerateErrorWithSyncReplyAckRequested | full | ebMS-2#10.1.1 | ( For each received multi-hop message, if the SyncReply and AckRequested elements is received in one message AND the AckRequested element is received in the same message ) | REQUIRED | An error is reported with an errorCode of "Inconsistent". |
| r3.3.7 | GenerateIntermediaryAckMsgIfNoSyncReply | full | ebMS-2#10.1.1 | ( For each received multi-hop message, when a node acts in the role of intermediary AND no SyncReply element is specified ) | OPTIONAL | A node may synchronously return an intermediate Acknowledgment Message to the Sending MSH. |
| r3.3.8 | GenerateAckBasedBasedOnActor | full | ebMS-2#10.1.3 | ( For each received multi-hop message, if an inbound message contains two AckRequested elements where one addresses NextMSH AND another AckRequest addresses the ToParty MSH AND the receving MSH is the ToParty MSH ) | REQUIRED | The MSH node is in the combined role of Next and ToParty MSH, and will send two Acknowledgments |
| r3.3.9 | GenerateIntermediaryAckMsgAtComplete | partial | ebMS-2#10.1.3 | ( For each received multi-hop message, a reliable message received by an MSH node in the role of intermediary ) | REQUIRED | The message is not acknowledged until the message is both persisted and delivered to the Next MSH. |
| r3.3.10 | GenerateIntermediarySignedAck | full | ebMS-2#10.1.4 | ( For each received multi-hop message, when a signed Acknowledgment Message is requested by an intermediate node ) | REQUIRED | The message is only generated as a standalone message and is not bundled with any other data (payload). |
| r3.3.11 | NoMsgOrderProcessForIntermediary | full | ebMS-2#10.2 | ( For each received multi-hop message, when the MSH acts in the role of intermediary ) | REQUIRED | The MSH does not attempt to participate in Message Order processing. |
| r3.3.12.1 | RequestDownstreamAck | full | ebMS-2#6.3.1 | ( For a downstream ( Next ) processor , if an AckRequested element is received ) | REQUIRED | An acknowledgment is returned. |
| r3.3.13 | GenerateMultipleAckRequested | full | ebMS-2#6.3.1 | ( For each generated multi-hop message, if there are two AckRequested elements in a generated message Header ) | REQUIRED | The two AckRequested elements do not specify the same value for their respective SOAP actor attributes. |
| r3.3.14 | TargetAtMostOneAckNextMSH | full | ebMS-2#6.3.1 | ( For each generated multi-hop message ) | REQUIRED | At most one AckRequested element may be targeted at the actor URI for the Next MSH. |
| r3.3.15 | TargetAtMostOneAckToPartyMSH | full | ebMS-2#6.3.1 | ( For each generated multi-hop message ) | REQUIRED | At most one AckRequested element may be targeted at the actor URI for the To Party MSH in a given message. |
| r3.3.16 | IgnoreIntermediaryDuplicates | full | ebMS-#6.5.2 | ( For each reliably received message, when the MSH acts as an intermediary node ) | REQUIRED | The MSH does not filter out perceived duplicate messages. |
| r3.3.18 | ControlIntermediaryMSHHandling | none | ebMS-2#4.1.3 | ( For each received multi-hop message, when a node acts as an intermediary ) | REQUIRED | The MSH does not change, format or in any way modify any element not targetted at that intermediary MSH. The MSH does not add or delete white space. |
| r3.3.19 | TargetAckRequestedToOrNextMSH | full | ebMS-2#6.3.1.1 | ( For each generated multi-hop message ) | REQUIRED | The AckRequested element is targeted at the NextMSH |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC