Subject: [sipcore] -push

From: Brian Rosen <[email-masked]>
Date: Mon, 12 Mar 2018 13:52:01 +0000

There was a lot of discussion during the WGLC on push. Does everyone think
their issues are dealt with satisfactorily I the latest draft?

Brian

---

From: Mickey Arnold <[email-masked]>
Date: Mon, 12 Mar 2018 14:14:16 +0000

Hi Brian,

The latest draft addresses all issues and concerns I raised during WGLC.

Thanks, Mickey

From: sipcore [mailto:[email-masked]] On Behalf Of Brian Rosen
Sent: 12 March 2018 13:52
To: SIPCORE <[email-masked]>
Subject: [sipcore] -push

There was a lot of discussion during the WGLC on push. Does everyone think their issues are dealt with satisfactorily I the latest draft?

Brian

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Mar 2018 14:34:23 +0000

My concerns about there only being proprietary push service providers remain.

On Mon, Mar 12, 2018 at 1:52 PM, Brian Rosen <[email-masked]> wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Brian Rosen <[email-masked]>
Date: Mon, 12 Mar 2018 11:02:25 -0400

Can we explore that a bit:
The “non-proprietary” that exists is RFC8030.
But the implementations of 8030 would need other things to work.
So to make sip-push work with 8030 would mean a bunch of other mechanisms.

Is there actual need (i.e. implementations) for 8030 based push?

Otherwise, while I understand your concern, it would seem that someone other than Christer should, if they want to, write a draft that would extend push to work with 8030 in practical implementations, pulling in other work to make it actually work.

Or did I miss something?  My writeup will reflect this objection, so the IESG will be aware of it.

Brian

> On Mar 12, 2018, at 10:34 AM, Martin Thomson <[email-masked]> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Mar 2018 15:11:51 +0000

You could implement a SIP UA in a browser.  I don't know whether this
WebRTC thing will take off, but it seems both plausible and useful.

What "other things" do you refer to specifically?  I think that it just works.

The pieces that 8030 needs are partly in place.  Christer added a
VAPID reference.  He removed the additional elements necessary to
convey keys. I think that was because this is only a poke and the poke
carries no information (and therefore, by 8030, does not need all the
encryption bits).

I object pretty strongly to this work defining proprietary-only
solutions when a standardized solution exists.

---

From: Brian Rosen <[email-masked]>
Date: Mon, 12 Mar 2018 11:24:41 -0400

My confusion: the reference was to RFC8292, but that’s VAPID and it’s in there.

Given VAPID is covered, what would we need beyond an explicit reference to 8030?

Brian
> On Mar 12, 2018, at 11:11 AM, Martin Thomson <[email-masked]> wrote:
>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Mar 2018 15:28:13 +0000

> Given VAPID is covered, what would we need beyond an explicit reference to 8030?

A definition for pn-provider is probably all right now.  Plus a
paragraph of text to support it.  I'd probably add an explanation for
why the encryption pieces aren't needed.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Mar 2018 15:30:06 +0000

Hi Martin,

You previously said "FCM supports RFC 8030". I thought that meant that FCM is based on RFC 8030, i.e. a standardized solution :)

But, I have no problem to include a registration for a generic "RFC8030" service.

Since you are the author of RFC 8030, are you able to put provide the registration information? See sections 9 and 10 for examples.

Regards,

Christer

-----Original Message-----
From: sipcore [mailto:[email-masked]] On Behalf Of Martin Thomson
Sent: 12 March 2018 17:12
To: Brian Rosen <[email-masked]>
Cc: SIPCORE <[email-masked]>
Subject: Re: [sipcore] -push

You could implement a SIP UA in a browser.  I don't know whether this WebRTC thing will take off, but it seems both plausible and useful.

The pieces that 8030 needs are partly in place.  Christer added a VAPID reference.  He removed the additional elements necessary to convey keys. I think that was because this is only a poke and the poke carries no information (and therefore, by 8030, does not need all the encryption bits).

I object pretty strongly to this work defining proprietary-only solutions when a standardized solution exists.

On Mon, Mar 12, 2018 at 3:02 PM, Brian Rosen <[email-masked]> wrote:
>>> There was a lot of discussion during the WGLC on push. Does everyone 
>>> think their issues are dealt with satisfactorily I the latest draft?
>>>
>>> Brian
>>>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Mar 2018 15:34:36 +0000

FCM supports 8030 in addition to its proprietary interface(s).

