Hi At the meeeting yesterday John brought up the point of where notifications should be send to, as this is currently not properly defined. This is for messages such as dataPlaneStateChange and errorEvent (which includes forcedEnd and other). One solution is to use the replyTo that was specified during the initial reserve. This has a number of limitations though, as it is not possible to change the where notification events go, and it is not possible to notify multiple parties. Instead we came up with the suggestion of explicit subscriptions. This means including to new messaging primitives for subscribing and subscribe to notifications. Furthermore we would add a way to indicate subsription in the header for future events. This allows subscribing in a reserve without having to send a seperate subscribe message. This can either be a flag indicating to use the replyTo field or a seperate field (are there any uses for different replyTo and subscription events). Implications of adding this: * Two new message primitives: subscribe and unsubscribe. - A subscribe message will have a single endpoint, and can specify a number of connection ids. - The return message should specify which connection ids the subscription succeeded * A flag or a field in the header for subscribing. Best regards, Henrik Henrik Thostrup Jensen <htj at nordu.net> Software Developer, NORDUnet