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

"Worley, Dale R (Dale)" <dworley@avaya.com> Thu, 11 November 2010 09:10 UTC

Return-Path: <dworley@avaya.com>
X-Original-To: sipcore@core3.amsl.com
Delivered-To: sipcore@core3.amsl.com
Received: from localhost (localhost []) by core3.amsl.com (Postfix) with ESMTP id F16BD3A6991 for <sipcore@core3.amsl.com>; Thu, 11 Nov 2010 01:10:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.393
X-Spam-Status: No, score=-102.393 tagged_above=-999 required=5 tests=[AWL=0.206, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([]) by localhost (core3.amsl.com []) (amavisd-new, port 10024) with ESMTP id Nf7zRdoCh0RY for <sipcore@core3.amsl.com>; Thu, 11 Nov 2010 01:10:13 -0800 (PST)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com []) by core3.amsl.com (Postfix) with ESMTP id 3CF5C3A69DA for <sipcore@ietf.org>; Thu, 11 Nov 2010 01:10:13 -0800 (PST)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAHpB20zGmAcF/2dsb2JhbACiP3GmOwKZMIVKBIRaiSM
X-IronPort-AV: E=Sophos;i="4.59,181,1288584000"; d="scan'208";a="249549595"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Nov 2010 04:10:37 -0500
X-IronPort-AV: E=Sophos;i="4.59,181,1288584000"; d="scan'208";a="539206643"
Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Nov 2010 04:10:37 -0500
Received: from DC-US1MBEX4.global.avaya.com ([]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Thu, 11 Nov 2010 04:10:37 -0500
From: "Worley, Dale R (Dale)" <dworley@avaya.com>
To: Paul Kyzivat <pkyzivat@cisco.com>, Mary Barnes <mary.ietf.barnes@gmail.com>
Date: Thu, 11 Nov 2010 04:09:02 -0500
Thread-Topic: Reason as a parameter rather than an escaped header
Thread-Index: AQHLgYBN581nCUuJQU2ysobR7UrBQg==
Message-ID: <CD5674C3CD99574EBA7432465FC13C1B2202288A06@DC-US1MBEX4.global.avaya.com>
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: "sipcore@ietf.org" <sipcore@ietf.org>
Subject: [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: Thu, 11 Nov 2010 09:10:15 -0000

First, I don't like the term "an escaped header".  The escaping
process is not central, what is central is that the "header" (per 3261
BNF terminology) is "added to" or "inserted into" the URI.

From: Paul Kyzivat [pkyzivat@cisco.com]
> On 11/7/2010 6:39 PM, Mary Barnes wrote:
> > I think there is still some confusion here - the Reason is NOT a URI
> > parameter. It is a SIP header field that is escaped in the URI for
> > compactness.
> I don't think there is any real confusion. Its just that the terminology
> is awkward. We have parameters to headers, and we have headers that are
> parameters to URIs.

The BNF in RFC 3261 calls these things "headers":

    SIP-URI          =  "sip:" [ userinfo ] hostport
			uri-parameters [ headers ]
    headers         =  "?" header *( "&" header )
    header          =  hname "=" hvalue

In our organization, we call them "header parameters", contrasted to
"URI parameters" ("uri-parameters" per 3261) and "field parameters"
(which has no proper name in 3261, but its syntax is "generic-param").
These phrases are used in the prose of 3261 with these meanings

> > In earlier versions, we had a separate parameter in the
> > SIP History-Info header for Reason, but Rohan suggested to just escape
> > the existing Reason header in the URI so as not to redefine Reason
> > parameters.
> I even remember him making that suggestion. Too bad he isn't around so
> we can wring his neck. I thought it was a hack at the time, but didn't
> then realize how much trouble it would cause.

Certainly, doing so is conceptually incorrect, as the reason is a
property of the request-URI that was used, not a portion of that
request-URI.  Fortunately, no operational failure can result, as the
request-URI of a request cannot contain header parameters.

But it looks like we need to continue this hack for compatibility.  So let us:
- publicly state this is a hack
- not repeat the mistake in other cases

> > The Reason header is intended to tag the Reason why the hi-targeted-to
> > URI was retargeted and thus it goes with the "old" hi-entry versus the
> > "new" one.
> 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.



   Although the use of the Reason header field in responses is
   considered in RFC3326, doing so is not specified for any existing
   response code.  Nonetheless, the Reason header field has been widely
   used in responses to carry Q.850 reason codes for failure responses
   to INVITEs that have been gatewayed to PSTN systems.  This document
   specifies and formally permits the use of the Reason header field in
   SIP responses to carry Q.850 reason codes for this and other

> > Also, note that we cannot change this now even if it were the right
> > thing to do due to backwards compatibility.
> So then we allow it continue to metastasize, e.g. by defining new Reason
> values that aren't ever expected to be used in requests, and that
> wouldn't make any sense if they were?

That seems likely.  It's probably a good thing.  It's a bit sketchy to use
the same header to describe why a request was generated and also why
a response was generated, but it's not going to cause confusion.