Re: [sipcore] Reason as a parameter rather than an escaped header

Paul Kyzivat <pkyzivat@cisco.com> Wed, 24 November 2010 22:35 UTC

Return-Path: <pkyzivat@cisco.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 85B1328C1A4 for <sipcore@core3.amsl.com>; Wed, 24 Nov 2010 14:35:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.213
X-Spam-Level:
X-Spam-Status: No, score=-110.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-8, 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 0qpcYWDdfGTj for <sipcore@core3.amsl.com>; Wed, 24 Nov 2010 14:35:33 -0800 (PST)
Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id DF8A428C129 for <sipcore@ietf.org>; Wed, 24 Nov 2010 14:35:32 -0800 (PST)
Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAFsi7UxAZnwM/2dsb2JhbACjCXGjEJsuhUcEhFuGBYMP
X-IronPort-AV: E=Sophos;i="4.59,250,1288569600"; d="scan'208";a="185909137"
Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 24 Nov 2010 22:36:33 +0000
Received: from [10.86.254.111] ([10.86.254.111]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAOMaWtW012387; Wed, 24 Nov 2010 22:36:32 GMT
Message-ID: <4CED9370.5010001@cisco.com>
Date: Wed, 24 Nov 2010 17:36:32 -0500
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6
MIME-Version: 1.0
To: Christer Holmberg <christer.holmberg@ericsson.com>
References: <CD5674C3CD99574EBA7432465FC13C1B2202288A06@DC-US1MBEX4.global.avaya.com> <4CDC04F2.3010701@cisco.com> <AANLkTi=utzFcqg_QTfurdB0WKK8MRAny8Pb8CEE=s60L@mail.gmail.com>, <4CEC570D.8080700@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502C71884@ESESSCMS0356.eemea.ericsson.se>
In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502C71884@ESESSCMS0356.eemea.ericsson.se>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Cc: "Worley, Dale R \(Dale\)" <dworley@avaya.com>, "sipcore@ietf.org" <sipcore@ietf.org>
Subject: Re: [sipcore] Reason as a parameter rather than an escaped header
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, 24 Nov 2010 22:35:36 -0000

On 11/24/2010 3:27 PM, Christer Holmberg wrote:
> Hi,
>
>>> I would suggest that the best way forward is that we keep the current
>>> text as is and note that any additional Reason headers that are defined
>>> in the future MUST be interpreted in the same manner.  However, I do NOT
>>> think we should hold up 4244bis until we get full agreement on adding
>>> new Reason header values for applications as I firmly believe it is
>>> orthogonal - it can work based upon the current normative approach and
>>> interpretation of the Reason in the hi-entries.  We can debate till the
>>> end of time (or the end of SIPCORE WG as we did with other broken things
>>> in SIP) that this wasn't the right approach, but it is what it is and I
>>> think it's time to move forward.
>>
>> I agree that 4244bis should not be held up because of the new reason
>> values draft(s?).
>>
>> At this point I would just like some clarity whether the *way* reasons
>> are used in the examples in
>> draft-mohali-sipcore-reason-extension-application-00 - reasons without
>> responses - is thought to be *valid* in the context of 4244bis. If the
>> answer is NO, then I'll shut up, and let Marianne or somebody else from
>> 3gpp complain if they think it should be.
>>
>> If the answer is YES - that usage is considered valid according to
>> 4244bis, then I still want to know why, and perhaps see some additional
>> text to make it clear.
>
> I think we should ask ourselves: assuming we allowed to do what Marianne is proposing, would anything break?
>
> Does anyone really care whether a H-I entry was inserted based on a "real" or "virtual" response? Aren't people more interested in the actual reason value?

I don't currently see a problem with permitting this (though I'm 
interested to hear if somebody else sees an issue).

But IMO the current text doesn't suggest to me that this is valid.
So if the desire is for it to be valid it would be good to have some 
text that makes it so.

	Thanks,
	Paul