Re: [sipcore] Reason as a parameter rather than an escapedheader (was Comments on draft-ietf-sipcore-rfc4244bis-02)

<> Mon, 08 November 2010 07:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CED543A689B for <>; Sun, 7 Nov 2010 23:55:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.249
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id OP-c0YofR9dc for <>; Sun, 7 Nov 2010 23:55:24 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 761333A6868 for <>; Sun, 7 Nov 2010 23:55:23 -0800 (PST)
Received: from (HELO ([]) by with ESMTP; 08 Nov 2010 08:55:39 +0100
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 08:55:38 +0100
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-MimeOLE: Produced By Microsoft Exchange V6.5
Date: Mon, 08 Nov 2010 08:53:02 +0100
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [sipcore] Reason as a parameter rather than an escapedheader (was Comments on draft-ietf-sipcore-rfc4244bis-02)
Thread-Index: Act/Dp+TWptJkoHxTKmW70ParzWVEwACbydA
References: <><><><><><><> <>
X-OriginalArrivalTime: 08 Nov 2010 07:55:38.0961 (UTC) FILETIME=[55721C10:01CB7F1A]
Subject: Re: [sipcore] Reason as a parameter rather than an escapedheader (was Comments on draft-ietf-sipcore-rfc4244bis-02)
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: Mon, 08 Nov 2010 07:55:25 -0000

we have already a mechanism putting a "cause" into the URI which is the target.
RFC4458 describes this for diverting reasons. 
So it is a own header used for History Info no new definition is needed.
And so this mechanism could be extended by the proposed values in and other needed. 

So in final the Reason is included within the "retargeting" URI based on the received response.
And the cause as defined in RFC4458 is in the target URI.


Best Regards


-----Ursprüngliche Nachricht-----
Von: [] Im Auftrag von Hadriel Kaplan
Gesendet: Montag, 8. November 2010 07:32
An: Shida Schubert
Betreff: Re: [sipcore] Reason as a parameter rather than an escapedheader (was Comments on draft-ietf-sipcore-rfc4244bis-02)

I know this is beating a dead horse, but breaking backwards compatibility for Hist-Ifno may be a GOOD thing.
Seriously.  Afaict, "legacy" H-I is broken.  It didn't solve people's problems, in an interoperable fashion.  That's why we needed 4244bis to begin with, ain't it?

In fact, start with a new header name, if need be.
To be transparent, we can name the new header "Possible-Targets-Lottery:" and if you guess the right "real" target from the list, you win some award.  :)


On Nov 8, 2010, at 12:48 AM, Shida Schubert wrote:

