OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-iic-conform message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Subject: Re: [ebxml-iic-conform] MS Level 2 test reqs


Jacques and all,

Here is iteration #2 of level 2 requirements, with changes as per attached comments. My comments are
preceded by [MIKE2].

Also, here is the first "go-around" for level 3 requirements. Comments welcome.

Cosmetic changes to HTML will follow ( e.g. moving REQUIRED/OPTIONAL out of Assertion text )

Mike

 
 
 

Title: OASIS ebxml-iic TC -> Requirements

OASIS ebxml-iic TC: Messaging Conformance Requirements

ID Name Test Coverage Specification Ref Precondition 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 meesage from a receiving MSH ) OPTIONAL: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 ) OPTIONAL:The candidate sends successive retries until a predetermined number of retries is exceeded.
r2.1.2 NotifyDeliveryFailureOnExceed full ebMS-#6 ( For each reliably generated message, if the MSH is configured to resend AND No Ack is received AND The predetermined number of retries is exceeded ) REQUIRED:The sending MSH notifies the From Party of the probable 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 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, after a system failure ) REQUIRED:The message is kept in persistent storage.
r2.1.5 PersistReceivedMsgID none ebMS-2#6.1 REQUIRED:For each reliably received message, the MessageId of the received messaged is recorded in persistent storage.
r2.1.6 PersistRecdMsg none ebMS-2#6.1 RECOMMENDED:For each reliably received message, 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 RECOMMENDED:For each reliably received message, the time at which a message is received is recorded in persistent storage.
r2.1.8 PersistResponseMsg none ebMS-2#6.1 RECOMMENDED:For each reliably sent message, each response message is stored in its entirety in persistent storage.
r2.1.12 TargetAckRequestedToOrNextMSH full ebMS-2#6.3.1.1 REQUIRED:For each Acknowledgment request message, the AckRequested element is targeted at the To Party or NextMSH
r2.1.13.1 SetAckRequestedSigned full ebMS-2#6.3.1.2 ( For each Acknowledgment request message, If the signed attribute of the AckRequested element is set to "true'". ) REQUIRED:The Acknowledgment message is signed.
r2.1.13.2 SetAckRequestedUnSigned full ebMS-2#6.3.1.2 ( For each Acknowledgment request message, If the signed attribute of the AckRequested element is set to "false'". ) REQUIRED:The Acknowledgment message is unsigned.
r2.1.14 SetSignedAttributeAfterVerifyReceivingMSHAckSupport full ebMS-2#6.3.1.2 ( For each Acknowledgment request message, if the Receiving MSH supports acknowledgment messages of the type recquested ) RECOMMENDED:The Sending MSH sets the value of the signed attribute on an outgoing message.
r2.1.15 ReturnAckMsg full ebMS-2#6.3.1.2 ( For each Acknowledgement request message, if an Acknowledgment of the type requested on an inbound message can be produced ) REQUIRED:A message containing an Acknowlegment element is returned to the Sending MSH.
r2.1.16a GenerateInconsistentErrorOnAck full ebMS-2#6.3.1.2 ( For each Acknowledgement request message, if an Acknowledgment of the type requested cannot be produced ) REQUIRED:An error is reported to the Sending MSH. The error is Inconsistent/Error if the request in inconsistent with the relevant CPA.
r2.1.16b GenerateInconsistentWarningOnAck full ebMS-2#6.3.1.2 ( For each Acknowledgment request message, if an Acknowledgment Message of the type requested cannot be produced ) REQUIRED:An error is reported to the Sending MSH. The error is Inconsistent/Warning if the mode is not supported.
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 STRONGLY RECOMMENDED:For each Acknowledgment message, 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 REQUIRED:For each generated Acknowledgment message, 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 REQUIRED:For each generated Acknowledgment message, 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 If 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 SetDuplicateElimination full ebMS-#6.4.1 ( For each generated Acknowledgment 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 Acknowledgment message, if the CPPA DuplicateElimination element = "never" ) REQUIRED:The DuplicateElimination element not present.
r2.1.30.3 SetDuplicateElimination full ebMS-#6.4.1 ( For each generated Acknowledgment 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.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-#6.4.1 ( For each received message containing a DuplicationElimination element, if duplicate elimination is not supported ) OPTIONAL:An Inconsistent/Error is reported to the From Party.
r2.1.33.2 ReportErrorDuplicateEliminationMsgToCPPA full ebMS-#6.4.1 ( 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 ) OPTIONAL:An Inconsistent/Error is reported to the From Party.
r2.1.33.3 ReportErrorDuplicateEliminationMsgToCPPA full ebMS-#6.4.1 ( For each reliably received message, if the value of duplicateElimination in the CPPA is "never" AND A DuplicateElimination element is present in the message ) OPTIONAL: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 AND For each reliably re-sent message, if the Retries 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 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 REQUIRED:For each received Acknowledgment message, the essage is placed in persistent storage with the same PersistDuration as the original message.
r2.1.46 DeliverAckWithResponse full ebMS-#6.5.3 REQUIRED:For each Acknowledgment message, 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 If 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 If the original acknowledgment is not present in the persistent store AND If the syncReplyMode is set to none AND If 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 If the original acknowledgment is not present in the persistent store AND If 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 If 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, if the message contains a MessageOrder element AND When receiving ordered messages with 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 For each received ordered message, 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 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 and the status attribute of the message is set to "Reset".
r2.2.6.2 UseZeroSequenceNoForFirstOrderedMsgAfterReset 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 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.3 UseZeroSequenceNoForFirstOrderedMsgAfterWrap 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 after the sequence wrapped at value 99999999 ) REQUIRED:The SequenceNumber element has value of 0.
r2.2.8 SetStatusToContinueMsg full ebMS-2#9.1.1 ( For each received message, if the message contains a MessageOrder element ) REQUIRED:The sequenceNumber element status attribute has a value of "Reset" or "Continue"
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 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, is namespace qualified witih XML Signature and 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 none ebMS-2#4.1.2.1 ( 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 GenerateSignToXMLDSIG full ebMS-2#4.1.3 REQUIRED:For each signed message, 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.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 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 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 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 none 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.
r2.4.20 AuthenticatePartyByCommunicationChannel none 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).
r2.4.21 ProvideMsgContentDataIntegrityByCommunicationChannel none 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).
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 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 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).
Title: OASIS ebxml-iic TC -> Requirements

