rfc2822
commented
4 hours ago I think this isn't a great idea, since it will fragment client<>server interoperability. Taking this route an iOS client would require that the server implements first-party support for Apple APN.
Why would it require that? It would support it, but people could still use a gateway instead.
My reason for allowing future protocols is that push protocols seem to develop quite rapidly, and who knows how long Web Push will last? And there's no reason to bind WebDAV-Push to Web Push, as it would work with any protocol. So it seems a quite arbitrary limitation to me to limit WebDAV-Push to Web Push.
However we would only specify the Web Push transport.
What about just mentioning that gateways would be possible in the document?
The current draft mentions support of additional non-standard transports:
I think this isn't a great idea, since it will fragment client<>server interoperability. Taking this route an iOS client would require that the server implements first-party support for Apple APN.
Instead, I suggest using gateways. The general idea of a gateway is that it receives push notification using the standard Web Push API, and forwards it to another service (typically, a proprietary, centralised service).
An example gateway is https://sr.ht/~emersion/pushgarden/. I've used it with IRC clients. The IRC bouncer supports only web push, and the gateway can forward notifications to either Apple or Google's notification services.
Using this approach also simplifies the protocol in general, because instead of wrapping around multiple different push transports, we can just rely on a single standard one.