RE: [i95, i22] - Proposal for clarifying use of SOAPAction

I absolutely agree that thinking about a routing extension or module (I
tend to call them SOAP bubbles) as being one of the things that we add
is a great idea. This would also allow us to provide support for
intermediaries, bidirectional message paths etc which a single HTTP
header field doesn't provide and I don't think the overhead would be
that bad.

This was discussed at the recent Web Services WS [1] - in fact, I wrote
a position paper on the very topic of SOAP routing [2]. At the same WS
it was proposed that work on such modules would be part of a
yet-to-be-created WG. However, before we can get there we (this group)
has to settle as many issues as possible on our spec so that we provide
a solid foundation for these modules.

Henrik

[1] http://www.w3.org/2001/01/WSWS 
[2] http://www.w3.org/2001/03/WSWS-popa/paper41

>  I understand your desire to not restrict or mandate how
>the SOAPAction header should be use (don't agree yet, but I
>understand it 8-)   May people like to use the SOAPAction
>header for routing, I believe, because it allows them to
>route w/o having to parse the XMLP message, how do you
>feel about adding (to the spec or as a well known extension)
>an attribute to the SOAP Envelope that contains the routing 
>information?  This would allow people to route with the 
>minimal about of parsing but still preserve the openness of 
>the SOAPAction header. Others - would this limited parsing 
>still be too much? -Dug