Subject: Re: [sipcore] SIP Push with mid-dialog request triggered notifications: Way forward - The text using PURK - Pull request

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Sep 2018 13:27:40 +0000

Hi,

I have generated yet another pull request, with text that allows mid-dialog push notifications for all types of mid-dialog requests.

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

The text allows the SIP UA to decide (based on local policy), for a given dialog, whether it wants to receive push notifications triggered by mid-dialog request received by the proxy.

Regards,

Christer

On 19/09/18 13:42, "sipcore on behalf of Christer Holmberg" <[email-masked] on behalf of [email-masked]> wrote:

    Hi,
        
    >> 2) Why make SUBSCRIBE special this way? Even if current wireless networks would never use it with INVITE (since there are keepalives and all sorts of other things that 
    >> would never let the UA sleep anyhow), or with SUBSCRIBE requests the UA receives, I don't see the harm in simplifying the specification to just use this in all dialogs. Any 
    >> dialog initiating/refreshing request could behave like the way you have SUBSCRIBE specified in the draft. Existing wireless deployments would never end up using it outside 
    >> the SUBSCRIBE case the draft is talking about, and that's fine. But this would cover the behavior for all of SIP. (For instance, some system that used MSRP might well have an 
    >> INVITE dialog that lives a long time, with infrequent use of the media path, and an endpoint there could quite reasonably sleep). Then the text in this spec (and I think the 
    >> code in any implementation) would become much simpler.
    >    
    > We can for sure allow this also in INVITE dialogs.
    >    
    > However, in VoIP sessions it is not needed, as the UA will be awake during the session, so I don't think we shall mandate it.
    
    One thing to keep in mind is that, for incoming sessions towards the UA, the push proxy needs to make a decision whether to add a Record-Route before it gets any indication from the UA.
    
    Now, the UA could still indicate in the 2xx response that it does not want to receive mid-dialog push requests, but the proxy cannot "undo" the Record-Route.
    
    Regards,
    
    Christer

        
        On 9/18/18 6:37 AM, Christer Holmberg wrote:
        > Pull request created:
        >
        > https://github.com/cdh4u/draft-sip-push/pull/23
        >
        > I call the new parameter PURK (Proxy Unique Registration Key), but let 
        > me know if you have a better suggestion :)
        >
        > Regards,
        >
        > Christer
        >
        >
        >
        >
        >
        > On 18/09/18 03:29, "Paul Kyzivat" <[email-masked]> wrote:
        >
        >      On 9/17/18 3:58 PM, Christer Holmberg wrote:
        >      > Hi,
        >      >
        >      >>>>> I have put together initial text to support mid-dialog NOTIFY request.
        >      >>>>>
        >      >>>>> I put everything in a dedicated section.
        >      >>>>>
        >      >>>>> If people are ok with the approach, I will create a proper pull request.
        >      >>>>
        >      >>>> I have one concern about this:
        >      >>>>
        >      >>>> The doc says that the PRID must be unique. But it doesn't state the
        >      >>>> scope of uniqueness. It looks to me that until now the PRID only had
        >      >>>> to be unique among PRID values issued by the same PNS. (At least if
        >      >>>> we assume that a given UA only uses one PNS.) But the new text for
        >      >>>> subscription dialogs expands the requirement. Now the PRID must be unique
        >      >>>> among all dialogs managed by the push proxy. These might involve multiple PNSs.
        >      >>>>
        >      >>>> It is hard to ensure uniqueness of PRID values across multiple PNSs
        >      >>>> since the format is left entirely up to the PNS. I think this needs more consideration.
        >      >>>
        >      >>> We can include more information in the SUBSCRIBE, if needed.
        >      >>
        >      >> Certainly more info there is needed. But I also think more needs to be said up front and first specification of PRID,
        >      >> that global uniqueness is required, across *all* PNSs. But beyond that, I don't see how it can be left to each individual
        >      >> PNS to specify how it is going to guarantee that its values are unique from those of other PNSs. Seems like each PNS needs
        >      >> to have a distinct namespace somehow.
        >      >
        >      > Even though I think that PRIDs will be globally unique in reality, we can't mandate in the speciation. But, for normal push cases that is not a problem, since there are additional pn- parameters.
        >      >
        >      > Anyway, if people are ok with Roman's suggestion of the proxy generating a random value (not a gruu) I think that would probably be a better solution.
        >      
        >      Yes, I agree it is a better solution.
        >      
        >      	Thanks,
        >      	Paul
        >      
        >
        > _______________________________________________
        > sipcore mailing list
        > [email-masked]
        > https://www.ietf.org/mailman/listinfo/sipcore
        
        _______________________________________________
        sipcore mailing list
        [email-masked]
        https://www.ietf.org/mailman/listinfo/sipcore

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

