Ian:
Some aspects of remaining work items, that we need to discuss too:
1. Security
- Finalize Security restrictions, per BSP 1.0 and WS-Security - or
more?
2. Composition Security / Reliability
- How prescriptive the specification should be about the SOAP
processing order, both sender and receiver sides. (Is it enough to state the
required/optional functional compositions, or does interoperability require
more than this?)
3. Sharpen the definition of MSH
- Either restrictive (processor of ebMS headers only) or inclusive (composition
of processors of all headers - reliability, security, ebMS3)
- assuming we can partition MSH functions as sending/receiving
(corresponding to functional "modules" in http://www.w3.org/TR/qaframe-spec/),
can an MSH implement only sending or receiving? (This has some editorial
consequences such as labeling "sending MSH" or not)
4. Role for an MSH in the SOAP processing
model
- should a [receiving] MSH be only an endpoint as in ebMS 2, or could
an MSH be a SOAP intermediary? (Could a well-formed SOAP message - including
body, attachments...- "become" an ebMS3 message after processing by a
[sending] MSH, and then be reversed again in its former state by a receiving
MSH, and forwarding?) This opens interesting composition schemes. Note that this
is not about "MSH intermediaries".
Hamid & Jacques