OASIS ebxml-iic TC: Messaging Conformance Requirements

ID Name Test Coverage Specification Ref Precondition Assertion
r3.1 MessageStatusService ebMS-2#8
r3.1.1 GenerateStatusResponseWithReliableMessaging full ebMS-2#8 ( For each received message, if the message contains a StatusRequest element AND If 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#8 ( For each received message, if the message contains a StatusRequest element AND If 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#8 ( For each received message, if the message contains a StatusRequest element AND If the message is received for a service that is not supported ) OPTIONAL:An Error Message is returned with an errorCode of "NotSupported".
r3.1.5 GenerateValidStatusRequestMessage none ebMS-2#8.1.1 REQUIRED:For each generated StatusRequest message, 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 full ebMS-2#8.1.3 ( For each received message, if the message contains a StatusRequest element AND If the StatusRequest child RefToMessageId element value is recognized by the MSH AND If 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#8.3.1 ( For each received message, if the message contains a StatusRequest element AND If the StatusRequest child RefToMessageId element value is recognized by the MSH AND If the message is received from an party deemed to be authorised ) REQUIRED: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#8.3.2 ( For each received message, if the message contains a StatusRequest element AND If the the StatusRequest child RefToMessageId element value is recognized AND If 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#8.3.2 ( For each received message, if the message contains a StatusRequest element AND If the the StatusRequest child RefToMessageId element value is not recognized AND If 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#8.3.2 ( For each received message, if the message contains a StatusRequest element AND If the the StatusRequest child RefToMessageId element value is recognized AND If 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.12 ProcessNotRecognizedStatusRequest full ebMS-2#8.1.3 ( For each received message, if the message contains a StatusRequest element AND If the the StatusRequest child RefToMessageId element value is not recognized AND If the message is received from an party deemed to be authorised ) OPTIONAL:A response is sent with the messageStatus attribute set to "NotRecognized".
r3.1.13 GenerateReceivedMessageStatus full ebMS-2#8.3.3 ( For each received message, if the message contains a StatusRequest element AND If the the StatusRequest child RefToMessageId element value is recognized AND If the message is received from an party deemed to be authorised AND If the message identified by the RefToMessageId element in the StatusRequest element has been received by the MSH ) REQUIRED:A StatusResponse with a 'Received' messageStatus should be present in the returned message.
r3.1.14 GenerateProcessedMessageStatus full ebMS-2#8.3.3 ( For each received message, if the message contains a StatusRequest element AND If the the StatusRequest child RefToMessageId element value is recognized AND If the message is received from an party deemed to be authorised AND If the message identified by the RefToMessageId element in the StatusRequest element has been processed by the MSH ) REQUIRED:A StatusResponse with a 'Processed' messageStatus is present in the returned message.
r3.1.15 GenerateReceivedMessageStatus full ebMS-2#8.3.3 ( For each received message, if the message contains a StatusRequest element AND If the the StatusRequest child RefToMessageId element value is recognized AND If the message is received from an party deemed to be authorised AND If 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 ) OPTIONAL:A message with an Error element is returned with an errorCode of "NotSupported".
r3.2.3 GenerateValidPingMessageStructure none 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 ( For each received message, if the message header Action element contains a child Ping element AND The requested service is supported ) 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 OPTIONAL:For each generated multi-hop message, 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 REQUIRED:For each generated multi-hop message, there will not be two AckRequested elements in the same message with a SOAP actor attribute value targetting the NextMSH.
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 If 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 If 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, the MSH node is in the combined role of Next and ToParty MSH. AND If an inbound message contains two AckRequested elements where another addresses ToPartyMSH, the MSH node is in the combined role of Next and ToParty MSH. AND If the MSH node is able to differentiate the acknowledgment requests based upon the actor attribute. ) REQUIRED:The MSH node sends acknowledgments as applicable.
r3.3.9 GenerateIntermediaryAckMsgAtComplete partial ebMS-2#10.1.3 REQUIRED:For each received multi-hop message, 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.
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 REQUIRED:For each generated multi-hop message, 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 REQUIRED:For each generated multi-hop message, 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.
Jacques,  
See [MIKE2] for comments



