Subject: [sipcore] I-D Action: draft-ietf-sipcore-sip-push-15.txt

From: [email-masked]
Date: Wed, 26 Sep 2018 02:32:53 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Session Initiation Protocol Core WG of the IETF.

        Title           : Push Notification with the Session Initiation Protocol (SIP)
        Authors         : Christer Holmberg
                          Michael Arnold
	Filename        : draft-ietf-sipcore-sip-push-15.txt
	Pages           : 30
	Date            : 2018-09-26

Abstract:
   This document describes how a Push Notification Service (PNS) can be
   used to wake suspended Session Initiation Protocol (SIP) User Agents
   (UAs), using push notifications, for the UA to be able to send
   binding refresh REGISTER requests and to receive receive incoming SIP
   requests.  The document defines new SIP URI parameters and new
   feature-capability indicators that can be used in SIP messages to
   indicate support of the mechanism defined in this document, to
   exchange PNS information between the SIP User Agent (UA) and the SIP
   entity that will request push notifications towards the UA, and to
   trigger such push notification requests.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sipcore-sip-push/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-sipcore-sip-push-15
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-push-15

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sipcore-sip-push-15

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Robert Sparks <[email-masked]>
Date: Wed, 26 Sep 2018 14:21:54 -0500

Hi Christer -

The introduction and a few other places early in the document haven't 
been updated to reflect long-lived dialogs / in-dialog requests.

RjS

On 9/26/18 4:32 AM, [email-masked] wrote:
> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 26 Sep 2018 19:45:29 +0000

Hi Robert,

>The introduction and a few other places early in the document haven't been updated to reflect long-lived dialogs / in-dialog requests.

You are correct. Eventhough most of the text in the Introduction is generic, there are a couple places where we need to add text about mid-dialog requests and longlived dialogs.

OLD:

   When the proxy receives a SIP request for a new dialog, or a stand-
   alone SIP request, addressed towards a UA, or when the proxy
   determines that the UA needs to send a binding refresh REGISTER
   request, the proxy will request a push notification towards the UA,
   using the PNS of the UA.

NEW:

   When the proxy receives a SIP request for a new dialog, a stand-
   alone SIP request or a SIP mid-dialog request (in case of longlived dialogs), 
   addressed towards a UA, or when the proxy determines that the UA needs 
   to send a binding refresh REGISTER request, the proxy will request a push 
   notification towards the UA, using the PNS of the UA.

---

OLD:

   The proxy MUST be in the signalling path of REGISTER requests sent by
   the UA towards the registrar, and of SIP requests (for a new dialog
   or a stand-alone) forwarded by the proxy responsible for the UA's
   domain (sometimes referred to as home proxy, S-CSCF, etc) towards the
   UA.  The proxy can also be co-located with the proxy responsible for
   the UA's domain.  This will also ensure that the Request-URI of SIP
   requests (for a new dialog or a stand-alone) can be matched against
   contacts in REGISTER requests.

NEW:

   The proxy MUST be in the signalling path of REGISTER requests sent by
   the UA towards the registrar, of SIP requests (for a new dialog
   or a stand-alone) forwarded by the proxy responsible for the UA's
   domain (sometimes referred to as home proxy, S-CSCF, etc) towards the
   UA and of mid-dialog requests that can trigger push notification requests. 
   The proxy can also be co-located with the proxy responsible for
   the UA's domain.  This will also ensure that the Request-URI of SIP
   requests (for a new dialog or a stand-alone) can be matched against
   contacts in REGISTER requests.

Note that it isn't mentioned in Sections 4 and 5 on purpose. I thought I'd describe long-lived dialogs in Section 6, in order to not make 4 and 5 more complex.

Regards,

Christer

RjS

On 9/26/18 4:32 AM, [email-masked] wrote:
> Please note that it may take a couple of minutes from the time of 
> submission until the htmlized version and diff are available at tools.ietf.org.
>

---

From: Robert Sparks <[email-masked]>
Date: Wed, 26 Sep 2018 14:57:37 -0500

Consider simplifying text where you can.

>     notification towards the UA, using the PNS of the UA.
Why not
NEW:
     When the proxy receives a SIP request targeted for the UA, or when 
the proxy
     determines that the UA needs to ...

and similar elsewhere

---

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

Hi,

I have put effort into trying to make the text clear, and I also asked our designers and implementers etc to read and comment on whether they think something is unclear. And, as there anyway will be changes based on the GenART- and IESG reviews, I'd like to move the draft forward.

Of course, if you have any specific parts that you want me to change I can look into that.

Regards,

Christer

On 26/09/18 22:57, "Robert Sparks" <[email-masked]> wrote:

    Why not
    NEW:
    
    and similar elsewhere