← Prev in month
← Prev in thread
Next in thread →
Next in month →
[ebxml-iic-conform] RE: status of iic conformance document review
Rik:
That
is good news. But I believe you used the wrong mail list
here:
guess
you wanted to post to ebxml-iic-msg, instead of
ebxml-msg ?
I am
correcting that. In fact, as we are shifting to new sublists, I
am
forwarding this for: ebxml-iic-conform, which should be
the list we
use for every conformance-related
topics.
Just make
sure you are using the latest version of the test
reqs:
Level
1 Test Reqs, published on 6/21
Level
2 Test Reqs, latest version 6/30
(realized Mike did send Level 2 only to the conf subgroup, so here it is
attached,
for
review from all)
Level
3 has not been yet reviewed.
Notes:
1-
These notions of Levels should not be given much meaning
here.
In
fact, we'll consolidate all these Test Reqs in a unique "master" Test Reqs
file.
They
will remain organized by spec modules, but no trace of any
conformance
level
or profile in the master file. Profiles or levels will be defined in separate
files
that
will refer to the master file.
2- The
structure of Test Requirement items (precondition/assertion) is explained
in
the
"ebXMLTestFramework.doc" draft currently published on our OASIS IIC
page.
(see
section 4.1).
3- The
"coverage" value associated with each test req item will need revision.
In
fact, we are thinking associating it rather with the spec itself (i.e. for each
spec
feature, we evaluate how much it is covered by our test
reqs.)
See
explanation in ebXMLTestFramework.doc, section 4.3.
4-
This is precisely where we need help from someone expert on the MS
spec:
Going
through each spec feature (at document sub-section granularity), we
need
to
tell how much/well it is covered by our Test Reqs. Note that a single feature
may
map to
more than one test req item, that's why we don't want to associate
this
value
to the test req itself, but to the spec section. So we need to
produce
a
document made of a list of elements such as:
<spec subsection #1.2.3> <list of test req item # it maps
to><degree of coverage>
<spec subsection #4.5.6> <list of test req item # it maps
to><degree of coverage>
...
You
can probably help us here...
Regards,
jacques
-----Original Message-----
From: Rik Drummond
[mailto:]
Sent: Wednesday, July 03, 2002 8:28
AM
To:
Subject: [ebxml-msg]
status of iic conformance document review
I should have the
conformance document for ebXML ms done early next week. Best regards, rik
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 is DeliveryFailure/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 from the Sending MSH within the conversation
)
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
AND
The status element is not set to "Reset"
)
REQUIRED:The status is set to "Continue".
r2.2.9
ResetMsgSeqForConversation
full
ebMS-2#9.1.1
(
For each received message, if the message contains a MessageOrder element
AND
When a node is acting as the Sending MSH
AND
When the status attribute is set to "Reset"
AND
When all previously sent messages have been accounted for
)
REQUIRED:The SequenceNumber is reset for a conversation.
r2.2.10.1
SyncReplyMsgNotIncludeMsgOrder
full
ebMS-2#9.2
(
For each received message, if the message contains a MessageOrder element
AND
No SyncReply element is present
)
REQUIRED:A MessageOrder element is never included in the same message as a SyncReply element.
r2.2.10.2
SyncReplyMsgNotIncludeMsgOrder
full
ebMS-2#9.2
(
For each received message, if the message does contains a SyncReply element
AND
No MessageOrder element is present
)
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
)
OPTIONAL:An error is reported. The error is Inconsistent/Error.
r2.3
MultiHopModule
ebMS-2#10
r2.3.1
SetMultiHopIntermediaryNextMSH
full
ebMS-2#10.1
OPTIONAL:Multi-hop reliable messaging can be used between intermediary MSH nodes by applying the AckRequested and Acknowledgment elements
with the SOAP actor attribute set to NextMSH (urn:oasis:names:tc:ebxml-msg:actor:nextMSH).
r2.3.2
RemoveIntermediaryAckRequested
full
ebMS-2#10.1.1
(
When a node acts as an intermediary
)
REQUIRED:The node removes any AckRequested element with a SOAP actor attribute of NextMSH.
r2.3.3
InsertIntermediaryAckRequested
full
ebMS-2#10.1.1
(
When a node acts as an intermediary
)
OPTIONAL:The node can insert a single AckRequested element with a SOAP actor attribute of NextMSH.
r2.3.4
GenerateSingleAckRequestedForNextMSH
full
ebMS-2#10.1.1
REQUIRED:There are no situations in which two AckRequested elements are generated in the same message with a SOAP actor attribute value
targetting the NextMSH.
r2.3.5
SyncReplyNoAckRequestedForNextMSH
full
ebMS-2#10.1.1
(
If a SyncReply element is present in a message
)
REQUIRED:An AckRequested element with SOAP actor attribute targetting the NextMSH is never included.
r2.3.6
ReportErrorWithSyncReplyAckRequested
full
ebMS-2#10.1.1
(
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. The error is Inconsistent/Error.
r2.3.7
GenerateIntermediaryAckMsgIfNoSyncReply
full
ebMS-2#10.1.1
(
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.
r2.3.8
GenerateAckBasedBasedOnActor
full
ebMS-2#10.1.3
(
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.
r2.3.9
GenerateIntermediaryAckMsgAtComplete
partial
ebMS-2#10.1.3
REQUIRED:A reliable message received by an MSH node in the role of intermediary is not acknowledged until the message is both persisted
and delivered to the Next MSH.
r2.3.10
GenerateIntermediarySignedAck
full
ebMS-2#10.1.4
(
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).
r2.3.11
NoMsgOrderProcessForIntermediary
full
ebMS-2#10.2
(
When the MSH acts in the role of intermediary
)
REQUIRED:The MSH does not attempt to participate in Message Order processing.
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).
← Prev in month
← Prev in thread
Next in thread →
Next in month →