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:

>
> S 4.1.
> >>      capability indicator, the UA SHOULD only send a re-registration
> >>      REGISTER request when it receives a push notification (even if the
> UA
> >>      is able to use a non-push mechanism for sending re-registration
> >>      REGISTER requests), or when there are circumstances (e.g., if the
> UA
> >>      is assigned new contact parameters due to a network configuration
> >>      change) that require an immediate REGISTER request to be sent.
> >
> >This text doesn't seem correct. If the initial response doesn't
> >contain "sip.pns" then you probably would still want to send regular
> >REGISTERs
>
> The text is about "sip.pnsreq".
>

Yes, but it's not phrased as being conditional on that other condition (see
previous comments about writing style).

---
>
> S 4.1.
> >>      change) that require an immediate REGISTER request to be sent.
> >>
> >>      NOTE: If the UA uses a non-push mechanism to wake and send a
> binding
> >>      refresh REGISTER request, such REGISTER request will update the
> >>      binding expiration timer, and the proxy does not need to request a
> >>      push notification towards the UA in order to wake the UA.  The
> proxy
> >
> >This doesn't seem obviously correct. Why is this so?
>
> As the UA will use other (non-push) mechanisms to wake up for updating the
> binding expiration timer, there is no need to use push notifications for
> that.
>

All right.


> ---
>
> S 4.1.
> >>      REGISTER request.
> >>
> >>      If the UA no longer wants to receive push notifications (requested
> by
> >>      the proxy), the UA MUST send a binding-refresh REGISTER request
> >>      without including the SIP URI parameters described above, or the UA
> >>      MUST remove the registration.
> >
> >This seems pretty hard to conform with, given that mobile applications
> >are often just shut down with no warning.
>
> On shut down, I believe mobile applications are typically moved in to a
> state where they are still able to perform some actions.
>

It's not reliable. Sometimes you get that, sometimes you don't.


Anyway, the text applies to situations where the UA is able to perform
> actions.
>
> So, perhaps clarifying that with:
>
> "the UA MUST (unless it is no longer able to perform SIP procedures, e.g.,
> due to a forced shutdown) send a"
>

This doesn't seem much like a MUST.

---
>
> S 4.1.
> >>      document.
> >>
> >>      For privacy and security reasons, the UA MUST NOT include the SIP
> URI
> >>      parameters defined in this document in non-REGISTER request, to
> >>      prevent the PNS information associated with the UA from reaching
> the
> >>      remote peer.  For example, the UA MUST NOT include the SIP URI
> >
> >For non-SIP experts, why is this not an issue with REGISTER?
>
> The REGISTER will only reach your registrar, it will not be forwarded to
> the remote peer.
>

Please say so.


>
> S 5.2.
> >>      If the UA has indicated, using the 'sip.pnsreg' media feature tag,
> >>      that it is able to wake using a non-push mechanism for sending
> >>      binding-refresh REGISTER requests, if the proxy does not receive a
> >>      REGISTER request prior to 120 seconds before the registration
> >>      expires, the proxy MAY request a push notification towards the UA,
> to
> >>      trigger the UA to send a REGISTER request.
> >
> >This paragraph needs to be rewritten in some way that is not so
> >conditional dense.
>
> There are only two conditions, aren't there?
>

No.

When a proxy receives:
   If the proxy considers
   If the proxy considers
   Similarly, when the proxy receives [not sure about the indent on this
one...]



> ---
>
> S 5.2.
> >>      UA expects to receive push notifications from the network.  A proxy
> >>      will not request push notifications towards a UA that has not
> >>      provided a pn-prid SIP URI parameter.
> >>
> >>      If the proxy receives information that a registration has expired,
> >>      the proxy MUST NOT request further push notifications towards the
> UA.
> >
> > Again, how would it receive such information?
>
> E.g., using RFC 3680 - or some other mechanism. As different networks and
> architectures might use different mechanisms for updating its nodes about
> the registration status, we don't want to mandate a specific mechanism.
>

You need to say something here about how that's out of scope. Otherwise,
people just go hunting through the text for it.



> S 5.3.1.
> >>      registrar too short, the proxy MUST NOT insert a Feature-Caps
> header
> >>      field with a 'sip.pns' feature-capability indicator in the
> response,
> >>      and the proxy MUST NOT request push notifications associated with
> the
> >>      registration.  A registration expiration interval MUST be
> considered
> >>      too short if the interval is smaller than the time prior to
> >>      expiration that the proxy would request a push notification.  The
> >
> >What does this text mean?
>
> If the registration interval is considered too short, a proxy will not
> enable SIP push.
>
> For example, assume a proxy would send a push notification 30 seconds
> prior to registration expirations.
>
> Now, if the registration expiration interval is only 20 seconds, it would
> not work.
>
> I don't think this will ever happen in real life, but people wanted this
> text.
>

OK, but it should be rewritten so it's clear.


> ---
>
> S 5.3.2.
> >>
> >>      If the proxy has knowledge that the UA is awake, and that the UA is
> >>      able to receive the SIP request without first sending a REGISTER
> >>      request, the proxy MAY choose to not request a push notification
> >>      towards the UA (and wait for the associated REGISTER request and
> 2xx
> >>      response) before it tries to forward the SIP request towards the
> UA.
> >
> >Why not race these?
>
> One could do that, but I don't think it should be mandated.
>

The current text prohibits racing if you *don't* know that the UA is awake.


>
> S 6.1.1.
> >>      triggered by incoming mid-dialog requests is done based on local
> >>      policy.  Such policy might be based on the type of SIP dialog, the
> >>      type of media (if any) negotiated for the dialog [RFC3264], etc.
> >>
> >>      NOTE: As the 'pn-purr' SIP URI parameter only applies to a give
> >>      dialog, the UA needs to include a 'pn-purr' parameter in the
> Contact
> >
> > "to a given" dialog?
>
> Correct. Will fix.
>
> ---
>
> S 6.2.1.
> >>   6.2.1.  REGISTER
> >>
> >>      When the proxy receives an initial REGISTER request for a
> >>      registration from the UA, if the proxy supports requesting push
> >>      notifications, triggered by mid-dialog requests, towards the
> >>      registered UA, the proxy MUST store the information (the pn- SIP
> URI
> >
> > Too many commas here to make sense of this requirement
>
> I'll see what I can do to fix that.
>
> ---
>
> S 10.
> >>      by two values, separated by a period (.): Team ID and Topic.  The
> >>      Team ID is provided by Apple and is unique to a development team.
> >>      The Topic consists of the Bundle ID, which uniquelly identifies an
> >>      appliciation, and a service value that identifies a service
> >>      associated with the application, separated by a period (.).  For
> VoIP
> >>      applications the service value is "voip".
> >
> > What is the syntax of these params?
>
> The details can be found in the PNS specific documentation.
>

These do not appear to be normative references. I at least need to know
enough about the structure to know what to expect.

-Ekr


> ---
>
> S 11.
> >>      The value of the pn-provider URI parameter is "fcm".
> >>
> >>      The value of the pn-param URI parameter is the Project ID.
> >>
> >>      The value of the pn-prid URI parameter is the Registration token,
> >>      which is generated by the FCM SDK for each client app instance.
> >
> > Again, what is the syntax of this?
>
> Same as above.
>
> Regards,
>
> Christer
>
>
>
>
>