Re: [sipcore] Alert-Info header field in non-100 1xx responses

Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com> Wed, 04 August 2010 13:00 UTC

Return-Path: <gonzalo.camarillo@ericsson.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 0A4433A67EE for <sipcore@core3.amsl.com>; Wed, 4 Aug 2010 06:00:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.634
X-Spam-Level:
X-Spam-Status: No, score=-105.634 tagged_above=-999 required=5 tests=[AWL=0.965, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 ijRKiobtLliy for <sipcore@core3.amsl.com>; Wed, 4 Aug 2010 06:00:20 -0700 (PDT)
Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id E54D13A67B3 for <sipcore@ietf.org>; Wed, 4 Aug 2010 06:00:19 -0700 (PDT)
X-AuditID: c1b4fb3d-b7b90ae00000278d-af-4c59647f0ed7
Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 83.73.10125.084695C4; Wed, 4 Aug 2010 15:00:48 +0200 (CEST)
Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Aug 2010 15:00:47 +0200
Received: from [131.160.126.136] ([131.160.126.136]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 4 Aug 2010 15:00:47 +0200
Message-ID: <4C59647F.8060700@ericsson.com>
Date: Wed, 04 Aug 2010 16:00:47 +0300
From: Gonzalo Camarillo <Gonzalo.Camarillo@ericsson.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6
MIME-Version: 1.0
To: Paul Kyzivat <pkyzivat@cisco.com>
References: <4C57DE8A.20700@ericsson.com> <4C581E77.6060205@cisco.com>
In-Reply-To: <4C581E77.6060205@cisco.com>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 04 Aug 2010 13:00:47.0431 (UTC) FILETIME=[0E7CED70:01CB33D5]
X-Brightmail-Tracker: AAAAAA==
Cc: Dale Worley <dworley@avaya.com>, SIPCORE <sipcore@ietf.org>
Subject: Re: [sipcore] Alert-Info header field in non-100 1xx responses
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: Wed, 04 Aug 2010 13:00:21 -0000

Hi Paul,

thanks for your (individual) opinion on the topic. With respect to the
process, I am well aware of the issue. That is why, first, I want to
know whether or not somebody has problems with this change. Once we
agree on a technical solution, we will easily take care of the
process-related issue. The main thing here is to make sure that this
proposal is reviewed by the relevant people in both SIPCORE and SALUD.

Thanks,

Gonalo

On 03/08/2010 4:49 PM, Paul Kyzivat wrote:
> Gonzalo,
> 
> Gonzalo Camarillo wrote:
>> Hi,
>>
>> RFC 3261 only allows Alert-Info header fields in 180 responses. The
>> SALUD WG would like to be able to insert this header field in any
>> non-100 1xx response. Formally, this change would be an update to RFC
>> 3261. So, we would like to get feedback from the SIPCORE WG on whether
>> or not such a change would be OK.
> 
> [as an individual] I think this is perfectly reasonable.
> 
> [as co-chair] There is the procedural issue of whether such a change 
> must be done by SIPCORE. The following is from the SIPCORE charter:
> 
> "Extensions to SIP that add new functionality that
> would not be required of all implementations will be done outside of
> this WG."
> 
> Since the processing of Alert-Info is always optional according to 3261, 
> defining a specific behavior for certain URNs is clearly an extension. 
> And making the header allowable in additional responses also seems to be 
> an extension.
> 
> So I'm ok with this.
> 
> 	Thanks,
> 	Paul