Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-sip-push - Martin's comments

From: [email-masked] (Dale R. Worley)
Date: Mon, 05 Feb 2018 23:42:52 -0500

Christer Holmberg <[email-masked]> writes:
>> This document addresses a serious shortcoming.  For a long time, we
>> have had SIP UAs on mobile devices that are privileged by virtue of
>> being developed and installed by the device vendor, but the nature of
>> these platforms makes developing an alternative UA impossible.
>>
>> But it swaps one type of vendor lock-in for another.  This is a rare
>> case of a (intended for) proposed standard document enshrining
>> proprietary protocols into the RFC >series.  And only proprietary
>> protocols.  No definition is added for RFC 8030, despite that having
>> a well-documented (and deployed) protocol.
>
> If you can provide pointers to RFC 8030-based services, I would love
> to include them. I assume the Mozilla Push Service is one of them?

I think a better way to look at this is that the document as it stands
assumes that there are a small number of "services", identified by
pn-provider tags.  In a sense, that's automatically "proprietary".

Consider the alternative world where we wanted to define a way for there
to be any number of RFC 8030-based services that a UA could use.  In
order to use the current architecture in the naive way, each service
would have to define a separate pn-provider tag, and the mapping between
tags and server addresses/URLs/whatever would be arbitrary.

Then again, one could define a tag that indicated an RFC 8030 service,
but it also required that the pn-prid would start with a component
that addressed the RFC 8030 service in question.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Feb 2018 04:49:00 +0000

Hi,

> I  think a better way to look at this is that the document as it stands assumes that there are a small number of "services", 
> dentified by pn-provider tags.  In a sense, that's automatically "proprietary".
>
> Consider the alternative world where we wanted to define a way for there to be any number of RFC 8030-based services that a UA could use.  In order to use the current 
> architecture in the naive way, each service would have to define a separate pn-provider tag, and the mapping between tags and server addresses/URLs/whatever would be > arbitrary.
>
> Then again, one could define a tag that indicated an RFC 8030 service, but it also required that the pn-prid would start with a component that addressed the RFC 8030 
> service in question.

RFC 8030 is not a service - it is a mechanism that can be used to implement a push notification service. So, in my opinion the pn-provider tag should indicate e.g., "Mozilla" - not "RFC 8030".

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Tue, 6 Feb 2018 16:17:26 +1100

> RFC 8030 is not a service - it is a mechanism that can be used to implement a push notification service. So, in my opinion the pn-provider tag should indicate e.g., "Mozilla" - not "RFC 8030".

You don't need to identify the provider.  That's the category error
here.  You need to identify the means by which the information you
have been given can be used.  So identifying RFC 8030 is the right
thing.

BTW, FCM supports RFC 8030.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Feb 2018 05:26:49 +0000

Hi,

>> RFC 8030 is not a service - it is a mechanism that can be used to implement a push 
>> notification service. So, in my opinion the pn-provider tag should indicate e.g., "Mozilla" >> - not "RFC 8030".
>
> You don't need to identify the provider.  That's the category error here.  You need to 
> identify the means by which the information you have been given can be used.  So 
> identifying RFC 8030 is the right thing.

So, if a proxy indicates that it supports "RFC 8030", can the UA assume that the proxy has all credentials etc needed in order to request push notifications from any 8030-based notification service, and that the proxy will always know from which 8030-based notification service to request the push notification when a request arrives?

>BTW, FCM supports RFC 8030.

Thanks!

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Tue, 6 Feb 2018 17:52:54 +1100

> So, if a proxy indicates that it supports "RFC 8030", can the UA assume that the proxy has all credentials etc needed in order to request push notifications from any 8030-based notification service…

For 8030 alone, yes.  But.

It's a more complicated question because the creation of a
subscription needs that information.  You haven't provided a way for
the UA to learn how the proxy will authenticate itself (see RFC 8292).
Some push services require this authentication and for the UA to
provide that authentication information when the subscription is
created.

I don't remember what the best way to do that in SIP would be.  An
INFO package perhaps?

>>BTW, FCM supports RFC 8030.

Full disclosure: FCM also insists on RFC 8292 authentication.  See above.

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 6 Feb 2018 15:17:02 +0000

Hi,

>>>> RFC 8030 is not a service - it is a mechanism that can be used to 
>>>> implement a push notification service. So, in my opinion the pn-provider tag should indicate e.g., "Mozilla" 
>>>> - not "RFC 8030".
>>>
>>> have been given can be used.  So identifying RFC 8030 is the right thing.
>>
>> So, if a proxy indicates that it supports "RFC 8030", can the UA assume that the proxy has all credentials etc needed 
>> in order to request push notifications from any 8030-based notification service, and that the proxy will always know 
>> from which 8030-based notification service to request the push notification when a request arrives?
>
> It's a more complicated question because the creation of a subscription needs that information.  You haven't provided 
> a way for the UA to learn how the proxy will authenticate itself (see RFC 8292).
> Some push services require this authentication and for the UA to provide that authentication information when the subscription is created.
>
> I don't remember what the best way to do that in SIP would be.  An INFO package perhaps?

It is true that push services require the proxy to be authenticated by the push service. And, in case the UA needs to provide some information to the proxy in order to do that authentication, it can use the pn-param for that. When registering a new provider value, one needs to specify what (if any) additional information is provided by the UA to the proxy.

> Full disclosure: FCM also insists on RFC 8292 authentication.  See above.

As described in Section 10 of the push draft, a UA provides the registration token (pn-prid) and the sender id (pn-param) to the proxy. Is something additional needed?

Regards,

Christer

---

From: Martin Thomson <[email-masked]>
Date: Wed, 7 Feb 2018 08:34:45 +1100

> It is true that push services require the proxy to be authenticated by the push service. And, in case the UA needs to provide some information to the proxy in order to do that authentication, it ca…

The other way around.  The proxy needs to provide its identity or
public key to the UA so that the UA can tell the push service who is
permitted to send messages.

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 7 Feb 2018 01:10:17 +0000

Hi,

>> It is true that push services require the proxy to be authenticated by the push service. And, in case the 
>> UA needs to provide some information to the proxy in order to do that authentication, it can use the 
>> pn-param for that. When registering a new provider value, one needs to specify what (if any) additional 
>> information is provided by the UA to the proxy.
>
> The other way around.  The proxy needs to provide its identity or public key to the UA so that the UA can tell the 
> push service who is permitted to send messages.

We could define a feature-capability indicator that the proxy can insert in the REGISTER response, in order to provide the information to the UA.

Regards,

Christer