Summary: The CosNotifyChannelAdmin::ConsumerAdmin::obtain_notification_X_supplier
operation, when asked for a proxy for a ClientType of ANY_EVENT,
returns a proxy that is unuasable by event service clients.

The reason is that the CosNotifyChannelAdmin::ProxyXSupplier interface
returned inherits only from CosEventChannelAdmin::XSupplier, and then
redefines the connect operation that was available in CosEventChannelAdmin::
ProxyXSupplier as connect_any_x_supplier. The interface can never be
narrowed to CosEventChannelAdmin::ProxyXSupplier, and therfore is
unusable by the Event Service style client.

Summary:
The suspend_connection/resume_connection messages do not describe what should happen to messages that are queued up. Are new messages rejected for the duration between the disconect and resume? Are messages that were queued up flushed? How does the Persistent Event Reliablity QoS effect the way both are handled? size=2> Along the same lines, what happens to events when a consumer disconnects? I assume events in this case would be lost.

Summary: I feel there is a flaw in the model described in the current Notification
Service spec for supporting Transactional Notification.

Summary: In Appendix A it is stated that "the EventTypeRepository class only has
one instance in any given implementation of the Repository". At the same
time, there is a package interface and a package factory that implies
that it"s possible to create multiple repositories (unless the
NotificationTypesPackage interface is expected to always returns the
same objects, no matter how many packages one have created).

The type of MaxEventsPerConsumer should be an unsigned long, why should this be long, so far as I can't tell there is no need for a negative number