~~~

   The value of the pn-provider URI parameter is "webpush".

   The value of the pn-param URI parameter is the subscription URI.

    The pn-prid URI parameter is not used and MUST be ignored if present.

    See RFC 8030 for details.  Note that encryption for web push
[RFC8291] is not used, therefore parameters for message encryption are
not defined in this specification.  Web push permits the sending of a
push message without a payload without encryption.

---

From: Brian Rosen <[email-masked]>
Date: Mon, 12 Mar 2018 11:36:36 -0400

If that gets into the draft, what else do we need?

Brian

> On Mar 12, 2018, at 11:34 AM, Martin Thomson <[email-masked]> wrote:
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Mar 2018 15:36:41 +0000

Thanks! :)

Regards,

Christer

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: 12 March 2018 17:35
To: Christer Holmberg <[email-masked]>
Cc: Brian Rosen <[email-masked]>; SIPCORE <[email-masked]>
Subject: Re: [sipcore] -push

~~~

    See RFC 8030 for details.  Note that encryption for web push [RFC8291] is not used, therefore parameters for message encryption are not defined in this specification.  Web push permits the sending of a push message without a payload without encryption.

On Mon, Mar 12, 2018 at 3:30 PM, Christer Holmberg <[email-masked]> wrote:
> Hi Martin,
>
> You previously said "FCM supports RFC 8030". I thought that meant that 
> FCM is based on RFC 8030, i.e. a standardized solution :)
>
>>>> There was a lot of discussion during the WGLC on push. Does 
>>>> everyone think their issues are dealt with satisfactorily I the latest draft?
>>>>
>>>> Brian
>>>>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Mar 2018 15:38:19 +0000

Hi Brian,

>If that gets into the draft, what else do we need?

I will add a new section (similar to sections 9 and 10), and add "webpush" to the table in section 12.5.

Regards,

Christer

>> You previously said "FCM supports RFC 8030". I thought that meant 
>> that FCM is based on RFC 8030, i.e. a standardized solution :)
>>

---

From: Martin Thomson <[email-masked]>
Date: Mon, 12 Mar 2018 15:39:20 +0000

I'd have to do a proper review.  And since I just flew half way around
the planet, I'm not sure when that happens.

---

From: Brian Rosen <[email-masked]>
Date: Mon, 12 Mar 2018 11:41:23 -0400

Okay.  When it’s out, and you can do so, please let us know.

Brian
> On Mar 12, 2018, at 11:39 AM, Martin Thomson <[email-masked]> wrote:
>

---

From: Roman Shpount <[email-masked]>
Date: Mon, 12 Mar 2018 13:55:53 -0400

Hi All,

I have couple of issues with this darft:

The first minor issue, is regarding what is supposed to happen when
registration expires interval is too short for push notification to be
successfully delivered. For instance should proxy refuse registrations with
expires set to value which is too small or should it not enabled push
support? Specifically, what happens when a new Registration with Expires
less then 120 is received by the proxy? If the group agrees what should
happen here (refuse registration, refuse push support, do not send push
notification), I can write a pull request.

The bigger issue for me is  regarding how this draft interacts with RFC
5626. Is this a replacement, independent document, or an update?

I think SIP push should really be used in conjunction with RFC 5626 and new
draft should update how RFC 5626 flows are managed. Specifically, section
5.3.2 should not be about initial dialog or stand-alone requests. It should
be tied to the existence of RFC 5626 flows to the client UA. If flow
exists, then it should be used for the request. If no flow is present, SIP
push notification should be initiated to create the flow. At the same time,
procedures in RFC 5626 for flow maintenance and recovery should be updated
to use sip push.

Regards,

_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Mar 2018 18:10:42 +0000

Hi,

> The first minor issue, is regarding what is supposed to happen when registration expires interval is too 
> short for push notification to be successfully delivered. For instance should proxy refuse registrations with 
> expires set to value which is too small or should it not enabled push support? Specifically, what happens 
> when a new Registration with Expires less then 120 is received by the proxy? If the group agrees what should 
> happen here (refuse registration, refuse push support, do not send push notification), I can write a pull request.

My suggestion is to either refuse the registration, or refuse push support, based on local policy.

I don't think we should negotiate push, but then not send push notification.

---

> The bigger issue for me is  regarding how this draft interacts with RFC 5626. Is this a replacement, independent document, or an update?

This is an independent document.

> I think SIP push should really be used in conjunction with RFC 5626 and new draft should update how RFC 5626 flows are 
> managed. Specifically, section 5.3.2 should not be about initial dialog or stand-alone requests. It should be tied to the existence 
> of RFC 5626 flows to the client UA. If flow exists, then it should be used for the request. If no flow is present, SIP push notification 
> should be initiated to create the flow. At the same time, procedures in RFC 5626 for flow maintenance and recovery should be 
> updated to use sip push.

