New section 2.6.6

Here is a proposed re-write of section 
2.6.6, generalized to cover all errors at intermediaries:  the (new) 
routing error, connection error and a (new) MessagePullIntervalExpired 
error.

2.6.6 Handling of Errors 
at Intermediaries

ebMS Errors (eb3:Error) generated by 
endpoints are subject to the same reporting options as errors in point-to-point 
communication. At least a couple of routing patterns for eb3:Error must be 
supported: (a) the error destination URL is known (e.g. obtained from the PMode) 
and does not require any multi-hop routing, or (b) the eb3:Error signal is 
routed using the same routing functions as those used for other ebMS signal 
messages.

An ebMS Error can be generated by Intermediaries 
when a message cannot be routed by the Intermediary because the message does not 
match any rule in the routing function. This new type of error MUST be supported 
by intermediaries:

  

  
error ID: EBMS:0020, 

  

  
short description: RoutingFailure

  

  
severity: failure

  

  
description: whenever an Intermediary is unable 
  to route an ebMS message, it must generate such an error and stop processing 
  the message. 

Note that finding a match for a message in the 
routing function is separate from applying the rule. For instance, the 
intermediary may not immediately forward the message but store it first. 

The reporting of an error generated by an 
intermediary MUST follow one of these three patterns: 

(a) Configured 
reporting: errors are handled and reported in 
an implementation-specific manner: either logged locally or sent to a fixed, 
pre-configured destination, or yet assigned to a specific MPC that another MSH 
may pull from. In all cases this is subject to a QoS agreement between I-Cloud 
providers and end-users.

(b) 
Message-determined reporting: if there is 
no provision for solution (a), the error is sent to the destination based on 
data contained in the faulty message. This may in turn fall into a couple of 
cases:

  

  
Either the WS-Addressing header wsa:FaultTo or wsa:ReplyTo is 
  present in the message in error and its value indicates an URL that can be 
  directly resolved. The Error message MUST be sent directly to this 
  location;

  

  
One of these WS-Addressing headers is present and contains an ebint:RoutingInput 
  reference parameter. The intermediary MUST then add this EPR to the error 
  message (as described in 2.7.3 - the ebMS Error message being considered as a 
  response message). The error message MUST then be sent to its destination 
  using the I-Cloud;

  

  
None of these WS-Addressing headers is present in the message in 
  errorbut a RoutingInput header can be inferred (section 2.7.3 , case 4) from 
  other headers available in the message in error. The intermediary MUST add the 
  inferred RoutingInput header to the Error message and sent it using the 
  I-Cloud.

(c) 
Default reporting: if there 
is no provision for either (a) or (b), the default reporting option for an error 
related to the routing of a message sent over an HTTP request, is to send back 
an error message over the HTTP response. The default reporting mode is usually 
sufficient for Hub-and-spoke configurations.

To 
prevent looping of error message intermediaries MUST NOT sent Error messages for 
messages that themselves transmit routing errors. Note that this not prevent an 
intermediary from generating and reporting of such errors as long as they are 
not sent out as Error messages. 

A non-normative example of a routing error signal 
is provided in appendix D.5 . 

Apart from RoutingError, intermediaries may also 
generate other errors:

  

  
The intermediary may not be able to push a 
  message to the next hop due to connection error. The ebMS v3.0 Core 
  Specification specifies the EBMS0005, ConnectionFailure error for this 
  situation.

  

  
If the routing rule of the intermediary 
  specifies that another MSH (either the final destination or the next 
  intermediary) will pull the message based on its message partition channel 
  identifier, the intermediary MUST store the message and wait for it to be 
  pulled. However, the intermediary MAY impose a limit on the time it will wait 
  for the message to be pulled, and discard messages that have not been pulled 
  after the limit is reached. The intermediary MAY report this as a new kind of 
  error, with error code EBMS0021, MessagePullIntervalExpired.