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

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, internet-drafts@ietf.org 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
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore