Subject: [sipcore] Draft new: draft-sip-push-00

From: Christer Holmberg <[email-masked]>
Date: Mon, 9 Oct 2017 13:48:54 +0000

Hi,

Since I did not hear anything from the author of
draft-ivanov-sipcore-pnsip, I¹ve submitted a draft
(draft-holmberg-sipcore-sip-push) which is based on that draft.

The holmberg draft contains more text, based on the list discussions and
comments.

One thing to note: while looking into different push notification
services, at least 2 commonly used ones do NOT provide a URI as the
subscription token. So, I¹ve kept the pn-type parameter, in order to
provide guidance on which push notification service is used.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Oct 2017 11:01:56 -0400

A couple of comments on this:

1) I'm a bit confused about the intended use of the URI parameters. On 
one hand these are included in the Contact-URI during registration. On 
the other hand, section 5 talks about the proxy checking for these 
parameters in the Request-URI, which in this case I take to mean the 
AoR. I would not expect to see these in the AoR. Please be more specific 
if the intent is that the proxy first does the request URI translation 
and *then* checks for these parameters.

2) Nowhere in here do I see any feedback mechanism from the 
proxy/registrar to the UA indicating that it actually supports this 
mechanism. ISTM that this calls for an option tag mechanism, with 
Require:push in the register request and a Supported:push in the response.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 10 Oct 2017 17:07:56 +0000

Hi Paul,

Thanks for your comments! See inline.

> 1) I'm a bit confused about the intended use of the URI parameters. On one hand these are included in the 
> Contact-URI during registration. On the other hand, section 5 talks about the proxy checking for these parameters 
> in the Request-URI, which in this case I take to mean the AoR. I would not expect to see these in the AoR. 
> Please be more specific if the intent is that the proxy first does the request URI translation and *then* checks for these parameters.

I refer to the Request-URI of the INVITE request, which will be the Contact-URI from the REGISTER. I will make sure that is clear in the text.

> 2) Nowhere in here do I see any feedback mechanism from the proxy/registrar to the UA indicating 
> that it actually supports this mechanism. ISTM that this calls for an option tag mechanism, with 

I was thinking of defining feature capability indicators for that. However, I wanted to submit the initial version, to see whether people have any interest to work on this in IETF to begin with.

Regards,

Christer

On 10/9/17 9:48 AM, Christer Holmberg wrote:
> The holmberg draft contains more text, based on the list discussions 
> and comments.
> 

_______________________________________________
sipcore mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sipcore

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 10 Oct 2017 14:41:33 -0400

Hi Christer,

> I refer to the Request-URI of the INVITE request, which will be the Contact-URI from the REGISTER. I will make sure that is clear in the text.

Thanks.

> I was thinking of defining feature capability indicators for that. However, I wanted to submit the initial version, to see whether people have any interest to work on this in IETF to begin with.

IMO an options tag works better here. Presumably the UA will be 
requesting this with the initial REGISTER, and won't be able to function 
if the feature isn't supported. The use of Require does exactly the 
right thing here.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 Oct 2017 07:54:04 +0000

Hi Paul,

…

>>>proxy/registrar to the UA indicating
>> I was thinking of defining feature capability indicators for that.
>>However, I wanted to submit the initial version, to see whether people
>>have any interest to work on this in IETF to begin with.
>

We need to keep in mind that it is not enough to indicate support of the
mechanism as such, you also need to indicate which push notification
providers (Apple, Firebase etc) you support, as the push request sent by
the proxy looks different for each of them.

So, I have been thinking that we probably would need a registry for the
type, which contains the type value (e.g., “APNS” for Apple) together with
a reference to the procedures. Also, in addition to the token, some
providers may require additional information to be sent from the device to
the proxy, so we may need an attribute to allow for that.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 11 Oct 2017 12:07:39 -0400

> the proxy, so we may need an attribute to allow for that.

That would make sense to me if the intent is that the client is going to 
search for a proxy to use that will support his need. But I doubt that 
is the use case.

Rather, I infer that the client will typically have no choice in what 
proxy is used, and so will be stuck with whatever it supports. Hence 
what is really important is just to indicate what he needs and get 
feedback as to whether it is supported. The option tag mechanism, 
together with the parameters indicating the desired push service, will 
achieve that.

The advantage over feature tags is that the REGISTER can outright fail 
if the feature isn't supported, in a way that can be understood by the 
UA. Using feature tags I think the REGISTER will succeed and then the UA 
will have to decide whether it can proceed without push support. If that 
is the desired outcome then feature tags may be fine.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 11 Oct 2017 17:43:36 +0000

Hi,

>>>> However, I wanted to submit the initial version, to see whether 
>>>> people have any interest to work on this in IETF to begin with.
>>>
>>> requesting this with the initial REGISTER, and won't be able to 
>>> function if the feature isn't supported. The use of Require does 
>>> exactly the right thing here.
>> 
>> We need to keep in mind that it is not enough to indicate support of 
>> the mechanism as such, you also need to indicate which push 
>> notification providers (Apple, Firebase etc) you support, as the push 
>> request sent by the proxy looks different for each of them.
>> 
>> So, I have been thinking that we probably would need a registry for 
>> the type, which contains the type value (e.g., "APNS" for Apple) 
>> together with a reference to the procedures. Also, in addition to the 
>> token, some providers may require additional information to be sent 
>> from the device to the proxy, so we may need an attribute to allow for that.
>
> That would make sense to me if the intent is that the client is going to search for a proxy to use that 
> will support his need. But I doubt that is the use case.
>
> Rather, I infer that the client will typically have no choice in what proxy is used, and so will be stuck with whatever it supports.

Clients can typically not choose what notification service to use. For example, an iOS device can only register to, and receive push notifications from, the Apple APNS.

So, it's not about choosing a proxy, but the client needs to know whether the proxy supports a particular push service.

Of course, if the proxy does not support the push service indicated by the client, it could reject the REGISTER request, but I am not sure we want to mandate that.  For example, the operator may still want to allow the client to register, and being able to make outgoing calls (e.g., emergency calls), even if the device won't be able to receive incoming calls.

Regards,

Christer