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

[Christer Holmberg <[e-mail]>]

Hi,


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

Ok.

---

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.

SHOULD?

---

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.

Ok.

---

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

Ok, I will have a look.

---

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.

The first paragraph of section 5.2 does say it is out of scope.

---

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.

I will see what I can do.

---

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

There was another sec-dir/gen-art comment asking to add the web links to the reference section.

I will to that, but I have not yet found the XML way of doing it.

Regards,

Christer