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