Re: [sipcore] draft-roach-sipcore-rfc3265bis-00

"Dale Worley" <dworley@nortel.com> Fri, 02 October 2009 21:43 UTC

Return-Path: <dworley@nortel.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 95A9E3A69E5 for <sipcore@core3.amsl.com>; Fri, 2 Oct 2009 14:43:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.58
X-Spam-Level:
X-Spam-Status: No, score=-6.58 tagged_above=-999 required=5 tests=[AWL=0.019, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D53ChRLqbrJN for <sipcore@core3.amsl.com>; Fri, 2 Oct 2009 14:43:47 -0700 (PDT)
Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 685BC3A68BE for <sipcore@ietf.org>; Fri, 2 Oct 2009 14:43:47 -0700 (PDT)
Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n92LigJ21727; Fri, 2 Oct 2009 21:44:42 GMT
Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Oct 2009 17:44:41 -0400
From: Dale Worley <dworley@nortel.com>
To: "DRAGE, Keith (Keith)" <drage@alcatel-lucent.com>
In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE20874FD06@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
References: <C0E80510684FE94DBDE3A4AF6B968D2D06311DBD@esealmw118.eemea.ericsson.se> <4A85C195.4060903@nostrum.com> <CA9998CD4A020D418654FCDEF4E707DF0E3D8462@esealmw113.eemea.ericsson.se> <EDC0A1AE77C57744B664A310A0B23AE20874FD06@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
Content-Type: text/plain
Organization: Nortel Networks
Date: Fri, 02 Oct 2009 17:44:40 -0400
Message-Id: <1254519880.3767.33.camel@khone.us.nortel.com>
Mime-Version: 1.0
X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8)
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 02 Oct 2009 21:44:41.0722 (UTC) FILETIME=[8C6195A0:01CA43A9]
Cc: Ian Elz <ian.elz@ericsson.com>, "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] draft-roach-sipcore-rfc3265bis-00
X-BeenThere: sipcore@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <sipcore.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/sipcore>, <mailto:sipcore-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Fri, 02 Oct 2009 21:43:48 -0000

In regard to the fact that a proxy (that wishes to remain in the
signaling path) must Record-Route all SUBSCRIBEs without to-tags, and
all NOTIFYs:

On Tue, 2009-08-18 at 15:24 +0200, DRAGE, Keith (Keith) wrote:
> Christer wrote
> 
> > Again, a 3261 compliant proxy may Record-Route the SUBSCRIBE, 
> > but that doesn't mean it will Record-Route the NOTIFY. It may 
> > simply be configured to Record-Route all dialog initiation requests.
> > 
> 
> It can only do this if it understands that SUBSCRIBE is a dialog
> initiation request, and it can only do this if it implements either
> RFC 3265 or 3265bis. 
> 
> As I understood it, the behaviour described by Adam is already in RFC
> 3265, and therefore it is a non-conformant implementation of RFC 3265
> if it does something difference.

Some years ago, I was in a long discussion about how SUBSCRIBE/NOTIFY
need to be record-routed, especially in the context of
non-dialog-stateful proxies.  Unfortunately, nobody in the conversation
recalled section 3.1.5 of RFC 3265, but we came to the conclusion that
in order for subscriptions to work *in practice*, a non-dialog-stateful
proxy must record-route SUBSCRIBEs without to-tags and all NOTIFYs, or
record-route none of them.  So practical demands require that any proxy
in an environment that uses SUB/NOT would satisfy 3.1.5 (in almost all
cases), that is *be* RFC 3265-compliant, even if it didn't *intend* to
be RFC 3265-compliant.

In that context, 3265bis doesn't demand any behavior from proxies that
they don't (in practice) have to have already.  So I think we can safely
depend on them having the proper behavior.

Dale