As per the EventDestination schema, while subscribing for the events, the client can send Destination, EventTypes, MessageIds and OriginResources. Here the EventTypes, MessageIds and OriginResources are the arrays.
My question is : If there are 3 members in each of these parameters, then there is 27 combinations of the event-message-resource need to be taken care. How does the server behave, if some of them are not supported. Should it respond as the subscription was a complete failure ? or report a partial failure by marking the failed combinations in the response?
I would expect the subscription would be successful. Checking the validity of each of the combinations does not appear terribly useful and would likely over-complicate the service, especially since particular registries and resource IDs may come and go during the life of the service. It will also create a burden on the client to constantly try/fail the subscription request. When an event is generated, I would expect the service would put the event information through some matching routine for each of the event destinations, and if a match is found, it would send it to the appropriate destination. Just because a particular combination may never happen, that's okay; the client simply wants something that will never happen.
I imagine most clients likely wouldn't be providing all of those fields in the subscription request. For example, a client may simply want all events from a particular Thermal resource, regardless of the message ID or event type.
MessageIds is an optional field in the event subscription; if a client makes a subscription request without MessageIds in the payload, then the service will send an event to the client for all MessageIds (assuming the other parameters match the subscription). However, if a client does provide MessageIds as part of the subscription request, then the service will only send events to the client that match one of the MessageIds in the subscription (also assuming the other parameters match the subscription).