[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=61799#comment-61799 ] 

Pim van der Eijk commented on EBXMLMSG-91:
------------------------------------------

This relates to the "PMode Inference" topic on which we have https://issues.oasis-open.org/browse/EBXMLMSG-48 and https://issues.oasis-open.org/browse/EBXMLMSG-68.    For the test service, an R-MSH could have PModes for all its communication partners, as the main practical use of it would be to check correct deployment of certificates, firewall configurations etc.    The PMode to apply could be retrieved if the PMode search takes From/PartyID into account, and AgreementRef to support different configurations with the same partner.  I think there are enough other headers (including mandatory headers) in a test service message to enable selection of the correct PMode, if multiple PModes are deployed.

I do think that it must be possible to configure PModes for test service messages, and propose that we clarify this in the core specification.  There are AS4 Usage Profiles that define specific behaviour for all AS4 messages (e.g. requiring all to be signed and acknowledged), and having a test service that behaves differently is not expected and not desired.

Whether or not an MSH supports the test service in situations where no PMode can be found could still be left to implementations (or to configuration).  It can be considered a policy issue, just as supporting ICMP ping is.  An MSH can have some default PMode or make some intelligent guesses.  Or some default non-ebMS3 response (e.g. an HTTP return code) could be generated.  It does not seem to be specific to the Ping service, there are other situations where an MSH may want to dynamically construct a PMode.   This has no impact on the specifications, which just assume the PMode is there.








> 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)