This mailing list has been a bit quiet recently. I have actually been busy implementing WS-Notification, and am at a stage where it is time for some more interop testing. This is surprisingly hard, as I cannot actually receive events at work; I can only test against remote systems from home. XMPP notification is much easier. 1. I will bring the HP system up and running with WS-N support on friday. I'm not convinced it generates all the events, at the right time. 2. I've been test subscribing against the ourgrid implementation. I can see that I can subscribe to events, but havent been able to test for incoming events. This is where we will find any incompatibilities between my reading of the WS-N spec and that of the Muse team. 3. I note that our CMP/deployapi tests don't take into account the possibility that events get received in a different order from that of the lifecycle. It seems to me that this is not actually precluded from the WS-N/SOAP protocols, especially WS-N over things other than HTTP, or with pooled notification threads (which is what I have for generating non-blocking notifications) How do people test state transitions -do they explicitly test for components walking through the expected lifecycle, or is it ok for events to come back out of order, provided the clock order of sent messages matches? 4. A draft document on testing the specification. Stephen Pickles was interested in this, so I added it to my list of deliverables. I dont have any coverage of CMP testing, if anyone else wants to volunterer. 5. Jun, can you make sure the NEC endpoint is up and running next week. If I can successfully subscribe and listen to the Ourgrid implementation, then I should be able to work with yours, but I would like to do it just to check off the 'all is complete' box in the interoperability document. -steve