Re: [sipcore] Eric Rescorla's Discuss on draft-ietf-sipcore-sip-push-21: (with DISCUSS and COMMENT) - the COMMENT issues

[Christer Holmberg <[e-mail]>]

Hi,

S 1.
>>      will request push notifications towards the UA.
>>
>>      When the proxy receives a SIP request for a new dialog or a stand-
>>      alone SIP request addressed towards a UA, or when the proxy
>>      determines that the UA needs to send a binding-refresh REGISTER
>>      request, the proxy will request a push notification towards the UA,
>
> "request ... towards" is ungrammatical

Is "request a push notification to be sent towards the UA" better?

>I would say "request that a push notification be sent to"

Ok.

...

S 4.1.
>>
>>      NOTE: The VAPID specific procedures of the SIP UA are outside the
>>      scope of this document.
>>
>>      When the UA receives a push notification, it MUST send a binding-
>>      refresh REGISTER request, using normal SIP procedures.  If there are
>
>This seems unnecessarily restrictive. Are we never going to want any
>other kind of push notification?

Well, in order for this mechanism to work, it has to be a MUST, and the procedures obviously only applies to UAs that use the SIP push mechanism.

>Yeah, this seems like a pretty major architectural flaw in this design, tbh, one that is
>remedied by just using RFC 8030-style notifications that contain content.

Other push notification services support content too, but we decided that we are not going to specify that for SIP push.

IF there comes a future case, where multiple SIP usages of push notifications have to co-exist, we can define usage of content (and e.g., define that SIP push is default).

Regards,

Christer