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

Shida Schubert <shida@ntt-at.com> Tue, 09 November 2010 06:28 UTC

Return-Path: <shida@ntt-at.com>
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 00E7F3A67AD for <sipcore@core3.amsl.com>; Mon, 8 Nov 2010 22:28:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -100.995
X-Spam-Level:
X-Spam-Status: No, score=-100.995 tagged_above=-999 required=5 tests=[AWL=-1.030, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, MANGLED_EXTNSN=2.3, USER_IN_WHITELIST=-100]
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 rnDqKAMia8Rf for <sipcore@core3.amsl.com>; Mon, 8 Nov 2010 22:28:07 -0800 (PST)
Received: from gateway15.websitewelcome.com (gateway15.websitewelcome.com [67.18.94.13]) by core3.amsl.com (Postfix) with SMTP id C45E63A67AE for <sipcore@ietf.org>; Mon, 8 Nov 2010 22:28:02 -0800 (PST)
Received: (qmail 25323 invoked from network); 9 Nov 2010 06:28:29 -0000
Received: from gator465.hostgator.com (69.56.174.130) by gateway15.websitewelcome.com with SMTP; 9 Nov 2010 06:28:29 -0000
Received: from [130.129.116.143] (port=52909 helo=dhcp-748f.meeting.ietf.org) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from <shida@ntt-at.com>) id 1PFhgp-0003uf-BN; Tue, 09 Nov 2010 00:28:20 -0600
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset=iso-8859-1
From: Shida Schubert <shida@ntt-at.com>
In-Reply-To: <B11765B89737A7498AF63EA84EC9F57715AC1E@ftrdmel1>
Date: Tue, 9 Nov 2010 15:28:21 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <881B134A-F820-4DCB-8A7B-AC22E76B1940@ntt-at.com>
References: <A444A0F8084434499206E78C106220CA023554628B@MCHP058A.global-ad.net><AANLkTi=B1qL2D-U85mMp3Dft2kvmuB9Sv5EAQ9vQBtot@mail.gmail.com><4CD6C020.7030603@cisco.com><AANLkTikGQuRP9Sbuh1zRktuVvk4fxDe6dXqb9-D9iZh=@mail.gmail.com><4CD7555F.30609@cisco.com><A444A0F8084434499206E78C106220CA02357AD53C@MCHP058A.global-ad.net><F57EC70C-8314-4DEB-BDEE-B85A2FD07D33@ntt-at.com><D4E3A40E-773D-4638-9A0E-7E8054E97236@acmepacket.com> <9886E5FCA6D76549A3011068483A4BD406D5CF8B@S4DE8PSAAQB.mitte.t-com.de> <B11765B89737A7498AF63EA84EC9F57715AC1E@ftrdmel1>
To: <marianne.mohali@orange-ftgroup.com> <marianne.mohali@orange-ftgroup.com>
X-Mailer: Apple Mail (2.1081)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - gator465.hostgator.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - ntt-at.com
Cc: sipcore@ietf.org, HKaplan@acmepacket.com, R.Jesske@telekom.de
Subject: Re: [sipcore] Reason as a parameter rather than anescapedheader (was Comments on draft-ietf-sipcore-rfc4244bis-02)
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: Tue, 09 Nov 2010 06:28:09 -0000

Hi Marianne;

 First of all, I have to disagree that RFC4244 is useless. AFAIK 
we are using it in our network and it is providing us with most of 
the functionality that we want, and with revised RFC4244bis 
according to guys actually implementing the stuff, it satisfies 
all the requirements we have so far.

 I agree that RFC4244 is not very simple, I think anybody that had 
to implement RFC4244 had a very difficult time trying to get the 
outcome they wanted. But I know at some country including Japan, 
it is the country wide standard used, and revising the spec in 
non-backword compatible way is going to be a nightmare. 

 I believe that RFC4244bis does clarify a lot of things that required 
guess work and it is a huge improvement over the original.

 Regards
  Shida

On Nov 9, 2010, at 9:42 AM, <marianne.mohali@orange-ftgroup.com> <marianne.mohali@orange-ftgroup.com> wrote:

