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

[Christer Holmberg <[e-mail]>]

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.

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

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

Looks good. I will change as suggested.

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

Looks good. I will change as suggested.

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

I can remove "other".

Thanks!

Regards,

Christer