---

From: Roman Shpount <[email-masked]>
Date: Fri, 21 Sep 2018 10:47:51 -0400

Christer,

I have reviewed the changes and I generally like them except for a few
comments that I have submitted.

First comment is that proxy MUST update newly generated ID on a regular
basis, or this value can be used for fingerprinting.

Second, newly generated key must be unique but does not have to be random.
Using a random function is just one way to generate it. Another way would
be to combine pn- parameters, add a random nonce, and encrypt using proxy
specific key. The value will look random for an external observer but will
not be strictly speaking random.

Regards,
_____________
Roman Shpount

On Fri, Sep 21, 2018 at 9:27 AM, Christer Holmberg <
[email-masked]> wrote:

> Hi,
>
> I have generated yet another pull request, with text that allows
> mid-dialog push notifications for all types of mid-dialog requests.
>
> The text allows the SIP UA to decide (based on local policy), for a given
> dialog, whether it wants to receive push notifications triggered by
> mid-dialog request received by the proxy.
>
> Regards,
>
> Christer
>
>
>
>
> On 19/09/18 13:42, "sipcore on behalf of Christer Holmberg" <
> [email-masked] on behalf of [email-masked]>
> wrote:
>
>     Hi,
>
>     >> 2) Why make SUBSCRIBE special this way? Even if current wireless
> networks would never use it with INVITE (since there are keepalives and all
> sorts of other things that
>     >> would never let the UA sleep anyhow), or with SUBSCRIBE requests
> the UA receives, I don't see the harm in simplifying the specification to
> just use this in all dialogs. Any
>     >> dialog initiating/refreshing request could behave like the way you
> have SUBSCRIBE specified in the draft. Existing wireless deployments would
> never end up using it outside
>     >> the SUBSCRIBE case the draft is talking about, and that's fine. But
> this would cover the behavior for all of SIP. (For instance, some system
> that used MSRP might well have an
>     >> INVITE dialog that lives a long time, with infrequent use of the
> media path, and an endpoint there could quite reasonably sleep). Then the
> text in this spec (and I think the
>     > However, in VoIP sessions it is not needed, as the UA will be awake
> during the session, so I don't think we shall mandate it.
>
>     One thing to keep in mind is that, for incoming sessions towards the
> UA, the push proxy needs to make a decision whether to add a Record-Route
> before it gets any indication from the UA.
>
>     Now, the UA could still indicate in the 2xx response that it does not
> want to receive mid-dialog push requests, but the proxy cannot "undo" the
> Record-Route.
>
>     Regards,
>
>     Christer
>
>
>
>
>         >      >> Certainly more info there is needed. But I also think
> more needs to be said up front and first specification of PRID,
>         >      >> that global uniqueness is required, across *all* PNSs.
> But beyond that, I don't see how it can be left to each individual
>         >      >> PNS to specify how it is going to guarantee that its
> values are unique from those of other PNSs. Seems like each PNS needs
>         >      > Even though I think that PRIDs will be globally unique in
> reality, we can't mandate in the speciation. But, for normal push cases
> that is not a problem, since there are additional pn- parameters.
>         >      >
>         >      > Anyway, if people are ok with Roman's suggestion of the
> proxy generating a random value (not a gruu) I think that would probably be
> a better solution.
>         >

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Sep 2018 14:56:40 +0000

Hi,

>I have reviewed the changes and I generally like them except for a few comments that I have submitted.
>
>First comment is that proxy MUST update newly generated ID on a regular basis, or this value can be used for fingerprinting.

Do you mean within the same registration, as part of a re-REGISTER? Then, what will happen if there is an ongoing dialog that was established prior to the new value was generated, and the proxy receives a mid-dialog request with the OLD value?

>Second, newly generated key must be unique but does not have to be random. Using a random function is just one way to generate it.

Agree. Will fix that.

Thanks!

Regards,

Christer

On Fri, Sep 21, 2018 at 9:27 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

On 19/09/18 13:42, "sipcore on behalf of Christer Holmberg" <[email-masked]<mailto:[email-masked]> on behalf of [email-masked]<mailto:[email-masked]>> wrote:

    Hi,

    Regards,

    Christer

        On 9/18/18 6:37 AM, Christer Holmberg wrote:
        > On 18/09/18 03:29, "Paul Kyzivat" <[email-masked]<mailto:[email-masked]>> wrote:
        >
        > [email-masked]<mailto:[email-masked]>

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

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

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Sep 2018 15:45:20 +0000

Hi,

I guess the proxy could generate a new value and send it in a response to a re-REGISTER, but it must still be able to use the old value to retrieve the pn- information - unless it keeps record of the ongoing dialogs and detects that there are no ongoing dialogs where the old value is used.

Regards,

Christer

Sent from my iPhone

On 21 Sep 2018, at 17.59, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Agree. Will fix that.

Thanks!

Regards,

Christer

Regards,

Christer

    Hi,

    Regards,

    Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Sep 2018 17:23:14 +0000

Hi,

I have updated the pull request, based on Roman’s comments.

Regards,

Christer

From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 21 September 2018 18:45
To: Roman Shpount <[email-masked]>
Cc: SIPCORE <[email-masked]>
Subject: Re: [sipcore] SIP Push with mid-dialog request triggered notifications: Way forward - The text using PURK - Pull request

Hi,

Regards,

Christer
Sent from my iPhone

Agree. Will fix that.

Thanks!

Regards,

Christer

Regards,

Christer

    Hi,

    Regards,

    Christer

---

From: Roman Shpount <[email-masked]>
Date: Fri, 21 Sep 2018 13:46:16 -0400

On Fri, Sep 21, 2018 at 10:56 AM, Christer Holmberg <
[email-masked]> wrote:

> Do you mean within the same registration, as part of a re-REGISTER? Then,
> what will happen if there is an ongoing dialog that was established prior
> to the new value was generated, and the proxy receives a mid-dialog request
> with the OLD value?
>
>
>
I actually mean both. New ID is generated for each binding refresh. All of
these IDs are valid until the registration with this Call-ID expires. What
we are implementing is similar to temp-gruu which is defined here:
https://tools.ietf.org/html/rfc5627#section-3.2

When creating the dialog, UA can use any of the key values it received
during the currently active registration. Typically new PURK should be used
for each dialog with a new party.

Regards,
_____________
Roman Shpount

---

From: Roman Shpount <[email-masked]>
Date: Fri, 21 Sep 2018 13:50:00 -0400

Christer,

This update looks good. The only remaining question is should proxy
generated new PURK on each binding refresh or periodically based on local
policy. In RFC 5627, temp-gruu was generated on each binding refresh so
that UA can obtain new value on demand.

Regards,

_____________
Roman Shpount

On Fri, Sep 21, 2018 at 1:23 PM, Christer Holmberg <
[email-masked]> wrote:

> *From:* sipcore [mailto:[email-masked]] *On Behalf Of *Christer
> Holmberg
> *Sent:* 21 September 2018 18:45
> *To:* Roman Shpount <[email-masked]>
> *Cc:* SIPCORE <[email-masked]>
> *Subject:* Re: [sipcore] SIP Push with mid-dialog request triggered
> notifications: Way forward - The text using PURK - Pull request
>
>
>
> Hi,
>
>
>
> I guess the proxy could generate a new value and send it in a response to
> a re-REGISTER, but it must still be able to use the old value to retrieve
> the pn- information - unless it keeps record of the ongoing dialogs and
> detects that there are no ongoing dialogs where the old value is used.
>
>
>
> Regards,
>
>
>
> Christer
>
> Sent from my iPhone
>
>
> On 21 Sep 2018, at 17.59, Christer Holmberg <christer.holmberg@ericsson.
> com> wrote:
>
> Hi,
>
>
>
> >Second, newly generated key must be unique but does not have to be
> random. Using a random function is just one way to generate it.
>
>
>
> Agree. Will fix that.
>
>
>
> Thanks!
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 21 Sep 2018 18:16:46 +0000

Hi,

>This update looks good. The only remaining question is should proxy generated >new PURK on each binding refresh or periodically based on local policy. In RFC >5627, temp-gruu was generated on each binding refresh so that UA can obtain new >value on demand.

Since the frequency of binding refreshes can vary quite much, I don’t think we should mandate a new value for each refresh.

Regards,

Christer

On Fri, Sep 21, 2018 at 1:23 PM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

From: sipcore [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Christer Holmberg
Sent: 21 September 2018 18:45
To: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Cc: SIPCORE <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] SIP Push with mid-dialog request triggered notifications: Way forward - The text using PURK - Pull request

Hi,

Regards,

Christer
Sent from my iPhone

Agree. Will fix that.

Thanks!

Regards,

Christer

Regards,

Christer

    Hi,

    Regards,

    Christer

---

From: Roman Shpount <[email-masked]>
Date: Fri, 21 Sep 2018 17:08:45 -0400

On Fri, Sep 21, 2018 at 2:16 PM, Christer Holmberg <
[email-masked]> wrote:

> generated >new PURK on each binding refresh or periodically based on
> local policy. In RFC >5627, temp-gruu was generated on each binding
> refresh so that UA can obtain new >value on demand.
>
>
>
> Since the frequency of binding refreshes can vary quite much, I don’t
> think we should mandate a new value for each refresh.
>
>
>
In this case, current update looks good to me.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 25 Sep 2018 08:21:25 +0000

Hi,

Are people (others than Roman) ok with this? I’d like to merge the PR and submit a new version of the draft.

Regards,

Christer

From: Roman Shpount <[email-masked]>
Date: Saturday 22 September 2018 at 00:08
To: Christer Holmberg <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [sipcore] SIP Push with mid-dialog request triggered notifications: Way forward - The text using PURK - Pull request

Regards,
_____________
Roman Shpount

---

From: Jonathan Lennox <[email-masked]>
Date: Thu, 27 Sep 2018 11:56:57 -0400

I have no comment on the mechanism, but I find it unfortunate to have a new object called a “PURK” when the IETF is also working on a mechanism called “PERC”...

> On Sep 25, 2018, at 4:21 AM, Christer Holmberg <[email-masked]> wrote:
> 
> Hi,
>  
> From: Roman Shpount <[email-masked] <mailto:[email-masked]>>
> To: Christer Holmberg <[email-masked] <mailto:[email-masked]>>
> Cc: "[email-masked] <mailto:[email-masked]>" <[email-masked] <mailto:[email-masked]>>
> On Fri, Sep 21, 2018 at 2:16 PM, Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
>>  
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/sipcore <https://www.ietf.org/mailman/listinfo/sipcore>

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 27 Sep 2018 16:03:36 +0000

Give me a better name and I’ll change it…

From: Jonathan Lennox [mailto:[email-masked]]
Sent: 27 September 2018 18:57
To: Christer Holmberg <[email-masked]>
Cc: Roman Shpount <[email-masked]>; SIPCORE <[email-masked]>
Subject: Re: [sipcore] SIP Push with mid-dialog request triggered notifications: Way forward - The text using PURK - Pull request

On Sep 25, 2018, at 4:21 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

Hi,

Regards,

Christer

From: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Saturday 22 September 2018 at 00:08
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] SIP Push with mid-dialog request triggered notifications: Way forward - The text using PURK - Pull request

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Sep 2018 07:23:02 +0000

