Subject: [sipcore] SIP Push Suggested Change: UA indicating support of multiple PNS

From: Christer Holmberg <[email-masked]>
Date: Fri, 11 Jan 2019 12:27:29 +0000

Dear push lovers,

As part of the IESG review, Adam raised an issue that needs to be discussed on the list.

What is it about?

Adam suggested that a UA, when it does a query of network PNS support, should be allowed to indicate support of *multiple* PNS. Currently the pn-provider syntax only supports a single value, and the text is written assuming there is only a single value.

What would the change be?

Modify the pn-provider syntax to allow multiple value, and allow the UA, when it does a query, to indicate support of multiple PNS.

When the UA actually wants to use a PNS (and also includes its PRID), it would only indicate a single PNS - as currently defined in the draft.

The proxy procedures would remain the same, i.e., if the proxy supports a PNS indicated by the UA it inserts the associated parameters, and if it doesn't it sends a 555 response. The text would only be modified to indicate that the UA might include support of multiple PNS.

Does anyone have an issue with such modification?

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Fri, 11 Jan 2019 13:54:21 -0500

On Fri, Jan 11, 2019 at 7:28 AM Christer Holmberg <
[email-masked]> wrote:

> Modify the pn-provider syntax to allow multiple value, and allow the UA,
> when it does a query, to indicate support of multiple PNS.
>
>
> When the UA actually wants to use a PNS (and also includes its PRID), it
> would only indicate a single PNS - as currently defined in the draft.
>
>
> The proxy procedures would remain the same, i.e., if the proxy supports a
> PNS indicated by the UA it inserts the associated parameters, and if it
> doesn't it sends a 555 response. The text would only be modified to
> indicate that the UA might include support of multiple PNS.
>
>

I do not think this change would break anything and this can prove to be
useful in the future, especially when clients will try to migrate to a
newer version of the push notification service and will need to specify
support for both legacy and new service.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Jan 2019 16:01:57 -0500

On 1/11/19 1:54 PM, Roman Shpount wrote:
> On Fri, Jan 11, 2019 at 7:28 AM Christer Holmberg 
> <[email-masked] <mailto:[email-masked]>> 
> wrote:
> 
>     Modify the pn-provider syntax to allow multiple value, and allow the
>     UA, when it does a query, to indicate support of multiple PNS.
> 
> 
>     When the UA actually wants to use a PNS (and also includes its
>     PRID), it would only indicate a single PNS - as currently defined in
>     the draft.
> 
> 
>     The proxy procedures would remain the same, i.e., if the proxy
>     supports a PNS indicated by the UA it inserts the associated
>     parameters, and if it doesn't it sends a 555 response. The text
>     would only be modified to indicate that the UA might include support
>     of multiple PNS.
> 
> 

This is introducing a negotiation between client and the network servers 
to find a mutually supported PNS. IMO this is a good thing, because both 
clients and networks are likely to support multiple, and the one(s) 
mutually supported may not be known a priori.

But, as currently defined, it appears that this will require a *single* 
server in the network to support all the PNSs. ISTM that there may well 
be cases where a single server implementation doesn't support all PNSs, 
and to acquire support a provider may have to deploy multiple proxies to 
cover all the PNSs that clients might desire. This could be made to 
work, but the details of the protocol negotiation will need to be 
adjusted to do so.

Also, if client and provider have multiple PNSs in common, who should 
get to decide which one will be used?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 11 Jan 2019 21:22:18 +0000

Hi,

>get to decide which one will be used?

The suggestion is that the network chooses, and if different proxies support different PNSs the proxy that supports the chosen PNS will indicate the support.

Regards,

Christer

---

From: Roman Shpount <[email-masked]>
Date: Fri, 11 Jan 2019 16:24:59 -0500

On Fri, Jan 11, 2019 at 4:22 PM Christer Holmberg <
[email-masked]> wrote:

> The suggestion is that the network chooses, and if different proxies
> support different PNSs the proxy that supports the chosen PNS will indicate
> the support.
>

I suggest that client indicates PNS in order of its preference, but then
proxy will chooses only a single PNS based on the client and its own
preferences.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 11 Jan 2019 21:35:51 +0000

Hi,

>I suggest that client indicates PNS in order of its preference, but then proxy will chooses only a single >PNS based on the client and its own preferences.

That is my suggestion.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 11 Jan 2019 18:30:12 -0500

On 1/11/19 4:24 PM, Roman Shpount wrote:
> On Fri, Jan 11, 2019 at 4:22 PM Christer Holmberg 
>     support different PNSs the proxy that supports the chosen PNS will
>     indicate the support.
> 
> 

That still assumes that a single server supports all the PNSs.

If client supports X and Y with preference for X, while proxy A supports 
Y and later proxy B supports X, then the client won't get his preference.

And if proxy A supports Z and proxy B supports X and Y, according to 
current rules there will be no support at all.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 12 Jan 2019 11:48:54 +0000

Hi,

>current rules there will be no support at all.

The text allows a proxy to forward the request to another proxy, based on local configuration.

So, proxy A can choose to not indicate support of its PNS, and instead forward the request to B, that will then indicate support of its PNS.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 12 Jan 2019 12:11:35 -0500

On 1/12/19 6:48 AM, Christer Holmberg wrote:

> So, proxy A can choose to not indicate support of its PNS, and instead 
> forward the request to B, that will then indicate support of its PNS.

The sneaky word there is "allows". And IIUC it should not do so unless 
it *knows* there is another push proxy downstream. There is no guarantee 
to the client that all of its supported PNSs will be *considered*.

The current mechanism was designed around the assumption that the client 
only offers one PNS. Changing to a system where the client can offer 
multiple PNSs should be accompanied by further consideration of how 
negotiation of which the PNS to use *should* work.

	Thanks,
	Paul