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

Paul Kyzivat <pkyzivat@alum.mit.edu> Mon, 21 January 2019 17:40 UTC

Return-Path: <pkyzivat@alum.mit.edu>
X-Original-To: sipcore@ietfa.amsl.com
Delivered-To: sipcore@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F941124D68 for <sipcore@ietfa.amsl.com>; Mon, 21 Jan 2019 09:40:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level:
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7TzstRXfblwX for <sipcore@ietfa.amsl.com>; Mon, 21 Jan 2019 09:40:50 -0800 (PST)
Received: from outgoing-alum.mit.edu (outgoing-alum.mit.edu [18.7.68.33]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 924F8124C04 for <sipcore@ietf.org>; Mon, 21 Jan 2019 09:40:50 -0800 (PST)
Received: from PaulKyzivatsMBP.localdomain (c-24-62-227-142.hsd1.ma.comcast.net [24.62.227.142]) (authenticated bits=0) (User authenticated as pkyzivat@ALUM.MIT.EDU) by outgoing-alum.mit.edu (8.14.7/8.12.4) with ESMTP id x0LHel49025946 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT) for <sipcore@ietf.org>; Mon, 21 Jan 2019 12:40:48 -0500
To: sipcore@ietf.org
References: <154806928171.8056.16604437906150841112@ietfa.amsl.com>
From: Paul Kyzivat <pkyzivat@alum.mit.edu>
Message-ID: <a68e014f-1989-0a21-141c-29c0ead3fbbe@alum.mit.edu>
Date: Mon, 21 Jan 2019 12:40:47 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:60.0) Gecko/20100101 Thunderbird/60.4.0
MIME-Version: 1.0
In-Reply-To: <154806928171.8056.16604437906150841112@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/sipcore/x5k4YAKSQWtytrfBbArryoLUhXY>
Subject: Re: [sipcore] I-D Action: draft-ietf-sipcore-sip-push-23.txt
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sipcore/>
List-Post: <mailto:sipcore@ietf.org>
List-Help: <mailto:sipcore-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Jan 2019 17:40:52 -0000

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