Yeah, I guess new message types aren’t necessary. We already have “OK” for responding to a client’s earlier “EVENT”. So “NOTICE” really can/should be specific to notifications related to a previous “REQ” or “CLOSE”, for which a subscription_id is available.
I doubt that adding the subscription_id would break clients, but it’s possible. If that’s a concern, my alternative suggestion would be to upgrade the NOTICE payload string to be a JSON stringified object which has “subscription_id”, “message” and any other fields.
