[OASIS Issue Tracker] (EBXMLMSG-68) AgreementRef

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

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

Sander Fieten commented on EBXMLMSG-68:
---------------------------------------

I assume section 4.3 should be read as a whole, i.e. it describes a *set* of default values and not individual defaults. Regardless of this I think it is correct to assume that the eb:AgreementRef element is absent when the PMode.Agreement is absent/empty and there is no value specified when the message is submitted to the MSH.

There is indeed no explicit MUST defined for including the eb:AgreementRef element when the PMode.Agreement parameter is set, but from the text in D.3.1 "maps to eb:AgreementRef in message header" I assume it the should be there. 

So I agree with the first sentence of statement 3 above.

Assuming that P-Mode lookup is implementation specific I would say that statement 1 and 2 are more recommendations than requirements.

> AgreementRef
> ------------
>
>                 Key: EBXMLMSG-68
>                 URL: https://issues.oasis-open.org/browse/EBXMLMSG-68
>             Project: OASIS ebXML Messaging Services TC
>          Issue Type: Improvement
>          Components: Core Spec
>            Reporter: Pim van der Eijk
>
> 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.  



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