I hope this is the best place to leave feedback for the push spec in its current form; if not let me know where to put it.
This spec looks broadly fine. Given servers may well be implementing both, it would make a lot of sense to align the specification with JMAP where the semantics are the same, specifically:
Consider renaming "endpoint" to "url" and moving that property and the "keys" property to the top level of the object instead of in a "resource" sub-object.
Consider replacing "client" and "device" with "deviceClientId" – to preserve the privacy of the user, we deliberately made this an opaque id in JMAP. If not doing this, it will need to at least be discussed in the security considerations.
Use the same structure for the push verification object; this is a no brainer, given it's the same data. It makes sense to use the same structure as described in section 7.2.2.
Rather than setting the verification code at a separate path, instead update the PushSubscription object with the code (as the "verificationCode" property); if successful, the subscription is now valid (so the presence of this replaces the need for the "validated" property). This method is no better or worse than the current spec, but it does make it align closely with JMAP which seems worthwhile when there is no good reason not to.
Unless tied to a session-based authorisation mechanism (which it almost certainly won't), the server will want to automatically expire push subscriptions after a certain amount of time if the client does not refresh them. This spec seems to be missing that; I suggest adding it. See the "expiry" property on the PushSubscription object in JMAP. (The client refreshes in JMAP by updating this property; I would suggest something similar in IMAP.)
The payload for push notifications is a JSON-formatted subset of the message. JMAP Mail RFC8621 already has a well-defined structure for this, I would again suggest using it, at least for "from", "subject", "receivedAt" (internal date) or "sentAt" (for the date header in the email), and "messageId". What to do for the body ("content") is more interesting. I would suggest "preview" from the JMAP spec, but it looks like you want to be able to send text/html or something else too. The current specification is underspecified regarding what is meant to be returned here, so more discussion needed at least.
As a general note, the use of hyphens in JSON property names is very unusual. JMAP uses camelCase, so I would recommend using that, although snake_case is also not uncommon.
Presuming you're bringing this to IETF106, I look forward to discussing this further there or on the EXTRA mailing list.
I hope this is the best place to leave feedback for the push spec in its current form; if not let me know where to put it.
This spec looks broadly fine. Given servers may well be implementing both, it would make a lot of sense to align the specification with JMAP where the semantics are the same, specifically:
Align the naming/structure of the subscription object with the JMAP PushSubscription object
Use the same structure for the push verification object; this is a no brainer, given it's the same data. It makes sense to use the same structure as described in section 7.2.2.
Rather than setting the verification code at a separate path, instead update the PushSubscription object with the code (as the "verificationCode" property); if successful, the subscription is now valid (so the presence of this replaces the need for the "validated" property). This method is no better or worse than the current spec, but it does make it align closely with JMAP which seems worthwhile when there is no good reason not to.
Unless tied to a session-based authorisation mechanism (which it almost certainly won't), the server will want to automatically expire push subscriptions after a certain amount of time if the client does not refresh them. This spec seems to be missing that; I suggest adding it. See the "expiry" property on the PushSubscription object in JMAP. (The client refreshes in JMAP by updating this property; I would suggest something similar in IMAP.)
The payload for push notifications is a JSON-formatted subset of the message. JMAP Mail RFC8621 already has a well-defined structure for this, I would again suggest using it, at least for "from", "subject", "receivedAt" (internal date) or "sentAt" (for the date header in the email), and "messageId". What to do for the body ("content") is more interesting. I would suggest "preview" from the JMAP spec, but it looks like you want to be able to send
text/htmlor something else too. The current specification is underspecified regarding what is meant to be returned here, so more discussion needed at least.As a general note, the use of hyphens in JSON property names is very unusual. JMAP uses camelCase, so I would recommend using that, although snake_case is also not uncommon.
Presuming you're bringing this to IETF106, I look forward to discussing this further there or on the EXTRA mailing list.