r2.2.5:re-wording: 
[precondition]: the MSH allows for specifying maximum of received out-of-order 
messages, 
and this maximum has been reached for a given conv ID. 
[assertion]: REQUIRED: MSH notifies sending MSH with delivery failure (with 
code...). 

[MIKE] - Spec does not infer that allowing for a maximum # of out-of-order
messages is an option.. it infers that this is a requirement.. If it is an option,
then it should be specified as such.. therefore the [precondition] is not a 
condition at all, in my opinion. It is also not testable as a condition.
Reworded, but the condition is whether "max" unsequenced message count has been reached.

[Jacques]: you are right: I interpreted the "if" below as an implementation option:
"...If the implementation defined limit for saved out-of-sequence messages is reached, 
then the Receiving MSH MUST indicate a delivery failure to the Sending MSH with errorCode set
 to DeliveryFailure and severity set to Error (see section 4.1.5). ..."


r2.2.6a: re-wording: (consolidated with r2.2.7a) 
[precondition]: sending message with MessageOrder element, which is first for a 
conversation ID 
[assertion]: REQUIRED: the sequenceNumber element must have value 0, 
and its Status attribute = "Reset". 

[MIKE2] - DONE


r2.2.7b: could be consolidated with r2.2.6b. 



[MIKE] - DONE ( also consolidated with r2.2.6a )


r2.2.8: (rewording) 
[precondition]: sending message with MessageOrder element, 
[assertion]: REQUIRED: the sequenceNumber element has Status attribute = "Reset" 
or "Continue". 


[MIKE2] - DONE 


r2.2.9: not correct as stated: (sounded like reset *must* be done if 
precondition is true.) 
[precondition]: when sending message with MessageOrder element, and Status 
attribute = "Reset" 
[assertion]: REQUIRED: all previous messages for this conversation must have 
been accounted for 
(Acks received). 
(Note: can only partially be verified... as I believe the reset is controlled by 
the MSH, 
not the app) 

[MIKE2] -- DONE



r2.2.10: we could restate this using precondition: 
[precondition]: when sending message with MessageOrder element, 
[assertion]: REQUIRED: no SyncReply element is present. 

[MIKE] - This is covered in "merged" r2.2.2

[Jacques]: You are right. 

[MIKE2] - I removed this requirement, because of the above


[precondition]: when sending message with SyncReply element, 
[assertion]: REQUIRED: no MessageOrder element is present. 

[MIKE2] - I added this ( the "reverse" of r2.2.2 ) as r2.2.10.2

[Jacques]: Is that one translated into r2.2.10.2 ? if yes, we should
not have "...AND No MessageOrder element is present " in the precondition,
as that should represent the Assertion of the test req.

[MIKE2] - You are right, this was an editing error.. the precondition has been removed

In fact, These two test reqs: r2.2.10.1 and r2.2.10.2 are not well written,
as their assertion is automatically implied by their precondition, it seems.
I believe r2.2.10.1 is subsumed by r2.2.2, if it is same as my previous r2.2.10 above.

[MIKE2] - r2.2.10.1 is subsumed by r2.2.2, and has been removed
r2.2.10.2 is an "reverse" assertion of r2.2.2 ( SyncReply present, then MessageOrder not present ), 
as opposed to ( MessageOrder present, SyncReply is not present in r2.2.2 ), so I believe that it is a valid test
requirement.
 

r2.2.11: "RECOMMENDED" instead of OPTIONAL ("should" in spec) 


[Jacques]: I still see "OPTIONAL" in r2.2.11 assertion...(should be "RECOMMENDED")

[MIKE2] - DONE - I missed that one.

r2.3: assume all these test reqs are moved to Level 3, review later... 

[MIKE2] - DONE - moved to level 3



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]


Powered by eList eXpress LLC