Subject: [sipcore] More comments regarding draft-ietf-sipcore-sip-push-08

From: [email-masked] (Dale R. Worley)
Date: Sun, 18 Mar 2018 10:02:55 -0400

Catching up on the work, I've gone through
draft-ietf-sipcore-sip-push-08, and here are some small technical issues
and editorial matters:

sec 5.2 makes it sound like the proxy is required to wake up the UA if
the registration is close to expiration, even if the UA registered
with sip.pnsreg and the proxy responded with sip.pnsreg.  Is that
intended?  Because it sounds like the behavior of the proxy does not
change based on sip.pnsreg -- it wakes up the UA if the registration
is near expiration.  In which case, what does sip.pnsreg do?  As
compared with sec 4, where sip.pnsreg seems to be the way that the UA
and the proxy negotiate which one of them is reponsible for timing
registrations.

   5.3.1.  REGISTER Request

   Otherwise, if the pn-provider SIP URI parameter identifies a PNS that
   the proxy does not support, or if the REGISTER request does not
   contain all additional information required for the specific PNS, the
   proxy MUST either forward the request (e.g., if the proxy knows that
   a downstream proxy supports the PNS) or send a SIP 555 (Push
   Notification Service Not Supported) response to the REGISTER request.
   If the proxy sends a SIP 555 (Push Notification Service Not
   Supported) response, the proxy SHOULD insert a Feature-Caps header
   field with a 'sip.pns' feature-capability indicator in the response,
   identifying each PNS that the proxy supports.

I think you want to add:

   If the proxy receives a SIP 555 response to a REGISTER that it
   forwarded, it SHOULD insert such a 'sip.pns' feature-capability in
   the response before forwarding it to the UA, or if a 'sip.pns'
   feature-capability indicator already exists in the response, it
   SHOULD add to the indicator identifications of each PNS that the
   proxy supports that is not already present in the indicator.

That way, if an upstream proxy generates a 555 response that lists one
PNS, then this proxy can add to sip.pns the tag for the PNS that it
supports, and the UA will be informed of both PNSs.

It might be worth splitting the error code for "push notification
service not supported" (section 5.3.1) from "push notification failed"
(section 5.3.2).  Given that the proposed text for 555 doesn't
actually describe the usage in section 5.3.2, perhaps that usage
should be changed to 556.

More editorial items:

sec 1

   The UA
   will provide the PRID to the SIP proxy that will request push
   notifications towards the UA in a REGISTER request.

"in a REGISTER request" seems to be not well anchored here, as it
seems like it might attach to either "provide" or "request".  Perhaps
this is clearer:

   The UA will use a REGISTER request to
   provide the PRID to the SIP proxy that will request push
   notifications towards the UA.

sec 4

   In addition, if the response contains a Feature-Caps header field
   with a 'sip.vapid' feature-capability indicator, the UA can use the
   Voluntary Application Server Identification VAPID) mechanism
   [RFC8292] to restrict push notifications to the proxy (assuming that
   the PNS supports VAPID).

I think you want to be more explict that 'sip.vapid' only indicates
that the proxy supports VAPID.  Perhaps:

   In addition, if the response contains a Feature-Caps header field
   with a 'sip.vapid' feature-capability indicator, the proxy supports
   use of the Voluntary Application Server Identification VAPID)
   mechanism [RFC8292] to restrict push notifications to the proxy.
   However, the use of VAPID also requires that the PNS supports
   VAPID, and determining that is the responsibility of the UA, not
   the proxy.

5.2.  Trigger Periodic Re-registration

   The proxy either needs to be the SIP registrar, or the proxy needs to
   retrieve the information from the registrar using some other
   mechanism.  Such mechanisms are outside the scope of this document.

I think that "other" should be removed.  Since there is no preceding
mechanism mentioned, the mechanism mentioned in this sentence cannot
be "other" relative to a preceding mechanism.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 18 Mar 2018 20:18:23 +0000

Hi Dale,

Thanks for your review! Please see inline.

> sec 5.2 makes it sound like the proxy is required to wake up the UA if the registration is 
>close to expiration, even if the UA registered with sip.pnsreg and the proxy responded 
>with sip.pnsreg.  Is that intended?  Because it sounds like the behavior of the proxy does 
>not change based on sip.pnsreg -- it wakes up the UA if the registration is near expiration.  
>In which case, what does sip.pnsreg do?  As compared with sec 4, where sip.pnsreg seems 
>to be the way that the UA and the proxy negotiate which one of them is reponsible for 
>timing registrations.

The difference in proxy behaviour is that, in case of sip.pnsreg, the proxy waits until the "last minute" (120 seconds) for a re-registration before it triggers a notification request. This should only happen in error cases, where the UA has indicated that it will send re-registrations but don't. In normal cases the UA will send re-registrations, and there will be no need for the proxy to request push notifications.

> That way, if an upstream proxy generates a 555 response that lists one PNS, then 
> this proxy can add to sip.pns the tag for the PNS that it supports, and the UA will 
> be informed of both PNSs.

Good point. We can do that.

> It might be worth splitting the error code for "push notification service not supported" (section 5.3.1) 
> from "push notification failed" (section 5.3.2).  Given that the proposed text for 555 doesn't actually 
> describe the usage in section 5.3.2, perhaps that usage should be changed to 556.

I agree that would be useful. We can do that.

> More editorial items:
>
> sec 1
>
>   The UA will provide the PRID to the SIP proxy that will request push
> "in a REGISTER request" seems to be not well anchored here, as it seems like it might attach to either "provide" or "request".  Perhaps this is clearer:
>

Looks good. I will change as suggested.

> I think you want to be more explict that 'sip.vapid' only indicates that the proxy supports VAPID.  Perhaps:
>

Looks good. I will change as suggested.

> I think that "other" should be removed.  Since there is no preceding mechanism 
> mentioned, the mechanism mentioned in this sentence cannot be "other" relative 
> to a preceding mechanism.

I can remove "other".

Thanks!

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Sun, 25 Mar 2018 20:52:18 -0400

Christer Holmberg <[email-masked]> writes:
>> sec 5.2 makes it sound like the proxy is required to wake up the UA
>>if the registration is close to expiration, even if the UA registered
> The difference in proxy behaviour is that, in case of sip.pnsreg, the
> proxy waits until the "last minute" (120 seconds) for a
> re-registration before it triggers a notification request. This should
> only happen in error cases, where the UA has indicated that it will
> send re-registrations but don't. In normal cases the UA will send
> re-registrations, and there will be no need for the proxy to request
> push notifications.

I can understand that.  But it seems to me that it would be better to
soften this to MAY rather than MUST, so that if the proxy and UA
negotiate sip.pnsreg, then the proxy doesn't need to keep state to
monitor registration refreshes.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 26 Mar 2018 07:21:33 +0000

Hi,

>monitor registration refreshes.

I can change to MAY.

Regards,

Christer