Re: [sipcore] Editorial comments on rfc4244bis-02

Hadriel Kaplan <HKaplan@acmepacket.com> Sun, 07 November 2010 12:26 UTC

Return-Path: <HKaplan@acmepacket.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 C558228C0F5 for <sipcore@core3.amsl.com>; Sun, 7 Nov 2010 04:26:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.205
X-Spam-Level:
X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599]
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 mEZXQV03dPIB for <sipcore@core3.amsl.com>; Sun, 7 Nov 2010 04:26:53 -0800 (PST)
Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A299A3A6883 for <sipcore@ietf.org>; Sun, 7 Nov 2010 04:26:53 -0800 (PST)
Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 7 Nov 2010 07:27:08 -0500
Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 7 Nov 2010 07:27:07 -0500
From: Hadriel Kaplan <HKaplan@acmepacket.com>
To: Paul Kyzivat <pkyzivat@cisco.com>
Date: Sun, 7 Nov 2010 07:26:56 -0500
Thread-Topic: [sipcore] Editorial comments on rfc4244bis-02
Thread-Index: Act+dxTujYLghNO7ThOhAcmncOJ47Q==
Message-ID: <CED3FB69-CDF1-4DEA-AE66-D12294FF664E@acmepacket.com>
References: <0CDF97F6-E125-45F8-B266-65E79BAE6F1A@acmepacket.com> <4CD648A4.60301@cisco.com>
In-Reply-To: <4CD648A4.60301@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] Editorial comments on rfc4244bis-02
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: Sun, 07 Nov 2010 12:26:55 -0000

True, I forgot about the forked case... but I don't think that's what they're talking about here, since regardless it's in the reverse direction towards the UAC and follows the SUBSCRIBE's (or REFER's) route set.  Or is the intent to use H-I for requests from the UAS to the UAC as well, in which case why isn't it used in in-dialog requests? (I don't see the point of it, but that's never stopped us before ;)

-hadriel


On Nov 7, 2010, at 1:35 AM, Paul Kyzivat wrote:

> On 11/6/2010 11:48 PM, Hadriel Kaplan wrote:
> 
>> 5) Section 7.1 says: "...plus NOTIFY requests that initiate a dialog."  Ummm... what type of NOTIFY requests would those be?? (other than proprietary)  Actually, that raises a question - can this appear in proprietary methods?
> 
> In case of forking, NOTIFY requests can initiate a dialog.
> And with 3256bis dialogs are *always* initiated by NOTIFY.
> 
> 	Thanks,
> 	Paul
> _______________________________________________
> sipcore mailing list
> sipcore@ietf.org
> https://www.ietf.org/mailman/listinfo/sipcore