Would ‘PURF (Proxy Unique Registration Reference)’ be better?

Regards,

Christer

From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 27 September 2018 19:04
To: Jonathan Lennox <[email-masked]>
Cc: SIPCORE <[email-masked]>; Roman Shpount <[email-masked]>
Subject: Re: [sipcore] SIP Push with mid-dialog request triggered notifications: Way forward - The text using PURK - Pull request

Cc: Roman Shpount <[email-masked]<mailto:[email-masked]>>; SIPCORE <[email-masked]<mailto:[email-masked]>>

Hi,

Regards,

Christer

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Sep 2018 07:29:55 +0000

Ok, I got the abbreviation wrong – don’t know where the F came from :)

From: Christer Holmberg
Sent: 28 September 2018 10:23
To: Christer Holmberg <[email-masked]>; Jonathan Lennox <[email-masked]>
Cc: SIPCORE <[email-masked]>; Roman Shpount <[email-masked]>
Subject: RE: [sipcore] SIP Push with mid-dialog request triggered notifications: Way forward - The text using PURK - Pull request

Regards,

Christer

From: sipcore [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: 27 September 2018 19:04
To: Jonathan Lennox <[email-masked]<mailto:[email-masked]>>
Cc: SIPCORE <[email-masked]<mailto:[email-masked]>>; Roman Shpount <[email-masked]<mailto:[email-masked]>>
Subject: Re: [sipcore] SIP Push with mid-dialog request triggered notifications: Way forward - The text using PURK - Pull request

Hi,

Regards,

Christer

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Sep 2018 07:41:04 +0000

‘PURP (Proxy Unique Registration Pointer)’

‘URP (Unique Registration Pointer)’

From: Christer Holmberg

Regards,

Christer

Hi,

Regards,

Christer

Regards,
_____________
Roman Shpount

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 28 Sep 2018 09:19:23 -0400

I actually like PURR, though.  (It gives us an opportunity for pictures of cats, which are always good.)

> On Sep 28, 2018, at 3:29 AM, Christer Holmberg <[email-masked]> wrote:
> 
>   <>
> From: sipcore [mailto:[email-masked] <mailto:[email-masked]>] On Behalf Of Christer Holmberg
> To: Jonathan Lennox <[email-masked] <mailto:[email-masked]>>
> Cc: SIPCORE <[email-masked] <mailto:[email-masked]>>; Roman Shpount <[email-masked] <mailto:[email-masked]>>
> From: Jonathan Lennox [mailto:[email-masked] <mailto:[email-masked]>] 
> Cc: Roman Shpount <[email-masked] <mailto:[email-masked]>>; SIPCORE <[email-masked] <mailto:[email-masked]>>
> On Sep 25, 2018, at 4:21 AM, Christer Holmberg <[email-masked] <mailto:[email-masked]>> wrote:
>  
> Hi,
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Sep 2018 13:29:43 +0000

Ok, so PURR it is :)

