OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] (EBXMLMSG-15) D3.4 Pmodes for error handling


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

Pim van der Eijk commented on EBXMLMSG-15:
------------------------------------------


For errors and receipts,  here is a review of the various PMode parameters:

PMode[1].Protocol.Address, but would duplicate some existing parameters.

PMode[1].Reliability.* for ebMS3 profiles the use e.g. WS-ReliablMessaging
PMode[1].Security.*  all parameters 

PMode[1].ErrorHandling.* in general are not to be used for errors.  Some errors for receipts (like Bad Receipt) are now defined for the corresponding user message.  Some errors on errors could be reported to back-ends?

Possibly PMode.*.Authorization.* 

Note:

In CPP/CPA there has always been a separation between Action Bindings (for UserMessages) and  Channel Definitions.    An Action is bound to a Channel.   Part of a Channel definition is to reference other channels for e.g. Errors.   I.e. Channel X could state that receipts for messages over that channel use Channel Y.    

This is an improvement over e.g.   PMode[1].ErrorHandling.Report.SenderErrorsTo, which just references an Address but does not define the other channel properties. 





> D3.4 Pmodes for error handling
> ------------------------------
>
>                 Key: EBXMLMSG-15
>                 URL: https://issues.oasis-open.org/browse/EBXMLMSG-15
>             Project: OASIS ebXML Messaging Services TC
>          Issue Type: Improvement
>          Components: Core Spec
>            Reporter: Pim van der Eijk
>
> There does not seem to be a way to specify that ebMS3 error messages are to be signed or encrypted.    The parameters in D3.5 are about the business message.  In particular for asynchronous errors, it is useful to be able to authenticate the MSH that is posting this error to validate it is the MSH to which the message in error was sent and not some other.
> For AS4 we could simplify this and state that an asynchronous error on a message should be signed if and only if the message in error was signed, as we did with receipt.



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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]