-
Type:
Improvement
-
Status: New
-
Priority:
Major
-
Resolution: Unresolved
-
Component/s: Core Spec
-
Labels:None
-
Proposal:
This relates to issues EBXML-MSG-65 (PMode ID) and EBXML-MSG-48 (P-Mode search).
If a messages has no AgreementRef, should the receiving MSH match it only to PModes with a specified AgreementRef or to all PModes (including ones that have a value)?
The optionality of the element refers to the optionality of the element in the eb:Messaging section.
For outgoing messages, section 4.3 states that if the PMode has no AgreementRef and it is not set in any other way, AgreementRef is omitted, but the reverse does not seem to be mandated (i.e. if there is an AgreementRef in PMode, it is not mandated that it has to be included). So for an incoming message, it cannot be assumed that absence of AgreementRef means the PMode parameter has no set value. So this would mean that if the element is not in the received message, it should be matched against all PModes, whether or not they have an AgreementRef parameter.
But then the next question is then what is to happen if there are multiple PModes that only differ on a value for AgreementRef for a combination of From/To/Service/... headers (i.e. these headers aren't enough to disambiguate the PMode) but may differ on other parameters (e.g. the certificates used, e.g. where AgreementRef is used for certificate rollover). It's not practical to have to consider multiple PModes. Therefore I think it's acceptable for an application to impose some practical constraints e.g.
1) require this lookup to return just one PMode (as in https://issues.oasis-open.org/browse/EBXMLMSG-48?jql=project%20%3D%20EBXMLMSG)
2) require the AgreementRef to be present in all incoming messages where for a combination of <FromPartyID, FromPartyIDType, ToPartyID, ToPartyIDType,Service, ServiceType, Action> there are multiple PModes.
But I think it's acceptable to more drastically constrain the lookup:
3) require AgreementRef to be present if it is a PMode parameter. And then our PMode search could be constrained to those PModes that have this parameter set, if the incoming message has the element. For messages that don't have AgreementRef in the header, it is matched only againt PModes that don't have the corresponding parameter set. Appendix D.3.1 has a requirement like this for PMode.ID.