Return-Path: 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 190C63A684F for ; Sun, 7 Nov 2010 22:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.116 X-Spam-Level: X-Spam-Status: No, score=-1.116 tagged_above=-999 required=5 tests=[AWL=-0.621, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, RDNS_NONE=0.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 XK87rPzEHhQa for ; Sun, 7 Nov 2010 22:31:36 -0800 (PST) Received: from ETMail2.acmepacket.com (unknown [216.41.24.9]) by core3.amsl.com (Postfix) with ESMTP id DCEBC3A69BA for ; Sun, 7 Nov 2010 22:31:30 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by ETMail2.acmepacket.com (216.41.24.9) with Microsoft SMTP Server (TLS) id 8.1.240.5; Mon, 8 Nov 2010 01:31:49 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 8 Nov 2010 01:31:49 -0500 From: Hadriel Kaplan To: Shida Schubert Date: Mon, 8 Nov 2010 01:31:47 -0500 Thread-Topic: [sipcore] Reason as a parameter rather than an escaped header (was Comments on draft-ietf-sipcore-rfc4244bis-02) Thread-Index: Act/Dp+TWptJkoHxTKmW70ParzWVEw== Message-ID: References: <4CD6C020.7030603@cisco.com> <4CD7555F.30609@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAgAAAUAAAAFU Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Reason as a parameter rather than an escaped header (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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 06:31:38 -0000 I know this is beating a dead horse, but breaking backwards compatibility f= or Hist-Ifno may be a GOOD thing. Seriously. Afaict, "legacy" H-I is broken. It didn't solve people's probl= ems, in an interoperable fashion. That's why we needed 4244bis to begin wi= th, 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:" a= nd 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: >=20 > I don't agree. This is going to completely break backward > compatibility. >=20 > Regards > Shida >=20 > On Nov 8, 2010, at 1:55 PM, Elwell, John wrote: >=20 >> I agree with Paul's concerns, and I think we should use bis as an opport= unity to get this right, even if we have to grandfather some existing mecha= nism. The Mohali draft is evidence that the present mechanism causes furthe= r problems down the line. >>=20 >> John >>=20 >>> -----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 >>>=20 >>>=20 >>>=20 >>> 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. >>>=20 >>> 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. >>>=20 >>>> 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. >>>=20 >>> 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. >>>=20 >>>> 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. >>>=20 >>> 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. >>>=20 >>>> 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 . >>>>=20 >>>> Also, note that we cannot change this now even if it were the right >>>> thing to do due to backwards compatibility. >>>=20 >>> 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? >>>=20 >>> Thanks, >>> Paul >>>=20 >>>> Mary. >>>>=20 >>>> On Sun, Nov 7, 2010 at 9:05 AM, Paul >>> Kyzivat wrote: >>>>> The following is giving me heartburn: >>>>>=20 >>>>> On 11/2/2010 3:25 PM, Mary Barnes wrote: >>>>>=20 >>>>>>> 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... >>>>>>=20 >>>>>> [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] >>>>>=20 >>>>>>> 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? >>>>>>=20 >>>>>> [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] >>>>>=20 >>>>> 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, >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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: >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> H-I should have had its own header field parameter for >>> this purpose - not >>>>> use the Reason header. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> 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. >>>>>=20 >>>>> Thanks, >>>>> Paul >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>=20 >>>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore