Subject: Re: [sipcore] Comments regarding sip-push registration - Editorial Comments & Pull Request

From: Christer Holmberg <[email-masked]>
Date: Tue, 2 Jan 2018 10:42:14 +0000

Hi,

Below are my replies to Dale¹s editorial comments.

>* Editorial things
>
>The capitalization of the section titles is inconsistent.

I¹ll fix that.

---

>   When the SIP proxy receives a SIP request for a new session, or a
>
>s/session/dialog/
>
>   the SIP proxy will send a push request to the push notification
>   service used by the SIP UA, using the push resource ID associated
>   with the registered contact of the SIP UA, in order to trigger a push
>   notification towards the SIP UA.  The SIP proxy will then forward the
>   SIP request towards the SIP UA using normal SIP routing procedures.
>   Once the SIP UA receives the push notification, it will be to receive
>   the SIP request, and to generate a SIP request (e.g., a SIP REGISTER)
>   itself.
>
>This description is incomplete, as it leaves out the step between the
>first and second sentences, "the proxy waits to receive a
>re-registration from the UA".  The other descriptions of the process
>for sending requests to the UA need to be checked for this as well.

The proxy procedures section says that the proxy can forward the request
once it receives the REGISTER request. I will add that to the Introduction
too.

---

>The abbreviation "pn-prid" is redundant, as it means "push
>notification - push registration id".  Perhaps reduce it to "pn-rid"
>or "pn-id".

I¹d prefer to keep pn-prid, in order to associate it with ³PRID".

---

>   The format of the PRID may vary depending on the PNS provider.  The
>   PRID may be part of a URI that can be used to retrieve the address
>   and port of the PNS when sending push requests to the PNS.  The PRID
>   may also be a token value, in which case the address and port of the
>   PNS needs to be provided using other means.
>
>It's not clear what "may be part of a URI" means, since just about any
>string could be part of a URI.  In any case, the format of the PRID is
>outside the scope of this document; from our point of view, it's an
>opaque string.  The only real restriction is that it's a sequence of
>Unicode characters and can be represented as a quoted-string (RFC 3261
>section 25.1).

If the text is unclear, I can remove it, and simply keep the
depending-on-the-PNS-provider sentence.

>   If the SIP UA at some point wants to stop the SIP proxy from sending
>   push requests, the SIP UA MUST send a SIP REGISTER request without
>   the pn-prid and pn-type URI parameters.
>
>It should be added, "or remove the registration".

I¹ll add that.

---

>   If the SIP UA expects to receive payload in the push notification,
>   the SIP UA MAY add a pn-enckey and a pn-encsec Contact header field
>   URI parameter, in order to allow encryption of the data using the
>   mechanism in [I-D.ietf-webpush-encryption].  The pn-enckey URI
>   parameter contains the public key, and the pn-encsec URI parameter
>   contains the authentication secret [I-D.ietf-webpush-encryption].
>
>Need to mention that the format and use of such a payload is outside
>the scope of this document; all we're doing here is defining the
>parameters that make such payloads possible.

I¹ll add that.

---

>   In some cases the push notification provider can be retrieved from
>   the pn-prid URI parameter.  In other cases the pn-type URI parameter
>   is used to identity the push notification provider.
>
>Exactly how you retrieve Apple Corp. from the parameters is unclear; I
>know of no media-type for Apple Corp.
>I think you mean, "Together, the pn-prid and pn-type parameters
>suffice to identify which push notification provider is to be used and
>how to direct it to notify the UA."

I believe the text has been removed in version -02.

---

>   If the proxy is not able to contact the push notification provider,
>   or even determine which push notification provider to contact, it
>   SHOULD reject the SIP request.
>
>This sentence conflates two situations that should be handled
>differently.  If the redirector is unable to contact the push
>notification provider, it must necessarily reject the request.  (Do we
>need to define a 4xx code to indicate that?)  If the redirector is
>unable to determine the push notification provider, it is able to
>detect that during registration, and the REGISTER should have been
>rejected.

I will s/SHOULD/MUST, and remove the unable-to-determine-the-provider part.

---

>    It is currently suggested (see pull request in other e-mail) that
>    a proxy that receives a SIP REGISTER request with pn- parameters
>    for a PNS provider it does not support sends a 501 (Not
>    Implemented) response code.
>
>    The question is whether it would be useful to define a
>    PNS-specific response code for this? E.g., 514 (Push Notification
>    Service Not Supported). In addition, we could define a feature
>    capability indicator that could be added to the response and list
>    the PNS providers supported by the proxy.
>
>And also,
>
>    I have updated the pull request by adding a new SIP response code,
>    555 (Push Notification Service Not Supported).
>
>Defining 514/555 like this doesn't really help, because the baseline
>incompatibility case is when the registrar/redirector doesn't
>understand the push notification mechanism at all, and happily
>provides an ordinary registration when the UA wanted a
>push-notification registration.  See comments about an option-tag
>above.

The -02 version now contains text saying that the proxy will insert a
feature capability indicator in the REGISTER 200 response. That will be an
indicator to the UA that the feature is supported.

Pull Request: https://github.com/cdh4u/draft-sip-push/pull/7

Regards,

Christer