Routing Errors

["Pim van der Eijk" <pvde@sonnenglanz.net>]

Section 2.6.6 of the current version of the spec describes three options for
routing errors at intermediaries:
(a) error is logged only
(b) error is sent to a fixed, pre-configured destination
(c) error is sent to destination identified by wsa:ReplyTo or wsa:FaulTo

I would like to propose some variants:

(d) error is sent on the HTTP response (anonymous EPR).  

(e) the error is sent to the icloud URI asynchronously.

In both cases (d) and (e) an error message generated using option (4) from
section 2.7.3 SHOULD be added. I.e. a routing parameter is added based on
UserMessage header elements. Attached are a UserMessage and a sample Error
message that an intermediary might generate. This allows routing errors to
be routed back to the senders.   

Option (d) is especially relevant for the first intermediary: endpoints
sending messages to an intermediary will get all routing errors immediately,
without having to be HTTP addressable or to pull from an MPC on some
intermediary.  To be able to generate the routing error, the intermediary
only needs to verify that it has a matching routing rule. It would not have
to actually wait until the message is routed, so the intermediary can still
be fully asynchronous (pull-on-push, or store-and-forward push-on-push). The
is-routable(message)->boolean function adds a minimal processing burden on
intermediaries so is quite acceptable even in high performance, high volume
environments.   Assuming typical multihop deployments will have vastly more
endpoints for any intermediary, I think (d) could be the default. At the
least, I would prefer it to options (a) and (b).

In scenario (e) the routing function of the intermediary would define how to
route the error message back through the icloud, using the regular options
for response messages.

Scenarios (d) and (e) MUST NOT be applied to messages that themselves carry
routing errors. 

Pim

Error.xml

1. UserMessage.xml