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
>