Re: [sipcore] Reason as a parameter rather than an escaped header
<R.Jesske@telekom.de> Fri, 26 November 2010 12:05 UTC
Return-Path: <R.Jesske@telekom.de>
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 6D0F93A6AF8 for <sipcore@core3.amsl.com>; Fri, 26 Nov 2010 04:05:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.249
X-Spam-Level:
X-Spam-Status: No, score=-3.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 xbEgkKAo-3gy for <sipcore@core3.amsl.com>; Fri, 26 Nov 2010 04:05:43 -0800 (PST)
Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id C9B653A6AC5 for <sipcore@ietf.org>; Fri, 26 Nov 2010 04:05:42 -0800 (PST)
Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 26 Nov 2010 13:06:41 +0100
Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.187]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 26 Nov 2010 13:06:41 +0100
From: R.Jesske@telekom.de
To: dworley@avaya.com, pkyzivat@cisco.com
Date: Fri, 26 Nov 2010 13:06:40 +0100
Thread-Topic: Reason as a parameter rather than an escaped header
Thread-Index: AcuBsSzQ68/6e0JSQK20l10bQRCF7AJkywTAAIdv8nA=
Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D04DCB170@HE111648.emea1.cds.t-internal.com>
References: <CD5674C3CD99574EBA7432465FC13C1B2202288A06@DC-US1MBEX4.global.avaya.com>, <4CDC04F2.3010701@cisco.com> <CD5674C3CD99574EBA7432465FC13C1B2202288A63@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <CD5674C3CD99574EBA7432465FC13C1B2202288A63@DC-US1MBEX4.global.avaya.com>
Accept-Language: en-US, de-DE
Content-Language: de-DE
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, de-DE
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: 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: Fri, 26 Nov 2010 12:05:44 -0000
Only to indicate that draft-jesske-dispatch-reason-in-responses-02 is in a queue where I wait for an indication how to proceed. If it should be progressed as an individual draft or as an WID in DISPATCH (or perhaps in SIPCORE). Roland > -----Ursprüngliche Nachricht----- > Von: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] Im Auftrag von Worley, Dale R (Dale) > Gesendet: Dienstag, 23. November 2010 20:27 > An: Paul Kyzivat > Cc: sipcore@ietf.org > Betreff: Re: [sipcore] Reason as a parameter rather than an > escaped header > > From: Paul Kyzivat [pkyzivat@cisco.com] > > >> Just stating it that was exposes the problem. > > >> The intent of the Reason header is specified in RFC3326. > > >> Any use that isn't consistent with that is an abuse. > > >> Its intended to indicate why a *request* is being sent. > > > > > > Yes, but it quickly mutated into a carrier in responses to provide > > > additional information as to why the response was generated. > > > Consider: > > > > > > draft-jesske-dispatch-reason-in-responses-02 > > > > 1 - quickly? The Reason header is old. > > 2 - did I miss something? what is the status of the jesske draft? > > isn't it still just an individual draft? > > Yes, you missed something, and so did everybody else. As turned up in > the discussion of the Jesske draft during one IETF meeting, just about > everybody assumes that Reason can be used in responses, and appears to > have been assuming that for many years. The Jesske draft in to > officially permit what everybody has been doing all along. > > > But my point wasn't reasons for requests vs. reasons for > responses. It > > was about reasons for requests vs. reasons for H-I entries. > And IIUC the > > reasons in Marianne's draft are *not* reasons for > responses. They are > > reasons for retargeting, generally without there having been any > > response. They are indeed a reason for a request. And it is > a reason for > > the request with the new target, not the reason for the > request with the > > old target. > > How you feel about this depends on how you assume the system is > architected. In my case, I expect *all* redirections to be due to 302 > responses received by the proxy from a redirect server. So I expect > (perhaps incorrectly) to see H-I entries like this: > > History-Info: <sip:original-address \ > ?Reason=SIP;cause=302, \ > > application;cause=2;text="Freephone">;index=1, > <sip:new>;index=1.1 > [with considerable abuse of the escaping rules] > > That is, the "application" value carries more information about why > the "SIP" value (302) was generated. > > But I don't know if others think that Reason will be commonly used in > this way. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >
- 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