> I don't agree. This is going to completely break backward
> compatibility.
> Regards
>  Shida
> On Nov 8, 2010, at 1:55 PM, Elwell, John wrote:
>> I agree with Paul's concerns, and I think we should use bis as an opportunity to get this right, even if we have to grandfather some existing mechanism. The Mohali draft is evidence that the present mechanism causes further problems down the line.
>> John
>>> -----Original Message-----
>>> From:
>>> [] On Behalf Of Paul Kyzivat
>>> Sent: 08 November 2010 01:42
>>> To: Mary Barnes
>>> Cc:
>>> Subject: Re: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02
>>> 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.
>>>> 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.
>>>> 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.
>>>> We originally had two URIs for each hi-entry (the old and
>>>> the new) . The idea of capturing the "new" is so that you
>>> already have
>>>> the old entry when you do the retarget, noting that when an entity
>>>> goes to process History-Info, the last entry isn't typically useful,
>>>> since it should always be the URI in the received request.  So,
>>>> logically, for each request that is retargeted, you have
>>> the "old" and
>>>> "new", so they really are related and .
>>>> 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?
>>>     Thanks,
>>>     Paul
>>>> Mary.
>>>> On Sun, Nov 7, 2010 at 9:05 AM, Paul
>>> Kyzivat<>  wrote:
>>>>> The following is giving me heartburn:
>>>>> On 11/2/2010 3:25 PM, Mary Barnes wrote:
>>>>>>> 2. There is some confusion concerning Reason - sometimes
>>> it is referred
>>>>>>> to as a parameter (e.g., 7.1 3rd bullet, 7.1 last
>>> paragraph), sometimes as
>>>>>>> reason header, sometimes as reason, sometimes as Reason
>>> header, sometimes as
>>>>>>> Reason...
>>>>>> [MB] Logically, Reason is a "parameter" for the
>>> hi-entries. However,
>>>>>> rather than redefine the "parameter", we reuse the Reason
>>> header by
>>>>>> escaping it in the URI - the term Reason header was used
>>> for brevity.
>>>>>> I did add text in the -02 to clarify that in cases where it is
>>>>>> confusing. I can change all instances to refer to "escape a Reason
>>>>>> header in the hi-targeted-uri" rather than just "add a
>>> Reason header".
>>>>>> [/MB]
>>>>>>> 4. As another general comment, there are too many
>>> normative statements
>>>>>>> using the passive voice, and therefore hard to
>>> understand. To quote one
>>>>>>> example of the sort of ambiguity that can arise from
>>> using passive, in
>>>>>>> 7.3.2:
>>>>>>> "For retargets that are the result of an explicit SIP response, a
>>>>>>>  Reason MUST be associated with the hi-targeted-to-uri."
>>>>>>> Is this saying that an entity that inserts History-Info
>>> MUST include in
>>>>>>> hi-targeted-uri an escaped Reason header field? Or is
>>> this saying that a
>>>>>>> recipient of Reason MUST associate it with an
>>> hi-targeted-to-uri. I guess
>>>>>>> the first interpretation is more plausible, but why not
>>> say what is meant,
>>>>>>> rather than fudging it?
>>>>>> [MB] The Reason header is added to the hi-entry whose
>>>>>> hi-targeted-to-URI is being retargeted due to the response.  It is
>>>>>> added by the entity receiving the response.  Note that it
>>> is added to
>>>>>> the entry prior to the entry that is being added as a
>>> result of the
>>>>>> retargeting due to the response - i.e., it's not added to the
>>>>>> "current" hi-entry.  It's added to the previous.  The sentences
>>>>>> following the one that you highlight are intended to say
>>> just that.
>>>>>> That's why the term "associated" is loosely used because the next
>>>>>> sentences are the normative part. So, really, that first sentence
>>>>>> shouldn't be "MUST be" and would be more accurate to say
>>> "is". [/MB]
>>>>> I guess this isn't a new concern - its been there all
>>> along, but it seems
>>>>> very wrong to me. (Warning - this is long.) Specifically,
>>>>> There is a real difference between Reason as a parameter
>>> of an H-I entry and
>>>>> an H-I entry containing a URI that contains a Reason
>>> header as a URI
>>>>> parameter. A URI parameter has a specific meaning - it
>>> specifies a Header
>>>>> that is to be incorporated into a request that uses that
>>> URI as an R-URI.
>>>>> Depending on details of how H-I entries are constructed
>>> during retargeting,
>>>>> it may be that a retarget URI would contain URI
>>> parameters, and those would
>>>>> end up in an H-I entry. There could be a Reason header
>>> included in the
>>>>> retarget URI. I *think* the procedures for UAC and proxy
>>> imply that the
>>>>> retargeted request would be constructed first - thus
>>> removing embedded
>>>>> parameters and making them headers in the request -
>>> *before* capturing the
>>>>> R-URI for H-I, but I'm not certain of that. If not, then
>>> there could be
>>>>> ambiguity about the origin and meaning of a Reason header
>>> in an H-I URI.
>>>>> Even if that is not a problem, there are potential
>>> problems if an H-I entry
>>>>> is ever used to construct a new request. For instance, if
>>> someone were to
>>>>> analyze H-I to identify the URI of some entity (say the
>>> caller) in order to
>>>>> send a new request there, it would lift the URI from H-I
>>> and put it into a
>>>>> new request. Then the Reason URI parameter would,
>>> according to 3261, be
>>>>> removed and be added as a header to that new request. That isn't
>>>>> catastrophic, but I think its at least misleading, because:
>>>>> The reason is on the wrong URI. The Reason explains why
>>> the retargeted URI
>>>>> is being used, so it belongs in the message addressed to
>>> that URI. It makes
>>>>> no sense that it be in a request to the R-URI that, in
>>> some prior usage, was
>>>>> eventually retargeted.
>>>>> Bottom line: the H-I use of Reason as a URI header
>>> parameter is a hack and
>>>>> an abuse of that mechanism. It might be benign and
>>> forgivable if it were
>>>>> consistent with the intended use of that mechanism. But it
>>> seems it is not -
>>>>> that it is at best the re-purposing of that mechanism in a
>>> case where it,
>>>>> arguably, might be thought not to conflict with legitimate
>>> use of the URI
>>>>> header parameter mechanism. I'll argue it isn't that
>>> benign - that there are
>>>>> overlaps where the uses overlap.
>>>>> H-I should have had its own header field parameter for
>>> this purpose - not
>>>>> use the Reason header.
>>>>> This has ripple effects. Now we have
>>>>> draft-mohali-sipcore-reason-call-forwarding which is
>>> defining new reason
>>>>> codes which are intended specifically for use with H-I, without any
>>>>> contemplation of their use in a real Reason header in a
>>> request. This is
>>>>> insanity - but not for the author who is just trying to
>>> work within the
>>>>> existing system. Its just an example of the mess created
>>> by the abuse of
>>>>> repurposing Reason within H-I.
>>>>> I commented to the author of
>>> draft-mohali-sipcore-reason-call-forwarding
>>>>> that I felt any extensions to Reason needed to be
>>> justified in their own
>>>>> right, without reference to H-I. In fact what is proposed
>>> there *does* make
>>>>> sense in its own right, without regard to H-I *if* it is
>>> used in the
>>>>> retargeted request, rather than the request that is about
>>> to be retargeted.
>>>>> This could be fitted into H-I. When retargeting, it could
>>> be specified that
>>>>> a Reason header should be added to the new request,
>>> explaining why it was
>>>>> retargeted. Then whoever makes the H-I entry for that
>>> could include in the
>>>>> H-I entry for that request the R-URI of the request with
>>> any Reason headers
>>>>> in that request added to the entry as URI parameters.
>>> However this would be
>>>>> incompatible with 4244 because it would change which entry
>>> contains the
>>>>> reason.
>>>>>       Thanks,
>>>>>       Paul
>>>>> _______________________________________________
>>>>> sipcore mailing list
>>> _______________________________________________
>>> sipcore mailing list
>> _______________________________________________
>> sipcore mailing list
> _______________________________________________
> sipcore mailing list

sipcore mailing list