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

From: [email-masked]
Date: Mon, 21 Jan 2019 03:14:41 -0800

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-23.txt
	Pages           : 39
	Date            : 2019-01-21

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 that push notifications are sent to 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-23
https://datatracker.ietf.org/doc/html/draft-ietf-sipcore-sip-push-23

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

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: Paul Kyzivat <[email-masked]>
Date: Mon, 21 Jan 2019 12:40:47 -0500

Christer,

In section 5.3:

    5.3.  SIP URI Comparison Rules

    When a SIP proxy compares two SIP URIs, the proxy uses the URI
    comparison rules defined in [RFC3261], with the following addition:
    the pn-prid, pn-provider and pn-param SIP URI parameters MUST also
    match in order for the comparison to be successful.

    If only the pn- SIP URI parameters listed above match, but other
    parts of the compared URIs do not match, a proxy MAY still consider
    the comparison successful, based on local policy.  This can occur in
    a race condition, if a UA modified some parts of the Contact URI in
    the most recent REGISTER request, but the Request-URI of a SIP
    request addressed towards the UA still contains the old parts.

I *presume* you only intend these extended matching rules to be applied 
in certain contexts. But you don't say anything about that. Someone 
might read this as applying to all the places in 3261 where matching is 
used.

Please add a few more words clarifying those circumstances when these 
extended matching rules apply.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 21 Jan 2019 19:22:36 +0000

Hi Paul,

Please see inline.

 > might read this as applying to all the places in 3261 where matching is

Good point. I do refer to the URI comparison section in the procedure sections, but it would be good to add a few words in the URI comparison section itself.

> extended matching rules apply.

What about modifying the 1st paragraph in the following way:

"As described in the SIP proxy procedures in this specification, there are cases where the proxy will compare the Contact header field URI of a 2xx response to a REGISTER request with the Request-URI of the SIP requests in the SIP Request Push Queue (Section 5.2). In those cases, when the proxy compares two SIP URIs, the proxy uses the URI
comparison rules defined in [RFC3261], with the following addition: the pn-prid, pn-provider and pn-param SIP URI parameters MUST also match in order for the comparison to be successful."

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 22 Jan 2019 08:27:06 +0000

Hi,

I was taking a second look in RFC 3261, and the text already says:

“o  URI uri-parameter components are compared as follows:

         -  Any uri-parameter appearing in both URIs must match.”

So, in my opinion that means that 3261 already covers the pn- parameters, and the only thing we need to do in draft-sip-push is to point that out.

However, draft-sip-push also allows a partial match, and that needs to be normative.

So, perhaps something like:

   “When a SIP proxy compares two SIP URIs, the proxy uses the URI
   comparison rules defined in [RFC3261], meaning that in order
   for a comparison to be successful the pn-prid, pn-provider and
   pn-param SIP URI parameters must also match.”

So, a proxy will always use these rules when comparing SIP URIs, not only when comparing a Contact URI with a Request-URI.

Pull request with suggested modficiation:

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

Regards,

Christer

From: sipcore <[email-masked]> on behalf of Christer Holmberg <[email-masked]>
Date: Monday, 21 January 2019 at 21.23
To: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-push-23.txt

Hi Paul,

Please see inline.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 28 Jan 2019 10:59:48 -0500

On 1/22/19 3:27 AM, Christer Holmberg wrote:
> So, in my opinion that means that 3261 already covers the pn- 
> parameters, and the only thing we need to do in draft-sip-push is to 
> point that out.
> 
> So, a proxy will always use these rules when comparing SIP URIs, not 
> only when comparing a Contact URI with a Request-URI.
> 

I reviewed this change in -24. It resolves my concern.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 28 Jan 2019 16:02:30 +0000

Thank you, Paul!

Regards,

Christer

On 28/01/2019, 18.00, "Paul Kyzivat" <[email-masked]> wrote:

    
    	Thanks,
    	Paul