OASIS ebXML Messaging Services TC

All, I have some questions I would like to discuss with you about the Error that should be returned if an MSH can not determine which P-Mode should handle a received message.   Do we want to specify a specific Error for this situation? If so, which Error should be used?   Section 6.7.1 of the Core Spec lists the standard ebMS processing errors. Based on the short descriptions it seems logical that EBMS:0010 - ProcessingModeMismatch is the correct Error to return. However the description of the semantics - the  header expected by the MSH is not compatible with the expected content, based on the associated P-Mode. - is a bit unclear because of the incompatibility between expectations and that it talks about an associated P-Mode. Especially the latter seems to suggest that a P-Mode is found for the message. Another option could be Error EBMS:0001 - ValueNotRecognized as the MSH is unable to find the P-Mode based on the received information. Regards Sander Attachment: smime.p7s Description: S/MIME cryptographic signature

All,   1.            Yes – already encountered situations this where PModes are varied – no way for Client to discover them; they need to be assigned on basis of inbound unique property.  Any HTTP side element (URL; IP address etc) can be mangled by routers etc and lost.  We are using the ebMS Form field to index agreed PModes and load these at runtime; but there are cases where these are not known ahead of time and I think it better to return as specific a message as possible.   2. Can we add a new Error to specifically cover this situation?  Ie PModes Unknown – ie not set up in advance.  Not actually an error - normally applies to a new or not configured connector attempts.    Not sure what the specific process is – ie mod to update Spec – how easy or hard is this?     Regards,   David Tuke Enterprise Architect     Oban Pty Ltd Ground Floor 19-23 Prospect St Box Hill 3128 Australia  ABN 18 163 365 080 T: +61 3 9044 1702 M: 0408 017 962 F: +61 3 9044 1799 E: David.Tuke@obansolutions.com.au W: www.obansolutions.com.au   ***NOTICE*** This e-mail may contain confidential or legally privileged material and if you are not the intended recipient, you are advised that Oban Pty Ltd does not consent to you reading or copying the material and does not waive any confidentiality or legal privilege associated with it. This e-mail may also contain material which is protected by copyright and if you are not the intended recipient, you are advised that Oban Pty Ltd has not consented to your reproduction of the material and there is no intention to provide you with an implied licence to exercise any of the rights of the copyright owner or an authorised licensee. If you have received this e-mail in error, please advise Oban Pty Ltd immediately by return e-mail or by telephone on 61-3-9236-1900. The recipient of this e-mail is solely responsible for conducting such tests and virus scanning as may be necessary, before using any attachment, to ensure that the attachment does not contain any virus and that use of the attached materials will in no way corrupt the recipient's data or systems or those of any other person.                 From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Sander Fieten Sent: Wednesday, 19 November 2014 8:10 AM To: ebxml-msg@lists.oasis-open.org Subject: [ebxml-msg] Error to use when P-Mode not found   All,   I have some questions I would like to discuss with you about the Error that should be returned if an MSH can not determine which P-Mode should handle a received message.   Do we want to specify a specific Error for this situation? If so, which Error should be used?   Section 6.7.1 of the Core Spec lists the standard ebMS processing errors. Based on the short descriptions it seems logical that EBMS:0010 - ProcessingModeMismatch is the correct Error to return. However the description of the semantics - "the  header expected by the MSH is not compatible with the expected content, based on the associated P-Mode." - is a bit unclear because of the incompatibility between expectations and that it talks about an associated P-Mode. Especially the latter seems to suggest that a P-Mode is found for the message. Another option could be Error EBMS:0001 - ValueNotRecognized as the MSH is unable to find the P-Mode based on the received information.   Regards Sander    

Perhaps an idea to revisit all ebms errors with the experience gained over the past couple of years with AS4 On 18 Nov 2014, at 23:10 , Sander Fieten <sander@fieten-it.com> wrote: > All, > > I have some questions I would like to discuss with you about the Error that should be returned if an MSH can not determine which P-Mode should handle a received message. > • Do we want to specify a specific Error for this situation? > > • If so, which Error should be used? > Section 6.7.1 of the Core Spec lists the standard ebMS processing errors. Based on the short descriptions it seems logical that EBMS:0010 - ProcessingModeMismatch is the correct Error to return. However the description of the semantics - "the header expected by the MSH is not compatible with the expected content, based on the associated P-Mode." - is a bit unclear because of the incompatibility between expectations and that it talks about an associated P-Mode. Especially the latter seems to suggest that a P-Mode is found for the message. Another option could be Error EBMS:0001 - ValueNotRecognized as the MSH is unable to find the P-Mode based on the received information. > > Regards > Sander > > -- Regards Theo

> Based on the short descriptions it seems logical that EBMS:0010 – ProcessingModeMismatch …   That is a bit of a stretch: that error above was supposed to occur when (a) the Pmode is actually well identified and known, (b) the message does not comply with tthat Pmode.   So sure we could say that a missing Pmode (unidentified) is a corner case, for lack of a specific error.   But it seems we need a new error as that solution does not help the users to understand what happened. Something like: EBMS:0012 MissingPmode “The MSH could not identify the Pmode for this message.”   -jacques     From: ebxml-msg@lists.oasis-open.org [mailto:ebxml-msg@lists.oasis-open.org] On Behalf Of Sander Fieten Sent: Tuesday, November 18, 2014 1:10 PM To: ebxml-msg@lists.oasis-open.org Subject: [ebxml-msg] Error to use when P-Mode not found   All,   I have some questions I would like to discuss with you about the Error that should be returned if an MSH can not determine which P-Mode should handle a received message.   Do we want to specify a specific Error for this situation? If so, which Error should be used?   Section 6.7.1 of the Core Spec lists the standard ebMS processing errors. Based on the short descriptions it seems logical that EBMS:0010 - ProcessingModeMismatch is the correct Error to return. However the description of the semantics - "the  header expected by the MSH is not compatible with the expected content, based on the associated P-Mode." - is a bit unclear because of the incompatibility between expectations and that it talks about an associated P-Mode. Especially the latter seems to suggest that a P-Mode is found for the message. Another option could be Error EBMS:0001 - ValueNotRecognized as the MSH is unable to find the P-Mode based on the received information.   Regards Sander    

We need to be careful,  I think many existing implementations do use 0010 for all situations where they cannot map a message,  whether it is messages with a PMode attribute value that is unknown,  or based on its UserMessage values to a configuration.    I would prefer to generalize the definition of the error to a more general pmode lookup error . On 11/19/2014 09:02 PM, Jacques Durand wrote: > Based on the short descriptions it seems logical that EBMS:0010 – ProcessingModeMismatch …   That is a bit of a stretch: that error above was supposed to occur when (a) the Pmode is actually well identified and known, (b) the message does not comply with tthat Pmode.   So sure we could say that a missing Pmode (unidentified) is a corner case, for lack of a specific error.   But it seems we need a new error as that solution does not help the users to understand what happened. Something like: EBMS:0012 MissingPmode “The MSH could not identify the Pmode for this message.”   -jacques     From: ebxml-msg@lists.oasis-open.org [ mailto:ebxml-msg@lists.oasis-open.org ] On Behalf Of Sander Fieten Sent: Tuesday, November 18, 2014 1:10 PM To: ebxml-msg@lists.oasis-open.org Subject: [ebxml-msg] Error to use when P-Mode not found   All,   I have some questions I would like to discuss with you about the Error that should be returned if an MSH can not determine which P-Mode should handle a received message.   Do we want to specify a specific Error for this situation? If so, which Error should be used?   Section 6.7.1 of the Core Spec lists the standard ebMS processing errors. Based on the short descriptions it seems logical that EBMS:0010 - ProcessingModeMismatch is the correct Error to return. However the description of the semantics - the  header expected by the MSH is not compatible with the expected content, based on the associated P-Mode. - is a bit unclear because of the incompatibility between expectations and that it talks about an associated P-Mode. Especially the latter seems to suggest that a P-Mode is found for the message. Another option could be Error EBMS:0001 - ValueNotRecognized as the MSH is unable to find the P-Mode based on the received information.   Regards Sander    

I agree with Pim that generalising this error may be a better solution. Otherwise it also looks very similar to EBMS:0003 which can also be used to indicate inconsistencies with the P-Mode ( some element/attribute value is inconsistent either with the content of other element/attribute, or with the processing mode of the MSH, ” )  Regards Sander On 20 Nov 2014, at 11:34, Pim van der Eijk < pvde@sonnenglanz.net > wrote: We need to be careful,  I think many existing implementations do use 0010 for all situations where they cannot map a message,  whether it is messages with a PMode attribute value that is unknown,  or based on its UserMessage values to a configuration.    I would prefer to generalize the definition of the error to a more general pmode lookup error . On 11/19/2014 09:02 PM, Jacques Durand wrote: >   Based on the short descriptions it seems logical that EBMS:0010 – ProcessingModeMismatch …   That is a bit of a stretch: that error above was supposed to occur when (a) the Pmode is actually well identified and known, (b) the message does not comply with tthat Pmode.   So sure we could say that a missing Pmode (unidentified) is a corner case, for lack of a specific error.   But it seems we need a new error as that solution does not help the users to understand what happened. Something like: EBMS:0012 MissingPmode “The MSH could not identify the Pmode for this message.”   -jacques       From:   ebxml-msg@lists.oasis-open.org   [ mailto:ebxml-msg@lists.oasis-open.org ]   On Behalf Of   Sander Fieten Sent:   Tuesday, November 18, 2014 1:10 PM To:   ebxml-msg@lists.oasis-open.org Subject:   [ebxml-msg] Error to use when P-Mode not found     All,   I have some questions I would like to discuss with you about the Error that should be returned if an MSH can not determine which P-Mode should handle a received message.   Do we want to specify a specific Error for this situation? If so, which Error should be used?   Section 6.7.1 of the Core Spec lists the standard ebMS processing errors. Based on the short descriptions it seems logical that EBMS:0010 - ProcessingModeMismatch is the correct Error to return. However the description of the semantics - the  header expected by the MSH is not compatible with the expected content, based on the associated P-Mode. - is a bit unclear because of the incompatibility between expectations and that it talks about an associated P-Mode. Especially the latter seems to suggest that a P-Mode is found for the message. Another option could be Error EBMS:0001 - ValueNotRecognized as the MSH is unable to find the P-Mode based on the received information.   Regards Sander     Attachment: smime.p7s Description: S/MIME cryptographic signature

Agreed. On 20 Nov 2014, at 12:34 , Pim van der Eijk <pvde@sonnenglanz.net> wrote: > We need to be careful, I think many existing implementations do use 0010 for all situations where they cannot map a message, whether it is messages with a PMode attribute value that is unknown, or based on its UserMessage values to a configuration. I would prefer to generalize the definition of the error to a more general "pmode lookup error". -- Regards Theo