Re: [sipcore] Reason as a parameter rather than an escaped header
Paul Kyzivat <pkyzivat@cisco.com> Wed, 24 November 2010 00:05 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 EB9DE3A69C3 for <sipcore@core3.amsl.com>; Tue, 23 Nov 2010 16:05:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -109.899
X-Spam-Level:
X-Spam-Status: No, score=-109.899 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, 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 B6EKFtjCDMtj for <sipcore@core3.amsl.com>; Tue, 23 Nov 2010 16:05:40 -0800 (PST)
Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 212CF3A6987 for <sipcore@ietf.org>; Tue, 23 Nov 2010 16:05:40 -0800 (PST)
Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEALfl60xAZnwN/2dsb2JhbACia3GicJsmhUsEhFqGBIMP
X-IronPort-AV: E=Sophos;i="4.59,244,1288569600"; d="scan'208";a="185316721"
Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 24 Nov 2010 00:06:38 +0000
Received: from [161.44.174.105] (dhcp-161-44-174-105.cisco.com [161.44.174.105]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oAO06cfM003419; Wed, 24 Nov 2010 00:06:38 GMT
Message-ID: <4CEC570D.8080700@cisco.com>
Date: Tue, 23 Nov 2010 19:06:37 -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: Mary Barnes <mary.ietf.barnes@gmail.com>
References: <CD5674C3CD99574EBA7432465FC13C1B2202288A06@DC-US1MBEX4.global.avaya.com> <4CDC04F2.3010701@cisco.com> <AANLkTi=utzFcqg_QTfurdB0WKK8MRAny8Pb8CEE=s60L@mail.gmail.com>
In-Reply-To: <AANLkTi=utzFcqg_QTfurdB0WKK8MRAny8Pb8CEE=s60L@mail.gmail.com>
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 00:05:42 -0000
On 11/23/2010 3:00 PM, Mary Barnes wrote: > I think we are somewhat ratholing here. A few responses inline below [MB]. Yes, I agree on that. > The intent of the Reason in the HI entries is to capture the reason a > request was retargeted. The current normative text is the Reason > (escaped header, header field, whatever) in the HI-entry is populated > based on SIP Response codes and any other Reason header (e.g., Q.850) > that might be associated with the request. The Reason is included in > the hi-entry with the hi-targeted-to-uri that was retargeted (i.e., the > old) versus the hi-targeted-to-uri in the hi-entry to which the Request > is being sent. We should not change this due to backwards compatibility > AND I think any new Reason values that we want to add to the hi-entries > need to be added consistently. > Thus IF there is agreement to add new Reason header field values for > applications, then if those are used to populate the hi-entry, they > should also be interpreted in the hi-entries to correspond to the > hi-targeted-to-uri that was retargeted (i.e., the old URI that is lost) > based on a decision that the request be associated with a specific > application RATHER than the Reason being the application associated with > the hi-entry with the hi-targeted-to-uri to which the request is being > sent (i.e, the new URI). In the interests of making progress rather than rat hole'ing, I already agreed (reluctantly) to acknowledge that the Reason headers in H-I entries need to continue to be assigned to the entries they have been, even though IMO this is nonsensical. We established that the URIs in H-I entries come from R-URIs that have no embedded headers, so that the embedded header in the H-I entry is only there as a result of explicit addition during the construction of the H-I entry. We just have to consider that the semantics of its presence there are unique. I'm no longer arguing that point. But my remaining concern is about the rules in 4244bis regarding how and when Reason headers are included in the H-I entries. It still seems to me that the text only talks about including them due to a response having been received. Where is the language that discusses adding a reason when retargeting is performed for some reason unrelated to a response? While I think one can argue that a server doing such retargeting can imagine having sent the request to a virtual redirect server and then processing the response from it, ISTM that would then call for adding H-I entries for those steps. > 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. Thanks, Paul
- Re: [sipcore] Reason as a parameter rather than a… Paul Kyzivat
- [sipcore] Reason as a parameter rather than an es… Worley, Dale R (Dale)
- Re: [sipcore] Reason as a parameter rather than a… Worley, Dale R (Dale)
- Re: [sipcore] Reason as a parameter rather than a… Mary Barnes
- Re: [sipcore] Reason as a parameter rather than a… Paul Kyzivat
- Re: [sipcore] Reason as a parameter rather than a… Christer Holmberg
- Re: [sipcore] Reason as a parameter rather than a… Paul Kyzivat
- Re: [sipcore] Reason as a parameter rather than a… Christer Holmberg
- Re: [sipcore] Reason as a parameter rather than a… Hadriel Kaplan
- Re: [sipcore] Reason as a parameter rather than a… marianne.mohali
- Re: [sipcore] Reason as a parameter rather than a… marianne.mohali
- Re: [sipcore] Reason as a parameter rather than a… R.Jesske
- Re: [sipcore] Reason as a parameter rather than a… Paul Kyzivat
- Re: [sipcore] Reason as a parameter rather than a… Mary Barnes
- Re: [sipcore] Reason as a parameter rather than a… marianne.mohali
- Re: [sipcore] Reason as a parameter rather than a… Hadriel Kaplan
- Re: [sipcore] Reason as a parameter rather than a… R.Jesske
- Re: [sipcore] Reason as a parameter rather than a… marianne.mohali