> Hi,
> 
> Trying to show how RFC4244 was useless as it was designed (not for what it was imagined), I failed. So, I decided to do with the existing abilities with H-I and escaped Reason header...
> Being involved in 3GPP debates on this topic (usage for CDIV service), I just want to say that, 3GPP is not using an other solution. 3GPP, exactly uses what is possible with RFC4244 and RFC 4458: a combination of both Reason header field parameter escaped a URI (associated to redirecting hi-entry) and cause URI parameter (associated to the retargeted-to hi-entry) ; both with a parameter named "cause=xxx" but not with the same values significations and not located in the same hi-entry (childlishly simple!). You can imagine misinterpretation...
> If it is complicated only for CDIV service (Keith and Roland can confirm) what will be the future for enriched services??
> 
> Having a history header could be usefull ONLY if simple solutions are offered to identify services's needs, select entries by types... For that, a parmeter, a header parameter, a URI parameter... Whatever, if it's clearly defined.
> 
> As I've often been told that H-I was already implemented, I choose to propose extensions based on the current header to show where the reasoning can leads. If H-I has to be re-designed, ok, I can re-design the extensions accordingly. But if there is not possibility to have application/services information, IMHO, H-I will stay at IETF.    
> If we have the opportinity to fix inconsistencies, lack of clearness, even with no backward compatibility ; I'm in !
> 
> About the Reason escaped in the hi-targeted-to-uri parameter of the H-I header field, I'm not sure it has no sense to associate the Reason to the address applying the retargeting.
> Beyond the break of backward compatibility, in ISUP, the redirecting reason is associated to the redirecting user (for Call Forwarding).
> 
> I see 2 possible interpretations:
> 1- It is the Reason why a new R-URI has been contacted unsuccessfully. What is the cause of this Retargeted-to destination failure.
> 2- The reason why the Retageting entity decides to modified the R-URI. eg. After receiving a SIP response, after an internal processing (see my drafts)...
> 
> Case 1: It could make sense for a 3xx response where the retargeting is invloved in the response (explicitly request a redirection). In an other situation, it is not the target destination answering with a 486 Busy Here that can determines that call has to be retargeted (it is the entity receiving that response = the Retargeting). In general, we need to know which entity do what. 
> 
> 
> Whatever the one chosen, it has to be clearly mentionned, not only with "associated to the hi-retargeted-to-uri" not saying which one. 
> 
> 
> Marianne
> 
>> -----Message d'origine-----
>> De : sipcore-bounces@ietf.org 
>> [mailto:sipcore-bounces@ietf.org] De la part de R.Jesske@telekom.de
>> Envoyé : lundi 8 novembre 2010 15:53
>> À : HKaplan@acmepacket.com; shida@ntt-at.com
>> Cc : sipcore@ietf.org
>> Objet : Re: [sipcore] Reason as a parameter rather than 
>> anescapedheader (was Comments on draft-ietf-sipcore-rfc4244bis-02)
>> 
>> Hi,
>> 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 
>> http://tools.ietf.org/html/draft-mohali-sipcore-reason-extensi
>> on-application-00 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.
>> 
>> Comments? 
>> 
>> Best Regards
>> 
>> Roland 
>> 
>> -----Ursprüngliche Nachricht-----
>> Von: sipcore-bounces@ietf.org 
>> [mailto:sipcore-bounces@ietf.org] Im Auftrag von Hadriel Kaplan
>> Gesendet: Montag, 8. November 2010 07:32
>> An: Shida Schubert
>> Cc: sipcore@ietf.org
>> 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.  :)
>> 
>> -hadriel
>> 
>> 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: sipcore-bounces@ietf.org
>>>>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat
>>>>> Sent: 08 November 2010 01:42
>>>>> To: Mary Barnes
>>>>> Cc: sipcore@ietf.org
>>>>> 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<pkyzivat@cisco.com>  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@ietf.org
>>>>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>>>>> 
>>>>>> 
>>>>> _______________________________________________
>>>>> sipcore mailing list
>>>>> sipcore@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>>> 
>>>> _______________________________________________
>>>> sipcore mailing list
>>>> sipcore@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>> 
>>> _______________________________________________
>>> sipcore mailing list
>>> sipcore@ietf.org
>>> https://www.ietf.org/mailman/listinfo/sipcore
>> 
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>> _______________________________________________
>> sipcore mailing list
>> sipcore@ietf.org
>> https://www.ietf.org/mailman/listinfo/sipcore
>>