From john.elwell@siemens-enterprise.com Mon Nov 1 03:23:41 2010 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 A5F9E3A67B3 for ; Mon, 1 Nov 2010 03:23:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.024 X-Spam-Level: X-Spam-Status: No, score=-102.024 tagged_above=-999 required=5 tests=[AWL=0.575, BAYES_00=-2.599, 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 Qa5DnGk++0gF for ; Mon, 1 Nov 2010 03:23:40 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 860F93A67D4 for ; Mon, 1 Nov 2010 03:23:40 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2127992; Mon, 1 Nov 2010 11:23:40 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 97CB61EB82AB; Mon, 1 Nov 2010 11:23:40 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 1 Nov 2010 11:23:40 +0100 From: "Elwell, John" To: "Worley, Dale R (Dale)" , "sipcore@ietf.org" Date: Mon, 1 Nov 2010 11:23:38 +0100 Thread-Topic: Reviewers needed for new music-on-hold technique Thread-Index: AQHLcVqTV/CZQEsmuUSbuxTZrQzVUpNMkT6g Message-ID: References: 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 Subject: Re: [sipcore] Reviewers needed for new music-on-hold technique 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, 01 Nov 2010 10:23:41 -0000 Dale, I haven't reviewed it in detail, but I see there is no mention of RTCP. Per= haps it isn't really relevant, except that it provides another reason why t= he media server needs to supply an IP address and port - even though it wil= l not receive RTP, it will receive RTCP. The RTCP port could be implicit or= explicit. John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Worley, Dale R (Dale) > Sent: 21 October 2010 21:00 > To: sipcore@ietf.org > Subject: [sipcore] Reviewers needed for new music-on-hold technique >=20 > I've written draft-worley-service-example to describe a=20 > music-on-hold technique which has some advantages over the=20 > technique in RFC 5359. (The two are mutually compatible, and=20 > both are compatible with almost all SIP UAs.) I am advancing=20 > this as an AD-sponsored RFC. I think I've fixed the last=20 > wrinkles and would like people to review the draft. >=20 > The -05 changes describe that (as in other third-party=20 > situations) it is not possible to handle codec numbers=20 > exactly correctly in all situations. But following certain=20 > guidelines provides correct behavior in the vast majority of cases. >=20 > Session Initiation Protocol Service Example -- Music on Hold > draft-worley-service-example-05 >=20 > The "music on hold" feature is one of the most desired features of > telephone systems in the business environment. "Music on hold" is > where, when one party to a call has the call "on hold",=20 > that party's > telephone provides an audio stream (often music) to be heard by the > other party. Architectural features of SIP make it difficult to > implement music-on-hold in a way that is fully compliant with the > standards. The implementation of music-on-hold described in this > document is fully effective and standards-compliant, and=20 > has a number > of advantages over the methods previously documented. In=20 > particular, > it is less likely to produce peculiar user interface=20 > effects and more > likely to work in systems which perform authentication than the > method of RFC 5359. >=20 > Thanks, >=20 > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From hannu.hietalahti@nokia.com Mon Nov 1 04:46:42 2010 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 596EC3A69A5 for ; Mon, 1 Nov 2010 04:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 d94h13J3XN8B for ; Mon, 1 Nov 2010 04:46:41 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 0CE173A67A6 for ; Mon, 1 Nov 2010 04:46:40 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id oA1BkKiU024943; Mon, 1 Nov 2010 06:46:29 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Nov 2010 13:46:08 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 1 Nov 2010 13:46:03 +0200 Received: from NOK-EUMSG-06.mgdnok.nokia.com ([94.245.81.109]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Mon, 1 Nov 2010 12:46:03 +0100 From: To: , , Date: Mon, 1 Nov 2010 12:46:02 +0100 Thread-Topic: [sipcore] Location Conveyance -04 submitted, here's the changes Thread-Index: Act2mlVdTb0CvQzFTY2pDhKiRuhu2gAAtZtwAMcwGpA= Message-ID: <5BAF85033CB5F3439C4DE153165522B1109FDD491C@NOK-EUMSG-06.mgdnok.nokia.com> References: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com> <625A3E65-E441-4340-A5E2-B847F8B964CF@bbn.com> <201010271838.o9RIcjgG008761@sj-core-5.cisco.com> <63EEFC46-26FC-4A69-B1A7-2CC79583B8B2@bbn.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-OriginalArrivalTime: 01 Nov 2010 11:46:03.0914 (UTC) FILETIME=[5CDE46A0:01CB79BA] X-Nokia-AV: Clean Cc: sipcore@ietf.org Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes 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, 01 Nov 2010 11:46:42 -0000 Hi Keith, yes, I remember you made this comment at Maastricht already, and I agree wi= th you that from 3GPP viewpoint we need encoding that allows *more than one= * piece of location information. In 3GPP case those would be typically the one obtained from the terminal an= d the one added by the serving network if it thinks it knows better.=20 But my imagination runs out after these two. Are you saying we need more th= an 2? BR, Hannu Hietalahti 3GPP TSG CT Chairman tel: +358 40 5021724 =20 >-----Original Message----- >From: sipcore-bounces@ietf.org=20 >[mailto:sipcore-bounces@ietf.org] On Behalf Of ext DRAGE, Keith (Keith) >Sent: 28 October, 2010 16:01 >To: Richard L. Barnes; James M. Polk >Cc: sipcore@ietf.org >Subject: Re: [sipcore] Location Conveyance -04 submitted,=20 >here's the changes > >To be more specific - we had a document that allowed multiple=20 >locations. It was reduced to one without any decision in that=20 >direction being made by the working group. It needs to go back=20 >to multiple values. > >In my view there are clear use cases where multiple values are=20 >required. > >regards > >Keith=20 > >> -----Original Message----- >> From: sipcore-bounces@ietf.org=20 >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Richard L. Barnes >> Sent: Thursday, October 28, 2010 1:19 PM >> To: James M. Polk >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] Location Conveyance -04 submitted,=20 >> here's the changes >>=20 >> >> I'm pretty comfortable with the document at this point,=20 >> but have just=20 >> >> one minor question: Why are you still limiting the number=20 >> of location=20 >> >> values? Why are three values harmful, but not two? This=20 >> still seems=20 >> >> like pointless ABNF legislation. >> > >> > we only added the ability to have a second locationValue=20 >because of=20 >> > your rough-loc ID. Before that, we were firm in not=20 >> allowing more than=20 >> > one. Given that choice, which do you like? >> > >> > Remember, this was Jon's proposal in SIPCORE in Anaheim, which it=20 >> > seemed everyone and their brother was agreeable with, so ... >>=20 >>=20 >> As I recall, the proposal was to just remove the limit on=20 >the number =20 >> of locations values, not to bump it up by one. From the minutes: >>=20 >> "Restore Geolocation header that has multiple URIs, even though we =20 >> would not recommend it. Entities inserting persence are responsbile =20 >> for any resulting errors. The header parameters distinguishing URIs =20 >> would not be added back in." >>=20 >> At least in my mind, multiple !=3D 2. >>=20 >> --Richard >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> > james >> > >> > >> >> --Richard >> >> >> >> >> >> >> >> >> >> On Oct 27, 2010, at 12:32 AM, James M. Polk wrote: >> >> >> >>> SIPCORE >> >>> >> >>> I've submitted the next version of Location Conveyance (-04) >> >>>=20 >> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio >> n-conveyance-04.txt >> >>> and I believe this version has addressed each open item from the >> >>> mailing list, as well as what was discussed and agreed to in the >> >>> Maastricht meeting. >> >>> >> >>> I have attempted to identify each open issue with the specific >> >>> resolution here (in no particular order): >> >>> >> >>> - Martin wanted Section 3 to be broken up into subsections, each >> >>> revolving around each of the 4 diagrams. I have done this. >> >>> >> >>> - allowed a maximum of two (up from one) locationValues to be >> >>> present in the Geolocation header value. The text however=20 >> recommends >> >>> against inserting a second value. This was agreed to in=20 >> Maastricht. >> >>> >> >>> - Because we're allowing a max of two locationValues,=20 >> they can be in >> >>> separate Geolocation headers in the SIP request. This scenario >> >>> necessitates bring a previous version's paragraph in=20 >> stating that a >> >>> 'SIP intermediary MUST inspect all instances of each Geolocation >> >>> header before considering the routing-allowed parameter to be >> >>> considered =3Dyes', to ensure there isn't a conflict in the 'other' >> >>> Geolocation header that states the policy is =3Dno. >> >>> >> >>> - with the ability to add a second locationValue, it is=20 >> necessary to >> >>> warn against doing this (confusion at the LRs). >> >>> >> >>> - Added the "you break it you bought it" philosophy to SIP >> >>> intermediaries that choose to insert a second location where one >> >>> already existed, especially for inserting a location URI in the >> >>> downstream SIP request. >> >>> >> >>> - Fixed the ABNF to handle zero, one or two (but no more) >> >>> locationValues according to the agreement in Maastricht. =20 >> There is a >> >>> one-off use case which won't be in play very often, but=20 >> is a WG item >> >>> in ECRIT that several wanted to allow the possibility for=20 >> (involving >> >>> allowing one coarse and one highly accurate location in=20 >> the same SIP >> >>> request). >> >>> >> >>> - Paul K. wanted the use-case in which a SIP intermediary=20 >> inserts a >> >>> locationValue where one didn't exist previously, and=20 >> received a 424 >> >>> (Bad Location Information) to that inserted location, from having >> >>> the 424 propagate towards the UAC (as the UAC might not=20 >> know what to >> >>> do with a 424). This is now covered in Section 4.3. >> >>> >> >>> - changed existing text to "MUST NOT" from "does not" about a 424 >> >>> not terminating an existing dialog (just increased the=20 >strength of >> >>> this. >> >>> >> >>> - I added the 424 to the table 2 entry in which the Geolocation >> >>> header can be in only this response. >> >>> >> >>> - I added text stating the conditions for adding a Geolocation >> >>> header value to the 424, to make it clear what is and what isn't >> >>> allowed for this. >> >>> >> >>> - Martin wanted me to add back in the top level Geolocation-Error >> >>> codes 100, 200, 300 and 400, which I did in section 4.3. >> >>> >> >>> - rejected the idea that the geolocation option-tag hasn't been >> >>> justified. >> >>> >> >>> - Added RFCs 2616, 2818 and HELD Deref ID to the=20 >> references section >> >>> because I added the ability to include HTTP: and HTTPS: URIs, and >> >>> stated if received, they should be dereferenced according to the >> >>> HELD Deref doc. >> >>> >> >>> - changed the Section 5 examples how Martin wanted them. >> >>> >> >>> - Stated that GEO-URIs are not appropriate for the SIP=20 >Geolocation >> >>> header, according to the discussion during the Maastricht Geopriv >> >>> meeting. >> >>> >> >>> - we changed the privacy section, and included a ref to=20 >> the Geopriv >> >>> Arch doc, according to the agreement in Geopriv at Maastricht. >> >>> >> >>> >> >>> Comments are encouraged >> >>> >> >>> We plan to request (3rd?) WGLC during the SIPCORE meeting=20 >> in Beijing >> >>> (to give folks a sense of our plans). >> >>> >> >>> James/Brian/Jon >> >>> >> >>> >> >>> _______________________________________________ >> >>> 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 >>=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 >= From dworley@avaya.com Mon Nov 1 10:47:22 2010 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 D93793A6A49 for ; Mon, 1 Nov 2010 10:47:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.693 X-Spam-Level: X-Spam-Status: No, score=-101.693 tagged_above=-999 required=5 tests=[AWL=0.906, BAYES_00=-2.599, 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 Nq0ESaEfosF6 for ; Mon, 1 Nov 2010 10:47:22 -0700 (PDT) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 744173A6A30 for ; Mon, 1 Nov 2010 10:47:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAD+ZzkyHCzI1/2dsb2JhbAChXXGlEAKaBoVFBI11 X-IronPort-AV: E=Sophos;i="4.58,275,1286164800"; d="scan'208";a="216508868" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 01 Nov 2010 13:47:21 -0400 X-IronPort-AV: E=Sophos;i="4.58,275,1286164800"; d="scan'208";a="532308387" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 01 Nov 2010 13:47:20 -0400 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Mon, 1 Nov 2010 13:47:20 -0400 From: "Worley, Dale R (Dale)" To: "Elwell, John" , "sipcore@ietf.org" Date: Mon, 1 Nov 2010 13:46:47 -0400 Thread-Topic: Reviewers needed for new music-on-hold technique Thread-Index: AQHLcVqTV/CZQEsmuUSbuxTZrQzVUpNMkT6ggBBljxE= Message-ID: References: , 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 Subject: Re: [sipcore] Reviewers needed for new music-on-hold technique 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, 01 Nov 2010 17:47:23 -0000 ________________________________________ From: Elwell, John [john.elwell@siemens-enterprise.com] I haven't reviewed it in detail, but I see there is no mention of RTCP. Per= haps it isn't really relevant, except that it provides another reason why t= he media server needs to supply an IP address and port - even though it wil= l not receive RTP, it will receive RTCP. The RTCP port could be implicit or= explicit. _______________________________________________ I hadn't thought about RTCP, but I'll put a note about it in the next versi= on. Thanks, Dale From mary.ietf.barnes@gmail.com Mon Nov 1 12:25:32 2010 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 36F8628C0DC for ; Mon, 1 Nov 2010 12:25:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 Vl5O3qCJrGCW for ; Mon, 1 Nov 2010 12:25:27 -0700 (PDT) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id E2F013A69FE for ; Mon, 1 Nov 2010 12:25:19 -0700 (PDT) Received: by gya6 with SMTP id 6so3807976gya.31 for ; Mon, 01 Nov 2010 12:25:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=b3Bz7EeLl2hj/ANhzlig47R4RMqIETZfd5bbmSSTEXc=; b=vLRZHcuXPnRDkXD1EpceG/FDDy1K1bErt19QqlUgcZSZXwypHd0dcKMWfhnzP+2fkl FHnY9/UGOBOKt3JiY8frZYqeS91Ceb7cme0hM0cWqmqThCqwYHq6Bfu8ZQgwq7wpkgNG Xivi7uL/sGmttoPc5fGxAAnEmBOA1M13PwZ3E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=usidrhznliubuOAmFlRkfLopzr/lXgQq3+2PiCw+v7+KORQEBg42woCMrLMqgfWmRQ MA52UGnlUzUQRbr7ySYXCOJXlAku14CdSHj0m6CMf6UssSDpsqgJfQ3FbLln3KTOW0Zw CjnHHPJ3IizDoX2j3dCx7xBBDr5Yc/ChILMVY= MIME-Version: 1.0 Received: by 10.151.9.8 with SMTP id m8mr19997063ybi.213.1288639520545; Mon, 01 Nov 2010 12:25:20 -0700 (PDT) Received: by 10.236.28.41 with HTTP; Mon, 1 Nov 2010 12:25:20 -0700 (PDT) In-Reply-To: References: <4C69ADA8.1010802@nostrum.com> <4C753AAA.3030407@nostrum.com> Date: Mon, 1 Nov 2010 14:25:20 -0500 Message-ID: From: Mary Barnes To: "Elwell, John" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sipcore@ietf.org" Subject: Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis 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, 01 Nov 2010 19:25:32 -0000 John, I apologize for missing these in the round of -02 changes. Per the other email thread, some of these are no longer relevant due to the extent of changes and some were redundant with issues raised (individually) in the tracker. So, I'll just responsd to those that are still relevant [MB]. I will note that one thing that would help me to avoid losing document reviews in my mailbox is that if folks could change the "Reminder" to (or prepend) the term "Review" (or "Comments") so that the email is a bit easier to find when one's mailbox is overflowing with issues from the issue tracker. Thanks, Mary. On Tue, Aug 31, 2010 at 11:32 AM, Elwell, John wrote: > I have reviewed the document as far as section 8, before running out of t= ime. Although the technical content of the document is reasonably stable, t= here are far too many minor problems that need fixing before it is ready to= go. Specific comments: > > 1. In general, there are too many normative statements (MUST/SHOULD) writ= ten in the passive voice, or in the active voice with an inappropriate subj= ect. I have pointed out a few of these in later comments, but all should be= checked. > > 2. It nearly always uses the term "header" rather than "header field", al= though never, as far as I know, meaning the entire SIP header. [MB] I'm not sure that I fully understand the concern. Can you point out a specific sentence or section of concern? The term "header" is used when it is referring to the History-Info header field, but that is done in other documents as well. In general, I think it's understood that it's referring to the header field when it's qualified. Perhaps you're referring to places where it is not qualified? The term hi-entry is used, as well. [/MB] > > 3. Section 2: > "The term "retarget" is used in this document to refer both to the > =A0 process of a Proxy Server/User Agent Client (UAC) changing a Uniform > =A0 Resource Identifier (URI) in a request based on the rules for > =A0 determining request targets as described in Section 16.5 =A0of [RFC32= 61] > =A0 and the subsequent forwarding of that request as described in section > =A0 16.6 of [RFC3261]." > Sections 16.5 and 16.6 of RFC 3261 are concerned only with proxies, so fo= r the UAC case it is inappropriate to say the term applies as described in = those sections. > > 4. Section 2: > "Noting that =A0[RFC3261] uses the term ... " > This sentence lacks a main clause. > > 5. Section 2: > "for which is =A0not" > Should be "for which it is not" > > 6. Section 3: > "by locating the first =A0entry just prior to the last hi-entry marked " > The word "first" is confusing. It seems to be redundant - unless it has s= ome special meaning that I have failed to grasp. > > 7. Section 4.1: > "and if the Request-URI was modified by a previous hop" > What is a hop? I tend to think of a hop as being the "wire" between two S= IP entities, but here it seems to be used to mean a SIP entity such as a pr= oxy. If we really want to use this term, we should define it. Check for oth= er instances too. [MB] I will change this to "previous SIP hop". Note that the term "hop" is used throught RFC 3263. If you would like, I could add a note in the terminology that the term is consistent with that. [/MB] > > 8. Section 4.1: > "A UAC that wants to ensure that privacy not > =A0 be applied to its identity =A0MUST include a Privacy header with a pr= iv- > =A0 value of "none."" > Privacy associated with a UAC's identity is outside the scope of History-= Info, which in general does not reveal a UAC's identity. > > 9. Section 4.1: > "reason =A0header" > Capitalize - should be "Reason". [MB] I'll fix that. It's now in section 5.1. [/MB] > > 10. "the reason =A0header =A0MUST be associated with the hi- > =A0 targeted-to-uri in the previous (last) hi-entry, as described in > =A0 Section 6.3.3" > I don't think 6.3.3 really tells me how to achieve this association - it = tells me when I must associate. But see also comments on 6.3.3. > > 11. Section 4.1: > "A new hi-entry MUST then be added for the URI from > =A0 the Contact header (which becomes the new Request-URI)." > This seems to be a rather convoluted way of saying that you use the new U= RI from the new Request URI to populate the new hi-entry. Mentioning Contac= t header (field) is confusing, since the recursed request also contains a C= ontact header field. [MB] I will just change that to: "The UAC MUST add an hi-entry using the Request-URI of the request as the hi-targeted-to-uri." [/MB] > > 12. Section 4.1: > "If the URI in the > =A0 Contact header =A0contains a "hit" URI parameter" > Make it clear this is the Contact header field from the 3xx response. > > 13. Section 4.1: > "Prior to any application usage of the information =A0by the UAC" > It is not clear what information this is talking about. Presumably H-I in= responses (and not just 3xx responses mentioned in the previous paragraph)= . > > 14. Section 4.2.1: > "The last hi-entry reflects the most recent > =A0 target and SHOULD contain =A0the Request-URI for the received request= ." > We cannot place a normative requirement on hi-entry. There is no normativ= e requirement on the UAS concerning receipt - the UAS is not in control of = what it receives. Should rephrase, e.g., "will normally contain". [MB] Agreed. [/MB] > > 15. Section 4.2.1: > "the > =A0 UAS MUST insert an hi-entry ." > How is this testable, other than by the fact that H-I will get reflected = in the response? But that should be covered in 4.2.2, shouldn't it? [MB] It's not testable on the wire. However, to applications at the UAS expecting that entry to be in a request that they might receive, it would seem appropriate that the field be added to the Request that is presented to any application. Doing that also ensures it will be in the response which is what the text currently states. I do not think that applications should be screening the information it receives to look for this situation. [/MB] > > 16. Section 4.2.1: > "If privacy is required, the procedures of > =A0 Section 6.3.2 MUST be used." > As far as I can see, 6.3.2 talks only about requests, whereas here we are= talking about responses. I am not convinced considerations are quite the s= ame. [MB] We did update the privacy section to be more clear that this is dealing with the privacy of the Request-URI for the UAS at which the requrest terminated. I think we can qualify that to say "If privacy is required for the response, ..."[/MB] > > 17. Section 4.2.2: > "The information can also be useful for > =A0 implementations with B2BUAs that include the History-Info, received > =A0 in the incoming request, in the subsequent outgoing request." > The words "implementations with B2BUAs" seem strange - why not just "B2BU= As"? [MB] I don't see this text in section 4.2.2. of -01 nor 5.2.2 of -02. I think you are referring to section 4.2.1. I'll change that it was trying to qualify a B2BUA as something that was very implementation specific and not standard SIP per se. [/MB] > > 18. Section 4.2.2: > "the UAS MUST > =A0 include any History-Info received in the request =A0in the subsequent > =A0 response" > Does this include 100 responses? [MB] I would think so. Can you think of a reason why it shouldn't? I would think it could be useful for debug. [/MB] > > 19. Section 4.2.2: > "The processing of History-Info in responses follows the methodology > =A0 described in Section 16.7 of [RFC3261 ]" > Section 16.7 is concerned only with proxies, not UASs. [MB] Yeah. I'm not quite sure when that strayed into that section. It's duplicated in section 6.2. I think it was a cut 'n paste error, since the general processing of HI is the same in responses whether sent by a proxy or UAS. [/MB] > > 20. Section 5.1.1: > "Upon receipt of an initial request for a dialog, or a standalone > =A0 request" > This is a different formulation from that in 4.1: "in any request not ass= ociated with an established dialog". [MB] The relates to issue 21 which Dale wanted to qualify to include early dialog's so I changed it to, "not associated with an early or established dialog". BTW, there's actually another occurrence in the requirements section in Appendix A (req 6), which matches the change that I made although the wording in 5.1 is still different, so that needs to be changed. [/MB] > > 21. Section 5.1.1: > "The proxy MUST add a "hit" SIP/SIPS URI parameter > =A0 =A0 =A0for the target URI that are determined" > Singular/plural error. > > 22. Section 5.1.1: > "If > =A0 =A0 =A0privacy is required, the procedures of Section 6.3.2 MUST be u= sed." > In fact I think one needs to go to 6.3.2 to find out how to determine whe= ther privacy is required, as well as for the procedures when it is found to= be required. [MB] I'll change that to: The procedures of section 7.3.1 MUST be followed to accomodate any privacy requirements. [/MB] > > 23. Section 5.1.2: > "When re-sending a request as a result of retargeting because of > =A0 failure" > Should we make it clear that this doesn't apply in case of 3xx, i.e., whi= ch errors it does apply to. [MB] It seems clear to me with the "i.e., either reception of error responses or a timeout which is considered to be an implicit 408 error response" as 3xx responses are not considered errors nor failures per RFC 3261 (i.e., the request still has the potential to be successful). We could just change it to read: " When re-sending a request as a result of retargeting because of either receipt of either an error response or a timeout which is considered to be an implicit 408 error response, ..." However, per the response to your comment #25, we may not need to separate the 3xx responses. [/MB] [/MB] > > 24. Section 5.1.2: > "If the received error response did not include > =A0 =A0 =A0any History-Info header fields, the proxy MUST use the same > =A0 =A0 =A0History-Info header fields that were sent in the outgoing requ= est > =A0 =A0 =A0that failed to build the outgoing request." > Hard to understand, because of the two instances of "outgoing request". P= erhaps: > "... MUST use the same History-Info header fields in the new outgoing req= uest as those sent in the request that failed." [MB] Yes - that is clearer. [/MB] > > 25. Sections 5.1.2 and 5.1.3. These are different, in that 5.1.2 allows f= or multiple branches failing, but 5.1.3 allows for only a single request en= countering 3xx. Firstly, it is possible >1 request can return 3xx (the prox= y is not forced to recurse immediately the first 3xx arrives). Secondly it = is possible that some failure responses might arrive before the 3xx on whic= h the proxy recurses. I think the new request should reflect H-I from all p= revious branches, not just the one leading to recursion. Also the tagging o= f the recursed request should take account of all previous branches. [MB] Yes - the redirection case should be consistent. And, really I don't know that we need a separate case for redirection as I agree it should send the aggregate information, as well. [/MB] > > 26. Section 5.2: > "A proxy that receives a request with the "histinfo" option tag in the > =A0 Supported header, SHOULD forward captured History-Info in subsequent, > =A0 provisional , and final responses " > Does this include 100 responses? [MB] That's the implication of "provisional" per RFC 3261. [/MB] > > 27. Section 5.2: > "A proxy MAY anonymize any hi-entry whose domain corresponds to a > =A0 domain for which it is responsible (as per [RFC3323 ])." > I don't think RFC 3323 tells me how to anonymize an hi-entry. [MB] RFC 3323 discusses anonymization and the role of an anonymizer, etc. So, I'm not clear on your concern. [/MB] > > 28. Section 5.2: > "The processing of History-Info in responses follows the methodology > =A0 described in Section 16.7 of [RFC3261], with the processing of > =A0 History-Info headers =A0adding an additional step, just before Step 9= , > =A0 "Forwarding the Response"." > What is meant by "processing of History-Info headers"? Does this refer to= the procedures of the first two paragraphs? [MB] Yes. [/MB] > > 29. Section 6.1: > "The format for > =A0 =A0 =A0this parameter is a string of digits, separated by dots to > =A0 =A0 =A0indicate the number of forward hops and retargets" > It is not clear from this whether the dots indicate the number of forward= hops or the number of retargets. I know it is explained in detail later, b= ut for somebody reading from front to back, this isn't very clear. Again, u= se of the word "hop" without definition is a concern. [MB] As I stated above, the term hop is used throughout RFC 3263. I can qualify as a SIP hop. Each dot is a hop and then each increment is a retarget. So, I could reword as: "The format for this parameter is a string of digits separated by dots. Each dot reflects a forward SIP hop and the value of the digit indicates the number retargets at each hop." [/MB] > > 30. Section 6.1: > "By adding the > =A0 =A0 =A0new entries in order (i.e., following existing entries per the > =A0 =A0 =A0details in Section 5.1 ), " > Section 5.1 doesn't really give details - in fact it refers forward to 6.= 3.4. [MB] Okay. I'll change the reference. [/MB] > > 31. Section 6.1: > "The latter case indicates that the > =A0 =A0 =A0History-Info entries for the domain MUST =A0be anonymized prio= r to > =A0 =A0 =A0forwarding, whereas the use of the Privacy header escaped in t= he > =A0 =A0 =A0hi-targeted-to-uri means that a specific hi-entry MUST be > =A0 =A0 =A0anonymized." > Two instances of bad use of normative language. The active voice should b= e used, with the subject indicating to what the requirement applies (presum= ably to an entity forwarding a request or response in certain circumstances= , but that surely is covered by the relevant procedures sections). I suspec= t we shouldn't be using normative language here. > > 32. Section 6.1: > "The following summarizes the =A0syntax of the History-Info header" > It looks to me like a formal definition, rather than a summary. > > 33. Section 6.1: > "hi-index =3D "index" EQUAL 1*DIGIT *("." 1*DIGIT) " > Would it be better to have a new definition index-value, which could then= be reused by mp-param? > > 34. Section 6.1: > "There MUST be no more than one hi-target parameter." > Presumably this is per hi-entry. > > 35. Section 6.3.1: > "SIP/SIPS URI target parameter for History-Info Header" > A confusing title, because the parameter seems to used in the URI when th= e URI is NOT in a History-Info header field. > > 36. Section 6.3.1: > "This > =A0 parameter is used to populate the hi-target parameter Section 6.3.5 > =A0 when a Request-URI is first added in a hi-entry in the History-Info > =A0 header field ." > I would say the parameter is used when an hi-entry is added containing th= e Request-URI value. > > 37. Section 6.3.1: > ""mp": The Request-URI is a URI that represents another user. =A0This > =A0 =A0 =A0occurs when a request is to be statically or dynamically > =A0 =A0 =A0retargeted to another user. " > So what if a request is retargeted to something that is neither a contact= nor the AOR of another user, e.g., retargeting a dial string to a service = URN? > > 38. Section 6.3.2: > This whole section talks about requests. What about responses? For exampl= e, a request from domain A arrives at a proxy in domain B, which inserts an= hi-entry requiring privacy before forwarding to the UAS. The UAS returns i= t in a response. I believe that hi-entry should be anonymized or removed be= fore passing back to domain A, but I can't find anything requiring this > > 39. Section 6.3.2: > "If the requestor has indicated a priv- > =A0 value of "session" or "header" in the request, all History-Info > =A0 entries MUST be anonymized =A0when the request leaves a domain for wh= ich > =A0 the intermediary is responsible." > Another bad formulation of a normative statement. It should use the activ= e voice, with a subject indicating the entity to which the requirement appl= ies. Or is that better handled in section 5 (perhaps it is already covered = - I haven't checked)? > > 40. Related to the above, I think the split of procedures between section= s 4 and 5 on the one hand and section 6 on the other hand is rather confusi= ng, and leads to a lot of forward and backward referencing and, in one or t= wo places, duplication I think. Perhaps it is too late to do much about thi= s, except to ensure consistency and avoid repetition. [MB] RFC 4244 had the order of those two sections switched. One of the co-authors preferred this approach. I personally preferred the former approach (i.e., defining the protocol elements and then defining the usage of such by each SIP entity). It is a chicken and egg thing really. I don't know that one approach has distinct advantages over others - I think the explanations need to be separate and that's consistent with other SIP RFCs (which follow the protocol definition first then the separate sections per SIP entity). We did try to remove as much duplication as possible, but I think sometimes it doesn't hurt to re-iterate things, although certainly that increases the burden in ensuring consistency. [/MB] > > 41. Section 6.3.3: > "For retargets that are the result of an explicit SIP response, a > =A0 Reason MUST be associated with the hi-targeted-to-uri ." > Again this is passive voice. Also, what is meant by "associated with". I = assume it means include a Reason in the hi-entry - why not say so? [MB] That's fine - the verbage is original RFC 4244 language, but can be changed as can the next two items (42,43). [/MB] > > 42. Section 6.3.2: > "MUST be included =A0as the > =A0 Reason associated with the hi-targeted-to-uri that has been > =A0 retargeted." > Again, the passive voice, and again I don't like the vague expression "as= sociated with". Similarly in subsequent sentences in this paragraph. > > 43. Section 6.3.4: > "an index MUST be =A0included along with the > =A0 Targeted-to-URI being captured" > Passive. Who or what does this requirement apply to? Presumably to any en= tity inserting an hi-entry, but not to an entity merely passing one on, or = a UAS reflecting an hi-entry back towards the UAC. > > 44. Section 6.3.4: > "Within each level, the > =A0 integer reflects the number of peer entities to which the request has > =A0 been routed ." > I don't think this is necessarily correct. For example, I could have two = branches, each with a different target, but both resolving to the same next= hop peer entity. Shouldn't it reflect the number of branches? [MB] That does mean the number of branches. Per your comment on section 6.1, I can reword that differently - i.e., consistent with the suggestion above. [/MB] > > 45. Section 6.3.4: > "With the index for each new > =A0 =A0 =A0 branch calculated by incrementing the last/lowest =A0digit at= the > =A0 =A0 =A0 current level" > What does last/lowest mean? I can understand "last", but not "lowest". I = spotted at least one other instance of this formulation. [MB] "lowest" is the "lowest" part of the branch if you will. Per comment above, I can change the description to match the response to your comment on 6.1. [/MB] > > 46. Section 6.3.4: > "For example, if the index in the History-Info header of > =A0 =A0 =A0 the received request was 1.2, then the index in the History-I= nfo > =A0 =A0 =A0 header field for the new hi-targeted- to-URI would be 1.3. " > This doesn't make sense. If the received request had index 1.2, surely th= e index of the new hi-entry would be 1.2.x? Or should "received request" be= "received 3xx response"? Even then I am not convinced that the index of th= e new hi-entry would necessarily be 1.3 - there may already have been a 1.3= , in which case it would have to be 1.4, and so on. > > 47. Section 6.3.4: > "Each index are =A0sequentially > =A0 =A0 =A0 assigned." > Change "are" to "is". > > 48. Section 6.3.4: > "Note that for each individual fork, only the entry corresponding > =A0 =A0 =A0 that =A0that fork is included " > Repeated "that". > > 49. Section 6.3.5: > "The hi-target attribute MUST =A0be added to the History-Info header if > =A0 the target to which the request is being forwarded contains a "hit" > =A0 URI parameter as defined in Section 6.3.1." > Again passive voice - what is the subject? Assuming it is a UAC or a prox= y, isn't such a requirement already covered by sections 4.1 and 5? We shoul= d not repeat normative statements in different sections. > > 50. Section 6.3.5: > "If the value of the "hit" parameter is "mp", then the index of the > =A0 entry corresponding to the original target (i.e., the "mapped-from" > =A0 target) MUST =A0be added as a parameter to "mp"." > Similar comment to above. > > 51. Section 6.3.5: > "2. =A0Entry prior to last entry with hi-target of "rc" in the Request > =A0 =A0 =A0 received by a UAS - i.e., the Request URI associated with the > =A0 =A0 =A0 destination of the request was determined based on a Register= ed > =A0 =A0 =A0 Contact." > I don't understand the i.e. part. The entry prior to the last entry with = "rc" was not determined based on a registered contact - it is the next entr= y (the one containing rc) that was so determined. > > 52. Section 6.3.5: > "4. =A0Entry prior to first entry with hi-target of "rc" in the Request > =A0 =A0 =A0 received by a UAS - i.e., the first Registered Contact to whi= ch > =A0 =A0 =A0 the request was targeted." > Similar comment. > > > John > > > > > > > > > > > > > > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach >> Sent: 25 August 2010 16:46 >> To: SIPCORE Chairs >> Cc: SIPCORE (Session Initiation Protocol Core) WG >> Subject: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis >> >> =A0 [as chair] >> >> As a reminder, we're just over halfway through this WGLC, and >> have not >> yet seen any comments. Please take some time to review this draft. >> >> /a >> >> On 8/16/10 4:29 PM, Adam Roach - SIPCORE Chair wrote: >> > >> > [as chair] >> > >> > A major author of draft-ietf-sipcore-rfc4244bis-01 believes >> that the >> > document has no remaining open issues, and is ready for evaluation. >> > Today, we are starting a two-week working group last call >> period. This >> > last call period ends on Tuesday, August 31st. >> > >> > The latest version of the document can be retrieved here: >> > >> > http://tools.ietf.org/html/draft-ietf-sipcore-rfc4244bis >> > >> > Any comments on the document should be sent to the SIPCORE >> mailing list. >> > >> > /a >> > >> > _______________________________________________ >> > 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 > From john.elwell@siemens-enterprise.com Mon Nov 1 15:13:44 2010 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 A69813A6A04 for ; Mon, 1 Nov 2010 15:13:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.139 X-Spam-Level: X-Spam-Status: No, score=-102.139 tagged_above=-999 required=5 tests=[AWL=0.460, BAYES_00=-2.599, 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 WAONeDzIlen3 for ; Mon, 1 Nov 2010 15:13:43 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 9C4233A69FB for ; Mon, 1 Nov 2010 15:13:42 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2133517 for sipcore@ietf.org; Mon, 1 Nov 2010 23:13:23 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 8497B23F0278 for ; Mon, 1 Nov 2010 23:13:23 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 1 Nov 2010 23:13:23 +0100 From: "Elwell, John" To: "sipcore@ietf.org" Date: Mon, 1 Nov 2010 23:13:20 +0100 Thread-Topic: Comments on draft-ietf-sipcore-rfc4244bis-02 Thread-Index: Act6Ef5KZlGL0+HEQeWLEjIf043SJg== Message-ID: 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 Subject: [sipcore] 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, 01 Nov 2010 22:13:44 -0000 Despite the effort that has gone into addressing comments raised by people = on -01, I still find -02 hard to understand in places. I have not had time = to review the whole document, but here are some comments up to section 7. J= ust as I finished writing this I saw Mary's response to my comments on -01,= which I will respond to tomorrow. Apologies for any overlap between the tw= o. 1. As a general comment that I have made before, the document still talks a= bout 'header' in many places where it is not referring to the entire header= for a SIP message, but only to a particular header field such as History-I= nfo. History-Info is only one field within the entire SIP header. See RFC 3= 261 section 6 - definitions of header and header field. Although RFC 3261 i= s not 100% consistent, in general things like Contact, To, From etc. are re= ferred to as header fields, and hence History-Info should be too. Section 4= .3 of RFC 4485 also calls for attention to be given to the correct use of t= erms header, header field and header field parameter, although it fails to = say what the correct use is and one has to rely on RFC 3261. Also there are some instances of "header parameter field", which is not a n= ormal term - it should be "header field parameter". 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 rea= son header, sometimes as reason, sometimes as Reason header, sometimes as R= eason... 3. The word "entry" is used inconsistently. Mostly it occurs in "hi-entry",= which is fine. But we also have "targeted-to-URI entry", "entry" (alone), = History-Info entry (which is probably fine, as long as we say what it is), = "header entry". Also "hi-entries". 4. As another general comment, there are too many normative statements usin= g 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 recip= ient of Reason MUST associate it with an hi-targeted-to-uri. I guess the fi= rst interpretation is more plausible, but why not say what is meant, rather= than fudging it? 5. Section 1: "there is a need for a standard mechanism within SIP for communicating the retargeting history of such a request" What is meant by "such a request"? We have not previously mentioned "reques= t". The preceding text has talked about calls, not requests, but perhaps it= should talk about requests. 6. Section 3: "Current network applications provide the ability for elements involved with the call to exchange additional information relating to how and why the call was routed to a particular destination" Change "exchange" to "obtain". I think that would fit better with the examp= les that follow. 7. Section 3: "Capturing aliases and Globally Routable User Agent URIs (GRUUs) [RFC5627], which can be overwritten by a home proxy upon receipt" The term "home proxy" is not used in RFC 3261. 8. Section 4: "The following information is carried in the History-Info header as detailed in Section 7.1:" I think it would be better to say "For each target used for forwarding a re= quest, the following information is carried in the History-Info header as = detailed in Section 7.1:" This would make it clear that there can be more than one instance of this i= nformation. 9. Section 4; "Target : A parameter indicating ..." This overloads the word target. Perhaps a better generic term for these par= ameters would be "Derivation". 10. Section 4: "A SIP entity changing the target of a request in response to a redirect or REFER" A REFER does not cause an entity to change the target of a request - it cau= ses an entity to generate a new request. H-I will indeed be added, but that= is covered by the statement above about creating a new request. 11. "propagates any History-Info header from the initial Request in the new request": Contrary to what it says in the first half of the sentence, this does indee= d acknowledge that we have a new request as a result of REFER. However, the= statement is incorrect because there is no normative statement (e.g., in s= ection 5) concerning this special behaviour for REFER. There is merely a re= quirement in Appendix A. 12. Section 4: "Note that an hi-entry is not included for the fork to sip:bob@192.0.2.7 " This is misleading, because there is indeed H-I sent to 192.0.2.7. I think = what it should say is that the H-I sent to 192.0.2.3 and subsequently sent = back to Alice does not contain an entry for target 192.0.2.7. 12bis. Section 5.1: "In addition, the UAC SHOULD add a History-Info header" Why is this only a SHOULD, not a MUST? What would be the exceptions? 13. Section 5.1: "As a result, intermediaries and the UAS at least know the original Request-URI, and if the Request- URI was modified by a previous hop. " This is inaccurate, since intermediaries may have removed H-I for privacy o= r other reasons. Best to delete the sentence. 14. Section 5.1: "A UAC that wants to ensure that privacy not be applied to its identity MUST include a Privacy header with a priv- value of "none"." I am not sure that 'none' ensures anything - it is only a request according= to RFC 3323. 15. Section 5.1: "A new hi-entry MUST then be added for the URI from the Contact header (which becomes the new Request-URI) " The Contact header field could contain >1 URIs. I think what we want to say= is that the UAC MUST populate the new-hi-entry with the URI chosen as the = Request-URI for the new request. 16. Section 5.1: "If the Contact header contained any of the header parameter fields defined in this specification" Don't understand. The parameters defined in this specification are paramete= rs of the History-Info header field, so would not appear in a Contact heade= r field. Admittedly there is some mention in 7.3.4 of using the parameters = in a Contact header field, but there is nothing that specifies the extended= syntax of the Contact header field. 17. Section 5.1: "MUST include the header parameter field as a header parameter field associated with the current hi-entry as described in Section 7.3.4." Is "current hi-entry" the "new hi-entry" from a couple of sentences earlier= ? 18. Section 5.2.1: "The last hi-entry reflects the most recent target and MUST contain the Request-URI for the received request," If I interpret this correctly, this is talking about what the UAS receives.= What the UAS receives is outside the control of the UAS, so we can't use R= FC 2119 language. Should be "will". 19. Section 5.2.1: "e.g., the last proxy does not support History-Info" In the previous sentence we used the term "previous entity", so it would be= better to stick to that term rather than "last proxy". 20. Section 5.2.1: "hi-index attribute" and "hi-target attribute" Up till now we have called these parameters rather than attributes. 21. Section 5.2.1: "The addition of the missing hi-entry ensures that the most complete information can be provided in the response ..." Not sure that it is "most complete" - "more complete" would be better, sinc= e there could still be some missing entries from upstream. 22. Section 5.2.1: "Prior to any application usage of the information, the validity MUST be ascertained" What MUST ascertain the validity - the UAS or the application? Use active v= oice. How does it do this? Is this testable? I don't believe we can use RFC= 2119 language here. 23. Section 5.2.2: "If the "histinfo" option tag is received in a request, the UAS MUST include any History-Info received in the request in the subsequent response" This is incorrect for a B2BUA - a B2BUA should be allowed to use informatio= n received from its other interface. Also it is not necessarily correct for= a regular UAS, since I would have thought a UAS should be required to incl= ude the hi-entry inserted in accordance with 5.2.1, rather than using just = the H-I received. 24. Section 5.2.2: "The processing of History-Info in responses follows the methodology described in Section 16.7 of [RFC3261], " We can't refer to 16.7 of RFC 3261, because that is for proxies, not UASs. 25. Section 5.3: "the redirect server MUST add the appropriate target header field parameter to each Contact header as described in Section 7.3.4." I don't think 7.3.4 tells me how to do this. Section 7.3.4 does mention the= Contact header field, but only in the context of adding these parameters t= o the History-Info header field (if I understand correctly). 26. Section 6: "A Reason MAY be associated with the hi-targeted-to-uri that has been retargeted as shown in the example in Appendix B.1." It would be good to be more precise, since B.1 is long - refer to A6, perha= ps. 27. Section 6.1.1: "The proxy MUST include an hi-index attribute with a value of "1"" It says we are inserting an entry, not replacing any existing entries. Valu= e "1" will not apply if there is an existing entry. 28. Section 6.1.1: "The proxy MUST add a separate hi-entry in each separate outgoing request for each of the current (outgoing) targets in the target set." Ambiguous - there should be only one entry per request - not one per target= in each request. Perhaps it should say "For each outgoing request relating to a target in th= e target set, the proxy MUST add a single hi-entry identifying that target.= For this new hi-entry, the proxy MUST..." 29. Section 6.1.2: "When re-sending a request as " I don't think this is really resending - we are retargeting, and therefore = changing some aspects of the original request. 30. Section 6.1.2: "in the order indicated by the indexing (see Section 7.3.3)" We really need a more precise reference - where in 7.3.3 does it tell me ho= w to use the aggregated information? 31. Section 6.1.2: "If the received error response did not include any History-Info header fields, the proxy MUST use the same History-Info header fields that were sent in the outgoing request that failed to build the outgoing request." First, the two instances of "outgoing request" are confusing - I think the = second should be "new outgoing request" or "retargeted request". Second, what if some responses include aggregated information and others do= n't? 32. Section 6.1.2: "Same as per Step 2 above for the normal forwarding case Section 6.1.1." This is confusing, because 6.1.1 is not on "normal forwarding case" but on = "initial requests". 33. Section 6.1.3: "When re-sending a request as " Again I don't think "re-sending" is the correct term. 34. Section 6.1.3: " Step 1: Including Previous Entries The proxy MUST include the History-Info header fields that were sent in the outgoing request that is being redirected." This seems to be a significant difference from the 4xx/5xx/6xx case. In tha= t case we include any hi-entries from downstream entities that have sent ba= ck the 4xx/5xx/6xx - why not in the 3xx case too? 35. Section 6.1.3: "add a Reason header this entry" Change "this" to "to this". 36. "MUST forward captured History-Info in subsequent, provisional, and final responses to the request sent by the ultimate UAS (see Section 5.2)" If a response does not contain any captured H-I (because the UAS doesn't su= pport it), is there any requirement on the proxy to generate it from its ow= n information? 37. Section 7.1: "Reason: An optional parameter for History-Info," It is not in the ABNF as a parameter of History-Info - in fact it is an esc= aped header field. 38. Section 7.1: "he hi-target is added for a hi-entry when it is first added in a History-Info header field, and only one value is permitted" I believe it should say "only one parameter is permitted". True that parame= ter ('rc' or 'mp') can have only one value, but I don't think that is the p= oint we are trying to make. 39. Section 7.3.2: "If the response contains a Reason header for a protocol that is not SIP (e.g., Q.850), it MUST be captured as an additional Reason associated with the hi-targeted-to-uri that has been retargeted, along with the SIP Response Code" I think this is saying that the entity MUST include two Reason parameters i= n the hi-entry. Perhaps we should state that more explicitly. Also, does or= der matter? 40. Section 7.3.3 item 6: "When a response is built and it represents the aggregate of responses to multiple forks " Suddenly we are talking about forks when previously we were talking about b= ranches. 41. Section 7.1.3, item 6: "For example, if a procesing entity received failure responses for forks 1.1.1 and 1.1.2, it would return both the 1.1.1 and 1.1.2 entries to the entity that generated the hi-entry with index of 1." I can't figure this out - shouldn't "index of 1" be "index of 1.1"? 42. Section 7.1.3, item 6: "See Appendix B.1 for an example" It is unclear where exactly in B.1 I am supposed to look - searching for '1= .1.1' or '1.1.2' produces no results. Please cite the specific messages. Although I didn't review beyond section 7, I happened to notice the followi= ng in Appendix B: "B. An entity (UA or proxy) retargeting in response to a redirect or REFER MUST include any Request History information from the redirect/REFER in the new request." It is unclear how you can retarget in response to a REFER. A REFER requests= leads to the generation of a new request - there is no retargeting. John= From keith.drage@alcatel-lucent.com Mon Nov 1 16:03:42 2010 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 5CB123A6A04 for ; Mon, 1 Nov 2010 16:03:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 t3bzn6KPzUey for ; Mon, 1 Nov 2010 16:03:41 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id 3C35D3A69C9 for ; Mon, 1 Nov 2010 16:03:39 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oA1N3XpU004683 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 2 Nov 2010 00:03:33 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Tue, 2 Nov 2010 00:03:33 +0100 From: "DRAGE, Keith (Keith)" To: "hannu.hietalahti@nokia.com" , "rbarnes@bbn.com" , "jmpolk@cisco.com" Date: Tue, 2 Nov 2010 00:03:33 +0100 Thread-Topic: [sipcore] Location Conveyance -04 submitted, here's the changes Thread-Index: Act2mlVdTb0CvQzFTY2pDhKiRuhu2gAAtZtwAMcwGpAAFNySEA== Message-ID: References: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com> <625A3E65-E441-4340-A5E2-B847F8B964CF@bbn.com> <201010271838.o9RIcjgG008761@sj-core-5.cisco.com> <63EEFC46-26FC-4A69-B1A7-2CC79583B8B2@bbn.com> <5BAF85033CB5F3439C4DE153165522B1109FDD491C@NOK-EUMSG-06.mgdnok.nokia.com> In-Reply-To: <5BAF85033CB5F3439C4DE153165522B1109FDD491C@NOK-EUMSG-06.mgdnok.nokia.com> 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-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes 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, 01 Nov 2010 23:03:42 -0000 If in 3GPP we look at subscription based business trunking arrangement. The end terminal includes one location. The enterprise network supporting the UE adds its own view of where the UE = is. The public network adds its own view of the location. That makes three. regards Keith=20 > -----Original Message----- > From: hannu.hietalahti@nokia.com [mailto:hannu.hietalahti@nokia.com]=20 > Sent: Monday, November 01, 2010 11:46 AM > To: DRAGE, Keith (Keith); rbarnes@bbn.com; jmpolk@cisco.com > Cc: sipcore@ietf.org > Subject: RE: [sipcore] Location Conveyance -04 submitted,=20 > here's the changes >=20 > Hi Keith, >=20 > yes, I remember you made this comment at Maastricht already,=20 > and I agree with you that from 3GPP viewpoint we need=20 > encoding that allows *more than one* piece of location information. >=20 > In 3GPP case those would be typically the one obtained from=20 > the terminal and the one added by the serving network if it=20 > thinks it knows better.=20 >=20 > But my imagination runs out after these two. Are you saying=20 > we need more than 2? >=20 > BR, > Hannu Hietalahti > 3GPP TSG CT Chairman > tel: +358 40 5021724 > =20 >=20 > >-----Original Message----- > >From: sipcore-bounces@ietf.org > >[mailto:sipcore-bounces@ietf.org] On Behalf Of ext DRAGE,=20 > Keith (Keith) > >Sent: 28 October, 2010 16:01 > >To: Richard L. Barnes; James M. Polk > >Cc: sipcore@ietf.org > >Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the=20 > >changes > > > >To be more specific - we had a document that allowed multiple=20 > >locations. It was reduced to one without any decision in=20 > that direction=20 > >being made by the working group. It needs to go back to multiple=20 > >values. > > > >In my view there are clear use cases where multiple values are=20 > >required. > > > >regards > > > >Keith > > > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Richard L. Barnes > >> Sent: Thursday, October 28, 2010 1:19 PM > >> To: James M. Polk > >> Cc: sipcore@ietf.org > >> Subject: Re: [sipcore] Location Conveyance -04 submitted,=20 > here's the=20 > >> changes > >>=20 > >> >> I'm pretty comfortable with the document at this point, > >> but have just > >> >> one minor question: Why are you still limiting the number > >> of location > >> >> values? Why are three values harmful, but not two? This > >> still seems > >> >> like pointless ABNF legislation. > >> > > >> > we only added the ability to have a second locationValue > >because of > >> > your rough-loc ID. Before that, we were firm in not > >> allowing more than > >> > one. Given that choice, which do you like? > >> > > >> > Remember, this was Jon's proposal in SIPCORE in Anaheim,=20 > which it=20 > >> > seemed everyone and their brother was agreeable with, so ... > >>=20 > >>=20 > >> As I recall, the proposal was to just remove the limit on > >the number > >> of locations values, not to bump it up by one. From the minutes: > >>=20 > >> "Restore Geolocation header that has multiple URIs, even though we=20 > >> would not recommend it. Entities inserting persence are=20 > responsbile=20 > >> for any resulting errors. The header parameters=20 > distinguishing URIs=20 > >> would not be added back in." > >>=20 > >> At least in my mind, multiple !=3D 2. > >>=20 > >> --Richard > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >>=20 > >> > james > >> > > >> > > >> >> --Richard > >> >> > >> >> > >> >> > >> >> > >> >> On Oct 27, 2010, at 12:32 AM, James M. Polk wrote: > >> >> > >> >>> SIPCORE > >> >>> > >> >>> I've submitted the next version of Location Conveyance (-04) > >> >>>=20 > >> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio > >> n-conveyance-04.txt > >> >>> and I believe this version has addressed each open=20 > item from the=20 > >> >>> mailing list, as well as what was discussed and agreed=20 > to in the=20 > >> >>> Maastricht meeting. > >> >>> > >> >>> I have attempted to identify each open issue with the specific=20 > >> >>> resolution here (in no particular order): > >> >>> > >> >>> - Martin wanted Section 3 to be broken up into=20 > subsections, each=20 > >> >>> revolving around each of the 4 diagrams. I have done this. > >> >>> > >> >>> - allowed a maximum of two (up from one) locationValues to be=20 > >> >>> present in the Geolocation header value. The text however > >> recommends > >> >>> against inserting a second value. This was agreed to in > >> Maastricht. > >> >>> > >> >>> - Because we're allowing a max of two locationValues, > >> they can be in > >> >>> separate Geolocation headers in the SIP request. This scenario=20 > >> >>> necessitates bring a previous version's paragraph in > >> stating that a > >> >>> 'SIP intermediary MUST inspect all instances of each=20 > Geolocation=20 > >> >>> header before considering the routing-allowed parameter to be=20 > >> >>> considered =3Dyes', to ensure there isn't a conflict in=20 > the 'other' > >> >>> Geolocation header that states the policy is =3Dno. > >> >>> > >> >>> - with the ability to add a second locationValue, it is > >> necessary to > >> >>> warn against doing this (confusion at the LRs). > >> >>> > >> >>> - Added the "you break it you bought it" philosophy to SIP=20 > >> >>> intermediaries that choose to insert a second location=20 > where one=20 > >> >>> already existed, especially for inserting a location=20 > URI in the=20 > >> >>> downstream SIP request. > >> >>> > >> >>> - Fixed the ABNF to handle zero, one or two (but no more)=20 > >> >>> locationValues according to the agreement in Maastricht. > >> There is a > >> >>> one-off use case which won't be in play very often, but > >> is a WG item > >> >>> in ECRIT that several wanted to allow the possibility for > >> (involving > >> >>> allowing one coarse and one highly accurate location in > >> the same SIP > >> >>> request). > >> >>> > >> >>> - Paul K. wanted the use-case in which a SIP intermediary > >> inserts a > >> >>> locationValue where one didn't exist previously, and > >> received a 424 > >> >>> (Bad Location Information) to that inserted location,=20 > from having=20 > >> >>> the 424 propagate towards the UAC (as the UAC might not > >> know what to > >> >>> do with a 424). This is now covered in Section 4.3. > >> >>> > >> >>> - changed existing text to "MUST NOT" from "does not"=20 > about a 424=20 > >> >>> not terminating an existing dialog (just increased the > >strength of > >> >>> this. > >> >>> > >> >>> - I added the 424 to the table 2 entry in which the=20 > Geolocation=20 > >> >>> header can be in only this response. > >> >>> > >> >>> - I added text stating the conditions for adding a Geolocation=20 > >> >>> header value to the 424, to make it clear what is and=20 > what isn't=20 > >> >>> allowed for this. > >> >>> > >> >>> - Martin wanted me to add back in the top level=20 > Geolocation-Error=20 > >> >>> codes 100, 200, 300 and 400, which I did in section 4.3. > >> >>> > >> >>> - rejected the idea that the geolocation option-tag=20 > hasn't been=20 > >> >>> justified. > >> >>> > >> >>> - Added RFCs 2616, 2818 and HELD Deref ID to the > >> references section > >> >>> because I added the ability to include HTTP: and=20 > HTTPS: URIs, and=20 > >> >>> stated if received, they should be dereferenced=20 > according to the=20 > >> >>> HELD Deref doc. > >> >>> > >> >>> - changed the Section 5 examples how Martin wanted them. > >> >>> > >> >>> - Stated that GEO-URIs are not appropriate for the SIP > >Geolocation > >> >>> header, according to the discussion during the=20 > Maastricht Geopriv=20 > >> >>> meeting. > >> >>> > >> >>> - we changed the privacy section, and included a ref to > >> the Geopriv > >> >>> Arch doc, according to the agreement in Geopriv at Maastricht. > >> >>> > >> >>> > >> >>> Comments are encouraged > >> >>> > >> >>> We plan to request (3rd?) WGLC during the SIPCORE meeting > >> in Beijing > >> >>> (to give folks a sense of our plans). > >> >>> > >> >>> James/Brian/Jon > >> >>> > >> >>> > >> >>> _______________________________________________ > >> >>> 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 > >>=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 > >= From hannu.hietalahti@nokia.com Mon Nov 1 23:49:46 2010 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 E3BF83A6811 for ; Mon, 1 Nov 2010 23:49:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 vPPvJAu4n8+H for ; Mon, 1 Nov 2010 23:49:45 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 945233A67E2 for ; Mon, 1 Nov 2010 23:49:44 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id oA26mmCU017775; Tue, 2 Nov 2010 08:48:49 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Nov 2010 08:48:48 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 2 Nov 2010 08:48:47 +0200 Received: from NOK-EUMSG-06.mgdnok.nokia.com ([94.245.81.109]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 2 Nov 2010 07:48:27 +0100 From: To: , , Date: Tue, 2 Nov 2010 07:48:25 +0100 Thread-Topic: [sipcore] Location Conveyance -04 submitted, here's the changes Thread-Index: Act2mlVdTb0CvQzFTY2pDhKiRuhu2gAAtZtwAMcwGpAAFNySEAATC3FA Message-ID: <5BAF85033CB5F3439C4DE153165522B1109FDD4CCF@NOK-EUMSG-06.mgdnok.nokia.com> References: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com> <625A3E65-E441-4340-A5E2-B847F8B964CF@bbn.com> <201010271838.o9RIcjgG008761@sj-core-5.cisco.com> <63EEFC46-26FC-4A69-B1A7-2CC79583B8B2@bbn.com> <5BAF85033CB5F3439C4DE153165522B1109FDD491C@NOK-EUMSG-06.mgdnok.nokia.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-OriginalArrivalTime: 02 Nov 2010 06:48:47.0979 (UTC) FILETIME=[003C53B0:01CB7A5A] X-Nokia-AV: Clean Cc: sipcore@ietf.org Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes 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: Tue, 02 Nov 2010 06:49:47 -0000 Thanks, Keith, I was not sure why the public network would add its idea of the user locati= on if it has received one from the corporate network already, but I can't s= ee why it would not be allowed to do so either. So it seems your are right. BR, Hannu Hietalahti 3GPP TSG CT Chairman tel: +358 40 5021724 =20 >-----Original Message----- >From: ext DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]=20 >Sent: 02 November, 2010 01:04 >To: Hietalahti Hannu (Nokia-CIC/Oulu); rbarnes@bbn.com;=20 >jmpolk@cisco.com >Cc: sipcore@ietf.org >Subject: RE: [sipcore] Location Conveyance -04 submitted,=20 >here's the changes > >If in 3GPP we look at subscription based business trunking arrangement. > >The end terminal includes one location. > >The enterprise network supporting the UE adds its own view of=20 >where the UE is. > >The public network adds its own view of the location. > >That makes three. > >regards > >Keith=20 > >> -----Original Message----- >> From: hannu.hietalahti@nokia.com [mailto:hannu.hietalahti@nokia.com]=20 >> Sent: Monday, November 01, 2010 11:46 AM >> To: DRAGE, Keith (Keith); rbarnes@bbn.com; jmpolk@cisco.com >> Cc: sipcore@ietf.org >> Subject: RE: [sipcore] Location Conveyance -04 submitted,=20 >> here's the changes >>=20 >> Hi Keith, >>=20 >> yes, I remember you made this comment at Maastricht already,=20 >> and I agree with you that from 3GPP viewpoint we need=20 >> encoding that allows *more than one* piece of location information. >>=20 >> In 3GPP case those would be typically the one obtained from=20 >> the terminal and the one added by the serving network if it=20 >> thinks it knows better.=20 >>=20 >> But my imagination runs out after these two. Are you saying=20 >> we need more than 2? >>=20 >> BR, >> Hannu Hietalahti >> 3GPP TSG CT Chairman >> tel: +358 40 5021724 >> =20 >>=20 >> >-----Original Message----- >> >From: sipcore-bounces@ietf.org >> >[mailto:sipcore-bounces@ietf.org] On Behalf Of ext DRAGE,=20 >> Keith (Keith) >> >Sent: 28 October, 2010 16:01 >> >To: Richard L. Barnes; James M. Polk >> >Cc: sipcore@ietf.org >> >Subject: Re: [sipcore] Location Conveyance -04 submitted,=20 >here's the=20 >> >changes >> > >> >To be more specific - we had a document that allowed multiple=20 >> >locations. It was reduced to one without any decision in=20 >> that direction=20 >> >being made by the working group. It needs to go back to multiple=20 >> >values. >> > >> >In my view there are clear use cases where multiple values are=20 >> >required. >> > >> >regards >> > >> >Keith >> > >> >> -----Original Message----- >> >> From: sipcore-bounces@ietf.org >> >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Richard L. Barnes >> >> Sent: Thursday, October 28, 2010 1:19 PM >> >> To: James M. Polk >> >> Cc: sipcore@ietf.org >> >> Subject: Re: [sipcore] Location Conveyance -04 submitted,=20 >> here's the=20 >> >> changes >> >>=20 >> >> >> I'm pretty comfortable with the document at this point, >> >> but have just >> >> >> one minor question: Why are you still limiting the number >> >> of location >> >> >> values? Why are three values harmful, but not two? This >> >> still seems >> >> >> like pointless ABNF legislation. >> >> > >> >> > we only added the ability to have a second locationValue >> >because of >> >> > your rough-loc ID. Before that, we were firm in not >> >> allowing more than >> >> > one. Given that choice, which do you like? >> >> > >> >> > Remember, this was Jon's proposal in SIPCORE in Anaheim,=20 >> which it=20 >> >> > seemed everyone and their brother was agreeable with, so ... >> >>=20 >> >>=20 >> >> As I recall, the proposal was to just remove the limit on >> >the number >> >> of locations values, not to bump it up by one. From the minutes: >> >>=20 >> >> "Restore Geolocation header that has multiple URIs, even=20 >though we=20 >> >> would not recommend it. Entities inserting persence are=20 >> responsbile=20 >> >> for any resulting errors. The header parameters=20 >> distinguishing URIs=20 >> >> would not be added back in." >> >>=20 >> >> At least in my mind, multiple !=3D 2. >> >>=20 >> >> --Richard >> >>=20 >> >>=20 >> >>=20 >> >>=20 >> >>=20 >> >>=20 >> >>=20 >> >> > james >> >> > >> >> > >> >> >> --Richard >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Oct 27, 2010, at 12:32 AM, James M. Polk wrote: >> >> >> >> >> >>> SIPCORE >> >> >>> >> >> >>> I've submitted the next version of Location Conveyance (-04) >> >> >>>=20 >> >> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio >> >> n-conveyance-04.txt >> >> >>> and I believe this version has addressed each open=20 >> item from the=20 >> >> >>> mailing list, as well as what was discussed and agreed=20 >> to in the=20 >> >> >>> Maastricht meeting. >> >> >>> >> >> >>> I have attempted to identify each open issue with the=20 >specific=20 >> >> >>> resolution here (in no particular order): >> >> >>> >> >> >>> - Martin wanted Section 3 to be broken up into=20 >> subsections, each=20 >> >> >>> revolving around each of the 4 diagrams. I have done this. >> >> >>> >> >> >>> - allowed a maximum of two (up from one) locationValues to be=20 >> >> >>> present in the Geolocation header value. The text however >> >> recommends >> >> >>> against inserting a second value. This was agreed to in >> >> Maastricht. >> >> >>> >> >> >>> - Because we're allowing a max of two locationValues, >> >> they can be in >> >> >>> separate Geolocation headers in the SIP request. This=20 >scenario=20 >> >> >>> necessitates bring a previous version's paragraph in >> >> stating that a >> >> >>> 'SIP intermediary MUST inspect all instances of each=20 >> Geolocation=20 >> >> >>> header before considering the routing-allowed parameter to be=20 >> >> >>> considered =3Dyes', to ensure there isn't a conflict in=20 >> the 'other' >> >> >>> Geolocation header that states the policy is =3Dno. >> >> >>> >> >> >>> - with the ability to add a second locationValue, it is >> >> necessary to >> >> >>> warn against doing this (confusion at the LRs). >> >> >>> >> >> >>> - Added the "you break it you bought it" philosophy to SIP=20 >> >> >>> intermediaries that choose to insert a second location=20 >> where one=20 >> >> >>> already existed, especially for inserting a location=20 >> URI in the=20 >> >> >>> downstream SIP request. >> >> >>> >> >> >>> - Fixed the ABNF to handle zero, one or two (but no more)=20 >> >> >>> locationValues according to the agreement in Maastricht. >> >> There is a >> >> >>> one-off use case which won't be in play very often, but >> >> is a WG item >> >> >>> in ECRIT that several wanted to allow the possibility for >> >> (involving >> >> >>> allowing one coarse and one highly accurate location in >> >> the same SIP >> >> >>> request). >> >> >>> >> >> >>> - Paul K. wanted the use-case in which a SIP intermediary >> >> inserts a >> >> >>> locationValue where one didn't exist previously, and >> >> received a 424 >> >> >>> (Bad Location Information) to that inserted location,=20 >> from having=20 >> >> >>> the 424 propagate towards the UAC (as the UAC might not >> >> know what to >> >> >>> do with a 424). This is now covered in Section 4.3. >> >> >>> >> >> >>> - changed existing text to "MUST NOT" from "does not"=20 >> about a 424=20 >> >> >>> not terminating an existing dialog (just increased the >> >strength of >> >> >>> this. >> >> >>> >> >> >>> - I added the 424 to the table 2 entry in which the=20 >> Geolocation=20 >> >> >>> header can be in only this response. >> >> >>> >> >> >>> - I added text stating the conditions for adding a=20 >Geolocation=20 >> >> >>> header value to the 424, to make it clear what is and=20 >> what isn't=20 >> >> >>> allowed for this. >> >> >>> >> >> >>> - Martin wanted me to add back in the top level=20 >> Geolocation-Error=20 >> >> >>> codes 100, 200, 300 and 400, which I did in section 4.3. >> >> >>> >> >> >>> - rejected the idea that the geolocation option-tag=20 >> hasn't been=20 >> >> >>> justified. >> >> >>> >> >> >>> - Added RFCs 2616, 2818 and HELD Deref ID to the >> >> references section >> >> >>> because I added the ability to include HTTP: and=20 >> HTTPS: URIs, and=20 >> >> >>> stated if received, they should be dereferenced=20 >> according to the=20 >> >> >>> HELD Deref doc. >> >> >>> >> >> >>> - changed the Section 5 examples how Martin wanted them. >> >> >>> >> >> >>> - Stated that GEO-URIs are not appropriate for the SIP >> >Geolocation >> >> >>> header, according to the discussion during the=20 >> Maastricht Geopriv=20 >> >> >>> meeting. >> >> >>> >> >> >>> - we changed the privacy section, and included a ref to >> >> the Geopriv >> >> >>> Arch doc, according to the agreement in Geopriv at Maastricht. >> >> >>> >> >> >>> >> >> >>> Comments are encouraged >> >> >>> >> >> >>> We plan to request (3rd?) WGLC during the SIPCORE meeting >> >> in Beijing >> >> >>> (to give folks a sense of our plans). >> >> >>> >> >> >>> James/Brian/Jon >> >> >>> >> >> >>> >> >> >>> _______________________________________________ >> >> >>> 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 >> >>=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 >> >= From john.elwell@siemens-enterprise.com Tue Nov 2 02:06:15 2010 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 423603A6872 for ; Tue, 2 Nov 2010 02:06:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.27 X-Spam-Level: X-Spam-Status: No, score=-102.27 tagged_above=-999 required=5 tests=[AWL=0.329, BAYES_00=-2.599, 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 PHjSG0rExqZE for ; Tue, 2 Nov 2010 02:06:14 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id A5B0D3A68B6 for ; Tue, 2 Nov 2010 02:06:13 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2138315; Tue, 2 Nov 2010 10:06:15 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 012BB23F0278; Tue, 2 Nov 2010 10:06:15 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 2 Nov 2010 10:06:14 +0100 From: "Elwell, John" To: Mary Barnes Date: Tue, 2 Nov 2010 10:06:13 +0100 Thread-Topic: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis Thread-Index: Act5+pNorfCuzKISSn61y7INZ5j3DQAbCzvg Message-ID: References: <4C69ADA8.1010802@nostrum.com> <4C753AAA.3030407@nostrum.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis 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: Tue, 02 Nov 2010 09:06:15 -0000 Mary, I have responded below, stripping out the stuff where I have nothing furthe= r to add.=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 > Sent: 01 November 2010 19:25 > To: Elwell, John > Cc: sipcore@ietf.org > Subject: Re: [sipcore] REMINDER: Re: WGLC:=20 > draft-ietf-sipcore-rfc4244bis >=20 > John, >=20 > I apologize for missing these in the round of -02 changes. Per the > other email thread, some of these are no longer relevant due to the > extent of changes and some were redundant with issues raised > (individually) in the tracker. So, I'll just responsd to those that > are still relevant [MB]. I will note that one thing that would help > me to avoid losing document reviews in my mailbox is that if folks > could change the "Reminder" to (or prepend) the term "Review" (or > "Comments") so that the email is a bit easier to find when one's > mailbox is overflowing with issues from the issue tracker. [JRE] Yes, good idea. >=20 > Thanks, > Mary. >=20 > On Tue, Aug 31, 2010 at 11:32 AM, Elwell, John > wrote: > > I have reviewed the document as far as section 8, before=20 > running out of time. Although the technical content of the=20 > document is reasonably stable, there are far too many minor=20 > problems that need fixing before it is ready to go. Specific comments: > > > > 1. In general, there are too many normative statements=20 > (MUST/SHOULD) written in the passive voice, or in the active=20 > voice with an inappropriate subject. I have pointed out a few=20 > of these in later comments, but all should be checked. > > > > 2. It nearly always uses the term "header" rather than=20 > "header field", although never, as far as I know, meaning the=20 > entire SIP header. > [MB] I'm not sure that I fully understand the concern. Can you point > out a specific sentence or section of concern? The term "header" is > used when it is referring to the History-Info header field, but that > is done in other documents as well. In general, I think it's > understood that it's referring to the header field when it's > qualified. Perhaps you're referring to places where it is not > qualified? The term hi-entry is used, as well. > [/MB] [JRE] I have explained in more detail in my comments on -02. > > > > 7. Section 4.1: > > "and if the Request-URI was modified by a previous hop" > > What is a hop? I tend to think of a hop as being the "wire"=20 > between two SIP entities, but here it seems to be used to=20 > mean a SIP entity such as a proxy. If we really want to use=20 > this term, we should define it. Check for other instances too. > [MB] I will change this to "previous SIP hop". Note that the term > "hop" is used throught RFC 3263. If you would like, I could add a note > in the terminology that the term is consistent with that. [/MB] [JRE] I am not even sure it is consistent in RFC 3263. Anyway, given existi= ng mixed usage of the term, I withdraw the comment. > > > > 15. Section 4.2.1: > > "the > > =A0 UAS MUST insert an hi-entry ." > > How is this testable, other than by the fact that H-I will=20 > get reflected in the response? But that should be covered in=20 > 4.2.2, shouldn't it? > [MB] It's not testable on the wire. However, to applications at the > UAS expecting that entry to be in a request that they might receive, > it would seem appropriate that the field be added to the Request that > is presented to any application. Doing that also ensures it will be in > the response which is what the text currently states. I do not think > that applications should be screening the information it receives to > look for this situation. [/MB] [JRE] OK, I can live with it as it is. > > > > 17. Section 4.2.2: > > "The information can also be useful for > > =A0 implementations with B2BUAs that include the=20 > History-Info, received > > =A0 in the incoming request, in the subsequent outgoing request." > > The words "implementations with B2BUAs" seem strange - why=20 > not just "B2BUAs"? > [MB] I don't see this text in section 4.2.2. of -01 nor 5.2.2 of -02. > I think you are referring to section 4.2.1. I'll change that it was > trying to qualify a B2BUA as something that was very implementation > specific and not standard SIP per se. [/MB] [JRE] Yes, sorry, it was 4.2.1. > > > > 18. Section 4.2.2: > > "the UAS MUST > > =A0 include any History-Info received in the request =A0in the=20 > subsequent > > =A0 response" > > Does this include 100 responses? > [MB] I would think so. Can you think of a reason why it shouldn't? I > would think it could be useful for debug. [/MB] [JRE] The 100 response typically only travels back a single hop, so the ben= efit of H-I in a 100 is marginal. Also some implementations might send back= a 100 response quite early during processing, perhaps even before they dec= ide whether to act as a proxy, a UAS or a redirect, so knowing how to popul= ate H-I in a 100 might be difficult. > > > > 25. Sections 5.1.2 and 5.1.3. These are different, in that=20 > 5.1.2 allows for multiple branches failing, but 5.1.3 allows=20 > for only a single request encountering 3xx. Firstly, it is=20 > possible >1 request can return 3xx (the proxy is not forced=20 > to recurse immediately the first 3xx arrives). Secondly it is=20 > possible that some failure responses might arrive before the=20 > 3xx on which the proxy recurses. I think the new request=20 > should reflect H-I from all previous branches, not just the=20 > one leading to recursion. Also the tagging of the recursed=20 > request should take account of all previous branches. > [MB] Yes - the redirection case should be consistent. And, really I > don't know that we need a separate case for redirection as I agree it > should send the aggregate information, as well. [/MB] [JRE] I think I made a similar comment on -02 already. Anyway, we seem to b= e in agreement. > > > > 26. Section 5.2: > > "A proxy that receives a request with the "histinfo" option=20 > tag in the > > =A0 Supported header, SHOULD forward captured History-Info in=20 > subsequent, > > =A0 provisional , and final responses " > > Does this include 100 responses? > [MB] That's the implication of "provisional" per RFC 3261. [/MB] [JRE] I am doubtful about the usefulness of 100. However, it is probably fa= irly academic, since 100 will probably have been sent earlier. A proxy is u= nlikely to send a 100 after receiving a provisional response from a downstr= eam entity. > > > > 27. Section 5.2: > > "A proxy MAY anonymize any hi-entry whose domain corresponds to a > > =A0 domain for which it is responsible (as per [RFC3323 ])." > > I don't think RFC 3323 tells me how to anonymize an hi-entry. > [MB] RFC 3323 discusses anonymization and the role of an anonymizer, > etc. So, I'm not clear on your concern. [/MB] [JRE] I guess if we talked about anonymizing the URI in the hi-target-to-ur= i it would be clearer. John= From mary.ietf.barnes@gmail.com Tue Nov 2 12:25:05 2010 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 DCED53A69D8 for ; Tue, 2 Nov 2010 12:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 IAwqqHeHh9DF for ; Tue, 2 Nov 2010 12:25:01 -0700 (PDT) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 852323A69C7 for ; Tue, 2 Nov 2010 12:25:00 -0700 (PDT) Received: by gxk7 with SMTP id 7so4758286gxk.31 for ; Tue, 02 Nov 2010 12:25:05 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=YlEYQlR8nRRFKGkEdCGLFw9ATJUZhX9RN9NrrwRPDTI=; b=G7KeRv3N9BbFoG4t9lREZ+taf+F/YNWzhW1qai56QkozsaLJ3awhHqc80b/Wx3sIT4 Q9PGyrMqN0Pf/xAHNLv6zhOuS6iUDABbePsIwI+TWAu2gn/oYeXl/MQkE+TNJNRkS/8w /v6B0jQSM9uI38DXhRD6RzrUi07M6RUpTmZKs= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=SpIepLPLKSo4+x3Fi8coXOALhkfeccl2IXOKLpxwSXwk+kRo+N5DGD12zRPEf5mKpU cNqCisTslWp/IkDiHOZRdtGdwZIKTUv7RyG6NR6twYRAFQ0Z+Kdqh/LLGhJsQ+hGAAXd gdIbhYmylS+1BIQhAtzDZPDg+BLR7KUrbjGgA= MIME-Version: 1.0 Received: by 10.150.97.1 with SMTP id u1mr31444021ybb.2.1288725905129; Tue, 02 Nov 2010 12:25:05 -0700 (PDT) Received: by 10.236.28.41 with HTTP; Tue, 2 Nov 2010 12:25:05 -0700 (PDT) In-Reply-To: References: Date: Tue, 2 Nov 2010 14:25:05 -0500 Message-ID: From: Mary Barnes To: "Elwell, John" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sipcore@ietf.org" Subject: Re: [sipcore] 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: Tue, 02 Nov 2010 19:25:06 -0000 Hi John, Responses inline below [MB]. I will skip the ones that I replied to in the other response [MB]. Thanks, Mary. On Mon, Nov 1, 2010 at 5:13 PM, Elwell, John wrote: > Despite the effort that has gone into addressing comments raised by peopl= e on -01, I still find -02 hard to understand in places. I have not had tim= e to review the whole document, but here are some comments up to section 7.= Just as I finished writing this I saw Mary's response to my comments on -0= 1, which I will respond to tomorrow. Apologies for any overlap between the = two. > > > 1. As a general comment that I have made before, the document still talks= about 'header' in many places where it is not referring to the entire head= er for a SIP message, but only to a particular header field such as History= -Info. History-Info is only one field within the entire SIP header. See RFC= 3261 section 6 - definitions of header and header field. Although RFC 3261= is not 100% consistent, in general things like Contact, To, From etc. are = referred to as header fields, and hence History-Info should be too. Section= 4.3 of RFC 4485 also calls for attention to be given to the correct use of= terms header, header field and header field parameter, although it fails t= o say what the correct use is and one has to rely on RFC 3261. [MB] I replied to this in the other email. But, yes, this doc does use Header to mean Header field, but that's done in many other documents. However, I can change all of those to say "header field" if it makes a difference in understanding the document. [This might be something to put on the RFC editor list if folks are insisting that we always use "Header field"] The term header field parameter AFAIK is only used to refer to the two new header field parameters defined in this document. [/MB]. > > Also there are some instances of "header parameter field", which is not a= normal term - it should be "header field parameter". [MB] That's a typo. [/MB] > > 2. There is some confusion concerning Reason - sometimes it is referred t= o as a parameter (e.g., 7.1 3rd bullet, 7.1 last paragraph), sometimes as r= eason 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] > > 3. The word "entry" is used inconsistently. Mostly it occurs in "hi-entry= ", which is fine. But we also have "targeted-to-URI entry", "entry" (alone)= , History-Info entry (which is probably fine, as long as we say what it is)= , "header entry". Also "hi-entries". [MB] Which term do you prefer? I will change all the entry(s) to hi-entry. The targeted-to-URI entry possibly should be hi-targeted-to-uri. [/MB] > > 4. As another general comment, there are too many normative statements us= ing the passive voice, and therefore hard to understand. To quote one examp= le 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 > =A0 Reason MUST be associated with the hi-targeted-to-uri." > Is this saying that an entity that inserts History-Info MUST include in h= i-targeted-uri an escaped Reason header field? Or is this saying that a rec= ipient 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, rath= er 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] > > 5. Section 1: > "there is a need for a standard mechanism within > =A0 SIP for communicating the retargeting history of such a request" > What is meant by "such a request"? We have not previously mentioned "requ= est". The preceding text has talked about calls, not requests, but perhaps = it should talk about requests. [MB] I will change "such a request" to "call requests". [/MB] > > 6. Section 3: > "Current network applications provide the ability for elements > =A0 involved with the call to exchange =A0additional information relating= to > =A0 how and why the call was routed to a particular destination" > Change "exchange" to "obtain". I think that would fit better with the exa= mples that follow. [MB] Okay. [/MB] > > 7. Section 3: > "Capturing aliases and Globally Routable User Agent URIs (GRUUs) > =A0 =A0 =A0[RFC5627], which can be overwritten by a home proxy =A0upon re= ceipt" > The term "home proxy" is not used in RFC 3261. [MB] I will change to "proxy in the home domain" which is a term used in RFC 5627 (earlier versions of GRUU did use the term "home proxy")[/MB] > > 8. Section 4: > "The =A0following information is carried in the History-Info header as > =A0 detailed in Section 7.1:" > I think it would be better to say "For each target used for forwarding a = request, the =A0following information is carried in the History-Info header= as detailed in Section 7.1:" > This would make it clear that there can be more than one instance of this= information. [MB] Okay. [/MB] > > 9. Section 4; > "Target : A parameter indicating ..." > This overloads the word target. Perhaps a better generic term for these p= arameters would be "Derivation". [MB] I will just change to "Indicates.." which matches the form of the other bullets in that list. [/MB] > > 10. Section 4: > "A SIP entity changing the target of a > =A0 request in response to a redirect or REFER" > A REFER does not cause an entity to change the target of a request - it c= auses an entity to generate a new request. H-I will indeed be added, but th= at is covered by the statement above about creating a new request. [MB] Yep. [/MB] > > 11. "propagates any > =A0 History-Info header from the initial Request in the new request": > Contrary to what it says in the first half of the sentence, this does ind= eed acknowledge that we have a new request as a result of REFER. However, t= he statement is incorrect because there is no normative statement (e.g., in= section 5) concerning this special behaviour for REFER. There is merely a = requirement in Appendix A. [MB] I'll add text. [/MB] > > 12. Section 4: > "Note that an hi-entry is not included for the fork to > =A0 sip:bob@192.0.2.7 " > This is misleading, because there is indeed H-I sent to 192.0.2.7. I thin= k what it should say is that the H-I sent to 192.0.2.3 and subsequently sen= t back to Alice does not contain an entry for target 192.0.2.7. [MB] yep. [/MB] > > 12bis. Section 5.1: > "In addition, the UAC > =A0 SHOULD add =A0a History-Info header" > Why is this only a SHOULD, not a MUST? What would be the exceptions? [MB] This was issue #28 where Dale suggested it be change from a "MAY" to a "SHOULD" (with which you agreed in the email thread). But, I don't have a problem to change this to a MUST. [/MB] > > 13. Section 5.1: > "As a result, intermediaries and > =A0 the UAS at least know the original Request-URI, and if the Request- > =A0 URI was modified by a previous hop. " > This is inaccurate, since intermediaries may have removed H-I for privacy= or other reasons. Best to delete the sentence. [MB] Okay. HOwever, entries should not be removed for privacy - that was a change from RFC 4244 - they MUST be anonymized. [/MB] > > 14. Section 5.1: > "A UAC that wants to ensure =A0that privacy not > =A0 be applied to its identity MUST include a Privacy header with a priv- > =A0 value of "none"." > I am not sure that 'none' ensures anything - it is only a request accordi= ng to RFC 3323. [MB] Then I'll change it from "ensure" to "request". [/MB] > > 15. Section 5.1: > "A new hi-entry =A0MUST then be added for the URI from > =A0 the Contact header (which becomes the new Request-URI) " > The Contact header field could contain >1 URIs. I think what we want to s= ay is that the UAC MUST populate the new-hi-entry with the URI chosen as th= e Request-URI for the new request. [MB] Yes. [/MB] > > 16. Section 5.1: > "If the Contact header contained any of > =A0 the header parameter fields defined in this specification" > Don't understand. The parameters defined in this specification are parame= ters of the History-Info header field, so would not appear in a Contact hea= der field. Admittedly there is some mention in 7.3.4 of using the parameter= s in a Contact header field, but there is nothing that specifies the extend= ed syntax of the Contact header field. [MB] The header field parameters are defined for the Contact header (and History-Info) in the IANA section. It is introduced in 7.1 and the usage thereof described in 7.3.4. [/MB] > > 17. Section 5.1: > "MUST include the header parameter field =A0as a header parameter field > =A0 associated with the current hi-entry as described in Section 7.3.4." > Is "current hi-entry" the "new hi-entry" from a couple of sentences earli= er? [MB] Yes. Do you have a terminology preference? [/MB] > > 18. Section 5.2.1: > "The last hi-entry reflects the most recent > =A0 target and MUST contain the Request-URI for the received request," > If I interpret this correctly, this is talking about what the UAS receive= s. What the UAS receives is outside the control of the UAS, so we can't use= RFC 2119 language. Should be "will". [MB] Yep. [/MB] > > 19. Section 5.2.1: > "e.g., the last proxy does > =A0 not support History-Info" > In the previous sentence we used the term "previous entity", so it would = be better to stick to that term rather than "last proxy". [MB] Okay. [/MB] > > 20. Section 5.2.1: > "hi-index attribute" > and > "hi-target attribute" > Up till now we have called these parameters rather than attributes [MB] I'll change to parameter [/MB]. > > 21. Section 5.2.1: > "The > =A0 addition of the missing hi-entry ensures that the most complete > =A0 information can be provided in the response ..." > Not sure that it is "most complete" - "more complete" would be better, si= nce there could still be some missing entries from upstream. [MB] Most complete as "possible" - but I can change to "more". [/MB] > > 22. Section 5.2.1: > "Prior to any application usage of the information, the validity MUST > =A0 be ascertained" > What MUST ascertain the validity - the UAS or the application? Use active= voice. How does it do this? Is this testable? I don't believe we can use R= FC2119 language here. [MB] That is saying that the UAS MUST check that the entries that it is aware of contain the information that might be needed by an application (i.e., the last entry, target header field parameters, etc.). It's testable from a software implementation perspective - not a protocol perspective. I can change the MUST to a lower case recommended .. ie., it is recommended that the UAS...Note, that this was one of the SHOULDS (from RFC 4244) that folks wanted to change to MUST. [/MB] > > 23. Section 5.2.2: > "If the "histinfo" option tag is received in a request, the UAS MUST > =A0 include any History-Info received in the request in the subsequent > =A0 response" > This is incorrect for a B2BUA - a B2BUA should be allowed to use informat= ion received from its other interface. Also it is not necessarily correct f= or a regular UAS, since I would have thought a UAS should be required to in= clude the hi-entry inserted in accordance with 5.2.1, rather than using jus= t the H-I received. [MB] We can reword something like the following to capture your concern: If the "histinfo" option tag is received in a request, the UAS MUST include any History-Info received in the request and any hi-entries added by the UAS in the subsequent response. In addition, in the case of a B2BUA, the UAS MAY include any hi-entries received by the UAC in a response in the subsequent response sent by the UAS. [/MB] > > 24. Section 5.2.2: > "The processing of History-Info in responses follows the methodology > =A0 described in Section 16.7 of [RFC3261], " > We can't refer to 16.7 of RFC 3261, because that is for proxies, not UASs= . [MB] See reply in other email response [/MB] > > 25. Section 5.3: > "the redirect server MUST add the appropriate target header > =A0 field parameter to each Contact header as described in Section 7.3.4.= " > I don't think 7.3.4 tells me how to do this. Section 7.3.4 does mention t= he Contact header field, but only in the context of adding these parameters= to the History-Info header field (if I understand correctly). [MB] 7.3.4 tells you which one to add based upon the mechanism by which the targets are determined. The header field parameter is added based upon the same criteria. [/MB] > > 26. Section 6: > "A Reason MAY be associated with the hi-targeted-to-uri that has been > =A0 retargeted as shown in the example in Appendix B.1." > It would be good to be more precise, since B.1 is long - refer to A6, per= haps. [MB] Okay. [/MB] > > 27. Section 6.1.1: > "The proxy MUST include an hi-index attribute > =A0 =A0 =A0with a value of "1"" > It says we are inserting an entry, not replacing any existing entries. Va= lue "1" will not apply if there is an existing entry. [MB] Correct. If the prior hop did not include an hi-entry, then one is added. Even if there are already other hi-entries, there is no way to know how many hops might have been missed and thus, the indexing needs to be reset to 1 to reflect such. [/MB] > > 28. Section 6.1.1: > "The proxy MUST add a separate hi-entry in each > =A0 =A0 =A0separate outgoing request for each of the current (outgoing) > =A0 =A0 =A0targets in the target set." > Ambiguous - there should be only one entry per request - not one per targ= et in each request. > Perhaps it should say "For each outgoing request relating to a target in = the target set, the proxy MUST add a single hi-entry identifying that targe= t. For this new hi-entry, the proxy MUST..." [MB] Yes - your suggestion is more clear. [/MB] > > 29. Section 6.1.2: > "When re-sending a request as " > I don't think this is really resending - we are retargeting, and therefor= e changing some aspects of the original request. [MB] I'll change to "sending the retargeted request" [/MB] > > 30. Section 6.1.2: > "in the order indicated by the indexing (see > =A0 =A0 =A0Section 7.3.3)" > We really need a more precise reference - where in 7.3.3 does it tell me = how to use the aggregated information? [MB] 7.3.3. refers to RFC 3261 Step 7 "Aggregate Authentication Header Field Values", which states: "the proxy MUST collect any WWW- Authenticate and Proxy-Authenticate header field values from all other 401 (Unauthorized) and 407 (Proxy Authentication Required) responses received so far in this response context and add them to this response without modification before forwarding. " It's actually easier to just reword that to match what is done for History-Info header field something like the following: The SIP entity MUST collect any History-Info header field values from all other responses received so far in this response context and add them to this response without modification before forwarding. [/MB] > > 31. Section 6.1.2: > "If the received error response did not include > =A0 =A0 =A0any History-Info header fields, the proxy MUST use the same > =A0 =A0 =A0History-Info header fields that were sent in the outgoing requ= est > =A0 =A0 =A0that failed to build the outgoing request." > First, the two instances of "outgoing request" are confusing - I think th= e second should be "new outgoing request" or "retargeted request". [MB] I'll change to "new outgoing request" since the other request could also have been retargeted. > Second, what if some responses include aggregated information and others = don't? [MB] That shouldn't matter. The receiving entity will use what it can. If the normative procedures are followed, it's fairly deterministic as to when the aggregated information should be used. [/MB] > > 32. Section 6.1.2: > "Same as per Step 2 above for the normal forwarding case > =A0 =A0 =A0Section 6.1.1." > This is confusing, because 6.1.1 is not on "normal forwarding case" but o= n "initial requests". [MB] Section 6.1.2. use of "initial" is referring to both the case of the "initial" hi-entry to be added (bullet 1) AND the case whereby a Proxy received a request and it is adding the "initial" hi-entry for the first ("initial") retargeting. The "normal" forwarding is specifically bullet #3. I think it would be clearer if we just removed the word "initial" from the title and first paragraph and add an explicit reference to bullet 3. [/MB] > > 33. Section 6.1.3: > "When re-sending a request as " > Again I don't think "re-sending" is the correct term. [MB] I'll change to the "generating new requests" [/MB] > > 34. Section 6.1.3: > " =A0 Step 1: =A0Including Previous Entries > =A0 =A0 =A0The proxy MUST include the History-Info header fields that wer= e > =A0 =A0 =A0sent in the outgoing request that is being redirected." > This seems to be a significant difference from the 4xx/5xx/6xx case. In t= hat case we include any hi-entries from downstream entities that have sent = back the 4xx/5xx/6xx - why not in the 3xx case too? [MB] See response to issue 25 in your previous set of comments. [/MB] > > 35. Section 6.1.3: > "add a Reason header this > =A0 =A0 =A0entry" > Change "this" to "to this". > > 36. "MUST forward captured History-Info in subsequent, > =A0 provisional, and final responses to the request sent by the ultimate > =A0 UAS (see Section 5.2)" > If a response does not contain any captured H-I (because the UAS doesn't = support it), is there any requirement on the proxy to generate it from its = own information? [MB] A proxy would have added an hi-entry for the UAS if it follows the normative procedures in this document. But, there is no way for the proxy to generate any additional hi-entries (in cases where the UAS internally retargets or B2BUA case). [/MB] > > 37. Section 7.1: > "Reason: An optional parameter for History-Info," > It is not in the ABNF as a parameter of History-Info - in fact it is an e= scaped header field. [MB] Correct - this is a summary of information associated with each hi-entry and it is described in as being escaped. Logically, the information is there. Certainly, it's clear that it's not defined specifically in the ABNF for the header. [/MB] > > 38. Section 7.1: > "he hi-target is added for a hi-entry when it is > =A0 =A0 =A0first added in a History-Info header field, and only one value= is > =A0 =A0 =A0permitted" > I believe it should say "only one parameter is permitted". True that para= meter ('rc' or 'mp') can have only one value, but I don't think that is the= point we are trying to make. [MB] Correct. [/MB] > > 39. Section 7.3.2: > "If the response contains a Reason header for a protocol > =A0 that is not SIP (e.g., Q.850), it MUST be captured as an additional > =A0 Reason associated with the hi-targeted-to-uri that has been > =A0 retargeted, along with the SIP Response Code" > I think this is saying that the entity MUST include two Reason parameters= in the hi-entry. Perhaps we should state that more explicitly. Also, does = order matter? [MB] I can add (i.e., there will be two reason headers), but I figured when you add "an additional" to one, that it's obvious that there are two headers. Per RFC , order does not matter. [/MB] > > 40. Section 7.3.3 item 6: > "When a response is built and it represents the aggregate of > =A0 =A0 =A0 responses to multiple forks " > Suddenly we are talking about forks when previously we were talking about= branches. [MB] A branch reflects a fork. I'll clarify the text in item 6, such that it reads: "the index MUST be captured for each forked request, creating a new branch, per the rules above= ..." and change the use of forks to branch in the body of item 6. [/MB] > > 41. Section 7.1.3, item 6: > "For example, if > =A0 =A0 =A0 a procesing entity received failure responses for forks 1.1.1= and > =A0 =A0 =A0 1.1.2, it would return both the 1.1.1 and 1.1.2 entries to th= e > =A0 =A0 =A0 entity that generated the hi-entry with index of 1." > I can't figure this out - shouldn't "index of 1" be "index of 1.1"? [MB] No. The processing entity in that sentence has the index of 1.1. The processing entity is the subject of that sentence and "it" returns the response to the entity that would have added the hi-entry with index of 1.[/MB] > > 42. Section 7.1.3, item 6: > "See > =A0 =A0 =A0 Appendix B.1 for an example" > It is unclear where exactly in B.1 I am supposed to look - searching for = '1.1.1' or '1.1.2' produces no results. Please cite the specific messages. [MB] Okay. [/MB] > > Although I didn't review beyond section 7, I happened to notice the follo= wing in Appendix B: > "B. =A0An entity (UA or proxy) retargeting in response to a redirect > =A0 =A0 =A0 =A0 =A0 or REFER MUST include any Request History information= from > =A0 =A0 =A0 =A0 =A0 the redirect/REFER in the new request." > It is unclear how you can retarget in response to a REFER. A REFER reques= ts leads to the generation of a new request - there is no retargeting. [MB] I'll reword that to reflect that the REFER includes the History-Information from previous retargets. [/MB] > > John > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From mary.ietf.barnes@gmail.com Tue Nov 2 12:50:43 2010 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 4D19B28C0F0 for ; Tue, 2 Nov 2010 12:50:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 qFZItHs4pajf for ; Tue, 2 Nov 2010 12:50:42 -0700 (PDT) Received: from mail-vw0-f44.google.com (mail-vw0-f44.google.com [209.85.212.44]) by core3.amsl.com (Postfix) with ESMTP id 40C943A6A03 for ; Tue, 2 Nov 2010 12:50:42 -0700 (PDT) Received: by vws3 with SMTP id 3so77789vws.31 for ; Tue, 02 Nov 2010 12:50:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=EgopPEhLUSNtDwSoIn12HHNccC5FVsixkSCI+ZFdmYU=; b=ikKr9uEGABJNE15kVJXErmsi8Qzw/9t2gqT0yfFC0dE7EfOimavQRKqA3PyC4nvTiW yIbD2OyDKRboUfiKPBwCsXjqtLdcHNToncgXR0R/Fgnlt25x0Gm9d+F5Q8HysmK2H+Fd Pd5LRM9n+TwwVdvX0R0BTWX70ANVX6gI9t71Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=GPAJ9ItAXFySoFeNSUIx7kPbiDFR3fpSYI29Qp4u3wPyIIP2PcA7LpiwUNj4B2oA0u P7bXLot2GambZGTjqDlYLgDgVUeIo+yuGknJPKyGmEcM6r5vbSN41PrngK1maEc/DOl9 JyXJWOhwnsj+gFHCkKqZcgbAEMVPdg4aCwtJ0= MIME-Version: 1.0 Received: by 10.224.205.200 with SMTP id fr8mr7250733qab.198.1288727446845; Tue, 02 Nov 2010 12:50:46 -0700 (PDT) Received: by 10.236.28.41 with HTTP; Tue, 2 Nov 2010 12:50:46 -0700 (PDT) In-Reply-To: References: <4C69ADA8.1010802@nostrum.com> <4C753AAA.3030407@nostrum.com> Date: Tue, 2 Nov 2010 14:50:46 -0500 Message-ID: From: Mary Barnes To: "Elwell, John" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sipcore@ietf.org" Subject: Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis 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: Tue, 02 Nov 2010 19:50:43 -0000 John, I've done the same. A couple responses inline below [MB2]. Thanks, Mary. On Tue, Nov 2, 2010 at 4:06 AM, Elwell, John wrote: > Mary, > > I have responded below, stripping out the stuff where I have nothing furt= her to add. > >> > 2. It nearly always uses the term "header" rather than >> "header field", although never, as far as I know, meaning the >> entire SIP header. >> [MB] I'm not sure that I fully understand the concern. Can you point >> out a specific sentence or section of concern? =A0The term "header" is >> used when it is referring to the History-Info header field, but that >> is done in other documents as well. =A0In general, I think it's >> understood that it's referring to the header field when it's >> qualified. Perhaps you're referring to places where it is not >> qualified? =A0 The term hi-entry is used, as well. >> [/MB] > [JRE] I have explained in more detail in my comments on -02. [MB2] I've responded to that in my subsequent response to your comments. [/= MB2] > > >> > >> > 18. Section 4.2.2: >> > "the UAS MUST >> > =A0 include any History-Info received in the request =A0in the >> subsequent >> > =A0 response" >> > Does this include 100 responses? >> [MB] I would think so. Can you think of a reason why it shouldn't? =A0I>= > would think it could be useful for debug. [/MB] > [JRE] The 100 response typically only travels back a single hop, so the b= enefit of H-I in a 100 is marginal. Also some implementations might send ba= ck a 100 response quite early during processing, perhaps even before they d= ecide whether to act as a proxy, a UAS or a redirect, so knowing how to pop= ulate H-I in a 100 might be difficult. [MB2] If it has no additional hi-entries, then there is nothing additional to send back, so I don't think it hurts anything - I would agree that in most cases it's of marginal value. We can include it as an exception in that sentence if you would prefer, although per the next comment, it seems that you are okay with leaving it as is. [/MB2] > > >> > >> > >> > 26. Section 5.2: >> > "A proxy that receives a request with the "histinfo" option >> tag in the >> > =A0 Supported header, SHOULD forward captured History-Info in >> subsequent, >> > =A0 provisional , and final responses " >> > Does this include 100 responses? >> [MB] That's the implication of "provisional" per RFC 3261. [/MB] > [JRE] I am doubtful about the usefulness of 100. However, it is probably = fairly academic, since 100 will probably have been sent earlier. A proxy is= unlikely to send a 100 after receiving a provisional response from a downs= tream entity. > >> > >> > 27. Section 5.2: >> > "A proxy MAY anonymize any hi-entry whose domain corresponds to a >> > =A0 domain for which it is responsible (as per [RFC3323 ])." >> > I don't think RFC 3323 tells me how to anonymize an hi-entry. >> [MB] =A0RFC 3323 discusses anonymization and the role of an anonymizer, >> etc. So, I'm not clear on your concern. [/MB] > [JRE] I guess if we talked about anonymizing the URI in the hi-target-to-= uri it would be clearer. [MB2] That's fine...I'll make it explicit that it's the hi-targeted-to-uri in the hi-entry that is anonymized. [/MB2] > > > > > John From john.elwell@siemens-enterprise.com Tue Nov 2 13:31:25 2010 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 597E328C0E0 for ; Tue, 2 Nov 2010 13:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.334 X-Spam-Level: X-Spam-Status: No, score=-102.334 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, 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 EjBcMpEJe06U for ; Tue, 2 Nov 2010 13:31:24 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 9625728C0F0 for ; Tue, 2 Nov 2010 13:31:23 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2146463; Tue, 2 Nov 2010 21:31:12 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 2D6B923F02AE; Tue, 2 Nov 2010 21:31:12 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 2 Nov 2010 21:31:12 +0100 From: "Elwell, John" To: Mary Barnes Date: Tue, 2 Nov 2010 21:31:10 +0100 Thread-Topic: [sipcore] H-I in 100 response (was REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis) Thread-Index: Act6x0KULvNi0/A9RYe7/9WE2pK6pgABNV6Q Message-ID: References: <4C69ADA8.1010802@nostrum.com> <4C753AAA.3030407@nostrum.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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] H-I in 100 response (was REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis) 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: Tue, 02 Nov 2010 20:31:25 -0000 So the remaining issue from this thread concerns whether to mandate History= -Info in a all provisional responses or just non-100 provisional responses = (subject to presence of the option tag in the request). Given that 100 tend= s to be generated differently from other provisional responses, and given t= he marginal use of H-I in 100 responses, I would prefer either to omit H-I = from 100 responses or use MAY. I don't have a strong opinion, but perhaps o= thers have a view. John > -----Original Message----- > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 > Sent: 02 November 2010 19:51 > To: Elwell, John > Cc: sipcore@ietf.org > Subject: Re: [sipcore] REMINDER: Re: WGLC:=20 > draft-ietf-sipcore-rfc4244bis >=20 > John, >=20 > I've done the same. A couple responses inline below [MB2]. >=20 > Thanks, > Mary. >=20 > On Tue, Nov 2, 2010 at 4:06 AM, Elwell, John > wrote: > > Mary, > > > > I have responded below, stripping out the stuff where I=20 > have nothing further to add. > > > > >> > 2. It nearly always uses the term "header" rather than > >> "header field", although never, as far as I know, meaning the > >> entire SIP header. > >> [MB] I'm not sure that I fully understand the concern. Can=20 > you point > >> out a specific sentence or section of concern? =A0The term=20 > "header" is > >> used when it is referring to the History-Info header=20 > field, but that > >> is done in other documents as well. =A0In general, I think it's > >> understood that it's referring to the header field when it's > >> qualified. Perhaps you're referring to places where it is not > >> qualified? =A0 The term hi-entry is used, as well. > >> [/MB] > > [JRE] I have explained in more detail in my comments on -02. > [MB2] I've responded to that in my subsequent response to=20 > your comments. [/MB2] > > > > >=20 > >> > > >> > 18. Section 4.2.2: > >> > "the UAS MUST > >> > =A0 include any History-Info received in the request =A0in the > >> subsequent > >> > =A0 response" > >> > Does this include 100 responses? > >> [MB] I would think so. Can you think of a reason why it=20 > shouldn't? =A0I>> would think it could be useful for debug. [/MB] > > [JRE] The 100 response typically only travels back a single=20 > hop, so the benefit of H-I in a 100 is marginal. Also some=20 > implementations might send back a 100 response quite early=20 > during processing, perhaps even before they decide whether to=20 > act as a proxy, a UAS or a redirect, so knowing how to=20 > populate H-I in a 100 might be difficult. > [MB2] If it has no additional hi-entries, then there is nothing > additional to send back, so I don't think it hurts anything - I would > agree that in most cases it's of marginal value. We can include it as > an exception in that sentence if you would prefer, although per the > next comment, it seems that you are okay with leaving it as is. > [/MB2] > > > > > >> > >=20 > >> > > >> > 26. Section 5.2: > >> > "A proxy that receives a request with the "histinfo" option > >> tag in the > >> > =A0 Supported header, SHOULD forward captured History-Info in > >> subsequent, > >> > =A0 provisional , and final responses " > >> > Does this include 100 responses? > >> [MB] That's the implication of "provisional" per RFC 3261. [/MB] > > [JRE] I am doubtful about the usefulness of 100. However,=20 > it is probably fairly academic, since 100 will probably have=20 > been sent earlier. A proxy is unlikely to send a 100 after=20 > receiving a provisional response from a downstream entity. > > > >> > > >> > 27. Section 5.2: > >> > "A proxy MAY anonymize any hi-entry whose domain corresponds to a > >> > =A0 domain for which it is responsible (as per [RFC3323 ])." > >> > I don't think RFC 3323 tells me how to anonymize an hi-entry. > >> [MB] =A0RFC 3323 discusses anonymization and the role of an=20 > anonymizer, > >> etc. So, I'm not clear on your concern. [/MB] > > [JRE] I guess if we talked about anonymizing the URI in the=20 > hi-target-to-uri it would be clearer. > [MB2] That's fine...I'll make it explicit that it's the > hi-targeted-to-uri in the hi-entry that is anonymized. [/MB2] > > > > > > > > > > John > = From pkyzivat@cisco.com Tue Nov 2 15:19:35 2010 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 9341F3A69F0 for ; Tue, 2 Nov 2010 15:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.437 X-Spam-Level: X-Spam-Status: No, score=-110.437 tagged_above=-999 required=5 tests=[AWL=0.163, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 O6UfyUdja0aR for ; Tue, 2 Nov 2010 15:19:34 -0700 (PDT) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 026963A68C2 for ; Tue, 2 Nov 2010 15:19:33 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPYq0ExAZnwN/2dsb2JhbAChXHGiW5wOhUUEilWDCIJs X-IronPort-AV: E=Sophos;i="4.58,285,1286150400"; d="scan'208";a="177694561" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 02 Nov 2010 22:19:39 +0000 Received: from [161.44.174.118] (dhcp-161-44-174-118.cisco.com [161.44.174.118]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oA2MJc7C017610 for ; Tue, 2 Nov 2010 22:19:38 GMT Message-ID: <4CD08E7A.1020503@cisco.com> Date: Tue, 02 Nov 2010 18:19:38 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: sipcore@ietf.org References: <4C69ADA8.1010802@nostrum.com> <4C753AAA.3030407@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] H-I in 100 response (was REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis) 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: Tue, 02 Nov 2010 22:19:35 -0000 On 11/2/2010 4:31 PM, Elwell, John wrote: > So the remaining issue from this thread concerns whether to mandate History-Info in a all provisional responses or just non-100 provisional responses (subject to presence of the option tag in the request). Given that 100 tends to be generated differently from other provisional responses, and given the marginal use of H-I in 100 responses, I would prefer either to omit H-I from 100 responses or use MAY. I don't have a strong opinion, but perhaps others have a view. Requiring (even permitting) H-I in 100 responses is a *terrible* idea. I don't see why you would need H-I in *any* provisional responses (with the possible exception of 199.) (Disclaimer - I have not read all the discussion on this subject.) Thanks, Paul > John > > >> -----Original Message----- >> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] >> Sent: 02 November 2010 19:51 >> To: Elwell, John >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] REMINDER: Re: WGLC: >> draft-ietf-sipcore-rfc4244bis >> >> John, >> >> I've done the same. A couple responses inline below [MB2]. >> >> Thanks, >> Mary. >> >> On Tue, Nov 2, 2010 at 4:06 AM, Elwell, John >> wrote: >>> Mary, >>> >>> I have responded below, stripping out the stuff where I >> have nothing further to add. >>> >> >>>>> 2. It nearly always uses the term "header" rather than >>>> "header field", although never, as far as I know, meaning the >>>> entire SIP header. >>>> [MB] I'm not sure that I fully understand the concern. Can >> you point >>>> out a specific sentence or section of concern? The term >> "header" is >>>> used when it is referring to the History-Info header >> field, but that >>>> is done in other documents as well. In general, I think it's >>>> understood that it's referring to the header field when it's >>>> qualified. Perhaps you're referring to places where it is not >>>> qualified? The term hi-entry is used, as well. >>>> [/MB] >>> [JRE] I have explained in more detail in my comments on -02. >> [MB2] I've responded to that in my subsequent response to >> your comments. [/MB2] >>> >>> >> >>>>> >>>>> 18. Section 4.2.2: >>>>> "the UAS MUST >>>>> include any History-Info received in the request in the >>>> subsequent >>>>> response" >>>>> Does this include 100 responses? >>>> [MB] I would think so. Can you think of a reason why it >> shouldn't? I>> would think it could be useful for debug. [/MB] >>> [JRE] The 100 response typically only travels back a single >> hop, so the benefit of H-I in a 100 is marginal. Also some >> implementations might send back a 100 response quite early >> during processing, perhaps even before they decide whether to >> act as a proxy, a UAS or a redirect, so knowing how to >> populate H-I in a 100 might be difficult. >> [MB2] If it has no additional hi-entries, then there is nothing >> additional to send back, so I don't think it hurts anything - I would >> agree that in most cases it's of marginal value. We can include it as >> an exception in that sentence if you would prefer, although per the >> next comment, it seems that you are okay with leaving it as is. >> [/MB2] >>> >>> >>>>> >> >>>>> >>>>> 26. Section 5.2: >>>>> "A proxy that receives a request with the "histinfo" option >>>> tag in the >>>>> Supported header, SHOULD forward captured History-Info in >>>> subsequent, >>>>> provisional , and final responses " >>>>> Does this include 100 responses? >>>> [MB] That's the implication of "provisional" per RFC 3261. [/MB] >>> [JRE] I am doubtful about the usefulness of 100. However, >> it is probably fairly academic, since 100 will probably have >> been sent earlier. A proxy is unlikely to send a 100 after >> receiving a provisional response from a downstream entity. >>> >>>>> >>>>> 27. Section 5.2: >>>>> "A proxy MAY anonymize any hi-entry whose domain corresponds to a >>>>> domain for which it is responsible (as per [RFC3323 ])." >>>>> I don't think RFC 3323 tells me how to anonymize an hi-entry. >>>> [MB] RFC 3323 discusses anonymization and the role of an >> anonymizer, >>>> etc. So, I'm not clear on your concern. [/MB] >>> [JRE] I guess if we talked about anonymizing the URI in the >> hi-target-to-uri it would be clearer. >> [MB2] That's fine...I'll make it explicit that it's the >> hi-targeted-to-uri in the hi-entry that is anonymized. [/MB2] >>> >>> >>> >>> >>> John >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From john.elwell@siemens-enterprise.com Wed Nov 3 02:16:10 2010 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 3C0453A6A1C for ; Wed, 3 Nov 2010 02:16:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.369 X-Spam-Level: X-Spam-Status: No, score=-102.369 tagged_above=-999 required=5 tests=[AWL=0.230, BAYES_00=-2.599, 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 orD2TkMKnP7p for ; Wed, 3 Nov 2010 02:16:07 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 961883A68A4 for ; Wed, 3 Nov 2010 02:16:06 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2150700; Wed, 3 Nov 2010 10:15:35 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id BF5EA23F028E; Wed, 3 Nov 2010 10:15:35 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 3 Nov 2010 10:15:35 +0100 From: "Elwell, John" To: Mary Barnes Date: Wed, 3 Nov 2010 10:15:34 +0100 Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02 Thread-Index: Act6w6iodKPigID0ST6cQcA76aKkfwAZ2OCw Message-ID: References: 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] 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: Wed, 03 Nov 2010 09:16:10 -0000 > -----Original Message----- > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > Sent: 02 November 2010 19:25 > To: Elwell, John > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02 > > Hi John, > > Responses inline below [MB]. I will skip the ones that I replied to > in the other response [MB]. > > Thanks, > Mary. > > On Mon, Nov 1, 2010 at 5:13 PM, Elwell, John > wrote: > > Despite the effort that has gone into addressing comments > raised by people on -01, I still find -02 hard to understand > in places. I have not had time to review the whole document, > but here are some comments up to section 7. Just as I > finished writing this I saw Mary's response to my comments on > -01, which I will respond to tomorrow. Apologies for any > overlap between the two. > > > > > > 1. As a general comment that I have made before, the > document still talks about 'header' in many places where it > is not referring to the entire header for a SIP message, but > only to a particular header field such as History-Info. > History-Info is only one field within the entire SIP header. > See RFC 3261 section 6 - definitions of header and header > field. Although RFC 3261 is not 100% consistent, in general > things like Contact, To, From etc. are referred to as header > fields, and hence History-Info should be too. Section 4.3 of > RFC 4485 also calls for attention to be given to the correct > use of terms header, header field and header field parameter, > although it fails to say what the correct use is and one has > to rely on RFC 3261. > [MB] I replied to this in the other email. But, yes, this doc does use > Header to mean Header field, but that's done in many other documents. > However, I can change all of those to say "header field" if it makes a > difference in understanding the document. [This might be something to > put on the RFC editor list if folks are insisting that we always use > "Header field"] The term header field parameter AFAIK is only used to > refer to the two new header field parameters defined in this document. > [/MB]. [JRE] Yes, I know some other documents have got it wrong. As editor, I gues= s the decision can rest with you (or defer to RFC-Editor) - I was just poin= ting out the discrepancy. > > > > Also there are some instances of "header parameter field", > which is not a normal term - it should be "header field parameter". > [MB] That's a typo. [/MB] > > > > 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] [JRE] I find it odd referring to it as a parameter of an hi-entry, yet it i= s not to be found in hi-param. I would suggest we change section 7.1 3rd bu= llet to say "Reason: Optional information in History-Info, capturing the re= ason for retargeting to a Targeted-to URI. It is reflected in the ....". Fu= rthermore, since we have this definition, in the rest of the document we sh= ould use "Reason", and not all the other variants. > > > > 3. The word "entry" is used inconsistently. Mostly it > occurs in "hi-entry", which is fine. But we also have > "targeted-to-URI entry", "entry" (alone), History-Info entry > (which is probably fine, as long as we say what it is), > "header entry". Also "hi-entries". > [MB] Which term do you prefer? I will change all the entry(s) to > hi-entry. The targeted-to-URI entry possibly should be > hi-targeted-to-uri. [/MB] [JRE] Sounds reasonable. > > > > > 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] [JRE] Right, so that fixes this particular instance of passive voice, since= it is no longer a normative statement. Use of the passive voice had concea= led the fact that we were incorrectly using normative language, which just = goes to prove my point that passive voice, at least in normative statements= , is bad. > > > > 7. Section 3: > > "Capturing aliases and Globally Routable User Agent URIs (GRUUs) > > [RFC5627], which can be overwritten by a home proxy > upon receipt" > > The term "home proxy" is not used in RFC 3261. > [MB] I will change to "proxy in the home domain" which is a term used > in RFC 5627 (earlier versions of GRUU did use the term "home > proxy")[/MB] [JRE] Good. > > > > 9. Section 4; > > "Target : A parameter indicating ..." > > This overloads the word target. Perhaps a better generic > term for these parameters would be "Derivation". > [MB] I will just change to "Indicates.." which matches the form of the > other bullets in that list. [/MB] [JRE] Sorry, I didn't express my concern very clearly. I was concerned that= "Target" is a confusing name for the collective term for rc and mp paramet= ers, since it overloads the word "target". I was suggesting we use "Derivat= ion" instead of "Target" (and hence hi-derivation instead of hi-target). Bu= t perhaps this is too much of a change at this stage. > > > > 16. Section 5.1: > > "If the Contact header contained any of > > the header parameter fields defined in this specification" > > Don't understand. The parameters defined in this > specification are parameters of the History-Info header > field, so would not appear in a Contact header field. > Admittedly there is some mention in 7.3.4 of using the > parameters in a Contact header field, but there is nothing > that specifies the extended syntax of the Contact header field. > [MB] The header field parameters are defined for the Contact header > (and History-Info) in the IANA section. It is introduced in 7.1 and > the usage thereof described in 7.3.4. [/MB] [JRE] Sorry, that is what comes of submitting comments before I have review= ed the whole document. However, the way things are scattered around in this= document makes it quite hard to find things, but it is probably too late t= o do much about that. > > > > 17. Section 5.1: > > "MUST include the header parameter field as a header > parameter field > > associated with the current hi-entry as described in > Section 7.3.4." > > Is "current hi-entry" the "new hi-entry" from a couple of > sentences earlier? > [MB] Yes. Do you have a terminology preference? [/MB] [JRE] I would use "new hi-entry". > > > > 22. Section 5.2.1: > > "Prior to any application usage of the information, the > validity MUST > > be ascertained" > > What MUST ascertain the validity - the UAS or the > application? Use active voice. How does it do this? Is this > testable? I don't believe we can use RFC2119 language here. > [MB] That is saying that the UAS MUST check that the entries that it > is aware of contain the information that might be needed by an > application (i.e., the last entry, target header field parameters, > etc.). It's testable from a software implementation perspective - not > a protocol perspective. I can change the MUST to a lower case > recommended .. ie., it is recommended that the UAS...Note, that this > was one of the SHOULDS (from RFC 4244) that folks wanted to change to > MUST. [/MB] [JRE] OK, I can live with MUST, but please use active voice. > > > > 25. Section 5.3: > > "the redirect server MUST add the appropriate target header > > field parameter to each Contact header as described in > Section 7.3.4." > > I don't think 7.3.4 tells me how to do this. Section 7.3.4 > does mention the Contact header field, but only in the > context of adding these parameters to the History-Info header > field (if I understand correctly). > [MB] 7.3.4 tells you which one to add based upon the mechanism by > which the targets are determined. The header field parameter is added > based upon the same criteria. [/MB] [JRE] So it should say "as described in Section 7.3.4 for adding to a Histo= ry-Info entry" or something similar. > > > > 27. Section 6.1.1: > > "The proxy MUST include an hi-index attribute > > with a value of "1"" > > It says we are inserting an entry, not replacing any > existing entries. Value "1" will not apply if there is an > existing entry. > [MB] Correct. If the prior hop did not include an hi-entry, then one > is added. Even if there are already other hi-entries, there is no way > to know how many hops might have been missed and thus, the indexing > needs to be reset to 1 to reflect such. [/MB] [JRE] So this means a downstream entity can receive two entries with index = "1" (possibly with intervening entries 1.1 etc.), not because of any incorr= ect behaviour of any of the nodes concerned, but merely because some interv= ening nodes don't support H-I. This was the first time I was aware of this.= We should add some explanation. Personally I would prefer to continue the = indexing rather than reset to "1". > > 36. "MUST forward captured History-Info in subsequent, > > provisional, and final responses to the request sent by > the ultimate > > UAS (see Section 5.2)" > > If a response does not contain any captured H-I (because > the UAS doesn't support it), is there any requirement on the > proxy to generate it from its own information? > [MB] A proxy would have added an hi-entry for the UAS if it follows > the normative procedures in this document. But, there is no way for > the proxy to generate any additional hi-entries (in cases where the > UAS internally retargets or B2BUA case). [/MB] [JRE] Understood. However, let me give you an example. A proxy receives a r= equest with entries 1 and 1.1, and forwards it thereby adding 1.1.1. Suppos= e the next entity is the UAS and the UAS supports H-I. The UAS will capture= 1, 1.1 and 1.1.1 in the returned response, so therefore the proxy forwards= 1, 1.1 and 1.1.1 when it forwards the response. That's fine. However, if t= he UAS does not support H-I, the response will contain no entries. In this = case, the proxy will be aware of entries 1, 1.1 and 1.2 and could add them = when forwarding the response. This assumes a certain amount of state be hel= d at the proxy, but no more than is required for forking, for example. Perhaps I have misinterpreted the word "captured" in the cited text - I had= assumed you meant captured in the received response, but of course it migh= t mean captured by the proxy from the time it forwarded the request. It cer= tainly needs some clarification. > > > > 37. Section 7.1: > > "Reason: An optional parameter for History-Info," > > It is not in the ABNF as a parameter of History-Info - in > fact it is an escaped header field. > [MB] Correct - this is a summary of information associated with each > hi-entry and it is described in as being escaped. Logically, the > information is there. Certainly, it's clear that it's not defined > specifically in the ABNF for the header. [/MB] [JRE] See my proposal above for rewording this. > > > > 39. Section 7.3.2: > > "If the response contains a Reason header for a protocol > > that is not SIP (e.g., Q.850), it MUST be captured as an > additional > > Reason associated with the hi-targeted-to-uri that has been > > retargeted, along with the SIP Response Code" > > I think this is saying that the entity MUST include two > Reason parameters in the hi-entry. Perhaps we should state > that more explicitly. Also, does order matter? > [MB] I can add (i.e., there will be two reason headers), but I figured > when you add "an additional" to one, that it's obvious that there are > two headers. Per RFC , order does not matter. [/MB] [JRE] I did interpret the wording correctly then, so perhaps the existing w= ording is OK. It just seemed a bit convoluted, somehow saying that the Reas= on conveying the SIP response code is somehow the main reason and the other= one is an additional Reason, when really they are just two Reasons. > > > > 41. Section 7.1.3, item 6: > > "For example, if > > a procesing entity received failure responses for > forks 1.1.1 and > > 1.1.2, it would return both the 1.1.1 and 1.1.2 entries to the > > entity that generated the hi-entry with index of 1." > > I can't figure this out - shouldn't "index of 1" be "index of 1.1"? > [MB] No. The processing entity in that sentence has the index of 1.1. > The processing entity is the subject of that sentence and "it" returns > the response to the entity that would have added the hi-entry with > index of 1.[/MB] [JRE] I still can't figure this out. A proxy receives a request with entrie= s 1 and 1.1. It creates two branches, 1.1.1 and 1.1.2. Both fail, so when t= he proxy sends a response back, it will include entries 1.1.1 and 1.1.2. Th= at response is sent to the entity that generated 1.1. > > > > Although I didn't review beyond section 7, I happened to > notice the following in Appendix B: > > "B. An entity (UA or proxy) retargeting in response to a redirect > > or REFER MUST include any Request History information from > > the redirect/REFER in the new request." > > It is unclear how you can retarget in response to a REFER. > A REFER requests leads to the generation of a new request - > there is no retargeting. > [MB] I'll reword that to reflect that the REFER includes the > History-Information from previous retargets. [/MB] [JRE] Well, clearly the REFER can contain H-I from previous retargets of th= e REFER request, but that has no bearing on the request generated as a resu= lt of the REFER. John From ian_elz@yahoo.co.uk Wed Nov 3 02:50:33 2010 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 914783A68A3 for ; Wed, 3 Nov 2010 02:50:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] 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 pzCLa8L1F0zU for ; Wed, 3 Nov 2010 02:50:32 -0700 (PDT) Received: from nm17.bullet.mail.ird.yahoo.com (nm17.bullet.mail.ird.yahoo.com [77.238.189.70]) by core3.amsl.com (Postfix) with SMTP id B61C43A68AB for ; Wed, 3 Nov 2010 02:50:28 -0700 (PDT) Received: from [77.238.189.53] by nm17.bullet.mail.ird.yahoo.com with NNFMP; 03 Nov 2010 09:50:34 -0000 Received: from [212.82.108.241] by tm6.bullet.mail.ird.yahoo.com with NNFMP; 03 Nov 2010 09:50:34 -0000 Received: from [127.0.0.1] by omp1006.mail.ird.yahoo.com with NNFMP; 03 Nov 2010 09:50:34 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 819874.21611.bm@omp1006.mail.ird.yahoo.com Received: (qmail 2492 invoked by uid 60001); 3 Nov 2010 09:50:34 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1288777834; bh=HPCntt3G1DvFt2PPqGvcAAkS2ezEh6fnsCCdRD/1/Zc=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=0CLV5aWN4mKgPvUHeobu4tM3LxpbGiriFZ8UIzpWNSOJce50KY+I7pKb3SMdu6w6by1nRlIg4WP9725NYRKcAsVilPQd8yfIdAaq3MCal/TjAWu54BjZ2JjqqGk+Cpd+DNVvLNmDIGNwsHsd9kG6tYPoysSxEFsiuMr3BB+bqU4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=LJTlCxnyey8EqujBvQkAVWY7NraUBZGR22oRJ5FHAZVgeNZ9qAde7zmYV+Do4RJtkLc1ly1ZrzjhiW/AQusYhFmJfq020b6St19mFVE5S8ECxolJ9V5kp4+uEKvD7TcbK7gjCj0r7sGRw2UX2xhsZcdmVkvUAJhr0mOVN4uLsl8=; Message-ID: <595924.92151.qm@web29110.mail.ird.yahoo.com> X-YMail-OSG: inM6fu4VM1kBvUEVSMKyh9_gQQ3AkhT4XhvlCR2lZHJFEei oz7Mlpxcn55wHNLoIkzLXUTRJYv_8bRa7SCy8bNkicqx8kIVmLi3sCGhbrpH iwcVJSv0A1YzU6qH3cEKqjJ3w.FIrAST2Uw8F_2SxYAbaINVlijywC8mslp3 Gtx95iXrgK26i7EcJgShAHEH5hhHzASt1dKQ2vw-- Received: from [80.231.29.20] by web29110.mail.ird.yahoo.com via HTTP; Wed, 03 Nov 2010 09:50:34 GMT X-Mailer: YahooMailRC/504.5 YahooMailWebService/0.8.107.284920 References: Date: Wed, 3 Nov 2010 09:50:34 +0000 (GMT) From: Ian Elz To: sipcore@ietf.org, john.elwell@siemens-enterprise.com, mary.ietf.barnes@gmail.com, pkyzivat@cisco.com In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-1710153091-1288777834=:92151" Subject: Re: [sipcore] H-I in 100 response (was REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis) 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: Wed, 03 Nov 2010 09:50:33 -0000 --0-1710153091-1288777834=:92151 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable 02 November 2010 22:19:38 Paul Kyzivat wrote:=0A=0A>On 11/2/2010 4:31 PM, E= lwell, John wrote:=0A>> So the remaining issue from this thread concerns wh= ether to mandate =0A>>History-Info in a all provisional responses or just n= on-100 provisional =0A>>responses (subject to presence of the option tag in= the request). Given that 100 =0A>>tends to be generated differently from o= ther provisional responses, and given =0A>>the marginal use of H-I in 100 r= esponses, I would prefer either to omit H-I from =0A>>100 responses or use = MAY. I don't have a strong opinion, but perhaps others have =0A>>a view.=0A= =0A>Requiring (even permitting) H-I in 100 responses is a *terrible* idea.= =0A=0A>I don't see why you would need H-I in *any* provisional responses (w= ith =0Athe possible exception of 199.)=0A=0A(>Disclaimer - I have not read = all the discussion on this subject.)=0A=0A>=A0=A0=A0 Thanks,=0A>=A0=A0=A0 P= aul=0A=0A=0A=A0=0AI don't believe that you can stop H-I in all=A0prov= isional=A0responses. =0A=0AI don't think that H-I is useful in a 100 Trying= response but it adds =0Asignificant value to other 1xx responses. I believ= e that 3GPP have specified H-I =0Ain 181 Call is Being Forwarded responses = as part of the CDIV service.=0A=0ASubject to Privacy settings returning the= H-I in the 181 provides valuable =0Ainformation to the caller.=0A=0AIan El= z=0A=0A{I have been trying to follow all the threads relating to 4424bis bu= t no longer =0Abeing employed in telecoms means that I have limited time. I= was going to review =0Athe 4424bis draft but then as there were lots of ot= her commnets I have sat back =0Aand and lurked. Time to got back and hide a= gain.}=0A=0A=0A --0-1710153091-1288777834=:92151 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
02 November 2010 22:19:38 Paul Kyzivat wrote:
=0A
 =
=0A
>On 11/2/2010 4:31 PM, Elwell, John wrote:
>> So = the remaining issue from this thread concerns whether to mandate History-In= fo in a all provisional responses or just non-100 provisional responses (su= bject to presence of the option tag in the request). Given that 100 tends t= o be generated differently from other provisional responses, and given the = marginal use of H-I in 100 responses, I would prefer either to omit H-I fro= m 100 responses or use MAY. I don't have a strong opinion, but perhaps othe= rs have a view.

>Requiring (even permitting) H-I in 100 responses= is a *terrible* idea.

>I don't see why you would need H-I in *an= y* provisional responses (with
the possible exception of 199.)

(= >Disclaimer - I have not read all the discussion on this subject.)
>    Thanks,
>    Paul
= =0A
<snip>
 
=0A
I don't believe that you can st= op H-I in all provisional responses.
=0A
 
= =0A
I don't think that H-I is useful in a 100 Trying response but it ad= ds significant value to other 1xx responses. I believe that 3GPP have speci= fied H-I in 181 Call is Being Forwarded responses as part of the CDIV servi= ce.
=0A
 
=0A
Subject to Privacy settings returning = the H-I in the 181 provides valuable information to the caller.
=0A 
=0A
Ian Elz
=0A
 
=0A
{I have been= trying to follow all the threads relating to 4424bis but no longer being e= mployed in telecoms means that I have limited time. I was going to review t= he 4424bis draft but then as there were lots of other commnets I have sat b= ack and and lurked. Time to got back and hide again.}
=0A
 =0A
 
=0A

=0A
 

=0A=0A=0A = --0-1710153091-1288777834=:92151-- From keith.drage@alcatel-lucent.com Wed Nov 3 03:41:44 2010 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 8C1663A68A3 for ; Wed, 3 Nov 2010 03:41:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 1yDsHkUMueXT for ; Wed, 3 Nov 2010 03:41:41 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 993AF3A677D for ; Wed, 3 Nov 2010 03:41:39 -0700 (PDT) Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oA3AeVii002632 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 3 Nov 2010 11:41:43 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com ([135.120.45.61]) with mapi; Wed, 3 Nov 2010 11:41:42 +0100 From: "DRAGE, Keith (Keith)" To: Mary Barnes , "Elwell, John" Date: Wed, 3 Nov 2010 11:41:41 +0100 Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02 Thread-Index: Act6w7C7xiBmxJg2SH+yiHKjhwzf7AAfNIuw Message-ID: References: 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] 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: Wed, 03 Nov 2010 10:41:44 -0000 > > 1. As a general comment that I have made before, the > document still talks about 'header' in many places where it > is not referring to the entire header for a SIP message, but > only to a particular header field such as History-Info. > History-Info is only one field within the entire SIP header. > See RFC 3261 section 6 - definitions of header and header > field. Although RFC 3261 is not 100% consistent, in general > things like Contact, To, From etc. are referred to as header > fields, and hence History-Info should be too. Section 4.3 of > RFC 4485 also calls for attention to be given to the correct > use of terms header, header field and header field parameter, > although it fails to say what the correct use is and one has > to rely on RFC 3261. > [MB] I replied to this in the other email. But, yes, this doc > does use Header to mean Header field, but that's done in many > other documents. > However, I can change all of those to say "header field" if > it makes a difference in understanding the document. [This > might be something to put on the RFC editor list if folks are > insisting that we always use "Header field"] The term header > field parameter AFAIK is only used to refer to the two new > header field parameters defined in this document. > [/MB]. If you look at the definitions in RFC 3261 you will find that "header" and = "header field" are terms with two very different meanings, so I would suppo= rt the change to "header field". > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > Sent: Tuesday, November 02, 2010 7:25 PM > To: Elwell, John > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02 > > Hi John, > > Responses inline below [MB]. I will skip the ones that I > replied to in the other response [MB]. > > Thanks, > Mary. > > On Mon, Nov 1, 2010 at 5:13 PM, Elwell, John > wrote: > > Despite the effort that has gone into addressing comments > raised by people on -01, I still find -02 hard to understand > in places. I have not had time to review the whole document, > but here are some comments up to section 7. Just as I > finished writing this I saw Mary's response to my comments on > -01, which I will respond to tomorrow. Apologies for any > overlap between the two. > > > > > > 1. As a general comment that I have made before, the > document still talks about 'header' in many places where it > is not referring to the entire header for a SIP message, but > only to a particular header field such as History-Info. > History-Info is only one field within the entire SIP header. > See RFC 3261 section 6 - definitions of header and header > field. Although RFC 3261 is not 100% consistent, in general > things like Contact, To, From etc. are referred to as header > fields, and hence History-Info should be too. Section 4.3 of > RFC 4485 also calls for attention to be given to the correct > use of terms header, header field and header field parameter, > although it fails to say what the correct use is and one has > to rely on RFC 3261. > [MB] I replied to this in the other email. But, yes, this doc > does use Header to mean Header field, but that's done in many > other documents. > However, I can change all of those to say "header field" if > it makes a difference in understanding the document. [This > might be something to put on the RFC editor list if folks are > insisting that we always use "Header field"] The term header > field parameter AFAIK is only used to refer to the two new > header field parameters defined in this document. > [/MB]. > > > > Also there are some instances of "header parameter field", > which is not a normal term - it should be "header field parameter". > [MB] That's a typo. [/MB] > > > > 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] > > > > 3. The word "entry" is used inconsistently. Mostly it > occurs in "hi-entry", which is fine. But we also have > "targeted-to-URI entry", "entry" (alone), History-Info entry > (which is probably fine, as long as we say what it is), > "header entry". Also "hi-entries". > [MB] Which term do you prefer? I will change all the > entry(s) to hi-entry. The targeted-to-URI entry possibly > should be hi-targeted-to-uri. [/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] > > > > 5. Section 1: > > "there is a need for a standard mechanism within > > SIP for communicating the retargeting history of such a request" > > What is meant by "such a request"? We have not previously > mentioned "request". The preceding text has talked about > calls, not requests, but perhaps it should talk about requests. > [MB] I will change "such a request" to "call requests". [/MB] > > > > 6. Section 3: > > "Current network applications provide the ability for elements > > involved with the call to exchange additional > information relating > > to > > how and why the call was routed to a particular destination" > > Change "exchange" to "obtain". I think that would fit > better with the examples that follow. > [MB] Okay. [/MB] > > > > 7. Section 3: > > "Capturing aliases and Globally Routable User Agent URIs (GRUUs) > > [RFC5627], which can be overwritten by a home proxy > upon receipt" > > The term "home proxy" is not used in RFC 3261. > [MB] I will change to "proxy in the home domain" which is a > term used in RFC 5627 (earlier versions of GRUU did use the > term "home proxy")[/MB] > > > > 8. Section 4: > > "The following information is carried in the History-Info header as > > detailed in Section 7.1:" > > I think it would be better to say "For each target used for > forwarding a request, the following information is carried > in the History-Info header as detailed in Section 7.1:" > > This would make it clear that there can be more than one > instance of this information. > [MB] Okay. [/MB] > > > > 9. Section 4; > > "Target : A parameter indicating ..." > > This overloads the word target. Perhaps a better generic > term for these parameters would be "Derivation". > [MB] I will just change to "Indicates.." which matches the > form of the other bullets in that list. [/MB] > > > > 10. Section 4: > > "A SIP entity changing the target of a > > request in response to a redirect or REFER" > > A REFER does not cause an entity to change the target of a > request - it causes an entity to generate a new request. H-I > will indeed be added, but that is covered by the statement > above about creating a new request. > [MB] Yep. [/MB] > > > > 11. "propagates any > > History-Info header from the initial Request in the new request": > > Contrary to what it says in the first half of the sentence, > this does indeed acknowledge that we have a new request as a > result of REFER. However, the statement is incorrect because > there is no normative statement (e.g., in section 5) > concerning this special behaviour for REFER. There is merely > a requirement in Appendix A. > [MB] I'll add text. [/MB] > > > > 12. Section 4: > > "Note that an hi-entry is not included for the fork to > > sip:bob@192.0.2.7 " > > This is misleading, because there is indeed H-I sent to > 192.0.2.7. I think what it should say is that the H-I sent to > 192.0.2.3 and subsequently sent back to Alice does not > contain an entry for target 192.0.2.7. > [MB] yep. [/MB] > > > > 12bis. Section 5.1: > > "In addition, the UAC > > SHOULD add a History-Info header" > > Why is this only a SHOULD, not a MUST? What would be the exceptions? > [MB] This was issue #28 where Dale suggested it be change > from a "MAY" to a "SHOULD" (with which you agreed in the > email thread). But, I don't have a problem to change this to > a MUST. [/MB] > > > > 13. Section 5.1: > > "As a result, intermediaries and > > the UAS at least know the original Request-URI, and if > the Request- > > URI was modified by a previous hop. " > > This is inaccurate, since intermediaries may have removed > H-I for privacy or other reasons. Best to delete the sentence. > [MB] Okay. HOwever, entries should not be removed for privacy > - that was a change from RFC 4244 - they MUST be anonymized. [/MB] > > > > 14. Section 5.1: > > "A UAC that wants to ensure that privacy not > > be applied to its identity MUST include a Privacy header with a > > priv- > > value of "none"." > > I am not sure that 'none' ensures anything - it is only a > request according to RFC 3323. > [MB] Then I'll change it from "ensure" to "request". [/MB] > > > > 15. Section 5.1: > > "A new hi-entry MUST then be added for the URI from > > the Contact header (which becomes the new Request-URI) " > > The Contact header field could contain >1 URIs. I think > what we want to say is that the UAC MUST populate the > new-hi-entry with the URI chosen as the Request-URI for the > new request. > [MB] Yes. [/MB] > > > > 16. Section 5.1: > > "If the Contact header contained any of > > the header parameter fields defined in this specification" > > Don't understand. The parameters defined in this > specification are parameters of the History-Info header > field, so would not appear in a Contact header field. > Admittedly there is some mention in 7.3.4 of using the > parameters in a Contact header field, but there is nothing > that specifies the extended syntax of the Contact header field. > [MB] The header field parameters are defined for the Contact > header (and History-Info) in the IANA section. It is > introduced in 7.1 and the usage thereof described in 7.3.4. [/MB] > > > > 17. Section 5.1: > > "MUST include the header parameter field as a header > parameter field > > associated with the current hi-entry as described in > Section 7.3.4." > > Is "current hi-entry" the "new hi-entry" from a couple of > sentences earlier? > [MB] Yes. Do you have a terminology preference? [/MB] > > > > 18. Section 5.2.1: > > "The last hi-entry reflects the most recent > > target and MUST contain the Request-URI for the received request," > > If I interpret this correctly, this is talking about what > the UAS receives. What the UAS receives is outside the > control of the UAS, so we can't use RFC 2119 language. Should > be "will". > [MB] Yep. [/MB] > > > > 19. Section 5.2.1: > > "e.g., the last proxy does > > not support History-Info" > > In the previous sentence we used the term "previous > entity", so it would be better to stick to that term rather > than "last proxy". > [MB] Okay. [/MB] > > > > 20. Section 5.2.1: > > "hi-index attribute" > > and > > "hi-target attribute" > > Up till now we have called these parameters rather than attributes > [MB] I'll change to parameter [/MB]. > > > > 21. Section 5.2.1: > > "The > > addition of the missing hi-entry ensures that the most complete > > information can be provided in the response ..." > > Not sure that it is "most complete" - "more complete" would > be better, since there could still be some missing entries > from upstream. > [MB] Most complete as "possible" - but I can change to "more". [/MB] > > > > 22. Section 5.2.1: > > "Prior to any application usage of the information, the > validity MUST > > be ascertained" > > What MUST ascertain the validity - the UAS or the > application? Use active voice. How does it do this? Is this > testable? I don't believe we can use RFC2119 language here. > [MB] That is saying that the UAS MUST check that the entries > that it is aware of contain the information that might be > needed by an application (i.e., the last entry, target header > field parameters, etc.). It's testable from a software > implementation perspective - not a protocol perspective. I > can change the MUST to a lower case recommended .. ie., it is > recommended that the UAS...Note, that this was one of the > SHOULDS (from RFC 4244) that folks wanted to change to MUST. [/MB] > > > > 23. Section 5.2.2: > > "If the "histinfo" option tag is received in a request, the UAS MUST > > include any History-Info received in the request in the subsequent > > response" > > This is incorrect for a B2BUA - a B2BUA should be allowed > to use information received from its other interface. Also it > is not necessarily correct for a regular UAS, since I would > have thought a UAS should be required to include the hi-entry > inserted in accordance with 5.2.1, rather than using just the > H-I received. > [MB] We can reword something like the following to capture > your concern: > > If the "histinfo" option tag is received in a request, the UAS MUST > include any History-Info received in the request and any hi-entries > added by the UAS in the subsequent response. In addition, in > the case of a B2BUA, the UAS MAY include any hi-entries > received by the UAC in a response in the subsequent response > sent by the UAS. > > [/MB] > > > > > 24. Section 5.2.2: > > "The processing of History-Info in responses follows the methodology > > described in Section 16.7 of [RFC3261], " > > We can't refer to 16.7 of RFC 3261, because that is for > proxies, not UASs. > [MB] See reply in other email response [/MB] > > > > 25. Section 5.3: > > "the redirect server MUST add the appropriate target header > > field parameter to each Contact header as described in > Section 7.3.4." > > I don't think 7.3.4 tells me how to do this. Section 7.3.4 > does mention the Contact header field, but only in the > context of adding these parameters to the History-Info header > field (if I understand correctly). > [MB] 7.3.4 tells you which one to add based upon the > mechanism by which the targets are determined. The header > field parameter is added based upon the same criteria. [/MB] > > > > 26. Section 6: > > "A Reason MAY be associated with the hi-targeted-to-uri > that has been > > retargeted as shown in the example in Appendix B.1." > > It would be good to be more precise, since B.1 is long - > refer to A6, perhaps. > [MB] Okay. [/MB] > > > > 27. Section 6.1.1: > > "The proxy MUST include an hi-index attribute > > with a value of "1"" > > It says we are inserting an entry, not replacing any > existing entries. Value "1" will not apply if there is an > existing entry. > [MB] Correct. If the prior hop did not include an hi-entry, > then one is added. Even if there are already other > hi-entries, there is no way to know how many hops might have > been missed and thus, the indexing needs to be reset to 1 to > reflect such. [/MB] > > > > 28. Section 6.1.1: > > "The proxy MUST add a separate hi-entry in each > > separate outgoing request for each of the current (outgoing) > > targets in the target set." > > Ambiguous - there should be only one entry per request - > not one per target in each request. > > Perhaps it should say "For each outgoing request relating > to a target in the target set, the proxy MUST add a single > hi-entry identifying that target. For this new hi-entry, the > proxy MUST..." > [MB] Yes - your suggestion is more clear. [/MB] > > > > 29. Section 6.1.2: > > "When re-sending a request as " > > I don't think this is really resending - we are > retargeting, and therefore changing some aspects of the > original request. > [MB] I'll change to "sending the retargeted request" [/MB] > > > > 30. Section 6.1.2: > > "in the order indicated by the indexing (see > > Section 7.3.3)" > > We really need a more precise reference - where in 7.3.3 > does it tell me how to use the aggregated information? > [MB] 7.3.3. refers to RFC 3261 Step 7 > "Aggregate Authentication Header Field Values", which states: > "the proxy MUST collect any WWW- > Authenticate and Proxy-Authenticate header field values from > all other 401 (Unauthorized) and 407 (Proxy Authentication > Required) responses received so far in this response context > and add them to this response without modification before > forwarding. " > > It's actually easier to just reword that to match what is > done for History-Info header field something like the following: > The SIP entity MUST collect any History-Info header > field values from > all other responses received so far in this response context > and add them to this response without modification before > forwarding. > [/MB] > > > > > > 31. Section 6.1.2: > > "If the received error response did not include > > any History-Info header fields, the proxy MUST use the same > > History-Info header fields that were sent in the > outgoing request > > that failed to build the outgoing request." > > First, the two instances of "outgoing request" are > confusing - I think the second should be "new outgoing > request" or "retargeted request". > [MB] I'll change to "new outgoing request" since the other > request could also have been retargeted. > > Second, what if some responses include aggregated > information and others don't? > [MB] That shouldn't matter. The receiving entity will use > what it can. If the normative procedures are followed, it's > fairly deterministic as to when the aggregated information > should be used. > [/MB] > > > > 32. Section 6.1.2: > > "Same as per Step 2 above for the normal forwarding case > > Section 6.1.1." > > This is confusing, because 6.1.1 is not on "normal > forwarding case" but on "initial requests". > [MB] Section 6.1.2. use of "initial" is referring to both > the case of the "initial" hi-entry to be added (bullet 1) AND > the case whereby a Proxy received a request and it is adding > the "initial" hi-entry for the first ("initial") retargeting. > The "normal" forwarding is specifically bullet #3. I think > it would be clearer if we just removed the word "initial" > from the title and first paragraph and add an explicit > reference to bullet 3. [/MB] > > > > 33. Section 6.1.3: > > "When re-sending a request as " > > Again I don't think "re-sending" is the correct term. > [MB] I'll change to the "generating new requests" [/MB] > > > > 34. Section 6.1.3: > > " Step 1: Including Previous Entries > > The proxy MUST include the History-Info header fields that were > > sent in the outgoing request that is being redirected." > > This seems to be a significant difference from the > 4xx/5xx/6xx case. In that case we include any hi-entries from > downstream entities that have sent back the 4xx/5xx/6xx - why > not in the 3xx case too? > [MB] See response to issue 25 in your previous set of comments. [/MB] > > > > 35. Section 6.1.3: > > "add a Reason header this > > entry" > > Change "this" to "to this". > > > > 36. "MUST forward captured History-Info in subsequent, > > provisional, and final responses to the request sent by > the ultimate > > UAS (see Section 5.2)" > > If a response does not contain any captured H-I (because > the UAS doesn't support it), is there any requirement on the > proxy to generate it from its own information? > [MB] A proxy would have added an hi-entry for the UAS if it > follows the normative procedures in this document. But, there > is no way for the proxy to generate any additional hi-entries > (in cases where the > UAS internally retargets or B2BUA case). [/MB] > > > > 37. Section 7.1: > > "Reason: An optional parameter for History-Info," > > It is not in the ABNF as a parameter of History-Info - in > fact it is an escaped header field. > [MB] Correct - this is a summary of information associated with each > hi-entry and it is described in as being escaped. Logically, the > information is there. Certainly, it's clear that it's not > defined specifically in the ABNF for the header. [/MB] > > > > 38. Section 7.1: > > "he hi-target is added for a hi-entry when it is > > first added in a History-Info header field, and only > one value is > > permitted" > > I believe it should say "only one parameter is permitted". > True that parameter ('rc' or 'mp') can have only one value, > but I don't think that is the point we are trying to make. > [MB] Correct. [/MB] > > > > 39. Section 7.3.2: > > "If the response contains a Reason header for a protocol > > that is not SIP (e.g., Q.850), it MUST be captured as an > additional > > Reason associated with the hi-targeted-to-uri that has been > > retargeted, along with the SIP Response Code" > > I think this is saying that the entity MUST include two > Reason parameters in the hi-entry. Perhaps we should state > that more explicitly. Also, does order matter? > [MB] I can add (i.e., there will be two reason headers), but > I figured when you add "an additional" to one, that it's > obvious that there are two headers. Per RFC , order does not > matter. [/MB] > > > > 40. Section 7.3.3 item 6: > > "When a response is built and it represents the aggregate of > > responses to multiple forks " > > Suddenly we are talking about forks when previously we were > talking about branches. > [MB] A branch reflects a fork. I'll clarify the text in > item 6, such that it reads: > "the index MUST be captured > for each forked request, creating a new branch, per > the rules above..." > and change the use of forks to branch in the body of item 6. > [/MB] > > > > 41. Section 7.1.3, item 6: > > "For example, if > > a procesing entity received failure responses for forks 1.1.1 > > and > > 1.1.2, it would return both the 1.1.1 and 1.1.2 entries to the > > entity that generated the hi-entry with index of 1." > > I can't figure this out - shouldn't "index of 1" be "index of 1.1"? > [MB] No. The processing entity in that sentence has the index of 1.1. > The processing entity is the subject of that sentence and > "it" returns the response to the entity that would have added > the hi-entry with index of 1.[/MB] > > > > 42. Section 7.1.3, item 6: > > "See > > Appendix B.1 for an example" > > It is unclear where exactly in B.1 I am supposed to look - > searching for '1.1.1' or '1.1.2' produces no results. Please > cite the specific messages. > [MB] Okay. [/MB] > > > > Although I didn't review beyond section 7, I happened to > notice the following in Appendix B: > > "B. An entity (UA or proxy) retargeting in response to a redirect > > or REFER MUST include any Request History information from > > the redirect/REFER in the new request." > > It is unclear how you can retarget in response to a REFER. > A REFER requests leads to the generation of a new request - > there is no retargeting. > [MB] I'll reword that to reflect that the REFER includes the > History-Information from previous retargets. [/MB] > > > > John > > _______________________________________________ > > 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 > From keith.drage@alcatel-lucent.com Wed Nov 3 03:42:55 2010 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 D2DA43A68F9 for ; Wed, 3 Nov 2010 03:42:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 bvvDPjoMiRpe for ; Wed, 3 Nov 2010 03:42:54 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id AE7173A68C8 for ; Wed, 3 Nov 2010 03:42:53 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oA3AcGGu012394 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Wed, 3 Nov 2010 11:42:53 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Wed, 3 Nov 2010 11:41:43 +0100 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "sipcore@ietf.org" Date: Wed, 3 Nov 2010 11:41:42 +0100 Thread-Topic: [sipcore] H-I in 100 response (was REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis) Thread-Index: Act63BKdJQ94zP/mThCiSQMb7hD1HQAZZW6g Message-ID: References: <4C69ADA8.1010802@nostrum.com> <4C753AAA.3030407@nostrum.com> <4CD08E7A.1020503@cisco.com> In-Reply-To: <4CD08E7A.1020503@cisco.com> 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-Scanned-By: MIMEDefang 2.64 on 155.132.188.80 Subject: Re: [sipcore] H-I in 100 response (was REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis) 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: Wed, 03 Nov 2010 10:42:55 -0000 Please do not put it in 100 responses, i.e. MUST NOT. Note that if it is put in 1xx responses that are not sent reliably, then in= my understanding you have no means of telling you have lost it along with = the response. So in this case it would have to be repeated in the final res= ponse. However there is probably a use case for being able to inform the us= er of call diversion at alerting time, so I would certainly allow it, i.e. = MAY to generate it or add to it, MUST to pass one on if you receive it. Keith > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Tuesday, November 02, 2010 10:20 PM > To: sipcore@ietf.org > Subject: Re: [sipcore] H-I in 100 response (was REMINDER: Re:=20 > WGLC: draft-ietf-sipcore-rfc4244bis) >=20 >=20 >=20 > On 11/2/2010 4:31 PM, Elwell, John wrote: > > So the remaining issue from this thread concerns whether to=20 > mandate History-Info in a all provisional responses or just=20 > non-100 provisional responses (subject to presence of the=20 > option tag in the request). Given that 100 tends to be=20 > generated differently from other provisional responses, and=20 > given the marginal use of H-I in 100 responses, I would=20 > prefer either to omit H-I from 100 responses or use MAY. I=20 > don't have a strong opinion, but perhaps others have a view. >=20 > Requiring (even permitting) H-I in 100 responses is a *terrible* idea. >=20 > I don't see why you would need H-I in *any* provisional=20 > responses (with the possible exception of 199.) >=20 > (Disclaimer - I have not read all the discussion on this subject.) >=20 > Thanks, > Paul >=20 > > John > > > > > >> -----Original Message----- > >> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] > >> Sent: 02 November 2010 19:51 > >> To: Elwell, John > >> Cc: sipcore@ietf.org > >> Subject: Re: [sipcore] REMINDER: Re: WGLC: > >> draft-ietf-sipcore-rfc4244bis > >> > >> John, > >> > >> I've done the same. A couple responses inline below [MB2]. > >> > >> Thanks, > >> Mary. > >> > >> On Tue, Nov 2, 2010 at 4:06 AM, Elwell, John=20 > >> wrote: > >>> Mary, > >>> > >>> I have responded below, stripping out the stuff where I > >> have nothing further to add. > >>> > >> > >>>>> 2. It nearly always uses the term "header" rather than > >>>> "header field", although never, as far as I know, meaning the=20 > >>>> entire SIP header. > >>>> [MB] I'm not sure that I fully understand the concern. Can > >> you point > >>>> out a specific sentence or section of concern? The term > >> "header" is > >>>> used when it is referring to the History-Info header > >> field, but that > >>>> is done in other documents as well. In general, I think it's=20 > >>>> understood that it's referring to the header field when it's=20 > >>>> qualified. Perhaps you're referring to places where it is not > >>>> qualified? The term hi-entry is used, as well. > >>>> [/MB] > >>> [JRE] I have explained in more detail in my comments on -02. > >> [MB2] I've responded to that in my subsequent response to your=20 > >> comments. [/MB2] > >>> > >>> > >> > >>>>> > >>>>> 18. Section 4.2.2: > >>>>> "the UAS MUST > >>>>> include any History-Info received in the request in the > >>>> subsequent > >>>>> response" > >>>>> Does this include 100 responses? > >>>> [MB] I would think so. Can you think of a reason why it > >> shouldn't? I>> would think it could be useful for debug. [/MB] > >>> [JRE] The 100 response typically only travels back a single > >> hop, so the benefit of H-I in a 100 is marginal. Also some=20 > >> implementations might send back a 100 response quite early during=20 > >> processing, perhaps even before they decide whether to act as a=20 > >> proxy, a UAS or a redirect, so knowing how to populate H-I=20 > in a 100=20 > >> might be difficult. > >> [MB2] If it has no additional hi-entries, then there is nothing=20 > >> additional to send back, so I don't think it hurts=20 > anything - I would=20 > >> agree that in most cases it's of marginal value. We can=20 > include it as=20 > >> an exception in that sentence if you would prefer,=20 > although per the=20 > >> next comment, it seems that you are okay with leaving it as is. > >> [/MB2] > >>> > >>> > >>>>> > >> > >>>>> > >>>>> 26. Section 5.2: > >>>>> "A proxy that receives a request with the "histinfo" option > >>>> tag in the > >>>>> Supported header, SHOULD forward captured History-Info in > >>>> subsequent, > >>>>> provisional , and final responses " > >>>>> Does this include 100 responses? > >>>> [MB] That's the implication of "provisional" per RFC 3261. [/MB] > >>> [JRE] I am doubtful about the usefulness of 100. However, > >> it is probably fairly academic, since 100 will probably have been=20 > >> sent earlier. A proxy is unlikely to send a 100 after receiving a=20 > >> provisional response from a downstream entity. > >>> > >>>>> > >>>>> 27. Section 5.2: > >>>>> "A proxy MAY anonymize any hi-entry whose domain=20 > corresponds to a > >>>>> domain for which it is responsible (as per [RFC3323 ])." > >>>>> I don't think RFC 3323 tells me how to anonymize an hi-entry. > >>>> [MB] RFC 3323 discusses anonymization and the role of an > >> anonymizer, > >>>> etc. So, I'm not clear on your concern. [/MB] > >>> [JRE] I guess if we talked about anonymizing the URI in the > >> hi-target-to-uri it would be clearer. > >> [MB2] That's fine...I'll make it explicit that it's the=20 > >> hi-targeted-to-uri in the hi-entry that is anonymized. [/MB2] > >>> > >>> > >>> > >>> > >>> John > >> > > _______________________________________________ > > 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 > = From youssef.chadli@orange-ftgroup.com Wed Nov 3 05:14:23 2010 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 F0B1D3A6A9D for ; Wed, 3 Nov 2010 05:14:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_29=0.6, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-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 y25eLKx0uSrw for ; Wed, 3 Nov 2010 05:14:23 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id E42383A6825 for ; Wed, 3 Nov 2010 05:14:22 -0700 (PDT) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4FB068B813E; Wed, 3 Nov 2010 11:27:58 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 529628B8039; Wed, 3 Nov 2010 10:59:39 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Wed, 3 Nov 2010 10:58:26 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Wed, 3 Nov 2010 10:55:41 +0100 Message-ID: <9ECCF01B52E7AB408A7EB8535264214102155080@ftrdmel0.rd.francetelecom.fr> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Bypassing out-of-service intermediate Proxy Thread-Index: ActKwqukakXd2CSyR9G+Afh4w9O9dQsxhaSAAAMmKZUA6UXXwA== References: <9ECCF01B52E7AB408A7EB8535264214101CD7EE2@ftrdmel0.rd.francetelecom.fr><4C7FDBEE.6080305@nostrum.com>, <9ECCF01B52E7AB408A7EB85352642141020FD443@ftrdmel0.rd.francetelecom.fr> From: To: , X-OriginalArrivalTime: 03 Nov 2010 09:58:26.0218 (UTC) FILETIME=[A89B90A0:01CB7B3D] Cc: sipcore@ietf.org Subject: Re: [sipcore] Bypassing out-of-service intermediate Proxy 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: Wed, 03 Nov 2010 12:14:24 -0000 I understand that the usage of DNS to provide alternate server is a way = to ensure redundancy. In such solution, to be able to handle SIP = requests inside a SIP dialog and for which the proxy need to be "dialog = statefull", there is a need to implement a mechanism that would allow = the "alternate" server to share the same SIP dialog contexts. My idea is in case of unavailability of the next hop and in case no = alternate server is returned by DNS (or alternate servers are = unreachable too), instead of rejecting the request (which would make the = call/session fails), the SIP Proxy may send it to the hop after the = unreachable one in the Route. This alternative would be authorized only = if the Proxy knows that it's better to bypass the unreachable node = instead of rejecting the request. The SIP proxy may get this information = via a URI parameter in the Route entry of the "unreachable" node for = example Best regards, Youssef -----Message d'origine----- De : Worley, Dale R (Dale) [mailto:dworley@avaya.com]=20 Envoy=E9 : vendredi 29 octobre 2010 20:22 =C0 : CHADLI Youssef RD-CORE-ISS; adam@nostrum.com Cc : sipcore@ietf.org Objet : RE: [sipcore] Bypassing out-of-service intermediate Proxy ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of = youssef.chadli@orange-ftgroup.com [youssef.chadli@orange-ftgroup.com] I understand that the intention of this text in RFC 3261 is to fail over = to an alternate server that serves the same function. Though, it's not = explicitly stated. However, I did not find any text in RFC 3261 that would make forbidden = failing over to a proxy further down the path. Moreover, I did not see = any problem to such behaviour. ________________________________ If a particular URI is included in a Route header, then there is some = important function the server with that URI is to perform. If one = element ignores this URI and sends the request to the next URI in the = Route header, presumably the function of the skipped server will not be = performed. In all cases that I have heard about, the correct way to provide = alternate servers for a failed server is to construct a DNS SRV name = which maps to the primary and alternate server as is desired. For instance, if functionA is to be serviced by serverA but in an = emergency the request can be routed to serverB, and if functionB is = serviced by serverB, then we construct two SRV names: functionA SRV serverA priority=3D1 functionA SRV serverB priority=3D2 functionB SRV serverB priority=3D1 and use this Route header: Route: sip:functionA, sip:functionB If an element has a request with this Route header, it will send the = request to sp:functionA using the RFC 3263 rules, viz., attempt to send = to serverA, and if that fails, attempt to send to serverB. Dale From pkyzivat@cisco.com Wed Nov 3 06:57:40 2010 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 534B63A68D2 for ; Wed, 3 Nov 2010 06:57:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8, 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 rCicjUpJjEpO for ; Wed, 3 Nov 2010 06:57:35 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 164D23A69B3 for ; Wed, 3 Nov 2010 06:57:33 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIIH0UxAZnwN/2dsb2JhbAChZHGiQ5tahUYEilWDCA X-IronPort-AV: E=Sophos;i="4.58,289,1286150400"; d="scan'208";a="178153144" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 03 Nov 2010 13:57:39 +0000 Received: from [10.86.250.226] (bxb-vpn3-738.cisco.com [10.86.250.226]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oA3DvdDO008250 for ; Wed, 3 Nov 2010 13:57:39 GMT Message-ID: <4CD16A52.7090006@cisco.com> Date: Wed, 03 Nov 2010 09:57:38 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: sipcore@ietf.org References: <9ECCF01B52E7AB408A7EB8535264214101CD7EE2@ftrdmel0.rd.francetelecom.fr><4C7FDBEE.6080305@nostrum.com>, <9ECCF01B52E7AB408A7EB85352642141020FD443@ftrdmel0.rd.francetelecom.fr> <9ECCF01B52E7AB408A7EB8535264214102155080@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB8535264214102155080@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Subject: Re: [sipcore] Bypassing out-of-service intermediate Proxy 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: Wed, 03 Nov 2010 13:57:40 -0000 This idea seems analogous to the auto assembly line deciding to bypass the broken station where the engine is inserted into the car, and just send the car on to the next station without its engine. The consumer who receives this car may be less than satisfied. :-( Thanks, Paul On 11/3/2010 5:55 AM, youssef.chadli@orange-ftgroup.com wrote: > > I understand that the usage of DNS to provide alternate server is a way to ensure redundancy. In such solution, to be able to handle SIP requests inside a SIP dialog and for which the proxy need to be "dialog statefull", there is a need to implement a mechanism that would allow the "alternate" server to share the same SIP dialog contexts. > > My idea is in case of unavailability of the next hop and in case no alternate server is returned by DNS (or alternate servers are unreachable too), instead of rejecting the request (which would make the call/session fails), the SIP Proxy may send it to the hop after the unreachable one in the Route. This alternative would be authorized only if the Proxy knows that it's better to bypass the unreachable node instead of rejecting the request. The SIP proxy may get this information via a URI parameter in the Route entry of the "unreachable" node for example > > Best regards, > > Youssef > > -----Message d'origine----- > De : Worley, Dale R (Dale) [mailto:dworley@avaya.com] > Envoyé : vendredi 29 octobre 2010 20:22 > À : CHADLI Youssef RD-CORE-ISS; adam@nostrum.com > Cc : sipcore@ietf.org > Objet : RE: [sipcore] Bypassing out-of-service intermediate Proxy > > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of youssef.chadli@orange-ftgroup.com [youssef.chadli@orange-ftgroup.com] > > I understand that the intention of this text in RFC 3261 is to fail over to an alternate server that serves the same function. Though, it's not explicitly stated. > > However, I did not find any text in RFC 3261 that would make forbidden failing over to a proxy further down the path. Moreover, I did not see any problem to such behaviour. > ________________________________ > > If a particular URI is included in a Route header, then there is some important function the server with that URI is to perform. If one element ignores this URI and sends the request to the next URI in the Route header, presumably the function of the skipped server will not be performed. > > In all cases that I have heard about, the correct way to provide alternate servers for a failed server is to construct a DNS SRV name which maps to the primary and alternate server as is desired. > > For instance, if functionA is to be serviced by serverA but in an emergency the request can be routed to serverB, and if functionB is serviced by serverB, then we construct two SRV names: > > functionA SRV serverA priority=1 > functionA SRV serverB priority=2 > > functionB SRV serverB priority=1 > > and use this Route header: > > Route: sip:functionA, sip:functionB > > If an element has a request with this Route header, it will send the request to sp:functionA using the RFC 3263 rules, viz., attempt to send to serverA, and if that fails, attempt to send to serverB. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From john.elwell@siemens-enterprise.com Wed Nov 3 09:30:09 2010 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 D739F28C117 for ; Wed, 3 Nov 2010 09:30:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.407 X-Spam-Level: X-Spam-Status: No, score=-102.407 tagged_above=-999 required=5 tests=[AWL=0.192, BAYES_00=-2.599, 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 ObJloje0M39X for ; Wed, 3 Nov 2010 09:30:07 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id DDF5C28C112 for ; Wed, 3 Nov 2010 09:30:06 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2159862; Wed, 3 Nov 2010 17:29:39 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 7B4E723F0278; Wed, 3 Nov 2010 17:29:39 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 3 Nov 2010 17:29:39 +0100 From: "Elwell, John" To: "sipcore@ietf.org" , "Barnes, Mary" Date: Wed, 3 Nov 2010 17:29:38 +0100 Thread-Topic: Yet more comments on rfc4244bis-02 Thread-Index: Act7dE7fGKtf73x4SlyxiZGRr9yA0A== Message-ID: 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 Subject: [sipcore] Yet more comments on 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: Wed, 03 Nov 2010 16:30:09 -0000 1. Section 7.3.1. "If there is a Privacy header in the request with a priv- value of "header" or "history", then the initial hi-entry MUST be anonymized and the header removed when the request leaves a domain for which the SIP entity is responsible." I think it should say "...and the Privacy header removed" - there is no poi= nt in removing the H-I header field if we have anonymized it. 2. What is meant by anonymizing a hi-entry (in this paragraph and elsewhere= )? Is it only the hi-targeted-to-uri that needs to be anonymized, or also i= ts parameters? The examples in annex B show just the URI anonymized and wit= h the value anonymous@anonymous.invalid. Is this how it MUST be done? 3. In the same sentence, is it sufficient to anonymize only the first hi-en= try? There could be further hi-entries for the same domain, and just reveal= ing internal routing within the domain might be considered a breach of priv= acy. Perhaps in that case you would need to rely on those additional hi-ent= ries being separately marked for privacy. If that is so, it would seem to b= e OK. 4. "In addition, the History-Info header can reveal general routing and diverting information within an intermediary, " Is it only routing information within an intermediary, or also routing info= rmation within a domain that you might want to make private? I think text l= ater in the paragraph concurs with the latter view. 5. "Finally, the terminator of the request may not want to reveal the final reached target to the originator. In this case, the terminator uses the a value of "history" in the Privacy header in the last hi- entry in the response. The SIP entity that forwards the response MUST anonymize that hi-entry and remove the Privacy header." Although a UAS can mark the final hi-entry as private, and there is a requi= rement for a proxy to anonymize this when the response leaves the domain, w= hat about other hi-entries that have been marked by proxies in the final do= main as private? These will get passed back in the response without anonymi= zation since they are not the final hi-entry and are not covered by this st= atement. Should the final sentence apply to any hi-entry? 6. Section 7.3.3: "To accomplish this, the processing entity MUST read the value from the History-Info header in the received request and MUST add another level of indexing " Should make it clear it is the last hi-entry of the received request (after= adding entries on behalf of previous hops). 7. "followed by an initial index for the new level of 1" I think this would be clearer if it said: "followed by an initial index of 1 for the new level" 8. "MUST be calculated by incrementing the last/lowest digit at the current level" and=20 "That is, the lowest/last digit of the index MUST be incremented " What if an index is a double-digit integer? 9. Section 8: "an application might need to provide special handling in some cases where there are gaps." Should there be a note discussing the fact that some gaps are not detectabl= e, e.g., if I receive 1, 1.1 and 1.1.1, I cannot detect if 1.2 or 1.1.2, sa= y, is missing. 10. Should we say anything in section 8 about anonymized entries? Note that= what we might say depends to some extent on whether what exactly gets anom= ymised. For example if an application searches for an rc or mp entry, if th= ose parameters have been anonymized it will not find them (but might find o= thers that have not been anonymized!), but if those parameters have not bee= n anonymized it will find them but the URI will be useless. 11. Section 9: "With the level of security provided by TLS (SEC-req-3), the information in the History-Info header can thus be evaluated to determine if information has been removed by evaluating the indices for gaps (SEC-req-1, SEC-req-2). " This is subject to the limitation pointed out in a comment above, about not= all gaps being detectable. 12. I would expect to see something in section 9 concerning privacy. We sho= uld mention the privacy mechanism and discuss its limits (i.e., depends on = trust of downstream entities to anonymize privacy-marked entries). Also the= re should probably be some discussion on strength of anonymization algorith= ms (unless we are indeed prescribing anonymous@anonymous.invalid). 13. Section 10.2: "This document defines a priv-value for the SIP Privacy header: history The following changes have been made to http://www.iana.org/assignments/sip-priv-values The following has been added to the registration for the SIP Privacy header:" I am not sure how to parse this. 14. Section 12.1: "This specification adds an optional SIP header field parameter to the History-Info and Contact headers. " In fact it adds two parameters to each. 15. "Entities that have not implemented this specification MUST ignore these parameters, " We cannot place a normative requirement on entities that don't implement th= is. Change "MUST" to "will". John From john.elwell@siemens-enterprise.com Thu Nov 4 10:48:28 2010 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 126FF28C0FF for ; Thu, 4 Nov 2010 10:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.435 X-Spam-Level: X-Spam-Status: No, score=-102.435 tagged_above=-999 required=5 tests=[AWL=0.164, BAYES_00=-2.599, 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 XFqIsApE5uiy for ; Thu, 4 Nov 2010 10:48:25 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id F3A303A6942 for ; Thu, 4 Nov 2010 10:48:22 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2178792; Thu, 4 Nov 2010 18:48:22 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id D365323F0278; Thu, 4 Nov 2010 18:48:22 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Thu, 4 Nov 2010 18:48:22 +0100 From: "Elwell, John" To: "DRAGE, Keith (Keith)" , "hannu.hietalahti@nokia.com" , "rbarnes@bbn.com" , "jmpolk@cisco.com" Date: Thu, 4 Nov 2010 18:48:21 +0100 Thread-Topic: [sipcore] Location Conveyance -04 submitted, here's the changes Thread-Index: Act2mlVdTb0CvQzFTY2pDhKiRuhu2gAAtZtwAMcwGpAAFNySEACOdTlg Message-ID: References: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com> <625A3E65-E441-4340-A5E2-B847F8B964CF@bbn.com> <201010271838.o9RIcjgG008761@sj-core-5.cisco.com> <63EEFC46-26FC-4A69-B1A7-2CC79583B8B2@bbn.com> <5BAF85033CB5F3439C4DE153165522B1109FDD491C@NOK-EUMSG-06.mgdnok.nokia.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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes 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: Thu, 04 Nov 2010 17:48:28 -0000 Keith, Be very careful with this sort of approach. The trend is towards fewer SIP-= PBXs and fewer "SIP trunks" serving an enterprise, with often a single SIP-= PBX and a single entry into the SIP Service Provider for a whole country or= even multiple countries. Even for the single country case, the service pro= vider network is unlikely to have a clue as to where, in the country, the c= aller might be located (or even where the PBX is located if there are two g= eographically separate servers). Caller ID isn't likely to help either, sin= ce users can move around within the enterprise network. John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) > Sent: 01 November 2010 23:04 > To: hannu.hietalahti@nokia.com; rbarnes@bbn.com; jmpolk@cisco.com > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Location Conveyance -04 submitted,=20 > here's the changes >=20 > If in 3GPP we look at subscription based business trunking=20 > arrangement. >=20 > The end terminal includes one location. >=20 > The enterprise network supporting the UE adds its own view of=20 > where the UE is. >=20 > The public network adds its own view of the location. >=20 > That makes three. >=20 > regards >=20 > Keith=20 >=20 > > -----Original Message----- > > From: hannu.hietalahti@nokia.com=20 > [mailto:hannu.hietalahti@nokia.com]=20 > > Sent: Monday, November 01, 2010 11:46 AM > > To: DRAGE, Keith (Keith); rbarnes@bbn.com; jmpolk@cisco.com > > Cc: sipcore@ietf.org > > Subject: RE: [sipcore] Location Conveyance -04 submitted,=20 > > here's the changes > >=20 > > Hi Keith, > >=20 > > yes, I remember you made this comment at Maastricht already,=20 > > and I agree with you that from 3GPP viewpoint we need=20 > > encoding that allows *more than one* piece of location information. > >=20 > > In 3GPP case those would be typically the one obtained from=20 > > the terminal and the one added by the serving network if it=20 > > thinks it knows better.=20 > >=20 > > But my imagination runs out after these two. Are you saying=20 > > we need more than 2? > >=20 > > BR, > > Hannu Hietalahti > > 3GPP TSG CT Chairman > > tel: +358 40 5021724 > > =20 > >=20 > > >-----Original Message----- > > >From: sipcore-bounces@ietf.org > > >[mailto:sipcore-bounces@ietf.org] On Behalf Of ext DRAGE,=20 > > Keith (Keith) > > >Sent: 28 October, 2010 16:01 > > >To: Richard L. Barnes; James M. Polk > > >Cc: sipcore@ietf.org > > >Subject: Re: [sipcore] Location Conveyance -04 submitted,=20 > here's the=20 > > >changes > > > > > >To be more specific - we had a document that allowed multiple=20 > > >locations. It was reduced to one without any decision in=20 > > that direction=20 > > >being made by the working group. It needs to go back to multiple=20 > > >values. > > > > > >In my view there are clear use cases where multiple values are=20 > > >required. > > > > > >regards > > > > > >Keith > > > > > >> -----Original Message----- > > >> From: sipcore-bounces@ietf.org > > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Richard L. Barnes > > >> Sent: Thursday, October 28, 2010 1:19 PM > > >> To: James M. Polk > > >> Cc: sipcore@ietf.org > > >> Subject: Re: [sipcore] Location Conveyance -04 submitted,=20 > > here's the=20 > > >> changes > > >>=20 > > >> >> I'm pretty comfortable with the document at this point, > > >> but have just > > >> >> one minor question: Why are you still limiting the number > > >> of location > > >> >> values? Why are three values harmful, but not two? This > > >> still seems > > >> >> like pointless ABNF legislation. > > >> > > > >> > we only added the ability to have a second locationValue > > >because of > > >> > your rough-loc ID. Before that, we were firm in not > > >> allowing more than > > >> > one. Given that choice, which do you like? > > >> > > > >> > Remember, this was Jon's proposal in SIPCORE in Anaheim,=20 > > which it=20 > > >> > seemed everyone and their brother was agreeable with, so ... > > >>=20 > > >>=20 > > >> As I recall, the proposal was to just remove the limit on > > >the number > > >> of locations values, not to bump it up by one. From the minutes: > > >>=20 > > >> "Restore Geolocation header that has multiple URIs, even=20 > though we=20 > > >> would not recommend it. Entities inserting persence are=20 > > responsbile=20 > > >> for any resulting errors. The header parameters=20 > > distinguishing URIs=20 > > >> would not be added back in." > > >>=20 > > >> At least in my mind, multiple !=3D 2. > > >>=20 > > >> --Richard > > >>=20 > > >>=20 > > >>=20 > > >>=20 > > >>=20 > > >>=20 > > >>=20 > > >> > james > > >> > > > >> > > > >> >> --Richard > > >> >> > > >> >> > > >> >> > > >> >> > > >> >> On Oct 27, 2010, at 12:32 AM, James M. Polk wrote: > > >> >> > > >> >>> SIPCORE > > >> >>> > > >> >>> I've submitted the next version of Location Conveyance (-04) > > >> >>>=20 > > >> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio > > >> n-conveyance-04.txt > > >> >>> and I believe this version has addressed each open=20 > > item from the=20 > > >> >>> mailing list, as well as what was discussed and agreed=20 > > to in the=20 > > >> >>> Maastricht meeting. > > >> >>> > > >> >>> I have attempted to identify each open issue with=20 > the specific=20 > > >> >>> resolution here (in no particular order): > > >> >>> > > >> >>> - Martin wanted Section 3 to be broken up into=20 > > subsections, each=20 > > >> >>> revolving around each of the 4 diagrams. I have done this. > > >> >>> > > >> >>> - allowed a maximum of two (up from one)=20 > locationValues to be=20 > > >> >>> present in the Geolocation header value. The text however > > >> recommends > > >> >>> against inserting a second value. This was agreed to in > > >> Maastricht. > > >> >>> > > >> >>> - Because we're allowing a max of two locationValues, > > >> they can be in > > >> >>> separate Geolocation headers in the SIP request.=20 > This scenario=20 > > >> >>> necessitates bring a previous version's paragraph in > > >> stating that a > > >> >>> 'SIP intermediary MUST inspect all instances of each=20 > > Geolocation=20 > > >> >>> header before considering the routing-allowed=20 > parameter to be=20 > > >> >>> considered =3Dyes', to ensure there isn't a conflict in=20 > > the 'other' > > >> >>> Geolocation header that states the policy is =3Dno. > > >> >>> > > >> >>> - with the ability to add a second locationValue, it is > > >> necessary to > > >> >>> warn against doing this (confusion at the LRs). > > >> >>> > > >> >>> - Added the "you break it you bought it" philosophy to SIP=20 > > >> >>> intermediaries that choose to insert a second location=20 > > where one=20 > > >> >>> already existed, especially for inserting a location=20 > > URI in the=20 > > >> >>> downstream SIP request. > > >> >>> > > >> >>> - Fixed the ABNF to handle zero, one or two (but no more)=20 > > >> >>> locationValues according to the agreement in Maastricht. > > >> There is a > > >> >>> one-off use case which won't be in play very often, but > > >> is a WG item > > >> >>> in ECRIT that several wanted to allow the possibility for > > >> (involving > > >> >>> allowing one coarse and one highly accurate location in > > >> the same SIP > > >> >>> request). > > >> >>> > > >> >>> - Paul K. wanted the use-case in which a SIP intermediary > > >> inserts a > > >> >>> locationValue where one didn't exist previously, and > > >> received a 424 > > >> >>> (Bad Location Information) to that inserted location,=20 > > from having=20 > > >> >>> the 424 propagate towards the UAC (as the UAC might not > > >> know what to > > >> >>> do with a 424). This is now covered in Section 4.3. > > >> >>> > > >> >>> - changed existing text to "MUST NOT" from "does not"=20 > > about a 424=20 > > >> >>> not terminating an existing dialog (just increased the > > >strength of > > >> >>> this. > > >> >>> > > >> >>> - I added the 424 to the table 2 entry in which the=20 > > Geolocation=20 > > >> >>> header can be in only this response. > > >> >>> > > >> >>> - I added text stating the conditions for adding a=20 > Geolocation=20 > > >> >>> header value to the 424, to make it clear what is and=20 > > what isn't=20 > > >> >>> allowed for this. > > >> >>> > > >> >>> - Martin wanted me to add back in the top level=20 > > Geolocation-Error=20 > > >> >>> codes 100, 200, 300 and 400, which I did in section 4.3. > > >> >>> > > >> >>> - rejected the idea that the geolocation option-tag=20 > > hasn't been=20 > > >> >>> justified. > > >> >>> > > >> >>> - Added RFCs 2616, 2818 and HELD Deref ID to the > > >> references section > > >> >>> because I added the ability to include HTTP: and=20 > > HTTPS: URIs, and=20 > > >> >>> stated if received, they should be dereferenced=20 > > according to the=20 > > >> >>> HELD Deref doc. > > >> >>> > > >> >>> - changed the Section 5 examples how Martin wanted them. > > >> >>> > > >> >>> - Stated that GEO-URIs are not appropriate for the SIP > > >Geolocation > > >> >>> header, according to the discussion during the=20 > > Maastricht Geopriv=20 > > >> >>> meeting. > > >> >>> > > >> >>> - we changed the privacy section, and included a ref to > > >> the Geopriv > > >> >>> Arch doc, according to the agreement in Geopriv at=20 > Maastricht. > > >> >>> > > >> >>> > > >> >>> Comments are encouraged > > >> >>> > > >> >>> We plan to request (3rd?) WGLC during the SIPCORE meeting > > >> in Beijing > > >> >>> (to give folks a sense of our plans). > > >> >>> > > >> >>> James/Brian/Jon > > >> >>> > > >> >>> > > >> >>> _______________________________________________ > > >> >>> 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 > > >>=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 > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From pkyzivat@cisco.com Thu Nov 4 11:00:21 2010 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 CD7463A6A1E for ; Thu, 4 Nov 2010 11:00:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 kx3cdhBbnADV for ; Thu, 4 Nov 2010 11:00:21 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id F02AC3A69C2 for ; Thu, 4 Nov 2010 11:00:20 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEOR0kxAZnwM/2dsb2JhbAChfHGiZZtDgnGCVQSKVYMI X-IronPort-AV: E=Sophos;i="4.58,297,1286150400"; d="scan'208";a="178660706" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 04 Nov 2010 18:00:31 +0000 Received: from [10.86.249.187] (bxb-vpn3-443.cisco.com [10.86.249.187]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA4I0U51012904 for ; Thu, 4 Nov 2010 18:00:31 GMT Message-ID: <4CD2F4BE.6080906@cisco.com> Date: Thu, 04 Nov 2010 14:00:30 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sipcore] draft-mohali-sipcore-reason-extension-application-00 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: Thu, 04 Nov 2010 18:00:21 -0000 [as individual] I took another look at this draft, and have a few observations/comments: Its claimed that in cases where retargeting is due to a 3xx response, then the reason is 3xx, while in the cases of interest in this draft the reason is one of the new application reason codes. But these are not mutually exclusive cases. All of the "application" cases called out could be implemented by sending the request to an application server that then returns a 3xx response with the value. If so, anything downstream that wishes to identify the reason would presumably want the application reason, which would perhaps have been lost in this process. ISTM that to resolve that, the redirect server would affix the reason header with the application code to the contact in the 3xx. Then, the proxy that recurses on the 3xx would place contact with the embedded reason header into the H-I, and would also place the reason header into the new outgoing request. A net effect of this is that the Reason header would be in the *new* URI in H-I, not in the *old* URI as is shown. To me that also makes more sense - its the reason this URI is present. Bottom line - this should all make sense even without the use of H-I. Then H-I usage can also be folded into the examples to give an even more complete picture of what happened. I also must say that I find the proposed cause text to be at best awkward. I'm not a grammarian, but ISTM that these terms are using the wrong part of speech - they don't sound like *causes*. And for that matter some of them don't sound like they are even related to retargeting. E.g. premium rate, vpn. I would expect that "The call was retargeted to number because " would make sense for each of these. Thanks, Paul From keith.drage@alcatel-lucent.com Thu Nov 4 21:36:44 2010 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 A87DE3A63C9 for ; Thu, 4 Nov 2010 21:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.963 X-Spam-Level: X-Spam-Status: No, score=-105.963 tagged_above=-999 required=5 tests=[AWL=0.286, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4, 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 hR-CRSJkgUmA for ; Thu, 4 Nov 2010 21:36:43 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id B55703A657C for ; Thu, 4 Nov 2010 21:36:41 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oA54ahsZ021503 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 5 Nov 2010 05:36:44 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Fri, 5 Nov 2010 05:36:43 +0100 From: "DRAGE, Keith (Keith)" To: "Elwell, John" , "hannu.hietalahti@nokia.com" , "rbarnes@bbn.com" , "jmpolk@cisco.com" Date: Fri, 5 Nov 2010 05:36:41 +0100 Thread-Topic: [sipcore] Location Conveyance -04 submitted, here's the changes Thread-Index: Act2mlVdTb0CvQzFTY2pDhKiRuhu2gAAtZtwAMcwGpAAFNySEACOdTlgABbnWwA= Message-ID: References: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com> <625A3E65-E441-4340-A5E2-B847F8B964CF@bbn.com> <201010271838.o9RIcjgG008761@sj-core-5.cisco.com> <63EEFC46-26FC-4A69-B1A7-2CC79583B8B2@bbn.com> <5BAF85033CB5F3439C4DE153165522B1109FDD491C@NOK-EUMSG-06.mgdnok.nokia.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-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes 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: Fri, 05 Nov 2010 04:36:44 -0000 Exactly, that is why I am saying you need multiples. Otherwise the scenario is that the PBX puts one in, and the public network = then replaces it because it says the regulator tells the network to always = provide a location. At least with my approach, all the locations are there,= and the PSAP then sorts it out. Keith > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Thursday, November 04, 2010 5:48 PM > To: DRAGE, Keith (Keith); hannu.hietalahti@nokia.com;=20 > rbarnes@bbn.com; jmpolk@cisco.com > Cc: sipcore@ietf.org > Subject: RE: [sipcore] Location Conveyance -04 submitted,=20 > here's the changes >=20 > Keith, >=20 > Be very careful with this sort of approach. The trend is=20 > towards fewer SIP-PBXs and fewer "SIP trunks" serving an=20 > enterprise, with often a single SIP-PBX and a single entry=20 > into the SIP Service Provider for a whole country or even=20 > multiple countries. Even for the single country case, the=20 > service provider network is unlikely to have a clue as to=20 > where, in the country, the caller might be located (or even=20 > where the PBX is located if there are two geographically=20 > separate servers). Caller ID isn't likely to help either,=20 > since users can move around within the enterprise network. >=20 > John >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE, Keith (Keith) > > Sent: 01 November 2010 23:04 > > To: hannu.hietalahti@nokia.com; rbarnes@bbn.com; jmpolk@cisco.com > > Cc: sipcore@ietf.org > > Subject: Re: [sipcore] Location Conveyance -04 submitted,=20 > here's the=20 > > changes > >=20 > > If in 3GPP we look at subscription based business trunking=20 > > arrangement. > >=20 > > The end terminal includes one location. > >=20 > > The enterprise network supporting the UE adds its own view of where=20 > > the UE is. > >=20 > > The public network adds its own view of the location. > >=20 > > That makes three. > >=20 > > regards > >=20 > > Keith > >=20 > > > -----Original Message----- > > > From: hannu.hietalahti@nokia.com > > [mailto:hannu.hietalahti@nokia.com] > > > Sent: Monday, November 01, 2010 11:46 AM > > > To: DRAGE, Keith (Keith); rbarnes@bbn.com; jmpolk@cisco.com > > > Cc: sipcore@ietf.org > > > Subject: RE: [sipcore] Location Conveyance -04 submitted,=20 > here's the=20 > > > changes > > >=20 > > > Hi Keith, > > >=20 > > > yes, I remember you made this comment at Maastricht=20 > already, and I=20 > > > agree with you that from 3GPP viewpoint we need encoding=20 > that allows=20 > > > *more than one* piece of location information. > > >=20 > > > In 3GPP case those would be typically the one obtained from the=20 > > > terminal and the one added by the serving network if it thinks it=20 > > > knows better. > > >=20 > > > But my imagination runs out after these two. Are you=20 > saying we need=20 > > > more than 2? > > >=20 > > > BR, > > > Hannu Hietalahti > > > 3GPP TSG CT Chairman > > > tel: +358 40 5021724 > > > =20 > > >=20 > > > >-----Original Message----- > > > >From: sipcore-bounces@ietf.org > > > >[mailto:sipcore-bounces@ietf.org] On Behalf Of ext DRAGE, > > > Keith (Keith) > > > >Sent: 28 October, 2010 16:01 > > > >To: Richard L. Barnes; James M. Polk > > > >Cc: sipcore@ietf.org > > > >Subject: Re: [sipcore] Location Conveyance -04 submitted, > > here's the > > > >changes > > > > > > > >To be more specific - we had a document that allowed multiple=20 > > > >locations. It was reduced to one without any decision in > > > that direction > > > >being made by the working group. It needs to go back to multiple=20 > > > >values. > > > > > > > >In my view there are clear use cases where multiple values are=20 > > > >required. > > > > > > > >regards > > > > > > > >Keith > > > > > > > >> -----Original Message----- > > > >> From: sipcore-bounces@ietf.org > > > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Richard=20 > L. Barnes > > > >> Sent: Thursday, October 28, 2010 1:19 PM > > > >> To: James M. Polk > > > >> Cc: sipcore@ietf.org > > > >> Subject: Re: [sipcore] Location Conveyance -04 submitted, > > > here's the > > > >> changes > > > >>=20 > > > >> >> I'm pretty comfortable with the document at this point, > > > >> but have just > > > >> >> one minor question: Why are you still limiting the number > > > >> of location > > > >> >> values? Why are three values harmful, but not two? This > > > >> still seems > > > >> >> like pointless ABNF legislation. > > > >> > > > > >> > we only added the ability to have a second locationValue > > > >because of > > > >> > your rough-loc ID. Before that, we were firm in not > > > >> allowing more than > > > >> > one. Given that choice, which do you like? > > > >> > > > > >> > Remember, this was Jon's proposal in SIPCORE in Anaheim, > > > which it > > > >> > seemed everyone and their brother was agreeable with, so ... > > > >>=20 > > > >>=20 > > > >> As I recall, the proposal was to just remove the limit on > > > >the number > > > >> of locations values, not to bump it up by one. From=20 > the minutes: > > > >>=20 > > > >> "Restore Geolocation header that has multiple URIs, even > > though we > > > >> would not recommend it. Entities inserting persence are > > > responsbile > > > >> for any resulting errors. The header parameters > > > distinguishing URIs > > > >> would not be added back in." > > > >>=20 > > > >> At least in my mind, multiple !=3D 2. > > > >>=20 > > > >> --Richard > > > >>=20 > > > >>=20 > > > >>=20 > > > >>=20 > > > >>=20 > > > >>=20 > > > >>=20 > > > >> > james > > > >> > > > > >> > > > > >> >> --Richard > > > >> >> > > > >> >> > > > >> >> > > > >> >> > > > >> >> On Oct 27, 2010, at 12:32 AM, James M. Polk wrote: > > > >> >> > > > >> >>> SIPCORE > > > >> >>> > > > >> >>> I've submitted the next version of Location=20 > Conveyance (-04) > > > >> >>>=20 > > > >> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio > > > >> n-conveyance-04.txt > > > >> >>> and I believe this version has addressed each open > > > item from the > > > >> >>> mailing list, as well as what was discussed and agreed > > > to in the > > > >> >>> Maastricht meeting. > > > >> >>> > > > >> >>> I have attempted to identify each open issue with > > the specific > > > >> >>> resolution here (in no particular order): > > > >> >>> > > > >> >>> - Martin wanted Section 3 to be broken up into > > > subsections, each > > > >> >>> revolving around each of the 4 diagrams. I have done this. > > > >> >>> > > > >> >>> - allowed a maximum of two (up from one) > > locationValues to be > > > >> >>> present in the Geolocation header value. The text however > > > >> recommends > > > >> >>> against inserting a second value. This was agreed to in > > > >> Maastricht. > > > >> >>> > > > >> >>> - Because we're allowing a max of two locationValues, > > > >> they can be in > > > >> >>> separate Geolocation headers in the SIP request.=20 > > This scenario > > > >> >>> necessitates bring a previous version's paragraph in > > > >> stating that a > > > >> >>> 'SIP intermediary MUST inspect all instances of each > > > Geolocation > > > >> >>> header before considering the routing-allowed > > parameter to be > > > >> >>> considered =3Dyes', to ensure there isn't a conflict in > > > the 'other' > > > >> >>> Geolocation header that states the policy is =3Dno. > > > >> >>> > > > >> >>> - with the ability to add a second locationValue, it is > > > >> necessary to > > > >> >>> warn against doing this (confusion at the LRs). > > > >> >>> > > > >> >>> - Added the "you break it you bought it" philosophy to SIP=20 > > > >> >>> intermediaries that choose to insert a second location > > > where one > > > >> >>> already existed, especially for inserting a location > > > URI in the > > > >> >>> downstream SIP request. > > > >> >>> > > > >> >>> - Fixed the ABNF to handle zero, one or two (but no more)=20 > > > >> >>> locationValues according to the agreement in Maastricht. > > > >> There is a > > > >> >>> one-off use case which won't be in play very often, but > > > >> is a WG item > > > >> >>> in ECRIT that several wanted to allow the possibility for > > > >> (involving > > > >> >>> allowing one coarse and one highly accurate location in > > > >> the same SIP > > > >> >>> request). > > > >> >>> > > > >> >>> - Paul K. wanted the use-case in which a SIP intermediary > > > >> inserts a > > > >> >>> locationValue where one didn't exist previously, and > > > >> received a 424 > > > >> >>> (Bad Location Information) to that inserted location, > > > from having > > > >> >>> the 424 propagate towards the UAC (as the UAC might not > > > >> know what to > > > >> >>> do with a 424). This is now covered in Section 4.3. > > > >> >>> > > > >> >>> - changed existing text to "MUST NOT" from "does not"=20 > > > about a 424 > > > >> >>> not terminating an existing dialog (just increased the > > > >strength of > > > >> >>> this. > > > >> >>> > > > >> >>> - I added the 424 to the table 2 entry in which the > > > Geolocation > > > >> >>> header can be in only this response. > > > >> >>> > > > >> >>> - I added text stating the conditions for adding a > > Geolocation > > > >> >>> header value to the 424, to make it clear what is and > > > what isn't > > > >> >>> allowed for this. > > > >> >>> > > > >> >>> - Martin wanted me to add back in the top level > > > Geolocation-Error > > > >> >>> codes 100, 200, 300 and 400, which I did in section 4.3. > > > >> >>> > > > >> >>> - rejected the idea that the geolocation option-tag > > > hasn't been > > > >> >>> justified. > > > >> >>> > > > >> >>> - Added RFCs 2616, 2818 and HELD Deref ID to the > > > >> references section > > > >> >>> because I added the ability to include HTTP: and > > > HTTPS: URIs, and > > > >> >>> stated if received, they should be dereferenced > > > according to the > > > >> >>> HELD Deref doc. > > > >> >>> > > > >> >>> - changed the Section 5 examples how Martin wanted them. > > > >> >>> > > > >> >>> - Stated that GEO-URIs are not appropriate for the SIP > > > >Geolocation > > > >> >>> header, according to the discussion during the > > > Maastricht Geopriv > > > >> >>> meeting. > > > >> >>> > > > >> >>> - we changed the privacy section, and included a ref to > > > >> the Geopriv > > > >> >>> Arch doc, according to the agreement in Geopriv at > > Maastricht. > > > >> >>> > > > >> >>> > > > >> >>> Comments are encouraged > > > >> >>> > > > >> >>> We plan to request (3rd?) WGLC during the SIPCORE meeting > > > >> in Beijing > > > >> >>> (to give folks a sense of our plans). > > > >> >>> > > > >> >>> James/Brian/Jon > > > >> >>> > > > >> >>> > > > >> >>> _______________________________________________ > > > >> >>> 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 > > > >>=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 > > > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > = From john.elwell@siemens-enterprise.com Fri Nov 5 01:57:10 2010 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 918CD3A657C for ; Fri, 5 Nov 2010 01:57:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.442 X-Spam-Level: X-Spam-Status: No, score=-102.442 tagged_above=-999 required=5 tests=[AWL=0.157, BAYES_00=-2.599, 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 tNh7pC3gbmlK for ; Fri, 5 Nov 2010 01:57:09 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 5D25C3A6452 for ; Fri, 5 Nov 2010 01:57:08 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2184677; Fri, 5 Nov 2010 08:22:50 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 37E6F1EB82AB; Fri, 5 Nov 2010 08:22:50 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 5 Nov 2010 08:22:50 +0100 From: "Elwell, John" To: "DRAGE, Keith (Keith)" , "hannu.hietalahti@nokia.com" , "rbarnes@bbn.com" , "jmpolk@cisco.com" Date: Fri, 5 Nov 2010 08:22:48 +0100 Thread-Topic: [sipcore] Location Conveyance -04 submitted, here's the changes Thread-Index: Act2mlVdTb0CvQzFTY2pDhKiRuhu2gAAtZtwAMcwGpAAFNySEACOdTlgABbnWwAABXISYA== Message-ID: References: <201010270432.o9R4WLe8013111@sj-core-5.cisco.com> <625A3E65-E441-4340-A5E2-B847F8B964CF@bbn.com> <201010271838.o9RIcjgG008761@sj-core-5.cisco.com> <63EEFC46-26FC-4A69-B1A7-2CC79583B8B2@bbn.com> <5BAF85033CB5F3439C4DE153165522B1109FDD491C@NOK-EUMSG-06.mgdnok.nokia.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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes 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: Fri, 05 Nov 2010 08:57:10 -0000 Yes, I agree that replacing an enterprise-provided location is very bad. Th= e problem with adding locations to locations already present is how the PSA= P chooses between 2 or even 3 locations. From my reading of the draft, we d= on't have any normative statement on the order in which locations are place= d in the header. If we had a rule that the first locationValue within a sin= gle or multiple Geolocation header fields is nearest to the source of the r= equest, and so on, it might help. Then it would be clear that the service p= rovider-provided location would be the least reliable, but it would still b= e there, e.g., for use if the other locations are bogus. John > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]=20 > Sent: 05 November 2010 04:37 > To: Elwell, John; hannu.hietalahti@nokia.com;=20 > rbarnes@bbn.com; jmpolk@cisco.com > Cc: sipcore@ietf.org > Subject: RE: [sipcore] Location Conveyance -04 submitted,=20 > here's the changes >=20 > Exactly, that is why I am saying you need multiples. >=20 > Otherwise the scenario is that the PBX puts one in, and the=20 > public network then replaces it because it says the regulator=20 > tells the network to always provide a location. At least with=20 > my approach, all the locations are there, and the PSAP then=20 > sorts it out. >=20 > Keith >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > > Sent: Thursday, November 04, 2010 5:48 PM > > To: DRAGE, Keith (Keith); hannu.hietalahti@nokia.com;=20 > > rbarnes@bbn.com; jmpolk@cisco.com > > Cc: sipcore@ietf.org > > Subject: RE: [sipcore] Location Conveyance -04 submitted,=20 > > here's the changes > >=20 > > Keith, > >=20 > > Be very careful with this sort of approach. The trend is=20 > > towards fewer SIP-PBXs and fewer "SIP trunks" serving an=20 > > enterprise, with often a single SIP-PBX and a single entry=20 > > into the SIP Service Provider for a whole country or even=20 > > multiple countries. Even for the single country case, the=20 > > service provider network is unlikely to have a clue as to=20 > > where, in the country, the caller might be located (or even=20 > > where the PBX is located if there are two geographically=20 > > separate servers). Caller ID isn't likely to help either,=20 > > since users can move around within the enterprise network. > >=20 > > John > >=20 > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE,=20 > Keith (Keith) > > > Sent: 01 November 2010 23:04 > > > To: hannu.hietalahti@nokia.com; rbarnes@bbn.com; jmpolk@cisco.com > > > Cc: sipcore@ietf.org > > > Subject: Re: [sipcore] Location Conveyance -04 submitted,=20 > > here's the=20 > > > changes > > >=20 > > > If in 3GPP we look at subscription based business trunking=20 > > > arrangement. > > >=20 > > > The end terminal includes one location. > > >=20 > > > The enterprise network supporting the UE adds its own=20 > view of where=20 > > > the UE is. > > >=20 > > > The public network adds its own view of the location. > > >=20 > > > That makes three. > > >=20 > > > regards > > >=20 > > > Keith > > >=20 > > > > -----Original Message----- > > > > From: hannu.hietalahti@nokia.com > > > [mailto:hannu.hietalahti@nokia.com] > > > > Sent: Monday, November 01, 2010 11:46 AM > > > > To: DRAGE, Keith (Keith); rbarnes@bbn.com; jmpolk@cisco.com > > > > Cc: sipcore@ietf.org > > > > Subject: RE: [sipcore] Location Conveyance -04 submitted,=20 > > here's the=20 > > > > changes > > > >=20 > > > > Hi Keith, > > > >=20 > > > > yes, I remember you made this comment at Maastricht=20 > > already, and I=20 > > > > agree with you that from 3GPP viewpoint we need encoding=20 > > that allows=20 > > > > *more than one* piece of location information. > > > >=20 > > > > In 3GPP case those would be typically the one obtained from the=20 > > > > terminal and the one added by the serving network if it=20 > thinks it=20 > > > > knows better. > > > >=20 > > > > But my imagination runs out after these two. Are you=20 > > saying we need=20 > > > > more than 2? > > > >=20 > > > > BR, > > > > Hannu Hietalahti > > > > 3GPP TSG CT Chairman > > > > tel: +358 40 5021724 > > > > =20 > > > >=20 > > > > >-----Original Message----- > > > > >From: sipcore-bounces@ietf.org > > > > >[mailto:sipcore-bounces@ietf.org] On Behalf Of ext DRAGE, > > > > Keith (Keith) > > > > >Sent: 28 October, 2010 16:01 > > > > >To: Richard L. Barnes; James M. Polk > > > > >Cc: sipcore@ietf.org > > > > >Subject: Re: [sipcore] Location Conveyance -04 submitted, > > > here's the > > > > >changes > > > > > > > > > >To be more specific - we had a document that allowed multiple=20 > > > > >locations. It was reduced to one without any decision in > > > > that direction > > > > >being made by the working group. It needs to go back=20 > to multiple=20 > > > > >values. > > > > > > > > > >In my view there are clear use cases where multiple values are=20 > > > > >required. > > > > > > > > > >regards > > > > > > > > > >Keith > > > > > > > > > >> -----Original Message----- > > > > >> From: sipcore-bounces@ietf.org > > > > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Richard=20 > > L. Barnes > > > > >> Sent: Thursday, October 28, 2010 1:19 PM > > > > >> To: James M. Polk > > > > >> Cc: sipcore@ietf.org > > > > >> Subject: Re: [sipcore] Location Conveyance -04 submitted, > > > > here's the > > > > >> changes > > > > >>=20 > > > > >> >> I'm pretty comfortable with the document at this point, > > > > >> but have just > > > > >> >> one minor question: Why are you still limiting the number > > > > >> of location > > > > >> >> values? Why are three values harmful, but not two? This > > > > >> still seems > > > > >> >> like pointless ABNF legislation. > > > > >> > > > > > >> > we only added the ability to have a second locationValue > > > > >because of > > > > >> > your rough-loc ID. Before that, we were firm in not > > > > >> allowing more than > > > > >> > one. Given that choice, which do you like? > > > > >> > > > > > >> > Remember, this was Jon's proposal in SIPCORE in Anaheim, > > > > which it > > > > >> > seemed everyone and their brother was agreeable=20 > with, so ... > > > > >>=20 > > > > >>=20 > > > > >> As I recall, the proposal was to just remove the limit on > > > > >the number > > > > >> of locations values, not to bump it up by one. From=20 > > the minutes: > > > > >>=20 > > > > >> "Restore Geolocation header that has multiple URIs, even > > > though we > > > > >> would not recommend it. Entities inserting persence are > > > > responsbile > > > > >> for any resulting errors. The header parameters > > > > distinguishing URIs > > > > >> would not be added back in." > > > > >>=20 > > > > >> At least in my mind, multiple !=3D 2. > > > > >>=20 > > > > >> --Richard > > > > >>=20 > > > > >>=20 > > > > >>=20 > > > > >>=20 > > > > >>=20 > > > > >>=20 > > > > >>=20 > > > > >> > james > > > > >> > > > > > >> > > > > > >> >> --Richard > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> On Oct 27, 2010, at 12:32 AM, James M. Polk wrote: > > > > >> >> > > > > >> >>> SIPCORE > > > > >> >>> > > > > >> >>> I've submitted the next version of Location=20 > > Conveyance (-04) > > > > >> >>>=20 > > > > >>=20 > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio > > > > >> n-conveyance-04.txt > > > > >> >>> and I believe this version has addressed each open > > > > item from the > > > > >> >>> mailing list, as well as what was discussed and agreed > > > > to in the > > > > >> >>> Maastricht meeting. > > > > >> >>> > > > > >> >>> I have attempted to identify each open issue with > > > the specific > > > > >> >>> resolution here (in no particular order): > > > > >> >>> > > > > >> >>> - Martin wanted Section 3 to be broken up into > > > > subsections, each > > > > >> >>> revolving around each of the 4 diagrams. I have=20 > done this. > > > > >> >>> > > > > >> >>> - allowed a maximum of two (up from one) > > > locationValues to be > > > > >> >>> present in the Geolocation header value. The text however > > > > >> recommends > > > > >> >>> against inserting a second value. This was agreed to in > > > > >> Maastricht. > > > > >> >>> > > > > >> >>> - Because we're allowing a max of two locationValues, > > > > >> they can be in > > > > >> >>> separate Geolocation headers in the SIP request.=20 > > > This scenario > > > > >> >>> necessitates bring a previous version's paragraph in > > > > >> stating that a > > > > >> >>> 'SIP intermediary MUST inspect all instances of each > > > > Geolocation > > > > >> >>> header before considering the routing-allowed > > > parameter to be > > > > >> >>> considered =3Dyes', to ensure there isn't a conflict in > > > > the 'other' > > > > >> >>> Geolocation header that states the policy is =3Dno. > > > > >> >>> > > > > >> >>> - with the ability to add a second locationValue, it is > > > > >> necessary to > > > > >> >>> warn against doing this (confusion at the LRs). > > > > >> >>> > > > > >> >>> - Added the "you break it you bought it"=20 > philosophy to SIP=20 > > > > >> >>> intermediaries that choose to insert a second location > > > > where one > > > > >> >>> already existed, especially for inserting a location > > > > URI in the > > > > >> >>> downstream SIP request. > > > > >> >>> > > > > >> >>> - Fixed the ABNF to handle zero, one or two (but=20 > no more)=20 > > > > >> >>> locationValues according to the agreement in Maastricht. > > > > >> There is a > > > > >> >>> one-off use case which won't be in play very often, but > > > > >> is a WG item > > > > >> >>> in ECRIT that several wanted to allow the possibility for > > > > >> (involving > > > > >> >>> allowing one coarse and one highly accurate location in > > > > >> the same SIP > > > > >> >>> request). > > > > >> >>> > > > > >> >>> - Paul K. wanted the use-case in which a SIP intermediary > > > > >> inserts a > > > > >> >>> locationValue where one didn't exist previously, and > > > > >> received a 424 > > > > >> >>> (Bad Location Information) to that inserted location, > > > > from having > > > > >> >>> the 424 propagate towards the UAC (as the UAC might not > > > > >> know what to > > > > >> >>> do with a 424). This is now covered in Section 4.3. > > > > >> >>> > > > > >> >>> - changed existing text to "MUST NOT" from "does not"=20 > > > > about a 424 > > > > >> >>> not terminating an existing dialog (just increased the > > > > >strength of > > > > >> >>> this. > > > > >> >>> > > > > >> >>> - I added the 424 to the table 2 entry in which the > > > > Geolocation > > > > >> >>> header can be in only this response. > > > > >> >>> > > > > >> >>> - I added text stating the conditions for adding a > > > Geolocation > > > > >> >>> header value to the 424, to make it clear what is and > > > > what isn't > > > > >> >>> allowed for this. > > > > >> >>> > > > > >> >>> - Martin wanted me to add back in the top level > > > > Geolocation-Error > > > > >> >>> codes 100, 200, 300 and 400, which I did in section 4.3. > > > > >> >>> > > > > >> >>> - rejected the idea that the geolocation option-tag > > > > hasn't been > > > > >> >>> justified. > > > > >> >>> > > > > >> >>> - Added RFCs 2616, 2818 and HELD Deref ID to the > > > > >> references section > > > > >> >>> because I added the ability to include HTTP: and > > > > HTTPS: URIs, and > > > > >> >>> stated if received, they should be dereferenced > > > > according to the > > > > >> >>> HELD Deref doc. > > > > >> >>> > > > > >> >>> - changed the Section 5 examples how Martin wanted them. > > > > >> >>> > > > > >> >>> - Stated that GEO-URIs are not appropriate for the SIP > > > > >Geolocation > > > > >> >>> header, according to the discussion during the > > > > Maastricht Geopriv > > > > >> >>> meeting. > > > > >> >>> > > > > >> >>> - we changed the privacy section, and included a ref to > > > > >> the Geopriv > > > > >> >>> Arch doc, according to the agreement in Geopriv at > > > Maastricht. > > > > >> >>> > > > > >> >>> > > > > >> >>> Comments are encouraged > > > > >> >>> > > > > >> >>> We plan to request (3rd?) WGLC during the SIPCORE meeting > > > > >> in Beijing > > > > >> >>> (to give folks a sense of our plans). > > > > >> >>> > > > > >> >>> James/Brian/Jon > > > > >> >>> > > > > >> >>> > > > > >> >>> _______________________________________________ > > > > >> >>> 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 > > > > >>=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 > > > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > = From john.elwell@siemens-enterprise.com Fri Nov 5 02:01:36 2010 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 6D4833A6452 for ; Fri, 5 Nov 2010 02:01:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.449 X-Spam-Level: X-Spam-Status: No, score=-102.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, 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 D1NRgLgV5CTD for ; Fri, 5 Nov 2010 02:01:34 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 52B353A63EB for ; Fri, 5 Nov 2010 02:01:34 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2183785 for sipcore@ietf.org; Fri, 5 Nov 2010 09:26:02 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 20F6623F0278 for ; Fri, 5 Nov 2010 09:26:02 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 5 Nov 2010 09:26:02 +0100 From: "Elwell, John" To: "sipcore@ietf.org" Date: Fri, 5 Nov 2010 09:25:59 +0100 Thread-Topic: More comments on location-conveyance-04 Thread-Index: Act8wxOA6LCr6AG7RhuTO8Kg78vJ6A== Message-ID: 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 Subject: [sipcore] More comments on location-conveyance-04 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: Fri, 05 Nov 2010 09:01:36 -0000 1. General This document seems to lack procedures sections for a UAC, a proxy and a UA= S. Some of the procedures can be deduced from material in section 4 and els= ewhere, but it is normal, for any SIP extension, to specify procedures for = specific entities. 2. As I have recently said about rfc4244bis, we should use "header field" i= nstead of "header" where appropriate throughout the document. My reasoning = has already been stated on this list in the context of rfc4244bis. 3. As I have recently said about rfc4244bis, we should avoid using the pass= ive voice in normative statements. A normative statement forces us to make = it clear which entity is required to comply with the statement. I have not = picked out specific instances, but there are many. 4. Abstract: "where SIP=20 intermediaries make routing decisions based upon the location of the user agent client." I think "user agent client" should be changed to "target". 5. Section 1: "Location Objection" Sustained! Change it to "Location Object". 6. Section 2: "to deliver URIs point to " Change to: "to deliver URIs pointing to " 7. Section 3.2: "the LS provides the location value to Bob instead of Alice directly." I think it should say: "the LS provides the location value to Bob directly instead of to Alice for conveyance to Bob." 8. Section 3.3: "In this case, the intermediary acts as a Location=20 Recipient." This is effectively a repetition of the 3rd sentence in the paragraph - del= ete. 9. Section 3.3: "In this case, the intermediary does not act as a Location=20 Recipient." It might be worth pointing out that this case is identical to that in 3.1. 10. Section 3.4: "Thus,=20 it must inform her user agent what location she should include in=20 any subsequent SIP request that contains her location. " Change "she should include" to "it should include". 11. Section 3.4: "In these=20 cases, the intermediary can reject " Change "In these cases" to "In this case", because I think there is only on= e case described in the preceding text. 12. Section 3.4: "the intermediary can reject Alice's request, through the SIP=20 response, convey to her the best way to repair the request" Add "and" after "Alice's request" (before the comma). New text: "the intermediary can reject Alice's request and, through the SIP=20 response, convey to her the best way to repair the request" 13. Section 3.4: "If desired, intermediaries=20 may furthermore allow both Alice's internally generated location, as well as the SIP intermediary's determination of where Alice, to=20 appear in the same SIP request (the resubmitted one), and permit=20 that to be forwarded to Bob. This case is discussed in more detail=20 in section 4.2 of this document." If I understand correctly, this case is also covered in 3.3. There is no ne= ed to cover the same case in both sub-sections. Delete one of them. 14. Section 3.4: "act a B2BUA " Change to: "act as a B2BUA " 15. Section 4.1: I am aware of separate discussions ongoing concerning the ABNF, but dependi= ng on what we end up with, we should ensure that the following error is som= ehow fixed: "routing-param =3D "routing-allowed" EQUAL "yes" / "no"" This omits the semicolon in front of "routing-allowed". According to the ex= amples (which I think are correct) there should be a semicolon. 16. Section 4.1: "not appropriate for usage the SIP Geolocation header." Change to: "not appropriate for usage in the SIP Geolocation header." 17. Section 4.1: "Other URI schemas used in the location URI MUST be reviewed against=20 the RFC 3693 [RFC3693] criteria for a Using Protocol." Who must conduct this review? Use active voice. I assume we are talking about any scheme for use under absoluteURI, since t= here is no other extension mechanism. 18. Section 4.1: "However, if a SIP intermediary were to add location, even if=20 location was not previously present in a SIP request, that SIP=20 intermediary is fully responsible for addressing the concerns of any 424 (Bad Location Information) SIP response it receives about this=20 location addition, and MUST NOT pass on (upstream) the 424 response." How does the SIP intermediary know that the 424 refers to the added locatio= n, as opposed to the original location? If I understand correctly, a Geoloc= ation header field in a 424 response denotes a corrected location, rather t= han a location in error, so comparison of sent and received Geolocation hea= der fields would not work. 19. Section 4.1: "If a routing-allowed parameter is parsed as set to "=3Dyes", an=20 implementation MUST parse the rest of the SIP headers for another=20 instance of the Geolocation header value to determine if there is=20 another instance of the routing-allowed parameter set to "=3Dno". If=20 this is the case, the behavior MUST be to process the "=3Dno"=20 indication only, and ignore the "=3Dyes"." This is a rather unusual requirement, and may be obviated by proposed chang= es to the ABNF. If not, my concern is that SIP parsers do not necessarily l= ook out for conflicting bits of information, and might just make the first = or last instance available to the application. Also it seems a bit unnecess= ary to specify this, since it is forbidden to add a second routing-allowed = parameter, so if two occur it is an invalid message, and perhaps unreasonab= le to expect a defined behaviour. 20. Section 4.1: "The following table extends the values in Tables 2 and 3 of RFC 3261 [RFC3261]." I thought there was an agreement in the WG not to maintain tables 2 and 3 i= n RFC 3261. 21. Section 4.1: "The Geolocation header field MAY be included in any one of the=20 optional requests by a UA. " If we get rid of the table, in accordance with the previous comment, this s= hould say: "The Geolocation header field MAY be included in any request except ACK or = CANCEL and in any 424 responses to such requests." 22. Section 4.2: "All=20 respects of the Geolocation and Geolocation-Error headers and=20 PIDF-LO(s) MUST remain unchanged, never added to or deleted." This should say: "Geolocation and Geolocation-Error header fields and=20 PIDF-LO body parts MUST remain unchanged, never added to or deleted." 23. Section 4.2: "In this scenario, a SIP intermediary is informing the upstream UA which location to=20 include in the next SIP request. " Two scenarios are mentioned in the preceding text. Should say: "In the latter scenario..." 24. Section 4.3: "Geolocation-Error =3D "Geolocation-Error" HCOLON=20 locationErrorValue locationErrorValue =3D location-error-arg=20 location-error-arg =3D location-error-code=20 *(SEMI location-error-params)" The is an unnecessary intermediate step here. Why not: "Geolocation-Error =3D "Geolocation-Error" HCOLON=20 locationErrorValue locationErrorValue =3D location-error-code=20 *(SEMI location-error-params)" 25. Section 4.3: "The following table extends the values in Table 2&3 of RFC 3261 [RFC3261]." Same comment as for the previous table. The table could be deleted. This wo= uld require a small change to the sentence after the table:, e.g.: "The Geo= location-Error header field MAY be included in any response to a SIP reques= t containing a Geolocation header field locationValue." 26. Section 4.3: If the request contains more than one locationValue, can there be more than= one Geolocation-Error header field in the response, if more than one locat= ion is in error? However, my earlier comment about associating a Geolocatio= n-Error with a particular locationValue would still be an issue. 27. Section 4.3: "The SIP requests included in table 2 above are the ones allowed to optionally contain the Geolocation header field (see section 4.1)." Table 2 as it stands doesn't list any requests - only responses. However, i= f my earlier comment about removing the table is accepted, this sentence wo= uld need attention anyway. In fact it appears to be redundant - I don't thi= nk it conveys any new information. Delete it. 28. Section 4.3: "The following subsections provide an initial list of location=20 based errors for any SIP non-100 response" I don't see any subsections. 29. Section 4.3: "Geolocation-Error: 200 "Retry Location Later ..." Should this be accompanied by a Retry-After header field? Under what circum= stances might an LR determine that it can't use the present location but co= uld use an updated location sometime in the future? I fail to see the motiv= ation for this error code. 30. Section 4.3: "with device updated=20 location" I assume this means the device must update the location. But how does the L= R know that the location came from the device, as opposed to some other loc= ation generator? Suggest delete "device"? 31. Section 4.3: "If the LS wants this message=20 processed without this permission reset, it MUST choose another=20 logical path (if one exists)." (two instances) What is meant by "another logical path"? 32. Section 4.4: "This document creates and registers with the IANA one new option=20 tag: "geolocation". This option tag is to be used, as defined in =20 [RFC3261], in the Require, Supported and Unsupported header fields." There should be some statement about what the option tag means, i.e., suppo= rt for the SIP extensions specified in this document. However, I have a mor= e fundamental concern. There are no procedures anywhere for using this opti= on tag in Supported, Unsupported or Require. If it is not used, why is it n= eeded? Inclusion of the Geolocation header field implies support by the UAC= . Sending a 424 or Geolocation-Error implies support by the UAS. Are there = other cases where support needs to be known (e.g., in a request without Geo= location or in a 200 response without Geolocation-Error)? If we don't have = any uses for the option tag, why define it? 33. Section 4.5: "In the case where a location recipient sends a 424 response and=20 wishes to communicate suitable location by reference rather than by=20 value, the 424 MUST include a content-indirection body per RFC 4483." Why is this needed? A 424 response can contain a Geolocation header field c= ontaining the reference. 34. Section 4.6: "The following is part of the discussion started in Section 3 ..." It seems to be more than a continuation of a discussion, it seems to be spe= cification. 35. Section 5.1: "the SIP request uses a sips-URI [RFC3261]" Would RFC 5630 be a more appropriate reference? 36. Section 5.1: " An assumption can be=20 made that SDP is the other message body part. " This is just an example. We don't need tell the reader to make an assumptio= n - just state that in this example SDP is the other body part. 37. "The "cid:" eases=20 message body parsing by disambiguating the MIME body that contains=20 the location information associated with this request." Easing parsing and disambiguating are two different properties - the one do= esn't rely on the other. Should say "eases message body parsing and disambi= guates multiple parts of the same type". 38. Section 5.1: "Any node wanting to know where user "target123" is would subscribe to=20 that user at server5 to dereference the sips-URI" I think this should say: "Any node wanting to know where the target is located would subscribe to th= e SIP presence event package [RFC 3856) at sips:target123@server5.atlanta.e= xample.com" 39. In the same sentence: "(see Figure 3 in=20 section 3 for this message flow )" This probably should be Figure 2. However, neither Figure 2 nor Figure 3 sh= ows the message flow (SUBSCRIBE/200/NOTIFY/200). 40. Section 6: "Implementations of this SIP location conveyance mechanism MUST=20 adhere to the guidance given in RFC3693 and its successors " I assume by "and its successors" we are specifically referring to [ID-GEOPR= IV-ARCH]. However, according to text earlier in the paragraph, and accordin= g to the architecture draft itself, it only updates RFC 3693, it is not a s= uccessor. So either say "all updates" or specifically mention the architect= ure draft. 41. Section 8.1: "The SIP Geolocation Header Field is created by this document, with=20 its definition and rules in Section 4.1 of this document, and should be added to the IANA sip-parameters registry, in the portion titled=20 "Header Field Parameters and Parameter Values" ." This provides a single IANA instruction where really it should provide two.= It should update the Header Fields registry with Geolocation and should up= date the Header Field Parameters and Parameter Values registry with routing= -allowed. 42. Section 8.2. "The SIP option tag "geolocation" is created by this document, with=20 the definition and rule in Section 4.4 of this document, to be added=20 to the IANA sip-parameters registry." Assuming we retain the option tag (see an earlier comment), it should be me= ntioned that it is the Options Tags registry that is to be added to. 43. Section 8.3: It should be mentioned that it is the Response Codes registry that is added= to. 44. Section 8.3: "Response code: 424 (recommended number to assign) Default reason phrase: Bad Location Information " It should be registered as simply "424 Bad Location Information". 45. Section 8.4: "The SIP Geolocation-error header field is created by this document,=20 with its definition and rules in Section 4.3 of this document, to be added to the IANA sip-parameters registry, in the portion titled=20 "Header Field Parameters and Parameter Values" Same comment as on 8.1. 46. Section 8.5. We need to state what the policy is for adding new values to the error code= s registry. 47: "8.6 IANA Registration of Location URI Schemes" Do we really need a registry for this? URI scheme names are already registe= red elsewhere. Also the ABNF doesn't provide an extensibility mechanism. Or= is "absoluteURI" meant to be the extension mechanism? However, there is no= thing in section 4 that limits schemes used under absoluteURI to being only= those defined in this registry, so it is unclear what purpose the registry= serves. John From HKaplan@acmepacket.com Fri Nov 5 07:43:01 2010 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 1A9A13A67A3; Fri, 5 Nov 2010 07:43:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.248 X-Spam-Level: X-Spam-Status: No, score=-2.248 tagged_above=-999 required=5 tests=[AWL=0.351, BAYES_00=-2.599] 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 iEPM3OPIllOp; Fri, 5 Nov 2010 07:43:00 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3F2F13A66B4; Fri, 5 Nov 2010 07:43:00 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Fri, 5 Nov 2010 10:43:12 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 5 Nov 2010 10:43:12 -0400 From: Hadriel Kaplan To: "sipcore@ietf.org Core) WG" Date: Fri, 5 Nov 2010 10:43:10 -0400 Thread-Topic: Monday afternoon slot for SIPCORE? Thread-Index: Act898Uw2KtB1l2STpq/G02eYFqTxA== Message-ID: <6E75D773-BE7F-491F-8F0C-682233B2DCC1@acmepacket.com> 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 Cc: "rai@ietf.org" Subject: [sipcore] Monday afternoon slot for SIPCORE? 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: Fri, 05 Nov 2010 14:43:01 -0000 Howdy, it appears Martini is giving up one of its slots: Monday 3-4pm. If the roo= m is still available, would it make sense to have SIPCORE meet during that = time as well, and give the whole hour to 4244bis? Right now 4244bis is only getting 30 minutes in SIPCORE, but ISTM that we r= eally need to spend more time on it so we can finally get it done/out and n= ot drag this on continually. just a thought, anyway. -hadriel= From john.elwell@siemens-enterprise.com Fri Nov 5 07:50:47 2010 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 A3F313A67E5; Fri, 5 Nov 2010 07:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.461 X-Spam-Level: X-Spam-Status: No, score=-102.461 tagged_above=-999 required=5 tests=[AWL=0.138, BAYES_00=-2.599, 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 zPqX9UWapc96; Fri, 5 Nov 2010 07:50:46 -0700 (PDT) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 3CDDC3A67C3; Fri, 5 Nov 2010 07:50:45 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2190866; Fri, 5 Nov 2010 15:50:58 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 2D0B91EB82B0; Fri, 5 Nov 2010 15:50:58 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 5 Nov 2010 15:50:58 +0100 From: "Elwell, John" To: Hadriel Kaplan , "sipcore@ietf.org Core) WG" Date: Fri, 5 Nov 2010 15:50:56 +0100 Thread-Topic: Monday afternoon slot for SIPCORE? Thread-Index: Act898Uw2KtB1l2STpq/G02eYFqTxAAAQ2Rw Message-ID: References: <6E75D773-BE7F-491F-8F0C-682233B2DCC1@acmepacket.com> In-Reply-To: <6E75D773-BE7F-491F-8F0C-682233B2DCC1@acmepacket.com> 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 Cc: "rai@ietf.org" Subject: Re: [sipcore] Monday afternoon slot for SIPCORE? 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: Fri, 05 Nov 2010 14:50:47 -0000 Sounds like a good idea. John=20 > -----Original Message----- > From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On=20 > Behalf Of Hadriel Kaplan > Sent: 05 November 2010 14:43 > To: sipcore@ietf.org Core) WG > Cc: rai@ietf.org > Subject: [RAI] Monday afternoon slot for SIPCORE? >=20 > Howdy, > it appears Martini is giving up one of its slots: Monday=20 > 3-4pm. If the room is still available, would it make sense=20 > to have SIPCORE meet during that time as well, and give the=20 > whole hour to 4244bis? >=20 > Right now 4244bis is only getting 30 minutes in SIPCORE, but=20 > ISTM that we really need to spend more time on it so we can=20 > finally get it done/out and not drag this on continually. >=20 > just a thought, anyway. >=20 > -hadriel > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai > = From youssef.chadli@orange-ftgroup.com Fri Nov 5 11:45:04 2010 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 7917D3A691C for ; Fri, 5 Nov 2010 11:45:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.049 X-Spam-Level: X-Spam-Status: No, score=-1.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_29=0.6, J_CHICKENPOX_39=0.6] 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 ETDMekQMBsHh for ; Fri, 5 Nov 2010 11:45:00 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 073BE3A67EE for ; Fri, 5 Nov 2010 11:44:59 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7D87D6C000F; Fri, 5 Nov 2010 19:45:33 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 725B56C0001; Fri, 5 Nov 2010 19:45:33 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 5 Nov 2010 19:45:11 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 5 Nov 2010 19:44:58 +0100 Message-ID: <9ECCF01B52E7AB408A7EB853526421410221B4E3@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4CD16A52.7090006@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Bypassing out-of-service intermediate Proxy Thread-Index: Act7Xx3W16gFkXjRTOqfHfUoU6Sk1wBuYItA References: <9ECCF01B52E7AB408A7EB8535264214101CD7EE2@ftrdmel0.rd.francetelecom.fr><4C7FDBEE.6080305@nostrum.com>, <9ECCF01B52E7AB408A7EB85352642141020FD443@ftrdmel0.rd.francetelecom.fr> <9ECCF01B52E7AB408A7EB8535264214102155080@ftrdmel0.rd.francetelecom.fr> <4CD16A52.7090006@cisco.com> From: To: , X-OriginalArrivalTime: 05 Nov 2010 18:45:11.0475 (UTC) FILETIME=[93A29030:01CB7D19] Subject: Re: [sipcore] Bypassing out-of-service intermediate Proxy 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: Fri, 05 Nov 2010 18:45:04 -0000 I don't think this analogy is correct. If you take the example of a SIP Server which is inserted in the SIP = path only to provide a supplementary service in case this latter is = requested by the user ( e.g. call transfer), I think that the user will = not be satisfied if it's call does not succeed just because the network = is not able to provide this service... Youssef -----Message d'origine----- De : sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] De la = part de Paul Kyzivat Envoy=E9 : mercredi 3 novembre 2010 14:58 =C0 : sipcore@ietf.org Objet : Re: [sipcore] Bypassing out-of-service intermediate Proxy This idea seems analogous to the auto assembly line deciding to bypass = the broken station where the engine is inserted into the car, and just = send the car on to the next station without its engine. The consumer who = receives this car may be less than satisfied. :-( Thanks, Paul On 11/3/2010 5:55 AM, youssef.chadli@orange-ftgroup.com wrote: > > I understand that the usage of DNS to provide alternate server is a = way to ensure redundancy. In such solution, to be able to handle SIP = requests inside a SIP dialog and for which the proxy need to be "dialog = statefull", there is a need to implement a mechanism that would allow = the "alternate" server to share the same SIP dialog contexts. > > My idea is in case of unavailability of the next hop and in case no=20 > alternate server is returned by DNS (or alternate servers are=20 > unreachable too), instead of rejecting the request (which would make=20 > the call/session fails), the SIP Proxy may send it to the hop after=20 > the unreachable one in the Route. This alternative would be authorized = > only if the Proxy knows that it's better to bypass the unreachable=20 > node instead of rejecting the request. The SIP proxy may get this=20 > information via a URI parameter in the Route entry of the=20 > "unreachable" node for example > > Best regards, > > Youssef > > -----Message d'origine----- > De : Worley, Dale R (Dale) [mailto:dworley@avaya.com] Envoy=E9 :=20 > vendredi 29 octobre 2010 20:22 =C0 : CHADLI Youssef RD-CORE-ISS;=20 > adam@nostrum.com Cc : sipcore@ietf.org Objet : RE: [sipcore] Bypassing = > out-of-service intermediate Proxy > > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of = > youssef.chadli@orange-ftgroup.com [youssef.chadli@orange-ftgroup.com] > > I understand that the intention of this text in RFC 3261 is to fail = over to an alternate server that serves the same function. Though, it's = not explicitly stated. > > However, I did not find any text in RFC 3261 that would make forbidden = failing over to a proxy further down the path. Moreover, I did not see = any problem to such behaviour. > ________________________________ > > If a particular URI is included in a Route header, then there is some = important function the server with that URI is to perform. If one = element ignores this URI and sends the request to the next URI in the = Route header, presumably the function of the skipped server will not be = performed. > > In all cases that I have heard about, the correct way to provide = alternate servers for a failed server is to construct a DNS SRV name = which maps to the primary and alternate server as is desired. > > For instance, if functionA is to be serviced by serverA but in an = emergency the request can be routed to serverB, and if functionB is = serviced by serverB, then we construct two SRV names: > > functionA SRV serverA priority=3D1 > functionA SRV serverB priority=3D2 > > functionB SRV serverB priority=3D1 > > and use this Route header: > > Route: sip:functionA, sip:functionB > > If an element has a request with this Route header, it will send the = request to sp:functionA using the RFC 3263 rules, viz., attempt to send = to serverA, and if that fails, attempt to send to serverB. > > Dale > _______________________________________________ > 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 From spencer@wonderhamster.org Fri Nov 5 12:54:01 2010 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 E49843A6935; Fri, 5 Nov 2010 12:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.731 X-Spam-Level: X-Spam-Status: No, score=-101.731 tagged_above=-999 required=5 tests=[AWL=0.866, BAYES_00=-2.599, STOX_REPLY_TYPE=0.001, 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 h3e8mvcoiPKS; Fri, 5 Nov 2010 12:54:00 -0700 (PDT) Received: from mout.perfora.net (mout.perfora.net [74.208.4.194]) by core3.amsl.com (Postfix) with ESMTP id 820663A6928; Fri, 5 Nov 2010 12:54:00 -0700 (PDT) Received: from S73602b (3.97.247.60.static.bjtelecom.net [60.247.97.3]) by mrelay.perfora.net (node=mrus3) with ESMTP (Nemesis) id 0MOO2H-1P9FpB1mYX-005jDA; Fri, 05 Nov 2010 15:54:10 -0400 Message-ID: From: "Spencer Dawkins" To: "Elwell, John" , "Hadriel Kaplan" , References: <6E75D773-BE7F-491F-8F0C-682233B2DCC1@acmepacket.com> Date: Fri, 5 Nov 2010 14:53:50 -0500 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.5931 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5994 X-Provags-ID: V02:K0:PeOBht2VqqXwtGkhUOVu8XAgw4XHL5CImeAi+w/nkJY qogx/d8srnl2BBRipiXGM2gmUx5XWofTnzc8XKZP3LLD1bIzaQ TkprbyzRqnC+XjFJbxJ2GFJk5h4/txuQooPo3E36ffrwHlZxGk YbsBBi8G7D+NUXkQYO2K0JJMFNnFzaUpzZ17f38zB5/wPIf6jm OqUDGPPP/6HYiu0ELjLd0ltvRYF04oiKnuA6hDouB4= Cc: rai@ietf.org Subject: Re: [sipcore] [RAI] Monday afternoon slot for SIPCORE? 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: Fri, 05 Nov 2010 19:54:02 -0000 MARTINI IS giving up its Monday afternoon slot, and (even better) the last thing I heard is that the scheduling tool doesn't allow the secretariat to CANCEL that slot without cancelling the Thursday morning slot as well - so I bet that means no one else can grab the room officially :D Spencer > Sounds like a good idea. > > John > >> -----Original Message----- >> From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On >> Behalf Of Hadriel Kaplan >> Sent: 05 November 2010 14:43 >> To: sipcore@ietf.org Core) WG >> Cc: rai@ietf.org >> Subject: [RAI] Monday afternoon slot for SIPCORE? >> >> Howdy, >> it appears Martini is giving up one of its slots: Monday >> 3-4pm. If the room is still available, would it make sense >> to have SIPCORE meet during that time as well, and give the >> whole hour to 4244bis? >> >> Right now 4244bis is only getting 30 minutes in SIPCORE, but >> ISTM that we really need to spend more time on it so we can >> finally get it done/out and not drag this on continually. >> >> just a thought, anyway. >> >> -hadriel >> _______________________________________________ >> RAI mailing list >> RAI@ietf.org >> https://www.ietf.org/mailman/listinfo/rai >> > _______________________________________________ > RAI mailing list > RAI@ietf.org > https://www.ietf.org/mailman/listinfo/rai From pkyzivat@cisco.com Sat Nov 6 04:39:35 2010 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 E459D3A6912 for ; Sat, 6 Nov 2010 04:38:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.999 X-Spam-Level: X-Spam-Status: No, score=-109.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8, 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 JFa4sBhbMSWw for ; Sat, 6 Nov 2010 04:37:52 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 165C73A68FD for ; Sat, 6 Nov 2010 04:37:28 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADLb1ExAaMHG/2dsb2JhbACiCHGgapsThUgEilWDCg X-IronPort-AV: E=Sophos;i="4.58,307,1286150400"; d="scan'208";a="615555565" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-6.cisco.com with ESMTP; 06 Nov 2010 11:37:35 +0000 Received: from [10.75.235.188] (hkidc-vpn-client-235-188.cisco.com [10.75.235.188]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA6BbWfE004659; Sat, 6 Nov 2010 11:37:33 GMT Message-ID: <4CD53DFC.8020401@cisco.com> Date: Sat, 06 Nov 2010 07:37:32 -0400 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: youssef.chadli@orange-ftgroup.com References: <9ECCF01B52E7AB408A7EB8535264214101CD7EE2@ftrdmel0.rd.francetelecom.fr><4C7FDBEE.6080305@nostrum.com>, <9ECCF01B52E7AB408A7EB85352642141020FD443@ftrdmel0.rd.francetelecom.fr> <9ECCF01B52E7AB408A7EB8535264214102155080@ftrdmel0.rd.francetelecom.fr> <4CD16A52.7090006@cisco.com> <9ECCF01B52E7AB408A7EB853526421410221B4E3@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB853526421410221B4E3@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Bypassing out-of-service intermediate Proxy 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: Sat, 06 Nov 2010 11:39:47 -0000 On 11/5/2010 2:44 PM, youssef.chadli@orange-ftgroup.com wrote: > > I don't think this analogy is correct. > > If you take the example of a SIP Server which is inserted in the SIP path only to provide a supplementary service in case this latter is requested by the user ( e.g. call transfer), I think that the user will not be satisfied if it's call does not succeed just because the network is not able to provide this service... Sure, the analogy *might* not always be correct, though it surely will be correct in some / many cases. How can the element doing the skipping know? In general it has no idea of the importance of an element in the route. Its at the time of insertion into the route that the importance is known, so that is when such decisions should be made. Thanks, Paul > > Youssef > > -----Message d'origine----- > De : sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] De la part de Paul Kyzivat > Envoyé : mercredi 3 novembre 2010 14:58 > À : sipcore@ietf.org > Objet : Re: [sipcore] Bypassing out-of-service intermediate Proxy > > This idea seems analogous to the auto assembly line deciding to bypass the broken station where the engine is inserted into the car, and just send the car on to the next station without its engine. The consumer who receives this car may be less than satisfied. :-( > > Thanks, > Paul > > On 11/3/2010 5:55 AM, youssef.chadli@orange-ftgroup.com wrote: >> >> I understand that the usage of DNS to provide alternate server is a way to ensure redundancy. In such solution, to be able to handle SIP requests inside a SIP dialog and for which the proxy need to be "dialog statefull", there is a need to implement a mechanism that would allow the "alternate" server to share the same SIP dialog contexts. >> >> My idea is in case of unavailability of the next hop and in case no >> alternate server is returned by DNS (or alternate servers are >> unreachable too), instead of rejecting the request (which would make >> the call/session fails), the SIP Proxy may send it to the hop after >> the unreachable one in the Route. This alternative would be authorized >> only if the Proxy knows that it's better to bypass the unreachable >> node instead of rejecting the request. The SIP proxy may get this >> information via a URI parameter in the Route entry of the >> "unreachable" node for example >> >> Best regards, >> >> Youssef >> >> -----Message d'origine----- >> De : Worley, Dale R (Dale) [mailto:dworley@avaya.com] Envoyé : >> vendredi 29 octobre 2010 20:22 À : CHADLI Youssef RD-CORE-ISS; >> adam@nostrum.com Cc : sipcore@ietf.org Objet : RE: [sipcore] Bypassing >> out-of-service intermediate Proxy >> >> ________________________________________ >> From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of >> youssef.chadli@orange-ftgroup.com [youssef.chadli@orange-ftgroup.com] >> >> I understand that the intention of this text in RFC 3261 is to fail over to an alternate server that serves the same function. Though, it's not explicitly stated. >> >> However, I did not find any text in RFC 3261 that would make forbidden failing over to a proxy further down the path. Moreover, I did not see any problem to such behaviour. >> ________________________________ >> >> If a particular URI is included in a Route header, then there is some important function the server with that URI is to perform. If one element ignores this URI and sends the request to the next URI in the Route header, presumably the function of the skipped server will not be performed. >> >> In all cases that I have heard about, the correct way to provide alternate servers for a failed server is to construct a DNS SRV name which maps to the primary and alternate server as is desired. >> >> For instance, if functionA is to be serviced by serverA but in an emergency the request can be routed to serverB, and if functionB is serviced by serverB, then we construct two SRV names: >> >> functionA SRV serverA priority=1 >> functionA SRV serverB priority=2 >> >> functionB SRV serverB priority=1 >> >> and use this Route header: >> >> Route: sip:functionA, sip:functionB >> >> If an element has a request with this Route header, it will send the request to sp:functionA using the RFC 3263 rules, viz., attempt to send to serverA, and if that fails, attempt to send to serverB. >> >> Dale >> _______________________________________________ >> 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 > From HKaplan@acmepacket.com Sat Nov 6 19:09:41 2010 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 22C343A6961 for ; Sat, 6 Nov 2010 19:09:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.196 X-Spam-Level: X-Spam-Status: No, score=-1.196 tagged_above=-999 required=5 tests=[AWL=-0.701, 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 eAPuZJi5mX6q for ; Sat, 6 Nov 2010 19:09:39 -0700 (PDT) Received: from ETMail2.acmepacket.com (unknown [216.41.24.9]) by core3.amsl.com (Postfix) with ESMTP id 5DCB23A6976 for ; Sat, 6 Nov 2010 19:09:37 -0700 (PDT) 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; Sat, 6 Nov 2010 22:09:54 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 6 Nov 2010 22:09:51 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Sat, 6 Nov 2010 22:09:47 -0400 Thread-Topic: [sipcore] H-I in 100 response (was REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis) Thread-Index: Act+INwj3o7y4DxNR+a1dTFTP/D9Og== Message-ID: <5C04F446-3A93-471C-B0AB-37CD57543BB9@acmepacket.com> References: <4C69ADA8.1010802@nostrum.com> <4C753AAA.3030407@nostrum.com> <4CD08E7A.1020503@cisco.com> In-Reply-To: <4CD08E7A.1020503@cisco.com> 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: AAAAAQAAAUA= Cc: "sipcore@ietf.org" Subject: Re: [sipcore] H-I in 100 response (was REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis) 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: Sun, 07 Nov 2010 02:09:41 -0000 On Nov 2, 2010, at 6:19 PM, Paul Kyzivat wrote: > On 11/2/2010 4:31 PM, Elwell, John wrote: >> So the remaining issue from this thread concerns whether to mandate Hist= ory-Info in a all provisional responses or just non-100 provisional respons= es (subject to presence of the option tag in the request). Given that 100 t= ends to be generated differently from other provisional responses, and give= n the marginal use of H-I in 100 responses, I would prefer either to omit H= -I from 100 responses or use MAY. I don't have a strong opinion, but perhap= s others have a view. >=20 > Requiring (even permitting) H-I in 100 responses is a *terrible* idea. Totally, 100%, absolutely agree with Paul. 100's are processed at a lower = layer of the SIP stack, and are hop-by-hop anyway making them useless for H= -I. -hadriel= From trac@tools.ietf.org Sat Nov 6 19:41:07 2010 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 14AA63A68D2 for ; Sat, 6 Nov 2010 19:41:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 8qeAfFY5xbq6 for ; Sat, 6 Nov 2010 19:41:06 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 6AF103A67D0 for ; Sat, 6 Nov 2010 19:41:05 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEvC6-0002A3-4Y; Sat, 06 Nov 2010 19:41:22 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sipcore issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hkaplan@acmepacket.com X-Trac-Project: sipcore Date: Sun, 07 Nov 2010 02:41:22 -0000 X-URL: http://tools.ietf.org/sipcore/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sipcore/trac/ticket/44 Message-ID: <064.81e343374deecdf821a6bab2507a302c@tools.ietf.org> X-Trac-Ticket-ID: 44 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hkaplan@acmepacket.com, sipcore@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: sipcore@ietf.org Subject: [sipcore] rfc4244bis #44 (new): 4244bis-02: security section misleading X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 02:41:07 -0000 #44: 4244bis-02: security section misleading Section 9 says: With the level of security provided by TLS (SEC-req-3), the information in the History-Info header can thus be evaluated to determine if information has been removed by evaluating the indices for gaps (SEC-req-1, SEC-req-2). It would be up to the application to define whether it can make use of the information in the case of missing entries. No, TLS doesn't do that. TLS only guarantees you that the next-hop or previous-hop is who its cert claims it to be (assuming you trust its anchor), and prevents tampering by something in-between you and that previous-hop or next-hop. That doesn't mean that previous-hop or next- hop, or some upstream/downstream entity beyond it, did not modify the H-I entries - including in ways which you cannot possibly detect. For example it could have renumbered them, changed their content, etc. This section-9 paragraph is wrong, and we won't be able to satisfy the security requirements in appendix A.1 That's *OK*. We're not going to get better than that. In fact, we basically need that behavior, since we need PSTN Gateways to be able to generate H-I entries based on ISUP info (even for numbers they don't own); and we need Diversion interworked to H-I too. -- ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: Type: defect | Status: new Priority: minor | Milestone: milestone1 Component: rfc4244bis | Version: 2.0 Severity: In WG Last Call | Keywords: ------------------------------------+--------------------------------------- Ticket URL: sipcore From trac@tools.ietf.org Sat Nov 6 19:49:24 2010 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 442B43A69A1 for ; Sat, 6 Nov 2010 19:49:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 AOlkqAspmKJW for ; Sat, 6 Nov 2010 19:49:23 -0700 (PDT) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 425443A697B for ; Sat, 6 Nov 2010 19:49:23 -0700 (PDT) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PEvK8-0006Pn-4u; Sat, 06 Nov 2010 19:49:40 -0700 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sipcore issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: hkaplan@acmepacket.com X-Trac-Project: sipcore Date: Sun, 07 Nov 2010 02:49:40 -0000 X-URL: http://tools.ietf.org/sipcore/ X-Trac-Ticket-URL: http://trac.tools.ietf.org/wg/sipcore/trac/ticket/45 Message-ID: <064.32c7985ec06278ea9918712118d70f22@tools.ietf.org> X-Trac-Ticket-ID: 45 X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: hkaplan@acmepacket.com, sipcore@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: sipcore@ietf.org Subject: [sipcore] rfc4244bis #45 (new): 4244bis-02: REFER handling not clear X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 07 Nov 2010 02:49:24 -0000 #45: 4244bis-02: REFER handling not clear I'm not quite sure what the draft expects of the UA processing a REFER and generating a new INVITE from it. Section 4 says: ... A SIP entity changing the target of a request in response to a redirect or REFER also propagates any History-Info header from the initial Request in the new request. Which "initial request"? The REFER? The REFER request has its own list of H-I, but I don't know what that has to do with the new INVITE going out. Alice calls Bob, Bob calls Charlie; Bob REFERs Charlie to Alice - why does Alice care how the REFER reached Charlie? Won't it in fact confuse applications to get H-I entries in INVITEs that are not in fact the history of the INVITE? For example, suppose Bob called Charlie but his call got redirected to Donna, and then Bob REFERed Donna to Alice - wouldn't it confuse Alice to get an INVITE with an H-I indicating Charlie was the original target of the INVITE and it got mapped to Donna, and that got sent to Alice?? -- ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: Type: defect | Status: new Priority: major | Milestone: milestone1 Component: rfc4244bis | Version: 2.0 Severity: In WG Last Call | Keywords: ------------------------------------+--------------------------------------- Ticket URL: sipcore From HKaplan@acmepacket.com Sat Nov 6 20:48:48 2010 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 603DB3A69C9 for ; Sat, 6 Nov 2010 20:48:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.148 X-Spam-Level: X-Spam-Status: No, score=-2.148 tagged_above=-999 required=5 tests=[AWL=0.451, BAYES_00=-2.599] 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 O3SKXi8Tu-zL for ; Sat, 6 Nov 2010 20:48:41 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 1932A3A69A7 for ; Sat, 6 Nov 2010 20:48:41 -0700 (PDT) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 6 Nov 2010 23:48:57 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 6 Nov 2010 23:48:55 -0400 From: Hadriel Kaplan To: "sipcore@ietf.org WG" Date: Sat, 6 Nov 2010 23:48:53 -0400 Thread-Topic: Editorial comments on rfc4244bis-02 Thread-Index: Act+LrMzO9XiO8INQXWiOQ9Q1iQ1cQ== Message-ID: <0CDF97F6-E125-45F8-B266-65E79BAE6F1A@acmepacket.com> 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 Subject: [sipcore] Editorial comments on 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: Sun, 07 Nov 2010 03:48:48 -0000 Howdy, I read the latest 02 draft and found it better than 01. (or I'm growing num= b to it ;) I'll use the tracker for technical comments, but this email for editorials: 1) I recommend moving section 7.1 and 7.2 to be the first section after the= overview - i.e., before the UA and proxy behavior sections, since those se= ctions use terms defined in section 7. I don't care whether 7.3 goes with = it or stays put as a new section. 2) I recommend that within section 7.1, move the ABNF to be before the list= of field definitions - that way it flows more naturally (and the way a lot= of other RFCs are done). 3) It feels like a lot of the processing rules of a UAC are effectively the= same as that of a Proxy on its client-transaction side, and the rules for = a UAS are the same as that of a Proxy on its server-transaction side. Or a= t least, they _should_ be the same. For example, the UAC must do the same = thing a proxy does for 3xx or failure response cases. And a UAS has to do = the same thing a Proxy does when it receives a request without itself in th= e bottom-most H-I. I don't know if it's better or worse to stop copying th= e same text and consolidate somehow. 4) Section 7.1, pages 16/17 says: Note that since both the Reason and Privacy parameters are escaped in the hi-targeted-to-uri, these fields will not be available in the case that the hi-targeted-to-uri is a Tel-URI [RFC3966]. I suggest adding the following sentence after that: "In such cases, the Tel-URI SHOULD be transformed to a SIP URI per section = 19.1.6 of [RFC3261]." 5) Section 7.1 says: "...plus NOTIFY requests that initiate a dialog." Umm= m... what type of NOTIFY requests would those be?? (other than proprietary)= Actually, that raises a question - can this appear in proprietary methods= ? 6) Section 5.1 "In addition, the UAC SHOULD add a History-Info..." change t= o MUST. 7) Section 7.3.4, first bullet: s/MSUT/MUST/ 8) Section 4, "(e.g., INVITE, REGISTER, MESSAGE, REFER and OPTIONS, PUBLISH= and SUBSCRIBE, etc.)" change to "(e.g., INVITE, REGISTER, MESSAGE, REFER, OPTIONS, PUBLISH, SUBSCRIBE, etc.)". Also this sentence is way u= gly. 9) Section 4, page 7, second para says: "Further detailed is provided in Se= ction 7.3.1." Changed "detailed" to "detail". 10) Appendix B examples show H-Is which are incorrectly formatted. Things = like: History-Info: ;\ index=3D1.1;rc=3D1 whereas it should be: History-Info: ;\ index=3D1.1;rc=3D1 I don't know if this was done on purpose - I recall seeing somewhere someth= ing to the effect of examples being wrong to help readability - but please = don't help people by making incorrectly formatted examples. :) -hadriel From shida@ntt-at.com Sat Nov 6 22:28:47 2010 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 21ADD3A6980 for ; Sat, 6 Nov 2010 22:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.665 X-Spam-Level: X-Spam-Status: No, score=-101.665 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_63=0.6, J_CHICKENPOX_74=0.6, 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 AekszM6QDdui for ; Sat, 6 Nov 2010 22:28:44 -0700 (PDT) Received: from gateway11.websitewelcome.com (gateway11.websitewelcome.com [67.18.55.4]) by core3.amsl.com (Postfix) with SMTP id 8B72B3A69A7 for ; Sat, 6 Nov 2010 22:28:31 -0700 (PDT) Received: (qmail 30662 invoked from network); 7 Nov 2010 05:37:20 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway11.websitewelcome.com with SMTP; 7 Nov 2010 05:37:20 -0000 Received: from [222.128.255.179] (port=62358) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PExno-0004qt-FR; Sun, 07 Nov 2010 00:28:30 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Sun, 7 Nov 2010 13:28:27 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Elwell, John" 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: "Barnes, Mary" , "sipcore@ietf.org" Subject: Re: [sipcore] Yet more comments on 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: Sun, 07 Nov 2010 05:28:47 -0000 Hi John; My responses on some of the comments, I think=20 Mary may be responding on the same issues but here are mine. On Nov 4, 2010, at 12:29 AM, Elwell, John wrote: > 1. Section 7.3.1. > "If there is a Privacy header in the request with a priv- > value of "header" or "history", then the initial hi-entry MUST be > anonymized and the header removed when the request leaves a domain > for which the SIP entity is responsible." > I think it should say "...and the Privacy header removed" - there is = no point in removing the H-I header field if we have anonymized it. You are right. The intention was to say "remove the priv-value and = remove the privacy=20 header itself if there are no other priv-value left (id may exists which = needs=20 to remain in the request until it reaches the egress point)".=20 >=20 > 2. What is meant by anonymizing a hi-entry (in this paragraph and = elsewhere)? Is it only the hi-targeted-to-uri that needs to be = anonymized, or also its parameters? The examples in annex B show just = the URI anonymized and with the value anonymous@anonymous.invalid. Is = this how it MUST be done? I personally don't have a strong opinion about prescribing the = anonymous@anonymou.invalid but=20 I think it would be useful to specify what the anonymized URI should = look like. This would avoid=20 anonymous URI anonymized numerous time by different privacy service for = example... As for the parameter, if rc/mp tag, index and encoded reason(RFC 3326) = are intact,=20 anonymized hi-entry can still provide some value, so I think only = hi-targeted-to-uri should be=20 anonymized. =20 >=20 > 3. In the same sentence, is it sufficient to anonymize only the first = hi-entry? There could be further hi-entries for the same domain, and = just revealing internal routing within the domain might be considered a = breach of privacy. Perhaps in that case you would need to rely on those = additional hi-entries being separately marked for privacy. If that is = so, it would seem to be OK. Your last suggestion/assumption was exactly the motivation and our=20 attempt to simplify privacy handling, by saying Privacy header with = priv-value=20 of "history"/"header" (not in hi-entry) for anonymizing first hi-entry = only and to use=20 privacy=3Dheader in hi-entry for any other hi-entries.=20 It would mean; =20 1. UA requests H-I privacy by using Privacy:history or Privacy:header 2. Proxy request H-I privacy by using = History-Info:?privacy=3Dhistory Which we thought would clarify the timing of when Privacy:history / = Privacy:header=20 and privacy=3Dhistory are used. But thinking further, it doesn't really simplify the overall=20 privacy handling of H-I and furthermore it changes the semantics of=20 header privacy in RFC3323. Excerpt from RFC3323 on header privacy says: =20 "If a privacy level of 'header' is requested, then the originating user has asked the privacy service to help to obscure headers that might otherwise reveal information about the originator of the request." This can encompass entries revealing internal routing and domain=20 information as you mentioned above, so restricting the use of = Privacy:header=20 to first entry only can be seen as changing the semantics defined in = RFC3323.=20 I think we should align the handling of H-I privacy of Privacy:history=20= and Privacy:header to that of RFC3323, allowing privacy service to=20 anonymize not only the first hi-entry but any other entries that=20 are from its domain.=20 I guess we need to further clarify how these two means of requesting=20 privacy interact, since you can have both privacy:history and few = hi-entries=20 with privacy=3Dhistory. I am assuming that when privacy service = anonymizes=20 history-info header based on privacy:history or privacy:header, it also =20= needs to remove the privacy=3Dhistory from hi-entries that it's = anonymizing.=20 Lastly what about the interaction with privacy:none? According to =20 section 5.1 of 4244bis, if UAC doesn't want privacy on its identity it = sets=20 Privacy header with priv-value of "none", but I am having a hard time=20 envisioning the need for this. When do you ever get the hi-entry = representing=20 your own AoR or contact address?=20 I think the hi-entry with privacy=3Dhistory should still be anonymized, = even when the Privacy:none is set in request because the privacy is requested by = proxy, I=20 think we need to add text on this as well. =20 >=20 > 4. "In addition, the History-Info header can reveal general routing = and > diverting information within an intermediary, " > Is it only routing information within an intermediary, or also routing = information within a domain that you might want to make private? I think = text later in the paragraph concurs with the latter view. >=20 > 5. "Finally, the terminator of the request may not want to reveal the > final reached target to the originator. In this case, the = terminator > uses the a value of "history" in the Privacy header in the last hi- > entry in the response. The SIP entity that forwards the response > MUST anonymize that hi-entry and remove the Privacy header." > Although a UAS can mark the final hi-entry as private, and there is a = requirement for a proxy to anonymize this when the response leaves the = domain, what about other hi-entries that have been marked by proxies in = the final domain as private? These will get passed back in the response = without anonymization since they are not the final hi-entry and are not = covered by this statement. Should the final sentence apply to any = hi-entry? RFC3323 recommends that privacy service to be included in the=20 request/response path if privacy is desired. The privacy handling=20 in 4244bis is based on RFC3323 so I don't know if we need to add=20 anything specific here for anonymizing the response. >=20 > 6. Section 7.3.3: > "To > accomplish this, the processing entity MUST read the value from > the History-Info header in the received request and MUST add > another level of indexing " > Should make it clear it is the last hi-entry of the received request = (after adding entries on behalf of previous hops). Agree.=20 >=20 > 7. "followed > by an initial index for the new level of 1" > I think this would be clearer if it said: > "followed by an initial index of 1 for the new level" Agree. >=20 > 8. "MUST be calculated by incrementing the last/lowest digit > at the current level" > and=20 > "That is, the lowest/last digit of the index MUST be > incremented " > What if an index is a double-digit integer? How about we remove the "lowest/last" and simply=20 say incrementing the digit at the current level by 1 or=20 something like that. >=20 > 9. Section 8: > "an > application might need to provide special handling in some cases > where there are gaps." > Should there be a note discussing the fact that some gaps are not = detectable, e.g., if I receive 1, 1.1 and 1.1.1, I cannot detect if 1.2 = or 1.1.2, say, is missing. This would happen, say for example if request was=20 parallel forked, each branch would have the hi-entry=20 that only the forked request traversed but missing=20 the information of the other forks. I don't know if I would=20 consider what you describe as a gap. You may be=20 missing the other branches but you should be able to=20 identify the gap in index for the branch that request=20 traversed. (You may be missing the actual hop in the=20 logical tree of History-Info that does not support=20 4244/4244bis but as they won't add the hi-entry =20 there won't be a gap in index itself).=20 >=20 > 10. Should we say anything in section 8 about anonymized entries? Note = that what we might say depends to some extent on whether what exactly = gets anomymised. For example if an application searches for an rc or mp = entry, if those parameters have been anonymized it will not find them = (but might find others that have not been anonymized!), but if those = parameters have not been anonymized it will find them but the URI will = be useless. URI will be useless but one can still determine how many times=20 request was retargeted, for example (Of course this is true only=20 if all the proxies are rfc4244bis compliant), which I think remains=20 useful. >=20 > 11. Section 9: > "With the level of security provided by TLS (SEC-req-3), the > information in the History-Info header can thus be evaluated to > determine if information has been removed by evaluating the indices > for gaps (SEC-req-1, SEC-req-2). " > This is subject to the limitation pointed out in a comment above, = about not all gaps being detectable. >=20 > 12. I would expect to see something in section 9 concerning privacy. = We should mention the privacy mechanism and discuss its limits (i.e., = depends on trust of downstream entities to anonymize privacy-marked = entries). Also there should probably be some discussion on strength of = anonymization algorithms (unless we are indeed prescribing = anonymous@anonymous.invalid). Agree that text should be added.=20 >=20 > 13. Section 10.2: > "This document defines a priv-value for the SIP Privacy header: > history The following changes have been made to > http://www.iana.org/assignments/sip-priv-values The following has > been added to the registration for the SIP Privacy header:" > I am not sure how to parse this. > =20 >=20 > 14. Section 12.1: > "This specification adds an > optional SIP header field parameter to the History-Info and Contact > headers. " > In fact it adds two parameters to each. Indeed.=20 >=20 > 15. "Entities that have not implemented this specification MUST > ignore these parameters, " > We cannot place a normative requirement on entities that don't = implement this. Change "MUST" to "will". Agree.=20 >=20 > John >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From sunerok@hotmail.com Sat Nov 6 23:30:55 2010 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 BE7133A67DB for ; Sat, 6 Nov 2010 23:30:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.502 X-Spam-Level: *** X-Spam-Status: No, score=3.502 tagged_above=-999 required=5 tests=[BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3] 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 qjKA8XUjiHLP for ; Sat, 6 Nov 2010 23:30:55 -0700 (PDT) Received: from blu0-omc1-s23.blu0.hotmail.com (blu0-omc1-s23.blu0.hotmail.com [65.55.116.34]) by core3.amsl.com (Postfix) with ESMTP id 1381C3A67FD for ; Sat, 6 Nov 2010 23:30:55 -0700 (PDT) Received: from BLU112-W14 ([65.55.116.9]) by blu0-omc1-s23.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.4675); Sat, 6 Nov 2010 23:31:12 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_ccb5dee0-8789-44a1-b558-c440fc6d3fb7_" X-Originating-IP: [130.129.114.51] From: =?gb2312?B?y+/V8buq?= To: Date: Sun, 7 Nov 2010 14:31:12 +0800 Importance: Normal MIME-Version: 1.0 X-OriginalArrivalTime: 07 Nov 2010 06:31:12.0374 (UTC) FILETIME=[5F1C8960:01CB7E45] Subject: [sipcore] Difference between Sipcore and Sip 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: Sun, 07 Nov 2010 06:32:13 -0000 --_ccb5dee0-8789-44a1-b558-c440fc6d3fb7_ Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Is Sip WG is still underwork ? Or is there any difference about the work in Sip WG and SipCore WG? --_ccb5dee0-8789-44a1-b558-c440fc6d3fb7_ Content-Type: text/html; charset="gb2312" Content-Transfer-Encoding: 8bit Is Sip WG is still underwork ? Or is there any difference about the work in Sip WG and SipCore WG?
--_ccb5dee0-8789-44a1-b558-c440fc6d3fb7_-- From pkyzivat@cisco.com Sat Nov 6 23:35:10 2010 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 5D4743A69CF for ; Sat, 6 Nov 2010 23:35:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.449 X-Spam-Level: X-Spam-Status: No, score=-110.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 i+vcDRRRsBTh for ; Sat, 6 Nov 2010 23:35:07 -0700 (PDT) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 3DBB03A69C1 for ; Sat, 6 Nov 2010 23:35:07 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMFAOvl1UxAaMHG/2dsb2JhbACUCo1/cZ8pmkSFSASEWIV9gwo X-IronPort-AV: E=Sophos;i="4.58,309,1286150400"; d="scan'208";a="282117943" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-5.cisco.com with ESMTP; 07 Nov 2010 06:35:21 +0000 Received: from [10.75.235.198] (hkidc-vpn-client-235-198.cisco.com [10.75.235.198]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA76ZIqB015204 for ; Sun, 7 Nov 2010 06:35:20 GMT Message-ID: <4CD648A4.60301@cisco.com> Date: Sun, 07 Nov 2010 01:35:16 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: sipcore@ietf.org References: <0CDF97F6-E125-45F8-B266-65E79BAE6F1A@acmepacket.com> In-Reply-To: <0CDF97F6-E125-45F8-B266-65E79BAE6F1A@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Editorial comments on 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: Sun, 07 Nov 2010 06:35:10 -0000 On 11/6/2010 11:48 PM, Hadriel Kaplan wrote: > 5) Section 7.1 says: "...plus NOTIFY requests that initiate a dialog." Ummm... what type of NOTIFY requests would those be?? (other than proprietary) Actually, that raises a question - can this appear in proprietary methods? In case of forking, NOTIFY requests can initiate a dialog. And with 3256bis dialogs are *always* initiated by NOTIFY. Thanks, Paul From keith.drage@alcatel-lucent.com Sat Nov 6 23:39:16 2010 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 A691E3A69C0 for ; Sat, 6 Nov 2010 23:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.973 X-Spam-Level: X-Spam-Status: No, score=-104.973 tagged_above=-999 required=5 tests=[AWL=-0.776, BAYES_00=-2.599, HELO_EQ_FR=0.35, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, RCVD_IN_DNSWL_MED=-4, 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 jTG1fWSeCuOu for ; Sat, 6 Nov 2010 23:39:16 -0700 (PDT) Received: from smail5.alcatel.fr (smail5.alcatel.fr [64.208.49.27]) by core3.amsl.com (Postfix) with ESMTP id B15FC3A67FD for ; Sat, 6 Nov 2010 23:39:15 -0700 (PDT) Received: from FRMRSSXCHHUB03.dc-m.alcatel-lucent.com (FRMRSSXCHHUB03.dc-m.alcatel-lucent.com [135.120.45.63]) by smail5.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oA76dUoe004598 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Sun, 7 Nov 2010 07:39:30 +0100 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.44]) by FRMRSSXCHHUB03.dc-m.alcatel-lucent.com ([135.120.45.63]) with mapi; Sun, 7 Nov 2010 07:39:30 +0100 From: "DRAGE, Keith (Keith)" To: =?gb2312?B?y+/V8buq?= , "sipcore@ietf.org" Date: Sun, 7 Nov 2010 07:39:27 +0100 Thread-Topic: [sipcore] Difference between Sipcore and Sip Thread-Index: Act+RZNhCdlmrTSTQC6YJdRXbrkMWgAAJ67A Message-ID: References: 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="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.13 Subject: Re: [sipcore] Difference between Sipcore and Sip 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: Sun, 07 Nov 2010 06:39:16 -0000 VGhlIFNJUCB3b3JraW5nIGdyb3VwIGlzIGZvcm1hbGx5IGNsb3NlZC4NCg0KVGhlcmUgYXJlIHN0 aWxsIGEgZmV3IFNJUCBXRyBkcmFmdHMgZ29pbmcgdGhyb3VnaCBJRVNHIGJ1dCBubyBuZXcgd29y ayBpcyBiZWluZyBjb25kdWN0ZWQuDQoNClRoZSBtYWlsaW5nIGxpc3QgcmVtYWlucyBvcGVuLCBi dXQgaXQgaXMgcHJpbWFyaWx5IG9wZW4gdG8gY292ZXIgYW55IGRpc2N1c3Npb25zIG9uIHRob3Nl IHdvcmtpbmcgZ3JvdXAgZHJhZnRzIHdpdGggSUVTRy4NCg0KRG8gbm90ZSB0aGF0IHRoZSBzY29w ZSBvZiBTSVBDT1JFIGlzIGRpZmZlcmVudCBmcm9tIHdoYXQgU0lQIHVzZWQgdG8gYmUuIFNvIGlu IHByb3Bvc2luZyBhbnkgd29yaywgcGxlYXNlIGxvb2sgYXQgdGhlIGNoYXJ0ZXJzIG9mIFNJUENP UkUgYW5kIERJU1BBVENIIHRvIGRlY2lkZSB3aGljaCBpcyB0aGUgbW9zdCBzdWl0YWJsZS4NCg0K cmVnYXJkcw0KDQpLZWl0aA0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoN CglGcm9tOiBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNA aWV0Zi5vcmddIE9uIEJlaGFsZiBPZiA/Pz8NCglTZW50OiBTdW5kYXksIE5vdmVtYmVyIDA3LCAy MDEwIDY6MzEgQU0NCglUbzogc2lwY29yZUBpZXRmLm9yZw0KCVN1YmplY3Q6IFtzaXBjb3JlXSBE aWZmZXJlbmNlIGJldHdlZW4gU2lwY29yZSBhbmQgU2lwDQoJDQoJDQoJSXMgU2lwIFdHIGlzIHN0 aWxsIHVuZGVyd29yayA/IE9yIGlzIHRoZXJlIGFueSBkaWZmZXJlbmNlIGFib3V0IHRoZSB3b3Jr IGluIFNpcCBXRyBhbmQgU2lwQ29yZSBXRz8NCgkNCg0K From pkyzivat@cisco.com Sun Nov 7 00:05:52 2010 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 1A1A23A69CE for ; Sun, 7 Nov 2010 00:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.479 X-Spam-Level: X-Spam-Status: No, score=-110.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 XPoNKrp1z+xq for ; Sun, 7 Nov 2010 00:05:51 -0700 (PDT) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 788503A69DB for ; Sun, 7 Nov 2010 00:05:51 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEbs1UxAaMHG/2dsb2JhbACiCXGfF5pHhUgEhFiFfYMK X-IronPort-AV: E=Sophos;i="4.58,309,1286150400"; d="scan'208";a="615884555" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-6.cisco.com with ESMTP; 07 Nov 2010 07:06:08 +0000 Received: from [10.75.235.198] (hkidc-vpn-client-235-198.cisco.com [10.75.235.198]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA7764nL019324; Sun, 7 Nov 2010 07:06:06 GMT Message-ID: <4CD64FDA.7070808@cisco.com> Date: Sun, 07 Nov 2010 02:06:02 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [sipcore] SIPCORE breakout for discussion of 4244bis - Monday 3:10-4:10 Pearl room 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: Sun, 07 Nov 2010 07:05:52 -0000 The martini wg gave up their Monday session, leaving a room open. Some have expressed a desire for more time to discuss 4244bis, so we are slotting a breakout session for that purpose in the Pearl room on Monday afternoon session 2 from 3:10-4:10 (1510-1610). This is breakout talk time. We won't be transacting any formal business. Thanks, Paul (as co-chair) From HKaplan@acmepacket.com Sun Nov 7 04:26:55 2010 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 C558228C0F5 for ; Sun, 7 Nov 2010 04:26:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.205 X-Spam-Level: X-Spam-Status: No, score=-2.205 tagged_above=-999 required=5 tests=[AWL=0.395, BAYES_00=-2.599] 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 mEZXQV03dPIB for ; Sun, 7 Nov 2010 04:26:53 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A299A3A6883 for ; Sun, 7 Nov 2010 04:26:53 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sun, 7 Nov 2010 07:27:08 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 7 Nov 2010 07:27:07 -0500 From: Hadriel Kaplan To: Paul Kyzivat Date: Sun, 7 Nov 2010 07:26:56 -0500 Thread-Topic: [sipcore] Editorial comments on rfc4244bis-02 Thread-Index: Act+dxTujYLghNO7ThOhAcmncOJ47Q== Message-ID: References: <0CDF97F6-E125-45F8-B266-65E79BAE6F1A@acmepacket.com> <4CD648A4.60301@cisco.com> In-Reply-To: <4CD648A4.60301@cisco.com> 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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Editorial comments on 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: Sun, 07 Nov 2010 12:26:55 -0000 True, I forgot about the forked case... but I don't think that's what they'= re talking about here, since regardless it's in the reverse direction towar= ds the UAC and follows the SUBSCRIBE's (or REFER's) route set. Or is the i= ntent to use H-I for requests from the UAS to the UAC as well, in which cas= e why isn't it used in in-dialog requests? (I don't see the point of it, bu= t that's never stopped us before ;) -hadriel On Nov 7, 2010, at 1:35 AM, Paul Kyzivat wrote: > On 11/6/2010 11:48 PM, Hadriel Kaplan wrote: >=20 >> 5) Section 7.1 says: "...plus NOTIFY requests that initiate a dialog." = Ummm... what type of NOTIFY requests would those be?? (other than proprieta= ry) Actually, that raises a question - can this appear in proprietary meth= ods? >=20 > In case of forking, NOTIFY requests can initiate a dialog. > And with 3256bis dialogs are *always* initiated by NOTIFY. >=20 > Thanks, > Paul > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Sun Nov 7 07:04:54 2010 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 3DFEB3A67AD for ; Sun, 7 Nov 2010 07:04:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.524 X-Spam-Level: X-Spam-Status: No, score=-110.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 L8dnyJthHtjk for ; Sun, 7 Nov 2010 07:04:53 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 13A4F3A6784 for ; Sun, 7 Nov 2010 07:04:53 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALlO1kxAaMHG/2dsb2JhbACiCnGdX5pKgnGCVwSEWIV9gwo X-IronPort-AV: E=Sophos;i="4.58,310,1286150400"; d="scan'208";a="616008309" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-6.cisco.com with ESMTP; 07 Nov 2010 15:05:11 +0000 Received: from [10.75.235.198] (hkidc-vpn-client-235-198.cisco.com [10.75.235.198]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA7F56OF010554 for ; Sun, 7 Nov 2010 15:05:08 GMT Message-ID: <4CD6C020.7030603@cisco.com> Date: Sun, 07 Nov 2010 10:05:04 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] 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: Sun, 07 Nov 2010 15:04:54 -0000 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 From pkyzivat@cisco.com Sun Nov 7 07:11:48 2010 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 DBD063A67B1 for ; Sun, 7 Nov 2010 07:11:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.532 X-Spam-Level: X-Spam-Status: No, score=-110.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 0qh8IV9XWp64 for ; Sun, 7 Nov 2010 07:11:47 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C4CA73A67AD for ; Sun, 7 Nov 2010 07:11:47 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AsMFABdQ1kxAaMHG/2dsb2JhbACUC41/cZ1bmkqFSASEWIV9gwo X-IronPort-AV: E=Sophos;i="4.58,310,1286150400"; d="scan'208";a="616010153" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-6.cisco.com with ESMTP; 07 Nov 2010 15:12:05 +0000 Received: from [10.75.235.198] (hkidc-vpn-client-235-198.cisco.com [10.75.235.198]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA7FC2MX011044 for ; Sun, 7 Nov 2010 15:12:04 GMT Message-ID: <4CD6C1C0.5000909@cisco.com> Date: Sun, 07 Nov 2010 10:12:00 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: sipcore@ietf.org References: <4C69ADA8.1010802@nostrum.com> <4C753AAA.3030407@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis 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: Sun, 07 Nov 2010 15:11:49 -0000 On 11/2/2010 3:50 PM, Mary Barnes wrote: >>>> Does this include 100 responses? >>> [MB] I would think so. Can you think of a reason why it shouldn't? I>> would think it could be useful for debug. [/MB] >> [JRE] The 100 response typically only travels back a single hop, so the benefit of H-I in a 100 is marginal. Also some implementations might send back a 100 response quite early during processing, perhaps even before they decide whether to act as a proxy, a UAS or a redirect, so knowing how to populate H-I in a 100 might be difficult. > [MB2] If it has no additional hi-entries, then there is nothing > additional to send back, so I don't think it hurts anything - I would > agree that in most cases it's of marginal value. We can include it as > an exception in that sentence if you would prefer, although per the > next comment, it seems that you are okay with leaving it as is. > [/MB2] IMO its unreasonable to expect the server to include *any* H-I in the 100 response. As Hadriel mentioned, 100 is often sent from a "lower" layer of the stack, perhaps before the message has been fully parsed. IMO H-I MAY be present in 100 responses, and SHOULD be ignored by the recipient if present. Since ignored, there should be no requirement on what content the H-I is to have in that case. Thanks, Paul From pkyzivat@cisco.com Sun Nov 7 07:35:36 2010 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 915C53A67D4 for ; Sun, 7 Nov 2010 07:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.539 X-Spam-Level: X-Spam-Status: No, score=-110.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 d9-hnqjldQ84 for ; Sun, 7 Nov 2010 07:35:35 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 529D33A679C for ; Sun, 7 Nov 2010 07:35:35 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALZV1kxAaMHG/2dsb2JhbACiCnGdappLhUgEhFiFfYMK X-IronPort-AV: E=Sophos;i="4.58,310,1286150400"; d="scan'208";a="289516993" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-2.cisco.com with ESMTP; 07 Nov 2010 15:35:53 +0000 Received: from [10.75.235.198] (hkidc-vpn-client-235-198.cisco.com [10.75.235.198]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA7FZn2T013774; Sun, 7 Nov 2010 15:35:51 GMT Message-ID: <4CD6C753.7010807@cisco.com> Date: Sun, 07 Nov 2010 10:35:47 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: Hadriel Kaplan References: <0CDF97F6-E125-45F8-B266-65E79BAE6F1A@acmepacket.com> <4CD648A4.60301@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Editorial comments on 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: Sun, 07 Nov 2010 15:35:36 -0000 On 11/7/2010 7:26 AM, Hadriel Kaplan wrote: > > True, I forgot about the forked case... but I don't think that's what they're talking about here, since regardless it's in the reverse direction towards the UAC and follows the SUBSCRIBE's (or REFER's) route set. Or is the intent to use H-I for requests from the UAS to the UAC as well, in which case why isn't it used in in-dialog requests? (I don't see the point of it, but that's never stopped us before ;) Sorry - I did just reply narrowly. You are right - every NOTIFY, even the "dialog initiating" ones are requests that are "in dialog" and hence AFAIK don't get H-I in them, nor AFAIK can they affect the H-I of the SUBSCRIBE or REFER that caused them. Thanks, Paul > -hadriel > > > On Nov 7, 2010, at 1:35 AM, Paul Kyzivat wrote: > >> On 11/6/2010 11:48 PM, Hadriel Kaplan wrote: >> >>> 5) Section 7.1 says: "...plus NOTIFY requests that initiate a dialog." Ummm... what type of NOTIFY requests would those be?? (other than proprietary) Actually, that raises a question - can this appear in proprietary methods? >> >> In case of forking, NOTIFY requests can initiate a dialog. >> And with 3256bis dialogs are *always* initiated by NOTIFY. >> >> Thanks, >> Paul >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > From mary.ietf.barnes@gmail.com Sun Nov 7 15:39:49 2010 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 1482328C113 for ; Sun, 7 Nov 2010 15:39:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 PRQT4uhgKQNu for ; Sun, 7 Nov 2010 15:39:15 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 53B573A6921 for ; Sun, 7 Nov 2010 15:38:56 -0800 (PST) Received: by gwb15 with SMTP id 15so3351609gwb.31 for ; Sun, 07 Nov 2010 15:39:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=pspVrw5oZ5hVIXtYIEmhThAxQTmPYW5hMvaJpdrJww0=; b=BZw+DEPKSRCFVL03MtWBIAxy+dlmqOZNeERhfwcDtzvsUQnqbst4ZzwThx3Qi1mQyT lv2NNTB11WM/5cnveFzx2nYO0EOt1tSl4CwAajNQxNulALajbQpMWGJN6/iXCTL8KNYX 7dqP4ubkfx+okqKarVSKbjEOn7ht5aXdmM1z8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=Badny8QTq/fMYjJCpqhgaEUABG+7NFW9SBl7kjtBge2GWWvA8uvddLps+H4ZInmQKW hoAdrVylUTt9bwF3WOcFkETgdYfJPX0nNH7yV6JGyrBzuY6j5pbSy6JYevPoNd8LKmME /fFl+87ysJXF/pdH63lsTzfo0FKpLbC8zk4jA= MIME-Version: 1.0 Received: by 10.150.50.4 with SMTP id x4mr7458866ybx.90.1289173155783; Sun, 07 Nov 2010 15:39:15 -0800 (PST) Received: by 10.236.95.35 with HTTP; Sun, 7 Nov 2010 15:39:15 -0800 (PST) In-Reply-To: <4CD6C020.7030603@cisco.com> References: <4CD6C020.7030603@cisco.com> Date: Sun, 7 Nov 2010 17:39:15 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sipcore@ietf.org Subject: Re: [sipcore] 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: Sun, 07 Nov 2010 23:39:49 -0000 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. 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. 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. 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. 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, sometim= es 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 >>> =A0 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 gue= ss >>> the first interpretation is more plausible, but why not say what is mea= nt, >>> 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. =A0It is >> added by the entity receiving the response. =A0Note 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. =A0It's added to the previous. =A0The 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 retargetin= g, > it may be that a retarget URI would contain URI parameters, and those wou= ld > 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 th= e > 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 ent= ry > 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 UR= I > is being used, so it belongs in the message addressed to that URI. It mak= es > 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 an= d > 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 no= t - > 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* ma= ke > 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 retargete= d. > > This could be fitted into H-I. When retargeting, it could be specified th= at > 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 th= e > H-I entry for that request the R-URI of the request with any Reason heade= rs > 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. > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From HKaplan@acmepacket.com Sun Nov 7 17:04:56 2010 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 6517B3A68EF for ; Sun, 7 Nov 2010 17:04:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.131 X-Spam-Level: X-Spam-Status: No, score=-1.131 tagged_above=-999 required=5 tests=[AWL=-0.636, 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 qBrs8wAet-jr for ; Sun, 7 Nov 2010 17:04:55 -0800 (PST) Received: from ETMail2.acmepacket.com (unknown [216.41.24.9]) by core3.amsl.com (Postfix) with ESMTP id C59233A68AD for ; Sun, 7 Nov 2010 17:04:54 -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; Sun, 7 Nov 2010 20:05:14 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 7 Nov 2010 20:05:14 -0500 From: Hadriel Kaplan To: Paul Kyzivat Date: Sun, 7 Nov 2010 20:05:10 -0500 Thread-Topic: [sipcore] Comments on draft-ietf-sipcore-rfc4244bis-02 Thread-Index: Act+4P8ATsIG0hZbTMW97TxScxTU2g== Message-ID: <455CFB9C-7E64-4147-B517-BA3FC9E91AE7@acmepacket.com> References: <4CD6C020.7030603@cisco.com> In-Reply-To: <4CD6C020.7030603@cisco.com> 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] 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 01:04:56 -0000 Yes, it sucks. And it's wrong. I raised it last year here: http://www.ietf.org/mail-archive/web/sipcore/current/msg00612.html But we're stuck with it for backwards compatibility. And it's even worse than you think. Apparently 3gpp uses H-I with a "cause= " URI param a la RFC 4458, rather than an embedded Reason header's cause pa= ram. On the other hand all of this will help me sell more boxes, so I think I'll= shut up now... -hadriel On Nov 7, 2010, at 10: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... >> [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 exa= mple 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 r= ecipient of Reason MUST associate it with an hi-targeted-to-uri. I guess th= e first interpretation is more plausible, but why not say what is meant, ra= ther 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] >=20 > I guess this isn't a new concern - its been there all along, but it=20 > 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= =20 > and an H-I entry containing a URI that contains a Reason header as a URI= =20 > parameter. A URI parameter has a specific meaning - it specifies a=20 > Header that is to be incorporated into a request that uses that URI as=20 > an R-URI. >=20 > Depending on details of how H-I entries are constructed during=20 > retargeting, it may be that a retarget URI would contain URI parameters,= =20 > and those would end up in an H-I entry. There could be a Reason header=20 > included in the retarget URI. I *think* the procedures for UAC and proxy= =20 > imply that the retargeted request would be constructed first - thus=20 > removing embedded parameters and making them headers in the request -=20 > *before* capturing the R-URI for H-I, but I'm not certain of that. If=20 > not, then there could be ambiguity about the origin and meaning of a=20 > Reason header in an H-I URI. >=20 > Even if that is not a problem, there are potential problems if an H-I=20 > entry is ever used to construct a new request. For instance, if someone=20 > were to analyze H-I to identify the URI of some entity (say the caller)=20 > in order to send a new request there, it would lift the URI from H-I and= =20 > put it into a new request. Then the Reason URI parameter would,=20 > according to 3261, be removed and be added as a header to that new=20 > request. That isn't catastrophic, but I think its at least misleading,=20 > because: >=20 > The reason is on the wrong URI. The Reason explains why the retargeted=20 > URI is being used, so it belongs in the message addressed to that URI.=20 > It makes no sense that it be in a request to the R-URI that, in some=20 > prior usage, was eventually retargeted. >=20 > Bottom line: the H-I use of Reason as a URI header parameter is a hack=20 > and an abuse of that mechanism. It might be benign and forgivable if it=20 > were consistent with the intended use of that mechanism. But it seems it= =20 > is not - that it is at best the re-purposing of that mechanism in a case= =20 > where it, arguably, might be thought not to conflict with legitimate use= =20 > of the URI header parameter mechanism. I'll argue it isn't that benign -= =20 > that there are overlaps where the uses overlap. >=20 > H-I should have had its own header field parameter for this purpose -=20 > not use the Reason header. >=20 > This has ripple effects. Now we have=20 > draft-mohali-sipcore-reason-call-forwarding which is defining new reason= =20 > codes which are intended specifically for use with H-I, without any=20 > contemplation of their use in a real Reason header in a request. This is= =20 > insanity - but not for the author who is just trying to work within the=20 > existing system. Its just an example of the mess created by the abuse of= =20 > repurposing Reason within H-I. >=20 > I commented to the author of draft-mohali-sipcore-reason-call-forwarding= =20 > that I felt any extensions to Reason needed to be justified in their own= =20 > right, without reference to H-I. In fact what is proposed there *does*=20 > make sense in its own right, without regard to H-I *if* it is used in=20 > the retargeted request, rather than the request that is about to be=20 > retargeted. >=20 > This could be fitted into H-I. When retargeting, it could be specified=20 > that a Reason header should be added to the new request, explaining why=20 > it was retargeted. Then whoever makes the H-I entry for that could=20 > include in the H-I entry for that request the R-URI of the request with=20 > any Reason headers in that request added to the entry as URI parameters.= =20 > However this would be incompatible with 4244 because it would change=20 > which entry contains the reason. >=20 > Thanks, > Paul > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Sun Nov 7 17:22:18 2010 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 640833A67B1 for ; Sun, 7 Nov 2010 17:22:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.544 X-Spam-Level: X-Spam-Status: No, score=-110.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 s0CoefkQqBj4 for ; Sun, 7 Nov 2010 17:22:15 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 1C0553A68A5 for ; Sun, 7 Nov 2010 17:22:15 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAIff1kxAaMHG/2dsb2JhbACiBXGfJ5pignGCVwSEWIV9gwo X-IronPort-AV: E=Sophos;i="4.58,311,1286150400"; d="scan'208";a="282299885" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-5.cisco.com with ESMTP; 08 Nov 2010 01:22:34 +0000 Received: from [10.75.234.6] (hkidc-vpn-client-234-6.cisco.com [10.75.234.6]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA81MSln020945; Mon, 8 Nov 2010 01:22:30 GMT Message-ID: <4CD750D2.6020500@cisco.com> Date: Sun, 07 Nov 2010 20:22:26 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: Hadriel Kaplan References: <4CD6C020.7030603@cisco.com> <455CFB9C-7E64-4147-B517-BA3FC9E91AE7@acmepacket.com> In-Reply-To: <455CFB9C-7E64-4147-B517-BA3FC9E91AE7@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] 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 01:22:18 -0000 Hadriel, OK, I guess I'm way late on this. This bis is a chance to fix problems isn't it? We should at least talk about the problems and see if we can figure some way around them. We may have to grandfather some behavior, but couldn't we define a better alternative and deprecate the broken stuff? And if 3gpp is doing something that isn't even consistent with 4244, that is *their* problem, and Acme's opportunity. Thanks, Paul On 11/7/2010 8:05 PM, Hadriel Kaplan wrote: > > Yes, it sucks. And it's wrong. I raised it last year here: > http://www.ietf.org/mail-archive/web/sipcore/current/msg00612.html > > But we're stuck with it for backwards compatibility. > > And it's even worse than you think. Apparently 3gpp uses H-I with a "cause" URI param a la RFC 4458, rather than an embedded Reason header's cause param. > > On the other hand all of this will help me sell more boxes, so I think I'll shut up now... > > -hadriel > > On Nov 7, 2010, at 10: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@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > > From jon.peterson@neustar.biz Sun Nov 7 17:35:49 2010 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 044C628C0DC for ; Sun, 7 Nov 2010 17:35:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.58 X-Spam-Level: X-Spam-Status: No, score=-101.58 tagged_above=-999 required=5 tests=[AWL=0.465, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, 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 R5aFXQ4qoQbM for ; Sun, 7 Nov 2010 17:35:43 -0800 (PST) Received: from neustar.com (keys.neustar.biz [156.154.17.104]) by core3.amsl.com (Postfix) with ESMTP id 988E33A691F for ; Sun, 7 Nov 2010 17:35:42 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1289180065; x=1604174761; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=T57k13XLjL70QJlm1UGWyV001Coo8MJEXssOCQbQhhY=; b=OIUTOlIUtJLaMTH15VYYToU6rJ5knF5q3C0ZKnfbHeVDMzQRkk2JrCXHa53Dor +ORgr8yDdtAzyOacgc2LSNKA== Received: from ([10.31.13.229]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.39166658; Sun, 07 Nov 2010 20:34:24 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Sun, 7 Nov 2010 20:34:24 -0500 From: "Peterson, Jon" To: "Elwell, John" , "DRAGE, Keith (Keith)" , "hannu.hietalahti@nokia.com" , "rbarnes@bbn.com" , "jmpolk@cisco.com" Date: Sun, 7 Nov 2010 20:34:20 -0500 Thread-Topic: [sipcore] Location Conveyance -04 submitted, here's the changes Thread-Index: Act2mlVdTb0CvQzFTY2pDhKiRuhu2gAAtZtwAMcwGpAAFNySEACOdTlgABbnWwAABXISYACLHd3L Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 3RusJ+47u/ySbnTlIRzzpw== Content-Type: multipart/alternative; boundary="_000_C8FD749C47D22jonpetersonneustarbiz_" MIME-Version: 1.0 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes 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 01:35:49 -0000 --_000_C8FD749C47D22jonpetersonneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I don't think the draft can do anything more helpful than say you shouldn't= include multiple location objects because they are confusing, and if you d= o permit multiple location objects, do so only in an environment where the = inserter and recipient share some agreement about their meaning and interpr= etation (a slight expansion of "you break it you bought it," there). I don'= t think it will be a useful or successful exercise for us to try to concret= ize that in a standard. Jon Peterson NeuStar, Inc. On 11/5/10 12:22 AM, "Elwell, John" wr= ote: Yes, I agree that replacing an enterprise-provided location is very bad. Th= e problem with adding locations to locations already present is how the PSA= P chooses between 2 or even 3 locations. From my reading of the draft, we d= on't have any normative statement on the order in which locations are place= d in the header. If we had a rule that the first locationValue within a sin= gle or multiple Geolocation header fields is nearest to the source of the r= equest, and so on, it might help. Then it would be clear that the service p= rovider-provided location would be the least reliable, but it would still b= e there, e.g., for use if the other locations are bogus. John > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Sent: 05 November 2010 04:37 > To: Elwell, John; hannu.hietalahti@nokia.com; > rbarnes@bbn.com; jmpolk@cisco.com > Cc: sipcore@ietf.org > Subject: RE: [sipcore] Location Conveyance -04 submitted, > here's the changes > > Exactly, that is why I am saying you need multiples. > > Otherwise the scenario is that the PBX puts one in, and the > public network then replaces it because it says the regulator > tells the network to always provide a location. At least with > my approach, all the locations are there, and the PSAP then > sorts it out. > > Keith > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Thursday, November 04, 2010 5:48 PM > > To: DRAGE, Keith (Keith); hannu.hietalahti@nokia.com; > > rbarnes@bbn.com; jmpolk@cisco.com > > Cc: sipcore@ietf.org > > Subject: RE: [sipcore] Location Conveyance -04 submitted, > > here's the changes > > > > Keith, > > > > Be very careful with this sort of approach. The trend is > > towards fewer SIP-PBXs and fewer "SIP trunks" serving an > > enterprise, with often a single SIP-PBX and a single entry > > into the SIP Service Provider for a whole country or even > > multiple countries. Even for the single country case, the > > service provider network is unlikely to have a clue as to > > where, in the country, the caller might be located (or even > > where the PBX is located if there are two geographically > > separate servers). Caller ID isn't likely to help either, > > since users can move around within the enterprise network. > > > > John > > > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE, > Keith (Keith) > > > Sent: 01 November 2010 23:04 > > > To: hannu.hietalahti@nokia.com; rbarnes@bbn.com; jmpolk@cisco.com > > > Cc: sipcore@ietf.org > > > Subject: Re: [sipcore] Location Conveyance -04 submitted, > > here's the > > > changes > > > > > > If in 3GPP we look at subscription based business trunking > > > arrangement. > > > > > > The end terminal includes one location. > > > > > > The enterprise network supporting the UE adds its own > view of where > > > the UE is. > > > > > > The public network adds its own view of the location. > > > > > > That makes three. > > > > > > regards > > > > > > Keith > > > > > > > -----Original Message----- > > > > From: hannu.hietalahti@nokia.com > > > [mailto:hannu.hietalahti@nokia.com] > > > > Sent: Monday, November 01, 2010 11:46 AM > > > > To: DRAGE, Keith (Keith); rbarnes@bbn.com; jmpolk@cisco.com > > > > Cc: sipcore@ietf.org > > > > Subject: RE: [sipcore] Location Conveyance -04 submitted, > > here's the > > > > changes > > > > > > > > Hi Keith, > > > > > > > > yes, I remember you made this comment at Maastricht > > already, and I > > > > agree with you that from 3GPP viewpoint we need encoding > > that allows > > > > *more than one* piece of location information. > > > > > > > > In 3GPP case those would be typically the one obtained from the > > > > terminal and the one added by the serving network if it > thinks it > > > > knows better. > > > > > > > > But my imagination runs out after these two. Are you > > saying we need > > > > more than 2? > > > > > > > > BR, > > > > Hannu Hietalahti > > > > 3GPP TSG CT Chairman > > > > tel: +358 40 5021724 > > > > > > > > > > > > >-----Original Message----- > > > > >From: sipcore-bounces@ietf.org > > > > >[mailto:sipcore-bounces@ietf.org] On Behalf Of ext DRAGE, > > > > Keith (Keith) > > > > >Sent: 28 October, 2010 16:01 > > > > >To: Richard L. Barnes; James M. Polk > > > > >Cc: sipcore@ietf.org > > > > >Subject: Re: [sipcore] Location Conveyance -04 submitted, > > > here's the > > > > >changes > > > > > > > > > >To be more specific - we had a document that allowed multiple > > > > >locations. It was reduced to one without any decision in > > > > that direction > > > > >being made by the working group. It needs to go back > to multiple > > > > >values. > > > > > > > > > >In my view there are clear use cases where multiple values are > > > > >required. > > > > > > > > > >regards > > > > > > > > > >Keith > > > > > > > > > >> -----Original Message----- > > > > >> From: sipcore-bounces@ietf.org > > > > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Richard > > L. Barnes > > > > >> Sent: Thursday, October 28, 2010 1:19 PM > > > > >> To: James M. Polk > > > > >> Cc: sipcore@ietf.org > > > > >> Subject: Re: [sipcore] Location Conveyance -04 submitted, > > > > here's the > > > > >> changes > > > > >> > > > > >> >> I'm pretty comfortable with the document at this point, > > > > >> but have just > > > > >> >> one minor question: Why are you still limiting the number > > > > >> of location > > > > >> >> values? Why are three values harmful, but not two? This > > > > >> still seems > > > > >> >> like pointless ABNF legislation. > > > > >> > > > > > >> > we only added the ability to have a second locationValue > > > > >because of > > > > >> > your rough-loc ID. Before that, we were firm in not > > > > >> allowing more than > > > > >> > one. Given that choice, which do you like? > > > > >> > > > > > >> > Remember, this was Jon's proposal in SIPCORE in Anaheim, > > > > which it > > > > >> > seemed everyone and their brother was agreeable > with, so ... > > > > >> > > > > >> > > > > >> As I recall, the proposal was to just remove the limit on > > > > >the number > > > > >> of locations values, not to bump it up by one. From > > the minutes: > > > > >> > > > > >> "Restore Geolocation header that has multiple URIs, even > > > though we > > > > >> would not recommend it. Entities inserting persence are > > > > responsbile > > > > >> for any resulting errors. The header parameters > > > > distinguishing URIs > > > > >> would not be added back in." > > > > >> > > > > >> At least in my mind, multiple !=3D 2. > > > > >> > > > > >> --Richard > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > james > > > > >> > > > > > >> > > > > > >> >> --Richard > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> On Oct 27, 2010, at 12:32 AM, James M. Polk wrote: > > > > >> >> > > > > >> >>> SIPCORE > > > > >> >>> > > > > >> >>> I've submitted the next version of Location > > Conveyance (-04) > > > > >> >>> > > > > >> > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio > > > > >> n-conveyance-04.txt > > > > >> >>> and I believe this version has addressed each open > > > > item from the > > > > >> >>> mailing list, as well as what was discussed and agreed > > > > to in the > > > > >> >>> Maastricht meeting. > > > > >> >>> > > > > >> >>> I have attempted to identify each open issue with > > > the specific > > > > >> >>> resolution here (in no particular order): > > > > >> >>> > > > > >> >>> - Martin wanted Section 3 to be broken up into > > > > subsections, each > > > > >> >>> revolving around each of the 4 diagrams. I have > done this. > > > > >> >>> > > > > >> >>> - allowed a maximum of two (up from one) > > > locationValues to be > > > > >> >>> present in the Geolocation header value. The text however > > > > >> recommends > > > > >> >>> against inserting a second value. This was agreed to in > > > > >> Maastricht. > > > > >> >>> > > > > >> >>> - Because we're allowing a max of two locationValues, > > > > >> they can be in > > > > >> >>> separate Geolocation headers in the SIP request. > > > This scenario > > > > >> >>> necessitates bring a previous version's paragraph in > > > > >> stating that a > > > > >> >>> 'SIP intermediary MUST inspect all instances of each > > > > Geolocation > > > > >> >>> header before considering the routing-allowed > > > parameter to be > > > > >> >>> considered =3Dyes', to ensure there isn't a conflict in > > > > the 'other' > > > > >> >>> Geolocation header that states the policy is =3Dno. > > > > >> >>> > > > > >> >>> - with the ability to add a second locationValue, it is > > > > >> necessary to > > > > >> >>> warn against doing this (confusion at the LRs). > > > > >> >>> > > > > >> >>> - Added the "you break it you bought it" > philosophy to SIP > > > > >> >>> intermediaries that choose to insert a second location > > > > where one > > > > >> >>> already existed, especially for inserting a location > > > > URI in the > > > > >> >>> downstream SIP request. > > > > >> >>> > > > > >> >>> - Fixed the ABNF to handle zero, one or two (but > no more) > > > > >> >>> locationValues according to the agreement in Maastricht. > > > > >> There is a > > > > >> >>> one-off use case which won't be in play very often, but > > > > >> is a WG item > > > > >> >>> in ECRIT that several wanted to allow the possibility for > > > > >> (inv --_000_C8FD749C47D22jonpetersonneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [sipcore] Location Conveyance -04 submitted, here's the  ch= anges
I don’t think the draft can do anything more helpful than say you sho= uldn’t include multiple location objects because they are confusing, = and if you do permit multiple location objects, do so only in an environmen= t where the inserter and recipient share some agreement about their meaning= and interpretation (a slight expansion of “you break it you bought i= t,” there). I don’t think it will be a useful or successful exe= rcise for us to try to concretize that in a standard.

Jon Peterson
NeuStar, Inc.


On 11/5/10 12:22 AM, "Elwell, John" <john.elwell@siemens-enterprise.com> wrote:

Yes, I agree that replacing an enterprise-p= rovided location is very bad. The problem with adding locations to location= s already present is how the PSAP chooses between 2 or even 3 locations. Fr= om my reading of the draft, we don't have any normative statement on the or= der in which locations are placed in the header. If we had a rule that the = first locationValue within a single or multiple Geolocation header fields i= s nearest to the source of the request, and so on, it might help. Then it w= ould be clear that the service provider-provided location would be the leas= t reliable, but it would still be there, e.g., for use if the other locatio= ns are bogus.

John

> -----Original Message-----
> From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com]
> Sent: 05 November 2010 04:37
> To: Elwell, John; hannu.hietala= hti@nokia.com;
> rbarnes@bbn.com; jmpolk@cisco.com
> Cc: sipcore@ietf.org
> Subject: RE: [sipcore] Location Conveyance -04 submitted,
> here's the changes
>
> Exactly, that is why I am saying you need multiples.
>
> Otherwise the scenario is that the PBX puts one in, and the
> public network then replaces it because it says the regulator
> tells the network to always provide a location. At least with
> my approach, all the locations are there, and the PSAP then
> sorts it out.
>
> Keith
>
> > -----Original Message-----
> > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]
> > Sent: Thursday, November 04, 2010 5:48 PM
> > To: DRAGE, Keith (Keith); = hannu.hietalahti@nokia.com;
> > rbarnes@bbn.com; jmpolk@cisco.com
> > Cc: sipcore@ietf.org
> > Subject: RE: [sipcore] Location Conveyance -04 submitted,
> > here's the changes
> >
> > Keith,
> >
> > Be very careful with this sort of approach. The trend is
> > towards fewer SIP-PBXs and fewer "SIP trunks" serving a= n
> > enterprise, with often a single SIP-PBX and a single entry
> > into the SIP Service Provider for a whole country or even
> > multiple countries. Even for the single country case, the
> > service provider network is unlikely to have a clue as to
> > where, in the country, the caller might be located (or even
> > where the PBX is located if there are two geographically
> > separate servers). Caller ID isn't likely to help either,
> > since users can move around within the enterprise network.
> >
> > John
> >
> > > -----Original Message-----
> > > From: sipcore-bounces@i= etf.org
> > > [mailto:sipcore-= bounces@ietf.org] On Behalf Of DRAGE,
> Keith (Keith)
> > > Sent: 01 November 2010 23:04
> > > To: hannu.hietalahti@= nokia.com; rbarnes@bbn.com; jmpolk@cisco.com
> > > Cc: sipcore@ietf.org
> > > Subject: Re: [sipcore] Location Conveyance -04 submitted, > > here's the
> > > changes
> > >
> > > If in 3GPP we look at subscription based business trunking > > > arrangement.
> > >
> > > The end terminal includes one location.
> > >
> > > The enterprise network supporting the UE adds its own
> view of where
> > > the UE is.
> > >
> > > The public network adds its own view of the location.
> > >
> > > That makes three.
> > >
> > > regards
> > >
> > > Keith
> > >
> > > > -----Original Message-----
> > > > From: hannu.hiet= alahti@nokia.com
> > > [mailto:hannu.= hietalahti@nokia.com]
> > > > Sent: Monday, November 01, 2010 11:46 AM
> > > > To: DRAGE, Keith (Keith); r= barnes@bbn.com; jmpolk@cisco.com
> > > > Cc: sipcore@ietf.org > > > > Subject: RE: [sipcore] Location Conveyance -04 submitte= d,
> > here's the
> > > > changes
> > > >
> > > > Hi Keith,
> > > >
> > > > yes, I remember you made this comment at Maastricht
> > already, and I
> > > > agree with you that from 3GPP viewpoint we need encodin= g
> > that allows
> > > > *more than one* piece of location information.
> > > >
> > > > In 3GPP case those would be typically the one obtained = from the
> > > > terminal and the one added by the serving network if it=
> thinks it
> > > > knows better.
> > > >
> > > > But my imagination runs out after these two. Are you > > saying we need
> > > > more than 2?
> > > >
> > > > BR,
> > > > Hannu Hietalahti
> > > > 3GPP TSG CT Chairman
> > > > tel: +358 40 5021724
> > > >
> > > >
> > > > >-----Original Message-----
> > > > >From: sipcore-= bounces@ietf.org
> > > > >[mailto= :sipcore-bounces@ietf.org] On Behalf Of ext DRAGE,
> > > > Keith (Keith)
> > > > >Sent: 28 October, 2010 16:01
> > > > >To: Richard L. Barnes; James M. Polk
> > > > >Cc: sipcore@ietf.org
> > > > >Subject: Re: [sipcore] Location Conveyance -04 subm= itted,
> > > here's the
> > > > >changes
> > > > >
> > > > >To be more specific - we had a document that allowe= d multiple
> > > > >locations. It was reduced to one without any decisi= on in
> > > > that direction
> > > > >being made by the working group. It needs to go bac= k
> to multiple
> > > > >values.
> > > > >
> > > > >In my view there are clear use cases where multiple= values are
> > > > >required.
> > > > >
> > > > >regards
> > > > >
> > > > >Keith
> > > > >
> > > > >> -----Original Message-----
> > > > >> From: sip= core-bounces@ietf.org
> > > > >> [m= ailto:sipcore-bounces@ietf.org] On Behalf Of Richard
> > L. Barnes
> > > > >> Sent: Thursday, October 28, 2010 1:19 PM
> > > > >> To: James M. Polk
> > > > >> Cc: sipcore@ietf.= org
> > > > >> Subject: Re: [sipcore] Location Conveyance -04= submitted,
> > > > here's the
> > > > >> changes
> > > > >>
> > > > >> >> I'm pretty comfortable with the docum= ent at this point,
> > > > >> but have just
> > > > >> >> one minor question: Why are you still= limiting the number
> > > > >> of location
> > > > >> >> values?  Why are three values ha= rmful, but not two?  This
> > > > >> still seems
> > > > >> >> like pointless ABNF legislation.
> > > > >> >
> > > > >> > we only added the ability to have a secon= d locationValue
> > > > >because of
> > > > >> > your rough-loc ID. Before that, we were f= irm in not
> > > > >> allowing more than
> > > > >> > one.  Given that choice, which do yo= u like?
> > > > >> >
> > > > >> > Remember, this was Jon's proposal in SIPC= ORE in Anaheim,
> > > > which it
> > > > >> > seemed everyone and their brother was agr= eeable
> with, so ...
> > > > >>
> > > > >>
> > > > >> As I recall, the proposal was to just remove t= he limit on
> > > > >the number
> > > > >> of locations values, not to bump it up by one.=  From
> > the minutes:
> > > > >>
> > > > >> "Restore Geolocation header that has mult= iple URIs, even
> > > though we
> > > > >> would not recommend it. Entities inserting per= sence are
> > > > responsbile
> > > > >> for any resulting errors. The header parameter= s
> > > > distinguishing URIs
> > > > >> would not be added back in."
> > > > >>
> > > > >> At least in my mind, multiple !=3D 2.
> > > > >>
> > > > >> --Richard
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >>
> > > > >> > james
> > > > >> >
> > > > >> >
> > > > >> >> --Richard
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >>
> > > > >> >> On Oct 27, 2010, at 12:32 AM, James M= . Polk wrote:
> > > > >> >>
> > > > >> >>> SIPCORE
> > > > >> >>>
> > > > >> >>> I've submitted the next version o= f Location
> > Conveyance (-04)
> > > > >> >>>
> > > > >>
> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio
> > > > >> n-conveyance-04.txt
> > > > >> >>> and I believe this version has ad= dressed each open
> > > > item from the
> > > > >> >>> mailing list, as well as what was= discussed and agreed
> > > > to in the
> > > > >> >>> Maastricht meeting.
> > > > >> >>>
> > > > >> >>> I have attempted to identify each= open issue with
> > > the specific
> > > > >> >>> resolution here (in no particular= order):
> > > > >> >>>
> > > > >> >>> - Martin wanted Section 3 to be b= roken up into
> > > > subsections, each
> > > > >> >>> revolving around each of the 4 di= agrams. I have
> done this.
> > > > >> >>>
> > > > >> >>> - allowed a maximum of two (up fr= om one)
> > > locationValues to be
> > > > >> >>> present in the Geolocation header= value. The text however
> > > > >> recommends
> > > > >> >>> against inserting a second value.= This was agreed to in
> > > > >> Maastricht.
> > > > >> >>>
> > > > >> >>> - Because we're allowing a max of= two locationValues,
> > > > >> they can be in
> > > > >> >>> separate Geolocation headers in t= he SIP request.
> > > This scenario
> > > > >> >>> necessitates bring a previous ver= sion's paragraph in
> > > > >> stating that a
> > > > >> >>> 'SIP intermediary MUST inspect al= l instances of each
> > > > Geolocation
> > > > >> >>> header before considering the rou= ting-allowed
> > > parameter to be
> > > > >> >>> considered =3Dyes', to ensure the= re isn't a conflict in
> > > > the 'other'
> > > > >> >>> Geolocation header that states th= e policy is =3Dno.
> > > > >> >>>
> > > > >> >>> - with the ability to add a secon= d locationValue, it is
> > > > >> necessary to
> > > > >> >>> warn against doing this (confusio= n at the LRs).
> > > > >> >>>
> > > > >> >>> - Added the "you break it yo= u bought it"
> philosophy to SIP
> > > > >> >>> intermediaries that choose to ins= ert a second location
> > > > where one
> > > > >> >>> already existed, especially for i= nserting a location
> > > > URI in the
> > > > >> >>> downstream SIP request.
> > > > >> >>>
> > > > >> >>> - Fixed the ABNF to handle zero, = one or two (but
> no more)
> > > > >> >>> locationValues according to the a= greement in Maastricht.
> > > > >> There is a
> > > > >> >>> one-off use case which won't be i= n play very often, but
> > > > >> is a WG item
> > > > >> >>> in ECRIT that several wanted to a= llow the possibility for
> > > > >> (inv
--_000_C8FD749C47D22jonpetersonneustarbiz_-- From rbarnes@bbn.com Sun Nov 7 17:37:47 2010 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 A9AA03A6932 for ; Sun, 7 Nov 2010 17:37:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.669 X-Spam-Level: X-Spam-Status: No, score=-102.669 tagged_above=-999 required=5 tests=[AWL=-0.071, BAYES_00=-2.599, 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 jDVfWJ7ph55l for ; Sun, 7 Nov 2010 17:37:38 -0800 (PST) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 2C5E228C0D0 for ; Sun, 7 Nov 2010 17:37:37 -0800 (PST) Received: from [128.89.253.162] (port=52720 helo=richards-MacBook-Pro.local) by smtp.bbn.com with esmtps (TLSv1:CAMELLIA256-SHA:256) (Exim 4.71 (FreeBSD)) (envelope-from ) id 1PFGgB-000614-Iv; Sun, 07 Nov 2010 20:37:52 -0500 Message-ID: <4CD7546A.4090506@bbn.com> Date: Mon, 08 Nov 2010 09:37:46 +0800 From: "Richard L. Barnes" User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Peterson, Jon" References: In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit Cc: "DRAGE, Keith \(Keith\)" , "sipcore@ietf.org" , "hannu.hietalahti@nokia.com" Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes 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 01:37:47 -0000 +1 What's called for here is cautionary text, not anything normative. --Richard On 11/8/10 9:34 AM, Peterson, Jon wrote: > > I don’t think the draft can do anything more helpful than say you > shouldn’t include multiple location objects because they are confusing, > and if you do permit multiple location objects, do so only in an > environment where the inserter and recipient share some agreement about > their meaning and interpretation (a slight expansion of “you break it > you bought it,” there). I don’t think it will be a useful or successful > exercise for us to try to concretize that in a standard. > > Jon Peterson > NeuStar, Inc. > > > On 11/5/10 12:22 AM, "Elwell, John" > wrote: > > Yes, I agree that replacing an enterprise-provided location is very > bad. The problem with adding locations to locations already present > is how the PSAP chooses between 2 or even 3 locations. From my > reading of the draft, we don't have any normative statement on the > order in which locations are placed in the header. If we had a rule > that the first locationValue within a single or multiple Geolocation > header fields is nearest to the source of the request, and so on, it > might help. Then it would be clear that the service > provider-provided location would be the least reliable, but it would > still be there, e.g., for use if the other locations are bogus. > > John > > > -----Original Message----- > > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > > Sent: 05 November 2010 04:37 > > To: Elwell, John; hannu.hietalahti@nokia.com; > > rbarnes@bbn.com; jmpolk@cisco.com > > Cc: sipcore@ietf.org > > Subject: RE: [sipcore] Location Conveyance -04 submitted, > > here's the changes > > > > Exactly, that is why I am saying you need multiples. > > > > Otherwise the scenario is that the PBX puts one in, and the > > public network then replaces it because it says the regulator > > tells the network to always provide a location. At least with > > my approach, all the locations are there, and the PSAP then > > sorts it out. > > > > Keith > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Thursday, November 04, 2010 5:48 PM > > > To: DRAGE, Keith (Keith); hannu.hietalahti@nokia.com; > > > rbarnes@bbn.com; jmpolk@cisco.com > > > Cc: sipcore@ietf.org > > > Subject: RE: [sipcore] Location Conveyance -04 submitted, > > > here's the changes > > > > > > Keith, > > > > > > Be very careful with this sort of approach. The trend is > > > towards fewer SIP-PBXs and fewer "SIP trunks" serving an > > > enterprise, with often a single SIP-PBX and a single entry > > > into the SIP Service Provider for a whole country or even > > > multiple countries. Even for the single country case, the > > > service provider network is unlikely to have a clue as to > > > where, in the country, the caller might be located (or even > > > where the PBX is located if there are two geographically > > > separate servers). Caller ID isn't likely to help either, > > > since users can move around within the enterprise network. > > > > > > John > > > > > > > -----Original Message----- > > > > From: sipcore-bounces@ietf.org > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE, > > Keith (Keith) > > > > Sent: 01 November 2010 23:04 > > > > To: hannu.hietalahti@nokia.com; rbarnes@bbn.com; jmpolk@cisco.com > > > > Cc: sipcore@ietf.org > > > > Subject: Re: [sipcore] Location Conveyance -04 submitted, > > > here's the > > > > changes > > > > > > > > If in 3GPP we look at subscription based business trunking > > > > arrangement. > > > > > > > > The end terminal includes one location. > > > > > > > > The enterprise network supporting the UE adds its own > > view of where > > > > the UE is. > > > > > > > > The public network adds its own view of the location. > > > > > > > > That makes three. > > > > > > > > regards > > > > > > > > Keith > > > > > > > > > -----Original Message----- > > > > > From: hannu.hietalahti@nokia.com > > > > [mailto:hannu.hietalahti@nokia.com] > > > > > Sent: Monday, November 01, 2010 11:46 AM > > > > > To: DRAGE, Keith (Keith); rbarnes@bbn.com; jmpolk@cisco.com > > > > > Cc: sipcore@ietf.org > > > > > Subject: RE: [sipcore] Location Conveyance -04 submitted, > > > here's the > > > > > changes > > > > > > > > > > Hi Keith, > > > > > > > > > > yes, I remember you made this comment at Maastricht > > > already, and I > > > > > agree with you that from 3GPP viewpoint we need encoding > > > that allows > > > > > *more than one* piece of location information. > > > > > > > > > > In 3GPP case those would be typically the one obtained from the > > > > > terminal and the one added by the serving network if it > > thinks it > > > > > knows better. > > > > > > > > > > But my imagination runs out after these two. Are you > > > saying we need > > > > > more than 2? > > > > > > > > > > BR, > > > > > Hannu Hietalahti > > > > > 3GPP TSG CT Chairman > > > > > tel: +358 40 5021724 > > > > > > > > > > > > > > > >-----Original Message----- > > > > > >From: sipcore-bounces@ietf.org > > > > > >[mailto:sipcore-bounces@ietf.org] On Behalf Of ext DRAGE, > > > > > Keith (Keith) > > > > > >Sent: 28 October, 2010 16:01 > > > > > >To: Richard L. Barnes; James M. Polk > > > > > >Cc: sipcore@ietf.org > > > > > >Subject: Re: [sipcore] Location Conveyance -04 submitted, > > > > here's the > > > > > >changes > > > > > > > > > > > >To be more specific - we had a document that allowed multiple > > > > > >locations. It was reduced to one without any decision in > > > > > that direction > > > > > >being made by the working group. It needs to go back > > to multiple > > > > > >values. > > > > > > > > > > > >In my view there are clear use cases where multiple values are > > > > > >required. > > > > > > > > > > > >regards > > > > > > > > > > > >Keith > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: sipcore-bounces@ietf.org > > > > > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Richard > > > L. Barnes > > > > > >> Sent: Thursday, October 28, 2010 1:19 PM > > > > > >> To: James M. Polk > > > > > >> Cc: sipcore@ietf.org > > > > > >> Subject: Re: [sipcore] Location Conveyance -04 submitted, > > > > > here's the > > > > > >> changes > > > > > >> > > > > > >> >> I'm pretty comfortable with the document at this point, > > > > > >> but have just > > > > > >> >> one minor question: Why are you still limiting the number > > > > > >> of location > > > > > >> >> values? Why are three values harmful, but not two? This > > > > > >> still seems > > > > > >> >> like pointless ABNF legislation. > > > > > >> > > > > > > >> > we only added the ability to have a second locationValue > > > > > >because of > > > > > >> > your rough-loc ID. Before that, we were firm in not > > > > > >> allowing more than > > > > > >> > one. Given that choice, which do you like? > > > > > >> > > > > > > >> > Remember, this was Jon's proposal in SIPCORE in Anaheim, > > > > > which it > > > > > >> > seemed everyone and their brother was agreeable > > with, so ... > > > > > >> > > > > > >> > > > > > >> As I recall, the proposal was to just remove the limit on > > > > > >the number > > > > > >> of locations values, not to bump it up by one. From > > > the minutes: > > > > > >> > > > > > >> "Restore Geolocation header that has multiple URIs, even > > > > though we > > > > > >> would not recommend it. Entities inserting persence are > > > > > responsbile > > > > > >> for any resulting errors. The header parameters > > > > > distinguishing URIs > > > > > >> would not be added back in." > > > > > >> > > > > > >> At least in my mind, multiple != 2. > > > > > >> > > > > > >> --Richard > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > james > > > > > >> > > > > > > >> > > > > > > >> >> --Richard > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> On Oct 27, 2010, at 12:32 AM, James M. Polk wrote: > > > > > >> >> > > > > > >> >>> SIPCORE > > > > > >> >>> > > > > > >> >>> I've submitted the next version of Location > > > Conveyance (-04) > > > > > >> >>> > > > > > >> > > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio > > > > > >> n-conveyance-04.txt > > > > > >> >>> and I believe this version has addressed each open > > > > > item from the > > > > > >> >>> mailing list, as well as what was discussed and agreed > > > > > to in the > > > > > >> >>> Maastricht meeting. > > > > > >> >>> > > > > > >> >>> I have attempted to identify each open issue with > > > > the specific > > > > > >> >>> resolution here (in no particular order): > > > > > >> >>> > > > > > >> >>> - Martin wanted Section 3 to be broken up into > > > > > subsections, each > > > > > >> >>> revolving around each of the 4 diagrams. I have > > done this. > > > > > >> >>> > > > > > >> >>> - allowed a maximum of two (up from one) > > > > locationValues to be > > > > > >> >>> present in the Geolocation header value. The text however > > > > > >> recommends > > > > > >> >>> against inserting a second value. This was agreed to in > > > > > >> Maastricht. > > > > > >> >>> > > > > > >> >>> - Because we're allowing a max of two locationValues, > > > > > >> they can be in > > > > > >> >>> separate Geolocation headers in the SIP request. > > > > This scenario > > > > > >> >>> necessitates bring a previous version's paragraph in > > > > > >> stating that a > > > > > >> >>> 'SIP intermediary MUST inspect all instances of each > > > > > Geolocation > > > > > >> >>> header before considering the routing-allowed > > > > parameter to be > > > > > >> >>> considered =yes', to ensure there isn't a conflict in > > > > > the 'other' > > > > > >> >>> Geolocation header that states the policy is =no. > > > > > >> >>> > > > > > >> >>> - with the ability to add a second locationValue, it is > > > > > >> necessary to > > > > > >> >>> warn against doing this (confusion at the LRs). > > > > > >> >>> > > > > > >> >>> - Added the "you break it you bought it" > > philosophy to SIP > > > > > >> >>> intermediaries that choose to insert a second location > > > > > where one > > > > > >> >>> already existed, especially for inserting a location > > > > > URI in the > > > > > >> >>> downstream SIP request. > > > > > >> >>> > > > > > >> >>> - Fixed the ABNF to handle zero, one or two (but > > no more) > > > > > >> >>> locationValues according to the agreement in Maastricht. > > > > > >> There is a > > > > > >> >>> one-off use case which won't be in play very often, but > > > > > >> is a WG item > > > > > >> >>> in ECRIT that several wanted to allow the possibility for > > > > > >> (inv > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Sun Nov 7 17:41:48 2010 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 2B5563A68A3 for ; Sun, 7 Nov 2010 17:41:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.553 X-Spam-Level: X-Spam-Status: No, score=-110.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 0QUGNZ0WNheQ for ; Sun, 7 Nov 2010 17:41:46 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 84D913A68DB for ; Sun, 7 Nov 2010 17:41:45 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADfk1kxAaMHG/2dsb2JhbACiBXGfJJpignGCVwSEWIV9gwo X-IronPort-AV: E=Sophos;i="4.58,311,1286150400"; d="scan'208";a="213307809" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 08 Nov 2010 01:41:59 +0000 Received: from [10.75.234.6] (hkidc-vpn-client-234-6.cisco.com [10.75.234.6]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA81frV6024212; Mon, 8 Nov 2010 01:41:55 GMT Message-ID: <4CD7555F.30609@cisco.com> Date: Sun, 07 Nov 2010 20:41:51 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: Mary Barnes References: <4CD6C020.7030603@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] 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 01:41:48 -0000 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@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > From mary.ietf.barnes@gmail.com Sun Nov 7 19:13:53 2010 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 549FF3A695E for ; Sun, 7 Nov 2010 19:13:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, 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 YZ3w-i-LUJBk for ; Sun, 7 Nov 2010 19:13:51 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 51C9F3A6965 for ; Sun, 7 Nov 2010 19:13:51 -0800 (PST) Received: by ywp6 with SMTP id 6so3396209ywp.31 for ; Sun, 07 Nov 2010 19:14:11 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=yETj7la1Vei0garN55dKnseA712yYSuVKBFpeN3ybdo=; b=suSF4agR6sQcIHd+WAWtIIzs1KBQZJKeO8dcyLDB7saUtyDoFwo88SNRAY+D0bGlJP 3OECUZHuREJnZbYgv+QTHt+t8+sruVsnRw1cLr3ww0nCMyeDgYUbsKhhhz7hTFU+3kJD rL3MKYC9tIHs14yxXtghyXBIqAcG1djn+rhYU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=WnDVxquGpTfNmcrjLc6UxEysmRJfTavtH29vsht1KXtBH/L4h8fJ9QCR9tvFnzQ/d9 8Jfy94Bi2d8soj70FicKvUFD+fD7c7Kvk+JYIztsnJGbzSPGclPA/tAUH4i+XI0OXsRX YGPm1U0TxAwkhT9LA8Z+XdSERKEb1pNl4VkrE= MIME-Version: 1.0 Received: by 10.90.39.6 with SMTP id m6mr4648690agm.60.1289186049470; Sun, 07 Nov 2010 19:14:09 -0800 (PST) Received: by 10.236.95.35 with HTTP; Sun, 7 Nov 2010 19:14:09 -0800 (PST) In-Reply-To: <4CD7555F.30609@cisco.com> References: <4CD6C020.7030603@cisco.com> <4CD7555F.30609@cisco.com> Date: Sun, 7 Nov 2010 21:14:09 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sipcore@ietf.org Subject: Re: [sipcore] 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 03:13:53 -0000 I totally agree that escaping the Reason header is a hack, but that was a hack that was agreed way long ago. While it does warp the definition of the Reason header, I do not think it breaks anything and this document does NOT define any new values for the Reason header. The definition of new values is entirely out of scope and orthogonal to the History-Info header. The WG does have control over whether new values are defined. And, there has still been no conclusion to the long time discussion as to whether the use of Reason headers is appropriate in Responses. I personally feel that this is a rathole and that we will never finish 4244bis if we continue debating this issue. Regards, Mary. On Sun, Nov 7, 2010 at 7:41 PM, Paul Kyzivat wrote: > > > 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. =A0So, >> 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? > > =A0 =A0 =A0 =A0Thanks, > =A0 =A0 =A0 =A0Paul > >> Mary. >> >> On Sun, Nov 7, 2010 at 9:05 AM, Paul Kyzivat =A0wrot= e: >>> >>> 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 referr= ed >>>>> to as a parameter (e.g., 7.1 3rd bullet, 7.1 last paragraph), sometim= es >>>>> 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 statement= s >>>>> using the passive voice, and therefore hard to understand. To quote o= ne >>>>> example of the sort of ambiguity that can arise from using passive, i= n >>>>> 7.3.2: >>>>> "For retargets that are the result of an explicit SIP response, a >>>>> =A0 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 tha= t >>>>> 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. =A0It is >>>> added by the entity receiving the response. =A0Note that it is added t= o >>>> 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. =A0It's added to the previous. =A0The 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 see= ms >>> very wrong to me. (Warning - this is long.) Specifically, >>> >>> There is a real difference between Reason as a parameter of an H-I entr= y >>> 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 Head= er >>> that is to be incorporated into a request that uses that URI as an R-UR= I. >>> >>> 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 orde= r >>> to >>> send a new request there, it would lift the URI from H-I and put it int= o >>> 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 wer= e >>> 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 i= t, >>> arguably, might be thought not to conflict with legitimate use of the U= RI >>> header parameter mechanism. I'll argue it isn't that benign - that ther= e >>> are >>> overlaps where the uses overlap. >>> >>> H-I should have had its own header field parameter for this purpose - n= ot >>> use the Reason header. >>> >>> This has ripple effects. Now we have >>> draft-mohali-sipcore-reason-call-forwarding which is defining new reaso= n >>> 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 i= s >>> 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 o= f >>> repurposing Reason within H-I. >>> >>> I commented to the author of draft-mohali-sipcore-reason-call-forwardin= g >>> that I felt any extensions to Reason needed to be justified in their ow= n >>> 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 w= as >>> 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 woul= d >>> be >>> incompatible with 4244 because it would change which entry contains the >>> reason. >>> >>> =A0 =A0 =A0 =A0Thanks, >>> =A0 =A0 =A0 =A0Paul >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >> > From john.elwell@siemens-enterprise.com Sun Nov 7 20:55:05 2010 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 2A31C28C0E4 for ; Sun, 7 Nov 2010 20:55:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.466 X-Spam-Level: X-Spam-Status: No, score=-102.466 tagged_above=-999 required=5 tests=[AWL=0.133, BAYES_00=-2.599, 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 wLBOYxmdX5IA for ; Sun, 7 Nov 2010 20:54:55 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 202EC3A692C for ; Sun, 7 Nov 2010 20:54:54 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2204796; Mon, 8 Nov 2010 05:55:14 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 1D0E023F0278; Mon, 8 Nov 2010 05:55:14 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 8 Nov 2010 05:55:13 +0100 From: "Elwell, John" To: Paul Kyzivat , Mary Barnes Date: Mon, 8 Nov 2010 05:55:13 +0100 Thread-Topic: [sipcore] Reason as a parameter rather than an escaped header (was Comments on draft-ietf-sipcore-rfc4244bis-02) Thread-Index: Act+5ivVo2TgeU0jR5qny9yN1cuTqwACdOgg Message-ID: References: <4CD6C020.7030603@cisco.com> <4CD7555F.30609@cisco.com> In-Reply-To: <4CD7555F.30609@cisco.com> 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 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 04:55:05 -0000 I agree with Paul's concerns, and I think we should use bis as an opportuni= ty to get this right, even if we have to grandfather some existing mechanis= m. The Mohali draft is evidence that the present mechanism causes further p= roblems down the line. John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [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=20 > terminology=20 > is awkward. We have parameters to headers, and we have=20 > headers that are=20 > parameters to URIs. >=20 > > In earlier versions, we had a separate parameter in the > > SIP History-Info header for Reason, but Rohan suggested to=20 > 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=20 > around so=20 > we can wring his neck. I thought it was a hack at the time,=20 > but didn't=20 > then realize how much trouble it would cause. >=20 > > The Reason header is intended to tag the Reason why the=20 > hi-targeted-to > > URI was retargeted and thus it goes with the "old" hi-entry=20 > 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=20 > 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=20 > 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. >=20 > So then we allow it continue to metastasize, e.g. by defining=20 > new Reason=20 > values that aren't ever expected to be used in requests, and that=20 > wouldn't make any sense if they were? >=20 > Thanks, > Paul >=20 > > Mary. > > > > On Sun, Nov 7, 2010 at 9:05 AM, Paul=20 > 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=20 > it is referred > >>>> to as a parameter (e.g., 7.1 3rd bullet, 7.1 last=20 > paragraph), sometimes as > >>>> reason header, sometimes as reason, sometimes as Reason=20 > header, sometimes as > >>>> Reason... > >>> > >>> [MB] Logically, Reason is a "parameter" for the=20 > hi-entries. However, > >>> rather than redefine the "parameter", we reuse the Reason=20 > header by > >>> escaping it in the URI - the term Reason header was used=20 > 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=20 > Reason header". > >>> [/MB] > >> > >>>> 4. As another general comment, there are too many=20 > normative statements > >>>> using the passive voice, and therefore hard to=20 > understand. To quote one > >>>> example of the sort of ambiguity that can arise from=20 > 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=20 > MUST include in > >>>> hi-targeted-uri an escaped Reason header field? Or is=20 > this saying that a > >>>> recipient of Reason MUST associate it with an=20 > hi-targeted-to-uri. I guess > >>>> the first interpretation is more plausible, but why not=20 > 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=20 > is added to > >>> the entry prior to the entry that is being added as a=20 > 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=20 > 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=20 > "is". [/MB] > >> > >> I guess this isn't a new concern - its been there all=20 > along, but it seems > >> very wrong to me. (Warning - this is long.) Specifically, > >> > >> There is a real difference between Reason as a parameter=20 > of an H-I entry and > >> an H-I entry containing a URI that contains a Reason=20 > header as a URI > >> parameter. A URI parameter has a specific meaning - it=20 > specifies a Header > >> that is to be incorporated into a request that uses that=20 > URI as an R-URI. > >> > >> Depending on details of how H-I entries are constructed=20 > during retargeting, > >> it may be that a retarget URI would contain URI=20 > parameters, and those would > >> end up in an H-I entry. There could be a Reason header=20 > included in the > >> retarget URI. I *think* the procedures for UAC and proxy=20 > imply that the > >> retargeted request would be constructed first - thus=20 > removing embedded > >> parameters and making them headers in the request -=20 > *before* capturing the > >> R-URI for H-I, but I'm not certain of that. If not, then=20 > there could be > >> ambiguity about the origin and meaning of a Reason header=20 > in an H-I URI. > >> > >> Even if that is not a problem, there are potential=20 > problems if an H-I entry > >> is ever used to construct a new request. For instance, if=20 > someone were to > >> analyze H-I to identify the URI of some entity (say the=20 > caller) in order to > >> send a new request there, it would lift the URI from H-I=20 > and put it into a > >> new request. Then the Reason URI parameter would,=20 > 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=20 > the retargeted URI > >> is being used, so it belongs in the message addressed to=20 > that URI. It makes > >> no sense that it be in a request to the R-URI that, in=20 > some prior usage, was > >> eventually retargeted. > >> > >> Bottom line: the H-I use of Reason as a URI header=20 > parameter is a hack and > >> an abuse of that mechanism. It might be benign and=20 > forgivable if it were > >> consistent with the intended use of that mechanism. But it=20 > seems it is not - > >> that it is at best the re-purposing of that mechanism in a=20 > case where it, > >> arguably, might be thought not to conflict with legitimate=20 > use of the URI > >> header parameter mechanism. I'll argue it isn't that=20 > benign - that there are > >> overlaps where the uses overlap. > >> > >> H-I should have had its own header field parameter for=20 > this purpose - not > >> use the Reason header. > >> > >> This has ripple effects. Now we have > >> draft-mohali-sipcore-reason-call-forwarding which is=20 > 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=20 > request. This is > >> insanity - but not for the author who is just trying to=20 > work within the > >> existing system. Its just an example of the mess created=20 > by the abuse of > >> repurposing Reason within H-I. > >> > >> I commented to the author of=20 > draft-mohali-sipcore-reason-call-forwarding > >> that I felt any extensions to Reason needed to be=20 > justified in their own > >> right, without reference to H-I. In fact what is proposed=20 > there *does* make > >> sense in its own right, without regard to H-I *if* it is=20 > used in the > >> retargeted request, rather than the request that is about=20 > to be retargeted. > >> > >> This could be fitted into H-I. When retargeting, it could=20 > be specified that > >> a Reason header should be added to the new request,=20 > explaining why it was > >> retargeted. Then whoever makes the H-I entry for that=20 > could include in the > >> H-I entry for that request the R-URI of the request with=20 > any Reason headers > >> in that request added to the entry as URI parameters.=20 > However this would be > >> incompatible with 4244 because it would change which entry=20 > 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 > = From john.elwell@siemens-enterprise.com Sun Nov 7 20:57:53 2010 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 D303828C0F2 for ; Sun, 7 Nov 2010 20:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.465 X-Spam-Level: X-Spam-Status: No, score=-102.465 tagged_above=-999 required=5 tests=[AWL=0.134, BAYES_00=-2.599, 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 XAlgOaueRIFL for ; Sun, 7 Nov 2010 20:57:46 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 9BB4E28C0E4 for ; Sun, 7 Nov 2010 20:57:45 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2205305; Mon, 8 Nov 2010 05:55:12 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 1E2BA23F0278; Mon, 8 Nov 2010 05:55:12 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 8 Nov 2010 05:55:12 +0100 From: "Elwell, John" To: "Peterson, Jon" , "DRAGE, Keith (Keith)" , "hannu.hietalahti@nokia.com" , "rbarnes@bbn.com" , "jmpolk@cisco.com" Date: Mon, 8 Nov 2010 05:55:11 +0100 Thread-Topic: [sipcore] Location Conveyance -04 submitted, here's the changes Thread-Index: Act2mlVdTb0CvQzFTY2pDhKiRuhu2gAAtZtwAMcwGpAAFNySEACOdTlgABbnWwAABXISYACLHd3LAAJ3WTA= Message-ID: References: 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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes 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 04:57:54 -0000 The only normative thing I was suggesting we add was to do with ordering, s= o that if there is >1 location present, the first is the one from nearest t= he source of the request. I don't see what harm that would do, and it could= help in some circumstances. John=20 > -----Original Message----- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz]=20 > Sent: 08 November 2010 01:34 > To: Elwell, John; DRAGE, Keith (Keith);=20 > hannu.hietalahti@nokia.com; rbarnes@bbn.com; jmpolk@cisco.com > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Location Conveyance -04 submitted,=20 > here's the changes >=20 >=20 > I don't think the draft can do anything more helpful than say=20 > you shouldn't include multiple location objects because they=20 > are confusing, and if you do permit multiple location=20 > objects, do so only in an environment where the inserter and=20 > recipient share some agreement about their meaning and=20 > interpretation (a slight expansion of "you break it you=20 > bought it," there). I don't think it will be a useful or=20 > successful exercise for us to try to concretize that in a standard. >=20 > Jon Peterson > NeuStar, Inc. >=20 >=20 > On 11/5/10 12:22 AM, "Elwell, John"=20 > wrote: >=20 >=20 >=20 > Yes, I agree that replacing an enterprise-provided=20 > location is very bad. The problem with adding locations to=20 > locations already present is how the PSAP chooses between 2=20 > or even 3 locations. From my reading of the draft, we don't=20 > have any normative statement on the order in which locations=20 > are placed in the header. If we had a rule that the first=20 > locationValue within a single or multiple Geolocation header=20 > fields is nearest to the source of the request, and so on, it=20 > might help. Then it would be clear that the service=20 > provider-provided location would be the least reliable, but=20 > it would still be there, e.g., for use if the other locations=20 > are bogus. > =09 > John > =09 > > -----Original Message----- > > From: DRAGE, Keith (Keith)=20 > [mailto:keith.drage@alcatel-lucent.com] > > Sent: 05 November 2010 04:37 > > To: Elwell, John; hannu.hietalahti@nokia.com; > > rbarnes@bbn.com; jmpolk@cisco.com > > Cc: sipcore@ietf.org > > Subject: RE: [sipcore] Location Conveyance -04 submitted, > > here's the changes > > > > Exactly, that is why I am saying you need multiples. > > > > Otherwise the scenario is that the PBX puts one in, and the > > public network then replaces it because it says the regulator > > tells the network to always provide a location. At least with > > my approach, all the locations are there, and the PSAP then > > sorts it out. > > > > Keith > > > > > -----Original Message----- > > > From: Elwell, John=20 > [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Thursday, November 04, 2010 5:48 PM > > > To: DRAGE, Keith (Keith); hannu.hietalahti@nokia.com; > > > rbarnes@bbn.com; jmpolk@cisco.com > > > Cc: sipcore@ietf.org > > > Subject: RE: [sipcore] Location Conveyance -04 submitted, > > > here's the changes > > > > > > Keith, > > > > > > Be very careful with this sort of approach. The trend is > > > towards fewer SIP-PBXs and fewer "SIP trunks" serving an > > > enterprise, with often a single SIP-PBX and a single entry > > > into the SIP Service Provider for a whole country or even > > > multiple countries. Even for the single country case, the > > > service provider network is unlikely to have a clue as to > > > where, in the country, the caller might be located (or even > > > where the PBX is located if there are two geographically > > > separate servers). Caller ID isn't likely to help either, > > > since users can move around within the enterprise network. > > > > > > John > > > > > > > -----Original Message----- > > > > From: sipcore-bounces@ietf.org > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE, > > Keith (Keith) > > > > Sent: 01 November 2010 23:04 > > > > To: hannu.hietalahti@nokia.com; rbarnes@bbn.com;=20 > jmpolk@cisco.com > > > > Cc: sipcore@ietf.org > > > > Subject: Re: [sipcore] Location Conveyance -04 submitted, > > > here's the > > > > changes > > > > > > > > If in 3GPP we look at subscription based business trunking > > > > arrangement. > > > > > > > > The end terminal includes one location. > > > > > > > > The enterprise network supporting the UE adds its own > > view of where > > > > the UE is. > > > > > > > > The public network adds its own view of the location. > > > > > > > > That makes three. > > > > > > > > regards > > > > > > > > Keith > > > > > > > > > -----Original Message----- > > > > > From: hannu.hietalahti@nokia.com > > > > [mailto:hannu.hietalahti@nokia.com] > > > > > Sent: Monday, November 01, 2010 11:46 AM > > > > > To: DRAGE, Keith (Keith); rbarnes@bbn.com;=20 > jmpolk@cisco.com > > > > > Cc: sipcore@ietf.org > > > > > Subject: RE: [sipcore] Location Conveyance -04=20 > submitted, > > > here's the > > > > > changes > > > > > > > > > > Hi Keith, > > > > > > > > > > yes, I remember you made this comment at Maastricht > > > already, and I > > > > > agree with you that from 3GPP viewpoint we need encoding > > > that allows > > > > > *more than one* piece of location information. > > > > > > > > > > In 3GPP case those would be typically the one=20 > obtained from the > > > > > terminal and the one added by the serving network if it > > thinks it > > > > > knows better. > > > > > > > > > > But my imagination runs out after these two. Are you > > > saying we need > > > > > more than 2? > > > > > > > > > > BR, > > > > > Hannu Hietalahti > > > > > 3GPP TSG CT Chairman > > > > > tel: +358 40 5021724 > > > > >=20 > > > > > > > > > > >-----Original Message----- > > > > > >From: sipcore-bounces@ietf.org > > > > > >[mailto:sipcore-bounces@ietf.org] On Behalf Of=20 > ext DRAGE, > > > > > Keith (Keith) > > > > > >Sent: 28 October, 2010 16:01 > > > > > >To: Richard L. Barnes; James M. Polk > > > > > >Cc: sipcore@ietf.org > > > > > >Subject: Re: [sipcore] Location Conveyance -04=20 > submitted, > > > > here's the > > > > > >changes > > > > > > > > > > > >To be more specific - we had a document that=20 > allowed multiple > > > > > >locations. It was reduced to one without any=20 > decision in > > > > > that direction > > > > > >being made by the working group. It needs to go back > > to multiple > > > > > >values. > > > > > > > > > > > >In my view there are clear use cases where=20 > multiple values are > > > > > >required. > > > > > > > > > > > >regards > > > > > > > > > > > >Keith > > > > > > > > > > > >> -----Original Message----- > > > > > >> From: sipcore-bounces@ietf.org > > > > > >> [mailto:sipcore-bounces@ietf.org] On Behalf=20 > Of Richard > > > L. Barnes > > > > > >> Sent: Thursday, October 28, 2010 1:19 PM > > > > > >> To: James M. Polk > > > > > >> Cc: sipcore@ietf.org > > > > > >> Subject: Re: [sipcore] Location Conveyance=20 > -04 submitted, > > > > > here's the > > > > > >> changes > > > > > >> > > > > > >> >> I'm pretty comfortable with the document=20 > at this point, > > > > > >> but have just > > > > > >> >> one minor question: Why are you still=20 > limiting the number > > > > > >> of location > > > > > >> >> values? Why are three values harmful,=20 > but not two? This > > > > > >> still seems > > > > > >> >> like pointless ABNF legislation. > > > > > >> > > > > > > >> > we only added the ability to have a second=20 > locationValue > > > > > >because of > > > > > >> > your rough-loc ID. Before that, we were firm in not > > > > > >> allowing more than > > > > > >> > one. Given that choice, which do you like? > > > > > >> > > > > > > >> > Remember, this was Jon's proposal in=20 > SIPCORE in Anaheim, > > > > > which it > > > > > >> > seemed everyone and their brother was agreeable > > with, so ... > > > > > >> > > > > > >> > > > > > >> As I recall, the proposal was to just remove=20 > the limit on > > > > > >the number > > > > > >> of locations values, not to bump it up by one. From > > > the minutes: > > > > > >> > > > > > >> "Restore Geolocation header that has=20 > multiple URIs, even > > > > though we > > > > > >> would not recommend it. Entities inserting=20 > persence are > > > > > responsbile > > > > > >> for any resulting errors. The header parameters > > > > > distinguishing URIs > > > > > >> would not be added back in." > > > > > >> > > > > > >> At least in my mind, multiple !=3D 2. > > > > > >> > > > > > >> --Richard > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > > > > > >> > james > > > > > >> > > > > > > >> > > > > > > >> >> --Richard > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> > > > > > >> >> On Oct 27, 2010, at 12:32 AM, James M. Polk wrote: > > > > > >> >> > > > > > >> >>> SIPCORE > > > > > >> >>> > > > > > >> >>> I've submitted the next version of Location > > > Conveyance (-04) > > > > > >> >>> > > > > > >> > > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio > > > > > >> n-conveyance-04.txt > > > > > >> >>> and I believe this version has addressed=20 > each open > > > > > item from the > > > > > >> >>> mailing list, as well as what was=20 > discussed and agreed > > > > > to in the > > > > > >> >>> Maastricht meeting. > > > > > >> >>> > > > > > >> >>> I have attempted to identify each open issue with > > > > the specific > > > > > >> >>> resolution here (in no particular order): > > > > > >> >>> > > > > > >> >>> - Martin wanted Section 3 to be broken up into > > > > > subsections, each > > > > > >> >>> revolving around each of the 4 diagrams. I have > > done this. > > > > > >> >>> > > > > > >> >>> - allowed a maximum of two (up from one) > > > > locationValues to be > > > > > >> >>> present in the Geolocation header value.=20 > The text however > > > > > >> recommends > > > > > >> >>> against inserting a second value. This=20 > was agreed to in > > > > > >> Maastricht. > > > > > >> >>> > > > > > >> >>> - Because we're allowing a max of two=20 > locationValues, > > > > > >> they can be in > > > > > >> >>> separate Geolocation headers in the SIP request. > > > > This scenario > > > > > >> >>> necessitates bring a previous version's=20 > paragraph in > > > > > >> stating that a > > > > > >> >>> 'SIP intermediary MUST inspect all=20 > instances of each > > > > > Geolocation > > > > > >> >>> header before considering the routing-allowed > > > > parameter to be > > > > > >> >>> considered =3Dyes', to ensure there isn't=20 > a conflict in > > > > > the 'other' > > > > > >> >>> Geolocation header that states the policy is =3Dno. > > > > > >> >>> > > > > > >> >>> - with the ability to add a second=20 > locationValue, it is > > > > > >> necessary to > > > > > >> >>> warn against doing this (confusion at the LRs). > > > > > >> >>> > > > > > >> >>> - Added the "you break it you bought it" > > philosophy to SIP > > > > > >> >>> intermediaries that choose to insert a=20 > second location > > > > > where one > > > > > >> >>> already existed, especially for=20 > inserting a location > > > > > URI in the > > > > > >> >>> downstream SIP request. > > > > > >> >>> > > > > > >> >>> - Fixed the ABNF to handle zero, one or two (but > > no more) > > > > > >> >>> locationValues according to the=20 > agreement in Maastricht. > > > > > >> There is a > > > > > >> >>> one-off use case which won't be in play=20 > very often, but > > > > > >> is a WG item > > > > > >> >>> in ECRIT that several wanted to allow=20 > the possibility for > > > > > >> (inv > =09 >=20 > = From hannu.hietalahti@nokia.com Sun Nov 7 21:02:16 2010 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 5FA5B3A697D for ; Sun, 7 Nov 2010 21:02:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.741 X-Spam-Level: X-Spam-Status: No, score=-6.741 tagged_above=-999 required=5 tests=[AWL=-0.143, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] 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 aB2kmCYEpC+Z for ; Sun, 7 Nov 2010 21:02:01 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 0976B28C10D for ; Sun, 7 Nov 2010 21:01:59 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id oA851eeo006692; Mon, 8 Nov 2010 07:01:54 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 07:01:49 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 07:01:48 +0200 Received: from NOK-EUMSG-06.mgdnok.nokia.com ([94.245.81.109]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 8 Nov 2010 06:01:48 +0100 From: To: , , , , Date: Mon, 8 Nov 2010 06:01:44 +0100 Thread-Topic: [sipcore] Location Conveyance -04 submitted, here's the changes Thread-Index: Act2mlVdTb0CvQzFTY2pDhKiRuhu2gAAtZtwAMcwGpAAFNySEACOdTlgABbnWwAABXISYACLHd3LAAZPCZA= Message-ID: <5BAF85033CB5F3439C4DE153165522B1109FEF8CA9@NOK-EUMSG-06.mgdnok.nokia.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_5BAF85033CB5F3439C4DE153165522B1109FEF8CA9NOKEUMSG06mgd_" MIME-Version: 1.0 X-OriginalArrivalTime: 08 Nov 2010 05:01:48.0531 (UTC) FILETIME=[0C6CCC30:01CB7F02] X-Nokia-AV: Clean Cc: sipcore@ietf.org Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes 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 05:02:16 -0000 --_000_5BAF85033CB5F3439C4DE153165522B1109FEF8CA9NOKEUMSG06mgd_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear all, under the open sky the satellite navigator of the terminal probably does gi= ve the most accurate location information. But the location obtained by the= network via base station in a motorway / train tunnel in is probably much = better than the one from the UE at the same time. And we need to serve the = terminals without GPS also. So therefore I tend to agree with Jon that as long as it is possible to enc= ode multiple location objects (which we unfortunately need to allow), the a= pplication level logic how to use those locations at the receiving end is o= utside of the scope of this document. In this draft we should not define an= y preference or indication which one of them is best. Having said that, do you see any problem to just mandate it or to build the= syntax in such a way that additional instances of location object are alwa= ys appended after the existing ones, withouth giving the reason or otherwis= e ranking them into any other order than purely chronological? While I can'= t guarantee that the terminal provided location is always the most accurate= , this way it would be at least possible to identify which one was closest = to the origin of the message (and even that does not guarantee it came all = the way from the terminal since the 3GPP UE is required to provide its loca= tion only is if knows its location). This way it would be at least possible to find the location that was insert= ed first...or last, if that is preferred. BR, Hannu Hietalahti 3GPP TSG CT Chairman tel: +358 40 5021724 ________________________________ From: ext Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: 08 November, 2010 03:34 To: Elwell, John; DRAGE, Keith (Keith); Hietalahti Hannu (Nokia-CIC/Oulu); = rbarnes@bbn.com; jmpolk@cisco.com Cc: sipcore@ietf.org Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the change= s I don't think the draft can do anything more helpful than say you shouldn't= include multiple location objects because they are confusing, and if you d= o permit multiple location objects, do so only in an environment where the = inserter and recipient share some agreement about their meaning and interpr= etation (a slight expansion of "you break it you bought it," there). I don'= t think it will be a useful or successful exercise for us to try to concret= ize that in a standard. Jon Peterson NeuStar, Inc. On 11/5/10 12:22 AM, "Elwell, John" wr= ote: Yes, I agree that replacing an enterprise-provided location is very bad. Th= e problem with adding locations to locations already present is how the PSA= P chooses between 2 or even 3 locations. From my reading of the draft, we d= on't have any normative statement on the order in which locations are place= d in the header. If we had a rule that the first locationValue within a sin= gle or multiple Geolocation header fields is nearest to the source of the r= equest, and so on, it might help. Then it would be clear that the service p= rovider-provided location would be the least reliable, but it would still b= e there, e.g., for use if the other locations are bogus. John > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:keith.drage@alcatel-lucent.com] > Sent: 05 November 2010 04:37 > To: Elwell, John; hannu.hietalahti@nokia.com; > rbarnes@bbn.com; jmpolk@cisco.com > Cc: sipcore@ietf.org > Subject: RE: [sipcore] Location Conveyance -04 submitted, > here's the changes > > Exactly, that is why I am saying you need multiples. > > Otherwise the scenario is that the PBX puts one in, and the > public network then replaces it because it says the regulator > tells the network to always provide a location. At least with > my approach, all the locations are there, and the PSAP then > sorts it out. > > Keith > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Thursday, November 04, 2010 5:48 PM > > To: DRAGE, Keith (Keith); hannu.hietalahti@nokia.com; > > rbarnes@bbn.com; jmpolk@cisco.com > > Cc: sipcore@ietf.org > > Subject: RE: [sipcore] Location Conveyance -04 submitted, > > here's the changes > > > > Keith, > > > > Be very careful with this sort of approach. The trend is > > towards fewer SIP-PBXs and fewer "SIP trunks" serving an > > enterprise, with often a single SIP-PBX and a single entry > > into the SIP Service Provider for a whole country or even > > multiple countries. Even for the single country case, the > > service provider network is unlikely to have a clue as to > > where, in the country, the caller might be located (or even > > where the PBX is located if there are two geographically > > separate servers). Caller ID isn't likely to help either, > > since users can move around within the enterprise network. > > > > John > > > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE, > Keith (Keith) > > > Sent: 01 November 2010 23:04 > > > To: hannu.hietalahti@nokia.com; rbarnes@bbn.com; jmpolk@cisco.com > > > Cc: sipcore@ietf.org > > > Subject: Re: [sipcore] Location Conveyance -04 submitted, > > here's the > > > changes > > > > > > If in 3GPP we look at subscription based business trunking > > > arrangement. > > > > > > The end terminal includes one location. > > > > > > The enterprise network supporting the UE adds its own > view of where > > > the UE is. > > > > > > The public network adds its own view of the location. > > > > > > That makes three. > > > > > > regards > > > > > > Keith > > > > > > > -----Original Message----- > > > > From: hannu.hietalahti@nokia.com > > > [mailto:hannu.hietalahti@nokia.com] > > > > Sent: Monday, November 01, 2010 11:46 AM > > > > To: DRAGE, Keith (Keith); rbarnes@bbn.com; jmpolk@cisco.com > > > > Cc: sipcore@ietf.org > > > > Subject: RE: [sipcore] Location Conveyance -04 submitted, > > here's the > > > > changes > > > > > > > > Hi Keith, > > > > > > > > yes, I remember you made this comment at Maastricht > > already, and I > > > > agree with you that from 3GPP viewpoint we need encoding > > that allows > > > > *more than one* piece of location information. > > > > > > > > In 3GPP case those would be typically the one obtained from the > > > > terminal and the one added by the serving network if it > thinks it > > > > knows better. > > > > > > > > But my imagination runs out after these two. Are you > > saying we need > > > > more than 2? > > > > > > > > BR, > > > > Hannu Hietalahti > > > > 3GPP TSG CT Chairman > > > > tel: +358 40 5021724 > > > > > > > > > > > > >-----Original Message----- > > > > >From: sipcore-bounces@ietf.org > > > > >[mailto:sipcore-bounces@ietf.org] On Behalf Of ext DRAGE, > > > > Keith (Keith) > > > > >Sent: 28 October, 2010 16:01 > > > > >To: Richard L. Barnes; James M. Polk > > > > >Cc: sipcore@ietf.org > > > > >Subject: Re: [sipcore] Location Conveyance -04 submitted, > > > here's the > > > > >changes > > > > > > > > > >To be more specific - we had a document that allowed multiple > > > > >locations. It was reduced to one without any decision in > > > > that direction > > > > >being made by the working group. It needs to go back > to multiple > > > > >values. > > > > > > > > > >In my view there are clear use cases where multiple values are > > > > >required. > > > > > > > > > >regards > > > > > > > > > >Keith > > > > > > > > > >> -----Original Message----- > > > > >> From: sipcore-bounces@ietf.org > > > > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Richard > > L. Barnes > > > > >> Sent: Thursday, October 28, 2010 1:19 PM > > > > >> To: James M. Polk > > > > >> Cc: sipcore@ietf.org > > > > >> Subject: Re: [sipcore] Location Conveyance -04 submitted, > > > > here's the > > > > >> changes > > > > >> > > > > >> >> I'm pretty comfortable with the document at this point, > > > > >> but have just > > > > >> >> one minor question: Why are you still limiting the number > > > > >> of location > > > > >> >> values? Why are three values harmful, but not two? This > > > > >> still seems > > > > >> >> like pointless ABNF legislation. > > > > >> > > > > > >> > we only added the ability to have a second locationValue > > > > >because of > > > > >> > your rough-loc ID. Before that, we were firm in not > > > > >> allowing more than > > > > >> > one. Given that choice, which do you like? > > > > >> > > > > > >> > Remember, this was Jon's proposal in SIPCORE in Anaheim, > > > > which it > > > > >> > seemed everyone and their brother was agreeable > with, so ... > > > > >> > > > > >> > > > > >> As I recall, the proposal was to just remove the limit on > > > > >the number > > > > >> of locations values, not to bump it up by one. From > > the minutes: > > > > >> > > > > >> "Restore Geolocation header that has multiple URIs, even > > > though we > > > > >> would not recommend it. Entities inserting persence are > > > > responsbile > > > > >> for any resulting errors. The header parameters > > > > distinguishing URIs > > > > >> would not be added back in." > > > > >> > > > > >> At least in my mind, multiple !=3D 2. > > > > >> > > > > >> --Richard > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > james > > > > >> > > > > > >> > > > > > >> >> --Richard > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> On Oct 27, 2010, at 12:32 AM, James M. Polk wrote: > > > > >> >> > > > > >> >>> SIPCORE > > > > >> >>> > > > > >> >>> I've submitted the next version of Location > > Conveyance (-04) > > > > >> >>> > > > > >> > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio > > > > >> n-conveyance-04.txt > > > > >> >>> and I believe this version has addressed each open > > > > item from the > > > > >> >>> mailing list, as well as what was discussed and agreed > > > > to in the > > > > >> >>> Maastricht meeting. > > > > >> >>> > > > > >> >>> I have attempted to identify each open issue with > > > the specific > > > > >> >>> resolution here (in no particular order): > > > > >> >>> > > > > >> >>> - Martin wanted Section 3 to be broken up into > > > > subsections, each > > > > >> >>> revolving around each of the 4 diagrams. I have > done this. > > > > >> >>> > > > > >> >>> - allowed a maximum of two (up from one) > > > locationValues to be > > > > >> >>> present in the Geolocation header value. The text however > > > > >> recommends > > > > >> >>> against inserting a second value. This was agreed to in > > > > >> Maastricht. > > > > >> >>> > > > > >> >>> - Because we're allowing a max of two locationValues, > > > > >> they can be in > > > > >> >>> separate Geolocation headers in the SIP request. > > > This scenario > > > > >> >>> necessitates bring a previous version's paragraph in > > > > >> stating that a > > > > >> >>> 'SIP intermediary MUST inspect all instances of each > > > > Geolocation > > > > >> >>> header before considering the routing-allowed > > > parameter to be > > > > >> >>> considered =3Dyes', to ensure there isn't a conflict in > > > > the 'other' > > > > >> >>> Geolocation header that states the policy is =3Dno. > > > > >> >>> > > > > >> >>> - with the ability to add a second locationValue, it is > > > > >> necessary to > > > > >> >>> warn against doing this (confusion at the LRs). > > > > >> >>> > > > > >> >>> - Added the "you break it you bought it" > philosophy to SIP > > > > >> >>> intermediaries that choose to insert a second location > > > > where one > > > > >> >>> already existed, especially for inserting a location > > > > URI in the > > > > >> >>> downstream SIP request. > > > > >> >>> > > > > >> >>> - Fixed the ABNF to handle zero, one or two (but > no more) > > > > >> >>> locationValues according to the agreement in Maastricht. > > > > >> There is a > > > > >> >>> one-off use case which won't be in play very often, but > > > > >> is a WG item > > > > >> >>> in ECRIT that several wanted to allow the possibility for > > > > >> (inv --_000_5BAF85033CB5F3439C4DE153165522B1109FEF8CA9NOKEUMSG06mgd_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [sipcore] Location Conveyance -04 submitted, here's = the  changes
Dear all,
 
under the open sky the satellite navigator of the = terminal=20 probably does give the most accurate location information. But=20 the location obtained by the network via base station in a moto= rway / train=20 tunnel in is probably much better than the= one=20 from the UE at the same time. And we need to serve the terminals without GP= S=20 also.
 
So therefore I tend to agree with Jon that as= long as=20 it is possible to encode multiple location objects (which we unfortunately = need=20 to allow), the application level logic how to use those locations at the=20 receiving end is outside of the scope of this document. In t= his=20 draft we should not define any preference or indication which one of them i= s=20 best.
 
Having said that, do you see any problem to just m= andate=20 it or to build the syntax in such a way that additional instances of=20 location object are always appended after the existing ones, withouth= =20 giving the reason or otherwise ranking them into any other order than purel= y=20 chronological? While I can't guarantee that the terminal provided location = is=20 always the most accurate, this way it would be at least possible to identif= y=20 which one was closest to the origin of the message (and even that does not= =20 guarantee it came all the way from the terminal since the 3GPP UE is requir= ed to=20 provide its location only is if knows its location).
 
This way it would be at least possible to find the= location=20 that was inserted first...or last, if that is preferred.

BR,
Hannu Hietalahti
3GPP TSG CT Chairman tel: +358 40 5021724

 

From: ext Peterson, Jon=20 [mailto:jon.peterson@neustar.biz]
Sent: 08 November, 2010=20 03:34
To: Elwell, John; DRAGE, Keith (Keith); Hietalahti Hannu= =20 (Nokia-CIC/Oulu); rbarnes@bbn.com; jmpolk@cisco.com
Cc:=20 sipcore@ietf.org
Subject: Re: [sipcore] Location Conveyance -04= =20 submitted, here's the changes


I don’t think the draft can do anythi= ng more=20 helpful than say you shouldn’t include multiple location objects be= cause they=20 are confusing, and if you do permit multiple location objects, do so only= in=20 an environment where the inserter and recipient share some agreement abou= t=20 their meaning and interpretation (a slight expansion of “you break = it you=20 bought it,” there). I don’t think it will be a useful or succ= essful exercise=20 for us to try to concretize that in a standard.

Jon=20 Peterson
NeuStar, Inc.


On 11/5/10 12:22 AM, "Elwell, John"= =20 <john.elwell@siemens-enterpris= e.com>=20 wrote:
Yes, I agree that replacing an enterprise-pro= vided=20 location is very bad. The problem with adding locations to locations al= ready=20 present is how the PSAP chooses between 2 or even 3 locations. From my= =20 reading of the draft, we don't have any normative statement on the orde= r in=20 which locations are placed in the header. If we had a rule that the fir= st=20 locationValue within a single or multiple Geolocation header fields is= =20 nearest to the source of the request, and so on, it might help. Then it= =20 would be clear that the service provider-provided location would be the= =20 least reliable, but it would still be there, e.g., for use if the other= =20 locations are bogus.

John

> -----Original=20 Message-----
> From: DRAGE, Keith (Keith) [mailto:keith.drage@alcat= el-lucent.com]
>=20 Sent: 05 November 2010 04:37
> To: Elwell, John; hannu.hietalahti@nokia.com;
= > rbarnes@bbn.com; jmpolk@cisco.com
> Cc: sipcore@ietf.org
> Subject: RE: [si= pcore]=20 Location Conveyance -04 submitted,
> here's the=20 changes
>
> Exactly, that is why I am saying you need=20 multiples.
>
> Otherwise the scenario is that the PBX puts = one=20 in, and the
> public network then replaces it because it says the= =20 regulator
> tells the network to always provide a location. At le= ast=20 with
> my approach, all the locations are there, and the PSAP=20 then
> sorts it out.
>
> Keith
>
> >=20 -----Original Message-----
> > From: Elwell, John [mailto:john.elwell@s= iemens-enterprise.com]
>=20 > Sent: Thursday, November 04, 2010 5:48 PM
> > To: DRAGE, = Keith=20 (Keith); hannu.hietalahti@nokia.com;
= >=20 > rbarnes@bbn.com; jmpolk@cisco.com
> > Cc: sipcore@ietf.org
> > Subject: RE= :=20 [sipcore] Location Conveyance -04 submitted,
> > here's the=20 changes
> >
> > Keith,
> >
> > Be v= ery=20 careful with this sort of approach. The trend is
> > towards f= ewer=20 SIP-PBXs and fewer "SIP trunks" serving an
> > enterprise, wit= h=20 often a single SIP-PBX and a single entry
> > into the SIP Ser= vice=20 Provider for a whole country or even
> > multiple countries. E= ven=20 for the single country case, the
> > service provider network = is=20 unlikely to have a clue as to
> > where, in the country, the c= aller=20 might be located (or even
> > where the PBX is located if ther= e are=20 two geographically
> > separate servers). Caller ID isn't like= ly to=20 help either,
> > since users can move around within the enterp= rise=20 network.
> >
> > John
> >
> > >= =20 -----Original Message-----
> > > From: sipcore-bounces@ietf.org
> = >=20 > [mailto:sipcore-bounces@ietf.or= g]=20 On Behalf Of DRAGE,
> Keith (Keith)
> > > Sent: 01=20 November 2010 23:04
> > > To: hannu.hietalahti@nokia.com; rbarnes@bbn.com; jmpolk@cisco.com
> > > Cc: sipcore@ietf.org
> > > Subjec= t: Re:=20 [sipcore] Location Conveyance -04 submitted,
> > here's the>=20 > > changes
> > >
> > > If in 3GPP we loo= k at=20 subscription based business trunking
> > > arrangement.
= >=20 > >
> > > The end terminal includes one location.
= >=20 > >
> > > The enterprise network supporting the UE ad= ds=20 its own
> view of where
> > > the UE is.
> >= =20 >
> > > The public network adds its own view of the=20 location.
> > >
> > > That makes three.
>= >=20 >
> > > regards
> > >
> > >=20 Keith
> > >
> > > > -----Original=20 Message-----
> > > > From: hannu.hietalahti@nokia.com
&= gt;=20 > > [mailto:hannu.hietalahti@noki= a.com]
>=20 > > > Sent: Monday, November 01, 2010 11:46 AM
> > &g= t;=20 > To: DRAGE, Keith (Keith); rbarnes@bbn.com; jmpolk@cisco.com
> > > > C= c: sipcore@ietf.org
> > > > S= ubject:=20 RE: [sipcore] Location Conveyance -04 submitted,
> > here's=20 the
> > > > changes
> > > >
> > = >=20 > Hi Keith,
> > > >
> > > > yes, I rem= ember=20 you made this comment at Maastricht
> > already, and I
>= >=20 > > agree with you that from 3GPP viewpoint we need encoding
&= gt;=20 > that allows
> > > > *more than one* piece of locati= on=20 information.
> > > >
> > > > In 3GPP case= =20 those would be typically the one obtained from the
> > > &g= t;=20 terminal and the one added by the serving network if it
> thinks= =20 it
> > > > knows better.
> > > >
> = >=20 > > But my imagination runs out after these two. Are you
> = >=20 saying we need
> > > > more than 2?
> > >=20 >
> > > > BR,
> > > > Hannu=20 Hietalahti
> > > > 3GPP TSG CT Chairman
> > >= ;=20 > tel: +358 40 5021724
> > > >
> > >=20 >
> > > > >-----Original Message-----
> >= >=20 > >From: sipcore-bounces@ietf.org
> = >=20 > > >[mailto:sipcore-bounces@ietf.or= g]=20 On Behalf Of ext DRAGE,
> > > > Keith (Keith)
> &g= t;=20 > > >Sent: 28 October, 2010 16:01
> > > > >T= o:=20 Richard L. Barnes; James M. Polk
> > > > >Cc: sipcore@ietf.org
> > > >=20 >Subject: Re: [sipcore] Location Conveyance -04 submitted,
> &= gt;=20 > here's the
> > > > >changes
> > > &g= t;=20 >
> > > > >To be more specific - we had a document= that=20 allowed multiple
> > > > >locations. It was reduced t= o one=20 without any decision in
> > > > that direction
> &= gt;=20 > > >being made by the working group. It needs to go back
&= gt;=20 to multiple
> > > > >values.
> > > >=20 >
> > > > >In my view there are clear use cases wh= ere=20 multiple values are
> > > > >required.
> > &= gt;=20 > >
> > > > >regards
> > > >=20 >
> > > > >Keith
> > > > >
&g= t;=20 > > > >> -----Original Message-----
> > > &g= t;=20 >> From: sipcore-bounces@ietf.org
> = >=20 > > >> [mailto:sipcore-bounces@ietf.or= g]=20 On Behalf Of Richard
> > L. Barnes
> > > > >= >=20 Sent: Thursday, October 28, 2010 1:19 PM
> > > > >>= ; To:=20 James M. Polk
> > > > >> Cc: sipcore@ietf.org
> > > > &= gt;>=20 Subject: Re: [sipcore] Location Conveyance -04 submitted,
> > = >=20 > here's the
> > > > >> changes
> > &g= t;=20 > >>
> > > > >> >> I'm pretty=20 comfortable with the document at this point,
> > > > >= ;>=20 but have just
> > > > >> >> one minor questi= on:=20 Why are you still limiting the number
> > > > >> o= f=20 location
> > > > >> >> values?  Why are= =20 three values harmful, but not two?  This
> > > >=20 >> still seems
> > > > >> >> like poin= tless=20 ABNF legislation.
> > > > >> >
> > >= ;=20 > >> > we only added the ability to have a second=20 locationValue
> > > > >because of
> > > &= gt;=20 >> > your rough-loc ID. Before that, we were firm in not
&g= t;=20 > > > >> allowing more than
> > > > >&= gt;=20 > one.  Given that choice, which do you like?
> > >= >=20 >> >
> > > > >> > Remember, this was J= on's=20 proposal in SIPCORE in Anaheim,
> > > > which it
>= >=20 > > >> > seemed everyone and their brother was=20 agreeable
> with, so ...
> > > > >>
> = >=20 > > >>
> > > > >> As I recall, the pro= posal=20 was to just remove the limit on
> > > > >the=20 number
> > > > >> of locations values, not to bump= it=20 up by one.  From
> > the minutes:
> > > >= =20 >>
> > > > >> "Restore Geolocation header th= at=20 has multiple URIs, even
> > > though we
> > > &= gt;=20 >> would not recommend it. Entities inserting persence are
>= ;=20 > > > responsbile
> > > > >> for any resu= lting=20 errors. The header parameters
> > > > distinguishing=20 URIs
> > > > >> would not be added back in."
&g= t;=20 > > > >>
> > > > >> At least in my = mind,=20 multiple !=3D 2.
> > > > >>
> > > >= =20 >> --Richard
> > > > >>
> > > &g= t;=20 >>
> > > > >>
> > > >=20 >>
> > > > >>
> > > >=20 >>
> > > > >>
> > > > >>= ;=20 > james
> > > > >> >
> > > >= =20 >> >
> > > > >> >> --Richard
>= ;=20 > > > >> >>
> > > > >>=20 >>
> > > > >> >>
> > > >= ;=20 >> >>
> > > > >> >> On Oct 27, 2= 010,=20 at 12:32 AM, James M. Polk wrote:
> > > > >>=20 >>
> > > > >> >>> SIPCORE
> &= gt;=20 > > >> >>>
> > > > >> >>= ;>=20 I've submitted the next version of Location
> > Conveyance=20 (-04)
> > > > >> >>>
> > > &g= t;=20 >>
> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio
>= =20 > > > >> n-conveyance-04.txt
> > > > >= >=20 >>> and I believe this version has addressed each open
>= >=20 > > item from the
> > > > >> >>> ma= iling=20 list, as well as what was discussed and agreed
> > > > t= o in=20 the
> > > > >> >>> Maastricht meeting.>=20 > > > >> >>>
> > > > >>=20 >>> I have attempted to identify each open issue with
> = >=20 > the specific
> > > > >> >>> resoluti= on=20 here (in no particular order):
> > > > >>=20 >>>
> > > > >> >>> - Martin want= ed=20 Section 3 to be broken up into
> > > > subsections,=20 each
> > > > >> >>> revolving around each= of=20 the 4 diagrams. I have
> done this.
> > > > >&g= t;=20 >>>
> > > > >> >>> - allowed a=20 maximum of two (up from one)
> > > locationValues to be
= >=20 > > > >> >>> present in the Geolocation header= =20 value. The text however
> > > > >> recommends
&= gt;=20 > > > >> >>> against inserting a second value. = This=20 was agreed to in
> > > > >> Maastricht.
> &g= t;=20 > > >> >>>
> > > > >> >>= ;>=20 - Because we're allowing a max of two locationValues,
> > >= >=20 >> they can be in
> > > > >> >>>=20 separate Geolocation headers in the SIP request.
> > > This= =20 scenario
> > > > >> >>> necessitates brin= g a=20 previous version's paragraph in
> > > > >> stating= that=20 a
> > > > >> >>> 'SIP intermediary MUST=20 inspect all instances of each
> > > > Geolocation
>= ;=20 > > > >> >>> header before considering the=20 routing-allowed
> > > parameter to be
> > > >= ;=20 >> >>> considered =3Dyes', to ensure there isn't a confl= ict=20 in
> > > > the 'other'
> > > > >>=20 >>> Geolocation header that states the policy is =3Dno.
>= ; >=20 > > >> >>>
> > > > >> >>= ;>=20 - with the ability to add a second locationValue, it is
> > &g= t;=20 > >> necessary to
> > > > >> >>>= warn=20 against doing this (confusion at the LRs).
> > > > >&= gt;=20 >>>
> > > > >> >>> - Added the "= you=20 break it you bought it"
> philosophy to SIP
> > > >= ;=20 >> >>> intermediaries that choose to insert a second=20 location
> > > > where one
> > > > >&g= t;=20 >>> already existed, especially for inserting a location
&g= t;=20 > > > URI in the
> > > > >> >>>= =20 downstream SIP request.
> > > > >> >>>>=20 > > > >> >>> - Fixed the ABNF to handle zero, o= ne or=20 two (but
> no more)
> > > > >> >>>= =20 locationValues according to the agreement in Maastricht.
> > &= gt;=20 > >> There is a
> > > > >> >>>=20 one-off use case which won't be in play very often, but
> > &g= t;=20 > >> is a WG item
> > > > >> >>>= in=20 ECRIT that several wanted to allow the possibility for
> > >= ;=20 > >> (inv
--_000_5BAF85033CB5F3439C4DE153165522B1109FEF8CA9NOKEUMSG06mgd_-- From hannu.hietalahti@nokia.com Sun Nov 7 21:06:22 2010 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 104DE3A697A for ; Sun, 7 Nov 2010 21:06:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.724 X-Spam-Level: X-Spam-Status: No, score=-6.724 tagged_above=-999 required=5 tests=[AWL=-0.125, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 cCwVbY5zpIp7 for ; Sun, 7 Nov 2010 21:06:17 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id A5CB63A6980 for ; Sun, 7 Nov 2010 21:06:16 -0800 (PST) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id oA856G79010171; Mon, 8 Nov 2010 07:06:21 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 07:06:12 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.8]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 07:06:07 +0200 Received: from NOK-EUMSG-06.mgdnok.nokia.com ([94.245.81.109]) by nok-am1mhub-04.mgdnok.nokia.com ([65.54.30.8]) with mapi; Mon, 8 Nov 2010 06:06:07 +0100 From: To: , , , , Date: Mon, 8 Nov 2010 06:06:04 +0100 Thread-Topic: [sipcore] Location Conveyance -04 submitted, here's the changes Thread-Index: Act2mlVdTb0CvQzFTY2pDhKiRuhu2gAAtZtwAMcwGpAAFNySEACOdTlgABbnWwAABXISYACLHd3LAAJ3WTAABNZXQA== Message-ID: <5BAF85033CB5F3439C4DE153165522B1109FEF8CAD@NOK-EUMSG-06.mgdnok.nokia.com> References: 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-OriginalArrivalTime: 08 Nov 2010 05:06:07.0841 (UTC) FILETIME=[A6FC5D10:01CB7F02] X-Nokia-AV: Clean Cc: sipcore@ietf.org Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes 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 05:06:22 -0000 John, I agree, but I am curious to what kind of application you have in mind to u= se the first/last/middle location object, please? BR, Hannu Hietalahti 3GPP TSG CT Chairman tel: +358 40 5021724 =20 >-----Original Message----- >From: ext Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 >Sent: 08 November, 2010 06:55 >To: Peterson, Jon; DRAGE, Keith (Keith); Hietalahti Hannu=20 >(Nokia-CIC/Oulu); rbarnes@bbn.com; jmpolk@cisco.com >Cc: sipcore@ietf.org >Subject: RE: [sipcore] Location Conveyance -04 submitted,=20 >here's the changes > >The only normative thing I was suggesting we add was to do=20 >with ordering, so that if there is >1 location present, the=20 >first is the one from nearest the source of the request. I=20 >don't see what harm that would do, and it could help in some=20 >circumstances. > >John=20 > >> -----Original Message----- >> From: Peterson, Jon [mailto:jon.peterson@neustar.biz]=20 >> Sent: 08 November 2010 01:34 >> To: Elwell, John; DRAGE, Keith (Keith);=20 >> hannu.hietalahti@nokia.com; rbarnes@bbn.com; jmpolk@cisco.com >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] Location Conveyance -04 submitted,=20 >> here's the changes >>=20 >>=20 >> I don't think the draft can do anything more helpful than say=20 >> you shouldn't include multiple location objects because they=20 >> are confusing, and if you do permit multiple location=20 >> objects, do so only in an environment where the inserter and=20 >> recipient share some agreement about their meaning and=20 >> interpretation (a slight expansion of "you break it you=20 >> bought it," there). I don't think it will be a useful or=20 >> successful exercise for us to try to concretize that in a standard. >>=20 >> Jon Peterson >> NeuStar, Inc. >>=20 >>=20 >> On 11/5/10 12:22 AM, "Elwell, John"=20 >> wrote: >>=20 >>=20 >>=20 >> Yes, I agree that replacing an enterprise-provided=20 >> location is very bad. The problem with adding locations to=20 >> locations already present is how the PSAP chooses between 2=20 >> or even 3 locations. From my reading of the draft, we don't=20 >> have any normative statement on the order in which locations=20 >> are placed in the header. If we had a rule that the first=20 >> locationValue within a single or multiple Geolocation header=20 >> fields is nearest to the source of the request, and so on, it=20 >> might help. Then it would be clear that the service=20 >> provider-provided location would be the least reliable, but=20 >> it would still be there, e.g., for use if the other locations=20 >> are bogus. >> =09 >> John >> =09 >> > -----Original Message----- >> > From: DRAGE, Keith (Keith)=20 >> [mailto:keith.drage@alcatel-lucent.com] >> > Sent: 05 November 2010 04:37 >> > To: Elwell, John; hannu.hietalahti@nokia.com; >> > rbarnes@bbn.com; jmpolk@cisco.com >> > Cc: sipcore@ietf.org >> > Subject: RE: [sipcore] Location Conveyance -04 submitted, >> > here's the changes >> > >> > Exactly, that is why I am saying you need multiples. >> > >> > Otherwise the scenario is that the PBX puts one in, and the >> > public network then replaces it because it says the regulator >> > tells the network to always provide a location. At least with >> > my approach, all the locations are there, and the PSAP then >> > sorts it out. >> > >> > Keith >> > >> > > -----Original Message----- >> > > From: Elwell, John=20 >> [mailto:john.elwell@siemens-enterprise.com] >> > > Sent: Thursday, November 04, 2010 5:48 PM >> > > To: DRAGE, Keith (Keith); hannu.hietalahti@nokia.com; >> > > rbarnes@bbn.com; jmpolk@cisco.com >> > > Cc: sipcore@ietf.org >> > > Subject: RE: [sipcore] Location Conveyance -04 submitted, >> > > here's the changes >> > > >> > > Keith, >> > > >> > > Be very careful with this sort of approach. The trend is >> > > towards fewer SIP-PBXs and fewer "SIP trunks" serving an >> > > enterprise, with often a single SIP-PBX and a single entry >> > > into the SIP Service Provider for a whole country or even >> > > multiple countries. Even for the single country case, the >> > > service provider network is unlikely to have a clue as to >> > > where, in the country, the caller might be located (or even >> > > where the PBX is located if there are two geographically >> > > separate servers). Caller ID isn't likely to help either, >> > > since users can move around within the enterprise network. >> > > >> > > John >> > > >> > > > -----Original Message----- >> > > > From: sipcore-bounces@ietf.org >> > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE, >> > Keith (Keith) >> > > > Sent: 01 November 2010 23:04 >> > > > To: hannu.hietalahti@nokia.com; rbarnes@bbn.com;=20 >> jmpolk@cisco.com >> > > > Cc: sipcore@ietf.org >> > > > Subject: Re: [sipcore] Location Conveyance -04 submitted, >> > > here's the >> > > > changes >> > > > >> > > > If in 3GPP we look at subscription based business trunking >> > > > arrangement. >> > > > >> > > > The end terminal includes one location. >> > > > >> > > > The enterprise network supporting the UE adds its own >> > view of where >> > > > the UE is. >> > > > >> > > > The public network adds its own view of the location. >> > > > >> > > > That makes three. >> > > > >> > > > regards >> > > > >> > > > Keith >> > > > >> > > > > -----Original Message----- >> > > > > From: hannu.hietalahti@nokia.com >> > > > [mailto:hannu.hietalahti@nokia.com] >> > > > > Sent: Monday, November 01, 2010 11:46 AM >> > > > > To: DRAGE, Keith (Keith); rbarnes@bbn.com;=20 >> jmpolk@cisco.com >> > > > > Cc: sipcore@ietf.org >> > > > > Subject: RE: [sipcore] Location Conveyance -04=20 >> submitted, >> > > here's the >> > > > > changes >> > > > > >> > > > > Hi Keith, >> > > > > >> > > > > yes, I remember you made this comment at Maastricht >> > > already, and I >> > > > > agree with you that from 3GPP viewpoint we need encoding >> > > that allows >> > > > > *more than one* piece of location information. >> > > > > >> > > > > In 3GPP case those would be typically the one=20 >> obtained from the >> > > > > terminal and the one added by the serving network if it >> > thinks it >> > > > > knows better. >> > > > > >> > > > > But my imagination runs out after these two. Are you >> > > saying we need >> > > > > more than 2? >> > > > > >> > > > > BR, >> > > > > Hannu Hietalahti >> > > > > 3GPP TSG CT Chairman >> > > > > tel: +358 40 5021724 >> > > > >=20 >> > > > > >> > > > > >-----Original Message----- >> > > > > >From: sipcore-bounces@ietf.org >> > > > > >[mailto:sipcore-bounces@ietf.org] On Behalf Of=20 >> ext DRAGE, >> > > > > Keith (Keith) >> > > > > >Sent: 28 October, 2010 16:01 >> > > > > >To: Richard L. Barnes; James M. Polk >> > > > > >Cc: sipcore@ietf.org >> > > > > >Subject: Re: [sipcore] Location Conveyance -04=20 >> submitted, >> > > > here's the >> > > > > >changes >> > > > > > >> > > > > >To be more specific - we had a document that=20 >> allowed multiple >> > > > > >locations. It was reduced to one without any=20 >> decision in >> > > > > that direction >> > > > > >being made by the working group. It needs to go back >> > to multiple >> > > > > >values. >> > > > > > >> > > > > >In my view there are clear use cases where=20 >> multiple values are >> > > > > >required. >> > > > > > >> > > > > >regards >> > > > > > >> > > > > >Keith >> > > > > > >> > > > > >> -----Original Message----- >> > > > > >> From: sipcore-bounces@ietf.org >> > > > > >> [mailto:sipcore-bounces@ietf.org] On Behalf=20 >> Of Richard >> > > L. Barnes >> > > > > >> Sent: Thursday, October 28, 2010 1:19 PM >> > > > > >> To: James M. Polk >> > > > > >> Cc: sipcore@ietf.org >> > > > > >> Subject: Re: [sipcore] Location Conveyance=20 >> -04 submitted, >> > > > > here's the >> > > > > >> changes >> > > > > >> >> > > > > >> >> I'm pretty comfortable with the document=20 >> at this point, >> > > > > >> but have just >> > > > > >> >> one minor question: Why are you still=20 >> limiting the number >> > > > > >> of location >> > > > > >> >> values? Why are three values harmful,=20 >> but not two? This >> > > > > >> still seems >> > > > > >> >> like pointless ABNF legislation. >> > > > > >> > >> > > > > >> > we only added the ability to have a second=20 >> locationValue >> > > > > >because of >> > > > > >> > your rough-loc ID. Before that, we were firm in not >> > > > > >> allowing more than >> > > > > >> > one. Given that choice, which do you like? >> > > > > >> > >> > > > > >> > Remember, this was Jon's proposal in=20 >> SIPCORE in Anaheim, >> > > > > which it >> > > > > >> > seemed everyone and their brother was agreeable >> > with, so ... >> > > > > >> >> > > > > >> >> > > > > >> As I recall, the proposal was to just remove=20 >> the limit on >> > > > > >the number >> > > > > >> of locations values, not to bump it up by one. From >> > > the minutes: >> > > > > >> >> > > > > >> "Restore Geolocation header that has=20 >> multiple URIs, even >> > > > though we >> > > > > >> would not recommend it. Entities inserting=20 >> persence are >> > > > > responsbile >> > > > > >> for any resulting errors. The header parameters >> > > > > distinguishing URIs >> > > > > >> would not be added back in." >> > > > > >> >> > > > > >> At least in my mind, multiple !=3D 2. >> > > > > >> >> > > > > >> --Richard >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> >> > > > > >> > james >> > > > > >> > >> > > > > >> > >> > > > > >> >> --Richard >> > > > > >> >> >> > > > > >> >> >> > > > > >> >> >> > > > > >> >> >> > > > > >> >> On Oct 27, 2010, at 12:32 AM, James M. Polk wrote: >> > > > > >> >> >> > > > > >> >>> SIPCORE >> > > > > >> >>> >> > > > > >> >>> I've submitted the next version of Location >> > > Conveyance (-04) >> > > > > >> >>> >> > > > > >> >> > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio >> > > > > >> n-conveyance-04.txt >> > > > > >> >>> and I believe this version has addressed=20 >> each open >> > > > > item from the >> > > > > >> >>> mailing list, as well as what was=20 >> discussed and agreed >> > > > > to in the >> > > > > >> >>> Maastricht meeting. >> > > > > >> >>> >> > > > > >> >>> I have attempted to identify each open issue with >> > > > the specific >> > > > > >> >>> resolution here (in no particular order): >> > > > > >> >>> >> > > > > >> >>> - Martin wanted Section 3 to be broken up into >> > > > > subsections, each >> > > > > >> >>> revolving around each of the 4 diagrams. I have >> > done this. >> > > > > >> >>> >> > > > > >> >>> - allowed a maximum of two (up from one) >> > > > locationValues to be >> > > > > >> >>> present in the Geolocation header value.=20 >> The text however >> > > > > >> recommends >> > > > > >> >>> against inserting a second value. This=20 >> was agreed to in >> > > > > >> Maastricht. >> > > > > >> >>> >> > > > > >> >>> - Because we're allowing a max of two=20 >> locationValues, >> > > > > >> they can be in >> > > > > >> >>> separate Geolocation headers in the SIP request. >> > > > This scenario >> > > > > >> >>> necessitates bring a previous version's=20 >> paragraph in >> > > > > >> stating that a >> > > > > >> >>> 'SIP intermediary MUST inspect all=20 >> instances of each >> > > > > Geolocation >> > > > > >> >>> header before considering the routing-allowed >> > > > parameter to be >> > > > > >> >>> considered =3Dyes', to ensure there isn't=20 >> a conflict in >> > > > > the 'other' >> > > > > >> >>> Geolocation header that states the policy is =3Dno. >> > > > > >> >>> >> > > > > >> >>> - with the ability to add a second=20 >> locationValue, it is >> > > > > >> necessary to >> > > > > >> >>> warn against doing this (confusion at the LRs). >> > > > > >> >>> >> > > > > >> >>> - Added the "you break it you bought it" >> > philosophy to SIP >> > > > > >> >>> intermediaries that choose to insert a=20 >> second location >> > > > > where one >> > > > > >> >>> already existed, especially for=20 >> inserting a location >> > > > > URI in the >> > > > > >> >>> downstream SIP request. >> > > > > >> >>> >> > > > > >> >>> - Fixed the ABNF to handle zero, one or two (but >> > no more) >> > > > > >> >>> locationValues according to the=20 >> agreement in Maastricht. >> > > > > >> There is a >> > > > > >> >>> one-off use case which won't be in play=20 >> very often, but >> > > > > >> is a WG item >> > > > > >> >>> in ECRIT that several wanted to allow=20 >> the possibility for >> > > > > >> (inv >> =09 >>=20 >> = From mary.ietf.barnes@gmail.com Sun Nov 7 21:19:07 2010 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 DA3F73A68DA for ; Sun, 7 Nov 2010 21:19:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.999 X-Spam-Level: X-Spam-Status: No, score=-101.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_74=0.6, 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 Q+9zg4SYTKSp for ; Sun, 7 Nov 2010 21:19:06 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 8866F28C0E4 for ; Sun, 7 Nov 2010 21:19:05 -0800 (PST) Received: by ywp6 with SMTP id 6so3428107ywp.31 for ; Sun, 07 Nov 2010 21:19:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=RWRYa9Euy81icD3r7yIb3Hi8trRBtjf/uQ92fEQeuR4=; b=kHfPqimdvVNCVAU7T0Ng0xVPVxnEgVowj/HjFtlxrGdTrd2BySunPdkYkF9AmXX8ko Dx5YD0WomMKhD8fvGUCbo0o40xN/qZ2Qz9rwUlKvlqDVQ69FPS+AUaYAMSgQvuXgaojE 9Vr50lfhBbAIPra4zPI4P6c4oHnlaCghOq69Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=TUJvCSJRZ/zPBUoWqPRjTJg+9cS7LHYzAGEVX8glHO0PZ9RkwAMIWMW7YxFWfog3gA f6wDDd+ZSNiN91cCz4IY/FG3bJdKWgFIiKEZywiScKGa0t2TEboyBl5OKrYhvqdRh0rj xRhIrkhS1kf5Vu1w4Ej1GEnhHCg/4zc/NOVD8= MIME-Version: 1.0 Received: by 10.90.25.13 with SMTP id 13mr4733382agy.33.1289193565089; Sun, 07 Nov 2010 21:19:25 -0800 (PST) Received: by 10.236.95.35 with HTTP; Sun, 7 Nov 2010 21:19:25 -0800 (PST) In-Reply-To: References: Date: Sun, 7 Nov 2010 23:19:25 -0600 Message-ID: From: Mary Barnes To: Shida Schubert Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "sipcore@ietf.org" , "Barnes, Mary" Subject: Re: [sipcore] Yet more comments on 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 05:19:07 -0000 A few additional comments inline below [MB]. Mary. On Sun, Nov 7, 2010 at 12:28 AM, Shida Schubert wrote: > > Hi John; > > =A0My responses on some of the comments, I think > Mary may be responding on the same issues but here are mine. > > On Nov 4, 2010, at 12:29 AM, Elwell, John wrote: > >> 1. Section 7.3.1. >> "If there is a Privacy header in the request with a priv- >> =A0 value of "header" or "history", then the initial hi-entry MUST be >> =A0 anonymized and the header removed when the request leaves a domain >> =A0 for which the SIP entity is responsible." >> I think it should say "...and the Privacy header removed" - there is no = point in removing the H-I header field if we have anonymized it. > > =A0You are right. The intention was to say "remove the priv-value and rem= ove the privacy > header itself if there are no other priv-value left (id may exists which = needs > to remain in the request until it reaches the egress point)". > >> >> 2. What is meant by anonymizing a hi-entry (in this paragraph and elsewh= ere)? Is it only the hi-targeted-to-uri that needs to be anonymized, or als= o its parameters? The examples in annex B show just the URI anonymized and = with the value anonymous@anonymous.invalid. Is this how it MUST be done? [MB] It is only the hi-targeted-to-uri that needs to be anonymized - it is a MUST. The other parameters MUST not be changed. [/MB] > > =A0I personally don't have a strong opinion about prescribing the anonymo= us@anonymou.invalid but > I think it would be useful to specify what the anonymized URI should look= like. This would avoid > anonymous URI anonymized numerous time by different privacy service for e= xample... > =A0As for the parameter, if rc/mp tag, index and encoded reason(RFC 3326)= are intact, > anonymized hi-entry can still provide some value, so I think only hi-targ= eted-to-uri should be > anonymized. > >> >> 3. In the same sentence, is it sufficient to anonymize only the first hi= -entry? There could be further hi-entries for the same domain, and just rev= ealing internal routing within the domain might be considered a breach of p= rivacy. Perhaps in that case you would need to rely on those additional hi-= entries being separately marked for privacy. If that is so, it would seem t= o be OK. > > =A0Your last suggestion/assumption was exactly the motivation and our > attempt to simplify privacy handling, by saying Privacy header with priv-= value > of "history"/"header" (not in hi-entry) for anonymizing first hi-entry on= ly and to use > privacy=3Dheader in hi-entry for any other hi-entries. > > =A0It would mean; > > =A0 1. UA requests H-I privacy by using Privacy:history or Privacy:header > =A0 2. Proxy request H-I privacy by using History-Info:?privac= y=3Dhistory > > =A0Which we thought would clarify the timing of when Privacy:history / Pr= ivacy:header > and privacy=3Dhistory are used. > > =A0But thinking further, it doesn't really simplify the overall > privacy handling of H-I =A0and furthermore it changes the semantics of > header privacy in RFC3323. > > =A0Excerpt from RFC3323 on header privacy says: > > =A0 "If a privacy level of 'header' is requested, then the originating > =A0 user has asked the privacy service to help to obscure headers that > =A0 might otherwise reveal information about the originator of the > =A0 request." > > =A0This can encompass entries revealing internal routing and domain > information as you mentioned above, so restricting the use of Privacy:hea= der > to first entry only can be seen as changing the semantics defined in RFC3= 323. > > =A0I think we should align the handling of H-I privacy of Privacy:history > and Privacy:header to that of RFC3323, allowing privacy service to > anonymize not only the first hi-entry but any other entries that > are from its domain. [MB] I don't have a strong opinion here. The suggestion above makes alot of sense. [/MB] > > =A0I guess we need to further clarify how these two means of requesting > privacy interact, since you can have both privacy:history and few hi-entr= ies > with privacy=3Dhistory. I am assuming that when privacy service anonymize= s > history-info header based on privacy:history or privacy:header, it also > needs to remove the privacy=3Dhistory from hi-entries that it's anonymizi= ng. [MB] Yes, we should clarify. With the approach discussed above, the privacy:history would "override" the privacy for each entry (within that domain). And, yes, per a previous thread, we do need to update the privacy text to indicate the removal of the privacy for each hi-entry as it is anonymized. [/MB] > > =A0Lastly what about the interaction with privacy:none? According to > section 5.1 of 4244bis, if UAC doesn't want privacy on its identity it se= ts > Privacy header with priv-value of "none", but I am having a hard time > envisioning the need for this. When do you ever get the hi-entry represen= ting > your own AoR or contact address? [MB] We originally did not include privacy of "none" as relevant to History-info (in 4244). That was added in -bis and I to question the value. I do not think it has any value as applied to History-Info and I would suggest we remove it or note that it has no impact in terms of the processing of privacy for the hi-entries. [/MB] > > =A0I think the hi-entry with privacy=3Dhistory should still be anonymized= , even when > the Privacy:none is set in request because the privacy is requested by pr= oxy, I > think we need to add text on this as well. [MB] Agreed. [/MB] > > >> >> 4. "In addition, the History-Info header can reveal general routing and >> =A0 diverting information within an intermediary, " >> Is it only routing information within an intermediary, or also routing i= nformation within a domain that you might want to make private? I think tex= t later in the paragraph concurs with the latter view. [MB] yes, it's the latter - within a domain for which the intermediary is responsible. [/MB] >> >> 5. "Finally, the terminator of the request may not want to reveal the >> =A0 final reached target to the originator. =A0In this case, the termina= tor >> =A0 uses the a value of "history" in the Privacy header in the last hi- >> =A0 entry in the response. =A0The SIP entity that forwards the response >> =A0 MUST anonymize that hi-entry and remove the Privacy header." >> Although a UAS can mark the final hi-entry as private, and there is a re= quirement for a proxy to anonymize this when the response leaves the domain= , what about other hi-entries that have been marked by proxies in the final= domain as private? These will get passed back in the response without anon= ymization since they are not the final hi-entry and are not covered by this= statement. Should the final sentence apply to any hi-entry? [MB] Yes. that sentence should apply to all responses - i.e., in general if there are hi-entries with an escaped privacy header, they should be anonymized and the privacy header removed. [/MB] > > =A0RFC3323 recommends that privacy service to be included in the > request/response path if privacy is desired. The privacy handling > in 4244bis is based on RFC3323 so I don't know if we need to add > anything specific here for anonymizing the response. > >> >> 6. Section 7.3.3: >> "To >> =A0 =A0 =A0 accomplish this, the processing entity MUST read the value f= rom >> =A0 =A0 =A0 the History-Info header in the received request and MUST add >> =A0 =A0 =A0 another level of indexing " >> Should make it clear it is the last hi-entry of the received request (af= ter adding entries on behalf of previous hops). > > =A0Agree. > >> >> 7. "followed >> =A0 =A0 =A0 by an initial index for the new level of 1" >> I think this would be clearer if it said: >> "followed by an initial index of 1 for the new level" > > =A0Agree. > >> >> 8. "MUST be calculated by incrementing the last/lowest digit >> =A0 =A0 =A0 at the current level" >> and >> "That is, the lowest/last digit of the index MUST be >> =A0 =A0 =A0 incremented " >> What if an index is a double-digit integer? > > =A0How about we remove the "lowest/last" and simply > say incrementing the digit at the current level by 1 or > something like that. > >> >> 9. Section 8: >> "an >> =A0 application might need to provide special handling in some cases >> =A0 where there are gaps." >> Should there be a note discussing the fact that some gaps are not detect= able, e.g., if I receive 1, 1.1 and 1.1.1, I cannot detect if 1.2 or 1.1.2,= say, is missing. > > =A0This would happen, say for example if request was > parallel forked, each branch would have the hi-entry > that only the forked request traversed but missing > the information of the other forks. I don't know if I would > consider what you describe as a gap. You may be > missing the other branches but you should be able to > identify the gap in index for the branch that request > traversed. (You may be missing the actual hop in the > logical tree of History-Info that does not support > 4244/4244bis but as they won't add the hi-entry > there won't be a gap in index itself). > >> >> 10. Should we say anything in section 8 about anonymized entries? Note t= hat what we might say depends to some extent on whether what exactly gets a= nomymised. For example if an application searches for an rc or mp entry, if= those parameters have been anonymized it will not find them (but might fin= d others that have not been anonymized!), but if those parameters have not = been anonymized it will find them but the URI will be useless. > > =A0URI will be useless but one can still determine how many times > request =A0was retargeted, for example (Of course this is true only > if all the proxies are rfc4244bis compliant), which I think remains > useful. > >> >> 11. Section 9: >> "With the level of security provided by TLS (SEC-req-3), the >> =A0 information in the History-Info header can thus be evaluated to >> =A0 determine if information has been removed by evaluating the indices >> =A0 for gaps (SEC-req-1, SEC-req-2). =A0" >> This is subject to the limitation pointed out in a comment above, about = not all gaps being detectable. >> >> 12. I would expect to see something in section 9 concerning privacy. We = should mention the privacy mechanism and discuss its limits (i.e., depends = on trust of downstream entities to anonymize privacy-marked entries). Also = there should probably be some discussion on strength of anonymization algor= ithms (unless we are indeed prescribing anonymous@anonymous.invalid). > > =A0Agree that text should be added. > >> >> 13. Section 10.2: >> "This document defines a priv-value for the SIP Privacy header: >> =A0 history The following changes have been made to >> =A0 http://www.iana.org/assignments/sip-priv-values The following has >> =A0 been added to the registration for the SIP Privacy header:" >> I am not sure how to parse this. > >> >> >> 14. Section 12.1: >> "This specification adds an >> =A0 optional SIP header field parameter to the History-Info and Contact >> =A0 headers. =A0" >> In fact it adds two parameters to each. > > =A0Indeed. > >> >> 15. "Entities that have not implemented this specification MUST >> =A0 ignore these parameters, " >> We cannot place a normative requirement on entities that don't implement= this. Change "MUST" to "will". > > =A0Agree. > >> >> John >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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 > From shida@ntt-at.com Sun Nov 7 21:48:15 2010 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 0AEAB28C0DF for ; Sun, 7 Nov 2010 21:48:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 mcW5xR4mOphw for ; Sun, 7 Nov 2010 21:48:13 -0800 (PST) Received: from gateway02.websitewelcome.com (gateway02.websitewelcome.com [69.56.176.20]) by core3.amsl.com (Postfix) with SMTP id 81EB43A6813 for ; Sun, 7 Nov 2010 21:48:13 -0800 (PST) Received: (qmail 7128 invoked from network); 8 Nov 2010 05:48:33 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway02.websitewelcome.com with SMTP; 8 Nov 2010 05:48:33 -0000 Received: from [130.129.65.133] (port=51635 helo=dhcp-4185.meeting.ietf.org) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PFKaf-0002LN-VX; Sun, 07 Nov 2010 23:48:27 -0600 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Mon, 8 Nov 2010 14:48:26 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CD6C020.7030603@cisco.com> <4CD7555F.30609@cisco.com> To: "Elwell, John" 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" 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 05:48:15 -0000 I don't agree. This is going to completely break backward=20 compatibility.=20 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. >=20 > John >=20 >> -----Original Message----- >> From: sipcore-bounces@ietf.org=20 >> [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=20 >> terminology=20 >> is awkward. We have parameters to headers, and we have=20 >> headers that are=20 >> parameters to URIs. >>=20 >>> In earlier versions, we had a separate parameter in the >>> SIP History-Info header for Reason, but Rohan suggested to=20 >> 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=20 >> around so=20 >> we can wring his neck. I thought it was a hack at the time,=20 >> but didn't=20 >> then realize how much trouble it would cause. >>=20 >>> The Reason header is intended to tag the Reason why the=20 >> hi-targeted-to >>> URI was retargeted and thus it goes with the "old" hi-entry=20 >> 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=20 >> 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=20 >> 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=20 >> new Reason=20 >> values that aren't ever expected to be used in requests, and that=20 >> wouldn't make any sense if they were? >>=20 >> Thanks, >> Paul >>=20 >>> Mary. >>>=20 >>> On Sun, Nov 7, 2010 at 9:05 AM, Paul=20 >> 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=20 >> it is referred >>>>>> to as a parameter (e.g., 7.1 3rd bullet, 7.1 last=20 >> paragraph), sometimes as >>>>>> reason header, sometimes as reason, sometimes as Reason=20 >> header, sometimes as >>>>>> Reason... >>>>>=20 >>>>> [MB] Logically, Reason is a "parameter" for the=20 >> hi-entries. However, >>>>> rather than redefine the "parameter", we reuse the Reason=20 >> header by >>>>> escaping it in the URI - the term Reason header was used=20 >> 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=20 >> Reason header". >>>>> [/MB] >>>>=20 >>>>>> 4. As another general comment, there are too many=20 >> normative statements >>>>>> using the passive voice, and therefore hard to=20 >> understand. To quote one >>>>>> example of the sort of ambiguity that can arise from=20 >> 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=20 >> MUST include in >>>>>> hi-targeted-uri an escaped Reason header field? Or is=20 >> this saying that a >>>>>> recipient of Reason MUST associate it with an=20 >> hi-targeted-to-uri. I guess >>>>>> the first interpretation is more plausible, but why not=20 >> 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=20 >> is added to >>>>> the entry prior to the entry that is being added as a=20 >> 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=20 >> 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=20 >> "is". [/MB] >>>>=20 >>>> I guess this isn't a new concern - its been there all=20 >> along, but it seems >>>> very wrong to me. (Warning - this is long.) Specifically, >>>>=20 >>>> There is a real difference between Reason as a parameter=20 >> of an H-I entry and >>>> an H-I entry containing a URI that contains a Reason=20 >> header as a URI >>>> parameter. A URI parameter has a specific meaning - it=20 >> specifies a Header >>>> that is to be incorporated into a request that uses that=20 >> URI as an R-URI. >>>>=20 >>>> Depending on details of how H-I entries are constructed=20 >> during retargeting, >>>> it may be that a retarget URI would contain URI=20 >> parameters, and those would >>>> end up in an H-I entry. There could be a Reason header=20 >> included in the >>>> retarget URI. I *think* the procedures for UAC and proxy=20 >> imply that the >>>> retargeted request would be constructed first - thus=20 >> removing embedded >>>> parameters and making them headers in the request -=20 >> *before* capturing the >>>> R-URI for H-I, but I'm not certain of that. If not, then=20 >> there could be >>>> ambiguity about the origin and meaning of a Reason header=20 >> in an H-I URI. >>>>=20 >>>> Even if that is not a problem, there are potential=20 >> problems if an H-I entry >>>> is ever used to construct a new request. For instance, if=20 >> someone were to >>>> analyze H-I to identify the URI of some entity (say the=20 >> caller) in order to >>>> send a new request there, it would lift the URI from H-I=20 >> and put it into a >>>> new request. Then the Reason URI parameter would,=20 >> 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=20 >> the retargeted URI >>>> is being used, so it belongs in the message addressed to=20 >> that URI. It makes >>>> no sense that it be in a request to the R-URI that, in=20 >> some prior usage, was >>>> eventually retargeted. >>>>=20 >>>> Bottom line: the H-I use of Reason as a URI header=20 >> parameter is a hack and >>>> an abuse of that mechanism. It might be benign and=20 >> forgivable if it were >>>> consistent with the intended use of that mechanism. But it=20 >> seems it is not - >>>> that it is at best the re-purposing of that mechanism in a=20 >> case where it, >>>> arguably, might be thought not to conflict with legitimate=20 >> use of the URI >>>> header parameter mechanism. I'll argue it isn't that=20 >> benign - that there are >>>> overlaps where the uses overlap. >>>>=20 >>>> H-I should have had its own header field parameter for=20 >> this purpose - not >>>> use the Reason header. >>>>=20 >>>> This has ripple effects. Now we have >>>> draft-mohali-sipcore-reason-call-forwarding which is=20 >> 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=20 >> request. This is >>>> insanity - but not for the author who is just trying to=20 >> work within the >>>> existing system. Its just an example of the mess created=20 >> by the abuse of >>>> repurposing Reason within H-I. >>>>=20 >>>> I commented to the author of=20 >> draft-mohali-sipcore-reason-call-forwarding >>>> that I felt any extensions to Reason needed to be=20 >> justified in their own >>>> right, without reference to H-I. In fact what is proposed=20 >> there *does* make >>>> sense in its own right, without regard to H-I *if* it is=20 >> used in the >>>> retargeted request, rather than the request that is about=20 >> to be retargeted. >>>>=20 >>>> This could be fitted into H-I. When retargeting, it could=20 >> be specified that >>>> a Reason header should be added to the new request,=20 >> explaining why it was >>>> retargeted. Then whoever makes the H-I entry for that=20 >> could include in the >>>> H-I entry for that request the R-URI of the request with=20 >> any Reason headers >>>> in that request added to the entry as URI parameters.=20 >> However this would be >>>> incompatible with 4244 because it would change which entry=20 >> 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 From john.elwell@siemens-enterprise.com Sun Nov 7 22:03:45 2010 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 9E2893A69C7 for ; Sun, 7 Nov 2010 22:03:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.47 X-Spam-Level: X-Spam-Status: No, score=-102.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, 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 FduQ6lNLX1vw for ; Sun, 7 Nov 2010 22:03:37 -0800 (PST) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 963043A69BC for ; Sun, 7 Nov 2010 22:03:36 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2205797; Mon, 8 Nov 2010 07:03:56 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 3C1D623F028E; Mon, 8 Nov 2010 07:03:56 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Mon, 8 Nov 2010 07:03:56 +0100 From: "Elwell, John" To: "hannu.hietalahti@nokia.com" , "jon.peterson@neustar.biz" , "keith.drage@alcatel-lucent.com" , "rbarnes@bbn.com" , "jmpolk@cisco.com" Date: Mon, 8 Nov 2010 07:03:53 +0100 Thread-Topic: [sipcore] Location Conveyance -04 submitted, here's the changes Thread-Index: Act2mlVdTb0CvQzFTY2pDhKiRuhu2gAAtZtwAMcwGpAAFNySEACOdTlgABbnWwAABXISYACLHd3LAAJ3WTAABNZXQAACDrbA Message-ID: References: <5BAF85033CB5F3439C4DE153165522B1109FEF8CAD@NOK-EUMSG-06.mgdnok.nokia.com> In-Reply-To: <5BAF85033CB5F3439C4DE153165522B1109FEF8CAD@NOK-EUMSG-06.mgdnok.nokia.com> 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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Location Conveyance -04 submitted, here's the changes 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:03:46 -0000 Hannu, It may just be a case of displaying the locations in a specific order to th= e call taker, rather than any automated application. John=20 > -----Original Message----- > From: hannu.hietalahti@nokia.com [mailto:hannu.hietalahti@nokia.com]=20 > Sent: 08 November 2010 05:06 > To: Elwell, John; jon.peterson@neustar.biz;=20 > keith.drage@alcatel-lucent.com; rbarnes@bbn.com; jmpolk@cisco.com > Cc: sipcore@ietf.org > Subject: RE: [sipcore] Location Conveyance -04 submitted,=20 > here's the changes >=20 > John, >=20 > I agree, but I am curious to what kind of application you=20 > have in mind to use the first/last/middle location object, please? >=20 > BR, > Hannu Hietalahti > 3GPP TSG CT Chairman > tel: +358 40 5021724 > =20 >=20 > >-----Original Message----- > >From: ext Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > >Sent: 08 November, 2010 06:55 > >To: Peterson, Jon; DRAGE, Keith (Keith); Hietalahti Hannu=20 > >(Nokia-CIC/Oulu); rbarnes@bbn.com; jmpolk@cisco.com > >Cc: sipcore@ietf.org > >Subject: RE: [sipcore] Location Conveyance -04 submitted,=20 > >here's the changes > > > >The only normative thing I was suggesting we add was to do=20 > >with ordering, so that if there is >1 location present, the=20 > >first is the one from nearest the source of the request. I=20 > >don't see what harm that would do, and it could help in some=20 > >circumstances. > > > >John=20 > > > >> -----Original Message----- > >> From: Peterson, Jon [mailto:jon.peterson@neustar.biz]=20 > >> Sent: 08 November 2010 01:34 > >> To: Elwell, John; DRAGE, Keith (Keith);=20 > >> hannu.hietalahti@nokia.com; rbarnes@bbn.com; jmpolk@cisco.com > >> Cc: sipcore@ietf.org > >> Subject: Re: [sipcore] Location Conveyance -04 submitted,=20 > >> here's the changes > >>=20 > >>=20 > >> I don't think the draft can do anything more helpful than say=20 > >> you shouldn't include multiple location objects because they=20 > >> are confusing, and if you do permit multiple location=20 > >> objects, do so only in an environment where the inserter and=20 > >> recipient share some agreement about their meaning and=20 > >> interpretation (a slight expansion of "you break it you=20 > >> bought it," there). I don't think it will be a useful or=20 > >> successful exercise for us to try to concretize that in a standard. > >>=20 > >> Jon Peterson > >> NeuStar, Inc. > >>=20 > >>=20 > >> On 11/5/10 12:22 AM, "Elwell, John"=20 > >> wrote: > >>=20 > >>=20 > >>=20 > >> Yes, I agree that replacing an enterprise-provided=20 > >> location is very bad. The problem with adding locations to=20 > >> locations already present is how the PSAP chooses between 2=20 > >> or even 3 locations. From my reading of the draft, we don't=20 > >> have any normative statement on the order in which locations=20 > >> are placed in the header. If we had a rule that the first=20 > >> locationValue within a single or multiple Geolocation header=20 > >> fields is nearest to the source of the request, and so on, it=20 > >> might help. Then it would be clear that the service=20 > >> provider-provided location would be the least reliable, but=20 > >> it would still be there, e.g., for use if the other locations=20 > >> are bogus. > >> =09 > >> John > >> =09 > >> > -----Original Message----- > >> > From: DRAGE, Keith (Keith)=20 > >> [mailto:keith.drage@alcatel-lucent.com] > >> > Sent: 05 November 2010 04:37 > >> > To: Elwell, John; hannu.hietalahti@nokia.com; > >> > rbarnes@bbn.com; jmpolk@cisco.com > >> > Cc: sipcore@ietf.org > >> > Subject: RE: [sipcore] Location Conveyance -04 submitted, > >> > here's the changes > >> > > >> > Exactly, that is why I am saying you need multiples. > >> > > >> > Otherwise the scenario is that the PBX puts one in, and the > >> > public network then replaces it because it says the regulator > >> > tells the network to always provide a location. At least with > >> > my approach, all the locations are there, and the PSAP then > >> > sorts it out. > >> > > >> > Keith > >> > > >> > > -----Original Message----- > >> > > From: Elwell, John=20 > >> [mailto:john.elwell@siemens-enterprise.com] > >> > > Sent: Thursday, November 04, 2010 5:48 PM > >> > > To: DRAGE, Keith (Keith); hannu.hietalahti@nokia.com; > >> > > rbarnes@bbn.com; jmpolk@cisco.com > >> > > Cc: sipcore@ietf.org > >> > > Subject: RE: [sipcore] Location Conveyance -04 submitted, > >> > > here's the changes > >> > > > >> > > Keith, > >> > > > >> > > Be very careful with this sort of approach. The trend is > >> > > towards fewer SIP-PBXs and fewer "SIP trunks" serving an > >> > > enterprise, with often a single SIP-PBX and a single entry > >> > > into the SIP Service Provider for a whole country or even > >> > > multiple countries. Even for the single country case, the > >> > > service provider network is unlikely to have a clue as to > >> > > where, in the country, the caller might be located (or even > >> > > where the PBX is located if there are two geographically > >> > > separate servers). Caller ID isn't likely to help either, > >> > > since users can move around within the enterprise network. > >> > > > >> > > John > >> > > > >> > > > -----Original Message----- > >> > > > From: sipcore-bounces@ietf.org > >> > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of DRAGE, > >> > Keith (Keith) > >> > > > Sent: 01 November 2010 23:04 > >> > > > To: hannu.hietalahti@nokia.com; rbarnes@bbn.com;=20 > >> jmpolk@cisco.com > >> > > > Cc: sipcore@ietf.org > >> > > > Subject: Re: [sipcore] Location Conveyance -04 submitted, > >> > > here's the > >> > > > changes > >> > > > > >> > > > If in 3GPP we look at subscription based business trunking > >> > > > arrangement. > >> > > > > >> > > > The end terminal includes one location. > >> > > > > >> > > > The enterprise network supporting the UE adds its own > >> > view of where > >> > > > the UE is. > >> > > > > >> > > > The public network adds its own view of the location. > >> > > > > >> > > > That makes three. > >> > > > > >> > > > regards > >> > > > > >> > > > Keith > >> > > > > >> > > > > -----Original Message----- > >> > > > > From: hannu.hietalahti@nokia.com > >> > > > [mailto:hannu.hietalahti@nokia.com] > >> > > > > Sent: Monday, November 01, 2010 11:46 AM > >> > > > > To: DRAGE, Keith (Keith); rbarnes@bbn.com;=20 > >> jmpolk@cisco.com > >> > > > > Cc: sipcore@ietf.org > >> > > > > Subject: RE: [sipcore] Location Conveyance -04=20 > >> submitted, > >> > > here's the > >> > > > > changes > >> > > > > > >> > > > > Hi Keith, > >> > > > > > >> > > > > yes, I remember you made this comment at Maastricht > >> > > already, and I > >> > > > > agree with you that from 3GPP viewpoint we need encoding > >> > > that allows > >> > > > > *more than one* piece of location information. > >> > > > > > >> > > > > In 3GPP case those would be typically the one=20 > >> obtained from the > >> > > > > terminal and the one added by the serving network if it > >> > thinks it > >> > > > > knows better. > >> > > > > > >> > > > > But my imagination runs out after these two. Are you > >> > > saying we need > >> > > > > more than 2? > >> > > > > > >> > > > > BR, > >> > > > > Hannu Hietalahti > >> > > > > 3GPP TSG CT Chairman > >> > > > > tel: +358 40 5021724 > >> > > > >=20 > >> > > > > > >> > > > > >-----Original Message----- > >> > > > > >From: sipcore-bounces@ietf.org > >> > > > > >[mailto:sipcore-bounces@ietf.org] On Behalf Of=20 > >> ext DRAGE, > >> > > > > Keith (Keith) > >> > > > > >Sent: 28 October, 2010 16:01 > >> > > > > >To: Richard L. Barnes; James M. Polk > >> > > > > >Cc: sipcore@ietf.org > >> > > > > >Subject: Re: [sipcore] Location Conveyance -04=20 > >> submitted, > >> > > > here's the > >> > > > > >changes > >> > > > > > > >> > > > > >To be more specific - we had a document that=20 > >> allowed multiple > >> > > > > >locations. It was reduced to one without any=20 > >> decision in > >> > > > > that direction > >> > > > > >being made by the working group. It needs to go back > >> > to multiple > >> > > > > >values. > >> > > > > > > >> > > > > >In my view there are clear use cases where=20 > >> multiple values are > >> > > > > >required. > >> > > > > > > >> > > > > >regards > >> > > > > > > >> > > > > >Keith > >> > > > > > > >> > > > > >> -----Original Message----- > >> > > > > >> From: sipcore-bounces@ietf.org > >> > > > > >> [mailto:sipcore-bounces@ietf.org] On Behalf=20 > >> Of Richard > >> > > L. Barnes > >> > > > > >> Sent: Thursday, October 28, 2010 1:19 PM > >> > > > > >> To: James M. Polk > >> > > > > >> Cc: sipcore@ietf.org > >> > > > > >> Subject: Re: [sipcore] Location Conveyance=20 > >> -04 submitted, > >> > > > > here's the > >> > > > > >> changes > >> > > > > >> > >> > > > > >> >> I'm pretty comfortable with the document=20 > >> at this point, > >> > > > > >> but have just > >> > > > > >> >> one minor question: Why are you still=20 > >> limiting the number > >> > > > > >> of location > >> > > > > >> >> values? Why are three values harmful,=20 > >> but not two? This > >> > > > > >> still seems > >> > > > > >> >> like pointless ABNF legislation. > >> > > > > >> > > >> > > > > >> > we only added the ability to have a second=20 > >> locationValue > >> > > > > >because of > >> > > > > >> > your rough-loc ID. Before that, we were firm in not > >> > > > > >> allowing more than > >> > > > > >> > one. Given that choice, which do you like? > >> > > > > >> > > >> > > > > >> > Remember, this was Jon's proposal in=20 > >> SIPCORE in Anaheim, > >> > > > > which it > >> > > > > >> > seemed everyone and their brother was agreeable > >> > with, so ... > >> > > > > >> > >> > > > > >> > >> > > > > >> As I recall, the proposal was to just remove=20 > >> the limit on > >> > > > > >the number > >> > > > > >> of locations values, not to bump it up by one. From > >> > > the minutes: > >> > > > > >> > >> > > > > >> "Restore Geolocation header that has=20 > >> multiple URIs, even > >> > > > though we > >> > > > > >> would not recommend it. Entities inserting=20 > >> persence are > >> > > > > responsbile > >> > > > > >> for any resulting errors. The header parameters > >> > > > > distinguishing URIs > >> > > > > >> would not be added back in." > >> > > > > >> > >> > > > > >> At least in my mind, multiple !=3D 2. > >> > > > > >> > >> > > > > >> --Richard > >> > > > > >> > >> > > > > >> > >> > > > > >> > >> > > > > >> > >> > > > > >> > >> > > > > >> > >> > > > > >> > >> > > > > >> > james > >> > > > > >> > > >> > > > > >> > > >> > > > > >> >> --Richard > >> > > > > >> >> > >> > > > > >> >> > >> > > > > >> >> > >> > > > > >> >> > >> > > > > >> >> On Oct 27, 2010, at 12:32 AM, James M. Polk wrote: > >> > > > > >> >> > >> > > > > >> >>> SIPCORE > >> > > > > >> >>> > >> > > > > >> >>> I've submitted the next version of Location > >> > > Conveyance (-04) > >> > > > > >> >>> > >> > > > > >> > >> > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio > >> > > > > >> n-conveyance-04.txt > >> > > > > >> >>> and I believe this version has addressed=20 > >> each open > >> > > > > item from the > >> > > > > >> >>> mailing list, as well as what was=20 > >> discussed and agreed > >> > > > > to in the > >> > > > > >> >>> Maastricht meeting. > >> > > > > >> >>> > >> > > > > >> >>> I have attempted to identify each open issue with > >> > > > the specific > >> > > > > >> >>> resolution here (in no particular order): > >> > > > > >> >>> > >> > > > > >> >>> - Martin wanted Section 3 to be broken up into > >> > > > > subsections, each > >> > > > > >> >>> revolving around each of the 4 diagrams. I have > >> > done this. > >> > > > > >> >>> > >> > > > > >> >>> - allowed a maximum of two (up from one) > >> > > > locationValues to be > >> > > > > >> >>> present in the Geolocation header value.=20 > >> The text however > >> > > > > >> recommends > >> > > > > >> >>> against inserting a second value. This=20 > >> was agreed to in > >> > > > > >> Maastricht. > >> > > > > >> >>> > >> > > > > >> >>> - Because we're allowing a max of two=20 > >> locationValues, > >> > > > > >> they can be in > >> > > > > >> >>> separate Geolocation headers in the SIP request. > >> > > > This scenario > >> > > > > >> >>> necessitates bring a previous version's=20 > >> paragraph in > >> > > > > >> stating that a > >> > > > > >> >>> 'SIP intermediary MUST inspect all=20 > >> instances of each > >> > > > > Geolocation > >> > > > > >> >>> header before considering the routing-allowed > >> > > > parameter to be > >> > > > > >> >>> considered =3Dyes', to ensure there isn't=20 > >> a conflict in > >> > > > > the 'other' > >> > > > > >> >>> Geolocation header that states the policy is =3Dno. > >> > > > > >> >>> > >> > > > > >> >>> - with the ability to add a second=20 > >> locationValue, it is > >> > > > > >> necessary to > >> > > > > >> >>> warn against doing this (confusion at the LRs). > >> > > > > >> >>> > >> > > > > >> >>> - Added the "you break it you bought it" > >> > philosophy to SIP > >> > > > > >> >>> intermediaries that choose to insert a=20 > >> second location > >> > > > > where one > >> > > > > >> >>> already existed, especially for=20 > >> inserting a location > >> > > > > URI in the > >> > > > > >> >>> downstream SIP request. > >> > > > > >> >>> > >> > > > > >> >>> - Fixed the ABNF to handle zero, one or two (but > >> > no more) > >> > > > > >> >>> locationValues according to the=20 > >> agreement in Maastricht. > >> > > > > >> There is a > >> > > > > >> >>> one-off use case which won't be in play=20 > >> very often, but > >> > > > > >> is a WG item > >> > > > > >> >>> in ECRIT that several wanted to allow=20 > >> the possibility for > >> > > > > >> (inv > >> =09 > >>=20 > >> = From mary.ietf.barnes@gmail.com Sun Nov 7 22:16:20 2010 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 9DEF13A6998 for ; Sun, 7 Nov 2010 22:16:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.524 X-Spam-Level: X-Spam-Status: No, score=-102.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, 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 t1RQNbeku5tx for ; Sun, 7 Nov 2010 22:16:16 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 1F38D3A699A for ; Sun, 7 Nov 2010 22:15:42 -0800 (PST) Received: by ywp6 with SMTP id 6so3442316ywp.31 for ; Sun, 07 Nov 2010 22:14:28 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=fWxukVodGz3XedGmE/fjw/m843RfLyDlQoqV7n+i4cs=; b=U6q9G26UyMrC6IMaL/XaiLf4A4DAQwFPeP1OUSr80iDgrzp+gvaXd1k2+Be1weUIck M/QtuaEG5Gqr//huR6mDE3V0M7t91wZpjVqsFDoR7XCfpiyljtaMl9MdOcdUCxw0K2i4 lQdNauKI1jH9jz4pdmbpRTJ4H2lIa/ywsLY1w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=wlSKwJGhNjB4vhd2Ulb7bPI0ZZn1fSOmr0WQzNfnyOk9y5f5UtA2MY9x9y/1oG4pdg YeoRie5guPiRAVo9zzY34zy4hCZ8jmkrvmbt6YDIz4hDRoQxyOhXdAGtP8yfp/iHp7i8 2bOa0sm8h0ki1MwsFTXVOhIhHxJxY04I+J5fQ= MIME-Version: 1.0 Received: by 10.151.51.15 with SMTP id d15mr4339190ybk.33.1289196868088; Sun, 07 Nov 2010 22:14:28 -0800 (PST) Received: by 10.236.95.35 with HTTP; Sun, 7 Nov 2010 22:14:28 -0800 (PST) In-Reply-To: <064.81e343374deecdf821a6bab2507a302c@tools.ietf.org> References: <064.81e343374deecdf821a6bab2507a302c@tools.ietf.org> Date: Mon, 8 Nov 2010 00:14:28 -0600 Message-ID: From: Mary Barnes To: sipcore issue tracker Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: sipcore@ietf.org Subject: Re: [sipcore] rfc4244bis #44 (new): 4244bis-02: security section misleading 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:16:20 -0000 I agree. Removing this is consistent with some of the earlier text we removed in terms handling and implications of missing information. Mary. On Sat, Nov 6, 2010 at 9:41 PM, sipcore issue tracker wrote: > #44: 4244bis-02: security section misleading > > =A0Section 9 says: > =A0 =A0With the level of security provided by TLS (SEC-req-3), the > =A0 =A0information in the History-Info header can thus be evaluated to > =A0 =A0determine if information has been removed by evaluating the indice= s > =A0 =A0for gaps (SEC-req-1, SEC-req-2). =A0It would be up to the applicat= ion > =A0 =A0to define whether it can make use of the information in the case o= f > =A0 =A0missing entries. > > =A0No, TLS doesn't do that. =A0TLS only guarantees you that the next-hop = or > =A0previous-hop is who its cert claims it to be (assuming you trust its > =A0anchor), and prevents tampering by something in-between you and that > =A0previous-hop or next-hop. =A0That doesn't mean that previous-hop or ne= xt- > =A0hop, or some upstream/downstream entity beyond it, did not modify the = H-I > =A0entries - including in ways which you cannot possibly detect. =A0For e= xample > =A0it could have renumbered them, changed their content, etc. > > =A0This section-9 paragraph is wrong, and we won't be able to satisfy the > =A0security requirements in appendix A.1 =A0That's *OK*. =A0We're not goi= ng to > =A0get better than that. =A0In fact, we basically need that behavior, sin= ce we > =A0need PSTN Gateways to be able to generate H-I entries based on ISUP in= fo > =A0(even for numbers they don't own); and we need Diversion interworked t= o > =A0H-I too. > > -- > ------------------------------------+------------------------------------= --- > =A0Reporter: =A0hkaplan@=85 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 =A0 =A0 Own= er: > =A0 =A0 Type: =A0defect =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 =A0S= tatus: =A0new > =A0Priority: =A0minor =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 | =A0 Milestone= : =A0milestone1 > Component: =A0rfc4244bis =A0 =A0 =A0 =A0 =A0 =A0 =A0| =A0 =A0 Version: = =A02.0 > =A0Severity: =A0In WG Last Call =A0 =A0 =A0 =A0 | =A0 =A0Keywords: > ------------------------------------+------------------------------------= --- > > Ticket URL: > sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From R.Jesske@telekom.de Sun Nov 7 22:27:33 2010 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 1E5A43A684F for ; Sun, 7 Nov 2010 22:27:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_63=0.6, RCVD_IN_DNSWL_LOW=-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 rpqnl8rBwtMJ for ; Sun, 7 Nov 2010 22:27:31 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id B59D83A697C for ; Sun, 7 Nov 2010 22:27:29 -0800 (PST) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 08 Nov 2010 07:27:41 +0100 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 07:27:41 +0100 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Nov 2010 07:27:39 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Message-ID: <9886E5FCA6D76549A3011068483A4BD406D5CF2D@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Reason as a parameter rather than an escaped header(was Comments on draft-ietf-sipcore-rfc4244bis-02) Thread-Index: Act/CJnmrep+n8GyRp6LVlwfPyIM+QAAf2RA References: <4CD6C020.7030603@cisco.com><4CD7555F.30609@cisco.com> From: To: , X-OriginalArrivalTime: 08 Nov 2010 06:27:41.0673 (UTC) FILETIME=[0BEFDD90:01CB7F0E] 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:27:33 -0000 I have the same problem as Shida has. We have already deployed RFC4244 and RFC4458 for Call forwarding. And a = new mechanism will violate our network. So from my point of view we have to life with that what is existing. Roland -----Urspr=FCngliche Nachricht----- Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im = Auftrag von Shida Schubert Gesendet: Montag, 8. November 2010 06:48 An: Elwell, John Cc: sipcore@ietf.org Betreff: Re: [sipcore] Reason as a parameter rather than an escaped = header(was Comments on draft-ietf-sipcore-rfc4244bis-02) I don't agree. This is going to completely break backward=20 compatibility.=20 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. >=20 > John >=20 >> -----Original Message----- >> From: sipcore-bounces@ietf.org=20 >> [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=20 >> terminology=20 >> is awkward. We have parameters to headers, and we have=20 >> headers that are=20 >> parameters to URIs. >>=20 >>> In earlier versions, we had a separate parameter in the >>> SIP History-Info header for Reason, but Rohan suggested to=20 >> 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=20 >> around so=20 >> we can wring his neck. I thought it was a hack at the time,=20 >> but didn't=20 >> then realize how much trouble it would cause. >>=20 >>> The Reason header is intended to tag the Reason why the=20 >> hi-targeted-to >>> URI was retargeted and thus it goes with the "old" hi-entry=20 >> 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=20 >> 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=20 >> 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=20 >> new Reason=20 >> values that aren't ever expected to be used in requests, and that=20 >> wouldn't make any sense if they were? >>=20 >> Thanks, >> Paul >>=20 >>> Mary. >>>=20 >>> On Sun, Nov 7, 2010 at 9:05 AM, Paul=20 >> 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=20 >> it is referred >>>>>> to as a parameter (e.g., 7.1 3rd bullet, 7.1 last=20 >> paragraph), sometimes as >>>>>> reason header, sometimes as reason, sometimes as Reason=20 >> header, sometimes as >>>>>> Reason... >>>>>=20 >>>>> [MB] Logically, Reason is a "parameter" for the=20 >> hi-entries. However, >>>>> rather than redefine the "parameter", we reuse the Reason=20 >> header by >>>>> escaping it in the URI - the term Reason header was used=20 >> 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=20 >> Reason header". >>>>> [/MB] >>>>=20 >>>>>> 4. As another general comment, there are too many=20 >> normative statements >>>>>> using the passive voice, and therefore hard to=20 >> understand. To quote one >>>>>> example of the sort of ambiguity that can arise from=20 >> 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=20 >> MUST include in >>>>>> hi-targeted-uri an escaped Reason header field? Or is=20 >> this saying that a >>>>>> recipient of Reason MUST associate it with an=20 >> hi-targeted-to-uri. I guess >>>>>> the first interpretation is more plausible, but why not=20 >> 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=20 >> is added to >>>>> the entry prior to the entry that is being added as a=20 >> 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=20 >> 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=20 >> "is". [/MB] >>>>=20 >>>> I guess this isn't a new concern - its been there all=20 >> along, but it seems >>>> very wrong to me. (Warning - this is long.) Specifically, >>>>=20 >>>> There is a real difference between Reason as a parameter=20 >> of an H-I entry and >>>> an H-I entry containing a URI that contains a Reason=20 >> header as a URI >>>> parameter. A URI parameter has a specific meaning - it=20 >> specifies a Header >>>> that is to be incorporated into a request that uses that=20 >> URI as an R-URI. >>>>=20 >>>> Depending on details of how H-I entries are constructed=20 >> during retargeting, >>>> it may be that a retarget URI would contain URI=20 >> parameters, and those would >>>> end up in an H-I entry. There could be a Reason header=20 >> included in the >>>> retarget URI. I *think* the procedures for UAC and proxy=20 >> imply that the >>>> retargeted request would be constructed first - thus=20 >> removing embedded >>>> parameters and making them headers in the request -=20 >> *before* capturing the >>>> R-URI for H-I, but I'm not certain of that. If not, then=20 >> there could be >>>> ambiguity about the origin and meaning of a Reason header=20 >> in an H-I URI. >>>>=20 >>>> Even if that is not a problem, there are potential=20 >> problems if an H-I entry >>>> is ever used to construct a new request. For instance, if=20 >> someone were to >>>> analyze H-I to identify the URI of some entity (say the=20 >> caller) in order to >>>> send a new request there, it would lift the URI from H-I=20 >> and put it into a >>>> new request. Then the Reason URI parameter would,=20 >> 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=20 >> the retargeted URI >>>> is being used, so it belongs in the message addressed to=20 >> that URI. It makes >>>> no sense that it be in a request to the R-URI that, in=20 >> some prior usage, was >>>> eventually retargeted. >>>>=20 >>>> Bottom line: the H-I use of Reason as a URI header=20 >> parameter is a hack and >>>> an abuse of that mechanism. It might be benign and=20 >> forgivable if it were >>>> consistent with the intended use of that mechanism. But it=20 >> seems it is not - >>>> that it is at best the re-purposing of that mechanism in a=20 >> case where it, >>>> arguably, might be thought not to conflict with legitimate=20 >> use of the URI >>>> header parameter mechanism. I'll argue it isn't that=20 >> benign - that there are >>>> overlaps where the uses overlap. >>>>=20 >>>> H-I should have had its own header field parameter for=20 >> this purpose - not >>>> use the Reason header. >>>>=20 >>>> This has ripple effects. Now we have >>>> draft-mohali-sipcore-reason-call-forwarding which is=20 >> 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=20 >> request. This is >>>> insanity - but not for the author who is just trying to=20 >> work within the >>>> existing system. Its just an example of the mess created=20 >> by the abuse of >>>> repurposing Reason within H-I. >>>>=20 >>>> I commented to the author of=20 >> draft-mohali-sipcore-reason-call-forwarding >>>> that I felt any extensions to Reason needed to be=20 >> justified in their own >>>> right, without reference to H-I. In fact what is proposed=20 >> there *does* make >>>> sense in its own right, without regard to H-I *if* it is=20 >> used in the >>>> retargeted request, rather than the request that is about=20 >> to be retargeted. >>>>=20 >>>> This could be fitted into H-I. When retargeting, it could=20 >> be specified that >>>> a Reason header should be added to the new request,=20 >> explaining why it was >>>> retargeted. Then whoever makes the H-I entry for that=20 >> could include in the >>>> H-I entry for that request the R-URI of the request with=20 >> any Reason headers >>>> in that request added to the entry as URI parameters.=20 >> However this would be >>>> incompatible with 4244 because it would change which entry=20 >> 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 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From john.elwell@siemens-enterprise.com Sun Nov 7 22:30:46 2010 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 537AC3A699A for ; Sun, 7 Nov 2010 22:30:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.474 X-Spam-Level: X-Spam-Status: No, score=-102.474 tagged_above=-999 required=5 tests=[AWL=0.125, BAYES_00=-2.599, 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 MFIUn7hxhz9R for ; Sun, 7 Nov 2010 22:30:45 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id A3E8A3A684F for ; Sun, 7 Nov 2010 22:30:44 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2205418; Mon, 8 Nov 2010 07:31:03 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 980D023F028E; Mon, 8 Nov 2010 07:31:03 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 8 Nov 2010 07:31:03 +0100 From: "Elwell, John" To: Mary Barnes , Shida Schubert Date: Mon, 8 Nov 2010 07:31:02 +0100 Thread-Topic: [sipcore] Yet more comments on rfc4244bis-02 Thread-Index: Act/BIOxgi43uUzjS8KjUp6YrSTV5gABzbFw Message-ID: References: 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="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "Barnes, Mary" , "sipcore@ietf.org" Subject: Re: [sipcore] Yet more comments on 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:30:46 -0000 Replying to both Shida and Mary:=20 > -----Original Message----- > From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 > Sent: 08 November 2010 05:19 > To: Shida Schubert > Cc: Elwell, John; Barnes, Mary; sipcore@ietf.org > Subject: Re: [sipcore] Yet more comments on rfc4244bis-02 >=20 > A few additional comments inline below [MB]. >=20 > Mary. >=20 > On Sun, Nov 7, 2010 at 12:28 AM, Shida Schubert=20 > wrote: > > > > Hi John; > > > > =A0My responses on some of the comments, I think > > Mary may be responding on the same issues but here are mine. > > > > On Nov 4, 2010, at 12:29 AM, Elwell, John wrote: > > > >> 1. Section 7.3.1. > >> "If there is a Privacy header in the request with a priv- > >> =A0 value of "header" or "history", then the initial hi-entry MUST be > >> =A0 anonymized and the header removed when the request=20 > leaves a domain > >> =A0 for which the SIP entity is responsible." > >> I think it should say "...and the Privacy header removed"=20 > - there is no point in removing the H-I header field if we=20 > have anonymized it. > > > > =A0You are right. The intention was to say "remove the=20 > priv-value and remove the privacy > > header itself if there are no other priv-value left (id may=20 > exists which needs > > to remain in the request until it reaches the egress point)". > > > >> > >> 2. What is meant by anonymizing a hi-entry (in this=20 > paragraph and elsewhere)? Is it only the hi-targeted-to-uri=20 > that needs to be anonymized, or also its parameters? The=20 > examples in annex B show just the URI anonymized and with the=20 > value anonymous@anonymous.invalid. Is this how it MUST be done? >=20 > [MB] It is only the hi-targeted-to-uri that needs to be anonymized - > it is a MUST. The other parameters MUST not be changed. [/MB] [JRE] You didn't express any opinion whether we should mandate the way in w= hich hi-targeted-uri is to be anonymized. > >> 8. "MUST be calculated by incrementing the last/lowest digit > >> =A0 =A0 =A0 at the current level" > >> and > >> "That is, the lowest/last digit of the index MUST be > >> =A0 =A0 =A0 incremented " > >> What if an index is a double-digit integer? > > > > =A0How about we remove the "lowest/last" and simply > > say incrementing the digit at the current level by 1 or > > something like that. [JRE] Why can't we specify the field as an integer, and then we can say we = increment the integer? > >> 9. Section 8: > >> "an > >> =A0 application might need to provide special handling in some cases > >> =A0 where there are gaps." > >> Should there be a note discussing the fact that some gaps=20 > are not detectable, e.g., if I receive 1, 1.1 and 1.1.1, I=20 > cannot detect if 1.2 or 1.1.2, say, is missing. > > > > =A0This would happen, say for example if request was > > parallel forked, each branch would have the hi-entry > > that only the forked request traversed but missing > > the information of the other forks. I don't know if I would > > consider what you describe as a gap. You may be > > missing the other branches but you should be able to > > identify the gap in index for the branch that request > > traversed. (You may be missing the actual hop in the > > logical tree of History-Info that does not support > > 4244/4244bis but as they won't add the hi-entry > > there won't be a gap in index itself). [JRE] Yes, I understand that, and that is why I just asked the question - I= don't have a strong opinion as to whether this is good enough or not. John= From HKaplan@acmepacket.com Sun Nov 7 22:31:38 2010 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 From shida@ntt-at.com Sun Nov 7 22:50:08 2010 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 B65B33A69BA for ; Sun, 7 Nov 2010 22:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 Rt1pUxZWQS47 for ; Sun, 7 Nov 2010 22:49:59 -0800 (PST) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [67.18.10.9]) by core3.amsl.com (Postfix) with SMTP id 5A8803A69D8 for ; Sun, 7 Nov 2010 22:49:59 -0800 (PST) Received: (qmail 5838 invoked from network); 8 Nov 2010 06:49:50 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway05.websitewelcome.com with SMTP; 8 Nov 2010 06:49:50 -0000 Received: from [130.129.65.133] (port=51964 helo=dhcp-4185.meeting.ietf.org) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PFLYS-0005T4-QC; Mon, 08 Nov 2010 00:50:14 -0600 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Mon, 8 Nov 2010 15:50:13 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Elwell, John" 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: "Barnes, Mary" , "sipcore@ietf.org" Subject: Re: [sipcore] Yet more comments on 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:50:08 -0000 Hi John; My comments inline. On Nov 8, 2010, at 3:31 PM, Elwell, John wrote: > Replying to both Shida and Mary:=20 >=20 >> -----Original Message----- >> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 >> Sent: 08 November 2010 05:19 >> To: Shida Schubert >> Cc: Elwell, John; Barnes, Mary; sipcore@ietf.org >> Subject: Re: [sipcore] Yet more comments on rfc4244bis-02 >>=20 >> A few additional comments inline below [MB]. >>=20 >> Mary. >>=20 >> On Sun, Nov 7, 2010 at 12:28 AM, Shida Schubert=20 >> wrote: >>>=20 >>> Hi John; >>>=20 >>> My responses on some of the comments, I think >>> Mary may be responding on the same issues but here are mine. >>>=20 >>> On Nov 4, 2010, at 12:29 AM, Elwell, John wrote: >>>=20 >>>> 1. Section 7.3.1. >>>> "If there is a Privacy header in the request with a priv- >>>> value of "header" or "history", then the initial hi-entry MUST be >>>> anonymized and the header removed when the request=20 >> leaves a domain >>>> for which the SIP entity is responsible." >>>> I think it should say "...and the Privacy header removed"=20 >> - there is no point in removing the H-I header field if we=20 >> have anonymized it. >>>=20 >>> You are right. The intention was to say "remove the=20 >> priv-value and remove the privacy >>> header itself if there are no other priv-value left (id may=20 >> exists which needs >>> to remain in the request until it reaches the egress point)". >>>=20 >>>>=20 >>>> 2. What is meant by anonymizing a hi-entry (in this=20 >> paragraph and elsewhere)? Is it only the hi-targeted-to-uri=20 >> that needs to be anonymized, or also its parameters? The=20 >> examples in annex B show just the URI anonymized and with the=20 >> value anonymous@anonymous.invalid. Is this how it MUST be done? >>=20 >> [MB] It is only the hi-targeted-to-uri that needs to be anonymized - >> it is a MUST. The other parameters MUST not be changed. [/MB] > [JRE] You didn't express any opinion whether we should mandate the way = in which hi-targeted-uri is to be anonymized. To avoid redundant anonymization in case there are numerous=20 proxy acting as a privacy services, it would be good to mandate=20 how hi-targeted-uri is anonymized, so I am happy to say MUST=20 here.=20 >=20 > >=20 >>>> 8. "MUST be calculated by incrementing the last/lowest digit >>>> at the current level" >>>> and >>>> "That is, the lowest/last digit of the index MUST be >>>> incremented " >>>> What if an index is a double-digit integer? >>>=20 >>> How about we remove the "lowest/last" and simply >>> say incrementing the digit at the current level by 1 or >>> something like that. > [JRE] Why can't we specify the field as an integer, and then we can = say we increment the integer? Sounds good to me.=20 >=20 >>>> 9. Section 8: >>>> "an >>>> application might need to provide special handling in some cases >>>> where there are gaps." >>>> Should there be a note discussing the fact that some gaps=20 >> are not detectable, e.g., if I receive 1, 1.1 and 1.1.1, I=20 >> cannot detect if 1.2 or 1.1.2, say, is missing. >>>=20 >>> This would happen, say for example if request was >>> parallel forked, each branch would have the hi-entry >>> that only the forked request traversed but missing >>> the information of the other forks. I don't know if I would >>> consider what you describe as a gap. You may be >>> missing the other branches but you should be able to >>> identify the gap in index for the branch that request >>> traversed. (You may be missing the actual hop in the >>> logical tree of History-Info that does not support >>> 4244/4244bis but as they won't add the hi-entry >>> there won't be a gap in index itself). > [JRE] Yes, I understand that, and that is why I just asked the = question - I don't have a strong opinion as to whether this is good = enough or not. I think we can definitely add a text saying the hi-entries=20 an entity receives may not represent the whole picture=20 of where request was sent (other branches etc.).=20 Regards Shida >=20 > >=20 > John From mary.ietf.barnes@gmail.com Sun Nov 7 22:56:02 2010 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 E85373A69BA for ; Sun, 7 Nov 2010 22:56:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.532 X-Spam-Level: X-Spam-Status: No, score=-102.532 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, 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 iaGymPzRLNRm for ; Sun, 7 Nov 2010 22:55:47 -0800 (PST) Received: from mail-yw0-f44.google.com (mail-yw0-f44.google.com [209.85.213.44]) by core3.amsl.com (Postfix) with ESMTP id 0FD943A6996 for ; Sun, 7 Nov 2010 22:55:29 -0800 (PST) Received: by ywp6 with SMTP id 6so3453586ywp.31 for ; Sun, 07 Nov 2010 22:55:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=ir1vIxOYUXzh7MeU9oXgBtyB7hSdprjPVQnm6pzEoic=; b=C3Y+WuQ5OHWRu47lQM3S7A/iRzGFd3V9t+NwTLNdIzTG2K3jUsZ2jqmwpHxcC+tSp+ b++3RD4RYK46HY+Z0bPG1SMeR2/pQIW1MJZOus/czxsDZ7h4omAnRxk6GHLw1sIN/JES hI6wKG4l+PHMPwEV7Pd+8IXlCGXb/qCGpbFQM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=hkzvhxkc0HcHyemaB9SZCxMfbo/RO3NZ9IyhUj3HQTepA117j1VmJpCKYELHqx+cfn rNHZPZ4tCZKYO2knz9x8vebxC6txnxvJy4wy9dUdJ4QEKl+yFiCploZ8aQ6pOimBQFQU 61rndogTFrFTlEhAQNbzs3EXgFqlM+28rhono= MIME-Version: 1.0 Received: by 10.150.144.16 with SMTP id r16mr7981781ybd.204.1289199348647; Sun, 07 Nov 2010 22:55:48 -0800 (PST) Received: by 10.236.95.35 with HTTP; Sun, 7 Nov 2010 22:55:48 -0800 (PST) In-Reply-To: References: Date: Mon, 8 Nov 2010 00:55:48 -0600 Message-ID: From: Mary Barnes To: "Elwell, John" Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cc: "Barnes, Mary" , "sipcore@ietf.org" Subject: Re: [sipcore] Yet more comments on 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:56:02 -0000 A few more comments below [MB2]. Thanks, Mary. On Mon, Nov 8, 2010 at 12:31 AM, Elwell, John wrote: > Replying to both Shida and Mary: > >> -----Original Message----- >> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] >> Sent: 08 November 2010 05:19 >> To: Shida Schubert >> Cc: Elwell, John; Barnes, Mary; sipcore@ietf.org >> Subject: Re: [sipcore] Yet more comments on rfc4244bis-02 >> >> A few additional comments inline below [MB]. >> >> Mary. >> >> On Sun, Nov 7, 2010 at 12:28 AM, Shida Schubert >> wrote: >> > >> > Hi John; >> > >> > =A0My responses on some of the comments, I think >> > Mary may be responding on the same issues but here are mine. >> > >> > On Nov 4, 2010, at 12:29 AM, Elwell, John wrote: >> > >> >> 1. Section 7.3.1. >> >> "If there is a Privacy header in the request with a priv- >> >> =A0 value of "header" or "history", then the initial hi-entry MUST be >> >> =A0 anonymized and the header removed when the request >> leaves a domain >> >> =A0 for which the SIP entity is responsible." >> >> I think it should say "...and the Privacy header removed" >> - there is no point in removing the H-I header field if we >> have anonymized it. >> > >> > =A0You are right. The intention was to say "remove the >> priv-value and remove the privacy >> > header itself if there are no other priv-value left (id may >> exists which needs >> > to remain in the request until it reaches the egress point)". >> > >> >> >> >> 2. What is meant by anonymizing a hi-entry (in this >> paragraph and elsewhere)? Is it only the hi-targeted-to-uri >> that needs to be anonymized, or also its parameters? The >> examples in annex B show just the URI anonymized and with the >> value anonymous@anonymous.invalid. Is this how it MUST be done? >> >> [MB] It is only the hi-targeted-to-uri that needs to be anonymized - >> it is a MUST. The other parameters MUST not be changed. [/MB] > [JRE] You didn't express any opinion whether we should mandate the way in= which hi-targeted-uri is to be anonymized. [MB2] My opinion is that we should mandate the anonymization in the same form as in RFC 3323. I can't think of a reason why it shouldn't be mandated. [MB2] > > > >> >> 8. "MUST be calculated by incrementing the last/lowest digit >> >> =A0 =A0 =A0 at the current level" >> >> and >> >> "That is, the lowest/last digit of the index MUST be >> >> =A0 =A0 =A0 incremented " >> >> What if an index is a double-digit integer? >> > >> > =A0How about we remove the "lowest/last" and simply >> > say incrementing the digit at the current level by 1 or >> > something like that. > [JRE] Why can't we specify the field as an integer, and then we can say w= e increment the integer? [MB] It can't be an integer since it can't have negative values. But, you are correct, we do need to allow multi-digit indices, so the ABNF needs to be fixed. [/MB] > >> >> 9. Section 8: >> >> "an >> >> =A0 application might need to provide special handling in some cases >> >> =A0 where there are gaps." >> >> Should there be a note discussing the fact that some gaps >> are not detectable, e.g., if I receive 1, 1.1 and 1.1.1, I >> cannot detect if 1.2 or 1.1.2, say, is missing. >> > >> > =A0This would happen, say for example if request was >> > parallel forked, each branch would have the hi-entry >> > that only the forked request traversed but missing >> > the information of the other forks. I don't know if I would >> > consider what you describe as a gap. You may be >> > missing the other branches but you should be able to >> > identify the gap in index for the branch that request >> > traversed. (You may be missing the actual hop in the >> > logical tree of History-Info that does not support >> > 4244/4244bis but as they won't add the hi-entry >> > there won't be a gap in index itself). > [JRE] Yes, I understand that, and that is why I just asked the question -= I don't have a strong opinion as to whether this is good enough or not. > > > > John From R.Jesske@telekom.de Sun Nov 7 23:55:23 2010 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 7D1DD3A6897 for ; Sun, 7 Nov 2010 23:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pQuqxPFekyPc for ; Sun, 7 Nov 2010 23:55:22 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id D5E633A6892 for ; Sun, 7 Nov 2010 23:55:21 -0800 (PST) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail81.telekom.de with ESMTP; 08 Nov 2010 08:55:37 +0100 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 08:55:36 +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, 8 Nov 2010 08:55:36 +0100 Message-ID: <9886E5FCA6D76549A3011068483A4BD406D5CF89@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Yet more comments on rfc4244bis-02 Thread-Index: Act/ET+h06LyiiFUQcCqjFEXp/cbKAAAZ/Ng References: From: To: , X-OriginalArrivalTime: 08 Nov 2010 07:55:36.0880 (UTC) FILETIME=[54349300:01CB7F1A] Cc: Mary.Barnes@polycom.com, sipcore@ietf.org Subject: Re: [sipcore] Yet more comments on 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 07:55:23 -0000 Shida, Do I understand you correct that you woulf like to mandate the uri = format e.g. anonymus@anonymus,invalid?=20 Why you would like it to be stronger than in RFC3323 mandated? Best Regards Roland =20 -----Urspr=FCngliche Nachricht----- Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im = Auftrag von Shida Schubert Gesendet: Montag, 8. November 2010 07:50 An: Elwell, John Cc: Barnes, Mary; sipcore@ietf.org Betreff: Re: [sipcore] Yet more comments on rfc4244bis-02 Hi John; My comments inline. On Nov 8, 2010, at 3:31 PM, Elwell, John wrote: > Replying to both Shida and Mary:=20 >=20 >> -----Original Message----- >> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 >> Sent: 08 November 2010 05:19 >> To: Shida Schubert >> Cc: Elwell, John; Barnes, Mary; sipcore@ietf.org >> Subject: Re: [sipcore] Yet more comments on rfc4244bis-02 >>=20 >> A few additional comments inline below [MB]. >>=20 >> Mary. >>=20 >> On Sun, Nov 7, 2010 at 12:28 AM, Shida Schubert=20 >> wrote: >>>=20 >>> Hi John; >>>=20 >>> My responses on some of the comments, I think >>> Mary may be responding on the same issues but here are mine. >>>=20 >>> On Nov 4, 2010, at 12:29 AM, Elwell, John wrote: >>>=20 >>>> 1. Section 7.3.1. >>>> "If there is a Privacy header in the request with a priv- >>>> value of "header" or "history", then the initial hi-entry MUST be >>>> anonymized and the header removed when the request=20 >> leaves a domain >>>> for which the SIP entity is responsible." >>>> I think it should say "...and the Privacy header removed"=20 >> - there is no point in removing the H-I header field if we=20 >> have anonymized it. >>>=20 >>> You are right. The intention was to say "remove the=20 >> priv-value and remove the privacy >>> header itself if there are no other priv-value left (id may=20 >> exists which needs >>> to remain in the request until it reaches the egress point)". >>>=20 >>>>=20 >>>> 2. What is meant by anonymizing a hi-entry (in this=20 >> paragraph and elsewhere)? Is it only the hi-targeted-to-uri=20 >> that needs to be anonymized, or also its parameters? The=20 >> examples in annex B show just the URI anonymized and with the=20 >> value anonymous@anonymous.invalid. Is this how it MUST be done? >>=20 >> [MB] It is only the hi-targeted-to-uri that needs to be anonymized - >> it is a MUST. The other parameters MUST not be changed. [/MB] > [JRE] You didn't express any opinion whether we should mandate the way = in which hi-targeted-uri is to be anonymized. To avoid redundant anonymization in case there are numerous=20 proxy acting as a privacy services, it would be good to mandate=20 how hi-targeted-uri is anonymized, so I am happy to say MUST=20 here.=20 >=20 > >=20 >>>> 8. "MUST be calculated by incrementing the last/lowest digit >>>> at the current level" >>>> and >>>> "That is, the lowest/last digit of the index MUST be >>>> incremented " >>>> What if an index is a double-digit integer? >>>=20 >>> How about we remove the "lowest/last" and simply >>> say incrementing the digit at the current level by 1 or >>> something like that. > [JRE] Why can't we specify the field as an integer, and then we can = say we increment the integer? Sounds good to me.=20 >=20 >>>> 9. Section 8: >>>> "an >>>> application might need to provide special handling in some cases >>>> where there are gaps." >>>> Should there be a note discussing the fact that some gaps=20 >> are not detectable, e.g., if I receive 1, 1.1 and 1.1.1, I=20 >> cannot detect if 1.2 or 1.1.2, say, is missing. >>>=20 >>> This would happen, say for example if request was >>> parallel forked, each branch would have the hi-entry >>> that only the forked request traversed but missing >>> the information of the other forks. I don't know if I would >>> consider what you describe as a gap. You may be >>> missing the other branches but you should be able to >>> identify the gap in index for the branch that request >>> traversed. (You may be missing the actual hop in the >>> logical tree of History-Info that does not support >>> 4244/4244bis but as they won't add the hi-entry >>> there won't be a gap in index itself). > [JRE] Yes, I understand that, and that is why I just asked the = question - I don't have a strong opinion as to whether this is good = enough or not. I think we can definitely add a text saying the hi-entries=20 an entity receives may not represent the whole picture=20 of where request was sent (other branches etc.).=20 Regards Shida >=20 > >=20 > John _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From R.Jesske@telekom.de Sun Nov 7 23:55:25 2010 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 CED543A689B for ; Sun, 7 Nov 2010 23:55:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OP-c0YofR9dc for ; Sun, 7 Nov 2010 23:55:24 -0800 (PST) Received: from tcmail53.telekom.de (tcmail53.telekom.de [217.5.214.110]) by core3.amsl.com (Postfix) with ESMTP id 761333A6868 for ; Sun, 7 Nov 2010 23:55:23 -0800 (PST) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail51.telekom.de with ESMTP; 08 Nov 2010 08:55:39 +0100 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de 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, 8 Nov 2010 08:53:02 +0100 Message-ID: <9886E5FCA6D76549A3011068483A4BD406D5CF8B@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: 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: <4CD6C020.7030603@cisco.com><4CD7555F.30609@cisco.com> From: To: , X-OriginalArrivalTime: 08 Nov 2010 07:55:38.0961 (UTC) FILETIME=[55721C10:01CB7F1A] Cc: sipcore@ietf.org Subject: Re: [sipcore] Reason as a parameter rather than an escapedheader (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 07:55:25 -0000 Hi, we have already a mechanism putting a "cause" into the URI which is the = target. RFC4458 describes this for diverting reasons.=20 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-extension-applicat= ion-00 and other needed.=20 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?=20 Best Regards Roland=20 -----Urspr=FCngliche 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: >=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 = 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. >>=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 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From shida@ntt-at.com Mon Nov 8 00:32:05 2010 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 2705F3A6774 for ; Mon, 8 Nov 2010 00:32:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.265 X-Spam-Level: X-Spam-Status: No, score=-102.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 gEzfsUpkDjxS for ; Mon, 8 Nov 2010 00:32:04 -0800 (PST) Received: from gateway01.websitewelcome.com (gateway01.websitewelcome.com [69.41.248.83]) by core3.amsl.com (Postfix) with SMTP id 00B5C3A6452 for ; Mon, 8 Nov 2010 00:32:03 -0800 (PST) Received: (qmail 14903 invoked from network); 8 Nov 2010 08:32:24 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway01.websitewelcome.com with SMTP; 8 Nov 2010 08:32:24 -0000 Received: from [130.129.65.133] (port=52331 helo=dhcp-4185.meeting.ietf.org) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PFN99-0005pu-GJ; Mon, 08 Nov 2010 02:32:23 -0600 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Shida Schubert In-Reply-To: <9886E5FCA6D76549A3011068483A4BD406D5CF89@S4DE8PSAAQB.mitte.t-com.de> Date: Mon, 8 Nov 2010 17:32:06 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <3D738383-240F-4E46-AD44-24601C1C297C@ntt-at.com> References: <9886E5FCA6D76549A3011068483A4BD406D5CF89@S4DE8PSAAQB.mitte.t-com.de> To: 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, Mary.Barnes@polycom.com Subject: Re: [sipcore] Yet more comments on 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 08:32:05 -0000 Hi Roland; I meant to say, mandate the use of domain name "anonymous.invalid" as=20= it is mandated in RFC3323 and used as a means to distinguish anonymized=20= URI in RFC5079. This would help privacy service to see if other privacy=20= service has already obfuscated the URI in H-I.=20 Regards Shida On Nov 8, 2010, at 4:55 PM, = wrote: > Shida, > Do I understand you correct that you woulf like to mandate the uri = format e.g. anonymus@anonymus,invalid?=20 > Why you would like it to be stronger than in RFC3323 mandated? >=20 > Best Regards >=20 > Roland >=20 >=20 >=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im = Auftrag von Shida Schubert > Gesendet: Montag, 8. November 2010 07:50 > An: Elwell, John > Cc: Barnes, Mary; sipcore@ietf.org > Betreff: Re: [sipcore] Yet more comments on rfc4244bis-02 >=20 >=20 > Hi John; >=20 > My comments inline. >=20 > On Nov 8, 2010, at 3:31 PM, Elwell, John wrote: >=20 >> Replying to both Shida and Mary:=20 >>=20 >>> -----Original Message----- >>> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com]=20 >>> Sent: 08 November 2010 05:19 >>> To: Shida Schubert >>> Cc: Elwell, John; Barnes, Mary; sipcore@ietf.org >>> Subject: Re: [sipcore] Yet more comments on rfc4244bis-02 >>>=20 >>> A few additional comments inline below [MB]. >>>=20 >>> Mary. >>>=20 >>> On Sun, Nov 7, 2010 at 12:28 AM, Shida Schubert=20 >>> wrote: >>>>=20 >>>> Hi John; >>>>=20 >>>> My responses on some of the comments, I think >>>> Mary may be responding on the same issues but here are mine. >>>>=20 >>>> On Nov 4, 2010, at 12:29 AM, Elwell, John wrote: >>>>=20 >>>>> 1. Section 7.3.1. >>>>> "If there is a Privacy header in the request with a priv- >>>>> value of "header" or "history", then the initial hi-entry MUST be >>>>> anonymized and the header removed when the request=20 >>> leaves a domain >>>>> for which the SIP entity is responsible." >>>>> I think it should say "...and the Privacy header removed"=20 >>> - there is no point in removing the H-I header field if we=20 >>> have anonymized it. >>>>=20 >>>> You are right. The intention was to say "remove the=20 >>> priv-value and remove the privacy >>>> header itself if there are no other priv-value left (id may=20 >>> exists which needs >>>> to remain in the request until it reaches the egress point)". >>>>=20 >>>>>=20 >>>>> 2. What is meant by anonymizing a hi-entry (in this=20 >>> paragraph and elsewhere)? Is it only the hi-targeted-to-uri=20 >>> that needs to be anonymized, or also its parameters? The=20 >>> examples in annex B show just the URI anonymized and with the=20 >>> value anonymous@anonymous.invalid. Is this how it MUST be done? >>>=20 >>> [MB] It is only the hi-targeted-to-uri that needs to be anonymized - >>> it is a MUST. The other parameters MUST not be changed. [/MB] >> [JRE] You didn't express any opinion whether we should mandate the = way in which hi-targeted-uri is to be anonymized. >=20 > To avoid redundant anonymization in case there are numerous=20 > proxy acting as a privacy services, it would be good to mandate=20 > how hi-targeted-uri is anonymized, so I am happy to say MUST=20 > here.=20 >=20 >>=20 >> >>=20 >>>>> 8. "MUST be calculated by incrementing the last/lowest digit >>>>> at the current level" >>>>> and >>>>> "That is, the lowest/last digit of the index MUST be >>>>> incremented " >>>>> What if an index is a double-digit integer? >>>>=20 >>>> How about we remove the "lowest/last" and simply >>>> say incrementing the digit at the current level by 1 or >>>> something like that. >> [JRE] Why can't we specify the field as an integer, and then we can = say we increment the integer? >=20 > Sounds good to me.=20 >=20 >>=20 >>>>> 9. Section 8: >>>>> "an >>>>> application might need to provide special handling in some cases >>>>> where there are gaps." >>>>> Should there be a note discussing the fact that some gaps=20 >>> are not detectable, e.g., if I receive 1, 1.1 and 1.1.1, I=20 >>> cannot detect if 1.2 or 1.1.2, say, is missing. >>>>=20 >>>> This would happen, say for example if request was >>>> parallel forked, each branch would have the hi-entry >>>> that only the forked request traversed but missing >>>> the information of the other forks. I don't know if I would >>>> consider what you describe as a gap. You may be >>>> missing the other branches but you should be able to >>>> identify the gap in index for the branch that request >>>> traversed. (You may be missing the actual hop in the >>>> logical tree of History-Info that does not support >>>> 4244/4244bis but as they won't add the hi-entry >>>> there won't be a gap in index itself). >> [JRE] Yes, I understand that, and that is why I just asked the = question - I don't have a strong opinion as to whether this is good = enough or not. >=20 > I think we can definitely add a text saying the hi-entries=20 > an entity receives may not represent the whole picture=20 > of where request was sent (other branches etc.).=20 >=20 > Regards > Shida >=20 >>=20 >> >>=20 >> John >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Mon Nov 8 02:20:56 2010 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 8BEEA3A6990 for ; Mon, 8 Nov 2010 02:20:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.959 X-Spam-Level: X-Spam-Status: No, score=-109.959 tagged_above=-999 required=5 tests=[AWL=-0.560, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8, 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 sIBrbs0V1V8o for ; Mon, 8 Nov 2010 02:20:54 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 944C03A694F for ; Mon, 8 Nov 2010 02:20:54 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABhe10xAaMHG/2dsb2JhbACiBHGhJpp3gnEBglYEhFiFfYMKiEQ X-IronPort-AV: E=Sophos;i="4.58,313,1286150400"; d="scan'208";a="282461861" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-5.cisco.com with ESMTP; 08 Nov 2010 10:21:14 +0000 Received: from [10.75.233.72] (hkidc-vpn-client-233-72.cisco.com [10.75.233.72]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA8AL95W010897 for ; Mon, 8 Nov 2010 10:21:11 GMT Message-ID: <4CD7CF13.5000005@cisco.com> Date: Mon, 08 Nov 2010 05:21:07 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: sipcore@ietf.org References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Yet more comments on 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 10:20:56 -0000 Why do you think that Privacy:none is not important for H-I? IIUC, Privacy:none is a way for a caller to get identity info passed e2e even if there are SPs along the path that wish to block things. Why would that not apply to H-I as well? I may want the callee to know the history of the call even if my SP does not wish that. Thanks, Paul On 11/8/2010 12:19 AM, Mary Barnes wrote: > A few additional comments inline below [MB]. > > Mary. > > On Sun, Nov 7, 2010 at 12:28 AM, Shida Schubert wrote: >> >> Hi John; >> >> My responses on some of the comments, I think >> Mary may be responding on the same issues but here are mine. >> >> On Nov 4, 2010, at 12:29 AM, Elwell, John wrote: >> >>> 1. Section 7.3.1. >>> "If there is a Privacy header in the request with a priv- >>> value of "header" or "history", then the initial hi-entry MUST be >>> anonymized and the header removed when the request leaves a domain >>> for which the SIP entity is responsible." >>> I think it should say "...and the Privacy header removed" - there is no point in removing the H-I header field if we have anonymized it. >> >> You are right. The intention was to say "remove the priv-value and remove the privacy >> header itself if there are no other priv-value left (id may exists which needs >> to remain in the request until it reaches the egress point)". >> >>> >>> 2. What is meant by anonymizing a hi-entry (in this paragraph and elsewhere)? Is it only the hi-targeted-to-uri that needs to be anonymized, or also its parameters? The examples in annex B show just the URI anonymized and with the value anonymous@anonymous.invalid. Is this how it MUST be done? > > [MB] It is only the hi-targeted-to-uri that needs to be anonymized - > it is a MUST. The other parameters MUST not be changed. [/MB] >> >> I personally don't have a strong opinion about prescribing the anonymous@anonymou.invalid but >> I think it would be useful to specify what the anonymized URI should look like. This would avoid >> anonymous URI anonymized numerous time by different privacy service for example... >> As for the parameter, if rc/mp tag, index and encoded reason(RFC 3326) are intact, >> anonymized hi-entry can still provide some value, so I think only hi-targeted-to-uri should be >> anonymized. >> >>> >>> 3. In the same sentence, is it sufficient to anonymize only the first hi-entry? There could be further hi-entries for the same domain, and just revealing internal routing within the domain might be considered a breach of privacy. Perhaps in that case you would need to rely on those additional hi-entries being separately marked for privacy. If that is so, it would seem to be OK. >> >> Your last suggestion/assumption was exactly the motivation and our >> attempt to simplify privacy handling, by saying Privacy header with priv-value >> of "history"/"header" (not in hi-entry) for anonymizing first hi-entry only and to use >> privacy=header in hi-entry for any other hi-entries. >> >> It would mean; >> >> 1. UA requests H-I privacy by using Privacy:history or Privacy:header >> 2. Proxy request H-I privacy by using History-Info:?privacy=history >> >> Which we thought would clarify the timing of when Privacy:history / Privacy:header >> and privacy=history are used. >> >> But thinking further, it doesn't really simplify the overall >> privacy handling of H-I and furthermore it changes the semantics of >> header privacy in RFC3323. >> >> Excerpt from RFC3323 on header privacy says: >> >> "If a privacy level of 'header' is requested, then the originating >> user has asked the privacy service to help to obscure headers that >> might otherwise reveal information about the originator of the >> request." >> >> This can encompass entries revealing internal routing and domain >> information as you mentioned above, so restricting the use of Privacy:header >> to first entry only can be seen as changing the semantics defined in RFC3323. >> >> I think we should align the handling of H-I privacy of Privacy:history >> and Privacy:header to that of RFC3323, allowing privacy service to >> anonymize not only the first hi-entry but any other entries that >> are from its domain. > [MB] I don't have a strong opinion here. The suggestion above makes > alot of sense. [/MB] >> >> I guess we need to further clarify how these two means of requesting >> privacy interact, since you can have both privacy:history and few hi-entries >> with privacy=history. I am assuming that when privacy service anonymizes >> history-info header based on privacy:history or privacy:header, it also >> needs to remove the privacy=history from hi-entries that it's anonymizing. > [MB] Yes, we should clarify. With the approach discussed above, the > privacy:history would "override" the privacy for each entry (within > that domain). And, yes, per a previous thread, we do need to update > the privacy text to indicate the removal of the privacy for each > hi-entry as it is anonymized. [/MB] > >> >> Lastly what about the interaction with privacy:none? According to >> section 5.1 of 4244bis, if UAC doesn't want privacy on its identity it sets >> Privacy header with priv-value of "none", but I am having a hard time >> envisioning the need for this. When do you ever get the hi-entry representing >> your own AoR or contact address? > [MB] We originally did not include privacy of "none" as relevant to > History-info (in 4244). That was added in -bis and I to question the > value. I do not think it has any value as applied to History-Info and > I would suggest we remove it or note that it has no impact in terms of > the processing of privacy for the hi-entries. [/MB] >> >> I think the hi-entry with privacy=history should still be anonymized, even when >> the Privacy:none is set in request because the privacy is requested by proxy, I >> think we need to add text on this as well. > [MB] Agreed. [/MB] >> >> >>> >>> 4. "In addition, the History-Info header can reveal general routing and >>> diverting information within an intermediary, " >>> Is it only routing information within an intermediary, or also routing information within a domain that you might want to make private? I think text later in the paragraph concurs with the latter view. > [MB] yes, it's the latter - within a domain for which the > intermediary is responsible. [/MB] >>> >>> 5. "Finally, the terminator of the request may not want to reveal the >>> final reached target to the originator. In this case, the terminator >>> uses the a value of "history" in the Privacy header in the last hi- >>> entry in the response. The SIP entity that forwards the response >>> MUST anonymize that hi-entry and remove the Privacy header." >>> Although a UAS can mark the final hi-entry as private, and there is a requirement for a proxy to anonymize this when the response leaves the domain, what about other hi-entries that have been marked by proxies in the final domain as private? These will get passed back in the response without anonymization since they are not the final hi-entry and are not covered by this statement. Should the final sentence apply to any hi-entry? > [MB] Yes. that sentence should apply to all responses - i.e., in > general if there are hi-entries with an escaped privacy header, they > should be anonymized and the privacy header removed. [/MB] >> >> RFC3323 recommends that privacy service to be included in the >> request/response path if privacy is desired. The privacy handling >> in 4244bis is based on RFC3323 so I don't know if we need to add >> anything specific here for anonymizing the response. >> >>> >>> 6. Section 7.3.3: >>> "To >>> accomplish this, the processing entity MUST read the value from >>> the History-Info header in the received request and MUST add >>> another level of indexing " >>> Should make it clear it is the last hi-entry of the received request (after adding entries on behalf of previous hops). >> >> Agree. >> >>> >>> 7. "followed >>> by an initial index for the new level of 1" >>> I think this would be clearer if it said: >>> "followed by an initial index of 1 for the new level" >> >> Agree. >> >>> >>> 8. "MUST be calculated by incrementing the last/lowest digit >>> at the current level" >>> and >>> "That is, the lowest/last digit of the index MUST be >>> incremented " >>> What if an index is a double-digit integer? >> >> How about we remove the "lowest/last" and simply >> say incrementing the digit at the current level by 1 or >> something like that. >> >>> >>> 9. Section 8: >>> "an >>> application might need to provide special handling in some cases >>> where there are gaps." >>> Should there be a note discussing the fact that some gaps are not detectable, e.g., if I receive 1, 1.1 and 1.1.1, I cannot detect if 1.2 or 1.1.2, say, is missing. >> >> This would happen, say for example if request was >> parallel forked, each branch would have the hi-entry >> that only the forked request traversed but missing >> the information of the other forks. I don't know if I would >> consider what you describe as a gap. You may be >> missing the other branches but you should be able to >> identify the gap in index for the branch that request >> traversed. (You may be missing the actual hop in the >> logical tree of History-Info that does not support >> 4244/4244bis but as they won't add the hi-entry >> there won't be a gap in index itself). >> >>> >>> 10. Should we say anything in section 8 about anonymized entries? Note that what we might say depends to some extent on whether what exactly gets anomymised. For example if an application searches for an rc or mp entry, if those parameters have been anonymized it will not find them (but might find others that have not been anonymized!), but if those parameters have not been anonymized it will find them but the URI will be useless. >> >> URI will be useless but one can still determine how many times >> request was retargeted, for example (Of course this is true only >> if all the proxies are rfc4244bis compliant), which I think remains >> useful. >> >>> >>> 11. Section 9: >>> "With the level of security provided by TLS (SEC-req-3), the >>> information in the History-Info header can thus be evaluated to >>> determine if information has been removed by evaluating the indices >>> for gaps (SEC-req-1, SEC-req-2). " >>> This is subject to the limitation pointed out in a comment above, about not all gaps being detectable. >>> >>> 12. I would expect to see something in section 9 concerning privacy. We should mention the privacy mechanism and discuss its limits (i.e., depends on trust of downstream entities to anonymize privacy-marked entries). Also there should probably be some discussion on strength of anonymization algorithms (unless we are indeed prescribing anonymous@anonymous.invalid). >> >> Agree that text should be added. >> >>> >>> 13. Section 10.2: >>> "This document defines a priv-value for the SIP Privacy header: >>> history The following changes have been made to >>> http://www.iana.org/assignments/sip-priv-values The following has >>> been added to the registration for the SIP Privacy header:" >>> I am not sure how to parse this. >> >>> >>> >>> 14. Section 12.1: >>> "This specification adds an >>> optional SIP header field parameter to the History-Info and Contact >>> headers. " >>> In fact it adds two parameters to each. >> >> Indeed. >> >>> >>> 15. "Entities that have not implemented this specification MUST >>> ignore these parameters, " >>> We cannot place a normative requirement on entities that don't implement this. Change "MUST" to "will". >> >> Agree. >> >>> >>> John >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > From shida@ntt-at.com Mon Nov 8 03:01:41 2010 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 09B9A28C13A for ; Mon, 8 Nov 2010 03:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.665 X-Spam-Level: X-Spam-Status: No, score=-101.665 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_63=0.6, J_CHICKENPOX_74=0.6, 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 Q9IUiYEaLfn8 for ; Mon, 8 Nov 2010 03:01:39 -0800 (PST) Received: from gateway13.websitewelcome.com (gateway13.websitewelcome.com [69.41.255.6]) by core3.amsl.com (Postfix) with SMTP id 2CEC93A6989 for ; Mon, 8 Nov 2010 03:01:39 -0800 (PST) Received: (qmail 28995 invoked from network); 8 Nov 2010 11:01:41 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway13.websitewelcome.com with SMTP; 8 Nov 2010 11:01:41 -0000 Received: from [130.129.65.133] (port=53733 helo=dhcp-4185.meeting.ietf.org) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PFPTv-0006H9-53; Mon, 08 Nov 2010 05:01:58 -0600 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <4CD7CF13.5000005@cisco.com> Date: Mon, 8 Nov 2010 20:01:44 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CD7CF13.5000005@cisco.com> To: Paul Kyzivat 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 Subject: Re: [sipcore] Yet more comments on 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 11:01:41 -0000 Paul; Privacy:none is used when caller (UAC) wants his/her identity delivered=20= to the destination (callee) despite the existence of privacy service, = but=20 with regards to H-I, when does it ever contain the URI that identifies = the=20 caller (UAC) ?=20 I agree that privacy:none will be valid if we can find a situation = where=20 URI of UA will be one of the hi-entry but my imagination is not strong=20= enough to see this.=20 Regards Shida=20 On Nov 8, 2010, at 7:21 PM, Paul Kyzivat wrote: > Why do you think that Privacy:none is not important for H-I? > IIUC, Privacy:none is a way for a caller to get identity info passed = e2e even if there are SPs along the path that wish to block things. >=20 > Why would that not apply to H-I as well? I may want the callee to know = the history of the call even if my SP does not wish that. >=20 > Thanks, > Paul >=20 > On 11/8/2010 12:19 AM, Mary Barnes wrote: >> A few additional comments inline below [MB]. >>=20 >> Mary. >>=20 >> On Sun, Nov 7, 2010 at 12:28 AM, Shida Schubert = wrote: >>>=20 >>> Hi John; >>>=20 >>> My responses on some of the comments, I think >>> Mary may be responding on the same issues but here are mine. >>>=20 >>> On Nov 4, 2010, at 12:29 AM, Elwell, John wrote: >>>=20 >>>> 1. Section 7.3.1. >>>> "If there is a Privacy header in the request with a priv- >>>> value of "header" or "history", then the initial hi-entry MUST be >>>> anonymized and the header removed when the request leaves a = domain >>>> for which the SIP entity is responsible." >>>> I think it should say "...and the Privacy header removed" - there = is no point in removing the H-I header field if we have anonymized it. >>>=20 >>> You are right. The intention was to say "remove the priv-value and = remove the privacy >>> header itself if there are no other priv-value left (id may exists = which needs >>> to remain in the request until it reaches the egress point)". >>>=20 >>>>=20 >>>> 2. What is meant by anonymizing a hi-entry (in this paragraph and = elsewhere)? Is it only the hi-targeted-to-uri that needs to be = anonymized, or also its parameters? The examples in annex B show just = the URI anonymized and with the value anonymous@anonymous.invalid. Is = this how it MUST be done? >>=20 >> [MB] It is only the hi-targeted-to-uri that needs to be anonymized - >> it is a MUST. The other parameters MUST not be changed. [/MB] >>>=20 >>> I personally don't have a strong opinion about prescribing the = anonymous@anonymou.invalid but >>> I think it would be useful to specify what the anonymized URI should = look like. This would avoid >>> anonymous URI anonymized numerous time by different privacy service = for example... >>> As for the parameter, if rc/mp tag, index and encoded reason(RFC = 3326) are intact, >>> anonymized hi-entry can still provide some value, so I think only = hi-targeted-to-uri should be >>> anonymized. >>>=20 >>>>=20 >>>> 3. In the same sentence, is it sufficient to anonymize only the = first hi-entry? There could be further hi-entries for the same domain, = and just revealing internal routing within the domain might be = considered a breach of privacy. Perhaps in that case you would need to = rely on those additional hi-entries being separately marked for privacy. = If that is so, it would seem to be OK. >>>=20 >>> Your last suggestion/assumption was exactly the motivation and our >>> attempt to simplify privacy handling, by saying Privacy header with = priv-value >>> of "history"/"header" (not in hi-entry) for anonymizing first = hi-entry only and to use >>> privacy=3Dheader in hi-entry for any other hi-entries. >>>=20 >>> It would mean; >>>=20 >>> 1. UA requests H-I privacy by using Privacy:history or = Privacy:header >>> 2. Proxy request H-I privacy by using = History-Info:?privacy=3Dhistory >>>=20 >>> Which we thought would clarify the timing of when Privacy:history / = Privacy:header >>> and privacy=3Dhistory are used. >>>=20 >>> But thinking further, it doesn't really simplify the overall >>> privacy handling of H-I and furthermore it changes the semantics of >>> header privacy in RFC3323. >>>=20 >>> Excerpt from RFC3323 on header privacy says: >>>=20 >>> "If a privacy level of 'header' is requested, then the originating >>> user has asked the privacy service to help to obscure headers that >>> might otherwise reveal information about the originator of the >>> request." >>>=20 >>> This can encompass entries revealing internal routing and domain >>> information as you mentioned above, so restricting the use of = Privacy:header >>> to first entry only can be seen as changing the semantics defined in = RFC3323. >>>=20 >>> I think we should align the handling of H-I privacy of = Privacy:history >>> and Privacy:header to that of RFC3323, allowing privacy service to >>> anonymize not only the first hi-entry but any other entries that >>> are from its domain. >> [MB] I don't have a strong opinion here. The suggestion above makes >> alot of sense. [/MB] >>>=20 >>> I guess we need to further clarify how these two means of = requesting >>> privacy interact, since you can have both privacy:history and few = hi-entries >>> with privacy=3Dhistory. I am assuming that when privacy service = anonymizes >>> history-info header based on privacy:history or privacy:header, it = also >>> needs to remove the privacy=3Dhistory from hi-entries that it's = anonymizing. >> [MB] Yes, we should clarify. With the approach discussed above, the >> privacy:history would "override" the privacy for each entry (within >> that domain). And, yes, per a previous thread, we do need to update >> the privacy text to indicate the removal of the privacy for each >> hi-entry as it is anonymized. [/MB] >>=20 >>>=20 >>> Lastly what about the interaction with privacy:none? According to >>> section 5.1 of 4244bis, if UAC doesn't want privacy on its identity = it sets >>> Privacy header with priv-value of "none", but I am having a hard = time >>> envisioning the need for this. When do you ever get the hi-entry = representing >>> your own AoR or contact address? >> [MB] We originally did not include privacy of "none" as relevant to >> History-info (in 4244). That was added in -bis and I to question the >> value. I do not think it has any value as applied to History-Info = and >> I would suggest we remove it or note that it has no impact in terms = of >> the processing of privacy for the hi-entries. [/MB] >>>=20 >>> I think the hi-entry with privacy=3Dhistory should still be = anonymized, even when >>> the Privacy:none is set in request because the privacy is requested = by proxy, I >>> think we need to add text on this as well. >> [MB] Agreed. [/MB] >>>=20 >>>=20 >>>>=20 >>>> 4. "In addition, the History-Info header can reveal general routing = and >>>> diverting information within an intermediary, " >>>> Is it only routing information within an intermediary, or also = routing information within a domain that you might want to make private? = I think text later in the paragraph concurs with the latter view. >> [MB] yes, it's the latter - within a domain for which the >> intermediary is responsible. [/MB] >>>>=20 >>>> 5. "Finally, the terminator of the request may not want to reveal = the >>>> final reached target to the originator. In this case, the = terminator >>>> uses the a value of "history" in the Privacy header in the last = hi- >>>> entry in the response. The SIP entity that forwards the response >>>> MUST anonymize that hi-entry and remove the Privacy header." >>>> Although a UAS can mark the final hi-entry as private, and there is = a requirement for a proxy to anonymize this when the response leaves the = domain, what about other hi-entries that have been marked by proxies in = the final domain as private? These will get passed back in the response = without anonymization since they are not the final hi-entry and are not = covered by this statement. Should the final sentence apply to any = hi-entry? >> [MB] Yes. that sentence should apply to all responses - i.e., in >> general if there are hi-entries with an escaped privacy header, they >> should be anonymized and the privacy header removed. [/MB] >>>=20 >>> RFC3323 recommends that privacy service to be included in the >>> request/response path if privacy is desired. The privacy handling >>> in 4244bis is based on RFC3323 so I don't know if we need to add >>> anything specific here for anonymizing the response. >>>=20 >>>>=20 >>>> 6. Section 7.3.3: >>>> "To >>>> accomplish this, the processing entity MUST read the value = from >>>> the History-Info header in the received request and MUST add >>>> another level of indexing " >>>> Should make it clear it is the last hi-entry of the received = request (after adding entries on behalf of previous hops). >>>=20 >>> Agree. >>>=20 >>>>=20 >>>> 7. "followed >>>> by an initial index for the new level of 1" >>>> I think this would be clearer if it said: >>>> "followed by an initial index of 1 for the new level" >>>=20 >>> Agree. >>>=20 >>>>=20 >>>> 8. "MUST be calculated by incrementing the last/lowest digit >>>> at the current level" >>>> and >>>> "That is, the lowest/last digit of the index MUST be >>>> incremented " >>>> What if an index is a double-digit integer? >>>=20 >>> How about we remove the "lowest/last" and simply >>> say incrementing the digit at the current level by 1 or >>> something like that. >>>=20 >>>>=20 >>>> 9. Section 8: >>>> "an >>>> application might need to provide special handling in some cases >>>> where there are gaps." >>>> Should there be a note discussing the fact that some gaps are not = detectable, e.g., if I receive 1, 1.1 and 1.1.1, I cannot detect if 1.2 = or 1.1.2, say, is missing. >>>=20 >>> This would happen, say for example if request was >>> parallel forked, each branch would have the hi-entry >>> that only the forked request traversed but missing >>> the information of the other forks. I don't know if I would >>> consider what you describe as a gap. You may be >>> missing the other branches but you should be able to >>> identify the gap in index for the branch that request >>> traversed. (You may be missing the actual hop in the >>> logical tree of History-Info that does not support >>> 4244/4244bis but as they won't add the hi-entry >>> there won't be a gap in index itself). >>>=20 >>>>=20 >>>> 10. Should we say anything in section 8 about anonymized entries? = Note that what we might say depends to some extent on whether what = exactly gets anomymised. For example if an application searches for an = rc or mp entry, if those parameters have been anonymized it will not = find them (but might find others that have not been anonymized!), but if = those parameters have not been anonymized it will find them but the URI = will be useless. >>>=20 >>> URI will be useless but one can still determine how many times >>> request was retargeted, for example (Of course this is true only >>> if all the proxies are rfc4244bis compliant), which I think remains >>> useful. >>>=20 >>>>=20 >>>> 11. Section 9: >>>> "With the level of security provided by TLS (SEC-req-3), the >>>> information in the History-Info header can thus be evaluated to >>>> determine if information has been removed by evaluating the = indices >>>> for gaps (SEC-req-1, SEC-req-2). " >>>> This is subject to the limitation pointed out in a comment above, = about not all gaps being detectable. >>>>=20 >>>> 12. I would expect to see something in section 9 concerning = privacy. We should mention the privacy mechanism and discuss its limits = (i.e., depends on trust of downstream entities to anonymize = privacy-marked entries). Also there should probably be some discussion = on strength of anonymization algorithms (unless we are indeed = prescribing anonymous@anonymous.invalid). >>>=20 >>> Agree that text should be added. >>>=20 >>>>=20 >>>> 13. Section 10.2: >>>> "This document defines a priv-value for the SIP Privacy header: >>>> history The following changes have been made to >>>> http://www.iana.org/assignments/sip-priv-values The following has >>>> been added to the registration for the SIP Privacy header:" >>>> I am not sure how to parse this. >>>=20 >>>>=20 >>>>=20 >>>> 14. Section 12.1: >>>> "This specification adds an >>>> optional SIP header field parameter to the History-Info and = Contact >>>> headers. " >>>> In fact it adds two parameters to each. >>>=20 >>> Indeed. >>>=20 >>>>=20 >>>> 15. "Entities that have not implemented this specification MUST >>>> ignore these parameters, " >>>> We cannot place a normative requirement on entities that don't = implement this. Change "MUST" to "will". >>>=20 >>> Agree. >>>=20 >>>>=20 >>>> John >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=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 >>=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From marianne.mohali@orange-ftgroup.com Mon Nov 8 03:33:21 2010 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 AA10628C14E for ; Mon, 8 Nov 2010 03:33:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.649 X-Spam-Level: X-Spam-Status: No, score=-2.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_12=0.6, RCVD_IN_DNSWL_LOW=-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 AxhUkzc6hTI0 for ; Mon, 8 Nov 2010 03:33:18 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id C123228C157 for ; Mon, 8 Nov 2010 03:33:14 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 4C61476800E; Mon, 8 Nov 2010 11:42:48 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id AD6C0858137; Mon, 8 Nov 2010 11:37:25 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 11:32:50 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Nov 2010 11:32:47 +0100 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Comments on draft-mohali-sipcore-reason-call-forwarding-00 Thread-Index: Actu+FBLDrUpi9blRoCLCk/IVseS5AAENRc9AGQS29AAL9ZyigAXLDdA References: <201010181911.o9IJBexL017690@sj-core-1.cisco.com> , From: To: , X-OriginalArrivalTime: 08 Nov 2010 10:32:50.0091 (UTC) FILETIME=[4AD657B0:01CB7F30] Subject: Re: [sipcore] Comments on draft-mohali-sipcore-reason-call-forwarding-00 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 11:33:21 -0000 Hi Dale, My new response inline [MM2]=20 Marianne > -----Message d'origine----- > De : Worley, Dale R (Dale) [mailto:dworley@avaya.com]=20 > Envoy=E9 : jeudi 21 octobre 2010 21:47 > =C0 : MOHALI Marianne RD-CORE-ISS; sipcore@ietf.org > Objet : RE: [sipcore] Comments on=20 > draft-mohali-sipcore-reason-call-forwarding-00 >=20 > >> From: Dale Worley >=20 > > From: Marianne Mohali >=20 > > > Section 3 does not give any BNF for CDIV, though it quotes all of=20 > > > the established BNF for the Reason header. Clearly, what=20 > is intended=20 > > > (but not stated) is: > > > > > > protocol =3D/ "CDIV" > >=20 > > [MM] What is just after the established BNF is not good? I've used > > RFC4411 as a model. >=20 > It is good to describe the change in words, but it is better=20 > to describe the change in both words and in BNF -- some=20 > people find one method easier to understand than the other=20 > method. And since the two methods are vulnerable to=20 > different kinds of errors, using both makes it easier to=20 > discover errors in the definition. >=20 > As far as I can tell, RFC 4411 contains no BNF at all, so it=20 > is not a good model of how to update BNF. >=20 [MM2] You're right, in the next version I will make the new proposed = syntax clearer.=20 > > > In regard to listing the CDIV cause values, it seems to me that=20 > > > there should be an existing encoding of call diversion reasons=20 > > > somewhere within the 3GPP specification, and it would be more=20 > > > effective for the draft to reference that table (which would be=20 > > > maintained by 3GPP) rather than defining a new IANA=20 > registry (which=20 > > > would be used almost exclusively by 3GPP). > >=20 > > [MM] Right, but the existing CDIV cause values (described=20 > in 3GPP) are=20 > > a corruption of SIP response codes and brings confusion. It is the=20 > > initial reason of this draft. Your idea of mixing both=20 > sound good to=20 > > me: register a new protocol value "CDIV" but keep the=20 > reasons values=20 > > as in 3GPP. The problem I see is that reason values are=20 > described in=20 > > RFC4458 not for the Reason header but for an URI parameter and I'me=20 > > not sure it is possible to re-use it. An other way could be to=20 > > registering cause values but with the same values as today=20 > instead of=20 > > (1 to 8). Let's think about it... >=20 > The ideal situation would be if 3GPP had a clear taxonomy of=20 > diversion situations, and the CDIV cause values were an=20 > encoding of those categories. In particular, we expect CDIV=20 > to be generated by a 3GPP system, and so 3GPP would clearly=20 > specify the diversion situations which are described by the=20 > cause values. >=20 > It is not ideal if Sipcore defines these cause values,=20 > because our understanding of call diversion services probably=20 > differs from the understanding of 3GPP. [MM2] Before raising a debate on sipcore, I first launch a discussion = with 3GPP people to have their feedback and to see if they are also = interested in simplification of CDIV implementation. For the time being, = 3GPP specification is based on RFCs (4244 and 4458), that the reason why = I think a change should be done via IETF (and also because current = debates on the Reason header escaped in the H-I are very close to this = topic).=20 =20 >=20 > Dale >=20 From marianne.mohali@orange-ftgroup.com Mon Nov 8 03:33:23 2010 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 C863B28C15A for ; Mon, 8 Nov 2010 03:33:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-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 m+In4c4B4cYn for ; Mon, 8 Nov 2010 03:33:22 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id 0183228C14E for ; Mon, 8 Nov 2010 03:33:22 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 0E6458580A0; Mon, 8 Nov 2010 12:37:43 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 28EF37D80C3; Mon, 8 Nov 2010 12:17:54 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 12:13:12 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Mon, 8 Nov 2010 12:13:10 +0100 Message-ID: In-Reply-To: <4CD2F4BE.6080906@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-mohali-sipcore-reason-extension-application-00 Thread-Index: Act8Si6R1956EIPOTQGaDMmgtnj8iQArl5hw References: <4CD2F4BE.6080906@cisco.com> From: To: , X-OriginalArrivalTime: 08 Nov 2010 11:13:12.0749 (UTC) FILETIME=[EEDA9DD0:01CB7F35] Subject: Re: [sipcore] draft-mohali-sipcore-reason-extension-application-00 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 11:33:24 -0000 Hi Paul, My response inline [MM] Thanks, Marianne=20 > -----Message d'origine----- > De : sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] De la part de Paul Kyzivat > Envoy=E9 : jeudi 4 novembre 2010 19:01 > =C0 : SIPCORE > Objet : [sipcore] draft-mohali-sipcore-reason-extension-application-00 >=20 > [as individual] >=20 > I took another look at this draft, and have a few=20 > observations/comments: >=20 > Its claimed that in cases where retargeting is due to a 3xx=20 > response, then the reason is 3xx, while in the cases of=20 > interest in this draft the reason is one of the new=20 > application reason codes. >=20 > But these are not mutually exclusive cases. All of the "application"=20 > cases called out could be implemented by sending the request=20 > to an application server that then returns a 3xx response=20 > with the value. If so, anything downstream that wishes to=20 > identify the reason would presumably want the application=20 > reason, which would perhaps have been lost in this process. >=20 > ISTM that to resolve that, the redirect server would affix=20 > the reason header with the application code to the contact in=20 > the 3xx. Then, the proxy that recurses on the 3xx would place=20 > contact with the embedded reason header into the H-I, and=20 > would also place the reason header into the new outgoing request. [MM] RFC3326 (Reason header) states that it is possible the have several = Reason values since the protocol values are different and an = implementation is free to ignore Reason values that it does not = understand. That's why we propose a new protocol value not to interfere = with the real received SIP cause (if there is one). >=20 > A net effect of this is that the Reason header would be in=20 > the *new* URI in H-I, not in the *old* URI as is shown. To me=20 > that also makes more sense - its the reason this URI is present. [MM] But the reason why this last (new) URI is present is because the = "old" one decides it. ISTM the important is who is responsible, who = requests the retargeting.=20 >=20 > Bottom line - this should all make sense even without the use of H-I.=20 > Then H-I usage can also be folded into the examples to give=20 > an even more complete picture of what happened. >=20 > I also must say that I find the proposed cause text to be at=20 > best awkward. I'm not a grammarian, but ISTM that these terms=20 > are using the wrong part of speech - they don't sound like=20 > *causes*. And for that matter some of them don't sound like=20 > they are even related to retargeting. E.g. premium rate, vpn.=20 > I would expect that "The call was retargeted to number=20 > because " would make sense for each of these. [MM] I can reword the descriptive sentences. However, the signification = is different from the one you propose. It's rather "The call processing = has been influenced because of this processing". The reason should not only available escaped in the H-I but also in a = "normal" SIP message (eg. BYE, CANCEL). But you're welcome to propose some text :) By the way, I've noted few inconsistencies in the terms usage = ("protocol-cause", "reason-params"..) so I will reword some sentences = for the next version.=20 >=20 > Thanks, > Paul > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From victor.pascual.avila@gmail.com Mon Nov 8 03:51:00 2010 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 E085F28C0F2 for ; Mon, 8 Nov 2010 03:51:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] 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 Z3fTcKNzAVoT for ; Mon, 8 Nov 2010 03:50:58 -0800 (PST) Received: from mail-bw0-f44.google.com (mail-bw0-f44.google.com [209.85.214.44]) by core3.amsl.com (Postfix) with ESMTP id 72AAE3A69AE for ; Mon, 8 Nov 2010 03:50:58 -0800 (PST) Received: by bwz12 with SMTP id 12so5239082bwz.31 for ; Mon, 08 Nov 2010 03:51:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=6gNAknOcTPehltiy32ZDdg6wxPq+lOxw0EaLMlOKho8=; b=ZeGp2zIPBQs49Hj6BYnx3G1fw2XAlrVZlIe055wCpy9MmWi1l7duATIAsuCm4mPL1F 86cInVHJqVfEt58FlM5KiGW3ceukH1W4bLitbBSuovwoZSImDtl3O2IqkQoXIB9hMi+/ Lg70Kioo9QJhY1DYSmYSeSSeTZZJji+nTquv0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=iLApe1xY3+mb77dUJdJp3sQbO0wrry+YZvhY6+LhDLtDueEajqcgKMK9nKkGpIuLEu AIWc8SX2BNXYhyekAbbdqITrAA6pHH4Xq8s3OFGLXyhNJS3BRdfcPum9URdhBZEAcj1E X+xTse+oeWNgqFyqdZswnYD7zP47Thf894KMw= MIME-Version: 1.0 Received: by 10.204.77.136 with SMTP id g8mr4799017bkk.108.1289217078141; Mon, 08 Nov 2010 03:51:18 -0800 (PST) Received: by 10.204.81.76 with HTTP; Mon, 8 Nov 2010 03:51:18 -0800 (PST) In-Reply-To: References: <4C69ADA8.1010802@nostrum.com> <4C753AAA.3030407@nostrum.com> <4CD08E7A.1020503@cisco.com> Date: Mon, 8 Nov 2010 12:51:18 +0100 Message-ID: From: Victor Pascual Avila To: "DRAGE, Keith (Keith)" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: "sipcore@ietf.org" Subject: Re: [sipcore] H-I in 100 response (was REMINDER: Re: WGLC: draft-ietf-sipcore-rfc4244bis) 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 11:51:01 -0000 On Wed, Nov 3, 2010 at 11:41 AM, DRAGE, Keith (Keith) wrote: > Please do not put it in 100 responses, i.e. MUST NOT. +1 > Note that if it is put in 1xx responses that are not sent reliably, then = in my understanding you have no means of telling you have lost it along wit= h the response. So in this case it would have to be repeated in the final r= esponse. However there is probably a use case for being able to inform the = user of call diversion at alerting time, so I would certainly allow it, i.e= . MAY to generate it or add to it, MUST to pass one on if you receive it. Would 100rel make any sense here? Cheers, -Victor > > Keith > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Tuesday, November 02, 2010 10:20 PM >> To: sipcore@ietf.org >> Subject: Re: [sipcore] H-I in 100 response (was REMINDER: Re: >> WGLC: draft-ietf-sipcore-rfc4244bis) >> >> >> >> On 11/2/2010 4:31 PM, Elwell, John wrote: >> > So the remaining issue from this thread concerns whether to >> mandate History-Info in a all provisional responses or just >> non-100 provisional responses (subject to presence of the >> option tag in the request). Given that 100 tends to be >> generated differently from other provisional responses, and >> given the marginal use of H-I in 100 responses, I would >> prefer either to omit H-I from 100 responses or use MAY. I >> don't have a strong opinion, but perhaps others have a view. >> >> Requiring (even permitting) H-I in 100 responses is a *terrible* idea. >> >> I don't see why you would need H-I in *any* provisional >> responses (with the possible exception of 199.) >> >> (Disclaimer - I have not read all the discussion on this subject.) >> >> =C2=A0 =C2=A0 =C2=A0 Thanks, >> =C2=A0 =C2=A0 =C2=A0 Paul >> >> > John >> > >> > >> >> -----Original Message----- >> >> From: Mary Barnes [mailto:mary.ietf.barnes@gmail.com] >> >> Sent: 02 November 2010 19:51 >> >> To: Elwell, John >> >> Cc: sipcore@ietf.org >> >> Subject: Re: [sipcore] REMINDER: Re: WGLC: >> >> draft-ietf-sipcore-rfc4244bis >> >> >> >> John, >> >> >> >> I've done the same. A couple responses inline below [MB2]. >> >> >> >> Thanks, >> >> Mary. >> >> >> >> On Tue, Nov 2, 2010 at 4:06 AM, Elwell, John >> >> =C2=A0wrote: >> >>> Mary, >> >>> >> >>> I have responded below, stripping out the stuff where I >> >> have nothing further to add. >> >>> >> >> >> >>>>> 2. It nearly always uses the term "header" rather than >> >>>> "header field", although never, as far as I know, meaning the >> >>>> entire SIP header. >> >>>> [MB] I'm not sure that I fully understand the concern. Can >> >> you point >> >>>> out a specific sentence or section of concern? =C2=A0The term >> >> "header" is >> >>>> used when it is referring to the History-Info header >> >> field, but that >> >>>> is done in other documents as well. =C2=A0In general, I think it's >> >>>> understood that it's referring to the header field when it's >> >>>> qualified. Perhaps you're referring to places where it is not >> >>>> qualified? =C2=A0 The term hi-entry is used, as well. >> >>>> [/MB] >> >>> [JRE] I have explained in more detail in my comments on -02. >> >> [MB2] I've responded to that in my subsequent response to your >> >> comments. [/MB2] >> >>> >> >>> >> >> >> >>>>> >> >>>>> 18. Section 4.2.2: >> >>>>> "the UAS MUST >> >>>>> =C2=A0 =C2=A0include any History-Info received in the request =C2= =A0in the >> >>>> subsequent >> >>>>> =C2=A0 =C2=A0response" >> >>>>> Does this include 100 responses? >> >>>> [MB] I would think so. Can you think of a reason why it >> >> shouldn't? =C2=A0I>> =C2=A0would think it could be useful for debug. = [/MB] >> >>> [JRE] The 100 response typically only travels back a single >> >> hop, so the benefit of H-I in a 100 is marginal. Also some >> >> implementations might send back a 100 response quite early during >> >> processing, perhaps even before they decide whether to act as a >> >> proxy, a UAS or a redirect, so knowing how to populate H-I >> in a 100 >> >> might be difficult. >> >> [MB2] If it has no additional hi-entries, then there is nothing >> >> additional to send back, so I don't think it hurts >> anything - I would >> >> agree that in most cases it's of marginal value. We can >> include it as >> >> an exception in that sentence if you would prefer, >> although per the >> >> next comment, it seems that you are okay with leaving it as is. >> >> [/MB2] >> >>> >> >>> >> >>>>> >> >> >> >>>>> >> >>>>> 26. Section 5.2: >> >>>>> "A proxy that receives a request with the "histinfo" option >> >>>> tag in the >> >>>>> =C2=A0 =C2=A0Supported header, SHOULD forward captured History-Inf= o in >> >>>> subsequent, >> >>>>> =C2=A0 =C2=A0provisional , and final responses " >> >>>>> Does this include 100 responses? >> >>>> [MB] That's the implication of "provisional" per RFC 3261. [/MB] >> >>> [JRE] I am doubtful about the usefulness of 100. However, >> >> it is probably fairly academic, since 100 will probably have been >> >> sent earlier. A proxy is unlikely to send a 100 after receiving a >> >> provisional response from a downstream entity. >> >>> >> >>>>> >> >>>>> 27. Section 5.2: >> >>>>> "A proxy MAY anonymize any hi-entry whose domain >> corresponds to a >> >>>>> =C2=A0 =C2=A0domain for which it is responsible (as per [RFC3323 ]= )." >> >>>>> I don't think RFC 3323 tells me how to anonymize an hi-entry. >> >>>> [MB] =C2=A0RFC 3323 discusses anonymization and the role of an >> >> anonymizer, >> >>>> etc. So, I'm not clear on your concern. [/MB] >> >>> [JRE] I guess if we talked about anonymizing the URI in the >> >> hi-target-to-uri it would be clearer. >> >> [MB2] That's fine...I'll make it explicit that it's the >> >> hi-targeted-to-uri in the hi-entry that is anonymized. [/MB2] >> >>> >> >>> >> >>> >> >>> >> >>> John >> >> >> > _______________________________________________ >> > 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 > --=20 Victor Pascual =C3=81vila From HKaplan@acmepacket.com Mon Nov 8 07:01:22 2010 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 B45193A67B2 for ; Mon, 8 Nov 2010 07:01:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.882 X-Spam-Level: X-Spam-Status: No, score=-1.882 tagged_above=-999 required=5 tests=[AWL=0.117, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] 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 4Z56OaC6m7fn for ; Mon, 8 Nov 2010 07:01:21 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A436E3A677D for ; Mon, 8 Nov 2010 07:01:21 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 8 Nov 2010 10:01:42 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 8 Nov 2010 10:01:42 -0500 From: Hadriel Kaplan To: Shida Schubert Date: Mon, 8 Nov 2010 10:01:39 -0500 Thread-Topic: [sipcore] Yet more comments on rfc4244bis-02 Thread-Index: Act/VdmnDrQiUFxTTD+W7qJiXyOmdg== Message-ID: <55338E45-63A9-43F2-9983-85252365B73F@acmepacket.com> References: <4CD7CF13.5000005@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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Yet more comments on 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 15:01:22 -0000 On Nov 8, 2010, at 6:01 AM, Shida Schubert wrote: > Privacy:none is used when caller (UAC) wants his/her identity delivered > to the destination (callee) despite the existence of privacy service, but > with regards to H-I, when does it ever contain the URI that identifies th= e > caller (UAC) ? > I agree that privacy:none will be valid if we can find a situation where > URI of UA will be one of the hi-entry but my imagination is not strong > enough to see this. But that also begs the question of why we need a Privacy header of "history= " to begin with. (I mean a real Privacy header in the message, not an embed= ded one in a particular HI URI) The only case I could imagine for such things is that the caller doesn't wa= nt their domain known about. I.e., I make an anonymous call from my SIP ph= one through my corporate SIP proxy, and my SIP phone sets "Privacy: history= " so that Acme Packet's anonymization proxy removes "acmepacket.com" from a= ny H-Is, before sending it out our SIP trunk, etc. -hadriel From R.Jesske@telekom.de Mon Nov 8 07:19:31 2010 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 661453A677D for ; Mon, 8 Nov 2010 07:19:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.949 X-Spam-Level: X-Spam-Status: No, score=-2.949 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-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 E7AigNlZ5b6P for ; Mon, 8 Nov 2010 07:19:30 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 237383A681B for ; Mon, 8 Nov 2010 07:19:29 -0800 (PST) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail81.telekom.de with ESMTP; 08 Nov 2010 16:19:06 +0100 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Mon, 8 Nov 2010 16:18:59 +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, 8 Nov 2010 16:18:54 +0100 Message-ID: <9886E5FCA6D76549A3011068483A4BD406D5D1D4@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <55338E45-63A9-43F2-9983-85252365B73F@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Yet more comments on rfc4244bis-02 Thread-Index: Act/VdmnDrQiUFxTTD+W7qJiXyOmdgAAaeLg References: <4CD7CF13.5000005@cisco.com> <55338E45-63A9-43F2-9983-85252365B73F@acmepacket.com> From: To: , X-OriginalArrivalTime: 08 Nov 2010 15:18:59.0757 (UTC) FILETIME=[44C175D0:01CB7F58] Cc: sipcore@ietf.org Subject: Re: [sipcore] Yet more comments on 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 15:19:31 -0000 Hi Hadriel, is has also an other reason. When you send from the retargeting SIP = Server an call Forwarding (Retargeting) notification in backward = direction (181 Response) with an History Info, the target should be = marked as private, because the retargeting server has no knowledge about = the privacy instructions of the terminating user. Best Regards Roland -----Urspr=FCngliche Nachricht----- Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im = Auftrag von Hadriel Kaplan Gesendet: Montag, 8. November 2010 16:02 An: Shida Schubert Cc: sipcore@ietf.org Betreff: Re: [sipcore] Yet more comments on rfc4244bis-02 On Nov 8, 2010, at 6:01 AM, Shida Schubert wrote: > Privacy:none is used when caller (UAC) wants his/her identity = delivered > to the destination (callee) despite the existence of privacy service, = but > with regards to H-I, when does it ever contain the URI that identifies = the > caller (UAC) ? > I agree that privacy:none will be valid if we can find a situation = where > URI of UA will be one of the hi-entry but my imagination is not strong > enough to see this. But that also begs the question of why we need a Privacy header of = "history" to begin with. (I mean a real Privacy header in the message, = not an embedded one in a particular HI URI) The only case I could imagine for such things is that the caller doesn't = want their domain known about. I.e., I make an anonymous call from my = SIP phone through my corporate SIP proxy, and my SIP phone sets = "Privacy: history" so that Acme Packet's anonymization proxy removes = "acmepacket.com" from any H-Is, before sending it out our SIP trunk, = etc. -hadriel _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From Internet-Drafts@ietf.org Mon Nov 8 10:00:02 2010 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 C7FA13A6849; Mon, 8 Nov 2010 10:00:02 -0800 (PST) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BAD HEADER, MIME error: error: unexpected end of preamble X-Spam-Flag: NO X-Spam-Score: -99.234 X-Spam-Level: X-Spam-Status: No, score=-99.234 tagged_above=-999 required=5 tests=[AWL=-0.420, BAYES_00=-2.599, MISSING_MIME_HB_SEP=2.119, SARE_BOUNDARY_LC=1.666, 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 eZoy9Ed6Pn7p; Mon, 8 Nov 2010 10:00:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 168513A680F; Mon, 8 Nov 2010 10:00:02 -0800 (PST) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="nextpart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no Message-ID: <20101108180002.24228.56239.idtracker@localhost> Date: Mon, 08 Nov 2010 10:00:02 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-sec-flows-04.txt 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 18:00:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Example call flows using Session Initiation Protocol (SIP) security mechanisms Author(s) : C. Jennings, et al. Filename : draft-ietf-sipcore-sec-flows-04.txt Pages : 66 Date : 2010-11-08 This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-sec-flows-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-sec-flows-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-08095216.I-D@ietf.org> --NextPart-- From ian_elz@yahoo.co.uk Mon Nov 8 10:09:59 2010 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 2848B3A6935 for ; Mon, 8 Nov 2010 10:09:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_74=0.6] 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 gwj4Y8BzZXkk for ; Mon, 8 Nov 2010 10:09:57 -0800 (PST) Received: from nm17-vm0.bullet.mail.ird.yahoo.com (nm17-vm0.bullet.mail.ird.yahoo.com [77.238.189.214]) by core3.amsl.com (Postfix) with SMTP id EF01A3A6863 for ; Mon, 8 Nov 2010 10:09:56 -0800 (PST) Received: from [77.238.189.232] by nm17.bullet.mail.ird.yahoo.com with NNFMP; 08 Nov 2010 18:10:18 -0000 Received: from [212.82.108.120] by tm13.bullet.mail.ird.yahoo.com with NNFMP; 08 Nov 2010 18:10:17 -0000 Received: from [127.0.0.1] by omp1029.mail.ird.yahoo.com with NNFMP; 08 Nov 2010 18:10:17 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 956319.36067.bm@omp1029.mail.ird.yahoo.com Received: (qmail 30437 invoked by uid 60001); 8 Nov 2010 18:10:17 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1289239817; bh=7MtCe8JhtBnKS5Vtv8luJJsRR8vVMAsccRm6Zw59Ezw=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=nrf68q16inqlBXl3pzHy398jaNurTA4it947DzX9lJbZUd7zZjeNE/0ZW6ksPFUYyXzPrpIz6zczr7B4zhqB9BuB4/BVx7SnLHYFZxDv9NDBd+YVzs3ZIUU0QT4IcPJ4GgrAkXeYY58FbrC9i8D8OjLeNItb543sMCVzJMcNvls= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=WisA6d4dM+T7geqaKV27RZEjrFGjOuWa0yy3+o4ZdxR9ZH25+hXnsuzXwXAyVX0wIJePQkhD/nx4V/UXyk7X6bZ+3qO5Nsk2AFCRoFhS5rdVS5KVvGvSyJ19xelkiYVouwLiTkBQLUhMksPeri5l+evttuLmMjtw46KuEtzKXaE=; Message-ID: <865731.30413.qm@web29104.mail.ird.yahoo.com> X-YMail-OSG: N7F1GxcVM1muzOx88_KT3O7HURcCU7wmnf5plu2yWrNVtWl rdG9gf04YCN2P1ptXmu8qSSqL05W7npBIYtIuVmB1exi9OhA9YGhpkmx6Xd3 FgBeN8iqG2Irt1c.TVA_Y6sRapiOoj4jA7TFWcoyW9jWhbzXz9_WJps8CDfB O8kSv0430isEsDQ8hk6Z5UX40aSXQAlBACUZ1OhwLeYqXlT1v.159EofxZpP ifUzWRGqq2_jR6WEKEmjIyoZ281YeSTlcjHqdOjqxwZhF13Nj Received: from [86.20.66.247] by web29104.mail.ird.yahoo.com via HTTP; Mon, 08 Nov 2010 18:10:17 GMT X-Mailer: YahooMailWebService/0.8.107.284920 Date: Mon, 8 Nov 2010 18:10:17 +0000 (GMT) From: Ian Elz To: Mary Barnes MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: Mary Barnes , sipcore@ietf.org Subject: Re: [sipcore] Yet more comments on rfc4244bis-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Ian Elz List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 18:09:59 -0000 Mary,=0A=0AI am a bit late replying.=0A=0AThe reason for the Privacy of "no= ne" was probably due to my comments.=0A=0ARegarding "Privacy:history" being= used to anonomise all H-I URI then this probably looks OK as it makes ever= ything private.=0A=0AThe problem is that making the Privacy header take pre= cedence over the individual entries is when you have "Privacy:none" and som= e of the H-I entries have Privacy=3Dhistory. If you take the Privacy:histor= y case then the ":none" will override "=3Dhistory" which effectively means = that the originator of the request can specify the privacy of URIs belongin= g to someone who diverts or re-targets the request.=0A=0AThis is just not c= orrect.=0A=0AThe purpose of allowing "privacy=3Dnone" in the H-I entry was = to allow the future possibility of the overriding the Privacy header.=0A=0A= We need to remember that RFC3323 was written when cocepts of diversion etc = were not part of sip.=0A=0AIan Elz=0A=0A----- Original Message -----=0AFrom= : "Mary Barnes" =0ATo: "Shida Schubert" =0ACc: sipcore@ietf.org, "Mary Barnes" = =0ASent: Monday, 8 November, 2010 5:19:25 AM=0ASubject: Re: [sipcore] Yet m= ore comments on rfc4244bis-02=0A=0AA few additional comments inline below [= MB].=0A=0AMary.=0A=0AOn Sun, Nov 7, 2010 at 12:28 AM, Shida Schubert wrote:=0A>=0A> Hi John;=0A>=0A> =A0My responses on some of the= comments, I think=0A> Mary may be responding on the same issues but here a= re mine.=0A>=0A> On Nov 4, 2010, at 12:29 AM, Elwell, John wrote:=0A>=0A>> = 1. Section 7.3.1.=0A>> "If there is a Privacy header in the request with a = priv-=0A>> =A0 value of "header" or "history", then the initial hi-entry MU= ST be=0A>> =A0 anonymized and the header removed when the request leaves a = domain=0A>> =A0 for which the SIP entity is responsible."=0A>> I think it s= hould say "...and the Privacy header removed" - there is no point in removi= ng the H-I header field if we have anonymized it.=0A>=0A> =A0You are right.= The intention was to say "remove the priv-value and remove the privacy=0A>= header itself if there are no other priv-value left (id may exists which n= eeds=0A> to remain in the request until it reaches the egress point)".=0A>= =0A>>=0A>> 2. What is meant by anonymizing a hi-entry (in this paragraph an= d elsewhere)? Is it only the hi-targeted-to-uri that needs to be anonymized= , or also its parameters? The examples in annex B show just the URI anonymi= zed and with the value anonymous@anonymous.invalid. Is this how it MUST be = done?=0A=0A[MB] It is only the hi-targeted-to-uri that needs to be anonymiz= ed -=0Ait is a MUST. The other parameters MUST not be changed. [/MB]=0A>=0A= > =A0I personally don't have a strong opinion about prescribing the anonymo= us@anonymou.invalid but=0A> I think it would be useful to specify what the = anonymized URI should look like. This would avoid=0A> anonymous URI anonymi= zed numerous time by different privacy service for example...=0A> =A0As for= the parameter, if rc/mp tag, index and encoded reason(RFC 3326) are intact= ,=0A> anonymized hi-entry can still provide some value, so I think only hi-= targeted-to-uri should be=0A> anonymized.=0A>=0A>>=0A>> 3. In the same sent= ence, is it sufficient to anonymize only the first hi-entry? There could be= further hi-entries for the same domain, and just revealing internal routin= g within the domain might be considered a breach of privacy. Perhaps in tha= t case you would need to rely on those additional hi-entries being separate= ly marked for privacy. If that is so, it would seem to be OK.=0A>=0A> =A0Yo= ur last suggestion/assumption was exactly the motivation and our=0A> attemp= t to simplify privacy handling, by saying Privacy header with priv-value=0A= > of "history"/"header" (not in hi-entry) for anonymizing first hi-entry on= ly and to use=0A> privacy=3Dheader in hi-entry for any other hi-entries.=0A= >=0A> =A0It would mean;=0A>=0A> =A0 1. UA requests H-I privacy by using Pri= vacy:history or Privacy:header=0A> =A0 2. Proxy request H-I privacy by usin= g History-Info:?privacy=3Dhistory=0A>=0A> =A0Which we thought wo= uld clarify the timing of when Privacy:history / Privacy:header=0A> and pri= vacy=3Dhistory are used.=0A>=0A> =A0But thinking further, it doesn't really= simplify the overall=0A> privacy handling of H-I =A0and furthermore it cha= nges the semantics of=0A> header privacy in RFC3323.=0A>=0A> =A0Excerpt fro= m RFC3323 on header privacy says:=0A>=0A> =A0 "If a privacy level of 'heade= r' is requested, then the originating=0A> =A0 user has asked the privacy se= rvice to help to obscure headers that=0A> =A0 might otherwise reveal inform= ation about the originator of the=0A> =A0 request."=0A>=0A> =A0This can enc= ompass entries revealing internal routing and domain=0A> information as you= mentioned above, so restricting the use of Privacy:header=0A> to first ent= ry only can be seen as changing the semantics defined in RFC3323.=0A>=0A> = =A0I think we should align the handling of H-I privacy of Privacy:history= =0A> and Privacy:header to that of RFC3323, allowing privacy service to=0A>= anonymize not only the first hi-entry but any other entries that=0A> are f= rom its domain.=0A[MB] I don't have a strong opinion here. The suggestion = above makes=0Aalot of sense. [/MB]=0A>=0A> =A0I guess we need to further c= larify how these two means of requesting=0A> privacy interact, since you ca= n have both privacy:history and few hi-entries=0A> with privacy=3Dhistory. = I am assuming that when privacy service anonymizes=0A> history-info header = based on privacy:history or privacy:header, it also=0A> needs to remove the= privacy=3Dhistory from hi-entries that it's anonymizing.=0A[MB] Yes, we sh= ould clarify. With the approach discussed above, the=0Aprivacy:history wou= ld "override" the privacy for each entry (within=0Athat domain). And, yes,= per a previous thread, we do need to update=0Athe privacy text to indicate= the removal of the privacy for each=0Ahi-entry as it is anonymized. [/MB]= =0A=0A>=0A> =A0Lastly what about the interaction with privacy:none? Accordi= ng to=0A> section 5.1 of 4244bis, if UAC doesn't want privacy on its identi= ty it sets=0A> Privacy header with priv-value of "none", but I am having a = hard time=0A> envisioning the need for this. When do you ever get the hi-en= try representing=0A> your own AoR or contact address?=0A[MB] We originally= did not include privacy of "none" as relevant to=0AHistory-info (in 4244).= That was added in -bis and I to question the=0Avalue. I do not think it h= as any value as applied to History-Info and=0AI would suggest we remove it = or note that it has no impact in terms of=0Athe processing of privacy for t= he hi-entries. [/MB]=0A>=0A> =A0I think the hi-entry with privacy=3Dhistory= should still be anonymized, even when=0A> the Privacy:none is set in reque= st because the privacy is requested by proxy, I=0A> think we need to add te= xt on this as well.=0A[MB] Agreed. [/MB]=0A>=0A>=0A>>=0A>> 4. "In addition,= the History-Info header can reveal general routing and=0A>> =A0 diverting = information within an intermediary, "=0A>> Is it only routing information w= ithin an intermediary, or also routing information within a domain that you= might want to make private? I think text later in the paragraph concurs wi= th the latter view.=0A[MB] yes, it's the latter - within a domain for whic= h the=0Aintermediary is responsible. [/MB]=0A>>=0A>> 5. "Finally, the termi= nator of the request may not want to reveal the=0A>> =A0 final reached targ= et to the originator. =A0In this case, the terminator=0A>> =A0 uses the a v= alue of "history" in the Privacy header in the last hi-=0A>> =A0 entry in t= he response. =A0The SIP entity that forwards the response=0A>> =A0 MUST ano= nymize that hi-entry and remove the Privacy header."=0A>> Although a UAS ca= n mark the final hi-entry as private, and there is a requirement for a prox= y to anonymize this when the response leaves the domain, what about other h= i-entries that have been marked by proxies in the final domain as private? = These will get passed back in the response without anonymization since they= are not the final hi-entry and are not covered by this statement. Should t= he final sentence apply to any hi-entry?=0A[MB] Yes. that sentence should a= pply to all responses - i.e., in=0Ageneral if there are hi-entries with an = escaped privacy header, they=0Ashould be anonymized and the privacy header = removed. [/MB]=0A>=0A> =A0RFC3323 recommends that privacy service to be inc= luded in the=0A> request/response path if privacy is desired. The privacy h= andling=0A> in 4244bis is based on RFC3323 so I don't know if we need to ad= d=0A> anything specific here for anonymizing the response.=0A>=0A>>=0A>> 6.= Section 7.3.3:=0A>> "To=0A>> =A0 =A0 =A0 accomplish this, the processing e= ntity MUST read the value from=0A>> =A0 =A0 =A0 the History-Info header in = the received request and MUST add=0A>> =A0 =A0 =A0 another level of indexin= g "=0A>> Should make it clear it is the last hi-entry of the received reque= st (after adding entries on behalf of previous hops).=0A>=0A> =A0Agree.=0A>= =0A>>=0A>> 7. "followed=0A>> =A0 =A0 =A0 by an initial index for the new le= vel of 1"=0A>> I think this would be clearer if it said:=0A>> "followed by = an initial index of 1 for the new level"=0A>=0A> =A0Agree.=0A>=0A>>=0A>> 8.= "MUST be calculated by incrementing the last/lowest digit=0A>> =A0 =A0 =A0= at the current level"=0A>> and=0A>> "That is, the lowest/last digit of the= index MUST be=0A>> =A0 =A0 =A0 incremented "=0A>> What if an index is a do= uble-digit integer?=0A>=0A> =A0How about we remove the "lowest/last" and si= mply=0A> say incrementing the digit at the current level by 1 or=0A> someth= ing like that.=0A>=0A>>=0A>> 9. Section 8:=0A>> "an=0A>> =A0 application mi= ght need to provide special handling in some cases=0A>> =A0 where there are= gaps."=0A>> Should there be a note discussing the fact that some gaps are = not detectable, e.g., if I receive 1, 1.1 and 1.1.1, I cannot detect if 1.2= or 1.1.2, say, is missing.=0A>=0A> =A0This would happen, say for example i= f request was=0A> parallel forked, each branch would have the hi-entry=0A> = that only the forked request traversed but missing=0A> the information of t= he other forks. I don't know if I would=0A> consider what you describe as a= gap. You may be=0A> missing the other branches but you should be able to= =0A> identify the gap in index for the branch that request=0A> traversed. (= You may be missing the actual hop in the=0A> logical tree of History-Info t= hat does not support=0A> 4244/4244bis but as they won't add the hi-entry=0A= > there won't be a gap in index itself).=0A>=0A>>=0A>> 10. Should we say an= ything in section 8 about anonymized entries? Note that what we might say d= epends to some extent on whether what exactly gets anomymised. For example = if an application searches for an rc or mp entry, if those parameters have = been anonymized it will not find them (but might find others that have not = been anonymized!), but if those parameters have not been anonymized it will= find them but the URI will be useless.=0A>=0A> =A0URI will be useless but = one can still determine how many times=0A> request =A0was retargeted, for e= xample (Of course this is true only=0A> if all the proxies are rfc4244bis c= ompliant), which I think remains=0A> useful.=0A>=0A>>=0A>> 11. Section 9:= =0A>> "With the level of security provided by TLS (SEC-req-3), the=0A>> =A0= information in the History-Info header can thus be evaluated to=0A>> =A0 d= etermine if information has been removed by evaluating the indices=0A>> =A0= for gaps (SEC-req-1, SEC-req-2). =A0"=0A>> This is subject to the limitati= on pointed out in a comment above, about not all gaps being detectable.=0A>= >=0A>> 12. I would expect to see something in section 9 concerning privacy.= We should mention the privacy mechanism and discuss its limits (i.e., depe= nds on trust of downstream entities to anonymize privacy-marked entries). A= lso there should probably be some discussion on strength of anonymization a= lgorithms (unless we are indeed prescribing anonymous@anonymous.invalid).= =0A>=0A> =A0Agree that text should be added.=0A>=0A>>=0A>> 13. Section 10.2= :=0A>> "This document defines a priv-value for the SIP Privacy header:=0A>>= =A0 history The following changes have been made to=0A>> =A0 http://www.ia= na.org/assignments/sip-priv-values The following has=0A>> =A0 been added to= the registration for the SIP Privacy header:"=0A>> I am not sure how to pa= rse this.=0A>=0A>>=0A>>=0A>> 14. Section 12.1:=0A>> "This specification add= s an=0A>> =A0 optional SIP header field parameter to the History-Info and C= ontact=0A>> =A0 headers. =A0"=0A>> In fact it adds two parameters to each.= =0A>=0A> =A0Indeed.=0A>=0A>>=0A>> 15. "Entities that have not implemented t= his specification MUST=0A>> =A0 ignore these parameters, "=0A>> We cannot p= lace a normative requirement on entities that don't implement this. Change = "MUST" to "will".=0A>=0A> =A0Agree.=0A>=0A>>=0A>> John=0A>>=0A>>=0A>>=0A>>= =0A>>=0A>>=0A>>=0A>>=0A>>=0A>> ____________________________________________= ___=0A>> sipcore mailing list=0A>> sipcore@ietf.org=0A>> https://www.ietf.o= rg/mailman/listinfo/sipcore=0A>=0A> _______________________________________= ________=0A> sipcore mailing list=0A> sipcore@ietf.org=0A> https://www.ietf= .org/mailman/listinfo/sipcore=0A>=0A=0A=0A=0A=0A From ian_elz@yahoo.co.uk Mon Nov 8 10:16:50 2010 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 8CAFB3A6874 for ; Mon, 8 Nov 2010 10:16:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.699 X-Spam-Level: X-Spam-Status: No, score=-1.699 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] 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 iKiU+nvMmM9y for ; Mon, 8 Nov 2010 10:16:49 -0800 (PST) Received: from nm4.bullet.mail.ird.yahoo.com (nm4.bullet.mail.ird.yahoo.com [77.238.189.61]) by core3.amsl.com (Postfix) with SMTP id 3ECB83A6867 for ; Mon, 8 Nov 2010 10:16:49 -0800 (PST) Received: from [77.238.189.232] by nm4.bullet.mail.ird.yahoo.com with NNFMP; 08 Nov 2010 18:17:07 -0000 Received: from [212.82.108.238] by tm13.bullet.mail.ird.yahoo.com with NNFMP; 08 Nov 2010 18:17:07 -0000 Received: from [127.0.0.1] by omp1003.mail.ird.yahoo.com with NNFMP; 08 Nov 2010 18:17:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 830361.63790.bm@omp1003.mail.ird.yahoo.com Received: (qmail 88976 invoked by uid 60001); 8 Nov 2010 18:17:07 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1289240227; bh=7aWhiwDxnd+Fjsj80yvdihsg3QBZJBRHum21r5mxr8U=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LhHvXe03Jv4PwBvp3f2j679dP3drTaNjKKZg2oaR7AOSsZMqiWajcFudb5OFkWmirOZj7n1lANMV9YLfv/RER7ubH7VjZj7V0VJms43XfDGJlr+YDghpHyZf0+V3s2EJ3qenJwHkMrAVy97NG9yC/cFOvbF6P1jWEYvoXinFWr4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=xiD8oJRJyVrDtATXFJ694oW2ieDtbjTp/588Gkch4nRKWLVFlIKLkkt9Bm7QHEZYoXk9aA39D3XPtFJNMG8Um2bhav/ljZukdLM9rCUgW/ivfV5fK4DsWFmKyl1Uxr404nanetCZDXDaouKpmgAbT+WKwc7J1EXjqOdZzDsE+kw=; Message-ID: <708708.88960.qm@web29117.mail.ird.yahoo.com> X-YMail-OSG: bMjOIGMVM1naVYz554ey0FP_yNtqc3EptuJFGf7SjfJUar8 5CZAU.9VYb7tRWRMjfC.cUTCvuSAchkaTLRi4ASVd10Zmhnx03zBVfBuBAfb eMGRdn9HgvJMhenCwnTxDtF7cZDLUKh3zMA0e7AbaKdV4NMYdFh3CEITogQ4 FRm94q5fHTK0UEyXMMS4jBmbZa_nJlhqqhkYhPhMtUarI2DCNqfIY8fXP46P 8CLn1M1QqGJdkgj6P6Hn9q3K6XiP0hEZvNIj4F7yyJGHEuS0AlrJMdYJ_f0Z 16A-- Received: from [86.20.66.247] by web29117.mail.ird.yahoo.com via HTTP; Mon, 08 Nov 2010 18:17:07 GMT X-Mailer: YahooMailWebService/0.8.107.284920 Date: Mon, 8 Nov 2010 18:17:07 +0000 (GMT) From: Ian Elz To: Hadriel Kaplan MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: sipcore@ietf.org Subject: Re: [sipcore] Yet more comments on rfc4244bis-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Ian Elz List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Nov 2010 18:16:50 -0000 Hadriel,=0A=0ARoland missed one other case in his reply.=0A=0AIf I divert a= call I may want my identity to be private even if the original caller allo= ws his identity to be presented; i.e. I don't want the final destination of= the call to know the identity of the diverting party.=0A=0AIan Elz=0A=0A--= --- Original Message -----=0AFrom: "Hadriel Kaplan" =0ATo: "Shida Schubert" =0ACc: sipcore@ietf.org=0ASent: = Monday, 8 November, 2010 3:01:39 PM=0ASubject: Re: [sipcore] Yet more comme= nts on rfc4244bis-02=0A=0A=0A=0AOn Nov 8, 2010, at 6:01 AM, Shida Schubert = wrote:=0A=0A> Privacy:none is used when caller (UAC) wants his/her identity= delivered=0A> to the destination (callee) despite the existence of privacy= service, but=0A> with regards to H-I, when does it ever contain the URI th= at identifies the=0A> caller (UAC) ?=0A> I agree that privacy:none will be = valid if we can find a situation where=0A> URI of UA will be one of the hi-= entry but my imagination is not strong=0A> enough to see this.=0A=0ABut tha= t also begs the question of why we need a Privacy header of "history" to be= gin with. (I mean a real Privacy header in the message, not an embedded one= in a particular HI URI)=0A=0AThe only case I could imagine for such things= is that the caller doesn't want their domain known about. I.e., I make an= anonymous call from my SIP phone through my corporate SIP proxy, and my SI= P phone sets "Privacy: history" so that Acme Packet's anonymization proxy r= emoves "acmepacket.com" from any H-Is, before sending it out our SIP trunk,= etc.=0A=0A-hadriel=0A=0A=0A=0A=0A=0A From HKaplan@acmepacket.com Mon Nov 8 14:04:18 2010 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 F420D3A697A for ; Mon, 8 Nov 2010 14:04:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.888 X-Spam-Level: X-Spam-Status: No, score=-1.888 tagged_above=-999 required=5 tests=[AWL=0.111, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] 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 nDSW-hse01VW for ; Mon, 8 Nov 2010 14:04:16 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 9B5F23A68AE for ; Mon, 8 Nov 2010 14:04:16 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Mon, 8 Nov 2010 17:04:36 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 8 Nov 2010 17:04:36 -0500 From: Hadriel Kaplan To: Ian Elz Date: Mon, 8 Nov 2010 17:04:27 -0500 Thread-Topic: [sipcore] Yet more comments on rfc4244bis-02 Thread-Index: Act/kOmm1nFmNrXeR0WDScjRtm0S8g== Message-ID: <3F081C03-63B9-4C3C-9BAE-7601ACD6FEC9@acmepacket.com> References: <708708.88960.qm@web29117.mail.ird.yahoo.com> In-Reply-To: <708708.88960.qm@web29117.mail.ird.yahoo.com> 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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Yet more comments on 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 22:04:18 -0000 Right but isn't that done with the _embedded_ Privacy header in the H-I URI= ? I was talking about the Privacy header of the request message itself - t= hat's what I meant by "(I mean a real Privacy header in the message, not an= embedded one in a particular HI URI)". Sorry for the confusion. -hadriel On Nov 8, 2010, at 1:17 PM, Ian Elz wrote: > Hadriel, >=20 > Roland missed one other case in his reply. >=20 > If I divert a call I may want my identity to be private even if the origi= nal caller allows his identity to be presented; i.e. I don't want the final= destination of the call to know the identity of the diverting party. >=20 > Ian Elz >=20 > ----- Original Message ----- > From: "Hadriel Kaplan" > To: "Shida Schubert" > Cc: sipcore@ietf.org > Sent: Monday, 8 November, 2010 3:01:39 PM > Subject: Re: [sipcore] Yet more comments on rfc4244bis-02 >=20 >=20 >=20 > On Nov 8, 2010, at 6:01 AM, Shida Schubert wrote: >=20 >> Privacy:none is used when caller (UAC) wants his/her identity delivered >> to the destination (callee) despite the existence of privacy service, bu= t >> with regards to H-I, when does it ever contain the URI that identifies t= he >> caller (UAC) ? >> I agree that privacy:none will be valid if we can find a situation where >> URI of UA will be one of the hi-entry but my imagination is not strong >> enough to see this. >=20 > But that also begs the question of why we need a Privacy header of "histo= ry" to begin with. (I mean a real Privacy header in the message, not an emb= edded one in a particular HI URI) >=20 > The only case I could imagine for such things is that the caller doesn't = want their domain known about. I.e., I make an anonymous call from my SIP = phone through my corporate SIP proxy, and my SIP phone sets "Privacy: histo= ry" so that Acme Packet's anonymization proxy removes "acmepacket.com" from= any H-Is, before sending it out our SIP trunk, etc. >=20 > -hadriel >=20 >=20 >=20 >=20 >=20 >=20 From HKaplan@acmepacket.com Mon Nov 8 14:04:18 2010 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 3F5903A68AE for ; Mon, 8 Nov 2010 14:04:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.841 X-Spam-Level: X-Spam-Status: No, score=-0.841 tagged_above=-999 required=5 tests=[AWL=-0.946, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_74=0.6, 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 desAQubigr+n for ; Mon, 8 Nov 2010 14:04:17 -0800 (PST) Received: from ETMail2.acmepacket.com (unknown [216.41.24.9]) by core3.amsl.com (Postfix) with ESMTP id 4DF1F3A68D5 for ; Mon, 8 Nov 2010 14:04:17 -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 17:04:39 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 8 Nov 2010 17:04:38 -0500 From: Hadriel Kaplan To: " " Date: Mon, 8 Nov 2010 17:04:34 -0500 Thread-Topic: AW: [sipcore] Yet more comments on rfc4244bis-02 Thread-Index: Act/kO6EzKExWkAuSLeRG1PhsUYvkA== Message-ID: References: <4CD7CF13.5000005@cisco.com> <55338E45-63A9-43F2-9983-85252365B73F@acmepacket.com> <9886E5FCA6D76549A3011068483A4BD406D5D1D4@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD406D5D1D4@S4DE8PSAAQB.mitte.t-com.de> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAQAAAUA= Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Yet more comments on 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 22:04:18 -0000 Right but isn't that done with the _embedded_ Privacy header in the H-I URI= ? I was talking about the Privacy header of the request message itself - t= hat's what I meant by "(I mean a real Privacy header in the message, not an= embedded one in a particular HI URI)". Sorry for the confusion. -hadriel On Nov 8, 2010, at 10:18 AM, wr= ote: > Hi Hadriel, > is has also an other reason. When you send from the retargeting SIP Serve= r an call Forwarding (Retargeting) notification in backward direction (181 = Response) with an History Info, the target should be marked as private, bec= ause the retargeting server has no knowledge about the privacy instructions= of the terminating user. >=20 > Best Regards >=20 > Roland >=20 > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftra= g von Hadriel Kaplan > Gesendet: Montag, 8. November 2010 16:02 > An: Shida Schubert > Cc: sipcore@ietf.org > Betreff: Re: [sipcore] Yet more comments on rfc4244bis-02 >=20 >=20 >=20 > On Nov 8, 2010, at 6:01 AM, Shida Schubert wrote: >=20 >> Privacy:none is used when caller (UAC) wants his/her identity delivered >> to the destination (callee) despite the existence of privacy service, bu= t >> with regards to H-I, when does it ever contain the URI that identifies t= he >> caller (UAC) ? >> I agree that privacy:none will be valid if we can find a situation where >> URI of UA will be one of the hi-entry but my imagination is not strong >> enough to see this. >=20 > But that also begs the question of why we need a Privacy header of "histo= ry" to begin with. (I mean a real Privacy header in the message, not an emb= edded one in a particular HI URI) >=20 > The only case I could imagine for such things is that the caller doesn't = want their domain known about. I.e., I make an anonymous call from my SIP = phone through my corporate SIP proxy, and my SIP phone sets "Privacy: histo= ry" so that Acme Packet's anonymization proxy removes "acmepacket.com" from= any H-Is, before sending it out our SIP trunk, etc. >=20 > -hadriel >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Mon Nov 8 16:08:46 2010 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 10C5628C0E7 for ; Mon, 8 Nov 2010 16:08:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.928 X-Spam-Level: X-Spam-Status: No, score=-109.928 tagged_above=-999 required=5 tests=[AWL=-0.529, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8, 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 Wi+GGPesh+W8 for ; Mon, 8 Nov 2010 16:08:44 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 82BA43A6927 for ; Mon, 8 Nov 2010 16:08:40 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACYg2ExAaMHG/2dsb2JhbACiHXGhOptygnEBglYEhFiFfYMKgm2FVw X-IronPort-AV: E=Sophos;i="4.59,172,1288569600"; d="scan'208";a="616738574" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-6.cisco.com with ESMTP; 09 Nov 2010 00:08:55 +0000 Received: from [10.75.234.6] (hkidc-vpn-client-234-6.cisco.com [10.75.234.6]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA908mNX014858 for ; Tue, 9 Nov 2010 00:08:50 GMT Message-ID: <4CD8910E.5080706@cisco.com> Date: Mon, 08 Nov 2010 19:08:46 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: sipcore@ietf.org References: <865731.30413.qm@web29104.mail.ird.yahoo.com> In-Reply-To: <865731.30413.qm@web29104.mail.ird.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Yet more comments on 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: Tue, 09 Nov 2010 00:08:46 -0000 On 11/8/2010 1:10 PM, Ian Elz wrote: > Mary, > > I am a bit late replying. > > The reason for the Privacy of "none" was probably due to my comments. > > Regarding "Privacy:history" being used to anonomise all H-I URI then this probably looks OK as it makes everything private. > > The problem is that making the Privacy header take precedence over the individual entries is when you have "Privacy:none" and some of the H-I entries have Privacy=history. If you take the Privacy:history case then the ":none" will override "=history" which effectively means that the originator of the request can specify the privacy of URIs belonging to someone who diverts or re-targets the request. > > This is just not correct. Why do you say this is not correct? ISTM the purpose of Privacy:none is precisely to demand that nothing be removed or anonymized. For instance, IIUC this would apply to Route headers, which present some of the same issues as H-I headers. Elements along the way that don't like this can either: - fail the call - omit information in the first place if they want it kept private Thanks, Paul > The purpose of allowing "privacy=none" in the H-I entry was to allow the future possibility of the overriding the Privacy header. > > We need to remember that RFC3323 was written when cocepts of diversion etc were not part of sip. > > Ian Elz > > ----- Original Message ----- > From: "Mary Barnes" > To: "Shida Schubert" > Cc: sipcore@ietf.org, "Mary Barnes" > Sent: Monday, 8 November, 2010 5:19:25 AM > Subject: Re: [sipcore] Yet more comments on rfc4244bis-02 > > A few additional comments inline below [MB]. > > Mary. > > On Sun, Nov 7, 2010 at 12:28 AM, Shida Schubert wrote: >> >> Hi John; >> >> My responses on some of the comments, I think >> Mary may be responding on the same issues but here are mine. >> >> On Nov 4, 2010, at 12:29 AM, Elwell, John wrote: >> >>> 1. Section 7.3.1. >>> "If there is a Privacy header in the request with a priv- >>> value of "header" or "history", then the initial hi-entry MUST be >>> anonymized and the header removed when the request leaves a domain >>> for which the SIP entity is responsible." >>> I think it should say "...and the Privacy header removed" - there is no point in removing the H-I header field if we have anonymized it. >> >> You are right. The intention was to say "remove the priv-value and remove the privacy >> header itself if there are no other priv-value left (id may exists which needs >> to remain in the request until it reaches the egress point)". >> >>> >>> 2. What is meant by anonymizing a hi-entry (in this paragraph and elsewhere)? Is it only the hi-targeted-to-uri that needs to be anonymized, or also its parameters? The examples in annex B show just the URI anonymized and with the value anonymous@anonymous.invalid. Is this how it MUST be done? > > [MB] It is only the hi-targeted-to-uri that needs to be anonymized - > it is a MUST. The other parameters MUST not be changed. [/MB] >> >> I personally don't have a strong opinion about prescribing the anonymous@anonymou.invalid but >> I think it would be useful to specify what the anonymized URI should look like. This would avoid >> anonymous URI anonymized numerous time by different privacy service for example... >> As for the parameter, if rc/mp tag, index and encoded reason(RFC 3326) are intact, >> anonymized hi-entry can still provide some value, so I think only hi-targeted-to-uri should be >> anonymized. >> >>> >>> 3. In the same sentence, is it sufficient to anonymize only the first hi-entry? There could be further hi-entries for the same domain, and just revealing internal routing within the domain might be considered a breach of privacy. Perhaps in that case you would need to rely on those additional hi-entries being separately marked for privacy. If that is so, it would seem to be OK. >> >> Your last suggestion/assumption was exactly the motivation and our >> attempt to simplify privacy handling, by saying Privacy header with priv-value >> of "history"/"header" (not in hi-entry) for anonymizing first hi-entry only and to use >> privacy=header in hi-entry for any other hi-entries. >> >> It would mean; >> >> 1. UA requests H-I privacy by using Privacy:history or Privacy:header >> 2. Proxy request H-I privacy by using History-Info:?privacy=history >> >> Which we thought would clarify the timing of when Privacy:history / Privacy:header >> and privacy=history are used. >> >> But thinking further, it doesn't really simplify the overall >> privacy handling of H-I and furthermore it changes the semantics of >> header privacy in RFC3323. >> >> Excerpt from RFC3323 on header privacy says: >> >> "If a privacy level of 'header' is requested, then the originating >> user has asked the privacy service to help to obscure headers that >> might otherwise reveal information about the originator of the >> request." >> >> This can encompass entries revealing internal routing and domain >> information as you mentioned above, so restricting the use of Privacy:header >> to first entry only can be seen as changing the semantics defined in RFC3323. >> >> I think we should align the handling of H-I privacy of Privacy:history >> and Privacy:header to that of RFC3323, allowing privacy service to >> anonymize not only the first hi-entry but any other entries that >> are from its domain. > [MB] I don't have a strong opinion here. The suggestion above makes > alot of sense. [/MB] >> >> I guess we need to further clarify how these two means of requesting >> privacy interact, since you can have both privacy:history and few hi-entries >> with privacy=history. I am assuming that when privacy service anonymizes >> history-info header based on privacy:history or privacy:header, it also >> needs to remove the privacy=history from hi-entries that it's anonymizing. > [MB] Yes, we should clarify. With the approach discussed above, the > privacy:history would "override" the privacy for each entry (within > that domain). And, yes, per a previous thread, we do need to update > the privacy text to indicate the removal of the privacy for each > hi-entry as it is anonymized. [/MB] > >> >> Lastly what about the interaction with privacy:none? According to >> section 5.1 of 4244bis, if UAC doesn't want privacy on its identity it sets >> Privacy header with priv-value of "none", but I am having a hard time >> envisioning the need for this. When do you ever get the hi-entry representing >> your own AoR or contact address? > [MB] We originally did not include privacy of "none" as relevant to > History-info (in 4244). That was added in -bis and I to question the > value. I do not think it has any value as applied to History-Info and > I would suggest we remove it or note that it has no impact in terms of > the processing of privacy for the hi-entries. [/MB] >> >> I think the hi-entry with privacy=history should still be anonymized, even when >> the Privacy:none is set in request because the privacy is requested by proxy, I >> think we need to add text on this as well. > [MB] Agreed. [/MB] >> >> >>> >>> 4. "In addition, the History-Info header can reveal general routing and >>> diverting information within an intermediary, " >>> Is it only routing information within an intermediary, or also routing information within a domain that you might want to make private? I think text later in the paragraph concurs with the latter view. > [MB] yes, it's the latter - within a domain for which the > intermediary is responsible. [/MB] >>> >>> 5. "Finally, the terminator of the request may not want to reveal the >>> final reached target to the originator. In this case, the terminator >>> uses the a value of "history" in the Privacy header in the last hi- >>> entry in the response. The SIP entity that forwards the response >>> MUST anonymize that hi-entry and remove the Privacy header." >>> Although a UAS can mark the final hi-entry as private, and there is a requirement for a proxy to anonymize this when the response leaves the domain, what about other hi-entries that have been marked by proxies in the final domain as private? These will get passed back in the response without anonymization since they are not the final hi-entry and are not covered by this statement. Should the final sentence apply to any hi-entry? > [MB] Yes. that sentence should apply to all responses - i.e., in > general if there are hi-entries with an escaped privacy header, they > should be anonymized and the privacy header removed. [/MB] >> >> RFC3323 recommends that privacy service to be included in the >> request/response path if privacy is desired. The privacy handling >> in 4244bis is based on RFC3323 so I don't know if we need to add >> anything specific here for anonymizing the response. >> >>> >>> 6. Section 7.3.3: >>> "To >>> accomplish this, the processing entity MUST read the value from >>> the History-Info header in the received request and MUST add >>> another level of indexing " >>> Should make it clear it is the last hi-entry of the received request (after adding entries on behalf of previous hops). >> >> Agree. >> >>> >>> 7. "followed >>> by an initial index for the new level of 1" >>> I think this would be clearer if it said: >>> "followed by an initial index of 1 for the new level" >> >> Agree. >> >>> >>> 8. "MUST be calculated by incrementing the last/lowest digit >>> at the current level" >>> and >>> "That is, the lowest/last digit of the index MUST be >>> incremented " >>> What if an index is a double-digit integer? >> >> How about we remove the "lowest/last" and simply >> say incrementing the digit at the current level by 1 or >> something like that. >> >>> >>> 9. Section 8: >>> "an >>> application might need to provide special handling in some cases >>> where there are gaps." >>> Should there be a note discussing the fact that some gaps are not detectable, e.g., if I receive 1, 1.1 and 1.1.1, I cannot detect if 1.2 or 1.1.2, say, is missing. >> >> This would happen, say for example if request was >> parallel forked, each branch would have the hi-entry >> that only the forked request traversed but missing >> the information of the other forks. I don't know if I would >> consider what you describe as a gap. You may be >> missing the other branches but you should be able to >> identify the gap in index for the branch that request >> traversed. (You may be missing the actual hop in the >> logical tree of History-Info that does not support >> 4244/4244bis but as they won't add the hi-entry >> there won't be a gap in index itself). >> >>> >>> 10. Should we say anything in section 8 about anonymized entries? Note that what we might say depends to some extent on whether what exactly gets anomymised. For example if an application searches for an rc or mp entry, if those parameters have been anonymized it will not find them (but might find others that have not been anonymized!), but if those parameters have not been anonymized it will find them but the URI will be useless. >> >> URI will be useless but one can still determine how many times >> request was retargeted, for example (Of course this is true only >> if all the proxies are rfc4244bis compliant), which I think remains >> useful. >> >>> >>> 11. Section 9: >>> "With the level of security provided by TLS (SEC-req-3), the >>> information in the History-Info header can thus be evaluated to >>> determine if information has been removed by evaluating the indices >>> for gaps (SEC-req-1, SEC-req-2). " >>> This is subject to the limitation pointed out in a comment above, about not all gaps being detectable. >>> >>> 12. I would expect to see something in section 9 concerning privacy. We should mention the privacy mechanism and discuss its limits (i.e., depends on trust of downstream entities to anonymize privacy-marked entries). Also there should probably be some discussion on strength of anonymization algorithms (unless we are indeed prescribing anonymous@anonymous.invalid). >> >> Agree that text should be added. >> >>> >>> 13. Section 10.2: >>> "This document defines a priv-value for the SIP Privacy header: >>> history The following changes have been made to >>> http://www.iana.org/assignments/sip-priv-values The following has >>> been added to the registration for the SIP Privacy header:" >>> I am not sure how to parse this. >> >>> >>> >>> 14. Section 12.1: >>> "This specification adds an >>> optional SIP header field parameter to the History-Info and Contact >>> headers. " >>> In fact it adds two parameters to each. >> >> Indeed. >> >>> >>> 15. "Entities that have not implemented this specification MUST >>> ignore these parameters, " >>> We cannot place a normative requirement on entities that don't implement this. Change "MUST" to "will". >> >> Agree. >> >>> >>> John >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 > From pkyzivat@cisco.com Mon Nov 8 16:10:35 2010 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 10F8D28C0E7 for ; Mon, 8 Nov 2010 16:10:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.199 X-Spam-Level: X-Spam-Status: No, score=-110.199 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8, 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 pst4INuiw8Vi for ; Mon, 8 Nov 2010 16:10:32 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 2B1CA3A6860 for ; Mon, 8 Nov 2010 16:10:32 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjYFAK8f2ExAaMHG/2dsb2JhbACUHI4BcaE0m3KCcoJWBIRYhX2DCg X-IronPort-AV: E=Sophos;i="4.59,172,1288569600"; d="scan'208";a="378876011" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-1.cisco.com with ESMTP; 09 Nov 2010 00:10:54 +0000 Received: from [10.75.234.6] (hkidc-vpn-client-234-6.cisco.com [10.75.234.6]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA90Al0P015824 for ; Tue, 9 Nov 2010 00:10:49 GMT Message-ID: <4CD89186.9050604@cisco.com> Date: Mon, 08 Nov 2010 19:10:46 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.11) Gecko/20101013 Thunderbird/3.1.5 MIME-Version: 1.0 To: sipcore@ietf.org References: <708708.88960.qm@web29117.mail.ird.yahoo.com> In-Reply-To: <708708.88960.qm@web29117.mail.ird.yahoo.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Yet more comments on 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: Tue, 09 Nov 2010 00:10:35 -0000 On 11/8/2010 1:17 PM, Ian Elz wrote: > Hadriel, > > Roland missed one other case in his reply. > > If I divert a call I may want my identity to be private even if the original caller allows his identity to be presented; i.e. I don't want the final destination of the call to know the identity of the diverting party. Won't your identity still be present in the To URI? Thanks, Paul > Ian Elz > > ----- Original Message ----- > From: "Hadriel Kaplan" > To: "Shida Schubert" > Cc: sipcore@ietf.org > Sent: Monday, 8 November, 2010 3:01:39 PM > Subject: Re: [sipcore] Yet more comments on rfc4244bis-02 > > > > On Nov 8, 2010, at 6:01 AM, Shida Schubert wrote: > >> Privacy:none is used when caller (UAC) wants his/her identity delivered >> to the destination (callee) despite the existence of privacy service, but >> with regards to H-I, when does it ever contain the URI that identifies the >> caller (UAC) ? >> I agree that privacy:none will be valid if we can find a situation where >> URI of UA will be one of the hi-entry but my imagination is not strong >> enough to see this. > > But that also begs the question of why we need a Privacy header of "history" to begin with. (I mean a real Privacy header in the message, not an embedded one in a particular HI URI) > > The only case I could imagine for such things is that the caller doesn't want their domain known about. I.e., I make an anonymous call from my SIP phone through my corporate SIP proxy, and my SIP phone sets "Privacy: history" so that Acme Packet's anonymization proxy removes "acmepacket.com" from any H-Is, before sending it out our SIP trunk, etc. > > -hadriel > > > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From marianne.mohali@orange-ftgroup.com Mon Nov 8 16:42:33 2010 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 CBE073A690E for ; Mon, 8 Nov 2010 16:42:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.949 X-Spam-Level: X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_FR=0.35, MANGLED_EXTNSN=2.3, RCVD_IN_DNSWL_LOW=-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 WKEeRqguMxlZ for ; Mon, 8 Nov 2010 16:42:32 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id C01883A687C for ; Mon, 8 Nov 2010 16:42:31 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 9B41F778001; Tue, 9 Nov 2010 01:47:08 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 8A631760001; Tue, 9 Nov 2010 01:47:08 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Nov 2010 01:42:53 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Nov 2010 01:42:46 +0100 Message-ID: In-Reply-To: <9886E5FCA6D76549A3011068483A4BD406D5CF8B@S4DE8PSAAQB.mitte.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Reason as a parameter rather than anescapedheader (was Comments on draft-ietf-sipcore-rfc4244bis-02) Thread-Index: Act/Dp+TWptJkoHxTKmW70ParzWVEwACbydAAAfV2GA= References: <4CD6C020.7030603@cisco.com><4CD7555F.30609@cisco.com> <9886E5FCA6D76549A3011068483A4BD406D5CF8B@S4DE8PSAAQB.mitte.t-com.de> From: To: , , X-OriginalArrivalTime: 09 Nov 2010 00:42:53.0355 (UTC) FILETIME=[0B26CFB0:01CB7FA7] Cc: sipcore@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 00:42:33 -0000 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=3Dxxx" 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. =20 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 =3D the Retargeting). In general, we need = to know which entity do what.=20 Whatever the one chosen, it has to be clearly mentionned, not only with = "associated to the hi-retargeted-to-uri" not saying which one.=20 =20 Marianne > -----Message d'origine----- > De : sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] De la part de R.Jesske@telekom.de > Envoy=E9 : lundi 8 novembre 2010 15:53 > =C0 : HKaplan@acmepacket.com; shida@ntt-at.com > Cc : sipcore@ietf.org > Objet : Re: [sipcore] Reason as a parameter rather than=20 > anescapedheader (was Comments on draft-ietf-sipcore-rfc4244bis-02) >=20 > Hi, > we have already a mechanism putting a "cause" into the URI=20 > which is the target. > RFC4458 describes this for diverting reasons.=20 > So it is a own header used for History Info no new definition=20 > is needed. > And so this mechanism could be extended by the proposed=20 > values in=20 > http://tools.ietf.org/html/draft-mohali-sipcore-reason-extensi > on-application-00 and other needed.=20 >=20 > So in final the Reason is included within the "retargeting"=20 > URI based on the received response. > And the cause as defined in RFC4458 is in the target URI. >=20 > Comments?=20 >=20 > Best Regards >=20 > Roland=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org=20 > [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=20 > escapedheader (was Comments on draft-ietf-sipcore-rfc4244bis-02) >=20 >=20 > I know this is beating a dead horse, but breaking backwards=20 > compatibility for Hist-Ifno may be a GOOD thing. > Seriously. Afaict, "legacy" H-I is broken. It didn't solve=20 > people's problems, in an interoperable fashion. That's why=20 > we needed 4244bis to begin with, ain't it? >=20 > In fact, start with a new header name, if need be. > To be transparent, we can name the new header=20 > "Possible-Targets-Lottery:" and if you guess the right "real"=20 > target from the list, you win some award. :) >=20 > -hadriel >=20 > On Nov 8, 2010, at 12:48 AM, Shida Schubert wrote: >=20 > >=20 > > I don't agree. This is going to completely break backward=20 > > 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=20 > bis as an opportunity to get this right, even if we have to=20 > grandfather some existing mechanism. The Mohali draft is=20 > evidence that the present mechanism causes further problems=20 > 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=20 > 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=20 > >>>> URI parameter. It is a SIP header field that is escaped=20 > in the URI=20 > >>>> for compactness. > >>>=20 > >>> I don't think there is any real confusion. Its just that the=20 > >>> terminology is awkward. We have parameters to headers,=20 > and we have=20 > >>> headers that are parameters to URIs. > >>>=20 > >>>> In earlier versions, we had a separate parameter in the SIP=20 > >>>> History-Info header for Reason, but Rohan suggested to > >>> just escape > >>>> the existing Reason header in the URI so as not to=20 > redefine Reason=20 > >>>> parameters. > >>>=20 > >>> I even remember him making that suggestion. Too bad he=20 > isn't around=20 > >>> so we can wring his neck. I thought it was a hack at the=20 > time, but=20 > >>> 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=20 > and the new)=20 > >>>> . The idea of capturing the "new" is so that you > >>> already have > >>>> the old entry when you do the retarget, noting that when=20 > an entity=20 > >>>> goes to process History-Info, the last entry isn't typically=20 > >>>> useful, since it should always be the URI in the=20 > received request. =20 > >>>> 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=20 > were the right=20 > >>>> thing to do due to backwards compatibility. > >>>=20 > >>> So then we allow it continue to metastasize, e.g. by defining new=20 > >>> Reason values that aren't ever expected to be used in=20 > requests, and=20 > >>> 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=20 > >>>>>> confusing. I can change all instances to refer to "escape a=20 > >>>>>> 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=20 > response,=20 > >>>>>>> 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=20 > >>>>>> hi-targeted-to-URI is being retargeted due to the=20 > response. It=20 > >>>>>> 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=20 > >>>>>> "current" hi-entry. It's added to the previous. The=20 > sentences=20 > >>>>>> following the one that you highlight are intended to say > >>> just that. > >>>>>> That's why the term "associated" is loosely used=20 > because the next=20 > >>>>>> sentences are the normative part. So, really, that=20 > first sentence=20 > >>>>>> 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.=20 > That isn't=20 > >>>>> 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=20 > >>>>> draft-mohali-sipcore-reason-call-forwarding which is > >>> defining new reason > >>>>> codes which are intended specifically for use with H-I, without=20 > >>>>> 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 >=20 > _______________________________________________ > 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 >=20 From Internet-Drafts@ietf.org Mon Nov 8 18:16:39 2010 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 D2AA628C212; Mon, 8 Nov 2010 18:16:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.929 X-Spam-Level: X-Spam-Status: No, score=-101.929 tagged_above=-999 required=5 tests=[AWL=0.670, BAYES_00=-2.599, 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 xnHoBxvq4aN1; Mon, 8 Nov 2010 18:16:39 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83F5428C1BF; Mon, 8 Nov 2010 18:15:39 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no Message-ID: <20101109021539.26008.25726.idtracker@localhost> Date: Mon, 08 Nov 2010 18:15:39 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-sec-flows-04.txt 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: Tue, 09 Nov 2010 02:16:40 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Example call flows using Session Initiation Protocol (SIP) security mechanisms Author(s) : C. Jennings, et al. Filename : draft-ietf-sipcore-sec-flows-04.txt Pages : 66 Date : 2010-11-08 This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-sec-flows-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-sec-flows-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-08095216.I-D@ietf.org> --NextPart-- From R.Jesske@telekom.de Mon Nov 8 18:17:07 2010 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 269C028C2EC for ; Mon, 8 Nov 2010 18:17:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.799 X-Spam-Level: X-Spam-Status: No, score=-1.799 tagged_above=-999 required=5 tests=[AWL=-0.850, BAYES_00=-2.599, HELO_EQ_DE=0.35, MANGLED_EXTNSN=2.3, RCVD_IN_DNSWL_LOW=-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 XgWVDRAQ90WL for ; Mon, 8 Nov 2010 18:17:05 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 8231E28C159 for ; Mon, 8 Nov 2010 18:16:39 -0800 (PST) Received: from s4de8psaans.blf.telekom.de (HELO s4de8psaans.mitte.t-com.de) ([10.151.180.168]) by tcmail71.telekom.de with ESMTP; 09 Nov 2010 03:16:58 +0100 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by s4de8psaans.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Nov 2010 03:16:58 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Nov 2010 03:16:53 +0100 Message-ID: <9886E5FCA6D76549A3011068483A4BD406D5D22C@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Reason as a parameter rather than anescapedheader (was Comments on draft-ietf-sipcore-rfc4244bis-02) Thread-Index: Act/Dp+TWptJkoHxTKmW70ParzWVEwACbydAAAfV2GAAHYTyEA== References: <4CD6C020.7030603@cisco.com><4CD7555F.30609@cisco.com> <9886E5FCA6D76549A3011068483A4BD406D5CF8B@S4DE8PSAAQB.mitte.t-com.de> From: To: , , X-OriginalArrivalTime: 09 Nov 2010 02:16:58.0584 (UTC) FILETIME=[2FF86580:01CB7FB4] Cc: sipcore@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 02:17:07 -0000 Hi, I see the problems also with the future use of the H-I. But how we could = solve it? Question is if we could make the Reason optional instead mandatory for = cases where the retargeting was based on a SIP Response? I cannot see what will break if we do it as a option. (For Call = forwarding it is important that we can count the real forwarding's. It = is not really important on which the forwarding's are based.) Next Question is if we could use instead the RFC4458 causes with further = values. I know I asked already this question but I didn't get a clear = answer why not to use. RFC4458 does define this causes not only for the = cases Voicemail and IVR, it says: "such as". What are the opinions on that. The only what I also want to have is a future proof solution as Marianne = would like. Within ISUP the Redirecting reason is within the Redirection Information = Parameter included which is not bind to any of the Numbers. It is a own = Parameter. So =20 there are not the problems where and how to place the "cause" Best Regards Roland =20 -----Urspr=FCngliche Nachricht----- Von: marianne.mohali@orange-ftgroup.com = [mailto:marianne.mohali@orange-ftgroup.com]=20 Gesendet: Dienstag, 9. November 2010 01:43 An: Jesske, Roland; HKaplan@acmepacket.com; shida@ntt-at.com Cc: sipcore@ietf.org Betreff: RE: [sipcore] Reason as a parameter rather than anescapedheader = (was Comments on draft-ietf-sipcore-rfc4244bis-02) 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=3Dxxx" 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 m 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. =20 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 =3D the Retargeting). In general, we need = to know which entity do what.=20 Whatever the one chosen, it has to be clearly mentionned, not only with = "associated to the hi-retargeted-to-uri" not saying which one.=20 =20 Marianne > -----Message d'origine----- > De : sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] De la part de R.Jesske@telekom.de > Envoy=E9 : lundi 8 novembre 2010 15:53 > =C0 : HKaplan@acmepacket.com; shida@ntt-at.com > Cc : sipcore@ietf.org > Objet : Re: [sipcore] Reason as a parameter rather than=20 > anescapedheader (was Comments on draft-ietf-sipcore-rfc4244bis-02) >=20 > Hi, > we have already a mechanism putting a "cause" into the URI=20 > which is the target. > RFC4458 describes this for diverting reasons.=20 > So it is a own header used for History Info no new definition=20 > is needed. > And so this mechanism could be extended by the proposed=20 > values in=20 > http://tools.ietf.org/html/draft-mohali-sipcore-reason-extensi > on-application-00 and other needed.=20 >=20 > So in final the Reason is included within the "retargeting"=20 > URI based on the received response. > And the cause as defined in RFC4458 is in the target URI. >=20 > Comments?=20 >=20 > Best Regards >=20 > Roland=20 >=20 > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org=20 > [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=20 > escapedheader (was Comments on draft-ietf-sipcore-rfc4244bis-02) >=20 >=20 > I know this is beating a dead horse, but breaking backwards=20 > compatibility for Hist-Ifno may be a GOOD thing. > Seriously. Afaict, "legacy" H-I is broken. It didn't solve=20 > people's problems, in an interoperable fashion. That's why=20 > we needed 4244bis to begin with, ain't it? >=20 > In fact, start with a new header name, if need be. > To be transparent, we can name the new header=20 > "Possible-Targets-Lottery:" and if you guess the right "real"=20 > target from the list, you win some award. :) >=20 > -hadriel >=20 > On Nov 8, 2010, at 12:48 AM, Shida Schubert wrote: >=20 > >=20 > > I don't agree. This is going to completely break backward=20 > > 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=20 > bis as an opportunity to get this right, even if we have to=20 > grandfather some existing mechanism. The Mohali draft is=20 > evidence that the present mechanism causes further problems=20 > 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=20 > 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=20 > >>>> URI parameter. It is a SIP header field that is escaped=20 > in the URI=20 > >>>> for compactness. > >>>=20 > >>> I don't think there is any real confusion. Its just that the=20 > >>> terminology is awkward. We have parameters to headers,=20 > and we have=20 > >>> headers that are parameters to URIs. > >>>=20 > >>>> In earlier versions, we had a separate parameter in the SIP=20 > >>>> History-Info header for Reason, but Rohan suggested to > >>> just escape > >>>> the existing Reason header in the URI so as not to=20 > redefine Reason=20 > >>>> parameters. > >>>=20 > >>> I even remember him making that suggestion. Too bad he=20 > isn't around=20 > >>> so we can wring his neck. I thought it was a hack at the=20 > time, but=20 > >>> 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=20 > and the new)=20 > >>>> . The idea of capturing the "new" is so that you > >>> already have > >>>> the old entry when you do the retarget, noting that when=20 > an entity=20 > >>>> goes to process History-Info, the last entry isn't typically=20 > >>>> useful, since it should always be the URI in the=20 > received request. =20 > >>>> 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=20 > were the right=20 > >>>> thing to do due to backwards compatibility. > >>>=20 > >>> So then we allow it continue to metastasize, e.g. by defining new=20 > >>> Reason values that aren't ever expected to be used in=20 > requests, and=20 > >>> 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=20 > >>>>>> confusing. I can change all instances to refer to "escape a=20 > >>>>>> 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=20 > response,=20 > >>>>>>> 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=20 > >>>>>> hi-targeted-to-URI is being retargeted due to the=20 > response. It=20 > >>>>>> 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=20 > >>>>>> "current" hi-entry. It's added to the previous. The=20 > sentences=20 > >>>>>> following the one that you highlight are intended to say > >>> just that. > >>>>>> That's why the term "associated" is loosely used=20 > because the next=20 > >>>>>> sentences are the normative part. So, really, that=20 > first sentence=20 > >>>>>> 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.=20 > That isn't=20 > >>>>> 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=20 > >>>>> draft-mohali-sipcore-reason-call-forwarding which is > >>> defining new reason > >>>>> codes which are intended specifically for use with H-I, without=20 > >>>>> 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 >=20 > _______________________________________________ > 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 >=20 From R.Jesske@telekom.de Mon Nov 8 18:27:27 2010 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 AD3653A6941 for ; Mon, 8 Nov 2010 18:27:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.549 X-Spam-Level: X-Spam-Status: No, score=-2.549 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, HELO_EQ_DE=0.35, J_CHICKENPOX_63=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_LOW=-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 td0OmAmtuG-b for ; Mon, 8 Nov 2010 18:27:26 -0800 (PST) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id B609828C0DC for ; Mon, 8 Nov 2010 18:27:23 -0800 (PST) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail81.telekom.de with ESMTP; 09 Nov 2010 03:27:45 +0100 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Tue, 9 Nov 2010 03:27:45 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 9 Nov 2010 03:27:34 +0100 Message-ID: <9886E5FCA6D76549A3011068483A4BD406D5D22F@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <4CD8910E.5080706@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Yet more comments on rfc4244bis-02 Thread-Index: Act/olsa9GHz1bvATDawQb4fnMImzgAEr7pA References: <865731.30413.qm@web29104.mail.ird.yahoo.com> <4CD8910E.5080706@cisco.com> From: To: , X-OriginalArrivalTime: 09 Nov 2010 02:27:45.0835 (UTC) FILETIME=[B1C30FB0:01CB7FB5] Subject: Re: [sipcore] Yet more comments on 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: Tue, 09 Nov 2010 02:27:27 -0000 Hi, seen from network operator perspective. The stronger value hits. So if there is a "history" and "none" in the same Message then the = History Info will be anonymised and the rest will stay as it is. Best Regards Roland =20 -----Urspr=FCngliche Nachricht----- Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im = Auftrag von Paul Kyzivat Gesendet: Dienstag, 9. November 2010 01:09 An: sipcore@ietf.org Betreff: Re: [sipcore] Yet more comments on rfc4244bis-02 On 11/8/2010 1:10 PM, Ian Elz wrote: > Mary, > > I am a bit late replying. > > The reason for the Privacy of "none" was probably due to my comments. > > Regarding "Privacy:history" being used to anonomise all H-I URI then = this probably looks OK as it makes everything private. > > The problem is that making the Privacy header take precedence over the = individual entries is when you have "Privacy:none" and some of the H-I = entries have Privacy=3Dhistory. If you take the Privacy:history case = then the ":none" will override "=3Dhistory" which effectively means that = the originator of the request can specify the privacy of URIs belonging = to someone who diverts or re-targets the request. > > This is just not correct. Why do you say this is not correct? ISTM the purpose of Privacy:none is precisely to demand that nothing be=20 removed or anonymized. For instance, IIUC this would apply to Route=20 headers, which present some of the same issues as H-I headers. Elements along the way that don't like this can either: - fail the call - omit information in the first place if they want it kept private Thanks, Paul > The purpose of allowing "privacy=3Dnone" in the H-I entry was to allow = the future possibility of the overriding the Privacy header. > > We need to remember that RFC3323 was written when cocepts of diversion = etc were not part of sip. > > Ian Elz > > ----- Original Message ----- > From: "Mary Barnes" > To: "Shida Schubert" > Cc: sipcore@ietf.org, "Mary Barnes" > Sent: Monday, 8 November, 2010 5:19:25 AM > Subject: Re: [sipcore] Yet more comments on rfc4244bis-02 > > A few additional comments inline below [MB]. > > Mary. > > On Sun, Nov 7, 2010 at 12:28 AM, Shida Schubert = wrote: >> >> Hi John; >> >> My responses on some of the comments, I think >> Mary may be responding on the same issues but here are mine. >> >> On Nov 4, 2010, at 12:29 AM, Elwell, John wrote: >> >>> 1. Section 7.3.1. >>> "If there is a Privacy header in the request with a priv- >>> value of "header" or "history", then the initial hi-entry MUST be >>> anonymized and the header removed when the request leaves a = domain >>> for which the SIP entity is responsible." >>> I think it should say "...and the Privacy header removed" - there is = no point in removing the H-I header field if we have anonymized it. >> >> You are right. The intention was to say "remove the priv-value and = remove the privacy >> header itself if there are no other priv-value left (id may exists = which needs >> to remain in the request until it reaches the egress point)". >> >>> >>> 2. What is meant by anonymizing a hi-entry (in this paragraph and = elsewhere)? Is it only the hi-targeted-to-uri that needs to be = anonymized, or also its parameters? The examples in annex B show just = the URI anonymized and with the value anonymous@anonymous.invalid. Is = this how it MUST be done? > > [MB] It is only the hi-targeted-to-uri that needs to be anonymized - > it is a MUST. The other parameters MUST not be changed. [/MB] >> >> I personally don't have a strong opinion about prescribing the = anonymous@anonymou.invalid but >> I think it would be useful to specify what the anonymized URI should = look like. This would avoid >> anonymous URI anonymized numerous time by different privacy service = for example... >> As for the parameter, if rc/mp tag, index and encoded reason(RFC = 3326) are intact, >> anonymized hi-entry can still provide some value, so I think only = hi-targeted-to-uri should be >> anonymized. >> >>> >>> 3. In the same sentence, is it sufficient to anonymize only the = first hi-entry? There could be further hi-entries for the same domain, = and just revealing internal routing within the domain might be = considered a breach of privacy. Perhaps in that case you would need to = rely on those additional hi-entries being separately marked for privacy. = If that is so, it would seem to be OK. >> >> Your last suggestion/assumption was exactly the motivation and our >> attempt to simplify privacy handling, by saying Privacy header with = priv-value >> of "history"/"header" (not in hi-entry) for anonymizing first = hi-entry only and to use >> privacy=3Dheader in hi-entry for any other hi-entries. >> >> It would mean; >> >> 1. UA requests H-I privacy by using Privacy:history or = Privacy:header >> 2. Proxy request H-I privacy by using = History-Info:?privacy=3Dhistory >> >> Which we thought would clarify the timing of when Privacy:history / = Privacy:header >> and privacy=3Dhistory are used. >> >> But thinking further, it doesn't really simplify the overall >> privacy handling of H-I and furthermore it changes the semantics of >> header privacy in RFC3323. >> >> Excerpt from RFC3323 on header privacy says: >> >> "If a privacy level of 'header' is requested, then the originating >> user has asked the privacy service to help to obscure headers that >> might otherwise reveal information about the originator of the >> request." >> >> This can encompass entries revealing internal routing and domain >> information as you mentioned above, so restricting the use of = Privacy:header >> to first entry only can be seen as changing the semantics defined in = RFC3323. >> >> I think we should align the handling of H-I privacy of = Privacy:history >> and Privacy:header to that of RFC3323, allowing privacy service to >> anonymize not only the first hi-entry but any other entries that >> are from its domain. > [MB] I don't have a strong opinion here. The suggestion above makes > alot of sense. [/MB] >> >> I guess we need to further clarify how these two means of = requesting >> privacy interact, since you can have both privacy:history and few = hi-entries >> with privacy=3Dhistory. I am assuming that when privacy service = anonymizes >> history-info header based on privacy:history or privacy:header, it = also >> needs to remove the privacy=3Dhistory from hi-entries that it's = anonymizing. > [MB] Yes, we should clarify. With the approach discussed above, the > privacy:history would "override" the privacy for each entry (within > that domain). And, yes, per a previous thread, we do need to update > the privacy text to indicate the removal of the privacy for each > hi-entry as it is anonymized. [/MB] > >> >> Lastly what about the interaction with privacy:none? According to >> section 5.1 of 4244bis, if UAC doesn't want privacy on its identity = it sets >> Privacy header with priv-value of "none", but I am having a hard time >> envisioning the need for this. When do you ever get the hi-entry = representing >> your own AoR or contact address? > [MB] We originally did not include privacy of "none" as relevant to > History-info (in 4244). That was added in -bis and I to question the > value. I do not think it has any value as applied to History-Info and > I would suggest we remove it or note that it has no impact in terms of > the processing of privacy for the hi-entries. [/MB] >> >> I think the hi-entry with privacy=3Dhistory should still be = anonymized, even when >> the Privacy:none is set in request because the privacy is requested = by proxy, I >> think we need to add text on this as well. > [MB] Agreed. [/MB] >> >> >>> >>> 4. "In addition, the History-Info header can reveal general routing = and >>> diverting information within an intermediary, " >>> Is it only routing information within an intermediary, or also = routing information within a domain that you might want to make private? = I think text later in the paragraph concurs with the latter view. > [MB] yes, it's the latter - within a domain for which the > intermediary is responsible. [/MB] >>> >>> 5. "Finally, the terminator of the request may not want to reveal = the >>> final reached target to the originator. In this case, the = terminator >>> uses the a value of "history" in the Privacy header in the last = hi- >>> entry in the response. The SIP entity that forwards the response >>> MUST anonymize that hi-entry and remove the Privacy header." >>> Although a UAS can mark the final hi-entry as private, and there is = a requirement for a proxy to anonymize this when the response leaves the = domain, what about other hi-entries that have been marked by proxies in = the final domain as private? These will get passed back in the response = without anonymization since they are not the final hi-entry and are not = covered by this statement. Should the final sentence apply to any = hi-entry? > [MB] Yes. that sentence should apply to all responses - i.e., in > general if there are hi-entries with an escaped privacy header, they > should be anonymized and the privacy header removed. [/MB] >> >> RFC3323 recommends that privacy service to be included in the >> request/response path if privacy is desired. The privacy handling >> in 4244bis is based on RFC3323 so I don't know if we need to add >> anything specific here for anonymizing the response. >> >>> >>> 6. Section 7.3.3: >>> "To >>> accomplish this, the processing entity MUST read the value = from >>> the History-Info header in the received request and MUST add >>> another level of indexing " >>> Should make it clear it is the last hi-entry of the received request = (after adding entries on behalf of previous hops). >> >> Agree. >> >>> >>> 7. "followed >>> by an initial index for the new level of 1" >>> I think this would be clearer if it said: >>> "followed by an initial index of 1 for the new level" >> >> Agree. >> >>> >>> 8. "MUST be calculated by incrementing the last/lowest digit >>> at the current level" >>> and >>> "That is, the lowest/last digit of the index MUST be >>> incremented " >>> What if an index is a double-digit integer? >> >> How about we remove the "lowest/last" and simply >> say incrementing the digit at the current level by 1 or >> something like that. >> >>> >>> 9. Section 8: >>> "an >>> application might need to provide special handling in some cases >>> where there are gaps." >>> Should there be a note discussing the fact that some gaps are not = detectable, e.g., if I receive 1, 1.1 and 1.1.1, I cannot detect if 1.2 = or 1.1.2, say, is missing. >> >> This would happen, say for example if request was >> parallel forked, each branch would have the hi-entry >> that only the forked request traversed but missing >> the information of the other forks. I don't know if I would >> consider what you describe as a gap. You may be >> missing the other branches but you should be able to >> identify the gap in index for the branch that request >> traversed. (You may be missing the actual hop in the >> logical tree of History-Info that does not support >> 4244/4244bis but as they won't add the hi-entry >> there won't be a gap in index itself). >> >>> >>> 10. Should we say anything in section 8 about anonymized entries? = Note that what we might say depends to some extent on whether what = exactly gets anomymised. For example if an application searches for an = rc or mp entry, if those parameters have been anonymized it will not = find them (but might find others that have not been anonymized!), but if = those parameters have not been anonymized it will find them but the URI = will be useless. >> >> URI will be useless but one can still determine how many times >> request was retargeted, for example (Of course this is true only >> if all the proxies are rfc4244bis compliant), which I think remains >> useful. >> >>> >>> 11. Section 9: >>> "With the level of security provided by TLS (SEC-req-3), the >>> information in the History-Info header can thus be evaluated to >>> determine if information has been removed by evaluating the = indices >>> for gaps (SEC-req-1, SEC-req-2). " >>> This is subject to the limitation pointed out in a comment above, = about not all gaps being detectable. >>> >>> 12. I would expect to see something in section 9 concerning privacy. = We should mention the privacy mechanism and discuss its limits (i.e., = depends on trust of downstream entities to anonymize privacy-marked = entries). Also there should probably be some discussion on strength of = anonymization algorithms (unless we are indeed prescribing = anonymous@anonymous.invalid). >> >> Agree that text should be added. >> >>> >>> 13. Section 10.2: >>> "This document defines a priv-value for the SIP Privacy header: >>> history The following changes have been made to >>> http://www.iana.org/assignments/sip-priv-values The following has >>> been added to the registration for the SIP Privacy header:" >>> I am not sure how to parse this. >> >>> >>> >>> 14. Section 12.1: >>> "This specification adds an >>> optional SIP header field parameter to the History-Info and = Contact >>> headers. " >>> In fact it adds two parameters to each. >> >> Indeed. >> >>> >>> 15. "Entities that have not implemented this specification MUST >>> ignore these parameters, " >>> We cannot place a normative requirement on entities that don't = implement this. Change "MUST" to "will". >> >> Agree. >> >>> >>> John >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >>> 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 From john.elwell@siemens-enterprise.com Mon Nov 8 18:32:42 2010 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 54A003A6A1A for ; Mon, 8 Nov 2010 18:32:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.485 X-Spam-Level: X-Spam-Status: No, score=-102.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, 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 6NH9L1R-MwRY for ; Mon, 8 Nov 2010 18:32:36 -0800 (PST) Received: from ms02.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 89CD428C1C4 for ; Mon, 8 Nov 2010 18:32:28 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms02.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2223280 for sipcore@ietf.org; Tue, 9 Nov 2010 03:32:50 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 2B5BD23F0278 for ; Tue, 9 Nov 2010 03:32:50 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Tue, 9 Nov 2010 03:32:50 +0100 From: "Elwell, John" To: "sipcore@ietf.org" Date: Tue, 9 Nov 2010 03:32:48 +0100 Thread-Topic: Understanding Privacy: history invoked by UAS Thread-Index: Act/tmX64nFBhz6FSZe0YJ2Va+pn3Q== Message-ID: 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 Subject: [sipcore] Understanding Privacy: history invoked by UAS 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: Tue, 09 Nov 2010 02:32:43 -0000 Suppose a request from A is targeted initially at B, this is mapped to C, a= nd then to registered contact D. The UAS (D) puts Privacy: history in the r= esponse, and therefore prevents A learning about C and D. Fine. Now, supposing D is not registered at the time, i.e., there is no registere= d contact for C. This results in a 4xx response to A. How do we ensure that= the identity of C is not disclosed to A, in line with what is achieved whe= n D is registered? John From pkyzivat@cisco.com Mon Nov 8 18:51:52 2010 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 9756D28C10A for ; Mon, 8 Nov 2010 18:51:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.888 X-Spam-Level: X-Spam-Status: No, score=-109.888 tagged_above=-999 required=5 tests=[AWL=-0.489, BAYES_00=-2.599, J_CHICKENPOX_63=0.6, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8, 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 3-jl9H-QktY0 for ; Mon, 8 Nov 2010 18:51:47 -0800 (PST) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 936FE28C260 for ; Mon, 8 Nov 2010 18:51:12 -0800 (PST) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKdF2ExAaMHG/2dsb2JhbACiHHGhDpt5gnEBglYEhFaFf4MKgm2FVw X-IronPort-AV: E=Sophos;i="4.59,172,1288569600"; d="scan'208";a="289886719" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-2.cisco.com with ESMTP; 09 Nov 2010 02:51:25 +0000 Received: from [10.75.235.233] (hkidc-vpn-client-235-233.cisco.com [10.75.235.233]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA92pIfT017276; Tue, 9 Nov 2010 02:51:20 GMT Message-ID: <4CD8B723.5090007@cisco.com> Date: Tue, 09 Nov 2010 10:51:15 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: R.Jesske@telekom.de References: <865731.30413.qm@web29104.mail.ird.yahoo.com> <4CD8910E.5080706@cisco.com> <9886E5FCA6D76549A3011068483A4BD406D5D22F@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD406D5D22F@S4DE8PSAAQB.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Yet more comments on 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: Tue, 09 Nov 2010 02:51:52 -0000 That begs the question of which is "stronger", and who is presumed to be in control. ISTM that the intent with Privacy was to put the UAC in control, not the operator. Of course the operators won't see it that way - they are used to being in control. And in the end we can do little to prevent the operators from doing as they wish, regardless of what the specs say. But we can say that they are non-compliant when doing so. Thanks, Paul On 11/9/2010 10:27 AM, R.Jesske@telekom.de wrote: > Hi, > seen from network operator perspective. The stronger value hits. > So if there is a "history" and "none" in the same Message then the History Info will be anonymised and the rest will stay as it is. > > Best Regards > > Roland > > > -----Ursprüngliche Nachricht----- > Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftrag von Paul Kyzivat > Gesendet: Dienstag, 9. November 2010 01:09 > An: sipcore@ietf.org > Betreff: Re: [sipcore] Yet more comments on rfc4244bis-02 > > > > On 11/8/2010 1:10 PM, Ian Elz wrote: >> Mary, >> >> I am a bit late replying. >> >> The reason for the Privacy of "none" was probably due to my comments. >> >> Regarding "Privacy:history" being used to anonomise all H-I URI then this probably looks OK as it makes everything private. >> >> The problem is that making the Privacy header take precedence over the individual entries is when you have "Privacy:none" and some of the H-I entries have Privacy=history. If you take the Privacy:history case then the ":none" will override "=history" which effectively means that the originator of the request can specify the privacy of URIs belonging to someone who diverts or re-targets the request. >> >> This is just not correct. > > Why do you say this is not correct? > ISTM the purpose of Privacy:none is precisely to demand that nothing be > removed or anonymized. For instance, IIUC this would apply to Route > headers, which present some of the same issues as H-I headers. > > Elements along the way that don't like this can either: > - fail the call > - omit information in the first place if they want it kept private > > Thanks, > Paul > >> The purpose of allowing "privacy=none" in the H-I entry was to allow the future possibility of the overriding the Privacy header. >> >> We need to remember that RFC3323 was written when cocepts of diversion etc were not part of sip. >> >> Ian Elz >> >> ----- Original Message ----- >> From: "Mary Barnes" >> To: "Shida Schubert" >> Cc: sipcore@ietf.org, "Mary Barnes" >> Sent: Monday, 8 November, 2010 5:19:25 AM >> Subject: Re: [sipcore] Yet more comments on rfc4244bis-02 >> >> A few additional comments inline below [MB]. >> >> Mary. >> >> On Sun, Nov 7, 2010 at 12:28 AM, Shida Schubert wrote: >>> >>> Hi John; >>> >>> My responses on some of the comments, I think >>> Mary may be responding on the same issues but here are mine. >>> >>> On Nov 4, 2010, at 12:29 AM, Elwell, John wrote: >>> >>>> 1. Section 7.3.1. >>>> "If there is a Privacy header in the request with a priv- >>>> value of "header" or "history", then the initial hi-entry MUST be >>>> anonymized and the header removed when the request leaves a domain >>>> for which the SIP entity is responsible." >>>> I think it should say "...and the Privacy header removed" - there is no point in removing the H-I header field if we have anonymized it. >>> >>> You are right. The intention was to say "remove the priv-value and remove the privacy >>> header itself if there are no other priv-value left (id may exists which needs >>> to remain in the request until it reaches the egress point)". >>> >>>> >>>> 2. What is meant by anonymizing a hi-entry (in this paragraph and elsewhere)? Is it only the hi-targeted-to-uri that needs to be anonymized, or also its parameters? The examples in annex B show just the URI anonymized and with the value anonymous@anonymous.invalid. Is this how it MUST be done? >> >> [MB] It is only the hi-targeted-to-uri that needs to be anonymized - >> it is a MUST. The other parameters MUST not be changed. [/MB] >>> >>> I personally don't have a strong opinion about prescribing the anonymous@anonymou.invalid but >>> I think it would be useful to specify what the anonymized URI should look like. This would avoid >>> anonymous URI anonymized numerous time by different privacy service for example... >>> As for the parameter, if rc/mp tag, index and encoded reason(RFC 3326) are intact, >>> anonymized hi-entry can still provide some value, so I think only hi-targeted-to-uri should be >>> anonymized. >>> >>>> >>>> 3. In the same sentence, is it sufficient to anonymize only the first hi-entry? There could be further hi-entries for the same domain, and just revealing internal routing within the domain might be considered a breach of privacy. Perhaps in that case you would need to rely on those additional hi-entries being separately marked for privacy. If that is so, it would seem to be OK. >>> >>> Your last suggestion/assumption was exactly the motivation and our >>> attempt to simplify privacy handling, by saying Privacy header with priv-value >>> of "history"/"header" (not in hi-entry) for anonymizing first hi-entry only and to use >>> privacy=header in hi-entry for any other hi-entries. >>> >>> It would mean; >>> >>> 1. UA requests H-I privacy by using Privacy:history or Privacy:header >>> 2. Proxy request H-I privacy by using History-Info:?privacy=history >>> >>> Which we thought would clarify the timing of when Privacy:history / Privacy:header >>> and privacy=history are used. >>> >>> But thinking further, it doesn't really simplify the overall >>> privacy handling of H-I and furthermore it changes the semantics of >>> header privacy in RFC3323. >>> >>> Excerpt from RFC3323 on header privacy says: >>> >>> "If a privacy level of 'header' is requested, then the originating >>> user has asked the privacy service to help to obscure headers that >>> might otherwise reveal information about the originator of the >>> request." >>> >>> This can encompass entries revealing internal routing and domain >>> information as you mentioned above, so restricting the use of Privacy:header >>> to first entry only can be seen as changing the semantics defined in RFC3323. >>> >>> I think we should align the handling of H-I privacy of Privacy:history >>> and Privacy:header to that of RFC3323, allowing privacy service to >>> anonymize not only the first hi-entry but any other entries that >>> are from its domain. >> [MB] I don't have a strong opinion here. The suggestion above makes >> alot of sense. [/MB] >>> >>> I guess we need to further clarify how these two means of requesting >>> privacy interact, since you can have both privacy:history and few hi-entries >>> with privacy=history. I am assuming that when privacy service anonymizes >>> history-info header based on privacy:history or privacy:header, it also >>> needs to remove the privacy=history from hi-entries that it's anonymizing. >> [MB] Yes, we should clarify. With the approach discussed above, the >> privacy:history would "override" the privacy for each entry (within >> that domain). And, yes, per a previous thread, we do need to update >> the privacy text to indicate the removal of the privacy for each >> hi-entry as it is anonymized. [/MB] >> >>> >>> Lastly what about the interaction with privacy:none? According to >>> section 5.1 of 4244bis, if UAC doesn't want privacy on its identity it sets >>> Privacy header with priv-value of "none", but I am having a hard time >>> envisioning the need for this. When do you ever get the hi-entry representing >>> your own AoR or contact address? >> [MB] We originally did not include privacy of "none" as relevant to >> History-info (in 4244). That was added in -bis and I to question the >> value. I do not think it has any value as applied to History-Info and >> I would suggest we remove it or note that it has no impact in terms of >> the processing of privacy for the hi-entries. [/MB] >>> >>> I think the hi-entry with privacy=history should still be anonymized, even when >>> the Privacy:none is set in request because the privacy is requested by proxy, I >>> think we need to add text on this as well. >> [MB] Agreed. [/MB] >>> >>> >>>> >>>> 4. "In addition, the History-Info header can reveal general routing and >>>> diverting information within an intermediary, " >>>> Is it only routing information within an intermediary, or also routing information within a domain that you might want to make private? I think text later in the paragraph concurs with the latter view. >> [MB] yes, it's the latter - within a domain for which the >> intermediary is responsible. [/MB] >>>> >>>> 5. "Finally, the terminator of the request may not want to reveal the >>>> final reached target to the originator. In this case, the terminator >>>> uses the a value of "history" in the Privacy header in the last hi- >>>> entry in the response. The SIP entity that forwards the response >>>> MUST anonymize that hi-entry and remove the Privacy header." >>>> Although a UAS can mark the final hi-entry as private, and there is a requirement for a proxy to anonymize this when the response leaves the domain, what about other hi-entries that have been marked by proxies in the final domain as private? These will get passed back in the response without anonymization since they are not the final hi-entry and are not covered by this statement. Should the final sentence apply to any hi-entry? >> [MB] Yes. that sentence should apply to all responses - i.e., in >> general if there are hi-entries with an escaped privacy header, they >> should be anonymized and the privacy header removed. [/MB] >>> >>> RFC3323 recommends that privacy service to be included in the >>> request/response path if privacy is desired. The privacy handling >>> in 4244bis is based on RFC3323 so I don't know if we need to add >>> anything specific here for anonymizing the response. >>> >>>> >>>> 6. Section 7.3.3: >>>> "To >>>> accomplish this, the processing entity MUST read the value from >>>> the History-Info header in the received request and MUST add >>>> another level of indexing " >>>> Should make it clear it is the last hi-entry of the received request (after adding entries on behalf of previous hops). >>> >>> Agree. >>> >>>> >>>> 7. "followed >>>> by an initial index for the new level of 1" >>>> I think this would be clearer if it said: >>>> "followed by an initial index of 1 for the new level" >>> >>> Agree. >>> >>>> >>>> 8. "MUST be calculated by incrementing the last/lowest digit >>>> at the current level" >>>> and >>>> "That is, the lowest/last digit of the index MUST be >>>> incremented " >>>> What if an index is a double-digit integer? >>> >>> How about we remove the "lowest/last" and simply >>> say incrementing the digit at the current level by 1 or >>> something like that. >>> >>>> >>>> 9. Section 8: >>>> "an >>>> application might need to provide special handling in some cases >>>> where there are gaps." >>>> Should there be a note discussing the fact that some gaps are not detectable, e.g., if I receive 1, 1.1 and 1.1.1, I cannot detect if 1.2 or 1.1.2, say, is missing. >>> >>> This would happen, say for example if request was >>> parallel forked, each branch would have the hi-entry >>> that only the forked request traversed but missing >>> the information of the other forks. I don't know if I would >>> consider what you describe as a gap. You may be >>> missing the other branches but you should be able to >>> identify the gap in index for the branch that request >>> traversed. (You may be missing the actual hop in the >>> logical tree of History-Info that does not support >>> 4244/4244bis but as they won't add the hi-entry >>> there won't be a gap in index itself). >>> >>>> >>>> 10. Should we say anything in section 8 about anonymized entries? Note that what we might say depends to some extent on whether what exactly gets anomymised. For example if an application searches for an rc or mp entry, if those parameters have been anonymized it will not find them (but might find others that have not been anonymized!), but if those parameters have not been anonymized it will find them but the URI will be useless. >>> >>> URI will be useless but one can still determine how many times >>> request was retargeted, for example (Of course this is true only >>> if all the proxies are rfc4244bis compliant), which I think remains >>> useful. >>> >>>> >>>> 11. Section 9: >>>> "With the level of security provided by TLS (SEC-req-3), the >>>> information in the History-Info header can thus be evaluated to >>>> determine if information has been removed by evaluating the indices >>>> for gaps (SEC-req-1, SEC-req-2). " >>>> This is subject to the limitation pointed out in a comment above, about not all gaps being detectable. >>>> >>>> 12. I would expect to see something in section 9 concerning privacy. We should mention the privacy mechanism and discuss its limits (i.e., depends on trust of downstream entities to anonymize privacy-marked entries). Also there should probably be some discussion on strength of anonymization algorithms (unless we are indeed prescribing anonymous@anonymous.invalid). >>> >>> Agree that text should be added. >>> >>>> >>>> 13. Section 10.2: >>>> "This document defines a priv-value for the SIP Privacy header: >>>> history The following changes have been made to >>>> http://www.iana.org/assignments/sip-priv-values The following has >>>> been added to the registration for the SIP Privacy header:" >>>> I am not sure how to parse this. >>> >>>> >>>> >>>> 14. Section 12.1: >>>> "This specification adds an >>>> optional SIP header field parameter to the History-Info and Contact >>>> headers. " >>>> In fact it adds two parameters to each. >>> >>> Indeed. >>> >>>> >>>> 15. "Entities that have not implemented this specification MUST >>>> ignore these parameters, " >>>> We cannot place a normative requirement on entities that don't implement this. Change "MUST" to "will". >>> >>> Agree. >>> >>>> >>>> John >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 > From Internet-Drafts@ietf.org Mon Nov 8 21:45:05 2010 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 05E2B3A6954; Mon, 8 Nov 2010 21:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.036 X-Spam-Level: X-Spam-Status: No, score=-102.036 tagged_above=-999 required=5 tests=[AWL=0.563, BAYES_00=-2.599, 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 c+XltAYrYrW3; Mon, 8 Nov 2010 21:45:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EAD6A3A6933; Mon, 8 Nov 2010 21:45:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no Message-ID: <20101109054501.24266.38329.idtracker@localhost> Date: Mon, 08 Nov 2010 21:45:01 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-sec-flows-05.txt 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: Tue, 09 Nov 2010 05:45:05 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Example call flows using Session Initiation Protocol (SIP) security mechanisms Author(s) : C. Jennings, et al. Filename : draft-ietf-sipcore-sec-flows-05.txt Pages : 66 Date : 2010-11-08 This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-sec-flows-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-sec-flows-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-08214402.I-D@ietf.org> --NextPart-- From HKaplan@acmepacket.com Mon Nov 8 21:55:01 2010 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 F39293A694E for ; Mon, 8 Nov 2010 21:55:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.84 X-Spam-Level: X-Spam-Status: No, score=-0.84 tagged_above=-999 required=5 tests=[AWL=-0.945, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_74=0.6, 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 kWHAbCCFzmA8 for ; Mon, 8 Nov 2010 21:55:00 -0800 (PST) Received: from ETMail2.acmepacket.com (unknown [216.41.24.9]) by core3.amsl.com (Postfix) with ESMTP id 8F76D3A6960 for ; Mon, 8 Nov 2010 21:54:59 -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; Tue, 9 Nov 2010 00:55:19 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 9 Nov 2010 00:55:18 -0500 From: Hadriel Kaplan To: Paul Kyzivat Date: Tue, 9 Nov 2010 00:55:14 -0500 Thread-Topic: [sipcore] Yet more comments on rfc4244bis-02 Thread-Index: Act/0q+9HRT0AcexQK+L0r+gyDxRgA== Message-ID: <6DE23D04-6C4C-4F58-BBD5-8FB602930BCF@acmepacket.com> References: <4CD7CF13.5000005@cisco.com> In-Reply-To: <4CD7CF13.5000005@cisco.com> 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: AAAAAQAAAUA= Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Yet more comments on 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: Tue, 09 Nov 2010 05:55:01 -0000 On Nov 8, 2010, at 5:21 AM, Paul Kyzivat wrote: > Why do you think that Privacy:none is not important for H-I? > IIUC, Privacy:none is a way for a caller to get identity info passed e2e > even if there are SPs along the path that wish to block things. >=20 > Why would that not apply to H-I as well? I may want the callee to know > the history of the call even if my SP does not wish that. I can't comment on the "none" setting bit, but expecting it to prevent an S= P from anonymizing (or more likely, removing) H-I entries is silly. Most o= f the H-I entries have absolutely nothing to do with the *caller*, and in f= act are far more revealing about the SP's equipment/nodes than revealing an= ything about the caller's identity. Even *allowing* a UAC to tell some downstream node what the downstream node= can/cannot reveal about the downstream node is a joke. Think of it this way: let's say we were talking about email SMTP, and there= were some SMTP header named "Privacy" which you could set to tell your Cis= co email server to anonymize your name from the email you send out. Imagin= e that the Cisco Email server was actually a cluster of decomposed roles in= separate physical boxes, with some internal SMTP message passing between t= he boxes. (like one did storage, one did virus checking access, one did spa= m filtering, one was for external SMTP, etc.) Between each of these system= s they add a History-Info header. Now imagine the Cisco IT department remo= ves these H-I headers when an email gets sent out of Cisco, in order to not= reveal this internal design and addresses. Do you really think Cisco's IT= department would allow your email client to tell their servers to expose t= hese headers??=20 -hadriel From shida@ntt-at.com Mon Nov 8 22:23:40 2010 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 BFA193A6894 for ; Mon, 8 Nov 2010 22:23:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.115 X-Spam-Level: X-Spam-Status: No, score=-102.115 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 F+2h3E+lGzAd for ; Mon, 8 Nov 2010 22:23:37 -0800 (PST) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.93.154.35]) by core3.amsl.com (Postfix) with SMTP id 753363A6810 for ; Mon, 8 Nov 2010 22:23:28 -0800 (PST) Received: (qmail 19123 invoked from network); 9 Nov 2010 06:24:48 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway14.websitewelcome.com with SMTP; 9 Nov 2010 06:24:48 -0000 Received: from [130.129.116.143] (port=52871 helo=dhcp-748f.meeting.ietf.org) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PFhcP-0001Li-Ae; Tue, 09 Nov 2010 00:23:46 -0600 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Tue, 9 Nov 2010 15:23:47 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: "Elwell, John" 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" Subject: Re: [sipcore] Understanding Privacy: history invoked by UAS 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: Tue, 09 Nov 2010 06:23:40 -0000 Hi John; In practice, if C cares about its privacy, there should be=20 a priori arrangement with the service provider or=20 configuration in proxy to withhold its identity. This will allow the proxy sending the 4xx which sets the hi-entry=20 to ensure privacy is applied by setting escaped privacy header=20 or Privacy:header.=20 Regards Shida=20 On Nov 9, 2010, at 11:32 AM, Elwell, John wrote: > Suppose a request from A is targeted initially at B, this is mapped to = C, and then to registered contact D. The UAS (D) puts Privacy: history = in the response, and therefore prevents A learning about C and D. Fine. >=20 > Now, supposing D is not registered at the time, i.e., there is no = registered contact for C. This results in a 4xx response to A. How do we = ensure that the identity of C is not disclosed to A, in line with what = is achieved when D is registered? >=20 > John >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From shida@ntt-at.com Mon Nov 8 22:28:09 2010 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 00E7F3A67AD for ; 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 ; 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 ; 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 ) 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 In-Reply-To: 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: <4CD6C020.7030603@cisco.com><4CD7555F.30609@cisco.com> <9886E5FCA6D76549A3011068483A4BD406D5CF8B@S4DE8PSAAQB.mitte.t-com.de> To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=20 we are using it in our network and it is providing us with most of=20 the functionality that we want, and with revised RFC4244bis=20 according to guys actually implementing the stuff, it satisfies=20 all the requirements we have so far. I agree that RFC4244 is not very simple, I think anybody that had=20 to implement RFC4244 had a very difficult time trying to get the=20 outcome they wanted. But I know at some country including Japan,=20 it is the country wide standard used, and revising the spec in=20 non-backword compatible way is going to be a nightmare.=20 I believe that RFC4244bis does clarify a lot of things that required=20 guess work and it is a huge improvement over the original. Regards Shida On Nov 9, 2010, at 9:42 AM, = wrote: > Hi, >=20 > 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=3Dxxx" 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?? >=20 > 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. >=20 > 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. =20 > If we have the opportinity to fix inconsistencies, lack of clearness, = even with no backward compatibility ; I'm in ! >=20 > 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). >=20 > 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)... >=20 > 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 =3D the Retargeting). In general, we need = to know which entity do what.=20 >=20 >=20 > Whatever the one chosen, it has to be clearly mentionned, not only = with "associated to the hi-retargeted-to-uri" not saying which one.=20 >=20 >=20 > Marianne >=20 >> -----Message d'origine----- >> De : sipcore-bounces@ietf.org=20 >> [mailto:sipcore-bounces@ietf.org] De la part de R.Jesske@telekom.de >> Envoy=E9 : lundi 8 novembre 2010 15:53 >> =C0 : HKaplan@acmepacket.com; shida@ntt-at.com >> Cc : sipcore@ietf.org >> Objet : Re: [sipcore] Reason as a parameter rather than=20 >> anescapedheader (was Comments on draft-ietf-sipcore-rfc4244bis-02) >>=20 >> Hi, >> we have already a mechanism putting a "cause" into the URI=20 >> which is the target. >> RFC4458 describes this for diverting reasons.=20 >> So it is a own header used for History Info no new definition=20 >> is needed. >> And so this mechanism could be extended by the proposed=20 >> values in=20 >> http://tools.ietf.org/html/draft-mohali-sipcore-reason-extensi >> on-application-00 and other needed.=20 >>=20 >> So in final the Reason is included within the "retargeting"=20 >> URI based on the received response. >> And the cause as defined in RFC4458 is in the target URI. >>=20 >> Comments?=20 >>=20 >> Best Regards >>=20 >> Roland=20 >>=20 >> -----Urspr=FCngliche Nachricht----- >> Von: sipcore-bounces@ietf.org=20 >> [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=20 >> escapedheader (was Comments on draft-ietf-sipcore-rfc4244bis-02) >>=20 >>=20 >> I know this is beating a dead horse, but breaking backwards=20 >> compatibility for Hist-Ifno may be a GOOD thing. >> Seriously. Afaict, "legacy" H-I is broken. It didn't solve=20 >> people's problems, in an interoperable fashion. That's why=20 >> we needed 4244bis to begin with, ain't it? >>=20 >> In fact, start with a new header name, if need be. >> To be transparent, we can name the new header=20 >> "Possible-Targets-Lottery:" and if you guess the right "real"=20 >> target from the list, you win some award. :) >>=20 >> -hadriel >>=20 >> On Nov 8, 2010, at 12:48 AM, Shida Schubert wrote: >>=20 >>>=20 >>> I don't agree. This is going to completely break backward=20 >>> 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=20 >> bis as an opportunity to get this right, even if we have to=20 >> grandfather some existing mechanism. The Mohali draft is=20 >> evidence that the present mechanism causes further problems=20 >> 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=20 >> 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=20= >>>>>> URI parameter. It is a SIP header field that is escaped=20 >> in the URI=20 >>>>>> for compactness. >>>>>=20 >>>>> I don't think there is any real confusion. Its just that the=20 >>>>> terminology is awkward. We have parameters to headers,=20 >> and we have=20 >>>>> headers that are parameters to URIs. >>>>>=20 >>>>>> In earlier versions, we had a separate parameter in the SIP=20 >>>>>> History-Info header for Reason, but Rohan suggested to >>>>> just escape >>>>>> the existing Reason header in the URI so as not to=20 >> redefine Reason=20 >>>>>> parameters. >>>>>=20 >>>>> I even remember him making that suggestion. Too bad he=20 >> isn't around=20 >>>>> so we can wring his neck. I thought it was a hack at the=20 >> time, but=20 >>>>> 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=20 >> and the new)=20 >>>>>> . The idea of capturing the "new" is so that you >>>>> already have >>>>>> the old entry when you do the retarget, noting that when=20 >> an entity=20 >>>>>> goes to process History-Info, the last entry isn't typically=20 >>>>>> useful, since it should always be the URI in the=20 >> received request. =20 >>>>>> 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=20 >> were the right=20 >>>>>> thing to do due to backwards compatibility. >>>>>=20 >>>>> So then we allow it continue to metastasize, e.g. by defining new=20= >>>>> Reason values that aren't ever expected to be used in=20 >> requests, and=20 >>>>> 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=20= >>>>>>>> confusing. I can change all instances to refer to "escape a=20 >>>>>>>> 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=20 >> response,=20 >>>>>>>>> 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=20 >>>>>>>> hi-targeted-to-URI is being retargeted due to the=20 >> response. It=20 >>>>>>>> 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=20= >>>>>>>> "current" hi-entry. It's added to the previous. The=20 >> sentences=20 >>>>>>>> following the one that you highlight are intended to say >>>>> just that. >>>>>>>> That's why the term "associated" is loosely used=20 >> because the next=20 >>>>>>>> sentences are the normative part. So, really, that=20 >> first sentence=20 >>>>>>>> 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.=20 >> That isn't=20 >>>>>>> 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=20 >>>>>>> draft-mohali-sipcore-reason-call-forwarding which is >>>>> defining new reason >>>>>>> codes which are intended specifically for use with H-I, without=20= >>>>>>> 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 >>=20 >> _______________________________________________ >> 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 >>=20 From jmpolk@cisco.com Tue Nov 9 00:03:06 2010 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 DCBFE3A6886 for ; Tue, 9 Nov 2010 00:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 yI6I3dIw1J5J for ; Tue, 9 Nov 2010 00:03:04 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id B6ED53A67E5 for ; Tue, 9 Nov 2010 00:03:04 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHqP2EyrR7Ht/2dsb2JhbACiHnGhAptmgnyCTgSEWA X-IronPort-AV: E=Sophos;i="4.59,174,1288569600"; d="scan'208";a="616910939" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 09 Nov 2010 08:03:28 +0000 Received: from jmpolk-wxp01.cisco.com ([10.21.73.191]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA983QR5020561; Tue, 9 Nov 2010 08:03:27 GMT Message-Id: <201011090803.oA983QR5020561@sj-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 09 Nov 2010 02:03:25 -0600 To: "Elwell, John" , "sipcore@ietf.org" From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] More comments on location-conveyance-04 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: Tue, 09 Nov 2010 08:03:06 -0000 John Thanks for the review, you caught a lot of nits that were oversights from the recent text cut-down. I'll go through them as best I can in-line At 02:25 AM 11/5/2010, Elwell, John wrote: >1. General >This document seems to lack procedures sections for a UAC, a proxy >and a UAS. Some of the procedures can be deduced from material in >section 4 and elsewhere, but it is normal, for any SIP extension, to >specify procedures for specific entities. [jmp] this has been the normal format in the past, and was as well up until the -02 of this SIPCORE doc, but changed with the massive text cut-down in -03 due to at least two factors - not simply having one operational behavior example (diagram) to work from. You'll see that section 3 has 4 equally useful examples that end up covering most, if not all, of this operational behavior taken 1 example at a time instead of one SIP entity at a time. - the second factor was my new co-author's bent on seriously reducing the paraphrasing or what other RFCs have said, sometimes dangerously so (i.e., by not exactly matching what was written in those other RFCs). >2. As I have recently said about rfc4244bis, we should use "header >field" instead of "header" where appropriate throughout the >document. My reasoning has already been stated on this list in the >context of rfc4244bis. [jmp] we'll get that part right >3. As I have recently said about rfc4244bis, we should avoid using >the passive voice in normative statements. A normative statement >forces us to make it clear which entity is required to comply with >the statement. I have not picked out specific instances, but there are many. [jmp] we'll get that part right, plus correct all the nits through your #9 below >4. Abstract: >"where SIP > intermediaries make routing decisions based upon the location of the > user agent client." >I think "user agent client" should be changed to "target". > >5. Section 1: >"Location Objection" >Sustained! Change it to "Location Object". > >6. Section 2: >"to deliver URIs point > to " >Change to: >"to deliver URIs pointing > to " > >7. Section 3.2: >"the LS provides the location value > to Bob instead of Alice directly." >I think it should say: >"the LS provides the location value > to Bob directly instead of to Alice for conveyance to Bob." > >8. Section 3.3: >"In this case, the intermediary acts as a Location > Recipient." >This is effectively a repetition of the 3rd sentence in the >paragraph - delete. > >9. Section 3.3: >"In this case, the intermediary does not act as a Location > Recipient." >It might be worth pointing out that this case is identical to that in 3.1. [jmp] sure >10. Section 3.4: >"Thus, > it must inform her user agent what location she should include in > any subsequent SIP request that contains her location. " >Change "she should include" to "it should include". [jmp] sure >11. Section 3.4: >"In these > cases, the intermediary can reject " >Change "In these cases" to "In this case", because I think there is >only one case described in the preceding text. [jmp] sure >12. Section 3.4: >"the intermediary can reject Alice's request, through the SIP > response, convey to her the best way to repair the request" >Add "and" after "Alice's request" (before the comma). New text: >"the intermediary can reject Alice's request and, through the SIP > response, convey to her the best way to repair the request" [jmp] sure >13. Section 3.4: >"If desired, intermediaries > may furthermore allow both Alice's internally generated location, as > well as the SIP intermediary's determination of where Alice, to > appear in the same SIP request (the resubmitted one), and permit > that to be forwarded to Bob. This case is discussed in more detail > in section 4.2 of this document." >If I understand correctly, this case is also covered in 3.3. There >is no need to cover the same case in both sub-sections. Delete one of them. [jmp] sure, probably take out what's in 3.4 >14. Section 3.4: >"act a B2BUA " >Change to: >"act as a B2BUA " [jmp] sure >15. Section 4.1: >I am aware of separate discussions ongoing concerning the ABNF, but >depending on what we end up with, we should ensure that the >following error is somehow fixed: >"routing-param = "routing-allowed" EQUAL "yes" / "no"" >This omits the semicolon in front of "routing-allowed". According to >the examples (which I think are correct) there should be a semicolon. [jmp] we'll fix the ABNF for each header once we figure out what the parameters need to be, more on that later. >16. Section 4.1: >"not appropriate for usage the SIP Geolocation > header." >Change to: >"not appropriate for usage in the SIP Geolocation > header." [jmp] sure >17. Section 4.1: >"Other URI schemas used in the location URI MUST be reviewed against > the RFC 3693 [RFC3693] criteria for a Using Protocol." >Who must conduct this review? Use active voice. >I assume we are talking about any scheme for use under absoluteURI, >since there is no other extension mechanism. [jmp] this is going to be addressed in something Jon is going to propose very soon on the list before the Thursday meeting, so stay tuned for that >18. Section 4.1: >"However, if a SIP intermediary were to add location, even if > location was not previously present in a SIP request, that SIP > intermediary is fully responsible for addressing the concerns of any > 424 (Bad Location Information) SIP response it receives about this > location addition, and MUST NOT pass on (upstream) the 424 response." >How does the SIP intermediary know that the 424 refers to the added >location, as opposed to the original location? If I understand >correctly, a Geolocation header field in a 424 response denotes a >corrected location, rather than a location in error, so comparison >of sent and received Geolocation header fields would not work. [jmp] to quote Jon's response to me about this [JFP] This is one of many tangles introduced by the multiple location object problem. We could either: a) add tons of cruft to support this, or, b) merely say this is another defect of the poor design of sending multiple location objects. The implication of 424 is that the recipient has not gotten the location they need. The guidance here is mainly for a case where the UAC did not provide location itself. >19. Section 4.1: >"If a routing-allowed parameter is parsed as set to "=yes", an > implementation MUST parse the rest of the SIP headers for another > instance of the Geolocation header value to determine if there is > another instance of the routing-allowed parameter set to "=no". If > this is the case, the behavior MUST be to process the "=no" > indication only, and ignore the "=yes"." >This is a rather unusual requirement, and may be obviated by >proposed changes to the ABNF. If not, my concern is that SIP parsers >do not necessarily look out for conflicting bits of information, and >might just make the first or last instance available to the >application. Also it seems a bit unnecessary to specify this, since >it is forbidden to add a second routing-allowed parameter, so if two >occur it is an invalid message, and perhaps unreasonable to expect a >defined behaviour. [jmp] this is probably my poor attempt at being doubly sure the default behavior of "=no" was adhered to. This really isn't necessary. That said, if there is only ever one Geolocation header field in a SIP request, this really does go away. >20. Section 4.1: >"The following table extends the values in Tables 2 and 3 of RFC 3261 > [RFC3261]." >I thought there was an agreement in the WG not to maintain tables 2 >and 3 in RFC 3261. [jmp] hmmm... missed that memo >21. Section 4.1: >"The Geolocation header field MAY be included in any one of the > optional requests by a UA. " >If we get rid of the table, in accordance with the previous comment, >this should say: >"The Geolocation header field MAY be included in any request except >ACK or CANCEL and in any 424 responses to such requests." [jmp] if we get rid of the table, this makes sense to me >22. Section 4.2: >"All > respects of the Geolocation and Geolocation-Error headers and > PIDF-LO(s) MUST remain unchanged, never added to or deleted." >This should say: >"Geolocation and Geolocation-Error header fields and > PIDF-LO body parts MUST remain unchanged, never added to or deleted." [jmp] sure >23. Section 4.2: >"In this scenario, > a SIP intermediary is informing the upstream UA which location to > include in the next SIP request. " >Two scenarios are mentioned in the preceding text. Should say: >"In the latter scenario..." > >24. Section 4.3: >"Geolocation-Error = "Geolocation-Error" HCOLON > locationErrorValue > locationErrorValue = location-error-arg > location-error-arg = location-error-code > *(SEMI location-error-params)" >The is an unnecessary intermediate step here. Why not: >"Geolocation-Error = "Geolocation-Error" HCOLON > locationErrorValue > locationErrorValue = location-error-code > *(SEMI location-error-params)" [jmp] this is an artifact of the -02 to -03 cut-down that I didn't catch. will get it now. >25. Section 4.3: >"The following table extends the values in Table 2&3 of RFC 3261 > [RFC3261]." >Same comment as for the previous table. The table could be deleted. >This would require a small change to the sentence after the table:, >e.g.: "The Geolocation-Error header field MAY be included in any >response to a SIP request containing a Geolocation header field locationValue." [jmp] sure >26. Section 4.3: >If the request contains more than one locationValue, can there be >more than one Geolocation-Error header field in the response, if >more than one location is in error? However, my earlier comment >about associating a Geolocation-Error with a particular >locationValue would still be an issue. [jmp] this really gets sticky, because as I see it, this means there needs to be a inserter= and an inserted-by= entities introduced (taken out in -03), which creates a whole lot of cruft that really makes this doc just hard to handle. >27. Section 4.3: >"The SIP requests included in table 2 above are the > ones allowed to optionally contain the Geolocation header field (see > section 4.1)." >Table 2 as it stands doesn't list any requests - only responses. >However, if my earlier comment about removing the table is accepted, >this sentence would need attention anyway. In fact it appears to be >redundant - I don't think it conveys any new information. Delete it. [jmp] sure >28. Section 4.3: >"The following subsections provide an initial list of location > based errors for any SIP non-100 response" >I don't see any subsections. [jmp] sure >29. Section 4.3: >"Geolocation-Error: 200 "Retry Location Later ..." >Should this be accompanied by a Retry-After header field? Under what >circumstances might an LR determine that it can't use the present >location but could use an updated location sometime in the future? I >fail to see the motivation for this error code. [jmp] this is from a combining of the old "retry with same location data later (because the LR is busy)" and "retry with new or refreshed location data" error types. Yeah, I understand we probably should include a Retry-After header field, and just didn't get that into the -04 rev. It needs to be there in the final version though. >30. Section 4.3: >"with device updated > location" >I assume this means the device must update the location. But how >does the LR know that the location came from the device, as opposed >to some other location generator? Suggest delete "device"? [jmp] yeah, you're probably right here, this is a little too cavalier for a specification. >31. Section 4.3: >"If the LS wants this message > processed without this permission reset, it MUST choose another > logical path (if one exists)." (two instances) >What is meant by "another logical path"? [jmp] one that avoids this SIP server or chain of servers - because, if the permission isn't reset, it'll be matched with a failure repeatedly, right? >32. Section 4.4: >"This document creates and registers with the IANA one new option > tag: "geolocation". This option tag is to be used, as defined in > [RFC3261], in the Require, Supported and Unsupported header fields." >There should be some statement about what the option tag means, >i.e., support for the SIP extensions specified in this document. >However, I have a more fundamental concern. There are no procedures >anywhere for using this option tag in Supported, Unsupported or >Require. If it is not used, why is it needed? Inclusion of the >Geolocation header field implies support by the UAC. Sending a 424 >or Geolocation-Error implies support by the UAS. Are there other >cases where support needs to be known (e.g., in a request without >Geolocation or in a 200 response without Geolocation-Error)? If we >don't have any uses for the option tag, why define it? [jmp] this is also going to be addressed in that separate message to the list by Jon as he bakes his new idea about all this. >33. Section 4.5: >"In the case where a location recipient sends a 424 response and > wishes to communicate suitable location by reference rather than by > value, the 424 MUST include a content-indirection body per RFC 4483." >Why is this needed? A 424 response can contain a Geolocation header >field containing the reference. [jmp] it's an artifact from a pre-03 version that needs to be addressed still. >34. Section 4.6: >"The following is part of the discussion started in Section 3 ..." >It seems to be more than a continuation of a discussion, it seems to >be specification. [jmp] fair, we'll address this >35. Section 5.1: >"the SIP request uses a sips-URI [RFC3261]" >Would RFC 5630 be a more appropriate reference? [jmp] neither Jon nor I think so >36. Section 5.1: >" An assumption can be > made that SDP is the other message body part. " >This is just an example. We don't need tell the reader to make an >assumption - just state that in this example SDP is the other body part. [jmp] fair >37. "The "cid:" eases > message body parsing by disambiguating the MIME body that contains > the location information associated with this request." >Easing parsing and disambiguating are two different properties - the >one doesn't rely on the other. Should say "eases message body >parsing and disambiguates multiple parts of the same type". [jmp] yeah, to be fixed >38. Section 5.1: >"Any > node wanting to know where user "target123" is would subscribe to > that user at server5 to dereference the sips-URI" >I think this should say: >"Any node wanting to know where the target is located would >subscribe to the SIP presence event package [RFC 3856) at >sips:target123@server5.atlanta.example.com" [jmp] right, poorly worded >39. In the same sentence: >"(see Figure 3 in > section 3 for this message flow )" >This probably should be Figure 2. However, neither Figure 2 nor >Figure 3 shows the message flow (SUBSCRIBE/200/NOTIFY/200). [jmp] yeah, they're at a higher level (not layer) by showing the dereference as a single message exchange, and not the pair/pair exchange, which is directly related to which protocol does the dereferencing (e.g., HTTP is 2 messages, and SIP is 4 messages) >40. Section 6: >"Implementations of this SIP location conveyance mechanism MUST > adhere to the guidance given in RFC3693 and its successors " >I assume by "and its successors" we are specifically referring to >[ID-GEOPRIV-ARCH]. However, according to text earlier in the >paragraph, and according to the architecture draft itself, it only >updates RFC 3693, it is not a successor. So either say "all updates" >or specifically mention the architecture draft. [jmp] again, this was a rounding of a corner that shouldn't have been, sorry, it will be fixed >41. Section 8.1: >"The SIP Geolocation Header Field is created by this document, with > its definition and rules in Section 4.1 of this document, and should > be added to the IANA sip-parameters registry, in the portion titled > "Header Field Parameters and Parameter Values" ." >This provides a single IANA instruction where really it should >provide two. It should update the Header Fields registry with >Geolocation and should update the Header Field Parameters and >Parameter Values registry with routing-allowed. [jmp] sure >42. Section 8.2. >"The SIP option tag "geolocation" is created by this document, with > the definition and rule in Section 4.4 of this document, to be added > to the IANA sip-parameters registry." >Assuming we retain the option tag (see an earlier comment), it >should be mentioned that it is the Options Tags registry that is to >be added to. [jmp] fair, but I think Jon's coming proposal will also affect this. >43. Section 8.3: >It should be mentioned that it is the Response Codes registry that >is added to. [jmp] sure >44. Section 8.3: >"Response code: 424 (recommended number to assign) > Default reason phrase: Bad Location Information " >It should be registered as simply "424 Bad Location Information". [jmp] ok, I guess this is an old habit of proposing a code number and not assuming the number an ID picked also gets picked by IANA. That said, I can make this change. >45. Section 8.4: >"The SIP Geolocation-error header field is created by this document, > with its definition and rules in Section 4.3 of this document, to be > added to the IANA sip-parameters registry, in the portion titled > "Header Field Parameters and Parameter Values" >Same comment as on 8.1. [jmp] ok >46. Section 8.5. >We need to state what the policy is for adding new values to the >error codes registry. [jmp] I believe right now I have up in section 8 part that a standards track doc is needed to extend any of this. >47: "8.6 IANA Registration of Location URI Schemes" >Do we really need a registry for this? URI scheme names are already >registered elsewhere. Also the ABNF doesn't provide an extensibility >mechanism. Or is "absoluteURI" meant to be the extension mechanism? >However, there is nothing in section 4 that limits schemes used >under absoluteURI to being only those defined in this registry, so >it is unclear what purpose the registry serves. [jmp] again, this will likely be addressed in Jon's new proposal about URI schemes and option tags. James >John > > > > > > > > > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From adam@nostrum.com Tue Nov 9 01:10:03 2010 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 2A1D63A68D7 for ; Tue, 9 Nov 2010 01:10:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.517 X-Spam-Level: X-Spam-Status: No, score=-102.517 tagged_above=-999 required=5 tests=[AWL=0.083, BAYES_00=-2.599, SPF_PASS=-0.001, 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 JSilWDKgX3qc for ; Tue, 9 Nov 2010 01:10:01 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 046ED3A68AB for ; Tue, 9 Nov 2010 01:10:00 -0800 (PST) Received: from dhcp-48c3.meeting.ietf.org (dhcp-48c3.meeting.ietf.org [130.129.72.195]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oA99ALVW083369 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Tue, 9 Nov 2010 03:10:23 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4CD90FFC.40502@nostrum.com> Date: Tue, 09 Nov 2010 17:10:20 +0800 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.72.195 is authenticated by a trusted mechanism) Subject: [sipcore] Summary: number of location headers X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 09:10:04 -0000 [as chair] I just wanted to summarize where it looks like the discussion ended up on whether we constrain the number of location header fields in a SIP message. From my review of the discussion, I believe that four people have weighed in on the topic to voice support for an arbitrary number of location headers (albeit with a implementation warning that doing so is not advisable): Martin Thompson: http://www.ietf.org/mail-archive/web/sipcore/current/msg03576.html Richard Barnes: http://www.ietf.org/mail-archive/web/sipcore/current/msg03580.html Keith Drage: http://www.ietf.org/mail-archive/web/sipcore/current/msg03600.html Hannu Hietalahti: http://www.ietf.org/mail-archive/web/sipcore/current/msg03619.html And two people have agreed to go along with that direction, with expressed reservations: Jon Peterson: http://www.ietf.org/mail-archive/web/sipcore/current/msg03601.html James Polk: http://www.ietf.org/mail-archive/web/sipcore/current/msg03603.html If any other working group participants have comments on this topic, they are encouraged to make them quickly. Lacking any further input, the authors will be instructed to revise the document to allow an arbitrary number of location header fields, with an accompanying warning that doing so is not recommended. /a From john.elwell@siemens-enterprise.com Tue Nov 9 06:48:13 2010 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 BA63B28C0E8 for ; Tue, 9 Nov 2010 06:48:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.495 X-Spam-Level: X-Spam-Status: No, score=-102.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, 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 PsbNu6XVpeH5 for ; Tue, 9 Nov 2010 06:48:12 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 46DC728C0D9 for ; Tue, 9 Nov 2010 06:48:11 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2234715; Tue, 9 Nov 2010 15:48:35 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id E9CEB1EB82AB; Tue, 9 Nov 2010 15:48:35 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 9 Nov 2010 15:48:35 +0100 From: "Elwell, John" To: "James M. Polk" , "sipcore@ietf.org" Date: Tue, 9 Nov 2010 15:48:31 +0100 Thread-Topic: [sipcore] More comments on location-conveyance-04 Thread-Index: Act/5JpEcUK7kFtlSVeC4kKsTnZfogAL0Zhw Message-ID: References: <201011090803.oA983QR5020561@sj-core-1.cisco.com> In-Reply-To: <201011090803.oA983QR5020561@sj-core-1.cisco.com> 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 Subject: Re: [sipcore] More comments on location-conveyance-04 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: Tue, 09 Nov 2010 14:48:13 -0000 James, Some further remarks below (rest removed):=20 > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com]=20 > Sent: 09 November 2010 08:03 > To: Elwell, John; sipcore@ietf.org > Subject: Re: [sipcore] More comments on location-conveyance-04 >=20 > John >=20 > Thanks for the review, you caught a lot of nits that were oversights=20 > from the recent text cut-down. I'll go through them as best=20 > I can in-line >=20 > At 02:25 AM 11/5/2010, Elwell, John wrote: > >1. General > >This document seems to lack procedures sections for a UAC, a proxy=20 > >and a UAS. Some of the procedures can be deduced from material in=20 > >section 4 and elsewhere, but it is normal, for any SIP extension, to=20 > >specify procedures for specific entities. >=20 > [jmp] this has been the normal format in the past, and was as well up=20 > until the -02 of this SIPCORE doc, but changed with the massive text=20 > cut-down in -03 due to at least two factors >=20 > - not simply having one operational behavior example (diagram) to=20 > work from. You'll see that section 3 has 4 equally useful examples=20 > that end up covering most, if not all, of this operational behavior=20 > taken 1 example at a time instead of one SIP entity at a time. >=20 > - the second factor was my new co-author's bent on seriously reducing=20 > the paraphrasing or what other RFCs have said, sometimes dangerously=20 > so (i.e., by not exactly matching what was written in those=20 > other RFCs). [JRE] Section 3 comprises only examples. There is no normative language in = section 3. In fact, as far as I can see, the only normative language is in = section 4, with a couple of exceptions in sections 6 and 7. Section4 does n= ot refer normatively to section 3 (and I don't think it should). What this = means is that somebody implementing this just has to obey the MUSTs (and pe= rhaps the SHOULDs) in section 4 (plus the couple in sections 6 and 7). So i= f there is anything we need a UAC, UAS or intermediary to do that is not sp= ecified in those sections, it most likely will not be done. If the group is= happy that everything is covered in section 4 (+ section 6 and 7), then fi= ne, but I am doubtful. It certainly doesn't follow conventional practice fo= r SIP standards track RFCs. > >18. Section 4.1: > >"However, if a SIP intermediary were to add location, even if > > location was not previously present in a SIP request, that SIP > > intermediary is fully responsible for addressing the=20 > concerns of any > > 424 (Bad Location Information) SIP response it receives=20 > about this > > location addition, and MUST NOT pass on (upstream) the=20 > 424 response." > >How does the SIP intermediary know that the 424 refers to the added=20 > >location, as opposed to the original location? If I understand=20 > >correctly, a Geolocation header field in a 424 response denotes a=20 > >corrected location, rather than a location in error, so comparison=20 > >of sent and received Geolocation header fields would not work. >=20 > [jmp] to quote Jon's response to me about this >=20 > [JFP] This is one of many tangles introduced by the multiple location=20 > object problem. We could either: a) add tons of cruft to support=20 > this, or, b) merely say this is another defect of the poor design of=20 > sending multiple location objects. The implication of 424 is that the=20 > recipient has not gotten the location they need. The guidance here is=20 > mainly for a case where the UAC did not provide location itself. [JRE] We at least need to say something about it. > >20. Section 4.1: > >"The following table extends the values in Tables 2 and 3 of RFC 3261 > > [RFC3261]." > >I thought there was an agreement in the WG not to maintain tables 2=20 > >and 3 in RFC 3261. >=20 > [jmp] hmmm... missed that memo [JRE] The rfc4244bis draft from sipcore is already in alignment with that d= ecision, so it makes sense to apply it to location-conveyance too. > >26. Section 4.3: > >If the request contains more than one locationValue, can there be=20 > >more than one Geolocation-Error header field in the response, if=20 > >more than one location is in error? However, my earlier comment=20 > >about associating a Geolocation-Error with a particular=20 > >locationValue would still be an issue. >=20 > [jmp] this really gets sticky, because as I see it, this means there=20 > needs to be a inserter=3D and an inserted-by=3D entities introduced=20 > (taken out in -03), which creates a whole lot of cruft that really=20 > makes this doc just hard to handle. [JRE] As I said above, we at least need to say something about this. > >31. Section 4.3: > >"If the LS wants this message > > processed without this permission reset, it MUST choose another > > logical path (if one exists)." (two instances) > >What is meant by "another logical path"? >=20 > [jmp] one that avoids this SIP server or chain of servers - because,=20 > if the permission isn't reset, it'll be matched with a failure=20 > repeatedly, right? [JRE] But how does the LS choose another path? And do we mean UAC rather th= an LS? > >35. Section 5.1: > >"the SIP request uses a sips-URI [RFC3261]" > >Would RFC 5630 be a more appropriate reference? >=20 > [jmp] neither Jon nor I think so [JRE] I can don't mind either way - was just asking the question. John= From ian_elz@yahoo.co.uk Tue Nov 9 09:41:33 2010 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 0A7DE3A6A11 for ; Tue, 9 Nov 2010 09:41:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.849 X-Spam-Level: X-Spam-Status: No, score=-1.849 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] 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 397QtxdNSS0W for ; Tue, 9 Nov 2010 09:41:30 -0800 (PST) Received: from nm3-vm1.bullet.mail.ird.yahoo.com (nm3-vm1.bullet.mail.ird.yahoo.com [77.238.189.212]) by core3.amsl.com (Postfix) with SMTP id 529393A682F for ; Tue, 9 Nov 2010 09:41:30 -0800 (PST) Received: from [77.238.189.54] by nm3.bullet.mail.ird.yahoo.com with NNFMP; 09 Nov 2010 17:41:51 -0000 Received: from [212.82.108.115] by tm7.bullet.mail.ird.yahoo.com with NNFMP; 09 Nov 2010 17:41:51 -0000 Received: from [127.0.0.1] by omp1024.mail.ird.yahoo.com with NNFMP; 09 Nov 2010 17:41:51 -0000 X-Yahoo-Newman-Property: ymail-5 X-Yahoo-Newman-Id: 315970.94426.bm@omp1024.mail.ird.yahoo.com Received: (qmail 26287 invoked by uid 60001); 9 Nov 2010 17:41:51 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1289324511; bh=+ITzauehHJ3yE0L/6N8i4PUr4a9KoLIIClaq7FKa+js=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=uNKN/SKtjudu0zs5koutB/IDrTi1Ivw4/woMu2VgRFibRDaDko9STvgOTie/kG1jwiDW7RsMZ8ncJbXxgsJGT/v0xEh9WTkCYoB5iv5rkN0ccu8bbaulIRB5upi8zZa6wch9chrJvfYqt740EDcP+nB5v9CaCgQT/ncFBvxFrUQ= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=LDTZwU03uIEqpQ1pDPDu3VULT46KMGI/pnS8c2bdQ0ZamMcssWezn3LcOFKuIejTqapMLweulWCX9M+HFWH0Ai0Qn4pFHUibuDGpGYZzD2GGSFtuY3oza8CTAEiGJu89WejeYcnWnDkYFuhiuSvjFzWEJr4e56YKHglgE/B6ySM=; Message-ID: <231164.26050.qm@web29108.mail.ird.yahoo.com> X-YMail-OSG: 0VGmvA4VM1kVnxqf08fCy9F0xl1MVgws6FPTFM6m.hGIGUd BKlz2PKIv Received: from [86.20.66.247] by web29108.mail.ird.yahoo.com via HTTP; Tue, 09 Nov 2010 17:41:50 GMT X-Mailer: YahooMailWebService/0.8.107.284920 Date: Tue, 9 Nov 2010 17:41:50 +0000 (GMT) From: Ian Elz To: Paul Kyzivat MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: sipcore@ietf.org Subject: Re: [sipcore] Yet more comments on rfc4244bis-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Ian Elz List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 17:41:33 -0000 Paul,=0A=0AAs a lot of this functionality is performed by a B2BUA (yes thos= e dreaded things again) the To header will be modified in the forwarded INV= ITE. This allows the forwarding user to remain anonymous to the final desti= nation.=0A=0AThe H-I is passed through so that inter-working with ISUP dive= rting information can occur if necessary.=0A=0AIan=0A=0A----- Original Mess= age -----=0AFrom: "Paul Kyzivat" =0ATo: sipcore@ietf.or= g=0ASent: Tuesday, 9 November, 2010 12:10:46 AM=0ASubject: Re: [sipcore] Ye= t more comments on rfc4244bis-02=0A=0A=0A=0AOn 11/8/2010 1:17 PM, Ian Elz w= rote:=0A> Hadriel,=0A>=0A> Roland missed one other case in his reply.=0A>= =0A> If I divert a call I may want my identity to be private even if the or= iginal caller allows his identity to be presented; i.e. I don't want the fi= nal destination of the call to know the identity of the diverting party.=0A= =0AWon't your identity still be present in the To URI?=0A=0A=09Thanks,=0A= =09Paul=0A=0A> Ian Elz=0A>=0A> ----- Original Message -----=0A> From: "Hadr= iel Kaplan"=0A> To: "Shida Schubert"=0A> Cc: sipcore@ietf.org=0A> Sent: Monday, 8 November, 2010 3:01:39 PM= =0A> Subject: Re: [sipcore] Yet more comments on rfc4244bis-02=0A>=0A>=0A>= =0A> On Nov 8, 2010, at 6:01 AM, Shida Schubert wrote:=0A>=0A>> Privacy:non= e is used when caller (UAC) wants his/her identity delivered=0A>> to the de= stination (callee) despite the existence of privacy service, but=0A>> with = regards to H-I, when does it ever contain the URI that identifies the=0A>> = caller (UAC) ?=0A>> I agree that privacy:none will be valid if we can find = a situation where=0A>> URI of UA will be one of the hi-entry but my imagina= tion is not strong=0A>> enough to see this.=0A>=0A> But that also begs the = question of why we need a Privacy header of "history" to begin with. (I mea= n a real Privacy header in the message, not an embedded one in a particular= HI URI)=0A>=0A> The only case I could imagine for such things is that the = caller doesn't want their domain known about. I.e., I make an anonymous ca= ll from my SIP phone through my corporate SIP proxy, and my SIP phone sets = "Privacy: history" so that Acme Packet's anonymization proxy removes "acmep= acket.com" from any H-Is, before sending it out our SIP trunk, etc.=0A>=0A>= -hadriel=0A>=0A>=0A>=0A>=0A>=0A>=0A> _____________________________________= __________=0A> sipcore mailing list=0A> sipcore@ietf.org=0A> https://www.ie= tf.org/mailman/listinfo/sipcore=0A>=0A=0A=0A=0A=0A From fluffy@cisco.com Tue Nov 9 12:41:22 2010 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 95A363A692E for ; Tue, 9 Nov 2010 12:41:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.565 X-Spam-Level: X-Spam-Status: No, score=-110.565 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 DQzvS2vKynyw for ; Tue, 9 Nov 2010 12:41:20 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E28D73A6A08 for ; Tue, 9 Nov 2010 12:41:17 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIGACNB2UyrR7Ht/2dsb2JhbACUJY4CcaJym1KFSgSEWYV9gww X-IronPort-AV: E=Sophos;i="4.59,175,1288569600"; d="scan'208";a="379183016" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 09 Nov 2010 20:41:42 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oA9KfeDk022920; Tue, 9 Nov 2010 20:41:41 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058501769F3A@ESESSCMS0356.eemea.ericsson.se> Date: Tue, 9 Nov 2010 13:42:02 -0700 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F2072F1E0DE894DA4B517B93C6A058501703422@ESESSCMS0356.eemea.ericsson.se> <4C936714.2040808@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501703523@ESESSCMS0356.eemea.ericsson.se>, <4C936E79.3070906@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8B@ESESSCMS0356.eemea.ericsson.se>, <4C938ED5.10507@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8E@ESESSCMS0356.eemea.ericsson.se>, <4C93E4DE.9070802@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA92@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058501769F3A@ESESSCMS0356.eemea.ericsson.se> To: sipcore@ietf.org X-Mailer: Apple Mail (2.1081) Subject: [sipcore] draft-holmberg-sipcore-proxy-feature- why not just use Supported 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: Tue, 09 Nov 2010 20:41:22 -0000 So, in my week of agreeing with Hadriel, I think he got it exactly right = when he said there is pretty much no feature a "plain" proxy would need = for this. If we are talking about things that would be a strict = technical read be considered B2BUA even if they are implemented a lot = like a proxy, then I can why something provided something like this = functionality would be needed.=20 But given this would be used by a B2BUA, I don't see why you need = anything more than just normal option tags. Say a SIP message comes from = A to B to C and now the response is coming back. C says it supports = feature c1, c2, and c3. B knows that it can transparently forward on = whatever is needed for c1, c2, but not c3 and it knows that in = additional to this it can do features b4 and b5. It modifies the = Supported header to have c1,c2,b4, and b5. and sends that back to A.=20 If the real uses cases have to do with caller pref features, then B can = modify those in the same way.=20 Anyways, I think we are way way ahead of ourselves discussing mechanism = before we even understand what the use cases are we are trying to solve. = I'd like to see some specific real world use cases and so we can work = out the real requirements. I'm expect the uses cases will contain B2BUA = in the call flows - that's reality.=20 On Sep 24, 2010, at 5:04 AM, Christer Holmberg wrote: >=20 >=20 > Hi, >=20 > I've submitted a draft, which extends the rr-param rule, allowing = proxies to indicate supported features using feature tags in Path, = Record-Route etc. >=20 > The draft can also be found at: = http://users.piuha.net/cholmber/drafts/draft-holmberg-sipcore-proxy-featur= e-00.txt >=20 > As I indicated earlier on the list, and as you can read in the draft, = there is a 3GPP use-case where we believe the mechanism could be used. = But, there is nothing 3GPP specific about the mechanism as such. >=20 > Regards, >=20 > Christer > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From ian_elz@yahoo.co.uk Tue Nov 9 15:38:47 2010 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 42BE73A69B3 for ; Tue, 9 Nov 2010 15:38:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.299 X-Spam-Level: X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_41=0.6, J_CHICKENPOX_63=0.6, J_CHICKENPOX_74=0.6] 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 l+ch1hiL1YTl for ; Tue, 9 Nov 2010 15:38:45 -0800 (PST) Received: from nm19-vm0.bullet.mail.ird.yahoo.com (nm19-vm0.bullet.mail.ird.yahoo.com [77.238.189.92]) by core3.amsl.com (Postfix) with SMTP id CFAF63A6980 for ; Tue, 9 Nov 2010 15:38:44 -0800 (PST) Received: from [77.238.189.56] by nm19.bullet.mail.ird.yahoo.com with NNFMP; 09 Nov 2010 23:39:07 -0000 Received: from [212.82.108.123] by tm9.bullet.mail.ird.yahoo.com with NNFMP; 09 Nov 2010 23:39:07 -0000 Received: from [127.0.0.1] by omp1032.mail.ird.yahoo.com with NNFMP; 09 Nov 2010 23:39:07 -0000 X-Yahoo-Newman-Property: ymail-3 X-Yahoo-Newman-Id: 26933.96885.bm@omp1032.mail.ird.yahoo.com Received: (qmail 52538 invoked by uid 60001); 9 Nov 2010 23:39:06 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.co.uk; s=s1024; t=1289345946; bh=DRI7pdvx5zdgytS2IA5SqBYxNMddRBSnMhIc+1DSStI=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=pKSiBKeesQrI6hc9lXsNR2suxaKfa4CA0/O2cFrONAsrYmEjuLHFkQ8MCb5mWxSvsYDgbREyaFQeink/sYd3nWmQEGXg69z/mQNN7TTJLcPkiZRyyv/q936LhoHUQKljn7BtbzkSVSOrmpz403QoU4ssForTXQI2AZy2MqGX/K8= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.co.uk; h=Message-ID:X-YMail-OSG:Received:X-Mailer:Date:From:Reply-To:Subject:To:Cc:MIME-Version:Content-Type:Content-Transfer-Encoding; b=ZZkZzQOmFNbrc968c2xClJ6zbB3dV9fgWq2qq9n+dQXCyyuAraScYXtTy/gkCmAvJxfrQeICk68+4n3wlMq45H2gl549FmczpNpaPmv4kthfqWXLk7Gj30Vm1WvSF37i2vgF9cuYqoKJfGCMMH81lV3BjxrMKWSwd0Z9ygao2Po=; Message-ID: <771231.52299.qm@web29101.mail.ird.yahoo.com> X-YMail-OSG: Wh86NEgVM1n3D01nmsY7pGn6838qR3d7bAbV6VMW69OGPP0 yUQsO8jlEuuYZZ9XFVr8mK._SeRhZkkS7M9rx8DN.U6_uZi.krA5UvWThNv6 12CZHouu9YADB2MD_cgNumg8E7jzMwfn13LiWZcvKcjh10DaYgozqwMP5vp0 Z4xNLeGnTvGEehf0r.E6sQKh9ns.UN4gODf49HrM4v40S.sRIT1VDrLrs8RU 6OoISBMYl1T9yh0EfehGJbRK28Vr_F7nb8H64GZQ.xs3zQWsTGERnB47XdLg - Received: from [86.20.66.247] by web29101.mail.ird.yahoo.com via HTTP; Tue, 09 Nov 2010 23:39:06 GMT X-Mailer: YahooMailWebService/0.8.107.285259 Date: Tue, 9 Nov 2010 23:39:06 +0000 (GMT) From: Ian Elz To: Paul Kyzivat MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Cc: sipcore@ietf.org, R Jesske Subject: Re: [sipcore] Yet more comments on rfc4244bis-02 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: Ian Elz List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Nov 2010 23:38:47 -0000 Paul,=0A=0AWith Privacy it is not the operators who are in control. This is= usually a regulatory matter which gives the user the option to set privacy= .=0A=0AIn the cases to which I refer the UAC (original caller) sets his pri= vacy and the UAS (called part)y may set his privacy in the return message. = Why shouldn't the forwarding party be able to specify his privacy when a ca= ll is forwarded.=0A=0AI do agree that the "stronger" argument is spurious. = I have no idea which is none, header, user, id or history is stronger. They= are all explicit in what they require. There should be a mechanism where a= ny uri may be kept private whilst others are not.=0A=0AIan=0A=0A----- Origi= nal Message -----=0AFrom: "Paul Kyzivat" =0ATo: "R Jess= ke" =0ACc: sipcore@ietf.org=0ASent: Tuesday, 9 Novembe= r, 2010 2:51:15 AM=0ASubject: Re: [sipcore] Yet more comments on rfc4244bis= -02=0A=0AThat begs the question of which is "stronger", and who is presumed= to be =0Ain control. ISTM that the intent with Privacy was to put the UAC = in =0Acontrol, not the operator. Of course the operators won't see it that = way =0A- they are used to being in control. And in the end we can do little= to =0Aprevent the operators from doing as they wish, regardless of what th= e =0Aspecs say. But we can say that they are non-compliant when doing so.= =0A=0A=09Thanks,=0A=09Paul=0A=0AOn 11/9/2010 10:27 AM, R.Jesske@telekom.de = wrote:=0A> Hi,=0A> seen from network operator perspective. The stronger val= ue hits.=0A> So if there is a "history" and "none" in the same Message then= the History Info will be anonymised and the rest will stay as it is.=0A>= =0A> Best Regards=0A>=0A> Roland=0A>=0A>=0A> -----Urspr=FCngliche Nachricht= -----=0A> Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] I= m Auftrag von Paul Kyzivat=0A> Gesendet: Dienstag, 9. November 2010 01:09= =0A> An: sipcore@ietf.org=0A> Betreff: Re: [sipcore] Yet more comments on r= fc4244bis-02=0A>=0A>=0A>=0A> On 11/8/2010 1:10 PM, Ian Elz wrote:=0A>> Mary= ,=0A>>=0A>> I am a bit late replying.=0A>>=0A>> The reason for the Privacy = of "none" was probably due to my comments.=0A>>=0A>> Regarding "Privacy:his= tory" being used to anonomise all H-I URI then this probably looks OK as it= makes everything private.=0A>>=0A>> The problem is that making the Privacy= header take precedence over the individual entries is when you have "Priva= cy:none" and some of the H-I entries have Privacy=3Dhistory. If you take th= e Privacy:history case then the ":none" will override "=3Dhistory" which ef= fectively means that the originator of the request can specify the privacy = of URIs belonging to someone who diverts or re-targets the request.=0A>>=0A= >> This is just not correct.=0A>=0A> Why do you say this is not correct?=0A= > ISTM the purpose of Privacy:none is precisely to demand that nothing be= =0A> removed or anonymized. For instance, IIUC this would apply to Route=0A= > headers, which present some of the same issues as H-I headers.=0A>=0A> El= ements along the way that don't like this can either:=0A> - fail the call= =0A> - omit information in the first place if they want it kept private=0A>= =0A> =09Thanks,=0A> =09Paul=0A>=0A>> The purpose of allowing "privacy=3Dnon= e" in the H-I entry was to allow the future possibility of the overriding t= he Privacy header.=0A>>=0A>> We need to remember that RFC3323 was written w= hen cocepts of diversion etc were not part of sip.=0A>>=0A>> Ian Elz=0A>>= =0A>> ----- Original Message -----=0A>> From: "Mary Barnes"=0A>> To: "Shida Schubert"=0A>> Cc: sipcore@i= etf.org, "Mary Barnes"=0A>> Sent: Monday, 8 Novemb= er, 2010 5:19:25 AM=0A>> Subject: Re: [sipcore] Yet more comments on rfc424= 4bis-02=0A>>=0A>> A few additional comments inline below [MB].=0A>>=0A>> Ma= ry.=0A>>=0A>> On Sun, Nov 7, 2010 at 12:28 AM, Shida Schubert wrote:=0A>>>=0A>>> Hi John;=0A>>>=0A>>> My responses on some of t= he comments, I think=0A>>> Mary may be responding on the same issues but he= re are mine.=0A>>>=0A>>> On Nov 4, 2010, at 12:29 AM, Elwell, John wrote:= =0A>>>=0A>>>> 1. Section 7.3.1.=0A>>>> "If there is a Privacy header in the= request with a priv-=0A>>>> value of "header" or "history", then the i= nitial hi-entry MUST be=0A>>>> anonymized and the header removed when t= he request leaves a domain=0A>>>> for which the SIP entity is responsib= le."=0A>>>> I think it should say "...and the Privacy header removed" - the= re is no point in removing the H-I header field if we have anonymized it.= =0A>>>=0A>>> You are right. The intention was to say "remove the priv-va= lue and remove the privacy=0A>>> header itself if there are no other priv-v= alue left (id may exists which needs=0A>>> to remain in the request until i= t reaches the egress point)".=0A>>>=0A>>>>=0A>>>> 2. What is meant by anony= mizing a hi-entry (in this paragraph and elsewhere)? Is it only the hi-targ= eted-to-uri that needs to be anonymized, or also its parameters? The exampl= es in annex B show just the URI anonymized and with the value anonymous@ano= nymous.invalid. Is this how it MUST be done?=0A>>=0A>> [MB] It is only the = hi-targeted-to-uri that needs to be anonymized -=0A>> it is a MUST. The oth= er parameters MUST not be changed. [/MB]=0A>>>=0A>>> I personally don't = have a strong opinion about prescribing the anonymous@anonymou.invalid but= =0A>>> I think it would be useful to specify what the anonymized URI should= look like. This would avoid=0A>>> anonymous URI anonymized numerous time b= y different privacy service for example...=0A>>> As for the parameter, i= f rc/mp tag, index and encoded reason(RFC 3326) are intact,=0A>>> anonymize= d hi-entry can still provide some value, so I think only hi-targeted-to-uri= should be=0A>>> anonymized.=0A>>>=0A>>>>=0A>>>> 3. In the same sentence, i= s it sufficient to anonymize only the first hi-entry? There could be furthe= r hi-entries for the same domain, and just revealing internal routing withi= n the domain might be considered a breach of privacy. Perhaps in that case = you would need to rely on those additional hi-entries being separately mark= ed for privacy. If that is so, it would seem to be OK.=0A>>>=0A>>> Your = last suggestion/assumption was exactly the motivation and our=0A>>> attempt= to simplify privacy handling, by saying Privacy header with priv-value=0A>= >> of "history"/"header" (not in hi-entry) for anonymizing first hi-entry o= nly and to use=0A>>> privacy=3Dheader in hi-entry for any other hi-entries.= =0A>>>=0A>>> It would mean;=0A>>>=0A>>> 1. UA requests H-I privacy b= y using Privacy:history or Privacy:header=0A>>> 2. Proxy request H-I pr= ivacy by using History-Info:?privacy=3Dhistory=0A>>>=0A>>> Wh= ich we thought would clarify the timing of when Privacy:history / Privacy:h= eader=0A>>> and privacy=3Dhistory are used.=0A>>>=0A>>> But thinking fur= ther, it doesn't really simplify the overall=0A>>> privacy handling of H-I = and furthermore it changes the semantics of=0A>>> header privacy in RFC332= 3.=0A>>>=0A>>> Excerpt from RFC3323 on header privacy says:=0A>>>=0A>>> = "If a privacy level of 'header' is requested, then the originating=0A>>= > user has asked the privacy service to help to obscure headers that=0A= >>> might otherwise reveal information about the originator of the=0A>>= > request."=0A>>>=0A>>> This can encompass entries revealing interna= l routing and domain=0A>>> information as you mentioned above, so restricti= ng the use of Privacy:header=0A>>> to first entry only can be seen as chang= ing the semantics defined in RFC3323.=0A>>>=0A>>> I think we should alig= n the handling of H-I privacy of Privacy:history=0A>>> and Privacy:header t= o that of RFC3323, allowing privacy service to=0A>>> anonymize not only the= first hi-entry but any other entries that=0A>>> are from its domain.=0A>> = [MB] I don't have a strong opinion here. The suggestion above makes=0A>> a= lot of sense. [/MB]=0A>>>=0A>>> I guess we need to further clarify how = these two means of requesting=0A>>> privacy interact, since you can have bo= th privacy:history and few hi-entries=0A>>> with privacy=3Dhistory. I am as= suming that when privacy service anonymizes=0A>>> history-info header based= on privacy:history or privacy:header, it also=0A>>> needs to remove the pr= ivacy=3Dhistory from hi-entries that it's anonymizing.=0A>> [MB] Yes, we sh= ould clarify. With the approach discussed above, the=0A>> privacy:history = would "override" the privacy for each entry (within=0A>> that domain). And= , yes, per a previous thread, we do need to update=0A>> the privacy text to= indicate the removal of the privacy for each=0A>> hi-entry as it is anonym= ized. [/MB]=0A>>=0A>>>=0A>>> Lastly what about the interaction with priv= acy:none? According to=0A>>> section 5.1 of 4244bis, if UAC doesn't want pr= ivacy on its identity it sets=0A>>> Privacy header with priv-value of "none= ", but I am having a hard time=0A>>> envisioning the need for this. When do= you ever get the hi-entry representing=0A>>> your own AoR or contact addre= ss?=0A>> [MB] We originally did not include privacy of "none" as relevant = to=0A>> History-info (in 4244). That was added in -bis and I to question th= e=0A>> value. I do not think it has any value as applied to History-Info a= nd=0A>> I would suggest we remove it or note that it has no impact in terms= of=0A>> the processing of privacy for the hi-entries. [/MB]=0A>>>=0A>>> = I think the hi-entry with privacy=3Dhistory should still be anonymized, ev= en when=0A>>> the Privacy:none is set in request because the privacy is req= uested by proxy, I=0A>>> think we need to add text on this as well.=0A>> [M= B] Agreed. [/MB]=0A>>>=0A>>>=0A>>>>=0A>>>> 4. "In addition, the History-Inf= o header can reveal general routing and=0A>>>> diverting information wi= thin an intermediary, "=0A>>>> Is it only routing information within an int= ermediary, or also routing information within a domain that you might want = to make private? I think text later in the paragraph concurs with the latte= r view.=0A>> [MB] yes, it's the latter - within a domain for which the=0A>= > intermediary is responsible. [/MB]=0A>>>>=0A>>>> 5. "Finally, the termina= tor of the request may not want to reveal the=0A>>>> final reached targ= et to the originator. In this case, the terminator=0A>>>> uses the a v= alue of "history" in the Privacy header in the last hi-=0A>>>> entry in= the response. The SIP entity that forwards the response=0A>>>> MUST a= nonymize that hi-entry and remove the Privacy header."=0A>>>> Although a UA= S can mark the final hi-entry as private, and there is a requirement for a = proxy to anonymize this when the response leaves the domain, what about oth= er hi-entries that have been marked by proxies in the final domain as priva= te? These will get passed back in the response without anonymization since = they are not the final hi-entry and are not covered by this statement. Shou= ld the final sentence apply to any hi-entry?=0A>> [MB] Yes. that sentence s= hould apply to all responses - i.e., in=0A>> general if there are hi-entrie= s with an escaped privacy header, they=0A>> should be anonymized and the pr= ivacy header removed. [/MB]=0A>>>=0A>>> RFC3323 recommends that privacy = service to be included in the=0A>>> request/response path if privacy is des= ired. The privacy handling=0A>>> in 4244bis is based on RFC3323 so I don't = know if we need to add=0A>>> anything specific here for anonymizing the res= ponse.=0A>>>=0A>>>>=0A>>>> 6. Section 7.3.3:=0A>>>> "To=0A>>>> acco= mplish this, the processing entity MUST read the value from=0A>>>> = the History-Info header in the received request and MUST add=0A>>>> = another level of indexing "=0A>>>> Should make it clear it is the last hi-= entry of the received request (after adding entries on behalf of previous h= ops).=0A>>>=0A>>> Agree.=0A>>>=0A>>>>=0A>>>> 7. "followed=0A>>>> = by an initial index for the new level of 1"=0A>>>> I think this would be c= learer if it said:=0A>>>> "followed by an initial index of 1 for the new le= vel"=0A>>>=0A>>> Agree.=0A>>>=0A>>>>=0A>>>> 8. "MUST be calculated by in= crementing the last/lowest digit=0A>>>> at the current level"=0A>>>= > and=0A>>>> "That is, the lowest/last digit of the index MUST be=0A>>>> = incremented "=0A>>>> What if an index is a double-digit integer?=0A>>= >=0A>>> How about we remove the "lowest/last" and simply=0A>>> say incre= menting the digit at the current level by 1 or=0A>>> something like that.= =0A>>>=0A>>>>=0A>>>> 9. Section 8:=0A>>>> "an=0A>>>> application might = need to provide special handling in some cases=0A>>>> where there are g= aps."=0A>>>> Should there be a note discussing the fact that some gaps are = not detectable, e.g., if I receive 1, 1.1 and 1.1.1, I cannot detect if 1.2= or 1.1.2, say, is missing.=0A>>>=0A>>> This would happen, say for examp= le if request was=0A>>> parallel forked, each branch would have the hi-entr= y=0A>>> that only the forked request traversed but missing=0A>>> the inform= ation of the other forks. I don't know if I would=0A>>> consider what you d= escribe as a gap. You may be=0A>>> missing the other branches but you shoul= d be able to=0A>>> identify the gap in index for the branch that request=0A= >>> traversed. (You may be missing the actual hop in the=0A>>> logical tree= of History-Info that does not support=0A>>> 4244/4244bis but as they won't= add the hi-entry=0A>>> there won't be a gap in index itself).=0A>>>=0A>>>>= =0A>>>> 10. Should we say anything in section 8 about anonymized entries? N= ote that what we might say depends to some extent on whether what exactly g= ets anomymised. For example if an application searches for an rc or mp entr= y, if those parameters have been anonymized it will not find them (but migh= t find others that have not been anonymized!), but if those parameters have= not been anonymized it will find them but the URI will be useless.=0A>>>= =0A>>> URI will be useless but one can still determine how many times=0A= >>> request was retargeted, for example (Of course this is true only=0A>>>= if all the proxies are rfc4244bis compliant), which I think remains=0A>>> = useful.=0A>>>=0A>>>>=0A>>>> 11. Section 9:=0A>>>> "With the level of securi= ty provided by TLS (SEC-req-3), the=0A>>>> information in the History-I= nfo header can thus be evaluated to=0A>>>> determine if information has= been removed by evaluating the indices=0A>>>> for gaps (SEC-req-1, SEC= -req-2). "=0A>>>> This is subject to the limitation pointed out in a comme= nt above, about not all gaps being detectable.=0A>>>>=0A>>>> 12. I would ex= pect to see something in section 9 concerning privacy. We should mention th= e privacy mechanism and discuss its limits (i.e., depends on trust of downs= tream entities to anonymize privacy-marked entries). Also there should prob= ably be some discussion on strength of anonymization algorithms (unless we = are indeed prescribing anonymous@anonymous.invalid).=0A>>>=0A>>> Agree t= hat text should be added.=0A>>>=0A>>>>=0A>>>> 13. Section 10.2:=0A>>>> "Thi= s document defines a priv-value for the SIP Privacy header:=0A>>>> hist= ory The following changes have been made to=0A>>>> http://www.iana.org/= assignments/sip-priv-values The following has=0A>>>> been added to the = registration for the SIP Privacy header:"=0A>>>> I am not sure how to parse= this.=0A>>>=0A>>>>=0A>>>>=0A>>>> 14. Section 12.1:=0A>>>> "This specificat= ion adds an=0A>>>> optional SIP header field parameter to the History-I= nfo and Contact=0A>>>> headers. "=0A>>>> In fact it adds two parameter= s to each.=0A>>>=0A>>> Indeed.=0A>>>=0A>>>>=0A>>>> 15. "Entities that ha= ve not implemented this specification MUST=0A>>>> ignore these paramete= rs, "=0A>>>> We cannot place a normative requirement on entities that don't= implement this. Change "MUST" to "will".=0A>>>=0A>>> Agree.=0A>>>=0A>>>= >=0A>>>> John=0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>>=0A>>>= >=0A>>>> _______________________________________________=0A>>>> sipcore mai= ling list=0A>>>> sipcore@ietf.org=0A>>>> https://www.ietf.org/mailman/listi= nfo/sipcore=0A>>>=0A>>> _______________________________________________=0A>= >> sipcore mailing list=0A>>> sipcore@ietf.org=0A>>> https://www.ietf.org/m= ailman/listinfo/sipcore=0A>>>=0A>>=0A>>=0A>>=0A>>=0A>>=0A>> _______________= ________________________________=0A>> sipcore mailing list=0A>> sipcore@iet= f.org=0A>> https://www.ietf.org/mailman/listinfo/sipcore=0A>>=0A> _________= ______________________________________=0A> sipcore mailing list=0A> sipcore= @ietf.org=0A> https://www.ietf.org/mailman/listinfo/sipcore=0A>=0A=0A=0A=0A= =0A From pkyzivat@cisco.com Tue Nov 9 16:04:17 2010 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 E990F28C117 for ; Tue, 9 Nov 2010 16:04:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.464 X-Spam-Level: X-Spam-Status: No, score=-110.464 tagged_above=-999 required=5 tests=[AWL=0.135, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 oY17PtnYkdMX for ; Tue, 9 Nov 2010 16:04:14 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 69A063A69FB for ; Tue, 9 Nov 2010 16:04:11 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiIGAElw2UxAaMHG/2dsb2JhbACUJo4CcaFTmy+CcYJZBIRXhX+DDA X-IronPort-AV: E=Sophos;i="4.59,176,1288569600"; d="scan'208";a="617291229" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-6.cisco.com with ESMTP; 10 Nov 2010 00:04:36 +0000 Received: from [10.75.233.220] (hkidc-vpn-client-233-220.cisco.com [10.75.233.220]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAA04RaO017654 for ; Wed, 10 Nov 2010 00:04:28 GMT Message-ID: <4CD9E189.6050704@cisco.com> Date: Wed, 10 Nov 2010 08:04:25 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: sipcore@ietf.org References: <7F2072F1E0DE894DA4B517B93C6A058501703422@ESESSCMS0356.eemea.ericsson.se> <4C936714.2040808@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501703523@ESESSCMS0356.eemea.ericsson.se>, <4C936E79.3070906@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8B@ESESSCMS0356.eemea.ericsson.se>, <4C938ED5.10507@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8E@ESESSCMS0356.eemea.ericsson.se>, <4C93E4DE.9070802@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA92@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058501769F3A@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- why not just use Supported 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: Wed, 10 Nov 2010 00:04:17 -0000 I'm tempted to agree with Cullen on this. But I think it "depends". If the B2BUA is a "proper" UA, and inserts its own Contact address in the call, then I think Cullen's description is right. If its a B2BUA because it messes with things a proxy cannot, but *doesn't* modify the Contact address, then just manipulating Supported isn't enough. Then the features that *it* supports are obtainable directly only by sending a request to *it*, using the Route header, etc. to identify that address. Its always seemed to me that a UA should always supply its own Contact address, but I've looked for verification of that in 3261 and not found it. Thanks, Paul On 11/10/2010 4:42 AM, Cullen Jennings wrote: > > So, in my week of agreeing with Hadriel, I think he got it exactly right when he said there is pretty much no feature a "plain" proxy would need for this. If we are talking about things that would be a strict technical read be considered B2BUA even if they are implemented a lot like a proxy, then I can why something provided something like this functionality would be needed. > > But given this would be used by a B2BUA, I don't see why you need anything more than just normal option tags. Say a SIP message comes from A to B to C and now the response is coming back. C says it supports feature c1, c2, and c3. B knows that it can transparently forward on whatever is needed for c1, c2, but not c3 and it knows that in additional to this it can do features b4 and b5. It modifies the Supported header to have c1,c2,b4, and b5. and sends that back to A. > > If the real uses cases have to do with caller pref features, then B can modify those in the same way. > > Anyways, I think we are way way ahead of ourselves discussing mechanism before we even understand what the use cases are we are trying to solve. I'd like to see some specific real world use cases and so we can work out the real requirements. I'm expect the uses cases will contain B2BUA in the call flows - that's reality. > > > On Sep 24, 2010, at 5:04 AM, Christer Holmberg wrote: > >> >> >> Hi, >> >> I've submitted a draft, which extends the rr-param rule, allowing proxies to indicate supported features using feature tags in Path, Record-Route etc. >> >> The draft can also be found at: http://users.piuha.net/cholmber/drafts/draft-holmberg-sipcore-proxy-feature-00.txt >> >> As I indicated earlier on the list, and as you can read in the draft, there is a 3GPP use-case where we believe the mechanism could be used. But, there is nothing 3GPP specific about the mechanism as such. >> >> Regards, >> >> Christer >> _______________________________________________ >> 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 > From aallen@rim.com Tue Nov 9 17:19:28 2010 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 D469E3A69FD for ; Tue, 9 Nov 2010 17:19:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.203 X-Spam-Level: X-Spam-Status: No, score=-5.203 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4] 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 GiDT2D-iw2t3 for ; Tue, 9 Nov 2010 17:19:27 -0800 (PST) Received: from mhs04ykf.rim.net (mhs04ykf.rim.net [216.9.243.82]) by core3.amsl.com (Postfix) with ESMTP id F1E2F3A6A25 for ; Tue, 9 Nov 2010 17:19:26 -0800 (PST) X-AuditID: 0a666446-b7bfcae0000024ce-44-4cd9f3373b33 Received: from XCH139CNC.rim.net ( [10.65.10.235]) by mhs04ykf.rim.net (RIM Mail) with SMTP id E2.97.09422.733F9DC4; Tue, 9 Nov 2010 20:19:51 -0500 (EST) Received: from XCH02DFW.rim.net ([10.150.100.31]) by XCH139CNC.rim.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 9 Nov 2010 20:19:51 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" content-transfer-encoding: quoted-printable Date: Tue, 9 Nov 2010 19:19:49 -0600 Message-ID: In-Reply-To: <4CD9E189.6050704@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-holmberg-sipcore-proxy-feature- why not just use Supported Thread-Index: AcuAat6XIt/v9PlARv6xOHOMfSzVMAACn+Bq From: "Andrew Allen" To: , X-OriginalArrivalTime: 10 Nov 2010 01:19:51.0737 (UTC) FILETIME=[5FD2CA90:01CB8075] X-Brightmail-Tracker: AAAAAgAAAZEWoNEM Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- why not just use Supported 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: Wed, 10 Nov 2010 01:19:28 -0000 I think the second case Paul describes is what in 3GPP is called a Routing B= 2BUA which sometimes behaves like a proxy and sometimes like a UA. IMHO thes= e entities should use Record-Route to keep themselves on the path and not wr= ite their own URI in the Contact but pass the Contact header transparently.= To do otherwise breaks things like GRUU and callee caps. I support the solving in a general way of how an intermediary that provides= some kind of funtionality on behalf of a UA can indicate its presence to ot= her entities. Another use case for this is helping to solve service interaction problems w= here multiple application servers are involved and the service logic perform= ed by one may need to be taken into account by the other. I also think it is necessary that UAs can detect the presence of intermediar= ies such as IP-PBXs and application servers in the path of a session and obt= ain a URI to which they can send requests to invoke service logic at those s= ervers without them having to overwrite the contact URI for the reasons stat= ed above. Andrew. ----- Original Message ----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Tuesday, November 09, 2010 07:04 PM To: sipcore@ietf.org Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- why not just us= e Supported I'm tempted to agree with Cullen on this. But I think it "depends". If the B2BUA is a "proper" UA, and inserts its own Contact address in the call, then I think Cullen's description is right. If its a B2BUA because it messes with things a proxy cannot, but *doesn't* modify the Contact address, then just manipulating Supported isn't enough. Then the features that *it* supports are obtainable directly only by sending a request to *it*, using the Route header, etc. to identify that address. Its always seemed to me that a UA should always supply its own Contact address, but I've looked for verification of that in 3261 and not found it. Thanks, Paul On 11/10/2010 4:42 AM, Cullen Jennings wrote: > > So, in my week of agreeing with Hadriel, I think he got it exactly right w= hen he said there is pretty much no feature a "plain" proxy would need for t= his. If we are talking about things that would be a strict technical read be= considered B2BUA even if they are implemented a lot like a proxy, then I ca= n why something provided something like this functionality would be needed. > > But given this would be used by a B2BUA, I don't see why you need anything= more than just normal option tags. Say a SIP message comes from A to B to C= and now the response is coming back. C says it supports feature c1, c2, and= c3. B knows that it can transparently forward on whatever is needed for c1,= c2, but not c3 and it knows that in additional to this it can do features b= 4 and b5. It modifies the Supported header to have c1,c2,b4, and b5. and sen= ds that back to A. > > If the real uses cases have to do with caller pref features, then B can mo= dify those in the same way. > > Anyways, I think we are way way ahead of ourselves discussing mechanism be= fore we even understand what the use cases are we are trying to solve. I'd l= ike to see some specific real world use cases and so we can work out the rea= l requirements. I'm expect the uses cases will contain B2BUA in the call flo= ws - that's reality. > > > On Sep 24, 2010, at 5:04 AM, Christer Holmberg wrote: > >> >> >> Hi, >> >> I've submitted a draft, which extends the rr-param rule, allowing proxies= to indicate supported features using feature tags in Path, Record-Route etc= . >> >> The draft can also be found at: http://users.piuha.net/cholmber/drafts/dr= aft-holmberg-sipcore-proxy-feature-00.txt >> >> As I indicated earlier on the list, and as you can read in the draft, the= re is a 3GPP use-case where we believe the mechanism could be used. But, the= re is nothing 3GPP specific about the mechanism as such. >> >> Regards, >> >> Christer >> _______________________________________________ >> 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 ---------------------------------------------------------------------=0A= This transmission (including any attachments) may contain confidential infor= mation, privileged material (including material protected by the solicitor-c= lient or other applicable privileges), or constitute non-public information.= Any use of this information by anyone other than the intended recipient is= prohibited. If you have received this transmission in error, please immedia= tely reply to the sender and delete this information from your system. Use,= dissemination, distribution, or reproduction of this transmission by uninte= nded recipients is not authorized and may be unlawful. From john.elwell@siemens-enterprise.com Tue Nov 9 17:29:45 2010 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 DB39F3A68AB for ; Tue, 9 Nov 2010 17:29:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.498 X-Spam-Level: X-Spam-Status: No, score=-102.498 tagged_above=-999 required=5 tests=[AWL=0.101, BAYES_00=-2.599, 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 aJlw1bMMml2d for ; Tue, 9 Nov 2010 17:29:45 -0800 (PST) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id B2EA63A68A0 for ; Tue, 9 Nov 2010 17:29:44 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2241842; Wed, 10 Nov 2010 02:30:06 +0100 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id D745723F0278; Wed, 10 Nov 2010 02:30:06 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Wed, 10 Nov 2010 02:30:06 +0100 From: "Elwell, John" To: Shida Schubert Date: Wed, 10 Nov 2010 02:30:04 +0100 Thread-Topic: [sipcore] Understanding Privacy: history invoked by UAS Thread-Index: Act/1rANo9eqTkUiQcubIPPdLGpiowAn6axA Message-ID: References: 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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Understanding Privacy: history invoked by UAS 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: Wed, 10 Nov 2010 01:29:46 -0000 In which case we don't need Privacy: history in the response, since it is o= nly a partial solution? John=20 > -----Original Message----- > From: Shida Schubert [mailto:shida@ntt-at.com]=20 > Sent: 09 November 2010 06:24 > To: Elwell, John > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Understanding Privacy: history invoked by UAS >=20 >=20 > Hi John; >=20 > In practice, if C cares about its privacy, there should be=20 > a priori arrangement with the service provider or=20 > configuration in proxy to withhold its identity. >=20 > This will allow the proxy sending the 4xx which sets the hi-entry=20 > to ensure privacy is applied by setting escaped privacy header=20 > or Privacy:header.=20 >=20 > Regards > Shida=20 >=20 > On Nov 9, 2010, at 11:32 AM, Elwell, John wrote: >=20 > > Suppose a request from A is targeted initially at B, this=20 > is mapped to C, and then to registered contact D. The UAS (D)=20 > puts Privacy: history in the response, and therefore prevents=20 > A learning about C and D. Fine. > >=20 > > Now, supposing D is not registered at the time, i.e., there=20 > is no registered contact for C. This results in a 4xx=20 > response to A. How do we ensure that the identity of C is not=20 > disclosed to A, in line with what is achieved when D is registered? > >=20 > > John > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore >=20 > = From john.elwell@siemens-enterprise.com Tue Nov 9 17:47:09 2010 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 512893A6904 for ; Tue, 9 Nov 2010 17:47:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.099, BAYES_00=-2.599, 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 0bow4irM-Hix for ; Tue, 9 Nov 2010 17:47:08 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 326DB3A68AB for ; Tue, 9 Nov 2010 17:47:07 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2240648; Wed, 10 Nov 2010 02:46:48 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id D71DE23F028E; Wed, 10 Nov 2010 02:46:48 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 10 Nov 2010 02:46:48 +0100 From: "Elwell, John" To: SIPCORE Chairs , "SIPCORE (Session Initiation Protocol Core) WG" Date: Wed, 10 Nov 2010 02:46:46 +0100 Thread-Topic: [sipcore] Summary: number of location headers Thread-Index: Act/7fuf6bscUKp/QZ6eF+3pdklD4wAis/BA Message-ID: References: <4CD90FFC.40502@nostrum.com> In-Reply-To: <4CD90FFC.40502@nostrum.com> 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 Subject: Re: [sipcore] Summary: number of location headers 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: Wed, 10 Nov 2010 01:47:09 -0000 I think we have to make provision for >1, and limiting it to 2 probably doe= sn't make sense. However, the warnings must include the fact that anyone in= serting an additional location and then getting back a 424 has no way of kn= owing whether the 424 applies to the location it inserted or a location alr= eady present. John=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach -=20 > SIPCORE Chair > Sent: 09 November 2010 09:10 > To: SIPCORE (Session Initiation Protocol Core) WG > Subject: [sipcore] Summary: number of location headers >=20 > [as chair] >=20 > I just wanted to summarize where it looks like the discussion=20 > ended up=20 > on whether we constrain the number of location header fields in a SIP=20 > message. From my review of the discussion, I believe that four people=20 > have weighed in on the topic to voice support for an=20 > arbitrary number of=20 > location headers (albeit with a implementation warning that=20 > doing so is=20 > not advisable): >=20 > Martin Thompson:=20 > http://www.ietf.org/mail-archive/web/sipcore/current/msg03576.html > Richard Barnes:=20 > http://www.ietf.org/mail-archive/web/sipcore/current/msg03580.html > Keith Drage:=20 > http://www.ietf.org/mail-archive/web/sipcore/current/msg03600.html > Hannu Hietalahti:=20 > http://www.ietf.org/mail-archive/web/sipcore/current/msg03619.html >=20 > And two people have agreed to go along with that direction, with=20 > expressed reservations: >=20 > Jon Peterson:=20 > http://www.ietf.org/mail-archive/web/sipcore/current/msg03601.html > James Polk:=20 > http://www.ietf.org/mail-archive/web/sipcore/current/msg03603.html >=20 > If any other working group participants have comments on this topic,=20 > they are encouraged to make them quickly. Lacking any further=20 > input, the=20 > authors will be instructed to revise the document to allow an=20 > arbitrary=20 > number of location header fields, with an accompanying warning that=20 > doing so is not recommended. >=20 > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From Martin.Thomson@andrew.com Tue Nov 9 17:53:28 2010 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 B09483A6A15 for ; Tue, 9 Nov 2010 17:53:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.56 X-Spam-Level: X-Spam-Status: No, score=-3.56 tagged_above=-999 required=5 tests=[AWL=-0.961, BAYES_00=-2.599] 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 MUvrfJ8pkTfa for ; Tue, 9 Nov 2010 17:53:27 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id BA5743A69D3 for ; Tue, 9 Nov 2010 17:53:27 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:62566 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S488538Ab0KJBxw (ORCPT ); Tue, 9 Nov 2010 19:53:52 -0600 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 9 Nov 2010 19:53:17 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 10 Nov 2010 09:53:12 +0800 From: "Thomson, Martin" To: "Elwell, John" , SIPCORE Chairs , "SIPCORE (Session Initiation Protocol Core) WG" Date: Wed, 10 Nov 2010 09:53:09 +0800 Thread-Topic: [sipcore] Summary: number of location headers Thread-Index: Act/7fuf6bscUKp/QZ6eF+3pdklD4wAis/BAAABBELA= Message-ID: <8B0A9FCBB9832F43971E38010638454F03F33652A1@SISPE7MB1.commscope.com> References: <4CD90FFC.40502@nostrum.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] Summary: number of location headers 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: Wed, 10 Nov 2010 01:53:28 -0000 VGhhdCdzIHNlbnNpYmxlLg0KDQpPbiAyMDEwLTExLTEwIGF0IDA5OjQ2OjQ2LCBFbHdlbGwsIEpv aG4gd3JvdGU6DQo+IEkgdGhpbmsgd2UgaGF2ZSB0byBtYWtlIHByb3Zpc2lvbiBmb3IgPjEsIGFu ZCBsaW1pdGluZyBpdCB0byAyIHByb2JhYmx5DQo+IGRvZXNuJ3QgbWFrZSBzZW5zZS4gSG93ZXZl ciwgdGhlIHdhcm5pbmdzIG11c3QgaW5jbHVkZSB0aGUgZmFjdCB0aGF0DQo+IGFueW9uZSBpbnNl cnRpbmcgYW4gYWRkaXRpb25hbCBsb2NhdGlvbiBhbmQgdGhlbiBnZXR0aW5nIGJhY2sgYSA0MjQg aGFzDQo+IG5vIHdheSBvZiBrbm93aW5nIHdoZXRoZXIgdGhlIDQyNCBhcHBsaWVzIHRvIHRoZSBs b2NhdGlvbiBpdCBpbnNlcnRlZA0KPiBvciBhIGxvY2F0aW9uIGFscmVhZHkgcHJlc2VudC4NCj4g DQo+IEpvaG4NCj4gDQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBz aXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcNCj4gPiBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRm Lm9yZ10gT24gQmVoYWxmIE9mIEFkYW0gUm9hY2ggLQ0KPiA+IFNJUENPUkUgQ2hhaXINCj4gPiBT ZW50OiAwOSBOb3ZlbWJlciAyMDEwIDA5OjEwDQo+ID4gVG86IFNJUENPUkUgKFNlc3Npb24gSW5p dGlhdGlvbiBQcm90b2NvbCBDb3JlKSBXRw0KPiA+IFN1YmplY3Q6IFtzaXBjb3JlXSBTdW1tYXJ5 OiBudW1iZXIgb2YgbG9jYXRpb24gaGVhZGVycw0KPiA+DQo+ID4gW2FzIGNoYWlyXQ0KPiA+DQo+ ID4gSSBqdXN0IHdhbnRlZCB0byBzdW1tYXJpemUgd2hlcmUgaXQgbG9va3MgbGlrZSB0aGUgZGlz Y3Vzc2lvbg0KPiA+IGVuZGVkIHVwDQo+ID4gb24gd2hldGhlciB3ZSBjb25zdHJhaW4gdGhlIG51 bWJlciBvZiBsb2NhdGlvbiBoZWFkZXIgZmllbGRzIGluIGEgU0lQDQo+ID4gbWVzc2FnZS4gRnJv bSBteSByZXZpZXcgb2YgdGhlIGRpc2N1c3Npb24sIEkgYmVsaWV2ZSB0aGF0IGZvdXIgcGVvcGxl DQo+ID4gaGF2ZSB3ZWlnaGVkIGluIG9uIHRoZSB0b3BpYyB0byB2b2ljZSBzdXBwb3J0IGZvciBh bg0KPiA+IGFyYml0cmFyeSBudW1iZXIgb2YNCj4gPiBsb2NhdGlvbiBoZWFkZXJzIChhbGJlaXQg d2l0aCBhIGltcGxlbWVudGF0aW9uIHdhcm5pbmcgdGhhdA0KPiA+IGRvaW5nIHNvIGlzDQo+ID4g bm90IGFkdmlzYWJsZSk6DQo+ID4NCj4gPiBNYXJ0aW4gVGhvbXBzb246DQo+ID4gaHR0cDovL3d3 dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcGNvcmUvY3VycmVudC9tc2cwMzU3Ni5odG1s DQo+ID4gUmljaGFyZCBCYXJuZXM6DQo+ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hp dmUvd2ViL3NpcGNvcmUvY3VycmVudC9tc2cwMzU4MC5odG1sDQo+ID4gS2VpdGggRHJhZ2U6DQo+ ID4gaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcGNvcmUvY3VycmVudC9t c2cwMzYwMC5odG1sDQo+ID4gSGFubnUgSGlldGFsYWh0aToNCj4gPiBodHRwOi8vd3d3LmlldGYu b3JnL21haWwtYXJjaGl2ZS93ZWIvc2lwY29yZS9jdXJyZW50L21zZzAzNjE5Lmh0bWwNCj4gPg0K PiA+IEFuZCB0d28gcGVvcGxlIGhhdmUgYWdyZWVkIHRvIGdvIGFsb25nIHdpdGggdGhhdCBkaXJl Y3Rpb24sIHdpdGgNCj4gPiBleHByZXNzZWQgcmVzZXJ2YXRpb25zOg0KPiA+DQo+ID4gSm9uIFBl dGVyc29uOg0KPiA+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXBjb3Jl L2N1cnJlbnQvbXNnMDM2MDEuaHRtbA0KPiA+IEphbWVzIFBvbGs6DQo+ID4gaHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL3NpcGNvcmUvY3VycmVudC9tc2cwMzYwMy5odG1sDQo+ ID4NCj4gPiBJZiBhbnkgb3RoZXIgd29ya2luZyBncm91cCBwYXJ0aWNpcGFudHMgaGF2ZSBjb21t ZW50cyBvbiB0aGlzIHRvcGljLA0KPiA+IHRoZXkgYXJlIGVuY291cmFnZWQgdG8gbWFrZSB0aGVt IHF1aWNrbHkuIExhY2tpbmcgYW55IGZ1cnRoZXINCj4gPiBpbnB1dCwgdGhlDQo+ID4gYXV0aG9y cyB3aWxsIGJlIGluc3RydWN0ZWQgdG8gcmV2aXNlIHRoZSBkb2N1bWVudCB0byBhbGxvdyBhbg0K PiA+IGFyYml0cmFyeQ0KPiA+IG51bWJlciBvZiBsb2NhdGlvbiBoZWFkZXIgZmllbGRzLCB3aXRo IGFuIGFjY29tcGFueWluZyB3YXJuaW5nIHRoYXQNCj4gPiBkb2luZyBzbyBpcyBub3QgcmVjb21t ZW5kZWQuDQo+ID4NCj4gPiAvYQ0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+ID4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gPiBzaXBjb3JlQGll dGYub3JnDQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3Jl DQo+ID4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0KDQo= From jon.peterson@neustar.biz Tue Nov 9 18:04:27 2010 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 5AE2E3A6902 for ; Tue, 9 Nov 2010 18:04:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.305 X-Spam-Level: X-Spam-Status: No, score=-102.305 tagged_above=-999 required=5 tests=[AWL=0.293, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 EVFFZE4VA8ab for ; Tue, 9 Nov 2010 18:04:22 -0800 (PST) Received: from neustar.com (mx1.neustar.com [156.154.17.104]) by core3.amsl.com (Postfix) with ESMTP id BB0553A67E3 for ; Tue, 9 Nov 2010 18:04:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1289354686; x=1604174761; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=vK8QNNkibcPvS/7USD4SuKXjKSOa7+5f1xep3OqDbBI=; b=ZmvGg4iS2m8vBfSfyXx2uiNcqeqsL1slZB9pMGnZJgaTWJoq5X5Pyb7hYB7Xhk nDe/8ViidNj5LD7G7UG4xkuA== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.39250220; Tue, 09 Nov 2010 21:04:45 -0500 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Tue, 9 Nov 2010 21:04:45 -0500 From: "Peterson, Jon" To: "sipcore@ietf.org" Date: Tue, 9 Nov 2010 21:04:39 -0500 Thread-Topic: Location-conveyance, option tags and URI scheme support Thread-Index: AcuAe6GOF4JGUmD4TEKI1iKWD+xc3A== Message-ID: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: SyrbKu4yLFscN+SAjwH1HQ== Content-Type: multipart/alternative; boundary="_000_C9001EB7480D2jonpetersonneustarbiz_" MIME-Version: 1.0 Subject: [sipcore] Location-conveyance, option tags and URI scheme support 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: Wed, 10 Nov 2010 02:04:27 -0000 --_000_C9001EB7480D2jonpetersonneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable As much as I hoped not to have to introduce any "clever" new ideas for loca= tion-conveyance, some of Mr. Elwell's comments caused us to circle round an= d think about the intended application of option tags in location-conveyanc= e, especially in conjunction with the various mechanisms intended to negoti= ate URI scheme support. For a while, I've been uncomfortable with the various error codes proposed = to negotiate URI scheme support for a couple of reasons: mostly because a U= RI scheme does not completely express the behavior that an endpoint needs t= o support. For example, what does it mean to say that an endpoint supports = SIP as a URI scheme for acquiring location by reference? That it supports S= UBSCRIBE/NOTIFY, or specifically fetch behavior, or specifically the presen= ce event package, or specifically some subset thereof? The same applies to = HTTP - one can easily imagine a bare HTTP GET for a location object, or one= can imagine a broader package like HELD. Simply articulating support for a= URI scheme seems insufficient. To invoke an overloaded term, we lack a mea= ns to support these sorts of "profiles" for delivering location by referenc= e. Meanwhile, the way the draft is written today, the use case for an option t= ag expressing support for "geolocation" is certainly murky at best. Rather = than removing the tag, however, perhaps we should replace it instead with m= ore specific tags for those "profiles." In this model, if you imagine we ha= ve a "presence" profile (and send requests with that tag in a Supported), a= nd you send location to a server that supports the "held" profile, it could= return a 421 with that "held" in a Require or what have you and inform the= UAC what it needs to send. This would also replace the proposed IANA registry of supported URI schemes= , presumably with a registry of these "profiles," which would have somethin= g roughly like Spec Required for its policy. Thoughts about whether or not we can endure this cleverness at this stage i= n the process? Backwards compatibility snafus? Jon Peterson NeuStar, Inc. --_000_C9001EB7480D2jonpetersonneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Location-conveyance, option tags and URI scheme support
As much as I hoped not to have to introduce any “clever” new id= eas for location-conveyance, some of Mr. Elwell’s comments caused us = to circle round and think about the intended application of option tags in = location-conveyance, especially in conjunction with the various mechanisms = intended to negotiate URI scheme support.

For a while, I’ve been uncomfortable with the various error codes pro= posed to negotiate URI scheme support for a couple of reasons: mostly becau= se a URI scheme does not completely express the behavior that an endpoint n= eeds to support. For example, what does it mean to say that an endpoint sup= ports SIP as a URI scheme for acquiring location by reference? That it supp= orts SUBSCRIBE/NOTIFY, or specifically fetch behavior, or specifically the = presence event package, or specifically some subset thereof? The same appli= es to HTTP – one can easily imagine a bare HTTP GET for a location ob= ject, or one can imagine a broader package like HELD. Simply articulating s= upport for a URI scheme seems insufficient. To invoke an overloaded term, w= e lack a means to support these sorts of “profiles” for deliver= ing location by reference.

Meanwhile, the way the draft is written today, the use case for an option t= ag expressing support for “geolocation” is certainly murky at b= est. Rather than removing the tag, however, perhaps we should replace it in= stead with more specific tags for those “profiles.” In this mod= el, if you imagine we have a “presence” profile (and send reque= sts with that tag in a Supported), and you send location to a server that s= upports the “held” profile, it could return a 421 with that = 220;held” in a Require or what have you and inform the UAC what it ne= eds to send.

This would also replace the proposed IANA registry of supported URI schemes= , presumably with a registry of these “profiles,” which would h= ave something roughly like Spec Required for its policy.

Thoughts about whether or not we can endure this cleverness at this stage i= n the process? Backwards compatibility snafus?

Jon Peterson
NeuStar, Inc. --_000_C9001EB7480D2jonpetersonneustarbiz_-- From christer.holmberg@ericsson.com Tue Nov 9 19:01:04 2010 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 773E33A67EC for ; Tue, 9 Nov 2010 19:01:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 PoXdZR6BV2ep for ; Tue, 9 Nov 2010 19:01:02 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id EA1BD3A67B7 for ; Tue, 9 Nov 2010 19:01:01 -0800 (PST) X-AuditID: c1b4fb3d-b7b28ae00000135b-f4-4cda0b062984 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 38.85.04955.60B0ADC4; Wed, 10 Nov 2010 04:01:26 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 10 Nov 2010 04:01:26 +0100 From: Christer Holmberg To: Andrew Allen , "pkyzivat@cisco.com" , "sipcore@ietf.org" Date: Wed, 10 Nov 2010 04:01:19 +0100 Thread-Topic: [sipcore] draft-holmberg-sipcore-proxy-feature- why not just use Supported Thread-Index: AcuAat6XIt/v9PlARv6xOHOMfSzVMAACn+BqAANhOpA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502F9C72C@ESESSCMS0356.eemea.ericsson.se> References: <4CD9E189.6050704@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: AAAAAA== Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- why not just use Supported 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: Wed, 10 Nov 2010 03:01:04 -0000 Hi, Andrew is correct: just because something isn't a "pure" proxy, it doesn't = mean it is going to modify the Contact header, Supported header etc. Also, I think the use-case (which I have presented on the list) where a pro= xy indicates that the Path address information can be used for routing requ= ests in both direction is an example of a "pure" proxy use-case. That is al= so an old problem, that we have discussed earlier every now and then. Regards, Christer =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Andrew Allen > Sent: 10. marraskuuta 2010 3:20 > To: pkyzivat@cisco.com; sipcore@ietf.org > Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature-=20 > why not just use Supported >=20 >=20 > I think the second case Paul describes is what in 3GPP is=20 > called a Routing B2BUA which sometimes behaves like a proxy=20 > and sometimes like a UA. IMHO these entities should use=20 > Record-Route to keep themselves on the path and not write=20 > their own URI in the Contact but pass the Contact header=20 > transparently. To do otherwise breaks things like GRUU and=20 > callee caps. >=20 > I support the solving in a general way of how an intermediary=20 > that provides some kind of funtionality on behalf of a UA can=20 > indicate its presence to other entities.=20 >=20 > Another use case for this is helping to solve service=20 > interaction problems where multiple application servers are=20 > involved and the service logic performed by one may need to=20 > be taken into account by the other. >=20 > I also think it is necessary that UAs can detect the presence=20 > of intermediaries such as IP-PBXs and application servers in=20 > the path of a session and obtain a URI to which they can send=20 > requests to invoke service logic at those servers without=20 > them having to overwrite the contact URI for the reasons stated above. >=20 > Andrew. >=20 > ----- Original Message ----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, November 09, 2010 07:04 PM > To: sipcore@ietf.org > Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature-=20 > why not just use Supported >=20 > I'm tempted to agree with Cullen on this. > But I think it "depends". >=20 > If the B2BUA is a "proper" UA, and inserts its own Contact=20 > address in the call, then I think Cullen's description is right. >=20 > If its a B2BUA because it messes with things a proxy cannot, but > *doesn't* modify the Contact address, then just manipulating=20 > Supported isn't enough. Then the features that *it* supports=20 > are obtainable directly only by sending a request to *it*,=20 > using the Route header, etc.=20 > to identify that address. >=20 > Its always seemed to me that a UA should always supply its=20 > own Contact address, but I've looked for verification of that=20 > in 3261 and not found it. >=20 > Thanks, > Paul >=20 > On 11/10/2010 4:42 AM, Cullen Jennings wrote: > > > > So, in my week of agreeing with Hadriel, I think he got it=20 > exactly right when he said there is pretty much no feature a=20 > "plain" proxy would need for this. If we are talking about=20 > things that would be a strict technical read be considered=20 > B2BUA even if they are implemented a lot like a proxy, then I=20 > can why something provided something like this functionality=20 > would be needed. > > > > But given this would be used by a B2BUA, I don't see why=20 > you need anything more than just normal option tags. Say a=20 > SIP message comes from A to B to C and now the response is=20 > coming back. C says it supports feature c1, c2, and c3. B=20 > knows that it can transparently forward on whatever is needed=20 > for c1, c2, but not c3 and it knows that in additional to=20 > this it can do features b4 and b5. It modifies the Supported=20 > header to have c1,c2,b4, and b5. and sends that back to A. > > > > If the real uses cases have to do with caller pref=20 > features, then B can modify those in the same way. > > > > Anyways, I think we are way way ahead of ourselves=20 > discussing mechanism before we even understand what the use=20 > cases are we are trying to solve. I'd like to see some=20 > specific real world use cases and so we can work out the real=20 > requirements. I'm expect the uses cases will contain B2BUA in=20 > the call flows - that's reality. > > > > > > On Sep 24, 2010, at 5:04 AM, Christer Holmberg wrote: > > > >> > >> > >> Hi, > >> > >> I've submitted a draft, which extends the rr-param rule,=20 > allowing proxies to indicate supported features using feature=20 > tags in Path, Record-Route etc. > >> > >> The draft can also be found at:=20 > >>=20 > http://users.piuha.net/cholmber/drafts/draft-holmberg-sipcore-proxy-f > >> eature-00.txt > >> > >> As I indicated earlier on the list, and as you can read in=20 > the draft, there is a 3GPP use-case where we believe the=20 > mechanism could be used. But, there is nothing 3GPP specific=20 > about the mechanism as such. > >> > >> Regards, > >> > >> Christer > >> _______________________________________________ > >> 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 >=20 > --------------------------------------------------------------------- > This transmission (including any attachments) may contain=20 > confidential information, privileged material (including=20 > material protected by the solicitor-client or other=20 > applicable privileges), or constitute non-public information.=20 > Any use of this information by anyone other than the intended=20 > recipient is prohibited. If you have received this=20 > transmission in error, please immediately reply to the sender=20 > and delete this information from your system. Use,=20 > dissemination, distribution, or reproduction of this=20 > transmission by unintended recipients is not authorized and=20 > may be unlawful. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From Martin.Thomson@andrew.com Tue Nov 9 19:08:42 2010 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 8378C3A680B for ; Tue, 9 Nov 2010 19:08:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.239 X-Spam-Level: X-Spam-Status: No, score=-3.239 tagged_above=-999 required=5 tests=[AWL=-0.640, BAYES_00=-2.599] 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 od8GVUTAHnqD for ; Tue, 9 Nov 2010 19:08:39 -0800 (PST) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id E43463A67F8 for ; Tue, 9 Nov 2010 19:08:38 -0800 (PST) Received: from [10.86.20.102] ([10.86.20.102]:12910 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S37921481Ab0KJDJE (ORCPT ); Tue, 9 Nov 2010 21:09:04 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 9 Nov 2010 21:09:04 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 10 Nov 2010 11:09:01 +0800 From: "Thomson, Martin" To: "Peterson, Jon" , "sipcore@ietf.org" Date: Wed, 10 Nov 2010 11:08:58 +0800 Thread-Topic: Location-conveyance, option tags and URI scheme support Thread-Index: AcuAe6GOF4JGUmD4TEKI1iKWD+xc3AAA+EWg Message-ID: <8B0A9FCBB9832F43971E38010638454F03F33652DB@SISPE7MB1.commscope.com> References: 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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] Location-conveyance, option tags and URI scheme support 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: Wed, 10 Nov 2010 03:08:42 -0000 VGhpcyBzb3VuZHMgbGlrZSBhIGdvb2QgaWRlYS4gIENsZXZlciBpcyBzb21ldGhpbmcgSSBjYW4g YXBwcmVjaWF0ZSwgZXZlbiBhdCB0aGlzIHN0YWdlLiAgVGhpcyBzaG91bGQgaW1wcm92ZSB0aGUg aW50ZXJvcGVyYWJpbGl0eSBzaXR1YXRpb24uDQoNCkkgYWxzbyByZWFsbHkgbGlrZSB0aGUgaWRl YSBvZiBjdXR0aW5nIG91dCB0aGUgZ2VvbG9jYXRpb24tZXJyb3IgaGVhZGVyLiAgVGhlcmUgd2Fz IGEgbG90IG9mIG1lY2hhbmlzbSB0aGVyZSwgZm9yIGxpdHRsZSBzaWduaWZpY2FudCB2YWx1ZS4N Cg0KVGhpbmtpbmcgYWJvdXQgdGhpcyBhIGxpdHRsZSBtb3JlIHRoZXJlIG1pZ2h0IGJlIGEgbmVl ZCBmb3IgdGhyZWUgdmFsdWVzOg0KDQpJIG5lZWQgYSBQSURGLUxPDQogIFJlcXVpcmU6IEdlb2xv Y2F0aW9uLXZhbHVlIA0KSSBuZWVkIGFuIEhUVFBbc10vSEVMRCBVUkkgDQogIFJlcXVpcmU6IEdl b2xvY2F0aW9uLXZhbHVlIA0KSSBuZWVkIGEgU0lQW3NdL3ByZXMgVVJJDQogIFJlcXVpcmU6IEdl b2xvY2F0aW9uLXByZXNlbmNlIA0KDQpJIHNlZSBsaXR0bGUgcmVhc29uIHRvIHNlcGFyYXRlbHkg aWRlbnRpZnkgSEVMRC4gIEhFTEQgZGVyZWZlcmVuY2Ugd29ya3Mgd2l0aCBIVFRQIEdFVCB3ZWxs IGVub3VnaCBhbmQgYSBIRUxELWNhcGFibGUgY2xpZW50IGNhbiByZWNvZ25pemUgYSBIRUxELWNh cGFibGUgc2VydmVyIGlmIHRoZXkgY2FyZSBhYm91dCB1c2luZyBIRUxEIChmb3IgcXVhbGl0eSBv ZiBzZXJ2aWNlIGNvbnN0cmFpbnRzIGFuZCBzbyBvbikuDQoNCkZyb20gdGhlIHBlcnNwZWN0aXZl IG9mIGxhdGUgY2hhbmdlcywgSSBleHBlY3QgdGhhdCB0aGUgZXJyb3IgaGFuZGxpbmcgY2FzZXMg YXJlIG5vdCB5ZXQgbWF0dXJlIGVub3VnaCBpbiBleGlzdGluZyBpbXBsZW1lbnRhdGlvbnMgdG8g YmUgY29uY2VybmVkLiAgSSB3aWxsIGNvbmZpcm0sIGJ1dCBkb24ndCBsZXQgdGhhdCBzdG9wIHlv dSBmcm9tIHByb2NlZWRpbmcuDQoNCi0tTWFydGluDQoNCihIb3cgZG8geW91IHNheSBPUiBpbiBh IHJlcXVpcmUgaGVhZGVyPyAgZS5nLiwgSSBuZWVkIEhUVFAgb3IgYSB2YWx1ZTsgZG8gd2UgbmVl ZCB0byBkZWZpbmUgc3BlY2lmaWMgc2VtYW50aWNzPykNCg0KT24gMjAxMC0xMS0xMCBhdCAxMDow NDozOSwgUGV0ZXJzb24sIEpvbiB3cm90ZToNCj4gDQo+IEFzIG11Y2ggYXMgSSBob3BlZCBub3Qg dG8gaGF2ZSB0byBpbnRyb2R1Y2UgYW55IOKAnGNsZXZlcuKAnSBuZXcgaWRlYXMgZm9yDQo+IGxv Y2F0aW9uLWNvbnZleWFuY2UsIHNvbWUgb2YgTXIuIEVsd2VsbOKAmXMgY29tbWVudHMgY2F1c2Vk IHVzIHRvIGNpcmNsZQ0KPiByb3VuZCBhbmQgdGhpbmsgYWJvdXQgdGhlIGludGVuZGVkIGFwcGxp Y2F0aW9uIG9mIG9wdGlvbiB0YWdzIGluDQo+IGxvY2F0aW9uLWNvbnZleWFuY2UsIGVzcGVjaWFs bHkgaW4gY29uanVuY3Rpb24gd2l0aCB0aGUgdmFyaW91cw0KPiBtZWNoYW5pc21zIGludGVuZGVk IHRvIG5lZ290aWF0ZSBVUkkgc2NoZW1lIHN1cHBvcnQuDQo+IA0KPiBGb3IgYSB3aGlsZSwgSeKA mXZlIGJlZW4gdW5jb21mb3J0YWJsZSB3aXRoIHRoZSB2YXJpb3VzIGVycm9yIGNvZGVzDQo+IHBy b3Bvc2VkIHRvIG5lZ290aWF0ZSBVUkkgc2NoZW1lIHN1cHBvcnQgZm9yIGEgY291cGxlIG9mIHJl YXNvbnM6DQo+IG1vc3RseQ0KPiBiZWNhdXNlIGEgVVJJIHNjaGVtZSBkb2VzIG5vdCBjb21wbGV0 ZWx5IGV4cHJlc3MgdGhlIGJlaGF2aW9yIHRoYXQgYW4NCj4gZW5kcG9pbnQgbmVlZHMgdG8gc3Vw cG9ydC4gRm9yIGV4YW1wbGUsIHdoYXQgZG9lcyBpdCBtZWFuIHRvIHNheSB0aGF0DQo+IGFuDQo+ IGVuZHBvaW50IHN1cHBvcnRzIFNJUCBhcyBhIFVSSSBzY2hlbWUgZm9yIGFjcXVpcmluZyBsb2Nh dGlvbiBieQ0KPiByZWZlcmVuY2U/IFRoYXQgaXQgc3VwcG9ydHMgU1VCU0NSSUJFL05PVElGWSwg b3Igc3BlY2lmaWNhbGx5IGZldGNoDQo+IGJlaGF2aW9yLCBvciBzcGVjaWZpY2FsbHkgdGhlIHBy ZXNlbmNlIGV2ZW50IHBhY2thZ2UsIG9yIHNwZWNpZmljYWxseQ0KPiBzb21lIHN1YnNldCB0aGVy ZW9mPyBUaGUgc2FtZSBhcHBsaWVzIHRvIEhUVFAg4oCTIG9uZSBjYW4gZWFzaWx5IGltYWdpbmUN Cj4gYQ0KPiBiYXJlIEhUVFAgR0VUIGZvciBhIGxvY2F0aW9uIG9iamVjdCwgb3Igb25lIGNhbiBp bWFnaW5lIGEgYnJvYWRlcg0KPiBwYWNrYWdlIGxpa2UgSEVMRC4gU2ltcGx5IGFydGljdWxhdGlu ZyBzdXBwb3J0IGZvciBhIFVSSSBzY2hlbWUgc2VlbXMNCj4gaW5zdWZmaWNpZW50LiBUbyBpbnZv a2UgYW4gb3ZlcmxvYWRlZCB0ZXJtLCB3ZSBsYWNrIGEgbWVhbnMgdG8gc3VwcG9ydA0KPiB0aGVz ZSBzb3J0cyBvZiDigJxwcm9maWxlc+KAnSBmb3IgZGVsaXZlcmluZyBsb2NhdGlvbiBieSByZWZl cmVuY2UuDQo+IA0KPiBNZWFud2hpbGUsIHRoZSB3YXkgdGhlIGRyYWZ0IGlzIHdyaXR0ZW4gdG9k YXksIHRoZSB1c2UgY2FzZSBmb3IgYW4NCj4gb3B0aW9uIHRhZyBleHByZXNzaW5nIHN1cHBvcnQg Zm9yIOKAnGdlb2xvY2F0aW9u4oCdIGlzIGNlcnRhaW5seSBtdXJreSBhdA0KPiBiZXN0LiBSYXRo ZXIgdGhhbiByZW1vdmluZyB0aGUgdGFnLCBob3dldmVyLCBwZXJoYXBzIHdlIHNob3VsZCByZXBs YWNlDQo+IGl0IGluc3RlYWQgd2l0aCBtb3JlIHNwZWNpZmljIHRhZ3MgZm9yIHRob3NlIOKAnHBy b2ZpbGVzLuKAnSBJbiB0aGlzIG1vZGVsLA0KPiBpZiB5b3UgaW1hZ2luZSB3ZSBoYXZlIGEg4oCc cHJlc2VuY2XigJ0gcHJvZmlsZSAoYW5kIHNlbmQgcmVxdWVzdHMgd2l0aA0KPiB0aGF0DQo+IHRh ZyBpbiBhIFN1cHBvcnRlZCksIGFuZCB5b3Ugc2VuZCBsb2NhdGlvbiB0byBhIHNlcnZlciB0aGF0 IHN1cHBvcnRzDQo+IHRoZQ0KPiDigJxoZWxk4oCdIHByb2ZpbGUsIGl0IGNvdWxkIHJldHVybiBh IDQyMSB3aXRoIHRoYXQg4oCcaGVsZOKAnSBpbiBhIFJlcXVpcmUgb3INCj4gd2hhdCBoYXZlIHlv dSBhbmQgaW5mb3JtIHRoZSBVQUMgd2hhdCBpdCBuZWVkcyB0byBzZW5kLg0KPiANCj4gVGhpcyB3 b3VsZCBhbHNvIHJlcGxhY2UgdGhlIHByb3Bvc2VkIElBTkEgcmVnaXN0cnkgb2Ygc3VwcG9ydGVk IFVSSQ0KPiBzY2hlbWVzLCBwcmVzdW1hYmx5IHdpdGggYSByZWdpc3RyeSBvZiB0aGVzZSDigJxw cm9maWxlcyzigJ0gd2hpY2ggd291bGQNCj4gaGF2ZSBzb21ldGhpbmcgcm91Z2hseSBsaWtlIFNw ZWMgUmVxdWlyZWQgZm9yIGl0cyBwb2xpY3kuDQo+IA0KPiBUaG91Z2h0cyBhYm91dCB3aGV0aGVy IG9yIG5vdCB3ZSBjYW4gZW5kdXJlIHRoaXMgY2xldmVybmVzcyBhdCB0aGlzDQo+IHN0YWdlIGlu IHRoZSBwcm9jZXNzPyBCYWNrd2FyZHMgY29tcGF0aWJpbGl0eSBzbmFmdXM/DQo+IA0KPiBKb24g UGV0ZXJzb24NCj4gTmV1U3RhciwgSW5jLg0KDQoNCg== From john.elwell@siemens-enterprise.com Tue Nov 9 19:32:17 2010 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 8A6FE3A672F for ; Tue, 9 Nov 2010 19:32:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.503 X-Spam-Level: X-Spam-Status: No, score=-102.503 tagged_above=-999 required=5 tests=[AWL=0.096, BAYES_00=-2.599, 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 RMq56CFY1MOn for ; Tue, 9 Nov 2010 19:32:16 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 7220D3A657C for ; Tue, 9 Nov 2010 19:32:15 -0800 (PST) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2240902; Wed, 10 Nov 2010 04:24:16 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx12-mx (Server) with ESMTP id 10AAB23F028E; Wed, 10 Nov 2010 04:24:16 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 10 Nov 2010 04:24:15 +0100 From: "Elwell, John" To: "Thomson, Martin" , "Peterson, Jon" , "sipcore@ietf.org" Date: Wed, 10 Nov 2010 04:24:10 +0100 Thread-Topic: [sipcore] Location-conveyance, option tags and URI scheme support Thread-Index: AcuAe6GOF4JGUmD4TEKI1iKWD+xc3AAA+EWgAAGMM9A= Message-ID: References: <8B0A9FCBB9832F43971E38010638454F03F33652DB@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F33652DB@SISPE7MB1.commscope.com> 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 Subject: Re: [sipcore] Location-conveyance, option tags and URI scheme support 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: Wed, 10 Nov 2010 03:32:17 -0000 Sounds like a good idea to me too. Require in a response is something that perhaps goes beyond RFC 3261, but t= here are precedents. Supported in a response might be sufficient. If there = are two you support (say value and HELD, but not SIP Presence), I don't thi= nk you could convey that semantic using Require, but you could using Suppor= ted. Putting both "value" and "HELD" in Require would imply you require the= recipient to support both. Comments on Martin's comments below:=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Thomson, Martin > Sent: 10 November 2010 03:09 > To: Peterson, Jon; sipcore@ietf.org > Subject: Re: [sipcore] Location-conveyance, option tags and=20 > URI scheme support >=20 > This sounds like a good idea. Clever is something I can=20 > appreciate, even at this stage. This should improve the=20 > interoperability situation. >=20 > I also really like the idea of cutting out the=20 > geolocation-error header. There was a lot of mechanism=20 > there, for little significant value. >=20 > Thinking about this a little more there might be a need for=20 > three values: >=20 > I need a PIDF-LO > Require: Geolocation-value=20 [JRE] I hadn't picked this one up from Jon's proposal, but it makes sense. > I need an HTTP[s]/HELD URI=20 > Require: Geolocation-value=20 > I need a SIP[s]/pres URI > Require: Geolocation-presence=20 >=20 > I see little reason to separately identify HELD. HELD=20 > dereference works with HTTP GET well enough and a=20 > HELD-capable client can recognize a HELD-capable server if=20 > they care about using HELD (for quality of service=20 > constraints and so on). [JRE] But the point of supporting HELD is that you expect a PIDF-LO in the = response. Just supporting HTTP does not necessarily mean you are able to ha= ndle PIDF-LO in a response? John >=20 > From the perspective of late changes, I expect that the error=20 > handling cases are not yet mature enough in existing=20 > implementations to be concerned. I will confirm, but don't=20 > let that stop you from proceeding. >=20 > --Martin >=20 > (How do you say OR in a require header? e.g., I need HTTP or=20 > a value; do we need to define specific semantics?) >=20 > On 2010-11-10 at 10:04:39, Peterson, Jon wrote: > >=20 > > As much as I hoped not to have to introduce any "clever"=20 > new ideas for > > location-conveyance, some of Mr. Elwell's comments caused=20 > us to circle > > round and think about the intended application of option tags in > > location-conveyance, especially in conjunction with the various > > mechanisms intended to negotiate URI scheme support. > >=20 > > For a while, I've been uncomfortable with the various error codes > > proposed to negotiate URI scheme support for a couple of reasons: > > mostly > > because a URI scheme does not completely express the=20 > behavior that an > > endpoint needs to support. For example, what does it mean=20 > to say that > > an > > endpoint supports SIP as a URI scheme for acquiring location by > > reference? That it supports SUBSCRIBE/NOTIFY, or specifically fetch > > behavior, or specifically the presence event package, or=20 > specifically > > some subset thereof? The same applies to HTTP - one can=20 > easily imagine > > a > > bare HTTP GET for a location object, or one can imagine a broader > > package like HELD. Simply articulating support for a URI=20 > scheme seems > > insufficient. To invoke an overloaded term, we lack a means=20 > to support > > these sorts of "profiles" for delivering location by reference. > >=20 > > Meanwhile, the way the draft is written today, the use case for an > > option tag expressing support for "geolocation" is=20 > certainly murky at > > best. Rather than removing the tag, however, perhaps we=20 > should replace > > it instead with more specific tags for those "profiles." In=20 > this model, > > if you imagine we have a "presence" profile (and send requests with > > that > > tag in a Supported), and you send location to a server that supports > > the > > "held" profile, it could return a 421 with that "held" in a=20 > Require or > > what have you and inform the UAC what it needs to send. > >=20 > > This would also replace the proposed IANA registry of supported URI > > schemes, presumably with a registry of these "profiles," which would > > have something roughly like Spec Required for its policy. > >=20 > > Thoughts about whether or not we can endure this cleverness at this > > stage in the process? Backwards compatibility snafus? > >=20 > > Jon Peterson > > NeuStar, Inc. >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From shida@ntt-at.com Tue Nov 9 19:50:00 2010 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 8CFC63A67F3 for ; Tue, 9 Nov 2010 19:50:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.673 X-Spam-Level: X-Spam-Status: No, score=-101.673 tagged_above=-999 required=5 tests=[AWL=-0.008, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_74=0.6, 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 zWqab0xAsf0J for ; Tue, 9 Nov 2010 19:49:59 -0800 (PST) Received: from gateway12.websitewelcome.com (gateway12.websitewelcome.com [69.93.35.2]) by core3.amsl.com (Postfix) with SMTP id 8CB163A6407 for ; Tue, 9 Nov 2010 19:49:59 -0800 (PST) Received: (qmail 18702 invoked from network); 10 Nov 2010 03:50:06 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway12.websitewelcome.com with SMTP; 10 Nov 2010 03:50:06 -0000 Received: from [130.129.128.223] (port=58725 helo=dhcp-80df.meeting.ietf.org) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PG1hN-0006DY-TC; Tue, 09 Nov 2010 21:50:20 -0600 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Wed, 10 Nov 2010 12:50:16 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <1A3940A5-123E-4FF1-8B94-76B6C5B49596@ntt-at.com> References: To: "Elwell, John" 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" Subject: Re: [sipcore] Understanding Privacy: history invoked by UAS 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: Wed, 10 Nov 2010 03:50:00 -0000 I think RFC4244 was quite vague about how privacy is=20 requested and due to that, both privacy header outside=20 H-I header or part of hi-entry are used without any clear=20 distinction. Thus for backward compatibility, I don't think we can=20 eliminate the use of Privacy:history, I think we can definitely=20 clarify the use of them by saying proxy SHOULD or MUST=20 use privacy=3Dheader and UAC uses Privacy:history.=20 I do think we should clarify the procedure of how history-info=20 is anonymized, may be something along the line as follows. 1. Setting privacy indication. UAC sets privacy by setting privacy:header or privacy:history Proxy/UAS sets privacy by setting privacy=3Dhistory in hi-entry 2. Applying privacy to request. Privacy service at the boundary of domain checks if privacy:header=20 or privacy:history exists. If privacy:history or privacy:header exists then it anonymize all the=20= hi-entry from its responsible domain by changing the hi-target-to-uri=20 to URI with anonymous.invalid.=20 If the hi-entry that is a target of anonymization and has = privacy=3Dhistory,=20 it will remove the privacy=3Dhistory after anonymizing the hi-entry. If the hi-entry is already anonymized (URI with anonymous.invalid) it=20= will leave the entry as is.=20 After anonymizing all the hi-entry from its responsible domain it will=20= remove the priv-value of "history" from Privacy header (real header). If there are no priv-value remaining in the Privacy header then it will=20= remove the Privacy header itself following the procedure in RFC3323. If there is no priv-value of "history" or "header", privacy service=20 looks through hi-entries and see if there are URI from its domain=20 with privacy=3Dhistory. For each hi-entry with privacy=3Dhistory, privacy service will = anonymize=20 the hi-target-to-uri and remove the privacy=3Dhistory after anonymizing=20= the hi-entry.=20 3. Privacy:none With regards to privacy:none, it's tad tricky because=20 as Ian said, how it's honored depends on the regulation etc.=20 Regards Shida On Nov 10, 2010, at 10:30 AM, Elwell, John wrote: > In which case we don't need Privacy: history in the response, since it = is only a partial solution? >=20 > John=20 >=20 >> -----Original Message----- >> From: Shida Schubert [mailto:shida@ntt-at.com]=20 >> Sent: 09 November 2010 06:24 >> To: Elwell, John >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] Understanding Privacy: history invoked by UAS >>=20 >>=20 >> Hi John; >>=20 >> In practice, if C cares about its privacy, there should be=20 >> a priori arrangement with the service provider or=20 >> configuration in proxy to withhold its identity. >>=20 >> This will allow the proxy sending the 4xx which sets the hi-entry=20 >> to ensure privacy is applied by setting escaped privacy header=20 >> or Privacy:header.=20 >>=20 >> Regards >> Shida=20 >>=20 >> On Nov 9, 2010, at 11:32 AM, Elwell, John wrote: >>=20 >>> Suppose a request from A is targeted initially at B, this=20 >> is mapped to C, and then to registered contact D. The UAS (D)=20 >> puts Privacy: history in the response, and therefore prevents=20 >> A learning about C and D. Fine. >>>=20 >>> Now, supposing D is not registered at the time, i.e., there=20 >> is no registered contact for C. This results in a 4xx=20 >> response to A. How do we ensure that the identity of C is not=20 >> disclosed to A, in line with what is achieved when D is registered? >>>=20 >>> John >>>=20 >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 >>=20 From Martin.Thomson@andrew.com Tue Nov 9 19:50:54 2010 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 78C373A6407 for ; Tue, 9 Nov 2010 19:50:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.148 X-Spam-Level: X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[AWL=-0.549, BAYES_00=-2.599] 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 d9cdTkJsZLYn for ; Tue, 9 Nov 2010 19:50:52 -0800 (PST) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id EA4C03A67B1 for ; Tue, 9 Nov 2010 19:50:51 -0800 (PST) Received: from [10.86.20.103] ([10.86.20.103]:17049 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S488567Ab0KJDvR (ORCPT ); Tue, 9 Nov 2010 21:51:17 -0600 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 9 Nov 2010 21:50:54 -0600 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 10 Nov 2010 11:50:50 +0800 From: "Thomson, Martin" To: "Elwell, John" , "Peterson, Jon" , "sipcore@ietf.org" Date: Wed, 10 Nov 2010 11:50:47 +0800 Thread-Topic: [sipcore] Location-conveyance, option tags and URI scheme support Thread-Index: AcuAe6GOF4JGUmD4TEKI1iKWD+xc3AAA+EWgAAGMM9AAAQptYA== Message-ID: <8B0A9FCBB9832F43971E38010638454F03F33652F2@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03F33652DB@SISPE7MB1.commscope.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] Location-conveyance, option tags and URI scheme support 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: Wed, 10 Nov 2010 03:50:54 -0000 T24gMjAxMC0xMS0xMCBhdCAxMToyNDoxMCwgRWx3ZWxsLCBKb2huIHdyb3RlOg0KPiA+IEkgc2Vl IGxpdHRsZSByZWFzb24gdG8gc2VwYXJhdGVseSBpZGVudGlmeSBIRUxELiAgSEVMRA0KPiA+IGRl cmVmZXJlbmNlIHdvcmtzIHdpdGggSFRUUCBHRVQgd2VsbCBlbm91Z2ggYW5kIGENCj4gPiBIRUxE LWNhcGFibGUgY2xpZW50IGNhbiByZWNvZ25pemUgYSBIRUxELWNhcGFibGUgc2VydmVyIGlmDQo+ ID4gdGhleSBjYXJlIGFib3V0IHVzaW5nIEhFTEQgKGZvciBxdWFsaXR5IG9mIHNlcnZpY2UNCj4g PiBjb25zdHJhaW50cyBhbmQgc28gb24pLg0KPiBbSlJFXSBCdXQgdGhlIHBvaW50IG9mIHN1cHBv cnRpbmcgSEVMRCBpcyB0aGF0IHlvdSBleHBlY3QgYSBQSURGLUxPIGluDQo+IHRoZSByZXNwb25z ZS4gSnVzdCBzdXBwb3J0aW5nIEhUVFAgZG9lcyBub3QgbmVjZXNzYXJpbHkgbWVhbiB5b3UgYXJl DQo+IGFibGUgdG8gaGFuZGxlIFBJREYtTE8gaW4gYSByZXNwb25zZT8NCg0KVGhlIHBvaW50IG9m IHN1cHBvcnRpbmcgR2VvbG9jYXRpb24taHR0cCBpcyB0aGF0IHlvdSBzdXBwb3J0IGFjcXVpc2l0 aW9uIG9mIGEgUElERi1MTyB1c2luZyBIVFRQIChhbmQgbWF5YmUgSEVMRCkuICBJdCdzIGEgY29u dGludXVtIG9mIHN1cHBvcnQgdGhhdCBkb2Vzbid0IHJlcXVpcmUgZGlzY3JldGUgc3RlcHMgKGlu IG15IG9waW5pb24pLg0KDQotLU1hcnRpbg0K From HKaplan@acmepacket.com Tue Nov 9 20:52:23 2010 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 31F0E3A67FE for ; Tue, 9 Nov 2010 20:52:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.775 X-Spam-Level: X-Spam-Status: No, score=-1.775 tagged_above=-999 required=5 tests=[AWL=0.224, BAYES_00=-2.599, J_CHICKENPOX_74=0.6] 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 iOYZZdfG00jq for ; Tue, 9 Nov 2010 20:52:22 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D80FE3A67E2 for ; Tue, 9 Nov 2010 20:52:21 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Tue, 9 Nov 2010 23:52:47 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 9 Nov 2010 23:52:47 -0500 From: Hadriel Kaplan To: Shida Schubert Date: Tue, 9 Nov 2010 23:52:43 -0500 Thread-Topic: [sipcore] Understanding Privacy: history invoked by UAS Thread-Index: AcuAkx168p1bfSMAT9G6L6ZMOBxfCw== Message-ID: <7B01FB93-0DD5-47B5-BB01-B2E6FAED3DDA@acmepacket.com> References: <1A3940A5-123E-4FF1-8B94-76B6C5B49596@ntt-at.com> In-Reply-To: <1A3940A5-123E-4FF1-8B94-76B6C5B49596@ntt-at.com> 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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Understanding Privacy: history invoked by UAS 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: Wed, 10 Nov 2010 04:52:23 -0000 Out of curiosity, will anything "break" if the anonymized H-I entries are s= imply removed? I'm not suggesting we document doing that in the draft, jus= t asking if any apps/use-cases/whatever will break if it happens. Because = my guess is some of us will just remove them, and I'd like to know if there= 's any real reason I shouldn't. -hadriel On Nov 9, 2010, at 10:50 PM, Shida Schubert wrote: >=20 > I think RFC4244 was quite vague about how privacy is=20 > requested and due to that, both privacy header outside=20 > H-I header or part of hi-entry are used without any clear=20 > distinction. >=20 > Thus for backward compatibility, I don't think we can=20 > eliminate the use of Privacy:history, I think we can definitely=20 > clarify the use of them by saying proxy SHOULD or MUST=20 > use privacy=3Dheader and UAC uses Privacy:history.=20 >=20 > I do think we should clarify the procedure of how history-info=20 > is anonymized, may be something along the line as follows. >=20 > 1. Setting privacy indication. >=20 > UAC sets privacy by setting privacy:header or privacy:history > Proxy/UAS sets privacy by setting privacy=3Dhistory in hi-entry >=20 > 2. Applying privacy to request. >=20 > Privacy service at the boundary of domain checks if privacy:header=20 > or privacy:history exists. >=20 > If privacy:history or privacy:header exists then it anonymize all the=20 > hi-entry from its responsible domain by changing the hi-target-to-uri=20 > to URI with anonymous.invalid.=20 >=20 > If the hi-entry that is a target of anonymization and has privacy=3Dhisto= ry,=20 > it will remove the privacy=3Dhistory after anonymizing the hi-entry. >=20 > If the hi-entry is already anonymized (URI with anonymous.invalid) it=20 > will leave the entry as is.=20 >=20 > After anonymizing all the hi-entry from its responsible domain it will=20 > remove the priv-value of "history" from Privacy header (real header). >=20 > If there are no priv-value remaining in the Privacy header then it will=20 > remove the Privacy header itself following the procedure in RFC3323. >=20 > If there is no priv-value of "history" or "header", privacy service=20 > looks through hi-entries and see if there are URI from its domain=20 > with privacy=3Dhistory. >=20 > For each hi-entry with privacy=3Dhistory, privacy service will anonymize= =20 > the hi-target-to-uri and remove the privacy=3Dhistory after anonymizing=20 > the hi-entry.=20 >=20 > 3. Privacy:none >=20 > With regards to privacy:none, it's tad tricky because=20 > as Ian said, how it's honored depends on the regulation etc.=20 >=20 > Regards > Shida >=20 > On Nov 10, 2010, at 10:30 AM, Elwell, John wrote: >=20 >> In which case we don't need Privacy: history in the response, since it i= s only a partial solution? >>=20 >> John=20 >>=20 >>> -----Original Message----- >>> From: Shida Schubert [mailto:shida@ntt-at.com]=20 >>> Sent: 09 November 2010 06:24 >>> To: Elwell, John >>> Cc: sipcore@ietf.org >>> Subject: Re: [sipcore] Understanding Privacy: history invoked by UAS >>>=20 >>>=20 >>> Hi John; >>>=20 >>> In practice, if C cares about its privacy, there should be=20 >>> a priori arrangement with the service provider or=20 >>> configuration in proxy to withhold its identity. >>>=20 >>> This will allow the proxy sending the 4xx which sets the hi-entry=20 >>> to ensure privacy is applied by setting escaped privacy header=20 >>> or Privacy:header.=20 >>>=20 >>> Regards >>> Shida=20 >>>=20 >>> On Nov 9, 2010, at 11:32 AM, Elwell, John wrote: >>>=20 >>>> Suppose a request from A is targeted initially at B, this=20 >>> is mapped to C, and then to registered contact D. The UAS (D)=20 >>> puts Privacy: history in the response, and therefore prevents=20 >>> A learning about C and D. Fine. >>>>=20 >>>> Now, supposing D is not registered at the time, i.e., there=20 >>> is no registered contact for C. This results in a 4xx=20 >>> response to A. How do we ensure that the identity of C is not=20 >>> disclosed to A, in line with what is achieved when D is registered? >>>>=20 >>>> John >>>>=20 >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>=20 >>>=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From shida@ntt-at.com Tue Nov 9 21:46:35 2010 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 06B913A68AF for ; Tue, 9 Nov 2010 21:46:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.672 X-Spam-Level: X-Spam-Status: No, score=-101.672 tagged_above=-999 required=5 tests=[AWL=-0.007, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_74=0.6, 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 3clehivc2QN4 for ; Tue, 9 Nov 2010 21:46:34 -0800 (PST) Received: from gateway05.websitewelcome.com (gateway05.websitewelcome.com [69.93.243.11]) by core3.amsl.com (Postfix) with SMTP id D25BA3A68A3 for ; Tue, 9 Nov 2010 21:46:33 -0800 (PST) Received: (qmail 29797 invoked from network); 10 Nov 2010 05:46:26 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway05.websitewelcome.com with SMTP; 10 Nov 2010 05:46:26 -0000 Received: from [130.129.128.223] (port=60503 helo=dhcp-80df.meeting.ietf.org) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PG3WG-0002rP-M3; Tue, 09 Nov 2010 23:46:54 -0600 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <7B01FB93-0DD5-47B5-BB01-B2E6FAED3DDA@acmepacket.com> Date: Wed, 10 Nov 2010 14:46:53 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <5B516382-FED2-4AE0-A17D-81C04B04E843@ntt-at.com> References: <1A3940A5-123E-4FF1-8B94-76B6C5B49596@ntt-at.com> <7B01FB93-0DD5-47B5-BB01-B2E6FAED3DDA@acmepacket.com> To: Hadriel Kaplan 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" Subject: Re: [sipcore] Understanding Privacy: history invoked by UAS 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: Wed, 10 Nov 2010 05:46:35 -0000 If you remove an entry or entries, I guess you may end=20 up with a gap in index and depending on when and how=20 much is removed, the index can deliver a false=20 representation of request path (if 1.1 and 1.1.1 was=20 removed entity receiving the request will add hi-entry=20 probably with an index of 1.1, missing 2 hops) and=20 may provide an erroneous "forwarding count" etc.=20 But this is something that would happen already with=20 RFC4244.=20 RFC4244bis enforces privacy service to anonymize=20 the hi-entry by changing the hi-target-to-uri into=20 anonymized URI and tries to prohibit (at least on the=20 specification) privacy service from removing the hi-entry.=20 RFC4244 on the other hand, was pretty flexible with=20 how privacy service would conduct anonymization,=20 it didn't prohibit privacy service from removing the=20 hi-entry. So I don't think anything would break as things are=20 working now without this enforcement added in=20 RFC4244bis. I think in most deployment where this is=20 important, how hi-entry is anonymized is probably=20 enforced and consistent within the environment where=20 it matters.=20 =20 Regards Shida On Nov 10, 2010, at 1:52 PM, Hadriel Kaplan wrote: >=20 > Out of curiosity, will anything "break" if the anonymized H-I entries = are simply removed? I'm not suggesting we document doing that in the = draft, just asking if any apps/use-cases/whatever will break if it = happens. Because my guess is some of us will just remove them, and I'd = like to know if there's any real reason I shouldn't. >=20 > -hadriel >=20 > On Nov 9, 2010, at 10:50 PM, Shida Schubert wrote: >=20 >>=20 >> I think RFC4244 was quite vague about how privacy is=20 >> requested and due to that, both privacy header outside=20 >> H-I header or part of hi-entry are used without any clear=20 >> distinction. >>=20 >> Thus for backward compatibility, I don't think we can=20 >> eliminate the use of Privacy:history, I think we can definitely=20 >> clarify the use of them by saying proxy SHOULD or MUST=20 >> use privacy=3Dheader and UAC uses Privacy:history.=20 >>=20 >> I do think we should clarify the procedure of how history-info=20 >> is anonymized, may be something along the line as follows. >>=20 >> 1. Setting privacy indication. >>=20 >> UAC sets privacy by setting privacy:header or privacy:history >> Proxy/UAS sets privacy by setting privacy=3Dhistory in hi-entry >>=20 >> 2. Applying privacy to request. >>=20 >> Privacy service at the boundary of domain checks if privacy:header=20 >> or privacy:history exists. >>=20 >> If privacy:history or privacy:header exists then it anonymize all the=20= >> hi-entry from its responsible domain by changing the hi-target-to-uri=20= >> to URI with anonymous.invalid.=20 >>=20 >> If the hi-entry that is a target of anonymization and has = privacy=3Dhistory,=20 >> it will remove the privacy=3Dhistory after anonymizing the hi-entry. >>=20 >> If the hi-entry is already anonymized (URI with anonymous.invalid) it=20= >> will leave the entry as is.=20 >>=20 >> After anonymizing all the hi-entry from its responsible domain it = will=20 >> remove the priv-value of "history" from Privacy header (real header). >>=20 >> If there are no priv-value remaining in the Privacy header then it = will=20 >> remove the Privacy header itself following the procedure in RFC3323. >>=20 >> If there is no priv-value of "history" or "header", privacy service=20= >> looks through hi-entries and see if there are URI from its domain=20 >> with privacy=3Dhistory. >>=20 >> For each hi-entry with privacy=3Dhistory, privacy service will = anonymize=20 >> the hi-target-to-uri and remove the privacy=3Dhistory after = anonymizing=20 >> the hi-entry.=20 >>=20 >> 3. Privacy:none >>=20 >> With regards to privacy:none, it's tad tricky because=20 >> as Ian said, how it's honored depends on the regulation etc.=20 >>=20 >> Regards >> Shida >>=20 >> On Nov 10, 2010, at 10:30 AM, Elwell, John wrote: >>=20 >>> In which case we don't need Privacy: history in the response, since = it is only a partial solution? >>>=20 >>> John=20 >>>=20 >>>> -----Original Message----- >>>> From: Shida Schubert [mailto:shida@ntt-at.com]=20 >>>> Sent: 09 November 2010 06:24 >>>> To: Elwell, John >>>> Cc: sipcore@ietf.org >>>> Subject: Re: [sipcore] Understanding Privacy: history invoked by = UAS >>>>=20 >>>>=20 >>>> Hi John; >>>>=20 >>>> In practice, if C cares about its privacy, there should be=20 >>>> a priori arrangement with the service provider or=20 >>>> configuration in proxy to withhold its identity. >>>>=20 >>>> This will allow the proxy sending the 4xx which sets the hi-entry=20= >>>> to ensure privacy is applied by setting escaped privacy header=20 >>>> or Privacy:header.=20 >>>>=20 >>>> Regards >>>> Shida=20 >>>>=20 >>>> On Nov 9, 2010, at 11:32 AM, Elwell, John wrote: >>>>=20 >>>>> Suppose a request from A is targeted initially at B, this=20 >>>> is mapped to C, and then to registered contact D. The UAS (D)=20 >>>> puts Privacy: history in the response, and therefore prevents=20 >>>> A learning about C and D. Fine. >>>>>=20 >>>>> Now, supposing D is not registered at the time, i.e., there=20 >>>> is no registered contact for C. This results in a 4xx=20 >>>> response to A. How do we ensure that the identity of C is not=20 >>>> disclosed to A, in line with what is achieved when D is registered? >>>>>=20 >>>>> John >>>>>=20 >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>=20 >>>>=20 >>=20 >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >=20 From HKaplan@acmepacket.com Tue Nov 9 22:38:34 2010 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 3CE3D3A6960 for ; Tue, 9 Nov 2010 22:38:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.092 X-Spam-Level: X-Spam-Status: No, score=-2.092 tagged_above=-999 required=5 tests=[AWL=0.507, BAYES_00=-2.599] 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 bXxvloaeTimN for ; Tue, 9 Nov 2010 22:37:39 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5CD0B3A691C for ; Tue, 9 Nov 2010 22:37:39 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 10 Nov 2010 01:38:02 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 10 Nov 2010 01:38:01 -0500 From: Hadriel Kaplan To: Cullen Jennings Date: Wed, 10 Nov 2010 01:37:58 -0500 Thread-Topic: [sipcore] draft-holmberg-sipcore-proxy-feature- why not just use Supported Thread-Index: AcuAodI2w+i/09kCRkWdnmsmNq/vOw== Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A058501703422@ESESSCMS0356.eemea.ericsson.se> <4C936714.2040808@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501703523@ESESSCMS0356.eemea.ericsson.se>, <4C936E79.3070906@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8B@ESESSCMS0356.eemea.ericsson.se>, <4C938ED5.10507@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8E@ESESSCMS0356.eemea.ericsson.se>, <4C93E4DE.9070802@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA92@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058501769F3A@ESESSCMS0356.eemea.ericsson.se> 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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- why not just use Supported 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: Wed, 10 Nov 2010 06:38:35 -0000 Not to contradict myself, but hey it's a new week. :) A rationale for it could be the cases in which a proxy is a proxy, but swit= ches to b2bua behavior in certain cases. (Paul's regular reminder that bein= g a proxy vs. a b2bua is a dynamic role not a permanent system type) For e= xample a proxy doing privacy service, or 3pcc for certain call cases, or a = generating BYE due to rfc4028 timeouts. So in the Register/Invite such a p= roxy would be a proxy, while during certain session/events it may behave as= a b2bua? But it would be good to see/discuss/explain/flesh-out example use-cases. (i= .e., "the problem") -hadriel On Nov 9, 2010, at 3:42 PM, Cullen Jennings wrote: >=20 > So, in my week of agreeing with Hadriel, I think he got it exactly right = when he said there is pretty much no feature a "plain" proxy would need for= this. If we are talking about things that would be a strict technical read= be considered B2BUA even if they are implemented a lot like a proxy, then = I can why something provided something like this functionality would be nee= ded.=20 >=20 > But given this would be used by a B2BUA, I don't see why you need anythin= g more than just normal option tags. Say a SIP message comes from A to B to= C and now the response is coming back. C says it supports feature c1, c2, = and c3. B knows that it can transparently forward on whatever is needed for= c1, c2, but not c3 and it knows that in additional to this it can do featu= res b4 and b5. It modifies the Supported header to have c1,c2,b4, and b5. a= nd sends that back to A.=20 >=20 > If the real uses cases have to do with caller pref features, then B can m= odify those in the same way.=20 >=20 > Anyways, I think we are way way ahead of ourselves discussing mechanism b= efore we even understand what the use cases are we are trying to solve. I'd= like to see some specific real world use cases and so we can work out the = real requirements. I'm expect the uses cases will contain B2BUA in the call= flows - that's reality.=20 >=20 >=20 > On Sep 24, 2010, at 5:04 AM, Christer Holmberg wrote: >=20 >>=20 >>=20 >> Hi, >>=20 >> I've submitted a draft, which extends the rr-param rule, allowing proxie= s to indicate supported features using feature tags in Path, Record-Route e= tc. >>=20 >> The draft can also be found at: http://users.piuha.net/cholmber/drafts/d= raft-holmberg-sipcore-proxy-feature-00.txt >>=20 >> As I indicated earlier on the list, and as you can read in the draft, th= ere is a 3GPP use-case where we believe the mechanism could be used. But, t= here is nothing 3GPP specific about the mechanism as such. >>=20 >> Regards, >>=20 >> Christer >> _______________________________________________ >> 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 From shida@ntt-at.com Tue Nov 9 23:21:30 2010 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 892EF3A67F9 for ; Tue, 9 Nov 2010 23:21:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.971 X-Spam-Level: X-Spam-Status: No, score=-101.971 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, 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 ZiOJ4uhnxZcb for ; Tue, 9 Nov 2010 23:21:29 -0800 (PST) Received: from gateway14.websitewelcome.com (gateway14.websitewelcome.com [69.41.245.8]) by core3.amsl.com (Postfix) with SMTP id 19F4D3A6864 for ; Tue, 9 Nov 2010 23:21:29 -0800 (PST) Received: (qmail 17537 invoked from network); 10 Nov 2010 07:22:53 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway14.websitewelcome.com with SMTP; 10 Nov 2010 07:22:53 -0000 Received: from [130.129.116.143] (port=62301 helo=dhcp-748f.meeting.ietf.org) by gator465.hostgator.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1PG502-000771-UQ; Wed, 10 Nov 2010 01:21:49 -0600 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: Date: Wed, 10 Nov 2010 16:21:45 +0900 Content-Transfer-Encoding: quoted-printable Message-Id: <1FAEBF56-548C-4B4A-BD91-E4C23E54DD6C@ntt-at.com> References: <7F2072F1E0DE894DA4B517B93C6A058501703422@ESESSCMS0356.eemea.ericsson.se> <4C936714.2040808@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501703523@ESESSCMS0356.eemea.ericsson.se>, <4C936E79.3070906@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8B@ESESSCMS0356.eemea.ericsson.se>, <4C938ED5.10507@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8E@ESESSCMS0356.eemea.ericsson.se>, <4C93E4DE.9070802@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA92@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058501769F3A@ESESSCMS0356.eemea.ericsson.se> To: Hadriel Kaplan 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" Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- why not just use Supported 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: Wed, 10 Nov 2010 07:21:30 -0000 One example may be an emergency call, AFAIK for=20 emergency call defined in ECRIT to work, there are many=20 features that are required from proxy(providing location,=20 inserting sos URN, possibly looking up LoST etc.),=20 especially when client doesn't support ECRIT at all.=20 I don't foresee simultaneous global deployment of=20 ECRIT, so knowing if the roaming domain supports=20 ECRIT may be important, so home network knows=20 whether it can delegate the handling of emergency=20 call.=20 Regards Shida On Nov 10, 2010, at 3:37 PM, Hadriel Kaplan wrote: >=20 > Not to contradict myself, but hey it's a new week. :) > A rationale for it could be the cases in which a proxy is a proxy, but = switches to b2bua behavior in certain cases. (Paul's regular reminder = that being a proxy vs. a b2bua is a dynamic role not a permanent system = type) For example a proxy doing privacy service, or 3pcc for certain = call cases, or a generating BYE due to rfc4028 timeouts. So in the = Register/Invite such a proxy would be a proxy, while during certain = session/events it may behave as a b2bua? >=20 > But it would be good to see/discuss/explain/flesh-out example = use-cases. (i.e., "the problem") >=20 > -hadriel >=20 > On Nov 9, 2010, at 3:42 PM, Cullen Jennings wrote: >=20 >>=20 >> So, in my week of agreeing with Hadriel, I think he got it exactly = right when he said there is pretty much no feature a "plain" proxy would = need for this. If we are talking about things that would be a strict = technical read be considered B2BUA even if they are implemented a lot = like a proxy, then I can why something provided something like this = functionality would be needed.=20 >>=20 >> But given this would be used by a B2BUA, I don't see why you need = anything more than just normal option tags. Say a SIP message comes from = A to B to C and now the response is coming back. C says it supports = feature c1, c2, and c3. B knows that it can transparently forward on = whatever is needed for c1, c2, but not c3 and it knows that in = additional to this it can do features b4 and b5. It modifies the = Supported header to have c1,c2,b4, and b5. and sends that back to A.=20 >>=20 >> If the real uses cases have to do with caller pref features, then B = can modify those in the same way.=20 >>=20 >> Anyways, I think we are way way ahead of ourselves discussing = mechanism before we even understand what the use cases are we are trying = to solve. I'd like to see some specific real world use cases and so we = can work out the real requirements. I'm expect the uses cases will = contain B2BUA in the call flows - that's reality.=20 >>=20 >>=20 >> On Sep 24, 2010, at 5:04 AM, Christer Holmberg wrote: >>=20 >>>=20 >>>=20 >>> Hi, >>>=20 >>> I've submitted a draft, which extends the rr-param rule, allowing = proxies to indicate supported features using feature tags in Path, = Record-Route etc. >>>=20 >>> The draft can also be found at: = http://users.piuha.net/cholmber/drafts/draft-holmberg-sipcore-proxy-featur= e-00.txt >>>=20 >>> As I indicated earlier on the list, and as you can read in the = draft, there is a 3GPP use-case where we believe the mechanism could be = used. But, there is nothing 3GPP specific about the mechanism as such. >>>=20 >>> Regards, >>>=20 >>> Christer >>> _______________________________________________ >>> 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 From john.elwell@siemens-enterprise.com Wed Nov 10 01:09:05 2010 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 83B9F3A69DF for ; Wed, 10 Nov 2010 01:09:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.508 X-Spam-Level: X-Spam-Status: No, score=-102.508 tagged_above=-999 required=5 tests=[AWL=0.091, BAYES_00=-2.599, 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 tGIz7TZOfEIC for ; Wed, 10 Nov 2010 01:09:04 -0800 (PST) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 69AB53A69D3 for ; Wed, 10 Nov 2010 01:09:04 -0800 (PST) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-2243193; Wed, 10 Nov 2010 10:09:25 +0100 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id A0A4B1EB82AB; Wed, 10 Nov 2010 10:09:25 +0100 (CET) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Wed, 10 Nov 2010 10:09:25 +0100 From: "Elwell, John" To: "Thomson, Martin" , "Peterson, Jon" , "sipcore@ietf.org" Date: Wed, 10 Nov 2010 10:09:24 +0100 Thread-Topic: [sipcore] Location-conveyance, option tags and URI scheme support Thread-Index: AcuAe6GOF4JGUmD4TEKI1iKWD+xc3AAA+EWgAAGMM9AAAQptYAALQckg Message-ID: References: <8B0A9FCBB9832F43971E38010638454F03F33652DB@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F03F33652F2@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F33652F2@SISPE7MB1.commscope.com> 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 Subject: Re: [sipcore] Location-conveyance, option tags and URI scheme support 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: Wed, 10 Nov 2010 09:09:05 -0000 OK, I go along with your expert opinion on this. John=20 > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]=20 > Sent: 10 November 2010 03:51 > To: Elwell, John; Peterson, Jon; sipcore@ietf.org > Subject: RE: [sipcore] Location-conveyance, option tags and=20 > URI scheme support >=20 > On 2010-11-10 at 11:24:10, Elwell, John wrote: > > > I see little reason to separately identify HELD. HELD > > > dereference works with HTTP GET well enough and a > > > HELD-capable client can recognize a HELD-capable server if > > > they care about using HELD (for quality of service > > > constraints and so on). > > [JRE] But the point of supporting HELD is that you expect a=20 > PIDF-LO in > > the response. Just supporting HTTP does not necessarily mean you are > > able to handle PIDF-LO in a response? >=20 > The point of supporting Geolocation-http is that you support=20 > acquisition of a PIDF-LO using HTTP (and maybe HELD). It's a=20 > continuum of support that doesn't require discrete steps (in=20 > my opinion). >=20 > --Martin > = From dworley@avaya.com Wed Nov 10 01:11:27 2010 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 6A4EA3A69E0 for ; Wed, 10 Nov 2010 01:11:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.317 X-Spam-Level: X-Spam-Status: No, score=-102.317 tagged_above=-999 required=5 tests=[AWL=0.282, BAYES_00=-2.599, 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 4njaqyPXDNid for ; Wed, 10 Nov 2010 01:11:21 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id C5B943A69DF for ; Wed, 10 Nov 2010 01:11:20 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPvv2UzGmAcF/2dsb2JhbACiNHGiVgKZB4VKBIRaiSI X-IronPort-AV: E=Sophos;i="4.59,177,1288584000"; d="scan'208";a="249348839" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 10 Nov 2010 04:11:46 -0500 X-IronPort-AV: E=Sophos;i="4.59,177,1288584000"; d="scan'208";a="538751161" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 10 Nov 2010 04:11:46 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Wed, 10 Nov 2010 04:11:46 -0500 From: "Worley, Dale R (Dale)" To: Christer Holmberg , "sipcore@ietf.org" Date: Wed, 10 Nov 2010 04:11:45 -0500 Thread-Topic: [sipcore] Proxy feature tag use-case: capability to use Path header field information in both directions Thread-Index: Actx3YGO+cBNKGQcR3CDz5aaOmQMSAO2PNyn Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A058502E8A90B@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502E8A90B@ESESSCMS0356.eemea.ericsson.se> 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 Subject: Re: [sipcore] Proxy feature tag use-case: capability to use Path header field information in both directions 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: Wed, 10 Nov 2010 09:11:28 -0000 ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Chri= ster Holmberg [christer.holmberg@ericsson.com] PROBLEM: ----------------- Many of you may remember the discussions we've had every now and then regar= ding issues of building a Service-Route. The RFC recommends against intermediaries inserting themselves in the Servi= ce-Route of the REGISTER response. In addition, the registrar cannot assume that the Path header(s) received i= n the REGISTER request can be used by the registrar to build the Service-Ro= ute, so often the only instane in the Service-Route is the registrar itself= . In addition, the UA cannot assume that the Path header(s) received in the R= EGISTER response can be used to build a route for initial dialog or stand-a= lone SIP requests. The reasons is that Path by definition only provides rou= ting information for the registrar-to-UA direction. So, today, if initial dialog or stand-alone SIP requests are to be routed v= ia specific intermediaries, it has to be done by configuration, since neith= er the Service-Route or Path can be used to build the route. ________________________________________ It seems to me that no manipulation of the Path header (as seen by the regi= strar) is useful for solving the problem of building a suitable Service-Rou= te. There are two cases: In the first case, the registrar, if it receives an I= NVITE (for example) is capable of processing it correctly or sending it to = some element that can. In this case, the UA does not need a Service-Route,= as it can send the INVITE by the same mechanism that it used to send the R= EGISTER. In the second case, where the INVITE must be routed to a different element = than the REGISTER, the incoming Path value seen by the registrar is not use= ful for constructing a suitable Service-Route, because the Path values desc= ribe how a request is routed to the registrar, not the service proxy. Knowing that the Path can be used in the UA-to-registrar direction (as well= as the registrar-to-UA direction) tells the UA something that it *already = knows*, viz., how to get requests to the registrar. Dale From pkyzivat@cisco.com Wed Nov 10 01:29:55 2010 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 A40FC3A69AF for ; Wed, 10 Nov 2010 01:29:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.182 X-Spam-Level: X-Spam-Status: No, score=-110.182 tagged_above=-999 required=5 tests=[AWL=-0.183, BAYES_00=-2.599, J_CHICKENPOX_74=0.6, RCVD_IN_DNSWL_HI=-8, 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 rZ1l6zAcJcdM for ; Wed, 10 Nov 2010 01:29:54 -0800 (PST) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id 7628F3A6897 for ; Wed, 10 Nov 2010 01:29:54 -0800 (PST) Authentication-Results: sj-iport-3.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAC712UxAaMHG/2dsb2JhbACiNHGgXpsTgnKCWASEWIV/gww X-IronPort-AV: E=Sophos;i="4.59,177,1288569600"; d="scan'208";a="246582045" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-3.cisco.com with ESMTP; 10 Nov 2010 09:30:05 +0000 Received: from [10.75.234.201] (hkidc-vpn-client-234-201.cisco.com [10.75.234.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAA9U1nb026127 for ; Wed, 10 Nov 2010 09:30:03 GMT Message-ID: <4CDA6617.5010801@cisco.com> Date: Wed, 10 Nov 2010 17:29:59 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: sipcore@ietf.org References: <1A3940A5-123E-4FF1-8B94-76B6C5B49596@ntt-at.com> In-Reply-To: <1A3940A5-123E-4FF1-8B94-76B6C5B49596@ntt-at.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Understanding Privacy: history invoked by UAS 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: Wed, 10 Nov 2010 09:29:55 -0000 Inline On 11/10/2010 11:50 AM, Shida Schubert wrote: > > I think RFC4244 was quite vague about how privacy is > requested and due to that, both privacy header outside > H-I header or part of hi-entry are used without any clear > distinction. > > Thus for backward compatibility, I don't think we can > eliminate the use of Privacy:history, I think we can definitely > clarify the use of them by saying proxy SHOULD or MUST > use privacy=header and UAC uses Privacy:history. > > I do think we should clarify the procedure of how history-info > is anonymized, may be something along the line as follows. What you outline here is a great improvement. > 1. Setting privacy indication. > > UAC sets privacy by setting privacy:header or privacy:history > Proxy/UAS sets privacy by setting privacy=history in hi-entry > > 2. Applying privacy to request. > > Privacy service at the boundary of domain checks if privacy:header > or privacy:history exists. > > If privacy:history or privacy:header exists then it anonymize all the > hi-entry from its responsible domain by changing the hi-target-to-uri > to URI with anonymous.invalid. > > If the hi-entry that is a target of anonymization and has privacy=history, > it will remove the privacy=history after anonymizing the hi-entry. > > If the hi-entry is already anonymized (URI with anonymous.invalid) it > will leave the entry as is. > > After anonymizing all the hi-entry from its responsible domain it will > remove the priv-value of "history" from Privacy header (real header). > > If there are no priv-value remaining in the Privacy header then it will > remove the Privacy header itself following the procedure in RFC3323. > > If there is no priv-value of "history" or "header", privacy service > looks through hi-entries and see if there are URI from its domain > with privacy=history. > > For each hi-entry with privacy=history, privacy service will anonymize > the hi-target-to-uri and remove the privacy=history after anonymizing > the hi-entry. > > 3. Privacy:none > > With regards to privacy:none, it's tad tricky because > as Ian said, how it's honored depends on the regulation etc. ISTM that privacy:none is pretty explicit about how it is to be implemented. Either you comply or you don't. If you feel that allowing the request to proceed while complying with privacy:none is contrary to your policy, then you have the option of failing the call, and just be up front with your users that you don't permit them to use privacy:none. Then they can decide if they still want to do business with you. Thanks, Paul > Regards > Shida > > On Nov 10, 2010, at 10:30 AM, Elwell, John wrote: > >> In which case we don't need Privacy: history in the response, since it is only a partial solution? >> >> John >> >>> -----Original Message----- >>> From: Shida Schubert [mailto:shida@ntt-at.com] >>> Sent: 09 November 2010 06:24 >>> To: Elwell, John >>> Cc: sipcore@ietf.org >>> Subject: Re: [sipcore] Understanding Privacy: history invoked by UAS >>> >>> >>> Hi John; >>> >>> In practice, if C cares about its privacy, there should be >>> a priori arrangement with the service provider or >>> configuration in proxy to withhold its identity. >>> >>> This will allow the proxy sending the 4xx which sets the hi-entry >>> to ensure privacy is applied by setting escaped privacy header >>> or Privacy:header. >>> >>> Regards >>> Shida >>> >>> On Nov 9, 2010, at 11:32 AM, Elwell, John wrote: >>> >>>> Suppose a request from A is targeted initially at B, this >>> is mapped to C, and then to registered contact D. The UAS (D) >>> puts Privacy: history in the response, and therefore prevents >>> A learning about C and D. Fine. >>>> >>>> Now, supposing D is not registered at the time, i.e., there >>> is no registered contact for C. This results in a 4xx >>> response to A. How do we ensure that the identity of C is not >>> disclosed to A, in line with what is achieved when D is registered? >>>> >>>> John >>>> >>>> _______________________________________________ >>>> 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 > From dworley@avaya.com Wed Nov 10 01:32:19 2010 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 2F4C73A6A95 for ; Wed, 10 Nov 2010 01:32:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.334 X-Spam-Level: X-Spam-Status: No, score=-102.334 tagged_above=-999 required=5 tests=[AWL=0.265, BAYES_00=-2.599, 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 5pd9eIgobKDb for ; Wed, 10 Nov 2010 01:32:12 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id CC69B3A6A89 for ; Wed, 10 Nov 2010 01:32:02 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANf12UyHCzI1/2dsb2JhbACiNHGicwKZA4VKBIRaiSI X-IronPort-AV: E=Sophos;i="4.59,177,1288584000"; d="scan'208";a="44856449" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 10 Nov 2010 04:32:05 -0500 X-IronPort-AV: E=Sophos;i="4.59,177,1288584000"; d="scan'208";a="536248751" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 10 Nov 2010 04:31:30 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Wed, 10 Nov 2010 04:31:29 -0500 From: "Worley, Dale R (Dale)" To: Cullen Jennings , "sipcore@ietf.org" Date: Wed, 10 Nov 2010 04:27:00 -0500 Thread-Topic: [sipcore] draft-holmberg-sipcore-proxy-feature- why not just use Supported Thread-Index: AcuATo5opL7VcYtzQX+LAIL4E9EdAgAat9Au Message-ID: References: <7F2072F1E0DE894DA4B517B93C6A058501703422@ESESSCMS0356.eemea.ericsson.se> <4C936714.2040808@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058501703523@ESESSCMS0356.eemea.ericsson.se>, <4C936E79.3070906@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8B@ESESSCMS0356.eemea.ericsson.se>, <4C938ED5.10507@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA8E@ESESSCMS0356.eemea.ericsson.se>, <4C93E4DE.9070802@cisco.com> <7F2072F1E0DE894DA4B517B93C6A0585015BCA92@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A058501769F3A@ESESSCMS0356.eemea.ericsson.se>, 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 Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- why not just use Supported 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: Wed, 10 Nov 2010 09:32:19 -0000 ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Cull= en Jennings [fluffy@cisco.com] But given this would be used by a B2BUA, I don't see why you need anything = more than just normal option tags. Say a SIP message comes from A to B to C= and now the response is coming back. C says it supports feature c1, c2, an= d c3. B knows that it can transparently forward on whatever is needed for c= 1, c2, but not c3 and it knows that in additional to this it can do feature= s b4 and b5. It modifies the Supported header to have c1,c2,b4, and b5. and= sends that back to A. _______________________________________________ The use cases seem to revolve around the dialog passing through a chain of = quasi-proxies, where one quasi-proxy needs to know if it should perform a p= articular function, or if it can delegate performing the function to a down= stream quasi-proxy. (A quasi-proxy is an element that generally acts like = a proxy, but at times performs actions that a proxy is forbidden to perform= .) The "feature tags" seem to be envisioned to be from the same namespace as c= aller-preference feature tags, but to describe entirely independent feature= s. So it's not entirely clear why that particular namespace is chosen as t= he features aren't intended to be UA features. I think Cullen's suggestion is a good one. If quasi-proxy C implements a f= eature, it can insert "Supported: feature-foo" into the response to an INVI= TE. Then quasi-proxy B can see that it can delegate feature-foo actions do= wnstream. B doesn't need to know *which* downstream quasi-proxy will imple= ment the feature. Dale From taisto.qvist@ericsson.com Wed Nov 10 01:31:37 2010 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 546803A6A89 for ; Wed, 10 Nov 2010 01:31:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.999 X-Spam-Level: X-Spam-Status: No, score=-5.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4] 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 IyDXRsNwLXkJ for ; Wed, 10 Nov 2010 01:31:36 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 7D5273A6897 for ; Wed, 10 Nov 2010 01:31:30 -0800 (PST) X-AuditID: c1b4fb39-b7b54ae000003464-0a-4cda668b51ac Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D6.AD.13412.B866ADC4; Wed, 10 Nov 2010 10:31:56 +0100 (CET) Received: from ESESSCMS0351.eemea.ericsson.se ([169.254.1.175]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 10 Nov 2010 10:31:55 +0100 From: Taisto Qvist To: "sipcore@ietf.org" Date: Wed, 10 Nov 2010 10:31:54 +0100 Thread-Topic: draft-ietf-sipcore-reinvite-06 and new contact in 2xx to *inital* invite Thread-Index: AcuAuhzOVcSGX/UmT9ieOdD0TB0HPg== Message-ID: <613AADD0FA18314792D9A3F64FE2FB740D35B051A7@ESESSCMS0351.eemea.ericsson.se> 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: AAAAAA== Subject: [sipcore] draft-ietf-sipcore-reinvite-06 and new contact in 2xx to *inital* invite 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: Wed, 10 Nov 2010 09:33:45 -0000 Hi folks,=20 =20 A while ago I started a discussion concerning how a client should be have w= hen it receives a new contact in the 2xx of an initial INVITE, compared to = the early dialog-establishing 183. =20 My reading of chapter 13.2.2.4, rfc3261, tells me that a client should NOT = update its remote target with the Contact of the 2xx.=20 The Contact of the 2xx, should be the same as the 1xx. =20 I have now read draft-ietf-sipcore-reinvite-06 and I am trying to interpret= the results, since even if that document mainly concerns re-invite, chapte= r 4.9 discusses the early dialog created by an initial request. =20 The document does not however mention(?) differences in contact:uri between= the initial 1xx, and the final 2xx to the INVITE. =20 The draft mandates that a successfull response, a reliable provisional resp= onse, or an in-dialog request to the new target implies a successfull chang= e of contact-uri. =20 Should I therefore assume that since a 2xx in a normal (initial) invite, is= also retransmitted reliably, that a UAC which receives a new contact in th= e 2xx compared to the contact in a 1xx(wether it has been sent reliably or = not), MUST update its remote target? =20 Since this (seems to) contradict 13.2.2.4, I would very much appreciate you= r views. =20 If the dialog identifier in the 2xx response matches the dialog identifier of an existing dialog, the dialog MUST be transitioned to the "confirmed" state, and the route set for the dialog MUST be recomputed based on the 2xx response using the procedures of Section 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be constructed using the procedures of Section 12.1.2. >> Note that the only piece of state that is recomputed is the route >> set. Other pieces of state such as the highest sequence numbers (remote and local) sent within the dialog are not recomputed. The route set only is recomputed for backwards compatibility. RFC 2543 did not mandate mirroring of the Record-Route header field in a 1xx, only 2xx. However, we cannot update the entire state of the dialog, since mid-dialog requests may have been sent within the early dialog, modifying the sequence numbers, for example. Additionally, I was a bit surprised by the following text, in the above dra= ft. Note also that a given UAS can establish additional early dialogs, which can have different targets, by returning additional unreliable provisional responses with different To tags. Since rfc3261, chapter 13.3.1.1 says: A UAS MAY send as many provisional responses as it likes. Each of these= MUST indicate the same dialog ID. However, these will not be delivered relia= bly. Which implies to me, that a *single* UAS can not send multiple 1xx with dif= ferent=20 tags? Regards Taisto Qvist From pkyzivat@cisco.com Wed Nov 10 02:16:56 2010 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 EAEFD3A69C2 for ; Wed, 10 Nov 2010 02:16:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.125 X-Spam-Level: X-Spam-Status: No, score=-110.125 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_HI=-8, 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 kUHbu6qsEOwP for ; Wed, 10 Nov 2010 02:16:56 -0800 (PST) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 057073A6807 for ; Wed, 10 Nov 2010 02:16:56 -0800 (PST) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGIA2kxAaMHG/2dsb2JhbACiNHGhBpsYhUoEhFiFf4MM X-IronPort-AV: E=Sophos;i="4.59,177,1288569600"; d="scan'208";a="379367831" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-1.cisco.com with ESMTP; 10 Nov 2010 10:17:22 +0000 Received: from [10.75.234.201] (hkidc-vpn-client-234-201.cisco.com [10.75.234.201]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAAAHHFC006091 for ; Wed, 10 Nov 2010 10:17:19 GMT Message-ID: <4CDA712B.6030300@cisco.com> Date: Wed, 10 Nov 2010 18:17:15 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: sipcore@ietf.org References: <613AADD0FA18314792D9A3F64FE2FB740D35B051A7@ESESSCMS0351.eemea.ericsson.se> In-Reply-To: <613AADD0FA18314792D9A3F64FE2FB740D35B051A7@ESESSCMS0351.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-06 and new contact in 2xx to *inital* invite 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: Wed, 10 Nov 2010 10:16:57 -0000 On 11/10/2010 5:31 PM, Taisto Qvist wrote: > Hi folks, > > A while ago I started a discussion concerning how a client should be have when it receives a new contact in the 2xx of an initial INVITE, compared to the early dialog-establishing 183. > > My reading of chapter 13.2.2.4, rfc3261, tells me that a client should NOT update its remote target with the Contact of the 2xx. > The Contact of the 2xx, should be the same as the 1xx. > > I have now read draft-ietf-sipcore-reinvite-06 and I am trying to interpret the results, since even if that document mainly concerns re-invite, chapter 4.9 discusses the early dialog created by an initial request. > > The document does not however mention(?) differences in contact:uri between the initial 1xx, and the final 2xx to the INVITE. > > The draft mandates that a successfull response, a reliable provisional response, or an in-dialog request to the new target implies a successfull change of contact-uri. > > Should I therefore assume that since a 2xx in a normal (initial) invite, is also retransmitted reliably, that a UAC which receives a new contact in the 2xx compared to the contact in a 1xx(wether it has been sent reliably or not), MUST update its remote target? > > Since this (seems to) contradict 13.2.2.4, I would very much appreciate your views. I'm interested to hear Gonzalo's take on this. IMO the most reasonable thing to do in this circumstance is to honor the new contact in the 2xx. This is probably contrary to 3261. Whether it is supported by ...sipcore-reinvite... may be debatable. > If the dialog identifier in the 2xx response matches the dialog > identifier of an existing dialog, the dialog MUST be transitioned to > the "confirmed" state, and the route set for the dialog MUST be > recomputed based on the 2xx response using the procedures of Section > 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be > constructed using the procedures of Section 12.1.2. > >>> Note that the only piece of state that is recomputed is the route >>> set. Other pieces of state such as the highest sequence numbers > (remote and local) sent within the dialog are not recomputed. The > route set only is recomputed for backwards compatibility. RFC > 2543 did not mandate mirroring of the Record-Route header field in > a 1xx, only 2xx. However, we cannot update the entire state of > the dialog, since mid-dialog requests may have been sent within > the early dialog, modifying the sequence numbers, for example. Note that the route-set doesn't include the contact. Maybe that was your point. > Additionally, I was a bit surprised by the following text, in the above draft. > > Note also that a given UAS can > establish additional early dialogs, which can have different targets, > by returning additional unreliable provisional responses with > different To tags. > > Since rfc3261, chapter 13.3.1.1 says: > > A UAS MAY send as many provisional responses as it likes. Each of these MUST > indicate the same dialog ID. However, these will not be delivered reliably. > > Which implies to me, that a *single* UAS can not send multiple 1xx with different > tags? Perhaps this is a matter of terminology. If you prefer, consider the same box to contain multiple UAs, each of which received a forked copy of the request. Then each returns a single response with a unique to-tag. There are a number of cases where this is a viable strategy for handling various problems. Thanks, Paul > Regards > Taisto Qvist > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From HKaplan@acmepacket.com Wed Nov 10 02:41:58 2010 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 7A9B93A6826 for ; Wed, 10 Nov 2010 02:41:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.751 X-Spam-Level: X-Spam-Status: No, score=-0.751 tagged_above=-999 required=5 tests=[AWL=-0.856, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_52=0.6, 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 MxUD2FuDnyBb for ; Wed, 10 Nov 2010 02:41:53 -0800 (PST) Received: from ETMail2.acmepacket.com (unknown [216.41.24.9]) by core3.amsl.com (Postfix) with ESMTP id 9A38A3A69C2 for ; Wed, 10 Nov 2010 02:41:51 -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; Wed, 10 Nov 2010 05:42:14 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 10 Nov 2010 05:42:11 -0500 From: Hadriel Kaplan To: "Worley, Dale R (Dale)" Date: Wed, 10 Nov 2010 05:42:04 -0500 Thread-Topic: [sipcore] Proxy feature tag use-case: capability to use Path header field information in both directions Thread-Index: AcuAw+suWHo05CttS7iw6zi8UAel9A== Message-ID: <56387DAC-E84C-4AA3-AD0C-F9AEE8F6B8CD@acmepacket.com> References: <7F2072F1E0DE894DA4B517B93C6A058502E8A90B@ESESSCMS0356.eemea.ericsson.se> 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: AAAAAQAAAUA= Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Proxy feature tag use-case: capability to use Path header field information in both directions 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: Wed, 10 Nov 2010 10:41:58 -0000 I think this is somewhat similar to a problem I posed to Christer privately= about the proxy-feature draft: "proxies" don't do the same features on all= their "sides". For example, let's assume there was a feature tag for priv= acy anonymization. A proxy doesn't always do anonymization for all SIP req= uests regardless of where they came from - it may only do them for requests= being sent out of their domain. Or another example is a proxy performing = location insertion for emergency calls - it only does this for calls from t= he UA, not for calls to the UA. Same with call-continuity. Same with IMS = AKA. Same with SRTP. Same with outbound. Same with a lot of "features". = Even in 3gpp, think of all the rules that are split into "terminating" vs.= "originating" modes. So when putting feature tags into a Register's Path header, my concern was = that Path was the Proxy->Registrar direction, and it would have to put the = features it can perform on that "side" for requests received on that side. = So a UA getting that back will find out stuff that it can't actually use, = and not find out stuff it can use. But I think there're two possible solutions, which also happen to solve the= Service-Route problem: 1) We allow a proxy to *insert* a Service-Route in the Register request, wi= th the address of the side facing the UA it received the Register on; and w= e have the Registrar take this list of received Service-Routes and use it i= n the Service-Route list it returns in the Register response (plus whatever= other ones it needs to). The UA will thus get this list back, which repre= sent the proxy direction it can actually use. OR... 2) The proxy inserts a Path header, but is allowed to change its Path heade= r URI (and feature tags) when it sees its own Path/Service-Route header in = the Register response, to be its other side/features. Option 1 is more proxy-ish. Option 2 is what some SBCs do today and works.= I think option-1 is the more right thing to do, from a purity perspective= . I can write up an I-D on this if people like it - option-1 would update rfc= 3608, option-2 would update rfc3327. -hadriel On Nov 10, 2010, at 4:11 AM, Worley, Dale R (Dale) wrote: > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Ch= rister Holmberg [christer.holmberg@ericsson.com] >=20 > PROBLEM: > ----------------- >=20 > Many of you may remember the discussions we've had every now and then reg= arding issues of building a Service-Route. >=20 > The RFC recommends against intermediaries inserting themselves in the Ser= vice-Route of the REGISTER response. >=20 > In addition, the registrar cannot assume that the Path header(s) received= in the REGISTER request can be used by the registrar to build the Service-= Route, so often the only instane in the Service-Route is the registrar itse= lf. >=20 > In addition, the UA cannot assume that the Path header(s) received in the= REGISTER response can be used to build a route for initial dialog or stand= -alone SIP requests. The reasons is that Path by definition only provides r= outing information for the registrar-to-UA direction. >=20 > So, today, if initial dialog or stand-alone SIP requests are to be routed= via specific intermediaries, it has to be done by configuration, since nei= ther the Service-Route or Path can be used to build the route. > ________________________________________ >=20 > It seems to me that no manipulation of the Path header (as seen by the re= gistrar) is useful for solving the problem of building a suitable Service-R= oute. >=20 > There are two cases: In the first case, the registrar, if it receives an= INVITE (for example) is capable of processing it correctly or sending it t= o some element that can. In this case, the UA does not need a Service-Rout= e, as it can send the INVITE by the same mechanism that it used to send the= REGISTER. >=20 > In the second case, where the INVITE must be routed to a different elemen= t than the REGISTER, the incoming Path value seen by the registrar is not u= seful for constructing a suitable Service-Route, because the Path values de= scribe how a request is routed to the registrar, not the service proxy. >=20 > Knowing that the Path can be used in the UA-to-registrar direction (as we= ll as the registrar-to-UA direction) tells the UA something that it *alread= y knows*, viz., how to get requests to the registrar. >=20 > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From jmpolk@cisco.com Wed Nov 10 05:39:05 2010 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 5E2863A6968 for ; Wed, 10 Nov 2010 05:39:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.751 X-Spam-Level: X-Spam-Status: No, score=-109.751 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8, 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 oz8JPz4H0flW for ; Wed, 10 Nov 2010 05:38:59 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id B7ABC3A6941 for ; Wed, 10 Nov 2010 05:38:59 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiYFANUu2kyrRN+J/2dsb2JhbAChXlhxogGbK4JxglkEhFo X-IronPort-AV: E=Sophos;i="4.59,178,1288569600"; d="scan'208";a="283916271" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-5.cisco.com with ESMTP; 10 Nov 2010 13:39:26 +0000 Received: from jmpolk-wxp01.cisco.com (sjc-vpn6-697.cisco.com [10.21.122.185]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id oAADdOXw021414; Wed, 10 Nov 2010 13:39:25 GMT Message-Id: <201011101339.oAADdOXw021414@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 10 Nov 2010 07:39:21 -0600 To: "Thomson, Martin" , "Peterson, Jon" , "sipcore@ietf.org" From: "James M. Polk" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03F33652DB@SISPE7MB1.comms cope.com> References: <8B0A9FCBB9832F43971E38010638454F03F33652DB@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] Location-conveyance, option tags and URI scheme support 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: Wed, 10 Nov 2010 13:39:05 -0000 At 09:08 PM 11/9/2010, Thomson, Martin wrote: >This sounds like a good idea. Clever is=20 >something I can appreciate, even at this=20 >stage. This should improve the interoperability situation. > >I also really like the idea of cutting out the=20 >geolocation-error header. There was a lot of=20 >mechanism there, for little significant value. Martin - there is no proposal to completely=20 remove the Geolocation-Error header value, just=20 cut down (further) the number of error codes we specify in this doc. The - 100 - 300 - 301 - 302 and - 400 error codes remain, and we're still unsettled=20 with how a SIP 503 response with a Retry-After=20 header value can replace the 200 error code.=20 Right now, I don't see how a SIP 503 response=20 gets related back to a location error, which we=20 want to assert, and not a general 503 (service=20 unavailable) response that has nothing to do with location >Thinking about this a little more there might be a need for three values: > >I need a PIDF-LO > Require: Geolocation-value >I need an HTTP[s]/HELD URI > Require: Geolocation-value this one would be "Require: Geolocation-HTTP" (not -value) right? >I need a SIP[s]/pres URI > Require: Geolocation-presence > >I see little reason to separately identify=20 >HELD. HELD dereference works with HTTP GET well=20 >enough and a HELD-capable client can recognize a=20 >HELD-capable server if they care about using=20 >HELD (for quality of service constraints and so on). > > From the perspective of late changes, I expect=20 > that the error handling cases are not yet=20 > mature enough in existing implementations to be=20 > concerned. I will confirm, but don't let that stop you from proceeding. > >--Martin > >(How do you say OR in a require header? you don't (yet) James >e.g., I need HTTP or a value; do we need to define specific semantics?) > >On 2010-11-10 at 10:04:39, Peterson, Jon wrote: > > > > As much as I hoped not to have to introduce any =E2=80=9Cclever=E2=80=9D= new ideas for > > location-conveyance, some of Mr. Elwell=E2=80=99s comments caused us to= circle > > round and think about the intended application of option tags in > > location-conveyance, especially in conjunction with the various > > mechanisms intended to negotiate URI scheme support. > > > > For a while, I=E2=80=99ve been uncomfortable with the various error= codes > > proposed to negotiate URI scheme support for a couple of reasons: > > mostly > > because a URI scheme does not completely express the behavior that an > > endpoint needs to support. For example, what does it mean to say that > > an > > endpoint supports SIP as a URI scheme for acquiring location by > > reference? That it supports SUBSCRIBE/NOTIFY, or specifically fetch > > behavior, or specifically the presence event package, or specifically > > some subset thereof? The same applies to HTTP =AD one can easily imagine > > > a > > bare HTTP GET for a location object, or one can imagine a broader > > package like HELD. Simply articulating support for a URI scheme seems > > insufficient. To invoke an overloaded term, we lack a means to support > > these sorts of =E2=80=9Cprofiles=E2=80=9D for delivering location by= reference. > > > > Meanwhile, the way the draft is written today, the use case for an > > option tag expressing support for =E2=80=9Cgeolocation=E2=80=9D is= certainly murky at > > best. Rather than removing the tag, however, perhaps we should replace > > it instead with more specific tags for those =E2=80=9Cprofiles.=E2=80=9D= In this model, > > if you imagine we have a =E2=80=9Cpresence=E2=80=9D profile (and send= requests with > > that > > tag in a Supported), and you send location to a server that supports > > the > > =E2=80=9Cheld=E2=80=9D profile, it could return a 421=20 > with that =E2=80=9Cheld=E2=80=9D in a Require or > > what have you and inform the UAC what it needs to send. > > > > This would also replace the proposed IANA registry of supported URI > > schemes, presumably with a registry of these =E2=80=9Cprofiles,=E2=80=9D= which would > > have something roughly like Spec Required for its policy. > > > > Thoughts about whether or not we can endure this cleverness at this > > stage in the process? Backwards compatibility snafus? > > > > Jon Peterson > > NeuStar, Inc. > > >_______________________________________________=20 >sipcore mailing list sipcore@ietf.org=20 >https://www.ietf.org/mailman/listinfo/sipcore From BPenfield@acmepacket.com Wed Nov 10 06:03:39 2010 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 218873A6965 for ; Wed, 10 Nov 2010 06:03:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_73=0.6] 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 ox8dtu2iEfJ2 for ; Wed, 10 Nov 2010 06:03:38 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 2514F3A6851 for ; Wed, 10 Nov 2010 06:03:37 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Wed, 10 Nov 2010 09:04:01 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 10 Nov 2010 09:04:01 -0500 From: Bob Penfield To: Paul Kyzivat , "sipcore@ietf.org" Date: Wed, 10 Nov 2010 09:04:00 -0500 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-06 and new contact in 2xx to *inital* invite Thread-Index: AcuAwH6ei6Kd+huyQ8W42wxgtQfNWQAHkcFw Message-ID: <429446390BA91242867940DBE798A06B8B929076DD@mail> References: <613AADD0FA18314792D9A3F64FE2FB740D35B051A7@ESESSCMS0351.eemea.ericsson.se> <4CDA712B.6030300@cisco.com> In-Reply-To: <4CDA712B.6030300@cisco.com> 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 Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-06 and new contact in 2xx to *inital* invite 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: Wed, 10 Nov 2010 14:03:39 -0000 inline >-----Original Message----- >From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf= Of Paul Kyzivat >Sent: Wednesday, November 10, 2010 5:17 AM >To: sipcore@ietf.org >Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-06 and new contact in 2= xx to *inital* invite > > >On 11/10/2010 5:31 PM, Taisto Qvist wrote: >> Hi folks, >> >> A while ago I started a discussion concerning how a client should be hav= e=20 >> when it receives a new contact in the 2xx of an initial INVITE, compared= to >> the early dialog-establishing 183. >> >> My reading of chapter 13.2.2.4, rfc3261, tells me that a client should N= OT=20 >> update its remote target with the Contact of the 2xx. >> The Contact of the 2xx, should be the same as the 1xx. >> >> I have now read draft-ietf-sipcore-reinvite-06 and I am trying to interp= ret=20 >> the results, since even if that document mainly concerns re-invite, chap= ter=20 >> 4.9 discusses the early dialog created by an initial request. >> >> The document does not however mention(?) differences in contact:uri betw= een=20 >> the initial 1xx, and the final 2xx to the INVITE. >> >> The draft mandates that a successfull response, a reliable provisional=20 >> response, or an in-dialog request to the new target implies a successful= l=20 >> change of contact-uri. >> >> Should I therefore assume that since a 2xx in a normal (initial) invite,= is=20 >> also retransmitted reliably, that a UAC which receives a new contact in = the=20 >> 2xx compared to the contact in a 1xx(wether it has been sent reliably or= =20 >> not), MUST update its remote target? >> >> Since this (seems to) contradict 13.2.2.4, I would very much appreciate = your=20 >> views. > >I'm interested to hear Gonzalo's take on this. >IMO the most reasonable thing to do in this circumstance is to honor the=20 >new contact in the 2xx. This is probably contrary to 3261. Whether it is=20 >supported by ...sipcore-reinvite... may be debatable. > The text below indicates that procedures in 12.2.1.2 should be used when=20 the 2xx matches an existing early dialog. These are the same procedures for a target refresh requests. That section has no procedures for constructing= =20 the route set, but does indicate that the remote target is updated. I have always used the Contact from the 2xx final response as the remote target of the confirmed dialog. >> If the dialog identifier in the 2xx response matches the dialog >> identifier of an existing dialog, the dialog MUST be transitioned to >> the "confirmed" state, and the route set for the dialog MUST be >> recomputed based on the 2xx response using the procedures of Section >> 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be >> constructed using the procedures of Section 12.1.2. >> >> >> Note that the only piece of state that is recomputed is the route >> >> set. Other pieces of state such as the highest sequence numbers >> (remote and local) sent within the dialog are not recomputed. Th= e >> route set only is recomputed for backwards compatibility. RFC >> 2543 did not mandate mirroring of the Record-Route header field i= n >> a 1xx, only 2xx. However, we cannot update the entire state of >> the dialog, since mid-dialog requests may have been sent within >> the early dialog, modifying the sequence numbers, for example. > > Note that the route-set doesn't include the contact. Maybe that was your= =20 > point. > From hannu.hietalahti@nokia.com Wed Nov 10 21:46:01 2010 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 351FB3A69CD for ; Wed, 10 Nov 2010 21:46:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.69 X-Spam-Level: X-Spam-Status: No, score=-6.69 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 YvyJXcG7Q9AT for ; Wed, 10 Nov 2010 21:45:59 -0800 (PST) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id 11DAD3A69CA for ; Wed, 10 Nov 2010 21:45:55 -0800 (PST) Received: from vaebh105.NOE.Nokia.com (vaebh105.europe.nokia.com [10.160.244.31]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id oAB5jmEA002124; Thu, 11 Nov 2010 07:46:22 +0200 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by vaebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Nov 2010 07:46:07 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Nov 2010 07:46:01 +0200 Received: from NOK-EUMSG-06.mgdnok.nokia.com ([94.245.81.109]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Thu, 11 Nov 2010 06:46:00 +0100 From: To: , Date: Thu, 11 Nov 2010 06:45:57 +0100 Thread-Topic: [sipcore] Summary: number of location headers Thread-Index: Act/7jFRahayayQQR0eYiLTIMKBrMwBclPeA Message-ID: <5BAF85033CB5F3439C4DE153165522B1109FF60202@NOK-EUMSG-06.mgdnok.nokia.com> References: <4CD90FFC.40502@nostrum.com> In-Reply-To: <4CD90FFC.40502@nostrum.com> 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-OriginalArrivalTime: 11 Nov 2010 05:46:01.0826 (UTC) FILETIME=[B926BC20:01CB8163] X-Nokia-AV: Clean Subject: Re: [sipcore] Summary: number of location headers 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: Thu, 11 Nov 2010 05:46:01 -0000 Thanks for summarising, Adam, being one of those requesting this change I of course support it, but could= we please also re-word the warning against adding multiple locations from = "SHOULD NOT" to giving a warning that adding more location objects does not= guarantee better accuracy and any possible conflict resolution is left for= the receiver of this information. The issue is real and I am not arguing to remove this warning. But in case = of emergency calls just strongly recommending against multiple location obj= ects with "SHOULD NOT" does not help much if both the terminal and the netw= ork *have to* insert their best understanding of the user's location. BR, Hannu Hietalahti 3GPP TSG CT Chairman tel: +358 40 5021724 =20 >-----Original Message----- >From: sipcore-bounces@ietf.org=20 >[mailto:sipcore-bounces@ietf.org] On Behalf Of ext Adam Roach=20 >- SIPCORE Chair >Sent: 09 November, 2010 11:10 >To: SIPCORE (Session Initiation Protocol Core) WG >Subject: [sipcore] Summary: number of location headers > >[as chair] > >I just wanted to summarize where it looks like the discussion ended up=20 >on whether we constrain the number of location header fields in a SIP=20 >message. From my review of the discussion, I believe that four people=20 >have weighed in on the topic to voice support for an arbitrary=20 >number of=20 >location headers (albeit with a implementation warning that=20 >doing so is=20 >not advisable): > >Martin Thompson:=20 >http://www.ietf.org/mail-archive/web/sipcore/current/msg03576.html >Richard Barnes:=20 >http://www.ietf.org/mail-archive/web/sipcore/current/msg03580.html >Keith Drage:=20 >http://www.ietf.org/mail-archive/web/sipcore/current/msg03600.html >Hannu Hietalahti:=20 >http://www.ietf.org/mail-archive/web/sipcore/current/msg03619.html > >And two people have agreed to go along with that direction, with=20 >expressed reservations: > >Jon Peterson:=20 >http://www.ietf.org/mail-archive/web/sipcore/current/msg03601.html >James Polk:=20 >http://www.ietf.org/mail-archive/web/sipcore/current/msg03603.html > >If any other working group participants have comments on this topic,=20 >they are encouraged to make them quickly. Lacking any further=20 >input, the=20 >authors will be instructed to revise the document to allow an=20 >arbitrary=20 >number of location header fields, with an accompanying warning that=20 >doing so is not recommended. > >/a >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore >= From jmpolk@cisco.com Wed Nov 10 22:14:49 2010 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 036643A68CB for ; Wed, 10 Nov 2010 22:14:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.599 X-Spam-Level: X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 XcylKVy3q4-s for ; Wed, 10 Nov 2010 22:14:40 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 21EE63A6880 for ; Wed, 10 Nov 2010 22:14:39 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHcY20ytJV2a/2dsb2JhbACiQHGkFJszhUoEhFo X-IronPort-AV: E=Sophos;i="4.59,181,1288569600"; d="scan'208";a="180692192" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rtp-iport-1.cisco.com with ESMTP; 11 Nov 2010 06:15:07 +0000 Received: from jmpolk-wxp01.cisco.com (sjc-vpn6-1169.cisco.com [10.21.124.145]) by rcdn-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id oAB6F4eW005052; Thu, 11 Nov 2010 06:15:05 GMT Message-Id: <201011110615.oAB6F4eW005052@rcdn-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 11 Nov 2010 00:15:02 -0600 To: , , From: "James M. Polk" In-Reply-To: <5BAF85033CB5F3439C4DE153165522B1109FF60202@NOK-EUMSG-06.mg dnok.nokia.com> References: <4CD90FFC.40502@nostrum.com> <5BAF85033CB5F3439C4DE153165522B1109FF60202@NOK-EUMSG-06.mgdnok.nokia.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] Summary: number of location headers 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: Thu, 11 Nov 2010 06:14:50 -0000 Hannu One aspect you do not mention below is how erroring is handled with multiple locations in the same SIP request. As the doc stands today, there is no consideration for who receives the 424 as to which location was in error. If there is only 1 location, this is simple to correlate. I am sympathetic to the emergency services case, and I'm hesitant to call that one case out as an exception because in the future there might be an equally valid case that hasn't been called out - then where are we (i.e., is the RFC then accurate?). Therefore, I think the emergency case can be an example of why "SHOULD NOT" doesn't apply, but that it is justified in an emergency document, and not here in the general purpose document (i.e., this is better suited IMO for ECRIT phonebcp or ECRIT framework documents). With that logic, respectfully, I think SHOULD NOT is appropriate here. James At 11:45 PM 11/10/2010, hannu.hietalahti@nokia.com wrote: >Thanks for summarising, Adam, > >being one of those requesting this change I of course support it, >but could we please also re-word the warning against adding multiple >locations from "SHOULD NOT" to giving a warning that adding more >location objects does not guarantee better accuracy and any possible >conflict resolution is left for the receiver of this information. > >The issue is real and I am not arguing to remove this warning. But >in case of emergency calls just strongly recommending against >multiple location objects with "SHOULD NOT" does not help much if >both the terminal and the network *have to* insert their best >understanding of the user's location. > >BR, >Hannu Hietalahti >3GPP TSG CT Chairman >tel: +358 40 5021724 > > > >-----Original Message----- > >From: sipcore-bounces@ietf.org > >[mailto:sipcore-bounces@ietf.org] On Behalf Of ext Adam Roach > >- SIPCORE Chair > >Sent: 09 November, 2010 11:10 > >To: SIPCORE (Session Initiation Protocol Core) WG > >Subject: [sipcore] Summary: number of location headers > > > >[as chair] > > > >I just wanted to summarize where it looks like the discussion ended up > >on whether we constrain the number of location header fields in a SIP > >message. From my review of the discussion, I believe that four people > >have weighed in on the topic to voice support for an arbitrary > >number of > >location headers (albeit with a implementation warning that > >doing so is > >not advisable): > > > >Martin Thompson: > >http://www.ietf.org/mail-archive/web/sipcore/current/msg03576.html > >Richard Barnes: > >http://www.ietf.org/mail-archive/web/sipcore/current/msg03580.html > >Keith Drage: > >http://www.ietf.org/mail-archive/web/sipcore/current/msg03600.html > >Hannu Hietalahti: > >http://www.ietf.org/mail-archive/web/sipcore/current/msg03619.html > > > >And two people have agreed to go along with that direction, with > >expressed reservations: > > > >Jon Peterson: > >http://www.ietf.org/mail-archive/web/sipcore/current/msg03601.html > >James Polk: > >http://www.ietf.org/mail-archive/web/sipcore/current/msg03603.html > > > >If any other working group participants have comments on this topic, > >they are encouraged to make them quickly. Lacking any further > >input, the > >authors will be instructed to revise the document to allow an > >arbitrary > >number of location header fields, with an accompanying warning that > >doing so is not recommended. > > > >/a > >_______________________________________________ > >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 From dworley@avaya.com Wed Nov 10 23:58:59 2010 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 AADBF3A6920 for ; Wed, 10 Nov 2010 23:58:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.372 X-Spam-Level: X-Spam-Status: No, score=-102.372 tagged_above=-999 required=5 tests=[AWL=0.227, BAYES_00=-2.599, 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 dP+Uv2GdlzTD for ; Wed, 10 Nov 2010 23:58:59 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id D142D3A691E for ; Wed, 10 Nov 2010 23:58:58 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANgw20yHCzI1/2dsb2JhbACiP3GmPwKZJIJyglgEhFqJIw X-IronPort-AV: E=Sophos;i="4.59,181,1288584000"; d="scan'208";a="249539551" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Nov 2010 02:59:27 -0500 X-IronPort-AV: E=Sophos;i="4.59,181,1288584000"; d="scan'208";a="536709267" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Nov 2010 02:59:27 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Thu, 11 Nov 2010 02:59:27 -0500 From: "Worley, Dale R (Dale)" To: "Elwell, John" , "sipcore@ietf.org" Date: Thu, 11 Nov 2010 02:57:03 -0500 Thread-Topic: Understanding Privacy: history invoked by UAS Thread-Index: Act/tmX64nFBhz6FSZe0YJ2Va+pn3QBv6FJK Message-ID: References: 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 Subject: Re: [sipcore] Understanding Privacy: history invoked by UAS 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: Thu, 11 Nov 2010 07:58:59 -0000 ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Elwe= ll, John [john.elwell@siemens-enterprise.com] Suppose a request from A is targeted initially at B, this is mapped to C, a= nd then to registered contact D. The UAS (D) puts Privacy: history in the r= esponse, and therefore prevents A learning about C and D. Fine. Now, supposing D is not registered at the time, i.e., there is no registere= d contact for C. This results in a 4xx response to A. How do we ensure that= the identity of C is not disclosed to A, in line with what is achieved whe= n D is registered? _______________________________________________ Actually, D isn't really the center of this. If D's user wants to prevent = his AOR (C) from being disclosed, he will have to make an arrangement with = the home proxy for C. The home proxy can add "Privacy: history" to any 4xx= response it generates for requests to C. Indeed, it will probably add "Pr= ivacy: history" to requests or responses to C even when D is registered. Dale From dworley@avaya.com Thu Nov 11 00:02:26 2010 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 421203A68BC for ; Thu, 11 Nov 2010 00:02:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.383 X-Spam-Level: X-Spam-Status: No, score=-102.383 tagged_above=-999 required=5 tests=[AWL=0.216, BAYES_00=-2.599, 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 uTsql2nAc2Ly for ; Thu, 11 Nov 2010 00:02:25 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 762FB3A67F9 for ; Thu, 11 Nov 2010 00:02:25 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAQy20yHCzI1/2dsb2JhbACiP3GmQQKZJIVKBIRaiSM X-IronPort-AV: E=Sophos;i="4.59,181,1288584000"; d="scan'208";a="249540103" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Nov 2010 03:02:54 -0500 X-IronPort-AV: E=Sophos;i="4.59,181,1288584000"; d="scan'208";a="536710710" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 11 Nov 2010 03:02:54 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Thu, 11 Nov 2010 03:02:54 -0500 From: "Worley, Dale R (Dale)" To: Hadriel Kaplan , Shida Schubert Date: Thu, 11 Nov 2010 02:59:39 -0500 Thread-Topic: [sipcore] Understanding Privacy: history invoked by UAS Thread-Index: AcuAkx168p1bfSMAT9G6L6ZMOBxfCwA40ZL7 Message-ID: References: <1A3940A5-123E-4FF1-8B94-76B6C5B49596@ntt-at.com>, <7B01FB93-0DD5-47B5-BB01-B2E6FAED3DDA@acmepacket.com> In-Reply-To: <7B01FB93-0DD5-47B5-BB01-B2E6FAED3DDA@acmepacket.com> 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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Understanding Privacy: history invoked by UAS 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: Thu, 11 Nov 2010 08:02:26 -0000 ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Hadr= iel Kaplan [HKaplan@acmepacket.com] Out of curiosity, will anything "break" if the anonymized H-I entries are s= imply removed? I'm not suggesting we document doing that in the draft, jus= t asking if any apps/use-cases/whatever will break if it happens. Because = my guess is some of us will just remove them, and I'd like to know if there= 's any real reason I shouldn't. _______________________________________________ Hmmm... Another reason that we need to definitively define what constitute= s a valid H-I value and what does not. (This is tracker issue 34: http://t= ools.ietf.org/wg/sipcore/trac/ticket/34) Dale From R.Jesske@telekom.de Thu Nov 11 00:23:04 2010 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 B58A33A69B3 for ; Thu, 11 Nov 2010 00:23:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.524 X-Spam-Level: X-Spam-Status: No, score=-2.524 tagged_above=-999 required=5 tests=[AWL=0.725, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-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 By+svMvHcFSm for ; Thu, 11 Nov 2010 00:23:03 -0800 (PST) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 6622B3A69AC for ; Thu, 11 Nov 2010 00:23:03 -0800 (PST) Received: from he110890.emea1.cds.t-internal.com ([10.134.92.131]) by tcmail71.telekom.de with ESMTP/TLS/AES128-SHA; 11 Nov 2010 09:23:02 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.118]) by he110890 ([10.134.92.131]) with mapi; Thu, 11 Nov 2010 09:22:58 +0100 From: To: , , Date: Thu, 11 Nov 2010 09:22:55 +0100 Thread-Topic: [sipcore] Understanding Privacy: history invoked by UAS Thread-Index: AcuAkx168p1bfSMAT9G6L6ZMOBxfCwA40ZL7AAB4J3A= Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D0146FC0E@HE111648.emea1.cds.t-internal.com> References: <1A3940A5-123E-4FF1-8B94-76B6C5B49596@ntt-at.com>, <7B01FB93-0DD5-47B5-BB01-B2E6FAED3DDA@acmepacket.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sipcore@ietf.org Subject: Re: [sipcore] Understanding Privacy: history invoked by UAS 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: Thu, 11 Nov 2010 08:23:04 -0000 For call forwarding the entries will be counted when a "mp" is included. Th= is is due to avoid to many Call forwardings. 3GPP has defined their service in counting the entries where a "cause" rega= rding RFC4458 is included. So if such entries will be deleted then the counter number of diversions is= not correct, which is also needed for the interworking with the PSTN. Roland > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] Im Auftrag von Worley, Dale R (Dale) > Gesendet: Donnerstag, 11. November 2010 09:00 > An: Hadriel Kaplan; Shida Schubert > Cc: sipcore@ietf.org > Betreff: Re: [sipcore] Understanding Privacy: history invoked by UAS > > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On > Behalf Of Hadriel Kaplan [HKaplan@acmepacket.com] > > Out of curiosity, will anything "break" if the anonymized H-I > entries are simply removed? I'm not suggesting we document > doing that in the draft, just asking if any > apps/use-cases/whatever will break if it happens. Because my > guess is some of us will just remove them, and I'd like to > know if there's any real reason I shouldn't. > _______________________________________________ > > Hmmm... Another reason that we need to definitively define > what constitutes a valid H-I value and what does not. (This > is tracker issue 34: http://tools.ietf.org/wg/sipcore/trac/ticket/34) > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From hannu.hietalahti@nokia.com Thu Nov 11 00:51:10 2010 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 52DD528C0DE for ; Thu, 11 Nov 2010 00:51:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.676 X-Spam-Level: X-Spam-Status: No, score=-6.676 tagged_above=-999 required=5 tests=[AWL=-0.077, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Xxh-WZULyUiR for ; Thu, 11 Nov 2010 00:51:09 -0800 (PST) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id CFB3828C108 for ; Thu, 11 Nov 2010 00:51:05 -0800 (PST) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id oAB8pBqK021708; Thu, 11 Nov 2010 10:51:31 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Nov 2010 10:51:11 +0200 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by esebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Thu, 11 Nov 2010 10:51:09 +0200 Received: from NOK-EUMSG-06.mgdnok.nokia.com ([94.245.81.109]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Thu, 11 Nov 2010 09:51:08 +0100 From: To: , , Date: Thu, 11 Nov 2010 09:51:04 +0100 Thread-Topic: [sipcore] Summary: number of location headers Thread-Index: AcuBZ9WumIufvd2cTHGeGfd1MZqkaAAFBF+g Message-ID: <5BAF85033CB5F3439C4DE153165522B1109FF60349@NOK-EUMSG-06.mgdnok.nokia.com> References: <4CD90FFC.40502@nostrum.com> <5BAF85033CB5F3439C4DE153165522B1109FF60202@NOK-EUMSG-06.mgdnok.nokia.com> <201011110615.oAB6F4eW005052@rcdn-core-3.cisco.com> In-Reply-To: <201011110615.oAB6F4eW005052@rcdn-core-3.cisco.com> 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-OriginalArrivalTime: 11 Nov 2010 08:51:09.0262 (UTC) FILETIME=[95B2F6E0:01CB817D] X-Nokia-AV: Clean Subject: Re: [sipcore] Summary: number of location headers 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: Thu, 11 Nov 2010 08:51:10 -0000 Thanks James, I agree. Jon already gave me his explanation which was pretty similar to yo= urs and therefore I am willing to withdraw my request to avoid the "SHOULD = NOT". While saying SHOULD NOT, we might also want to give the reason to tha= t strong recommendation, though? We know at least one case where it will be mandatory for the terminal and t= he network to insert the user location. I hope the problem with correlating= 424 reject to any of the multiple location objects does not stop us keepin= g the option of multiple location objects. BR, Hannu Hietalahti 3GPP TSG CT Chairman tel: +358 40 5021724 =20 >-----Original Message----- >From: ext James M. Polk [mailto:jmpolk@cisco.com]=20 >Sent: 11 November, 2010 08:15 >To: Hietalahti Hannu (Nokia-CIC/Oulu);=20 >sipcore-chairs@tools.ietf.org; sipcore@ietf.org >Subject: Re: [sipcore] Summary: number of location headers > >Hannu > >One aspect you do not mention below is how erroring is handled with=20 >multiple locations in the same SIP request. As the doc stands today,=20 >there is no consideration for who receives the 424 as to which=20 >location was in error. If there is only 1 location, this is simple to=20 >correlate. > >I am sympathetic to the emergency services case, and I'm hesitant to=20 >call that one case out as an exception because in the future there=20 >might be an equally valid case that hasn't been called out - then=20 >where are we (i.e., is the RFC then accurate?). > >Therefore, I think the emergency case can be an example of why=20 >"SHOULD NOT" doesn't apply, but that it is justified in an emergency=20 >document, and not here in the general purpose document (i.e., this is=20 >better suited IMO for ECRIT phonebcp or ECRIT framework documents). > >With that logic, respectfully, I think SHOULD NOT is appropriate here. > >James > >At 11:45 PM 11/10/2010, hannu.hietalahti@nokia.com wrote: >>Thanks for summarising, Adam, >> >>being one of those requesting this change I of course support it,=20 >>but could we please also re-word the warning against adding multiple=20 >>locations from "SHOULD NOT" to giving a warning that adding more=20 >>location objects does not guarantee better accuracy and any possible=20 >>conflict resolution is left for the receiver of this information. >> >>The issue is real and I am not arguing to remove this warning. But=20 >>in case of emergency calls just strongly recommending against=20 >>multiple location objects with "SHOULD NOT" does not help much if=20 >>both the terminal and the network *have to* insert their best=20 >>understanding of the user's location. >> >>BR, >>Hannu Hietalahti >>3GPP TSG CT Chairman >>tel: +358 40 5021724 >> >> >> >-----Original Message----- >> >From: sipcore-bounces@ietf.org >> >[mailto:sipcore-bounces@ietf.org] On Behalf Of ext Adam Roach >> >- SIPCORE Chair >> >Sent: 09 November, 2010 11:10 >> >To: SIPCORE (Session Initiation Protocol Core) WG >> >Subject: [sipcore] Summary: number of location headers >> > >> >[as chair] >> > >> >I just wanted to summarize where it looks like the=20 >discussion ended up >> >on whether we constrain the number of location header=20 >fields in a SIP >> >message. From my review of the discussion, I believe that=20 >four people >> >have weighed in on the topic to voice support for an arbitrary >> >number of >> >location headers (albeit with a implementation warning that >> >doing so is >> >not advisable): >> > >> >Martin Thompson: >> >http://www.ietf.org/mail-archive/web/sipcore/current/msg03576.html >> >Richard Barnes: >> >http://www.ietf.org/mail-archive/web/sipcore/current/msg03580.html >> >Keith Drage: >> >http://www.ietf.org/mail-archive/web/sipcore/current/msg03600.html >> >Hannu Hietalahti: >> >http://www.ietf.org/mail-archive/web/sipcore/current/msg03619.html >> > >> >And two people have agreed to go along with that direction, with >> >expressed reservations: >> > >> >Jon Peterson: >> >http://www.ietf.org/mail-archive/web/sipcore/current/msg03601.html >> >James Polk: >> >http://www.ietf.org/mail-archive/web/sipcore/current/msg03603.html >> > >> >If any other working group participants have comments on this topic, >> >they are encouraged to make them quickly. Lacking any further >> >input, the >> >authors will be instructed to revise the document to allow an >> >arbitrary >> >number of location header fields, with an accompanying warning that >> >doing so is not recommended. >> > >> >/a >> >_______________________________________________ >> >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 > >= From taisto.qvist@ericsson.com Thu Nov 11 01:05:14 2010 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 4D5D73A6991 for ; Thu, 11 Nov 2010 01:05:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.816 X-Spam-Level: X-Spam-Status: No, score=-5.816 tagged_above=-999 required=5 tests=[AWL=-0.417, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4] 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 PNfuTMwSVkPh for ; Thu, 11 Nov 2010 01:05:13 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id B56203A68F1 for ; Thu, 11 Nov 2010 01:05:12 -0800 (PST) X-AuditID: c1b4fb3d-b7b28ae00000135b-51-4cdbb1e433b9 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 5A.3C.04955.4E1BBDC4; Thu, 11 Nov 2010 10:05:40 +0100 (CET) Received: from ESESSCMS0351.eemea.ericsson.se ([169.254.1.175]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Thu, 11 Nov 2010 10:05:40 +0100 From: Taisto Qvist To: Paul Kyzivat , "sipcore@ietf.org" Date: Thu, 11 Nov 2010 10:05:39 +0100 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-06 and new contact in 2xx to *inital* invite Thread-Index: AcuAwHst7PX6EsP6T7mPpaSwvc4uiQAvYIvA Message-ID: <613AADD0FA18314792D9A3F64FE2FB740D35B056A3@ESESSCMS0351.eemea.ericsson.se> References: <613AADD0FA18314792D9A3F64FE2FB740D35B051A7@ESESSCMS0351.eemea.ericsson.se> <4CDA712B.6030300@cisco.com> In-Reply-To: <4CDA712B.6030300@cisco.com> 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: AAAAAA== Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-06 and new contact in 2xx to *inital* invite 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: Thu, 11 Nov 2010 09:05:14 -0000 Minor comments below -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Paul Kyzivat Sent: den 10 november 2010 11:17 To: sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-06 and new contact in 2x= x to *inital* invite On 11/10/2010 5:31 PM, Taisto Qvist wrote: > Hi folks, > > A while ago I started a discussion concerning how a client should be have= when it receives a new contact in the 2xx of an initial INVITE, compared t= o the early dialog-establishing 183. > > My reading of chapter 13.2.2.4, rfc3261, tells me that a client should NO= T update its remote target with the Contact of the 2xx. > The Contact of the 2xx, should be the same as the 1xx. > > I have now read draft-ietf-sipcore-reinvite-06 and I am trying to interpr= et the results, since even if that document mainly concerns re-invite, chap= ter 4.9 discusses the early dialog created by an initial request. > > The document does not however mention(?) differences in contact:uri betwe= en the initial 1xx, and the final 2xx to the INVITE. > > The draft mandates that a successfull response, a reliable provisional re= sponse, or an in-dialog request to the new target implies a successfull cha= nge of contact-uri. > > Should I therefore assume that since a 2xx in a normal (initial) invite, = is also retransmitted reliably, that a UAC which receives a new contact in = the 2xx compared to the contact in a 1xx(wether it has been sent reliably o= r not), MUST update its remote target? > > Since this (seems to) contradict 13.2.2.4, I would very much appreciate y= our views. I'm interested to hear Gonzalo's take on this. IMO the most reasonable thing to do in this circumstance is to honor the ne= w contact in the 2xx. This is probably contrary to 3261. Whether it is supp= orted by ...sipcore-reinvite... may be debatable. > If the dialog identifier in the 2xx response matches the dialog > identifier of an existing dialog, the dialog MUST be transitioned to > the "confirmed" state, and the route set for the dialog MUST be > recomputed based on the 2xx response using the procedures of Section > 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be > constructed using the procedures of Section 12.1.2. > >>> Note that the only piece of state that is recomputed is the route >>> set. Other pieces of state such as the highest sequence numbers > (remote and local) sent within the dialog are not recomputed. The > route set only is recomputed for backwards compatibility. RFC > 2543 did not mandate mirroring of the Record-Route header field in > a 1xx, only 2xx. However, we cannot update the entire state of > the dialog, since mid-dialog requests may have been sent within > the early dialog, modifying the sequence numbers, for example. Note that the route-set doesn't include the contact. Maybe that was your po= int. [TQ] Yepp :-) > Additionally, I was a bit surprised by the following text, in the above d= raft. > > Note also that a given UAS can > establish additional early dialogs, which can have different targets, > by returning additional unreliable provisional responses with > different To tags. > > Since rfc3261, chapter 13.3.1.1 says: > > A UAS MAY send as many provisional responses as it likes. Each of th= ese MUST > indicate the same dialog ID. However, these will not be delivered re= liably. > > Which implies to me, that a *single* UAS can not send multiple 1xx=20 > with different tags? Perhaps this is a matter of terminology. If you prefer, consider the same box to contain multiple UAs, each of which= received a forked copy of the request. Then each returns a single response= with a unique to-tag. There are a number of cases where this is a viable strategy for handling va= rious problems. [TQ] It most certainly is. But when I read that paragraph it doesnt indicate a g= eneric endpoint which consists of multiple UAS:es that received several for= ked requests. Too me, it claims that a single UAS, that has received a *single* request, = can respond to that single transaction, with multiple provisional responses= , creating=20 multiple early dialogs by using different tags. That seems to completely co= ntradict rfc3261.=20 But maybe I'm just beeing a bit to literal, although for interoperability r= easons, I think that maybe we should be :-) /Taisto From dworley@avaya.com Thu Nov 11 01:10:15 2010 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 F16BD3A6991 for ; 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-Level: 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nf7zRdoCh0RY for ; Thu, 11 Nov 2010 01:10:13 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 3CF5C3A69DA for ; 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) ([198.152.7.5]) 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) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Nov 2010 04:10:37 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Thu, 11 Nov 2010 04:10:37 -0500 From: "Worley, Dale R (Dale)" To: Paul Kyzivat , Mary Barnes 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: 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 Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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. >=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. The BNF in RFC 3261 calls these things "headers": SIP-URI =3D "sip:" [ userinfo ] hostport uri-parameters [ headers ] headers =3D "?" header *( "&" header ) header =3D hname "=3D" 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 (usually). > > 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. 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. >=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. 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 Abstract 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 purposes. > > 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? 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. Dale From fluffy@cisco.com Thu Nov 11 01:41:06 2010 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 1A3843A69C8 for ; Thu, 11 Nov 2010 01:41:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.573 X-Spam-Level: X-Spam-Status: No, score=-110.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 9taPiEGpM+nw for ; Thu, 11 Nov 2010 01:40:57 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id E96FF3A69B3 for ; Thu, 11 Nov 2010 01:40:56 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAPtI20yrR7Ht/2dsb2JhbACiQHGkPZtGhUoEhFqFfoML X-IronPort-AV: E=Sophos;i="4.59,182,1288569600"; d="scan'208";a="618097157" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-6.cisco.com with ESMTP; 11 Nov 2010 09:41:26 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAB9fPvN005091; Thu, 11 Nov 2010 09:41:26 GMT From: Cullen Jennings Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Nov 2010 02:41:47 -0700 Message-Id: <14FFF078-E5D1-45F2-8D9A-AD52DE677CEF@cisco.com> To: sipcore@ietf.org, Mary Barnes Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [sipcore] draft-barnes-sipcore-rfc4244bis 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: Thu, 11 Nov 2010 09:41:06 -0000 The draft has a lot well specified procedures about how to write tags to = a message, and it discusses that the tags could be used in lots of ways. = However, I would like to see some text added to section 8 that allowed = implementers to use this specification to implemented some of the use = cases it is designed to meet. Specifically I would like to see normative = language on how a voicemail system can use the tags found in an incoming = invite to determined which mailbox the call should be delivered too.=20 People have suggested to me this information is in the call flows = document. I like call flows, I think they help people, but this is an = information document with no normative language describing how to do = this. I'm not a huge fan of people implementing things off call flows. I = rather have the procedures for this specified in 4244bis and then have = example call flows that illustrated this in the call flow draft.=20 Overall, this draft fixes many of the fundamental problems of RFC 4244. Cullen PS - Sorry this was sent right before the meeting. Normally I would try = and discuss something like this in the meeting but given the audio = latencies we have been having today, I don't think that would work out = ver well so decide to send this.=20= From mary.ietf.barnes@gmail.com Thu Nov 11 01:58:54 2010 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 046DA3A6A43 for ; Thu, 11 Nov 2010 01:58:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.552 X-Spam-Level: X-Spam-Status: No, score=-102.552 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 K+XV4oz1QBtJ for ; Thu, 11 Nov 2010 01:58:53 -0800 (PST) Received: from mail-yx0-f172.google.com (mail-yx0-f172.google.com [209.85.213.172]) by core3.amsl.com (Postfix) with ESMTP id DC2B43A6A4B for ; Thu, 11 Nov 2010 01:58:52 -0800 (PST) Received: by yxn35 with SMTP id 35so240642yxn.31 for ; Thu, 11 Nov 2010 01:59:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=aaK7GBPXWKmxYU66T08bpw0tevkPQW37qqdiooFMpW4=; b=L1eqM7WsNX1ppS9HKLyfI0xwmSlRl2U++o90qrjT1rd8FQnLUPPlULF6Ro2cCBsp6z CR6j8oeTuLET0jzjxaPPjGffPU6G23juhVrpA1Pr4m3Wk8fy0RYqByZo4cf8gQmjSGwS Ji4GD+O1+bVVD7ulUEQanLnVZXwn4oVvpHmGY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=P0LQrH8B38gWgjzRbhJMsxc55yZlDu9TrbOde+3ZvonK0KVF7JWow+RqQxUR4h+2pb I5Zfc4Izapn++GNljN6bW2CgztbpHt/2IVUUsfnKZYO1ApR2ziIaL0PwWaSPEyUccQdh MXkGjFNLDcb8TC0beAC6auboyPmX/NmALrVxA= MIME-Version: 1.0 Received: by 10.90.25.13 with SMTP id 13mr1184398agy.33.1289469561483; Thu, 11 Nov 2010 01:59:21 -0800 (PST) Received: by 10.236.95.35 with HTTP; Thu, 11 Nov 2010 01:59:21 -0800 (PST) In-Reply-To: References: <1A3940A5-123E-4FF1-8B94-76B6C5B49596@ntt-at.com> <7B01FB93-0DD5-47B5-BB01-B2E6FAED3DDA@acmepacket.com> Date: Thu, 11 Nov 2010 03:59:21 -0600 Message-ID: From: Mary Barnes To: "Worley, Dale R (Dale)" Content-Type: multipart/alternative; boundary=00163630f5fb293e570494c40786 Cc: "sipcore@ietf.org" , Hadriel Kaplan Subject: Re: [sipcore] Understanding Privacy: history invoked by UAS 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: Thu, 11 Nov 2010 09:58:54 -0000 --00163630f5fb293e570494c40786 Content-Type: text/plain; charset=ISO-8859-1 Responses inline below [MB]. On Thu, Nov 11, 2010 at 1:59 AM, Worley, Dale R (Dale) wrote: > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of > Hadriel Kaplan [HKaplan@acmepacket.com] > > Out of curiosity, will anything "break" if the anonymized H-I entries are > simply removed? I'm not suggesting we document doing that in the draft, > just asking if any apps/use-cases/whatever will break if it happens. > Because my guess is some of us will just remove them, and I'd like to know > if there's any real reason I shouldn't. > [MB] Hadriel - There is text that describes that applications must be able to handle gaps and thus not break. We can't police the protocol, but removing the entries would not be normative behavior since it could impact an end application that wants to make use of the information. This is the usual be generous in what you receive...[/MB] > _______________________________________________ > > Hmmm... Another reason that we need to definitively define what > constitutes a valid H-I value and what does not. (This is tracker issue 34: > http://tools.ietf.org/wg/sipcore/trac/ticket/34) > [MB] Dale - I don't see that Issue 34 is related to this specific issue. Please see my response to issue 34 on the mailing list. [/MB] > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --00163630f5fb293e570494c40786 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Responses inline below [MB].


On Thu, Nov 11, 2010 at 1:59 AM, Worley, Dal= e R (Dale) <dworley@avaya.com> wrote:
________________________________________
From: sipcore= -bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Hadriel Kaplan [HKaplan@acmepacket.= com]

Out of curiosity, will anything "break" if the anonymized H-I ent= ries are simply removed? =A0I'm not suggesting we document doing that i= n the draft, just asking if any apps/use-cases/whatever will break if it ha= ppens. =A0Because my guess is some of us will just remove them, and I'd= like to know if there's any real reason I shouldn't.
[MB] Hadriel - There is text that describes that ap= plications must be able to handle gaps and thus not break. We can't pol= ice the protocol, but removing the entries would not be normative behavior = since it could impact an end application that wants to make use of the info= rmation. This is the usual be generous in what you receive...[/MB]
_______________________________________________

Hmmm... =A0Another reason that we need to definitively define what constitu= tes a valid H-I value and what does not. =A0(This is tracker issue 34: h= ttp://tools.ietf.org/wg/sipcore/trac/ticket/34)
[MB] Dale - I don't see that Issue 34 is related to t= his specific issue. Please see my response to issue 34 on the mailing list.= [/MB]


Dale
_______________________________________________=
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore
=
--00163630f5fb293e570494c40786-- From dworley@avaya.com Thu Nov 11 02:07:48 2010 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 E61D23A6873 for ; Thu, 11 Nov 2010 02:07:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.402 X-Spam-Level: X-Spam-Status: No, score=-102.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, 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 4J9-AGcDLy0I for ; Thu, 11 Nov 2010 02:07:48 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id D5AC13A69D0 for ; Thu, 11 Nov 2010 02:07:47 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJVP20zGmAcF/2dsb2JhbACiQXGmUQKZNoVKBIRaiSM X-IronPort-AV: E=Sophos;i="4.59,182,1288584000"; d="scan'208";a="249557356" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 11 Nov 2010 05:08:16 -0500 X-IronPort-AV: E=Sophos;i="4.59,182,1288584000"; d="scan'208";a="539222195" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Nov 2010 05:08:16 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Thu, 11 Nov 2010 05:08:15 -0500 From: "Worley, Dale R (Dale)" To: "R.Jesske@telekom.de" , "marianne.mohali@orange-ftgroup.com" , "HKaplan@acmepacket.com" , "shida@ntt-at.com" Date: Thu, 11 Nov 2010 05:08:15 -0500 Thread-Topic: [sipcore] Reason as a parameter rather than anescapedheader (was Comments on draft-ietf-sipcore-rfc4244bis-02) Thread-Index: Act/Dp+TWptJkoHxTKmW70ParzWVEwACbydAAAfV2GAAHYTyEAB2K5aS Message-ID: References: <4CD6C020.7030603@cisco.com><4CD7555F.30609@cisco.com> <9886E5FCA6D76549A3011068483A4BD406D5CF8B@S4DE8PSAAQB.mitte.t-com.de> , <9886E5FCA6D76549A3011068483A4BD406D5D22C@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD406D5D22C@S4DE8PSAAQB.mitte.t-com.de> 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 Cc: "sipcore@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 10:07:49 -0000 From: R.Jesske@telekom.de > Question is if we could make the Reason optional instead mandatory > for cases where the retargeting was based on a SIP Response? >=20 > I cannot see what will break if we do it as a option. (For Call > forwarding it is important that we can count the real > forwarding's. It is not really important on which the forwarding's > are based.) Since 4244 does not require Reason headers, any implementation should be able to cope with with the absence of Reason. However, there is a subtle aspect: In the current 4244bis, it seems that the presence of a Reason header on a history-entry documents that the request carrying that URI has completed (and returned the specified response). If I'm correct in this, omitting a Reason header has an additional meaning and so can't be made optional. > Next Question is if we could use instead the RFC4458 causes with > further values. I know I asked already this question but I didn't > get a clear answer why not to use. RFC4458 does define this causes > not only for the cases Voicemail and IVR, it says: "such as". >=20 > What are the opinions on that. If I understand RFC 4458 correctly, the 'cause' URI-parameter is added to the "new" URI to indicate the reason it was generated or used. Assuming History-Info shows how and why each request-URI was generated, the 'cause' URI-parameter is redundant. However, if we define further 'cause' values, it might provide additional information. > Within ISUP the Redirecting reason is within the Redirection > Information Parameter included which is not bind to any of the > Numbers. It is a own Parameter. So there are not the problems where > and how to place the "cause" It does seem to me that this causes a problem in interworking, but I might be wrong. Dale From trac@tools.ietf.org Thu Nov 11 02:28:12 2010 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 C39223A683A for ; Thu, 11 Nov 2010 02:28:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, 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 eibbPxEVEAdc for ; Thu, 11 Nov 2010 02:28:12 -0800 (PST) Received: from zinfandel.tools.ietf.org (unknown [IPv6:2001:1890:1112:1::2a]) by core3.amsl.com (Postfix) with ESMTP id 31F673A686B for ; Thu, 11 Nov 2010 02:28:12 -0800 (PST) Received: from localhost ([::1] helo=zinfandel.tools.ietf.org) by zinfandel.tools.ietf.org with esmtp (Exim 4.72) (envelope-from ) id 1PGUOW-00060A-Ju; Thu, 11 Nov 2010 02:28:40 -0800 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit From: "sipcore issue tracker" X-Trac-Version: 0.11.7 Precedence: bulk Auto-Submitted: auto-generated X-Mailer: Trac 0.11.7, by Edgewall Software To: worley@alum.mit.edu X-Trac-Project: sipcore Date: Thu, 11 Nov 2010 10:28:40 -0000 X-URL: http://tools.ietf.org/sipcore/ X-Trac-Ticket-URL: http://tools.ietf.org/wg/sipcore/trac/ticket/12#comment:1 Message-ID: <073.72870041f0f819efce2e45d8a2e833b0@tools.ietf.org> References: <064.89665f0da52766f4162641242eae3a7e@tools.ietf.org> X-Trac-Ticket-ID: 12 In-Reply-To: <064.89665f0da52766f4162641242eae3a7e@tools.ietf.org> X-SA-Exim-Connect-IP: ::1 X-SA-Exim-Rcpt-To: worley@alum.mit.edu, sipcore@ietf.org X-SA-Exim-Mail-From: trac@tools.ietf.org X-SA-Exim-Scanned: No (on zinfandel.tools.ietf.org); SAEximRunCond expanded to false Cc: sipcore@ietf.org Subject: Re: [sipcore] rfc4244bis #12 (new): Section 7 on Application Considerations needs work X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 10:28:12 -0000 #12: Section 7 on Application Considerations needs work Comment(by worley@…): Indeed, section 7 should present sample (not normative) algorithms that particular applications might use, to show that the 4244bis mechanism actually does support the applications that people want. -- ------------------------------------+--------------------------------------- Reporter: hkaplan@… | Owner: Type: enhancement | Status: new Priority: major | Milestone: milestone1 Component: rfc4244bis | Version: 2.0 Severity: In WG Last Call | Keywords: ------------------------------------+--------------------------------------- Ticket URL: sipcore From dworley@avaya.com Thu Nov 11 02:41:35 2010 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 6AD2E3A68C6 for ; Thu, 11 Nov 2010 02:41:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.41 X-Spam-Level: X-Spam-Status: No, score=-102.41 tagged_above=-999 required=5 tests=[AWL=0.189, BAYES_00=-2.599, 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 5AtnTdyHfA7A for ; Thu, 11 Nov 2010 02:41:33 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 956AD3A6933 for ; Thu, 11 Nov 2010 02:41:31 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAtX20zGmAcF/2dsb2JhbACiQXGmZgKZPIVKBIRaiSM X-IronPort-AV: E=Sophos;i="4.59,182,1288584000"; d="scan'208";a="218082025" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 11 Nov 2010 05:41:59 -0500 X-IronPort-AV: E=Sophos;i="4.59,182,1288584000"; d="scan'208";a="539233088" Received: from dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 11 Nov 2010 05:41:58 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX2.global.avaya.com ([::1]) with mapi; Thu, 11 Nov 2010 05:41:58 -0500 From: "Worley, Dale R (Dale)" To: Cullen Jennings , "sipcore@ietf.org" , Mary Barnes Date: Thu, 11 Nov 2010 05:39:46 -0500 Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis Thread-Index: AcuBhKpVmXrHPIR2S6Cvc/vbGh0vQgACBe03 Message-ID: References: <14FFF078-E5D1-45F2-8D9A-AD52DE677CEF@cisco.com> In-Reply-To: <14FFF078-E5D1-45F2-8D9A-AD52DE677CEF@cisco.com> 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 Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis 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: Thu, 11 Nov 2010 10:41:36 -0000 ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Cull= en Jennings [fluffy@cisco.com] Specifically I would like to see normative language on how a voicemail syst= em can use the tags found in an incoming invite to determined which mailbox= the call should be delivered too. _______________________________________________ I don't think we should (or even can) make such an algorithm normative, but= the draft should include example algorithms to demonstrate how application= s can do the things that we want to support. Dale From peter.musgrave@magorcorp.com Thu Nov 11 03:44:34 2010 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 1C7953A6A3F for ; Thu, 11 Nov 2010 03:44:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.539 X-Spam-Level: X-Spam-Status: No, score=-102.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, 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 f6DpdbDimC27 for ; Thu, 11 Nov 2010 03:44:32 -0800 (PST) Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 7E0E93A6972 for ; Thu, 11 Nov 2010 03:44:32 -0800 (PST) Received: by gwb10 with SMTP id 10so682416gwb.31 for ; Thu, 11 Nov 2010 03:45:01 -0800 (PST) Received: by 10.151.9.18 with SMTP id m18mr1584926ybi.172.1289475901789; Thu, 11 Nov 2010 03:45:01 -0800 (PST) Received: from dhcp-728b.meeting.ietf.org (dhcp-728b.meeting.ietf.org [130.129.114.139]) by mx.google.com with ESMTPS id 43sm1436125yhl.37.2010.11.11.03.44.59 (version=TLSv1/SSLv3 cipher=RC4-MD5); Thu, 11 Nov 2010 03:45:01 -0800 (PST) From: Peter Musgrave Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Nov 2010 19:44:56 +0800 Message-Id: <1C1C437E-769D-49C1-9724-4A257626D6F2@magorcorp.com> To: sipcore@ietf.org Mime-Version: 1.0 (Apple Message framework v1082) X-Mailer: Apple Mail (2.1082) Subject: [sipcore] Raw Minutes 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: Thu, 11 Nov 2010 11:44:34 -0000 SIPCORE IETF79 Beijing As per agenda.. =3D=3D Location Conveyance =3D=3D James Polk/John Peterson 424 issue: Martin - agrees with the proposal on the slide Any disagreement? No Defer call for consensus until there is specific text Rough ordering point: Is this ok? Hadriel: Are we being too wishy washy? Should we be more specific? Is = this unavoidable? John: Consensus on list was to allow multiple location objects.=20 Hadriel: Can we have a rule which is more specific? (Some discussion of the past history and some of the corner cases which = makes this hard) Hans expressed support for chronological order, but rules to decide = which one are hard.=20 Martin - are we attaching semantics (e.g. with chrono order). Safer to = just consider as a set.=20 John - order might be easy and can say caveat emptier=85don;t see the = harm Martin - either way is ok Adam: Who is ok with putting text to say "insertion must be done at the = end of the list"? Ok? 18 Not? 0 (consensus) geolocation option-tag? Error codes were viewed as somewhat cumbersome (review by John Elwell). = Idea is to use option-tag profiles. List discussion very favourable.=20 John Elwell: This is ok. Concern about use in Require=85 JohnP: Leaving the door open, might not need it.=20 Keith: What happens with multiple locations and end-to-end support of a = tag=85will option tag get changed JohnP: You would add additional supported tags as it goes=85in the case = of intermediary.=20 Hadriel: Concerned about putting this in Require. Do we want calls to = fail in those cases?=20 John: MIght be useful in error code.=20 Martin: Use in requests might not make sense, but in responses seems = appropriate (esp. 424) Adam: Starting to see warts now that we've discussed=85especially if we = get two of these in a message etc.=20 JohnP: A lot of this is an artifact of multiple locations, we could find = some remedies e.g. tag on header instead of in supported.=20 Martin: Request in geolocation has a URI, don't need to say how to use a = particular URI.=20 JohnP: Unless we're committed to one profile then we need multiple = location cases.=20 Martin: Let's put a new parameter in header with a new RFC=85 JohnP: Gross profile solution might work=85 Hadriel: option-tag is a hammer looking for nail=85if it's in Suppored = need to put in all all the time.=20 JohnP: We conceded supported in request might not be useful, but in = response it is. James Polk: Just one location would solve this=85.the pain threshold for = this is high.=20 Hadriel: It's a collision of scheme - not solved by just one location.=20= RJS: Can we make time for more discussion?=20 Geolocation Header Errors: Martin: Are the errors actionable? James: We need these error codes. Martin: But I can't do anything with the information.=20 (Discussion about specific error codes=85100, 424, 301, 302 etc.) Martin: Lot of mechanism here - not sure it adds a lot of info other = than better feedback.=20 JohnP: What do the different subsides tell us? James: Retention, Routing Allowed could result in=20 James: Pizza hit case=85(rapid steam of error codes), server could = correct and retyr.=20 Martin: Maybe, but the cost is high for this.=20 Hadriel: Detailed error codes are for troubleshooting - not for = self-healing. They do have value. Richard: Maybe we don't need this detail in this doc. Just put in a = separate doc.=20 Keith: May need another mechanism. Can we accept call but still convey = a geolocation error? JohnP: I think we still need these, want to get to smallest set - maybe = we can a bit more.=20 Hannes: Support for a separate doc seems good idea. Chair: Extend discussion James: Disagree with separate doc.=20 James: Geopriv was very fixed on this=855606 is a bad case=85 Allysa: Geopriv fields are directives for a recipient.=20 Martin: They will take the call (technical side track discussion - which I didn't follow) Hadriel: Beware reason phrases - they do not localize (more debate=85) JohnP: Let's take an expedient path. Leave what's in there. It does no = harm. Consensus Call: Should we leave in error codes as they are: Adam: Consensus for leaving in.=20 Adam: Let's try and do some interim work to get this done=85watch the = list for details.=20 (some process description. ) RJS: Let's put text in the doc.=20 Keith: Strong objection.=20 =3D=3D History Info & Target-Uri Support =3D=3D Mary Barnes Hadriel: Out-of-Dialog REFER could have H-I=85 (ok - we'll remove the bullet) Scatching it from NOTIFIES.=20 Privacy (1) - any issues with this proposal? (none) Privacy (2) - Issue 4: "none" - Option 2 - ignore PaulK - I'd like to think about this=85. JohnP: Trying to apply 3323 is tough - it's an old doc=85it does not = affect these options. Option 2 is ok.=20 Reason in HI Adam: Agree with leaving it alone=85anything else out of scope Dale: In favour. (with explanation) PaulK: Ok - I give up.=20 Adam: Anyone against.=20 (no) =3D=3D Proxy Features =3D=3D Christer Holmberg Dual-Direction Tags/Path: Dale: Why does UA need info in Path. This is how to get to registrar=85 Hadriel: No INVITE might not follow the same path.=20 Christer: But this is a policy issue=85in some cases yo do want the INV = to follow the same path Dale: Does this not happen by default? (more discussion) PaulK: Rat-hole. Let's move on to the mechanism. (I tuned out here...some discussion about detecting interaction between = intermediaries) Adam: PLease keep the discussion going. We would need to add a MIlestone = and make sure this is the right place for this work. =3D=3D Reason Header Extension for Applications =3D=3D Mary-Anne Not much feedback on the list=85 PaulK: I thought this was germane since we're doing work on HI bis=85 PaulK: Not clear how reason goes into H-I, there are no responses which = allow Reason Roland H: Reason in response is in Dispatch Mary: we don't want to extend 4458 Paul: Is there an interaction with HI which needs to be dealt with Mary: Don't think so.=20 Dale: Many of the codes are straight-forward, but first has to do with = paid services. Might want to be subdivided=85 Cullen: Don't understand why we need this=85 Adam: Work through on the list. Express interest=85.might not be = sipcore=85. Goodnight=85. From fluffy@cisco.com Thu Nov 11 03:46:57 2010 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 694AD3A683A for ; Thu, 11 Nov 2010 03:46:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.573 X-Spam-Level: X-Spam-Status: No, score=-110.573 tagged_above=-999 required=5 tests=[AWL=0.026, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 J7T1h-Q6QFC2 for ; Thu, 11 Nov 2010 03:46:56 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0B9803A6A3F for ; Thu, 11 Nov 2010 03:46:56 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEZm20yrR7Hu/2dsb2JhbACiQXGkY5tQhUoEhFqFPEKDCw X-IronPort-AV: E=Sophos;i="4.59,182,1288569600"; d="scan'208";a="618136039" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 11 Nov 2010 11:47:25 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oABBlOQn007498 for ; Thu, 11 Nov 2010 11:47:25 GMT From: Cullen Jennings Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Date: Thu, 11 Nov 2010 04:47:46 -0700 Message-Id: <39D9259D-1505-4008-89DD-C8C1909D814C@cisco.com> To: sipcore@ietf.org Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Subject: [sipcore] Notes from SIPCORE meeting IETF 79 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: Thu, 11 Nov 2010 11:46:57 -0000 Chair Slides - See slides for status of drafts ---------------------------------------------------- Location Conveyance 1) Number of location values.=20 Draft will allow as many as you want with warning not to do it.=20 No objections to the 424 handling proposed. Martin like this and pointed = out only this is the reasonable thing to do. Richard Barnes agrees too.=20= 2) Ordering of location, what does it mean The order is the order they were added and mean nothing more or less = than that.=20 Hadriel said he did not understand this work then convinced us he was = right.=20 Hannu: He likes the multiple objects and like adding them in = chronological order. He does not think it is possible to provide a rule = that does better than this.=20 Martin : Would prefer to say that it is just a set and the ordering does = not provide chronological. Jon thinks it easy to order these (like Vias) = and there are environments. Jon does not see harm, Martin can live that.=20= We agreed that you MUST add location to the end of the set. (18 in = favor, zero against) 3) There was a bunch of fluff. Propose replacing the fluff with a = option tag for each type of differencing. This allows one to use normal = SIP extensibility to replace the fluff.=20 John Elwell: happy with general proposal. Pointed out using Require = does not make sense. Hadriel could not imagine when you put this in a = Require.=20 Martin pointed out that this will end up in the Supported header in a = 424 and it is actionable.=20 Adam: noticed it has warts and they are effectively profiles. We end up = needed one option tag for each for each URI and no good way to = correlated the option tag with the correct URL.=20 Jon: could approach this with things like putting the tag on the URL so = they are correlated. May be better approaches.=20 Adam: there are non emergency cases where it makes sense to fail the = call when you can't get a location.=20 Jon:=20 Martin: When you sent a URI, it has all the information you need to know = to get the location Jon: I am the ghost of Rohan Mahy and I have come with an new Event = package to haunt you=20 Geo location Errors Codes The question is when you return different error codes, does the device = receiving the code do anything differently. Ans: if the retransmission = is flag is set to =93no=94, and it got an error saying it needed to be = yes, then it can resend with it set to yes.=20 Martin: points out the price is high and ask if there could be another = SIP code.=20 Hadriel: These codes are also used for logging to help figure out what = went wrong.=20 Richard: does not see the point of the complexity.=20 Keith: need to be able to reject the location but accept the call - so = we need to keep the geoloc error=20 Jon: We tried to get rid of them, can=92t - should have as few as = possible - may be able to get a bit smaller but not much.=20 Hannes: We could use the reason phrase - lots of other protocols do . We could add something later.=20 Jon made strong argument for leaving it as it is is the quickest path to = get done and this does not harm.=20 Neutral Observer: you can go to a separate room and discuss offline = along with 3 dimensional color holograms to visualize the options=20 Hum Do you believe we should leave in the base specification the error = location codes as they are roughly today. It was strong consensus to = leave in.=20 Result: Leave the error codes in roughly as they are today.=20 4) Will close this on the list=20 Chairs will put information on list with plan to move this faster.=20 AD Position: The authors have a clear guidance on way to update this. = They will update that in the draft and if it turns out it does not work = we can decide how to change the draft.=20 --------------------------------------- Delivering request-URI and parameters to UAS via proxy There was an ad-hoc meeting on Monday.=20 There seems to be some debate about what was agreed to at the Monday = meeting.=20 We are scratching the out of dialog refer in the bullet in slides - It = can be in out of dialog refers. Just not notifies.=20 Slide 6: Issue 3. Hadriel points out this solution is really weird. This = is to hides your domain.=20 Issue #4: Paul was not especial OK with this. No one else expressed = opinions. Paul wants to think about it.=20 Jon: Trying to apply 3323 to model day is going to be hard. The design = of 3323 was you would use a service that provided they anonymization = service. =93none=94 was for the case you were forced through it but did = not want it to anything. Choosing option 2 to issue 4 seems as good as = anything.=20 Hadriel: problem here 3323 was designed about protecting who it was from = and HI is about who it is going to and just hard to map. Andrew points = out this is not exactly the case and it does provide some privacy.=20 Slide 8: Reason header issue=20 Adam (as individual) agreed with this recommendation to meet goals of WG = milestone. Dale also supports this as this will help reveal why the = previous request failed. Paul gives up on this misguided idea and = supports this.=20 No one objected to this.=20 --------------------------------------------- Proxy Feature Tags Dale: What do you need this for, why wouldn=92t your INVITE go same path = as Register? Evidently IMS likes the invite to get lost but Register = work fine. No information on why was provided. Paul tried to stop the = rat hole. It sounded more like a full blown routing rabbit warren.=20 Chair: we should discuss more about mechanisms, instead of use cases. Problem with option tags require RFC but that would probably not work = for session continuity.=20 Andrew Alan: Would like to solve this - would like to solve service = interaction problem. Would like to be able to fine the URI of = intermediaries on the path so one can send them out of dial requests.=20 Chair: Let=92s move the discussion to mailing list. ----------------------------------------------- Reason Header Extension for Applications Paul K (as individual): We don=92t even have a place you can put this in = the HI today.=20 Christer: has a draft in to put Reason code in HI=20 Hadriel: The internal proxy processing of HI might be able to be used = for this=20 Mary: We probably need to update HI to be clear about this=20 Dale: several of these just indicate why a number was translated=20 Dale: The paid service code may need to be subdivided into multiple = cases=20 I don't understand why we need this=20 Chair: would need to take to list and not clear if sipcore would be = right place or not =20 Thank you Cullen and the secret but supper helpful Anonymous User 6 to = take the minutes!= From pkyzivat@cisco.com Thu Nov 11 06:41:37 2010 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 748DB3A695D for ; Thu, 11 Nov 2010 06:41:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.143 X-Spam-Level: X-Spam-Status: No, score=-110.143 tagged_above=-999 required=5 tests=[AWL=-0.144, BAYES_00=-2.599, J_CHICKENPOX_32=0.6, RCVD_IN_DNSWL_HI=-8, 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 QEzCasCclLpz for ; Thu, 11 Nov 2010 06:41:36 -0800 (PST) Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id 0F89D3A68A0 for ; Thu, 11 Nov 2010 06:41:36 -0800 (PST) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEqP20xAaMHG/2dsb2JhbACiQ3GlB5tYhUoEhFiGAIML X-IronPort-AV: E=Sophos;i="4.59,183,1288569600"; d="scan'208";a="618200786" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-6.cisco.com with ESMTP; 11 Nov 2010 14:42:04 +0000 Received: from [10.75.233.107] (hkidc-vpn-client-233-107.cisco.com [10.75.233.107]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oABEg03w008522; Thu, 11 Nov 2010 14:42:02 GMT Message-ID: <4CDC00B6.2020803@cisco.com> Date: Thu, 11 Nov 2010 22:41:58 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Taisto Qvist References: <613AADD0FA18314792D9A3F64FE2FB740D35B051A7@ESESSCMS0351.eemea.ericsson.se> <4CDA712B.6030300@cisco.com> <613AADD0FA18314792D9A3F64FE2FB740D35B056A3@ESESSCMS0351.eemea.ericsson.se> In-Reply-To: <613AADD0FA18314792D9A3F64FE2FB740D35B056A3@ESESSCMS0351.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-06 and new contact in 2xx to *inital* invite 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: Thu, 11 Nov 2010 14:41:37 -0000 On 11/11/2010 5:05 PM, Taisto Qvist wrote: >> A UAS MAY send as many provisional responses as it likes. Each of these MUST >> indicate the same dialog ID. However, these will not be delivered reliably. >> >> Which implies to me, that a *single* UAS can not send multiple 1xx >> with different tags? > > Perhaps this is a matter of terminology. > If you prefer, consider the same box to contain multiple UAs, each of which received a forked copy of the request. Then each returns a single response with a unique to-tag. > There are a number of cases where this is a viable strategy for handling various problems. > > [TQ] > It most certainly is. But when I read that paragraph it doesnt indicate a generic endpoint which consists of multiple UAS:es that received several forked requests. > Too me, it claims that a single UAS, that has received a *single* request, can respond to that single transaction, with multiple provisional responses, creating > multiple early dialogs by using different tags. That seems to completely contradict rfc3261. > > But maybe I'm just beeing a bit to literal, although for interoperability reasons, I think that maybe we should be :-) The way to think of this (its a conceptual model, not a real one) is that the UA may choose to virtually fork the request to several of its evil twins. Then each one of those can independently handle the request, with its own to-tag. The fact that the forking happened without any message passing is irrelevant to the UAC - it all looks to the same as if the forking really happened. Thanks, Paul From pkyzivat@cisco.com Thu Nov 11 06:59:52 2010 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 EA9043A6970 for ; Thu, 11 Nov 2010 06:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.439 X-Spam-Level: X-Spam-Status: No, score=-110.439 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 ZB8HWKBtmLG1 for ; Thu, 11 Nov 2010 06:59:52 -0800 (PST) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 14E633A6851 for ; Thu, 11 Nov 2010 06:59:52 -0800 (PST) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEADeU20xAaMHG/2dsb2JhbACiRXGlHZtWhUoEhFiGAIML X-IronPort-AV: E=Sophos;i="4.59,183,1288569600"; d="scan'208";a="215581084" Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-4.cisco.com with ESMTP; 11 Nov 2010 15:00:13 +0000 Received: from [10.75.233.107] (hkidc-vpn-client-233-107.cisco.com [10.75.233.107]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oABF04bZ010614; Thu, 11 Nov 2010 15:00:06 GMT Message-ID: <4CDC04F2.3010701@cisco.com> Date: Thu, 11 Nov 2010 23:00:02 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "Worley, Dale R (Dale)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Nov 2010 14:59:53 -0000 inline On 11/11/2010 5:09 PM, Worley, Dale R (Dale) wrote: > 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 yep >>> 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. > 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? >> 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. I disagree its a good thing. If we need new response codes we can define them, so we shouldn't in general need new response codes to clarify response codes. Perhaps the Q.850 stuff is a special case since we are there relating things from a different and independent namespace. Even then its a bit dicy. 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. Thanks, Paul From HKaplan@acmepacket.com Thu Nov 11 18:05:48 2010 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 4ED593A67F7 for ; Thu, 11 Nov 2010 18:05:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.058 X-Spam-Level: X-Spam-Status: No, score=-2.058 tagged_above=-999 required=5 tests=[AWL=0.541, BAYES_00=-2.599] 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 YO2yTm8iUyzY for ; Thu, 11 Nov 2010 18:05:47 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 66D903A6781 for ; Thu, 11 Nov 2010 18:05:47 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 11 Nov 2010 21:06:18 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 11 Nov 2010 21:06:18 -0500 From: Hadriel Kaplan To: "sipcore@ietf.org WG" Date: Thu, 11 Nov 2010 21:06:16 -0500 Thread-Topic: Why doesn't 4244bis cover Marianne's use-case? Thread-Index: AcuCDjF+SApIdspJSNqP2SboPfuUGA== Message-ID: <2F27AF47-BD50-45FC-A832-DD845EEAA8FA@acmepacket.com> 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 Subject: [sipcore] Why doesn't 4244bis cover Marianne's use-case? 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: Fri, 12 Nov 2010 02:05:48 -0000 Hi, It was unfortunate that we ran out of time in sipcore to talk about Mariann= e's draft, because I think it's a kind of litmus test of rfc4244bis. Or el= se I think I must be missing something very basic. (easily the case) When I read Marianne's draft, it sounds like the use-case she's trying to c= over is call-forwarding, for things like voicemail systems to be able to de= tect/process. So what really confuses me is I thought one of the basic app= lications 4244bis was trying to enable was exactly that one. Right? If it= 's not sufficient to achieve that, I think we've screwed up somewhere... or= at least need to make sure it's not something we can fix in 4244bis, becau= se now would be a really good time to fix it. :) My 2 cents. -hadriel= From adam@nostrum.com Thu Nov 11 18:53:12 2010 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 8B9343A6781 for ; Thu, 11 Nov 2010 18:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.56 X-Spam-Level: X-Spam-Status: No, score=-102.56 tagged_above=-999 required=5 tests=[AWL=0.040, BAYES_00=-2.599, SPF_PASS=-0.001, 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 NmRVYQl-GB98 for ; Thu, 11 Nov 2010 18:53:10 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 83DF43A68B6 for ; Thu, 11 Nov 2010 18:53:10 -0800 (PST) Received: from dhcp-48c3.meeting.ietf.org (dhcp-48c3.meeting.ietf.org [130.129.72.195]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oAC2raF0011411 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Thu, 11 Nov 2010 20:53:39 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4CDCAC2F.2090904@nostrum.com> Date: Fri, 12 Nov 2010 10:53:35 +0800 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Hadriel Kaplan References: <2F27AF47-BD50-45FC-A832-DD845EEAA8FA@acmepacket.com> In-Reply-To: <2F27AF47-BD50-45FC-A832-DD845EEAA8FA@acmepacket.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.72.195 is authenticated by a trusted mechanism) Cc: "sipcore@ietf.org WG" Subject: Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case? 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: Fri, 12 Nov 2010 02:53:12 -0000 [as chair] On 11/12/10 10:06 AM, Hadriel Kaplan wrote: > When I read Marianne's draft, it sounds like the use-case she's trying to cover is call-forwarding, for things like voicemail systems to be able to detect/process. So what really confuses me is I thought one of the basic applications 4244bis was trying to enable was exactly that one. Right? If it's not sufficient to achieve that, I think we've screwed up somewhere... or at least need to make sure it's not something we can fix in 4244bis, because now would be a really good time to fix it. :) At IETF 75, when we were discussing the applicability of 4244bis to the SIPCORE charter (as opposed to simply developing a new document that was limited to describing how to use 4244 to deliver URI parameters), one of the rather important points that was made was that we would "limit bis changes to [those necessary to] satisfy target uri requirements." If the RAI community at large wants to expand this to include a general tune-up and/or kitchen-sinking of 4244, then we need to figure out a way to put the SIPCORE milestone to rest and then send the rest of the changes to DISPATCH. I have no interest in letting this milestone drag on as people come up with new things they'd like to see added or changed. /a From HKaplan@acmepacket.com Thu Nov 11 19:31:36 2010 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 8806F3A6980 for ; Thu, 11 Nov 2010 19:31:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.068 X-Spam-Level: X-Spam-Status: No, score=-2.068 tagged_above=-999 required=5 tests=[AWL=0.531, BAYES_00=-2.599] 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 f5WScqtKz5wD for ; Thu, 11 Nov 2010 19:31:35 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 70A793A691B for ; Thu, 11 Nov 2010 19:31:35 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 11 Nov 2010 22:32:06 -0500 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 11 Nov 2010 22:32:06 -0500 From: Hadriel Kaplan To: Adam Roach Date: Thu, 11 Nov 2010 22:32:03 -0500 Thread-Topic: [sipcore] Why doesn't 4244bis cover Marianne's use-case? Thread-Index: AcuCGi1fz/ZUOl2uSquWRR64hshQVg== Message-ID: <479339F9-5AE2-4145-A132-36F53D011ECF@acmepacket.com> References: <2F27AF47-BD50-45FC-A832-DD845EEAA8FA@acmepacket.com> <4CDCAC2F.2090904@nostrum.com> In-Reply-To: <4CDCAC2F.2090904@nostrum.com> 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 Cc: "sipcore@ietf.org WG" Subject: Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case? 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: Fri, 12 Nov 2010 03:31:36 -0000 I'd like a clarification.=20 You said: > "limit bis=20 > changes to [those necessary to] satisfy target uri requirements." If by that you mean literally just to enable GRUU delivery, we've already e= xceeded that. You don't need an "mp" tag for that, for example, afaict. But I'm also not sure it's fair to be that restrictive in your interpretati= on of what the bis can change. Obviously we have to constrain the scope, t= o actually get anywhere. But there's no point in publishing a document if it doesn't solve a problem= people actually have, just for the sake of publishing a document.=20 [soapbox] An RFC is not an end goal in itself - it's a means to an end, namely for en= abling interoperable protocols people will *actually use*. [/soapbox] (I know we all agree on this, I'm just venting) BTW, I'm not sure Marianne's use-case requires *ANY* normative changes to r= fc4244bis. I was just commenting that it would have been nice to really un= derstand if rfc4244bis did not cover it. This is similar to Cullen's conce= rn about use-cases/application-examples. We need to make sure the changes = we're making are actually useful. (I think they *are*, or are as close as w= e can get, but that doesn't mean we shouldn't go through the exercise... us= ing H-I just isn't that simple/obvious) -hadriel On Nov 11, 2010, at 9:53 PM, Adam Roach wrote: > [as chair] >=20 > On 11/12/10 10:06 AM, Hadriel Kaplan wrote: >> When I read Marianne's draft, it sounds like the use-case she's trying t= o cover is call-forwarding, for things like voicemail systems to be able to= detect/process. So what really confuses me is I thought one of the basic = applications 4244bis was trying to enable was exactly that one. Right? If= it's not sufficient to achieve that, I think we've screwed up somewhere...= or at least need to make sure it's not something we can fix in 4244bis, be= cause now would be a really good time to fix it. :) >=20 > At IETF 75, when we were discussing the applicability of 4244bis to the=20 > SIPCORE charter (as opposed to simply developing a new document that was= =20 > limited to describing how to use 4244 to deliver URI parameters), one of= =20 > the rather important points that was made was that we would "limit bis=20 > changes to [those necessary to] satisfy target uri requirements." >=20 > If the RAI community at large wants to expand this to include a general=20 > tune-up and/or kitchen-sinking of 4244, then we need to figure out a way= =20 > to put the SIPCORE milestone to rest and then send the rest of the=20 > changes to DISPATCH. I have no interest in letting this milestone drag=20 > on as people come up with new things they'd like to see added or changed. >=20 > /a From youssef.chadli@orange-ftgroup.com Tue Nov 16 09:02:37 2010 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 514103A6DBD for ; Tue, 16 Nov 2010 09:02:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.049 X-Spam-Level: X-Spam-Status: No, score=-2.049 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, J_CHICKENPOX_29=0.6, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_LOW=-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 cox1ew3pGn4C for ; Tue, 16 Nov 2010 09:02:36 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id EA0093A68F2 for ; Tue, 16 Nov 2010 09:02:35 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 7A76E77800D; Tue, 16 Nov 2010 18:06:37 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 77C27858011; Tue, 16 Nov 2010 18:06:23 +0100 (CET) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Tue, 16 Nov 2010 18:01:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Tue, 16 Nov 2010 18:01:18 +0100 Message-ID: <9ECCF01B52E7AB408A7EB85352642141022A9552@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <4CD53DFC.8020401@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Bypassing out-of-service intermediate Proxy Thread-Index: Act9pwQEV7/PjqRaRkKhk2AoTys28QIB/LJA References: <9ECCF01B52E7AB408A7EB8535264214101CD7EE2@ftrdmel0.rd.francetelecom.fr><4C7FDBEE.6080305@nostrum.com>, <9ECCF01B52E7AB408A7EB85352642141020FD443@ftrdmel0.rd.francetelecom.fr> <9ECCF01B52E7AB408A7EB8535264214102155080@ftrdmel0.rd.francetelecom.fr> <4CD16A52.7090006@cisco.com> <9ECCF01B52E7AB408A7EB853526421410221B4E3@ftrdmel0.rd.francetelecom.fr> <4CD53DFC.8020401@cisco.com> From: To: X-OriginalArrivalTime: 16 Nov 2010 17:01:37.0693 (UTC) FILETIME=[EE79ECD0:01CB85AF] Cc: sipcore@ietf.org Subject: Re: [sipcore] Bypassing out-of-service intermediate Proxy 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: Tue, 16 Nov 2010 17:02:37 -0000 =20 > How can the element doing the skipping know? In general it has no idea = of the importance of an element in the route. > Its at the time of insertion into the route that the importance is = known, so that is when such decisions should be made. I see two ways: at the moment of insertion into the Route, as you = mentionned, via a URI parameters ( the element which inserts itself into = the Route knows whether it's could be sikpped) or via a static = configuration ( which is of course less flexible solution) Best Regards,=20 Youssef =20 -----Message d'origine----- De : Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Envoy=E9 : samedi 6 novembre 2010 12:38 =C0 : CHADLI Youssef RD-CORE-ISS Cc : sipcore@ietf.org Objet : Re: [sipcore] Bypassing out-of-service intermediate Proxy On 11/5/2010 2:44 PM, youssef.chadli@orange-ftgroup.com wrote: > > I don't think this analogy is correct. > > If you take the example of a SIP Server which is inserted in the SIP = path only to provide a supplementary service in case this latter is = requested by the user ( e.g. call transfer), I think that the user will = not be satisfied if it's call does not succeed just because the network = is not able to provide this service... Sure, the analogy *might* not always be correct, though it surely will = be correct in some / many cases. How can the element doing the skipping know? In general it has no idea = of the importance of an element in the route. Its at the time of insertion into the route that the importance is = known, so that is when such decisions should be made. Thanks, Paul > > Youssef > > -----Message d'origine----- > De : sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] De la=20 > part de Paul Kyzivat Envoy=E9 : mercredi 3 novembre 2010 14:58 =C0 :=20 > sipcore@ietf.org Objet : Re: [sipcore] Bypassing out-of-service=20 > intermediate Proxy > > This idea seems analogous to the auto assembly line deciding to bypass = > the broken station where the engine is inserted into the car, and just = > send the car on to the next station without its engine. The consumer=20 > who receives this car may be less than satisfied. :-( > > Thanks, > Paul > > On 11/3/2010 5:55 AM, youssef.chadli@orange-ftgroup.com wrote: >> >> I understand that the usage of DNS to provide alternate server is a = way to ensure redundancy. In such solution, to be able to handle SIP = requests inside a SIP dialog and for which the proxy need to be "dialog = statefull", there is a need to implement a mechanism that would allow = the "alternate" server to share the same SIP dialog contexts. >> >> My idea is in case of unavailability of the next hop and in case no=20 >> alternate server is returned by DNS (or alternate servers are=20 >> unreachable too), instead of rejecting the request (which would make=20 >> the call/session fails), the SIP Proxy may send it to the hop after=20 >> the unreachable one in the Route. This alternative would be=20 >> authorized only if the Proxy knows that it's better to bypass the=20 >> unreachable node instead of rejecting the request. The SIP proxy may=20 >> get this information via a URI parameter in the Route entry of the=20 >> "unreachable" node for example >> >> Best regards, >> >> Youssef >> >> -----Message d'origine----- >> De : Worley, Dale R (Dale) [mailto:dworley@avaya.com] Envoy=E9 : >> vendredi 29 octobre 2010 20:22 =C0 : CHADLI Youssef RD-CORE-ISS;=20 >> adam@nostrum.com Cc : sipcore@ietf.org Objet : RE: [sipcore]=20 >> Bypassing out-of-service intermediate Proxy >> >> ________________________________________ >> From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf=20 >> Of youssef.chadli@orange-ftgroup.com=20 >> [youssef.chadli@orange-ftgroup.com] >> >> I understand that the intention of this text in RFC 3261 is to fail = over to an alternate server that serves the same function. Though, it's = not explicitly stated. >> >> However, I did not find any text in RFC 3261 that would make = forbidden failing over to a proxy further down the path. Moreover, I = did not see any problem to such behaviour. >> ________________________________ >> >> If a particular URI is included in a Route header, then there is some = important function the server with that URI is to perform. If one = element ignores this URI and sends the request to the next URI in the = Route header, presumably the function of the skipped server will not be = performed. >> >> In all cases that I have heard about, the correct way to provide = alternate servers for a failed server is to construct a DNS SRV name = which maps to the primary and alternate server as is desired. >> >> For instance, if functionA is to be serviced by serverA but in an = emergency the request can be routed to serverB, and if functionB is = serviced by serverB, then we construct two SRV names: >> >> functionA SRV serverA priority=3D1 >> functionA SRV serverB priority=3D2 >> >> functionB SRV serverB priority=3D1 >> >> and use this Route header: >> >> Route: sip:functionA, sip:functionB >> >> If an element has a request with this Route header, it will send the = request to sp:functionA using the RFC 3263 rules, viz., attempt to send = to serverA, and if that fails, attempt to send to serverB. >> >> Dale >> _______________________________________________ >> 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 > From gonzalo.camarillo@ericsson.com Wed Nov 17 07:02:04 2010 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 5CCEE3A691F for ; Wed, 17 Nov 2010 07:02:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 m5qPw4BgCBP1 for ; Wed, 17 Nov 2010 07:02:03 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 2BF4B3A6904 for ; Wed, 17 Nov 2010 07:02:02 -0800 (PST) X-AuditID: c1b4fb39-b7cabae000005002-96-4ce3ee980a03 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D9.C7.20482.89EE3EC4; Wed, 17 Nov 2010 16:02:48 +0100 (CET) Received: from [131.160.126.132] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.2.234.1; Wed, 17 Nov 2010 16:02:48 +0100 Message-ID: <4CE3EE96.7080902@ericsson.com> Date: Wed, 17 Nov 2010 17:02:46 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: SIPCORE X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Comments on draft-ietf-sipcore-sec-flows-05 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: Wed, 17 Nov 2010 15:02:04 -0000 Hi, a few days ago, I received a publication request for the following draft: http://www.ietf.org/id/draft-ietf-sipcore-sec-flows-05.txt Please, find below a few minor comments on the draft. Cheers, Gonzalo References use the following convention (RFC 5246 [12]). The current recommendation is to use [RFC5246] instead. Something like this should work in xml2rfc: Once you are at it, you may want to also add the following: Add a reference for ASN.1 and X.509 Expand acronyms on their first use (e.g., UA and EKU). Page 28. The word "Section" needs to be capitalized when referring to particular sections (e.g., Section 6 of RFC 5280). Page 28. Some paragraphs contain pointers to the relevant normative behavior as defined in other RFCs. However, some paragraphs do not have those pointers. For example: Some SIP clients incorrectly only do SSLv3 and do not support TLS. Many SIP clients were found to accept expired certificates with no warning or error. In the next paragraph, add a reference to Section 3.2 of RFC 5621: Some implementations used binary MIME encodings while others used base64. It is advisable that implementations send only binary and are prepared to receive either. From pkyzivat@cisco.com Wed Nov 17 16:43:39 2010 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 C8D833A6778 for ; Wed, 17 Nov 2010 16:43:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.699 X-Spam-Level: X-Spam-Status: No, score=-109.699 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_HI=-8, 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 qa3Wxva7oX91 for ; Wed, 17 Nov 2010 16:43:37 -0800 (PST) Received: from sj-iport-5.cisco.com (sj-iport-5.cisco.com [171.68.10.87]) by core3.amsl.com (Postfix) with ESMTP id 550833A677D for ; Wed, 17 Nov 2010 16:43:37 -0800 (PST) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ8F5EyrR7Hu/2dsb2JhbACiU3GkV5swhUsEhFiGAIMM X-IronPort-AV: E=Sophos;i="4.59,214,1288569600"; d="scan'208";a="288357137" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 18 Nov 2010 00:44:19 +0000 Received: from [10.86.253.98] ([10.86.253.98]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id oAI0iICB020733; Thu, 18 Nov 2010 00:44:18 GMT Message-ID: <4CE476E2.70801@cisco.com> Date: Thu, 18 Nov 2010 08:44:18 +0800 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: youssef.chadli@orange-ftgroup.com References: <9ECCF01B52E7AB408A7EB8535264214101CD7EE2@ftrdmel0.rd.francetelecom.fr><4C7FDBEE.6080305@nostrum.com>, <9ECCF01B52E7AB408A7EB85352642141020FD443@ftrdmel0.rd.francetelecom.fr> <9ECCF01B52E7AB408A7EB8535264214102155080@ftrdmel0.rd.francetelecom.fr> <4CD16A52.7090006@cisco.com> <9ECCF01B52E7AB408A7EB853526421410221B4E3@ftrdmel0.rd.francetelecom.fr> <4CD53DFC.8020401@cisco.com> <9ECCF01B52E7AB408A7EB85352642141022A9552@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB85352642141022A9552@ftrdmel0.rd.francetelecom.fr> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Bypassing out-of-service intermediate Proxy 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: Thu, 18 Nov 2010 00:43:39 -0000 Well, if the server knows it can be skipped it could simply not record-route. Or, as Dale suggested, it could record-route with a DNS name that prefers to include it, but that names the predecessor as a lower priority alternative. You are the first person I have ever heard ask for this functionality, so I expect it would be a hard sell to add any new mechanism to the specs to permit this in some other way. If you think it is important, start trying to make a case for it. Thanks, Paul On 11/17/2010 1:01 AM, youssef.chadli@orange-ftgroup.com wrote: > >> How can the element doing the skipping know? In general it has no idea of the importance of an element in the route. >> Its at the time of insertion into the route that the importance is known, so that is when such decisions should be made. > > I see two ways: at the moment of insertion into the Route, as you mentionned, via a URI parameters ( the element which inserts itself into the Route knows whether it's could be sikpped) or via a static configuration ( which is of course less flexible solution) > > Best Regards, > > Youssef > > -----Message d'origine----- > De : Paul Kyzivat [mailto:pkyzivat@cisco.com] > Envoyé : samedi 6 novembre 2010 12:38 > À : CHADLI Youssef RD-CORE-ISS > Cc : sipcore@ietf.org > Objet : Re: [sipcore] Bypassing out-of-service intermediate Proxy > > > > On 11/5/2010 2:44 PM, youssef.chadli@orange-ftgroup.com wrote: >> >> I don't think this analogy is correct. >> >> If you take the example of a SIP Server which is inserted in the SIP path only to provide a supplementary service in case this latter is requested by the user ( e.g. call transfer), I think that the user will not be satisfied if it's call does not succeed just because the network is not able to provide this service... > > Sure, the analogy *might* not always be correct, though it surely will be correct in some / many cases. > > How can the element doing the skipping know? In general it has no idea of the importance of an element in the route. > Its at the time of insertion into the route that the importance is known, so that is when such decisions should be made. > > Thanks, > Paul >> >> Youssef >> >> -----Message d'origine----- >> De : sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] De la >> part de Paul Kyzivat Envoyé : mercredi 3 novembre 2010 14:58 À : >> sipcore@ietf.org Objet : Re: [sipcore] Bypassing out-of-service >> intermediate Proxy >> >> This idea seems analogous to the auto assembly line deciding to bypass >> the broken station where the engine is inserted into the car, and just >> send the car on to the next station without its engine. The consumer >> who receives this car may be less than satisfied. :-( >> >> Thanks, >> Paul >> >> On 11/3/2010 5:55 AM, youssef.chadli@orange-ftgroup.com wrote: >>> >>> I understand that the usage of DNS to provide alternate server is a way to ensure redundancy. In such solution, to be able to handle SIP requests inside a SIP dialog and for which the proxy need to be "dialog statefull", there is a need to implement a mechanism that would allow the "alternate" server to share the same SIP dialog contexts. >>> >>> My idea is in case of unavailability of the next hop and in case no >>> alternate server is returned by DNS (or alternate servers are >>> unreachable too), instead of rejecting the request (which would make >>> the call/session fails), the SIP Proxy may send it to the hop after >>> the unreachable one in the Route. This alternative would be >>> authorized only if the Proxy knows that it's better to bypass the >>> unreachable node instead of rejecting the request. The SIP proxy may >>> get this information via a URI parameter in the Route entry of the >>> "unreachable" node for example >>> >>> Best regards, >>> >>> Youssef >>> >>> -----Message d'origine----- >>> De : Worley, Dale R (Dale) [mailto:dworley@avaya.com] Envoyé : >>> vendredi 29 octobre 2010 20:22 À : CHADLI Youssef RD-CORE-ISS; >>> adam@nostrum.com Cc : sipcore@ietf.org Objet : RE: [sipcore] >>> Bypassing out-of-service intermediate Proxy >>> >>> ________________________________________ >>> From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf >>> Of youssef.chadli@orange-ftgroup.com >>> [youssef.chadli@orange-ftgroup.com] >>> >>> I understand that the intention of this text in RFC 3261 is to fail over to an alternate server that serves the same function. Though, it's not explicitly stated. >>> >>> However, I did not find any text in RFC 3261 that would make forbidden failing over to a proxy further down the path. Moreover, I did not see any problem to such behaviour. >>> ________________________________ >>> >>> If a particular URI is included in a Route header, then there is some important function the server with that URI is to perform. If one element ignores this URI and sends the request to the next URI in the Route header, presumably the function of the skipped server will not be performed. >>> >>> In all cases that I have heard about, the correct way to provide alternate servers for a failed server is to construct a DNS SRV name which maps to the primary and alternate server as is desired. >>> >>> For instance, if functionA is to be serviced by serverA but in an emergency the request can be routed to serverB, and if functionB is serviced by serverB, then we construct two SRV names: >>> >>> functionA SRV serverA priority=1 >>> functionA SRV serverB priority=2 >>> >>> functionB SRV serverB priority=1 >>> >>> and use this Route header: >>> >>> Route: sip:functionA, sip:functionB >>> >>> If an element has a request with this Route header, it will send the request to sp:functionA using the RFC 3263 rules, viz., attempt to send to serverA, and if that fails, attempt to send to serverB. >>> >>> Dale >>> _______________________________________________ >>> 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 >> > From taisto.qvist@ericsson.com Thu Nov 18 06:49:47 2010 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 BAD603A6836 for ; Thu, 18 Nov 2010 06:49:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.977 X-Spam-Level: X-Spam-Status: No, score=-5.977 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4] 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 uyRkDhgSnYHM for ; Thu, 18 Nov 2010 06:49:46 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 5BA793A6818 for ; Thu, 18 Nov 2010 06:49:46 -0800 (PST) X-AuditID: c1b4fb39-b7cabae000005002-0b-4ce53d395b2f Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 8D.20.20482.93D35EC4; Thu, 18 Nov 2010 15:50:33 +0100 (CET) Received: from ESESSCMS0351.eemea.ericsson.se ([169.254.1.104]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 18 Nov 2010 15:50:33 +0100 From: Taisto Qvist To: Bob Penfield , Paul Kyzivat , "sipcore@ietf.org" Date: Thu, 18 Nov 2010 15:50:32 +0100 Thread-Topic: [sipcore] draft-ietf-sipcore-reinvite-06 and new contact in 2xx to *inital* invite Thread-Index: AcuAwH6ei6Kd+huyQ8W42wxgtQfNWQAHkcFwAZPnBlA= Message-ID: <613AADD0FA18314792D9A3F64FE2FB740DEF8BC64C@ESESSCMS0351.eemea.ericsson.se> References: <613AADD0FA18314792D9A3F64FE2FB740D35B051A7@ESESSCMS0351.eemea.ericsson.se> <4CDA712B.6030300@cisco.com> <429446390BA91242867940DBE798A06B8B929076DD@mail> In-Reply-To: <429446390BA91242867940DBE798A06B8B929076DD@mail> 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: AAAAAA== Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-06 and new contact in 2xx to *inital* invite 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: Thu, 18 Nov 2010 14:49:47 -0000 Hi again,=20 I would really like to get more peoples opinion of this.=20 Personally I never made the the interpretation that the reference=20 to 12.2.1.2 was valid in this case. That text explicitly says: When a UAC receives a 2xx response to a target refresh request, it MUST replace the dialog's remote target URI with the URI from the Contact header field in that response, if present. ..and since I didnt see this 2xx, for an initial invite, as a target=20 refresh request. I fine either way, I just think its a bit confusing and want to clear the mist a bit, since I've had problems with this. Having it clarified in "black and white" in an RFC wouldnt be all=20 bad either :-) Regards Taisto Qvist -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Bob Penfield Sent: den 10 november 2010 15:04 To: Paul Kyzivat; sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-06 and new contact in 2x= x to *inital* invite inline >-----Original Message----- >From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 >Behalf Of Paul Kyzivat >Sent: Wednesday, November 10, 2010 5:17 AM >To: sipcore@ietf.org >Subject: Re: [sipcore] draft-ietf-sipcore-reinvite-06 and new contact=20 >in 2xx to *inital* invite > > >On 11/10/2010 5:31 PM, Taisto Qvist wrote: >> Hi folks, >> >> A while ago I started a discussion concerning how a client should be=20 >> have when it receives a new contact in the 2xx of an initial INVITE,=20 >> compared to the early dialog-establishing 183. >> >> My reading of chapter 13.2.2.4, rfc3261, tells me that a client=20 >> should NOT update its remote target with the Contact of the 2xx. >> The Contact of the 2xx, should be the same as the 1xx. >> >> I have now read draft-ietf-sipcore-reinvite-06 and I am trying to=20 >> interpret the results, since even if that document mainly concerns=20 >> re-invite, chapter >> 4.9 discusses the early dialog created by an initial request. >> >> The document does not however mention(?) differences in contact:uri=20 >> between the initial 1xx, and the final 2xx to the INVITE. >> >> The draft mandates that a successfull response, a reliable=20 >> provisional response, or an in-dialog request to the new target=20 >> implies a successfull change of contact-uri. >> >> Should I therefore assume that since a 2xx in a normal (initial)=20 >> invite, is also retransmitted reliably, that a UAC which receives a=20 >> new contact in the 2xx compared to the contact in a 1xx(wether it has=20 >> been sent reliably or not), MUST update its remote target? >> >> Since this (seems to) contradict 13.2.2.4, I would very much=20 >> appreciate your views. > >I'm interested to hear Gonzalo's take on this. >IMO the most reasonable thing to do in this circumstance is to honor=20 >the new contact in the 2xx. This is probably contrary to 3261. Whether=20 >it is supported by ...sipcore-reinvite... may be debatable. > The text below indicates that procedures in 12.2.1.2 should be used when th= e 2xx matches an existing early dialog. These are the same procedures for a= target refresh requests. That section has no procedures for constructing t= he route set, but does indicate that the remote target is updated. I have a= lways used the Contact from the 2xx final response as the remote target of = the confirmed dialog. >> If the dialog identifier in the 2xx response matches the dialog >> identifier of an existing dialog, the dialog MUST be transitioned to >> the "confirmed" state, and the route set for the dialog MUST be >> recomputed based on the 2xx response using the procedures of Section >> 12.2.1.2. Otherwise, a new dialog in the "confirmed" state MUST be >> constructed using the procedures of Section 12.1.2. >> >> >> Note that the only piece of state that is recomputed is the route >> >> set. Other pieces of state such as the highest sequence=20 >> >> numbers >> (remote and local) sent within the dialog are not recomputed. Th= e >> route set only is recomputed for backwards compatibility. RFC >> 2543 did not mandate mirroring of the Record-Route header field i= n >> a 1xx, only 2xx. However, we cannot update the entire state of >> the dialog, since mid-dialog requests may have been sent within >> the early dialog, modifying the sequence numbers, for example. > > Note that the route-set doesn't include the contact. Maybe that was=20 > your point. > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From Internet-Drafts@ietf.org Thu Nov 18 08:45:06 2010 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 E72633A688B; Thu, 18 Nov 2010 08:45:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.261 X-Spam-Level: X-Spam-Status: No, score=-102.261 tagged_above=-999 required=5 tests=[AWL=0.339, BAYES_00=-2.599, 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 MyH+wT0+eYxk; Thu, 18 Nov 2010 08:45:03 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1FBC53A688D; Thu, 18 Nov 2010 08:45:03 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.09 Message-ID: <20101118164503.2990.26860.idtracker@localhost> Date: Thu, 18 Nov 2010 08:45:03 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-sec-flows-06.txt 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: Thu, 18 Nov 2010 16:45:06 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Example call flows using Session Initiation Protocol (SIP) security mechanisms Author(s) : C. Jennings, et al. Filename : draft-ietf-sipcore-sec-flows-06.txt Pages : 74 Date : 2010-11-18 This document shows example call flows demonstrating the use of Transport Layer Security (TLS), and Secure/Multipurpose Internet Mail Extensions (S/MIME) in Session Initiation Protocol (SIP). It also provides information that helps implementers build interoperable SIP software. To help facilitate interoperability testing, it includes certificates used in the example call flows and processes to create certificates for testing. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-sec-flows-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-sec-flows-06.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-18084235.I-D@ietf.org> --NextPart-- From brian@estacado.net Thu Nov 18 08:47:01 2010 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 2AB203A688B for ; Thu, 18 Nov 2010 08:47:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 8tcKIu6Qg69S for ; Thu, 18 Nov 2010 08:47:00 -0800 (PST) Received: from estacado.net (estacado-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:266::2]) by core3.amsl.com (Postfix) with ESMTP id BC9E328C0CF for ; Thu, 18 Nov 2010 08:46:59 -0800 (PST) Received: from [192.168.1.105] (cpe-76-182-241-151.tx.res.rr.com [76.182.241.151]) (authenticated bits=0) by estacado.net (8.14.3/8.14.2) with ESMTP id oAIGlcYA005348 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Nov 2010 10:47:43 -0600 (CST) (envelope-from brian@estacado.net) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Brian Hibbard In-Reply-To: <4CE3EE96.7080902@ericsson.com> Date: Thu, 18 Nov 2010 10:47:38 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4CE3EE96.7080902@ericsson.com> To: Gonzalo Camarillo X-Mailer: Apple Mail (2.1081) Cc: SIPCORE , SIPCORE Chairs Subject: Re: [sipcore] Comments on draft-ietf-sipcore-sec-flows-05 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: Thu, 18 Nov 2010 16:47:01 -0000 Gonzalo, Thank you for your review. I made these revisions to the newly = submitted version draft-ietf-sipcore-sec-flows-06 to address the points = you made: References are now generated with symrefs=3D"yes", sortrefs=3D"yes", = subcompact=3D"no".=20 References to ASN.1 (ITU X.683) and ITU X.509 are added. Acronyms expanded on first use: EKU, UA, and CPIM. "Section" was capitalized in each case when used in a reference. A pointer to Section 26.2.1 of RFC 3261 was added for text on page 28, = "Some SIP clients incorrectly only do SSLv3 and do not support TLS." =20 A pointer to Section 4.1.2.5 of RFC 5280 was added for text on page 28, = "Many SIP clients were found to accept expired certificates with no = warning or error." Reference to Section 3.2 of RFC 5621 for text on page 28, "Some = implementations used binary encodings=85" Thanks, Brian On Nov 17, 2010, at 9:02 AM, Gonzalo Camarillo wrote: > Hi, >=20 > a few days ago, I received a publication request for the following = draft: >=20 > http://www.ietf.org/id/draft-ietf-sipcore-sec-flows-05.txt >=20 > Please, find below a few minor comments on the draft. >=20 > Cheers, >=20 > Gonzalo >=20 >=20 > References use the following convention (RFC 5246 [12]). The current > recommendation is to use [RFC5246] instead. Something like this should > work in xml2rfc: >=20 > >=20 > Once you are at it, you may want to also add the following: >=20 > > >=20 > Add a reference for ASN.1 and X.509 >=20 > Expand acronyms on their first use (e.g., UA and EKU). >=20 > Page 28. The word "Section" needs to be capitalized when referring to > particular sections (e.g., Section 6 of RFC 5280). >=20 > Page 28. Some paragraphs contain pointers to the relevant normative > behavior as defined in other RFCs. However, some paragraphs do not > have those pointers. For example: >=20 > Some SIP clients incorrectly only do SSLv3 and do not support TLS. >=20 > Many SIP clients were found to accept expired certificates with no > warning or error. >=20 >=20 > In the next paragraph, add a reference to Section 3.2 of RFC 5621: >=20 > Some implementations used binary MIME encodings while others used > base64. It is advisable that implementations send only binary and > are prepared to receive either. >=20 >=20 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From dworley@avaya.com Thu Nov 18 12:29:35 2010 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 77CFB3A6834 for ; Thu, 18 Nov 2010 12:29:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.462 X-Spam-Level: X-Spam-Status: No, score=-102.462 tagged_above=-999 required=5 tests=[AWL=0.137, BAYES_00=-2.599, 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 kNt8mQqpe-rr for ; Thu, 18 Nov 2010 12:29:33 -0800 (PST) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by core3.amsl.com (Postfix) with ESMTP id 705783A6811 for ; Thu, 18 Nov 2010 12:29:33 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJcb5UyHCzI1/2dsb2JhbACiV3GmJQKZHoVLBIRaiSY X-IronPort-AV: E=Sophos;i="4.59,218,1288584000"; d="scan'208";a="250806975" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by co300216-co-outbound.net.avaya.com with ESMTP; 18 Nov 2010 15:30:20 -0500 X-IronPort-AV: E=Sophos;i="4.59,218,1288584000"; d="scan'208";a="540470483" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 18 Nov 2010 15:30:20 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Thu, 18 Nov 2010 15:30:20 -0500 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Thu, 18 Nov 2010 15:30:19 -0500 Thread-Topic: [sipcore] Bypassing out-of-service intermediate Proxy Thread-Index: Act7Xx3W16gFkXjRTOqfHfUoU6Sk1wBuYItAApFaf6A= Message-ID: References: <9ECCF01B52E7AB408A7EB8535264214101CD7EE2@ftrdmel0.rd.francetelecom.fr><4C7FDBEE.6080305@nostrum.com>, <9ECCF01B52E7AB408A7EB85352642141020FD443@ftrdmel0.rd.francetelecom.fr> <9ECCF01B52E7AB408A7EB8535264214102155080@ftrdmel0.rd.francetelecom.fr> <4CD16A52.7090006@cisco.com>, <9ECCF01B52E7AB408A7EB853526421410221B4E3@ftrdmel0.rd.francetelecom.fr> In-Reply-To: <9ECCF01B52E7AB408A7EB853526421410221B4E3@ftrdmel0.rd.francetelecom.fr> 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 Subject: Re: [sipcore] Bypassing out-of-service intermediate Proxy 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: Thu, 18 Nov 2010 20:29:36 -0000 ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of yous= sef.chadli@orange-ftgroup.com [youssef.chadli@orange-ftgroup.com] If you take the example of a SIP Server which is inserted in the SIP path o= nly to provide a supplementary service in case this latter is requested by = the user ( e.g. call transfer), I think that the user will not be satisfied= if it's call does not succeed just because the network is not able to prov= ide this service... _______________________________________________ If we are considering how Route is handled, the question is not the failure= of the call to be connected, but rather once the call is established, if t= he server fails, ensuring that later in-dialog requests (e.g., REFER, BYE) = succeed. But in practice, devices that provide supplementary services are usually B2= BUAs (even if they could be implemented as proxies, or nearly so), and the = proposed mechanism will not rescue a call from a failed B2BUA. Dale From rjsparks@nostrum.com Thu Nov 18 19:09:21 2010 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 A32E228C0D9; Thu, 18 Nov 2010 19:09:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.599 X-Spam-Level: X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599, SPF_PASS=-0.001, 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 vm9+0QpCevAA; Thu, 18 Nov 2010 19:09:20 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 8056A3A63C9; Thu, 18 Nov 2010 19:09:19 -0800 (PST) Received: from 132-177-252-45.ip.sipit.net ([132.177.252.45]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oAJ39wFf021051 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 18 Nov 2010 21:10:05 -0600 (CST) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Nov 2010 11:09:57 +0800 Message-Id: To: rai@ietf.org, SIPCORE Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Received-SPF: pass (nostrum.com: 132.177.252.45 is authenticated by a trusted mechanism) Subject: [sipcore] SIPit27 Summary 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: Fri, 19 Nov 2010 03:09:21 -0000 (Also available at ) 
SIPit 27 was hosted by ETSI in cooperation with ITRI in Taiwan, Taipei
the week of November 15-19, 2010.

There were 54 attendees from 22 companies visiting from 10 countries.
We had 34 distinct implementations.=20

We had several first-time attendees at this event, many bringing=20
engineering prototypes.=20

The largest change from the previous SIPit was in the level of support
for RFC5626 (Outbound). Nearly a quarter of the implemenations present
included an outbound implementation. Interestingly, about half of those
supported using outbound only with TCP. Multiparty testing uncovered
a potential problem with that specification (see the notes below).

The roles represented (some implementations act in more than one role)
 25 endpoints
  9 proxy/registrars/b2bua/sbcs
  1 dedicated event server

Implementations using each transport for SIP messages:
   UDP   100%=20
   TCP   86%
   TLS   74% server-auth, 62% mutual-auth
   SCTP  15%
   DTLS   0%

53% the implementations present supported IPv6.

There were no Identity implementations present.

For DNS we had support for:
   Full RFC3263		: 68%=20
   SRV only		: 21%
   A records only	: 11%
   no DNS support	: 0%

Support for various items in the endpoints=20
  64% replaces
  32% 3489stun
  24% outbound=20
  24% turn
  24% path
  20% ice
  20% gruu
  20% diversion
  16% service-route
  16% 5389stun
  16% history-info (there were no implementations of 4244bis)
  12% sip/stun multiplexing
  12% sigcomp
  12% join

Support for various items in the proxies:
  57% path
  29% service-route
  29% sigcomp
  29% diversion
  14% gruu
  14% sip/stun multiplexing
  14% history-info

The endpoints and B2BUAs implemented these methods:
 100% INVITE, CANCEL, ACK, BYE=20
  96% REGISTER
  96% OPTIONS
  92% REFER
  92% NOTIFY=20
  88% SUBSCRIBE
  80% UPDATE
  80% INFO
  76% PRACK=20
  52% MESSAGE
  48% PUBLISH=20

80% of the implementations sent RTP from the port advertised for =
reception (symmetric-rtp).
3 of the implementations required the other party to use symmetric-rtp.

80% of the UAs present both sent RTCP and paid attention to RTCP they =
received.

60% of the endpoints present supported SRTP using sdes.
There was one SRTP-mikey implementation present, and two ZRTP =
implementations.
There were no dtls-srtp implementations at this SIPit.

40% of the endpoints supported multipart/mime.
There were no implementations present with S/MIME support.

32% of the implementations present followed RFC6026 (corrections to the =
INVITE transaction)
52% followed RFC4320 (corrections to the non-INVITE transaction)

There were 3 SIP Event Server implementations (not counting endpoints =
that support events only for refer).
There were 7 SIP Event Client implementations (not counting endpoints =
that support events only for refer).

These event packages were supported:
  Server   Client
    2        6        presence
    1        4        presence.winfo
    0        2        message-summary
    1        3        dialog
    1        3        reg
    0        1        conference
    1        1        xcap-diff
    0        1        reg-gruu

These packages were supported with the eventlist extension:
  Server   Client
    1        3        presence

There was one implementation of event-rate-control, and two =
implementations of subnot-etags present.

There was one Info-Packages implementations present using an =
unregistered payload type.

Four of the proxies present still rely only on max-forwards.=20
There was one implementation of fork-loop-fix, but no implementations of =
max-breadth.

Multiparty tests (notes contributed by Eoin McLeod and Byron Campen)

The spiral and forking tests continue to be helpful, uncovering bugs in =
new endpoint=20
implementations, particularly when there are multiple early-media legs =
or 200 OKs from
multiple branches. The more notable interoperability problems this time =
were
related to Route/Record-Route, especially when making a transition from =
IPv4 to IPv6
across a proxy. Most of those problems were resolved when the =
implementations involved
followed the double record-routing recommendations in RFC5658. That =
said, when there
were many IPv6 hops contributing to the route-set, we began running into =
maximum=20
message-size assumptions in the endpoints. The team working on this =
multiparty
created a clever self-testing tool allowing an endpoint to request a =
number of v6
and v4 hops by using the dialed digits (e.g. 664664446@).

The end of the forking test focused on TLS. We constructed a =
configuration exercised
a TLS connection between each of the partipating elements with a single =
SIP request
(see =
). =
The majority
of the elements involved correctly validated the certificates when =
establishing=20
connections. There were some issues with Record-Route values being =
created that did
not match the certificate contents for the proxy.

We exercised the proxy-doom (see RFC5393) test scenario utilizing a =
larger number
of participating AoRs. Even with the loop detection mechanisms in that =
specification,
the number of messages induced utilizing 30 AoRs flooded the =
participants in this test,
pointing to the need for implementation of Max-Breadth.

The STUN/TURN/ICE multiparty saw successful negotiation of the use of =
reflexive candidates
at each endpoint. We exercised successful calls between endpoints =
supporting Outbound and
those that didn't (but both supporting ICE). We induced a successful =
call with media=20
traversing a TURN trapezoid by putting two endpoints behind different =
NATS, configuring=20
them to not advertise reflexive candidates, and using firewalls to =
prevent each endpoint=20
from seeing the other endpoint's TURN server directly.

We had a significant number of Outbound implementations present, and =
exercised correct
interaction between multiple edge-proxy and registrar implementations. A =
few of the UAs
participating could only establish one flow. The participants discovered =
a potential
problem in RFC5626 - the conditions under which an authoritative =
proxy/register is allowed
to try a second (or subsequent) flow when receiving an error on the =
active flow may be
incorrect. Currently, section 7 of RFC5626 restricts this to when the =
proxy has received
a 430, a 408, or a transport failure. It does not allow quick failover =
if the proxy receives
a 503, or a 480 that may have resulted form a 503 at some proxy between =
the edge proxy and
the authoritative proxy/registrar. The characterization of all responses =
other than 430 or
408 meaning "The targeted instance has already provided its response." =
may be incorrect.
The next SIPit's Outbound multiparty will focus on Flow-Timer behavior.

The SRTP multiparty test continues to expose issues with how different =
implementations
currently achieve "best-effort" security using SDES. Some implement =
RTP/SAVP, others=20
implement RTP/AVP with crypto attributes. We encountered some issues =
with secure RTCP -
even if 32-bit keys are negotiated for RTP, the RTCP still needs to use =
80-bit keys.
One implementation confused the flag indicating unencrypted SRTCP with =
meaning RTCP
(hence leaving out the authentication hash).

We spent some time late in the event introducing torture tests, and =
unusual messages=20
into the network (for example, sending an unsolicted 200 OK to an INVITE =
to the broadcast=20
address, which stimulated BYEs from a few implementations). In general, =
the implementations
at the event handled (or ignored) these messages correctly, but enough =
didn't that we will
continue to try these at the next several events.
From gonzalo.camarillo@ericsson.com Fri Nov 19 04:08:29 2010 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 E97D63A6830 for ; Fri, 19 Nov 2010 04:08:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 MWMhriEm4X9M for ; Fri, 19 Nov 2010 04:08:27 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id E79A23A686B for ; Fri, 19 Nov 2010 04:08:25 -0800 (PST) X-AuditID: c1b4fb39-b7cabae000005002-b5-4ce668eac45f Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 01.B4.20482.AE866EC4; Fri, 19 Nov 2010 13:09:14 +0100 (CET) Received: from [131.160.37.44] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.2.234.1; Fri, 19 Nov 2010 13:09:13 +0100 Message-ID: <4CE668E9.80603@ericsson.com> Date: Fri, 19 Nov 2010 14:09:13 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Thunderbird/3.1.2 MIME-Version: 1.0 To: Brian Hibbard References: <4CE3EE96.7080902@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.1.1 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE , SIPCORE Chairs Subject: Re: [sipcore] Comments on draft-ietf-sipcore-sec-flows-05 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: Fri, 19 Nov 2010 12:08:30 -0000 Hi Brian, thanks for your quick response. I have just requested the IETF LC for this draft. Cheers, Gonzalo On 18/11/2010 6:47 PM, Brian Hibbard wrote: > Gonzalo, > > > Thank you for your review. I made these revisions to the newly submitted version draft-ietf-sipcore-sec-flows-06 to address the points you made: > > References are now generated with symrefs="yes", sortrefs="yes", subcompact="no". > > References to ASN.1 (ITU X.683) and ITU X.509 are added. > > Acronyms expanded on first use: EKU, UA, and CPIM. > > "Section" was capitalized in each case when used in a reference. > > A pointer to Section 26.2.1 of RFC 3261 was added for text on page 28, "Some SIP clients incorrectly only do SSLv3 and do not support TLS." > > A pointer to Section 4.1.2.5 of RFC 5280 was added for text on page 28, "Many SIP clients were found to accept expired certificates with no warning or error." > > Reference to Section 3.2 of RFC 5621 for text on page 28, "Some implementations used binary encodings…" > > Thanks, > Brian > > On Nov 17, 2010, at 9:02 AM, Gonzalo Camarillo wrote: > >> Hi, >> >> a few days ago, I received a publication request for the following draft: >> >> http://www.ietf.org/id/draft-ietf-sipcore-sec-flows-05.txt >> >> Please, find below a few minor comments on the draft. >> >> Cheers, >> >> Gonzalo >> >> >> References use the following convention (RFC 5246 [12]). The current >> recommendation is to use [RFC5246] instead. Something like this should >> work in xml2rfc: >> >> >> >> Once you are at it, you may want to also add the following: >> >> >> >> >> Add a reference for ASN.1 and X.509 >> >> Expand acronyms on their first use (e.g., UA and EKU). >> >> Page 28. The word "Section" needs to be capitalized when referring to >> particular sections (e.g., Section 6 of RFC 5280). >> >> Page 28. Some paragraphs contain pointers to the relevant normative >> behavior as defined in other RFCs. However, some paragraphs do not >> have those pointers. For example: >> >> Some SIP clients incorrectly only do SSLv3 and do not support TLS. >> >> Many SIP clients were found to accept expired certificates with no >> warning or error. >> >> >> In the next paragraph, add a reference to Section 3.2 of RFC 5621: >> >> Some implementations used binary MIME encodings while others used >> base64. It is advisable that implementations send only binary and >> are prepared to receive either. >> >> >> >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > From iesg-secretary@ietf.org Fri Nov 19 04:53:19 2010 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 DC5DA28C0FF; Fri, 19 Nov 2010 04:53:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.557 X-Spam-Level: X-Spam-Status: No, score=-102.557 tagged_above=-999 required=5 tests=[AWL=0.042, BAYES_00=-2.599, 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 CNglldse5Mrh; Fri, 19 Nov 2010 04:53:19 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 353F33A6830; Fri, 19 Nov 2010 04:53:19 -0800 (PST) Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: The IESG To: IETF-Announce X-Test-IDTracker: no X-IETF-IDTracker: 3.09 Message-ID: <20101119125319.1465.41709.idtracker@localhost> Date: Fri, 19 Nov 2010 04:53:19 -0800 Cc: sipcore@ietf.org Subject: [sipcore] Last Call: (Example call flows using Session Initiation Protocol (SIP) security mechanisms) to Informational RFC 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: Fri, 19 Nov 2010 12:53:20 -0000 The IESG has received a request from the Session Initiation Protocol Core WG (sipcore) to consider the following document: - 'Example call flows using Session Initiation Protocol (SIP) security mechanisms' as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2010-12-03. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-sipcore-sec-flows/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-sipcore-sec-flows/ No IPR declarations have been submitted directly on this I-D. From Internet-Drafts@ietf.org Fri Nov 19 06:15:03 2010 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 3ED633A683F; Fri, 19 Nov 2010 06:15:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.388 X-Spam-Level: X-Spam-Status: No, score=-102.388 tagged_above=-999 required=5 tests=[AWL=0.211, BAYES_00=-2.599, 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 cQZh9DiH0r6s; Fri, 19 Nov 2010 06:15:01 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1F7B3A6778; Fri, 19 Nov 2010 06:15:01 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.09 Message-ID: <20101119141501.6848.80470.idtracker@localhost> Date: Fri, 19 Nov 2010 06:15:01 -0800 Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-07.txt 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: Fri, 19 Nov 2010 14:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) Author(s) : G. Camarillo, et al. Filename : draft-ietf-sipcore-reinvite-07.txt Pages : 25 Date : 2010-11-19 In this document, we clarify the handling of re-INVITEs in SIP. We clarify in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, we clarify issues related to target-refresh requests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-reinvite-07.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-reinvite-07.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-11-19060645.I-D@ietf.org> --NextPart-- From henry.sinnreich@gmail.com Fri Nov 19 06:57:50 2010 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 B898C3A67F2; Fri, 19 Nov 2010 06:57:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.099 X-Spam-Level: X-Spam-Status: No, score=-3.099 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599] 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 94bPkwtaJhJI; Fri, 19 Nov 2010 06:57:49 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id EBA953A67E5; Fri, 19 Nov 2010 06:57:48 -0800 (PST) Received: by gxk27 with SMTP id 27so2923585gxk.31 for ; Fri, 19 Nov 2010 06:58:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:user-agent:date:subject:from :to:message-id:thread-topic:thread-index:in-reply-to:mime-version :content-type:content-transfer-encoding; bh=jaOmT2GK1RjRhWchVNTG1Jz14pa08AelGM1B9uNUW/g=; b=W/dgtg1TlgkGKOyquVym+PNWFI/L9riulhNwvoq8sEsQrCdpIb/A3tVa7c0NCHUgl1 J1/kA0sEC4UiIoBupzecLGDLkFIxajj6lLy8OdtvtGP7cegRJG7RRDlezQ++xy7amS5c Q0EDKa5hNRhe7piNi5d05e3mob0Le+8DIVpe4= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=user-agent:date:subject:from:to:message-id:thread-topic :thread-index:in-reply-to:mime-version:content-type :content-transfer-encoding; b=naC1ZViPzmgPSUWO1CMzANVrueQ7lbyz4IGKOyvH3G9NIz0vPRNr+DtEokoFkDa9Wd gD6JUsjJamWgm4X7S0oWhKPS+yEG96+ki9t/g0pzta2/REnlmY0Y8obZf0056W+hrm4g z3nPGGqa2+TcrVd3Cyo1qTA/XnWpMT8O7XDds= Received: by 10.150.54.14 with SMTP id c14mr4005940yba.57.1290178718473; Fri, 19 Nov 2010 06:58:38 -0800 (PST) Received: from [10.0.1.2] (cpe-76-184-225-135.tx.res.rr.com [76.184.225.135]) by mx.google.com with ESMTPS id m12sm1133445ybn.12.2010.11.19.06.58.35 (version=TLSv1/SSLv3 cipher=RC4-MD5); Fri, 19 Nov 2010 06:58:36 -0800 (PST) User-Agent: Microsoft-Entourage/12.27.0.100910 Date: Fri, 19 Nov 2010 08:58:34 -0600 From: Henry Sinnreich To: Robert Sparks , , SIPCORE Message-ID: Thread-Topic: [sipcore] SIPit27 Summary Thread-Index: AcuH+jyxUqlXTY2D9Uq6quYrFVu9Jw== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [sipcore] SIPit27 Summary 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: Fri, 19 Nov 2010 14:57:50 -0000 This is an excellent report and attests a very successful SIPit. Thanks for sharing and Kudos for all the work, Henry On 11/18/10 9:09 PM, "Robert Sparks" wrote: > (Also available at ) > > 
> SIPit 27 was hosted by ETSI in cooperation with ITRI in Taiwan, Taipei
> the week of November 15-19, 2010.
> 
> There were 54 attendees from 22 companies visiting from 10 countries.
> We had 34 distinct implementations.
> 
> We had several first-time attendees at this event, many bringing
> engineering prototypes.
> 
> The largest change from the previous SIPit was in the level of support
> for RFC5626 (Outbound). Nearly a quarter of the implemenations present
> included an outbound implementation. Interestingly, about half of those
> supported using outbound only with TCP. Multiparty testing uncovered
> a potential problem with that specification (see the notes below).
> 
> The roles represented (some implementations act in more than one role)
>  25 endpoints
>   9 proxy/registrars/b2bua/sbcs
>   1 dedicated event server
> 
> Implementations using each transport for SIP messages:
>    UDP   100% 
>    TCP   86%
>    TLS   74% server-auth, 62% mutual-auth
>    SCTP  15%
>    DTLS   0%
> 
> 53% the implementations present supported IPv6.
> 
> There were no Identity implementations present.
> 
> For DNS we had support for:
>    Full RFC3263  : 68%
>    SRV only  : 21%
>    A records only : 11%
>    no DNS support : 0%
> 
> Support for various items in the endpoints
>   64% replaces
>   32% 3489stun
>   24% outbound 
>   24% turn
>   24% path
>   20% ice
>   20% gruu
>   20% diversion
>   16% service-route
>   16% 5389stun
>   16% history-info (there were no implementations of 4244bis)
>   12% sip/stun multiplexing
>   12% sigcomp
>   12% join
> 
> Support for various items in the proxies:
>   57% path
>   29% service-route
>   29% sigcomp
>   29% diversion
>   14% gruu
>   14% sip/stun multiplexing
>   14% history-info
> 
> The endpoints and B2BUAs implemented these methods:
>  100% INVITE, CANCEL, ACK, BYE
>   96% REGISTER
>   96% OPTIONS
>   92% REFER
>   92% NOTIFY 
>   88% SUBSCRIBE
>   80% UPDATE
>   80% INFO
>   76% PRACK 
>   52% MESSAGE
>   48% PUBLISH 
> 
> 80% of the implementations sent RTP from the port advertised for reception
> (symmetric-rtp).
> 3 of the implementations required the other party to use symmetric-rtp.
> 
> 80% of the UAs present both sent RTCP and paid attention to RTCP they
> received.
> 
> 60% of the endpoints present supported SRTP using sdes.
> There was one SRTP-mikey implementation present, and two ZRTP implementations.
> There were no dtls-srtp implementations at this SIPit.
> 
> 40% of the endpoints supported multipart/mime.
> There were no implementations present with S/MIME support.
> 
> 32% of the implementations present followed RFC6026 (corrections to the INVITE
> transaction)
> 52% followed RFC4320 (corrections to the non-INVITE transaction)
> 
> There were 3 SIP Event Server implementations (not counting endpoints that
> support events only for refer).
> There were 7 SIP Event Client implementations (not counting endpoints that
> support events only for refer).
> 
> These event packages were supported:
>   Server   Client
>     2        6        presence
>     1        4        presence.winfo
>     0        2        message-summary
>     1        3        dialog
>     1        3        reg
>     0        1        conference
>     1        1        xcap-diff
>     0        1        reg-gruu
> 
> These packages were supported with the eventlist extension:
>   Server   Client
>     1        3        presence
> 
> There was one implementation of event-rate-control, and two implementations of
> subnot-etags present.
> 
> There was one Info-Packages implementations present using an unregistered
> payload type.
> 
> Four of the proxies present still rely only on max-forwards.
> There was one implementation of fork-loop-fix, but no implementations of
> max-breadth.
> 
> Multiparty tests (notes contributed by Eoin McLeod and Byron Campen)
> 
> The spiral and forking tests continue to be helpful, uncovering bugs in new
> endpoint 
> implementations, particularly when there are multiple early-media legs or 200
> OKs from
> multiple branches. The more notable interoperability problems this time were
> related to Route/Record-Route, especially when making a transition from IPv4
> to IPv6
> across a proxy. Most of those problems were resolved when the implementations
> involved
> followed the double record-routing recommendations in RFC5658. That said, when
> there
> were many IPv6 hops contributing to the route-set, we began running into
> maximum 
> message-size assumptions in the endpoints. The team working on this multiparty
> created a clever self-testing tool allowing an endpoint to request a number of
> v6
> and v4 hops by using the dialed digits (e.g. 664664446@).
> 
> The end of the forking test focused on TLS. We constructed a configuration
> exercised
> a TLS connection between each of the partipating elements with a single SIP
> request
> (see ). The
> majority
> of the elements involved correctly validated the certificates when
> establishing 
> connections. There were some issues with Record-Route values being created
> that did
> not match the certificate contents for the proxy.
> 
> We exercised the proxy-doom (see RFC5393) test scenario utilizing a larger
> number
> of participating AoRs. Even with the loop detection mechanisms in that
> specification,
> the number of messages induced utilizing 30 AoRs flooded the participants in
> this test,
> pointing to the need for implementation of Max-Breadth.
> 
> The STUN/TURN/ICE multiparty saw successful negotiation of the use of
> reflexive candidates
> at each endpoint. We exercised successful calls between endpoints supporting
> Outbound and
> those that didn't (but both supporting ICE). We induced a successful call with
> media 
> traversing a TURN trapezoid by putting two endpoints behind different NATS,
> configuring 
> them to not advertise reflexive candidates, and using firewalls to prevent
> each endpoint 
> from seeing the other endpoint's TURN server directly.
> 
> We had a significant number of Outbound implementations present, and exercised
> correct
> interaction between multiple edge-proxy and registrar implementations. A few
> of the UAs
> participating could only establish one flow. The participants discovered a
> potential
> problem in RFC5626 - the conditions under which an authoritative
> proxy/register is allowed
> to try a second (or subsequent) flow when receiving an error on the active
> flow may be
> incorrect. Currently, section 7 of RFC5626 restricts this to when the proxy
> has received
> a 430, a 408, or a transport failure. It does not allow quick failover if the
> proxy receives
> a 503, or a 480 that may have resulted form a 503 at some proxy between the
> edge proxy and
> the authoritative proxy/registrar. The characterization of all responses other
> than 430 or
> 408 meaning "The targeted instance has already provided its response." may be
> incorrect.
> The next SIPit's Outbound multiparty will focus on Flow-Timer behavior.
> 
> The SRTP multiparty test continues to expose issues with how different
> implementations
> currently achieve "best-effort" security using SDES. Some implement RTP/SAVP,
> others 
> implement RTP/AVP with crypto attributes. We encountered some issues with
> secure RTCP -
> even if 32-bit keys are negotiated for RTP, the RTCP still needs to use 80-bit
> keys.
> One implementation confused the flag indicating unencrypted SRTCP with meaning
> RTCP
> (hence leaving out the authentication hash).
> 
> We spent some time late in the event introducing torture tests, and unusual
> messages 
> into the network (for example, sending an unsolicted 200 OK to an INVITE to
> the broadcast 
> address, which stimulated BYEs from a few implementations). In general, the
> implementations
> at the event handled (or ignored) these messages correctly, but enough didn't
> that we will
> continue to try these at the next several events.
>
> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From marianne.mohali@orange-ftgroup.com Fri Nov 19 07:31:38 2010 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 100453A6818 for ; Fri, 19 Nov 2010 07:31:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.766 X-Spam-Level: X-Spam-Status: No, score=-2.766 tagged_above=-999 required=5 tests=[AWL=0.483, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-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 OT0A916msEei for ; Fri, 19 Nov 2010 07:31:37 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (p-mail1.rd.francetelecom.com [195.101.245.15]) by core3.amsl.com (Postfix) with ESMTP id 37C023A6812 for ; Fri, 19 Nov 2010 07:31:35 -0800 (PST) Received: from p-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id 2E73B8B8008; Fri, 19 Nov 2010 16:33:14 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail1.rd.francetelecom.com (Postfix) with ESMTP id 267258B8002; Fri, 19 Nov 2010 16:33:14 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Fri, 19 Nov 2010 16:32:21 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Fri, 19 Nov 2010 16:32:19 +0100 Message-ID: In-Reply-To: <479339F9-5AE2-4145-A132-36F53D011ECF@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Why doesn't 4244bis cover Marianne's use-case? Thread-Index: AcuCGi1fz/ZUOl2uSquWRR64hshQVgDkFe3A References: <2F27AF47-BD50-45FC-A832-DD845EEAA8FA@acmepacket.com><4CDCAC2F.2090904@nostrum.com> <479339F9-5AE2-4145-A132-36F53D011ECF@acmepacket.com> From: To: , X-OriginalArrivalTime: 19 Nov 2010 15:32:21.0113 (UTC) FILETIME=[F4F1EE90:01CB87FE] Cc: sipcore@ietf.org Subject: Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case? 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: Fri, 19 Nov 2010 15:31:38 -0000 Hi, The objective of draft-mohali-sipcore-reason-extension-application is to = know why and, more exactly, which application has influenced the = session. 4244bis do not cover the need but is necessary to meet the need. 3 Use-cases for application-specific Reason: 1. in accordance with RFC3326, in a BYE or CANCEL to explain why a = session has been released/canceled (general use-case)=20 2. in accordance with 4244bis, escaped in the History-Info header (2 = sub-cases) 2.1. When the call is retargeted (R-URI changed), explaining that it = is because of an application-specific internal decision. 2.2. When there is no retargeting (R-URI unchanged), just to mark in = the session history that this application has been invocated. Work on RFC4244bis has to be concluded and this draft has a different = scope. I don't see any interaction issues. Why not finish RFC4244bis and use this draft both to enrich Reason = header in general and to meet the needs using History-Info (already = covering the use of Reason)? Hadriel, you said "When I read Marianne's draft, it sounds like the = use-case she's trying to cover is call-forwarding"=20 but the presented draft has really NO link with Call Forwarding (it is = an other draft ;-). Marianne > -----Message d'origine----- > De : sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] De la part de Hadriel Kaplan > Envoy=E9 : vendredi 12 novembre 2010 04:32 > =C0 : Adam Roach > Cc : sipcore@ietf.org WG > Objet : Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case? >=20 >=20 > I'd like a clarification.=20 > You said: > > "limit bis > > changes to [those necessary to] satisfy target uri requirements." >=20 >=20 > If by that you mean literally just to enable GRUU delivery,=20 > we've already exceeded that. You don't need an "mp" tag for=20 > that, for example, afaict. >=20 > But I'm also not sure it's fair to be that restrictive in=20 > your interpretation of what the bis can change. Obviously we=20 > have to constrain the scope, to actually get anywhere. > But there's no point in publishing a document if it doesn't=20 > solve a problem people actually have, just for the sake of=20 > publishing a document.=20 >=20 > [soapbox] > An RFC is not an end goal in itself - it's a means to an end,=20 > namely for enabling interoperable protocols people will=20 > *actually use*. > [/soapbox] > (I know we all agree on this, I'm just venting) >=20 > BTW, I'm not sure Marianne's use-case requires *ANY*=20 > normative changes to rfc4244bis. I was just commenting that=20 > it would have been nice to really understand if rfc4244bis=20 > did not cover it. This is similar to Cullen's concern about=20 > use-cases/application-examples. We need to make sure the=20 > changes we're making are actually useful. (I think they=20 > *are*, or are as close as we can get, but that doesn't mean=20 > we shouldn't go through the exercise... using H-I just isn't=20 > that simple/obvious) >=20 > -hadriel >=20 > On Nov 11, 2010, at 9:53 PM, Adam Roach wrote: >=20 > > [as chair] > >=20 > > On 11/12/10 10:06 AM, Hadriel Kaplan wrote: > >> When I read Marianne's draft, it sounds like the use-case=20 > she's trying to cover is call-forwarding, for things like=20 > voicemail systems to be able to detect/process. So what=20 > really confuses me is I thought one of the basic applications=20 > 4244bis was trying to enable was exactly that one. Right? =20 > If it's not sufficient to achieve that, I think we've screwed=20 > up somewhere... or at least need to make sure it's not=20 > something we can fix in 4244bis, because now would be a=20 > really good time to fix it. :) > >=20 > > At IETF 75, when we were discussing the applicability of=20 > 4244bis to the=20 > > SIPCORE charter (as opposed to simply developing a new=20 > document that was=20 > > limited to describing how to use 4244 to deliver URI=20 > parameters), one of=20 > > the rather important points that was made was that we would=20 > "limit bis=20 > > changes to [those necessary to] satisfy target uri requirements." > >=20 > > If the RAI community at large wants to expand this to=20 > include a general=20 > > tune-up and/or kitchen-sinking of 4244, then we need to=20 > figure out a way=20 > > to put the SIPCORE milestone to rest and then send the rest of the=20 > > changes to DISPATCH. I have no interest in letting this=20 > milestone drag=20 > > on as people come up with new things they'd like to see=20 > added or changed. > >=20 > > /a >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From mary.ietf.barnes@gmail.com Fri Nov 19 08:02:12 2010 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 A3DF43A6860 for ; Fri, 19 Nov 2010 08:02:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.561 X-Spam-Level: X-Spam-Status: No, score=-102.561 tagged_above=-999 required=5 tests=[AWL=0.037, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 k6XbKG6y9Nwy for ; Fri, 19 Nov 2010 08:02:11 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 4F6A53A680B for ; Fri, 19 Nov 2010 08:02:11 -0800 (PST) Received: by gyb13 with SMTP id 13so24780gyb.31 for ; Fri, 19 Nov 2010 08:03:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=JRLJPt63c8x0a0kAZk4U3DyuaV5YTjnfUKypaWhSmZo=; b=HcrPIVSqYk2lNU34pP6hI06Hb+Q4gK5bnmHKOjrtFknRItvcaNh7/dyOqNomfCPcpp SYx3a7UUmzD+heHi+W6p4yoOk5w/ROyAG2sbarO05Jjro9t64W6+UuMk1fnr4nrV9q3R n0XQ0ZeRogf6fRK0mbcPizMkqfB0GJtrYtGt8= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=dY7asFhafLv7mU6ZjOGz/L3AQtTCzyHiRk0Rw/Nj8JPwBNvGsuhp6v0pEz/C514qB2 gXHxo8SbUlqChZj/QAcd92tJvYXvUAnrZ7VAjR12WUe2275ain9U4vy9KiHTMC8lCtyp atGs7avRgz7UTCzXOrNsehHENj4q35nLcFM4A= MIME-Version: 1.0 Received: by 10.151.51.15 with SMTP id d15mr3953568ybk.33.1290182580745; Fri, 19 Nov 2010 08:03:00 -0800 (PST) Received: by 10.236.95.35 with HTTP; Fri, 19 Nov 2010 08:03:00 -0800 (PST) In-Reply-To: <479339F9-5AE2-4145-A132-36F53D011ECF@acmepacket.com> References: <2F27AF47-BD50-45FC-A832-DD845EEAA8FA@acmepacket.com> <4CDCAC2F.2090904@nostrum.com> <479339F9-5AE2-4145-A132-36F53D011ECF@acmepacket.com> Date: Fri, 19 Nov 2010 10:03:00 -0600 Message-ID: From: Mary Barnes To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=0015174c0e046bbca604956a0a65 Cc: "sipcore@ietf.org WG" Subject: Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case? 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: Fri, 19 Nov 2010 16:02:12 -0000 --0015174c0e046bbca604956a0a65 Content-Type: text/plain; charset=ISO-8859-1 Response inline below [MB]. Mary. On Thu, Nov 11, 2010 at 9:32 PM, Hadriel Kaplan wrote: > > I'd like a clarification. > You said: > > "limit bis > > changes to [those necessary to] satisfy target uri requirements." > > > If by that you mean literally just to enable GRUU delivery, we've already > exceeded that. You don't need an "mp" tag for that, for example, afaict. > > But I'm also not sure it's fair to be that restrictive in your > interpretation of what the bis can change. Obviously we have to constrain > the scope, to actually get anywhere. > But there's no point in publishing a document if it doesn't solve a problem > people actually have, just for the sake of publishing a document. > > [soapbox] > An RFC is not an end goal in itself - it's a means to an end, namely for > enabling interoperable protocols people will *actually use*. > [/soapbox] > (I know we all agree on this, I'm just venting) > > BTW, I'm not sure Marianne's use-case requires *ANY* normative changes to > rfc4244bis. I was just commenting that it would have been nice to really > understand if rfc4244bis did not cover it. This is similar to Cullen's > concern about use-cases/application-examples. We need to make sure the > changes we're making are actually useful. (I think they *are*, or are as > close as we can get, but that doesn't mean we shouldn't go through the > exercise... using H-I just isn't that simple/obvious) > [MB] Correct, I also do not believe that Marianne's use cases require normative changes to RFC 4244bis, which is really agnostic in terms of the Reason header value. I can certainly see that History-Info header provides necessary functionality for the use case, however, the use cases also require extensions to Reason header values that are normative. For this same reason, we are removing the sub-addressing use case since it requires new functionality beyond what is provided by 4244bis. [/MB] > > -hadriel > > On Nov 11, 2010, at 9:53 PM, Adam Roach wrote: > > > [as chair] > > > > On 11/12/10 10:06 AM, Hadriel Kaplan wrote: > >> When I read Marianne's draft, it sounds like the use-case she's trying > to cover is call-forwarding, for things like voicemail systems to be able to > detect/process. So what really confuses me is I thought one of the basic > applications 4244bis was trying to enable was exactly that one. Right? If > it's not sufficient to achieve that, I think we've screwed up somewhere... > or at least need to make sure it's not something we can fix in 4244bis, > because now would be a really good time to fix it. :) > > > > At IETF 75, when we were discussing the applicability of 4244bis to the > > SIPCORE charter (as opposed to simply developing a new document that was > > limited to describing how to use 4244 to deliver URI parameters), one of > > the rather important points that was made was that we would "limit bis > > changes to [those necessary to] satisfy target uri requirements." > > > > If the RAI community at large wants to expand this to include a general > > tune-up and/or kitchen-sinking of 4244, then we need to figure out a way > > to put the SIPCORE milestone to rest and then send the rest of the > > changes to DISPATCH. I have no interest in letting this milestone drag > > on as people come up with new things they'd like to see added or changed. > > > > /a > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --0015174c0e046bbca604956a0a65 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Response inline below [MB].

Mary.

On Thu, Nov 11, 2010 at 9:32 PM, Hadriel Kaplan <HKaplan@acmepacket.com= > wrote:

I'd like a clarification.
You said:
> "limit bis
> changes to [those necessary to] satisfy target uri requirements."=


If by that you mean literally just to enable GRUU delivery, we've= already exceeded that. =A0You don't need an "mp" tag for tha= t, for example, afaict.

But I'm also not sure it's fair to be that restrictive in your inte= rpretation of what the bis can change. =A0Obviously we have to constrain th= e scope, to actually get anywhere.
But there's no point in publishing a document if it doesn't solve a= problem people actually have, just for the sake of publishing a document.<= br>
[soapbox]
An RFC is not an end goal in itself - it's a means to an end, namely fo= r enabling interoperable protocols people will *actually use*.
[/soapbox]
(I know we all agree on this, I'm just venting)

BTW, I'm not sure Marianne's use-case requires *ANY* normative chan= ges to rfc4244bis. =A0I was just commenting that it would have been nice to= really understand if rfc4244bis did not cover it. =A0This is similar to Cu= llen's concern about use-cases/application-examples. =A0We need to make= sure the changes we're making are actually useful. (I think they *are*= , or are as close as we can get, but that doesn't mean we shouldn't= go through the exercise... using H-I just isn't that simple/obvious)

[MB] Correct, I also do not believe that M= arianne's use cases require normative changes to RFC 4244bis, which is = really agnostic in terms of the Reason header value. =A0I can certainly see= that History-Info header provides necessary functionality for the use case= , however, the use cases also require extensions to Reason header values th= at are normative. =A0For this same reason, we are removing the sub-addressi= ng use case since it requires new functionality beyond what is provided by = 4244bis. =A0[/MB]

-hadriel

On Nov 11, 2010, at 9:53 PM, Adam Roach wrote:

> [as chair]
>
> On 11/12/10 10:06 AM, Hadriel Kaplan wrote:
>> When I read Marianne's draft, it sounds like the use-case she&= #39;s trying to cover is call-forwarding, for things like voicemail systems= to be able to detect/process. =A0So what really confuses me is I thought o= ne of the basic applications 4244bis was trying to enable was exactly that = one. =A0Right? =A0If it's not sufficient to achieve that, I think we= 9;ve screwed up somewhere... or at least need to make sure it's not som= ething we can fix in 4244bis, because now would be a really good time to fi= x it. =A0:)
>
> At IETF 75, when we were discussing the applicability of 4244bis to th= e
> SIPCORE charter (as opposed to simply developing a new document that w= as
> limited to describing how to use 4244 to deliver URI parameters), one = of
> the rather important points that was made was that we would "limi= t bis
> changes to [those necessary to] satisfy target uri requirements."=
>
> If the RAI community at large wants to expand this to include a genera= l
> tune-up and/or kitchen-sinking of 4244, then we need to figure out a w= ay
> to put the SIPCORE milestone to rest and then send the rest of the
> changes to DISPATCH. I have no interest in letting this milestone drag=
> on as people come up with new things they'd like to see added or c= hanged.
>
> /a

_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--0015174c0e046bbca604956a0a65-- From dworley@avaya.com Fri Nov 19 08:45:39 2010 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 0E3073A684F for ; Fri, 19 Nov 2010 08:45:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.469 X-Spam-Level: X-Spam-Status: No, score=-102.469 tagged_above=-999 required=5 tests=[AWL=0.130, BAYES_00=-2.599, 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 QtmBWnLwJ9SP for ; Fri, 19 Nov 2010 08:45:38 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (nj300815-nj-outbound.net.avaya.com [135.11.29.16]) by core3.amsl.com (Postfix) with ESMTP id 264DD3A67F2 for ; Fri, 19 Nov 2010 08:45:38 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHo45kyHCzI1/2dsb2JhbACiYXGkFQKZM4VLBIRaiSk X-IronPort-AV: E=Sophos;i="4.59,224,1288584000"; d="scan'208";a="46340221" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by p-us1-iereast-outbound-tmp.us1.avaya.com with ESMTP; 19 Nov 2010 11:46:27 -0500 X-IronPort-AV: E=Sophos;i="4.59,224,1288584000"; d="scan'208";a="541491481" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 19 Nov 2010 11:45:57 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 19 Nov 2010 11:45:56 -0500 From: "Worley, Dale R (Dale)" To: Hadriel Kaplan , "sipcore@ietf.org WG" Date: Fri, 19 Nov 2010 11:42:57 -0500 Thread-Topic: Why doesn't 4244bis cover Marianne's use-case? Thread-Index: AcuCDjF+SApIdspJSNqP2SboPfuUGAF+qBD9 Message-ID: References: <2F27AF47-BD50-45FC-A832-DD845EEAA8FA@acmepacket.com> In-Reply-To: <2F27AF47-BD50-45FC-A832-DD845EEAA8FA@acmepacket.com> 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 Subject: Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case? 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: Fri, 19 Nov 2010 16:45:39 -0000 ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Hadr= iel Kaplan [HKaplan@acmepacket.com] It was unfortunate that we ran out of time in sipcore to talk about Mariann= e's draft, because I think it's a kind of litmus test of rfc4244bis. Or el= se I think I must be missing something very basic. (easily the case) _______________________________________________ As others have said in other terms, draft-mohali-diversion-history-info is= orthogonal to 4244bis. draft-mohali provides additional Reason values tha= t provide more detailed information on why a call was routed as it was. Th= ose Reason values will be recorded in H-I according to 4244bis. In a sense= , draft-mohali *is* a litmus test of 4244bis, because without H-I, the valu= e of the new Reason values would be dramatically reduced. But since the tw= o are orthogonal, draft-mohali needs to be specified, but it can be specifi= ed separately. Dale From pkyzivat@cisco.com Fri Nov 19 10:15:47 2010 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 775623A6876 for ; Fri, 19 Nov 2010 10:15:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.454 X-Spam-Level: X-Spam-Status: No, score=-110.454 tagged_above=-999 required=5 tests=[AWL=0.145, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 sOr7gFGLcwk0 for ; Fri, 19 Nov 2010 10:15:46 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 69D1B3A6850 for ; Fri, 19 Nov 2010 10:15:46 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Au4FAK9N5kxAZnwM/2dsb2JhbACUX44CcaImmz+FSwSEWoYBgw4 X-IronPort-AV: E=Sophos;i="4.59,224,1288569600"; d="scan'208";a="184134376" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 19 Nov 2010 18:16:36 +0000 Received: from [161.44.174.105] (dhcp-161-44-174-105.cisco.com [161.44.174.105]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAJIGaZW008941 for ; Fri, 19 Nov 2010 18:16:36 GMT Message-ID: <4CE6BF03.1030307@cisco.com> Date: Fri, 19 Nov 2010 13:16:35 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: sipcore@ietf.org References: <2F27AF47-BD50-45FC-A832-DD845EEAA8FA@acmepacket.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case? 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: Fri, 19 Nov 2010 18:15:47 -0000 I'm inclined to agree that this draft (draft-mohali-sipcore-reason-extension-application, not draft-mohali-diversion-history-info) *ought* to be orthogonal to 4244bis, and "just work" with it. BUT, in reality I'm not convinced that this is so. The following is from 4244bis: For retargets that are the result of an explicit SIP response, a Reason MUST be associated with the hi-targeted-to-uri. If the SIP response does not include a Reason header (see [RFC3326]), the SIP Response Code that triggered the retargeting MUST be included as the Reason associated with the hi-targeted-to-uri that has been retargeted. If the response contains a Reason header for a protocol that is not SIP (e.g., Q.850), it MUST be captured as an additional Reason associated with the hi-targeted-to-uri that has been retargeted, along with the SIP Response Code. If the Reason header is a SIP reason, then it MUST be used as the Reason associated with the hi-targeted-to-uri rather than the SIP response code. Note that the above is limited to "retargets that are the result of an explicit SIP response". But when I look at the call flows in the draft, none of the retargets are the result of a sip response. Rather, they are spontaneous retargets due to server logic. 4244bis does not cover using the Reason header in H-I entries for this purpose. Thanks, Paul On 11/19/2010 11:42 AM, Worley, Dale R (Dale) wrote: > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Hadriel Kaplan [HKaplan@acmepacket.com] > > It was unfortunate that we ran out of time in sipcore to talk about Marianne's draft, because I think it's a kind of litmus test of rfc4244bis. Or else I think I must be missing something very basic. (easily the case) > _______________________________________________ > > As others have said in other terms, draft-mohali-diversion-history-info is orthogonal to 4244bis. draft-mohali provides additional Reason values that provide more detailed information on why a call was routed as it was. Those Reason values will be recorded in H-I according to 4244bis. In a sense, draft-mohali *is* a litmus test of 4244bis, because without H-I, the value of the new Reason values would be dramatically reduced. But since the two are orthogonal, draft-mohali needs to be specified, but it can be specified separately. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From mary.ietf.barnes@gmail.com Fri Nov 19 10:40:01 2010 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 7FA2B28C0F8 for ; Fri, 19 Nov 2010 10:40:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.563 X-Spam-Level: X-Spam-Status: No, score=-102.563 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 PeJjgyGSJbWT for ; Fri, 19 Nov 2010 10:39:56 -0800 (PST) Received: from mail-gx0-f172.google.com (mail-gx0-f172.google.com [209.85.161.172]) by core3.amsl.com (Postfix) with ESMTP id 8AB6A28C101 for ; Fri, 19 Nov 2010 10:39:55 -0800 (PST) Received: by gxk27 with SMTP id 27so3134317gxk.31 for ; Fri, 19 Nov 2010 10:40:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=BHHSeGUdAIXXYuWaJsQEbthGJCnN+UwGQqMljrvD648=; b=LundKWN5r1JGi0ZELwogMa4gcRPA3uhELvbCl9kMB6YiEzezD4jKyig9LCNPs1dFAx bnqxrarkJuA3HuERPVoe2ujzjOnSKJtITd92+sNRonitpekcInxC7ObMRaPR6Cr2EA6g WzTERS7dWBhf316lDWrynHWkpSyRj8iF7Esto= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=CQjw6uYnQzAZsQLtPFH2xT1tE25Jal+V9T9Il4QGlN2mujqzXtZj1VJctKsIZ4jcou OwAwRRNL6v8B5nF7YQ6gAG+jbsGsKepi+Ps4nMBL504f6G9x86eEUW16VbwCDiQXt0tD +kx+2BxAtY383WiJ4fkXeIyip3xX84Z3b3ZrQ= MIME-Version: 1.0 Received: by 10.151.51.15 with SMTP id d15mr4224539ybk.33.1290192044713; Fri, 19 Nov 2010 10:40:44 -0800 (PST) Received: by 10.236.95.35 with HTTP; Fri, 19 Nov 2010 10:40:44 -0800 (PST) In-Reply-To: <4CE6BF03.1030307@cisco.com> References: <2F27AF47-BD50-45FC-A832-DD845EEAA8FA@acmepacket.com> <4CE6BF03.1030307@cisco.com> Date: Fri, 19 Nov 2010 12:40:44 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=0015174c0e0484688604956c3e03 Cc: sipcore@ietf.org Subject: Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case? 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: Fri, 19 Nov 2010 18:40:01 -0000 --0015174c0e0484688604956c3e03 Content-Type: text/plain; charset=ISO-8859-1 I don't disagree that strictly speaking adding the response codes based on applications is beyond what is currently specified in 4244bis. We could add text change the text to something like the following (and I'm thinking either way that text should be updated since this is much more concise): If the response contains any Reason header fields, then the Reason header fields MUST be captured as Reasons associated with the hi-targeted-to-uri that has been retargeted. If the SIP response does not include a Reason header field (see [RFC3326]), the SIP Response Code that triggered the retargeting MUST be included as the Reason associated with the hi-targeted-to-uri that has been retargeted. And, that would allow for any future extensions to the Reason header to be plopped into an hi-entry. If the Reason header were mandatory, then it would be easy in that HI just uses whatever value for the Reason header(s) that are there. However, without having the new values defined for the Reason header we can't reference them and I would rather not hold up 4244bis, just so that we can have explicit text. Per the suggested text above, I think it's better anyways that we aren't referencing the specific Reason header field values, but rather just capture what's there. Regards, Mary. On Fri, Nov 19, 2010 at 12:16 PM, Paul Kyzivat wrote: > I'm inclined to agree that this draft > (draft-mohali-sipcore-reason-extension-application, not > draft-mohali-diversion-history-info) *ought* to be orthogonal to 4244bis, > and "just work" with it. > > BUT, in reality I'm not convinced that this is so. The following is from > 4244bis: > > For retargets that are the result of an explicit SIP response, a > Reason MUST be associated with the hi-targeted-to-uri. If the SIP > response does not include a Reason header (see [RFC3326]), the SIP > Response Code that triggered the retargeting MUST be included as the > Reason associated with the hi-targeted-to-uri that has been > retargeted. If the response contains a Reason header for a protocol > that is not SIP (e.g., Q.850), it MUST be captured as an additional > Reason associated with the hi-targeted-to-uri that has been > retargeted, along with the SIP Response Code. If the Reason header > is a SIP reason, then it MUST be used as the Reason associated with > the hi-targeted-to-uri rather than the SIP response code. > > Note that the above is limited to "retargets that are the result of an > explicit SIP response". But when I look at the call flows in the draft, none > of the retargets are the result of a sip response. Rather, they are > spontaneous retargets due to server logic. 4244bis does not cover using the > Reason header in H-I entries for this purpose. > > Thanks, > Paul > > > On 11/19/2010 11:42 AM, Worley, Dale R (Dale) wrote: > >> ________________________________________ >> From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of >> Hadriel Kaplan [HKaplan@acmepacket.com] >> >> It was unfortunate that we ran out of time in sipcore to talk about >> Marianne's draft, because I think it's a kind of litmus test of rfc4244bis. >> Or else I think I must be missing something very basic. (easily the case) >> _______________________________________________ >> >> As others have said in other terms, draft-mohali-diversion-history-info >> is orthogonal to 4244bis. draft-mohali provides additional Reason values >> that provide more detailed information on why a call was routed as it was. >> Those Reason values will be recorded in H-I according to 4244bis. In a >> sense, draft-mohali *is* a litmus test of 4244bis, because without H-I, the >> value of the new Reason values would be dramatically reduced. But since the >> two are orthogonal, draft-mohali needs to be specified, but it can be >> specified separately. >> >> Dale >> _______________________________________________ >> 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 > --0015174c0e0484688604956c3e03 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I don't disagree that strictly speaking adding the response codes based= on applications is beyond what is currently specified in 4244bis. =A0 We c= ould add text change the text to something like the following (and I'm = thinking either way that text should be updated since this is much more con= cise):

=A0=A0If the response contains any Reason header fields, then=A0
=A0=A0the Reason header fields MUST be captured as Reasons=A0
=A0=A0associated with the hi-targeted-to-uri that has been
=A0 r= etargeted. =A0If the SIP
=A0 response does not include a Reason header field (see [RFC3326]), the SI= P
=A0 Response Code that triggered the retargeting MUST be included as t= he
=A0 Reason associated with the hi-targeted-to-uri that has been
= =A0 retargeted. =A0

And, that would allow for any future extensions to the = Reason header to be plopped into an hi-entry. =A0 If the Reason header were= mandatory, then it would be easy in that HI just uses whatever value for t= he Reason header(s) =A0that are there. =A0

However, without having the new values defined for the = Reason header we can't reference them and I would rather not hold up 42= 44bis, just so that we can have explicit text. Per the suggested text above= , I think it's better anyways that we aren't referencing the specif= ic Reason header field values, but rather just capture what's there.=A0=

Regards,
Mary.=A0

On Fri, Nov 19, 2010 at 12:16 PM, Paul Kyzivat <= ;pkyzivat@cisco.com> wr= ote:
I'm inclined to agree that this draft (= draft-mohali-sipcore-reason-extension-application, not draft-mohali-diversi= on-history-info) *ought* to be orthogonal to 4244bis, and "just work&q= uot; with it.

BUT, in reality I'm not convinced that this is so. The following is fro= m 4244bis:

=A0 For retargets that are the result of an explicit SIP response, a
=A0 Reason MUST be associated with the hi-targeted-to-uri. =A0If the SIP =A0 response does not include a Reason header (see [RFC3326]), the SIP
=A0 Response Code that triggered the retargeting MUST be included as the =A0 Reason associated with the hi-targeted-to-uri that has been
=A0 retargeted. =A0If the response contains a Reason header for a protocol=
=A0 that is not SIP (e.g., Q.850), it MUST be captured as an additional =A0 Reason associated with the hi-targeted-to-uri that has been
=A0 retargeted, along with the SIP Response Code. =A0If the Reason header<= br> =A0 is a SIP reason, then it MUST be used as the Reason associated with =A0 the hi-targeted-to-uri rather than the SIP response code.

Note that the above is limited to "retargets that are the result of an= explicit SIP response". But when I look at the call flows in the draf= t, none of the retargets are the result of a sip response. Rather, they are= spontaneous retargets due to server logic. 4244bis does not cover using th= e Reason header in H-I entries for this purpose.

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul


On 11/19/2010 11:42 AM, Worley, Dale R (Dale) wrote:
________________________________________
From: sipcore= -bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Hadriel Kaplan [HKaplan@acmepacket.= com]

It was unfortunate that we ran out of time in sipcore to talk about Mariann= e's draft, because I think it's a kind of litmus test of rfc4244bis= . =A0Or else I think I must be missing something very basic. (easily the ca= se)
_______________________________________________

As others have said in other terms, =A0draft-mohali-diversion-history-info = is orthogonal to 4244bis. =A0draft-mohali provides additional Reason values= that provide more detailed information on why a call was routed as it was.= =A0Those Reason values will be recorded in H-I according to 4244bis. =A0In= a sense, draft-mohali *is* a litmus test of 4244bis, because without H-I, = the value of the new Reason values would be dramatically reduced. =A0But si= nce the two are orthogonal, draft-mohali needs to be specified, but it can = be specified separately.

Dale
_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

_______________________________________________
sipcore mailing list
sipcore@ietf.org<= br> https://www.ietf.org/mailman/listinfo/sipcore

--0015174c0e0484688604956c3e03-- From pkyzivat@cisco.com Fri Nov 19 11:13:06 2010 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 DFA0D3A6876 for ; Fri, 19 Nov 2010 11:13:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.476 X-Spam-Level: X-Spam-Status: No, score=-110.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 jiqiudxo3FpA for ; Fri, 19 Nov 2010 11:13:05 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 879D13A67FF for ; Fri, 19 Nov 2010 11:13:05 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJZa5kxAZnwM/2dsb2JhbACiYXGiIZs7hUsEhFqGAYMO X-IronPort-AV: E=Sophos;i="4.59,224,1288569600"; d="scan'208";a="184151322" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 19 Nov 2010 19:13:50 +0000 Received: from [161.44.174.105] (dhcp-161-44-174-105.cisco.com [161.44.174.105]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAJJDnCT024247; Fri, 19 Nov 2010 19:13:49 GMT Message-ID: <4CE6CC6D.30103@cisco.com> Date: Fri, 19 Nov 2010 14:13:49 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Mary Barnes References: <2F27AF47-BD50-45FC-A832-DD845EEAA8FA@acmepacket.com> <4CE6BF03.1030307@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case? 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: Fri, 19 Nov 2010 19:13:07 -0000 On 11/19/2010 1:40 PM, Mary Barnes wrote: > I don't disagree that strictly speaking adding the response codes based > on applications is beyond what is currently specified in 4244bis. We > could add text change the text to something like the following (and I'm > thinking either way that text should be updated since this is much more > concise): > > If the response contains any Reason header fields, then > the Reason header fields MUST be captured as Reasons > associated with the hi-targeted-to-uri that has been > retargeted. If the SIP > response does not include a Reason header field (see [RFC3326]), the SIP > Response Code that triggered the retargeting MUST be included as the > Reason associated with the hi-targeted-to-uri that has been > retargeted. (I know I'm being legalistic here, but sometimes its necessary.) The above still only covers cases where the retargeting is the result of a response, which doesn't cover Marianne's case. There are several ways to deal with this: - leave as it is. Marianne's cases won't be covered. But she can rewrite her draft to show a proxy forwarding to an app server that returns a 3xx with reason code. (But not so useful if that is not the actual intended use.) - assume that Marianne's cases are morally equivalent to forwarding to a "virtual server" that behaves as above, and so the H-I can be updated as if that were the case. (But the H-I entries aren't the same, because there are none for the visit to the "virtual server". - reword 4244bis so that a Reason header MAY be included (with suitable conditions - TBD) even if not received in a response, to cover Marianne's cases. (But this takes 4244bis beyond the scope it was intended to cover.) - leave 4244bis alone, but change draft-mohali-sipcore-reason-extension- application to be a revision to 4244bis. (Avoids the scope issue, but results in two back-to-back revisions to the same document. Developers will not be pleased with that.) What do you think? Thanks, Paul > And, that would allow for any future extensions to the Reason header to > be plopped into an hi-entry. If the Reason header were mandatory, then > it would be easy in that HI just uses whatever value for the Reason > header(s) that are there. > > However, without having the new values defined for the Reason header we > can't reference them and I would rather not hold up 4244bis, just so > that we can have explicit text. Per the suggested text above, I think > it's better anyways that we aren't referencing the specific Reason > header field values, but rather just capture what's there. > > Regards, > Mary. > > On Fri, Nov 19, 2010 at 12:16 PM, Paul Kyzivat > wrote: > > I'm inclined to agree that this draft > (draft-mohali-sipcore-reason-extension-application, not > draft-mohali-diversion-history-info) *ought* to be orthogonal to > 4244bis, and "just work" with it. > > BUT, in reality I'm not convinced that this is so. The following is > from 4244bis: > > For retargets that are the result of an explicit SIP response, a > Reason MUST be associated with the hi-targeted-to-uri. If the SIP > response does not include a Reason header (see [RFC3326]), the SIP > Response Code that triggered the retargeting MUST be included as the > Reason associated with the hi-targeted-to-uri that has been > retargeted. If the response contains a Reason header for a protocol > that is not SIP (e.g., Q.850), it MUST be captured as an additional > Reason associated with the hi-targeted-to-uri that has been > retargeted, along with the SIP Response Code. If the Reason header > is a SIP reason, then it MUST be used as the Reason associated with > the hi-targeted-to-uri rather than the SIP response code. > > Note that the above is limited to "retargets that are the result of > an explicit SIP response". But when I look at the call flows in the > draft, none of the retargets are the result of a sip response. > Rather, they are spontaneous retargets due to server logic. 4244bis > does not cover using the Reason header in H-I entries for this purpose. > > Thanks, > Paul > > > On 11/19/2010 11:42 AM, Worley, Dale R (Dale) wrote: > > ________________________________________ > From: sipcore-bounces@ietf.org > [sipcore-bounces@ietf.org ] On > Behalf Of Hadriel Kaplan [HKaplan@acmepacket.com > ] > > It was unfortunate that we ran out of time in sipcore to talk > about Marianne's draft, because I think it's a kind of litmus > test of rfc4244bis. Or else I think I must be missing something > very basic. (easily the case) > _______________________________________________ > > As others have said in other terms, > draft-mohali-diversion-history-info is orthogonal to 4244bis. > draft-mohali provides additional Reason values that provide > more detailed information on why a call was routed as it was. > Those Reason values will be recorded in H-I according to > 4244bis. In a sense, draft-mohali *is* a litmus test of > 4244bis, because without H-I, the value of the new Reason values > would be dramatically reduced. But since the two are > orthogonal, draft-mohali needs to be specified, but it can be > specified separately. > > Dale > _______________________________________________ > 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 > > From mary.ietf.barnes@gmail.com Fri Nov 19 12:11:44 2010 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 CB2DD28C126 for ; Fri, 19 Nov 2010 12:11:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.565 X-Spam-Level: X-Spam-Status: No, score=-102.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 HArcAHggCX2c for ; Fri, 19 Nov 2010 12:11:31 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 78C2C28C135 for ; Fri, 19 Nov 2010 12:11:28 -0800 (PST) Received: by iwn40 with SMTP id 40so5462225iwn.31 for ; Fri, 19 Nov 2010 12:12:18 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=ruAEhaYduM57b/+aVTQcA7nzYkDL74HM5gk7Q6xy5tg=; b=xSlxjloltRSt7jX7WkqQ5f1e9s2Ky+1TQpmlcoVWVKbo/10Ckt0teqzI/jWFQT+YP3 ZRrkPHNjHxcJHEg3ir/cE3u/tdFcQ+G/RCzd0KZj/7DLUXg1cMkc+MB6s5I/T2TClIQ/ h3yZhiGEF5rF6LaA4mQajw4KqhXkZdnjYZQPY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=U3mn7xXIxJ+fCnj1knApnfJvDDIAK1dCPXdJqVF7Xy/a/aG7sBufGaNv7cvp6mDsOK eiQ63BRJ1z5ZASn66CERhOm+RFLT4Qv+D58cBtNFaTPrHEqQgx1+lwF/ZwCmpyeaVQBL mixOj5bsbWzr1iqpAaL2k+K8wfJ2Ec6NTIKH8= MIME-Version: 1.0 Received: by 10.231.34.8 with SMTP id j8mr2503454ibd.121.1290197538654; Fri, 19 Nov 2010 12:12:18 -0800 (PST) Received: by 10.42.167.9 with HTTP; Fri, 19 Nov 2010 12:12:18 -0800 (PST) In-Reply-To: <4CE6CC6D.30103@cisco.com> References: <2F27AF47-BD50-45FC-A832-DD845EEAA8FA@acmepacket.com> <4CE6BF03.1030307@cisco.com> <4CE6CC6D.30103@cisco.com> Date: Fri, 19 Nov 2010 14:12:18 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=002215048a1bfb4a3404956d851c Cc: sipcore@ietf.org Subject: Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case? 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: Fri, 19 Nov 2010 20:11:44 -0000 --002215048a1bfb4a3404956d851c Content-Type: text/plain; charset=ISO-8859-1 My intent was that if the response to the request (based both on external and internal retargeting) contains any Reason header field values, then those are all included in the Reason header field value included in the hi-entry. So, I was presupposing that even in the case of internal retargeting the reason could be captured - including these new application specific ones - i.e., the "values" for the Reason header field are set independent (and prior) to its addition to the History-Info. So, what I had in mind is essentially your 2nd option below. I really, really do not want to bog down 4244bis to make this addition of application reasons explicit. Anytime we've gotten into any application specific discussions or proposals, it is very difficult to reach consensus and move work forward. And, the definition of these application specific reasons is significant in that it requires agreement on the values since it's not just reusing values already defined in other specifications as are the current Reason header field types and values. I don't see this as something that will happen very quickly (unfortunately), in particular given that the semantics of the applications noted are not yet defined (or if there is a definitive reference from another SDO), it needs to be included. Regards, Mary. On Fri, Nov 19, 2010 at 1:13 PM, Paul Kyzivat wrote: > > > On 11/19/2010 1:40 PM, Mary Barnes wrote: > >> I don't disagree that strictly speaking adding the response codes based >> on applications is beyond what is currently specified in 4244bis. We >> could add text change the text to something like the following (and I'm >> thinking either way that text should be updated since this is much more >> concise): >> >> If the response contains any Reason header fields, then >> the Reason header fields MUST be captured as Reasons >> associated with the hi-targeted-to-uri that has been >> retargeted. If the SIP >> response does not include a Reason header field (see [RFC3326]), the SIP >> Response Code that triggered the retargeting MUST be included as the >> Reason associated with the hi-targeted-to-uri that has been >> retargeted. >> > > (I know I'm being legalistic here, but sometimes its necessary.) > > The above still only covers cases where the retargeting is the result of a > response, which doesn't cover Marianne's case. There are several ways to > deal with this: > > - leave as it is. Marianne's cases won't be covered. But she can > rewrite her draft to show a proxy forwarding to an app server > that returns a 3xx with reason code. (But not so useful if that is > not the actual intended use.) > > - assume that Marianne's cases are morally equivalent to > forwarding to a "virtual server" that behaves as above, and so > the H-I can be updated as if that were the case. (But the H-I > entries aren't the same, because there are none for the visit to > the "virtual server". > > - reword 4244bis so that a Reason header MAY be included (with suitable > conditions - TBD) even if not received in a response, to cover > Marianne's cases. (But this takes 4244bis beyond the scope it was > intended to cover.) > > - leave 4244bis alone, but change draft-mohali-sipcore-reason-extension- > application to be a revision to 4244bis. (Avoids the scope issue, > but results in two back-to-back revisions to the same document. > Developers will not be pleased with that.) > > What do you think? > > Thanks, > Paul > > And, that would allow for any future extensions to the Reason header to >> be plopped into an hi-entry. If the Reason header were mandatory, then >> it would be easy in that HI just uses whatever value for the Reason >> header(s) that are there. >> >> However, without having the new values defined for the Reason header we >> can't reference them and I would rather not hold up 4244bis, just so >> that we can have explicit text. Per the suggested text above, I think >> it's better anyways that we aren't referencing the specific Reason >> header field values, but rather just capture what's there. >> >> Regards, >> Mary. >> >> On Fri, Nov 19, 2010 at 12:16 PM, Paul Kyzivat > > wrote: >> >> I'm inclined to agree that this draft >> (draft-mohali-sipcore-reason-extension-application, not >> draft-mohali-diversion-history-info) *ought* to be orthogonal to >> 4244bis, and "just work" with it. >> >> BUT, in reality I'm not convinced that this is so. The following is >> from 4244bis: >> >> For retargets that are the result of an explicit SIP response, a >> Reason MUST be associated with the hi-targeted-to-uri. If the SIP >> response does not include a Reason header (see [RFC3326]), the SIP >> Response Code that triggered the retargeting MUST be included as the >> Reason associated with the hi-targeted-to-uri that has been >> retargeted. If the response contains a Reason header for a protocol >> that is not SIP (e.g., Q.850), it MUST be captured as an additional >> Reason associated with the hi-targeted-to-uri that has been >> retargeted, along with the SIP Response Code. If the Reason header >> is a SIP reason, then it MUST be used as the Reason associated with >> the hi-targeted-to-uri rather than the SIP response code. >> >> Note that the above is limited to "retargets that are the result of >> an explicit SIP response". But when I look at the call flows in the >> draft, none of the retargets are the result of a sip response. >> Rather, they are spontaneous retargets due to server logic. 4244bis >> does not cover using the Reason header in H-I entries for this purpose. >> >> Thanks, >> Paul >> >> >> On 11/19/2010 11:42 AM, Worley, Dale R (Dale) wrote: >> >> ________________________________________ >> From: sipcore-bounces@ietf.org >> [sipcore-bounces@ietf.org ] On >> >> Behalf Of Hadriel Kaplan [HKaplan@acmepacket.com >> ] >> >> >> It was unfortunate that we ran out of time in sipcore to talk >> about Marianne's draft, because I think it's a kind of litmus >> test of rfc4244bis. Or else I think I must be missing something >> very basic. (easily the case) >> _______________________________________________ >> >> As others have said in other terms, >> draft-mohali-diversion-history-info is orthogonal to 4244bis. >> draft-mohali provides additional Reason values that provide >> more detailed information on why a call was routed as it was. >> Those Reason values will be recorded in H-I according to >> 4244bis. In a sense, draft-mohali *is* a litmus test of >> 4244bis, because without H-I, the value of the new Reason values >> would be dramatically reduced. But since the two are >> orthogonal, draft-mohali needs to be specified, but it can be >> specified separately. >> >> Dale >> _______________________________________________ >> 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 >> >> >> --002215048a1bfb4a3404956d851c Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable My intent was that if the response to the request (based both on external a= nd internal retargeting) contains any Reason header field values, then thos= e are all included in the Reason header field value included in the hi-entr= y. =A0So, I was presupposing that even in the case of internal retargeting = the reason could be captured - including these new application specific one= s - i.e., the "values" for the Reason header field are set indepe= ndent (and prior) to its addition to the History-Info. =A0So, what I had in= mind is essentially your 2nd option below.=A0

I really, really do not want to bog down 4244bis to make thi= s addition of application reasons explicit. =A0Anytime we've gotten int= o any application specific discussions or proposals, it is very difficult t= o reach consensus and move work forward. =A0And, the definition of these ap= plication specific reasons is significant in that it requires agreement on = the values since it's not just reusing values already defined in other = specifications as are the current Reason header field types and values. =A0= I don't see this as something that will happen very quickly (unfortunat= ely), in particular given that the semantics of =A0the applications noted a= re not yet defined (or if there is a definitive reference from another SDO)= , it needs to be included.=A0

Regards,
Mary.=A0

On Fri, Nov 19, 2010 at 1:13 PM, Paul Kyzivat <pky= zivat@cisco.com> wrote:


On 11/19/2010 1:40 PM, Mary Barnes wrote:
I don't disagree that strictly speaking adding the response codes based=
on applications is beyond what is currently specified in 4244bis. =A0 We could add text change the text to something like the following (and I'm=
thinking either way that text should be updated since this is much more
concise):

=A0 If the response contains any Reason header fields, then
=A0 the Reason header fields MUST be captured as Reasons
=A0 associated with the hi-targeted-to-uri that has been
=A0 retargeted. =A0If the SIP
=A0 response does not include a Reason header field (see [RFC3326]), the S= IP
=A0 Response Code that triggered the retargeting MUST be included as the =A0 Reason associated with the hi-targeted-to-uri that has been
=A0 retargeted.

(I know I'm being legalistic here, but sometimes its necessary.)

The above still only covers cases where the retargeting is the result of a = response, which doesn't cover Marianne's case. There are several wa= ys to deal with this:

- leave as it is. Marianne's cases won't be covered. But she can =A0rewrite her draft to show a proxy forwarding to an app server
=A0that returns a 3xx with reason code. (But not so useful if that is
=A0not the actual intended use.)

- assume that Marianne's cases are morally equivalent to
=A0forwarding to a "virtual server" that behaves as above, and s= o
=A0the H-I can be updated as if that were the case. (But the H-I
=A0entries aren't the same, because there are none for the visit to =A0the "virtual server".

- reword 4244bis so that a Reason header MAY be included (with suitable
=A0conditions - TBD) even if not received in a response, to cover
=A0Marianne's cases. (But this takes 4244bis beyond the scope it was =A0intended to cover.)

- leave 4244bis alone, but change draft-mohali-sipcore-reason-extension- =A0application to be a revision to 4244bis. (Avoids the scope issue,
=A0but results in two back-to-back revisions to the same document.
=A0Developers will not be pleased with that.)

What do you think?

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul

And, that would allow for any future extensions to the Reason header to
be plopped into an hi-entry. =A0 If the Reason header were mandatory, then<= br> it would be easy in that HI just uses whatever value for the Reason
header(s) =A0that are there.

However, without having the new values defined for the Reason header we
can't reference them and I would rather not hold up 4244bis, just so that we can have explicit text. Per the suggested text above, I think
it's better anyways that we aren't referencing the specific Reason<= br> header field values, but rather just capture what's there.

Regards,
Mary.

On Fri, Nov 19, 2010 at 12:16 PM, Paul Kyzivat <pkyzivat@cisco.com
<= /div>
<mailto:pkyzivat= @cisco.com>> wrote:

=A0 =A0I'm inclined to agree that this draft
=A0 =A0(draft-mohali-sipcore-reason-extension-application, not
=A0 =A0draft-mohali-diversion-history-info) *ought* to be orthogonal to =A0 =A04244bis, and "just work" with it.

=A0 =A0BUT, in reality I'm not convinced that this is so. The followin= g is
=A0 =A0from 4244bis:

=A0 =A0 =A0 For retargets that are the result of an explicit SIP response,= a
=A0 =A0 =A0 Reason MUST be associated with the hi-targeted-to-uri. =A0If t= he SIP
=A0 =A0 =A0 response does not include a Reason header (see [RFC3326]), the= SIP
=A0 =A0 =A0 Response Code that triggered the retargeting MUST be included = as the
=A0 =A0 =A0 Reason associated with the hi-targeted-to-uri that has been =A0 =A0 =A0 retargeted. =A0If the response contains a Reason header for a = protocol
=A0 =A0 =A0 that is not SIP (e.g., Q.850), it MUST be captured as an addit= ional
=A0 =A0 =A0 Reason associated with the hi-targeted-to-uri that has been =A0 =A0 =A0 retargeted, along with the SIP Response Code. =A0If the Reason= header
=A0 =A0 =A0 is a SIP reason, then it MUST be used as the Reason associated= with
=A0 =A0 =A0 the hi-targeted-to-uri rather than the SIP response code.

=A0 =A0Note that the above is limited to "retargets that are the resu= lt of
=A0 =A0an explicit SIP response". But when I look at the call flows i= n the
=A0 =A0draft, none of the retargets are the result of a sip response.
=A0 =A0Rather, they are spontaneous retargets due to server logic. 4244bis=
=A0 =A0does not cover using the Reason header in H-I entries for this purp= ose.

=A0 =A0 =A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0 =A0 =A0Paul


=A0 =A0On 11/19/2010 11:42 AM, Worley, Dale R (Dale) wrote:

=A0 =A0 =A0 =A0________________________________________
=A0 =A0 =A0 =A0From: sipcore-bounces@ietf.org <mailto:sipcore-bounces@ietf.org>
=A0 =A0 =A0 =A0[sipcore-bounces@ietf.org <mailto:sipcore-bounces@ietf.org>] On
=A0 =A0 =A0 =A0Behalf Of Hadriel Kaplan [HKaplan@acmepacket.com
=A0 =A0 =A0 =A0<mailto:HKaplan@acmepacket.com>]


=A0 =A0 =A0 =A0It was unfortunate that we ran out of time in sipcore to ta= lk
=A0 =A0 =A0 =A0about Marianne's draft, because I think it's a kind= of litmus
=A0 =A0 =A0 =A0test of rfc4244bis. =A0Or else I think I must be missing so= mething
=A0 =A0 =A0 =A0very basic. (easily the case)
=A0 =A0 =A0 =A0_______________________________________________

=A0 =A0 =A0 =A0As others have said in other terms,
=A0 =A0 =A0 =A0 =A0draft-mohali-diversion-history-info is orthogonal to 42= 44bis.
=A0 =A0 =A0 =A0 =A0draft-mohali provides additional Reason values that pro= vide
=A0 =A0 =A0 =A0more detailed information on why a call was routed as it wa= s.
=A0 =A0 =A0 =A0 =A0Those Reason values will be recorded in H-I according t= o
=A0 =A0 =A0 =A04244bis. =A0In a sense, draft-mohali *is* a litmus test of<= br> =A0 =A0 =A0 =A04244bis, because without H-I, the value of the new Reason v= alues
=A0 =A0 =A0 =A0would be dramatically reduced. =A0But since the two are
=A0 =A0 =A0 =A0orthogonal, draft-mohali needs to be specified, but it can = be
=A0 =A0 =A0 =A0specified separately.

=A0 =A0 =A0 =A0Dale
=A0 =A0 =A0 =A0_______________________________________________
=A0 =A0 =A0 =A0sipcore mailing list
=A0 =A0 =A0 =A0sipco= re@ietf.org <mailto:sipcore@ietf.org>

=A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/sipcore

=A0 =A0_______________________________________________
=A0 =A0sipcore mailing list
=A0 =A0sipcore@ietf.= org <mailto:si= pcore@ietf.org>
--002215048a1bfb4a3404956d851c-- From dworley@avaya.com Fri Nov 19 12:13:20 2010 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 C4C0F3A68D0 for ; Fri, 19 Nov 2010 12:13:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.476 X-Spam-Level: X-Spam-Status: No, score=-102.476 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, 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 RSBLiaOL9meP for ; Fri, 19 Nov 2010 12:13:20 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id C16623A689C for ; Fri, 19 Nov 2010 12:13:19 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAN5o5kzGmAcF/2dsb2JhbACiYXGkQgKZJYVLBIRaiSk X-IronPort-AV: E=Sophos;i="4.59,224,1288584000"; d="scan'208";a="219434483" Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by de307622-de-outbound.net.avaya.com with ESMTP; 19 Nov 2010 15:14:08 -0500 X-IronPort-AV: E=Sophos;i="4.59,225,1288584000"; d="scan'208";a="542835654" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by co300216-co-erhwest-out.avaya.com with ESMTP; 19 Nov 2010 15:14:08 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Fri, 19 Nov 2010 15:14:07 -0500 From: "Worley, Dale R (Dale)" To: Paul Kyzivat , Mary Barnes Date: Fri, 19 Nov 2010 15:11:20 -0500 Thread-Topic: [sipcore] Why doesn't 4244bis cover Marianne's use-case? Thread-Index: AcuIHew+0kS/7W8vTce6TZxPUZQ7IQACAIl4 Message-ID: References: <2F27AF47-BD50-45FC-A832-DD845EEAA8FA@acmepacket.com> <4CE6BF03.1030307@cisco.com> , <4CE6CC6D.30103@cisco.com> In-Reply-To: <4CE6CC6D.30103@cisco.com> 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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case? 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: Fri, 19 Nov 2010 20:13:20 -0000 ________________________________________ From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Paul= Kyzivat [pkyzivat@cisco.com] (I know I'm being legalistic here, but sometimes its necessary.) [...] - reword 4244bis so that a Reason header MAY be included (with suitable conditions - TBD) even if not received in a response, to cover Marianne's cases. (But this takes 4244bis beyond the scope it was intended to cover.) _______________________________________________ Certainly in this situation, we'd better be legalistic, because there are s= o many ways that it could turn into a mess. I prefer adding a suitable clause to 4244bis to allow the proxy to insert a= Reason header for a URI that is redirected, as this is the clean way to ha= ndle the situation. (The alternative is to synthesize an entry showing tha= t the request was sent to a virtual redirection server, but that would make= the H-I even longer.) This is another aspect of the problem of documentin= g what the rules are for a consistent H-I header. Dale From pkyzivat@cisco.com Fri Nov 19 12:46:30 2010 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 2CDC73A68D4 for ; Fri, 19 Nov 2010 12:46:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.485 X-Spam-Level: X-Spam-Status: No, score=-110.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 ejnsTp9BDViI for ; Fri, 19 Nov 2010 12:46:28 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 52DC13A6811 for ; Fri, 19 Nov 2010 12:46:28 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANdw5kxAZnwN/2dsb2JhbACiYXGiUZs4hUsEhFqGAYMO X-IronPort-AV: E=Sophos;i="4.59,225,1288569600"; d="scan'208";a="184184883" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 19 Nov 2010 20:47:15 +0000 Received: from [161.44.174.105] (dhcp-161-44-174-105.cisco.com [161.44.174.105]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oAJKlFH8003653; Fri, 19 Nov 2010 20:47:15 GMT Message-ID: <4CE6E252.5070701@cisco.com> Date: Fri, 19 Nov 2010 15:47:14 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Mary Barnes References: <2F27AF47-BD50-45FC-A832-DD845EEAA8FA@acmepacket.com> <4CE6BF03.1030307@cisco.com> <4CE6CC6D.30103@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case? 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: Fri, 19 Nov 2010 20:46:30 -0000 Mary, I don't think anyone is suggesting that 4244bis have anything to say about application-specific reason codes. The question is whether its permissible for a server to include a Reason in an H-I entry when that Reason was not received in an actual response. The trouble with arguing that the current language covers "internal" retargeting is that if we assume some sort of virtual server that returned a redirect and Reason, then that presumably ought to have its own H-I entry. I expect we all agree that having such an extra H-I entry is undesirable. So, the question is whether the current language is sufficient to allow a server to "fabricate" a Reason code and include it, or if we need some explicit language to allow that. There is a partial analogy here to sip servers that use multiple to-tags to pretend a request was forked, in order to provide alternative o/a outcomes. The validity of this is based on presumption of "internal forking". In general I think people have been ok with that without any explicit text permitting it. But of course in the absence of H-I there is really no way to know if the forking was virtual or real. Recently I've had someone question the legitimacy of this argument. Ideally it would be better if it were more strongly supported by text. I think the argument re Reason in H-I is a bit weaker because H-I is at the root of it, and explaining that there was (virtual) redirection without a corresponding H-I entry may be hard for some to swallow. (I guess we would have to argue that it was virtual redirection to a server that didn't support H-I and so didn't include the H-I entry. But then we would expect to see 3xx as a Reason in addition to whatever other Reason is included.) But I am still open to a convincing argument that the existing words allow this behavior. (The use of "cause=xxx" that I hear IMS includes is another story. Its going to take a much stronger argument to convince me that is permitted by 4244 or 4244bis.) Thanks, Paul On 11/19/2010 3:12 PM, Mary Barnes wrote: > My intent was that if the response to the request (based both on > external and internal retargeting) contains any Reason header field > values, then those are all included in the Reason header field value > included in the hi-entry. So, I was presupposing that even in the case > of internal retargeting the reason could be captured - including these > new application specific ones - i.e., the "values" for the Reason header > field are set independent (and prior) to its addition to the > History-Info. So, what I had in mind is essentially your 2nd option below. > > I really, really do not want to bog down 4244bis to make this addition > of application reasons explicit. Anytime we've gotten into any > application specific discussions or proposals, it is very difficult to > reach consensus and move work forward. And, the definition of these > application specific reasons is significant in that it requires > agreement on the values since it's not just reusing values already > defined in other specifications as are the current Reason header field > types and values. I don't see this as something that will happen very > quickly (unfortunately), in particular given that the semantics of the > applications noted are not yet defined (or if there is a definitive > reference from another SDO), it needs to be included. > > Regards, > Mary. > > On Fri, Nov 19, 2010 at 1:13 PM, Paul Kyzivat > wrote: > > > > On 11/19/2010 1:40 PM, Mary Barnes wrote: > > I don't disagree that strictly speaking adding the response > codes based > on applications is beyond what is currently specified in > 4244bis. We > could add text change the text to something like the following > (and I'm > thinking either way that text should be updated since this is > much more > concise): > > If the response contains any Reason header fields, then > the Reason header fields MUST be captured as Reasons > associated with the hi-targeted-to-uri that has been > retargeted. If the SIP > response does not include a Reason header field (see > [RFC3326]), the SIP > Response Code that triggered the retargeting MUST be included > as the > Reason associated with the hi-targeted-to-uri that has been > retargeted. > > > (I know I'm being legalistic here, but sometimes its necessary.) > > The above still only covers cases where the retargeting is the > result of a response, which doesn't cover Marianne's case. There are > several ways to deal with this: > > - leave as it is. Marianne's cases won't be covered. But she can > rewrite her draft to show a proxy forwarding to an app server > that returns a 3xx with reason code. (But not so useful if that is > not the actual intended use.) > > - assume that Marianne's cases are morally equivalent to > forwarding to a "virtual server" that behaves as above, and so > the H-I can be updated as if that were the case. (But the H-I > entries aren't the same, because there are none for the visit to > the "virtual server". > > - reword 4244bis so that a Reason header MAY be included (with suitable > conditions - TBD) even if not received in a response, to cover > Marianne's cases. (But this takes 4244bis beyond the scope it was > intended to cover.) > > - leave 4244bis alone, but change draft-mohali-sipcore-reason-extension- > application to be a revision to 4244bis. (Avoids the scope issue, > but results in two back-to-back revisions to the same document. > Developers will not be pleased with that.) > > What do you think? > > Thanks, > Paul > > And, that would allow for any future extensions to the Reason > header to > be plopped into an hi-entry. If the Reason header were > mandatory, then > it would be easy in that HI just uses whatever value for the Reason > header(s) that are there. > > However, without having the new values defined for the Reason > header we > can't reference them and I would rather not hold up 4244bis, just so > that we can have explicit text. Per the suggested text above, I > think > it's better anyways that we aren't referencing the specific Reason > header field values, but rather just capture what's there. > > Regards, > Mary. > > On Fri, Nov 19, 2010 at 12:16 PM, Paul Kyzivat > > >> wrote: > > I'm inclined to agree that this draft > (draft-mohali-sipcore-reason-extension-application, not > draft-mohali-diversion-history-info) *ought* to be orthogonal to > 4244bis, and "just work" with it. > > BUT, in reality I'm not convinced that this is so. The > following is > from 4244bis: > > For retargets that are the result of an explicit SIP > response, a > Reason MUST be associated with the hi-targeted-to-uri. > If the SIP > response does not include a Reason header (see > [RFC3326]), the SIP > Response Code that triggered the retargeting MUST be > included as the > Reason associated with the hi-targeted-to-uri that has been > retargeted. If the response contains a Reason header for > a protocol > that is not SIP (e.g., Q.850), it MUST be captured as an > additional > Reason associated with the hi-targeted-to-uri that has been > retargeted, along with the SIP Response Code. If the > Reason header > is a SIP reason, then it MUST be used as the Reason > associated with > the hi-targeted-to-uri rather than the SIP response code. > > Note that the above is limited to "retargets that are the > result of > an explicit SIP response". But when I look at the call flows > in the > draft, none of the retargets are the result of a sip response. > Rather, they are spontaneous retargets due to server logic. > 4244bis > does not cover using the Reason header in H-I entries for > this purpose. > > Thanks, > Paul > > > On 11/19/2010 11:42 AM, Worley, Dale R (Dale) wrote: > > ________________________________________ > From: sipcore-bounces@ietf.org > > > > [sipcore-bounces@ietf.org > > >] On > > Behalf Of Hadriel Kaplan [HKaplan@acmepacket.com > > >] > > > It was unfortunate that we ran out of time in sipcore to > talk > about Marianne's draft, because I think it's a kind of > litmus > test of rfc4244bis. Or else I think I must be missing > something > very basic. (easily the case) > _______________________________________________ > > As others have said in other terms, > draft-mohali-diversion-history-info is orthogonal to > 4244bis. > draft-mohali provides additional Reason values that > provide > more detailed information on why a call was routed as it > was. > Those Reason values will be recorded in H-I according to > 4244bis. In a sense, draft-mohali *is* a litmus test of > 4244bis, because without H-I, the value of the new > Reason values > would be dramatically reduced. But since the two are > orthogonal, draft-mohali needs to be specified, but it > can be > specified separately. > > Dale > _______________________________________________ > 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 > > From mary.ietf.barnes@gmail.com Fri Nov 19 12:59:58 2010 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 15A463A68DC for ; Fri, 19 Nov 2010 12:59:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.567 X-Spam-Level: X-Spam-Status: No, score=-102.567 tagged_above=-999 required=5 tests=[AWL=0.031, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 W3nHVYWDFeU6 for ; Fri, 19 Nov 2010 12:59:56 -0800 (PST) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id B1C173A6862 for ; Fri, 19 Nov 2010 12:59:55 -0800 (PST) Received: by iwn40 with SMTP id 40so5508423iwn.31 for ; Fri, 19 Nov 2010 13:00:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=D6dF02BrHliNhQ24uMn6o/pL19DZ5GotVmHJpfvuE0k=; b=mSAEK+8cCfYhfGJc/x87xq8ikP7GHLM6WtG2r/5i1I6D6StS6V06Z8Mbdw3AnRPtbn vY5aXNSaWB6Sr7dW+Rl/ld2fV1kxdJxHu9LxDtTVmbLsd7CF8I/KX0Dv8DJXHdu2SiyK 8MmIelrO8o9nRljA1UV9Dj9KIIJw4JlTV3XXw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=n//ReIucayk3K8ToNPCDf6BaZJuhnQn5S5wVBGYfiP6KxMIPIL329vDvy9cj/3XWGV p/QI8B0sogH53iQKF1lehMZtWf8SpVled0n5SV5uGPNwZyOGP9pwLtgJqRXGolb1jg9F 2TS+Y1NjwqRlZu6VnveRenc5OtIGOmbjRyJME= MIME-Version: 1.0 Received: by 10.231.20.68 with SMTP id e4mr371152ibb.146.1290200444639; Fri, 19 Nov 2010 13:00:44 -0800 (PST) Received: by 10.42.167.9 with HTTP; Fri, 19 Nov 2010 13:00:44 -0800 (PST) In-Reply-To: <4CE6E252.5070701@cisco.com> References: <2F27AF47-BD50-45FC-A832-DD845EEAA8FA@acmepacket.com> <4CE6BF03.1030307@cisco.com> <4CE6CC6D.30103@cisco.com> <4CE6E252.5070701@cisco.com> Date: Fri, 19 Nov 2010 15:00:44 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=000325574bc2311c1c04956e3361 Cc: sipcore@ietf.org Subject: Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case? 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: Fri, 19 Nov 2010 20:59:58 -0000 --000325574bc2311c1c04956e3361 Content-Type: text/plain; charset=ISO-8859-1 Perhaps there's something about Marianne's proposal that I don't understand, but I thought that there was some sort of retargeting that occurred for which the application reason was applicable rather than it just being fabricated. We have text that we add hi-entries for "internal" retargeting of a request and I would think that includes any "virtual" retargeting, although I would consider that still be be "internal " retargetting (i.e, it's a retarget that does not result in a new SIP request to another SIP entity. I would agree that you wouldn't just fabricate an hi-entry to include an application specific reason, but again, I didn't understand Marianne's document to be proposing that. Mary. On Fri, Nov 19, 2010 at 2:47 PM, Paul Kyzivat wrote: > Mary, > > I don't think anyone is suggesting that 4244bis have anything to say about > application-specific reason codes. > > The question is whether its permissible for a server to include a Reason in > an H-I entry when that Reason was not received in an actual response. The > trouble with arguing that the current language covers "internal" retargeting > is that if we assume some sort of virtual server that returned a redirect > and Reason, then that presumably ought to have its own H-I entry. I expect > we all agree that having such an extra H-I entry is undesirable. > > So, the question is whether the current language is sufficient to allow a > server to "fabricate" a Reason code and include it, or if we need some > explicit language to allow that. > > There is a partial analogy here to sip servers that use multiple to-tags to > pretend a request was forked, in order to provide alternative o/a outcomes. > The validity of this is based on presumption of "internal forking". In > general I think people have been ok with that without any explicit text > permitting it. But of course in the absence of H-I there is really no way to > know if the forking was virtual or real. Recently I've had someone question > the legitimacy of this argument. Ideally it would be better if it were more > strongly supported by text. > > I think the argument re Reason in H-I is a bit weaker because H-I is at the > root of it, and explaining that there was (virtual) redirection without a > corresponding H-I entry may be hard for some to swallow. (I guess we would > have to argue that it was virtual redirection to a server that didn't > support H-I and so didn't include the H-I entry. But then we would expect to > see 3xx as a Reason in addition to whatever other Reason is included.) > > But I am still open to a convincing argument that the existing words allow > this behavior. > > (The use of "cause=xxx" that I hear IMS includes is another story. Its > going to take a much stronger argument to convince me that is permitted by > 4244 or 4244bis.) > > Thanks, > Paul > > > On 11/19/2010 3:12 PM, Mary Barnes wrote: > >> My intent was that if the response to the request (based both on >> external and internal retargeting) contains any Reason header field >> values, then those are all included in the Reason header field value >> included in the hi-entry. So, I was presupposing that even in the case >> of internal retargeting the reason could be captured - including these >> new application specific ones - i.e., the "values" for the Reason header >> field are set independent (and prior) to its addition to the >> History-Info. So, what I had in mind is essentially your 2nd option >> below. >> >> I really, really do not want to bog down 4244bis to make this addition >> of application reasons explicit. Anytime we've gotten into any >> application specific discussions or proposals, it is very difficult to >> reach consensus and move work forward. And, the definition of these >> application specific reasons is significant in that it requires >> agreement on the values since it's not just reusing values already >> defined in other specifications as are the current Reason header field >> types and values. I don't see this as something that will happen very >> quickly (unfortunately), in particular given that the semantics of the >> applications noted are not yet defined (or if there is a definitive >> reference from another SDO), it needs to be included. >> >> Regards, >> Mary. >> >> On Fri, Nov 19, 2010 at 1:13 PM, Paul Kyzivat > > wrote: >> >> >> >> On 11/19/2010 1:40 PM, Mary Barnes wrote: >> >> I don't disagree that strictly speaking adding the response >> codes based >> on applications is beyond what is currently specified in >> 4244bis. We >> could add text change the text to something like the following >> (and I'm >> thinking either way that text should be updated since this is >> much more >> concise): >> >> If the response contains any Reason header fields, then >> the Reason header fields MUST be captured as Reasons >> associated with the hi-targeted-to-uri that has been >> retargeted. If the SIP >> response does not include a Reason header field (see >> [RFC3326]), the SIP >> Response Code that triggered the retargeting MUST be included >> as the >> Reason associated with the hi-targeted-to-uri that has been >> retargeted. >> >> >> (I know I'm being legalistic here, but sometimes its necessary.) >> >> The above still only covers cases where the retargeting is the >> result of a response, which doesn't cover Marianne's case. There are >> several ways to deal with this: >> >> - leave as it is. Marianne's cases won't be covered. But she can >> rewrite her draft to show a proxy forwarding to an app server >> that returns a 3xx with reason code. (But not so useful if that is >> not the actual intended use.) >> >> - assume that Marianne's cases are morally equivalent to >> forwarding to a "virtual server" that behaves as above, and so >> the H-I can be updated as if that were the case. (But the H-I >> entries aren't the same, because there are none for the visit to >> the "virtual server". >> >> - reword 4244bis so that a Reason header MAY be included (with suitable >> conditions - TBD) even if not received in a response, to cover >> Marianne's cases. (But this takes 4244bis beyond the scope it was >> intended to cover.) >> >> - leave 4244bis alone, but change >> draft-mohali-sipcore-reason-extension- >> application to be a revision to 4244bis. (Avoids the scope issue, >> but results in two back-to-back revisions to the same document. >> Developers will not be pleased with that.) >> >> What do you think? >> >> Thanks, >> Paul >> >> And, that would allow for any future extensions to the Reason >> header to >> be plopped into an hi-entry. If the Reason header were >> mandatory, then >> it would be easy in that HI just uses whatever value for the Reason >> header(s) that are there. >> >> However, without having the new values defined for the Reason >> header we >> can't reference them and I would rather not hold up 4244bis, just >> so >> that we can have explicit text. Per the suggested text above, I >> think >> it's better anyways that we aren't referencing the specific Reason >> header field values, but rather just capture what's there. >> >> Regards, >> Mary. >> >> On Fri, Nov 19, 2010 at 12:16 PM, Paul Kyzivat >> >> >> wrote: >> >> I'm inclined to agree that this draft >> (draft-mohali-sipcore-reason-extension-application, not >> draft-mohali-diversion-history-info) *ought* to be orthogonal >> to >> 4244bis, and "just work" with it. >> >> BUT, in reality I'm not convinced that this is so. The >> following is >> from 4244bis: >> >> For retargets that are the result of an explicit SIP >> response, a >> Reason MUST be associated with the hi-targeted-to-uri. >> If the SIP >> response does not include a Reason header (see >> [RFC3326]), the SIP >> Response Code that triggered the retargeting MUST be >> included as the >> Reason associated with the hi-targeted-to-uri that has been >> retargeted. If the response contains a Reason header for >> a protocol >> that is not SIP (e.g., Q.850), it MUST be captured as an >> additional >> Reason associated with the hi-targeted-to-uri that has been >> retargeted, along with the SIP Response Code. If the >> Reason header >> is a SIP reason, then it MUST be used as the Reason >> associated with >> the hi-targeted-to-uri rather than the SIP response code. >> >> Note that the above is limited to "retargets that are the >> result of >> an explicit SIP response". But when I look at the call flows >> in the >> draft, none of the retargets are the result of a sip response. >> Rather, they are spontaneous retargets due to server logic. >> 4244bis >> does not cover using the Reason header in H-I entries for >> this purpose. >> >> Thanks, >> Paul >> >> >> On 11/19/2010 11:42 AM, Worley, Dale R (Dale) wrote: >> >> ________________________________________ >> From: sipcore-bounces@ietf.org >> >> > >> >> >> [sipcore-bounces@ietf.org >> >> > >] On >> >> Behalf Of Hadriel Kaplan [HKaplan@acmepacket.com >> >> >] >> >> >> >> It was unfortunate that we ran out of time in sipcore to >> talk >> about Marianne's draft, because I think it's a kind of >> litmus >> test of rfc4244bis. Or else I think I must be missing >> something >> very basic. (easily the case) >> _______________________________________________ >> >> As others have said in other terms, >> draft-mohali-diversion-history-info is orthogonal to >> 4244bis. >> draft-mohali provides additional Reason values that >> provide >> more detailed information on why a call was routed as it >> was. >> Those Reason values will be recorded in H-I according to >> 4244bis. In a sense, draft-mohali *is* a litmus test of >> 4244bis, because without H-I, the value of the new >> Reason values >> would be dramatically reduced. But since the two are >> orthogonal, draft-mohali needs to be specified, but it >> can be >> specified separately. >> >> Dale >> _______________________________________________ >> 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 >> >> >> --000325574bc2311c1c04956e3361 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Perhaps there's something about Marianne's proposal that I don'= t understand, but I thought that there was some sort of retargeting that oc= curred for which the application reason was applicable rather than it just = being fabricated. =A0We have text that we add hi-entries for "internal= " retargeting of a request and I would think that includes any "v= irtual" retargeting, although I would consider that still be be "= internal " retargetting (i.e, it's a retarget that does not result= in a new SIP request to another SIP entity. =A0I would agree that you woul= dn't just fabricate an hi-entry to include an application specific reas= on, but again, I didn't understand Marianne's document to be propos= ing that.=A0

Mary.=A0

On Fri, Nov 19, 2= 010 at 2:47 PM, Paul Kyzivat <pkyzivat@cisco.com> wrote:
Mary,

I don't think anyone is suggesting that 4244bis have anything to say ab= out application-specific reason codes.

The question is whether its permissible for a server to include a Reason in= an H-I entry when that Reason was not received in an actual response. The = trouble with arguing that the current language covers "internal" = retargeting is that if we assume some sort of virtual server that returned = a redirect and Reason, then that presumably ought to have its own H-I entry= . I expect we all agree that having such an extra H-I entry is undesirable.=

So, the question is whether the current language is sufficient to allow a s= erver to "fabricate" a Reason code and include it, or if we need = some explicit language to allow that.

There is a partial analogy here to sip servers that use multiple to-tags to= pretend a request was forked, in order to provide alternative o/a outcomes= . The validity of this is based on presumption of "internal forking&qu= ot;. In general I think people have been ok with that without any explicit = text permitting it. But of course in the absence of H-I there is really no = way to know if the forking was virtual or real. Recently I've had someo= ne question the legitimacy of this argument. Ideally it would be better if = it were more strongly supported by text.

I think the argument re Reason in H-I is a bit weaker because H-I is at the= root of it, and explaining that there was (virtual) redirection without a = corresponding H-I entry may be hard for some to swallow. (I guess we would = have to argue that it was virtual redirection to a server that didn't s= upport H-I and so didn't include the H-I entry. But then we would expec= t to see 3xx as a Reason in addition to whatever other Reason is included.)=

But I am still open to a convincing argument that the existing words allow = this behavior.

(The use of "cause=3Dxxx" that I hear IMS includes is another sto= ry. Its going to take a much stronger argument to convince me that is permi= tted by 4244 or 4244bis.)

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul


On 11/19/2010 3:12 PM, Mary Barnes wrote:
My intent was that if the response to the request (based both on
external and internal retargeting) contains any Reason header field
values, then those are all included in the Reason header field value
included in the hi-entry. =A0So, I was presupposing that even in the case of internal retargeting the reason could be captured - including these
new application specific ones - i.e., the "values" for the Reason= header
field are set independent (and prior) to its addition to the
History-Info. =A0So, what I had in mind is essentially your 2nd option belo= w.

I really, really do not want to bog down 4244bis to make this addition
of application reasons explicit. =A0Anytime we've gotten into any
application specific discussions or proposals, it is very difficult to
reach consensus and move work forward. =A0And, the definition of these
application specific reasons is significant in that it requires
agreement on the values since it's not just reusing values already
defined in other specifications as are the current Reason header field
types and values. =A0I don't see this as something that will happen ver= y
quickly (unfortunately), in particular given that the semantics of =A0the applications noted are not yet defined (or if there is a definitive
reference from another SDO), it needs to be included.

Regards,
Mary.

On Fri, Nov 19, 2010 at 1:13 PM, Paul Kyzivat <pkyzivat@cisco.com
<mailto:pkyzivat= @cisco.com>> wrote:



=A0 =A0On 11/19/2010 1:40 PM, Mary Barnes wrote:

=A0 =A0 =A0 =A0I don't disagree that strictly speaking adding the resp= onse
=A0 =A0 =A0 =A0codes based
=A0 =A0 =A0 =A0on applications is beyond what is currently specified in =A0 =A0 =A0 =A04244bis. =A0 We
=A0 =A0 =A0 =A0could add text change the text to something like the follow= ing
=A0 =A0 =A0 =A0(and I'm
=A0 =A0 =A0 =A0thinking either way that text should be updated since this = is
=A0 =A0 =A0 =A0much more
=A0 =A0 =A0 =A0concise):

=A0 =A0 =A0 =A0 =A0 If the response contains any Reason header fields, the= n
=A0 =A0 =A0 =A0 =A0 the Reason header fields MUST be captured as Reasons =A0 =A0 =A0 =A0 =A0 associated with the hi-targeted-to-uri that has been =A0 =A0 =A0 =A0 =A0 retargeted. =A0If the SIP
=A0 =A0 =A0 =A0 =A0 response does not include a Reason header field (see =A0 =A0 =A0 =A0[RFC3326]), the SIP
=A0 =A0 =A0 =A0 =A0 Response Code that triggered the retargeting MUST be i= ncluded
=A0 =A0 =A0 =A0as the
=A0 =A0 =A0 =A0 =A0 Reason associated with the hi-targeted-to-uri that has= been
=A0 =A0 =A0 =A0 =A0 retargeted.


=A0 =A0(I know I'm being legalistic here, but sometimes its necessary.= )

=A0 =A0The above still only covers cases where the retargeting is the
=A0 =A0result of a response, which doesn't cover Marianne's case. = There are
=A0 =A0several ways to deal with this:

=A0 =A0- leave as it is. Marianne's cases won't be covered. But sh= e can
=A0 =A0 =A0rewrite her draft to show a proxy forwarding to an app server =A0 =A0 =A0that returns a 3xx with reason code. (But not so useful if that= is
=A0 =A0 =A0not the actual intended use.)

=A0 =A0- assume that Marianne's cases are morally equivalent to
=A0 =A0 =A0forwarding to a "virtual server" that behaves as abov= e, and so
=A0 =A0 =A0the H-I can be updated as if that were the case. (But the H-I =A0 =A0 =A0entries aren't the same, because there are none for the vis= it to
=A0 =A0 =A0the "virtual server".

=A0 =A0- reword 4244bis so that a Reason header MAY be included (with suit= able
=A0 =A0 =A0conditions - TBD) even if not received in a response, to cover<= br> =A0 =A0 =A0Marianne's cases. (But this takes 4244bis beyond the scope = it was
=A0 =A0 =A0intended to cover.)

=A0 =A0- leave 4244bis alone, but change draft-mohali-sipcore-reason-exten= sion-
=A0 =A0 =A0application to be a revision to 4244bis. (Avoids the scope issu= e,
=A0 =A0 =A0but results in two back-to-back revisions to the same document.=
=A0 =A0 =A0Developers will not be pleased with that.)

=A0 =A0What do you think?

=A0 =A0 =A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0 =A0 =A0Paul

=A0 =A0 =A0 =A0And, that would allow for any future extensions to the Reas= on
=A0 =A0 =A0 =A0header to
=A0 =A0 =A0 =A0be plopped into an hi-entry. =A0 If the Reason header were<= br> =A0 =A0 =A0 =A0mandatory, then
=A0 =A0 =A0 =A0it would be easy in that HI just uses whatever value for th= e Reason
=A0 =A0 =A0 =A0header(s) =A0that are there.

=A0 =A0 =A0 =A0However, without having the new values defined for the Reas= on
=A0 =A0 =A0 =A0header we
=A0 =A0 =A0 =A0can't reference them and I would rather not hold up 424= 4bis, just so
=A0 =A0 =A0 =A0that we can have explicit text. Per the suggested text abov= e, I
=A0 =A0 =A0 =A0think
=A0 =A0 =A0 =A0it's better anyways that we aren't referencing the = specific Reason
=A0 =A0 =A0 =A0header field values, but rather just capture what's the= re.

=A0 =A0 =A0 =A0Regards,
=A0 =A0 =A0 =A0Mary.

=A0 =A0 =A0 =A0On Fri, Nov 19, 2010 at 12:16 PM, Paul Kyzivat
=A0 =A0 =A0 =A0<pkyzivat@cisco.com <mailto:pkyzivat@cisco.com>
<= div class=3D"h5"> =A0 =A0 =A0 =A0<mailto:pkyzivat@cisco.com <mailto:pkyzivat@cisco.com>>> wrote:

=A0 =A0 =A0 =A0 =A0 =A0I'm inclined to agree that this draft
=A0 =A0 =A0 =A0 =A0 =A0(draft-mohali-sipcore-reason-extension-application,= not
=A0 =A0 =A0 =A0 =A0 =A0draft-mohali-diversion-history-info) *ought* to be = orthogonal to
=A0 =A0 =A0 =A0 =A0 =A04244bis, and "just work" with it.

=A0 =A0 =A0 =A0 =A0 =A0BUT, in reality I'm not convinced that this is = so. The
=A0 =A0 =A0 =A0following is
=A0 =A0 =A0 =A0 =A0 =A0from 4244bis:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 For retargets that are the result of an explic= it SIP
=A0 =A0 =A0 =A0response, a
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Reason MUST be associated with the hi-targeted= -to-uri.
=A0 =A0 =A0 =A0 =A0If the SIP
=A0 =A0 =A0 =A0 =A0 =A0 =A0 response does not include a Reason header (see=
=A0 =A0 =A0 =A0[RFC3326]), the SIP
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Response Code that triggered the retargeting M= UST be
=A0 =A0 =A0 =A0included as the
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Reason associated with the hi-targeted-to-uri = that has been
=A0 =A0 =A0 =A0 =A0 =A0 =A0 retargeted. =A0If the response contains a Reas= on header for
=A0 =A0 =A0 =A0a protocol
=A0 =A0 =A0 =A0 =A0 =A0 =A0 that is not SIP (e.g., Q.850), it MUST be capt= ured as an
=A0 =A0 =A0 =A0additional
=A0 =A0 =A0 =A0 =A0 =A0 =A0 Reason associated with the hi-targeted-to-uri = that has been
=A0 =A0 =A0 =A0 =A0 =A0 =A0 retargeted, along with the SIP Response Code. = =A0If the
=A0 =A0 =A0 =A0Reason header
=A0 =A0 =A0 =A0 =A0 =A0 =A0 is a SIP reason, then it MUST be used as the R= eason
=A0 =A0 =A0 =A0associated with
=A0 =A0 =A0 =A0 =A0 =A0 =A0 the hi-targeted-to-uri rather than the SIP res= ponse code.

=A0 =A0 =A0 =A0 =A0 =A0Note that the above is limited to "retargets t= hat are the
=A0 =A0 =A0 =A0result of
=A0 =A0 =A0 =A0 =A0 =A0an explicit SIP response". But when I look at = the call flows
=A0 =A0 =A0 =A0in the
=A0 =A0 =A0 =A0 =A0 =A0draft, none of the retargets are the result of a si= p response.
=A0 =A0 =A0 =A0 =A0 =A0Rather, they are spontaneous retargets due to serve= r logic.
=A0 =A0 =A0 =A04244bis
=A0 =A0 =A0 =A0 =A0 =A0does not cover using the Reason header in H-I entri= es for
=A0 =A0 =A0 =A0this purpose.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Paul


=A0 =A0 =A0 =A0 =A0 =A0On 11/19/2010 11:42 AM, Worley, Dale R (Dale) wrote= :

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0________________________________________ =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0From: sipcore-bounces@ietf.org
=A0 =A0 =A0 =A0<mailto:sipcore-bounces@ietf.org>
=A0 =A0 =A0 =A0<mailto:sipcore-bounces@ietf.org <mailto:sipcore-bounces@ietf.org>&g= t;

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0[sipcore-bounces@ietf.org
=A0 =A0 =A0 =A0<mailto:sipcore-bounces@ietf.org>
=A0 =A0 =A0 =A0<mailto:sipcore-bounces@ietf.org
=A0 =A0 =A0 =A0<mailto:sipcore-bounces@ietf.org>>] On

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Behalf Of Hadriel Kaplan [HKaplan@acmepacket.com
=A0 =A0 =A0 =A0<mailto:HKaplan@acmepacket.com>
=A0 =A0 =A0 =A0<mailto:HKaplan@acmepacket.com <mailto:HKaplan@acmepacket.com>>]
=



=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0It was unfortunate that we ran out of time = in sipcore to
=A0 =A0 =A0 =A0talk
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0about Marianne's draft, because I think= it's a kind of
=A0 =A0 =A0 =A0litmus
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0test of rfc4244bis. =A0Or else I think I mu= st be missing
=A0 =A0 =A0 =A0something
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0very basic. (easily the case)
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0___________________________________________= ____

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0As others have said in other terms,
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0draft-mohali-diversion-history-info is = orthogonal to
=A0 =A0 =A0 =A04244bis.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0draft-mohali provides additional Reason= values that
=A0 =A0 =A0 =A0provide
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0more detailed information on why a call was= routed as it
=A0 =A0 =A0 =A0was.
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Those Reason values will be recorded in= H-I according to
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A04244bis. =A0In a sense, draft-mohali *is* a= litmus test of
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A04244bis, because without H-I, the value of = the new
=A0 =A0 =A0 =A0Reason values
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0would be dramatically reduced. =A0But since= the two are
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0orthogonal, draft-mohali needs to be specif= ied, but it
=A0 =A0 =A0 =A0can be
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0specified separately.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Dale
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0___________________________________________= ____
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0sipcore mailing list
=A0 =A0 =A0 =A0sipco= re@ietf.org <mailto:sipcore@ietf.org>
=A0 =A0 =A0 =A0<mailto:sipcore@ietf.org <mailto:sipcore@ietf.org>>


=A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/sipcore

=A0 =A0 =A0 =A0 =A0 =A0_______________________________________________
=A0 =A0 =A0 =A0 =A0 =A0sipcore mailing list
=A0 =A0 =A0 =A0sipco= re@ietf.org <mailto:sipcore@ietf.org>
=A0 =A0 =A0 =A0<mailto:sipcore@ietf.org <mailto:sipcore@ietf.org>>


=A0 =A0 =A0 =A0https://www.ietf.org/mailman/listinfo/sipcore



--000325574bc2311c1c04956e3361-- From pkyzivat@cisco.com Fri Nov 19 13:33:47 2010 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 75B523A680A for ; Fri, 19 Nov 2010 13:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.492 X-Spam-Level: X-Spam-Status: No, score=-110.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 LBR4z8TVe45O for ; Fri, 19 Nov 2010 13:33:45 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 557ED3A68D4 for ; Fri, 19 Nov 2010 13:33:45 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAI985kxAZnwN/2dsb2JhbACiYXGiPptBhUsEhFqGAYMO X-IronPort-AV: E=Sophos;i="4.59,226,1288569600"; d="scan'208";a="184198528" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 19 Nov 2010 21:34:35 +0000 Received: from [161.44.174.105] (dhcp-161-44-174-105.cisco.com [161.44.174.105]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oAJLYZZI015682; Fri, 19 Nov 2010 21:34:35 GMT Message-ID: <4CE6ED6B.4060802@cisco.com> Date: Fri, 19 Nov 2010 16:34:35 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Mary Barnes References: <2F27AF47-BD50-45FC-A832-DD845EEAA8FA@acmepacket.com> <4CE6BF03.1030307@cisco.com> <4CE6CC6D.30103@cisco.com> <4CE6E252.5070701@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case? 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: Fri, 19 Nov 2010 21:33:47 -0000 On 11/19/2010 4:00 PM, Mary Barnes wrote: > Perhaps there's something about Marianne's proposal that I don't > understand, but I thought that there was some sort of retargeting that > occurred for which the application reason was applicable rather than it > just being fabricated. We have text that we add hi-entries for > "internal" retargeting of a request and I would think that includes any > "virtual" retargeting, although I would consider that still be be > "internal " retargetting (i.e, it's a retarget that does not result in a > new SIP request to another SIP entity. I just went looking for the language you refer to. I find some about internal retargeting and the creation of multiple H-I entries. But the language for inclusion of Reason based on responses didn't directly relate to this in my mind. Maybe its just me. In any case, when I look at B.1, there always is a *real* response that drives the insertion of a Reason. (With the exception of the timeout, which is treated as a 480 - entirely legit according to 3261.) > I would agree that you wouldn't > just fabricate an hi-entry to include an application specific reason, > but again, I didn't understand Marianne's document to be proposing that. I certainly read it that way, at least from the example. (Take a careful look at the example in the document.) IIUC that is the entire intent of the draft. It is certainly legitimate for a server responsible for the R-URI to spontaneously decide to retarget, without first having received a response to provoke that behavior. If we then grant it the right to assign a Reason for that retargeting, I think we must allow to select *any* valid Reason, whether that reason is application-specific or not. Thanks, Paul BTW, while looking at this I noticed an error in F1 in B.1. The INVITE in F1 has sip:alice@example.com as the R-URI, when it should (AFAIK) have sip:bob@example.com. Has that already been noted? > > Mary. > > On Fri, Nov 19, 2010 at 2:47 PM, Paul Kyzivat > wrote: > > Mary, > > I don't think anyone is suggesting that 4244bis have anything to say > about application-specific reason codes. > > The question is whether its permissible for a server to include a > Reason in an H-I entry when that Reason was not received in an > actual response. The trouble with arguing that the current language > covers "internal" retargeting is that if we assume some sort of > virtual server that returned a redirect and Reason, then that > presumably ought to have its own H-I entry. I expect we all agree > that having such an extra H-I entry is undesirable. > > So, the question is whether the current language is sufficient to > allow a server to "fabricate" a Reason code and include it, or if we > need some explicit language to allow that. > > There is a partial analogy here to sip servers that use multiple > to-tags to pretend a request was forked, in order to provide > alternative o/a outcomes. The validity of this is based on > presumption of "internal forking". In general I think people have > been ok with that without any explicit text permitting it. But of > course in the absence of H-I there is really no way to know if the > forking was virtual or real. Recently I've had someone question the > legitimacy of this argument. Ideally it would be better if it were > more strongly supported by text. > > I think the argument re Reason in H-I is a bit weaker because H-I is > at the root of it, and explaining that there was (virtual) > redirection without a corresponding H-I entry may be hard for some > to swallow. (I guess we would have to argue that it was virtual > redirection to a server that didn't support H-I and so didn't > include the H-I entry. But then we would expect to see 3xx as a > Reason in addition to whatever other Reason is included.) > > But I am still open to a convincing argument that the existing words > allow this behavior. > > (The use of "cause=xxx" that I hear IMS includes is another story. > Its going to take a much stronger argument to convince me that is > permitted by 4244 or 4244bis.) > > Thanks, > Paul > > > On 11/19/2010 3:12 PM, Mary Barnes wrote: > > My intent was that if the response to the request (based both on > external and internal retargeting) contains any Reason header field > values, then those are all included in the Reason header field value > included in the hi-entry. So, I was presupposing that even in > the case > of internal retargeting the reason could be captured - including > these > new application specific ones - i.e., the "values" for the > Reason header > field are set independent (and prior) to its addition to the > History-Info. So, what I had in mind is essentially your 2nd > option below. > > I really, really do not want to bog down 4244bis to make this > addition > of application reasons explicit. Anytime we've gotten into any > application specific discussions or proposals, it is very > difficult to > reach consensus and move work forward. And, the definition of these > application specific reasons is significant in that it requires > agreement on the values since it's not just reusing values already > defined in other specifications as are the current Reason header > field > types and values. I don't see this as something that will > happen very > quickly (unfortunately), in particular given that the semantics > of the > applications noted are not yet defined (or if there is a definitive > reference from another SDO), it needs to be included. > > Regards, > Mary. > > On Fri, Nov 19, 2010 at 1:13 PM, Paul Kyzivat > > >> wrote: > > > > On 11/19/2010 1:40 PM, Mary Barnes wrote: > > I don't disagree that strictly speaking adding the response > codes based > on applications is beyond what is currently specified in > 4244bis. We > could add text change the text to something like the > following > (and I'm > thinking either way that text should be updated since > this is > much more > concise): > > If the response contains any Reason header fields, then > the Reason header fields MUST be captured as Reasons > associated with the hi-targeted-to-uri that has been > retargeted. If the SIP > response does not include a Reason header field (see > [RFC3326]), the SIP > Response Code that triggered the retargeting MUST be > included > as the > Reason associated with the hi-targeted-to-uri that > has been > retargeted. > > > (I know I'm being legalistic here, but sometimes its necessary.) > > The above still only covers cases where the retargeting is the > result of a response, which doesn't cover Marianne's case. > There are > several ways to deal with this: > > - leave as it is. Marianne's cases won't be covered. But she can > rewrite her draft to show a proxy forwarding to an app server > that returns a 3xx with reason code. (But not so useful if > that is > not the actual intended use.) > > - assume that Marianne's cases are morally equivalent to > forwarding to a "virtual server" that behaves as above, and so > the H-I can be updated as if that were the case. (But the H-I > entries aren't the same, because there are none for the > visit to > the "virtual server". > > - reword 4244bis so that a Reason header MAY be included > (with suitable > conditions - TBD) even if not received in a response, to cover > Marianne's cases. (But this takes 4244bis beyond the scope > it was > intended to cover.) > > - leave 4244bis alone, but change > draft-mohali-sipcore-reason-extension- > application to be a revision to 4244bis. (Avoids the scope > issue, > but results in two back-to-back revisions to the same > document. > Developers will not be pleased with that.) > > What do you think? > > Thanks, > Paul > > And, that would allow for any future extensions to the > Reason > header to > be plopped into an hi-entry. If the Reason header were > mandatory, then > it would be easy in that HI just uses whatever value for > the Reason > header(s) that are there. > > However, without having the new values defined for the > Reason > header we > can't reference them and I would rather not hold up > 4244bis, just so > that we can have explicit text. Per the suggested text > above, I > think > it's better anyways that we aren't referencing the > specific Reason > header field values, but rather just capture what's there. > > Regards, > Mary. > > On Fri, Nov 19, 2010 at 12:16 PM, Paul Kyzivat > > > > > >>> wrote: > > I'm inclined to agree that this draft > (draft-mohali-sipcore-reason-extension-application, not > draft-mohali-diversion-history-info) *ought* to be > orthogonal to > 4244bis, and "just work" with it. > > BUT, in reality I'm not convinced that this is so. The > following is > from 4244bis: > > For retargets that are the result of an explicit SIP > response, a > Reason MUST be associated with the > hi-targeted-to-uri. > If the SIP > response does not include a Reason header (see > [RFC3326]), the SIP > Response Code that triggered the retargeting MUST be > included as the > Reason associated with the hi-targeted-to-uri > that has been > retargeted. If the response contains a Reason > header for > a protocol > that is not SIP (e.g., Q.850), it MUST be > captured as an > additional > Reason associated with the hi-targeted-to-uri > that has been > retargeted, along with the SIP Response Code. If the > Reason header > is a SIP reason, then it MUST be used as the Reason > associated with > the hi-targeted-to-uri rather than the SIP > response code. > > Note that the above is limited to "retargets that > are the > result of > an explicit SIP response". But when I look at the > call flows > in the > draft, none of the retargets are the result of a sip > response. > Rather, they are spontaneous retargets due to server > logic. > 4244bis > does not cover using the Reason header in H-I > entries for > this purpose. > > Thanks, > Paul > > > On 11/19/2010 11:42 AM, Worley, Dale R (Dale) wrote: > > ________________________________________ > From: sipcore-bounces@ietf.org > > > > > >> > > [sipcore-bounces@ietf.org > > > > > >>] On > > Behalf Of Hadriel Kaplan [HKaplan@acmepacket.com > > > > > >>] > > > > It was unfortunate that we ran out of time in > sipcore to > talk > about Marianne's draft, because I think it's a > kind of > litmus > test of rfc4244bis. Or else I think I must be > missing > something > very basic. (easily the case) > _______________________________________________ > > As others have said in other terms, > draft-mohali-diversion-history-info is > orthogonal to > 4244bis. > draft-mohali provides additional Reason values > that > provide > more detailed information on why a call was > routed as it > was. > Those Reason values will be recorded in H-I > according to > 4244bis. In a sense, draft-mohali *is* a litmus > test of > 4244bis, because without H-I, the value of the new > Reason values > would be dramatically reduced. But since the > two are > orthogonal, draft-mohali needs to be specified, > but it > can be > specified separately. > > Dale > _______________________________________________ > 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 > > > From HKaplan@acmepacket.com Sat Nov 20 06:32:35 2010 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 2497A3A69D8 for ; Sat, 20 Nov 2010 06:32:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.094 X-Spam-Level: X-Spam-Status: No, score=-2.094 tagged_above=-999 required=5 tests=[AWL=0.505, BAYES_00=-2.599] 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 q3QWz9MMc6Rl for ; Sat, 20 Nov 2010 06:32:31 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 163703A69D7 for ; Sat, 20 Nov 2010 06:32:29 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 20 Nov 2010 09:33:20 -0500 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Sat, 20 Nov 2010 09:33:20 -0500 From: Hadriel Kaplan To: " " Date: Sat, 20 Nov 2010 09:33:15 -0500 Thread-Topic: [sipcore] Why doesn't 4244bis cover Marianne's use-case? Thread-Index: AcuIv98uHrJ4/VxiST+M4qwVm/gS+A== Message-ID: References: <2F27AF47-BD50-45FC-A832-DD845EEAA8FA@acmepacket.com><4CDCAC2F.2090904@nostrum.com> <479339F9-5AE2-4145-A132-36F53D011ECF@acmepacket.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 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case? 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: Sat, 20 Nov 2010 14:32:35 -0000 On Nov 19, 2010, at 10:32 AM, wrote: > Hadriel, you said "When I read Marianne's draft, it sounds like the use-c= ase she's trying to cover is call-forwarding"=20 > but the presented draft has really NO link with Call Forwarding (it is an= other draft ;-). Sorry for the confusion - I meant draft-mohali-sipcore-reason-call-forwardi= ng-00 specifically. -hadriel From HKaplan@acmepacket.com Sat Nov 20 06:43:14 2010 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 5866E28C0E4 for ; Sat, 20 Nov 2010 06:43:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[AWL=0.498, BAYES_00=-2.599] 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 9KmKNCqb293K for ; Sat, 20 Nov 2010 06:43:12 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B329C28C0D0 for ; Sat, 20 Nov 2010 06:43:11 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Sat, 20 Nov 2010 09:44:02 -0500 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Sat, 20 Nov 2010 09:44:02 -0500 From: Hadriel Kaplan To: "Worley, Dale R (Dale)" Date: Sat, 20 Nov 2010 09:44:00 -0500 Thread-Topic: Why doesn't 4244bis cover Marianne's use-case? Thread-Index: AcuIwV764RIL37iSRruFmIDiw2FncA== Message-ID: <92A1352A-F227-4585-8095-D2E293B4A110@acmepacket.com> References: <2F27AF47-BD50-45FC-A832-DD845EEAA8FA@acmepacket.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 Cc: "sipcore@ietf.org WG" Subject: Re: [sipcore] Why doesn't 4244bis cover Marianne's use-case? 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: Sat, 20 Nov 2010 14:43:14 -0000 The two aren't orthogonal - although perhaps we're talking about a differen= t "draft-mohali". I'm talking about draft-mohali-sipcore-reason-call-forwarding-00. If you ignore the reason cause code stuff in it, the main functional differ= ence I can discern in that draft is that the call-forwarding action occurs = internally in a system, rather than externally with a SIP redirect/response= . If that's true, then what I was trying to say at the mic during the WG m= eeting was that we've already said H-I would record H-I entries for interna= l processing - essentially as if the SIP request had gone to a next-hop and= the next-hop had redirected the call using 3xx, or rejected the call with = a 4xx. What we haven't settled on is, for entries created due to internal processi= ng, whether the embedded Reason header cause code can still be used or not,= and specifically whether we can use *SIP* response codes in that embedded = Reason header for internally generated H-I entries. Personally I think it = makes sense to do so, because what matters in this whole thing is how the r= eceiver of H-I processes H-I entries to invoke specific application logic. = It doesn't actually matter whether there was a physical on-the-wire SIP 48= 6 response which caused a proxy to recurse or retarget - what matters is th= at the proxy retargeted due to the user being busy. If you believe that, then the new cause codes in draft-mohali-sipcore-reaso= n-call-forwarding-00 suddenly start to look a heck of lot like SIP reason c= odes. For example, a "User Busy" is the same as a SIP 486; a "No Reply" is= a SIP 408; a "deflection immediate response" is a 302; "Not Logged-in" is = a 480. -hadriel On Nov 19, 2010, at 11:42 AM, Worley, Dale R (Dale) wrote: > ________________________________________ > From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf Of Ha= driel Kaplan [HKaplan@acmepacket.com] >=20 > It was unfortunate that we ran out of time in sipcore to talk about Maria= nne's draft, because I think it's a kind of litmus test of rfc4244bis. Or = else I think I must be missing something very basic. (easily the case) > _______________________________________________ >=20 > As others have said in other terms, draft-mohali-diversion-history-info = is orthogonal to 4244bis. draft-mohali provides additional Reason values t= hat provide more detailed information on why a call was routed as it was. = Those Reason values will be recorded in H-I according to 4244bis. In a sen= se, draft-mohali *is* a litmus test of 4244bis, because without H-I, the va= lue of the new Reason values would be dramatically reduced. But since the = two are orthogonal, draft-mohali needs to be specified, but it can be speci= fied separately. >=20 > Dale From dworley@avaya.com Tue Nov 23 11:25:54 2010 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 A305428C129 for ; Tue, 23 Nov 2010 11:25:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.481 X-Spam-Level: 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qFp0DGJph49u for ; Tue, 23 Nov 2010 11:25:53 -0800 (PST) Received: from p-us1-iereast-outbound-tmp.us1.avaya.com (p-us1-iereast-outbound-tmp.us1.avaya.com [135.11.29.16]) by core3.amsl.com (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 co300216-co-erhwest.avaya.com) ([198.152.7.5]) by p-us1-iereast-outbound-tmp.us1.avaya.com 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 dc-us1hcex2.us1.avaya.com (HELO DC-US1HCEX2.global.avaya.com) ([135.11.52.21]) by co300216-co-erhwest-out.avaya.com with ESMTP; 23 Nov 2010 14:26:50 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX2.global.avaya.com ([::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: , <4CDC04F2.3010701@cisco.com> In-Reply-To: <4CDC04F2.3010701@cisco.com> 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 Cc: "sipcore@ietf.org" Subject: Re: [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 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 [pkyzivat@cisco.com] > >> 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 >=20 > 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: ;index=3D1, ;index=3D1.1 [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. Dale From mary.ietf.barnes@gmail.com Tue Nov 23 11:59:05 2010 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 78E2628C10B for ; Tue, 23 Nov 2010 11:59:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.568 X-Spam-Level: X-Spam-Status: No, score=-102.568 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 7pyb7teg0F-w for ; Tue, 23 Nov 2010 11:59:04 -0800 (PST) Received: from mail-gy0-f172.google.com (mail-gy0-f172.google.com [209.85.160.172]) by core3.amsl.com (Postfix) with ESMTP id 126AD28C0FE for ; Tue, 23 Nov 2010 11:59:03 -0800 (PST) Received: by gyb13 with SMTP id 13so2547359gyb.31 for ; Tue, 23 Nov 2010 12:00:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=5XdrKwwEhKmvQpRpCW7mfvDqLphAU5fguisxqXJ/+2g=; b=axL5gPEZgVSxkSAj16KiFuFAkAaGZDBYrJNFfVd0yzmsK5b5AiGiVZsR2rGb2GIwBg EjOOWdNo6JIjCzj+/HtaDbW1bsSF479PuL48+VUjCB1AOHDZACoPbNHaR/uWZdDID+mC HLBsU7Y2WmBcXb5KhWc6Sm8es7z2uhbItC7Gg= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=wcNWiiOLyjBwxJQoly37OU2bFmkx1jFrSijL87UdNnVrUiPRIjIc14OJ7Wi6Lb73jm RsXJngaIO23jmcKo3rtvyGOAAUt9TKbLrIuo1sy3mFug/Hi2/cJFVe0YKD5QObMlAY6B msnXJBSTkDdz+IS6j6rrjIaW1SUskG0LUfpGw= MIME-Version: 1.0 Received: by 10.100.196.20 with SMTP id t20mr1304319anf.142.1290542401623; Tue, 23 Nov 2010 12:00:01 -0800 (PST) Received: by 10.236.95.35 with HTTP; Tue, 23 Nov 2010 12:00:01 -0800 (PST) In-Reply-To: <4CDC04F2.3010701@cisco.com> References: <4CDC04F2.3010701@cisco.com> Date: Tue, 23 Nov 2010 14:00:01 -0600 Message-ID: From: Mary Barnes To: Paul Kyzivat Content-Type: multipart/alternative; boundary=0016e645b7646a97430495bdd17f Cc: "Worley, Dale R \(Dale\)" , "sipcore@ietf.org" Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Nov 2010 19:59:05 -0000 --0016e645b7646a97430495bdd17f Content-Type: text/plain; charset=ISO-8859-1 I think we are somewhat ratholing here. A few responses inline below [MB]. On Thu, Nov 11, 2010 at 9:00 AM, Paul Kyzivat wrote: > inline > > > On 11/11/2010 5:09 PM, Worley, Dale R (Dale) wrote: > > 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 >> > > yep > > > 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. >> 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? > > > 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. >> > > I disagree its a good thing. > > If we need new response codes we can define them, so we shouldn't in > general need new response codes to clarify response codes. > > Perhaps the Q.850 stuff is a special case since we are there relating > things from a different and independent namespace. Even then its a bit dicy. > > 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. > The intent of the Reason in the HI entries is to capture the reason a request was retargeted. The current normative text is the Reason (escaped header, header field, whatever) in the HI-entry is populated based on SIP Response codes and any other Reason header (e.g., Q.850) that might be associated with the request. The Reason is included in the hi-entry with the hi-targeted-to-uri that was retargeted (i.e., the old) versus the hi-targeted-to-uri in the hi-entry to which the Request is being sent. We should not change this due to backwards compatibility AND I think any new Reason values that we want to add to the hi-entries need to be added consistently. Thus IF there is agreement to add new Reason header field values for applications, then if those are used to populate the hi-entry, they should also be interpreted in the hi-entries to correspond to the hi-targeted-to-uri that was retargeted (i.e., the old URI that is lost) based on a decision that the request be associated with a specific application RATHER than the Reason being the application associated with the hi-entry with the hi-targeted-to-uri to which the request is being sent (i.e, the new URI). I would suggest that the best way forward is that we keep the current text as is and note that any additional Reason headers that are defined in the future MUST be interpreted in the same manner. However, I do NOT think we should hold up 4244bis until we get full agreement on adding new Reason header values for applications as I firmly believe it is orthogonal - it can work based upon the current normative approach and interpretation of the Reason in the hi-entries. We can debate till the end of time (or the end of SIPCORE WG as we did with other broken things in SIP) that this wasn't the right approach, but it is what it is and I think it's time to move forward. Regards, Mary. > > Thanks, > Paul > --0016e645b7646a97430495bdd17f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I think we are somewhat ratholing here. =A0A few responses inline below [MB= ].=A0

On Thu, Nov 11, 2010 at 9:00 AM, Pa= ul Kyzivat <pkyz= ivat@cisco.com> wrote:
inline


On 11/11/2010 5:09 PM, Worley, Dale R (Dale) wrote:

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

yep


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 versu= s 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.
Consider:

=A0 =A0draft-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?
=A0 =A0isn't it still just an individual draft?


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. =A0It's probably a good thing. =A0It's a bit ske= tchy 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.

I disagree its a good thing.

If we need new response codes we can define them, so we shouldn't in ge= neral need new response codes to clarify response codes.

Perhaps the Q.850 stuff is a special case since we are there relating thing= s from a different and independent namespace. Even then its a bit dicy.

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 re= asons in Marianne's draft are *not* reasons for responses. They are rea= sons for retargeting, generally without there having been any response. The= y are indeed a reason for a request. And it is a reason for the request wit= h the new target, not the reason for the request with the old target.
The intent of the Reason in the HI entries is to capture = the reason a request was retargeted. =A0The current normative text is the R= eason (escaped header, header field, whatever) in the HI-entry is populated= based on SIP Response codes and any other Reason header (e.g., Q.850) that= might be associated with the request. =A0The Reason is included in the hi-= entry with the hi-targeted-to-uri that was retargeted (i.e., the old) versu= s the hi-targeted-to-uri in the hi-entry to which the Request is being sent= . =A0We should not change this due to backwards compatibility AND I think a= ny new Reason values that we want to add to the hi-entries need to be added= consistently.

Thus IF there is agreement to add new Reason header fie= ld values for applications, then if those are used to populate the hi-entry= , they should also be interpreted in the hi-entries to correspond to the hi= -targeted-to-uri that was retargeted=A0(i.e., the old URI that is lost) bas= ed on a decision that the request be associated with a specific application= RATHER than the Reason being the application associated with the hi-entry = with the hi-targeted-to-uri to which the request is being sent (i.e, the ne= w URI). =A0

I would suggest that the best way forward is that we ke= ep the current text as is and note that any additional Reason headers that = are defined in the future MUST be interpreted in the same manner. =A0Howeve= r, I do NOT think we should hold up 4244bis until we get full agreement on = adding new Reason header values for applications as I firmly believe it is = orthogonal - it can work based upon the current normative approach and inte= rpretation of the Reason in the hi-entries. =A0We can debate till the end o= f time (or the end of SIPCORE WG as we did with other broken things in SIP)= that this wasn't the right approach, but it is what it is and I think = it's time to move forward.=A0

Regards,
Mary.=A0
=A0

=A0 =A0 =A0 =A0Thanks,
=A0 =A0 =A0 =A0Paul

--0016e645b7646a97430495bdd17f-- From rjsparks@nostrum.com Tue Nov 23 11:59:30 2010 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 EC15F28C10B for ; Tue, 23 Nov 2010 11:59:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.15 X-Spam-Level: X-Spam-Status: No, score=-101.15 tagged_above=-999 required=5 tests=[AWL=-1.450, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, MANGLED_PILL=2.3, SPF_PASS=-0.001, 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 EIGNJiUkJd6D for ; Tue, 23 Nov 2010 11:59:30 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 7564D28C0FE for ; Tue, 23 Nov 2010 11:59:28 -0800 (PST) Received: from [192.168.2.105] (pool-173-71-48-4.dllstx.fios.verizon.net [173.71.48.4]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oANK0Mum094960 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Nov 2010 14:00:22 -0600 (CST) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Nov 2010 14:00:21 -0600 Message-Id: <9D7CD9CF-4E47-41D1-8D01-F98808851223@nostrum.com> To: SIPCORE Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Received-SPF: pass (nostrum.com: 173.71.48.4 is authenticated by a trusted mechanism) Subject: [sipcore] Security issue in -keep-08 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: Tue, 23 Nov 2010 19:59:31 -0000 I believe there is a serious problem with the recommendations in the = Security Considerations section in keep-08 where it discusses having downstream elements change the keep parameter. Consider this scenario. A user agent implementing this specification = sends a request that goes through two proxies before it arrives at its destination. The first proxy does not = know about this specification. The second proxy does, and chooses to attempt to maliciously affect the = relationship between UA1 and P1 as suggested in these security considerations. View the following flow in a fixed-width font: UA1 P1 P2 UA2 | | | |=20 | INVITE | | | | Via: UA;keep | INVITE | | |------------------>| Via: P1 | |=20 | | Via: UA;keep | |=20 | |--------------->| | | | |----->|=20 | | | 200 | | | 200 |<-----| | | Via: P1 | | | 200 | Via: UA;keep=3D1 | | | Via: UA;keep=3D1 |<---------------| | |<------------------| | |=20 | | | |=20 Since P1 doesn't support this specification, it does not know to look at = "it's" Via to see if some downstream element has modified what it would have put in the keep parameter value = - the recommendation in the current draft does not mitigate this attack at all. If the hop between UA1 and = P1 is UDP, this may result in STUN being send towards P1's SIP listening port with P1 not expecting (or being = able to deal with) it. This is a general problem with attempting to use Via parameters to = indicate support for extensions. A similar problem exists for ;rport, and for ;lr. However, if a downstream element = abused those parameters, signaling is guaranteed to fail. This proposed parameter has a different property = - this abuse may only result in extra traffic for someone else. I don't think this document is the right place to solve the general = problem, but this discussion needs to be rewritten to be clearer about the problem and the lack of any current = way to mitigate it. RjS= From rjsparks@nostrum.com Tue Nov 23 12:29:59 2010 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 6711C28C1A6 for ; Tue, 23 Nov 2010 12:29:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.238 X-Spam-Level: X-Spam-Status: No, score=-102.238 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, SPF_PASS=-0.001, 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 tB5O6V1wH5-C for ; Tue, 23 Nov 2010 12:29:58 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 05AD93A6933 for ; Tue, 23 Nov 2010 12:29:57 -0800 (PST) Received: from [192.168.2.105] (pool-173-71-48-4.dllstx.fios.verizon.net [173.71.48.4]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oANKUojN097324 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 23 Nov 2010 14:30:51 -0600 (CST) (envelope-from rjsparks@nostrum.com) From: Robert Sparks Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Tue, 23 Nov 2010 14:30:50 -0600 Message-Id: <4892E0CC-52C7-4422-A5DA-C6A7553A4053@nostrum.com> To: SIPCORE Mime-Version: 1.0 (Apple Message framework v1081) X-Mailer: Apple Mail (2.1081) Received-SPF: pass (nostrum.com: 173.71.48.4 is authenticated by a trusted mechanism) Subject: [sipcore] AD review: draft-ietf-sipcore-keep-08 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: Tue, 23 Nov 2010 20:29:59 -0000 Summary: Revised ID needed The text needs to be adjusted to reflect the security issue I called out = in a separate message to the list today. During that adjustment, there are a few other places to consider making = changes: * Section 4.4, second paragraph "The parameter can contain" is confusing = - it could be read to imply that the parameter can contain other things as well. I suggest rewriting this = sentence as "The parameter value, if present, represents a recommended keep-alive frequency..." * The document talks about invoking keep for INVITE initiated dialogs, = but not about SUBSCRIBE initiated dialogs. Was it the intent to not allow the use of the mechanism for = SUBSCRIBE initiated dialogs? =20 * Section 4.4 talks about normative server behavior for using this = mechanism with INVITE initiated dialogs. where is the companion set of normative requirements for using the = mechanism to keep alive a REGISTRATION flow? * In several places, the document refers to an element inspecting "its" = Via header. This is imprecise and will lead to arguments among implementers. I suggest explicitly calling = out "the topmost Via header field value" and being very specific about when you are talking about a message = being received or a message being sent. * In section 5's fourth paragraph, it would help avoid confusion to say = "adds a value the a 'keep' parameter to indicate willingness" instead of "uses the 'keep' parameter...". *In the last sentence of Section 5 - what value is "without forcing = entities to re-write the value of Flow-Timer header field" adding? I suggest deleting the phrase. * Section 6's first paragraph says "Entities that want to reuse = connections MUST use a another mechanism". (Note the spurious 'a'). Why is this a 2119 MUST? I suggest saying = "would need to" instead. * The first sentence in 7.4 would be better if it said Figure 3 instead = of "The figure". The end of the first paragraph has a spurious period. * All of the examples showing Via header fields use a shorthand, = pseudo-code style representation of the header field format. It would be good to explicitly note that in the = document. It would be better to provide one example that was syntactically correct. * In Section 10's section paragraph. I suggest that you be explicit that = you are talking about hop-by-hop integrity protection (calling out TLS or DTLS), to avoid confusion = with end-to-end integrity protection mechanisms (S/MIME) which will not help this case. * In section 10's third paragraph, you call out "(at high rates)". This = is potentially misleading - the rates are at the highest somewhere just under once a second. I suggest = replacing "(at high rates)" with "(up to approximately once a second)". =20 From pkyzivat@cisco.com Tue Nov 23 16:05:41 2010 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 EB9DE3A69C3 for ; Tue, 23 Nov 2010 16:05:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.899 X-Spam-Level: X-Spam-Status: No, score=-109.899 tagged_above=-999 required=5 tests=[AWL=-0.500, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-8, 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 B6EKFtjCDMtj for ; Tue, 23 Nov 2010 16:05:40 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 212CF3A6987 for ; Tue, 23 Nov 2010 16:05:40 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALfl60xAZnwN/2dsb2JhbACia3GicJsmhUsEhFqGBIMP X-IronPort-AV: E=Sophos;i="4.59,244,1288569600"; d="scan'208";a="185316721" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 24 Nov 2010 00:06:38 +0000 Received: from [161.44.174.105] (dhcp-161-44-174-105.cisco.com [161.44.174.105]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oAO06cfM003419; Wed, 24 Nov 2010 00:06:38 GMT Message-ID: <4CEC570D.8080700@cisco.com> Date: Tue, 23 Nov 2010 19:06:37 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Mary Barnes References: <4CDC04F2.3010701@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Worley, Dale R \(Dale\)" , "sipcore@ietf.org" Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 00:05:42 -0000 On 11/23/2010 3:00 PM, Mary Barnes wrote: > I think we are somewhat ratholing here. A few responses inline below [MB]. Yes, I agree on that. > The intent of the Reason in the HI entries is to capture the reason a > request was retargeted. The current normative text is the Reason > (escaped header, header field, whatever) in the HI-entry is populated > based on SIP Response codes and any other Reason header (e.g., Q.850) > that might be associated with the request. The Reason is included in > the hi-entry with the hi-targeted-to-uri that was retargeted (i.e., the > old) versus the hi-targeted-to-uri in the hi-entry to which the Request > is being sent. We should not change this due to backwards compatibility > AND I think any new Reason values that we want to add to the hi-entries > need to be added consistently. > Thus IF there is agreement to add new Reason header field values for > applications, then if those are used to populate the hi-entry, they > should also be interpreted in the hi-entries to correspond to the > hi-targeted-to-uri that was retargeted (i.e., the old URI that is lost) > based on a decision that the request be associated with a specific > application RATHER than the Reason being the application associated with > the hi-entry with the hi-targeted-to-uri to which the request is being > sent (i.e, the new URI). In the interests of making progress rather than rat hole'ing, I already agreed (reluctantly) to acknowledge that the Reason headers in H-I entries need to continue to be assigned to the entries they have been, even though IMO this is nonsensical. We established that the URIs in H-I entries come from R-URIs that have no embedded headers, so that the embedded header in the H-I entry is only there as a result of explicit addition during the construction of the H-I entry. We just have to consider that the semantics of its presence there are unique. I'm no longer arguing that point. But my remaining concern is about the rules in 4244bis regarding how and when Reason headers are included in the H-I entries. It still seems to me that the text only talks about including them due to a response having been received. Where is the language that discusses adding a reason when retargeting is performed for some reason unrelated to a response? While I think one can argue that a server doing such retargeting can imagine having sent the request to a virtual redirect server and then processing the response from it, ISTM that would then call for adding H-I entries for those steps. > I would suggest that the best way forward is that we keep the current > text as is and note that any additional Reason headers that are defined > in the future MUST be interpreted in the same manner. However, I do NOT > think we should hold up 4244bis until we get full agreement on adding > new Reason header values for applications as I firmly believe it is > orthogonal - it can work based upon the current normative approach and > interpretation of the Reason in the hi-entries. We can debate till the > end of time (or the end of SIPCORE WG as we did with other broken things > in SIP) that this wasn't the right approach, but it is what it is and I > think it's time to move forward. I agree that 4244bis should not be held up because of the new reason values draft(s?). At this point I would just like some clarity whether the *way* reasons are used in the examples in draft-mohali-sipcore-reason-extension-application-00 - reasons without responses - is thought to be *valid* in the context of 4244bis. If the answer is NO, then I'll shut up, and let Marianne or somebody else from 3gpp complain if they think it should be. If the answer is YES - that usage is considered valid according to 4244bis, then I still want to know why, and perhaps see some additional text to make it clear. Thanks, Paul From christer.holmberg@ericsson.com Wed Nov 24 04:49:25 2010 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 8ADF528C1EA for ; Wed, 24 Nov 2010 04:49:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.208 X-Spam-Level: X-Spam-Status: No, score=-5.208 tagged_above=-999 required=5 tests=[AWL=-1.509, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, MANGLED_PILL=2.3, RCVD_IN_DNSWL_MED=-4] 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 gywfNBP+H7KP for ; Wed, 24 Nov 2010 04:49:20 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 3184D28C1C4 for ; Wed, 24 Nov 2010 04:49:19 -0800 (PST) X-AuditID: c1b4fb3d-b7b8cae0000016b1-a3-4ced0a0a2898 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 34.C5.05809.A0A0DEC4; Wed, 24 Nov 2010 13:50:19 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0237.eemea.ericsson.se ([153.88.115.90]) with mapi; Wed, 24 Nov 2010 13:50:18 +0100 From: Christer Holmberg To: Robert Sparks , SIPCORE Date: Wed, 24 Nov 2010 13:50:17 +0100 Thread-Topic: Security issue in -keep-08 Thread-Index: AcuLSRGPLIqZJaLvQqOi7v3m/yMeMAAjAw2g Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850307D840@ESESSCMS0356.eemea.ericsson.se> References: <9D7CD9CF-4E47-41D1-8D01-F98808851223@nostrum.com> In-Reply-To: <9D7CD9CF-4E47-41D1-8D01-F98808851223@nostrum.com> 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: AAAAAA== Subject: Re: [sipcore] Security issue in -keep-08 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: Wed, 24 Nov 2010 12:49:25 -0000 Hi Robert, Thanks for reviewing the document! I guess the attack you describe could also happen in Outbound, if someone i= nserts an "ob" parameter in the Path header of the proxy adjacent to the UA= , and that proxy does not check its Path header before forwarding the respo= nse to the UA. Having said that, I guess a way to protect against this attack could be to = say that an entity MUST stop sending STUN messages if it doesn't receive a = response to them. Regards, Christer =20 > -----Original Message----- > From: Robert Sparks [mailto:rjsparks@nostrum.com]=20 > Sent: 23. marraskuuta 2010 22:00 > To: SIPCORE > Cc: Christer Holmberg > Subject: Security issue in -keep-08 >=20 > I believe there is a serious problem with the recommendations=20 > in the Security Considerations section in keep-08 where it=20 > discusses having downstream elements change the keep parameter. >=20 > Consider this scenario. A user agent implementing this=20 > specification sends a request that goes through two proxies=20 > before it arrives at its destination. The first proxy does=20 > not know about this specification. The second proxy does, and=20 > chooses to attempt to maliciously affect the relationship=20 > between UA1 and P1 as suggested in these security considerations. >=20 > View the following flow in a fixed-width font: >=20 > UA1 P1 P2 UA2 > | | | |=20 > | INVITE | | | > | Via: UA;keep | INVITE | | > |------------------>| Via: P1 | |=20 > | | Via: UA;keep | |=20 > | |--------------->| | > | | |----->|=20 > | | | 200 | > | | 200 |<-----| > | | Via: P1 | | > | 200 | Via: UA;keep=3D1 | | > | Via: UA;keep=3D1 |<---------------| | > |<------------------| | |=20 > | | | |=20 >=20 >=20 > Since P1 doesn't support this specification, it does not know=20 > to look at "it's" Via to see if some downstream element has=20 > modified what it would have put in the keep parameter value -=20 > the recommendation in the current draft does not mitigate=20 > this attack at all. If the hop between UA1 and P1 is UDP,=20 > this may result in STUN being send towards P1's SIP listening=20 > port with P1 not expecting (or being able to deal with) it. >=20 > This is a general problem with attempting to use Via=20 > parameters to indicate support for extensions. A similar=20 > problem exists for ;rport, and for ;lr. However, if a=20 > downstream element abused those parameters, signaling is=20 > guaranteed to fail. This proposed parameter has a different=20 > property - this abuse may only result in extra traffic for=20 > someone else. >=20 > I don't think this document is the right place to solve the=20 > general problem, but this discussion needs to be rewritten to=20 > be clearer about the problem and the lack of any current way=20 > to mitigate it. >=20 > RjS= From dworley@avaya.com Wed Nov 24 07:22:36 2010 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 0ADBC28C10E for ; Wed, 24 Nov 2010 07:22:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.489 X-Spam-Level: X-Spam-Status: No, score=-102.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, 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 W0R6R85YX4f9 for ; Wed, 24 Nov 2010 07:22:35 -0800 (PST) Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by core3.amsl.com (Postfix) with ESMTP id 1423428C0E1 for ; Wed, 24 Nov 2010 07:22:34 -0800 (PST) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvcHAHG87EyHCzI1/2dsb2JhbACieWsGpUgCmSmFRwSEW4ku X-IronPort-AV: E=Sophos;i="4.59,248,1288584000"; d="scan'208";a="220079193" Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 24 Nov 2010 10:23:33 -0500 X-IronPort-AV: E=Sophos;i="4.59,248,1288584000"; d="scan'208";a="544454375" Received: from unknown (HELO DC-US1HCEX3.global.avaya.com) ([135.11.52.22]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 24 Nov 2010 10:23:32 -0500 Received: from DC-US1MBEX4.global.avaya.com ([169.254.1.90]) by DC-US1HCEX3.global.avaya.com ([135.11.52.22]) with mapi; Wed, 24 Nov 2010 10:23:32 -0500 From: "Worley, Dale R (Dale)" To: "sipcore@ietf.org" Date: Wed, 24 Nov 2010 10:23:31 -0500 Thread-Topic: draft-holmberg-sipcore-proxy-feature-00 Thread-Index: AQHLi+pQsOY1XYWsbEehaS5zfdjC8A== Message-ID: 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 Subject: [sipcore] draft-holmberg-sipcore-proxy-feature-00 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: Wed, 24 Nov 2010 15:22:36 -0000 I previously wrote: > Knowing that the Path can be used in the UA-to-registrar direction > (as well as the registrar-to-UA direction) tells the UA something > that it *already knows*, viz., how to get requests to the registrar. Hadriel clarified this matter to me. The expected architectural situation is where: The UA registers to one of a number of registrars. Based on which registrar the UA is registered to, the UA must use a *corresponding* proxy. I am told this is common in 3GPP designs, but it is an abnormal method of operation in generic SIP. (Our product can operate with a cluster of proxy/registrars, but we have gone to signficant work to ensure that the proxies and registrars are fully interchangable on a request-by-request basis.) This feature of the expected use case should be made more clear for the (majority of) people in SIP who aren't familiar with the 3GPP architecture. Dale From christer.holmberg@ericsson.com Wed Nov 24 11:18:30 2010 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 301AA3A69A5 for ; Wed, 24 Nov 2010 11:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.696 X-Spam-Level: X-Spam-Status: No, score=-5.696 tagged_above=-999 required=5 tests=[AWL=-0.855, BAYES_00=-2.599, FR_3TAG_3TAG=1.758, RCVD_IN_DNSWL_MED=-4] 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 e+VgevHaV+8A for ; Wed, 24 Nov 2010 11:18:29 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 7466D3A6990 for ; Wed, 24 Nov 2010 11:18:28 -0800 (PST) X-AuditID: c1b4fb39-b7c5aae000003b0f-6a-4ced653f1b1a Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 26.FC.15119.F356DEC4; Wed, 24 Nov 2010 20:19:27 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Wed, 24 Nov 2010 20:19:27 +0100 From: Christer Holmberg To: Robert Sparks , SIPCORE Date: Wed, 24 Nov 2010 20:19:26 +0100 Thread-Topic: AD review: draft-ietf-sipcore-keep-08 Thread-Index: AcuLTVOcJ65h0amkTRmAnyyGNzH3WwAifNKQ Message-ID: <224F5CB1ECAB2C45BC64065AFD0339650406B5FC94@ESESSCMS0356.eemea.ericsson.se> References: <4892E0CC-52C7-4422-A5DA-C6A7553A4053@nostrum.com> In-Reply-To: <4892E0CC-52C7-4422-A5DA-C6A7553A4053@nostrum.com> 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: AAAAAA== Subject: Re: [sipcore] AD review: draft-ietf-sipcore-keep-08 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: Wed, 24 Nov 2010 19:18:30 -0000 Hi Robert, Comments inline ([CHH]) >Summary: Revised ID needed >=20 >The text needs to be adjusted to reflect the security issue I=20 >called out in a separate message to the list today. >During that adjustment, there are a few other places to=20 >consider making changes: [CHH] See other thread. ------ >* Section 4.4, second paragraph "The parameter can contain"=20 >is confusing - it could be read to imply that the parameter=20 >can contain other things as well. I suggest rewriting this=20 >sentence as "The parameter value, if present, represents a=20 >recommended keep-alive frequency..." [CHH] Done. "The parameter value, if present and with a value other than zero, represen= ts a recommended keep-alive frequency, given in seconds." ------- >* The document talks about invoking keep for INVITE initiated=20 >dialogs, but not about SUBSCRIBE initiated dialogs. Was it the=20 >intent to not allow the use of the mechanism for SUBSCRIBE initiated=20 >dialogs? [CHH] The intent was to allow it for INVITE initiaded dialogs. I can't remember any technical reasons why keep could not be applied also t= o SUB dialogs. Nobody has ever requested it, however. ------- =20 >* Section 4.4 talks about normative server behavior for using=20 >this mechanism with INVITE initiated dialogs. >where is the companion set of normative requirements for=20 >using the mechanism to keep alive a REGISTRATION >flow? [CHH] The 2nd paragraph is the generic rule, which covers both INVITE and R= EGISTER. The 3rd paragraph is an addition that covers the case where multiple respon= ses are sent to a request, which is INVITE specific. But, maybe to make it more clear, and based on your comment on section 5 (s= ee further down), I could rewrite the 3rd paragraph: "There might be multiple responses to an INVITE request. When a SIP entity indicates willingness to receive keep-alives in a response to an INVITE request, it MUST add a parameter value to the=20 "keep" parameter in at least one reliable response to the request. The SIP = entity MAY add identical parameter values to the "keep" parameters in other responses= to the same request. The SIP entity MUST NOT add different parameter value to the= "keep"=20 parameters in responses to the same request. The SIP entity SHOULD indicate= =20 the willingness to receive keep-alives as soon as possible." The same editorial change would also be done in section 3: ""keep" parameter: A SIP Via header field parameter that a SIP entity can insert in its Via header field of a request to explicitly indicate willingness to send keep-alives towards its adjacent downstream SIP entity. A SIP entity can add a parameter value to=20 the "keep" parameter in a response to explicitly indicate willingness to=20 receive keep-alives from its adjacent upstream SIP entity." -------=20 >* In several places, the document refers to an element=20 >inspecting "its" Via header. This is imprecise and will >lead to arguments among implementers. I suggest=20 >explicitly calling out "the topmost Via header field value" >and being very specific about when you are talking about a=20 >message being received or a message being sent. [CHH] I will look into that. ------- =20 >* In section 5's fourth paragraph, it would help avoid=20 >confusion to say "adds a value the a 'keep' parameter to >indicate willingness" instead of "uses the 'keep' parameter...". [CHH] Done. "If a SIP entity that adds a parameter value to the "keep" parameter, in or= der to indicate willingness to receive keep-alives, also inserts..." ------- =20 >*In the last sentence of Section 5 - what value is "without=20 >forcing entities to re-write the value of Flow-Timer header=20 >field" adding? I suggest deleting the phrase. [CHH] Done. ------- >* Section 6's first paragraph says "Entities that want to=20 >reuse connections MUST use a another mechanism". >(Note the spurious 'a'). Why is this a 2119 MUST? I=20 >suggest saying "would need to" instead. [CHH] Done.=20 The reason behind the "MUST" was to clearly indicate that keep as such is n= ot a connection reuse mechanism. ------- >* The first sentence in 7.4 would be better if it said Figure=20 >3 instead of "The figure". The end of the first >paragraph has a spurious period. [CHH] Done. ------- >* All of the examples showing Via header fields use a=20 >shorthand, pseudo-code style representation of the >header field format. It would be good to explicitly note=20 >that in the document. It would be better to provide >one example that was syntactically correct. [CHH] I assume you mean that, instead of "Via:UAC" and "Via:P1" I would use= something like "Via:uac.operator.com" and "Via:p1.operator.com"? Personally I think it's more clear to use pseudo-style (as the example is n= ot supposed to be teach-yourself-SIP), but I can change according to your s= uggestion. ------- =20 >* In Section 10's section paragraph. I suggest that you be=20 >explicit that you are talking about hop-by-hop >integrity protection (calling out TLS or DTLS), to avoid=20 >confusion with end-to-end integrity protection >mechanisms (S/MIME) which will not help this case. [CHH] I suggest the follwoing change (): "Unless SIP messages are integrity protected hop-by-hop (e.g. using TL= S or DTLS),=20 a man-in-the-middle can modify Via header fields...." ------- =20 >* In section 10's third paragraph, you call out "(at high=20 >rates)". This is potentially misleading - the rates >are at the highest somewhere just under once a second. I=20 >suggest replacing "(at high rates)" with >"(up to approximately once a second)". [CHH] Done. =20 ------- Thank You for reviewing the document! Regards, Christer= From christer.holmberg@ericsson.com Wed Nov 24 12:26:29 2010 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 D254328C13A for ; Wed, 24 Nov 2010 12:26:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.233 X-Spam-Level: X-Spam-Status: No, score=-6.233 tagged_above=-999 required=5 tests=[AWL=-0.234, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_MED=-4] 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 yFxDAfT9UF0l for ; Wed, 24 Nov 2010 12:26:24 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id A4CF328C136 for ; Wed, 24 Nov 2010 12:26:23 -0800 (PST) X-AuditID: c1b4fb3d-b7b8cae0000016b1-38-4ced752a2f08 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 62.D1.05809.A257DEC4; Wed, 24 Nov 2010 21:27:23 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Wed, 24 Nov 2010 21:27:20 +0100 From: Christer Holmberg To: Paul Kyzivat , Mary Barnes Date: Wed, 24 Nov 2010 21:27:19 +0100 Thread-Topic: [sipcore] Reason as a parameter rather than an escaped header Thread-Index: AcuLa3pzhdzxtFR3ROW5F0D6sgmHdAAqaG6x Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502C71884@ESESSCMS0356.eemea.ericsson.se> References: <4CDC04F2.3010701@cisco.com> , <4CEC570D.8080700@cisco.com> In-Reply-To: <4CEC570D.8080700@cisco.com> 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: AAAAAA== Cc: "Worley, Dale R \(Dale\)" , "sipcore@ietf.org" Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 20:26:29 -0000 Hi, >> I would suggest that the best way forward is that we keep the current >> text as is and note that any additional Reason headers that are defined >> in the future MUST be interpreted in the same manner. However, I do NOT >> think we should hold up 4244bis until we get full agreement on adding >> new Reason header values for applications as I firmly believe it is >> orthogonal - it can work based upon the current normative approach and >> interpretation of the Reason in the hi-entries. We can debate till the >> end of time (or the end of SIPCORE WG as we did with other broken things >> in SIP) that this wasn't the right approach, but it is what it is and I >> think it's time to move forward. > >I agree that 4244bis should not be held up because of the new reason >values draft(s?). > >At this point I would just like some clarity whether the *way* reasons >are used in the examples in >draft-mohali-sipcore-reason-extension-application-00 - reasons without >responses - is thought to be *valid* in the context of 4244bis. If the >answer is NO, then I'll shut up, and let Marianne or somebody else from >3gpp complain if they think it should be. > >If the answer is YES - that usage is considered valid according to >4244bis, then I still want to know why, and perhaps see some additional >text to make it clear. I think we should ask ourselves: assuming we allowed to do what Marianne is= proposing, would anything break? Does anyone really care whether a H-I entry was inserted based on a "real" = or "virtual" response? Aren't people more interested in the actual reason v= alue? Regards, Christer= From pkyzivat@cisco.com Wed Nov 24 14:35:36 2010 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 85B1328C1A4 for ; Wed, 24 Nov 2010 14:35:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.213 X-Spam-Level: X-Spam-Status: No, score=-110.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_51=0.6, RCVD_IN_DNSWL_HI=-8, 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 0qpcYWDdfGTj for ; Wed, 24 Nov 2010 14:35:33 -0800 (PST) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id DF8A428C129 for ; Wed, 24 Nov 2010 14:35:32 -0800 (PST) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFsi7UxAZnwM/2dsb2JhbACjCXGjEJsuhUcEhFuGBYMP X-IronPort-AV: E=Sophos;i="4.59,250,1288569600"; d="scan'208";a="185909137" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 24 Nov 2010 22:36:33 +0000 Received: from [10.86.254.111] ([10.86.254.111]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAOMaWtW012387; Wed, 24 Nov 2010 22:36:32 GMT Message-ID: <4CED9370.5010001@cisco.com> Date: Wed, 24 Nov 2010 17:36:32 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Christer Holmberg References: <4CDC04F2.3010701@cisco.com> , <4CEC570D.8080700@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502C71884@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502C71884@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Worley, Dale R \(Dale\)" , "sipcore@ietf.org" Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 22:35:36 -0000 On 11/24/2010 3:27 PM, Christer Holmberg wrote: > Hi, > >>> I would suggest that the best way forward is that we keep the current >>> text as is and note that any additional Reason headers that are defined >>> in the future MUST be interpreted in the same manner. However, I do NOT >>> think we should hold up 4244bis until we get full agreement on adding >>> new Reason header values for applications as I firmly believe it is >>> orthogonal - it can work based upon the current normative approach and >>> interpretation of the Reason in the hi-entries. We can debate till the >>> end of time (or the end of SIPCORE WG as we did with other broken things >>> in SIP) that this wasn't the right approach, but it is what it is and I >>> think it's time to move forward. >> >> I agree that 4244bis should not be held up because of the new reason >> values draft(s?). >> >> At this point I would just like some clarity whether the *way* reasons >> are used in the examples in >> draft-mohali-sipcore-reason-extension-application-00 - reasons without >> responses - is thought to be *valid* in the context of 4244bis. If the >> answer is NO, then I'll shut up, and let Marianne or somebody else from >> 3gpp complain if they think it should be. >> >> If the answer is YES - that usage is considered valid according to >> 4244bis, then I still want to know why, and perhaps see some additional >> text to make it clear. > > I think we should ask ourselves: assuming we allowed to do what Marianne is proposing, would anything break? > > Does anyone really care whether a H-I entry was inserted based on a "real" or "virtual" response? Aren't people more interested in the actual reason value? I don't currently see a problem with permitting this (though I'm interested to hear if somebody else sees an issue). But IMO the current text doesn't suggest to me that this is valid. So if the desire is for it to be valid it would be good to have some text that makes it so. Thanks, Paul From adam@nostrum.com Wed Nov 24 15:53:30 2010 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 80F3F28C15F for ; Wed, 24 Nov 2010 15:53:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.583 X-Spam-Level: X-Spam-Status: No, score=-102.583 tagged_above=-999 required=5 tests=[AWL=0.017, BAYES_00=-2.599, SPF_PASS=-0.001, 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 GlnndkhzzcwY for ; Wed, 24 Nov 2010 15:53:29 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 632D528C15C for ; Wed, 24 Nov 2010 15:53:29 -0800 (PST) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oAONsQfP029299 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO) for ; Wed, 24 Nov 2010 17:54:27 -0600 (CST) (envelope-from adam@nostrum.com) Message-ID: <4CEDA5B2.9020806@nostrum.com> Date: Wed, 24 Nov 2010 17:54:26 -0600 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] IETF 79 Minutes X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Nov 2010 23:53:30 -0000 [as chair] I have posted preliminary minutes for the face-to-face meeting in Beijing: http://www.ietf.org/proceedings/79/minutes/sipcore.html Please review. Any feedback should be sent to the SIPCORE chairs. Thanks! /a From christer.holmberg@ericsson.com Wed Nov 24 22:47:28 2010 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 4FA6B3A6AA4 for ; Wed, 24 Nov 2010 22:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.521 X-Spam-Level: X-Spam-Status: No, score=-6.521 tagged_above=-999 required=5 tests=[AWL=0.078, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 1XM4t+NDEZHU for ; Wed, 24 Nov 2010 22:47:26 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id C1C473A6A63 for ; Wed, 24 Nov 2010 22:47:25 -0800 (PST) X-AuditID: c1b4fb3d-b7b8cae0000016b1-7e-4cee06b921a0 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 42.50.05809.9B60EEC4; Thu, 25 Nov 2010 07:48:25 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Thu, 25 Nov 2010 07:48:25 +0100 From: Christer Holmberg To: Paul Kyzivat Date: Thu, 25 Nov 2010 07:48:22 +0100 Thread-Topic: [sipcore] Reason as a parameter rather than an escaped header Thread-Index: AcuMKAzrkkMfuJMoTxWWEvjyd8VGKgARIZmw Message-ID: <7F2072F1E0DE894DA4B517B93C6A05850307DAE8@ESESSCMS0356.eemea.ericsson.se> References: <4CDC04F2.3010701@cisco.com> , <4CEC570D.8080700@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502C71884@ESESSCMS0356.eemea.ericsson.se> <4CED9370.5010001@cisco.com> In-Reply-To: <4CED9370.5010001@cisco.com> 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: AAAAAA== Cc: "Worley, Dale R \(Dale\)" , "sipcore@ietf.org" Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2010 06:47:28 -0000 Hi,=20 >>I think we should ask ourselves: assuming we allowed to do=20 >>what Marianne is proposing, would anything break? >> >>Does anyone really care whether a H-I entry was inserted=20 >>based on a "real" or "virtual" response? Aren't people more=20 >>interested in the actual reason value? >=20 >I don't currently see a problem with permitting this (though=20 >I'm interested to hear if somebody else sees an issue). >=20 >But IMO the current text doesn't suggest to me that this is valid. >So if the desire is for it to be valid it would be good to=20 >have some text that makes it so. I agree. We would need to add some text. Regards, Christer From HKaplan@acmepacket.com Thu Nov 25 03:56:05 2010 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 B0DF128C0F6 for ; Thu, 25 Nov 2010 03:56:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.103 X-Spam-Level: X-Spam-Status: No, score=-2.103 tagged_above=-999 required=5 tests=[AWL=0.496, BAYES_00=-2.599] 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 POQi9EIsLAJF for ; Thu, 25 Nov 2010 03:56:04 -0800 (PST) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id B98B528C0D8 for ; Thu, 25 Nov 2010 03:56:04 -0800 (PST) Received: from mail.acmepacket.com (216.41.24.7) by etmail.acmepacket.com (216.41.24.6) with Microsoft SMTP Server (TLS) id 8.2.254.0; Thu, 25 Nov 2010 06:57:05 -0500 Received: from mailbox1.acmepacket.com ([216.41.24.12]) by mail ([127.0.0.1]) with mapi; Thu, 25 Nov 2010 06:57:02 -0500 From: Hadriel Kaplan To: Paul Kyzivat Date: Thu, 25 Nov 2010 06:57:01 -0500 Thread-Topic: [sipcore] Reason as a parameter rather than an escaped header Thread-Index: AcuMl99FA/lF6V1FR3y5kQR+r7oSCA== Message-ID: <3A8FC9BC-3112-492A-87C2-3B5290A2D36D@acmepacket.com> References: <4CDC04F2.3010701@cisco.com> <4CEC570D.8080700@cisco.com> In-Reply-To: <4CEC570D.8080700@cisco.com> 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 Cc: "Worley, Dale R \(Dale\)" , "sipcore@ietf.org" Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2010 11:56:05 -0000 On Nov 23, 2010, at 7:06 PM, Paul Kyzivat wrote: > But my remaining concern is about the rules in 4244bis regarding how and= =20 > when Reason headers are included in the H-I entries. It still seems to=20 > me that the text only talks about including them due to a response=20 > having been received. Where is the language that discusses adding a=20 > reason when retargeting is performed for some reason unrelated to a=20 > response? >=20 > While I think one can argue that a server doing such retargeting can=20 > imagine having sent the request to a virtual redirect server and then=20 > processing the response from it, ISTM that would then call for adding=20 > H-I entries for those steps. Right, that's the main piece to figure out first. We already agreed that 4= 244bis tells proxies to create H-I entries for internal retargeting decisio= ns. What's not clear is what internal H-I entries have to be created, and = whether the embedded Reason header value of the *SIP* type can be used for = such cases. For example, suppose Alice called Bob, and proxy-1 internally diverts it to= Charlie because it knows Bob is busy, *without* having to send the INVITE = to Bob and getting a 486 response. Is it legit for the H-I look like this: History-Info: ;index=3D1 History-Info: ;index=3D1.1;mp=3D1 History-Info: ;index=3D1.1.1;rc=3D1.1 Or does it have to look like this: History-Info: ;index=3D1 History-Info: ;index=3D1.1 History-Info: ;index=3D1.2;mp=3D1 History-Info: ;index=3D1.2.1;rc=3D1.2 Or does it have to do something like this: History-Info: ;index= =3D1 History-Info: ;index=3D1.1;mp=3D1 History-Info: ;index=3D1.1.1;rc=3D1.1 -hadriel From marianne.mohali@orange-ftgroup.com Thu Nov 25 14:32:36 2010 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 B0C1B3A6A79 for ; Thu, 25 Nov 2010 14:32:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.886 X-Spam-Level: X-Spam-Status: No, score=-2.886 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_LOW=-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 ujo+9y4fDWmD for ; Thu, 25 Nov 2010 14:32:33 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (p-mail2.rd.francetelecom.com [195.101.245.16]) by core3.amsl.com (Postfix) with ESMTP id AA2763A69C1 for ; Thu, 25 Nov 2010 14:32:27 -0800 (PST) Received: from p-mail2.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id AF757778001; Thu, 25 Nov 2010 23:38:03 +0100 (CET) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by p-mail2.rd.francetelecom.com (Postfix) with ESMTP id 97016760002; Thu, 25 Nov 2010 23:38:03 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Nov 2010 23:33:29 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Nov 2010 23:33:25 +0100 Message-ID: In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850307DAE8@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Reason as a parameter rather than an escaped header Thread-Index: AcuMKAzrkkMfuJMoTxWWEvjyd8VGKgARIZmwACANjDA= References: <4CDC04F2.3010701@cisco.com>, <4CEC570D.8080700@cisco.com><7F2072F1E0DE894DA4B517B93C6A058502C71884@ESESSCMS0356.eemea.ericsson.se><4CED9370.5010001@cisco.com> <7F2072F1E0DE894DA4B517B93C6A05850307DAE8@ESESSCMS0356.eemea.ericsson.se> From: To: , X-OriginalArrivalTime: 25 Nov 2010 22:33:29.0692 (UTC) FILETIME=[C8AB99C0:01CB8CF0] Cc: dworley@avaya.com, sipcore@ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2010 22:32:37 -0000 Hi, I agree that draft-mohali-sipcore-reason-extension-application could = live independently of 4244bis, except for the section "Reason in the = History-Info header" that should still allow wat is proposed in = draft-reason. Note that RFC4244 is compatible with the draft-reason proposal: As work = on 4244bis was in progress, we based the draft on the following text = from RFC4244: "For retargets as a result of timeouts or internal events, = a Reason MAY be associated with the hi-targeted-to-uri that has been = retargeted." Unfortunately, this sentence disappeared and only the last sentence = about timeout suggests to insert a Reason for an internal process. =20 If there is no objection, we could put this text back in 4244bis to keep = explicit the ability to insert the Reason header field in a H-I entry = for *internal* reasons (with a MAY). =20 Regards, Marianne=20 > -----Message d'origine----- > De : sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] De la part de Christer Holmberg > Envoy=E9 : jeudi 25 novembre 2010 07:48 > =C0 : Paul Kyzivat > Cc : Worley, Dale R (Dale); sipcore@ietf.org > Objet : Re: [sipcore] Reason as a parameter rather than an=20 > escaped header >=20 >=20 > Hi,=20 >=20 > >>I think we should ask ourselves: assuming we allowed to do what=20 > >>Marianne is proposing, would anything break? > >> > >>Does anyone really care whether a H-I entry was inserted based on a=20 > >>"real" or "virtual" response? Aren't people more interested in the=20 > >>actual reason value? > >=20 > >I don't currently see a problem with permitting this (though I'm=20 > >interested to hear if somebody else sees an issue). > >=20 > >But IMO the current text doesn't suggest to me that this is valid. > >So if the desire is for it to be valid it would be good to have some=20 > >text that makes it so. >=20 > I agree. We would need to add some text. >=20 > Regards, >=20 > Christer >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From marianne.mohali@orange-ftgroup.com Thu Nov 25 14:47:22 2010 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 5F91C3A69C2 for ; Thu, 25 Nov 2010 14:47:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.249 X-Spam-Level: X-Spam-Status: No, score=-2.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35] 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 DdpyHN7eEh5a for ; Thu, 25 Nov 2010 14:47:21 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 4CCDB3A69BF for ; Thu, 25 Nov 2010 14:47:21 -0800 (PST) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id A9F996C0007; Thu, 25 Nov 2010 23:48:46 +0100 (CET) Received: from ftrdsmtp2.rd.francetelecom.fr (unknown [10.192.128.47]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 9E0D66C0002; Thu, 25 Nov 2010 23:48:46 +0100 (CET) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp2.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.4675); Thu, 25 Nov 2010 23:48:22 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Date: Thu, 25 Nov 2010 23:48:19 +0100 Message-ID: In-Reply-To: <3A8FC9BC-3112-492A-87C2-3B5290A2D36D@acmepacket.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Reason as a parameter rather than an escaped header Thread-Index: AcuMl99FA/lF6V1FR3y5kQR+r7oSCAAWVKMA References: <4CDC04F2.3010701@cisco.com><4CEC570D.8080700@cisco.com> <3A8FC9BC-3112-492A-87C2-3B5290A2D36D@acmepacket.com> From: To: , X-OriginalArrivalTime: 25 Nov 2010 22:48:22.0218 (UTC) FILETIME=[DCA842A0:01CB8CF2] Cc: dworley@avaya.com, sipcore@ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 25 Nov 2010 22:47:22 -0000 Hi, My adding [MM] Marianne > -----Message d'origine----- > De : sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] De la part de Hadriel Kaplan > Envoy=E9 : jeudi 25 novembre 2010 12:57 > =C0 : Paul Kyzivat > Cc : Worley, Dale R (Dale); sipcore@ietf.org > Objet : Re: [sipcore] Reason as a parameter rather than an=20 > escaped header >=20 >=20 > On Nov 23, 2010, at 7:06 PM, Paul Kyzivat wrote: >=20 > > But my remaining concern is about the rules in 4244bis=20 > regarding how=20 > > and when Reason headers are included in the H-I entries. It still=20 > > seems to me that the text only talks about including them due to a=20 > > response having been received. Where is the language that discusses=20 > > adding a reason when retargeting is performed for some reason=20 > > unrelated to a response? > >=20 > > While I think one can argue that a server doing such=20 > retargeting can=20 > > imagine having sent the request to a virtual redirect=20 > server and then=20 > > processing the response from it, ISTM that would then call=20 > for adding=20 > > H-I entries for those steps. >=20 > Right, that's the main piece to figure out first. We already=20 > agreed that 4244bis tells proxies to create H-I entries for=20 > internal retargeting decisions. What's not clear is what=20 > internal H-I entries have to be created, and whether the=20 > embedded Reason header value of the *SIP* type can be used=20 > for such cases. >=20 > For example, suppose Alice called Bob, and proxy-1 internally=20 > diverts it to Charlie because it knows Bob is busy, *without*=20 > having to send the INVITE to Bob and getting a 486 response. >=20 > Is it legit for the H-I look like this: > History-Info: = ;index=3D1 > History-Info: ;index=3D1.1;mp=3D1 > History-Info: ;index=3D1.1.1;rc=3D1.1 >=20 > Or does it have to look like this: > History-Info: ;index=3D1 > History-Info: = ;index=3D1.1 > History-Info: ;index=3D1.2;mp=3D1 > History-Info: ;index=3D1.2.1;rc=3D1.2 >=20 > Or does it have to do something like this: > History-Info:=20 > ;index=3D1 > History-Info: ;index=3D1.1;mp=3D1 > History-Info: ;index=3D1.1.1;rc=3D1.1 >=20 [MM] Or (as per 3GPP CDIV 24.604 for call forwarding busy) History-Info: ;index=3D1 History-Info: ;index=3D1.1;mp=3D1 History-Info: ;index=3D1.1.1;rc=3D1.1 > -hadriel >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From christer.holmberg@ericsson.com Thu Nov 25 23:30:02 2010 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 45F813A6A0B for ; Thu, 25 Nov 2010 23:30:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.075 X-Spam-Level: X-Spam-Status: No, score=-5.075 tagged_above=-999 required=5 tests=[AWL=-1.376, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, MANGLED_PILL=2.3, RCVD_IN_DNSWL_MED=-4] 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 DOAHxWTE5RtN for ; Thu, 25 Nov 2010 23:30:00 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 955DA3A695C for ; Thu, 25 Nov 2010 23:29:59 -0800 (PST) X-AuditID: c1b4fb39-b7c5aae000003b0f-5a-4cef6235913e Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 45.27.15119.5326FEC4; Fri, 26 Nov 2010 08:31:01 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Fri, 26 Nov 2010 08:31:00 +0100 From: Christer Holmberg To: Robert Sparks , SIPCORE Date: Fri, 26 Nov 2010 08:30:59 +0100 Thread-Topic: Security issue in -keep-08 Thread-Index: AcuLSRGPLIqZJaLvQqOi7v3m/yMeMAAjAw2gAFkjF5A= Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585030B1833@ESESSCMS0356.eemea.ericsson.se> References: <9D7CD9CF-4E47-41D1-8D01-F98808851223@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05850307D840@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A05850307D840@ESESSCMS0356.eemea.ericsson.se> 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: AAAAAA== Subject: Re: [sipcore] Security issue in -keep-08 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: Fri, 26 Nov 2010 07:30:02 -0000 Hi Robert, I suggest adding the following new paragraph to the security considerations= section: "In order to prevent attacks, when an entity sends STUN keep-alives to an a= djacent downstream entity that is not willing to receive keep-alives (or do= es not support STUN), but for which willingess to receive keep-alives has b= een inidicated by some other downstream entity, if the sending entity does = not receive a response to any of the STUN keep-alive requests, it MUST stop= =20 sending the keep-alive requests for the remaining duration of the dialog (i= f the sending of keep-alives were negotiated for a dialog) or until the sen= ding of keep-alives is re-negotiated for the registration (if the sending k= eep-alives were negotiated for a registration). Further actions taken by th= e sending entity is outside the scope of this specification." Regards, Christer > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg > Sent: 24. marraskuuta 2010 14:50 > To: Robert Sparks; SIPCORE > Subject: Re: [sipcore] Security issue in -keep-08 >=20 >=20 > Hi Robert, >=20 > Thanks for reviewing the document! >=20 > I guess the attack you describe could also happen in=20 > Outbound, if someone inserts an "ob" parameter in the Path=20 > header of the proxy adjacent to the UA, and that proxy does=20 > not check its Path header before forwarding the response to the UA. >=20 > Having said that, I guess a way to protect against this=20 > attack could be to say that an entity MUST stop sending STUN=20 > messages if it doesn't receive a response to them. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > =20 >=20 > > -----Original Message----- > > From: Robert Sparks [mailto:rjsparks@nostrum.com] > > Sent: 23. marraskuuta 2010 22:00 > > To: SIPCORE > > Cc: Christer Holmberg > > Subject: Security issue in -keep-08 > >=20 > > I believe there is a serious problem with the=20 > recommendations in the=20 > > Security Considerations section in keep-08 where it=20 > discusses having=20 > > downstream elements change the keep parameter. > >=20 > > Consider this scenario. A user agent implementing this=20 > specification=20 > > sends a request that goes through two proxies before it=20 > arrives at its=20 > > destination. The first proxy does not know about this=20 > specification.=20 > > The second proxy does, and chooses to attempt to maliciously affect=20 > > the relationship between UA1 and P1 as suggested in these security=20 > > considerations. > >=20 > > View the following flow in a fixed-width font: > >=20 > > UA1 P1 P2 UA2 > > | | | |=20 > > | INVITE | | | > > | Via: UA;keep | INVITE | | > > |------------------>| Via: P1 | |=20 > > | | Via: UA;keep | |=20 > > | |--------------->| | > > | | |----->|=20 > > | | | 200 | > > | | 200 |<-----| > > | | Via: P1 | | > > | 200 | Via: UA;keep=3D1 | | > > | Via: UA;keep=3D1 |<---------------| | > > |<------------------| | |=20 > > | | | |=20 > >=20 > >=20 > > Since P1 doesn't support this specification, it does not=20 > know to look=20 > > at "it's" Via to see if some downstream element has=20 > modified what it=20 > > would have put in the keep parameter value - the=20 > recommendation in the=20 > > current draft does not mitigate this attack at all. If the=20 > hop between=20 > > UA1 and P1 is UDP, this may result in STUN being send=20 > towards P1's SIP=20 > > listening port with P1 not expecting (or being able to deal=20 > with) it. > >=20 > > This is a general problem with attempting to use Via parameters to=20 > > indicate support for extensions. A similar problem exists=20 > for ;rport,=20 > > and for ;lr. However, if a downstream element abused those=20 > parameters,=20 > > signaling is guaranteed to fail. This proposed parameter has a=20 > > different property - this abuse may only result in extra=20 > traffic for=20 > > someone else. > >=20 > > I don't think this document is the right place to solve the general=20 > > problem, but this discussion needs to be rewritten to be=20 > clearer about=20 > > the problem and the lack of any current way to mitigate it. > >=20 > > RjS > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From christer.holmberg@ericsson.com Fri Nov 26 01:12:13 2010 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 12D983A6A59 for ; Fri, 26 Nov 2010 01:12:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.471 X-Spam-Level: X-Spam-Status: No, score=-6.471 tagged_above=-999 required=5 tests=[AWL=0.128, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 dyJiYnRORO+7 for ; Fri, 26 Nov 2010 01:12:12 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id B17213A6A7D for ; Fri, 26 Nov 2010 01:12:10 -0800 (PST) X-AuditID: c1b4fb3d-b7b8cae0000016b1-88-4cef7a28c0b7 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id F5.66.05809.82A7FEC4; Fri, 26 Nov 2010 10:13:13 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Fri, 26 Nov 2010 10:13:12 +0100 From: Christer Holmberg To: Robert Sparks , SIPCORE Date: Fri, 26 Nov 2010 10:13:11 +0100 Thread-Topic: AD review: draft-ietf-sipcore-keep-08 - example encoding Thread-Index: AcuLTVOcJ65h0amkTRmAnyyGNzH3WwAifNKQAFyUWGA= Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585030B1910@ESESSCMS0356.eemea.ericsson.se> References: <4892E0CC-52C7-4422-A5DA-C6A7553A4053@nostrum.com> <224F5CB1ECAB2C45BC64065AFD0339650406B5FC94@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <224F5CB1ECAB2C45BC64065AFD0339650406B5FC94@ESESSCMS0356.eemea.ericsson.se> 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: AAAAAA== Subject: Re: [sipcore] AD review: draft-ietf-sipcore-keep-08 - example encoding 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: Fri, 26 Nov 2010 09:12:13 -0000 =20 Hi Robert, ------- >>* All of the examples showing Via header fields use a shorthand,=20 >>pseudo-code style representation of the header field format.=20 >>It would be good to explicitly note that in the document. It would be=20 >>better to provide one example that was syntactically correct. >=20 >[CHH] I assume you mean that, instead of "Via:UAC" and=20 >"Via:P1" I would use something like "Via:uac.operator.com"=20 >and "Via:p1.operator.com"? >=20 >Personally I think it's more clear to use pseudo-style (as=20 >the example is not supposed to be teach-yourself-SIP), but I=20 >can change according to your suggestion. [CHH] I took a look at this. Using syntactically correct header fields woul= d make the example quite messy, due to the length of the header fields, so = my suggestion would be to instead add the following paragraph to the genera= l section of the examples: "NOTE: The examples do not show the actual syntactical encoding of the req= uest lines, response lines and the Via header fields, but rather a pseudo code in order to identity t= he message type and to=20 which entity a Via header field is associated." ------- Regards, Christer= From R.Jesske@telekom.de Fri Nov 26 04:05:44 2010 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 6D0F93A6AF8 for ; Fri, 26 Nov 2010 04:05:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.249 X-Spam-Level: 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 mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xbEgkKAo-3gy for ; Fri, 26 Nov 2010 04:05:43 -0800 (PST) Received: from tcmail33.telekom.de (tcmail33.telekom.de [194.25.30.7]) by core3.amsl.com (Postfix) with ESMTP id C9B653A6AC5 for ; Fri, 26 Nov 2010 04:05:42 -0800 (PST) Received: from he111629.emea1.cds.t-internal.com ([10.134.93.21]) by tcmail31.telekom.de with ESMTP/TLS/AES128-SHA; 26 Nov 2010 13:06:41 +0100 Received: from HE111648.emea1.cds.t-internal.com ([169.254.5.187]) by HE111629.emea1.cds.t-internal.com ([::1]) with mapi; Fri, 26 Nov 2010 13:06:41 +0100 From: To: , Date: Fri, 26 Nov 2010 13:06:40 +0100 Thread-Topic: Reason as a parameter rather than an escaped header Thread-Index: AcuBsSzQ68/6e0JSQK20l10bQRCF7AJkywTAAIdv8nA= Message-ID: <580BEA5E3B99744AB1F5BFF5E9A3C67D04DCB170@HE111648.emea1.cds.t-internal.com> References: , <4CDC04F2.3010701@cisco.com> In-Reply-To: Accept-Language: en-US, de-DE Content-Language: de-DE X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, de-DE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sipcore@ietf.org Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Nov 2010 12:05:44 -0000 Only to indicate that draft-jesske-dispatch-reason-in-responses-02 is in a = queue where I wait for an indication how to proceed. If it should be progre= ssed as an individual draft or as an WID in DISPATCH (or perhaps in SIPCORE= ). Roland > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] Im Auftrag von Worley, Dale R (Dale) > Gesendet: Dienstag, 23. November 2010 20:27 > An: Paul Kyzivat > Cc: sipcore@ietf.org > Betreff: Re: [sipcore] Reason as a parameter rather than an > escaped header > > From: Paul Kyzivat [pkyzivat@cisco.com] > > >> 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: ?Reason=3DSIP;cause=3D302, \ > > application;cause=3D2;text=3D"Freephone">;index=3D1, > ;index=3D1.1 > [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. > > Dale > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Fri Nov 26 15:07:54 2010 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 BD1DF28C122 for ; Fri, 26 Nov 2010 15:07:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.876 X-Spam-Level: X-Spam-Status: No, score=-5.876 tagged_above=-999 required=5 tests=[AWL=-0.477, BAYES_00=-2.599, J_CHICKENPOX_29=0.6, J_CHICKENPOX_39=0.6, RCVD_IN_DNSWL_MED=-4] 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 QJLjVDsc4OHG for ; Fri, 26 Nov 2010 15:07:53 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 0EC7828C114 for ; Fri, 26 Nov 2010 15:07:52 -0800 (PST) X-AuditID: c1b4fb39-b7c5aae000003b0f-68-4cf03e07afc3 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DF.C6.15119.70E30FC4; Sat, 27 Nov 2010 00:08:55 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Sat, 27 Nov 2010 00:08:54 +0100 From: Christer Holmberg To: Paul Kyzivat , "youssef.chadli@orange-ftgroup.com" Date: Sat, 27 Nov 2010 00:08:54 +0100 Thread-Topic: [sipcore] Bypassing out-of-service intermediate Proxy Thread-Index: AcuGucJgDasXXQisTj27OAMu8zhX2wHA82BU Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502C71893@ESESSCMS0356.eemea.ericsson.se> References: <9ECCF01B52E7AB408A7EB8535264214101CD7EE2@ftrdmel0.rd.francetelecom.fr><4C7FDBEE.6080305@nostrum.com>, <9ECCF01B52E7AB408A7EB85352642141020FD443@ftrdmel0.rd.francetelecom.fr> <9ECCF01B52E7AB408A7EB8535264214102155080@ftrdmel0.rd.francetelecom.fr> <4CD16A52.7090006@cisco.com> <9ECCF01B52E7AB408A7EB853526421410221B4E3@ftrdmel0.rd.francetelecom.fr> <4CD53DFC.8020401@cisco.com> <9ECCF01B52E7AB408A7EB85352642141022A9552@ftrdmel0.rd.francetelecom.fr>, <4CE476E2.70801@cisco.com> In-Reply-To: <4CE476E2.70801@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: AAAAAA== Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Bypassing out-of-service intermediate Proxy 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: Fri, 26 Nov 2010 23:07:55 -0000 Hi, >Well, if the server knows it can be skipped it could simply not >record-route. > >Or, as Dale suggested, it could record-route with a DNS name that >prefers to include it, but that names the predecessor as a lower >priority alternative. > >You are the first person I have ever heard ask for this functionality, >so I expect it would be a hard sell to add any new mechanism to the >specs to permit this in some other way. If you think it is important, >start trying to make a case for it. Not exactly the same case that Youssef is talking about, but every now and = then I have had discussions that it would be useful to be able to re-negoti= ate the route set (not only the local/remote targets, but also the record-r= outes) during a dialog. E.g. in Outbound cases it could be used to move ong= oing dialogs from a failed flow to another (it is not always possible to ac= hieve it by using domain names and DNS). A problem is of course backward compability, becuase you would need to ensu= re that every intermediary that wants to remain in the route set inserts Re= cord-Route in every re-INVITE/UPDATE (or whatever request is used to re-neg= otiate the route set). No, I did not suggest that we start work on such functionality :) Regards, Christer On 11/17/2010 1:01 AM, youssef.chadli@orange-ftgroup.com wrote: > >> How can the element doing the skipping know? In general it has no idea o= f the importance of an element in the route. >> Its at the time of insertion into the route that the importance is known= , so that is when such decisions should be made. > > I see two ways: at the moment of insertion into the Route, as you mention= ned, via a URI parameters ( the element which inserts itself into the Route= knows whether it's could be sikpped) or via a static configuration ( which= is of course less flexible solution) > > Best Regards, > > Youssef > > -----Message d'origine----- > De : Paul Kyzivat [mailto:pkyzivat@cisco.com] > Envoy=E9 : samedi 6 novembre 2010 12:38 > =C0 : CHADLI Youssef RD-CORE-ISS > Cc : sipcore@ietf.org > Objet : Re: [sipcore] Bypassing out-of-service intermediate Proxy > > > > On 11/5/2010 2:44 PM, youssef.chadli@orange-ftgroup.com wrote: >> >> I don't think this analogy is correct. >> >> If you take the example of a SIP Server which is inserted in the SIP pat= h only to provide a supplementary service in case this latter is requested = by the user ( e.g. call transfer), I think that the user will not be satisf= ied if it's call does not succeed just because the network is not able to p= rovide this service... > > Sure, the analogy *might* not always be correct, though it surely will be= correct in some / many cases. > > How can the element doing the skipping know? In general it has no idea of= the importance of an element in the route. > Its at the time of insertion into the route that the importance is known,= so that is when such decisions should be made. > > Thanks, > Paul >> >> Youssef >> >> -----Message d'origine----- >> De : sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] De la >> part de Paul Kyzivat Envoy=E9 : mercredi 3 novembre 2010 14:58 =C0 : >> sipcore@ietf.org Objet : Re: [sipcore] Bypassing out-of-service >> intermediate Proxy >> >> This idea seems analogous to the auto assembly line deciding to bypass >> the broken station where the engine is inserted into the car, and just >> send the car on to the next station without its engine. The consumer >> who receives this car may be less than satisfied. :-( >> >> Thanks, >> Paul >> >> On 11/3/2010 5:55 AM, youssef.chadli@orange-ftgroup.com wrote: >>> >>> I understand that the usage of DNS to provide alternate server is a way= to ensure redundancy. In such solution, to be able to handle SIP requests = inside a SIP dialog and for which the proxy need to be "dialog statefull", = there is a need to implement a mechanism that would allow the "alternate" s= erver to share the same SIP dialog contexts. >>> >>> My idea is in case of unavailability of the next hop and in case no >>> alternate server is returned by DNS (or alternate servers are >>> unreachable too), instead of rejecting the request (which would make >>> the call/session fails), the SIP Proxy may send it to the hop after >>> the unreachable one in the Route. This alternative would be >>> authorized only if the Proxy knows that it's better to bypass the >>> unreachable node instead of rejecting the request. The SIP proxy may >>> get this information via a URI parameter in the Route entry of the >>> "unreachable" node for example >>> >>> Best regards, >>> >>> Youssef >>> >>> -----Message d'origine----- >>> De : Worley, Dale R (Dale) [mailto:dworley@avaya.com] Envoy=E9 : >>> vendredi 29 octobre 2010 20:22 =C0 : CHADLI Youssef RD-CORE-ISS; >>> adam@nostrum.com Cc : sipcore@ietf.org Objet : RE: [sipcore] >>> Bypassing out-of-service intermediate Proxy >>> >>> ________________________________________ >>> From: sipcore-bounces@ietf.org [sipcore-bounces@ietf.org] On Behalf >>> Of youssef.chadli@orange-ftgroup.com >>> [youssef.chadli@orange-ftgroup.com] >>> >>> I understand that the intention of this text in RFC 3261 is to fail ove= r to an alternate server that serves the same function. Though, it's not ex= plicitly stated. >>> >>> However, I did not find any text in RFC 3261 that would make forbidden = failing over to a proxy further down the path. Moreover, I did not see any= problem to such behaviour. >>> ________________________________ >>> >>> If a particular URI is included in a Route header, then there is some i= mportant function the server with that URI is to perform. If one element i= gnores this URI and sends the request to the next URI in the Route header, = presumably the function of the skipped server will not be performed. >>> >>> In all cases that I have heard about, the correct way to provide altern= ate servers for a failed server is to construct a DNS SRV name which maps t= o the primary and alternate server as is desired. >>> >>> For instance, if functionA is to be serviced by serverA but in an emerg= ency the request can be routed to serverB, and if functionB is serviced by = serverB, then we construct two SRV names: >>> >>> functionA SRV serverA priority=3D1 >>> functionA SRV serverB priority=3D2 >>> >>> functionB SRV serverB priority=3D1 >>> >>> and use this Route header: >>> >>> Route: sip:functionA, sip:functionB >>> >>> If an element has a request with this Route header, it will send the re= quest to sp:functionA using the RFC 3263 rules, viz., attempt to send to se= rverA, and if that fails, attempt to send to serverB. >>> >>> Dale >>> _______________________________________________ >>> 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= From pkyzivat@cisco.com Sun Nov 28 18:19:24 2010 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 D4FEB3A6BE0 for ; Sun, 28 Nov 2010 18:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.487 X-Spam-Level: X-Spam-Status: No, score=-110.487 tagged_above=-999 required=5 tests=[AWL=0.112, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 dPcALmRIW05W for ; Sun, 28 Nov 2010 18:19:23 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id C11EE3A6BA3 for ; Sun, 28 Nov 2010 18:19:23 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANuc8kxAZnwM/2dsb2JhbACifHGmQpothUcEhFyGBYMP X-IronPort-AV: E=Sophos;i="4.59,274,1288569600"; d="scan'208";a="186686192" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 29 Nov 2010 02:20:29 +0000 Received: from [10.86.250.233] (bxb-vpn3-745.cisco.com [10.86.250.233]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id oAT2KSYl016170; Mon, 29 Nov 2010 02:20:28 GMT Message-ID: <4CF30DEC.1010204@cisco.com> Date: Sun, 28 Nov 2010 21:20:28 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: marianne.mohali@orange-ftgroup.com References: <4CDC04F2.3010701@cisco.com><4CEC570D.8080700@cisco.com> <3A8FC9BC-3112-492A-87C2-3B5290A2D36D@acmepacket.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit Cc: dworley@avaya.com, sipcore@ietf.org, HKaplan@acmepacket.com Subject: Re: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Nov 2010 02:19:24 -0000 I'm not especially particular about which of the various patterns of H-I entries are permitted - could be one or more of them, with discretion about what to include. (Though there could be merit in permitting omission of extra "virtual" entries that add no value.) But whatever it is, the draft should say *something* that is sufficient to determine if the usage chosen is valid or not. Thanks, Paul On 11/25/2010 5:48 PM, marianne.mohali@orange-ftgroup.com wrote: > > Hi, > > My adding [MM] > > Marianne > >> -----Message d'origine----- >> De : sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] De la part de Hadriel Kaplan >> Envoyé : jeudi 25 novembre 2010 12:57 >> À : Paul Kyzivat >> Cc : Worley, Dale R (Dale); sipcore@ietf.org >> Objet : Re: [sipcore] Reason as a parameter rather than an >> escaped header >> >> >> On Nov 23, 2010, at 7:06 PM, Paul Kyzivat wrote: >> >>> But my remaining concern is about the rules in 4244bis >> regarding how >>> and when Reason headers are included in the H-I entries. It still >>> seems to me that the text only talks about including them due to a >>> response having been received. Where is the language that discusses >>> adding a reason when retargeting is performed for some reason >>> unrelated to a response? >>> >>> While I think one can argue that a server doing such >> retargeting can >>> imagine having sent the request to a virtual redirect >> server and then >>> processing the response from it, ISTM that would then call >> for adding >>> H-I entries for those steps. >> >> Right, that's the main piece to figure out first. We already >> agreed that 4244bis tells proxies to create H-I entries for >> internal retargeting decisions. What's not clear is what >> internal H-I entries have to be created, and whether the >> embedded Reason header value of the *SIP* type can be used >> for such cases. >> >> For example, suppose Alice called Bob, and proxy-1 internally >> diverts it to Charlie because it knows Bob is busy, *without* >> having to send the INVITE to Bob and getting a 486 response. >> >> Is it legit for the H-I look like this: >> History-Info:;index=1 >> History-Info:;index=1.1;mp=1 >> History-Info:;index=1.1.1;rc=1.1 >> >> Or does it have to look like this: >> History-Info:;index=1 >> History-Info:;index=1.1 >> History-Info:;index=1.2;mp=1 >> History-Info:;index=1.2.1;rc=1.2 >> >> Or does it have to do something like this: >> History-Info: >> ;index=1 >> History-Info:;index=1.1;mp=1 >> History-Info:;index=1.1.1;rc=1.1 >> > [MM] Or (as per 3GPP CDIV 24.604 for call forwarding busy) > History-Info:;index=1 > History-Info:;index=1.1;mp=1 > History-Info:;index=1.1.1;rc=1.1 > >> -hadriel >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > From pkyzivat@cisco.com Sun Nov 28 18:55:33 2010 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 F2D713A6BAD for ; Sun, 28 Nov 2010 18:55:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.509 X-Spam-Level: X-Spam-Status: No, score=-110.509 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 88DBPR7yVKyX for ; Sun, 28 Nov 2010 18:55:32 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id 0B4333A6BAB for ; Sun, 28 Nov 2010 18:55:31 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAA6l8kxAZnwN/2dsb2JhbACifHGmSpouhUcEhFyGBYMP X-IronPort-AV: E=Sophos;i="4.59,274,1288569600"; d="scan'208";a="186696714" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 29 Nov 2010 02:56:40 +0000 Received: from [10.86.250.233] (bxb-vpn3-745.cisco.com [10.86.250.233]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oAT2ue2o015624; Mon, 29 Nov 2010 02:56:40 GMT Message-ID: <4CF31667.60601@cisco.com> Date: Sun, 28 Nov 2010 21:56:39 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Christer Holmberg References: <9ECCF01B52E7AB408A7EB8535264214101CD7EE2@ftrdmel0.rd.francetelecom.fr><4C7FDBEE.6080305@nostrum.com>, <9ECCF01B52E7AB408A7EB85352642141020FD443@ftrdmel0.rd.francetelecom.fr> <9ECCF01B52E7AB408A7EB8535264214102155080@ftrdmel0.rd.francetelecom.fr> <4CD16A52.7090006@cisco.com> <9ECCF01B52E7AB408A7EB853526421410221B4E3@ftrdmel0.rd.francetelecom.fr> <4CD53DFC.8020401@cisco.com> <9ECCF01B52E7AB408A7EB85352642141022A9552@ftrdmel0.rd.francetelecom.fr>, <4CE476E2.70801@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502C71893@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502C71893@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" , "youssef.chadli@orange-ftgroup.com" Subject: Re: [sipcore] Bypassing out-of-service intermediate Proxy 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, 29 Nov 2010 02:55:33 -0000 On 11/26/2010 6:08 PM, Christer Holmberg wrote: > Not exactly the same case that Youssef is talking about, but every now and then I have had discussions that it would be useful to be able to re-negotiate the route set (not only the local/remote targets, but also the record-routes) during a dialog. E.g. in Outbound cases it could be used to move ongoing dialogs from a failed flow to another (it is not always possible to achieve it by using domain names and DNS). > > A problem is of course backward compability, becuase you would need to ensure that every intermediary that wants to remain in the route set inserts Record-Route in every re-INVITE/UPDATE (or whatever request is used to re-negotiate the route set). > > No, I did not suggest that we start work on such functionality :) We already have a way to do that: INVITE with Replaces. Thanks, Paul From christer.holmberg@ericsson.com Sun Nov 28 22:45:24 2010 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 5FC343A6BF9 for ; Sun, 28 Nov 2010 22:45:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.463 X-Spam-Level: X-Spam-Status: No, score=-6.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 vhvARSgZmse2 for ; Sun, 28 Nov 2010 22:45:08 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 45BA03A6BFC for ; Sun, 28 Nov 2010 22:45:07 -0800 (PST) X-AuditID: c1b4fb3d-b7b8cae0000016b1-95-4cf34c37b1a8 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 17.4E.05809.73C43FC4; Mon, 29 Nov 2010 07:46:15 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Mon, 29 Nov 2010 07:46:15 +0100 From: Christer Holmberg To: Paul Kyzivat Date: Mon, 29 Nov 2010 07:42:54 +0100 Thread-Topic: [sipcore] Bypassing out-of-service intermediate Proxy Thread-Index: AcuPcQ2LO/H5UYixQPOKlQtg+raSVgAH5kno Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502C7189A@ESESSCMS0356.eemea.ericsson.se> References: <9ECCF01B52E7AB408A7EB8535264214101CD7EE2@ftrdmel0.rd.francetelecom.fr><4C7FDBEE.6080305@nostrum.com>, <9ECCF01B52E7AB408A7EB85352642141020FD443@ftrdmel0.rd.francetelecom.fr> <9ECCF01B52E7AB408A7EB8535264214102155080@ftrdmel0.rd.francetelecom.fr> <4CD16A52.7090006@cisco.com> <9ECCF01B52E7AB408A7EB853526421410221B4E3@ftrdmel0.rd.francetelecom.fr> <4CD53DFC.8020401@cisco.com> <9ECCF01B52E7AB408A7EB85352642141022A9552@ftrdmel0.rd.francetelecom.fr>, <4CE476E2.70801@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502C71893@ESESSCMS0356.eemea.ericsson.se>, <4CF31667.60601@cisco.com> In-Reply-To: <4CF31667.60601@cisco.com> 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: AAAAAA== Cc: "sipcore@ietf.org" , "youssef.chadli@orange-ftgroup.com" Subject: Re: [sipcore] Bypassing out-of-service intermediate Proxy 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, 29 Nov 2010 06:45:24 -0000 Hi, >>Not exactly the same case that Youssef is talking about, but every now an= d then I have had discussions that=20 >>it would be useful to be able to re-negotiate the route set (not only the= local/remote targets, but also the=20 >>record-routes) during a dialog. E.g. in Outbound cases it could be used t= o move ongoing dialogs from a=20 >>failed flow to another (it is not always possible to achieve it by using = domain names and DNS). >> >>A problem is of course backward compability, becuase you would need to en= sure that every intermediary=20 >>that wants to remain in the route set inserts Record-Route in every re-IN= VITE/UPDATE (or whatever=20 >>request is used to re-negotiate the route set). >> >>No, I did not suggest that we start work on such functionality :) > >We already have a way to do that: INVITE with Replaces. Sure, but that requires the establishment of a new session.=20 Because I don't think it's allowd to send a re-INVITE, in order for a sessi= on to replace "itself", is it? Regards, Christer= From pkyzivat@cisco.com Mon Nov 29 04:30:34 2010 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 AF9953A6AC6 for ; Mon, 29 Nov 2010 04:30:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -110.517 X-Spam-Level: X-Spam-Status: No, score=-110.517 tagged_above=-999 required=5 tests=[AWL=0.082, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, 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 NMFbHWfKZUpI for ; Mon, 29 Nov 2010 04:30:33 -0800 (PST) Received: from rtp-iport-1.cisco.com (rtp-iport-1.cisco.com [64.102.122.148]) by core3.amsl.com (Postfix) with ESMTP id B78B83A6AB3 for ; Mon, 29 Nov 2010 04:30:32 -0800 (PST) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAA8s80xAZnwN/2dsb2JhbACifnGnLJpohUcEhFyGBYMP X-IronPort-AV: E=Sophos;i="4.59,276,1288569600"; d="scan'208";a="186819591" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 29 Nov 2010 12:31:41 +0000 Received: from [10.86.250.233] (bxb-vpn3-745.cisco.com [10.86.250.233]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id oATCVew0008483; Mon, 29 Nov 2010 12:31:41 GMT Message-ID: <4CF39D2C.7040007@cisco.com> Date: Mon, 29 Nov 2010 07:31:40 -0500 From: Paul Kyzivat User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Thunderbird/3.1.6 MIME-Version: 1.0 To: Christer Holmberg References: <9ECCF01B52E7AB408A7EB8535264214101CD7EE2@ftrdmel0.rd.francetelecom.fr><4C7FDBEE.6080305@nostrum.com>, <9ECCF01B52E7AB408A7EB85352642141020FD443@ftrdmel0.rd.francetelecom.fr> <9ECCF01B52E7AB408A7EB8535264214102155080@ftrdmel0.rd.francetelecom.fr> <4CD16A52.7090006@cisco.com> <9ECCF01B52E7AB408A7EB853526421410221B4E3@ftrdmel0.rd.francetelecom.fr> <4CD53DFC.8020401@cisco.com> <9ECCF01B52E7AB408A7EB85352642141022A9552@ftrdmel0.rd.francetelecom.fr>, <4CE476E2.70801@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502C71893@ESESSCMS0356.eemea.ericsson.se>, <4CF31667.60601@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502C7189A@ESESSCMS0356.eemea.ericsson.se> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502C7189A@ESESSCMS0356.eemea.ericsson.se> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" , "youssef.chadli@orange-ftgroup.com" Subject: Re: [sipcore] Bypassing out-of-service intermediate Proxy 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, 29 Nov 2010 12:30:35 -0000 On 11/29/2010 1:42 AM, Christer Holmberg wrote: > Hi, > >>> Not exactly the same case that Youssef is talking about, but every now and then I have had discussions that >>> it would be useful to be able to re-negotiate the route set (not only the local/remote targets, but also the >>> record-routes) during a dialog. E.g. in Outbound cases it could be used to move ongoing dialogs from a >>> failed flow to another (it is not always possible to achieve it by using domain names and DNS). >>> >>> A problem is of course backward compability, becuase you would need to ensure that every intermediary >>> that wants to remain in the route set inserts Record-Route in every re-INVITE/UPDATE (or whatever >>> request is used to re-negotiate the route set). >>> >>> No, I did not suggest that we start work on such functionality :) >> >> We already have a way to do that: INVITE with Replaces. > > Sure, but that requires the establishment of a new session. > > Because I don't think it's allowd to send a re-INVITE, in order for a session to replace "itself", is it? Yes, it requires establishment of a new session. But the new session could be identical to the old one. (E.g. the exact same media addresses, ports, and formats could be offered.) Thanks, Paul From christer.holmberg@ericsson.com Mon Nov 29 04:52:20 2010 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 13C613A6BC5 for ; Mon, 29 Nov 2010 04:52:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.468 X-Spam-Level: X-Spam-Status: No, score=-6.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 YtGG5x56z6Pf for ; Mon, 29 Nov 2010 04:52:19 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id EE7833A6A1A for ; Mon, 29 Nov 2010 04:52:18 -0800 (PST) X-AuditID: c1b4fb39-b7bafae000002a42-58-4cf3a2470e46 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 94.8F.10818.742A3FC4; Mon, 29 Nov 2010 13:53:27 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0256.eemea.ericsson.se ([10.2.3.125]) with mapi; Mon, 29 Nov 2010 13:53:26 +0100 From: Christer Holmberg To: Paul Kyzivat Date: Mon, 29 Nov 2010 13:53:26 +0100 Thread-Topic: [sipcore] Bypassing out-of-service intermediate Proxy Thread-Index: AcuPwWGQ1SLPbHR9Tq+gABwevxfoxgAAqzGA Message-ID: <7F2072F1E0DE894DA4B517B93C6A0585030B21EB@ESESSCMS0356.eemea.ericsson.se> References: <9ECCF01B52E7AB408A7EB8535264214101CD7EE2@ftrdmel0.rd.francetelecom.fr><4C7FDBEE.6080305@nostrum.com>, <9ECCF01B52E7AB408A7EB85352642141020FD443@ftrdmel0.rd.francetelecom.fr> <9ECCF01B52E7AB408A7EB8535264214102155080@ftrdmel0.rd.francetelecom.fr> <4CD16A52.7090006@cisco.com> <9ECCF01B52E7AB408A7EB853526421410221B4E3@ftrdmel0.rd.francetelecom.fr> <4CD53DFC.8020401@cisco.com> <9ECCF01B52E7AB408A7EB85352642141022A9552@ftrdmel0.rd.francetelecom.fr>, <4CE476E2.70801@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502C71893@ESESSCMS0356.eemea.ericsson.se>, <4CF31667.60601@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502C7189A@ESESSCMS0356.eemea.ericsson.se> <4CF39D2C.7040007@cisco.com> In-Reply-To: <4CF39D2C.7040007@cisco.com> 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: AAAAAA== Cc: "sipcore@ietf.org" , "youssef.chadli@orange-ftgroup.com" Subject: Re: [sipcore] Bypassing out-of-service intermediate Proxy 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, 29 Nov 2010 12:52:20 -0000 Hi,=20 >>>>Not exactly the same case that Youssef is talking about,=20 >>>>but every now and then I have had discussions that it would be useful t= o be=20 >>>>able to re-negotiate the route set (not only the local/remote=20 >>>>targets, but also the record-routes) during a dialog. E.g. in Outbound = cases it=20 >>>>could be used to move ongoing dialogs from a failed flow to=20 >>>>another (it is not always possible to achieve it by using=20 >>>>domain names and DNS). >>>> >>>>A problem is of course backward compability, becuase you would need=20 >>>>to ensure that every intermediary that wants to remain in the route=20 >>>>set inserts Record-Route in every re-INVITE/UPDATE (or=20 >>>>whatever request is used to re-negotiate the route set). >>>> >>>>No, I did not suggest that we start work on such functionality :) >>> >>>We already have a way to do that: INVITE with Replaces. >> >>Sure, but that requires the establishment of a new session. >> >>Because I don't think it's allowd to send a re-INVITE, in=20 >>order for a session to replace "itself", is it? >=20 >Yes, it requires establishment of a new session. But the new=20 >session could be identical to the old one. (E.g. the exact=20 >same media addresses, ports, and formats could be offered.) I guess it would be useful to e.g. have a response code which would trigger= the new INVITE, so that it doesn't have to be done by a B2BUA in the netwo= rk. For example, if a registrar detects that it cannot forward a mid-session re= quest on an outbound flow, it could send an error response back to the UA i= n order to trigger a new INVITE, which would then be forwarded on another o= utbound flow. Regards, Christer From rjsparks@nostrum.com Mon Nov 29 08:11:03 2010 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 892C128C0EF for ; Mon, 29 Nov 2010 08:11:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.842 X-Spam-Level: X-Spam-Status: No, score=-100.842 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FR_3TAG_3TAG=1.758, SPF_PASS=-0.001, 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 ePfMm6fY8K1x for ; Mon, 29 Nov 2010 08:11:02 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id EA8233A6BCC for ; Mon, 29 Nov 2010 08:11:00 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oATGC6MA062506 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Nov 2010 10:12:07 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: <224F5CB1ECAB2C45BC64065AFD0339650406B5FC94@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 29 Nov 2010 10:12:05 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4892E0CC-52C7-4422-A5DA-C6A7553A4053@nostrum.com> <224F5CB1ECAB2C45BC64065AFD0339650406B5FC94@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] AD review: draft-ietf-sipcore-keep-08 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, 29 Nov 2010 16:11:03 -0000 On Nov 24, 2010, at 1:19 PM, Christer Holmberg wrote: >=20 > Hi Robert, >=20 > Comments inline ([CHH]) >=20 >> Summary: Revised ID needed >>=20 >> The text needs to be adjusted to reflect the security issue I=20 >> called out in a separate message to the list today. >> During that adjustment, there are a few other places to=20 >> consider making changes: >=20 > [CHH] See other thread. >=20 > ------ >=20 >> * Section 4.4, second paragraph "The parameter can contain"=20 >> is confusing - it could be read to imply that the parameter=20 >> can contain other things as well. I suggest rewriting this=20 >> sentence as "The parameter value, if present, represents a=20 >> recommended keep-alive frequency..." >=20 > [CHH] Done. >=20 > "The parameter value, if present and with a value other than zero, = represents a recommended keep-alive frequency, given in seconds." >=20 >=20 > ------- >=20 >> * The document talks about invoking keep for INVITE initiated=20 >> dialogs, but not about SUBSCRIBE initiated dialogs. Was it the=20 >> intent to not allow the use of the mechanism for SUBSCRIBE initiated=20= >> dialogs? >=20 > [CHH] The intent was to allow it for INVITE initiaded dialogs. >=20 > I can't remember any technical reasons why keep could not be applied = also to SUB dialogs. Nobody has ever requested it, however. >=20 >=20 > ------- >=20 >> * Section 4.4 talks about normative server behavior for using=20 >> this mechanism with INVITE initiated dialogs. >> where is the companion set of normative requirements for=20 >> using the mechanism to keep alive a REGISTRATION >> flow? >=20 > [CHH] The 2nd paragraph is the generic rule, which covers both INVITE = and REGISTER. >=20 > The 3rd paragraph is an addition that covers the case where multiple = responses are sent to a request, which is INVITE specific. >=20 > But, maybe to make it more clear, and based on your comment on section = 5 (see further down), I could rewrite the 3rd paragraph: >=20 > "There might be multiple responses to an INVITE request. > When a SIP entity indicates willingness to receive keep-alives in a > response to an INVITE request, it MUST add a parameter value to the=20 > "keep" parameter in at least one reliable response to the request. The = SIP entity MAY > add identical parameter values to the "keep" parameters in other = responses to the > same request. The SIP entity MUST NOT add different parameter value = to the "keep"=20 > parameters in responses to the same request. The SIP entity SHOULD = indicate=20 > the willingness to receive keep-alives as soon as possible." This text is better, but it uncovers another issue. For these = keep-alives associated with a dialog, you need to adjust the text to reflect responses _in that = dialog_. In the presence of forking, you may have multiple 183s from different branches (or = multiple 200 OKs from different branches. If the keep-alive activity is intended to be = associated with the dialogs (which is what I think the text is currently trying to do), you need to = adjust to note that the element needs to include its keep value as early as possible on each = dialog, and note that the keep-alive messages will be sent reflecting each dialog that was set = up. An alternative is to negotiate one keepalive stream per 5-tuple, using a = reference count (you stop when the last dialog using the 5-tuple terminates), but that = seems pretty error-prone. >=20 >=20 > The same editorial change would also be done in section 3: >=20 > ""keep" parameter: A SIP Via header field parameter that a SIP entity > can insert in its Via header field of a request to explicitly > indicate willingness to send keep-alives towards its adjacent > downstream SIP entity. A SIP entity can add a parameter value to=20 > the "keep" parameter in a response to explicitly indicate willingness = to=20 > receive keep-alives from its adjacent upstream SIP entity." >=20 > -------=20 >=20 >> * In several places, the document refers to an element=20 >> inspecting "its" Via header. This is imprecise and will >> lead to arguments among implementers. I suggest=20 >> explicitly calling out "the topmost Via header field value" >> and being very specific about when you are talking about a=20 >> message being received or a message being sent. >=20 > [CHH] I will look into that. >=20 > ------- >=20 >> * In section 5's fourth paragraph, it would help avoid=20 >> confusion to say "adds a value the a 'keep' parameter to >> indicate willingness" instead of "uses the 'keep' parameter...". >=20 > [CHH] Done. >=20 > "If a SIP entity that adds a parameter value to the "keep" parameter, = in order to indicate willingness to receive keep-alives, also = inserts..." >=20 > ------- >=20 >> *In the last sentence of Section 5 - what value is "without=20 >> forcing entities to re-write the value of Flow-Timer header=20 >> field" adding? I suggest deleting the phrase. >=20 > [CHH] Done. >=20 > ------- >=20 >> * Section 6's first paragraph says "Entities that want to=20 >> reuse connections MUST use a another mechanism". >> (Note the spurious 'a'). Why is this a 2119 MUST? I=20 >> suggest saying "would need to" instead. >=20 > [CHH] Done.=20 >=20 > The reason behind the "MUST" was to clearly indicate that keep as such = is not a connection reuse mechanism. That's an incorrect use of the 2119 term.=20 I can't test implementation of that requirement - there's no way to = account for it in an interoperability report, and there's no good reference to what an implementer would need to read in order to = satisfy the requirement. You are really just trying to say this mechanism doesn't provide connection reuse. Just say = that. >=20 > ------- >=20 >> * The first sentence in 7.4 would be better if it said Figure=20 >> 3 instead of "The figure". The end of the first >> paragraph has a spurious period. >=20 > [CHH] Done. >=20 > ------- >=20 >> * All of the examples showing Via header fields use a=20 >> shorthand, pseudo-code style representation of the >> header field format. It would be good to explicitly note=20 >> that in the document. It would be better to provide >> one example that was syntactically correct. >=20 > [CHH] I assume you mean that, instead of "Via:UAC" and "Via:P1" I = would use something like "Via:uac.operator.com" and = "Via:p1.operator.com"? >=20 > Personally I think it's more clear to use pseudo-style (as the example = is not supposed to be teach-yourself-SIP), but I can change according to = your suggestion. I'll respond to this through your followup message. >=20 > ------- >=20 >> * In Section 10's section paragraph. I suggest that you be=20 >> explicit that you are talking about hop-by-hop >> integrity protection (calling out TLS or DTLS), to avoid=20 >> confusion with end-to-end integrity protection >> mechanisms (S/MIME) which will not help this case. >=20 > [CHH] I suggest the follwoing change (): >=20 > "Unless SIP messages are integrity protected hop-by-hop (e.g. = using TLS or DTLS),=20 > a man-in-the-middle can modify Via header fields...." >=20 > ------- >=20 >> * In section 10's third paragraph, you call out "(at high=20 >> rates)". This is potentially misleading - the rates >> are at the highest somewhere just under once a second. I=20 >> suggest replacing "(at high rates)" with >> "(up to approximately once a second)". >=20 > [CHH] Done. >=20 > ------- >=20 > Thank You for reviewing the document! >=20 > Regards, >=20 > Christer From rjsparks@nostrum.com Mon Nov 29 08:17:00 2010 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 6749C28C0EF for ; Mon, 29 Nov 2010 08:17:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.721 X-Spam-Level: X-Spam-Status: No, score=-101.721 tagged_above=-999 required=5 tests=[AWL=0.879, BAYES_00=-2.599, SPF_PASS=-0.001, 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 xLtY0BpQnfnB for ; Mon, 29 Nov 2010 08:16:59 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id CBAF23A6BCC for ; Mon, 29 Nov 2010 08:16:58 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oATGHspk062980 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Nov 2010 10:17:54 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585030B1910@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 29 Nov 2010 10:17:54 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <941257A2-81B6-4EB2-A8ED-5E6E13B183A6@nostrum.com> References: <4892E0CC-52C7-4422-A5DA-C6A7553A4053@nostrum.com> <224F5CB1ECAB2C45BC64065AFD0339650406B5FC94@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585030B1910@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] AD review: draft-ietf-sipcore-keep-08 - example encoding 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, 29 Nov 2010 16:17:00 -0000 I didn't intend for you to modify the existing examples. The Note is = good. But I suggest you _add_ a single instance of a Via header field that is = syntactically correct near the beginning of the document as an explanatory figure. Something like: Topmost Via header field value in a request: Via: SIP/2.0/UDP pc33.example.com;branch=3Dz9hG4bK776asdhds;keep;rport Topmost Via header field value in an associated response: Via : SIP/2.0/UDP = pc33.example.com;received=3D192.0.2.2;rport=3D18250;keep=3D20;branch=3Dz9h= G4bK776asdhds RjS On Nov 26, 2010, at 3:13 AM, Christer Holmberg wrote: >=20 > Hi Robert, >=20 > ------- >=20 >>> * All of the examples showing Via header fields use a shorthand,=20 >>> pseudo-code style representation of the header field format.=20 >>> It would be good to explicitly note that in the document. It would = be=20 >>> better to provide one example that was syntactically correct. >>=20 >> [CHH] I assume you mean that, instead of "Via:UAC" and=20 >> "Via:P1" I would use something like "Via:uac.operator.com"=20 >> and "Via:p1.operator.com"? >>=20 >> Personally I think it's more clear to use pseudo-style (as=20 >> the example is not supposed to be teach-yourself-SIP), but I=20 >> can change according to your suggestion. >=20 > [CHH] I took a look at this. Using syntactically correct header fields = would make the example quite messy, due to the length of the header = fields, so my suggestion would be to instead add the following paragraph = to the general section of the examples: >=20 > "NOTE: The examples do not show the actual syntactical encoding = of the request lines, response lines > and the Via header fields, but rather a pseudo code in order to = identity the message type and to=20 > which entity a Via header field is associated." >=20 > ------- >=20 > Regards, >=20 > Christer From rjsparks@nostrum.com Mon Nov 29 08:23:42 2010 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 010E028C143 for ; Mon, 29 Nov 2010 08:23:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.711 X-Spam-Level: X-Spam-Status: No, score=-100.711 tagged_above=-999 required=5 tests=[AWL=-1.010, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, MANGLED_PILL=2.3, SPF_PASS=-0.001, 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 e6fh0Wrqu+oZ for ; Mon, 29 Nov 2010 08:23:41 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id 25FAC3A6C1D for ; Mon, 29 Nov 2010 08:23:39 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oATGOkvK063472 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Nov 2010 10:24:46 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A0585030B1833@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 29 Nov 2010 10:24:45 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <02688FBA-D5B4-403E-944E-FB9245936F36@nostrum.com> References: <9D7CD9CF-4E47-41D1-8D01-F98808851223@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05850307D840@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585030B1833@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Security issue in -keep-08 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, 29 Nov 2010 16:23:42 -0000 I don't object to the direction this text is taking, but it doesn't = _prevent_ attacks. It only mitigates the damage, and it assumes the attacked element doesn't just break when it gets the first STUN message = on its SIP listening port. On Nov 26, 2010, at 1:30 AM, Christer Holmberg wrote: >=20 > Hi Robert, >=20 > I suggest adding the following new paragraph to the security = considerations section: >=20 > "In order to prevent attacks, when an entity sends STUN keep-alives to = an adjacent downstream entity that is not willing to receive keep-alives = (or does not support STUN), but for which willingess to receive = keep-alives has been inidicated by some other downstream entity, if the = sending entity does not receive a response to any of the STUN keep-alive = requests, it MUST stop=20 > sending the keep-alive requests for the remaining duration of the = dialog (if the sending of keep-alives were negotiated for a dialog) or = until the sending of keep-alives is re-negotiated for the registration = (if the sending keep-alives were negotiated for a registration). Further = actions taken by the sending entity is outside the scope of this = specification." >=20 > Regards, >=20 > Christer >=20 >> -----Original Message----- >> From: sipcore-bounces@ietf.org=20 >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: 24. marraskuuta 2010 14:50 >> To: Robert Sparks; SIPCORE >> Subject: Re: [sipcore] Security issue in -keep-08 >>=20 >>=20 >> Hi Robert, >>=20 >> Thanks for reviewing the document! >>=20 >> I guess the attack you describe could also happen in=20 >> Outbound, if someone inserts an "ob" parameter in the Path=20 >> header of the proxy adjacent to the UA, and that proxy does=20 >> not check its Path header before forwarding the response to the UA. >>=20 >> Having said that, I guess a way to protect against this=20 >> attack could be to say that an entity MUST stop sending STUN=20 >> messages if it doesn't receive a response to them. >>=20 >> Regards, >>=20 >> Christer >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >>> -----Original Message----- >>> From: Robert Sparks [mailto:rjsparks@nostrum.com] >>> Sent: 23. marraskuuta 2010 22:00 >>> To: SIPCORE >>> Cc: Christer Holmberg >>> Subject: Security issue in -keep-08 >>>=20 >>> I believe there is a serious problem with the=20 >> recommendations in the=20 >>> Security Considerations section in keep-08 where it=20 >> discusses having=20 >>> downstream elements change the keep parameter. >>>=20 >>> Consider this scenario. A user agent implementing this=20 >> specification=20 >>> sends a request that goes through two proxies before it=20 >> arrives at its=20 >>> destination. The first proxy does not know about this=20 >> specification.=20 >>> The second proxy does, and chooses to attempt to maliciously affect=20= >>> the relationship between UA1 and P1 as suggested in these security=20= >>> considerations. >>>=20 >>> View the following flow in a fixed-width font: >>>=20 >>> UA1 P1 P2 UA2 >>> | | | |=20 >>> | INVITE | | | >>> | Via: UA;keep | INVITE | | >>> |------------------>| Via: P1 | |=20 >>> | | Via: UA;keep | |=20 >>> | |--------------->| | >>> | | |----->|=20 >>> | | | 200 | >>> | | 200 |<-----| >>> | | Via: P1 | | >>> | 200 | Via: UA;keep=3D1 | | >>> | Via: UA;keep=3D1 |<---------------| | >>> |<------------------| | |=20 >>> | | | |=20 >>>=20 >>>=20 >>> Since P1 doesn't support this specification, it does not=20 >> know to look=20 >>> at "it's" Via to see if some downstream element has=20 >> modified what it=20 >>> would have put in the keep parameter value - the=20 >> recommendation in the=20 >>> current draft does not mitigate this attack at all. If the=20 >> hop between=20 >>> UA1 and P1 is UDP, this may result in STUN being send=20 >> towards P1's SIP=20 >>> listening port with P1 not expecting (or being able to deal=20 >> with) it. >>>=20 >>> This is a general problem with attempting to use Via parameters to=20= >>> indicate support for extensions. A similar problem exists=20 >> for ;rport,=20 >>> and for ;lr. However, if a downstream element abused those=20 >> parameters,=20 >>> signaling is guaranteed to fail. This proposed parameter has a=20 >>> different property - this abuse may only result in extra=20 >> traffic for=20 >>> someone else. >>>=20 >>> I don't think this document is the right place to solve the general=20= >>> problem, but this discussion needs to be rewritten to be=20 >> clearer about=20 >>> the problem and the lack of any current way to mitigate it. >>>=20 >>> RjS >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >>=20 From christer.holmberg@ericsson.com Mon Nov 29 12:22:16 2010 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 E02C328C0F7 for ; Mon, 29 Nov 2010 12:22:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.022 X-Spam-Level: X-Spam-Status: No, score=-5.022 tagged_above=-999 required=5 tests=[AWL=-1.323, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, MANGLED_PILL=2.3, RCVD_IN_DNSWL_MED=-4] 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 bwG4BXqb+05C for ; Mon, 29 Nov 2010 12:22:15 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 2351D28C0F5 for ; Mon, 29 Nov 2010 12:22:14 -0800 (PST) X-AuditID: c1b4fb39-b7bafae000002a42-32-4cf40bbc79ba Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id FA.99.10818.CBB04FC4; Mon, 29 Nov 2010 21:23:24 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0247.eemea.ericsson.se ([10.2.3.116]) with mapi; Mon, 29 Nov 2010 21:23:24 +0100 From: Christer Holmberg To: Robert Sparks Date: Mon, 29 Nov 2010 21:23:23 +0100 Thread-Topic: Security issue in -keep-08 Thread-Index: AcuP4fFOIcnN9VOqTXGGkm0f0IR01AAIAuZl Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502C718A9@ESESSCMS0356.eemea.ericsson.se> References: <9D7CD9CF-4E47-41D1-8D01-F98808851223@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05850307D840@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585030B1833@ESESSCMS0356.eemea.ericsson.se>, <02688FBA-D5B4-403E-944E-FB9245936F36@nostrum.com> In-Reply-To: <02688FBA-D5B4-403E-944E-FB9245936F36@nostrum.com> 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: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Security issue in -keep-08 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, 29 Nov 2010 20:22:17 -0000 Hi, >I don't object to the direction this text is taking, but it doesn't _preve= nt_ attacks. It only mitigates the damage, >and it assumes the attacked ele= ment doesn't just break when it gets the first STUN message on its SIP=20 >listening port. Well, if it breaks from a single STUN mesage I think there is going to be t= rouble sooner or later anyway, because nothing prevents entities from sendi= ng STUN messages (or whatever data) to the listening port even if keep supp= ort is not indicated. I have no idea what I could write in order to prevent the attack from happe= ning. Regards, Christer On Nov 26, 2010, at 1:30 AM, Christer Holmberg wrote: > > Hi Robert, > > I suggest adding the following new paragraph to the security consideratio= ns section: > > "In order to prevent attacks, when an entity sends STUN keep-alives to an= adjacent downstream entity that is not willing to receive keep-alives (or = does not support STUN), but for which willingess to receive keep-alives has= been inidicated by some other downstream entity, if the sending entity doe= s not receive a response to any of the STUN keep-alive requests, it MUST st= op > sending the keep-alive requests for the remaining duration of the dialog = (if the sending of keep-alives were negotiated for a dialog) or until the s= ending of keep-alives is re-negotiated for the registration (if the sending= keep-alives were negotiated for a registration). Further actions taken by = the sending entity is outside the scope of this specification." > > Regards, > > Christer > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >> Sent: 24. marraskuuta 2010 14:50 >> To: Robert Sparks; SIPCORE >> Subject: Re: [sipcore] Security issue in -keep-08 >> >> >> Hi Robert, >> >> Thanks for reviewing the document! >> >> I guess the attack you describe could also happen in >> Outbound, if someone inserts an "ob" parameter in the Path >> header of the proxy adjacent to the UA, and that proxy does >> not check its Path header before forwarding the response to the UA. >> >> Having said that, I guess a way to protect against this >> attack could be to say that an entity MUST stop sending STUN >> messages if it doesn't receive a response to them. >> >> Regards, >> >> Christer >> >> >> >> >> >> >>> -----Original Message----- >>> From: Robert Sparks [mailto:rjsparks@nostrum.com] >>> Sent: 23. marraskuuta 2010 22:00 >>> To: SIPCORE >>> Cc: Christer Holmberg >>> Subject: Security issue in -keep-08 >>> >>> I believe there is a serious problem with the >> recommendations in the >>> Security Considerations section in keep-08 where it >> discusses having >>> downstream elements change the keep parameter. >>> >>> Consider this scenario. A user agent implementing this >> specification >>> sends a request that goes through two proxies before it >> arrives at its >>> destination. The first proxy does not know about this >> specification. >>> The second proxy does, and chooses to attempt to maliciously affect >>> the relationship between UA1 and P1 as suggested in these security >>> considerations. >>> >>> View the following flow in a fixed-width font: >>> >>> UA1 P1 P2 UA2 >>> | | | | >>> | INVITE | | | >>> | Via: UA;keep | INVITE | | >>> |------------------>| Via: P1 | | >>> | | Via: UA;keep | | >>> | |--------------->| | >>> | | |----->| >>> | | | 200 | >>> | | 200 |<-----| >>> | | Via: P1 | | >>> | 200 | Via: UA;keep=3D1 | | >>> | Via: UA;keep=3D1 |<---------------| | >>> |<------------------| | | >>> | | | | >>> >>> >>> Since P1 doesn't support this specification, it does not >> know to look >>> at "it's" Via to see if some downstream element has >> modified what it >>> would have put in the keep parameter value - the >> recommendation in the >>> current draft does not mitigate this attack at all. If the >> hop between >>> UA1 and P1 is UDP, this may result in STUN being send >> towards P1's SIP >>> listening port with P1 not expecting (or being able to deal >> with) it. >>> >>> This is a general problem with attempting to use Via parameters to >>> indicate support for extensions. A similar problem exists >> for ;rport, >>> and for ;lr. However, if a downstream element abused those >> parameters, >>> signaling is guaranteed to fail. This proposed parameter has a >>> different property - this abuse may only result in extra >> traffic for >>> someone else. >>> >>> I don't think this document is the right place to solve the general >>> problem, but this discussion needs to be rewritten to be >> clearer about >>> the problem and the lack of any current way to mitigate it. >>> >>> RjS >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >>= From rjsparks@nostrum.com Mon Nov 29 12:31:48 2010 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 BD49C28C0F5 for ; Mon, 29 Nov 2010 12:31:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.524 X-Spam-Level: X-Spam-Status: No, score=-101.524 tagged_above=-999 required=5 tests=[AWL=0.476, BAYES_00=-2.599, J_CHICKENPOX_24=0.6, SPF_PASS=-0.001, 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 rpjzZJFRmpdC for ; Mon, 29 Nov 2010 12:31:47 -0800 (PST) Received: from nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by core3.amsl.com (Postfix) with ESMTP id D692D28C10E for ; Mon, 29 Nov 2010 12:31:46 -0800 (PST) Received: from dn3-177.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id oATKWrvV083816 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 29 Nov 2010 14:32:53 -0600 (CST) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1082) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502C718A9@ESESSCMS0356.eemea.ericsson.se> Date: Mon, 29 Nov 2010 14:32:52 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <9D7CD9CF-4E47-41D1-8D01-F98808851223@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A05850307D840@ESESSCMS0356.eemea.ericsson.se> <7F2072F1E0DE894DA4B517B93C6A0585030B1833@ESESSCMS0356.eemea.ericsson.se>, <02688FBA-D5B4-403E-944E-FB9245936F36@nostrum.com> <7F2072F1E0DE894DA4B517B93C6A058502C718A9@ESESSCMS0356.eemea.ericsson.se> To: Christer Holmberg X-Mailer: Apple Mail (2.1082) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Security issue in -keep-08 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, 29 Nov 2010 20:31:48 -0000 On Nov 29, 2010, at 2:23 PM, Christer Holmberg wrote: > Hi, >=20 >> I don't object to the direction this text is taking, but it doesn't = _prevent_ attacks. It only mitigates the damage, >and it assumes the = attacked element doesn't just break when it gets the first STUN message = on its SIP=20 >> listening port. >=20 > Well, if it breaks from a single STUN mesage I think there is going to = be trouble sooner or later anyway, because nothing prevents entities = from sending STUN messages (or whatever data) to the listening port even = if keep support is not indicated. Of course, and it might break if something sends any other protocol (or = line noise) to it as well. But, there's a difference between "things might break if something sends = an unrequested alien message" and "we'll force the system to send what = might be an alien message as a matter of normal operation and hope = things don't break" >=20 > I have no idea what I could write in order to prevent the attack from = happening. As I indicated in my earlier note, I don't think we _can_ prevent this = attack with the current tools, and I don't think it's this document's job to make a new tool to address it. What the document can do is capture what we understand, documenting the = risk. I'll suggest some text if someone else doesn't beat me to it - it will be later this week at the earliest for me. RjS >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > On Nov 26, 2010, at 1:30 AM, Christer Holmberg wrote: >=20 >>=20 >> Hi Robert, >>=20 >> I suggest adding the following new paragraph to the security = considerations section: >>=20 >> "In order to prevent attacks, when an entity sends STUN keep-alives = to an adjacent downstream entity that is not willing to receive = keep-alives (or does not support STUN), but for which willingess to = receive keep-alives has been inidicated by some other downstream entity, = if the sending entity does not receive a response to any of the STUN = keep-alive requests, it MUST stop >> sending the keep-alive requests for the remaining duration of the = dialog (if the sending of keep-alives were negotiated for a dialog) or = until the sending of keep-alives is re-negotiated for the registration = (if the sending keep-alives were negotiated for a registration). Further = actions taken by the sending entity is outside the scope of this = specification." >>=20 >> Regards, >>=20 >> Christer >>=20 >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org >>> [mailto:sipcore-bounces@ietf.org] On Behalf Of Christer Holmberg >>> Sent: 24. marraskuuta 2010 14:50 >>> To: Robert Sparks; SIPCORE >>> Subject: Re: [sipcore] Security issue in -keep-08 >>>=20 >>>=20 >>> Hi Robert, >>>=20 >>> Thanks for reviewing the document! >>>=20 >>> I guess the attack you describe could also happen in >>> Outbound, if someone inserts an "ob" parameter in the Path >>> header of the proxy adjacent to the UA, and that proxy does >>> not check its Path header before forwarding the response to the UA. >>>=20 >>> Having said that, I guess a way to protect against this >>> attack could be to say that an entity MUST stop sending STUN >>> messages if it doesn't receive a response to them. >>>=20 >>> Regards, >>>=20 >>> Christer >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> -----Original Message----- >>>> From: Robert Sparks [mailto:rjsparks@nostrum.com] >>>> Sent: 23. marraskuuta 2010 22:00 >>>> To: SIPCORE >>>> Cc: Christer Holmberg >>>> Subject: Security issue in -keep-08 >>>>=20 >>>> I believe there is a serious problem with the >>> recommendations in the >>>> Security Considerations section in keep-08 where it >>> discusses having >>>> downstream elements change the keep parameter. >>>>=20 >>>> Consider this scenario. A user agent implementing this >>> specification >>>> sends a request that goes through two proxies before it >>> arrives at its >>>> destination. The first proxy does not know about this >>> specification. >>>> The second proxy does, and chooses to attempt to maliciously affect >>>> the relationship between UA1 and P1 as suggested in these security >>>> considerations. >>>>=20 >>>> View the following flow in a fixed-width font: >>>>=20 >>>> UA1 P1 P2 UA2 >>>> | | | | >>>> | INVITE | | | >>>> | Via: UA;keep | INVITE | | >>>> |------------------>| Via: P1 | | >>>> | | Via: UA;keep | | >>>> | |--------------->| | >>>> | | |----->| >>>> | | | 200 | >>>> | | 200 |<-----| >>>> | | Via: P1 | | >>>> | 200 | Via: UA;keep=3D1 | | >>>> | Via: UA;keep=3D1 |<---------------| | >>>> |<------------------| | | >>>> | | | | >>>>=20 >>>>=20 >>>> Since P1 doesn't support this specification, it does not >>> know to look >>>> at "it's" Via to see if some downstream element has >>> modified what it >>>> would have put in the keep parameter value - the >>> recommendation in the >>>> current draft does not mitigate this attack at all. If the >>> hop between >>>> UA1 and P1 is UDP, this may result in STUN being send >>> towards P1's SIP >>>> listening port with P1 not expecting (or being able to deal >>> with) it. >>>>=20 >>>> This is a general problem with attempting to use Via parameters to >>>> indicate support for extensions. A similar problem exists >>> for ;rport, >>>> and for ;lr. However, if a downstream element abused those >>> parameters, >>>> signaling is guaranteed to fail. This proposed parameter has a >>>> different property - this abuse may only result in extra >>> traffic for >>>> someone else. >>>>=20 >>>> I don't think this document is the right place to solve the general >>>> problem, but this discussion needs to be rewritten to be >>> clearer about >>>> the problem and the lack of any current way to mitigate it. >>>>=20 >>>> RjS >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>=20 From christer.holmberg@ericsson.com Mon Nov 29 12:50:49 2010 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 1365428C108 for ; Mon, 29 Nov 2010 12:50:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.428 X-Spam-Level: X-Spam-Status: No, score=-6.428 tagged_above=-999 required=5 tests=[AWL=0.171, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 ossTbP9zPv54 for ; Mon, 29 Nov 2010 12:50:47 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id DA1D128C0D7 for ; Mon, 29 Nov 2010 12:50:46 -0800 (PST) X-AuditID: c1b4fb3d-b7b8cae0000016b1-ca-4cf4126c6085 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 68.12.05809.C6214FC4; Mon, 29 Nov 2010 21:51:56 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0184.eemea.ericsson.se ([153.88.115.81]) with mapi; Mon, 29 Nov 2010 21:51:55 +0100 From: Christer Holmberg To: Robert Sparks Date: Mon, 29 Nov 2010 21:51:55 +0100 Thread-Topic: AD review: draft-ietf-sipcore-keep-08 Thread-Index: AcuP4Cy+gxyrqPJ5SbSwfYR8lEtKLQAI3h59 Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502C718AA@ESESSCMS0356.eemea.ericsson.se> References: <4892E0CC-52C7-4422-A5DA-C6A7553A4053@nostrum.com> <224F5CB1ECAB2C45BC64065AFD0339650406B5FC94@ESESSCMS0356.eemea.ericsson.se>, 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: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] AD review: draft-ietf-sipcore-keep-08 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, 29 Nov 2010 20:50:49 -0000 Hi, Comments inline ([CHH]). --------- >>> * Section 4.4 talks about normative server behavior for using >>> this mechanism with INVITE initiated dialogs. >>> where is the companion set of normative requirements for >>> using the mechanism to keep alive a REGISTRATION >>> flow? >> >> [CHH] The 2nd paragraph is the generic rule, which covers both INVITE an= d REGISTER. >> >> The 3rd paragraph is an addition that covers the case where multiple res= ponses are sent to a request, which is INVITE specific. >> >> But, maybe to make it more clear, and based on your comment on section 5= (see further down), I could rewrite the 3rd paragraph: >> >> "There might be multiple responses to an INVITE request. >> When a SIP entity indicates willingness to receive keep-alives in a >> response to an INVITE request, it MUST add a parameter value to the >> "keep" parameter in at least one reliable response to the request. The S= IP entity MAY >> add identical parameter values to the "keep" parameters in other respon= ses to the >> same request. The SIP entity MUST NOT add different parameter value to = the "keep" >> parameters in responses to the same request. The SIP entity SHOULD indic= ate >> the willingness to receive keep-alives as soon as possible." > >This text is better, but it uncovers another issue. For these keep-alives = associated with >a dialog, you need to adjust the text to reflect responses _in that dialog= _. In the presence >of forking, you may have multiple 183s from different branches (or multipl= e 200 OKs from >different branches. If the keep-alive activity is intended to be associate= d with the dialogs >(which is what I think the text is currently trying to do), you need to ad= just to note that the >element needs to include its keep value as early as possible on each dialo= g, and note that >the keep-alive messages will be sent reflecting each dialog that was set u= p. > >An alternative is to negotiate one keepalive stream per 5-tuple, using a r= eference count >(you stop when the last dialog using the 5-tuple terminates), but that see= ms pretty error-prone. [CHH] I suggest the following modification (...) "The SIP entity MUST NOT add different parameter value to the "keep" parame= ters in responses to the same request. The SIP entity SHOULD indicate the willingness to rec= eive keep-alives, for=20 each dialog on which it is willing the receive keep-alives, as soon a= s possible." --------- >>>* Section 6's first paragraph says "Entities that want to >>>reuse connections MUST use a another mechanism". >>>(Note the spurious 'a'). Why is this a 2119 MUST? I >>>suggest saying "would need to" instead. >> >>[CHH] Done. >> >>The reason behind the "MUST" was to clearly indicate that keep as such is= not a connection reuse mechanism. > >That's an incorrect use of the 2119 term. >I can't test implementation of that requirement - there's no way to accoun= t for it in an interoperability report, and there's >no good reference to what an implementer would need to read in order to sa= tisfy the requirement. You are really just >trying to say this mechanism doesn't provide connection reuse. Just say th= at. [CHH] Done. "Entities that want to reuse connections need to use another mechanism to e= nsure that security aspects associated with connection reuse are taken into consi= deration." --------- Regards, Christer= From peter.leis@nsn.com Tue Nov 30 00:50:11 2010 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 E544B3A6B3F for ; Tue, 30 Nov 2010 00:50:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] 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 d08x+NbuqLiM for ; Tue, 30 Nov 2010 00:50:09 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by core3.amsl.com (Postfix) with ESMTP id 5192E3A69C5 for ; Tue, 30 Nov 2010 00:50:08 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id oAU8pDTr029055 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 30 Nov 2010 09:51:13 +0100 Received: from demuexc022.nsn-intra.net (demuexc022.nsn-intra.net [10.150.128.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id oAU8pBuG028631; Tue, 30 Nov 2010 09:51:13 +0100 Received: from DEMUEXC035.nsn-intra.net ([10.150.128.26]) by demuexc022.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.4675); Tue, 30 Nov 2010 09:51:07 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Date: Tue, 30 Nov 2010 09:51:05 +0100 Message-ID: <79C4240C13B4C84B910850B96B1B431201CCCCB8@DEMUEXC035.nsn-intra.net> In-Reply-To: <7F2072F1E0DE894DA4B517B93C6A058502F9C72C@ESESSCMS0356.eemea.ericsson.se> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-holmberg-sipcore-proxy-feature- why notjust use Supported Thread-Index: AcuAat6XIt/v9PlARv6xOHOMfSzVMAACn+BqAANhOpAD+bjPkA== References: <4CD9E189.6050704@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502F9C72C@ESESSCMS0356.eemea.ericsson.se> From: "Leis, Peter (NSN - DE/Munich)" To: X-OriginalArrivalTime: 30 Nov 2010 08:51:07.0049 (UTC) FILETIME=[BA3A8990:01CB906B] Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- why notjust use Supported 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: Tue, 30 Nov 2010 08:50:12 -0000 hello, I support solving the 3GPP use case that Christer was refering to in the draft, using the draft as the basis for the work. regards Peter > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of ext Christer Holmberg > Sent: Wednesday, November 10, 2010 4:01 AM > To: Andrew Allen; pkyzivat@cisco.com; sipcore@ietf.org > Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- why > notjust use Supported >=20 >=20 > Hi, >=20 > Andrew is correct: just because something isn't a "pure" proxy, it > doesn't mean it is going to modify the Contact header, Supported header > etc. >=20 > Also, I think the use-case (which I have presented on the list) where a > proxy indicates that the Path address information can be used for > routing requests in both direction is an example of a "pure" proxy use- > case. That is also an old problem, that we have discussed earlier every > now and then. >=20 > Regards, >=20 > Christer >=20 >=20 >=20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Andrew Allen > > Sent: 10. marraskuuta 2010 3:20 > > To: pkyzivat@cisco.com; sipcore@ietf.org > > Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- > > why not just use Supported > > > > > > I think the second case Paul describes is what in 3GPP is > > called a Routing B2BUA which sometimes behaves like a proxy > > and sometimes like a UA. IMHO these entities should use > > Record-Route to keep themselves on the path and not write > > their own URI in the Contact but pass the Contact header > > transparently. To do otherwise breaks things like GRUU and > > callee caps. > > > > I support the solving in a general way of how an intermediary > > that provides some kind of funtionality on behalf of a UA can > > indicate its presence to other entities. > > > > Another use case for this is helping to solve service > > interaction problems where multiple application servers are > > involved and the service logic performed by one may need to > > be taken into account by the other. > > > > I also think it is necessary that UAs can detect the presence > > of intermediaries such as IP-PBXs and application servers in > > the path of a session and obtain a URI to which they can send > > requests to invoke service logic at those servers without > > them having to overwrite the contact URI for the reasons stated above. > > > > Andrew. > > > > ----- Original Message ----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Tuesday, November 09, 2010 07:04 PM > > To: sipcore@ietf.org > > Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- > > why not just use Supported > > > > I'm tempted to agree with Cullen on this. > > But I think it "depends". > > > > If the B2BUA is a "proper" UA, and inserts its own Contact > > address in the call, then I think Cullen's description is right. > > > > If its a B2BUA because it messes with things a proxy cannot, but > > *doesn't* modify the Contact address, then just manipulating > > Supported isn't enough. Then the features that *it* supports > > are obtainable directly only by sending a request to *it*, > > using the Route header, etc. > > to identify that address. > > > > Its always seemed to me that a UA should always supply its > > own Contact address, but I've looked for verification of that > > in 3261 and not found it. > > > > Thanks, > > Paul > > > > On 11/10/2010 4:42 AM, Cullen Jennings wrote: > > > > > > So, in my week of agreeing with Hadriel, I think he got it > > exactly right when he said there is pretty much no feature a > > "plain" proxy would need for this. If we are talking about > > things that would be a strict technical read be considered > > B2BUA even if they are implemented a lot like a proxy, then I > > can why something provided something like this functionality > > would be needed. > > > > > > But given this would be used by a B2BUA, I don't see why > > you need anything more than just normal option tags. Say a > > SIP message comes from A to B to C and now the response is > > coming back. C says it supports feature c1, c2, and c3. B > > knows that it can transparently forward on whatever is needed > > for c1, c2, but not c3 and it knows that in additional to > > this it can do features b4 and b5. It modifies the Supported > > header to have c1,c2,b4, and b5. and sends that back to A. > > > > > > If the real uses cases have to do with caller pref > > features, then B can modify those in the same way. > > > > > > Anyways, I think we are way way ahead of ourselves > > discussing mechanism before we even understand what the use > > cases are we are trying to solve. I'd like to see some > > specific real world use cases and so we can work out the real > > requirements. I'm expect the uses cases will contain B2BUA in > > the call flows - that's reality. > > > > > > > > > On Sep 24, 2010, at 5:04 AM, Christer Holmberg wrote: > > > > > >> > > >> > > >> Hi, > > >> > > >> I've submitted a draft, which extends the rr-param rule, > > allowing proxies to indicate supported features using feature > > tags in Path, Record-Route etc. > > >> > > >> The draft can also be found at: > > >> > > http://users.piuha.net/cholmber/drafts/draft-holmberg-sipcore-proxy-f > > >> eature-00.txt > > >> > > >> As I indicated earlier on the list, and as you can read in > > the draft, there is a 3GPP use-case where we believe the > > mechanism could be used. But, there is nothing 3GPP specific > > about the mechanism as such. > > >> > > >> Regards, > > >> > > >> Christer > > >> _______________________________________________ > > >> 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 > > > > --------------------------------------------------------------------- > > This transmission (including any attachments) may contain > > confidential information, privileged material (including > > material protected by the solicitor-client or other > > applicable privileges), or constitute non-public information. > > Any use of this information by anyone other than the intended > > recipient is prohibited. If you have received this > > transmission in error, please immediately reply to the sender > > and delete this information from your system. Use, > > dissemination, distribution, or reproduction of this > > transmission by unintended recipients is not authorized and > > may be unlawful. > > _______________________________________________ > > 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 From md3135@att.com Tue Nov 30 04:40:13 2010 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 B6D4128C133 for ; Tue, 30 Nov 2010 04:40:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, 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 bBj-X-QpBxLj for ; Tue, 30 Nov 2010 04:40:11 -0800 (PST) Received: from mail167.messagelabs.com (mail167.messagelabs.com [216.82.253.179]) by core3.amsl.com (Postfix) with ESMTP id 3892028C151 for ; Tue, 30 Nov 2010 04:40:11 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-3.tower-167.messagelabs.com!1291120880!32488775!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 21110 invoked from network); 30 Nov 2010 12:41:21 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-3.tower-167.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Nov 2010 12:41:21 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oAUCebJn019673 for ; Tue, 30 Nov 2010 07:40:37 -0500 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id oAUCeYhj019648 for ; Tue, 30 Nov 2010 07:40:35 -0500 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 Date: Tue, 30 Nov 2010 07:41:17 -0500 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD5424@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-holmberg-sipcore-proxy-feature- whynotjust use Supported Thread-Index: AcuAat6XIt/v9PlARv6xOHOMfSzVMAACn+BqAANhOpAD+bjPkAAIhuO7 From: "DOLLY, MARTIN C (ATTLABS)" To: , X-Mailman-Approved-At: Tue, 30 Nov 2010 06:11:23 -0800 Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- whynotjust use Supported 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: Tue, 30 Nov 2010 12:40:13 -0000 QVQmVCBhbHNvIHN1cHBvcnRzIHRoaXMNCg0KTWFydGluIEMuIERvbGx5DQpTZW50IHRvIHlvdSBi eSBBVCZULi4uIEFtZXJpY2EncyBGYXN0ZXN0IE1vYmlsZSBCcm9hZGJhbmQgTmV0d29yay4gUmV0 aGluayBQb3NzaWJsZS4NCisxLjYwOS45MDMuMzM2MA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdl IC0tLS0tDQpGcm9tOiBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgPHNpcGNvcmUtYm91bmNlc0Bp ZXRmLm9yZz4NClRvOiBzaXBjb3JlQGlldGYub3JnIDxzaXBjb3JlQGlldGYub3JnPg0KU2VudDog VHVlIE5vdiAzMCAwMzo1MTowNSAyMDEwDQpTdWJqZWN0OiBSZTogW3NpcGNvcmVdIGRyYWZ0LWhv bG1iZXJnLXNpcGNvcmUtcHJveHktZmVhdHVyZS0gd2h5bm90anVzdAl1c2UJU3VwcG9ydGVkDQoN CmhlbGxvLA0KDQpJIHN1cHBvcnQgc29sdmluZyB0aGUgM0dQUCB1c2UgY2FzZSB0aGF0IENocmlz dGVyIHdhcyByZWZlcmluZyB0byBpbiB0aGUNCmRyYWZ0LCB1c2luZyB0aGUgZHJhZnQgYXMgdGhl IGJhc2lzIGZvciB0aGUgd29yay4NCg0KcmVnYXJkcw0KUGV0ZXINCg0KPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpz aXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJlaGFsZiBPZiBleHQgQ2hyaXN0ZXIgSG9s bWJlcmcNCj4gU2VudDogV2VkbmVzZGF5LCBOb3ZlbWJlciAxMCwgMjAxMCA0OjAxIEFNDQo+IFRv OiBBbmRyZXcgQWxsZW47IHBreXppdmF0QGNpc2NvLmNvbTsgc2lwY29yZUBpZXRmLm9yZw0KPiBT dWJqZWN0OiBSZTogW3NpcGNvcmVdIGRyYWZ0LWhvbG1iZXJnLXNpcGNvcmUtcHJveHktZmVhdHVy ZS0gd2h5DQo+IG5vdGp1c3QgdXNlIFN1cHBvcnRlZA0KPiANCj4gDQo+IEhpLA0KPiANCj4gQW5k cmV3IGlzIGNvcnJlY3Q6IGp1c3QgYmVjYXVzZSBzb21ldGhpbmcgaXNuJ3QgYSAicHVyZSIgcHJv eHksIGl0DQo+IGRvZXNuJ3QgbWVhbiBpdCBpcyBnb2luZyB0byBtb2RpZnkgdGhlIENvbnRhY3Qg aGVhZGVyLCBTdXBwb3J0ZWQNCmhlYWRlcg0KPiBldGMuDQo+IA0KPiBBbHNvLCBJIHRoaW5rIHRo ZSB1c2UtY2FzZSAod2hpY2ggSSBoYXZlIHByZXNlbnRlZCBvbiB0aGUgbGlzdCkgd2hlcmUNCmEN Cj4gcHJveHkgaW5kaWNhdGVzIHRoYXQgdGhlIFBhdGggYWRkcmVzcyBpbmZvcm1hdGlvbiBjYW4g YmUgdXNlZCBmb3INCj4gcm91dGluZyByZXF1ZXN0cyBpbiBib3RoIGRpcmVjdGlvbiBpcyBhbiBl eGFtcGxlIG9mIGEgInB1cmUiIHByb3h5DQp1c2UtDQo+IGNhc2UuIFRoYXQgaXMgYWxzbyBhbiBv bGQgcHJvYmxlbSwgdGhhdCB3ZSBoYXZlIGRpc2N1c3NlZCBlYXJsaWVyDQpldmVyeQ0KPiBub3cg YW5kIHRoZW4uDQo+IA0KPiBSZWdhcmRzLA0KPiANCj4gQ2hyaXN0ZXINCj4gDQo+IA0KPiANCj4g DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBzaXBjb3JlLWJvdW5j ZXNAaWV0Zi5vcmcNCj4gPiBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVo YWxmIE9mIEFuZHJldyBBbGxlbg0KPiA+IFNlbnQ6IDEwLiBtYXJyYXNrdXV0YSAyMDEwIDM6MjAN Cj4gPiBUbzogcGt5eml2YXRAY2lzY28uY29tOyBzaXBjb3JlQGlldGYub3JnDQo+ID4gU3ViamVj dDogUmU6IFtzaXBjb3JlXSBkcmFmdC1ob2xtYmVyZy1zaXBjb3JlLXByb3h5LWZlYXR1cmUtDQo+ ID4gd2h5IG5vdCBqdXN0IHVzZSBTdXBwb3J0ZWQNCj4gPg0KPiA+DQo+ID4gSSB0aGluayB0aGUg c2Vjb25kIGNhc2UgUGF1bCBkZXNjcmliZXMgaXMgd2hhdCBpbiAzR1BQIGlzDQo+ID4gY2FsbGVk IGEgUm91dGluZyBCMkJVQSB3aGljaCBzb21ldGltZXMgYmVoYXZlcyBsaWtlIGEgcHJveHkNCj4g PiBhbmQgc29tZXRpbWVzIGxpa2UgYSBVQS4gSU1ITyB0aGVzZSBlbnRpdGllcyBzaG91bGQgdXNl DQo+ID4gUmVjb3JkLVJvdXRlIHRvIGtlZXAgdGhlbXNlbHZlcyBvbiB0aGUgcGF0aCBhbmQgbm90 IHdyaXRlDQo+ID4gdGhlaXIgb3duIFVSSSBpbiB0aGUgQ29udGFjdCBidXQgcGFzcyB0aGUgQ29u dGFjdCBoZWFkZXINCj4gPiB0cmFuc3BhcmVudGx5LiBUbyBkbyBvdGhlcndpc2UgYnJlYWtzIHRo aW5ncyBsaWtlIEdSVVUgYW5kDQo+ID4gY2FsbGVlIGNhcHMuDQo+ID4NCj4gPiBJIHN1cHBvcnQg dGhlIHNvbHZpbmcgaW4gYSBnZW5lcmFsIHdheSBvZiBob3cgYW4gaW50ZXJtZWRpYXJ5DQo+ID4g dGhhdCBwcm92aWRlcyBzb21lIGtpbmQgb2YgZnVudGlvbmFsaXR5IG9uIGJlaGFsZiBvZiBhIFVB IGNhbg0KPiA+IGluZGljYXRlIGl0cyBwcmVzZW5jZSB0byBvdGhlciBlbnRpdGllcy4NCj4gPg0K PiA+IEFub3RoZXIgdXNlIGNhc2UgZm9yIHRoaXMgaXMgaGVscGluZyB0byBzb2x2ZSBzZXJ2aWNl DQo+ID4gaW50ZXJhY3Rpb24gcHJvYmxlbXMgd2hlcmUgbXVsdGlwbGUgYXBwbGljYXRpb24gc2Vy dmVycyBhcmUNCj4gPiBpbnZvbHZlZCBhbmQgdGhlIHNlcnZpY2UgbG9naWMgcGVyZm9ybWVkIGJ5 IG9uZSBtYXkgbmVlZCB0bw0KPiA+IGJlIHRha2VuIGludG8gYWNjb3VudCBieSB0aGUgb3RoZXIu DQo+ID4NCj4gPiBJIGFsc28gdGhpbmsgaXQgaXMgbmVjZXNzYXJ5IHRoYXQgVUFzIGNhbiBkZXRl Y3QgdGhlIHByZXNlbmNlDQo+ID4gb2YgaW50ZXJtZWRpYXJpZXMgc3VjaCBhcyBJUC1QQlhzIGFu ZCBhcHBsaWNhdGlvbiBzZXJ2ZXJzIGluDQo+ID4gdGhlIHBhdGggb2YgYSBzZXNzaW9uIGFuZCBv YnRhaW4gYSBVUkkgdG8gd2hpY2ggdGhleSBjYW4gc2VuZA0KPiA+IHJlcXVlc3RzIHRvIGludm9r ZSBzZXJ2aWNlIGxvZ2ljIGF0IHRob3NlIHNlcnZlcnMgd2l0aG91dA0KPiA+IHRoZW0gaGF2aW5n IHRvIG92ZXJ3cml0ZSB0aGUgY29udGFjdCBVUkkgZm9yIHRoZSByZWFzb25zIHN0YXRlZA0KYWJv dmUuDQo+ID4NCj4gPiBBbmRyZXcuDQo+ID4NCj4gPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0t LS0tDQo+ID4gRnJvbTogUGF1bCBLeXppdmF0IFttYWlsdG86cGt5eml2YXRAY2lzY28uY29tXQ0K PiA+IFNlbnQ6IFR1ZXNkYXksIE5vdmVtYmVyIDA5LCAyMDEwIDA3OjA0IFBNDQo+ID4gVG86IHNp cGNvcmVAaWV0Zi5vcmcgPHNpcGNvcmVAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogUmU6IFtzaXBj b3JlXSBkcmFmdC1ob2xtYmVyZy1zaXBjb3JlLXByb3h5LWZlYXR1cmUtDQo+ID4gd2h5IG5vdCBq dXN0IHVzZQlTdXBwb3J0ZWQNCj4gPg0KPiA+IEknbSB0ZW1wdGVkIHRvIGFncmVlIHdpdGggQ3Vs bGVuIG9uIHRoaXMuDQo+ID4gQnV0IEkgdGhpbmsgaXQgImRlcGVuZHMiLg0KPiA+DQo+ID4gSWYg dGhlIEIyQlVBIGlzIGEgInByb3BlciIgVUEsIGFuZCBpbnNlcnRzIGl0cyBvd24gQ29udGFjdA0K PiA+IGFkZHJlc3MgaW4gdGhlIGNhbGwsIHRoZW4gSSB0aGluayBDdWxsZW4ncyBkZXNjcmlwdGlv biBpcyByaWdodC4NCj4gPg0KPiA+IElmIGl0cyBhIEIyQlVBIGJlY2F1c2UgaXQgbWVzc2VzIHdp dGggdGhpbmdzIGEgcHJveHkgY2Fubm90LCBidXQNCj4gPiAqZG9lc24ndCogbW9kaWZ5IHRoZSBD b250YWN0IGFkZHJlc3MsIHRoZW4ganVzdCBtYW5pcHVsYXRpbmcNCj4gPiBTdXBwb3J0ZWQgaXNu J3QgZW5vdWdoLiBUaGVuIHRoZSBmZWF0dXJlcyB0aGF0ICppdCogc3VwcG9ydHMNCj4gPiBhcmUg b2J0YWluYWJsZSBkaXJlY3RseSBvbmx5IGJ5IHNlbmRpbmcgYSByZXF1ZXN0IHRvICppdCosDQo+ ID4gdXNpbmcgdGhlIFJvdXRlIGhlYWRlciwgZXRjLg0KPiA+IHRvIGlkZW50aWZ5IHRoYXQgYWRk cmVzcy4NCj4gPg0KPiA+IEl0cyBhbHdheXMgc2VlbWVkIHRvIG1lIHRoYXQgYSBVQSBzaG91bGQg YWx3YXlzIHN1cHBseSBpdHMNCj4gPiBvd24gQ29udGFjdCBhZGRyZXNzLCBidXQgSSd2ZSBsb29r ZWQgZm9yIHZlcmlmaWNhdGlvbiBvZiB0aGF0DQo+ID4gaW4gMzI2MSBhbmQgbm90IGZvdW5kIGl0 Lg0KPiA+DQo+ID4gCVRoYW5rcywNCj4gPiAJUGF1bA0KPiA+DQo+ID4gT24gMTEvMTAvMjAxMCA0 OjQyIEFNLCBDdWxsZW4gSmVubmluZ3Mgd3JvdGU6DQo+ID4gPg0KPiA+ID4gU28sIGluIG15IHdl ZWsgb2YgYWdyZWVpbmcgd2l0aCBIYWRyaWVsLCBJIHRoaW5rIGhlIGdvdCBpdA0KPiA+IGV4YWN0 bHkgcmlnaHQgd2hlbiBoZSBzYWlkIHRoZXJlIGlzIHByZXR0eSBtdWNoIG5vIGZlYXR1cmUgYQ0K PiA+ICJwbGFpbiIgcHJveHkgd291bGQgbmVlZCBmb3IgdGhpcy4gSWYgd2UgYXJlIHRhbGtpbmcg YWJvdXQNCj4gPiB0aGluZ3MgdGhhdCB3b3VsZCBiZSBhIHN0cmljdCB0ZWNobmljYWwgcmVhZCBi ZSBjb25zaWRlcmVkDQo+ID4gQjJCVUEgZXZlbiBpZiB0aGV5IGFyZSBpbXBsZW1lbnRlZCBhIGxv dCBsaWtlIGEgcHJveHksIHRoZW4gSQ0KPiA+IGNhbiB3aHkgc29tZXRoaW5nIHByb3ZpZGVkIHNv bWV0aGluZyBsaWtlIHRoaXMgZnVuY3Rpb25hbGl0eQ0KPiA+IHdvdWxkIGJlIG5lZWRlZC4NCj4g PiA+DQo+ID4gPiBCdXQgZ2l2ZW4gdGhpcyB3b3VsZCBiZSB1c2VkIGJ5IGEgQjJCVUEsIEkgZG9u J3Qgc2VlIHdoeQ0KPiA+IHlvdSBuZWVkIGFueXRoaW5nIG1vcmUgdGhhbiBqdXN0IG5vcm1hbCBv cHRpb24gdGFncy4gU2F5IGENCj4gPiBTSVAgbWVzc2FnZSBjb21lcyBmcm9tIEEgdG8gQiB0byBD IGFuZCBub3cgdGhlIHJlc3BvbnNlIGlzDQo+ID4gY29taW5nIGJhY2suIEMgc2F5cyBpdCBzdXBw b3J0cyBmZWF0dXJlIGMxLCBjMiwgYW5kIGMzLiBCDQo+ID4ga25vd3MgdGhhdCBpdCBjYW4gdHJh bnNwYXJlbnRseSBmb3J3YXJkIG9uIHdoYXRldmVyIGlzIG5lZWRlZA0KPiA+IGZvciBjMSwgYzIs IGJ1dCBub3QgYzMgYW5kIGl0IGtub3dzIHRoYXQgaW4gYWRkaXRpb25hbCB0bw0KPiA+IHRoaXMg aXQgY2FuIGRvIGZlYXR1cmVzIGI0IGFuZCBiNS4gSXQgbW9kaWZpZXMgdGhlIFN1cHBvcnRlZA0K PiA+IGhlYWRlciB0byBoYXZlIGMxLGMyLGI0LCBhbmQgYjUuIGFuZCBzZW5kcyB0aGF0IGJhY2sg dG8gQS4NCj4gPiA+DQo+ID4gPiBJZiB0aGUgcmVhbCB1c2VzIGNhc2VzIGhhdmUgdG8gZG8gd2l0 aCBjYWxsZXIgcHJlZg0KPiA+IGZlYXR1cmVzLCB0aGVuIEIgY2FuIG1vZGlmeSB0aG9zZSBpbiB0 aGUgc2FtZSB3YXkuDQo+ID4gPg0KPiA+ID4gQW55d2F5cywgSSB0aGluayB3ZSBhcmUgd2F5IHdh eSBhaGVhZCBvZiBvdXJzZWx2ZXMNCj4gPiBkaXNjdXNzaW5nIG1lY2hhbmlzbSBiZWZvcmUgd2Ug ZXZlbiB1bmRlcnN0YW5kIHdoYXQgdGhlIHVzZQ0KPiA+IGNhc2VzIGFyZSB3ZSBhcmUgdHJ5aW5n IHRvIHNvbHZlLiBJJ2QgbGlrZSB0byBzZWUgc29tZQ0KPiA+IHNwZWNpZmljIHJlYWwgd29ybGQg dXNlIGNhc2VzIGFuZCBzbyB3ZSBjYW4gd29yayBvdXQgdGhlIHJlYWwNCj4gPiByZXF1aXJlbWVu dHMuIEknbSBleHBlY3QgdGhlIHVzZXMgY2FzZXMgd2lsbCBjb250YWluIEIyQlVBIGluDQo+ID4g dGhlIGNhbGwgZmxvd3MgLSB0aGF0J3MgcmVhbGl0eS4NCj4gPiA+DQo+ID4gPg0KPiA+ID4gT24g U2VwIDI0LCAyMDEwLCBhdCA1OjA0IEFNLCBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZToNCj4gPiA+ DQo+ID4gPj4NCj4gPiA+Pg0KPiA+ID4+IEhpLA0KPiA+ID4+DQo+ID4gPj4gSSd2ZSBzdWJtaXR0 ZWQgYSBkcmFmdCwgd2hpY2ggZXh0ZW5kcyB0aGUgcnItcGFyYW0gcnVsZSwNCj4gPiBhbGxvd2lu ZyBwcm94aWVzIHRvIGluZGljYXRlIHN1cHBvcnRlZCBmZWF0dXJlcyB1c2luZyBmZWF0dXJlDQo+ ID4gdGFncyBpbiBQYXRoLCBSZWNvcmQtUm91dGUgZXRjLg0KPiA+ID4+DQo+ID4gPj4gVGhlIGRy YWZ0IGNhbiBhbHNvIGJlIGZvdW5kIGF0Og0KPiA+ID4+DQo+ID4NCmh0dHA6Ly91c2Vycy5waXVo YS5uZXQvY2hvbG1iZXIvZHJhZnRzL2RyYWZ0LWhvbG1iZXJnLXNpcGNvcmUtcHJveHktZg0KPiA+ ID4+IGVhdHVyZS0wMC50eHQNCj4gPiA+Pg0KPiA+ID4+IEFzIEkgaW5kaWNhdGVkIGVhcmxpZXIg b24gdGhlIGxpc3QsIGFuZCBhcyB5b3UgY2FuIHJlYWQgaW4NCj4gPiB0aGUgZHJhZnQsIHRoZXJl IGlzIGEgM0dQUCB1c2UtY2FzZSB3aGVyZSB3ZSBiZWxpZXZlIHRoZQ0KPiA+IG1lY2hhbmlzbSBj b3VsZCBiZSB1c2VkLiBCdXQsIHRoZXJlIGlzIG5vdGhpbmcgM0dQUCBzcGVjaWZpYw0KPiA+IGFi b3V0IHRoZSBtZWNoYW5pc20gYXMgc3VjaC4NCj4gPiA+Pg0KPiA+ID4+IFJlZ2FyZHMsDQo+ID4g Pj4NCj4gPiA+PiBDaHJpc3Rlcg0KPiA+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fDQo+ID4gPj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gPiA+PiBz aXBjb3JlQGlldGYub3JnDQo+ID4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0 aW5mby9zaXBjb3JlDQo+ID4gPg0KPiA+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPiA+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+ID4gPiBzaXBj b3JlQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L3NpcGNvcmUNCj4gPiA+DQo+ID4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCj4gPiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiA+IHNpcGNvcmVAaWV0Zi5v cmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4g Pg0KPiA+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBUaGlzIHRyYW5zbWlzc2lvbiAoaW5jbHVkaW5nIGFu eSBhdHRhY2htZW50cykgbWF5IGNvbnRhaW4NCj4gPiBjb25maWRlbnRpYWwgaW5mb3JtYXRpb24s IHByaXZpbGVnZWQgbWF0ZXJpYWwgKGluY2x1ZGluZw0KPiA+IG1hdGVyaWFsIHByb3RlY3RlZCBi eSB0aGUgc29saWNpdG9yLWNsaWVudCBvciBvdGhlcg0KPiA+IGFwcGxpY2FibGUgcHJpdmlsZWdl cyksIG9yIGNvbnN0aXR1dGUgbm9uLXB1YmxpYyBpbmZvcm1hdGlvbi4NCj4gPiBBbnkgdXNlIG9m IHRoaXMgaW5mb3JtYXRpb24gYnkgYW55b25lIG90aGVyIHRoYW4gdGhlIGludGVuZGVkDQo+ID4g cmVjaXBpZW50IGlzIHByb2hpYml0ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMNCj4gPiB0 cmFuc21pc3Npb24gaW4gZXJyb3IsIHBsZWFzZSBpbW1lZGlhdGVseSByZXBseSB0byB0aGUgc2Vu ZGVyDQo+ID4gYW5kIGRlbGV0ZSB0aGlzIGluZm9ybWF0aW9uIGZyb20geW91ciBzeXN0ZW0uIFVz ZSwNCj4gPiBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24sIG9yIHJlcHJvZHVjdGlvbiBvZiB0 aGlzDQo+ID4gdHJhbnNtaXNzaW9uIGJ5IHVuaW50ZW5kZWQgcmVjaXBpZW50cyBpcyBub3QgYXV0 aG9yaXplZCBhbmQNCj4gPiBtYXkgYmUgdW5sYXdmdWwuDQo+ID4gX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiBzaXBjb3JlIG1haWxpbmcgbGlzdA0K PiA+IHNpcGNvcmVAaWV0Zi5vcmcNCj4gPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NpcGNvcmUNCj4gPg0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiBzaXBjb3JlQGlldGYub3Jn DQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGlu ZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xp c3RpbmZvL3NpcGNvcmUNCg== From christer.holmberg@ericsson.com Tue Nov 30 10:18:57 2010 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 657EB28C170 for ; Tue, 30 Nov 2010 10:18:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.434 X-Spam-Level: X-Spam-Status: No, score=-6.434 tagged_above=-999 required=5 tests=[AWL=0.165, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] 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 Itfwc9MplgsA for ; Tue, 30 Nov 2010 10:18:55 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 3B3BC28C161 for ; Tue, 30 Nov 2010 10:18:55 -0800 (PST) X-AuditID: c1b4fb39-b7bafae000002a42-02-4cf540559e75 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id C4.15.10818.55045FC4; Tue, 30 Nov 2010 19:20:05 +0100 (CET) Received: from ESESSCMS0356.eemea.ericsson.se ([169.254.1.175]) by esessmw0197.eemea.ericsson.se ([153.88.115.87]) with mapi; Tue, 30 Nov 2010 19:20:05 +0100 From: Christer Holmberg To: "Leis, Peter (NSN - DE/Munich)" , "sipcore@ietf.org" Date: Tue, 30 Nov 2010 19:15:49 +0100 Thread-Topic: [sipcore] draft-holmberg-sipcore-proxy-feature- why notjust use Supported Thread-Index: AcuAat6XIt/v9PlARv6xOHOMfSzVMAACn+BqAANhOpAD+bjPkAAUNcGf Message-ID: <7F2072F1E0DE894DA4B517B93C6A058502C718CD@ESESSCMS0356.eemea.ericsson.se> References: <4CD9E189.6050704@cisco.com> <7F2072F1E0DE894DA4B517B93C6A058502F9C72C@ESESSCMS0356.eemea.ericsson.se>, <79C4240C13B4C84B910850B96B1B431201CCCCB8@DEMUEXC035.nsn-intra.net> In-Reply-To: <79C4240C13B4C84B910850B96B1B431201CCCCB8@DEMUEXC035.nsn-intra.net> 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: AAAAAA== Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- why notjust use Supported 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: Tue, 30 Nov 2010 18:18:57 -0000 Hi, At the previous 3GPP CT1 meeting, the group indicated willingness to use th= e mechanism in the draft in the work on session continuity. There has been some comments on that we need text regarding "directionality= ", ie if an indicated capability is only valid in one direction, and I agre= e to that we need to address that. But, in general I would like to know what to do in order to move the draft = forward and adopt it as a working group item. Regards, Christer ________________________________________ From: Leis, Peter (NSN - DE/Munich) [peter.leis@nsn.com] Sent: Tuesday, November 30, 2010 10:51 AM To: sipcore@ietf.org Cc: Christer Holmberg; Andrew Allen; pkyzivat@cisco.com Subject: RE: [sipcore] draft-holmberg-sipcore-proxy-feature- why notjust = use Supported hello, I support solving the 3GPP use case that Christer was refering to in the draft, using the draft as the basis for the work. regards Peter > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of ext Christer Holmberg > Sent: Wednesday, November 10, 2010 4:01 AM > To: Andrew Allen; pkyzivat@cisco.com; sipcore@ietf.org > Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- why > notjust use Supported > > > Hi, > > Andrew is correct: just because something isn't a "pure" proxy, it > doesn't mean it is going to modify the Contact header, Supported header > etc. > > Also, I think the use-case (which I have presented on the list) where a > proxy indicates that the Path address information can be used for > routing requests in both direction is an example of a "pure" proxy use- > case. That is also an old problem, that we have discussed earlier every > now and then. > > Regards, > > Christer > > > > > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Andrew Allen > > Sent: 10. marraskuuta 2010 3:20 > > To: pkyzivat@cisco.com; sipcore@ietf.org > > Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- > > why not just use Supported > > > > > > I think the second case Paul describes is what in 3GPP is > > called a Routing B2BUA which sometimes behaves like a proxy > > and sometimes like a UA. IMHO these entities should use > > Record-Route to keep themselves on the path and not write > > their own URI in the Contact but pass the Contact header > > transparently. To do otherwise breaks things like GRUU and > > callee caps. > > > > I support the solving in a general way of how an intermediary > > that provides some kind of funtionality on behalf of a UA can > > indicate its presence to other entities. > > > > Another use case for this is helping to solve service > > interaction problems where multiple application servers are > > involved and the service logic performed by one may need to > > be taken into account by the other. > > > > I also think it is necessary that UAs can detect the presence > > of intermediaries such as IP-PBXs and application servers in > > the path of a session and obtain a URI to which they can send > > requests to invoke service logic at those servers without > > them having to overwrite the contact URI for the reasons stated above. > > > > Andrew. > > > > ----- Original Message ----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Tuesday, November 09, 2010 07:04 PM > > To: sipcore@ietf.org > > Subject: Re: [sipcore] draft-holmberg-sipcore-proxy-feature- > > why not just use Supported > > > > I'm tempted to agree with Cullen on this. > > But I think it "depends". > > > > If the B2BUA is a "proper" UA, and inserts its own Contact > > address in the call, then I think Cullen's description is right. > > > > If its a B2BUA because it messes with things a proxy cannot, but > > *doesn't* modify the Contact address, then just manipulating > > Supported isn't enough. Then the features that *it* supports > > are obtainable directly only by sending a request to *it*, > > using the Route header, etc. > > to identify that address. > > > > Its always seemed to me that a UA should always supply its > > own Contact address, but I've looked for verification of that > > in 3261 and not found it. > > > > Thanks, > > Paul > > > > On 11/10/2010 4:42 AM, Cullen Jennings wrote: > > > > > > So, in my week of agreeing with Hadriel, I think he got it > > exactly right when he said there is pretty much no feature a > > "plain" proxy would need for this. If we are talking about > > things that would be a strict technical read be considered > > B2BUA even if they are implemented a lot like a proxy, then I > > can why something provided something like this functionality > > would be needed. > > > > > > But given this would be used by a B2BUA, I don't see why > > you need anything more than just normal option tags. Say a > > SIP message comes from A to B to C and now the response is > > coming back. C says it supports feature c1, c2, and c3. B > > knows that it can transparently forward on whatever is needed > > for c1, c2, but not c3 and it knows that in additional to > > this it can do features b4 and b5. It modifies the Supported > > header to have c1,c2,b4, and b5. and sends that back to A. > > > > > > If the real uses cases have to do with caller pref > > features, then B can modify those in the same way. > > > > > > Anyways, I think we are way way ahead of ourselves > > discussing mechanism before we even understand what the use > > cases are we are trying to solve. I'd like to see some > > specific real world use cases and so we can work out the real > > requirements. I'm expect the uses cases will contain B2BUA in > > the call flows - that's reality. > > > > > > > > > On Sep 24, 2010, at 5:04 AM, Christer Holmberg wrote: > > > > > >> > > >> > > >> Hi, > > >> > > >> I've submitted a draft, which extends the rr-param rule, > > allowing proxies to indicate supported features using feature > > tags in Path, Record-Route etc. > > >> > > >> The draft can also be found at: > > >> > > http://users.piuha.net/cholmber/drafts/draft-holmberg-sipcore-proxy-f > > >> eature-00.txt > > >> > > >> As I indicated earlier on the list, and as you can read in > > the draft, there is a 3GPP use-case where we believe the > > mechanism could be used. But, there is nothing 3GPP specific > > about the mechanism as such. > > >> > > >> Regards, > > >> > > >> Christer > > >> _______________________________________________ > > >> 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 > > > > --------------------------------------------------------------------- > > This transmission (including any attachments) may contain > > confidential information, privileged material (including > > material protected by the solicitor-client or other > > applicable privileges), or constitute non-public information. > > Any use of this information by anyone other than the intended > > recipient is prohibited. If you have received this > > transmission in error, please immediately reply to the sender > > and delete this information from your system. Use, > > dissemination, distribution, or reproduction of this > > transmission by unintended recipients is not authorized and > > may be unlawful. > > _______________________________________________ > > 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=