[OASIS Issue Tracker] (EBXMLMSG-91) Core Spec, section 5.2.2.9 (test service), clarify wording

[OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org>]

    [ https://issues.oasis-open.org/browse/EBXMLMSG-91?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=61718#comment-61718 ] 

Sander Fieten commented on EBXMLMSG-91:
---------------------------------------

If the MSH always accept messages with this service and action for any configured P-Mode it would allow to test the configuration, like the used certificates, of a specific P-Mode. Which can be very useful. 
However it also creates a challenge for the MSH because all P-Modes will share this Service and Action combination and it may be difficult to determine for which P-Mode the test is requested if there exist multiple P-Mode for the same pair of MSHs and the message or P-Modes don't include other identifying information (like P-Mode id or AgreementRef). 
Because the specification does not state how to handle this, it can be understood to refer to a specifically configured P-Mode for the test service. Question is whether this is okay or that we should add default behaviour in case the "test" message can not be mapped to a specific P-Mode.  

> Core Spec, section 5.2.2.9 (test service), clarify wording
> ----------------------------------------------------------
>
>                 Key: EBXMLMSG-91
>                 URL: https://issues.oasis-open.org/browse/EBXMLMSG-91
>             Project: OASIS ebXML Messaging Services TC
>          Issue Type: Improvement
>          Components: Core Spec
>            Reporter: Pim van der Eijk
>
> This section states "Such a value for the eb:Action element only indicates that the user message is sent for testing purposes and does not require any specific handling by the MSH".
> It is unclear what "[no] specific handling" means.  Some products and AS4 profiles assume the test service/action still needs a PMode configuration like any ebMS3 message, meaning that such tests may result in errors or receipts, but (at least) one vendor interprets it differently.



--
This message was sent by Atlassian JIRA
(v6.2.2#6258)