Instead of lazily adding the ice.notifyBack to the listen.icepush requests upon registering for cloud push and resulting in the eventual server-side NotifyBackURI representation, we should introduce new .icepush requests specifically for this:

1. add-notify-back-uri.icepush
2. has-notify-back-uri.icepush
3. remove-notify-back-uri.icepush

All these requests should be kept quite simple. The add request should at a minimum include the browserID and notifyBackURI as only the client-side is able to obtain the notifyBackURI. The response to the add request can likely just be a 200 OK or 204 No Content status message. The has request should at a minimum include the browserID. This request can be used by the cloud/mobile component to check if its browserID already has a notifyBackURI associated with it. The response to the has request can likely just be a 200 OK or 204 No Content status message indicating its browserID has a notifyBackURI associated with it, or it can likely just be a 404 Not Found status message indicating its browserID has no notifyBackURI associated with it.

For this both the client-side and server-side need to include support for these new .icepush requests.