ebxml-iic message

Subject: Re: [ebxml-iic] 7/20/2003: Conformance Document Comments

From: "Michael Kass" <michael.kass@nist.gov>
To: "Monica J. Martin" <monica.martin@sun.com>,"ebXML IIC - main list \(E-mail\)" <ebxml-iic@lists.oasis-open.org>
Date: Mon, 21 Jul 2003 01:05:21 -0400

Monica,

    Thanks for the input.  My comments below:

ebMS 2.0 Test Coverage 22 July 2003

1. Title, correct to 2003 (now says 2002)



[MIKE] -= Changed date to title



2. Section 4, would it be logical to assume that the breakdown in test
requirements,

for example 2-30 for Message Packaging, etc. could help us establish
profiles?



[MIKE] - Yes.  Requirements are already grouped by functional area (
packaging,

SyncReply, Reliable Messaging, etc.)  Profiling can be done by reference to
particular

requirementIDs in particular sections of the document.





3. General: Patterns of sequences - Look at for example:

a. Descriptions

b. Header filter types



Could the test case grab at category and then extend? Send, construct,
correlate,

check and verify, for example.

What is different are the values that are inserted into the test cases
themselves?

If the patterns appear only to be reusable in the abstract and less so for
the executable,

perhaps this could help us validate the completeness of tests.  Test case is
not

complete unless - simply - it has a construct, start, process, end,
validate,

for example.



[MIKE] - The patterns are reusable in the executable test suite as well.  We
would have to

extend the existing test suite schema to reference previously defined Test
Steps through

ID reference.  Completeness of tests is already determined by schema
validation... i.e.

no Test Case is valid unless it has a send, construct, receive, filter,
verify/validate action.





4. Table 6, Section 5.1.2, Highlight in another color, delete or place in a
note

after the table, the references to parameters that aren't required for
conformance

testing. This could confuse the user.



[MIKE] - I agree that providing a parameter, but then saying it is not used
in the

conformance test suite is confusing.  This applies to two special
parameters:

"Confidentiality" and "Authentication".  I would suggest we simply remove
the note

about their "non-use" in this conformance test suite rather than
removing/highlighting them.

They may be used later if the test suite expands to cover more of the
specification in

the security area.  In the mean time, they can be given a value of "none" in
the MSH

configuration table.





5. General: At what point will be begin to discuss SMTP? Would we enter into

a collaboration with CECID or some of the Pacific players to do this? I
would

think they would be interested (ebMail).



[MIKE] - Tests (#70, #71, #128 and  #157), are the only four tests that
cannot be run in SMTP, so I would

think that approaching CECID regarding useing this test suite would be
valuable to them.





6. Have we assessed what conformance requirements we are not addressing in
the

ebMS 2.0 - perhaps we should have a coverage document that shows what is
being

covered by interoperabily and what is for conformance, so users may more
easily

understand the differences, and value, that each type of testing brings.



[MIKE] - Although it would help to "merge" interop and conformance testing
requirements

to give a complete list, I am not in favor of it because I feel doing so
creates an ambiguity

regarding what conformance testing is (spec driven) and is not
(interoperability driven).







Then, we can also determine requirements we are not addressing, and whether
that

is a function of the testability of the specification, the test limitations

of the framework, or we just haven't gotten that far yet (for example,
associated

with a profile model where we have selected the most often used
capabilities).





[MIKE] -  I think that the test coverage document ( see my attachment )
provides a good indicator of what

requirements have been addressed, or not addressed, and the reasons why.   I
think that

it would be valuable to come to an agreement within the IIC regarding what
conformance test

requirements fall under "MSH conformance testing" and which requirements are
considered

"application conformance testing".

I have tried to identify what I consider "application level" conformance
testing requirements that

can not be tested because the MSH does not control application-level message
content.







7. General, test coverage: Gaps in testing error handling.  Can we discuss
this as this

appears to be an important function? What category does this fit into from

item 6 above?

[MIKE] - I believe that error handling testing falls in to the confmance
testing (particluarly tests #54, #57, #58, #61, #62)
This can be addressed by writing more robust error handling test
requirements that exercise as many error conditions as possible)

----- Original Message ----- 
From: "Monica J. Martin" <monica.martin@sun.com>
To: "ebXML IIC - main list (E-mail)" <ebxml-iic@lists.oasis-open.org>
Sent: Sunday, July 20, 2003 8:40 PM
Subject: [ebxml-iic] 7/20/2003: Conformance Document Comments


