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

"Worley, Dale R (Dale)" <> Tue, 23 November 2010 19:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A305428C129 for <>; Tue, 23 Nov 2010 11:25:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -102.481
X-Spam-Status: No, score=-102.481 tagged_above=-999 required=5 tests=[AWL=0.118, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qFp0DGJph49u for <>; Tue, 23 Nov 2010 11:25:53 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C8B1E28C139 for <>; Tue, 23 Nov 2010 11:25:53 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEANuj60zGmAcF/2dsb2JhbACiYnGlUAKZG4VLBIRaiS0
X-IronPort-AV: E=Sophos;i="4.59,243,1288584000"; d="scan'208";a="46861562"
Received: from unknown (HELO ([]) by with ESMTP; 23 Nov 2010 14:26:51 -0500
X-IronPort-AV: E=Sophos;i="4.59,243,1288584000"; d="scan'208";a="544770106"
Received: from (HELO ([]) by with ESMTP; 23 Nov 2010 14:26:50 -0500
Received: from ([]) by ([::1]) with mapi; Tue, 23 Nov 2010 14:26:50 -0500
From: "Worley, Dale R (Dale)" <>
To: Paul Kyzivat <>
Date: Tue, 23 Nov 2010 14:26:37 -0500
Thread-Topic: Reason as a parameter rather than an escaped header
Thread-Index: AcuBsSzQ68/6e0JSQK20l10bQRCF7AJkywTA
Message-ID: <>
References: <>, <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "" <>
Subject: Re: [sipcore] Reason as a parameter rather than an escaped header
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Core Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 23 Nov 2010 19:25:54 -0000

From: Paul Kyzivat []
> >> 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, \
[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.