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

[Christer Holmberg <[e-mail]>]

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" <[e-mail]> wrote:

    Consider simplifying text where you can.
    
    
    On 9/26/18 2:45 PM, Christer Holmberg wrote:
    > 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.
    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
    >
    > ---
    >
    > 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, [e-mail] wrote:
    >> 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/
    >>
    >> _______________________________________________
    >> sipcore mailing list
    >> [e-mail]
    >> https://www.ietf.org/mailman/listinfo/sipcore
    > _______________________________________________
    > sipcore mailing list
    > [e-mail]
    > https://www.ietf.org/mailman/listinfo/sipcore