From: Jonathan Lennox <[email-masked]>
Date: Friday 28 September 2018 at 16:19
To: Christer Holmberg <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, Roman Shpount <[email-masked]>
Subject: Re: [sipcore] SIP Push with mid-dialog request triggered notifications: Way forward - The text using PURK - Pull request

On Sep 28, 2018, at 3:29 AM, Christer Holmberg <[email-masked]<mailto:[email-masked]>> wrote:

From: Christer Holmberg
Sent: 28 September 2018 10:23
To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>; Jonathan Lennox <[email-masked]<mailto:[email-masked]>>
Cc: SIPCORE <[email-masked]<mailto:[email-masked]>>; Roman Shpount <[email-masked]<mailto:[email-masked]>>
Subject: RE: [sipcore] SIP Push with mid-dialog request triggered notifications: Way forward - The text using PURK - Pull request

Regards,

Christer

Hi,

Regards,

Christer

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Sep 2018 12:34:38 -0400

> ‘URP (Unique Registration Pointer)’

I don't like the use of "pointer" here. These are not pointers. They are 
identifiers. URID would work, though it may be too similar to other 
things. How about UPRID (Unique Proxy Registration ID), or PURID.

Or what about Proxy Unique Temporary Registration ID (PUTRID)? :)

	Thanks,
	Paul