> Comments on annotated test requirements, and conformance document
attached.
> Note, I've also included a few thoughts on our beginning discussion on
> patterns.
>
> Thanks.
>


----------------------------------------------------------------------------
----


> You may leave a Technical Committee at any time by visiting
http://www.oasis-open.org/apps/org/workgroup/ebxml-iic/members/leave_workgroup.php

Title: OASIS ebxml-iic TC -> Requirements

OASIS ebxml-iic TC: Conformance Test Case Coverage, 20 July 2003

Master Requirements File: ebXML Messaging Services 2.0

ID	Name	Specification Ref	Precondition	Requirement Level	Assertion	Test Coverage
req_id_1	Global Requirements for All Tests	ebMS-2#1.3
funreq_id_1	SchemaValidation	ebMS-2#1.3	(For each generated message)	REQUIRED	Supports all mandatory syntax and behavior defined in Core plus Additional Features	Not Tested - This broad requirement is tested individually by all other tests in the conformance test suite
req_id_2	PackagingSpecification	ebMS-2#2
funreq_id_2	GenerateConformantSOAPWithAttachMIMEHeaders	ebMS-2#2.1.2	(For each generated mesage, if it is multipart MIME OR if it is not text/xml)	REQUIRED	The primary SOAP message is carried in the root body part of the message.
funreq_id_3	GenerateConformantSOAPWithAttachMIMEHeaders	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
funreq_id_4	GenerateCorrectMessagePackageContent-Type	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".
funreq_id_5	GenerateContent-IDStartValues	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.
funreq_id_6	ProcessNon-MultipartMessages	ebMS-2#2.1.2	( For each received message, if the message is not multipart MIME)	REQUIRED	The MSH accepts the message.
funreq_id_7	ProcessMultipartNoPayloadMessages	ebMS-2#2.1.2	( For each received message, if the message is multipart MIME AND the message has no payload)	REQUIRED	The MSH accepts the message.
funreq_id_8	GenerateCorrectSOAPMessageContentType	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".
funreq_id_9	GenerateSpecificSOAPMessageCharacterSet	ebMS-2#2.1.3.1	(For each generated message)	REQUIRED	The MIME Content-Type charset header of each generated SOAP Message specifies the character set used to generate the message.	Not Tested - Test Hanesss does not define a way to determine actual encoding of message
funreq_id_10	GenerateSameEncodingAndCharacterSetValue	ebMS-2#2.1.3.1	(For each generated message, if both the MIME charset and SOAP message encoding declaration are present)	REQUIRED	They shall have the same value.
funreq_id_11	GenerateDefaultSOAPMessageCharacterSet	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.
funreq_id_12	GeneratePayloadContainer	ebMS-2#2.1.4	(For each generated message, if the Message Package contains an application payload)	RECOMMENDED	It should be enclosed in a Payload Container.
funreq_id_13	ProvideEmptyManifestAndPayloadIntegrity	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
funreq_id_14	ProvideManifestAndPayloadIntegrity	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
funreq_id_15	ProcessUnrecognizedMIMEHeaders	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.
funreq_id_16	GeneratePrologXMLDeclaration	ebMS-2#2	(For each generated message, if an XML Prolog is present in the SOAP message)	OPTIONAL	The Prolog contains an XML declaration.
funreq_id_17	GenerateXMLVersionInProlog	ebMS-2#2.2.1	(For each generated message, if the XML Prolog exists in the SOAP message)	REQUIRED	XML version is declared
funreq_id_19	GenerateCorrectExtensionElementNamespace	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"
funreq_id_20	GenerateCorrectEnvelopeSchemaLocation	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"
funreq_id_21	GenerateCorrectSOAPHeaderAndBodySchemaLocation	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"
funreq_id_22	GenerateCorrectSOAPHeaderNamespace	ebMS-2#2.3.4	(For each generated message)	REQUIRED	A SOAP Header element is namespace qualified as per the SOAP namespace declaration in the SOAP Envelope element with the namespace "http://schemas.xmlsoap.org/soap/envelope/" .
funreq_id_23	GenerateCorrectSOAPBodyNamespace	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 with the namespace "http://schemas.xmlsoap.org/soap/envelope/" .
funreq_id_24	GenerateMessageHeaderInSOAPHeader	ebMS-2#2.3.5.1	(For each generated message)	REQUIRED	A SOAP Header element always contains an ebXML MessageHeader element.
funreq_id_25	GenerateCorrectForeignElementNamespaces	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".
funreq_id_26	GenerateCorrectForeignElementNamespaces	ebMS-2#2.3.6	(For each received message)	OPTIONAL	The candidate MSH ignores the namespace-qualified #wildcard element
funreq_id_27	GenerateIdAttributeToExtensionElements	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).	Partially Tested - Only MessageHeader element tested
funreq_id_28	GenerateCorrectMessageHeaderVersion	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"
funreq_id_29	GenerateCorrectSOAPMustUnderstandNamespace	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).	Partially Tested - Only MessageHeader element tested
funreq_id_30	ProcessMustUnderstand	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.	Partially Tested - Only MessageHeader element tested
req_id_3	CoreExtensionElements	ebMS-2#3.1.1
funreq_id_31	GenerateUniquePartyId	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.	Not Tested - This is application level testing
funreq_id_32	ReportInconsistentPartyIdContent	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)
funreq_id_33	GenerateValidPartyIdContent	ebMS-2#3.1.1.1	(For each generated message, if generated PartyId contains a type attribute)	RECOMMENDED	Its value is a URI
funreq_id_34	GenerateValidPartyIdContent	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
funreq_id_35	ReportFailedCPAIDResolution	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).
funreq_id_36	ProvideConversationIdIntegrity	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.
funreq_id_38	ReportInconsistentServiceElementContent	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)
funreq_id_39	GenerateConsistentServiceElementContent	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
funreq_id_40	ReportUnrecognizedServiceAndOrAction	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).
funreq_id_41	ProvideRefToMessageIdIntegrity	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.
funreq_id_42	GenerateNoRefToMessageId	ebMS-2#3.1.6.3	(For each generated message, if there is no earlier related message )	REQUIRED	The RefToMessageId element is never present.
funreq_id_43	GenerateErrorRefToMessageId	ebMS-2#3.1.6.3	(For each generated message, if a previous message generated an error)	REQUIRED	The RefToMessageId element is always present with a value indicating the message in error.
funreq_id_44	ProcessTimeToLive	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).
funreq_id_45	GenerateValidUTCTime	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.
funreq_id_46	GenerateDistinctLangValuesForDescription	ebMS-2#3.1.8	(For each generated message)	RECOMMENDED	No two Description elements must have the same xml:lang attribute value	Not Tested - This is application level testing
funreq_id_47	GenerateNoPayloadOrApplicationDataInBodyOrManifest	ebMS-2#3.2	(For each generated message)	RECOMMENDED	No payload/application data is present in generated SOAP Body elements	Not Tested - Any XML content is allowed in a SOAP body, so no way to determine if application data is present
funreq_id_48	ReportNon-ExistentMIMEPartForManifestReference	ebMS-2#3.2.2	(For each received message, if 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).
funreq_id_49	ReportUnresolvableHREFInManifest	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)
funreq_id_50	GenerateResolvableHREFInManifest	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
funreq_id_51	ProcessUnreferencedPayloads	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.
req_id_4	ErrorHandling	ebMS-2#4.2
funreq_id_52	ProcessUpstreamSOAPFault	ebMS-2#4.2	(For each received message)	REQUIRED	The MSH can accept and process SOAP Fault values from a downstream SOAP processor.	Not Tested - Spec does not say how downstrream SOAP faults should be handled
funreq_id_53	GenerateCompliantSOAPFaults	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.	Not Tested - This is SOAP conformance testing, and specific SOAP fault generation by MSH is not defined in [ebMS]
funreq_id_54	GenerateWarnings	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.	Partially Tested - Not tested for all possible "warning" errors
funreq_id_55	ReportDataCommunicationErrors	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.	Not Tested - This Test Framework does not support HTTP or SMTP conformance testing
funreq_id_56	GenerateNoErrorList	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.	Not Tested - This is not a testable requirement as written in specification
funreq_id_57	ProvideErrorAndHighestSeverityIntegrity	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.	Partially Tested - Not tested for all possible ebXML errors
funreq_id_58	GenerateCorrectCodeContextValue	ebMS-2#4.2.3.2.2	(For each generated message)	REQUIRED	The codeContext attribute of any generated Error element is always a URI.	Partially Tested - Not tested for all possible ebXML errors
funreq_id_59	GenerateCorrectCodeContextNamespaceValue	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.
funreq_id_60	GenerateCorrectErrorSeverityValue	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.	Partially Tested - Not tested for all "warning" errors
funreq_id_61	ProvideXPointerAndErrorIntegrity	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.	Partially Tested - Only tests if XPointer is returned, not its value
funreq_id_62	GenerateReferencedMIMEPartErrorsWithCID	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.	Not Tested - This is "application level" testing
funreq_id_63	GenerateErrorCodesUsingLongDescription	ebMS-2#4.2.3.4	(For each generated message)	REQUIRED	The "Short Description" text for each error code provided by the Message Service Specification does not appear in any relevant Error element.	Not Tested - Spec never defines what "should" be in the Description
funreq_id_64	ReportErrorToMessageOrigin	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 determinedAND · 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.
funreq_id_65	ProcessWithNoErrorReportLocation	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.
funreq_id_66	ProcessCPPAErrorURI	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.
funreq_id_67	ProcessWithNoCPPAErrorURIPresent	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.
funreq_id_68	GenerateServiceAndActionForErrorsFromIndependentMessage	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
funreq_id_69	ProcessErrorListWhereHighestSeverityEqualsError	ebMS-2#4.2.4.1	(For each received message, if the message generates an ErrorList element with highestSeverity set to Error)	RECOMMENDED	The error is: Logged; Resolved by other means; and, No further action is taken.
req_id_5	SynchReply	ebMS-24.3
funreq_id_70	ProcessSyncReply	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.
funreq_id_71	ReportMessageAndCPASyncReplyConflict	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).
funreq_id_72	GenerateAgreeingMessageAndCPASyncReply	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.
req_id_6	ReliableMsg	ebMS-2#6
funreq_id_73	ResendToAckReceived	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
funreq_id_74	ResendToRetriesExceeded	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.
funreq_id_75	ResumeAfterAckReceived	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 behaves as if the message was successfully delivered.
funreq_id_76	NotifyDeliveryFailureOnExceed	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
funreq_id_77	PersistReliableSentMsg	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 processsed as if the interruption had not occurred.	Not Tested - System interrupts are not possible using existing framework
funreq_id_78	PersistReliableSentMsgNoAck	ebMS-2#6.1	(For each reliably sent message, after a system interruption AND no Ack was received prior to the interruptionAND the system recovers within the TimeToLive window.)	REQUIRED	The message is kept in persistent storage and processsed as if the interruption had not occurred.	Not Tested -System interrupts are not possible using existing framework
funreq_id_79	PersistReliableSentMsgAfterInterrupt	ebMS-2#6.1	(For each reliably sent message, after a system interruption)	REQUIRED	The message is kept in persistent storage.	Not Tested -System interrupts are not possible using existing framework
funreq_id_80	PersistReliableReceivedMsgAfterInterrupt	ebMS-2#6.1	(For each reliably received message, after a system interruption AND the system recovers within the TimeToLive window.)	REQUIRED	The message processsed as if the interruption had not occurred.	Not Tested -System interrupts are not possible using existing framework
funreq_id_81	PersistReliableReceivedMsgNoAck	ebMS-2#6.1	(For each reliably received message, after a system interruption AND no Ack was sent prior to the interruptionAND the system recovers within the TimeToLive window.)	REQUIRED	The message is kept in persistent storage and processsed as if the interruption had not occurred.	Not Tested -System interrupts are not possible using existing framework
funreq_id_82	PersistReliableReceivedMsg	ebMS-2#6.1	(For each reliably received message, after a system interruption)	REQUIRED	The message is kept in persistent storage.	Not Tested -System interrupts are not possible using existing framework
funreq_id_83	PersistReliableSentMsgAfterSystemFailure	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 occurred.	Not Tested -System interrupts are not possible using existing framework
funreq_id_84	PersistReliableSentMsgAfterSystemFailureAndNoAck	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 occurred.	Not Tested -System interrupts are not possible using existing framework
funreq_id_85	PersistReliableReceivedMsg	ebMS-2#6.1	(For each reliably received message)	REQUIRED	The complete message is kept in persistent storage.	Not Tested -Examination of persistent store not possible with with this framework
funreq_id_86	PersistReceivedMsgID	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.	Not Tested -Examination of persistent store not possible with with this framework
funreq_id_87	PersistRecdMsg	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.	Not Tested -Examination of persistent store not possible with with this framework
funreq_id_88	PersistReceivedMsgTimestamp	ebMS-2#6.1	(For each reliably received message)	RECOMMENDED	The time at which a message is received is recorded in persistent storage.	Not Tested -Examination of persistent store not possible with with this framework
funreq_id_89	PersistResponseMsg	ebMS-2#6.1	(For each reliably received message)	RECOMMENDED	Each response message is stored in its entirety in persistent storage.	Not Tested -Examination of persistent store not possible with with this framework
funreq_id_90	TargetAckRequestedToOrNextMSH	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
funreq_id_91	SetAckRequestedUnSigned	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.
funreq_id_92	SetSignedAttributeAfterVerifyReceivingMSHAckSupport	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.
funreq_id_93	SetSignedAttributeAfterVerifyReceivingMSHAckSupport	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 = Warning .	Partially Tested - Only tested for sha-1 signature altorithm
funreq_id_94	SetSignedAttributeAfterVerifyReceivingMSHAckSupport	ebMS-2#6.3.1.2	(For each received message with an AckRequested with the Signed attribute set to True AND and NOT consistent with the CPPA AND requirementType="required"> if the Receiving MSH supports signed acknowledgment messages of the type requested)	REQUIRED	The MSH generates an Error of type Inconsistent and an Error severity = Error .
funreq_id_95	SendAckToFromParty	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.
funreq_id_96	GenererateAckWithNoPayloadAndNoAckRequested	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.
funreq_id_97	ReportErrorWithoutAckRequeseted	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.	Partially Tested - Not tested for all possible errors
funreq_id_98	SpecifyNoSOAPActorToPartyAck	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.
funreq_id_99	SpecifySOAPActorToPartyAck	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.
funreq_id_100	GenerateAckMsgTimestamp	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.
funreq_id_101	GenerateAckUsingMsgIDInRefToMessageID	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.
funreq_id_102	IdentifyPartyWithAckFromElement	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.
funreq_id_103	IdentifyPartyWithoutAckFromElement	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.
funreq_id_104	UseSignedAckMustContainRef	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.
funreq_id_105	QualifyRefElementByNamespace	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.
funreq_id_106	NotifyClientOfAckDelivery	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.	This is "application level" testing, not testable in existing framework
funreq_id_107	IgnoreDuplicateRefToMessageID	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.
funreq_id_108	SetAckServiceActionValues	ebMS-#6.3.2.7	(For each generated Acknowledgment message, If no errors were detected in the message receivedAND 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
funreq_id_109	SetDuplicateEliminationAlways	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.
funreq_id_110	SetDuplicateEliminationtoNever	ebMS-#6.4.1	(For each generated message, if the CPPA DuplicateElimination element = "never")	REQUIRED	The DuplicateElimination element is not present.
funreq_id_111	SetDuplicateEliminationPerMessage	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.
funreq_id_112	ReceiveDuplicateEliminationAlways	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.
funreq_id_113	ReceiveDuplicateEliminationtoNever	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.
funreq_id_114	PersistMsgWithDuplicateElimination	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.
funreq_id_115	PersistMsgWithDuplicateEliminationAndInterruption	ebMS-#6.4.1	(For each reliably sent message, if Duplication element is present on an inbound messageAND the system recovers from an interruption within the TimeToLive window.)	REQUIRED	The message is presented to the To Party Application at-most-once.	Test Framework does not support system interruptions
funreq_id_116	ReportErrorIfDuplicateEliminationUnsupported	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.
funreq_id_117	ReportErrorDuplicateEliminationMsgToCPPA	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.
funreq_id_118	ReportErrorDuplicateEliminationMsgToCPPA	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.
funreq_id_119	RedeliveryMsgbyRetries	ebMS-#6.4.3	(For each generated message, if the message that requested acknowledgment is not acknowledged within the RetryInterval)	OPTIONAL	The message is redelivered up to a maximum number of retries as specified by the Retries parameter in the relevent CPA.
funreq_id_120	RetryIntervalMinLapseTime	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..
funreq_id_121	SetTimeToLive	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)
funreq_id_122	PersistSentMsgLength	ebMS-#6.4.6	(For each reliably received message, if the PersistDuration parameter is present in the CPPAAND DuplicationElimination element is present in the messsage AND the same message is received again by the MSH before PersistDuration expires)	REQUIRED	The message is presented only once to the application.
funreq_id_123	PersistSentMsgLength	ebMS-#6.4.6	(For each reliably received message, if the PersistDuration parameter is present in the CPPAAND AckRequested element is present in the messsage AND the same message is received again by the MSH before PersistDuration expires)	REQUIRED	An Acknowledgement message is sent back to the sending MSH.
funreq_id_124	SendNoMsgWithLapsePersistDurationMsgID	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.
funreq_id_125	ReptDeliveryFailureIfPersistDurationExpired	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.
funreq_id_126	TimestampPersistDurationGreaterThanTimeToLive	ebMS-#6.4.4	(For each reliably sent message)	REQUIRED	For each reliably sent message, the message satisfies the equation: PersistDuration > TimeStamp + TimeToLive.
funreq_id_127	IgnoreSyncReplyMode	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.
funreq_id_128	ReturnSyncReplyElementInResponsePayload	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.
funreq_id_129	ReturnSyncReplyResponsePayload	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.
funreq_id_130	GenerateAckWhenAckRequested	ebMS-#6.5.3	(For each reliably received message, if the AckRequested element that has a SOAP actor URI targeting the MSH)	REQUIRED	An Acknowledgement Message is generated with RefToMessageId having the MessageId value of the message being acknowledged.
funreq_id_131	PersistAckWithOriginalMsg	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.
funreq_id_132	DeliverAckWithResponse	ebMS-#6.5.3	(For each Acknowledgment message)	OPTIONAL	The message can be delivered as part of the normal response to the received message.
funreq_id_133	DeliverSeperatelAckServiceAndAction	ebMS-#6.5.3	(For each Acknowledgment message, if the Acknowledgment element is sent seperately from the response to the received message)	REQUIRED	The Service element value is "urn:oasis:names:tc:ebxml-msg:service" and the Action element value is "Acknowledgment"
funreq_id_134	DeliverSeperateAckRefToMessageId	ebMS-#6.5.3	(For each Acknowledgment message, if the Acknowledgment element is sent seperately from the response to the received message)	REQUIRED	The RefToMessageId element is set to the MessageId of the message received.
funreq_id_135	DeliverSeperateAckFromValue	ebMS-#6.5.3	(For each Acknowledgment message, if the Acknowledgment element is sent seperately from the response to the received message)	OPTIONAL	The From element MAY be populated with the To element extracted from the message received and all child elements from the To element received SHOULD be included in this From element.
funreq_id_136	DeliverSeperateAckToValue	ebMS-#6.5.3	(For each Acknowledgment message, if the Acknowledgment element is sent seperately from the response to the received message)	OPTIONAL	The To element MAY be populated with the From element extracted from the message received and all child elements from the From element received SHOULD be included in this To element.
funreq_id_137	AckNotReceivedResend	ebMS-#6.5.3	(For each generated message containing an AckRequested element, AND if an Acknowledgment message has not been received AND the time specified in the RegryInterval parameter has passed since the last message was sentAND the message has been resent less than the number of times specified in the Retries parameter)	REQUIRED	The Sending MSH resends the original message.
funreq_id_138	AckNotReceivedMaxRetriesExceeded	ebMS-#6.5.3	(For each generated message containing an AckRequested element, AND an Acknowledgment message has not been received after the maximum number of retries)	REQUIRED	The Sending MSH notifies the application and/or system administrator of the failure to receive an Acknowledgment Message.	Not Tested - The Test Framework does not support caputre of system administrator notifications.
funreq_id_139	ResendMsgOnCommError	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.	Not Tested - The Test Framework does not support generation of protocol errors
funreq_id_140	SendOriginalAckOnDuplicateMsg	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.
funreq_id_141	GenerateSyncResponseOnDuplicateMsg	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 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.
funreq_id_142	GenerateAckMsgOnNonSyncDuplicateMsg	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 set to none)	OPTIONAL	A new Acknowledgment Message is generated and sent.
funreq_id_143	ReportErrorOnMsgWithAckReqNoTransmit	ebMS-#6.5.7	(For each reliably received message, if the message contains an AckRequested elementAND 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.
funreq_id_144	GenerateWarningErrorOnMsgWithAckRequested	ebMS-#6.5.7	(For each reliably received message, if the message contains an AckRequested elementAND 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.
funreq_id_145	NotifyFailureByAlternateMeans	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.	Not Tested - This is an untestable requirement as written in the specification
req_id_7	MsgOrder	ebMS-2#9
funreq_id_146	EnableMsgOrderWithReliableMsg	ebMS-2#9	(For each received message, if the message contains a MessageOrder element)	REQUIRED	The DuplicateElimination is present and SyncReply element is not present	Not Tested -This is "application level" testing
funreq_id_147	ProcessSequenceMsg	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.
funreq_id_148	PassOrderedMsgToApplication	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.	Not Tested -Not testable in this framework
funreq_id_149	GenerateDeliveryFailureOnOutOfSequMsg	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.	Not Tested -Specification abmbiguity prohibits testing
funreq_id_150	UseZeroSequenceNoForFirstOrderedMsgForConversation	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."
funreq_id_151	UseStatusResetForFirstOrderedMsgForConversation	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 value is set to Reset"
funreq_id_152	UseZeroSequenceNoForFirstOrderedMsgAfterReset	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.
funreq_id_153	UseZeroSequenceNoAndStatusResetForFirstOrderedMsgAfterReset	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 status value is set to Reset
funreq_id_154	UseZeroSequenceNoAndSatusContinueForFirstOrderedMsgAfterWrap	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 and a status Value of Continue	Not Tested -Number of messages required precludes testing
funreq_id_155	ResetMsgSeqForConversation	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 sent messages for this conversation must have been accounted for.	Not Tested -This is application testing
funreq_id_156	SyncReplyMsgNotIncludeMsgOrder	ebMS-2#9.2	(For each generated message, if the message contains a SyncReply element)	REQUIRED	A MessageOrder element is never included in the same message as a SyncReply element.	Not Tested -This is application testing
funreq_id_157	ReportErrorMsgOrderSyncReply	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.
req_id_8	SecurityAndCommunicationChannels	ebMS-2#4
funreq_id_158	SignatureElementIsChildOfSoapHeader	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.
funreq_id_159	SignatureIsNamespaceQualified	ebMS-2#4.1	(For each generated message, when one or more Signature elements is present)	REQUIRED	It is namespace qualified witih http://www.w3.org/2000/09/xmldsig#"
funreq_id_160	SignatureConformsToXMLDSIG	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 available at http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/.
funreq_id_161	AttributeSignatureElement	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.	Not Tested - This is application-level testing
funreq_id_162	ApplySecurityBasedOnTransportOfCPA	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 ""
funreq_id_163	GenerateSignToXMLDSIG	ebMS-2#4.1.3	(For each signed message)	REQUIRED	Digital signatures are generated and rendered according the XML Signature specification (XMLDSIG).	Partially Tested - for suggested DSIG parameters only
funreq_id_164	GenerateSignChildElements	ebMS-2#4.1.3	(For each signed message)	REQUIRED	The SignedInfo element has a CanonicalizationMethod, SignatureMethod and one or more Reference elements.
funreq_id_165	GenerateSignAlgorithmAttribute	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.
funreq_id_166	SignCanonicalMethod	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"
funreq_id_167	SignatureMethodAlgorithmAttribute	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"
funreq_id_168	SupportDSA-SHA1SignAlgorithm	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.
funreq_id_169	AddOptionalReferenceAttribute	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.
funreq_id_170	IncludeMandatoryTransformElementToEnvelopedSign	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".
funreq_id_171	GenerateMandatoryTransformWithExcludeSOAPActor	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.
funreq_id_172	CanonicalizationTransformElementAlgorithmAttribute	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".
funreq_id_173	XMLSignReferenceURIForPayload	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.
funreq_id_174	MapSignReferenceURIToManifestPayload	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.
funreq_id_175	GenerateSignPriorToTransferEncoding	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.	Not Tested - Framework cannot verify signing before encoding
funreq_id_176	SignAckReferenceElementList	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.
funreq_id_177	AuthenticatePartyByCommunicationChannel	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).	Not Tested - Not supported by test framework
funreq_id_178	ProvideMsgContentDataIntegrityByCommunicationChannel	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).	Not Tested - Not supported by test framework
funreq_id_179	SignMsgPriorToEncryption	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)	OPTIONAL	Signing takes place prior to encryption.	Not Tested - Framework cannot verify signing before encryption
funreq_id_180	ProvideMsgContentDataConfidentialityByCommunicationChannel	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).	Not Tested - Framework cannot verify message confidentiality
funreq_id_181	AuthorizeMsgWithBilateralAuthenticationByNetworkProtocol	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).	Not Tested - Framework cannot verify authorization
req_id_9	MessageStatusService	ebMS-2#7
funreq_id_182	GenerateStatusResponseWithReliableMessaging	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.
funreq_id_183	GenerateStatusResponseWithoutReliableMessaging	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.
funreq_id_184	ReportUnsupportedService	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".
funreq_id_185	GenerateValidStatusRequestMessage	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.
funreq_id_186	ProcessUnauthorizedStatusRequest	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 a party deemed to be unauthorised)	OPTIONAL	A response is sent with the messageStatus attribute set to "UnAuthorized".
funreq_id_187	ProvideRefToMessageIdAndMessageIdIntegrity	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 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.
funreq_id_188	SetTimestampRecognizedAndAuthorized	ebMS-2#7.3.2	(For each received message, if the message contains a StatusRequest element AND the StatusRequest child RefToMessageId element value is recognized)	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.
funreq_id_189	SetTimestampNotRecognized	ebMS-2#7.3.2	(For each received message, if the message contains a StatusRequest element AND the StatusRequest child RefToMessageId element value is not recognized)	REQUIRED	The Timestamp child element of the StatusResponse element is not present in the response message.
funreq_id_190	SetTimestampNotAuthorized	ebMS-2#7.3.2	(For each received message, if the message contains a StatusRequest element AND the StatusRequest child RefToMessageId element value is not authorized.)	REQUIRED	The Timestamp child element of the StatusResponse element is not present in the response message.
funreq_id_191	GenerateUnauthorizedMessageStatus	ebMS-2#7.3.3	(For each received message, if the message contains a StatusRequest element AND the message is recognized)	REQUIRED	The messageStatus attribute in the StatusResponse element has a value of 'UnAuthorized'.
funreq_id_192	GenerateNotRecognizedMessageStatus	ebMS-2#7.3.3	(For each received message, if the message contains a StatusRequest element AND the StatusRequest child RefToMessageId element value is not recognized)	REQUIRED	The messageStatus attribute in the StatusResponse element has a value of 'NotRecognized'.
funreq_id_193	GenerateReceivedMessageStatus	ebMS-2#7.3.3	(For each received message, if the message contains a StatusRequest element AND the StatusRequest child RefToMessageId element value is recognized AND the RefToMessageId element value is recognized and not yet processed)	REQUIRED	The messageStatus attribute in the StatusResponse element has a value of 'Received'.	Not Tested - This is application-level testing
funreq_id_194	GenerateProcessedMessageStatus	ebMS-2#7.3.3	(For each received message, if the message contains a StatusRequest element AND the StatusRequest child RefToMessageId element value is recognized AND the RefToMessageId element value is recognized and processed)	REQUIRED	The messageStatus attribute in the StatusResponse element has a value of 'Processed'.	Not Tested - This is application-level testing
funreq_id_195	GenerateReceivedMessageStatus	ebMS-2#7.3.3	(For each received message, if the message contains a StatusRequest element AND the StatusRequest child RefToMessageId element value is recognized 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.
req_id_10	PingService	ebMS-2#8
funreq_id_196	ReportServiceNotSupported	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".
funreq_id_197	GenerateValidPingMessageStructure	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 ( if present ) are configured as specified in the Message Service Specification.	Not Tested = This is application level testing
funreq_id_198	GeneratePongResponse	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 ANDThe Ping request is occurring under normally expected conditions, and 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 ( if present ) are configured as specified in the Message Service Specification.
req_id_11	MultiHopModule	ebMS-2#10
funreq_id_199	SetMultiHopIntermediaryNextMSH	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).
funreq_id_200	RemoveIntermediaryAckRequested	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.
funreq_id_201	InsertIntermediaryAckRequested	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.
funreq_id_202	GenerateSingleAckRequestedForNextMSH	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.
funreq_id_203	SyncReplyNoAckRequestedForNextMSH	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.
funreq_id_204	GenerateErrorWithSyncReplyAckRequested	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".
funreq_id_205	GenerateIntermediaryAckMsgIfNoSyncReply	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.
funreq_id_206	GenerateAckBasedOnActor	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
funreq_id_207	GenerateIntermediaryAckMsgAtComplete	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.
funreq_id_208	GenerateIntermediarySignedAck	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).
funreq_id_209	NoMsgOrderProcessForIntermediary	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.
funreq_id_210	RequestDownstreamAck	ebMS-2#6.3.1	(For a downstream ( Next ) processor , if an AckRequested element is received)	REQUIRED	An acknowledgment is returned.
funreq_id_211	GenerateMultipleAckRequested	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.	Not tested - Application level testing
funreq_id_212	TargetAtMostOneAckNextMSH	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.	Not tested - Application level testing
funreq_id_213	TargetAtMostOneAckToPartyMSH	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.	Not tested - Application level testing
funreq_id_214	IgnoreIntermediaryDuplicates	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.
funreq_id_215	ControlIntermediaryMSHHandling	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.
funreq_id_216	TargetAckRequestedToOrNextMSH	ebMS-2#6.3.1.1	(For each generated multi-hop message)	REQUIRED	The AckRequested element is targeted at the NextMSH

References:
- [ebxml-iic] 7/20/2003: Conformance Document Comments
  - From: "Monica J. Martin" <monica.martin@sun.com>