[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [ebxml-msg] [OASIS Issue Tracker] (EBXMLMSG-65) PMode.ID
Hi Pim My take at this inline On 05 Jan 2015, at 17:30 , Pim van der Eijk <pvde@sonnenglanz.net> wrote: > > Hi, > > At the November call, we decided that implementers would comment how they implemented PMode.ID. > Could you please add your responses as comments so we can close them? > > This is about three question asked in https://lists.oasis-open.org/archives/ebxml-msg/201410/msg00007.html: > > My interpretation (from the spec and discussions) is that, "support by an MSH" means that the MSH can have PModes with an ID, and if a PMode has an "ID", the "support by an MSH" means that the sending MSH MUST include it with outgoing messages, and a receiving MSH MUST use it to retrieve a specific configuration. So the required support in AS4 would requires the ability to attach an identifier to a PMode. > > 1) Do you agree with this interpretation? Section 5.2.2.7 of the core spec it states the following '@pmode: This OPTIONAL (agreementref) attribute allows for explicit association of a message with a P-Mode. When used, its value contains the PMode.ID parameter.’ My interpretation on this is that if included in a received message then the receiving MSH MUST use it to retrieve a specific configuration. Note that other parameters such as initiator/responder and/or agreementref not matching may still result in rejecting the incoming message with an error such as the p-mode mismatch error (EBMS:0010)… I would not interpret the above as meaning that if a p-mode on a receiving MSH has an id but an incoming message does not have agreementref@pmode (p-mode id) set that an incoming message must be rejected. Other p-mode parameters such as agreementref and service/action may be matched on such an incoming message to a p-mode with an id. I think that different implementations may handle things differently here and that parties may need to come to an agreement on how things should be handled. > 2) If a sender does not include an ID in a message, should the receiving MSH match it against PModes that do not have an ID only, or to all PModes (some that have, and some that do not have a PMode ID) ? If an ID is not present in an incoming message then implementations of receiving MSHs may or may not attempt to match such an incoming message to any configured p-mode with or without an ID using other p-mode parameters including service, action and agreement. So implementation specific imo. > > 3) If a sender includes an ID in a message, and the receiving MSH does not have a PMode with this ID, should it return an error or should it attempt to match the message to PModes without ID (i.e. ignore the ID) Following on from my interpretation of 5.2.2.7 as above, a receiving MSH should return an error. > > Thanks, > > Pim > > -------- Forwarded Message -------- > Subject: [ebxml-msg] [OASIS Issue Tracker] (EBXMLMSG-65) PMode.ID > Date: Sun, 9 Nov 2014 12:14:54 +0000 (UTC) > From: OASIS Issues Tracker <workgroup_mailer@lists.oasis-open.org> > To: ebxml-msg@lists.oasis-open.org > > Pim van der Eijk created EBXMLMSG-65: > ---------------------------------------- > > Summary: PMode.ID > Key: EBXMLMSG-65 > URL: > https://issues.oasis-open.org/browse/EBXMLMSG-65 > > Project: OASIS ebXML Messaging Services TC > Issue Type: Improvement > Reporter: Pim van der Eijk > > > As discussed in the call, I add a JIRA issue for PMode.ID. > > People with implementations of AS4, please add a comment on how you implemented it and handle the three situations and if it matches the interpretation below. > > The idea is to add some clarification to the spec. > > > ___ > > Reading in the history I see that on March 2011 it was made “required” in AS4: > > “2.1.3.1 and 2.2.3.1: made support "required" for PMode.ID and PMode.agreement (meaning an implementation must be able to use this Pmode value - if present - to fill-in the related message header element.)” > > > > So I think your interpretation is overall right: > > > > “My interpretation (from the spec and discussions) is that, "support by an MSH" means that the MSH can have PModes with an ID, and if a PMode has an "ID", the "support by an MSH" means that the sending MSH MUST include it with outgoing messages, and a receiving MSH MUST use it to retrieve a specific configuration. So the required support in AS4 would requires the ability to attach an identifier to a PMode.” > > > > Although I would reword it as: > > > > “…the "support by an MSH" means that the sending MSH MAY include it with outgoing messages, and a receiving MSH MUST be able to use it to retrieve a specific configuration. “ > > > > > > “2) If a sender does not include an ID in a message, should the receiving MSH match it against PModes that do not have an ID only, or to all PModes (some that have, and some that do not have a PMode ID) ? “ > > > > I would say against all PModes available. The Receiver should just ignore the PMode.ID feature in that case. Core spec says “If the ID is specified, the AgreementRef/@pmode attribute value is also expected to be set in associated messages.” but it is just a convenience – not a strong requirement. > > 3) If a sender includes an ID in a message, and the receiving MSH does not have a PMode with this ID, should it return an error or should it attempt to match the message to PModes without ID (i.e. ignore the ID) > > > > I think it makes sense to return an error in that case, because if the PMode on Sender side has an ID, it should also have one on Receiver side. Or at least just a warning, if matching works with a PMode without ID. > > > > -jacques > > > > -- > This message was sent by Atlassian JIRA > (v6.2.2#6258) > > --------------------------------------------------------------------- > To unsubscribe from this mail list, you must leave the OASIS TC that > generates this mail. Follow this link to all your TCs in OASIS at: > > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php > > > > > -- Regards Theo
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]