> *From:*Christer Holmberg
> *Sent:* 28 September 2018 10:23
> *To:* Christer Holmberg <[email-masked]>; Jonathan 
> Lennox <[email-masked]>
> *Cc:* SIPCORE <[email-masked]>; Roman Shpount <[email-masked]>
> *Subject:* RE: [sipcore] SIP Push with mid-dialog request triggered 
> *From:*sipcore [mailto:[email-masked]] *On Behalf Of *Christer 
> Holmberg
> *Sent:* 27 September 2018 19:04
> *To:* Jonathan Lennox <[email-masked] <mailto:[email-masked]>>
> *Cc:* SIPCORE <[email-masked] <mailto:[email-masked]>>; Roman 
> Shpount <[email-masked] <mailto:[email-masked]>>
> *From:*Jonathan Lennox [mailto:[email-masked]]
> *Sent:* 27 September 2018 18:57
> *To:* Christer Holmberg <[email-masked] 
> <mailto:[email-masked]>>
> *Cc:* Roman Shpount <[email-masked] <mailto:[email-masked]>>; 
> SIPCORE <[email-masked] <mailto:[email-masked]>>
> I have no comment on the mechanism, but I find it unfortunate to have a 
> new object called a “PURK” when the IETF is also working on a mechanism 
> called “PERC”...
> 
>     On Sep 25, 2018, at 4:21 AM, Christer Holmberg
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>     Hi,
> 
>     Are people (others than Roman) ok with this? I’d like to merge the
>     PR and submit a new version of the draft.
> 
>     Regards,
> 
>     Christer
> 
>     *From:*Roman Shpount <[email-masked] <mailto:[email-masked]>>
>     *Date:*Saturday 22 September 2018 at 00:08
>     *To:*Christer Holmberg <[email-masked]
>     <mailto:[email-masked]>>
>     *Cc:*"[email-masked] <mailto:[email-masked]>" <[email-masked]
>     <mailto:[email-masked]>>
>     *Subject:*Re: [sipcore] SIP Push with mid-dialog request triggered
>     On Fri, Sep 21, 2018 at 2:16 PM, Christer Holmberg
>     <[email-masked]
>     <mailto:[email-masked]>> wrote:
> 
>         >This update looks good. The only remaining question is should
>         proxy generated>new PURK on each binding refresh or periodically
>         based on local policy. In RFC>5627, temp-gruu was generated on
>         each binding refresh so that UA can obtain new>value on demand.
> 
>         Since the frequency of binding refreshes can vary quite much, I
>         don’t think we should mandate a new value for each refresh.
>

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 28 Sep 2018 16:53:37 +0000

