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

[Eric Rescorla <[e-mail]>]

On Mon, Jan 7, 2019 at 5:09 AM Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
>
> In this reply I will address the COMMENT issues:
>
>
> >This document is very badly in need of editorial work for readability.
> >I would urge the responsible AD to make one.
>
> I have done quite a bit of editorial work based on WGLC/AD comments etc. I
> am happy to improve it even further, but someone needs to guide me what to
> do.
>

Ben?


> S 1.
> >>      used to wake such applications, nor will incoming network traffic
> >>      wake the application.  Instead, one way to wake the application is
> by
> >>      using a Push Notification Service (PNS).  Typically each operating
> >>      system uses a dedicated PNS.  For example, Apple iOS devices use
> the
> >>      Apple Push Notification service (APNs) while Android devices use
> the
> >>      Firebase Cloud Messaging (FCM) service.
> >
> >What is a Push Notification Service? I mean, I know, but you need to
> >say.
>
> I will add some text/reference about that.
>
> ---
>
> 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"

>
> S 1.
> >>            |<---------------------|                         |
> >>            |                      |                         |
> >>            |          SIP REGISTER (Push Resource ID)       |
> >>            |===============================================>|
> >>            |                      |                         | SIP
> REGISTER
> >>            |                      |
> |============>
> >
> >These arrows don't seem to go anywhere. I think you need to label the
> >registrar.
>
> Ok, I will label the "registrar/home proxy" (I don't think we need to
> separate them).
>

Sure.


> ---
>
> 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.