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,


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.

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?

---

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

---

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.

If there will be additional usages of push notifications for such UAs, I think they will have to deal with making sure the UA is able to determine what usage the push notifications are associated with.

---

S 4.1.
>>      protocol is used, the SIP request might reach the UA before the
>>      REGISTER response.
>>
>>      NOTE: The lifetime of any NAT binding created by the REGISTER request
>>      only needs to be long enough in order for the SIP request that
>>      triggered the push notification to reach the UA.
>
>This general architectural point should be made further up.

Ok, I will move it.

---

S 4.1.
>>      [RFC3840] in each Contact header field URI of each REGISTER request.
>>      Then, if the response to the REGISTER request contains a 'sip.pnsreg'
>>      feature-capability indicator with an indicator value, the UA
>>      refreshes the binding prior to the binding expires.  The indicator
>>      value indicates a minimum time (given in seconds), prior to the
>>      binding expires when the UA MUST send the REGISTER request.  Even if
>
>This sentence needs a rewrite.

I'll see what I can do.

---

S 4.1.
>>      Then, if the response to the REGISTER request contains a 'sip.pnsreg'
>>      feature-capability indicator with an indicator value, the UA
>>      refreshes the binding prior to the binding expires.  The indicator
>>      value indicates a minimum time (given in seconds), prior to the
>>      binding expires when the UA MUST send the REGISTER request.  Even if
>>      the UA is able to to send REGISTER requests using a non-push
>
>"to to"

Will fix.

>Also, all UAs that are conformant to this specification are able to
>send REGISTERS via a non-push as the first register is sent that way.

Correct. I will clarify that.

---

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

---

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.

---

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.

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"

---

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.

---

S 5.2.
>>      the registrar using some mechanism.  Such mechanisms are outside the
>>      scope of this document, but could be implemented e.g., using the
>>      SIPregistration event package mechanism [RFC3680].
>>
>>      When the proxy receives an indication that the UA needs to send a
>>      binding-refresh REGISTER request, the proxy requests a push
>
>You need to define what such an indication is.

As described in the paragraph above, the indication mechanism is outside the scope of the document. RFC 3680 can be used (and is given as an example), but there could also be other mechanisms.

---

S 5.2.
>>      scope of this document, but could be implemented e.g., using the
>>      SIPregistration event package mechanism [RFC3680].
>>
>>      When the proxy receives an indication that the UA needs to send a
>>      binding-refresh REGISTER request, the proxy requests a push
>>      notification towards the UA.
>
> "requests...towards" again

Will fix.

---

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?

---

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.

---

S 5.3.1.
>>
>>   5.3.  SIP Requests
>>
>>   5.3.1.  REGISTER
>>
>>      The procedures in this section apply when the SIP proxy receives a
>
>This section is incredibly hard to follow. Can you rewrite it with
>some sort of structure that reflects the logic of the proxy?

I'll see what I can do.

---

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.

---

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.

---

S 6.1.1.
>>
>>   6.1.  SIP UA Behavior
>>
>>   6.1.1.  Initial Request for Dialog
>>
>>      When the UA sends in initial request for a dialog, or a 2xx response
>
>"an initial request"

Will fix.

---

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.

---

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