You don't need RFC 5626 in order to use push, and the draft was never intended to update RFC 5626.

Having said that, if there is interest, we can write a separate draft on using push together with RFC 5626, and describe how the existence/non-existence of flows can impact push notifications.

Regards,

Christer

Brian

---

From: Roman Shpount <[email-masked]>
Date: Mon, 12 Mar 2018 14:33:22 -0400

On Mon, Mar 12, 2018 at 2:10 PM, Christer Holmberg <
[email-masked]> wrote:

> registration expires interval is too
> support? Specifically, what happens

Do you need me to write a pull request or would you add the appropriate
text?

> This is an independent document.

I can see that treating this as an independent document helps moving this
draft to completion quicker, so this is a good reason to keep this
independent.

> > I think SIP push should really be used in conjunction with RFC 5626 and
> new draft should update how RFC 5626 flows are
> > managed. Specifically, section 5.3.2 should not be about initial dialog
> or stand-alone requests. It should be tied to the existence
> > of RFC 5626 flows to the client UA. If flow exists, then it should be
> used for the request. If no flow is present, SIP push notification
> > should be initiated to create the flow. At the same time, procedures in
> RFC 5626 for flow maintenance and recovery should be
> > updated to use sip push.
>
> Having said that, if there is interest, we can write a separate draft on
> using push together with RFC 5626, and describe how the
> existence/non-existence of flows can impact push notifications.
>

Do you think sip push would ever be used without RFC 5626 or would these
two be always deployed together? As it stands, I think these documents are
not consistent with each other and RFC 5626 needs an update to make it work
with sip push.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Mar 2018 18:34:03 +0000

Hi,

I have created a pull request, adding webpush.

I had a look at RFC 8030, and I modified the information that is added to pn-prid and pn-param, because I think both are needed. Please have a look.

https://github.com/cdh4u/draft-sip-push/pull/14

Regards,

Christer

-----Original Message-----
From: Martin Thomson [mailto:[email-masked]] 
Sent: 12 March 2018 17:35
To: Christer Holmberg <[email-masked]>
Cc: Brian Rosen <[email-masked]>; SIPCORE <[email-masked]>
Subject: Re: [sipcore] -push

~~~

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 12 Mar 2018 18:44:02 +0000

Hi,

> Do you need me to write a pull request or would you add the appropriate text?

I assume it's just a few sentences in one place, so I guess you can provide text in an e-mail reply.

(But, if you prefer a pull request, that works too).

---

> I can see that treating this as an independent document helps moving this draft to completion quicker, so this is a good reason to keep this independent. 

Thanks!

>> Having said that, if there is interest, we can write a separate draft on using push together with RFC 5626, and describe 
>> how the existence/non-existence of flows can impact push notifications.
>
> Do you think sip push would ever be used without RFC 5626 or would these two be always deployed together? 

I KNOW that sip push will be used without RFC 5626 :)

> As it stands, I think these documents are not consistent with each other and RFC 5626 needs an update to make it work with sip push.

We would have to look into that, and the best way as far as documentation is concerned.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Mar 2018 10:55:01 +0000

Hi,

>>>> short for push notification to be successfully delivered. For
>>>>instance should proxy refuse registrations with
>>>> happen here (refuse registration, refuse push support, do not send
>>>>push notification), I can write a pull request.
>>>>

What about the following text:

   "If the proxy considers the requested registration expiration interval
(RFC3261) to be too short, the
    proxy MUST either send a 423 (Internal Too Brief) response to the
REGISTER request or skip the rest
    of the procedures in this section, and process the REGISTER request
using normal SIP procedures.
    Similarly, when the proxy receives a 2xx response to the REGISTER
request, if the proxy considers
    the registration expiration internal indicated by the registrar too
short, the proxy MUST NOT insert
    a Feature-Caps header field with a 'sip.pns' feature-capability
indicator in the response, and the
    Proxy MUST NOT request push notifications associated with the
registration.

    NOTE: A registration expiration interval is considered too short if
the interval is smaller than the
    time prior to expiration when the proxy requests a push notification.²

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Mar 2018 11:17:33 +0000

Pull request:

https://github.com/cdh4u/draft-sip-push/pull/15

Regards,

Christer

On 13/03/18 12:55, "Christer Holmberg" <[email-masked]>
wrote:

>If the proxy considers the requested registration expiration interval

---

From: Roman Shpount <[email-masked]>
Date: Tue, 13 Mar 2018 13:33:49 -0400

Looks good.
This clears all my issues for this draft.

Regards,

_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Mar 2018 18:57:02 +0000

Thanks, Roman!

Regards,

Christer

From: Roman Shpount [mailto:[email-masked]]
Sent: 13 March 2018 19:34
To: Christer Holmberg <[email-masked]>
Cc: SIPCORE <[email-masked]>
Subject: Re: [sipcore] -push

Looks good.

Regards,

_____________
Roman Shpount

On Tue, Mar 13, 2018 at 7:17 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Pull request:

Regards,

Christer

---

From: [email-masked] (Dale R. Worley)
Date: Sat, 17 Mar 2018 08:48:10 -0400

> their issues are dealt with satisfactorily I the latest draft?

In my mind there are a considerable number of open issues.  Part of the
problem is that I'm just not caught up on the conversation, but I'm
pretty sure that another part is that I don't see the problem space
we're addressing clearly, and quickly looking at the latest draft, I
don't see that it lays out the constraints that the solution has to work
within.  Because of that vagueness, I am not comfortable with some of
the less-elegant/consistent parts of the proposal are truly needed, that
we may be able to produce a better mechanism.

The first step to solving this is for me to get caught up on the
discussion, which I am starting to to.

However, one open point is this question I had, which I don't think has
been sufficiently addressed.  The problem is that the current scheme
requires that the implementing proxy be able to see any re-REGISTER that
the device produces, which argues that the proxy must be very central to
the SIP service for the SIP domain.  And yet some aspects of the scheme
seem to be required only because the proxy is *not* central to the SIP
service, in particular, that the proxy has no visibility into the AOR to
which an incoming request is directed.  This suggests that the proxy is
"downstream" from the domain's redirector, which seems to be in conflice
that the proxy can see evern REGISTER for the domain.

    Re: [sipcore] SIP-push -- Where is the "proxy"?
    Date: Thu, 08 Mar 2018 22:22:29 -0500

    On one hand, as you say, the proxy can be in the path of the REGISTER.
    That requires that the proxy be "near" the registrar, so that any
    REGISTER for the AOR will necessarily pass through the proxy as well.
    But that pretty much requires that the proxy be attached to the
    registrar, as otherwise REGISTERs can take routes to the registrar that
    miss the proxy.

    (I particularly imagine the WiFi/cellular use case that Roman mentions,
    which has been a huge market target for over 10 years.  In that case,
    the phone can easily re-REGISTER on an entirely different network than
    it was previously registered through.)

    But if the proxy is "near the edge", it needs a way to wait for the
    re-REGISTER that doesn't require it to process the re-REGISTER.  I think
    that this can be done by it subscribing to the 'reg' package for the
    AOR, but that requires that the R-URI that it sees in the incoming
    request to somehow carry the AOR.

Dale

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 17 Mar 2018 13:08:46 +0000

Hi,

> In my mind there are a considerable number of open issues.  Part of the problem is that I'm just not caught
> up on the conversation, but I'm pretty sure that another part is that I don't see the problem space we're addressing 
> clearly, and quickly looking at the latest draft, I don't see that it lays out the constraints that the solution has to work 
> within.  Because of that vagueness, I am not comfortable with some of the less-elegant/consistent parts of the proposal 
> are truly needed, that we may be able to produce a better mechanism.
>
> The first step to solving this is for me to get caught up on the discussion, which I am starting to to.
>
> However, one open point is this question I had, which I don't think has been sufficiently addressed.  The problem is that
> the current scheme requires that the implementing proxy be able to see any re-REGISTER that the device produces, which 
> argues that the proxy must be very central to the SIP service for the SIP domain.  And yet some aspects of the scheme seem 
> to be required only because the proxy is *not* central to the SIP service, in particular, that the proxy has no visibility into the 
> AOR to which an incoming request is directed.  This suggests that the proxy is "downstream" from the domain's redirector, 
> which seems to be in conflice that the proxy can see evern REGISTER for the domain.

It has been the assumption from day one that the proxy is either part of the registrar, or somehow access to registration information in order to know when re-registration push notifications are to be requested (the proxy is not able to request re-register push notifications if it doesn't know when the registration is about to expire). That fits all planned deployments that I am aware of.

Having said that, as I indicated earlier, it is always possible to define additional URI parameters etc in order to provide additional information to the proxy. But that can be done in a separate draft.

Regards,

Christer

Dale