Hi Paul,

Jonathan liked PURR (Proxy Unique Registration Reference), so I changed to that and submitted a new version. I hope people are on with that.

Regards,

Christer

Sent from my iPhone

> On 28 Sep 2018, at 19.34, Paul Kyzivat <[email-masked]> wrote:
> 
> I don't like the use of "pointer" here. These are not pointers. They are identifiers. URID would work, though it may be too similar to other things. How about UPRID (Unique Proxy Registration ID), or PURID.
> 
>> *To:* Christer Holmberg <[email-masked]>; Jonathan Lennox <[email-masked]>
>> *Subject:* RE: [sipcore] SIP Push with mid-dialog request triggered notifications: Way forward - The text using PURK - Pull request
>> *From:*sipcore [mailto:[email-masked]] *On Behalf Of *Christer Holmberg
>> *Cc:* SIPCORE <[email-masked] <mailto:[email-masked]>>; Roman Shpount <[email-masked] <mailto:[email-masked]>>
>> *Subject:* Re: [sipcore] SIP Push with mid-dialog request triggered notifications: Way forward - The text using PURK - Pull request
>> *To:* Christer Holmberg <[email-masked] <mailto:[email-masked]>>
>> *Cc:* Roman Shpount <[email-masked] <mailto:[email-masked]>>; SIPCORE <[email-masked] <mailto:[email-masked]>>
>> *Subject:* Re: [sipcore] SIP Push with mid-dialog request triggered notifications: Way forward - The text using PURK - Pull request

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 28 Sep 2018 15:28:07 -0400

> Jonathan liked PURR (Proxy Unique Registration Reference), so I changed to that and submitted a new version. I hope people are on with that.

I'm fine with that, though PUTRID would be fun.

	Thanks,
	Paul