From gonzalo.camarillo@ericsson.com Wed Jul 1 10:39:43 2009 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 EB8703A69F7 for ; Wed, 1 Jul 2009 10:39:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 h+7VNOOVocvw for ; Wed, 1 Jul 2009 10:39:43 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 5B2F93A6A88 for ; Wed, 1 Jul 2009 10:39:19 -0700 (PDT) X-AuditID: c1b4fb3e-b7be1ae000004757-60-4a4b9b8d16b0 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id D5.37.18263.D8B9B4A4; Wed, 1 Jul 2009 19:23:25 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Jul 2009 19:23:25 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Jul 2009 19:23:24 +0200 Received: from [131.160.126.222] (rvi2-126-222.lmf.ericsson.se [131.160.126.222]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 78C81246A; Wed, 1 Jul 2009 20:23:24 +0300 (EEST) Message-ID: <4A4B9B8C.1080900@ericsson.com> Date: Wed, 01 Jul 2009 20:23:24 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: sipcore@ietf.org References: <4A16F967.6050509@nostrum.com> <4A30B989.9040805@nostrum.com> <4A4A77D9.1020700@nostrum.com> In-Reply-To: <4A4A77D9.1020700@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jul 2009 17:23:24.0716 (UTC) FILETIME=[A3BD8EC0:01C9FA70] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] LAST CALL: Re: IETF 75: Agenda Time Requests 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, 01 Jul 2009 17:39:44 -0000 Folks, this is our draft agenda for Stockholm. As indicated previously, if we do not receive any other agenda requests we will be looking into reducing our face-to-face time substantially. http://www.ietf.org/proceedings/09jul/agenda/sipcore.html Cheers, Gonzalo SIPCORE co-chair Adam Roach wrote: > [as chair] > > So far, the chairs have received three requests for agenda time: > > * draft-ietf-sipcore-keep > * history-info-bis / target-uri > * 3265-bis > > Unless we receive additional requests before the end of this week, we > will be instructing the secretariat to reduce the amount of face-to-face > meeting time to one hour, so as to alleviate any scheduling conflicts > that we would otherwise cause. > > After we do this, it will be too late to request additional agenda time. > If you want to discuss something in Stockholm other than these three > items, speak up now. > > /a > > Adam Roach wrote: >> On 22-May-2009, Adam Roach wrote: >>> If you wish to request agenda time, please send these three pieces of >>> information to the SIPCORE chairs on or before June 3rd. >> >> >> That was, of course, a typo. The deadline for agenda requests is July >> 3rd. Please see the original mail below (with the date corrected) for >> further details. >> >> /a >> >> >>> [as chair] >>> >>> In keeping with the spirit of our charter, we intend to run SIPCORE >>> face-to-face meetings in a very focused fashion. To that end, >>> requests for SIPCORE agenda time need to contain the following >>> information: >>> >>> 1. The name of the draft or drafts under discussion >>> 2. A list of open issues to be addressed >>> 3. A pointer to non-trivial mailing list discussion of the draft (the >>> subject line of associated threads is sufficient) >>> >>> Presentations are expected to be focused around the list of open >>> issues, not the general contents of or changes to the document. >>> Tutorial content must be limited to explaining the open issues and >>> potential resolutions to those issues. >>> >>> Please note that it will be very difficult to have non-trivial >>> mailing list discussion of drafts that are submitted very close to >>> the document submission deadlines. We strongly encourage authors who >>> plan to request agenda time to publish a revised document well ahead >>> of the deadlines. >>> >>> Currently, we have requested a total of 3.5 hours of meeting time at >>> the upcoming meeting in Stockholm this July. Depending on the total >>> number of open issues and the associated volume of mailing list >>> traffic, we may reduce this to 2.5 hours or even 1 hour. >>> >>> If you wish to request agenda time, please send these three pieces of >>> information to the SIPCORE chairs on or before July 3rd. Length of >>> timeslots will be determined based on the number and complexity of >>> open issues in the agenda request. If a new open issue arises after >>> submission of a request, please notify the chairs so that we can >>> adjust timeslots accordingly. >>> >>> For the sake of clarity: the discussion will not be limited to the >>> open items listed in your request; it can include open items that >>> arise after you submit your request. So, if your list of open items >>> is somewhat weak but you expect that difficult points may arise >>> between June 3rd and the Stockholm meeting, please send in a request >>> indicating that fact. >>> >>> /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 AUDET@nortel.com Wed Jul 1 11:43:45 2009 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 25EE63A6915 for ; Wed, 1 Jul 2009 11:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.067 X-Spam-Level: X-Spam-Status: No, score=-6.067 tagged_above=-999 required=5 tests=[AWL=-0.068, BAYES_00=-2.599, J_CHICKENPOX_74=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 q1CYmG8DHPRK for ; Wed, 1 Jul 2009 11:43:41 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 8AA3C3A67F0 for ; Wed, 1 Jul 2009 11:43:41 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n61IhfG18405; Wed, 1 Jul 2009 18:43:41 GMT 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, 1 Jul 2009 13:42:48 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EC8AD11@zrc2hxm0.corp.nortel.com> In-Reply-To: A<0D5F89FAC29E2C41B98A6A762007F5D00213B56F@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] 4244bis and privacy thread-index: Acn11AWR+Z7be2FAQvKtnWIFO4vfcAAB1KHQAABgLvAAFKai8AAAYdKwABEiZHAAitux8AAa+YTgABHtvHAASa8UkA== References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EB2624A@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4048F809B@S4DE8PSAAQB.mitte.t-com.de> <4A43DEC9.1020802@gmail.com> <9886E5FCA6D76549A3011068483A4BD4048F80AC@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1EB26AB5@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D00213AA4C@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522C! CF1EB6BD6 9@zrc2hxm0.c orp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EBE2181@zrc2hxm0.corp.nortel.com> A<0D5F89FAC29E2C41B98A6A762007F5D00213B56F@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Elwell, John" , "Ian Elz" , "Mary Barnes" , , Cc: sipcore@ietf.org, shida@agnada.com Subject: Re: [sipcore] 4244bis and privacy 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, 01 Jul 2009 18:43:45 -0000 I see another problem with Privacy in RFC 4244. Currently, it talks about "Session" Privacy impacting HI and says = nothing about "User" privacy impacting HI. (see RFC 3323) This makes no sense to me. Session is supposed to relate strictly=20 to SDP-level information (i.e., IP address inside SDP, and maybe some other fields). I don't see at all why "session" would mean don't do HI. On the other hand 4244 is silent about "User" Privacy. I belive if "user privacy" is used, then defintively it implies the URIs = representing that user should be anonymized. Views? =20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Tuesday, June 30, 2009 00:30 > To: Audet, Francois (SC100:3055); Ian Elz; Barnes, Mary=20 > (RICH2:AR00); R.Jesske@telekom.de; ietf.hanserik@gmail.com > Cc: sipcore@ietf.org; shida@agnada.com > Subject: RE: [sipcore] 4244bis and privacy >=20 > Yes, I think something like this makes sense. >=20 > John=20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: 30 June 2009 00:06 > > To: Ian Elz; Elwell, John; Mary Barnes; R.Jesske@telekom.de;=20 > > ietf.hanserik@gmail.com > > Cc: sipcore@ietf.org; shida@agnada.com > > Subject: RE: [sipcore] 4244bis and privacy > >=20 > > I think the current "interpretation" is not terribly=20 > useful. I prefer=20 > > your suggestion. The current RFC 4244 text is not very clear. > >=20 > > It seems to me that: > > - Privacy should associated with a specific hi-entry (and=20 > perhaps any > > entry that corresponds to that same user), and not the header=20 > > itself. > > - That way, it is possible that specific entries be=20 > anonymize, but not > > others. For example, if you call me without privacy, and I call=20 > > forward > > you to John with privacy setup for myself, John should=20 > see an entry=20 > > for > > you and an anonymized entry for me. > > - There is no reason why "none" couldn't be used in this context.=20 > > Again, > > with the same example as above, John could requies "none"=20 > > for him, and > > I could set privacy on for myself. > >=20 > > I don't think this type of rule for 4244bis would require=20 > any change=20 > > whatsoever to RFC 3323. It would be completely self-contained in=20 > > 4244bis. > >=20 > > Comments? > >=20 > > > -----Original Message----- > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > Sent: Monday, June 29, 2009 03:26 > > > To: Audet, Francois (SC100:3055); Elwell, John; Barnes, Mary=20 > > > (RICH2:AR00); R.Jesske@telekom.de; ietf.hanserik@gmail.com > > > Cc: sipcore@ietf.org; shida@agnada.com > > > Subject: RE: [sipcore] 4244bis and privacy > > >=20 > > > Francios, > > >=20 > > > I agree that 4244bis should not specify the actions of=20 > proxies etc=20 > > > where this is a matter of local policy. > > >=20 > > > My original proposed change was to allow the inclusion of=20 > the value=20 > > > "none" in the alongside the value "history" to be included in the=20 > > > Privacy header parameter escaped in the=20 > hi-targeted-to-uri. (RFC4244=20 > > > section 4.1) > > >=20 > > > It appears however that the current interpretation of the Privacy=20 > > > header means that the value included in the Privacy=20 > header, which is=20 > > > applicable to the originating rather than retargeting user is=20 > > > applied to the retargeting user rather than the explicit value=20 > > > included for the retargeting user. > > > The escaped privacy value is only used if there is no=20 > Privacy header=20 > > > or the Privacy header only contains the value "user". > > >=20 > > > The end result of this interpretation is that including=20 > an explicit=20 > > > value "none" escaped as a Privacy parameter would have no=20 > effect and=20 > > > would have the same meaning as not including a Privacy header=20 > > > parameter escaped in the hi-targeted-to-uri. > > >=20 > > > 4244bis is not the place to extend the sip Privacy handling to=20 > > > specify how 3rd party identities in sip messages should=20 > have their=20 > > > own specific privacy maintained. > > >=20 > > > Allowing the inclusion of the explicitly Privacy=3Dnone=20 > value in the=20 > > > hi-targeted-to-uri would not change any handling at this time but=20 > > > would make the new H-I RFC suitable for use if an updated privacy=20 > > > RFC is proposed which does have specific support for 3rd party=20 > > > identities. > > >=20 > > > H-I is not the only place where the explicit privacy of 3rd party=20 > > > identities is required. The Referred-By header is one other case=20 > > > where a similar explicit privacy may need to be considered in the=20 > > > future. > > >=20 > > > regards > > >=20 > > > Ian > > >=20 > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortel.com] > > > Sent: 26 June 2009 16:55 > > > To: Ian Elz; Elwell, John; Mary Barnes; R.Jesske@telekom.de;=20 > > > ietf.hanserik@gmail.com > > > Cc: sipcore@ietf.org; shida@agnada.com > > > Subject: RE: [sipcore] 4244bis and privacy > > >=20 > > > I do see things that we should fix right-away in History-Info,=20 > > > regarding privacy. > > >=20 > > > I also think that History-Info shouldn't "overstrech" and get too=20 > > > deep into the nitty gritty of privacy. What should be in=20 > HI is high=20 > > > level guidance. > > >=20 > > > In section 3.1, for example, it says that Privacy header will=20 > > > determine if a History-Info *header field* can be included by an=20 > > > intermediary. This does not make any sense. What it should say is=20 > > > that the Privacy header will determine if a history-info=20 > *entry* can=20 > > > be added for the UA inserting the Privacy header. > > >=20 > > > So, in my opinion, we can go ahead and fix that right now. > > >=20 > > > I don't think we need to get into super low-level procedural=20 > > > descriptions of the type "proxy MUST this and that if Privacy = =3D=3D=20 > > > this and that". I believe privacy matters are=20 > policy-level decisions=20 > > > that service providers and enteprises will have, and they are not=20 > > > going to be implemented by simplistic procedural rules=20 > from an RFC. > > >=20 > > > Comments? > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: sipcore-bounces@ietf.org > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Ian Elz > > > > Sent: Friday, June 26, 2009 01:08 > > > > To: Elwell, John; Barnes, Mary (RICH2:AR00);=20 > R.Jesske@telekom.de;=20 > > > > ietf.hanserik@gmail.com > > > > Cc: sipcore@ietf.org; shida@agnada.com > > > > Subject: Re: [sipcore] 4244bis and privacy > > > >=20 > > > > John, > > > >=20 > > > > Your statement " not anonymise or remove any information > > > that the UAC > > > > has already placed in the request " is the key here. > > > >=20 > > > > The UAC has not included the H-I entry, particularly the one=20 > > > > containing the identity of the diverting party. > > > >=20 > > > > This was not considered in RFC3323 and we have an issue=20 > where we=20 > > > > cannot determine which entity included which information. > > > > This creates a problem where a restriction by the > > originating party > > > > will prevent a downstream identity from permitting > > presentation of > > > > their identity. > > > >=20 > > > > I agree with Mary that this probably requires an update to > > > > RFC3323 so we should start by updating RFC3323 and then > > > move on to the > > > > other impacted RFCs. The issue that this will raise for > > H-I is that > > > > there will be another change required after the Privacy RFC > > > has been > > > > agreed. > > > >=20 > > > > This is far from ideal but the 4424bis draft contains a lot > > > more than > > > > just this issue. > > > >=20 > > > > Ian > > > >=20 > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: 26 June 2009 08:30 > > > > To: Mary Barnes; R.Jesske@telekom.de; ietf.hanserik@gmail.com > > > > Cc: Ian Elz; sipcore@ietf.org; shida@agnada.com > > > > Subject: RE: [sipcore] 4244bis and privacy > > > >=20 > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: sipcore-bounces@ietf.org > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > > > > > Sent: 25 June 2009 22:45 > > > > > To: R.Jesske@telekom.de; ietf.hanserik@gmail.com > > > > > Cc: ian.elz@ericsson.com; sipcore@ietf.org; shida@agnada.com > > > > > Subject: Re: [sipcore] 4244bis and privacy > > > > >=20 > > > > > Roland, > > > > >=20 > > > > > The reason you can't have "none" at the request level and > > > > "history" at > > > > > the entry level is because RFC 3323 states that you MUST > > > NOT apply > > > > > privacy to the message. Even if you put "history" in the > > > > entries, the > > > > > privacy service would just ignore that - per RFC 3323. =20 > > > So, if you > > > > > want to change that behavior, then RFC 3323 should be > > > > changed - i.e., > > > > > the MUST NOT for the "none" could be changed to a SHOULD > > > > NOT and then > > > > > a general statement about possible exceptions. Then, we > > could add > > > > > something to RFC 4244 for this case. But, changing RFC > > > > > 3323 is totally out of scope for what we are currently > > > working on. =20 > > > > [JRE] I would interpret privacy 'none' in RFC 3323 as > > > meaning that a > > > > downstream entity must not anonymise or remove any > > information that > > > > the UAC has already placed in the request. > > > > If a downstream entity chooses: > > > > - not to add H-I, > > > > - to add anonymised H-I, or > > > > - to anonymise an H-I entry that some intermediate entity > > > has added, I > > > > don't see that as being in violation of what the UAC has > > requested. > > > >=20 > > > > John > > > >=20 > > > >=20 > > > > >=20 > > > > > That all said, I would sure think that if you are leaving a > > > > "trusted > > > > > network" that you have a B2BUA in there, as I've said=20 > in other=20 > > > > > threads. Thus, the B2BUA builds a new request and certainly > > > > can add a > > > > > privacy header that it believes is appropriate since > > the outgoing > > > > > request is done by the UAC function of a B2BUA. > > > > >=20 > > > > > Mary.=20 > > > > >=20 > > > > >=20 > > > > > -----Original Message----- > > > > > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > > > > > Sent: Thursday, June 25, 2009 4:32 PM > > > > > To: ietf.hanserik@gmail.com > > > > > Cc: Barnes, Mary (RICH2:AR00); ian.elz@ericsson.com; > > > > sipcore@ietf.org; > > > > > shida@agnada.com > > > > > Subject: AW: [sipcore] 4244bis and privacy > > > > >=20 > > > > > Hi Hans Erik, > > > > > We have also to take regulatory into consideration. In > > > Germany the > > > > > last trusted network is responsible for anonymising=20 > information. > > > > >=20 > > > > > But nevertheless if Network provider A wants to have History=20 > > > > > completely private this operator will set privacy > > history for the > > > > > header. > > > > > If the succeeding Operator want to present elements the AS > > > > which adds > > > > > a entry has then to re label all entries from the > > > preceding network > > > > > and the entries from it's own network will be unmarked > > within the > > > > > Header. > > > > >=20 > > > > > But never the less I fully agree to your last sentence. > > > > >=20 > > > > > The real Question is if this should really be allowed > > > that a entry > > > > > marked with "none" overrules the privacy statement > > > > "history" for the > > > > > complete header. > > > > >=20 > > > > > I'm against this behaviour.=20 > > > > >=20 > > > > > Best Regards > > > > >=20 > > > > > Roland > > > > >=20 > > > > > -----Urspr=FCngliche Nachricht----- > > > > > Von: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > > > > Gesendet: Donnerstag, 25. Juni 2009 22:32 > > > > > An: Jesske, Roland > > > > > Cc: mary.barnes@nortel.com; ian.elz@ericsson.com; > > > sipcore@ietf.org; > > > > > shida@agnada.com > > > > > Betreff: Re: [sipcore] 4244bis and privacy > > > > >=20 > > > > > Hi Roland, > > > > >=20 > > > > > I don't understand the argument, by the time that the > > > History-Info > > > > > leaves operator A that wishes complete privacy, all the > > > > History-Info > > > > > headers should be anonymised according to 4244 and 4244bis. > > > > >=20 > > > > > What is the point in mandating that operator A to force > > > > operator B to > > > > > also anonymise the entries "owned" by operator B. > > > > >=20 > > > > > It is of course without question that each operator has > > > > full privacy > > > > > control over its own added entries. And each operator can > > > based on > > > > > local policy decide to remove the entire history if it > > > > things that is > > > > > wise to do. > > > > >=20 > > > > > /Hans Erik > > > > >=20 > > > > >=20 > > > > > R.Jesske@telekom.de wrote: > > > > > > Hi Marry and Ian, > > > > > > The whole discussion puzzle me. We have specified CDIV > > > > > within TISPAN and 3GPP.=20 > > > > > > There is described that privacy "none" can be used for > > > > > entries. BUT assuming that each entry has its own privacy > > > > statement if > > > > > needed. > > > > > > I fully agree on Mary's comment that a privacy "history"=20 > > > > > cannot overruled by a privacy value "none" within a entry.=20 > > > > > > There may be operators that would like to keep the whole > > > > > History Info private even if entries has other > > statements, so the > > > > > entity could add privacy history to the whole header. > > > > > Nothing more. > > > > > > > > > > > > On the other side a Application Server including a entry > > > > > should have the possibility to rewrite the entries so that > > > > instead of > > > > > "history" for the whole header the all received entries > > > within the > > > > > History-Info header will be marked with "history" and the > > > > added header > > > > > (which shall be presented to the terminating user) will > > either be > > > > > marked with "none" or will not be marked. > > > > > > > > > > > > Perhaps a hint could be given, but I do not insist on it. > > > > > > > > > > > > Best Regards, > > > > > > > > > > > > Roland > > > > > > > > > > > > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > > Von: sipcore-bounces@ietf.org > > > > [mailto:sipcore-bounces@ietf.org] Im > > > > > > Auftrag von Mary Barnes > > > > > > Gesendet: Donnerstag, 25. Juni 2009 18:29 > > > > > > An: Ian Elz > > > > > > Cc: sipcore@ietf.org; Shida Schubert > > > > > > Betreff: Re: [sipcore] 4244bis and privacy > > > > > > > > > > > > Hi Ian, > > > > > > > > > > > > Responses inline below [MB2]. > > > > > > > > > > > > Mary. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > > > > Sent: Thursday, June 25, 2009 10:13 AM > > > > > > To: Barnes, Mary (RICH2:AR00) > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida=20 > Schubert;=20 > > > > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > Mary, > > > > > > > > > > > > I am a little concerned about one answer that you gave: > > > > > > > > > > > > > > > > > > If you have a Privacy header with a value of "none" and a > > > > H-I entry > > > > > > with Privacy header parameter with value "history" what is > > > > > the privacy > > > > > > of the individual H-I entry? > > > > > > [MB] We did not explicitly address the "none" in RFC > > > > 4244, but the > > > > > > general statement is the privacy headers at the request > > > > > level override > > > > > > any at the hi-entry level. [/MB] > > > > > > =20 > > > > > > This means that if privacy is required for an individual > > > > > H-I entry but > > > > > > the originating user included "Privacy:none" in the request > > > > > then there > > > > > > is no option to include the real URI in the H-I entry. > > > > > > [MB2] I'm confused here - the "none" definition is as you > > > > > note below, > > > > > > thus "none" prohibits the removal or anonymization of the > > > > entries, > > > > > > thus I would think you would fine this functionality > > desireable. > > > > > > However, this does not prohibit an entity based on policy > > > > > to anonymize > > > > > > (or remove entries if privacy is required for that > > > domain if the > > > > > > entity does not have access to a privacy service). [/MB2] > > > > > > > > > > > > This occurs as RFC3323 states in section 4.3: "However, if > > > > > the Privacy > > > > > > header value of 'none' is specified in a message, privacy > > > > services > > > > > > MUST NOT perform any privacy function and MUST NOT remove > > > > or modify > > > > > > the Privacy header." > > > > > > > > > > > > The only option for an intermediate node including a H-I > > > > > entry where > > > > > > "Privacy:none" is specified and privacy for the H-I URI is > > > > > required is > > > > > > to include an anonymous entry or not include the H-I entry. > > > > > > [MB2] If privacy is required then yes, you include > > > > > anonymous entries > > > > > > or don't include. That's the basic privacy mechanism > > > for privacy > > > > > > levels of "session" "header" and "history" in the R-URI or > > > > > "history"=20 > > > > > > in the specific entries, as well as when there is a policy > > > > > for privacy > > > > > > for the entries added by a specific domain. The "none"=20 > > > > > really has no > > > > > > influence on the later case per se. [/MB2] > > > > > > > > > > > > In your previous response you stated that we would violate > > > > > RFC3323 if > > > > > > we specified additional behaviour for privacy explicitly > > > > > stated with a > > > > > > URI -n the H-I entry. I don't believe that this is the case > > > > > as RFC3323 > > > > > > only considered privacy in a two party scenario and did not > > > > > consider > > > > > > third party identities being included in a message > > between two > > > > > > parties. H-I is not the only case where this occurs as the > > > > > Referred-By > > > > > > header when included in the INVITE (or other request) > > > > which results > > > > > > from the REFER has the same issue. > > > > > > [MB2] I can't necessarily disagree on this one (we can > > > debate it > > > > > > either way). But to fix it requires an update to=20 > RFC 3323 and=20 > > > > > > shouldn't be something that we want to fix in=20 > 4244bis. [/MB2] > > > > > > > > > > > > RFC4244 was the first time that there was a recognition > > > > > that privacy > > > > > > for these individual third party identities may be > > > > > required. To allow > > > > > > this explicit statement of privacy to be overridden by > > > a generic > > > > > > statement which is applicable to a different user is > > > > > counterintuitive. > > > > > > [MB2] See my comment above. But, as I have consistently > > > > > said, the idea > > > > > > that an entity might want to override the "none" is > > > > > entirely based on > > > > > > policy and 4244 and 4244bis allow privacy to be applied to > > > > > the entries > > > > > > that are added by that entity if the policy dictates > > so (and we > > > > > > already say that). [/MB2] > > > > > > > > > > > > The original Privacy header is usually included by or on > > > > > behalf of the > > > > > > originating user and should not be allowed to specify the > > > > > privacy of > > > > > > the original called user, e.g. the 800 number, and > > prevent this > > > > > > identity being presented if this user does not have the > > > > > same level of privacy. > > > > > > [MB2] As I tried to say in a previous response, a random > > > > > entity (i.e., > > > > > > one for whom the R-URI is not in a domain under its > > > > control) cannot > > > > > > add a privacy header to the Request. Per RFC 3323 an > > > > entity may add > > > > > > the header to a request only if it has the appropriate=20 > > > > > > relationship/authorization with the original called user > > > > > who intiated > > > > > > the request. And, I would find it very surprising if an > > > > entity that > > > > > > did have responsibility would apply privacy since > > that would be > > > > > > counter intuitive and I would hope that SPs would be > > > judicious in > > > > > > specifying the appropriate and inappropriate manner in > > > which the > > > > > > proxies they deploy and interface with privatize the > > > > messages. The > > > > > > protocol CANNOT control this behavior and that's why > > > there is the > > > > > > policy clause in 4244 and 4244bis. [/MB2] > > > > > > > > > > > > The real issue with the 800 scenario is as you have stated > > > > > is that the > > > > > > answerer will not know the original called identity and > > > > will not be > > > > > > able to correctly handle the call. As more generic call > > > > centres are > > > > > > used which will answer calls on behalf of many different > > > > > organizations > > > > > > using CTI and the original called identity to have to > > > implement a > > > > > > generic system asking the caller who he originally > > > called appear > > > > > > unprofessional, is inefficient and unproductive. > > > > > > [MB2] And, as I noted, it is rare for a call centre to > > > > route a call > > > > > > directly to an agent without a user providing some sort of > > > > > input. Even > > > > > > companies like American Airlines, even though they have the > > > > > info that > > > > > > I enter via the IVR, they still ask some basic questions > > > > > and there are > > > > > > times when they have to reroute me. I don't think we > > > can totally > > > > > > automate things. And, again, once the call hits the > > > > domain that is > > > > > > responsible for that 800 number the entities in that > > > domain have > > > > > > control over how they muck with the R-URI, such that they > > > > should be > > > > > > able to use any IVR info to appropriately direct the call - > > > > > it's not > > > > > > the number that's meaningful, but how the system gets the > > > > > call to the > > > > > > right user and the additional information they provide as > > > > > the call is > > > > > > presented to the agent. I would honestly think that having > > > > > something > > > > > > other than an 800 number show up on the display would > > > be far more > > > > > > useful and in my experience in the systems I developed > > > > > we're usually > > > > > > talking about CTI interfaces so you have a lot you can > > > do. And, > > > > > > actually all of this really doesn't matter in that you MUST > > > > > be able to > > > > > > handle this situation independent of the privacy since > > > > > History-Info is > > > > > > optional, you need default behavior assigned. [/MB2] > > > > > > > > > > > > We have an opportunity to allow presentation of specific > > > > identities > > > > > > and to solve this particular problem so we should take it. > > > > > > [MB2] The most we can do is to document the risks/impacts > > > > > of the use > > > > > > of the Privacy headers at the R-URI level. There is > > > > already general > > > > > > text in > > > > > > 4244 and 4244bis that the privacy may impact whether the > > > > > applications > > > > > > get the information. And, as I noted before, most > > > > > commercial systems > > > > > > are using B2BUAs which will allow you far more control over > > > > > the use of > > > > > > the Privacy headers in the network. But, again, I don't > > > > > think that's > > > > > > something that should be address in 4244bis. [/MB2] > > > > > > > > > > > > I hope that we can get some wider discussion on this issue > > > > > so a more > > > > > > general consensus can be obtained. > > > > > > > > > > > > Regards > > > > > > > > > > > > Ian > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > > > > Sent: 24 June 2009 17:27 > > > > > > To: Ian Elz > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida=20 > Schubert;=20 > > > > > > sipcore@ietf.org; Francois Audet > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > Hi Ian, > > > > > > > > > > > > Responses inline below [MB]. > > > > > > > > > > > > Mary.=20 > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > > > > Sent: Wednesday, June 24, 2009 10:37 AM > > > > > > To: Barnes, Mary (RICH2:AR00) > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida=20 > Schubert;=20 > > > > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > Mary, > > > > > > > > > > > > I was not proposing that we change the handling of H-I > > > > > which is based > > > > > > upon local policy. If that causes an issue for a network > > > > > operator then > > > > > > they can modify their local policy accordingly or arrange > > > > with the > > > > > > proxy vendor to modify their equipment to be more > > flexible with > > > > > > regards to policy. > > > > > > > > > > > > Can you clarify for me: > > > > > > > > > > > > If you have a Privacy header with either "session" or > > > > "header" doe > > > > > > this impact the H-I entries or will only a value of > > > > > "history" impact > > > > > > the H-I entries? > > > > > > [MB] Yes, both "session" and "header" level privacy, > > > > > consistent with > > > > > > RFC 3323, mandate that entries be anonymized or > > > dropped, with the > > > > > > latter being the recommendation for "session" level > > > > > privacy. RFC 4244 > > > > > > mandated that they be dropped and 4244bis=20 > recommends they be=20 > > > > > > anonymized. The original intent for the value of "history" > > > > > was for the > > > > > > tagging of the individual entries, but you end up getting > > > > > the header > > > > > > level functionality as well. [/MB] > > > > > > > > > > > > If you have a Privacy header with a value of "none" and a > > > > H-I entry > > > > > > with Privacy header parameter with value "history" what is > > > > > the privacy > > > > > > of the individual H-I entry? > > > > > > [MB] We did not explicitly address the "none" in RFC > > > > 4244, but the > > > > > > general statement is the privacy headers at the request > > > > > level override > > > > > > any at the hi-entry level. [/MB] > > > > > > > > > > > > From reading RFC4244 a Privacy header with value > > "history" will > > > > > > effectively make all H-I entries private and there is > > > > currently no > > > > > > option to include a H-I Privacy header parameter with > > > > value "none". > > > > > > [MB] Correct, per my comment above. [/MB] > > > > > > > > > > > > H-I at present allows the inclusion of Privacy header > > > > parameters to > > > > > > explicitly express privacy for an individual H-I entry > > > > but a single > > > > > > node which includes a header "Privacy: history" makes all > > > > > H-I entries > > > > > > private even if this is not the requirements for the > > > specific URI. > > > > > > [MB] Correct, but the only node that should add the header > > > > > is a node > > > > > > which is responsible for the domain associated with the > > > > > Request URI in > > > > > > the incoming request or is authorized to do so. [/MB] > > > > > > > > > > > > I will admit that having worked in a telephony environment > > > > > for a long > > > > > > time I am used to having privacy of identities set on a > > > > per number > > > > > > basis and the relative inflexibility of the IETF Privacy > > > > header is > > > > > > relatively restrictive as to specifying which > > identities may be > > > > > > presented and which not. > > > > > > [MB] Yes, this is an entirely different paradigm. I > > developed > > > > > > telephony s/w for over a decade and this is entirely > > > > different - it > > > > > > provides a lot more flexibility, which makes things > > > far, far less > > > > > > deterministic than what you have in telephony switches > > > where your > > > > > > routing and translations are configured for the most part, > > > > > with just a > > > > > > few capabilities for controlling the privacy and it's a > > > > > closed network. > > > > > > > > > > > > With RFC4244/4244bis, there MUST be a mechanism at the > > > UAS or end > > > > > > application that can handle a request that doesn't have the=20 > > > > > > appropriate information either because nodes didn't support=20 > > > > > > History-Info or some random node in the network applied > > > > > privacy (which > > > > > > I think is highly > > > > > > unlikely) - this is normative per section 5 of RFC > > > 4244. So, the > > > > > > worst case scenario I see for this 800 service (which will > > > > > get to the > > > > > > right UAS but without the exact 800 number that was dialed) > > > > > is that it > > > > > > goes to a default ACD group/customer service agent, > > > etc. who then > > > > > > needs to gather the appropriate information and in my > > > > > experience this > > > > > > is often an IVR system these days. So, the service is not > > > > > broken when > > > > > > privacy is applied in an undesireable manner, it's just not > > > > > optimal. =20 > > > > > > This is something that should be addressed in the > > > > target-uri draft > > > > > > which has all the details of how specific services use > > > > History-Info. > > > > > > One other thing to consider is that most networks that are > > > > > emulating > > > > > > telephony type features use B2BUAs, which follow the > > > > > UAS/UAC rules for > > > > > > the header rather than the proxy rules, noting that the > > > > UAC can set > > > > > > the Privacy header to whatever value it sees as appropriate > > > > > for the request. > > > > > > [/MB] > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > Ian > > > > > > > > > > > > -----Original Message----- > > > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > > > > Sent: 24 June 2009 15:48 > > > > > > To: Ian Elz > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida=20 > Schubert;=20 > > > > > > sipcore@ietf.org; Francois Audet > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > Hi Ian, > > > > > > > > > > > > I do not believe we should do the "override" behavior as I > > > > > think that > > > > > > violates RFC 3323, as the "history" is really a subset of > > > > the cases > > > > > > whereby a UAC or proxy would add "session" or "header" to > > > > > the request. > > > > > > And, the latter two cases have the same (undesireable) > > > > > result. I agree > > > > > > this impacts your services, but we can't mandate that > > > > > proxies provide > > > > > > information that might violate their local policies and > > > indeed a > > > > > > proxy's local policies can result in the information being > > > > > anonymized > > > > > > (or removed if they can't anonymize) even in the=20 > "none" case. > > > > > > > > > > > > I do believe it's reasonable that we strongly recommend > > > that the > > > > > > request level (versus specific hi-entries) not be used > > > > and if it is > > > > > > used, the consequence is that some services will=20 > not have the=20 > > > > > > information they need - this was the gist of my previous > > > > > response (to > > > > > > which I did not get any additional feedback). Now, we could > > > > > add some text that the "none" > > > > > > case SHOULD be used (e.g., added by first hop proxy) if it > > > > > is desired > > > > > > that the information not be subject to privacy > > > > > restrictions. I do not > > > > > > think it is then particularly useful to add logic around > > > > the proxy > > > > > > then being able to tag the entries within their domain as > > > > > subject to privacy. > > > > > > I think that conflicts with the intent of the request > > > > level "none". > > > > > > However, as I mention above, per the current text, a proxy > > > > > can (based > > > > > > on local policy) remove entries - so a proxy can capture > > > > hi within > > > > > > their domain and not forward any of that information to the > > > > > next hop > > > > > > in another domain - you already have that functionality. =20 > > > > > But, I think > > > > > > this introduces the general problem that you might be > > > > > impacting other > > > > > > services further down the line, which I thought was the > > > > problem you > > > > > > were wanting to solve - not specifically your example > > > > > service but, for > > > > > > example, in the case that someone is debugging and they > > > want the > > > > > > entire history, so depending upon the service, this is also=20 > > > > > > undesirable behavior. > > > > > > > > > > > > > > > > > > Regards, > > > > > > Mary.=20 > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > > > > Sent: Wednesday, June 24, 2009 2:57 AM > > > > > > To: Barnes, Mary (RICH2:AR00) > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida=20 > Schubert;=20 > > > > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > > > > > > > Mary, > > > > > > > > > > > > [I have added the list to this thread for wider comment.] > > > > > > > > > > > > In the previous discussions I commented that in RFC4424 > > > > > that a Privacy > > > > > > header with value "history" effectively makes all H-I > > > > > entries private > > > > > > with the result that the H-I entries may be removed. > > > > > > > > > > > > There has now been a comprehensive discussion on > > > > indication of the > > > > > > initial 'target' to the final recipient for call handling > > > > purposes. > > > > > > > > > > > > The main use case related to a freephone example where the > > > > > answering > > > > > > location may be a call centre where the original freephone > > > > > number may > > > > > > be required for correct call handling. > > > > > > > > > > > > If you now consider the following example (modified from > > > > Francois'=20 > > > > > > text in the latest draft - excuse any errors that I may > > > > > have inserted) > > > > > > > > > > > > INVITE sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx > > > > > > Privacy: history > > > > > > History-Info: > > > > > >=20 > > > > > = ;index=3D1;rt;aor =20 > > > > > (1) > > > > > > History-Info: = ;index=3D1.1;mp;aor > > > > > > (2) > > > > > > History-Info: ;index=3D1.1.1;rc > > > > > > (3) > > > > > > > > > > > > In this case due to the Privacy header all of the H-I > > > entries are > > > > > > considered private and the +18001234567 will not be > > > > > delivered to the > > > > > > final destination with the result that call handling may > > > > > not be correct. > > > > > > The Privacy header may have been inserted by any of the > > > > nodes which > > > > > > routed the message and inserted a H-I entry. > > > > > > > > > > > > If however the H-I was allowed to include a header > > parameter of > > > > > > "?Privacy=3Dnone" in the H-I entry and that an explicit > > H-I entry > > > > > > privacy value would be considered to have precedence over > > > > a Privacy > > > > > > header with a value of "history" then the mapping of the > > > > > +18001234567 > > > > > > could be explicitly specified as not private and may be > > > passed on. > > > > > > > > > > > > Thus when the mapping from sip:+18001234567@example.com to=20 > > > > > > sip:bob@biloxi.example.com when H-I entry (2) above is > > > > > included could > > > > > > also insert the Privacy header parameter in H-I entry (1). > > > > > > > > > > > > Thus the message would appear as follows: > > > > > > > > > > > > INVITE sip:sip:+18001234567@example.com; user=3Dphone;p=3Dx > > > > > > Privacy: history > > > > > > History-Info: > > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 > = ;index=3D= 1;rt; > > > > > > ao > > > > > > r > > > > > > History-Info: = ;index=3D1.1;mp;aor > > > > > > History-Info: ;index=3D1.1.1;rc > > > > > > > > > > > > This would result in all the H-I entries except (1) being > > > > > considered > > > > > > private with the result that the =3D1800... Number is > > > > passed for call > > > > > > handling purposes. > > > > > > > > > > > > This change is backward compatible with the existing > > > > > implementation as > > > > > > any node using the existing functionality as defined in > > > > > RFC4244 will > > > > > > continue to be supported. > > > > > > > > > > > > The alternative is to remove the ability to include the > > > > > value "history" > > > > > > in the Privacy header and only allow this value in the > > > > > Privacy header > > > > > > parameter. This alternative is not backward compatible. > > > > > > > > > > > > Without this change a single node in the message path which > > > > > includes a > > > > > > header "Privacy: history" will prevent delivery of the > > > > aor and thus > > > > > > prevent proper call handling. > > > > > > > > > > > > Ian Elz > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Christer Holmberg > > > > > > Sent: 23 June 2009 19:40 > > > > > > To: 'Mary Barnes'; Francois Audet; Hans Erik van > > Elburg; Shida > > > > > > Schubert > > > > > > Cc: Ian Elz > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > =20 > > > > > > Hi, > > > > > > > > > > > > I include Ian, so he can comment to your resposne himself. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > > > > Sent: Tuesday, June 23, 2009 9:40 PM > > > > > > To: Christer Holmberg; Francois Audet; Hans Erik van > > > > Elburg; Shida > > > > > > Schubert > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > Here was the thread of response and the last comment was > > > > > from Ian that > > > > > > he would consider the response: > > > > > >=20 > http://www.ietf.org/mail-archive/web/sip/current/msg26948.html > > > > > > > > > > > > And, there was not agreement on the "none" but rather to > > > > > qualify the > > > > > > SHOULD NOT forward. However, in the sipcore-4244bis-00, > > > > > rather than > > > > > > changing the text such that the headers SHOULD be=20 > removed, we=20 > > > > > > recommend that they be anonymized (in section 4.3.3.3.1). > > > > That is > > > > > > entirely consistent with RFC 3324 and thus we have > > removed the > > > > > > recommendations to remove the headers entirely. However, > > > > > that changed > > > > > > never got done in section 3.2, so we would need to > > change this: > > > > > > "Thus, the History- Info header > > > > > > SHOULD NOT be included in Requests where the requestor > > > > > has indicated > > > > > > a priv-value of Session- or Header-level privacy." > > > > > > > > > > > > But, I'm really beginning to be of the mindset that we > > > > should just > > > > > > remove all the subsections of section 3 (i.e., leave the > > > > > text in the > > > > > > upper level section), so we don't have to keep=20 > worrying about=20 > > > > > > consistency. > > > > > > > > > > > > So, lets either fixt the text in 3.2 or remove altogether > > > > > and then I > > > > > > think we are really at the point of needing to submit this > > > > > version so > > > > > > folks that actually have an interest in it can review > > > the updated > > > > > > document. > > > > > > > > > > > > Mary.=20 > > > > > > > > > > > > -----Original Message----- > > > > > > From: Christer Holmberg > > [mailto:christer.holmberg@ericsson.com] > > > > > > Sent: Tuesday, June 23, 2009 1:10 PM > > > > > > To: Barnes, Mary (RICH2:AR00); Audet, Francois > > > > > (SC100:3055); Hans Erik > > > > > > van Elburg; Shida Schubert > > > > > > Subject: 4244bis and privacy > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > Below is a comment/proposal which one of my collegues (Ian > > > > > Elz) gave > > > > > > on the list a while ago, when the first version of > > 4244bis was > > > > > > submitted, but was not incorporated. Do you think it would > > > > > be useful? > > > > > > > > > > > > ------- > > > > > > > > > > > > While the HI approach to target may solve the problem of > > > > > being able to > > > > > > deliver the target URI to the final destination there is no > > > > > guarantee > > > > > > that it will actually be delivered. > > > > > > > > > > > > The problem arises with how Privacy is defined for HI. > > > > > > > > > > > > 4424 defines a new Privacy value "history" which may be > > > placed in > > > > > > either the Privacy header or as a header parameter to the > > > > HI entry. > > > > > > > > > > > > If one node uses the former option "Privacy: history" then > > > > > this will > > > > > > make all headers private and will result in all HI > > > entries being > > > > > > removed or made anonymous when the message containing > > the HI is > > > > > > delivered to the user. > > > > > > > > > > > > There is a simple solution to this and that is to also > > > > > allow the use > > > > > > of the "none" Privacy value as a header parameter in the > > > > HI entry.=20 > > > > > > This would explicitly state that no privacy is required > > > to the HI > > > > > > entry and this would override a "history" value in the > > > > > Privacy header. > > > > > > > > > > > > I pointed this out to Mary when the 4424bis draft was first > > > > > published > > > > > > but the change has not been made in the latest draft. > > > > > > > > > > > > The change is backward compatible and would not cause an > > > > issue with > > > > > > any existing implementations. > > > > > > > > > > > > ------ > > > > > > > > > > > > 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 > > > > > > =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 > > >=20 > >=20 >=20 From dworley@nortel.com Wed Jul 1 12:21:14 2009 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 A70D13A6B24 for ; Wed, 1 Jul 2009 12:21:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.717 X-Spam-Level: X-Spam-Status: No, score=-6.717 tagged_above=-999 required=5 tests=[AWL=-0.118, 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 sPGS0u3agH+E for ; Wed, 1 Jul 2009 12:21:14 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id BA1223A67E4 for ; Wed, 1 Jul 2009 12:21:13 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n61JJTq01180 for ; Wed, 1 Jul 2009 19:19:29 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 1 Jul 2009 15:21:00 -0400 From: "Dale Worley" To: SIPCORE Content-Type: text/plain Organization: Nortel Networks Date: Wed, 01 Jul 2009 15:20:59 -0400 Message-Id: <1246476059.3751.63.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jul 2009 19:21:00.0086 (UTC) FILETIME=[11119560:01C9FA81] 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: Wed, 01 Jul 2009 19:21:14 -0000 I am eager to see draft-barnes-sipcore-rfc4244bis progress, as it appears to be a mechanism that can solve a great number of problems (some of which are yet to appear fully). Because History-Info can record multiple retargeting events, it can handle situations where there are multiple interacting services. I see that as essential to support the complex scenarios that "next generation" networks will need to support. I do see some problems in the exposition, and I will propose improvements to the wording. Is a -02 version in the works? Dale From gonzalo.camarillo@ericsson.com Wed Jul 1 12:48:11 2009 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 5FA4F3A68B4 for ; Wed, 1 Jul 2009 12:48:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.249 X-Spam-Level: X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 PjWmyj6MtxMl for ; Wed, 1 Jul 2009 12:48:10 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id CE4613A67D9 for ; Wed, 1 Jul 2009 12:48:06 -0700 (PDT) X-AuditID: c1b4fb3c-b7bdcae0000052f9-0a-4a4bbd77c480 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 1B.42.21241.77DBB4A4; Wed, 1 Jul 2009 21:48:07 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Jul 2009 21:48:00 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 1 Jul 2009 21:48:00 +0200 Received: from [131.160.126.222] (rvi2-126-222.lmf.ericsson.se [131.160.126.222]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 76854246A; Wed, 1 Jul 2009 22:48:00 +0300 (EEST) Message-ID: <4A4BBD70.1020905@ericsson.com> Date: Wed, 01 Jul 2009 22:48:00 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Vijay Gurbani References: <4A49AC25.7010602@alcatel-lucent.com> In-Reply-To: <4A49AC25.7010602@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jul 2009 19:48:00.0473 (UTC) FILETIME=[D6E50490:01C9FA84] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] I-D on TCP/SCTP connection reuse 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, 01 Jul 2009 19:48:11 -0000 Hi Vijay, > At this point, we are > not sure where to target it -- sipcore is probably the closest. when you are not sure where a new draft belongs, it is usually a good idea to send it to the DISPATCH list. As you have seen, discussions on how to dispatch new items can happen fairly quickly. Cheers, Gonzalo From AUDET@nortel.com Wed Jul 1 14:38:07 2009 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 C3B033A6A45 for ; Wed, 1 Jul 2009 14:38:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.365 X-Spam-Level: X-Spam-Status: No, score=-6.365 tagged_above=-999 required=5 tests=[AWL=0.234, 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 Ts9YGry6LY+r for ; Wed, 1 Jul 2009 14:38:07 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id C43BB3A68FA for ; Wed, 1 Jul 2009 14:38:06 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n61LcDG28657 for ; Wed, 1 Jul 2009 21:38:14 GMT 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, 1 Jul 2009 16:37:00 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EC8B13D@zrc2hxm0.corp.nortel.com> In-Reply-To: <1246476059.3751.63.camel@victoria-pingtel-com.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis thread-index: Acn6gSxmrpxRRyCuSqCBonT4/aliuwAEnUkg References: <1246476059.3751.63.camel@victoria-pingtel-com.us.nortel.com> From: "Francois Audet" To: "Dale Worley" , "SIPCORE" 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: Wed, 01 Jul 2009 21:38:07 -0000 Yes, there is an -02 in the works, to be published before Stockholm. I am planning to submit it soon. In the meanwhile, you can access a draft here: http://svn.resiprocate.org/rep/ietf-drafts/audet/draft-barnes-sipcore-rfc= 4244bis-02.txt > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Worley, Dale=20 > (BL60:9D30) > Sent: Wednesday, July 01, 2009 12:21 > To: SIPCORE > Subject: [sipcore] draft-barnes-sipcore-rfc4244bis >=20 > I am eager to see draft-barnes-sipcore-rfc4244bis progress,=20 > as it appears to be a mechanism that can solve a great number=20 > of problems (some of which are yet to appear fully). Because=20 > History-Info can record multiple retargeting events, it can=20 > handle situations where there are multiple interacting=20 > services. I see that as essential to support the complex=20 > scenarios that "next generation" networks will need to support. >=20 > I do see some problems in the exposition, and I will propose=20 > improvements to the wording. >=20 > Is a -02 version in the works? >=20 > Dale >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From ietf.hanserik@gmail.com Thu Jul 2 01:03:38 2009 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 94EE93A6A9D for ; Thu, 2 Jul 2009 01:03:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.972 X-Spam-Level: X-Spam-Status: No, score=-1.972 tagged_above=-999 required=5 tests=[AWL=-0.342, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_74=0.6, URI_HEX=0.368] 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 QiXJWWoAnHwq for ; Thu, 2 Jul 2009 01:03:32 -0700 (PDT) Received: from mail-ew0-f210.google.com (mail-ew0-f210.google.com [209.85.219.210]) by core3.amsl.com (Postfix) with ESMTP id 7C9203A67B2 for ; Thu, 2 Jul 2009 01:03:31 -0700 (PDT) Received: by ewy6 with SMTP id 6so1864506ewy.37 for ; Thu, 02 Jul 2009 01:03:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=PbLrNn4kLoc2/HTtD9mZvJGIKlqBG8KOE8AbA4Zn3/M=; b=aDxggdBpxu/1hcmKqElYPEHsIKIrqOu/wkVMcD1t+rJmJhJp7keu/IlqEXIEWz4GrU 5nG/Sgp5ZKiDcOgmkjjiCbgBQ0AMwL+T1/fghqcCwMr5uCUyDnuAqR1xkgl2b1F/CMh/ 1iYVBfiXxsUv9z2tnxjJShgKox5FI+tyRiuxQ= 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=UtGVS/wZmicsvX+ZBuS/ElxFQ6iWww7wxyNBAtdkZFmhosRNgqTg2sJjIMMrnCxx1s RLprF8rEMENQmY2/Qbn/WsOc2lRh9vORIWFZwUjxN+JRXiRrwaSxO7aKrXyB4NX9phnJ T4mx2186l0ai+/sosCXGbsRNmYXtf2Z0aueyw= MIME-Version: 1.0 Received: by 10.210.70.8 with SMTP id s8mr543149eba.54.1246521819711; Thu, 02 Jul 2009 01:03:39 -0700 (PDT) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EC8AD11@zrc2hxm0.corp.nortel.com> References: <9886E5FCA6D76549A3011068483A4BD4048F809B@S4DE8PSAAQB.mitte.t-com.de> <4A43DEC9.1020802@gmail.com> <9886E5FCA6D76549A3011068483A4BD4048F80AC@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1EB26AB5@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D00213AA4C@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1EBE2181@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D00213B56F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1EC8AD11@zrc2hxm0.corp.nortel.com> Date: Thu, 2 Jul 2009 10:03:39 +0200 Message-ID: <9ae56b1e0907020103s1cd95dc7jf61d26c025e14602@mail.gmail.com> From: Hans Erik van Elburg To: Francois Audet Content-Type: multipart/alternative; boundary=0015174c3c6a44caaf046db47af7 Cc: sipcore@ietf.org, R.Jesske@telekom.de, Ian Elz , shida@agnada.com Subject: Re: [sipcore] 4244bis and privacy 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, 02 Jul 2009 08:03:38 -0000 --0015174c3c6a44caaf046db47af7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes I think I do agree with you. /Hans Erik van Elburg On Wed, Jul 1, 2009 at 8:42 PM, Francois Audet wrote: > I see another problem with Privacy in RFC 4244. > > Currently, it talks about "Session" Privacy impacting HI and says nothing > about > "User" privacy impacting HI. (see RFC 3323) > > This makes no sense to me. Session is supposed to relate strictly > to SDP-level information (i.e., IP address inside SDP, and maybe some > other fields). > > I don't see at all why "session" would mean don't do HI. > > On the other hand 4244 is silent about "User" Privacy. I belive if > "user privacy" is used, then defintively it implies the URIs representing > that user should be anonymized. > > Views? > > > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Tuesday, June 30, 2009 00:30 > > To: Audet, Francois (SC100:3055); Ian Elz; Barnes, Mary > > (RICH2:AR00); R.Jesske@telekom.de; ietf.hanserik@gmail.com > > Cc: sipcore@ietf.org; shida@agnada.com > > Subject: RE: [sipcore] 4244bis and privacy > > > > Yes, I think something like this makes sense. > > > > John > > > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortel.com] > > > Sent: 30 June 2009 00:06 > > > To: Ian Elz; Elwell, John; Mary Barnes; R.Jesske@telekom.de; > > > ietf.hanserik@gmail.com > > > Cc: sipcore@ietf.org; shida@agnada.com > > > Subject: RE: [sipcore] 4244bis and privacy > > > > > > I think the current "interpretation" is not terribly > > useful. I prefer > > > your suggestion. The current RFC 4244 text is not very clear. > > > > > > It seems to me that: > > > - Privacy should associated with a specific hi-entry (and > > perhaps any > > > entry that corresponds to that same user), and not the header > > > itself. > > > - That way, it is possible that specific entries be > > anonymize, but not > > > others. For example, if you call me without privacy, and I call > > > forward > > > you to John with privacy setup for myself, John should > > see an entry > > > for > > > you and an anonymized entry for me. > > > - There is no reason why "none" couldn't be used in this context. > > > Again, > > > with the same example as above, John could requies "none" > > > for him, and > > > I could set privacy on for myself. > > > > > > I don't think this type of rule for 4244bis would require > > any change > > > whatsoever to RFC 3323. It would be completely self-contained in > > > 4244bis. > > > > > > Comments? > > > > > > > -----Original Message----- > > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > > Sent: Monday, June 29, 2009 03:26 > > > > To: Audet, Francois (SC100:3055); Elwell, John; Barnes, Mary > > > > (RICH2:AR00); R.Jesske@telekom.de; ietf.hanserik@gmail.com > > > > Cc: sipcore@ietf.org; shida@agnada.com > > > > Subject: RE: [sipcore] 4244bis and privacy > > > > > > > > Francios, > > > > > > > > I agree that 4244bis should not specify the actions of > > proxies etc > > > > where this is a matter of local policy. > > > > > > > > My original proposed change was to allow the inclusion of > > the value > > > > "none" in the alongside the value "history" to be included in the > > > > Privacy header parameter escaped in the > > hi-targeted-to-uri. (RFC4244 > > > > section 4.1) > > > > > > > > It appears however that the current interpretation of the Privacy > > > > header means that the value included in the Privacy > > header, which is > > > > applicable to the originating rather than retargeting user is > > > > applied to the retargeting user rather than the explicit value > > > > included for the retargeting user. > > > > The escaped privacy value is only used if there is no > > Privacy header > > > > or the Privacy header only contains the value "user". > > > > > > > > The end result of this interpretation is that including > > an explicit > > > > value "none" escaped as a Privacy parameter would have no > > effect and > > > > would have the same meaning as not including a Privacy header > > > > parameter escaped in the hi-targeted-to-uri. > > > > > > > > 4244bis is not the place to extend the sip Privacy handling to > > > > specify how 3rd party identities in sip messages should > > have their > > > > own specific privacy maintained. > > > > > > > > Allowing the inclusion of the explicitly Privacy=3Dnone > > value in the > > > > hi-targeted-to-uri would not change any handling at this time but > > > > would make the new H-I RFC suitable for use if an updated privacy > > > > RFC is proposed which does have specific support for 3rd party > > > > identities. > > > > > > > > H-I is not the only place where the explicit privacy of 3rd party > > > > identities is required. The Referred-By header is one other case > > > > where a similar explicit privacy may need to be considered in the > > > > future. > > > > > > > > regards > > > > > > > > Ian > > > > > > > > -----Original Message----- > > > > From: Francois Audet [mailto:audet@nortel.com] > > > > Sent: 26 June 2009 16:55 > > > > To: Ian Elz; Elwell, John; Mary Barnes; R.Jesske@telekom.de; > > > > ietf.hanserik@gmail.com > > > > Cc: sipcore@ietf.org; shida@agnada.com > > > > Subject: RE: [sipcore] 4244bis and privacy > > > > > > > > I do see things that we should fix right-away in History-Info, > > > > regarding privacy. > > > > > > > > I also think that History-Info shouldn't "overstrech" and get too > > > > deep into the nitty gritty of privacy. What should be in > > HI is high > > > > level guidance. > > > > > > > > In section 3.1, for example, it says that Privacy header will > > > > determine if a History-Info *header field* can be included by an > > > > intermediary. This does not make any sense. What it should say is > > > > that the Privacy header will determine if a history-info > > *entry* can > > > > be added for the UA inserting the Privacy header. > > > > > > > > So, in my opinion, we can go ahead and fix that right now. > > > > > > > > I don't think we need to get into super low-level procedural > > > > descriptions of the type "proxy MUST this and that if Privacy =3D= =3D > > > > this and that". I believe privacy matters are > > policy-level decisions > > > > that service providers and enteprises will have, and they are not > > > > going to be implemented by simplistic procedural rules > > from an RFC. > > > > > > > > Comments? > > > > > > > > > > > > > -----Original Message----- > > > > > From: sipcore-bounces@ietf.org > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Ian Elz > > > > > Sent: Friday, June 26, 2009 01:08 > > > > > To: Elwell, John; Barnes, Mary (RICH2:AR00); > > R.Jesske@telekom.de; > > > > > ietf.hanserik@gmail.com > > > > > Cc: sipcore@ietf.org; shida@agnada.com > > > > > Subject: Re: [sipcore] 4244bis and privacy > > > > > > > > > > John, > > > > > > > > > > Your statement " not anonymise or remove any information > > > > that the UAC > > > > > has already placed in the request " is the key here. > > > > > > > > > > The UAC has not included the H-I entry, particularly the one > > > > > containing the identity of the diverting party. > > > > > > > > > > This was not considered in RFC3323 and we have an issue > > where we > > > > > cannot determine which entity included which information. > > > > > This creates a problem where a restriction by the > > > originating party > > > > > will prevent a downstream identity from permitting > > > presentation of > > > > > their identity. > > > > > > > > > > I agree with Mary that this probably requires an update to > > > > > RFC3323 so we should start by updating RFC3323 and then > > > > move on to the > > > > > other impacted RFCs. The issue that this will raise for > > > H-I is that > > > > > there will be another change required after the Privacy RFC > > > > has been > > > > > agreed. > > > > > > > > > > This is far from ideal but the 4424bis draft contains a lot > > > > more than > > > > > just this issue. > > > > > > > > > > Ian > > > > > > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > > Sent: 26 June 2009 08:30 > > > > > To: Mary Barnes; R.Jesske@telekom.de; ietf.hanserik@gmail.com > > > > > Cc: Ian Elz; sipcore@ietf.org; shida@agnada.com > > > > > Subject: RE: [sipcore] 4244bis and privacy > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: sipcore-bounces@ietf.org > > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > > > > > > Sent: 25 June 2009 22:45 > > > > > > To: R.Jesske@telekom.de; ietf.hanserik@gmail.com > > > > > > Cc: ian.elz@ericsson.com; sipcore@ietf.org; shida@agnada.com > > > > > > Subject: Re: [sipcore] 4244bis and privacy > > > > > > > > > > > > Roland, > > > > > > > > > > > > The reason you can't have "none" at the request level and > > > > > "history" at > > > > > > the entry level is because RFC 3323 states that you MUST > > > > NOT apply > > > > > > privacy to the message. Even if you put "history" in the > > > > > entries, the > > > > > > privacy service would just ignore that - per RFC 3323. > > > > So, if you > > > > > > want to change that behavior, then RFC 3323 should be > > > > > changed - i.e., > > > > > > the MUST NOT for the "none" could be changed to a SHOULD > > > > > NOT and then > > > > > > a general statement about possible exceptions. Then, we > > > could add > > > > > > something to RFC 4244 for this case. But, changing RFC > > > > > > 3323 is totally out of scope for what we are currently > > > > working on. > > > > > [JRE] I would interpret privacy 'none' in RFC 3323 as > > > > meaning that a > > > > > downstream entity must not anonymise or remove any > > > information that > > > > > the UAC has already placed in the request. > > > > > If a downstream entity chooses: > > > > > - not to add H-I, > > > > > - to add anonymised H-I, or > > > > > - to anonymise an H-I entry that some intermediate entity > > > > has added, I > > > > > don't see that as being in violation of what the UAC has > > > requested. > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > > > That all said, I would sure think that if you are leaving a > > > > > "trusted > > > > > > network" that you have a B2BUA in there, as I've said > > in other > > > > > > threads. Thus, the B2BUA builds a new request and certainly > > > > > can add a > > > > > > privacy header that it believes is appropriate since > > > the outgoing > > > > > > request is done by the UAC function of a B2BUA. > > > > > > > > > > > > Mary. > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > > > > > > Sent: Thursday, June 25, 2009 4:32 PM > > > > > > To: ietf.hanserik@gmail.com > > > > > > Cc: Barnes, Mary (RICH2:AR00); ian.elz@ericsson.com; > > > > > sipcore@ietf.org; > > > > > > shida@agnada.com > > > > > > Subject: AW: [sipcore] 4244bis and privacy > > > > > > > > > > > > Hi Hans Erik, > > > > > > We have also to take regulatory into consideration. In > > > > Germany the > > > > > > last trusted network is responsible for anonymising > > information. > > > > > > > > > > > > But nevertheless if Network provider A wants to have History > > > > > > completely private this operator will set privacy > > > history for the > > > > > > header. > > > > > > If the succeeding Operator want to present elements the AS > > > > > which adds > > > > > > a entry has then to re label all entries from the > > > > preceding network > > > > > > and the entries from it's own network will be unmarked > > > within the > > > > > > Header. > > > > > > > > > > > > But never the less I fully agree to your last sentence. > > > > > > > > > > > > The real Question is if this should really be allowed > > > > that a entry > > > > > > marked with "none" overrules the privacy statement > > > > > "history" for the > > > > > > complete header. > > > > > > > > > > > > I'm against this behaviour. > > > > > > > > > > > > Best Regards > > > > > > > > > > > > Roland > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > > Von: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > > > > > Gesendet: Donnerstag, 25. Juni 2009 22:32 > > > > > > An: Jesske, Roland > > > > > > Cc: mary.barnes@nortel.com; ian.elz@ericsson.com; > > > > sipcore@ietf.org; > > > > > > shida@agnada.com > > > > > > Betreff: Re: [sipcore] 4244bis and privacy > > > > > > > > > > > > Hi Roland, > > > > > > > > > > > > I don't understand the argument, by the time that the > > > > History-Info > > > > > > leaves operator A that wishes complete privacy, all the > > > > > History-Info > > > > > > headers should be anonymised according to 4244 and 4244bis. > > > > > > > > > > > > What is the point in mandating that operator A to force > > > > > operator B to > > > > > > also anonymise the entries "owned" by operator B. > > > > > > > > > > > > It is of course without question that each operator has > > > > > full privacy > > > > > > control over its own added entries. And each operator can > > > > based on > > > > > > local policy decide to remove the entire history if it > > > > > things that is > > > > > > wise to do. > > > > > > > > > > > > /Hans Erik > > > > > > > > > > > > > > > > > > R.Jesske@telekom.de wrote: > > > > > > > Hi Marry and Ian, > > > > > > > The whole discussion puzzle me. We have specified CDIV > > > > > > within TISPAN and 3GPP. > > > > > > > There is described that privacy "none" can be used for > > > > > > entries. BUT assuming that each entry has its own privacy > > > > > statement if > > > > > > needed. > > > > > > > I fully agree on Mary's comment that a privacy "history" > > > > > > cannot overruled by a privacy value "none" within a entry. > > > > > > > There may be operators that would like to keep the whole > > > > > > History Info private even if entries has other > > > statements, so the > > > > > > entity could add privacy history to the whole header. > > > > > > Nothing more. > > > > > > > > > > > > > > On the other side a Application Server including a entry > > > > > > should have the possibility to rewrite the entries so that > > > > > instead of > > > > > > "history" for the whole header the all received entries > > > > within the > > > > > > History-Info header will be marked with "history" and the > > > > > added header > > > > > > (which shall be presented to the terminating user) will > > > either be > > > > > > marked with "none" or will not be marked. > > > > > > > > > > > > > > Perhaps a hint could be given, but I do not insist on it. > > > > > > > > > > > > > > Best Regards, > > > > > > > > > > > > > > Roland > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > > > Von: sipcore-bounces@ietf.org > > > > > [mailto:sipcore-bounces@ietf.org] Im > > > > > > > Auftrag von Mary Barnes > > > > > > > Gesendet: Donnerstag, 25. Juni 2009 18:29 > > > > > > > An: Ian Elz > > > > > > > Cc: sipcore@ietf.org; Shida Schubert > > > > > > > Betreff: Re: [sipcore] 4244bis and privacy > > > > > > > > > > > > > > Hi Ian, > > > > > > > > > > > > > > Responses inline below [MB2]. > > > > > > > > > > > > > > Mary. > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > > > > > Sent: Thursday, June 25, 2009 10:13 AM > > > > > > > To: Barnes, Mary (RICH2:AR00) > > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida > > Schubert; > > > > > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > > > Mary, > > > > > > > > > > > > > > I am a little concerned about one answer that you gave: > > > > > > > > > > > > > > > > > > > > > If you have a Privacy header with a value of "none" and a > > > > > H-I entry > > > > > > > with Privacy header parameter with value "history" what is > > > > > > the privacy > > > > > > > of the individual H-I entry? > > > > > > > [MB] We did not explicitly address the "none" in RFC > > > > > 4244, but the > > > > > > > general statement is the privacy headers at the request > > > > > > level override > > > > > > > any at the hi-entry level. [/MB] > > > > > > > > > > > > > > This means that if privacy is required for an individual > > > > > > H-I entry but > > > > > > > the originating user included "Privacy:none" in the request > > > > > > then there > > > > > > > is no option to include the real URI in the H-I entry. > > > > > > > [MB2] I'm confused here - the "none" definition is as you > > > > > > note below, > > > > > > > thus "none" prohibits the removal or anonymization of the > > > > > entries, > > > > > > > thus I would think you would fine this functionality > > > desireable. > > > > > > > However, this does not prohibit an entity based on policy > > > > > > to anonymize > > > > > > > (or remove entries if privacy is required for that > > > > domain if the > > > > > > > entity does not have access to a privacy service). [/MB2] > > > > > > > > > > > > > > This occurs as RFC3323 states in section 4.3: "However, if > > > > > > the Privacy > > > > > > > header value of 'none' is specified in a message, privacy > > > > > services > > > > > > > MUST NOT perform any privacy function and MUST NOT remove > > > > > or modify > > > > > > > the Privacy header." > > > > > > > > > > > > > > The only option for an intermediate node including a H-I > > > > > > entry where > > > > > > > "Privacy:none" is specified and privacy for the H-I URI is > > > > > > required is > > > > > > > to include an anonymous entry or not include the H-I entry. > > > > > > > [MB2] If privacy is required then yes, you include > > > > > > anonymous entries > > > > > > > or don't include. That's the basic privacy mechanism > > > > for privacy > > > > > > > levels of "session" "header" and "history" in the R-URI or > > > > > > "history" > > > > > > > in the specific entries, as well as when there is a policy > > > > > > for privacy > > > > > > > for the entries added by a specific domain. The "none" > > > > > > really has no > > > > > > > influence on the later case per se. [/MB2] > > > > > > > > > > > > > > In your previous response you stated that we would violate > > > > > > RFC3323 if > > > > > > > we specified additional behaviour for privacy explicitly > > > > > > stated with a > > > > > > > URI -n the H-I entry. I don't believe that this is the case > > > > > > as RFC3323 > > > > > > > only considered privacy in a two party scenario and did not > > > > > > consider > > > > > > > third party identities being included in a message > > > between two > > > > > > > parties. H-I is not the only case where this occurs as the > > > > > > Referred-By > > > > > > > header when included in the INVITE (or other request) > > > > > which results > > > > > > > from the REFER has the same issue. > > > > > > > [MB2] I can't necessarily disagree on this one (we can > > > > debate it > > > > > > > either way). But to fix it requires an update to > > RFC 3323 and > > > > > > > shouldn't be something that we want to fix in > > 4244bis. [/MB2] > > > > > > > > > > > > > > RFC4244 was the first time that there was a recognition > > > > > > that privacy > > > > > > > for these individual third party identities may be > > > > > > required. To allow > > > > > > > this explicit statement of privacy to be overridden by > > > > a generic > > > > > > > statement which is applicable to a different user is > > > > > > counterintuitive. > > > > > > > [MB2] See my comment above. But, as I have consistently > > > > > > said, the idea > > > > > > > that an entity might want to override the "none" is > > > > > > entirely based on > > > > > > > policy and 4244 and 4244bis allow privacy to be applied to > > > > > > the entries > > > > > > > that are added by that entity if the policy dictates > > > so (and we > > > > > > > already say that). [/MB2] > > > > > > > > > > > > > > The original Privacy header is usually included by or on > > > > > > behalf of the > > > > > > > originating user and should not be allowed to specify the > > > > > > privacy of > > > > > > > the original called user, e.g. the 800 number, and > > > prevent this > > > > > > > identity being presented if this user does not have the > > > > > > same level of privacy. > > > > > > > [MB2] As I tried to say in a previous response, a random > > > > > > entity (i.e., > > > > > > > one for whom the R-URI is not in a domain under its > > > > > control) cannot > > > > > > > add a privacy header to the Request. Per RFC 3323 an > > > > > entity may add > > > > > > > the header to a request only if it has the appropriate > > > > > > > relationship/authorization with the original called user > > > > > > who intiated > > > > > > > the request. And, I would find it very surprising if an > > > > > entity that > > > > > > > did have responsibility would apply privacy since > > > that would be > > > > > > > counter intuitive and I would hope that SPs would be > > > > judicious in > > > > > > > specifying the appropriate and inappropriate manner in > > > > which the > > > > > > > proxies they deploy and interface with privatize the > > > > > messages. The > > > > > > > protocol CANNOT control this behavior and that's why > > > > there is the > > > > > > > policy clause in 4244 and 4244bis. [/MB2] > > > > > > > > > > > > > > The real issue with the 800 scenario is as you have stated > > > > > > is that the > > > > > > > answerer will not know the original called identity and > > > > > will not be > > > > > > > able to correctly handle the call. As more generic call > > > > > centres are > > > > > > > used which will answer calls on behalf of many different > > > > > > organizations > > > > > > > using CTI and the original called identity to have to > > > > implement a > > > > > > > generic system asking the caller who he originally > > > > called appear > > > > > > > unprofessional, is inefficient and unproductive. > > > > > > > [MB2] And, as I noted, it is rare for a call centre to > > > > > route a call > > > > > > > directly to an agent without a user providing some sort of > > > > > > input. Even > > > > > > > companies like American Airlines, even though they have the > > > > > > info that > > > > > > > I enter via the IVR, they still ask some basic questions > > > > > > and there are > > > > > > > times when they have to reroute me. I don't think we > > > > can totally > > > > > > > automate things. And, again, once the call hits the > > > > > domain that is > > > > > > > responsible for that 800 number the entities in that > > > > domain have > > > > > > > control over how they muck with the R-URI, such that they > > > > > should be > > > > > > > able to use any IVR info to appropriately direct the call - > > > > > > it's not > > > > > > > the number that's meaningful, but how the system gets the > > > > > > call to the > > > > > > > right user and the additional information they provide as > > > > > > the call is > > > > > > > presented to the agent. I would honestly think that having > > > > > > something > > > > > > > other than an 800 number show up on the display would > > > > be far more > > > > > > > useful and in my experience in the systems I developed > > > > > > we're usually > > > > > > > talking about CTI interfaces so you have a lot you can > > > > do. And, > > > > > > > actually all of this really doesn't matter in that you MUST > > > > > > be able to > > > > > > > handle this situation independent of the privacy since > > > > > > History-Info is > > > > > > > optional, you need default behavior assigned. [/MB2] > > > > > > > > > > > > > > We have an opportunity to allow presentation of specific > > > > > identities > > > > > > > and to solve this particular problem so we should take it. > > > > > > > [MB2] The most we can do is to document the risks/impacts > > > > > > of the use > > > > > > > of the Privacy headers at the R-URI level. There is > > > > > already general > > > > > > > text in > > > > > > > 4244 and 4244bis that the privacy may impact whether the > > > > > > applications > > > > > > > get the information. And, as I noted before, most > > > > > > commercial systems > > > > > > > are using B2BUAs which will allow you far more control over > > > > > > the use of > > > > > > > the Privacy headers in the network. But, again, I don't > > > > > > think that's > > > > > > > something that should be address in 4244bis. [/MB2] > > > > > > > > > > > > > > I hope that we can get some wider discussion on this issue > > > > > > so a more > > > > > > > general consensus can be obtained. > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Ian > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > > > > > Sent: 24 June 2009 17:27 > > > > > > > To: Ian Elz > > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida > > Schubert; > > > > > > > sipcore@ietf.org; Francois Audet > > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > > > Hi Ian, > > > > > > > > > > > > > > Responses inline below [MB]. > > > > > > > > > > > > > > Mary. > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > > > > > Sent: Wednesday, June 24, 2009 10:37 AM > > > > > > > To: Barnes, Mary (RICH2:AR00) > > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida > > Schubert; > > > > > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > > > Mary, > > > > > > > > > > > > > > I was not proposing that we change the handling of H-I > > > > > > which is based > > > > > > > upon local policy. If that causes an issue for a network > > > > > > operator then > > > > > > > they can modify their local policy accordingly or arrange > > > > > with the > > > > > > > proxy vendor to modify their equipment to be more > > > flexible with > > > > > > > regards to policy. > > > > > > > > > > > > > > Can you clarify for me: > > > > > > > > > > > > > > If you have a Privacy header with either "session" or > > > > > "header" doe > > > > > > > this impact the H-I entries or will only a value of > > > > > > "history" impact > > > > > > > the H-I entries? > > > > > > > [MB] Yes, both "session" and "header" level privacy, > > > > > > consistent with > > > > > > > RFC 3323, mandate that entries be anonymized or > > > > dropped, with the > > > > > > > latter being the recommendation for "session" level > > > > > > privacy. RFC 4244 > > > > > > > mandated that they be dropped and 4244bis > > recommends they be > > > > > > > anonymized. The original intent for the value of "history" > > > > > > was for the > > > > > > > tagging of the individual entries, but you end up getting > > > > > > the header > > > > > > > level functionality as well. [/MB] > > > > > > > > > > > > > > If you have a Privacy header with a value of "none" and a > > > > > H-I entry > > > > > > > with Privacy header parameter with value "history" what is > > > > > > the privacy > > > > > > > of the individual H-I entry? > > > > > > > [MB] We did not explicitly address the "none" in RFC > > > > > 4244, but the > > > > > > > general statement is the privacy headers at the request > > > > > > level override > > > > > > > any at the hi-entry level. [/MB] > > > > > > > > > > > > > > From reading RFC4244 a Privacy header with value > > > "history" will > > > > > > > effectively make all H-I entries private and there is > > > > > currently no > > > > > > > option to include a H-I Privacy header parameter with > > > > > value "none". > > > > > > > [MB] Correct, per my comment above. [/MB] > > > > > > > > > > > > > > H-I at present allows the inclusion of Privacy header > > > > > parameters to > > > > > > > explicitly express privacy for an individual H-I entry > > > > > but a single > > > > > > > node which includes a header "Privacy: history" makes all > > > > > > H-I entries > > > > > > > private even if this is not the requirements for the > > > > specific URI. > > > > > > > [MB] Correct, but the only node that should add the header > > > > > > is a node > > > > > > > which is responsible for the domain associated with the > > > > > > Request URI in > > > > > > > the incoming request or is authorized to do so. [/MB] > > > > > > > > > > > > > > I will admit that having worked in a telephony environment > > > > > > for a long > > > > > > > time I am used to having privacy of identities set on a > > > > > per number > > > > > > > basis and the relative inflexibility of the IETF Privacy > > > > > header is > > > > > > > relatively restrictive as to specifying which > > > identities may be > > > > > > > presented and which not. > > > > > > > [MB] Yes, this is an entirely different paradigm. I > > > developed > > > > > > > telephony s/w for over a decade and this is entirely > > > > > different - it > > > > > > > provides a lot more flexibility, which makes things > > > > far, far less > > > > > > > deterministic than what you have in telephony switches > > > > where your > > > > > > > routing and translations are configured for the most part, > > > > > > with just a > > > > > > > few capabilities for controlling the privacy and it's a > > > > > > closed network. > > > > > > > > > > > > > > With RFC4244/4244bis, there MUST be a mechanism at the > > > > UAS or end > > > > > > > application that can handle a request that doesn't have the > > > > > > > appropriate information either because nodes didn't support > > > > > > > History-Info or some random node in the network applied > > > > > > privacy (which > > > > > > > I think is highly > > > > > > > unlikely) - this is normative per section 5 of RFC > > > > 4244. So, the > > > > > > > worst case scenario I see for this 800 service (which will > > > > > > get to the > > > > > > > right UAS but without the exact 800 number that was dialed) > > > > > > is that it > > > > > > > goes to a default ACD group/customer service agent, > > > > etc. who then > > > > > > > needs to gather the appropriate information and in my > > > > > > experience this > > > > > > > is often an IVR system these days. So, the service is not > > > > > > broken when > > > > > > > privacy is applied in an undesireable manner, it's just not > > > > > > optimal. > > > > > > > This is something that should be addressed in the > > > > > target-uri draft > > > > > > > which has all the details of how specific services use > > > > > History-Info. > > > > > > > One other thing to consider is that most networks that are > > > > > > emulating > > > > > > > telephony type features use B2BUAs, which follow the > > > > > > UAS/UAC rules for > > > > > > > the header rather than the proxy rules, noting that the > > > > > UAC can set > > > > > > > the Privacy header to whatever value it sees as appropriate > > > > > > for the request. > > > > > > > [/MB] > > > > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > > > Ian > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > > > > > Sent: 24 June 2009 15:48 > > > > > > > To: Ian Elz > > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida > > Schubert; > > > > > > > sipcore@ietf.org; Francois Audet > > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > > > Hi Ian, > > > > > > > > > > > > > > I do not believe we should do the "override" behavior as I > > > > > > think that > > > > > > > violates RFC 3323, as the "history" is really a subset of > > > > > the cases > > > > > > > whereby a UAC or proxy would add "session" or "header" to > > > > > > the request. > > > > > > > And, the latter two cases have the same (undesireable) > > > > > > result. I agree > > > > > > > this impacts your services, but we can't mandate that > > > > > > proxies provide > > > > > > > information that might violate their local policies and > > > > indeed a > > > > > > > proxy's local policies can result in the information being > > > > > > anonymized > > > > > > > (or removed if they can't anonymize) even in the > > "none" case. > > > > > > > > > > > > > > I do believe it's reasonable that we strongly recommend > > > > that the > > > > > > > request level (versus specific hi-entries) not be used > > > > > and if it is > > > > > > > used, the consequence is that some services will > > not have the > > > > > > > information they need - this was the gist of my previous > > > > > > response (to > > > > > > > which I did not get any additional feedback). Now, we could > > > > > > add some text that the "none" > > > > > > > case SHOULD be used (e.g., added by first hop proxy) if it > > > > > > is desired > > > > > > > that the information not be subject to privacy > > > > > > restrictions. I do not > > > > > > > think it is then particularly useful to add logic around > > > > > the proxy > > > > > > > then being able to tag the entries within their domain as > > > > > > subject to privacy. > > > > > > > I think that conflicts with the intent of the request > > > > > level "none". > > > > > > > However, as I mention above, per the current text, a proxy > > > > > > can (based > > > > > > > on local policy) remove entries - so a proxy can capture > > > > > hi within > > > > > > > their domain and not forward any of that information to the > > > > > > next hop > > > > > > > in another domain - you already have that functionality. > > > > > > But, I think > > > > > > > this introduces the general problem that you might be > > > > > > impacting other > > > > > > > services further down the line, which I thought was the > > > > > problem you > > > > > > > were wanting to solve - not specifically your example > > > > > > service but, for > > > > > > > example, in the case that someone is debugging and they > > > > want the > > > > > > > entire history, so depending upon the service, this is also > > > > > > > undesirable behavior. > > > > > > > > > > > > > > > > > > > > > Regards, > > > > > > > Mary. > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > > > > > Sent: Wednesday, June 24, 2009 2:57 AM > > > > > > > To: Barnes, Mary (RICH2:AR00) > > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida > > Schubert; > > > > > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > > > > > > > > > > Mary, > > > > > > > > > > > > > > [I have added the list to this thread for wider comment.] > > > > > > > > > > > > > > In the previous discussions I commented that in RFC4424 > > > > > > that a Privacy > > > > > > > header with value "history" effectively makes all H-I > > > > > > entries private > > > > > > > with the result that the H-I entries may be removed. > > > > > > > > > > > > > > There has now been a comprehensive discussion on > > > > > indication of the > > > > > > > initial 'target' to the final recipient for call handling > > > > > purposes. > > > > > > > > > > > > > > The main use case related to a freephone example where the > > > > > > answering > > > > > > > location may be a call centre where the original freephone > > > > > > number may > > > > > > > be required for correct call handling. > > > > > > > > > > > > > > If you now consider the following example (modified from > > > > > Francois' > > > > > > > text in the latest draft - excuse any errors that I may > > > > > > have inserted) > > > > > > > > > > > > > > INVITE sip:sip:+18001234567@example.com > ;user=3Dphone;p=3Dx > > > > > > > Privacy: history > > > > > > > History-Info: > > > > > > > > > > > > > > ;user=3Dphone;p=3Dx>;index=3D1;rt;aor > > > > > > (1) > > > > > > > History-Info: > >;index=3D1.1;mp;aor > > > > > > > (2) > > > > > > > History-Info: > >;index=3D1.1.1;rc > > > > > > > (3) > > > > > > > > > > > > > > In this case due to the Privacy header all of the H-I > > > > entries are > > > > > > > considered private and the +18001234567 will not be > > > > > > delivered to the > > > > > > > final destination with the result that call handling may > > > > > > not be correct. > > > > > > > The Privacy header may have been inserted by any of the > > > > > nodes which > > > > > > > routed the message and inserted a H-I entry. > > > > > > > > > > > > > > If however the H-I was allowed to include a header > > > parameter of > > > > > > > "?Privacy=3Dnone" in the H-I entry and that an explicit > > > H-I entry > > > > > > > privacy value would be considered to have precedence over > > > > > a Privacy > > > > > > > header with a value of "history" then the mapping of the > > > > > > +18001234567 > > > > > > > could be explicitly specified as not private and may be > > > > passed on. > > > > > > > > > > > > > > Thus when the mapping from sip:+18001234567@example.comto > > > > > > > sip:bob@biloxi.example.com whe= n > H-I entry (2) above is > > > > > > included could > > > > > > > also insert the Privacy header parameter in H-I entry (1). > > > > > > > > > > > > > > Thus the message would appear as follows: > > > > > > > > > > > > > > INVITE sip:sip:+18001234567@example.com; > user=3Dphone;p=3Dx > > > > > > > Privacy: history > > > > > > > History-Info: > > > > > > > > > > > > > > > > > > > > > > > > > > > ;index= =3D1;rt; > > > > > > > ao > > > > > > > r > > > > > > > History-Info: > >;index=3D1.1;mp;aor > > > > > > > History-Info: > >;index=3D1.1.1;rc > > > > > > > > > > > > > > This would result in all the H-I entries except (1) being > > > > > > considered > > > > > > > private with the result that the =3D1800... Number is > > > > > passed for call > > > > > > > handling purposes. > > > > > > > > > > > > > > This change is backward compatible with the existing > > > > > > implementation as > > > > > > > any node using the existing functionality as defined in > > > > > > RFC4244 will > > > > > > > continue to be supported. > > > > > > > > > > > > > > The alternative is to remove the ability to include the > > > > > > value "history" > > > > > > > in the Privacy header and only allow this value in the > > > > > > Privacy header > > > > > > > parameter. This alternative is not backward compatible. > > > > > > > > > > > > > > Without this change a single node in the message path which > > > > > > includes a > > > > > > > header "Privacy: history" will prevent delivery of the > > > > > aor and thus > > > > > > > prevent proper call handling. > > > > > > > > > > > > > > Ian Elz > > > > > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Christer Holmberg > > > > > > > Sent: 23 June 2009 19:40 > > > > > > > To: 'Mary Barnes'; Francois Audet; Hans Erik van > > > Elburg; Shida > > > > > > > Schubert > > > > > > > Cc: Ian Elz > > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > I include Ian, so he can comment to your resposne himself. > > > > > > > > > > > > > > Regards, > > > > > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > > > > > Sent: Tuesday, June 23, 2009 9:40 PM > > > > > > > To: Christer Holmberg; Francois Audet; Hans Erik van > > > > > Elburg; Shida > > > > > > > Schubert > > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > > > Here was the thread of response and the last comment was > > > > > > from Ian that > > > > > > > he would consider the response: > > > > > > > > > http://www.ietf.org/mail-archive/web/sip/current/msg26948.html > > > > > > > > > > > > > > And, there was not agreement on the "none" but rather to > > > > > > qualify the > > > > > > > SHOULD NOT forward. However, in the sipcore-4244bis-00, > > > > > > rather than > > > > > > > changing the text such that the headers SHOULD be > > removed, we > > > > > > > recommend that they be anonymized (in section 4.3.3.3.1). > > > > > That is > > > > > > > entirely consistent with RFC 3324 and thus we have > > > removed the > > > > > > > recommendations to remove the headers entirely. However, > > > > > > that changed > > > > > > > never got done in section 3.2, so we would need to > > > change this: > > > > > > > "Thus, the History- Info header > > > > > > > SHOULD NOT be included in Requests where the requestor > > > > > > has indicated > > > > > > > a priv-value of Session- or Header-level privacy." > > > > > > > > > > > > > > But, I'm really beginning to be of the mindset that we > > > > > should just > > > > > > > remove all the subsections of section 3 (i.e., leave the > > > > > > text in the > > > > > > > upper level section), so we don't have to keep > > worrying about > > > > > > > consistency. > > > > > > > > > > > > > > So, lets either fixt the text in 3.2 or remove altogether > > > > > > and then I > > > > > > > think we are really at the point of needing to submit this > > > > > > version so > > > > > > > folks that actually have an interest in it can review > > > > the updated > > > > > > > document. > > > > > > > > > > > > > > Mary. > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: Christer Holmberg > > > [mailto:christer.holmberg@ericsson.com] > > > > > > > Sent: Tuesday, June 23, 2009 1:10 PM > > > > > > > To: Barnes, Mary (RICH2:AR00); Audet, Francois > > > > > > (SC100:3055); Hans Erik > > > > > > > van Elburg; Shida Schubert > > > > > > > Subject: 4244bis and privacy > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > Below is a comment/proposal which one of my collegues (Ian > > > > > > Elz) gave > > > > > > > on the list a while ago, when the first version of > > > 4244bis was > > > > > > > submitted, but was not incorporated. Do you think it would > > > > > > be useful? > > > > > > > > > > > > > > ------- > > > > > > > > > > > > > > While the HI approach to target may solve the problem of > > > > > > being able to > > > > > > > deliver the target URI to the final destination there is no > > > > > > guarantee > > > > > > > that it will actually be delivered. > > > > > > > > > > > > > > The problem arises with how Privacy is defined for HI. > > > > > > > > > > > > > > 4424 defines a new Privacy value "history" which may be > > > > placed in > > > > > > > either the Privacy header or as a header parameter to the > > > > > HI entry. > > > > > > > > > > > > > > If one node uses the former option "Privacy: history" then > > > > > > this will > > > > > > > make all headers private and will result in all HI > > > > entries being > > > > > > > removed or made anonymous when the message containing > > > the HI is > > > > > > > delivered to the user. > > > > > > > > > > > > > > There is a simple solution to this and that is to also > > > > > > allow the use > > > > > > > of the "none" Privacy value as a header parameter in the > > > > > HI entry. > > > > > > > This would explicitly state that no privacy is required > > > > to the HI > > > > > > > entry and this would override a "history" value in the > > > > > > Privacy header. > > > > > > > > > > > > > > I pointed this out to Mary when the 4424bis draft was first > > > > > > published > > > > > > > but the change has not been made in the latest draft. > > > > > > > > > > > > > > The change is backward compatible and would not cause an > > > > > issue with > > > > > > > any existing implementations. > > > > > > > > > > > > > > ------ > > > > > > > > > > > > > > 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 > > > > > > > > > > > _______________________________________________ > > > > > sipcore mailing list > > > > > sipcore@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > > > > > > > --0015174c3c6a44caaf046db47af7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes I think I do agree with you.

/Hans Erik van Elbur= g

On Wed, Jul 1, 2009 at 8:42 PM, Francois Aud= et <audet@nortel.c= om> wrote:
I see another problem with Privacy in RFC 4244.

Currently, it talks about "Session" Privacy impacting HI and says= nothing about
"User" privacy impacting HI. (see RFC 3323)

This makes no sense to me. Session is supposed to relate strictly
to SDP-level information (i.e., IP address inside SDP, and maybe some
other fields).

I don't see at all why "session" would mean don't do HI.<= br>
On the other hand 4244 is silent about "User" Privacy. I belive i= f
"user privacy" is used, then defintively it implies the URIs repr= esenting
that user should be anonymized.

Views?



> -----Original Message-----
> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]
> Sent: Tuesday, June 30, 2009 00:30
> To: Audet, Francois (SC100:305= 5); Ian Elz; Barnes, Mary
> (RICH2:AR00); R.Jesske@telekom.= de; ietf.hanserik@gmail.com<= /a>
> Cc: sipcore@ietf.org; shida@agnada.com
> Subject: RE: [sipcore] 4244bis and privacy
>
> Yes, I think something like this makes sense.
>
> John
>
> > -----Original Message-----
> > From: Francois Audet [mailto:= audet@nortel.com]
> > Sent: 30 June 2009 00:06
> > To: Ian Elz; Elwell, John; Mary Barnes; R.Jesske@telekom.de;
> > ietf.hanserik@gmail.co= m
> > Cc: sipcore@ietf.org; shida@agnada.com
> > Subject: RE: [sipcore] 4244bis and privacy
> >
> > I think the current "interpretation" is not terribly > useful. I prefer
> > your suggestion. The current RFC 4244 text is not very clear.
> >
> > It seems to me that:
> > - Privacy should associated with a specific hi-entry (and
> perhaps any
> > =A0 entry that corresponds to that same user), and not the header=
> > itself.
> > - That way, it is possible that specific entries be
> anonymize, but not
> > =A0 others. For example, if you call me without privacy, and I ca= ll
> > forward
> > =A0 you to John with privacy setup for myself, John should
> see an entry
> > for
> > =A0 you and an anonymized entry for me.
> > - There is no reason why "none" couldn't be used in= this context.
> > Again,
> > =A0 with the same example as above, John could requies "none= "
> > for him, and
> > =A0 I could set privacy on for myself.
> >
> > I don't think this type of rule for 4244bis would require
> any change
> > whatsoever to RFC 3323. It would be completely self-contained in<= br> > > 4244bis.
> >
> > Comments?
> >
> > > -----Original Message-----
> > > From: Ian Elz [mailto:ian.elz@ericsson.com]
> > > Sent: Monday, June 29, 2009 03:26
> > > To: Audet, Francois (SC100:3055); Elwell, John; Barnes, Mary=
> > > (RICH2:AR00); R.Jessk= e@telekom.de; ietf.hanserik@= gmail.com
> > > Cc: sipcore@ietf.org= ; shida@agnada.com
> > > Subject: RE: [sipcore] 4244bis and privacy
> > >
> > > Francios,
> > >
> > > I agree that 4244bis should not specify the actions of
> proxies etc
> > > where this is a matter of local policy.
> > >
> > > My original proposed change was to allow the inclusion of > the value
> > > "none" in the alongside the value "history&qu= ot; to be included in the
> > > Privacy header parameter escaped in the
> hi-targeted-to-uri. (RFC4244
> > > section 4.1)
> > >
> > > It appears however that the current interpretation of the Pr= ivacy
> > > header means that the value included in the Privacy
> header, which is
> > > applicable to the originating rather than retargeting user i= s
> > > applied to the retargeting user rather than the explicit val= ue
> > > included for the retargeting user.
> > > The escaped privacy value is only used if there is no
> Privacy header
> > > or the Privacy header only contains the value "user&quo= t;.
> > >
> > > The end result of this interpretation is that including
> an explicit
> > > value "none" escaped as a Privacy parameter would = have no
> effect and
> > > would have the same meaning as not including a Privacy heade= r
> > > parameter escaped in the hi-targeted-to-uri.
> > >
> > > 4244bis is not the place to extend the sip Privacy handling = to
> > > specify how 3rd party identities in sip messages should
> have their
> > > own specific privacy maintained.
> > >
> > > Allowing the inclusion of the explicitly Privacy=3Dnone
> value in the
> > > hi-targeted-to-uri would not change any handling at this tim= e but
> > > would make the new H-I RFC suitable for use if an updated pr= ivacy
> > > RFC is proposed which does have specific support for 3rd par= ty
> > > identities.
> > >
> > > H-I is not the only place where the explicit privacy of 3rd = party
> > > identities is required. The Referred-By header is one other = case
> > > where a similar explicit privacy may need to be considered i= n the
> > > future.
> > >
> > > regards
> > >
> > > Ian
> > >
> > > -----Original Message-----
> > > From: Francois Audet [mailto:audet@nortel.com]
> > > Sent: 26 June 2009 16:55
> > > To: Ian Elz; Elwell, John; Mary Barnes; R.Jesske@telekom.de;
> > > ietf.hanserik@gma= il.com
> > > Cc: sipcore@ietf.org= ; shida@agnada.com
> > > Subject: RE: [sipcore] 4244bis and privacy
> > >
> > > I do see things that we should fix right-away in History-Inf= o,
> > > regarding privacy.
> > >
> > > I also think that History-Info shouldn't "overstrec= h" and get too
> > > deep into the nitty gritty of privacy. What should be in
> HI is high
> > > level guidance.
> > >
> > > In section 3.1, for example, it says that Privacy header wil= l
> > > determine if a History-Info *header field* can be included b= y an
> > > intermediary. This does not make any sense. What it should s= ay is
> > > that the Privacy header will determine if a history-info
> *entry* can
> > > be added for the UA inserting the Privacy header.
> > >
> > > So, in my opinion, we can go ahead and fix that right now. > > >
> > > I don't think we need to get into super low-level proced= ural
> > > descriptions of the type "proxy MUST this and that if P= rivacy =3D=3D
> > > this and that". I believe privacy matters are
> policy-level decisions
> > > that service providers and enteprises will have, and they ar= e not
> > > going to be implemented by simplistic procedural rules
> from an RFC.
> > >
> > > Comments?
> > >
> > >
> > > > -----Original Message-----
> > > > From: sipco= re-bounces@ietf.org
> > > > [mailto:sip= core-bounces@ietf.org] On Behalf Of Ian Elz
> > > > Sent: Friday, June 26, 2009 01:08
> > > > To: Elwell, John; Barnes, Mary (RICH2:AR00);
> R.Jesske@telekom.de;
> > > > ietf.hanseri= k@gmail.com
> > > > Cc: sipcore@ietf.or= g; shida@agnada.com
> > > > Subject: Re: [sipcore] 4244bis and privacy
> > > >
> > > > John,
> > > >
> > > > Your statement " not anonymise or remove any infor= mation
> > > that the UAC
> > > > has already placed in the request " is the key her= e.
> > > >
> > > > The UAC has not included the H-I entry, particularly th= e one
> > > > containing the identity of the diverting party.
> > > >
> > > > This was not considered in RFC3323 and we have an issue=
> where we
> > > > cannot determine which entity included which informatio= n.
> > > > This creates a problem where a restriction by the
> > originating party
> > > > will prevent a downstream identity from permitting
> > presentation of
> > > > their identity.
> > > >
> > > > I agree with Mary that this probably requires an update= to
> > > > RFC3323 so we should start by updating RFC3323 and then=
> > > move on to the
> > > > other impacted RFCs. The issue that this will raise for=
> > H-I is that
> > > > there will be another change required after the Privacy= RFC
> > > has been
> > > > agreed.
> > > >
> > > > This is far from ideal but the 4424bis draft contains a= lot
> > > more than
> > > > just this issue.
> > > >
> > > > Ian
> > > >
> > > > -----Original Message-----
> > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]
> > > > Sent: 26 June 2009 08:30
> > > > To: Mary Barnes; R.Jesske@telekom.de; ietf.h= anserik@gmail.com
> > > > Cc: Ian Elz; sipcor= e@ietf.org; shida@agnada.com > > > > Subject: RE: [sipcore] 4244bis and privacy
> > > >
> > > >
> > > >
> > > > > -----Original Message-----
> > > > > From: = sipcore-bounces@ietf.org
> > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes
> > > > > Sent: 25 June 2009 22:45
> > > > > To: R.Jessk= e@telekom.de; ietf.hanserik@= gmail.com
> > > > > Cc: ian.el= z@ericsson.com; sipcore@ietf.org; shida@agnada.com
> > > > > Subject: Re: [sipcore] 4244bis and privacy
> > > > >
> > > > > Roland,
> > > > >
> > > > > The reason you can't have "none" at = the request level and
> > > > "history" at
> > > > > the entry level is because RFC 3323 states that yo= u MUST
> > > NOT apply
> > > > > privacy to the message. Even if you put "hist= ory" in the
> > > > entries, the
> > > > > privacy service would just ignore that - per RFC 3= 323.
> > > So, if you
> > > > > want to change that behavior, then RFC 3323 should= be
> > > > changed - i.e.,
> > > > > the MUST NOT for the "none" could be cha= nged to a SHOULD
> > > > NOT and then
> > > > > a general statement about possible exceptions. The= n, we
> > could add
> > > > > something to RFC 4244 for this case. But, changing= RFC
> > > > > 3323 is totally out of scope for what we are curre= ntly
> > > working on.
> > > > [JRE] I would interpret privacy 'none' in RFC 3= 323 as
> > > meaning that a
> > > > downstream entity must not anonymise or remove any
> > information that
> > > > the UAC has already placed in the request.
> > > > If a downstream entity chooses:
> > > > - not to add H-I,
> > > > - to add anonymised H-I, or
> > > > - to anonymise an H-I entry that some intermediate enti= ty
> > > has added, I
> > > > don't see that as being in violation of what the UA= C has
> > requested.
> > > >
> > > > John
> > > >
> > > >
> > > > >
> > > > > That all said, I would sure think that if you are = leaving a
> > > > "trusted
> > > > > network" that you have a B2BUA in there, as I= 've said
> in other
> > > > > threads. Thus, the B2BUA builds a new request and = certainly
> > > > can add a
> > > > > privacy header that it believes is appropriate sin= ce
> > the outgoing
> > > > > request is done by the UAC function of a B2BUA. > > > > >
> > > > > Mary.
> > > > >
> > > > >
> > > > > -----Original Message-----
> > > > > From: R.Jes= ske@telekom.de [mailto:R.Jesske@= telekom.de]
> > > > > Sent: Thursday, June 25, 2009 4:32 PM
> > > > > To: iet= f.hanserik@gmail.com
> > > > > Cc: Barnes, Mary (RICH2:AR00); ian.elz@ericsson.com;
> > > > sipcore@ietf.org;
> > > > > shida@agnada.c= om
> > > > > Subject: AW: [sipcore] 4244bis and privacy
> > > > >
> > > > > Hi Hans Erik,
> > > > > We have also to take regulatory into consideration= . In
> > > Germany the
> > > > > last trusted network is responsible for anonymisin= g
> information.
> > > > >
> > > > > But nevertheless if Network provider A wants to ha= ve History
> > > > > completely private this operator will set privacy<= br> > > history for the
> > > > > header.
> > > > > If the succeeding Operator want to present element= s the AS
> > > > which adds
> > > > > a entry has then to re label all entries from the<= br> > > > preceding network
> > > > > and the entries from it's own network will be = unmarked
> > within the
> > > > > Header.
> > > > >
> > > > > But never the less I fully agree to your last sent= ence.
> > > > >
> > > > > The real Question is if this should really be allo= wed
> > > that a entry
> > > > > marked with "none" overrules the privacy= statement
> > > > "history" for the
> > > > > complete header.
> > > > >
> > > > > I'm against this behaviour.
> > > > >
> > > > > Best Regards
> > > > >
> > > > > Roland
> > > > >
> > > > > -----Urspr=FCngliche Nachricht-----
> > > > > Von: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
> > > > > Gesendet: Donnerstag, 25. Juni 2009 22:32
> > > > > An: Jesske, Roland
> > > > > Cc: mary= .barnes@nortel.com; ian.elz@eri= csson.com;
> > > sipcore@ietf.org; > > > > > shida@agnada.c= om
> > > > > Betreff: Re: [sipcore] 4244bis and privacy
> > > > >
> > > > > Hi Roland,
> > > > >
> > > > > I don't understand the argument, by the time t= hat the
> > > History-Info
> > > > > leaves operator A that wishes complete privacy, al= l the
> > > > History-Info
> > > > > headers should be anonymised according to 4244 and= 4244bis.
> > > > >
> > > > > What is the point in mandating that operator A to = force
> > > > operator B to
> > > > > also anonymise the entries "owned" by op= erator B.
> > > > >
> > > > > It is of course without question that each operato= r has
> > > > full privacy
> > > > > control over its own added entries. And each opera= tor can
> > > based on
> > > > > local policy decide to remove the entire history i= f it
> > > > things that is
> > > > > wise to do.
> > > > >
> > > > > /Hans Erik
> > > > >
> > > > >
> > > > > R.Jesske@te= lekom.de wrote:
> > > > > > Hi Marry and Ian,
> > > > > > The whole discussion puzzle me. We have speci= fied CDIV
> > > > > within TISPAN and 3GPP.
> > > > > > There is described that privacy "none&qu= ot; can be used for
> > > > > entries. BUT assuming that each entry has its own = privacy
> > > > statement if
> > > > > needed.
> > > > > > I fully agree on Mary's comment that a pr= ivacy "history"
> > > > > cannot overruled by a privacy value "none&quo= t; within a entry.
> > > > > > There may be operators that would like to kee= p the whole
> > > > > History Info private even if entries has other
> > statements, so the
> > > > > entity could add privacy history to the whole head= er.
> > > > > Nothing more.
> > > > > >
> > > > > > On the other side a Application Server includ= ing a entry
> > > > > should have the possibility to rewrite the entries= so that
> > > > instead of
> > > > > "history" for the whole header the all r= eceived entries
> > > within the
> > > > > History-Info header will be marked with "hist= ory" and the
> > > > added header
> > > > > (which shall be presented to the terminating user)= will
> > either be
> > > > > marked with "none" or will not be marked= .
> > > > > >
> > > > > > Perhaps a hint could be given, but I do not i= nsist on it.
> > > > > >
> > > > > > Best Regards,
> > > > > >
> > > > > > Roland
> > > > > >
> > > > > >
> > > > > >
> > > > > > -----Urspr=FCngliche Nachricht-----
> > > > > > Von: sipcore-bounces@ietf.org
> > > > [mailto:sip= core-bounces@ietf.org] Im
> > > > > > Auftrag von Mary Barnes
> > > > > > Gesendet: Donnerstag, 25. Juni 2009 18:29
> > > > > > An: Ian Elz
> > > > > > Cc: sipco= re@ietf.org; Shida Schubert
> > > > > > Betreff: Re: [sipcore] 4244bis and privacy > > > > > >
> > > > > > Hi Ian,
> > > > > >
> > > > > > Responses inline below [MB2].
> > > > > >
> > > > > > Mary.
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Ian Elz [mailto:ian.elz@ericsson.com]
> > > > > > Sent: Thursday, June 25, 2009 10:13 AM
> > > > > > To: Barnes, Mary (RICH2:AR00)
> > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; = Shida
> Schubert;
> > > > > > sipcore@i= etf.org; Audet, Francois (SC100:3055)
> > > > > > Subject: RE: 4244bis and privacy
> > > > > >
> > > > > > Mary,
> > > > > >
> > > > > > I am a little concerned about one answer that= you gave:
> > > > > >
> > > > > >
> > > > > > If you have a Privacy header with a value of = "none" and a
> > > > H-I entry
> > > > > > with Privacy header parameter with value &quo= t;history" what is
> > > > > the privacy
> > > > > > of the individual H-I entry?
> > > > > > [MB] We did not explicitly address the "= none" in RFC
> > > > 4244, but the
> > > > > > general statement is the privacy headers at t= he request
> > > > > level override
> > > > > > any at the hi-entry level. [/MB]
> > > > > >
> > > > > > This means that if privacy is required for an= individual
> > > > > H-I entry but
> > > > > > the originating user included "Privacy:n= one" in the request
> > > > > then there
> > > > > > is no option to include the real URI in the H= -I entry.
> > > > > > [MB2] I'm confused here - the "none&= quot; definition is as you
> > > > > note below,
> > > > > > thus "none" prohibits the removal o= r anonymization of the
> > > > entries,
> > > > > > thus I would think you would fine this functi= onality
> > desireable.
> > > > > > However, this does not prohibit an entity bas= ed on policy
> > > > > to anonymize
> > > > > > (or remove entries if privacy is required for= that
> > > domain if the
> > > > > > entity does not have access to a privacy serv= ice). [/MB2]
> > > > > >
> > > > > > This occurs as RFC3323 states in section 4.3:= "However, if
> > > > > the Privacy
> > > > > > header value of 'none' is specified i= n a message, privacy
> > > > services
> > > > > > MUST NOT perform any privacy function and MUS= T NOT remove
> > > > or modify
> > > > > > the Privacy header."
> > > > > >
> > > > > > The only option for an intermediate node incl= uding a H-I
> > > > > entry where
> > > > > > "Privacy:none" is specified and pri= vacy for the H-I URI is
> > > > > required is
> > > > > > to include an anonymous entry or not include = the H-I entry.
> > > > > > [MB2] If privacy is required then yes, you in= clude
> > > > > anonymous entries
> > > > > > or don't include. That's the basic pr= ivacy mechanism
> > > for privacy
> > > > > > levels of "session" "header&qu= ot; and "history" in the R-URI or
> > > > > "history"
> > > > > > in the specific entries, as well as when ther= e is a policy
> > > > > for privacy
> > > > > > for the entries added by a specific domain. T= he "none"
> > > > > really has no
> > > > > > influence on the later case per se. [/MB2] > > > > > >
> > > > > > In your previous response you stated that we = would violate
> > > > > RFC3323 if
> > > > > > we specified additional behaviour for privacy= explicitly
> > > > > stated with a
> > > > > > URI -n the H-I entry. I don't believe tha= t this is the case
> > > > > as RFC3323
> > > > > > only considered privacy in a two party scenar= io and did not
> > > > > consider
> > > > > > third party identities being included in a me= ssage
> > between two
> > > > > > parties. H-I is not the only case where this = occurs as the
> > > > > Referred-By
> > > > > > header when included in the INVITE (or other = request)
> > > > which results
> > > > > > from the REFER has the same issue.
> > > > > > [MB2] I can't necessarily disagree on thi= s one (we can
> > > debate it
> > > > > > either way). But to fix it requires an update= to
> RFC 3323 and
> > > > > > shouldn't be something that we want to fi= x in
> 4244bis. [/MB2]
> > > > > >
> > > > > > RFC4244 was the first time that there was a r= ecognition
> > > > > that privacy
> > > > > > for these individual third party identities m= ay be
> > > > > required. To allow
> > > > > > this explicit statement of privacy to be over= ridden by
> > > a generic
> > > > > > statement which is applicable to a different = user is
> > > > > counterintuitive.
> > > > > > [MB2] See my comment above. But, as I have co= nsistently
> > > > > said, the idea
> > > > > > that an entity might want to override the &qu= ot;none" is
> > > > > entirely based on
> > > > > > policy and 4244 and 4244bis allow privacy to = be applied to
> > > > > the entries
> > > > > > that are added by that entity if the policy d= ictates
> > so (and we
> > > > > > already say that). [/MB2]
> > > > > >
> > > > > > The original Privacy header is usually includ= ed by or on
> > > > > behalf of the
> > > > > > originating user and should not be allowed to= specify the
> > > > > privacy of
> > > > > > the original called user, e.g. the 800 number= , and
> > prevent this
> > > > > > identity being presented if this user does no= t have the
> > > > > same level of privacy.
> > > > > > [MB2] As I tried to say in a previous respons= e, a random
> > > > > entity (i.e.,
> > > > > > one for whom the R-URI is not in a domain und= er its
> > > > control) cannot
> > > > > > add a privacy header to the Request. Per RFC = 3323 an
> > > > entity may add
> > > > > > the header to a request only if it has the ap= propriate
> > > > > > relationship/authorization with the original = called user
> > > > > who intiated
> > > > > > the request. And, I would find it very surpri= sing if an
> > > > entity that
> > > > > > did have responsibility would apply privacy s= ince
> > that would be
> > > > > > counter intuitive and I would hope that SPs w= ould be
> > > judicious in
> > > > > > specifying the appropriate and inappropriate = manner in
> > > which the
> > > > > > proxies they deploy and interface with privat= ize the
> > > > messages. The
> > > > > > protocol CANNOT control this behavior and tha= t's why
> > > there is the
> > > > > > policy clause in 4244 and 4244bis. [/MB2]
> > > > > >
> > > > > > The real issue with the 800 scenario is as yo= u have stated
> > > > > is that the
> > > > > > answerer will not know the original called id= entity and
> > > > will not be
> > > > > > able to correctly handle the call. As more ge= neric call
> > > > centres are
> > > > > > used which will answer calls on behalf of man= y different
> > > > > organizations
> > > > > > using CTI and the original called identity to= have to
> > > implement a
> > > > > > generic system asking the caller who he origi= nally
> > > called appear
> > > > > > unprofessional, is inefficient and unproducti= ve.
> > > > > > [MB2] And, as I noted, it is rare for a call = centre to
> > > > route a call
> > > > > > directly to an agent without a user providing= some sort of
> > > > > input. Even
> > > > > > companies like American Airlines, even though= they have the
> > > > > info that
> > > > > > I enter via the IVR, they still ask some basi= c questions
> > > > > and there are
> > > > > > times when they have to reroute me. I don'= ;t think we
> > > can totally
> > > > > > automate things. =A0And, again, once the call= hits the
> > > > domain that is
> > > > > > responsible for that 800 number the entities = in that
> > > domain have
> > > > > > control over how they muck with the R-URI, su= ch that they
> > > > should be
> > > > > > able to use any IVR info to appropriately dir= ect the call -
> > > > > it's not
> > > > > > the number that's meaningful, but how the= system gets the
> > > > > call to the
> > > > > > right user and the additional information the= y provide as
> > > > > the call is
> > > > > > presented to the agent. I would honestly thin= k that having
> > > > > something
> > > > > > other than an 800 number show up on the displ= ay would
> > > be far more
> > > > > > useful and in my experience in the systems I = developed
> > > > > we're usually
> > > > > > talking about CTI interfaces so you have a lo= t you can
> > > do. =A0And,
> > > > > > actually all of this really doesn't matte= r in that you MUST
> > > > > be able to
> > > > > > handle this situation independent of the priv= acy since
> > > > > History-Info is
> > > > > > optional, you need default behavior assigned.= [/MB2]
> > > > > >
> > > > > > We have an opportunity to allow presentation = of specific
> > > > identities
> > > > > > and to solve this particular problem so we sh= ould take it.
> > > > > > [MB2] The most we can do is to document the r= isks/impacts
> > > > > of the use
> > > > > > of the Privacy headers at the R-URI level. Th= ere is
> > > > already general
> > > > > > text in
> > > > > > 4244 and 4244bis that the privacy may impact = whether the
> > > > > applications
> > > > > > get the information. =A0And, as I noted befor= e, most
> > > > > commercial systems
> > > > > > are using B2BUAs which will allow you far mor= e control over
> > > > > the use of
> > > > > > the Privacy headers in the network. But, agai= n, I don't
> > > > > think that's
> > > > > > something that should be address in 4244bis. = =A0[/MB2]
> > > > > >
> > > > > > I hope that we can get some wider discussion = on this issue
> > > > > so a more
> > > > > > general consensus can be obtained.
> > > > > >
> > > > > > Regards
> > > > > >
> > > > > > Ian
> > > > > >
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com]
> > > > > > Sent: 24 June 2009 17:27
> > > > > > To: Ian Elz
> > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; = Shida
> Schubert;
> > > > > > sipcore@i= etf.org; Francois Audet
> > > > > > Subject: RE: 4244bis and privacy
> > > > > >
> > > > > > Hi Ian,
> > > > > >
> > > > > > Responses inline below [MB].
> > > > > >
> > > > > > Mary.
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Ian Elz [mailto:ian.elz@ericsson.com]
> > > > > > Sent: Wednesday, June 24, 2009 10:37 AM
> > > > > > To: Barnes, Mary (RICH2:AR00)
> > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; = Shida
> Schubert;
> > > > > > sipcore@i= etf.org; Audet, Francois (SC100:3055)
> > > > > > Subject: RE: 4244bis and privacy
> > > > > >
> > > > > > Mary,
> > > > > >
> > > > > > I was not proposing that we change the handli= ng of H-I
> > > > > which is based
> > > > > > upon local policy. If that causes an issue fo= r a network
> > > > > operator then
> > > > > > they can modify their local policy accordingl= y or arrange
> > > > with the
> > > > > > proxy vendor to modify their equipment to be = more
> > flexible with
> > > > > > regards to policy.
> > > > > >
> > > > > > Can you clarify for me:
> > > > > >
> > > > > > If you have a Privacy header with either &quo= t;session" or
> > > > "header" doe
> > > > > > this impact the H-I entries or will only a va= lue of
> > > > > "history" impact
> > > > > > the H-I entries?
> > > > > > [MB] Yes, both "session" and "= header" level privacy,
> > > > > consistent with
> > > > > > RFC 3323, mandate that entries be anonymized = or
> > > dropped, with the
> > > > > > latter being the recommendation for "ses= sion" level
> > > > > privacy. RFC 4244
> > > > > > mandated that they be dropped and 4244bis
> recommends they be
> > > > > > anonymized. The original intent for the value= of "history"
> > > > > was for the
> > > > > > tagging of the individual entries, but you en= d up getting
> > > > > the header
> > > > > > level functionality as well. [/MB]
> > > > > >
> > > > > > If you have a Privacy header with a value of = "none" and a
> > > > H-I entry
> > > > > > with Privacy header parameter with value &quo= t;history" what is
> > > > > the privacy
> > > > > > of the individual H-I entry?
> > > > > > [MB] We did not explicitly address the "= none" in RFC
> > > > 4244, but the
> > > > > > general statement is the privacy headers at t= he request
> > > > > level override
> > > > > > any at the hi-entry level. [/MB]
> > > > > >
> > > > > > From reading RFC4244 a Privacy header with va= lue
> > "history" will
> > > > > > effectively make all H-I entries private and = there is
> > > > currently no
> > > > > > option to =A0include a H-I Privacy header par= ameter with
> > > > value "none".
> > > > > > [MB] Correct, per my comment above. [/MB]
> > > > > >
> > > > > > H-I at present allows the inclusion of Privac= y header
> > > > parameters to
> > > > > > explicitly express privacy for an individual = H-I entry
> > > > but a single
> > > > > > node which includes a header "Privacy: h= istory" makes all
> > > > > H-I entries
> > > > > > private even if this is not the requirements = for the
> > > specific URI.
> > > > > > [MB] Correct, but the only node that should a= dd the header
> > > > > is a node
> > > > > > which is responsible for the domain associate= d with the
> > > > > Request URI in
> > > > > > the incoming request or is authorized to do s= o. [/MB]
> > > > > >
> > > > > > I will admit that having worked in a telephon= y environment
> > > > > for a long
> > > > > > time I am used to having privacy of identitie= s set on a
> > > > per number
> > > > > > basis and the relative inflexibility of the I= ETF Privacy
> > > > header is
> > > > > > relatively restrictive as to specifying which=
> > identities may be
> > > > > > presented and which not.
> > > > > > [MB] Yes, this is an entirely different parad= igm. =A0I
> > developed
> > > > > > telephony s/w for over a decade and this is e= ntirely
> > > > different - it
> > > > > > provides a lot more flexibility, which makes = things
> > > far, far less
> > > > > > deterministic than what you have in telephony= switches
> > > where your
> > > > > > routing and translations are configured for t= he most part,
> > > > > with just a
> > > > > > few capabilities for controlling the privacy = and it's a
> > > > > closed network.
> > > > > >
> > > > > > With RFC4244/4244bis, there MUST be a mechani= sm at the
> > > UAS or end
> > > > > > application that can handle a request that do= esn't have the
> > > > > > appropriate information either because nodes = didn't support
> > > > > > History-Info or some random node in the netwo= rk applied
> > > > > privacy (which
> > > > > > I think is highly
> > > > > > unlikely) - this is normative per section 5 o= f RFC
> > > 4244. =A0So, the
> > > > > > worst case scenario I see for this 800 servic= e =A0(which will
> > > > > get to the
> > > > > > right UAS but without the exact 800 number th= at was dialed)
> > > > > is that it
> > > > > > goes to a default ACD group/customer service = agent,
> > > etc. who then
> > > > > > needs to gather the appropriate information a= nd in my
> > > > > experience this
> > > > > > is often an IVR system these days. =A0So, the= service is not
> > > > > broken when
> > > > > > privacy is applied in an undesireable manner,= it's just not
> > > > > optimal.
> > > > > > This is something that should be addressed in= the
> > > > target-uri draft
> > > > > > which has all the details of how specific ser= vices use
> > > > History-Info.
> > > > > > One other thing to consider is that most netw= orks that are
> > > > > emulating
> > > > > > telephony type features use B2BUAs, which fol= low the
> > > > > UAS/UAC rules for
> > > > > > the header rather than the proxy rules, notin= g that the
> > > > UAC can set
> > > > > > the Privacy header to whatever value it sees = as appropriate
> > > > > for the request.
> > > > > > [/MB]
> > > > > >
> > > > > >
> > > > > > Regards
> > > > > >
> > > > > > Ian
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com]
> > > > > > Sent: 24 June 2009 15:48
> > > > > > To: Ian Elz
> > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; = Shida
> Schubert;
> > > > > > sipcore@i= etf.org; Francois Audet
> > > > > > Subject: RE: 4244bis and privacy
> > > > > >
> > > > > > Hi Ian,
> > > > > >
> > > > > > I do not believe we should do the "overr= ide" behavior as I
> > > > > think that
> > > > > > violates RFC 3323, as the "history"= is really a subset of
> > > > the cases
> > > > > > whereby a UAC or proxy would add "sessio= n" or "header" to
> > > > > the request.
> > > > > > And, the latter two cases have the same (unde= sireable)
> > > > > result. =A0 I agree
> > > > > > this impacts your services, but we can't = mandate that
> > > > > proxies provide
> > > > > > information that might violate their local po= licies and
> > > indeed a
> > > > > > proxy's local policies can result in the = information being
> > > > > anonymized
> > > > > > (or removed if they can't anonymize) even= in the
> "none" case.
> > > > > >
> > > > > > I do believe it's reasonable that we stro= ngly recommend
> > > that the
> > > > > > request level (versus specific hi-entries) no= t be used
> > > > and if it is
> > > > > > used, the consequence is that some services w= ill
> not have the
> > > > > > information they need - this was the gist of = my previous
> > > > > response (to
> > > > > > which I did not get any additional feedback).= Now, we could
> > > > > add some text that the "none"
> > > > > > case SHOULD be used (e.g., added by first hop= proxy) if it
> > > > > is desired
> > > > > > that the information not be subject to privac= y
> > > > > restrictions. I do not
> > > > > > think it is then particularly useful to add l= ogic around
> > > > the proxy
> > > > > > then being able to tag the entries within the= ir domain as
> > > > > subject to privacy.
> > > > > > I think that conflicts with the intent of the= request
> > > > level "none".
> > > > > > However, as I mention above, per the current = text, a proxy
> > > > > can (based
> > > > > > on local policy) remove entries - so a proxy = can capture
> > > > hi within
> > > > > > their domain and not forward any of that info= rmation to the
> > > > > next hop
> > > > > > in another domain - you already have that fun= ctionality.
> > > > > But, I think
> > > > > > this introduces the general problem that you = might be
> > > > > impacting other
> > > > > > services further down the line, which I thoug= ht was the
> > > > problem you
> > > > > > were wanting to solve - not specifically your= example
> > > > > service but, for
> > > > > > example, in the case that someone is debuggin= g and they
> > > want the
> > > > > > entire history, so depending upon the service= , this is also
> > > > > > undesirable behavior.
> > > > > >
> > > > > >
> > > > > > Regards,
> > > > > > Mary.
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Ian Elz [mailto:ian.elz@ericsson.com]
> > > > > > Sent: Wednesday, June 24, 2009 2:57 AM
> > > > > > To: Barnes, Mary (RICH2:AR00)
> > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; = Shida
> Schubert;
> > > > > > sipcore@i= etf.org; Audet, Francois (SC100:3055)
> > > > > > Subject: RE: 4244bis and privacy
> > > > > >
> > > > > >
> > > > > > =A0Mary,
> > > > > >
> > > > > > [I have added the list to this thread for wid= er comment.]
> > > > > >
> > > > > > In the previous discussions I commented that = in RFC4424
> > > > > that a Privacy
> > > > > > header with value "history" effecti= vely makes all H-I
> > > > > entries private
> > > > > > with the result that the H-I entries may be r= emoved.
> > > > > >
> > > > > > There has now been a comprehensive discussion= on
> > > > indication of the
> > > > > > initial 'target' to the final recipie= nt for call handling
> > > > purposes.
> > > > > >
> > > > > > The main use case related to a freephone exam= ple where the
> > > > > answering
> > > > > > location may be a call centre where the origi= nal freephone
> > > > > number may
> > > > > > be required for correct call handling.
> > > > > >
> > > > > > If you now consider the following example (mo= dified from
> > > > Francois'
> > > > > > text in the latest draft - excuse any errors = that I may
> > > > > have inserted)
> > > > > >
> > > > > > INVITE sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx=
> > > > > > Privacy: history
> > > > > > History-Info:
> > > > > >
> > > > > <sip:+18001234567@example.com;user=3Dphone;p=3Dx>;index=3D1;rt;= aor
> > > > > =A0 =A0 =A0 =A0(1)
> > > > > > History-Info: <sip:bob@biloxi.example.com>;index=3D1.1;mp;aor<= br> > > > > > > (2)
> > > > > > History-Info: <sip:bob@192.0.2.3>;index=3D1.1.1;rc
> > > > > > (3)
> > > > > >
> > > > > > In this case due to the Privacy header all of= the H-I
> > > entries are
> > > > > > considered private and the +18001234567 will = not be
> > > > > delivered to the
> > > > > > final destination with the result that call h= andling may
> > > > > not be correct.
> > > > > > The Privacy header may have been inserted by = any of the
> > > > nodes which
> > > > > > routed the message and inserted a H-I entry.<= br> > > > > > >
> > > > > > If however the H-I was allowed to include a h= eader
> > parameter of
> > > > > > "?Privacy=3Dnone" in the H-I entry = and that an explicit
> > H-I entry
> > > > > > privacy value would be considered to have pre= cedence over
> > > > a Privacy
> > > > > > header with a value of "history" th= en the mapping of the
> > > > > +18001234567
> > > > > > could be explicitly specified as not private = and may be
> > > passed on.
> > > > > >
> > > > > > Thus when the mapping from sip:+18001234567@example.com to
> > > > > > sip:bob@biloxi.example.com when H-I entry (2) above is
> > > > > included could
> > > > > > also insert the Privacy header parameter in H= -I entry (1).
> > > > > >
> > > > > > Thus the message would appear as follows:
> > > > > >
> > > > > > INVITE sip:sip:+18001234567@example.com; user=3Dphone;p=3D= x
> > > > > > Privacy: history
> > > > > > History-Info:
> > > > > >
> > > > >
> > > >
> > >
> >
> <sip:+18001234567@example.com?Privacy=3Dno= ne;user=3Dphone;p=3Dx>;index=3D1;rt;
> > > > > > ao
> > > > > > r
> > > > > > History-Info: <sip:bob@biloxi.example.com>;index=3D1.1;mp;aor<= br> > > > > > > History-Info: <sip:bob@192.0.2.3>;index=3D1.1.1;rc
> > > > > >
> > > > > > This would result in all the H-I entries exce= pt (1) being
> > > > > considered
> > > > > > private with the result that the =3D1800... N= umber is
> > > > passed for call
> > > > > > handling purposes.
> > > > > >
> > > > > > This change is backward compatible with the e= xisting
> > > > > implementation as
> > > > > > any node using the existing functionality as = defined in
> > > > > RFC4244 will
> > > > > > continue to be supported.
> > > > > >
> > > > > > The alternative is to remove the ability to i= nclude the
> > > > > value "history"
> > > > > > in the Privacy header and only allow this val= ue in the
> > > > > Privacy header
> > > > > > parameter. This alternative is not backward c= ompatible.
> > > > > >
> > > > > > Without this change a single node in the mess= age path which
> > > > > includes a
> > > > > > header "Privacy: history" will prev= ent delivery of the
> > > > aor and thus
> > > > > > prevent proper call handling.
> > > > > >
> > > > > > Ian Elz
> > > > > >
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Christer Holmberg
> > > > > > Sent: 23 June 2009 19:40
> > > > > > To: 'Mary Barnes'; Francois Audet; Ha= ns Erik van
> > Elburg; Shida
> > > > > > Schubert
> > > > > > Cc: Ian Elz
> > > > > > Subject: RE: 4244bis and privacy
> > > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > I include Ian, so he can comment to your resp= osne himself.
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Christer
> > > > > >
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com]
> > > > > > Sent: Tuesday, June 23, 2009 9:40 PM
> > > > > > To: Christer Holmberg; Francois Audet; Hans E= rik van
> > > > Elburg; Shida
> > > > > > Schubert
> > > > > > Subject: RE: 4244bis and privacy
> > > > > >
> > > > > > Here was the thread of response and the last = comment was
> > > > > from Ian that
> > > > > > he would consider the response:
> > > > > >
> http://www.ietf.org/mail-archive/web/sip/current/msg= 26948.html
> > > > > >
> > > > > > And, there was not agreement on the "non= e" but rather to
> > > > > qualify the
> > > > > > SHOULD NOT forward. =A0However, in the sipcor= e-4244bis-00,
> > > > > rather than
> > > > > > changing the text such that the headers SHOUL= D be
> removed, we
> > > > > > recommend that they be anonymized (in section= 4.3.3.3.1).
> > > > =A0That is
> > > > > > entirely consistent with RFC 3324 and thus we= have
> > removed the
> > > > > > recommendations to remove the headers entirel= y. However,
> > > > > that changed
> > > > > > never got done in section 3.2, so we would ne= ed to
> > change this:
> > > > > > =A0 =A0"Thus, the History- Info header > > > > > > =A0 =A0SHOULD NOT be included in Requests whe= re the requestor
> > > > > has indicated
> > > > > > =A0 =A0a priv-value of Session- or Header-lev= el privacy."
> > > > > >
> > > > > > But, I'm really beginning to be of the mi= ndset that we
> > > > should just
> > > > > > remove all the subsections of section 3 (i.e.= , leave the
> > > > > text in the
> > > > > > upper level section), so we don't have to= keep
> worrying about
> > > > > > consistency.
> > > > > >
> > > > > > So, lets either fixt the text in 3.2 or remov= e altogether
> > > > > and then I
> > > > > > think we are really at the point of needing t= o submit this
> > > > > version so
> > > > > > folks that actually have an interest in it ca= n review
> > > the updated
> > > > > > document.
> > > > > >
> > > > > > Mary.
> > > > > >
> > > > > > -----Original Message-----
> > > > > > From: Christer Holmberg
> > [mailto:christe= r.holmberg@ericsson.com]
> > > > > > Sent: Tuesday, June 23, 2009 1:10 PM
> > > > > > To: Barnes, Mary (RICH2:AR00); Audet, Francoi= s
> > > > > (SC100:3055); Hans Erik
> > > > > > van Elburg; Shida Schubert
> > > > > > Subject: 4244bis and privacy
> > > > > >
> > > > > >
> > > > > > Hi,
> > > > > >
> > > > > > Below is a comment/proposal which one of my c= ollegues (Ian
> > > > > Elz) gave
> > > > > > on the list a while ago, when the first versi= on of
> > 4244bis was
> > > > > > submitted, but was not incorporated. Do you t= hink it would
> > > > > be useful?
> > > > > >
> > > > > > -------
> > > > > >
> > > > > > While the HI approach to target may solve the= problem of
> > > > > being able to
> > > > > > deliver the target URI to the final destinati= on there is no
> > > > > guarantee
> > > > > > that it will actually be delivered.
> > > > > >
> > > > > > The problem arises with how Privacy is define= d for HI.
> > > > > >
> > > > > > 4424 defines a new Privacy value "histor= y" which may be
> > > placed in
> > > > > > either the Privacy header or as a header para= meter to the
> > > > HI entry.
> > > > > >
> > > > > > If one node uses the former option "Priv= acy: history" then
> > > > > this will
> > > > > > make all headers private and will result in a= ll HI
> > > entries being
> > > > > > removed or made anonymous when the message co= ntaining
> > the HI is
> > > > > > delivered to the user.
> > > > > >
> > > > > > There is a simple solution to this and that i= s to also
> > > > > allow the use
> > > > > > of the "none" Privacy value as a he= ader parameter in the
> > > > HI entry.
> > > > > > This would explicitly state that no privacy i= s required
> > > to the HI
> > > > > > entry and this would override a "history= " value in the
> > > > > Privacy header.
> > > > > >
> > > > > > I pointed this out to Mary when the 4424bis d= raft was first
> > > > > published
> > > > > > but the change has not been made in the lates= t draft.
> > > > > >
> > > > > > The change is backward compatible and would n= ot cause an
> > > > issue with
> > > > > > any existing implementations.
> > > > > >
> > > > > > ------
> > > > > >
> > > > > > Regards,
> > > > > >
> > > > > > Christer
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > _____________________________________________= __
> > > > > > sipcore mailing list
> > > > > > sipcore@i= etf.org
> > > > > > https://www.ietf.org/mailman/listinfo/sipcor= e
> > > > > > _____________________________________________= __
> > > > > > sipcore mailing list
> > > > > > sipcore@i= etf.org
> > > > > > https://www.ietf.org/mailman/listinfo/sipcor= e
> > > > > >
> > > > > _______________________________________________ > > > > > sipcore mailing list
> > > > > sipcore@ietf.o= rg
> > > > > https://www.ietf.org/mailman/listinfo/sipcore=
> > > > >
> > > > _______________________________________________
> > > > sipcore mailing list
> > > > sipcore@ietf.org
> > > > https://www.ietf.org/mailman/listinfo/sipcore
> > > >
> > >
> >
>

--0015174c3c6a44caaf046db47af7-- From ian.elz@ericsson.com Thu Jul 2 01:05:21 2009 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 6E2143A695E for ; Thu, 2 Jul 2009 01:05:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.889 X-Spam-Level: X-Spam-Status: No, score=-5.889 tagged_above=-999 required=5 tests=[AWL=-0.240, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_74=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 q4VUaQWu0Ql2 for ; Thu, 2 Jul 2009 01:05:17 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 44CAE3A6818 for ; Thu, 2 Jul 2009 01:05:16 -0700 (PDT) X-AuditID: c1b4fb3c-b7bdcae0000052f9-6a-4a4c6a503f70 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 57.58.21241.05A6C4A4; Thu, 2 Jul 2009 10:05:37 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 2 Jul 2009 10:04:15 +0200 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, 2 Jul 2009 10:04:16 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EC8AD11@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] 4244bis and privacy Thread-Index: Acn11AWR+Z7be2FAQvKtnWIFO4vfcAAB1KHQAABgLvAAFKai8AAAYdKwABEiZHAAitux8AAa+YTgABHtvHAASa8UkAAbXziQ References: <1ECE0EB50388174790F9694F77522CCF1EA7FE55@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EA809F4@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EAD7773@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EB2624A@zrc2hxm0.corp.nortel.com> <9886E5FCA6D76549A3011068483A4BD4048F809B@S4DE8PSAAQB.mitte.t-com.de> <4A43DEC9.1020802@gmail.com> <9886E5FCA6D76549A3011068483A4BD4048F80AC@S4DE8PSAAQB.mitte.t-com.de> <1ECE0EB50388174790F9694F77522CCF1EB26AB5@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D00213AA4C@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522C! CF1EB6B D69@zrc2hxm0 .corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EBE2181@zrc2hxm0.corp.nortel.com> A<0D5F89FAC29E2C41B98A6A762007F5D00213B56F@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1EC8AD11@zrc2hxm0.corp.nortel.com> From: "Ian Elz" To: "Francois Audet" , "Elwell, John" , "Mary Barnes" , , X-OriginalArrivalTime: 02 Jul 2009 08:04:15.0896 (UTC) FILETIME=[B17FA180:01C9FAEB] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org, shida@agnada.com Subject: Re: [sipcore] 4244bis and privacy 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, 02 Jul 2009 08:05:21 -0000 Francois, I see what you mean. Section 3.3 has the offending words. The Privacy header is set by the originating user. Is it likely that the = URI of the originating user will appear in the H-I entries? Perhaps when RFC4244 was originally written it was recognized that the = "Privacy:user" specifically related to the originator and the H-I header = would not include the originators URI. I see your point about "session" though. I think that we need a wider discussion about Privacy in general. The = existing Privacy for the originating user as described in RFC3323 is = fine but the issue has become wider. Ian Elz (I am on vacation from this afternoon and am not back until 13 July so I = will probably have a lot to catch up on this thread.) -----Original Message----- From: Francois Audet [mailto:audet@nortel.com]=20 Sent: 01 July 2009 19:43 To: Elwell, John; Ian Elz; Mary Barnes; R.Jesske@telekom.de; = ietf.hanserik@gmail.com Cc: sipcore@ietf.org; shida@agnada.com Subject: RE: [sipcore] 4244bis and privacy I see another problem with Privacy in RFC 4244. Currently, it talks about "Session" Privacy impacting HI and says = nothing about "User" privacy impacting HI. (see RFC 3323) This makes no sense to me. Session is supposed to relate strictly to = SDP-level information (i.e., IP address inside SDP, and maybe some other = fields). I don't see at all why "session" would mean don't do HI. On the other hand 4244 is silent about "User" Privacy. I belive if "user = privacy" is used, then defintively it implies the URIs representing that = user should be anonymized. Views? =20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Tuesday, June 30, 2009 00:30 > To: Audet, Francois (SC100:3055); Ian Elz; Barnes, Mary (RICH2:AR00);=20 > R.Jesske@telekom.de; ietf.hanserik@gmail.com > Cc: sipcore@ietf.org; shida@agnada.com > Subject: RE: [sipcore] 4244bis and privacy >=20 > Yes, I think something like this makes sense. >=20 > John >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: 30 June 2009 00:06 > > To: Ian Elz; Elwell, John; Mary Barnes; R.Jesske@telekom.de;=20 > > ietf.hanserik@gmail.com > > Cc: sipcore@ietf.org; shida@agnada.com > > Subject: RE: [sipcore] 4244bis and privacy > >=20 > > I think the current "interpretation" is not terribly > useful. I prefer > > your suggestion. The current RFC 4244 text is not very clear. > >=20 > > It seems to me that: > > - Privacy should associated with a specific hi-entry (and > perhaps any > > entry that corresponds to that same user), and not the header=20 > > itself. > > - That way, it is possible that specific entries be > anonymize, but not > > others. For example, if you call me without privacy, and I call=20 > > forward > > you to John with privacy setup for myself, John should > see an entry > > for > > you and an anonymized entry for me. > > - There is no reason why "none" couldn't be used in this context.=20 > > Again, > > with the same example as above, John could requies "none"=20 > > for him, and > > I could set privacy on for myself. > >=20 > > I don't think this type of rule for 4244bis would require > any change > > whatsoever to RFC 3323. It would be completely self-contained in=20 > > 4244bis. > >=20 > > Comments? > >=20 > > > -----Original Message----- > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > Sent: Monday, June 29, 2009 03:26 > > > To: Audet, Francois (SC100:3055); Elwell, John; Barnes, Mary=20 > > > (RICH2:AR00); R.Jesske@telekom.de; ietf.hanserik@gmail.com > > > Cc: sipcore@ietf.org; shida@agnada.com > > > Subject: RE: [sipcore] 4244bis and privacy > > >=20 > > > Francios, > > >=20 > > > I agree that 4244bis should not specify the actions of > proxies etc > > > where this is a matter of local policy. > > >=20 > > > My original proposed change was to allow the inclusion of > the value > > > "none" in the alongside the value "history" to be included in the=20 > > > Privacy header parameter escaped in the > hi-targeted-to-uri. (RFC4244 > > > section 4.1) > > >=20 > > > It appears however that the current interpretation of the Privacy=20 > > > header means that the value included in the Privacy > header, which is > > > applicable to the originating rather than retargeting user is=20 > > > applied to the retargeting user rather than the explicit value=20 > > > included for the retargeting user. > > > The escaped privacy value is only used if there is no > Privacy header > > > or the Privacy header only contains the value "user". > > >=20 > > > The end result of this interpretation is that including > an explicit > > > value "none" escaped as a Privacy parameter would have no > effect and > > > would have the same meaning as not including a Privacy header=20 > > > parameter escaped in the hi-targeted-to-uri. > > >=20 > > > 4244bis is not the place to extend the sip Privacy handling to=20 > > > specify how 3rd party identities in sip messages should > have their > > > own specific privacy maintained. > > >=20 > > > Allowing the inclusion of the explicitly Privacy=3Dnone > value in the > > > hi-targeted-to-uri would not change any handling at this time but=20 > > > would make the new H-I RFC suitable for use if an updated privacy=20 > > > RFC is proposed which does have specific support for 3rd party=20 > > > identities. > > >=20 > > > H-I is not the only place where the explicit privacy of 3rd party=20 > > > identities is required. The Referred-By header is one other case=20 > > > where a similar explicit privacy may need to be considered in the=20 > > > future. > > >=20 > > > regards > > >=20 > > > Ian > > >=20 > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortel.com] > > > Sent: 26 June 2009 16:55 > > > To: Ian Elz; Elwell, John; Mary Barnes; R.Jesske@telekom.de;=20 > > > ietf.hanserik@gmail.com > > > Cc: sipcore@ietf.org; shida@agnada.com > > > Subject: RE: [sipcore] 4244bis and privacy > > >=20 > > > I do see things that we should fix right-away in History-Info,=20 > > > regarding privacy. > > >=20 > > > I also think that History-Info shouldn't "overstrech" and get too=20 > > > deep into the nitty gritty of privacy. What should be in > HI is high > > > level guidance. > > >=20 > > > In section 3.1, for example, it says that Privacy header will=20 > > > determine if a History-Info *header field* can be included by an=20 > > > intermediary. This does not make any sense. What it should say is=20 > > > that the Privacy header will determine if a history-info > *entry* can > > > be added for the UA inserting the Privacy header. > > >=20 > > > So, in my opinion, we can go ahead and fix that right now. > > >=20 > > > I don't think we need to get into super low-level procedural=20 > > > descriptions of the type "proxy MUST this and that if Privacy = =3D=3D=20 > > > this and that". I believe privacy matters are > policy-level decisions > > > that service providers and enteprises will have, and they are not=20 > > > going to be implemented by simplistic procedural rules > from an RFC. > > >=20 > > > Comments? > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: sipcore-bounces@ietf.org > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Ian Elz > > > > Sent: Friday, June 26, 2009 01:08 > > > > To: Elwell, John; Barnes, Mary (RICH2:AR00); > R.Jesske@telekom.de; > > > > ietf.hanserik@gmail.com > > > > Cc: sipcore@ietf.org; shida@agnada.com > > > > Subject: Re: [sipcore] 4244bis and privacy > > > >=20 > > > > John, > > > >=20 > > > > Your statement " not anonymise or remove any information > > > that the UAC > > > > has already placed in the request " is the key here. > > > >=20 > > > > The UAC has not included the H-I entry, particularly the one=20 > > > > containing the identity of the diverting party. > > > >=20 > > > > This was not considered in RFC3323 and we have an issue > where we > > > > cannot determine which entity included which information. > > > > This creates a problem where a restriction by the > > originating party > > > > will prevent a downstream identity from permitting > > presentation of > > > > their identity. > > > >=20 > > > > I agree with Mary that this probably requires an update to > > > > RFC3323 so we should start by updating RFC3323 and then > > > move on to the > > > > other impacted RFCs. The issue that this will raise for > > H-I is that > > > > there will be another change required after the Privacy RFC > > > has been > > > > agreed. > > > >=20 > > > > This is far from ideal but the 4424bis draft contains a lot > > > more than > > > > just this issue. > > > >=20 > > > > Ian > > > >=20 > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: 26 June 2009 08:30 > > > > To: Mary Barnes; R.Jesske@telekom.de; ietf.hanserik@gmail.com > > > > Cc: Ian Elz; sipcore@ietf.org; shida@agnada.com > > > > Subject: RE: [sipcore] 4244bis and privacy > > > >=20 > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: sipcore-bounces@ietf.org=20 > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Mary Barnes > > > > > Sent: 25 June 2009 22:45 > > > > > To: R.Jesske@telekom.de; ietf.hanserik@gmail.com > > > > > Cc: ian.elz@ericsson.com; sipcore@ietf.org; shida@agnada.com > > > > > Subject: Re: [sipcore] 4244bis and privacy > > > > >=20 > > > > > Roland, > > > > >=20 > > > > > The reason you can't have "none" at the request level and > > > > "history" at > > > > > the entry level is because RFC 3323 states that you MUST > > > NOT apply > > > > > privacy to the message. Even if you put "history" in the > > > > entries, the > > > > > privacy service would just ignore that - per RFC 3323. =20 > > > So, if you > > > > > want to change that behavior, then RFC 3323 should be > > > > changed - i.e., > > > > > the MUST NOT for the "none" could be changed to a SHOULD > > > > NOT and then > > > > > a general statement about possible exceptions. Then, we > > could add > > > > > something to RFC 4244 for this case. But, changing RFC > > > > > 3323 is totally out of scope for what we are currently > > > working on. =20 > > > > [JRE] I would interpret privacy 'none' in RFC 3323 as > > > meaning that a > > > > downstream entity must not anonymise or remove any > > information that > > > > the UAC has already placed in the request. > > > > If a downstream entity chooses: > > > > - not to add H-I, > > > > - to add anonymised H-I, or > > > > - to anonymise an H-I entry that some intermediate entity > > > has added, I > > > > don't see that as being in violation of what the UAC has > > requested. > > > >=20 > > > > John > > > >=20 > > > >=20 > > > > >=20 > > > > > That all said, I would sure think that if you are leaving a > > > > "trusted > > > > > network" that you have a B2BUA in there, as I've said > in other > > > > > threads. Thus, the B2BUA builds a new request and certainly > > > > can add a > > > > > privacy header that it believes is appropriate since > > the outgoing > > > > > request is done by the UAC function of a B2BUA. > > > > >=20 > > > > > Mary.=20 > > > > >=20 > > > > >=20 > > > > > -----Original Message----- > > > > > From: R.Jesske@telekom.de [mailto:R.Jesske@telekom.de] > > > > > Sent: Thursday, June 25, 2009 4:32 PM > > > > > To: ietf.hanserik@gmail.com > > > > > Cc: Barnes, Mary (RICH2:AR00); ian.elz@ericsson.com; > > > > sipcore@ietf.org; > > > > > shida@agnada.com > > > > > Subject: AW: [sipcore] 4244bis and privacy > > > > >=20 > > > > > Hi Hans Erik, > > > > > We have also to take regulatory into consideration. In > > > Germany the > > > > > last trusted network is responsible for anonymising > information. > > > > >=20 > > > > > But nevertheless if Network provider A wants to have History=20 > > > > > completely private this operator will set privacy > > history for the > > > > > header. > > > > > If the succeeding Operator want to present elements the AS > > > > which adds > > > > > a entry has then to re label all entries from the > > > preceding network > > > > > and the entries from it's own network will be unmarked > > within the > > > > > Header. > > > > >=20 > > > > > But never the less I fully agree to your last sentence. > > > > >=20 > > > > > The real Question is if this should really be allowed > > > that a entry > > > > > marked with "none" overrules the privacy statement > > > > "history" for the > > > > > complete header. > > > > >=20 > > > > > I'm against this behaviour.=20 > > > > >=20 > > > > > Best Regards > > > > >=20 > > > > > Roland > > > > >=20 > > > > > -----Urspr=FCngliche Nachricht----- > > > > > Von: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > > > > Gesendet: Donnerstag, 25. Juni 2009 22:32 > > > > > An: Jesske, Roland > > > > > Cc: mary.barnes@nortel.com; ian.elz@ericsson.com; > > > sipcore@ietf.org; > > > > > shida@agnada.com > > > > > Betreff: Re: [sipcore] 4244bis and privacy > > > > >=20 > > > > > Hi Roland, > > > > >=20 > > > > > I don't understand the argument, by the time that the > > > History-Info > > > > > leaves operator A that wishes complete privacy, all the > > > > History-Info > > > > > headers should be anonymised according to 4244 and 4244bis. > > > > >=20 > > > > > What is the point in mandating that operator A to force > > > > operator B to > > > > > also anonymise the entries "owned" by operator B. > > > > >=20 > > > > > It is of course without question that each operator has > > > > full privacy > > > > > control over its own added entries. And each operator can > > > based on > > > > > local policy decide to remove the entire history if it > > > > things that is > > > > > wise to do. > > > > >=20 > > > > > /Hans Erik > > > > >=20 > > > > >=20 > > > > > R.Jesske@telekom.de wrote: > > > > > > Hi Marry and Ian, > > > > > > The whole discussion puzzle me. We have specified CDIV > > > > > within TISPAN and 3GPP.=20 > > > > > > There is described that privacy "none" can be used for > > > > > entries. BUT assuming that each entry has its own privacy > > > > statement if > > > > > needed. > > > > > > I fully agree on Mary's comment that a privacy "history"=20 > > > > > cannot overruled by a privacy value "none" within a entry.=20 > > > > > > There may be operators that would like to keep the whole > > > > > History Info private even if entries has other > > statements, so the > > > > > entity could add privacy history to the whole header. > > > > > Nothing more. > > > > > > > > > > > > On the other side a Application Server including a entry > > > > > should have the possibility to rewrite the entries so that > > > > instead of > > > > > "history" for the whole header the all received entries > > > within the > > > > > History-Info header will be marked with "history" and the > > > > added header > > > > > (which shall be presented to the terminating user) will > > either be > > > > > marked with "none" or will not be marked. > > > > > > > > > > > > Perhaps a hint could be given, but I do not insist on it. > > > > > > > > > > > > Best Regards, > > > > > > > > > > > > Roland > > > > > > > > > > > > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > > Von: sipcore-bounces@ietf.org > > > > [mailto:sipcore-bounces@ietf.org] Im > > > > > > Auftrag von Mary Barnes > > > > > > Gesendet: Donnerstag, 25. Juni 2009 18:29 > > > > > > An: Ian Elz > > > > > > Cc: sipcore@ietf.org; Shida Schubert > > > > > > Betreff: Re: [sipcore] 4244bis and privacy > > > > > > > > > > > > Hi Ian, > > > > > > > > > > > > Responses inline below [MB2]. > > > > > > > > > > > > Mary. > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > > > > Sent: Thursday, June 25, 2009 10:13 AM > > > > > > To: Barnes, Mary (RICH2:AR00) > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida > Schubert; > > > > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > Mary, > > > > > > > > > > > > I am a little concerned about one answer that you gave: > > > > > > > > > > > > > > > > > > If you have a Privacy header with a value of "none" and a > > > > H-I entry > > > > > > with Privacy header parameter with value "history" what is > > > > > the privacy > > > > > > of the individual H-I entry? > > > > > > [MB] We did not explicitly address the "none" in RFC > > > > 4244, but the > > > > > > general statement is the privacy headers at the request > > > > > level override > > > > > > any at the hi-entry level. [/MB] > > > > > > =20 > > > > > > This means that if privacy is required for an individual > > > > > H-I entry but > > > > > > the originating user included "Privacy:none" in the request > > > > > then there > > > > > > is no option to include the real URI in the H-I entry. > > > > > > [MB2] I'm confused here - the "none" definition is as you > > > > > note below, > > > > > > thus "none" prohibits the removal or anonymization of the > > > > entries, > > > > > > thus I would think you would fine this functionality > > desireable. > > > > > > However, this does not prohibit an entity based on policy > > > > > to anonymize > > > > > > (or remove entries if privacy is required for that > > > domain if the > > > > > > entity does not have access to a privacy service). [/MB2] > > > > > > > > > > > > This occurs as RFC3323 states in section 4.3: "However, if > > > > > the Privacy > > > > > > header value of 'none' is specified in a message, privacy > > > > services > > > > > > MUST NOT perform any privacy function and MUST NOT remove > > > > or modify > > > > > > the Privacy header." > > > > > > > > > > > > The only option for an intermediate node including a H-I > > > > > entry where > > > > > > "Privacy:none" is specified and privacy for the H-I URI is > > > > > required is > > > > > > to include an anonymous entry or not include the H-I entry. > > > > > > [MB2] If privacy is required then yes, you include > > > > > anonymous entries > > > > > > or don't include. That's the basic privacy mechanism > > > for privacy > > > > > > levels of "session" "header" and "history" in the R-URI or > > > > > "history"=20 > > > > > > in the specific entries, as well as when there is a policy > > > > > for privacy > > > > > > for the entries added by a specific domain. The "none"=20 > > > > > really has no > > > > > > influence on the later case per se. [/MB2] > > > > > > > > > > > > In your previous response you stated that we would violate > > > > > RFC3323 if > > > > > > we specified additional behaviour for privacy explicitly > > > > > stated with a > > > > > > URI -n the H-I entry. I don't believe that this is the case > > > > > as RFC3323 > > > > > > only considered privacy in a two party scenario and did not > > > > > consider > > > > > > third party identities being included in a message > > between two > > > > > > parties. H-I is not the only case where this occurs as the > > > > > Referred-By > > > > > > header when included in the INVITE (or other request) > > > > which results > > > > > > from the REFER has the same issue. > > > > > > [MB2] I can't necessarily disagree on this one (we can > > > debate it > > > > > > either way). But to fix it requires an update to > RFC 3323 and > > > > > > shouldn't be something that we want to fix in > 4244bis. [/MB2] > > > > > > > > > > > > RFC4244 was the first time that there was a recognition > > > > > that privacy > > > > > > for these individual third party identities may be > > > > > required. To allow > > > > > > this explicit statement of privacy to be overridden by > > > a generic > > > > > > statement which is applicable to a different user is > > > > > counterintuitive. > > > > > > [MB2] See my comment above. But, as I have consistently > > > > > said, the idea > > > > > > that an entity might want to override the "none" is > > > > > entirely based on > > > > > > policy and 4244 and 4244bis allow privacy to be applied to > > > > > the entries > > > > > > that are added by that entity if the policy dictates > > so (and we > > > > > > already say that). [/MB2] > > > > > > > > > > > > The original Privacy header is usually included by or on > > > > > behalf of the > > > > > > originating user and should not be allowed to specify the > > > > > privacy of > > > > > > the original called user, e.g. the 800 number, and > > prevent this > > > > > > identity being presented if this user does not have the > > > > > same level of privacy. > > > > > > [MB2] As I tried to say in a previous response, a random > > > > > entity (i.e., > > > > > > one for whom the R-URI is not in a domain under its > > > > control) cannot > > > > > > add a privacy header to the Request. Per RFC 3323 an > > > > entity may add > > > > > > the header to a request only if it has the appropriate=20 > > > > > > relationship/authorization with the original called user > > > > > who intiated > > > > > > the request. And, I would find it very surprising if an > > > > entity that > > > > > > did have responsibility would apply privacy since > > that would be > > > > > > counter intuitive and I would hope that SPs would be > > > judicious in > > > > > > specifying the appropriate and inappropriate manner in > > > which the > > > > > > proxies they deploy and interface with privatize the > > > > messages. The > > > > > > protocol CANNOT control this behavior and that's why > > > there is the > > > > > > policy clause in 4244 and 4244bis. [/MB2] > > > > > > > > > > > > The real issue with the 800 scenario is as you have stated > > > > > is that the > > > > > > answerer will not know the original called identity and > > > > will not be > > > > > > able to correctly handle the call. As more generic call > > > > centres are > > > > > > used which will answer calls on behalf of many different > > > > > organizations > > > > > > using CTI and the original called identity to have to > > > implement a > > > > > > generic system asking the caller who he originally > > > called appear > > > > > > unprofessional, is inefficient and unproductive. > > > > > > [MB2] And, as I noted, it is rare for a call centre to > > > > route a call > > > > > > directly to an agent without a user providing some sort of > > > > > input. Even > > > > > > companies like American Airlines, even though they have the > > > > > info that > > > > > > I enter via the IVR, they still ask some basic questions > > > > > and there are > > > > > > times when they have to reroute me. I don't think we > > > can totally > > > > > > automate things. And, again, once the call hits the > > > > domain that is > > > > > > responsible for that 800 number the entities in that > > > domain have > > > > > > control over how they muck with the R-URI, such that they > > > > should be > > > > > > able to use any IVR info to appropriately direct the call - > > > > > it's not > > > > > > the number that's meaningful, but how the system gets the > > > > > call to the > > > > > > right user and the additional information they provide as > > > > > the call is > > > > > > presented to the agent. I would honestly think that having > > > > > something > > > > > > other than an 800 number show up on the display would > > > be far more > > > > > > useful and in my experience in the systems I developed > > > > > we're usually > > > > > > talking about CTI interfaces so you have a lot you can > > > do. And, > > > > > > actually all of this really doesn't matter in that you MUST > > > > > be able to > > > > > > handle this situation independent of the privacy since > > > > > History-Info is > > > > > > optional, you need default behavior assigned. [/MB2] > > > > > > > > > > > > We have an opportunity to allow presentation of specific > > > > identities > > > > > > and to solve this particular problem so we should take it. > > > > > > [MB2] The most we can do is to document the risks/impacts > > > > > of the use > > > > > > of the Privacy headers at the R-URI level. There is > > > > already general > > > > > > text in > > > > > > 4244 and 4244bis that the privacy may impact whether the > > > > > applications > > > > > > get the information. And, as I noted before, most > > > > > commercial systems > > > > > > are using B2BUAs which will allow you far more control over > > > > > the use of > > > > > > the Privacy headers in the network. But, again, I don't > > > > > think that's > > > > > > something that should be address in 4244bis. [/MB2] > > > > > > > > > > > > I hope that we can get some wider discussion on this issue > > > > > so a more > > > > > > general consensus can be obtained. > > > > > > > > > > > > Regards > > > > > > > > > > > > Ian > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > > > > Sent: 24 June 2009 17:27 > > > > > > To: Ian Elz > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida > Schubert; > > > > > > sipcore@ietf.org; Francois Audet > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > Hi Ian, > > > > > > > > > > > > Responses inline below [MB]. > > > > > > > > > > > > Mary.=20 > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > > > > Sent: Wednesday, June 24, 2009 10:37 AM > > > > > > To: Barnes, Mary (RICH2:AR00) > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida > Schubert; > > > > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > Mary, > > > > > > > > > > > > I was not proposing that we change the handling of H-I > > > > > which is based > > > > > > upon local policy. If that causes an issue for a network > > > > > operator then > > > > > > they can modify their local policy accordingly or arrange > > > > with the > > > > > > proxy vendor to modify their equipment to be more > > flexible with > > > > > > regards to policy. > > > > > > > > > > > > Can you clarify for me: > > > > > > > > > > > > If you have a Privacy header with either "session" or > > > > "header" doe > > > > > > this impact the H-I entries or will only a value of > > > > > "history" impact > > > > > > the H-I entries? > > > > > > [MB] Yes, both "session" and "header" level privacy, > > > > > consistent with > > > > > > RFC 3323, mandate that entries be anonymized or > > > dropped, with the > > > > > > latter being the recommendation for "session" level > > > > > privacy. RFC 4244 > > > > > > mandated that they be dropped and 4244bis > recommends they be > > > > > > anonymized. The original intent for the value of "history" > > > > > was for the > > > > > > tagging of the individual entries, but you end up getting > > > > > the header > > > > > > level functionality as well. [/MB] > > > > > > > > > > > > If you have a Privacy header with a value of "none" and a > > > > H-I entry > > > > > > with Privacy header parameter with value "history" what is > > > > > the privacy > > > > > > of the individual H-I entry? > > > > > > [MB] We did not explicitly address the "none" in RFC > > > > 4244, but the > > > > > > general statement is the privacy headers at the request > > > > > level override > > > > > > any at the hi-entry level. [/MB] > > > > > > > > > > > > From reading RFC4244 a Privacy header with value > > "history" will > > > > > > effectively make all H-I entries private and there is > > > > currently no > > > > > > option to include a H-I Privacy header parameter with > > > > value "none". > > > > > > [MB] Correct, per my comment above. [/MB] > > > > > > > > > > > > H-I at present allows the inclusion of Privacy header > > > > parameters to > > > > > > explicitly express privacy for an individual H-I entry > > > > but a single > > > > > > node which includes a header "Privacy: history" makes all > > > > > H-I entries > > > > > > private even if this is not the requirements for the > > > specific URI. > > > > > > [MB] Correct, but the only node that should add the header > > > > > is a node > > > > > > which is responsible for the domain associated with the > > > > > Request URI in > > > > > > the incoming request or is authorized to do so. [/MB] > > > > > > > > > > > > I will admit that having worked in a telephony environment > > > > > for a long > > > > > > time I am used to having privacy of identities set on a > > > > per number > > > > > > basis and the relative inflexibility of the IETF Privacy > > > > header is > > > > > > relatively restrictive as to specifying which > > identities may be > > > > > > presented and which not. > > > > > > [MB] Yes, this is an entirely different paradigm. I > > developed > > > > > > telephony s/w for over a decade and this is entirely > > > > different - it > > > > > > provides a lot more flexibility, which makes things > > > far, far less > > > > > > deterministic than what you have in telephony switches > > > where your > > > > > > routing and translations are configured for the most part, > > > > > with just a > > > > > > few capabilities for controlling the privacy and it's a > > > > > closed network. > > > > > > > > > > > > With RFC4244/4244bis, there MUST be a mechanism at the > > > UAS or end > > > > > > application that can handle a request that doesn't have the=20 > > > > > > appropriate information either because nodes didn't support=20 > > > > > > History-Info or some random node in the network applied > > > > > privacy (which > > > > > > I think is highly > > > > > > unlikely) - this is normative per section 5 of RFC > > > 4244. So, the > > > > > > worst case scenario I see for this 800 service (which will > > > > > get to the > > > > > > right UAS but without the exact 800 number that was dialed) > > > > > is that it > > > > > > goes to a default ACD group/customer service agent, > > > etc. who then > > > > > > needs to gather the appropriate information and in my > > > > > experience this > > > > > > is often an IVR system these days. So, the service is not > > > > > broken when > > > > > > privacy is applied in an undesireable manner, it's just not > > > > > optimal. =20 > > > > > > This is something that should be addressed in the > > > > target-uri draft > > > > > > which has all the details of how specific services use > > > > History-Info. > > > > > > One other thing to consider is that most networks that are > > > > > emulating > > > > > > telephony type features use B2BUAs, which follow the > > > > > UAS/UAC rules for > > > > > > the header rather than the proxy rules, noting that the > > > > UAC can set > > > > > > the Privacy header to whatever value it sees as appropriate > > > > > for the request. > > > > > > [/MB] > > > > > > > > > > > > > > > > > > Regards > > > > > > > > > > > > Ian > > > > > > > > > > > > -----Original Message----- > > > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > > > > Sent: 24 June 2009 15:48 > > > > > > To: Ian Elz > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida > Schubert; > > > > > > sipcore@ietf.org; Francois Audet > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > Hi Ian, > > > > > > > > > > > > I do not believe we should do the "override" behavior as I > > > > > think that > > > > > > violates RFC 3323, as the "history" is really a subset of > > > > the cases > > > > > > whereby a UAC or proxy would add "session" or "header" to > > > > > the request. > > > > > > And, the latter two cases have the same (undesireable) > > > > > result. I agree > > > > > > this impacts your services, but we can't mandate that > > > > > proxies provide > > > > > > information that might violate their local policies and > > > indeed a > > > > > > proxy's local policies can result in the information being > > > > > anonymized > > > > > > (or removed if they can't anonymize) even in the > "none" case. > > > > > > > > > > > > I do believe it's reasonable that we strongly recommend > > > that the > > > > > > request level (versus specific hi-entries) not be used > > > > and if it is > > > > > > used, the consequence is that some services will > not have the > > > > > > information they need - this was the gist of my previous > > > > > response (to > > > > > > which I did not get any additional feedback). Now, we could > > > > > add some text that the "none" > > > > > > case SHOULD be used (e.g., added by first hop proxy) if it > > > > > is desired > > > > > > that the information not be subject to privacy > > > > > restrictions. I do not > > > > > > think it is then particularly useful to add logic around > > > > the proxy > > > > > > then being able to tag the entries within their domain as > > > > > subject to privacy. > > > > > > I think that conflicts with the intent of the request > > > > level "none". > > > > > > However, as I mention above, per the current text, a proxy > > > > > can (based > > > > > > on local policy) remove entries - so a proxy can capture > > > > hi within > > > > > > their domain and not forward any of that information to the > > > > > next hop > > > > > > in another domain - you already have that functionality. =20 > > > > > But, I think > > > > > > this introduces the general problem that you might be > > > > > impacting other > > > > > > services further down the line, which I thought was the > > > > problem you > > > > > > were wanting to solve - not specifically your example > > > > > service but, for > > > > > > example, in the case that someone is debugging and they > > > want the > > > > > > entire history, so depending upon the service, this is also=20 > > > > > > undesirable behavior. > > > > > > > > > > > > > > > > > > Regards, > > > > > > Mary.=20 > > > > > > > > > > > > -----Original Message----- > > > > > > From: Ian Elz [mailto:ian.elz@ericsson.com] > > > > > > Sent: Wednesday, June 24, 2009 2:57 AM > > > > > > To: Barnes, Mary (RICH2:AR00) > > > > > > Cc: Christer Holmberg; Hans Erik van Elburg; Shida > Schubert; > > > > > > sipcore@ietf.org; Audet, Francois (SC100:3055) > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > > > > > > > Mary, > > > > > > > > > > > > [I have added the list to this thread for wider comment.] > > > > > > > > > > > > In the previous discussions I commented that in RFC4424 > > > > > that a Privacy > > > > > > header with value "history" effectively makes all H-I > > > > > entries private > > > > > > with the result that the H-I entries may be removed. > > > > > > > > > > > > There has now been a comprehensive discussion on > > > > indication of the > > > > > > initial 'target' to the final recipient for call handling > > > > purposes. > > > > > > > > > > > > The main use case related to a freephone example where the > > > > > answering > > > > > > location may be a call centre where the original freephone > > > > > number may > > > > > > be required for correct call handling. > > > > > > > > > > > > If you now consider the following example (modified from > > > > Francois'=20 > > > > > > text in the latest draft - excuse any errors that I may > > > > > have inserted) > > > > > > > > > > > > INVITE sip:sip:+18001234567@example.com;user=3Dphone;p=3Dx > > > > > > Privacy: history > > > > > > History-Info: > > > > > >=20 > > > > > = ;index=3D1;rt;aor =20 > > > > > (1) > > > > > > History-Info: = ;index=3D1.1;mp;aor > > > > > > (2) > > > > > > History-Info: ;index=3D1.1.1;rc > > > > > > (3) > > > > > > > > > > > > In this case due to the Privacy header all of the H-I > > > entries are > > > > > > considered private and the +18001234567 will not be > > > > > delivered to the > > > > > > final destination with the result that call handling may > > > > > not be correct. > > > > > > The Privacy header may have been inserted by any of the > > > > nodes which > > > > > > routed the message and inserted a H-I entry. > > > > > > > > > > > > If however the H-I was allowed to include a header > > parameter of > > > > > > "?Privacy=3Dnone" in the H-I entry and that an explicit > > H-I entry > > > > > > privacy value would be considered to have precedence over > > > > a Privacy > > > > > > header with a value of "history" then the mapping of the > > > > > +18001234567 > > > > > > could be explicitly specified as not private and may be > > > passed on. > > > > > > > > > > > > Thus when the mapping from sip:+18001234567@example.com to=20 > > > > > > sip:bob@biloxi.example.com when H-I entry (2) above is > > > > > included could > > > > > > also insert the Privacy header parameter in H-I entry (1). > > > > > > > > > > > > Thus the message would appear as follows: > > > > > > > > > > > > INVITE sip:sip:+18001234567@example.com; user=3Dphone;p=3Dx > > > > > > Privacy: history > > > > > > History-Info: > > > > > >=20 > > > > >=20 > > > >=20 > > >=20 > >=20 > = ;index=3D= 1;rt; > > > > > > ao > > > > > > r > > > > > > History-Info: = ;index=3D1.1;mp;aor > > > > > > History-Info: ;index=3D1.1.1;rc > > > > > > > > > > > > This would result in all the H-I entries except (1) being > > > > > considered > > > > > > private with the result that the =3D1800... Number is > > > > passed for call > > > > > > handling purposes. > > > > > > > > > > > > This change is backward compatible with the existing > > > > > implementation as > > > > > > any node using the existing functionality as defined in > > > > > RFC4244 will > > > > > > continue to be supported. > > > > > > > > > > > > The alternative is to remove the ability to include the > > > > > value "history" > > > > > > in the Privacy header and only allow this value in the > > > > > Privacy header > > > > > > parameter. This alternative is not backward compatible. > > > > > > > > > > > > Without this change a single node in the message path which > > > > > includes a > > > > > > header "Privacy: history" will prevent delivery of the > > > > aor and thus > > > > > > prevent proper call handling. > > > > > > > > > > > > Ian Elz > > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Christer Holmberg > > > > > > Sent: 23 June 2009 19:40 > > > > > > To: 'Mary Barnes'; Francois Audet; Hans Erik van > > Elburg; Shida > > > > > > Schubert > > > > > > Cc: Ian Elz > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > =20 > > > > > > Hi, > > > > > > > > > > > > I include Ian, so he can comment to your resposne himself. > > > > > > > > > > > > Regards, > > > > > > > > > > > > Christer > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > > > > > Sent: Tuesday, June 23, 2009 9:40 PM > > > > > > To: Christer Holmberg; Francois Audet; Hans Erik van > > > > Elburg; Shida > > > > > > Schubert > > > > > > Subject: RE: 4244bis and privacy > > > > > > > > > > > > Here was the thread of response and the last comment was > > > > > from Ian that > > > > > > he would consider the response: > > > > > >=20 > http://www.ietf.org/mail-archive/web/sip/current/msg26948.html > > > > > > > > > > > > And, there was not agreement on the "none" but rather to > > > > > qualify the > > > > > > SHOULD NOT forward. However, in the sipcore-4244bis-00, > > > > > rather than > > > > > > changing the text such that the headers SHOULD be > removed, we > > > > > > recommend that they be anonymized (in section 4.3.3.3.1). > > > > That is > > > > > > entirely consistent with RFC 3324 and thus we have > > removed the > > > > > > recommendations to remove the headers entirely. However, > > > > > that changed > > > > > > never got done in section 3.2, so we would need to > > change this: > > > > > > "Thus, the History- Info header > > > > > > SHOULD NOT be included in Requests where the requestor > > > > > has indicated > > > > > > a priv-value of Session- or Header-level privacy." > > > > > > > > > > > > But, I'm really beginning to be of the mindset that we > > > > should just > > > > > > remove all the subsections of section 3 (i.e., leave the > > > > > text in the > > > > > > upper level section), so we don't have to keep > worrying about > > > > > > consistency. > > > > > > > > > > > > So, lets either fixt the text in 3.2 or remove altogether > > > > > and then I > > > > > > think we are really at the point of needing to submit this > > > > > version so > > > > > > folks that actually have an interest in it can review > > > the updated > > > > > > document. > > > > > > > > > > > > Mary.=20 > > > > > > > > > > > > -----Original Message----- > > > > > > From: Christer Holmberg > > [mailto:christer.holmberg@ericsson.com] > > > > > > Sent: Tuesday, June 23, 2009 1:10 PM > > > > > > To: Barnes, Mary (RICH2:AR00); Audet, Francois > > > > > (SC100:3055); Hans Erik > > > > > > van Elburg; Shida Schubert > > > > > > Subject: 4244bis and privacy > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > Below is a comment/proposal which one of my collegues (Ian > > > > > Elz) gave > > > > > > on the list a while ago, when the first version of > > 4244bis was > > > > > > submitted, but was not incorporated. Do you think it would > > > > > be useful? > > > > > > > > > > > > ------- > > > > > > > > > > > > While the HI approach to target may solve the problem of > > > > > being able to > > > > > > deliver the target URI to the final destination there is no > > > > > guarantee > > > > > > that it will actually be delivered. > > > > > > > > > > > > The problem arises with how Privacy is defined for HI. > > > > > > > > > > > > 4424 defines a new Privacy value "history" which may be > > > placed in > > > > > > either the Privacy header or as a header parameter to the > > > > HI entry. > > > > > > > > > > > > If one node uses the former option "Privacy: history" then > > > > > this will > > > > > > make all headers private and will result in all HI > > > entries being > > > > > > removed or made anonymous when the message containing > > the HI is > > > > > > delivered to the user. > > > > > > > > > > > > There is a simple solution to this and that is to also > > > > > allow the use > > > > > > of the "none" Privacy value as a header parameter in the > > > > HI entry.=20 > > > > > > This would explicitly state that no privacy is required > > > to the HI > > > > > > entry and this would override a "history" value in the > > > > > Privacy header. > > > > > > > > > > > > I pointed this out to Mary when the 4424bis draft was first > > > > > published > > > > > > but the change has not been made in the latest draft. > > > > > > > > > > > > The change is backward compatible and would not cause an > > > > issue with > > > > > > any existing implementations. > > > > > > > > > > > > ------ > > > > > > > > > > > > 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 > > > > > > =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 > > >=20 > >=20 >=20 From john.elwell@siemens-enterprise.com Thu Jul 2 02:50:23 2009 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 41E853A6D59 for ; Thu, 2 Jul 2009 02:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 lvCKU1LKj6Bh for ; Thu, 2 Jul 2009 02:50:21 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 67E843A6D5C for ; Thu, 2 Jul 2009 02:50:21 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KM50018YFCIMM@siemenscomms.co.uk> for sipcore@ietf.org; Thu, 02 Jul 2009 10:50:42 +0100 (BST) Date: Thu, 02 Jul 2009 10:50:41 +0100 From: "Elwell, John" To: sipcore@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00218BF88@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Review of draft-ietf-sipcore-location-conveyance-00 sections 1 to 3 Thread-Index: Acn68wvbhWYT+bW3Toih/rCadXYLww== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [sipcore] Review of draft-ietf-sipcore-location-conveyance-00 sections 1 to 3 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, 02 Jul 2009 09:50:23 -0000 I focused on sections 1 to 3, since they have been subject to substantial changes. I think the changes on the whole are an improvement, but I still have some minor comments and nits. Minor comments: - "Location Information Server (LIS) - a logical server that stores=20 geolocation records of Targets, which correspond to LbyR URIs." Several problems with this definition: a) What are "geolocation records"? Elsewhere in the document we talk about just "location" or "location information" - I doubt the need to introduce yet another term "geolocation record", which does not seem to be used elsewhere. b) What exactly "correspond" to LbyR URIs. Targets certainly do not "correspond" to LbyR URIs. Also I don't think geolocation records "correspond" to LbyR URIs. Is it trying to say something like "these records being identified by LbyR URIs"? c) I don't think this definition of the term LIS is in line with usage within GEOPRIV documents, e.g., lis-discovery or HELD. In HELD, a LIS provides either a location by value or a reference. A URI provided as a reference will result in a recipient contacting a server to provide the location value, but that server is not necessarily a LIS, I believe. At least I don't believe it acts as a LIS in this circumstance, even if the same physical server can also be a LIS. I think where we use the term LIS in location-conveyance, we should perhaps consider using something like "dereferencing server" instead. - "This document describes how Location can be "conveyed" from one SIP=20 entity unsolicited to another entity using SIP [RFC3261]." I think it would be worth mentioning that it applies only to SIP requests: "This document describes how Location can be "conveyed" in a SIP [RFC 3261] request from one SIP entity unsolicited to another SIP entity." - Later in the same paragraph: "The phrase "location conveyance"=20 describes scenarios in which a SIP user agent client (UAC) is=20 informing a user agent server (UAS) or intermediate SIP server=20 without being previously asked where the UAC is." This is more restrictive than the sentence in the preceding comment (in that conveyance is constrained to start at the UAC, rather than at a proxy). The sentence does not seem to add any value and can be dropped. - "Location Conveyance is different from a UAC, Alice, seeking the=20 location the UAS, Bob. Location conveyance, using SIP, never asks=20 for another entity's location be in a response. Asking for someone=20 else's location is not discussed in this document." This is redundant, since the sentence two comments back already says "unsolicited". If we really need to say anything, we can much more simply say: "Requesting an entity to convey its location via SIP is outside the scope of this document." - "This document describes the extension to SIP for how it complies with the Using Protocol=20 requirements, " I think this would be better worded as: "This document specifies an extension to SIP to allow it to be a Using Protocol in compliance with the requirements of [RFC 3693]." - "Common terms are in Section 1. Section 3 provides an overview of SIP location conveyance. Section 4 details the modifications necessary=20 to accomplish location conveyance. Section 5 gives decode examples=20 of geolocation within SIP requests, both LbyV and LbyR. Section 6=20 articulates the SIP element type behaviors for location conveyance.=20 Section 7 discusses Geopriv privacy considerations. Section 8=20 discusses security considerations. Section 9 IANA registers the=20 modifications made to SIP by this document from section 4." This duplicates the table of contents (well, it hardly adds anything) - delete. - "Section 4 gets into guidance and limitations of this behavior." Section 4 seems to specify normative behaviour, so I would hardly call it guidance. I would delete this sentence. If we really need to retain such a sentence, we should use more precise wording than "gets into". - "It is possible, and it fact, planned in certain=20 circumstances to have SIP requests routed based on the location of=20 the target. This means SIP servers can be location recipients. If=20 this is not desired by a location inserter - the act of including=20 location into this request, then a separate indication is given in=20 the Geolocation header it this usage is allowed." I am not sure what the last sentence means - a "location inserter" is not an "act of including location into this request". I think what might be undesirable is not the fact that SIP servers can be location recipients, but the fact that they might use location information for routing. I think the last sentence should be rewritten something like this. "The location inserter is able to include a separate indication in the Geolocation header field to denote whether routing on the basis of the target's location is permitted." If we do this, then the last sentence seems to follow on nicely from the first sentence, and the second sentence seems to get in the way, so delete the second sentence. If we really need to retain the second sentence, at least change "SIP servers" to "SIP proxies" (since a UAS is also a SIP server). - "There is no mechanism by which the veracity of these parameters can=20 be verified." It is not clear what "these parameters" refers to, because the term "parameter" has not been used in the preceding text. It would be best to enumerate the particular fields that this refers to. - "They are hints to downstream entities on how the=20 location information in the message was originated, intended and=20 used." The words "was ... used" do not make sense - the information has not yet been used - merely conveyed. I am not sure what is intended here. - " LbyR refers to a UA=20 including a location URI in a SIP request header field which can be=20 dereferenced by a Location Recipient to receive Alice's Location=20 Object, in the form of a PIDF-LO." The header field is not dereferenced, it is the location URI that is dereferenced. I would suggest (also making other parts of the sentence more generic): "LbyR refers to a Location Server including in the header of a SIP request a location URI that can be=20 dereferenced by a Location Recipient to receive a Location=20 Object, in the form of a PIDF-LO, representing the Target's location." Nits: - In the abstract, "where SIP servers=20 make routing decisions based on the location of the user agent=20 clients" Change "clients" to "client", since a SIP request can have only one UAC. - "directly or indirectly from transmitting SIP=20 entity" Change to "directly or indirectly from a transmitting SIP=20 entity" - "In=20 other works" Change to "In=20 other words" - "a new SIP header" Change to: "a new SIP header field" (and likewise for "a new header" later. Also other places in the document where "header" is used rather than "header field", even though we are referring to only a part of the SIP header.) - "that points to the where the location is" Change to: "that points to where the location is" - "either in the SIP request itself " I think it would be more accurate to say: "either in the body of the SIP request" - "or on an external server (LbyR)" It is not clear what "external" is relative to. Change to: "or on a server (LbyR)" - "Transport Layer Security is expected when a request contains=20 a target's location. Some implementations will choose to have=20 S/MIME to encrypt message bodies from source to destination." Shouldn't we have a paragraph break before this? John From john.elwell@siemens-enterprise.com Thu Jul 2 02:50:23 2009 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 648143A6D6E for ; Thu, 2 Jul 2009 02:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.553 X-Spam-Level: X-Spam-Status: No, score=-2.553 tagged_above=-999 required=5 tests=[AWL=0.046, 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 wsnEjiu0OiBt for ; Thu, 2 Jul 2009 02:50:22 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 1652B3A6D68 for ; Thu, 2 Jul 2009 02:50:22 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KM500192FCIMM@siemenscomms.co.uk> for sipcore@ietf.org; Thu, 02 Jul 2009 10:50:42 +0100 (BST) Date: Thu, 02 Jul 2009 10:50:42 +0100 From: "Elwell, John" In-reply-to: To: "James M. Polk" , sipcore@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00218BF89@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] SIPCORE Location Conveyance -00 submitted Thread-Index: Acn0/ZzQNjmPdX+hQKyNkjOcAD4FDgF8jzIw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: Subject: Re: [sipcore] SIPCORE Location Conveyance -00 submitted 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, 02 Jul 2009 09:50:23 -0000 =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of James M. Polk > Sent: 24 June 2009 19:56 > To: sipcore@ietf.org > Subject: [sipcore] SIPCORE Location Conveyance -00 submitted >=20 > SIPCORE WG >=20 > I have just submitted=20 > draft-ietf-sipcore-location-conveyance-00.txt here > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio n-conveyance-00.txt >=20 > This is the subsequent version from SIP Location Conveyance -13. >=20 > Here's what's changed in SIPCORE-00 compared to the SIP-13 version: >=20 > - Understanding that readability was a main concern - I reduced the=20 > Intro section to 4 paragraphs (less than half of what was in -13) >=20 > - simplified the Overview section, added a couple of flow figures to=20 > show how location is transmitted within a SIP request in a message=20 > body, and as a URI reference similar to content indirection. >=20 > - moved some of the Intro text to the Overview section, but cut out a=20 > lot of what was in the Overview section that is explained=20 > later in the draft. >=20 > - Removed all the UA-1 vs UA-2 stuff, and replaced it with Alice and=20 > Bob references, making this easier to read. >=20 > - I reduced the terminology section, and what was left that was=20 > already defined in another RFC, is now the same text from that RFC=20 > (which is also referenced each time). >=20 > - I toned down the 2119 text for servers inserting location into a=20 > request from SHOULD NOT to not RECOMMENDED, based on WG comment. [JRE] Why does this constitute a toning down? I though SHOULD NOT and NOT RECOMMENDED were the same in RFC 2119. Can somebody please explain the subtle distinction? John >=20 > - I added RFC5491 (PIDF-LO Usage) and RFC 4483 (SIP Content=20 > Indirection) as references. >=20 > - I removed text saying future error codes can be specified in each=20 > category, as that seems to confuse some about the meaning of this.=20 > But added text saying more granular error codes that have the same=20 > action by a UA can be created. >=20 > - I'm not an S/MIME expert, and was told (a long time ago) it can be=20 > used just for signing, and not encrypting. Two from this WG seemed=20 > to adamantly disagree with this, so I removed that text about=20 > signing only. >=20 > - Clarified a point that is allowed in PIDF-LO, and that SIP=20 > shouldn't attempt to overcome this - that if Bob sends Alice his=20 > location, and sets his to "yes"; within the=20 > time (in which the location is still valid), if=20 > Bob transfers Alice to Carol, that PIDF-LO privacy rules implicitly=20 > allow Alice to tell Carol where Bob is. This came up in another=20 > forum, and is a current byproduct of the policy rules within the=20 > PIDF-LO and this document cannot overcome those. >=20 > A benefit to this policy is that if Alice calls for emergency help,=20 > and somehow is routed to the wrong PSAP (emergency call center),=20 > PSAP-1 can transfer Alice's location to PSAP-2 (i.e., the correct=20 > PSAP serving Alice's area). Therefore, this PIDF-LO policy is not=20 > necessarily a hole. BTW - the default value of=20 > has always been to "no". >=20 > - I removed the term sighter from the doc (a legacy term within=20 > Geopriv), and replaced it with locator. >=20 > Comments are welcome >=20 > James >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From jmpolk@cisco.com Thu Jul 2 10:17:02 2009 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 3C7BF3A6B06 for ; Thu, 2 Jul 2009 10:17:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.372, 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 vitYZoNG0KPJ for ; Thu, 2 Jul 2009 10:17:00 -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 8A2A33A69F0 for ; Thu, 2 Jul 2009 10:17:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,336,1243814400"; d="scan'208";a="336413347" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 02 Jul 2009 17:17:23 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n62HHNAL008815; Thu, 2 Jul 2009 10:17:23 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n62HHN3k022073; Thu, 2 Jul 2009 17:17:23 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 10:17:23 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.73.89]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 10:17:22 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 02 Jul 2009 12:17:21 -0500 To: "Elwell, John" , sipcore@ietf.org From: "James M. Polk" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00218BF88@GBNTHT12009MSX.gb 002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D00218BF88@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 02 Jul 2009 17:17:23.0034 (UTC) FILETIME=[F69303A0:01C9FB38] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11100; t=1246555043; x=1247419043; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[sipcore]=20Review=20of=0A=20=20draft-i etf-sipcore-location-conveyance-00=20sections=201=20to=203 |Sender:=20; bh=z3sHn7NQIBwErFgcj/qgEz9vUM1aTu0zy7Lu+SU6JBM=; b=ykAPOwE0HYUcfZAzHxD3v0w3sAoHTVFDSbZrcUzdmV/ZJ2pgo/Edw6Vr0P qw1Sphz++LsLF/YQA6iGq3NMVZb2PdO2R+RS7Jn5Qk4bzBHkmHO/977Qdeqe S5ciPPPVmb; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [sipcore] Review of draft-ietf-sipcore-location-conveyance-00 sections 1 to 3 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, 02 Jul 2009 17:17:02 -0000 At 04:50 AM 7/2/2009, Elwell, John wrote: >I focused on sections 1 to 3, since they have been subject to >substantial changes. I think the changes on the whole are an >improvement, but I still have some minor comments and nits. John -- thanks for the review. >Minor comments: >- "Location Information Server (LIS) - a logical server that stores > geolocation records of Targets, which correspond to LbyR URIs." I agree this term definition is fuzzy, and planned on doing more with it when I rev the doc before the -01 deadline. >Several problems with this definition: >a) What are "geolocation records"? Elsewhere in the document we talk >about just "location" or "location information" - I doubt the need to >introduce yet another term "geolocation record", which does not seem to >be used elsewhere. >b) What exactly "correspond" to LbyR URIs. Targets certainly do not >"correspond" to LbyR URIs. Also I don't think geolocation records >"correspond" to LbyR URIs. Is it trying to say something like "these >records being identified by LbyR URIs"? I'll change the wording. >c) I don't think this definition of the term LIS is in line with usage >within GEOPRIV documents, e.g., lis-discovery or HELD. In HELD, a LIS >provides either a location by value or a reference. A URI provided as a >reference will result in a recipient contacting a server to provide the >location value, but that server is not necessarily a LIS, I believe. I think it is, but will verify. >At >least I don't believe it acts as a LIS in this circumstance, I think this is the exact circumstance in which this acts this way, but could be wrong, and will verify with Mary Barnes (author of HELD). I didn't look to the HELD docs - that have to describe this same thing - for a way of stating/defining all this, and I should have. >even if the >same physical server can also be a LIS. I think where we use the term >LIS in location-conveyance, we should perhaps consider using something >like "dereferencing server" instead. that works for me, but within geopriv-speak, they use the term LIS for this (or I can't tell when this isn't applied in this way). I'll verify. >- "This document describes how Location can be "conveyed" from one SIP > entity unsolicited to another entity using SIP [RFC3261]." >I think it would be worth mentioning that it applies only to SIP >requests: > "This document describes how Location can be "conveyed" in a SIP [RFC >3261] request from one SIP entity unsolicited to another SIP entity." this is a good suggestion - and I'll easily do this. >- Later in the same paragraph: "The phrase "location conveyance" > describes scenarios in which a SIP user agent client (UAC) is > informing a user agent server (UAS) or intermediate SIP server > without being previously asked where the UAC is." >This is more restrictive than the sentence in the preceding comment (in >that conveyance is constrained to start at the UAC, rather than at a >proxy). The sentence does not seem to add any value and can be dropped. it is basically repeating, so I'll drop it. >- "Location Conveyance is different from a UAC, Alice, seeking the > location the UAS, Bob. Location conveyance, using SIP, never asks > for another entity's location be in a response. Asking for someone > else's location is not discussed in this document." >This is redundant, since the sentence two comments back already says >"unsolicited". If we really need to say anything, we can much more >simply say: > "Requesting an entity to convey its location via SIP is outside the >scope of this document." I had a sentence saying this, but took it out. I guess I shouldn't have. >- "This document describes the > extension to SIP for how it complies with the Using Protocol > requirements, " >I think this would be better worded as: > "This document specifies an extension to SIP to allow it to be a Using >Protocol in compliance with the requirements of [RFC 3693]." good suggestion >- "Common terms are in Section 1. Section 3 provides an overview of SIP > location conveyance. Section 4 details the modifications necessary > to accomplish location conveyance. Section 5 gives decode examples > of geolocation within SIP requests, both LbyV and LbyR. Section 6 > articulates the SIP element type behaviors for location conveyance. > Section 7 discusses Geopriv privacy considerations. Section 8 > discusses security considerations. Section 9 IANA registers the > modifications made to SIP by this document from section 4." >This duplicates the table of contents (well, it hardly adds anything) - >delete. many many docs have a paragraph like this, and have a TOC, so I kept it here because of that practice. I can easily drop it - because you're right, if someone had read the TOC, nothing here is new. >- "Section 4 gets into guidance and limitations of this behavior." >Section 4 seems to specify normative behaviour, so I would hardly call >it guidance. I would delete this sentence. If we really need to retain >such a sentence, we should use more precise wording than "gets into". fair >- "It is possible, and it fact, planned in certain > circumstances to have SIP requests routed based on the location of > the target. This means SIP servers can be location recipients. If > this is not desired by a location inserter - the act of including > location into this request, then a separate indication is given in > the Geolocation header it this usage is allowed." >I am not sure what the last sentence means - a "location inserter" is >not an "act of including location into this request". the inserter term does come out of the blue, so I'll clarify this, as it is an important point. >I think what might >be undesirable is not the fact that SIP servers can be location >recipients, but the fact that they might use location information for >routing. you do not like the idea of servers routing a request based on the contained location? can you clarify, please if you do feel this way, then I disagree with you, as this is central to emergency services and other source based routing (i.e., directing the message based on where the UAC is, instead of what the destination address is). >I think the last sentence should be rewritten something like >this. > "The location inserter is able to include a separate indication in the >Geolocation header field to denote whether routing on the basis of the >target's location is permitted." regardless of hte above, this sentence is not wrong, and does make a good point, so I'll look at including it. >If we do this, then the last sentence seems to follow on nicely from the >first sentence, and the second sentence seems to get in the way, so >delete the second sentence. If we really need to retain the second >sentence, at least change "SIP servers" to "SIP proxies" (since a UAS is >also a SIP server). wrt proxies vs. servers -- I tried to account for there being B2BUAs at the same place as proxies would be, to attempt to get them to behave in nearly identical ways based on this spec. >- "There is no mechanism by which the veracity of these parameters can > be verified." >It is not clear what "these parameters" refers to, because the term >"parameter" has not been used in the preceding text. It would be best to >enumerate the particular fields that this refers to. fair comment >- "They are hints to downstream entities on how the > location information in the message was originated, intended and > used." >The words "was ... used" do not make sense - the information has not yet >been used - merely conveyed. I am not sure what is intended here. I'll make this clearer >- " LbyR refers to a UA > including a location URI in a SIP request header field which can be > dereferenced by a Location Recipient to receive Alice's Location > Object, in the form of a PIDF-LO." >The header field is not dereferenced, it is the location URI that is >dereferenced. this is an artifact of the acronym "LbyR" being considered an archiecture by the Geopriv WG for about a year (some still feel it is), where I believe LbyR is just a location URI. This is an attempt to have the Geopriv folks understand that the Location URI, which is the Geolocation header value is used to dereference the Target's location. >I would suggest (also making other parts of the sentence >more generic): > "LbyR refers to a Location Server > including in the header of a SIP request a location URI that can be > dereferenced by a Location Recipient to receive a Location > Object, in the form of a PIDF-LO, representing the Target's >location." interesting suggestion... connecting the UAC as the Target that's really acting as a Location Server. While true, this might confuse SIP specific folks. Then again, maybe not - given that what you state above is accurate. >Nits: > >- In the abstract, "where SIP servers > make routing decisions based on the location of the user agent > clients" >Change "clients" to "client", since a SIP request can have only one UAC. fair >- "directly or indirectly from transmitting SIP > entity" >Change to > "directly or indirectly from a transmitting SIP > entity" good catch >- "In > other works" >Change to > "In > other words" thanks! >- "a new SIP header" >Change to: > "a new SIP header field" >(and likewise for "a new header" later. Also other places in the >document where "header" is used rather than "header field", even though >we are referring to only a part of the SIP header.) fair, in fact, I did this sweep before, but obviously didn't catch all of the replacements. >- "that points to the where the > location is" >Change to: > "that points to where the > location is" thanks >- "either in the SIP request itself " >I think it would be more accurate to say: > "either in the body of the SIP request" fair >- "or on an external server (LbyR)" >It is not clear what "external" is relative to. Change to: > "or on a server (LbyR)" it is meant to emphasize that LbyR is a location URI pointing towards the location record that does not reside on the location target itself (even if the target is an LS), it is on another entity. perhaps I do not need to make this point. >- "Transport Layer Security is expected when a request contains > a target's location. Some implementations will choose to have > S/MIME to encrypt message bodies from source to destination." >Shouldn't we have a paragraph break before this? we could... and I will ;-) Thanks James >John >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From jmpolk@cisco.com Thu Jul 2 10:28:02 2009 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 07DEA3A6B94 for ; Thu, 2 Jul 2009 10:28:02 -0700 (PDT) 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.366, 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 5i95YNsUmR3x for ; Thu, 2 Jul 2009 10:28:00 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 700223A6BA1 for ; Thu, 2 Jul 2009 10:28:00 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,336,1243814400"; d="scan'208";a="208871851" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 02 Jul 2009 17:28:04 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n62HS4ol005596; Thu, 2 Jul 2009 10:28:04 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n62HS43m003749; Thu, 2 Jul 2009 17:28:04 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 10:28:04 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.73.89]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 10:28:03 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 02 Jul 2009 12:28:02 -0500 To: "Elwell, John" , sipcore@ietf.org From: "James M. Polk" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00218BF89@GBNTHT12009MSX.gb 002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D00218BF89@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 02 Jul 2009 17:28:03.0827 (UTC) FILETIME=[74844430:01C9FB3A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=543; t=1246555684; x=1247419684; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[sipcore]=20SIPCORE=20Location=20Convey ance=20-00=20submitted |Sender:=20; bh=FEX/HxAEz8Ol0DP9aW2jLXNgoXrHvPEIRVJCD/Ka/sA=; b=WzVlpF5w8i0CkPfU5dwgashahkZBETMoqUbhNzgwiit0SCGEFcYYqIyVhm HrrhsI79yt7Bz9ah2GyZncZuW4gfnDHgMGULriJZ+rcXFLOYvDT1KA5u3dwe qAq2TaHl+Z; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [sipcore] SIPCORE Location Conveyance -00 submitted 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, 02 Jul 2009 17:28:02 -0000 At 04:50 AM 7/2/2009, Elwell, John wrote: > > - I toned down the 2119 text for servers inserting location into a > > request from SHOULD NOT to not RECOMMENDED, based on WG comment. >[JRE] Why does this constitute a toning down? I though SHOULD NOT and >NOT RECOMMENDED were the same in RFC 2119. Can somebody please explain >the subtle distinction? I thought (think?) (NOT) RECOMMENDED doesn't need to be implemented, and SHOULD (NOT) does, for PS to DS movement. I can change the text to "inadvisable" otherwise >John > From john.elwell@siemens-enterprise.com Thu Jul 2 11:07:19 2009 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 AB0103A6DC3 for ; Thu, 2 Jul 2009 11:07:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 8+BR7pxEqWqO for ; Thu, 2 Jul 2009 11:07:18 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 2AF853A6DB4 for ; Thu, 2 Jul 2009 11:07:18 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KM6008BQ2CROZ@siemenscomms.co.uk> for sipcore@ietf.org; Thu, 02 Jul 2009 19:07:39 +0100 (BST) Date: Thu, 02 Jul 2009 19:07:39 +0100 From: "Elwell, John" In-reply-to: To: "James M. Polk" , sipcore@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00218C331@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] Review of draft-ietf-sipcore-location-conveyance-00 sections 1 to 3 Thread-Index: Acn7OPkzw37WgkI/T+yFA/Ay04T13wABGvew Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D00218BF88@GBNTHT12009MSX.gb002.siemens.net> Subject: Re: [sipcore] Review of draft-ietf-sipcore-location-conveyance-00 sections 1 to 3 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, 02 Jul 2009 18:07:19 -0000 James, Thanks for attending to my comments. Just some remarks on the ones you queried. > >- "It is possible, and it fact, planned in certain > > circumstances to have SIP requests routed based on the=20 > location of > > the target. This means SIP servers can be location recipients. If > > this is not desired by a location inserter - the act of including > > location into this request, then a separate indication=20 > is given in > > the Geolocation header it this usage is allowed." > >I am not sure what the last sentence means - a "location inserter" is > >not an "act of including location into this request". >=20 > the inserter term does come out of the blue, so I'll clarify this, as=20 > it is an important point. [JRE] Sorry, perhaps my comment was not clear, but the way the sentence is constructed suggests that "a location server" is "the act of including...". I don't have a problem with the term "inserter", but with the words that follow and the general sentence construction. >=20 > >I think what might > >be undesirable is not the fact that SIP servers can be location > >recipients, but the fact that they might use location information for > >routing. >=20 > you do not like the idea of servers routing a request based on the=20 > contained location? [JRE] My comment is misunderstood. I am talking about what the inserter does not desire. I believe the text is trying to cover the case where the location inserter does not desire that location be used for routing. >=20 > can you clarify, please [JRE] I hope my explanations above are clear. >=20 > if you do feel this way, then I disagree with you, as this is central=20 > to emergency services and other source based routing (i.e., directing=20 > the message based on where the UAC is, instead of what the=20 > destination address is). >=20 > >I think the last sentence should be rewritten something like > >this. > > "The location inserter is able to include a separate=20 > indication in the > >Geolocation header field to denote whether routing on the=20 > basis of the > >target's location is permitted." >=20 > regardless of hte above, this sentence is not wrong, and does make a=20 > good point, so I'll look at including it. >=20 >=20 > >If we do this, then the last sentence seems to follow on=20 > nicely from the > >first sentence, and the second sentence seems to get in the way, so > >delete the second sentence. If we really need to retain the second > >sentence, at least change "SIP servers" to "SIP proxies"=20 > (since a UAS is > >also a SIP server). >=20 > wrt proxies vs. servers -- I tried to account for there being B2BUAs=20 > at the same place as proxies would be, to attempt to get them to=20 > behave in nearly identical ways based on this spec. [JRE] SIP RFCs have traditionally not specified B2BUA behaviour (whether or not that is good, I don't wish to debate here). Also, if you do want to include B2BUAs, you would need to make it more clear, e.g., define server as meaning proxy or B2BUA (maybe redirect too, I guess). On the other hand, a UAS, although it is a server, cannot route, so maybe my point is moot. > >- " LbyR refers to a UA > > including a location URI in a SIP request header field=20 > which can be > > dereferenced by a Location Recipient to receive Alice's Location > > Object, in the form of a PIDF-LO." > >The header field is not dereferenced, it is the location URI that is > >dereferenced. >=20 > this is an artifact of the acronym "LbyR" being considered an=20 > archiecture by the Geopriv WG for about a year (some still feel it=20 > is), where I believe LbyR is just a location URI. This is an attempt=20 > to have the Geopriv folks understand that the Location URI, which is=20 > the Geolocation header value is used to dereference the=20 > Target's location. [JRE] I agree, but my original complaint still holds, i.e., it is the URI that is dereferenced, not the header field. The header field contains more than just the URI. >=20 > >I would suggest (also making other parts of the sentence > >more generic): > > "LbyR refers to a Location Server > > including in the header of a SIP request a location URI=20 > that can be > > dereferenced by a Location Recipient to receive a Location > > Object, in the form of a PIDF-LO, representing the Target's > >location." >=20 > interesting suggestion... connecting the UAC as the Target that's=20 > really acting as a Location Server. While true, this might confuse=20 > SIP specific folks. Then again, maybe not - given that what you=20 > state above is accurate. [JRE] The point I was trying to make is that we also allow a proxy to be a Location Server, i.e., to insert the location. Location Server is therefore more accurate than UA. > >- "or on an external server (LbyR)" > >It is not clear what "external" is relative to. Change to: > > "or on a server (LbyR)" >=20 > it is meant to emphasize that LbyR is a location URI pointing towards=20 > the location record that does not reside on the location target=20 > itself (even if the target is an LS), it is on another entity.=20 > perhaps I do not need to make this point. [JRE] It is not clear to me, so I would indeed prefer to remove "external". John From john.elwell@siemens-enterprise.com Thu Jul 2 11:10:42 2009 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 812BC3A6DC1 for ; Thu, 2 Jul 2009 11:10:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 l1+++Y0WZz9U for ; Thu, 2 Jul 2009 11:10:41 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 04D4528C0E0 for ; Thu, 2 Jul 2009 11:10:41 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KM60094L2IF9J@siemenscomms.co.uk> for sipcore@ietf.org; Thu, 02 Jul 2009 19:11:03 +0100 (BST) Date: Thu, 02 Jul 2009 19:11:03 +0100 From: "Elwell, John" In-reply-to: To: "James M. Polk" , sipcore@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00218C334@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] SIPCORE Location Conveyance -00 submitted Thread-Index: Acn7OncpPDgdPzwtTfi8wTc31SN8GQABbMjg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D00218BF89@GBNTHT12009MSX.gb002.siemens.net> Subject: Re: [sipcore] SIPCORE Location Conveyance -00 submitted 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, 02 Jul 2009 18:10:42 -0000 =20 > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com]=20 > Sent: 02 July 2009 18:28 > To: Elwell, John; sipcore@ietf.org > Subject: RE: [sipcore] SIPCORE Location Conveyance -00 submitted >=20 > At 04:50 AM 7/2/2009, Elwell, John wrote: > > > - I toned down the 2119 text for servers inserting location into a > > > request from SHOULD NOT to not RECOMMENDED, based on WG comment. > >[JRE] Why does this constitute a toning down? I though SHOULD NOT and > >NOT RECOMMENDED were the same in RFC 2119. Can somebody=20 > please explain > >the subtle distinction? >=20 > I thought (think?) (NOT) RECOMMENDED doesn't need to be implemented,=20 > and SHOULD (NOT) does, for PS to DS movement. [JRE] RFC 2119 states: "4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full implications should be understood and the case carefully weighed before implementing any behavior described with this label." Therefore they mean the same thing. >=20 > I can change the text to "inadvisable" otherwise [JRE] If you want to tone it down, you would indeed need to use non-normative text. But it depends what the WG wants - I don't have an opinion. John >=20 >=20 > >John > > >=20 >=20 From dworley@nortel.com Thu Jul 2 11:17:15 2009 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 B590028C269 for ; Thu, 2 Jul 2009 11:17:15 -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=[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 W18qieG7v2aN for ; Thu, 2 Jul 2009 11:17:14 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 222053A6B61 for ; Thu, 2 Jul 2009 11:17:14 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n62HmBZ00377 for ; Thu, 2 Jul 2009 17:48:11 GMT Received: from [47.141.31.172] ([47.141.31.172]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 13:49:42 -0400 From: "Dale Worley" To: SIPCORE Content-Type: text/plain Organization: Nortel Networks Date: Thu, 02 Jul 2009 13:49:41 -0400 Message-Id: <1246556981.10099.65.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2009 17:49:42.0531 (UTC) FILETIME=[7A9AC530:01C9FB3D] 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, 02 Jul 2009 18:17:15 -0000 Regarding the BNF for the History-Info header (section 4.1 in the draft version of -02): The current BNF requires that the "index" parameter appear immediately after the URI, whereas other parameters appear after it: History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) hi-entry = hi-targeted-to-uri SEMI hi-index *(SEMI hi-param) hi-targeted-to-uri = name-addr hi-index = "index" EQUAL 1*DIGIT *("." 1*DIGIT) hi-param = hi-target/hi-aor/hi-extension hi-target = "rc" / "cc" / "mp" / "rt" hi-aor = "aor" hi-extension = generic-param IMHO, this is not a good way to organize the grammar, as it makes it difficult to generate hi-entry's with generic code (there needs to be some way to constrain the "index" parameter to be first), and violates the general rule that the order of parameters is not significant. I propose to adjust the BNF to: History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) hi-entry = hi-targeted-to-uri *(SEMI hi-param) hi-targeted-to-uri = name-addr hi-param = hi-index / hi-target / hi-aor / hi-extension hi-index = "index" EQUAL 1*DIGIT *("." 1*DIGIT) hi-target = "rc" / "cc" / "mp" / "rt" hi-aor = "aor" hi-extension = generic-param Of course, the "index" parameter is still mandatory per the semantic constraints listed earlier in section 4.1. I've also inserted into the hi-index BNF some spaces around the instances of "/" for better readability. Dale From pkyzivat@cisco.com Thu Jul 2 11:39:28 2009 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 A817028B23E for ; Thu, 2 Jul 2009 11:39:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.556 X-Spam-Level: X-Spam-Status: No, score=-6.556 tagged_above=-999 required=5 tests=[AWL=0.043, 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 PvWvhjf4Cicy for ; Thu, 2 Jul 2009 11:39:27 -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 52D1E3A6A36 for ; Thu, 2 Jul 2009 11:39:27 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,336,1243814400"; d="scan'208";a="49226982" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 02 Jul 2009 18:39:47 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n62Idlpk030605; Thu, 2 Jul 2009 14:39:47 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n62IdlFE002521; Thu, 2 Jul 2009 18:39:47 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 14:39:47 -0400 Received: from [161.44.182.248] ([161.44.182.248]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 14:39:46 -0400 Message-ID: <4A4CFEF1.1000006@cisco.com> Date: Thu, 02 Jul 2009 14:39:45 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Dale Worley References: <1246556981.10099.65.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1246556981.10099.65.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2009 18:39:46.0592 (UTC) FILETIME=[792A1A00:01C9FB44] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2743; t=1246559987; x=1247423987; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20draft-barnes-sipcore-rfc424 4bis |Sender:=20 |To:=20Dale=20Worley=20; bh=2dxrXS9+GX0BoBZXVNypSwARoZOOfS831URmU4OnqsQ=; b=yRn1TQ0LjgF6SDYB83MDb+YbibOcP9fOOgFMCBkrScBowmtqjiZps6yQfL uuzLb1lOE8TwwUn7XF5s96YF3TSAjMs/1kTq822lsT1xmgnLGfNr8PYu9X3/ hcpa7gTG9G; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIPCORE 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, 02 Jul 2009 18:39:28 -0000 Dale, I agree with your concern about the BNF. A requirement about the ordering of the params is problematic. OTOH, this is a revision to an existing RFC which had that ordering requirement. Its possible that relaxing it might lead to interop problems. Perhaps the best one can do is put in a recommendation to make the index first. Regarding indicating that the index is required: it can be done in text, but it can also be done in the BNF, as follows: History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) hi-entry = hi-targeted-to-uri hi-param-list hi-targeted-to-uri = name-addr hi-param-list = *(SEMI hi-option) SEMI hi-index *(hi-option) hi-option = hi-target / hi-aor / hi-extension hi-index = "index" EQUAL 1*DIGIT *("." 1*DIGIT) hi-target = "rc" / "cc" / "mp" / "rt" hi-aor = "aor" hi-extension = generic-param Thanks, Paul Dale Worley wrote: > Regarding the BNF for the History-Info header (section 4.1 in the draft > version of -02): > > The current BNF requires that the "index" parameter appear immediately > after the URI, whereas other parameters appear after it: > > History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) > > hi-entry = hi-targeted-to-uri SEMI hi-index *(SEMI hi-param) > > hi-targeted-to-uri = name-addr > > hi-index = "index" EQUAL 1*DIGIT *("." 1*DIGIT) > > hi-param = hi-target/hi-aor/hi-extension > > hi-target = "rc" / "cc" / "mp" / "rt" > > hi-aor = "aor" > > hi-extension = generic-param > > IMHO, this is not a good way to organize the grammar, as it makes it > difficult to generate hi-entry's with generic code (there needs to be > some way to constrain the "index" parameter to be first), and violates > the general rule that the order of parameters is not significant. > > I propose to adjust the BNF to: > > History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) > > hi-entry = hi-targeted-to-uri *(SEMI hi-param) > > hi-targeted-to-uri = name-addr > > hi-param = hi-index / hi-target / hi-aor / hi-extension > > hi-index = "index" EQUAL 1*DIGIT *("." 1*DIGIT) > > hi-target = "rc" / "cc" / "mp" / "rt" > > hi-aor = "aor" > > hi-extension = generic-param > > Of course, the "index" parameter is still mandatory per the semantic > constraints listed earlier in section 4.1. > > I've also inserted into the hi-index BNF some spaces around the > instances of "/" for better readability. > > Dale > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From jmpolk@cisco.com Thu Jul 2 13:07:48 2009 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 8F2BA28C146 for ; Thu, 2 Jul 2009 13:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.24 X-Spam-Level: X-Spam-Status: No, score=-6.24 tagged_above=-999 required=5 tests=[AWL=0.359, 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 mTaLFv2ALy3L for ; Thu, 2 Jul 2009 13:07:47 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 55AED28C23D for ; Thu, 2 Jul 2009 13:07:47 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,337,1243814400"; d="scan'208";a="38824526" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-4.cisco.com with ESMTP; 02 Jul 2009 20:08:10 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n62K8AX5002798; Thu, 2 Jul 2009 13:08:10 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n62K8A8x018203; Thu, 2 Jul 2009 20:08:10 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 13:08:10 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.149.205]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 13:08:09 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 02 Jul 2009 15:08:08 -0500 To: "Elwell, John" , sipcore@ietf.org From: "James M. Polk" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00218C331@GBNTHT12009MSX.gb 002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D00218BF88@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00218C331@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 02 Jul 2009 20:08:09.0391 (UTC) FILETIME=[D1E103F0:01C9FB50] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6443; t=1246565290; x=1247429290; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[sipcore]=20Review=20of=20=0A=20=20draf t-ietf-sipcore-location-conveyance-00=20sections=201=20to=20 3 |Sender:=20; bh=1oYnZfcg/XiRLBRLuvrRP1CuzVA7KBNabGVMxBoUjSg=; b=vKZZX8sf+a9pPrA79Sl+lkcGjVv5738ZtTe3nUgcZtXLoLiP9S6nnr8zuu 1xlolLOKfYtmMdJDZTvNcEl7vJgcZjcJqdNQcyjqfeyC0RNSA3VOHojAHGzt xcMyRnpq2p; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [sipcore] Review of draft-ietf-sipcore-location-conveyance-00 sections 1 to 3 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, 02 Jul 2009 20:07:48 -0000 At 01:07 PM 7/2/2009, Elwell, John wrote: >James, > >Thanks for attending to my comments. Just some remarks on the ones you >queried. > > > >- "It is possible, and it fact, planned in certain > > > circumstances to have SIP requests routed based on the > > location of > > > the target. This means SIP servers can be location recipients. If > > > this is not desired by a location inserter - the act of including > > > location into this request, then a separate indication > > is given in > > > the Geolocation header it this usage is allowed." > > >I am not sure what the last sentence means - a "location inserter" is > > >not an "act of including location into this request". > > > > the inserter term does come out of the blue, so I'll clarify this, as > > it is an important point. >[JRE] Sorry, perhaps my comment was not clear, but the way the sentence >is constructed suggests that "a location server" is "the act of >including...". I don't have a problem with the term "inserter", but with >the words that follow and the general sentence construction. that makes more sense now, thanks > > > > >I think what might > > >be undesirable is not the fact that SIP servers can be location > > >recipients, but the fact that they might use location information for > > >routing. > > > > you do not like the idea of servers routing a request based on the > > contained location? >[JRE] My comment is misunderstood. I am talking about what the inserter >does not desire. I believe the text is trying to cover the case where >the location inserter does not desire that location be used for routing. thanks again > > > > can you clarify, please >[JRE] I hope my explanations above are clear. yep > > > > if you do feel this way, then I disagree with you, as this is central > > to emergency services and other source based routing (i.e., directing > > the message based on where the UAC is, instead of what the > > destination address is). > > > > >I think the last sentence should be rewritten something like > > >this. > > > "The location inserter is able to include a separate > > indication in the > > >Geolocation header field to denote whether routing on the > > basis of the > > >target's location is permitted." > > > > regardless of hte above, this sentence is not wrong, and does make a > > good point, so I'll look at including it. > > > > > > >If we do this, then the last sentence seems to follow on > > nicely from the > > >first sentence, and the second sentence seems to get in the way, so > > >delete the second sentence. If we really need to retain the second > > >sentence, at least change "SIP servers" to "SIP proxies" > > (since a UAS is > > >also a SIP server). > > > > wrt proxies vs. servers -- I tried to account for there being B2BUAs > > at the same place as proxies would be, to attempt to get them to > > behave in nearly identical ways based on this spec. >[JRE] SIP RFCs have traditionally not specified B2BUA behaviour (whether >or not that is good, I don't wish to debate here). Also, if you do want >to include B2BUAs, you would need to make it more clear, e.g., define >server as meaning proxy or B2BUA (maybe redirect too, I guess). On the >other hand, a UAS, although it is a server, cannot route, so maybe my >point is moot. yeah - I know this is a tough one, and someone else said making this small change to "server" does give one more leverage to mean more than proxy if the discussion goes that way (anywhere). theoretically, we cannot really do anything about b2buas, but this is a - perhaps vein - attempt to include them in the discussion to keep them behaving, while not getting into the argument of calling them out and having to explain that (which would be an endless argument from someone who wants to dig in their heels). > > >- " LbyR refers to a UA > > > including a location URI in a SIP request header field > > which can be > > > dereferenced by a Location Recipient to receive Alice's Location > > > Object, in the form of a PIDF-LO." > > >The header field is not dereferenced, it is the location URI that is > > >dereferenced. > > > > this is an artifact of the acronym "LbyR" being considered an > > archiecture by the Geopriv WG for about a year (some still feel it > > is), where I believe LbyR is just a location URI. This is an attempt > > to have the Geopriv folks understand that the Location URI, which is > > the Geolocation header value is used to dereference the > > Target's location. >[JRE] I agree, but my original complaint still holds, i.e., it is the >URI that is dereferenced, not the header field. I agree, and will make it clear by saying it's the header value that is used to make the dereference >The header field >contains more than just the URI. > > > > > >I would suggest (also making other parts of the sentence > > >more generic): > > > "LbyR refers to a Location Server > > > including in the header of a SIP request a location URI > > that can be > > > dereferenced by a Location Recipient to receive a Location > > > Object, in the form of a PIDF-LO, representing the Target's > > >location." > > > > interesting suggestion... connecting the UAC as the Target that's > > really acting as a Location Server. While true, this might confuse > > SIP specific folks. Then again, maybe not - given that what you > > state above is accurate. >[JRE] The point I was trying to make is that we also allow a proxy to be >a Location Server, i.e., to insert the location. Location Server is >therefore more accurate than UA. you're right, and I was clarifying that the target - if that's the UAC that created the PIDF-LO and inserted it in the SIP request - is also a Location Server. I'll make this clear on all accounts. > > >- "or on an external server (LbyR)" > > >It is not clear what "external" is relative to. Change to: > > > "or on a server (LbyR)" > > > > it is meant to emphasize that LbyR is a location URI pointing towards > > the location record that does not reside on the location target > > itself (even if the target is an LS), it is on another entity. > > perhaps I do not need to make this point. >[JRE] It is not clear to me, so I would indeed prefer to remove >"external". ok, I will. Thanks again! James >John From jmpolk@cisco.com Thu Jul 2 13:17:47 2009 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 BE64628C146 for ; Thu, 2 Jul 2009 13:17:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.246 X-Spam-Level: X-Spam-Status: No, score=-6.246 tagged_above=-999 required=5 tests=[AWL=0.353, 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 nfjpYbMWkqEc for ; Thu, 2 Jul 2009 13:17:46 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B5D0228C0DF for ; Thu, 2 Jul 2009 13:17:46 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,337,1243814400"; d="scan'208";a="208923612" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 02 Jul 2009 20:18:06 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n62KI6Yn025858; Thu, 2 Jul 2009 13:18:06 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n62KI6Fw025644; Thu, 2 Jul 2009 20:18:06 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 13:18:05 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.149.205]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 13:18:05 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 02 Jul 2009 15:18:04 -0500 To: "Elwell, John" , sipcore@ietf.org From: "James M. Polk" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00218C334@GBNTHT12009MSX.gb 002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D00218BF89@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00218C334@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 02 Jul 2009 20:18:05.0735 (UTC) FILETIME=[3553E370:01C9FB52] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2047; t=1246565886; x=1247429886; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[sipcore]=20SIPCORE=20Location=20Convey ance=20-00=20submitted |Sender:=20; bh=Mutw7+iphVuJOWspDdOPIjhGcG8vC0H/MDnHyElikjo=; b=px6DVKOHxOQh7OBaVyM3GFVkKqYnV7f6cQNBRPoZnHKfsn3+7KqDG3XHur t43zgeMPUN+nmyRvQOshKI/jAaWoYWBlIV4tx3DoI/dXGzVfOH5EcspF1rMq 2tfOLQJe7s; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Subject: Re: [sipcore] SIPCORE Location Conveyance -00 submitted 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, 02 Jul 2009 20:17:47 -0000 At 01:11 PM 7/2/2009, Elwell, John wrote: > > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: 02 July 2009 18:28 > > To: Elwell, John; sipcore@ietf.org > > Subject: RE: [sipcore] SIPCORE Location Conveyance -00 submitted > > > > At 04:50 AM 7/2/2009, Elwell, John wrote: > > > > - I toned down the 2119 text for servers inserting location into a > > > > request from SHOULD NOT to not RECOMMENDED, based on WG comment. > > >[JRE] Why does this constitute a toning down? I though SHOULD NOT and > > >NOT RECOMMENDED were the same in RFC 2119. Can somebody > > please explain > > >the subtle distinction? > > > > I thought (think?) (NOT) RECOMMENDED doesn't need to be implemented, > > and SHOULD (NOT) does, for PS to DS movement. >[JRE] RFC 2119 states: >"4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that > there may exist valid reasons in particular circumstances when the > particular behavior is acceptable or even useful, but the full > implications should be understood and the case carefully weighed > before implementing any behavior described with this label." > >Therefore they mean the same thing. I obviously have to re-read 2119 again... ... (especially bad for a WG chair not to remember this) > > > > I can change the text to "inadvisable" otherwise >[JRE] If you want to tone it down, you would indeed need to use >non-normative text. But it depends what the WG wants - I don't have an >opinion. This is text that has been in the ID for a number of years now, perhaps 6-8 wg reversions - if not since the the concept of servers inserting location was introduced with LbyRs, without changing meaning. So I don't want to change the normative meaning too much - and definitely not from normative to informative. I was responding to one opinion that wanted the whole text removed, by trying to soften it. I obviously blew that... James >John > > > > > > > >John > > > > > > > From Martin.Thomson@andrew.com Thu Jul 2 16:29:12 2009 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 A6DFB3A67FB for ; Thu, 2 Jul 2009 16:29:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 c3uL2KwF4jKo for ; Thu, 2 Jul 2009 16:29:11 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 41F4F3A6B59 for ; Thu, 2 Jul 2009 16:28:49 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_02_18_51_14 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 02 Jul 2009 18:51:14 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 18:29:12 -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: Thu, 2 Jul 2009 18:28:29 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Review of draft-ietf-sipcore-location-conveyance-00 sections 1 to 3 Thread-Index: Acn7OPnhU/eRfWG7RYKoPPPbmTIwgQAMQDKA References: <0D5F89FAC29E2C41B98A6A762007F5D00218BF88@GBNTHT12009MSX.gb002.siemens.net> From: "Thomson, Martin" To: "James M. Polk" , "Elwell, John" , X-OriginalArrivalTime: 02 Jul 2009 23:29:12.0384 (UTC) FILETIME=[E7FBAC00:01C9FB6C] Subject: Re: [sipcore] Review of draft-ietf-sipcore-location-conveyance-00 sections 1 to 3 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, 02 Jul 2009 23:29:12 -0000 SGkgSmFtZXMsDQoNCkpvaG4gaXMgY29ycmVjdCBhYm91dCB1c2Ugb2YgTElTIGFuZCBMUy4gIEEg TElTIGlzIGEgc3BlY2lhbGl6ZWQgdGVybSB0aGF0IGlzIHVzZWQgb25seSBpbiB0aGUgbG9jYXRp b24gY29uZmlndXJhdGlvbiBwcm90b2NvbCAoTENQKSBjb250ZXh0IG9ubHkuDQoNCldoZW4gYSBs b2NhdGlvbiByZWNpcGllbnQgKExSKSByZXRyaWV2ZXMgbG9jYXRpb24gaW5mb3JtYXRpb24gKExJ KSBmcm9tIGEgbG9jYXRpb24gVVJJIHRoZSBlbnRpdHkgdGhhdCBpdCBjb250YWN0cyBpcyAob3Ig YWN0cyBhcykgYSBsb2NhdGlvbiBzZXJ2ZXIgKExTKS4NCg0KSWYgeW91IGxvb2sgYXQgdGhlIGxh dGVzdCB2ZXJzaW9uIG9mIFJpY2hhcmQncyBhcmNoaXRlY3R1cmUgZHJhZnQgb3IgdGhlIEhFTEQg ZGVmZXJlbmNlIGRyYWZ0LCB0aGUgYmFzaWMgaWRlYSBpcyB0aGF0IExTIGlzIGEgcm9sZSBhc3N1 bWVkIGJ5IGFuIGVudGl0eSB0aGF0IHByb3ZpZGVzIExJIHRvIGFuIExSLg0KDQpJIGhhdmUgYSBm ZXcgbWlub3IgdGhpbmdzIGJlbG93Lg0KDQo+ID5jKSBJIGRvbid0IHRoaW5rIHRoaXMgZGVmaW5p dGlvbiBvZiB0aGUgdGVybSBMSVMgaXMgaW4gbGluZSB3aXRoIHVzYWdlDQo+ID53aXRoaW4gR0VP UFJJViBkb2N1bWVudHMsIGUuZy4sIGxpcy1kaXNjb3Zlcnkgb3IgSEVMRC4gSW4gSEVMRCwgYSBM SVMNCj4gPnByb3ZpZGVzIGVpdGhlciBhIGxvY2F0aW9uIGJ5IHZhbHVlIG9yIGEgcmVmZXJlbmNl LiBBIFVSSSBwcm92aWRlZCBhcw0KPiBhDQo+ID5yZWZlcmVuY2Ugd2lsbCByZXN1bHQgaW4gYSBy ZWNpcGllbnQgY29udGFjdGluZyBhIHNlcnZlciB0byBwcm92aWRlDQo+IHRoZQ0KPiA+bG9jYXRp b24gdmFsdWUsIGJ1dCB0aGF0IHNlcnZlciBpcyBub3QgbmVjZXNzYXJpbHkgYSBMSVMsIEkgYmVs aWV2ZS4NCj4gDQo+IEkgdGhpbmsgaXQgaXMsIGJ1dCB3aWxsIHZlcmlmeS4NCj4gDQo+ID5BdA0K PiA+bGVhc3QgSSBkb24ndCBiZWxpZXZlIGl0IGFjdHMgYXMgYSBMSVMgaW4gdGhpcyBjaXJjdW1z dGFuY2UsDQo+IA0KPiBJIHRoaW5rIHRoaXMgaXMgdGhlIGV4YWN0IGNpcmN1bXN0YW5jZSBpbiB3 aGljaCB0aGlzIGFjdHMgdGhpcyB3YXksDQo+IGJ1dCBjb3VsZCBiZSB3cm9uZywgYW5kIHdpbGwg dmVyaWZ5IHdpdGggTWFyeSBCYXJuZXMgKGF1dGhvciBvZg0KPiBIRUxEKS4gSSBkaWRuJ3QgbG9v ayB0byB0aGUgSEVMRCBkb2NzIC0gdGhhdCBoYXZlIHRvIGRlc2NyaWJlIHRoaXMNCj4gc2FtZSB0 aGluZyAtIGZvciBhIHdheSBvZiBzdGF0aW5nL2RlZmluaW5nIGFsbCB0aGlzLCBhbmQgSSBzaG91 bGQgaGF2ZS4NCj4gDQo+ID5ldmVuIGlmIHRoZQ0KPiA+c2FtZSBwaHlzaWNhbCBzZXJ2ZXIgY2Fu IGFsc28gYmUgYSBMSVMuIEkgdGhpbmsgd2hlcmUgd2UgdXNlIHRoZSB0ZXJtDQo+ID5MSVMgaW4g bG9jYXRpb24tY29udmV5YW5jZSwgd2Ugc2hvdWxkIHBlcmhhcHMgY29uc2lkZXIgdXNpbmcgc29t ZXRoaW5nDQo+ID5saWtlICJkZXJlZmVyZW5jaW5nIHNlcnZlciIgaW5zdGVhZC4NCj4gDQo+IHRo YXQgd29ya3MgZm9yIG1lLCBidXQgd2l0aGluIGdlb3ByaXYtc3BlYWssIHRoZXkgdXNlIHRoZSB0 ZXJtIExJUw0KPiBmb3IgdGhpcyAob3IgSSBjYW4ndCB0ZWxsIHdoZW4gdGhpcyBpc24ndCBhcHBs aWVkIGluIHRoaXMgd2F5KS4gSSdsbA0KPiB2ZXJpZnkuDQo+IA0KLi4uIA0KPiANCj4gPi0gIiBM YnlSIHJlZmVycyB0byBhIFVBDQo+ID4gICAgaW5jbHVkaW5nIGEgbG9jYXRpb24gVVJJIGluIGEg U0lQIHJlcXVlc3QgaGVhZGVyIGZpZWxkIHdoaWNoIGNhbg0KPiBiZQ0KPiA+ICAgIGRlcmVmZXJl bmNlZCBieSBhIExvY2F0aW9uIFJlY2lwaWVudCB0byByZWNlaXZlIEFsaWNlJ3MgTG9jYXRpb24N Cj4gPiAgICBPYmplY3QsIGluIHRoZSBmb3JtIG9mIGEgUElERi1MTy4iDQo+ID5UaGUgaGVhZGVy IGZpZWxkIGlzIG5vdCBkZXJlZmVyZW5jZWQsIGl0IGlzIHRoZSBsb2NhdGlvbiBVUkkgdGhhdCBp cw0KPiA+ZGVyZWZlcmVuY2VkLg0KPiANCj4gdGhpcyBpcyBhbiBhcnRpZmFjdCBvZiB0aGUgYWNy b255bSAiTGJ5UiIgYmVpbmcgY29uc2lkZXJlZCBhbg0KPiBhcmNoaWVjdHVyZSBieSB0aGUgR2Vv cHJpdiBXRyBmb3IgYWJvdXQgYSB5ZWFyIChzb21lIHN0aWxsIGZlZWwgaXQNCj4gaXMpLCB3aGVy ZSBJIGJlbGlldmUgTGJ5UiBpcyBqdXN0IGEgbG9jYXRpb24gVVJJLiAgVGhpcyBpcyBhbiBhdHRl bXB0DQo+IHRvIGhhdmUgdGhlIEdlb3ByaXYgZm9sa3MgdW5kZXJzdGFuZCB0aGF0IHRoZSBMb2Nh dGlvbiBVUkksIHdoaWNoIGlzDQo+IHRoZSBHZW9sb2NhdGlvbiBoZWFkZXIgdmFsdWUgaXMgdXNl ZCB0byBkZXJlZmVyZW5jZSB0aGUgVGFyZ2V0J3MNCj4gbG9jYXRpb24uDQoNCiJMb2NhdGlvbiBi eSByZWZlcmVuY2UiIHJlZmVycyB0byB0aGUgcHJvY2VzcyBvZiBjb252ZXlhbmNlIHdoZXJlIGEg bG9jYXRpb24gVVJJIGlzIHVzZWQgaW5zdGVhZCBvZiBhIGxvY2F0aW9uIG9iamVjdC4gIFlvdSBj YW4ndCBzYXkgIkxieVIgPT0gbG9jYXRpb24gVVJJIi4NCg0KVGhlIGZhY3QgdGhhdCB0aGlzIHBy b2Nlc3MgaXMgbm90IGVzcGVjaWFsbHkgY29tcGxleCwgb3IgZXZlbiBzcGVjaWFsIGZyb20geW91 ciBwZXJzcGVjdGl2ZSwgZG9lc24ndCBtZWFuIHRoYXQgd2UgZG9uJ3QgbmVlZCB1bmFtYmlndW91 cyBsYWJlbHMuICBUaGVyZSBhcmUgdmVyeSBnb29kIHJlYXNvbnMgZm9yIGNvaW5pbmcgdGhlIG5v bWVuY2xhdHVyZS4gIE1pc3VzaW5nIGl0IGRvZXNuJ3QgaGVscDsgaXQgb25seSBmb21lbnRzIGNv bmZ1c2lvbi4NCg0KPiA+SSB3b3VsZCBzdWdnZXN0IChhbHNvIG1ha2luZyBvdGhlciBwYXJ0cyBv ZiB0aGUgc2VudGVuY2UNCj4gPm1vcmUgZ2VuZXJpYyk6DQo+ID4gICAgIkxieVIgcmVmZXJzIHRv IGEgTG9jYXRpb24gU2VydmVyDQo+ID4gICAgaW5jbHVkaW5nIGluIHRoZSBoZWFkZXIgb2YgYSBT SVAgcmVxdWVzdCBhIGxvY2F0aW9uIFVSSSB0aGF0IGNhbg0KPiBiZQ0KPiA+ICAgIGRlcmVmZXJl bmNlZCBieSBhIExvY2F0aW9uIFJlY2lwaWVudCB0byByZWNlaXZlIGEgTG9jYXRpb24NCj4gPiAg ICBPYmplY3QsIGluIHRoZSBmb3JtIG9mIGEgUElERi1MTywgcmVwcmVzZW50aW5nIHRoZSBUYXJn ZXQncw0KPiA+bG9jYXRpb24uIg0KPiANCj4gaW50ZXJlc3Rpbmcgc3VnZ2VzdGlvbi4uLiBjb25u ZWN0aW5nIHRoZSBVQUMgYXMgdGhlIFRhcmdldCB0aGF0J3MNCj4gcmVhbGx5IGFjdGluZyBhcyBh IExvY2F0aW9uIFNlcnZlci4gV2hpbGUgdHJ1ZSwgdGhpcyBtaWdodCBjb25mdXNlDQo+IFNJUCBz cGVjaWZpYyBmb2xrcy4gIFRoZW4gYWdhaW4sIG1heWJlIG5vdCAtIGdpdmVuIHRoYXQgd2hhdCB5 b3UNCj4gc3RhdGUgYWJvdmUgaXMgYWNjdXJhdGUuDQoNCkkgbGlrZSBKb2huJ3Mgd29yZGluZywg YnV0IHRlbmQgdG8gYWdyZWUgLSB0aGUgZmFjdCB0aGF0IHRoZSBVQUMgYmVjb21lcyBhbiBsb2Nh dGlvbiBzZXJ2ZXIgbWlnaHQgYmUgbG9zdCBvbiBzb21lIHJlYWRlcnMuDQoNClRoZW4gYWdhaW4s IHRoZSBUYXJnZXQtVUFDIGNvbm5lY3Rpb24gc3RpbGwgaXNuJ3QgbWFkZS4gIEFyZSB3ZSBhc3N1 bWluZyB0aGlzIHN0aWxsPw0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBt YXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRl IGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5hbC4g IEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJdDQo= From jmpolk@cisco.com Thu Jul 2 21:00:11 2009 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 99F983A68A7 for ; Thu, 2 Jul 2009 21:00:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.257 X-Spam-Level: X-Spam-Status: No, score=-6.257 tagged_above=-999 required=5 tests=[AWL=0.342, 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 GGXFsAde9OWX for ; Thu, 2 Jul 2009 21:00:10 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 40EDA3A6927 for ; Thu, 2 Jul 2009 21:00:10 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,338,1243814400"; d="scan'208";a="182683428" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 03 Jul 2009 04:00:33 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6340XpI030556; Thu, 2 Jul 2009 21:00:33 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6340XFU007917; Fri, 3 Jul 2009 04:00:33 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 21:00:33 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.89.206]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 21:00:33 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 02 Jul 2009 22:59:38 -0500 To: "Thomson, Martin" , "Elwell, John" , From: "James M. Polk" In-Reply-To: References: <0D5F89FAC29E2C41B98A6A762007F5D00218BF88@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 03 Jul 2009 04:00:33.0084 (UTC) FILETIME=[D00957C0:01C9FB92] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6170; t=1246593633; x=1247457633; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[sipcore]=20Review=20of=0A=20=20draft-i etf-sipcore-location-conveyance-00=20sections=201=20to=203 |Sender:=20; bh=bXMSAsadaqnEiETITtD/kh4uBz4RhDjJaK2y11hCTd8=; b=W7znXsEZzyzOnhziDj/tztVT8rhMU+eCp6N0lA81DitHq1JZwHX03zWZYm 6IPcC+mfSdedSz3/bHSBihYOJnekhwRt1uaeZn8yM/Hk8PrWenlXsyg39qU1 rufzsTH9ze; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [sipcore] Review of draft-ietf-sipcore-location-conveyance-00 sections 1 to 3 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, 03 Jul 2009 04:00:11 -0000 At 06:28 PM 7/2/2009, Thomson, Martin wrote: >Hi James, > >John is correct about use of LIS and LS. A LIS is a specialized >term that is used only in the location configuration protocol (LCP) >context only. I have to admit - I didn't ever get this limitation about a LIS (that it's only for LCPs). FWIW -- I thoroughly disagree with this definition, but may be in the minority. Upon determining that I'm in the minority, I will remove "LIS" from conveyance and replace it with LS and Location Server. >When a location recipient (LR) retrieves location information (LI) >from a location URI the entity that it contacts is (or acts as) a >location server (LS). this is really a geopriv discussion - because to me, only an LCP delivers LI, and SIP is no where near any LCP. SIP is concerned with LOs (either by-value in a SIP request, or attained via a dereference transaction). LOs are PIDF-LOs that can be message bodies in SIP requests. >If you look at the latest version of Richard's architecture draft I've been raising a point about this since he began that ID because I have never agreed to his interpretation of the Geopriv architecture. >or the HELD deference draft, the basic idea is that LS is a role >assumed by an entity that provides LI to an LR. LS is also a role that a SIP proxy takes on when it uses the location in the SIP request (by-value or by-reference) to make routing decisions for that request. Remember, he only changed his arch where LSs were every location aware intermediary along the message path towards the ultimate destination in the -05 version. This concept didn't exist in the -04 version of Loc-sec. >I have a few minor things below. ok > > >c) I don't think this definition of the term LIS is in line with usage > > >within GEOPRIV documents, e.g., lis-discovery or HELD. In HELD, a LIS > > >provides either a location by value or a reference. A URI provided as > > a > > >reference will result in a recipient contacting a server to provide > > the > > >location value, but that server is not necessarily a LIS, I believe. > > > > I think it is, but will verify. > > > > >At > > >least I don't believe it acts as a LIS in this circumstance, > > > > I think this is the exact circumstance in which this acts this way, > > but could be wrong, and will verify with Mary Barnes (author of > > HELD). I didn't look to the HELD docs - that have to describe this > > same thing - for a way of stating/defining all this, and I should have. > > > > >even if the > > >same physical server can also be a LIS. I think where we use the term > > >LIS in location-conveyance, we should perhaps consider using something > > >like "dereferencing server" instead. > > > > that works for me, but within geopriv-speak, they use the term LIS > > for this (or I can't tell when this isn't applied in this way). I'll > > verify. > > >... > > > > >- " LbyR refers to a UA > > > including a location URI in a SIP request header field which can > > be > > > dereferenced by a Location Recipient to receive Alice's Location > > > Object, in the form of a PIDF-LO." > > >The header field is not dereferenced, it is the location URI that is > > >dereferenced. > > > > this is an artifact of the acronym "LbyR" being considered an > > archiecture by the Geopriv WG for about a year (some still feel it > > is), where I believe LbyR is just a location URI. This is an attempt > > to have the Geopriv folks understand that the Location URI, which is > > the Geolocation header value is used to dereference the Target's > > location. > >"Location by reference" refers to the process of conveyance where a >location URI is used instead of a location object. ok >You can't say "LbyR == location URI". grrr! >The fact that this process is not especially complex, or even >special from your perspective, doesn't mean that we don't need >unambiguous labels. There are very good reasons for coining the >nomenclature. Misusing it doesn't help; it only foments confusion. > > > >I would suggest (also making other parts of the sentence > > >more generic): > > > "LbyR refers to a Location Server > > > including in the header of a SIP request a location URI that can > > be > > > dereferenced by a Location Recipient to receive a Location > > > Object, in the form of a PIDF-LO, representing the Target's > > >location." > > > > interesting suggestion... connecting the UAC as the Target that's > > really acting as a Location Server. While true, this might confuse > > SIP specific folks. Then again, maybe not - given that what you > > state above is accurate. > >I like John's wording, but tend to agree - the fact that the UAC >becomes an location server might be lost on some readers. > >Then again, the Target-UAC connection still isn't made. that has been going on in the background, offlist >Are we assuming this still? we can't. signaling is easily decomposed from a presence document. the target is identified as the "entity=" attribute within the element. Check section 5 of conveyance (i.e., my LbyV example) to see. Therefore, the target identifier is found there, even if it is an unlinkable pseudonym to intermediary entities. If it is not understood by the location recipient, then it is ignored because it cannot attach identity to it. I will take your advice (based on reading RFC 4479) and delete - and not mention - the as this is providing too much information that might reveal a link to the target's identity. >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] From Martin.Thomson@andrew.com Thu Jul 2 21:22:44 2009 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 8EB373A68B5 for ; Thu, 2 Jul 2009 21:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.559 X-Spam-Level: X-Spam-Status: No, score=-2.559 tagged_above=-999 required=5 tests=[AWL=0.040, 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 0aH4tQMyKN97 for ; Thu, 2 Jul 2009 21:22:43 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 8740B3A6809 for ; Thu, 2 Jul 2009 21:22:43 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_02_23_45_08 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 02 Jul 2009 23:45:08 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 23:23:06 -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: Thu, 2 Jul 2009 23:22:28 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Review of draft-ietf-sipcore-location-conveyance-00 sections 1 to 3 Thread-Index: Acn7ktE2uoKvvNKCSkSzrs/SlSgmsQAAFJog References: <0D5F89FAC29E2C41B98A6A762007F5D00218BF88@GBNTHT12009MSX.gb002.siemens.net> From: "Thomson, Martin" To: "James M. Polk" , "Elwell, John" , X-OriginalArrivalTime: 03 Jul 2009 04:23:06.0401 (UTC) FILETIME=[F6AD2110:01C9FB95] Subject: Re: [sipcore] Review of draft-ietf-sipcore-location-conveyance-00 sections 1 to 3 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, 03 Jul 2009 04:22:44 -0000 SW5saW5lLi4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBKYW1lcyBN LiBQb2xrIFttYWlsdG86am1wb2xrQGNpc2NvLmNvbV0NCj4gU2VudDogRnJpZGF5LCAzIEp1bHkg MjAwOSAyOjAwIFBNDQo+IFRvOiBUaG9tc29uLCBNYXJ0aW47IEVsd2VsbCwgSm9objsgc2lwY29y ZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW3NpcGNvcmVdIFJldmlldyBvZiBkcmFmdC1pZXRm LXNpcGNvcmUtbG9jYXRpb24tDQo+IGNvbnZleWFuY2UtMDAgc2VjdGlvbnMgMSB0byAzDQo+IA0K PiBBdCAwNjoyOCBQTSA3LzIvMjAwOSwgVGhvbXNvbiwgTWFydGluIHdyb3RlOg0KPiA+SGkgSmFt ZXMsDQo+ID4NCj4gPkpvaG4gaXMgY29ycmVjdCBhYm91dCB1c2Ugb2YgTElTIGFuZCBMUy4gIEEg TElTIGlzIGEgc3BlY2lhbGl6ZWQNCj4gPnRlcm0gdGhhdCBpcyB1c2VkIG9ubHkgaW4gdGhlIGxv Y2F0aW9uIGNvbmZpZ3VyYXRpb24gcHJvdG9jb2wgKExDUCkNCj4gPmNvbnRleHQgb25seS4NCj4g DQo+IEkgaGF2ZSB0byBhZG1pdCAtIEkgZGlkbid0IGV2ZXIgZ2V0IHRoaXMgbGltaXRhdGlvbiBh Ym91dCBhIExJUyAodGhhdA0KPiBpdCdzIG9ubHkgZm9yIExDUHMpLg0KPiANCj4gRldJVyAtLSBJ IHRob3JvdWdobHkgZGlzYWdyZWUgd2l0aCB0aGlzIGRlZmluaXRpb24sIGJ1dCBtYXkgYmUgaW4g dGhlDQo+IG1pbm9yaXR5Lg0KPiANCj4gVXBvbiBkZXRlcm1pbmluZyB0aGF0IEknbSBpbiB0aGUg bWlub3JpdHksIEkgd2lsbCByZW1vdmUgIkxJUyIgZnJvbQ0KPiBjb252ZXlhbmNlIGFuZCByZXBs YWNlIGl0IHdpdGggTFMgYW5kIExvY2F0aW9uIFNlcnZlci4NCg0KSSBoYXZlIG5vIHByb2JsZW0g d2l0aCBzb21lb25lIGxhYmVsbGluZyB0aGUgcGllY2Ugb2YgaGFyZHdhcmUgb3Igc29mdHdhcmUg YXMgYSBMSVMuICBXZSBkbyB0aGF0LiAgQnV0IHRoZSBpbXBvcnRhbnQgcG9pbnQgaXMgdGhhdCB0 aGUgcm9sZSBhc3N1bWVkIGlzIHRoYXQgb2YgYSBMb2NhdGlvbiBTZXJ2ZXIuDQoNCkEgTElTIGlz bid0IHRoZSBvbmx5IHNvcnQgb2YgZW50aXR5IHRoYXQgY291bGQgcHJvdmlkZSB0aGUgbG9jYXRp b24gVVJJLiAgVGhpcyBjb3VsZCBqdXN0IGFzIGVhc2lseSBiZSBhIHByZXNlbmNlIHNlcnZpY2Us IG9yIGEgc3RhdGljIHdlYiBzaXRlIChmb3IgYW4gaHR0cFtzXTogVVJJKS4gIEkgYW0gYXdhcmUg b2Ygc2VydmljZXMgdGhhdCBhbHJlYWR5IGV4aXN0OyBzb21lIG9mIHRoZW0gbWlnaHQgZXZlbiBi ZSBhYmxlIHRvIHByb3ZpZGUgUElERi1MTy4NCg0KQnV0IHlvdSdyZSByaWdodCwgbGV0J3MgbnV0 IHRoaXMgb3V0IGluIEdFT1BSSVYuICBDYW4geW91IHN0YXJ0IHRoZSBiYWxsIHJvbGxpbmc/ICBP ciB3b3VsZCB5b3UgcHJlZmVyIHRoYXQgSSBkaWQ/DQoNCi4uLg0KPiA+VGhlbiBhZ2FpbiwgdGhl IFRhcmdldC1VQUMgY29ubmVjdGlvbiBzdGlsbCBpc24ndCBtYWRlLg0KPiANCj4gdGhhdCBoYXMg YmVlbiBnb2luZyBvbiBpbiB0aGUgYmFja2dyb3VuZCwgb2ZmbGlzdA0KDQpQbGVhc2UgbGV0IG1l IGtub3cgd2hhdCB0aGUgb3V0Y29tZSBpcy4gIEknbSBzdXJlIHdlJ3JlIGFsbCBpbnRlcmVzdGVk Lg0KDQo+ID5BcmUgd2UgYXNzdW1pbmcgdGhpcyBzdGlsbD8NCj4gDQo+IHdlIGNhbid0Lg0KDQpZ b3UnbGwgaGF2ZSB0byBqdXN0aWZ5IHRoYXQuICBJIGRvbid0IG9ubHkgdGhpbmsgaXQncyBwb3Nz aWJsZSwgSSB0aGluayB0aGF0IGl0J3MgbmVjZXNzYXJ5Lg0KIA0KPiBzaWduYWxpbmcgaXMgZWFz aWx5IGRlY29tcG9zZWQgZnJvbSBhIHByZXNlbmNlIGRvY3VtZW50Lg0KDQpTdXJlLCBidXQgd2hl biB5b3UgcmVtb3ZlIHRoZSBwcmVzZW5jZSBkb2N1bWVudCBpdCBsb3NlcyBhbnkgbWVhbmluZyBp dCBtaWdodCBoYXZlIGdhaW5lZCBmcm9tIGJlaW5nIGF0dGFjaGVkIHRvIHRoZSBzaWduYWxsaW5n Lg0KDQo+IHRoZSB0YXJnZXQgaXMgaWRlbnRpZmllZCBhcyB0aGUgImVudGl0eT0iIGF0dHJpYnV0 ZSB3aXRoaW4gdGhlDQo+IDxwcmVzZW5jZT4gZWxlbWVudC4gQ2hlY2sgc2VjdGlvbiA1IG9mIGNv bnZleWFuY2UgKGkuZS4sIG15IExieVYNCj4gZXhhbXBsZSkgdG8gc2VlLg0KDQpUaGUgVGFyZ2V0 IGlzICJpZGVudGlmaWVkIiBieSB0aGUgZW50aXR5IGF0dHJpYnV0ZSwgYnV0IHRoZXJlJ3Mgbm8g Z3VhcmFudGVlIHRoYXQgdGhlIHJlY2lwaWVudCBjYW4gbWFrZSB1c2Ugb2YgdGhhdCBpZGVudGlm aWVyLiAgQW4gdW5saW5rZWQgcHNldWRvbnltIHdvdWxkbid0IG9mZmVyIGFueSBjbHVlcy4gDQoN Cj4gVGhlcmVmb3JlLCB0aGUgdGFyZ2V0IGlkZW50aWZpZXIgaXMgZm91bmQgdGhlcmUsIGV2ZW4g aWYgaXQgaXMgYW4NCj4gdW5saW5rYWJsZSBwc2V1ZG9ueW0gdG8gaW50ZXJtZWRpYXJ5IGVudGl0 aWVzLiBJZiBpdCBpcyBub3QNCj4gdW5kZXJzdG9vZCBieSB0aGUgbG9jYXRpb24gcmVjaXBpZW50 LCB0aGVuIGl0IGlzIGlnbm9yZWQgYmVjYXVzZSBpdA0KPiBjYW5ub3QgYXR0YWNoIGlkZW50aXR5 IHRvIGl0Lg0KDQpTbyB5b3UgYXJlIHNheWluZyB0aGF0IGlmIHRoZSBwcmVzZW5jZSBkb2N1bWVu dCBjb250YWlucyBhbiBpZGVudGlmaWVyIHRoYXQgY2Fubm90IGJlIGxpbmtlZCB0byB0aGUgVUFD IGJ5IGEgcmVjaXBpZW50LCB0aGVuIHRoYXQgZG9jdW1lbnQgcG9zc2libHkgcmVmZXJzIHRvIGFu b3RoZXIgZW50aXR5LiAgQSBwcm94eSBwZXJmb3JtaW5nIGxvY2F0aW9uLWJhc2VkIHJvdXRpbmcg d291bGQgaWdub3JlIHRoZSByZXF1ZXN0LCBvciByZWdhcmQgbG9jYXRpb24gaW5mb3JtYXRpb24g YXMgYWJzZW50Lg0KDQpJIG9mZmVyIGEgZGlmZmVyZW50IHBvc3NpYmlsaXR5OiB0aGF0IHRoZSBs b2NhdGlvbiBpbmZvcm1hdGlvbiBwZXJ0YWlucyB0byB0aGUgZW50aXR5IHRoYXQgbWFrZXMgdGhl IHJlcXVlc3QsIHJlZ2FyZGxlc3Mgb2YgdGhlIGlkZW50aWZpZXIgdXNlZCB3aXRoaW4gdGhlIGRv Y3VtZW50Lg0KDQo+IEkgd2lsbCB0YWtlIHlvdXIgYWR2aWNlIChiYXNlZCBvbiByZWFkaW5nIFJG QyA0NDc5KSBhbmQgZGVsZXRlIC0gYW5kDQo+IG5vdCBtZW50aW9uIC0gdGhlIDxkZXZpY2VJRD4g YXMgdGhpcyBpcyBwcm92aWRpbmcgdG9vIG11Y2gNCj4gaW5mb3JtYXRpb24gdGhhdCBtaWdodCBy ZXZlYWwgYSBsaW5rIHRvIHRoZSB0YXJnZXQncyBpZGVudGl0eS4NCg0KVGhhbmtzLg0KDQotLU1h cnRpbg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVz c2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFp biBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRp b24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRo ZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0 aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0NCg== From jmpolk@cisco.com Thu Jul 2 22:14:46 2009 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 E06073A6927 for ; Thu, 2 Jul 2009 22:14:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.263 X-Spam-Level: X-Spam-Status: No, score=-6.263 tagged_above=-999 required=5 tests=[AWL=0.336, 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 FtHvLu5byIjh for ; Thu, 2 Jul 2009 22:14:45 -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 6910328C126 for ; Thu, 2 Jul 2009 22:14:20 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,338,1243814400"; d="scan'208";a="336744664" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 03 Jul 2009 05:14:43 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n635EhEE031778; Thu, 2 Jul 2009 22:14:43 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n635EhM2023180; Fri, 3 Jul 2009 05:14:43 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 22:14:43 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.89.206]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 22:14:42 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 03 Jul 2009 00:14:38 -0500 To: Hans Erik van Elburg From: "James M. Polk" In-Reply-To: <9ae56b1e0906250618x328c3012t9cb634f654f17469@mail.gmail.co m> References: <9ae56b1e0906250618x328c3012t9cb634f654f17469@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 03 Jul 2009 05:14:42.0863 (UTC) FILETIME=[2C4FBBF0:01C9FB9D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6823; t=1246598083; x=1247462083; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[sipcore]=20SIPCORE=20Location=20Convey ance=20-00=20submitted |Sender:=20; bh=fIJ3WvdnHv71pppZoiGJFrY3A/KjOM02IINN18eIi9Y=; b=N/cZ0mvanV6cnFN6Eq9G27O3eJqUIXrr72x5+3be3SO8qHFcBcxLa9qzve lXvXPuuaOJlZ/nHDicBrmAaiWS72zugskWjX1d8X+ejhZFagBk4aYaDCf4bP Smevqwdbhy; Authentication-Results: sj-dkim-4; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: sipcore@ietf.org, "Thomson, Martin" Subject: Re: [sipcore] SIPCORE Location Conveyance -00 submitted 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, 03 Jul 2009 05:14:47 -0000 At 08:18 AM 6/25/2009, Hans Erik van Elburg wrote: >So what IS the semantics of something like: >Geolocation: inserted-by="node1.example.com" Conveyance mandates that a URI be in the locationValue of a Geolocation header value. A tel: number is not supported. Only 4 URI schemes are supported: - a RFC 2392 defined cid-URL that indicates the location is by-value as a message body in the SIP request; - a sip:-, sips:- and pres:-uri which are location URIs to dereference the PIDF-LO are also supported. if a cid: doesn't appear in the Geolocation header value, then the URI MUST be deferencebale at a Location Server. a tel: doesn't accomplish this. According to Conveyance, everything must end up with location in a PIDF-LO format. anything else is proprietary at this point, or requires an extension in a future RFC to become a standard in any form. >Does it express the location of the sender? it can, but doesn't have to. in the PIDF-LO, there is a element with a entity= attribute which identifies the target - whether the UAC or another entity. >Can it express the location of the receiver? yes it can. >Can the meaning depend on who inserted it? it depends on who the presence document is identifying. if there are more than 1 presence documents in the SIP request (by-value or by-reference), the target identifier identifies who each is identifying (see below). >Where does it say so? Is "it" the ID or is "it" asking where is this identified? If "it" is the ID, I will make this clearer in the next rev, but here is answer: The element of the PIDF-LO has a entity= attribute that identifies who the target is for *this* location. >Also the use of the word Target is extremely confusing in a SIP >setting, even if you define it to mean something else then what it >means normally. "Target" in Geopriv is very similar to "presentity" in Presence, which is close to SIP. wrt changing these terms -- that ship has sailed, my friend >BR, >/Hans Erik van Elburg > >On Thu, Jun 25, 2009 at 2:33 AM, Thomson, Martin ><Martin.Thomson@andrew.com> wrote: >Inline, > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Thursday, 25 June 2009 10:03 AM > > To: Thomson, Martin; sipcore@ietf.org > > Subject: RE: [sipcore] SIPCORE Location Conveyance -00 submitted > > > > At 06:06 PM 6/24/2009, Thomson, Martin wrote: > > >Hi James, > > > > > >I'll preface this email with the usual note that it's shocking how > > >old this document is. This is an important document from my > > >perspective, and it needs to be published. > > > > > >Your rewritten intro is a great improvement. I didn't read in > > >detail beyond this, but it's certainly much clearer. > > > > > >I note that the example PIDF-LO documents still contain > > >errors. Refer to 5491 or one of my previous reviews for details. > > > > your previous emails have never had any details to know what you're > > talking about... just as this one doesn't. Since I cannot determine > > what you want changed, knowing I'm not a mind reader, the text > > remains as it is. > >I don't have time right now to detail the myriad ways. For now all >I can do is suggest that you validate the XML. Before you do >though, ensure that you remove all instances of >processContents="lax" so that the validator doesn't decide to skip >validation on anything. > >Offhand, I noted that provided-by usage is incorrect (remove it), >you omitted the mandatory deviceID element from device, timestamp >comes after status, retransmission-allowed is of the 'xs:boolean' >type which means s/no/false/ (contrary to what might be indicated in RFC4119). > > > >The one major flaw that I highlighted in my WGLC comments to the > > >former SIP WG remains. The document does not establish strict > > >semantics for the location it conveys. Is the location information > > >indicated in a Geolocation header belong to the entity identified in > > >the From header? Or is it the UAC that sends the request? While > > >this might seem intuitive, it's not. To complicate things, the > > >PIDF-LO can contain alternative identification information, there is > > >a potential for confusion or conflict. > > > > Please read the parts you say you didn't read this time to read the > > text that's been in the doc for quite some time now that discusses > > this. > >I just re-read the first 10 pages, plus the descriptions of UAC and >UAS behaviour without finding anything other than vague hints. In >all cases you talk about "target", "Target" or "Alice" without >describing how that identity is established or linked to any >protocol parameters. I'd expect this to be more clearly described >before you get into the protocol details. > >I did find this hidden at the bottom of S4.1: > > The > element [RFC5491] in the PIDF-LO XML indicates whose location > is contained in the PIDF-LO. > >This is potentially of no use: SIP peers do not necessarily have >the necessary context to make sense of these identifiers; deviceID >is not mandatory; and for privacy reasons I would recommend to >anyone implementing this that they do not provide this information. > >(The correct reference here is RFC 4479 - presence data model, which >defines this field; and I suspect that you mean >..., not , which has other semantics.) > > > >This document needs to be really clear about who the location > > >belongs to within the context of the exchange. > > > > here's a hint: this is (and has always been) done in the PIDF-LO, > > this is not (and never has been) part of any of the SIP headers. > >Now this is a problem indeed. The possibility that the PIDF-LO >contains an unlinked pseudonym (c.f. RFC 3693) has to be >considered. Note also the above problems. > > > > > >--Martin > > > > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore > From jmpolk@cisco.com Thu Jul 2 22:41:20 2009 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 6BB8B3A69D2 for ; Thu, 2 Jul 2009 22:41:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.273 X-Spam-Level: X-Spam-Status: No, score=-6.273 tagged_above=-999 required=5 tests=[AWL=0.326, 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 NlFZP5Pok4eQ for ; Thu, 2 Jul 2009 22:41:19 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 38D933A6831 for ; Thu, 2 Jul 2009 22:41:19 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,338,1243814400"; d="scan'208";a="182701937" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 03 Jul 2009 05:41:42 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n635febh032005; Thu, 2 Jul 2009 22:41:40 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n635feHm008939; Fri, 3 Jul 2009 05:41:40 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 22:41:39 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.89.206]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 2 Jul 2009 22:41:39 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 03 Jul 2009 00:41:38 -0500 To: "Thomson, Martin" , "Elwell, John" , From: "James M. Polk" In-Reply-To: References: <0D5F89FAC29E2C41B98A6A762007F5D00218BF88@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 03 Jul 2009 05:41:39.0384 (UTC) FILETIME=[EFD54380:01C9FBA0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6377; t=1246599700; x=1247463700; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[sipcore]=20Review=20of=20=0A=20=20draf t-ietf-sipcore-location-conveyance-00=20sections=201=20to=20 3 |Sender:=20; bh=KbXvLYkr9yHzNS7T/vvtgQVQ88TmQIm6Fr5hOPWm6E4=; b=XsRNqdAPIA4h1wwuhcNrfbZ36F3m5A4SJtlKSduKzDhpr3q59nwXzp40Gn MERBbc6BGH26ew++YjOKYjqErvjKAHmNuaQbX2yRKs5n+sBaBVddp5OgFq+x QevcIfqBOlNzZYfIUGmoPA7UuaLsnEL/NGHc4s6M2xZxmhYrXavbg=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [sipcore] Review of draft-ietf-sipcore-location-conveyance-00 sections 1 to 3 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, 03 Jul 2009 05:41:20 -0000 inline At 11:22 PM 7/2/2009, Thomson, Martin wrote: >Inline.. > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Friday, 3 July 2009 2:00 PM > > To: Thomson, Martin; Elwell, John; sipcore@ietf.org > > Subject: RE: [sipcore] Review of draft-ietf-sipcore-location- > > conveyance-00 sections 1 to 3 > > > > At 06:28 PM 7/2/2009, Thomson, Martin wrote: > > >Hi James, > > > > > >John is correct about use of LIS and LS. A LIS is a specialized > > >term that is used only in the location configuration protocol (LCP) > > >context only. > > > > I have to admit - I didn't ever get this limitation about a LIS (that > > it's only for LCPs). > > > > FWIW -- I thoroughly disagree with this definition, but may be in the > > minority. > > > > Upon determining that I'm in the minority, I will remove "LIS" from > > conveyance and replace it with LS and Location Server. > >I have no problem with someone labelling the piece of hardware or >software as a LIS. We do that. But the important point is that the >role assumed is that of a Location Server. > >A LIS isn't the only sort of entity that could provide the location >URI. This could just as easily be a presence service, or a static >web site (for an http[s]: URI). I am aware of services that already >exist; some of them might even be able to provide PIDF-LO. > >But you're right, let's nut this out in GEOPRIV. Can you start the >ball rolling? Or would you prefer that I did? I don't care >... > > >Then again, the Target-UAC connection still isn't made. > > > > that has been going on in the background, offlist > >Please let me know what the outcome is. I'm sure we're all interested. actually - I said this below already, and verified this with Mr. Peterson this week. > > >Are we assuming this still? > > > > we can't. > >You'll have to justify that. I don't only think it's possible, I >think that it's necessary. > > > signaling is easily decomposed from a presence document. > >Sure, but when you remove the presence document it loses any meaning >it might have gained from being attached to the signalling. exactly, and what's the problem with this? a presence document is intended to be useful on its own, without signaling. > > the target is identified as the "entity=" attribute within the > > element. Check section 5 of conveyance (i.e., my LbyV > > example) to see. > >The Target is "identified" by the entity attribute, but there's no >guarantee that the recipient can make use of that identifier. exactly >An unlinked pseudonym wouldn't offer any clues. but at this point, this is the advantage. There is no identity information revealed to who doesn't know the pseudonym (which is the point, right?) If Alice doesn't use an unlinknable pseudonym, and uses something that is readable to her identity (like an AOR or contact address), the this presence document is linkable to her identity with or without signaling information. > > Therefore, the target identifier is found there, even if it is an > > unlinkable pseudonym to intermediary entities. If it is not > > understood by the location recipient, then it is ignored because it > > cannot attach identity to it. > >So you are saying that if the presence document contains an >identifier that cannot be linked to the UAC by a recipient, then >that document possibly refers to another entity. not exactly. I'm saying regardless of who signaled the document (for example, whether from Bob to Alice, or Alice to Carol), the entity= attribute identifies to who hte target is for this document without the signaling. If this is Bob's location, he is the target. If it can be linked to him, then both Alice and Carol know this is Bob's target location (no matter who sent it to Alice or Carol). If this is unlinkable, even if Bob sent it to Alice *and* Carol, neither know this is Bob's target location. They cannot assume this is Bob's location, because they can't verify the identity within the document (which is necessary). Furthering the Alice, Bob and Carol example, let's say Bob told Alice his location, and Alice passed this on to Carol, along with Alice's location. This is possible because the entity= attribute in both PIDF-LO documents that Carol received identify which location goes to which entity (Alice and Bob respectfully). This assumes that Bob set his retransmission-allowed to "yes" or true, and the retention-expiry hasn't elapsed. >A proxy performing location-based routing would ignore the request, >or regard location information as absent. yes this would necessitate a 424 (bad location) response, with a error code set to 100 (cannot process location). I would normally want to add a new error code specifically in the 1XX range indicating the problem specifically is (to the effect of) "received *a* location, but couldn't link this to your location to use for location based routing -- please provide your linkable identity and try again". However, a few of you want me to remove the error section entirely, so adding a new one doesn't make much sense, right? (***even though it would address THIS EXACT PROBLEM***)... >I offer a different possibility: that the location information >pertains to the entity that makes the request, regardless of the >identifier used within the document. that links the identity to the SIP request, even if the use doesn't want this link. That doesn't seem right. > > I will take your advice (based on reading RFC 4479) and delete - and > > not mention - the as this is providing too much > > information that might reveal a link to the target's identity. > >Thanks. no problem. >--Martin > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] From Martin.Thomson@andrew.com Thu Jul 2 23:14:14 2009 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 BBC553A6C28 for ; Thu, 2 Jul 2009 23:14:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 4fnFwPSkm7P9 for ; Thu, 2 Jul 2009 23:14:13 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 644513A6C3C for ; Thu, 2 Jul 2009 23:14:10 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_03_01_36_35 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Fri, 03 Jul 2009 01:36:34 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 3 Jul 2009 01:14:32 -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: Fri, 3 Jul 2009 01:14:07 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sipcore-location-conveyance-00 : identity binding (was: something else) Thread-Index: Acn7oPMG1ppIgcb8R7+l3HmJkgxBhgAATWrw References: <0D5F89FAC29E2C41B98A6A762007F5D00218BF88@GBNTHT12009MSX.gb002.siemens.net> From: "Thomson, Martin" To: "James M. Polk" , X-OriginalArrivalTime: 03 Jul 2009 06:14:32.0939 (UTC) FILETIME=[8829DBB0:01C9FBA5] Subject: [sipcore] draft-ietf-sipcore-location-conveyance-00 : identity binding (was: something else) 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, 03 Jul 2009 06:14:14 -0000 SSBjYW4gc3ltcGF0aGl6ZSB3aXRoIHlvdXIgZGVzaXJlIHRvIGtlZXAgZXZlcnl0aGluZyB3aXRo aW4gdGhlIFBJREYsIGJ1dCBpdCdzIGp1c3Qgbm90IHByYWN0aWNhbC4NCg0KSWYgdGhpcyB3ZXJl IGEgZmlsZSB0cmFuc2ZlciBwcm90b2NvbCwgdGhlbiBJIGNhbiBzZWUgdGhlIHNlbnNlIGluIGJl aW5nIGFibGUgdG8gc2hpcCBhcmJpdHJhcnkgUElERiBkb2N1bWVudHMgYXJvdW5kLiAgSG93ZXZl ciwgd2UncmUgdGFsa2luZyBhYm91dCBhdHRhY2hpbmcgc2VtYW50aWNzIHRvIHRoZXNlIGRvY3Vt ZW50cyBpbiB0aGUgY29udGV4dCBvZiBzaWduYWxsaW5nLiAgVGhlIEdlb2xvY2F0aW9uIGhlYWRl ciBtYWtlcyBhIGJpbmRpbmcgYmV0d2VlbiB0aGUgcmVxdWVzdCBhbmQgdGhlIGRvY3VtZW50LiAg VGhhdCBiaW5kaW5nIGhhZCBiZXR0ZXIgaGF2ZSBzb21lIHdlbGwtdW5kZXJzdG9vZCBtZWFuaW5n IG9yIHRoaXMgYWxsIGZhaWxzLg0KDQpJZiB5b3Ugd2FudCB0byBwYXNzIGFyb3VuZCB1bnJlbGF0 ZWQgaW5mb3JtYXRpb24sIHlvdSdyZSBmcmVlIHRvIGRvIHNvIHdpdGhvdXQgYSBHZW9sb2NhdGlv biBoZWFkZXIuDQoNClRoZXJlIGFyZSB0d28gdXNlIGNhc2VzIHRoYXQgbWFrZSB3aGF0IHlvdSBw cm9wb3NlIHZlcnkgZGlmZmljdWx0IGZyb20gYSBwcmFjdGljYWwgc3RhbmRwb2ludC4gIE9uZSBp cyBhIHZlcnkgcmVhbCBwcm9ibGVtOyB0aGUgb3RoZXIgY2FuIGJlIGFyZ3VlZCB0byBiZSBsZXNz IHNvLCBidXQgY29udGludWVzIHRvIHBsYWd1ZSB1cywgc28gaXQncyBwcm9iYWJseSBzdGlsbCBp bXBvcnRhbnQuDQoNCjEpIElmIHdlIHVzZSB5b3VyIGludGVycHJldGF0aW9uLCB0aGVuIGxvY2F0 aW9uIFVSSXMgbmVlZCB0byBiZSBkZXJlZmVyZW5jZWQgYmVmb3JlIGFueW9uZSBjYW4gZXZlbiBi ZSBzdXJlIHRoYXQgdGhleSBhcmUgcmVsZXZhbnQuDQoNCjFiKSBGdXJ0aGVybW9yZSwgeW91ciBM UyAtIGVzcGVjaWFsbHkgaWYgaXQgaXMgYSBMSVMgLSBtaWdodCBub3QgdXNlIHRoZSBpZGVudGl0 eSB0aGF0IHlvdSB3YW50LiAgSXQgcHJvYmFibHkgY2FuJ3QuICBJdCBpcyB1bmxpa2VseSB0aGF0 IGEgTElTIGlzIGFibGUgdG8gYXNzZXJ0IHRoYXQgc2lwczphbGljZUBleGFtcGxlLmNvbSB3YXMg cHJlc2VudCBhdCB0aGUgZ2l2ZW4gbG9jYXRpb24gYW5kIHRpbWUuICBJdCdzIGdvaW5nIHRvIHNh eSB0aGF0IHRoZSBlbnRpdHkgdGhhdCByZXF1ZXN0ZWQgbG9jYXRpb24gaW5mb3JtYXRpb24gYXQg dGhhdCB0aW1lIHdhcyBhdCB0aGF0IGxvY2F0aW9uIGFuZCBnaXZlIHRoZW0gYSBuYW1lLi4uYW4g dW5saW5rZWQgcHNldWRvbnltLg0KDQoyKSBUaGUgb3RoZXIgaXMgZGlnaXRhbCBzaWduaW5nIGFu ZCBpbnRlZ3JpdHkuICBUaGUgYmluZGluZyBiZXR3ZWVuIGxvY2F0aW9uIGFuZCBpZGVudGl0eSBp cyBvZnRlbiBtYWRlIGluIGEgY29udGV4dCB0aGF0IGlzIHVuYXdhcmUgb2YgU0lQIGlkZW50aXRp ZXMuICBUaGVyZWZvcmUsIGEgc2lnbmVkIFBJREYgZG9jdW1lbnQgbWlnaHQgbm90IGluY2x1ZGUg YW4gaWRlbnRpdHkgdGhhdCBpcyBtZWFuaW5nZnVsIGluIHRoZSBzaWduYWxsaW5nIGNvbnRleHQu DQoNClRoZXJlJ3Mgbm8gcmVhc29uIHRoYXQgeW91IGNhbid0IGFzc2lnbiBtZWFuaW5nIHRvIHRo ZSBHZW9sb2NhdGlvbiBoZWFkZXIgdGhhdCBzYXlzOiB3aG9tZXZlciBpbnNlcnRlZCB0aGlzIGhl YWRlciBhc3NlcnRzIHRoYXQgdGhlIFVBQyBpcyBhdCB0aGUgaW5kaWNhdGVkIGxvY2F0aW9uLiAg VGhhdCBkb2Vzbid0IG5lY2Vzc2FyaWx5IGltcGx5IHRoYXQgdGhlIGVudGl0eSBpZGVudGlmaWVk IGluIHRoZSBkb2N1bWVudCBpcyB0aGUgc2FtZSBhcyB0aGUgVUFDLCBvciB2aWNlIHZlcnNhLCBh bGwgaXQgZG9lcyBpcyBwcm92aWRlIGEgYmluZGluZyBiZXR3ZWVuIGlkZW50aXR5IGluIG9uZSBj b250ZXh0ICh0aGUgVUFDKSBhbmQgYW5vdGhlciAodGhlIFRhcmdldCBvZiB0aGUgUElERikuDQoN CihJbiB5b3VyIGV4YW1wbGUsIHRoZSBzZW1hbnRpYyB3ZWIgZm9sa3Mgd291bGQgYXNzZXJ0IHRo YXQgYSBVUkkgdGVsbHMgeW91IG5vdGhpbmcsIG9ubHkgdGhlIGNvbnRleHQgd2hlcmUgaXQgYXBw ZWFycyBnaXZlcyB5b3UgdGhlIGluZm9ybWF0aW9uIG5lY2Vzc2FyeSB0byBwdXQgaXQgaW50byBj b250ZXh0LiAgTWF5YmUgQWxpY2UgY2FuIHRlbGwgQ2Fyb2wgdGhhdCB0aGUgbG9jYXRpb24gc2hl IGp1c3QgcmVjZWl2ZWQgd2FzIEJvYidzIGxvY2F0aW9uOyBvciBpdCBjYW4gaWRlbnRpZnkgQm9i IGRpcmVjdGx5LikNCg0KLS1NYXJ0aW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0K PiBGcm9tOiBKYW1lcyBNLiBQb2xrIFttYWlsdG86am1wb2xrQGNpc2NvLmNvbV0NCj4gU2VudDog RnJpZGF5LCAzIEp1bHkgMjAwOSAzOjQyIFBNDQo+IFRvOiBUaG9tc29uLCBNYXJ0aW47IEVsd2Vs bCwgSm9objsgc2lwY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSRTogW3NpcGNvcmVdIFJldmll dyBvZiBkcmFmdC1pZXRmLXNpcGNvcmUtbG9jYXRpb24tDQo+IGNvbnZleWFuY2UtMDAgc2VjdGlv bnMgMSB0byAzDQo+IA0KPiA+Li4uDQo+ID4gPiA+VGhlbiBhZ2FpbiwgdGhlIFRhcmdldC1VQUMg Y29ubmVjdGlvbiBzdGlsbCBpc24ndCBtYWRlLg0KPiA+ID4NCj4gPiA+IHRoYXQgaGFzIGJlZW4g Z29pbmcgb24gaW4gdGhlIGJhY2tncm91bmQsIG9mZmxpc3QNCj4gPg0KPiA+UGxlYXNlIGxldCBt ZSBrbm93IHdoYXQgdGhlIG91dGNvbWUgaXMuICBJJ20gc3VyZSB3ZSdyZSBhbGwNCj4gaW50ZXJl c3RlZC4NCj4gDQo+IGFjdHVhbGx5IC0gSSBzYWlkIHRoaXMgYmVsb3cgYWxyZWFkeSwgYW5kIHZl cmlmaWVkIHRoaXMgd2l0aCBNci4NCj4gUGV0ZXJzb24gdGhpcyB3ZWVrLg0KPiANCj4gDQo+ID4g PiA+QXJlIHdlIGFzc3VtaW5nIHRoaXMgc3RpbGw/DQo+ID4gPg0KPiA+ID4gd2UgY2FuJ3QuDQo+ ID4NCj4gPllvdSdsbCBoYXZlIHRvIGp1c3RpZnkgdGhhdC4gIEkgZG9uJ3Qgb25seSB0aGluayBp dCdzIHBvc3NpYmxlLCBJDQo+ID50aGluayB0aGF0IGl0J3MgbmVjZXNzYXJ5Lg0KPiA+DQo+ID4g PiBzaWduYWxpbmcgaXMgZWFzaWx5IGRlY29tcG9zZWQgZnJvbSBhIHByZXNlbmNlIGRvY3VtZW50 Lg0KPiA+DQo+ID5TdXJlLCBidXQgd2hlbiB5b3UgcmVtb3ZlIHRoZSBwcmVzZW5jZSBkb2N1bWVu dCBpdCBsb3NlcyBhbnkgbWVhbmluZw0KPiA+aXQgbWlnaHQgaGF2ZSBnYWluZWQgZnJvbSBiZWlu ZyBhdHRhY2hlZCB0byB0aGUgc2lnbmFsbGluZy4NCj4gDQo+IGV4YWN0bHksIGFuZCB3aGF0J3Mg dGhlIHByb2JsZW0gd2l0aCB0aGlzPyAgYSBwcmVzZW5jZSBkb2N1bWVudCBpcw0KPiBpbnRlbmRl ZCB0byBiZSB1c2VmdWwgb24gaXRzIG93biwgd2l0aG91dCBzaWduYWxpbmcuDQo+IA0KPiANCj4g PiA+IHRoZSB0YXJnZXQgaXMgaWRlbnRpZmllZCBhcyB0aGUgImVudGl0eT0iIGF0dHJpYnV0ZSB3 aXRoaW4gdGhlDQo+ID4gPiA8cHJlc2VuY2U+IGVsZW1lbnQuIENoZWNrIHNlY3Rpb24gNSBvZiBj b252ZXlhbmNlIChpLmUuLCBteSBMYnlWDQo+ID4gPiBleGFtcGxlKSB0byBzZWUuDQo+ID4NCj4g PlRoZSBUYXJnZXQgaXMgImlkZW50aWZpZWQiIGJ5IHRoZSBlbnRpdHkgYXR0cmlidXRlLCBidXQg dGhlcmUncyBubw0KPiA+Z3VhcmFudGVlIHRoYXQgdGhlIHJlY2lwaWVudCBjYW4gbWFrZSB1c2Ug b2YgdGhhdCBpZGVudGlmaWVyLg0KPiANCj4gZXhhY3RseQ0KPiANCj4gPkFuIHVubGlua2VkIHBz ZXVkb255bSB3b3VsZG4ndCBvZmZlciBhbnkgY2x1ZXMuDQo+IA0KPiBidXQgYXQgdGhpcyBwb2lu dCwgdGhpcyBpcyB0aGUgYWR2YW50YWdlLiBUaGVyZSBpcyBubyBpZGVudGl0eQ0KPiBpbmZvcm1h dGlvbiByZXZlYWxlZCB0byB3aG8gZG9lc24ndCBrbm93IHRoZSBwc2V1ZG9ueW0gKHdoaWNoIGlz IHRoZQ0KPiBwb2ludCwgcmlnaHQ/KQ0KPiANCj4gSWYgQWxpY2UgZG9lc24ndCB1c2UgYW4gdW5s aW5rbmFibGUgcHNldWRvbnltLCBhbmQgdXNlcyBzb21ldGhpbmcNCj4gdGhhdCBpcyByZWFkYWJs ZSB0byBoZXIgaWRlbnRpdHkgKGxpa2UgYW4gQU9SIG9yIGNvbnRhY3QgYWRkcmVzcyksDQo+IHRo ZSB0aGlzIHByZXNlbmNlIGRvY3VtZW50IGlzIGxpbmthYmxlIHRvIGhlciBpZGVudGl0eSB3aXRo IG9yDQo+IHdpdGhvdXQgc2lnbmFsaW5nIGluZm9ybWF0aW9uLg0KPiANCj4gDQo+ID4gPiBUaGVy ZWZvcmUsIHRoZSB0YXJnZXQgaWRlbnRpZmllciBpcyBmb3VuZCB0aGVyZSwgZXZlbiBpZiBpdCBp cyBhbg0KPiA+ID4gdW5saW5rYWJsZSBwc2V1ZG9ueW0gdG8gaW50ZXJtZWRpYXJ5IGVudGl0aWVz LiBJZiBpdCBpcyBub3QNCj4gPiA+IHVuZGVyc3Rvb2QgYnkgdGhlIGxvY2F0aW9uIHJlY2lwaWVu dCwgdGhlbiBpdCBpcyBpZ25vcmVkIGJlY2F1c2UgaXQNCj4gPiA+IGNhbm5vdCBhdHRhY2ggaWRl bnRpdHkgdG8gaXQuDQo+ID4NCj4gPlNvIHlvdSBhcmUgc2F5aW5nIHRoYXQgaWYgdGhlIHByZXNl bmNlIGRvY3VtZW50IGNvbnRhaW5zIGFuDQo+ID5pZGVudGlmaWVyIHRoYXQgY2Fubm90IGJlIGxp bmtlZCB0byB0aGUgVUFDIGJ5IGEgcmVjaXBpZW50LCB0aGVuDQo+ID50aGF0IGRvY3VtZW50IHBv c3NpYmx5IHJlZmVycyB0byBhbm90aGVyIGVudGl0eS4NCj4gDQo+IG5vdCBleGFjdGx5Lg0KPiAN Cj4gSSdtIHNheWluZyByZWdhcmRsZXNzIG9mIHdobyBzaWduYWxlZCB0aGUgZG9jdW1lbnQgKGZv ciBleGFtcGxlLA0KPiB3aGV0aGVyIGZyb20gQm9iIHRvIEFsaWNlLCBvciBBbGljZSB0byBDYXJv bCksIHRoZSBlbnRpdHk9IGF0dHJpYnV0ZQ0KPiBpZGVudGlmaWVzIHRvIHdobyBodGUgdGFyZ2V0 IGlzIGZvciB0aGlzIGRvY3VtZW50IHdpdGhvdXQgdGhlDQo+IHNpZ25hbGluZy4gSWYgdGhpcyBp cyBCb2IncyBsb2NhdGlvbiwgaGUgaXMgdGhlIHRhcmdldC4gSWYgaXQgY2FuIGJlDQo+IGxpbmtl ZCB0byBoaW0sIHRoZW4gYm90aCBBbGljZSBhbmQgQ2Fyb2wga25vdyB0aGlzIGlzIEJvYidzIHRh cmdldA0KPiBsb2NhdGlvbiAobm8gbWF0dGVyIHdobyBzZW50IGl0IHRvIEFsaWNlIG9yIENhcm9s KS4gIElmIHRoaXMgaXMNCj4gdW5saW5rYWJsZSwgZXZlbiBpZiBCb2Igc2VudCBpdCB0byBBbGlj ZSAqYW5kKiBDYXJvbCwgbmVpdGhlciBrbm93DQo+IHRoaXMgaXMgQm9iJ3MgdGFyZ2V0IGxvY2F0 aW9uLiBUaGV5IGNhbm5vdCBhc3N1bWUgdGhpcyBpcyBCb2Incw0KPiBsb2NhdGlvbiwgYmVjYXVz ZSB0aGV5IGNhbid0IHZlcmlmeSB0aGUgaWRlbnRpdHkgd2l0aGluIHRoZSBkb2N1bWVudA0KPiAo d2hpY2ggaXMgbmVjZXNzYXJ5KS4NCj4gDQo+IEZ1cnRoZXJpbmcgdGhlIEFsaWNlLCBCb2IgYW5k IENhcm9sIGV4YW1wbGUsIGxldCdzIHNheSBCb2IgdG9sZCBBbGljZQ0KPiBoaXMgbG9jYXRpb24s IGFuZCBBbGljZSBwYXNzZWQgdGhpcyBvbiB0byBDYXJvbCwgYWxvbmcgd2l0aCBBbGljZSdzDQo+ IGxvY2F0aW9uLiBUaGlzIGlzIHBvc3NpYmxlIGJlY2F1c2UgdGhlIGVudGl0eT0gYXR0cmlidXRl IGluIGJvdGgNCj4gUElERi1MTyBkb2N1bWVudHMgdGhhdCBDYXJvbCByZWNlaXZlZCBpZGVudGlm eSB3aGljaCBsb2NhdGlvbiBnb2VzIHRvDQo+IHdoaWNoIGVudGl0eSAoQWxpY2UgYW5kIEJvYiBy ZXNwZWN0ZnVsbHkpLiBUaGlzIGFzc3VtZXMgdGhhdCBCb2Igc2V0DQo+IGhpcyByZXRyYW5zbWlz c2lvbi1hbGxvd2VkIHRvICJ5ZXMiIG9yIHRydWUsIGFuZCB0aGUgcmV0ZW50aW9uLWV4cGlyeQ0K PiBoYXNuJ3QgZWxhcHNlZC4NCj4gDQo+ID5BIHByb3h5IHBlcmZvcm1pbmcgbG9jYXRpb24tYmFz ZWQgcm91dGluZyB3b3VsZCBpZ25vcmUgdGhlIHJlcXVlc3QsDQo+ID5vciByZWdhcmQgbG9jYXRp b24gaW5mb3JtYXRpb24gYXMgYWJzZW50Lg0KPiANCj4geWVzDQo+IA0KPiB0aGlzIHdvdWxkIG5l Y2Vzc2l0YXRlIGEgNDI0IChiYWQgbG9jYXRpb24pIHJlc3BvbnNlLCB3aXRoIGEgZXJyb3INCj4g Y29kZSBzZXQgdG8gMTAwIChjYW5ub3QgcHJvY2VzcyBsb2NhdGlvbikuDQo+IA0KPiBJIHdvdWxk IG5vcm1hbGx5IHdhbnQgdG8gYWRkIGEgbmV3IGVycm9yIGNvZGUgc3BlY2lmaWNhbGx5IGluIHRo ZSAxWFgNCj4gcmFuZ2UgaW5kaWNhdGluZyB0aGUgcHJvYmxlbSBzcGVjaWZpY2FsbHkgaXMgKHRv IHRoZSBlZmZlY3Qgb2YpDQo+ICJyZWNlaXZlZCAqYSogbG9jYXRpb24sIGJ1dCBjb3VsZG4ndCBs aW5rIHRoaXMgdG8geW91ciBsb2NhdGlvbiB0bw0KPiB1c2UgZm9yIGxvY2F0aW9uIGJhc2VkIHJv dXRpbmcgLS0gcGxlYXNlIHByb3ZpZGUgeW91ciBsaW5rYWJsZQ0KPiBpZGVudGl0eSBhbmQgdHJ5 IGFnYWluIi4gSG93ZXZlciwgYSBmZXcgb2YgeW91IHdhbnQgbWUgdG8gcmVtb3ZlIHRoZQ0KPiBl cnJvciBzZWN0aW9uIGVudGlyZWx5LCBzbyBhZGRpbmcgYSBuZXcgb25lIGRvZXNuJ3QgbWFrZSBt dWNoIHNlbnNlLA0KPiByaWdodD8gKCoqKmV2ZW4gdGhvdWdoIGl0IHdvdWxkIGFkZHJlc3MgVEhJ UyBFWEFDVCBQUk9CTEVNKioqKS4uLg0KPiANCj4gPG11bWJsZT4NCj4gDQo+IA0KPiA+SSBvZmZl ciBhIGRpZmZlcmVudCBwb3NzaWJpbGl0eTogdGhhdCB0aGUgbG9jYXRpb24gaW5mb3JtYXRpb24N Cj4gPnBlcnRhaW5zIHRvIHRoZSBlbnRpdHkgdGhhdCBtYWtlcyB0aGUgcmVxdWVzdCwgcmVnYXJk bGVzcyBvZiB0aGUNCj4gPmlkZW50aWZpZXIgdXNlZCB3aXRoaW4gdGhlIGRvY3VtZW50Lg0KPiAN Cj4gdGhhdCBsaW5rcyB0aGUgaWRlbnRpdHkgdG8gdGhlIFNJUCByZXF1ZXN0LCBldmVuIGlmIHRo ZSB1c2UgZG9lc24ndA0KPiB3YW50IHRoaXMgbGluay4gVGhhdCBkb2Vzbid0IHNlZW0gcmlnaHQu DQo+IA0KPiANCj4gPiA+IEkgd2lsbCB0YWtlIHlvdXIgYWR2aWNlIChiYXNlZCBvbiByZWFkaW5n IFJGQyA0NDc5KSBhbmQgZGVsZXRlIC0NCj4gYW5kDQo+ID4gPiBub3QgbWVudGlvbiAtIHRoZSA8 ZGV2aWNlSUQ+IGFzIHRoaXMgaXMgcHJvdmlkaW5nIHRvbyBtdWNoDQo+ID4gPiBpbmZvcm1hdGlv biB0aGF0IG1pZ2h0IHJldmVhbCBhIGxpbmsgdG8gdGhlIHRhcmdldCdzIGlkZW50aXR5Lg0KPiA+ DQo+ID5UaGFua3MuDQo+IA0KPiBubyBwcm9ibGVtLg0KPiANCj4gDQo+ID4tLU1hcnRpbg0KPiA+ DQo+ID4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID5UaGlz IG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFuZCBtYXkNCj4g PmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGlu Zm9ybWF0aW9uLg0KPiA+SWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBu b3RpZnkgdGhlIHNlbmRlcg0KPiA+aW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwu ICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KPiA+dGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0K PiA+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+W21mMl0N Cj4gDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNz YWdlIGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWlu IHByaXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlv bi4gIA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhl IHNlbmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRo b3JpemVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ0K From john.elwell@siemens-enterprise.com Thu Jul 2 23:21:42 2009 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 59F2F3A6C28 for ; Thu, 2 Jul 2009 23:21:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 TAEvZaIQu6px for ; Thu, 2 Jul 2009 23:21:41 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 816E23A6973 for ; Thu, 2 Jul 2009 23:21:41 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KM7005AU0CRAP@siemenscomms.co.uk> for sipcore@ietf.org; Fri, 03 Jul 2009 07:22:03 +0100 (BST) Date: Fri, 03 Jul 2009 07:22:02 +0100 From: "Elwell, John" In-reply-to: To: "James M. Polk" , sipcore@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00218C370@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] Review of draft-ietf-sipcore-location-conveyance-00 sections 1 to 3 Thread-Index: Acn7UOHzjKsIR2CkQoetEhcQ0D2d8gAVYApA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D00218BF88@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00218C331@GBNTHT12009MSX.gb002.siemens.net> Subject: Re: [sipcore] Review of draft-ietf-sipcore-location-conveyance-00 sections 1 to 3 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, 03 Jul 2009 06:21:42 -0000 > > > >- " LbyR refers to a UA > > > > including a location URI in a SIP request header field > > > which can be > > > > dereferenced by a Location Recipient to receive=20 > Alice's Location > > > > Object, in the form of a PIDF-LO." > > > >The header field is not dereferenced, it is the location=20 > URI that is > > > >dereferenced. > > > > > > this is an artifact of the acronym "LbyR" being considered an > > > archiecture by the Geopriv WG for about a year (some still feel it > > > is), where I believe LbyR is just a location URI. This=20 > is an attempt > > > to have the Geopriv folks understand that the Location=20 > URI, which is > > > the Geolocation header value is used to dereference the > > > Target's location. > >[JRE] I agree, but my original complaint still holds, i.e., it is the > >URI that is dereferenced, not the header field. >=20 > I agree, and will make it clear by saying it's the header value that=20 > is used to make the dereference [JRE] No, it is not the entire header field value (including its parameters) - it is only the URI. John From john.elwell@siemens-enterprise.com Thu Jul 2 23:46:19 2009 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 7822B3A6B7F for ; Thu, 2 Jul 2009 23:46:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 3Ozax41W22cn for ; Thu, 2 Jul 2009 23:46:18 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 1725A3A6B29 for ; Thu, 2 Jul 2009 23:44:20 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KM700724128BB@siemenscomms.co.uk> for sipcore@ietf.org; Fri, 03 Jul 2009 07:37:20 +0100 (BST) Date: Fri, 03 Jul 2009 07:37:18 +0100 From: "Elwell, John" To: Martin.Thomson@andrew.com, "James M. Polk" , sipcore@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00218C372@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Use of term "Location Server" in location-conveyance draft Thread-Index: Acn7qLY49Op+mLx0SLmCjdJS7321fw== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [sipcore] Use of term "Location Server" in location-conveyance draft 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, 03 Jul 2009 06:46:19 -0000 The separate thread arising from my review of the draft has left me very confused about what exactly the term "Location Server" means in this draft. The draft itself says: " A [RFC3693] defined "Using=20 Protocol" describes how a "Location Server" transmits a "Location=20 Object" to a "Location Recipient" while maintaining the contained=20 privacy intentions of the Target intact. This document describes the extension to SIP for how it complies with the Using Protocol=20 requirements, where the location server is a UA or Proxy Server and=20 the Location Recipient is another UA or Proxy Server." My review comments that touched on this subject assumed the above definition. According to this, the server that the Location Recipient goes to to dereference the LbyR URI is NOT a Location Server. But some of the thread messages have suggested it IS a Location Server. We cannot use the term Location Server to mean two different things. Can somebody please clarify? John From jmpolk@cisco.com Sat Jul 4 13:22:31 2009 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 91D2D3A68B4 for ; Sat, 4 Jul 2009 13:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.292 X-Spam-Level: X-Spam-Status: No, score=-6.292 tagged_above=-999 required=5 tests=[AWL=0.307, 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 PXmIVHychGIG for ; Sat, 4 Jul 2009 13:22:29 -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 92D583A68A1 for ; Sat, 4 Jul 2009 13:22:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,349,1243814400"; d="scan'208";a="337557420" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 04 Jul 2009 20:22:54 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n64KMsYG031142; Sat, 4 Jul 2009 13:22:54 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n64KMs3S000165; Sat, 4 Jul 2009 20:22:54 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Jul 2009 13:22:53 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.73.134]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Jul 2009 13:22:53 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 04 Jul 2009 15:22:52 -0500 To: "Elwell, John" , sipcore@ietf.org From: "James M. Polk" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00218C370@GBNTHT12009MSX.gb 002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D00218BF88@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00218C331@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00218C370@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 04 Jul 2009 20:22:53.0786 (UTC) FILETIME=[35D87BA0:01C9FCE5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1250; t=1246738974; x=1247602974; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[sipcore]=20Review=20of=20=20=0A=20=20d raft-ietf-sipcore-location-conveyance-00=20sections=201=20to =203 |Sender:=20; bh=7PDK30IrKVTsJnbZK475CXKzj3a4hB2d9QvUjoU49G0=; b=KHiOgSQbNkf5ZDeeYsFmLI3dyzkR5Z/VhmdbtaxSJRlloCn84bhPtkw/i5 MzfP1PEyedaN2fVZaGTmbb8kKUJI+wrKdA6hi03bFsVwj43YrogfsGkwOqu/ j2FzacUu7kP2ndQJzbx4tGXwGxAHLQAR5QXDtxG1S9YgWtoDq1tEc=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Subject: Re: [sipcore] Review of draft-ietf-sipcore-location-conveyance-00 sections 1 to 3 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, 04 Jul 2009 20:22:31 -0000 At 01:22 AM 7/3/2009, Elwell, John wrote: > > > > >- " LbyR refers to a UA > > > > > including a location URI in a SIP request header field > > > > which can be > > > > > dereferenced by a Location Recipient to receive > > Alice's Location > > > > > Object, in the form of a PIDF-LO." > > > > >The header field is not dereferenced, it is the location > > URI that is > > > > >dereferenced. > > > > > > > > this is an artifact of the acronym "LbyR" being considered an > > > > archiecture by the Geopriv WG for about a year (some still feel it > > > > is), where I believe LbyR is just a location URI. This > > is an attempt > > > > to have the Geopriv folks understand that the Location > > URI, which is > > > > the Geolocation header value is used to dereference the > > > > Target's location. > > >[JRE] I agree, but my original complaint still holds, i.e., it is the > > >URI that is dereferenced, not the header field. > > > > I agree, and will make it clear by saying it's the header value that > > is used to make the dereference >[JRE] No, it is not the entire header field value (including its >parameters) - it is only the URI. Sorry, that's what I meant to say, but didn't. It is the URI. >John From jmpolk@cisco.com Sat Jul 4 14:26:06 2009 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 1D23E3A68B4 for ; Sat, 4 Jul 2009 14:26:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.297 X-Spam-Level: X-Spam-Status: No, score=-6.297 tagged_above=-999 required=5 tests=[AWL=0.302, 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 Z6zY0oEv2JGU for ; Sat, 4 Jul 2009 14:26:03 -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 CF4383A6A13 for ; Sat, 4 Jul 2009 14:26:02 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,349,1243814400"; d="scan'208";a="337573231" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 04 Jul 2009 21:18:31 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n64LIV5t012489; Sat, 4 Jul 2009 14:18:31 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n64LIV4p016615; Sat, 4 Jul 2009 21:18:31 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Jul 2009 14:18:30 -0700 Received: from jmpolk-wxp01.cisco.com ([10.21.73.134]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sat, 4 Jul 2009 14:18:30 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sat, 04 Jul 2009 16:18:29 -0500 To: "Thomson, Martin" , From: "James M. Polk" In-Reply-To: References: <0D5F89FAC29E2C41B98A6A762007F5D00218BF88@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 04 Jul 2009 21:18:30.0348 (UTC) FILETIME=[FA9770C0:01C9FCEC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=13818; t=1246742311; x=1247606311; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20draft-ietf-sipcore-location-conveyance- 00=20=3A=20identity=0A=20=20binding=20(was=3A=20something=20 else) |Sender:=20; bh=8ASFunJu4uARt15KOLy7XrwOsoow9sXhchB1HigUxd8=; b=FHTBHJLTfDYbCtGod4jTsZtGEXnXsvmATBShhv4bFMWuTS+3j9uwMpfZxz wK7uEBVD8jDIufmw9uOfSMHdegHtE4fF4b2qF6TVhqAlCzMZCznB3rph2vug gVksKB4Qty; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-00 : identity binding (was: something else) 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, 04 Jul 2009 21:26:06 -0000 At 01:14 AM 7/3/2009, Thomson, Martin wrote: >I can sympathize with your desire to keep everything within the >PIDF, but it's just not practical. That's the way presence it built, and I'm not going to try and change that model - not because of a single header value. >If this were a file transfer protocol, then I can see the sense in >being able to ship arbitrary PIDF documents around. I'm missing how shipping around message bodies isn't just like shipping files around...? Whether it be in an INVITE or a NOTIFY based on a subscription that was accepted. A PIDF is something that signaling cannot remain a part of (i.e., these are decomposed). >However, we're talking about attaching semantics to these documents >in the context of signalling. no, we really aren't. The information in the signaling doesn't have to be in the message body, and visa versa. For example, if Alice has Carol's PIDF-LO, and understands that Alice is allowed to retransmit that information and the retention timer hasn't expired, there is nothing in the RFC 4119 (or any update) that declares Alice cannot tell Bob where Carol is. How Bob determines who is identified within a or each document is by the "entity=" attribute within that document. >The Geolocation header makes a binding between the request and the document. no, the Geolocation header determines *where* the LO is (local in the SIP request, or remote via a dereferencable URI). The Geolocation header also says which SIP entity inserted each location value and whether or not that value can be used for routing. It doesn't bind an entity, for 1 reason, because is just isn't that easy to accomplish the equivalent of an unlinkable pseudonym - which is a requirement for PIDF-LOs based on the rules within RFC 3693. Anonymity is just hard in SIP, and not practiced very much (outside of gov agencies ;-) >That binding had better have some well-understood meaning or this all fails. It's the binding that's the problem for something that is meant to be decomposed. >If you want to pass around unrelated information, you're free to do >so without a Geolocation header. I do not agree with this on several counts. a presence document MUST NOT be forced to be linked to signaling, is the most important one. >There are two use cases that make what you propose very difficult >from a practical standpoint. One is a very real problem; the other >can be argued to be less so, but continues to plague us, so it's >probably still important. > >1) If we use your interpretation, then location URIs need to be >dereferenced before anyone can even be sure that they are relevant. Firstly, they shouldn't be if the "routing-allowed" is set to no, therefore these entities shouldn't be looking at location at all. Secondly, if a presence document's entity isn't understood, this is a security measure, and maybe the entity owner doesn't want you looking at it in the first place (and figuring out how it's about). >1b) Furthermore, your LS - especially if it is a LIS - might not use >the identity that you want. you define a LIS as a sender of LI (location Information), which has, by definition, no identity information -- so there's no "might" at all about identity from a LIS. A PIDF-LO has identity information, which is why we've gone to great lengths to make the information in it secure and private. >It probably can't. It is unlikely that a LIS is able to assert that >sips:alice@example.com was present at the given location and time. wow (said sarcastically) -- now you are seeing why I don't believe in OBO... seriously, a LIS, which you define as a LI provider via an LCP (location configuration protocol) such as DHCP or LLDP-MED cannot provide identity information, so no, it is the LI recipient - the UA - that attaches the identity information to the LI to form a LO (Location Object). A PIDF-LO is the one example that's standardized now for this. It contains an entity= attribute that the UA places it's identity information that is the *binder* of identity to the accompanying location information. I agree that putting unlinked pseudonyms in this attribute can cause problems, especially when a SIP request that contains a PIDF-LO wants to have that message routed based on the contained location. I am going to add text saying this scenario is to be avoided in the next rev (-01) of the doc. It isn't there now, and that's a mistake. >It's going to say that the entity that requested location >information at that time was at that location and give them a >name...an unlinked pseudonym. LI doesn't provide identity because LCPs do not provide identity. It's the identity of the UA that attaches identity (even unlinkable) to the LI when it forms an LO. >2) The other is digital signing and integrity. The binding between >location and identity is often made in a context that is unaware of >SIP identities. Therefore, a signed PIDF document might not include >an identity that is meaningful in the signalling context. But what's signed? It's the PIDF-LO *after* the entity= attribute is populated. It's the UA that chooses to bind it's identity (i.e., the currently registered user to that UA) to the presence document that happens to carry a location object. Remember, RFC 4119 created the LO in the existing PIDF, and the entity= attribute was already defined in every PIDF (and it's not optional BTW). >There's no reason that you can't assign meaning to the Geolocation >header that says: whomever inserted this header asserts that the UAC >is at the indicated location. The text has always said location can only be conveyed in a PIDF-LO (which is part of PIDF -- i.e., presence). In resolving the idea that servers can insert location just as UACs can, the text then included the inserter= indication is included by the entity that inserted *this* locationValue (i.e., location URI by-value or by-reference). The target identity has always had to be part of the presence document. The Location Generator (that's also a Location Server) creates the PIDF-LO. In that, is this entity= attribute that can be a linkable or unlinkable identity. >That doesn't necessarily imply that the entity identified in the >document is the same as the UAC, or vice versa, all it does is >provide a binding between identity in one context (the UAC) and >another (the Target of the PIDF). this means you want to through out the whole idea of unlinkable pseudonyms and their beneficial use, because that's what you are doing. In order for an unlinkable pseudonyms to still be useful in your usage - the SIP signaling will also have to be anonymous. Have you looked at how hard that is? Have you looked at how many header values contain linkage to the owner and/or owner's domain? Look at RFC 3323 and ask how many have implemented it... >(In your example, the semantic web folks would assert that a URI >tells you nothing, only the context where it appears gives you the >information necessary to put it into context. >Maybe Alice can tell Carol that the location she just received was >Bob's location; or it can identify Bob directly.) err, that's what I've been saying. The Alice to Carol SIP request that contains the PIDF that is associated with Bob will have to have an entity= attribute that says "this is Bob's document", likely by his AOR or Contact address. If Carol doesn't understand that entity= indicator, then the document is useless, just as an unlinkable pseudonym would be... >--Martin > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Friday, 3 July 2009 3:42 PM > > To: Thomson, Martin; Elwell, John; sipcore@ietf.org > > Subject: RE: [sipcore] Review of draft-ietf-sipcore-location- > > conveyance-00 sections 1 to 3 > > > > >... > > > > >Then again, the Target-UAC connection still isn't made. > > > > > > > > that has been going on in the background, offlist > > > > > >Please let me know what the outcome is. I'm sure we're all > > interested. > > > > actually - I said this below already, and verified this with Mr. > > Peterson this week. > > > > > > > > >Are we assuming this still? > > > > > > > > we can't. > > > > > >You'll have to justify that. I don't only think it's possible, I > > >think that it's necessary. > > > > > > > signaling is easily decomposed from a presence document. > > > > > >Sure, but when you remove the presence document it loses any meaning > > >it might have gained from being attached to the signalling. > > > > exactly, and what's the problem with this? a presence document is > > intended to be useful on its own, without signaling. > > > > > > > > the target is identified as the "entity=" attribute within the > > > > element. Check section 5 of conveyance (i.e., my LbyV > > > > example) to see. > > > > > >The Target is "identified" by the entity attribute, but there's no > > >guarantee that the recipient can make use of that identifier. > > > > exactly > > > > >An unlinked pseudonym wouldn't offer any clues. > > > > but at this point, this is the advantage. There is no identity > > information revealed to who doesn't know the pseudonym (which is the > > point, right?) > > > > If Alice doesn't use an unlinknable pseudonym, and uses something > > that is readable to her identity (like an AOR or contact address), > > the this presence document is linkable to her identity with or > > without signaling information. > > > > > > > > Therefore, the target identifier is found there, even if it is an > > > > unlinkable pseudonym to intermediary entities. If it is not > > > > understood by the location recipient, then it is ignored because it > > > > cannot attach identity to it. > > > > > >So you are saying that if the presence document contains an > > >identifier that cannot be linked to the UAC by a recipient, then > > >that document possibly refers to another entity. > > > > not exactly. > > > > I'm saying regardless of who signaled the document (for example, > > whether from Bob to Alice, or Alice to Carol), the entity= attribute > > identifies to who hte target is for this document without the > > signaling. If this is Bob's location, he is the target. If it can be > > linked to him, then both Alice and Carol know this is Bob's target > > location (no matter who sent it to Alice or Carol). If this is > > unlinkable, even if Bob sent it to Alice *and* Carol, neither know > > this is Bob's target location. They cannot assume this is Bob's > > location, because they can't verify the identity within the document > > (which is necessary). > > > > Furthering the Alice, Bob and Carol example, let's say Bob told Alice > > his location, and Alice passed this on to Carol, along with Alice's > > location. This is possible because the entity= attribute in both > > PIDF-LO documents that Carol received identify which location goes to > > which entity (Alice and Bob respectfully). This assumes that Bob set > > his retransmission-allowed to "yes" or true, and the retention-expiry > > hasn't elapsed. > > > > >A proxy performing location-based routing would ignore the request, > > >or regard location information as absent. > > > > yes > > > > this would necessitate a 424 (bad location) response, with a error > > code set to 100 (cannot process location). > > > > I would normally want to add a new error code specifically in the 1XX > > range indicating the problem specifically is (to the effect of) > > "received *a* location, but couldn't link this to your location to > > use for location based routing -- please provide your linkable > > identity and try again". However, a few of you want me to remove the > > error section entirely, so adding a new one doesn't make much sense, > > right? (***even though it would address THIS EXACT PROBLEM***)... > > > > > > > > > > >I offer a different possibility: that the location information > > >pertains to the entity that makes the request, regardless of the > > >identifier used within the document. > > > > that links the identity to the SIP request, even if the use doesn't > > want this link. That doesn't seem right. > > > > > > > > I will take your advice (based on reading RFC 4479) and delete - > > and > > > > not mention - the as this is providing too much > > > > information that might reveal a link to the target's identity. > > > > > >Thanks. > > > > no problem. > > > > > > >--Martin > > > > > >---------------------------------------------------------------------- > > -------------------------- > > >This message is for the designated recipient only and may > > >contain privileged, proprietary, or otherwise private information. > > >If you have received it in error, please notify the sender > > >immediately and delete the original. Any unauthorized use of > > >this email is prohibited. > > >---------------------------------------------------------------------- > > -------------------------- > > >[mf2] > > > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] From root@core3.amsl.com Sun Jul 5 06:45:01 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 8A4B83A6B9D; Sun, 5 Jul 2009 06:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090705134501.8A4B83A6B9D@core3.amsl.com> Date: Sun, 5 Jul 2009 06:45:01 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-info-events-00.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: Sun, 05 Jul 2009 13:45:01 -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 : Session Initiation Protocol (SIP) INFO Method and Package Framework Author(s) : E. Burger, et al. Filename : draft-ietf-sipcore-info-events-00.txt Pages : 38 Date : 2009-07-05 This document provides new semantics for the SIP INFO method of RFC 2976. These new semantics defined here are fully backwards compatible with the old semantics. Core to the new semantics is a mechanism for defining, negotiating and exchanging Info Packages that use the INFO method. Applications that need to exchange session- related information within a SIP INVITE-created session, also known as application level information, use these INFO requests. This draft addresses issues and open items from RFC 2976 and replaces it. Conventions Used in this Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. The terminology in this document conforms to the Internet Security Glossary [RFC4949]. Be aware this document strictly follows RFC 3261 [RFC3261] for the definition of the terms User Agent Server (UAS) and User Agent Client (UAC). Specifically, the UAC issues a SIP request and the UAS responds. This terminology may be confusing when one combines the INFO case with the INVITE case. For an INVITE, the initiator of the session is the UAC and the target of the session is the UAS. However, it is possible for the target UA of the session, the UAS of the INVITE transaction, to send an INFO to the initiating UA of the session, the UAC of the INVITE transaction. From the perspective of the INFO, the target UA of the session (INVITE UAS) is, in fact, the UAC (sender) of the INFO request. Likewise, from the perspective of the INFO, the initiating UA of the session (INVITE UAC) is the UAS (recipient) of the INFO request. Since this document strictly follows RFC 3261, we refer to the UA that issues the INVITE as the "initiating UA" and the UA that responds to the INVITE as the "target UA" to remove any confusion. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-info-events-00.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-info-events-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-05063049.I-D@ietf.org> --NextPart-- From Martin.Thomson@andrew.com Sun Jul 5 17:14:12 2009 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 797123A6C16 for ; Sun, 5 Jul 2009 17:14:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.563 X-Spam-Level: X-Spam-Status: No, score=-2.563 tagged_above=-999 required=5 tests=[AWL=0.036, 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 RaVW2W6X2cMi for ; Sun, 5 Jul 2009 17:14:11 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 9D23C3A6B62 for ; Sun, 5 Jul 2009 17:13:57 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_05_19_36_27 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Sun, 05 Jul 2009 19:36:27 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 5 Jul 2009 19:14:22 -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: Sun, 5 Jul 2009 19:14:19 -0500 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sipcore-location-conveyance-00 : identity binding (was: something else) Thread-Index: Acn87Px0x+EyYd9oTcSbCB7KQImflAA3+KHg References: <0D5F89FAC29E2C41B98A6A762007F5D00218BF88@GBNTHT12009MSX.gb002.siemens.net> From: "Thomson, Martin" To: "James M. Polk" , X-OriginalArrivalTime: 06 Jul 2009 00:14:22.0100 (UTC) FILETIME=[B656C540:01C9FDCE] Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-00 : identity binding (was: something else) 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, 06 Jul 2009 00:14:12 -0000 SmFtZXMsDQoNCklmIHRoZSBHZW9sb2NhdGlvbiBoZWFkZXIgaXNuJ3QgbGlua2luZyBQSURGIGRv Y3VtZW50cyBpbnRvIHNpZ25hbGxpbmcsIEknbSBhdCBhIGxvc3MgdG8gZXhwbGFpbiB3aHkgaXQg aXMgdGhlcmUgYXQgYWxsLg0KDQpJdCdzIGJlY29taW5nIG1vcmUgYW5kIG1vcmUgYXBwYXJlbnQg dGhhdCB5b3UgZG9uJ3QgdW5kZXJzdGFuZCBob3cgbG9jYXRpb24gYnkgcmVmZXJlbmNlIGlzIGRl cGxveWVkLiAgSSBiZWxpZXZlIHRoYXQgdGhpcyBzYXlzIGVub3VnaDoNCg0KPiA+SXQgcHJvYmFi bHkgY2FuJ3QuICBJdCBpcyB1bmxpa2VseSB0aGF0IGEgTElTIGlzIGFibGUgdG8gYXNzZXJ0IHRo YXQNCj4gPnNpcHM6YWxpY2VAZXhhbXBsZS5jb20gd2FzIHByZXNlbnQgYXQgdGhlIGdpdmVuIGxv Y2F0aW9uIGFuZCB0aW1lLg0KPiAJDQo+IHdvdyAoc2FpZCBzYXJjYXN0aWNhbGx5KSAtLSBub3cg eW91IGFyZSBzZWVpbmcgd2h5IEkgZG9uJ3QgYmVsaWV2ZSBpbg0KPiBPQk8uLi4NCg0KTm8gb25l IGJ1dCB5b3UgaGFzIGJyb3VnaHQgdXAgdGhhdCB0ZXJtLiAgSXQncyBub3QgZXZlbiByZWxldmFu dCB0byB0aGUgZGlzY3Vzc2lvbi4NCg0KLS1NYXJ0aW4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiBGcm9tOiBKYW1lcyBNLiBQb2xrIFttYWlsdG86am1wb2xrQGNpc2NvLmNvbV0N Cj4gU2VudDogU3VuZGF5LCA1IEp1bHkgMjAwOSA3OjE4IEFNDQo+IFRvOiBUaG9tc29uLCBNYXJ0 aW47IHNpcGNvcmVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IGRyYWZ0LWlldGYtc2lwY29yZS1s b2NhdGlvbi1jb252ZXlhbmNlLTAwIDogaWRlbnRpdHkNCj4gYmluZGluZyAod2FzOiBzb21ldGhp bmcgZWxzZSkNCj4gDQo+IEF0IDAxOjE0IEFNIDcvMy8yMDA5LCBUaG9tc29uLCBNYXJ0aW4gd3Jv dGU6DQo+ID5JIGNhbiBzeW1wYXRoaXplIHdpdGggeW91ciBkZXNpcmUgdG8ga2VlcCBldmVyeXRo aW5nIHdpdGhpbiB0aGUNCj4gPlBJREYsIGJ1dCBpdCdzIGp1c3Qgbm90IHByYWN0aWNhbC4NCj4g DQo+IFRoYXQncyB0aGUgd2F5IHByZXNlbmNlIGl0IGJ1aWx0LCBhbmQgSSdtIG5vdCBnb2luZyB0 byB0cnkgYW5kIGNoYW5nZQ0KPiB0aGF0IG1vZGVsIC0gbm90IGJlY2F1c2Ugb2YgYSBzaW5nbGUg aGVhZGVyIHZhbHVlLg0KPiANCj4gDQo+ID5JZiB0aGlzIHdlcmUgYSBmaWxlIHRyYW5zZmVyIHBy b3RvY29sLCB0aGVuIEkgY2FuIHNlZSB0aGUgc2Vuc2UgaW4NCj4gPmJlaW5nIGFibGUgdG8gc2hp cCBhcmJpdHJhcnkgUElERiBkb2N1bWVudHMgYXJvdW5kLg0KPiANCj4gSSdtIG1pc3NpbmcgaG93 IHNoaXBwaW5nIGFyb3VuZCBtZXNzYWdlIGJvZGllcyBpc24ndCBqdXN0IGxpa2UNCj4gc2hpcHBp bmcgZmlsZXMgYXJvdW5kLi4uPw0KPiANCj4gV2hldGhlciBpdCBiZSBpbiBhbiBJTlZJVEUgb3Ig YSBOT1RJRlkgYmFzZWQgb24gYSBzdWJzY3JpcHRpb24gdGhhdA0KPiB3YXMgYWNjZXB0ZWQuIEEg UElERiBpcyBzb21ldGhpbmcgdGhhdCBzaWduYWxpbmcgY2Fubm90IHJlbWFpbiBhIHBhcnQNCj4g b2YgKGkuZS4sIHRoZXNlIGFyZSBkZWNvbXBvc2VkKS4NCj4gDQo+ID5Ib3dldmVyLCB3ZSdyZSB0 YWxraW5nIGFib3V0IGF0dGFjaGluZyBzZW1hbnRpY3MgdG8gdGhlc2UgZG9jdW1lbnRzDQo+ID5p biB0aGUgY29udGV4dCBvZiBzaWduYWxsaW5nLg0KPiANCj4gbm8sIHdlIHJlYWxseSBhcmVuJ3Qu IFRoZSBpbmZvcm1hdGlvbiBpbiB0aGUgc2lnbmFsaW5nIGRvZXNuJ3QgaGF2ZQ0KPiB0byBiZSBp biB0aGUgbWVzc2FnZSBib2R5LCBhbmQgdmlzYSB2ZXJzYS4gRm9yIGV4YW1wbGUsIGlmIEFsaWNl IGhhcw0KPiBDYXJvbCdzIFBJREYtTE8sIGFuZCB1bmRlcnN0YW5kcyB0aGF0IEFsaWNlIGlzIGFs bG93ZWQgdG8gcmV0cmFuc21pdA0KPiB0aGF0IGluZm9ybWF0aW9uIGFuZCB0aGUgcmV0ZW50aW9u IHRpbWVyIGhhc24ndCBleHBpcmVkLCB0aGVyZSBpcw0KPiBub3RoaW5nIGluIHRoZSBSRkMgNDEx OSAob3IgYW55IHVwZGF0ZSkgdGhhdCBkZWNsYXJlcyBBbGljZSBjYW5ub3QNCj4gdGVsbCBCb2Ig d2hlcmUgQ2Fyb2wgaXMuIEhvdyBCb2IgZGV0ZXJtaW5lcyB3aG8gaXMgaWRlbnRpZmllZCB3aXRo aW4NCj4gYSBvciBlYWNoIGRvY3VtZW50IGlzIGJ5IHRoZSAiZW50aXR5PSIgYXR0cmlidXRlIHdp dGhpbiB0aGF0IGRvY3VtZW50Lg0KPiANCj4gPlRoZSBHZW9sb2NhdGlvbiBoZWFkZXIgbWFrZXMg YSBiaW5kaW5nIGJldHdlZW4gdGhlIHJlcXVlc3QgYW5kIHRoZQ0KPiBkb2N1bWVudC4NCj4gDQo+ IG5vLCB0aGUgR2VvbG9jYXRpb24gaGVhZGVyIGRldGVybWluZXMgKndoZXJlKiB0aGUgTE8gaXMg KGxvY2FsIGluIHRoZQ0KPiBTSVAgcmVxdWVzdCwgb3IgcmVtb3RlIHZpYSBhIGRlcmVmZXJlbmNh YmxlIFVSSSkuICBUaGUgR2VvbG9jYXRpb24NCj4gaGVhZGVyIGFsc28gc2F5cyB3aGljaCBTSVAg ZW50aXR5IGluc2VydGVkIGVhY2ggbG9jYXRpb24gdmFsdWUgYW5kDQo+IHdoZXRoZXIgb3Igbm90 IHRoYXQgdmFsdWUgY2FuIGJlIHVzZWQgZm9yIHJvdXRpbmcuIEl0IGRvZXNuJ3QNCj4gYmluZCAg YW4gZW50aXR5LCBmb3IgMSByZWFzb24sIGJlY2F1c2UgaXMganVzdCBpc24ndCB0aGF0IGVhc3kg dG8NCj4gYWNjb21wbGlzaCB0aGUgZXF1aXZhbGVudCBvZiBhbiB1bmxpbmthYmxlIHBzZXVkb255 bSAtIHdoaWNoIGlzIGENCj4gcmVxdWlyZW1lbnQgZm9yIFBJREYtTE9zIGJhc2VkIG9uIHRoZSBy dWxlcyB3aXRoaW4gUkZDIDM2OTMuDQo+IEFub255bWl0eSBpcyBqdXN0IGhhcmQgaW4gU0lQLCBh bmQgbm90IHByYWN0aWNlZCB2ZXJ5IG11Y2ggKG91dHNpZGUNCj4gb2YgZ292IGFnZW5jaWVzICA7 LSkNCj4gDQo+ID5UaGF0IGJpbmRpbmcgaGFkIGJldHRlciBoYXZlIHNvbWUgd2VsbC11bmRlcnN0 b29kIG1lYW5pbmcgb3IgdGhpcyBhbGwNCj4gZmFpbHMuDQo+IA0KPiBJdCdzIHRoZSBiaW5kaW5n IHRoYXQncyB0aGUgcHJvYmxlbSBmb3Igc29tZXRoaW5nIHRoYXQgaXMgbWVhbnQgdG8gYmUNCj4g ZGVjb21wb3NlZC4NCj4gDQo+IA0KPiA+SWYgeW91IHdhbnQgdG8gcGFzcyBhcm91bmQgdW5yZWxh dGVkIGluZm9ybWF0aW9uLCB5b3UncmUgZnJlZSB0byBkbw0KPiA+c28gd2l0aG91dCBhIEdlb2xv Y2F0aW9uIGhlYWRlci4NCj4gDQo+IEkgZG8gbm90IGFncmVlIHdpdGggdGhpcyBvbiBzZXZlcmFs IGNvdW50cy4gIGEgcHJlc2VuY2UgZG9jdW1lbnQgTVVTVA0KPiBOT1QgYmUgZm9yY2VkIHRvIGJl IGxpbmtlZCB0byBzaWduYWxpbmcsIGlzIHRoZSBtb3N0IGltcG9ydGFudCBvbmUuDQo+IA0KPiAN Cj4gPlRoZXJlIGFyZSB0d28gdXNlIGNhc2VzIHRoYXQgbWFrZSB3aGF0IHlvdSBwcm9wb3NlIHZl cnkgZGlmZmljdWx0DQo+ID5mcm9tIGEgcHJhY3RpY2FsIHN0YW5kcG9pbnQuICBPbmUgaXMgYSB2 ZXJ5IHJlYWwgcHJvYmxlbTsgdGhlIG90aGVyDQo+ID5jYW4gYmUgYXJndWVkIHRvIGJlIGxlc3Mg c28sIGJ1dCBjb250aW51ZXMgdG8gcGxhZ3VlIHVzLCBzbyBpdCdzDQo+ID5wcm9iYWJseSBzdGls bCBpbXBvcnRhbnQuDQo+ID4NCj4gPjEpIElmIHdlIHVzZSB5b3VyIGludGVycHJldGF0aW9uLCB0 aGVuIGxvY2F0aW9uIFVSSXMgbmVlZCB0byBiZQ0KPiA+ZGVyZWZlcmVuY2VkIGJlZm9yZSBhbnlv bmUgY2FuIGV2ZW4gYmUgc3VyZSB0aGF0IHRoZXkgYXJlIHJlbGV2YW50Lg0KPiANCj4gRmlyc3Rs eSwgdGhleSBzaG91bGRuJ3QgYmUgaWYgdGhlICJyb3V0aW5nLWFsbG93ZWQiIGlzIHNldCB0byBu bywNCj4gdGhlcmVmb3JlIHRoZXNlIGVudGl0aWVzIHNob3VsZG4ndCBiZSBsb29raW5nIGF0IGxv Y2F0aW9uIGF0IGFsbC4NCj4gDQo+IFNlY29uZGx5LCBpZiBhIHByZXNlbmNlIGRvY3VtZW50J3Mg ZW50aXR5IGlzbid0IHVuZGVyc3Rvb2QsIHRoaXMgaXMgYQ0KPiBzZWN1cml0eSBtZWFzdXJlLCBh bmQgbWF5YmUgdGhlIGVudGl0eSBvd25lciBkb2Vzbid0IHdhbnQgeW91IGxvb2tpbmcNCj4gYXQg aXQgaW4gdGhlIGZpcnN0IHBsYWNlIChhbmQgZmlndXJpbmcgb3V0IGhvdyBpdCdzIGFib3V0KS4N Cj4gDQo+IA0KPiA+MWIpIEZ1cnRoZXJtb3JlLCB5b3VyIExTIC0gZXNwZWNpYWxseSBpZiBpdCBp cyBhIExJUyAtIG1pZ2h0IG5vdCB1c2UNCj4gPnRoZSBpZGVudGl0eSB0aGF0IHlvdSB3YW50Lg0K PiANCj4geW91IGRlZmluZSBhIExJUyBhcyBhIHNlbmRlciBvZiBMSSAobG9jYXRpb24gSW5mb3Jt YXRpb24pLCB3aGljaCBoYXMsDQo+IGJ5IGRlZmluaXRpb24sIG5vIGlkZW50aXR5IGluZm9ybWF0 aW9uIC0tIHNvIHRoZXJlJ3Mgbm8gIm1pZ2h0IiBhdA0KPiBhbGwgYWJvdXQgaWRlbnRpdHkgZnJv bSBhIExJUy4gQSBQSURGLUxPIGhhcyBpZGVudGl0eSBpbmZvcm1hdGlvbiwNCj4gd2hpY2ggaXMg d2h5IHdlJ3ZlIGdvbmUgdG8gZ3JlYXQgbGVuZ3RocyB0byBtYWtlIHRoZSBpbmZvcm1hdGlvbiBp bg0KPiBpdCBzZWN1cmUgYW5kIHByaXZhdGUuDQo+IA0KPiA+SXQgcHJvYmFibHkgY2FuJ3QuICBJ dCBpcyB1bmxpa2VseSB0aGF0IGEgTElTIGlzIGFibGUgdG8gYXNzZXJ0IHRoYXQNCj4gPnNpcHM6 YWxpY2VAZXhhbXBsZS5jb20gd2FzIHByZXNlbnQgYXQgdGhlIGdpdmVuIGxvY2F0aW9uIGFuZCB0 aW1lLg0KPiAJDQo+IHdvdyAoc2FpZCBzYXJjYXN0aWNhbGx5KSAtLSBub3cgeW91IGFyZSBzZWVp bmcgd2h5IEkgZG9uJ3QgYmVsaWV2ZSBpbg0KPiBPQk8uLi4NCj4gDQo+IHNlcmlvdXNseSwgYSBM SVMsIHdoaWNoIHlvdSBkZWZpbmUgYXMgYSBMSSBwcm92aWRlciB2aWEgYW4gTENQDQo+IChsb2Nh dGlvbiBjb25maWd1cmF0aW9uIHByb3RvY29sKSBzdWNoIGFzIERIQ1Agb3IgTExEUC1NRUQgY2Fu bm90DQo+IHByb3ZpZGUgaWRlbnRpdHkgaW5mb3JtYXRpb24sIHNvIG5vLCBpdCBpcyB0aGUgTEkg cmVjaXBpZW50IC0gdGhlIFVBDQo+IC0gdGhhdCBhdHRhY2hlcyB0aGUgaWRlbnRpdHkgaW5mb3Jt YXRpb24gdG8gdGhlIExJIHRvIGZvcm0gYSBMTw0KPiAoTG9jYXRpb24gT2JqZWN0KS4gQSBQSURG LUxPIGlzIHRoZSBvbmUgZXhhbXBsZSB0aGF0J3Mgc3RhbmRhcmRpemVkDQo+IG5vdyBmb3IgdGhp cy4gSXQgY29udGFpbnMgYW4gZW50aXR5PSBhdHRyaWJ1dGUgdGhhdCB0aGUgVUEgcGxhY2VzDQo+ IGl0J3MgaWRlbnRpdHkgaW5mb3JtYXRpb24gdGhhdCBpcyB0aGUgKmJpbmRlciogb2YgaWRlbnRp dHkgdG8gdGhlDQo+IGFjY29tcGFueWluZyBsb2NhdGlvbiBpbmZvcm1hdGlvbi4NCj4gDQo+IEkg YWdyZWUgdGhhdCBwdXR0aW5nIHVubGlua2VkIHBzZXVkb255bXMgaW4gdGhpcyBhdHRyaWJ1dGUg Y2FuIGNhdXNlDQo+IHByb2JsZW1zLCBlc3BlY2lhbGx5IHdoZW4gYSBTSVAgcmVxdWVzdCB0aGF0 IGNvbnRhaW5zIGEgUElERi1MTyB3YW50cw0KPiB0byBoYXZlIHRoYXQgbWVzc2FnZSByb3V0ZWQg YmFzZWQgb24gdGhlIGNvbnRhaW5lZCBsb2NhdGlvbi4gSSBhbQ0KPiBnb2luZyB0byBhZGQgdGV4 dCBzYXlpbmcgdGhpcyBzY2VuYXJpbyBpcyB0byBiZSBhdm9pZGVkIGluIHRoZSBuZXh0DQo+IHJl diAoLTAxKSBvZiB0aGUgZG9jLiBJdCBpc24ndCB0aGVyZSBub3csIGFuZCB0aGF0J3MgYSBtaXN0 YWtlLg0KPiANCj4gPkl0J3MgZ29pbmcgdG8gc2F5IHRoYXQgdGhlIGVudGl0eSB0aGF0IHJlcXVl c3RlZCBsb2NhdGlvbg0KPiA+aW5mb3JtYXRpb24gYXQgdGhhdCB0aW1lIHdhcyBhdCB0aGF0IGxv Y2F0aW9uIGFuZCBnaXZlIHRoZW0gYQ0KPiA+bmFtZS4uLmFuIHVubGlua2VkIHBzZXVkb255bS4N Cj4gDQo+IExJIGRvZXNuJ3QgcHJvdmlkZSBpZGVudGl0eSBiZWNhdXNlIExDUHMgZG8gbm90IHBy b3ZpZGUNCj4gaWRlbnRpdHkuICBJdCdzIHRoZSBpZGVudGl0eSBvZiB0aGUgVUEgdGhhdCBhdHRh Y2hlcyBpZGVudGl0eSAoZXZlbg0KPiB1bmxpbmthYmxlKSB0byB0aGUgTEkgd2hlbiBpdCBmb3Jt cyBhbiBMTy4NCj4gDQo+IA0KPiA+MikgVGhlIG90aGVyIGlzIGRpZ2l0YWwgc2lnbmluZyBhbmQg aW50ZWdyaXR5LiAgVGhlIGJpbmRpbmcgYmV0d2Vlbg0KPiA+bG9jYXRpb24gYW5kIGlkZW50aXR5 IGlzIG9mdGVuIG1hZGUgaW4gYSBjb250ZXh0IHRoYXQgaXMgdW5hd2FyZSBvZg0KPiA+U0lQIGlk ZW50aXRpZXMuICBUaGVyZWZvcmUsIGEgc2lnbmVkIFBJREYgZG9jdW1lbnQgbWlnaHQgbm90IGlu Y2x1ZGUNCj4gPmFuIGlkZW50aXR5IHRoYXQgaXMgbWVhbmluZ2Z1bCBpbiB0aGUgc2lnbmFsbGlu ZyBjb250ZXh0Lg0KPiANCj4gQnV0IHdoYXQncyBzaWduZWQ/IEl0J3MgdGhlIFBJREYtTE8gKmFm dGVyKiB0aGUgZW50aXR5PSBhdHRyaWJ1dGUgaXMNCj4gcG9wdWxhdGVkLiBJdCdzIHRoZSBVQSB0 aGF0IGNob29zZXMgdG8gYmluZCBpdCdzIGlkZW50aXR5IChpLmUuLCB0aGUNCj4gY3VycmVudGx5 IHJlZ2lzdGVyZWQgdXNlciB0byB0aGF0IFVBKSB0byB0aGUgcHJlc2VuY2UgZG9jdW1lbnQgdGhh dA0KPiBoYXBwZW5zIHRvIGNhcnJ5IGEgbG9jYXRpb24gb2JqZWN0LiAgUmVtZW1iZXIsIFJGQyA0 MTE5IGNyZWF0ZWQgdGhlDQo+IExPIGluIHRoZSBleGlzdGluZyBQSURGLCBhbmQgdGhlIGVudGl0 eT0gYXR0cmlidXRlIHdhcyBhbHJlYWR5DQo+IGRlZmluZWQgaW4gZXZlcnkgUElERiAoYW5kIGl0 J3Mgbm90IG9wdGlvbmFsIEJUVykuDQo+IA0KPiANCj4gPlRoZXJlJ3Mgbm8gcmVhc29uIHRoYXQg eW91IGNhbid0IGFzc2lnbiBtZWFuaW5nIHRvIHRoZSBHZW9sb2NhdGlvbg0KPiA+aGVhZGVyIHRo YXQgc2F5czogd2hvbWV2ZXIgaW5zZXJ0ZWQgdGhpcyBoZWFkZXIgYXNzZXJ0cyB0aGF0IHRoZSBV QUMNCj4gPmlzIGF0IHRoZSBpbmRpY2F0ZWQgbG9jYXRpb24uDQo+IA0KPiBUaGUgdGV4dCBoYXMg YWx3YXlzIHNhaWQgbG9jYXRpb24gY2FuIG9ubHkgYmUgY29udmV5ZWQgaW4gYSBQSURGLUxPDQo+ ICh3aGljaCBpcyBwYXJ0IG9mIFBJREYgLS0gaS5lLiwgcHJlc2VuY2UpLiBJbiByZXNvbHZpbmcg dGhlIGlkZWEgdGhhdA0KPiBzZXJ2ZXJzIGNhbiBpbnNlcnQgbG9jYXRpb24ganVzdCBhcyBVQUNz IGNhbiwgdGhlIHRleHQgdGhlbiBpbmNsdWRlZA0KPiB0aGUgaW5zZXJ0ZXI9IGluZGljYXRpb24g aXMgaW5jbHVkZWQgYnkgdGhlIGVudGl0eSB0aGF0IGluc2VydGVkDQo+ICp0aGlzKiBsb2NhdGlv blZhbHVlIChpLmUuLCBsb2NhdGlvbiBVUkkgYnktdmFsdWUgb3IgYnktcmVmZXJlbmNlKS4NCj4g DQo+IFRoZSB0YXJnZXQgaWRlbnRpdHkgaGFzIGFsd2F5cyBoYWQgdG8gYmUgcGFydCBvZiB0aGUg cHJlc2VuY2UNCj4gZG9jdW1lbnQuIFRoZSBMb2NhdGlvbiBHZW5lcmF0b3IgKHRoYXQncyBhbHNv IGEgTG9jYXRpb24gU2VydmVyKQ0KPiBjcmVhdGVzIHRoZSBQSURGLUxPLiBJbiB0aGF0LCBpcyB0 aGlzIGVudGl0eT0gYXR0cmlidXRlIHRoYXQgY2FuIGJlIGENCj4gbGlua2FibGUgb3IgdW5saW5r YWJsZSBpZGVudGl0eS4NCj4gDQo+ID5UaGF0IGRvZXNuJ3QgbmVjZXNzYXJpbHkgaW1wbHkgdGhh dCB0aGUgZW50aXR5IGlkZW50aWZpZWQgaW4gdGhlDQo+ID5kb2N1bWVudCBpcyB0aGUgc2FtZSBh cyB0aGUgVUFDLCBvciB2aWNlIHZlcnNhLCBhbGwgaXQgZG9lcyBpcw0KPiA+cHJvdmlkZSBhIGJp bmRpbmcgYmV0d2VlbiBpZGVudGl0eSBpbiBvbmUgY29udGV4dCAodGhlIFVBQykgYW5kDQo+ID5h bm90aGVyICh0aGUgVGFyZ2V0IG9mIHRoZSBQSURGKS4NCj4gDQo+IHRoaXMgbWVhbnMgeW91IHdh bnQgdG8gdGhyb3VnaCBvdXQgdGhlIHdob2xlIGlkZWEgb2YgdW5saW5rYWJsZQ0KPiBwc2V1ZG9u eW1zIGFuZCB0aGVpciBiZW5lZmljaWFsIHVzZSwgYmVjYXVzZSB0aGF0J3Mgd2hhdCB5b3UgYXJl DQo+IGRvaW5nLiBJbiBvcmRlciBmb3IgYW4gdW5saW5rYWJsZSBwc2V1ZG9ueW1zIHRvIHN0aWxs IGJlIHVzZWZ1bCBpbg0KPiB5b3VyIHVzYWdlIC0gdGhlIFNJUCBzaWduYWxpbmcgd2lsbCBhbHNv IGhhdmUgdG8gYmUgYW5vbnltb3VzLiAgSGF2ZQ0KPiB5b3UgbG9va2VkIGF0IGhvdyBoYXJkIHRo YXQgaXM/IEhhdmUgeW91IGxvb2tlZCBhdCBob3cgbWFueSBoZWFkZXINCj4gdmFsdWVzIGNvbnRh aW4gbGlua2FnZSB0byB0aGUgb3duZXIgYW5kL29yIG93bmVyJ3MgZG9tYWluPyBMb29rIGF0DQo+ IFJGQyAzMzIzIGFuZCBhc2sgaG93IG1hbnkgaGF2ZSBpbXBsZW1lbnRlZCBpdC4uLg0KPiANCj4g DQo+ID4oSW4geW91ciBleGFtcGxlLCB0aGUgc2VtYW50aWMgd2ViIGZvbGtzIHdvdWxkIGFzc2Vy dCB0aGF0IGEgVVJJDQo+ID50ZWxscyB5b3Ugbm90aGluZywgb25seSB0aGUgY29udGV4dCB3aGVy ZSBpdCBhcHBlYXJzIGdpdmVzIHlvdSB0aGUNCj4gPmluZm9ybWF0aW9uIG5lY2Vzc2FyeSB0byBw dXQgaXQgaW50byBjb250ZXh0Lg0KPiANCj4gPk1heWJlIEFsaWNlIGNhbiB0ZWxsIENhcm9sIHRo YXQgdGhlIGxvY2F0aW9uIHNoZSBqdXN0IHJlY2VpdmVkIHdhcw0KPiA+Qm9iJ3MgbG9jYXRpb247 IG9yIGl0IGNhbiBpZGVudGlmeSBCb2IgZGlyZWN0bHkuKQ0KPiANCj4gZXJyLCB0aGF0J3Mgd2hh dCBJJ3ZlIGJlZW4gc2F5aW5nLiBUaGUgQWxpY2UgdG8gQ2Fyb2wgU0lQIHJlcXVlc3QNCj4gdGhh dCBjb250YWlucyB0aGUgUElERiB0aGF0IGlzIGFzc29jaWF0ZWQgd2l0aCBCb2Igd2lsbCBoYXZl IHRvIGhhdmUNCj4gYW4gZW50aXR5PSBhdHRyaWJ1dGUgdGhhdCBzYXlzICJ0aGlzIGlzIEJvYidz IGRvY3VtZW50IiwgbGlrZWx5IGJ5DQo+IGhpcyBBT1Igb3IgQ29udGFjdCBhZGRyZXNzLiBJZiBD YXJvbCBkb2Vzbid0IHVuZGVyc3RhbmQgdGhhdCBlbnRpdHk9DQo+IGluZGljYXRvciwgdGhlbiB0 aGUgZG9jdW1lbnQgaXMgdXNlbGVzcywganVzdCBhcyBhbiB1bmxpbmthYmxlDQo+IHBzZXVkb255 bSB3b3VsZCBiZS4uLg0KPiANCj4gDQo+ID4tLU1hcnRpbg0KPiA+DQotLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMgbWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0 ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFy eSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uICANCklmIHlvdSBoYXZlIHJlY2Vp dmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFu ZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1h aWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LQ0KW21mMl0NCg== From gonzalo.camarillo@ericsson.com Sun Jul 5 23:26:18 2009 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 517143A6C0C for ; Sun, 5 Jul 2009 23:26:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.205 X-Spam-Level: X-Spam-Status: No, score=-6.205 tagged_above=-999 required=5 tests=[AWL=0.044, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 nAudTJ+UBNV3 for ; Sun, 5 Jul 2009 23:26:17 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id CD4FC3A6B3A for ; Sun, 5 Jul 2009 23:26:16 -0700 (PDT) X-AuditID: c1b4fb3c-b7c04ae0000036a1-b1-4a519920c4ff Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 64.0E.13985.029915A4; Mon, 6 Jul 2009 08:26:40 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jul 2009 08:26:35 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jul 2009 08:26:35 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 72B7423F6; Mon, 6 Jul 2009 09:26:35 +0300 (EEST) Message-ID: <4A51991B.90407@ericsson.com> Date: Mon, 06 Jul 2009 09:26:35 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "Elwell, John" References: <4A43115C.7040902@ericsson.com> <0D5F89FAC29E2C41B98A6A762007F5D0021058FB@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0021058FB@GBNTHT12009MSX.gb002.siemens.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2009 06:26:35.0394 (UTC) FILETIME=[B604FE20:01C9FE02] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Input requested on how to proceed with the essential corrections to RFC 3261 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, 06 Jul 2009 06:26:18 -0000 Hi John, > By the way, I noticed the absence of sip-sips from the list of drafts > updating RFC 3261. Arguably that could also be considered an "essential > correction", but I certainly think it should remain in its own document. I did not include it on the list because it is already in the RFC Editor's queue: https://datatracker.ietf.org/idtracker/draft-ietf-sip-sips/ Cheers, Gonzalo From gonzalo.camarillo@ericsson.com Mon Jul 6 08:44:51 2009 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 AF6A23A6D0F for ; Mon, 6 Jul 2009 08:44:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.182 X-Spam-Level: X-Spam-Status: No, score=-6.182 tagged_above=-999 required=5 tests=[AWL=0.067, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 J+ATz1CKXWJT for ; Mon, 6 Jul 2009 08:44:51 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id B043A3A6B7F for ; Mon, 6 Jul 2009 08:44:50 -0700 (PDT) X-AuditID: c1b4fb3c-b7c04ae0000036a1-77-4a52019c4713 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 45.B6.13985.C91025A4; Mon, 6 Jul 2009 15:52:29 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jul 2009 15:52:28 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 6 Jul 2009 15:52:27 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id CA58C23F6; Mon, 6 Jul 2009 16:52:27 +0300 (EEST) Message-ID: <4A52019B.4030600@ericsson.com> Date: Mon, 06 Jul 2009 16:52:27 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2009 13:52:28.0009 (UTC) FILETIME=[FFD21590:01C9FE40] X-Brightmail-Tracker: AAAAAA== Cc: gao.yang2@zte.com.cn Subject: [sipcore] New revision of the re-INVITE handling draft 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, 06 Jul 2009 15:44:51 -0000 Folks, [as individual] I have just submitted a new revision of the re-INVITE handling draft. The last revision of this draft was presented and widely discussed in the SIPPING WG: http://www.ietf.org/internet-drafts/draft-camarillo-sipcore-reinvite-00.txt This draft documents the agreement among folks involved in the (endless) "rollback" discussions. Comments are welcome. Thanks, Gonzalo From pkyzivat@cisco.com Mon Jul 6 16:37:30 2009 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 D6CB028C44B for ; Mon, 6 Jul 2009 16:37:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.59 X-Spam-Level: X-Spam-Status: No, score=-6.59 tagged_above=-999 required=5 tests=[AWL=0.009, 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 WkXUk8Phqh6h for ; Mon, 6 Jul 2009 16:37:29 -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 0FEC828C410 for ; Mon, 6 Jul 2009 16:37:29 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,359,1243814400"; d="scan'208";a="338698713" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 06 Jul 2009 23:37:24 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n66NbOaf023144; Mon, 6 Jul 2009 16:37:24 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n66NbOuo003556; Mon, 6 Jul 2009 23:37:24 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 19:37:24 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 6 Jul 2009 19:37:23 -0400 Message-ID: <4A528AB2.7020206@cisco.com> Date: Mon, 06 Jul 2009 19:37:22 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4A52019B.4030600@ericsson.com> In-Reply-To: <4A52019B.4030600@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 06 Jul 2009 23:37:23.0604 (UTC) FILETIME=[B66CE540:01C9FE92] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5455; t=1246923444; x=1247787444; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20New=20revision=20of=20the=2 0re-INVITE=20handling=20draft |Sender:=20; bh=Oo79UqG+gh3FV9FdrvMj40QbZ6giyHNPH/EaGXWd5JI=; b=L1qkJ4uCxTfG68+jVXtw21viI+4l0R4FcJF2tVPCbon1hx4a6pKFK/BqjL x/bGfU8v682vU54BBM9hFO20sSG6qTHjqIiyFaZ85NfgAmFffPGzfswvPqTR JILw+s2a08ZSa7WxDU2kAGaE3O7jjxKSJRc9y+n2JjmvatBs6xusA=; Authentication-Results: sj-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 06 Jul 2009 23:37:30 -0000 Gonzalo, Thanks for doing this work! I do have some comments: Section 3/Figure 1 The figure shows a 6xx response. The text says that the UAS wants to reject the new offer. A UAS would probably not use a 6xx response to reject media. (I guess it might use 606, but 488 would be more appropriate.) In fact, it probably would not reject the request at all, but rather would just refuse the added media stream. The point being made doesn't require that the response be 6xx or that it be with the purpose of refusing the media. So I think what is needed here is to find a plausible example to make the point. A good one for the purpose here might be a 488 to reject the media, or a 401 response as another sort of reason for rejecting the whole thing but wanting to preserve what there is. Section 5: > A change to the session state is considered to have been executed > when the new media parameters are being used. Therefore, a change to > a stream subject to preconditions [RFC4032] is considered to have > been executed when the new media parameters start being used; not > when the preconditions for the stream are met. Unsurprisingly, the > UAS considers the new parameters to be in use when it actually starts > using them. I'm not entirely following this. I think there may be an assumption here that the UAC is the offerer and the UAS the answerer. I'm guessing you are saying that the answerer considers the new parameters to be in use when it actually starts using them. Since this section is about the UAS (for the reinvite), this point is probably that when the UAS is also the answerer it can decide when the new media is in use based on when it starts using them. But what happens when the UAS is the offerer? In that case I think it must assume the media is in use as soon as it is offered. But maybe that isn't always the case with preconditions. I don't think it can wait till it receives media, because media may be in flight when it makes its decision. > As described in Section 8.3.1 of RFC 3264 [RFC3264], the > UAC considers the new parameters to be in use when media is received > in the new port, which should be interpreted as follows: > > Received, in this case, means that the media is passed to a media > sink. This means that if there is a playout buffer, the agent > would continue to listen on the old port until the media on the > new port reached the top of the playout buffer. At that time, it > MAY cease listening for media on the old port. I don't know what the above has to do with the behavior of the UAS. > 9. Clarifications on Target Refresh Requests > > On receiving a target refresh request with an updated remote target, > a UAS updates the remote target of the dialog immediately. This > update represents the execution of a state change. Therefore, > following the rules in Section 5, UASs always return 2xx responses to > target refresh requests that update the remote target. This does not address cases where the UAS cannot accept the change with a 200. Some cases that fall into this category are: - request includes a Require of an unsupported option (e.g. 100rel) - request cannot be authorized - server overload - precondition failure In any case, if no state changes have been made prior to the request with a target change, then there is no issue with rejecting the target refresh if need be. The issue with target refresh is that the UA sending it may have an urgent need for it to be accepted, since it may not be able to communicate on its old address(es) any longer. And if that is the case it may also have an urgent need to change its media addresses as well for the same reason. That would be motivation for doing both at once. If a reINVITE includes a target change, then its very difficult to know when the UAC must begin using it. So I think the UAS must assume it must be considered in use immediately. Hence it should *try* to avoid rejecting the request, even if it must reject all the media in the request. But there is still a possibility that it will have to reject due to authorization, overload, etc. If that is done right away its no different than any request rejected before any changes have been made. A difficult case is where a reINVITE has been initiated, and has not completed. (Perhaps its ringing.) Then the UAC loses its IP address or IP connectivity and needs to make a target change. So it sends an UPDATE with the target change. What it should probably do in that case is *not* include an offer in the UPDATE. Then it can't be rejected for o/a reasons. Once that is done it can continue the o/a process, updating its media addresses when it has the chance. Once the UAC target has changed, the UAS should not fail the INVITE. If need be it should reject all the media in order to avoid that. Another difficult case if if a reINVITE has been initiated and the UAS finds it needs to change its address. Similar considerations to above seem to apply. Frankly, this is all very nasty, and those in this situation may have few options for what do do. It feels deserving of its own treatment. Namely a whole call flow document with various use cases where target change is required. Probably a BCP. Thanks, Paul From gao.yang2@zte.com.cn Tue Jul 7 03:52:06 2009 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 A81713A6E48 for ; Tue, 7 Jul 2009 03:52:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.237 X-Spam-Level: X-Spam-Status: No, score=-94.237 tagged_above=-999 required=5 tests=[AWL=-2.646, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, J_CHICKENPOX_62=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 UmncljaCamrb for ; Tue, 7 Jul 2009 03:52:04 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 247C128C38A for ; Tue, 7 Jul 2009 03:52:01 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 91101727820181; Tue, 7 Jul 2009 18:39:28 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.99] with StormMail ESMTP id 89631.6637927919; Tue, 7 Jul 2009 18:44:40 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n67Aq5Ic099623; Tue, 7 Jul 2009 18:52:05 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 7 Jul 2009 18:51:46 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-07 18:51:49, Serialize complete at 2009-07-07 18:51:49 Content-Type: multipart/alternative; boundary="=_alternative 003BACA6482575EC_=" X-MAIL: mse1.zte.com.cn n67Aq5Ic099623 Cc: SIPCORE Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ICBOZXcgcmV2aXNpb24gb2YgdGhlIHJl?= =?gb2312?b?LUlOVklURSBoYW5kbGluZyBkcmFmdA==?= 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, 07 Jul 2009 10:52:06 -0000 This is a multipart message in MIME format. --=_alternative 003BACA6482575EC_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGmjrA0KDQpQbGVhc2Ugc2VlIGlubGluZXMuDQoNClRoYW5rcy4NCg0KR2FvDQoNCk9LVU1VUkEg U2hpbmppIDxzaGluQHNvZnRmcm9udC5jby5qcD4g0LTT2iAyMDA5LTA3LTA3IDE4OjE1OjA4Og0K DQo+IEhpLA0KPiANCj4gSSBoYXZlIHNvbWUgY29tbWVudHMuDQo+IA0KPiBSRkMzMjYxIGRlc2Ny aWJlIGFib3V0IHRoZSBhdG9taWMgcHJvY2Vzcy4NCj4gDQo+IDggR2VuZXJhbCBVc2VyIEFnZW50 IEJlaGF2aW9yDQo+ICA4LjIgVUFTIEJlaGF2aW9yDQo+ICAgIE5vdGUgdGhhdCByZXF1ZXN0IHBy b2Nlc3NpbmcgaXMgYXRvbWljLiAgSWYgYSByZXF1ZXN0IGlzIGFjY2VwdGVkLA0KPiAgICBhbGwg c3RhdGUgY2hhbmdlcyBhc3NvY2lhdGVkIHdpdGggaXQgTVVTVCBiZSBwZXJmb3JtZWQuICBJZiBp dCBpcw0KPiAgICByZWplY3RlZCwgYWxsIHN0YXRlIGNoYW5nZXMgTVVTVCBOT1QgYmUgcGVyZm9y bWVkLg0KPiANCj4gMTIgRGlhbG9ncw0KPiAgMTIuMiBSZXF1ZXN0cyB3aXRoaW4gYSBEaWFsb2cN Cj4gIDEyLjIuMiBVQVMgQmVoYXZpb3INCj4gICAgUmVxdWVzdHMgc2VudCB3aXRoaW4gYSBkaWFs b2csIGFzIGFueSBvdGhlciByZXF1ZXN0cywgYXJlIGF0b21pYy4gIElmDQo+ICAgIGEgcGFydGlj dWxhciByZXF1ZXN0IGlzIGFjY2VwdGVkIGJ5IHRoZSBVQVMsIGFsbCB0aGUgc3RhdGUgY2hhbmdl cw0KPiAgICBhc3NvY2lhdGVkIHdpdGggaXQgYXJlIHBlcmZvcm1lZC4gIElmIHRoZSByZXF1ZXN0 IGlzIHJlamVjdGVkLCBub25lDQo+ICAgIG9mIHRoZSBzdGF0ZSBjaGFuZ2VzIGFyZSBwZXJmb3Jt ZWQuDQo+IA0KPiAxNCBNb2RpZnlpbmcgYW4gRXhpc3RpbmcgU2Vzc2lvbg0KPiAgMTQuMSBVQUMg QmVoYXZpb3INCj4gICAgSWYgYSBVQSByZWNlaXZlcyBhIG5vbi0yeHggZmluYWwgcmVzcG9uc2Ug dG8gYSByZS1JTlZJVEUsIHRoZSBzZXNzaW9uDQo+ICAgIHBhcmFtZXRlcnMgTVVTVCByZW1haW4g dW5jaGFuZ2VkLCBhcyBpZiBubyByZS1JTlZJVEUgaGFkIGJlZW4gaXNzdWVkLg0KPiANCj4gYWJv dmUgcnVsZSB3b3JrIGZpbmUgZm9yIHJlLUlOVklURSBhbmQgUFJBQ0suIGJ1dCBJIHRoaW5rIHRo YXQgVVBEQVRFDQo+IGFuZCBwcmVjb25kaXRpb24gcHJvY2VkdXJlIHdhcyBjb25zaWRlcmVkIGlu c3VmZmljaWVudGx5IGFib3V0IGFuIGVycm9yDQo+IHJlc3BvbnNlIHRvIGEgcmUtSU5WSVRFLg0K PiANCj4gaWYgYWxsIGNoYW5nZXMgZXhlY3V0ZWQgYnkgVVBEQVRFIHRyYW5zYWN0aW9ucyBhcmUg ZXhjbHVkZWQgZnJvbSB0aGUNCj4gcm9sbGJhY2ssIGFyZSB0aGVyZSBhbnkgcHJvYmxlbXM/DQo+ IA0KDQpbR2FvXSBBcyBtZWRpYSBuZWdvdGlhdGlvbiBvdmVybGFwIG1vcmUgdGhhbiBvbmUgTy9B IHBhaXJzIHN1Y2ggYXMgDQpwcmVjb25kaXRpb24sIHRoZW4gaXQgd2lsbCB1c2UgVVBEQVRFLzIw ME9LIGFzIHN1YnNlcXVlbnQgTy9BIHBhaXIgYWZ0ZXIgDQp0aGUgZmlyc3QgTy9BIHBhaXIoSU5W SVRFLzE4MyBvciAxODMvUFJBQ0spLiBBbmQgaW4gc3VjaCBjYXNlLCB3ZSBjYW4gbm90IA0KbGV0 IFVQREFURS8yMDBPSydzIE8vQSBwYWlyIGFsb25lIGFmdGVyIHVuLXN1Y2Nlc3NmdWwgUmUtSU5W SVRFLiBTbywgSU1PLCANCm1ha2luZyBhbGwgY2hhbmdlcyBleGVjdXRlZCBieSBVUERBVEUgdHJh bnNhY3Rpb25zIGV4Y2x1ZGVkIGZyb20gdGhlIA0Kcm9sbGJhY2sgaXMgbm90IG5pY2Ugd2F5Lg0K DQoNCj4gVGhhdCBpcywNCj4gDQo+ICAgfCAgIElOVklURSAgICAgfCAgICAgICAgICAgICAgICAg IHwgICAgICAgICAgICAgIHwNCj4gICB8LS0tLS0tLS0tLS0tLT58ICAgICAgICAgICAgICAgICAg fCAgICAgICAgICAgICAgfA0KPiAgIHwgICAxODMgICAgICAgIHwgICAgICAgICAgICAgICAgICB8 ICAgICAgICAgICAgICB8DQo+ICAgfDwtLS0tLS0tLS0tLS0tfCAgICAgICAgICAgICAgICAgIHwg ICAgICAgICAgICAgIHwNCj4gICB8ICAgUFJBQ0sgICAgICB8ICAgICAgICAgICAgICAgICAgfCAg ICAgICAgICAgICAgfA0KPiAgIHwtLS0tLS0tLS0tLS0tPnwgICAgICAgICAgICAgICAgICB8ICAg ICAgICAgICAgICB8DQo+ICAgfCAgIDIwMChQUkFDSykgfCAgICAgICAgICAgICAgICAgIHwgICAg ICAgICAgICAgIHwNCj4gICB8PC0tLS0tLS0tLS0tLS18IGlzIGlkZW50aWNhbCB0byAgfCAgICAg ICAgICAgICAgfA0KPiAgIHwgICBVUERBVEUgICAgIHwgICAgICAgICAgICAgICAgICB8ICAgVVBE QVRFICAgICB8DQo+ICAgfC0tLS0tLS0tLS0tLS0+fCAgICAgICAgICAgICAgICAgIHwtLS0tLS0t LS0tLS0tPnwNCj4gICB8ICAgMjAwKFVQREFURSl8ICAgICAgICAgICAgICAgICAgfCAgIDIwMChV UERBVEUpfA0KPiAgIHw8LS0tLS0tLS0tLS0tLXwgICAgICAgICAgICAgICAgICB8PC0tLS0tLS0t LS0tLS18DQo+ICAgfCAgIDQ4OChJTlZJVEUpfCAgICAgICAgICAgICAgICAgIHwgICAgICAgICAg ICAgIHwNCj4gICB8PC0tLS0tLS0tLS0tLS18ICAgICAgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgfA0KPiAgIHwgICBBQ0sgICAgICAgIHwgICAgICAgICAgICAgICAgICB8ICAgICAgICAgICAg ICB8DQo+ICAgfC0tLS0tLS0tLS0tLS0+fCAgICAgICAgICAgICAgICAgIHwgICAgICAgICAgICAg IHwNCj4gDQo+IA0KPiBUaGlzIHVwZGF0ZXMgUkZDMzMxMS4NCj4gDQo+IEJ1dCBhdCB0aGlzIHBv aW50LCBJIGhhdmUgb25lIGRvdWJ0Lg0KPiBNYXkgcHJlY29uZGl0aW9uIHByb2NlZHVyZSBiZSBz dGFydGVkIGJ5IFVQREFURT8NCj4gDQoNCltHYW9dIEFzIHRoZXJlIGlzIG5vIHNwZWNpZmljIHJl c3RyaWN0IGFib3V0IHByZWNvbmRpdGlvbiBwcm9jZWR1cmUgDQpzdGFydGVkIGJ5IFVQREFURSwg dGhlbiBVQUMgY2FuIHNlbmQgYSBVUERBVEUgYXMgT2ZmZXIod2l0aCBwcmVjb25kaXRpb24pIA0K b3V0c2lkZSBvZiBSZS1JTlZJVEUuDQpCdXQgaWYgdGhlIHFvcyBzdHJlbmd0aCBpcyBtYW5kYXRv cnksIGFuZCB0aGUgVUFTIGNhbiBub3QgcmVhY2ggdGhlIA0KZGVzaXJlZCBxb3MsIGl0IE1VU1Qg cmVqZWN0IHRoZSBPZmZlciB3aXRoIDUwNC4gU28sIGF0IEJDUCBsZXZlbCwgd2UgDQpzaG91bGQg dHJpZ2dlciBuZXcgc2Vzc2lvbiBtb2RpZmljYXRpb24gd2l0aCBwcmVjb25kaXRpb24gaW4gUmUt SU5WSVRFIA0KaW5zdGVhZCBvZiBVUERBVEUuDQoNCj4gPjQuICBQcm9ibGVtcyB3aXRoIEVycm9y IFJlc3BvbnNlcyBhbmQgQWxyZWFkeS1leGVjdXRlZCBDaGFuZ2VzDQo+ID4gICBVc2luZyBhbiBl cnJvciByZXNwb25zZSB0byB1bmRvIGFscmVhZHkgZXhlY3V0ZWQgY2hhbmdlcyBwcmVzZW50cyBh bg0KPiA+ICAgYWRkaXRpb25hbCBwcm9ibGVtLiAgU2VjdGlvbiA0IG9mIFtSRkMzMjY0XSBzcGVj aWZpZXMgcnVsZXMgdG8gYXZvaWQNCj4gPiAgIGdsYXJlIHNpdHVhdGlvbnMgKGkuZS4sIHRvIGF2 b2lkIG9mZmVyL2Fuc3dlciBjb2xsaXNpb25zIGluIHJhY2UNCj4gPiAgIGNvbmRpdGlvbnMpLiAg RXZlbiB3aGVuIGJvdGggVUFzIGdlbmVyYXRlIGFuIG9mZmVyIGF0IHRoZSBzYW1lIHRpbWUsDQo+ ID4gICB0aGVyZSBhcmUgcnVsZXMgdG8gZGV0ZXJtaW5lIHdoaWNoIG9uZSBzaG91bGQgYmUgcHJv Y2Vzc2VkIGZpcnN0Lg0KPiA+ICAgSG93ZXZlciwgdGhlcmUgYXJlIG5vIHJ1bGVzIHRvIGF2b2lk IGEgY29sbGlzaW9uIGJldHdlZW4gYW4gb2ZmZXIgaW4NCj4gPiAgIGFuIFVQREFURSByZXF1ZXN0 IGFuZCBhbiBlcnJvciByZXNwb25zZSBmb3IgYSByZS1JTlZJVEUuICBTaW5jZSBib3RoDQo+ID4g ICB0aGUgVVBEQVRFIHJlcXVlc3QgYW5kIHRoZSBlcnJvciByZXNwb25zZSB3b3VsZCByZXF1ZXN0 IGNoYW5nZXMsIGl0DQo+ID4gICB3b3VsZCBub3QgYmUgY2xlYXIgd2hpY2ggY2hhbmdlcyB3b3Vs ZCBuZWVkIHRvIGJlIGV4ZWN1dGVkIGZpcnN0Lg0KPiA+ICAgVGhpcyBpcyB5ZXQgYW5vdGhlciBy ZWFzb24gd2h5IFVBU3Mgc2hvdWxkIG5vdCB1c2UgZXJyb3IgcmVzcG9uc2VzIA0KdG8NCj4gPiAg IHVuZG8gYWxyZWFkeS1leGVjdXRlZCBjaGFuZ2VzLg0KPiANCj4gSSB0aGluayBnbGFyZSBzaXR1 YXRpb25zIG9jY3VyIGluIHRocmVlIGNhc2VzLg0KPiANCj4gMS4NCj4gIHwgVVBEQVRFICAgICAg IDQ4OChyZUlOVklURSkgfA0KPiAgfC0tLS0tLS0tLVwgICAvLS0tLS0tLS0tLS0tLS18DQo+ICB8 ICAgICAgICAgIFwgLyAgICAgICBBQ0sgICAgIHwNCj4gIHwgICAgICAgICAgIFggICAgICAgLS0t LS0tLS0+fA0KPiAgfCAgICAgICAgICAvIFwgICAgICAgICAgICAgICB8DQo+ICB8PC0tLS0tLS0t LyAgIFwtLS0tLS0tLS0tLS0tPnwNCj4gIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K PiAgfCAgICAgICAgICAgICAgICAgMjAwKFVQREFURSl8DQo+ICB8PC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLXwNCj4gIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0KPiANCj4gMi4N Cj4gIHwgVVBEQVRFICAgICAgICAgICAgICAgICAgICAgfA0KPiAgfC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLT58DQo+ICB8ICAgICAgICAgICAgICAgIDIwMChVUERBVEUpIHwNCj4gIHw8LS0t LS0tLS1cICAgLy0tLS0tLS0tLS0tLS0tKw0KPiAgfCAgICAgICAgICBcIC8gICAgICAgICAgICAg ICB8DQo+ICB8ICAgICAgICAgICBYICAgICAgICAgICAgICAgIHwNCj4gIHwgICAgICAgICAgLyBc IDQ4OChyZUlOVklURSkgfA0KPiAgfDwtLS0tLS0tLS8gICBcLS0tLS0tLS0tLS0tLS0rDQo+ICB8 ICAgICAgICAgICAgICAgICAgICBBQ0sgICAgIHwNCj4gIHwgICAgICAgICAgICAgICAgICAgLS0t LS0tLS0+fA0KPiAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+IA0KPiAzLg0KPiAg fCAgICAgICAgICAgICAgIDQ4OChyZUlOVklURSl8DQo+ICB8PC0tLS0tLS0tXCAgIC8tLS0tLS0t LS0tLS0tLXwNCj4gIHwgICAgICAgICAgXCAvICAgICAgQUNLICAgICAgfA0KPiAgfCAgICAgICAg ICAgWCAgICAgIC0tLS0tLS0tLT58DQo+ICB8ICAgICAgICAgIC8gXCAgICAgICAgVVBEQVRFIHwN Cj4gIHwgICAgICAgICAvICAgXC0tLS0tLS0tLS0tLS0tfA0KPiAgfCAgICAgICAgLyAgICAgICAg ICAgICAgICAgICB8DQo+ICB8ICAgICAgIC8gIDIwMChVUERBVEUpICAgICAgIHwNCj4gIHwtLS0t LS0vLS0tLS0tLS0tLS0tLS0tLS0tLS0+fA0KPiAgfCAgICAgLyAgICAgICAgICAgICAgICAgICAg ICB8DQo+ICB8PC0tLS8gICAgICAgICAgICAgICAgICAgICAgIHwNCj4gIHwgDQo+IA0KPiANCj4g PjYuICBVQUMgQmVoYXZpb3INCj4gPiAgIEluIG9yZGVyIHRvIGNvcGUgd2l0aCB0aGlzIHR5cGUg b2YgVUFTLCBhIFVBQyB0aGF0IHJlY2VpdmVzIGFuIGVycm9yDQo+ID4gICByZXNwb25zZSB0byBh IHJlLUlOVklURSBmb3Igd2hpY2ggY2hhbmdlcyBoYXZlIGJlZW4gYWxyZWFkeSBleGVjdXRlZA0K PiA+ICAgU0hPVUxEIGdlbmVyYXRlIGEgbmV3IHJlLUlOVklURSBvciBVUERBVEUgcmVxdWVzdCBp biBvcmRlciB0byBtYWtlDQo+ID4gICBzdXJlIHRoYXQgYm90aCBVQXMgaGF2ZSBhIGNvbW1vbiB2 aWV3IG9mIHRoZSBzdGF0ZSBvZiB0aGUgc2Vzc2lvbi4NCj4gDQo+IElmIGFsbCBjaGFuZ2VzIGFy ZSB0aGUgcmVzdWx0cyBvZiBvbmx5IHJlLUlOVklURSBhbmQgUFJBUkssIEkgdGhpbmsNCj4gbmV3 IFVQREFURShvciByZS1JTlZJVEUpIHJlcXVlc3QgaXMgbm90IG5lY2Vzc2FyeS4NCj4gDQo+IFJl Z2FyZHMsDQo+IFNoaW5qaQ0KPiANCj4gDQo+IFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAY2lzY28u Y29tPg0KPiA+R29uemFsbywNCj4gPg0KPiA+VGhhbmtzIGZvciBkb2luZyB0aGlzIHdvcmshIEkg ZG8gaGF2ZSBzb21lIGNvbW1lbnRzOg0KPiA+DQo+ID5TZWN0aW9uIDMvRmlndXJlIDENCj4gPg0K PiA+VGhlIGZpZ3VyZSBzaG93cyBhIDZ4eCByZXNwb25zZS4NCj4gPlRoZSB0ZXh0IHNheXMgdGhh dCB0aGUgVUFTIHdhbnRzIHRvIHJlamVjdCB0aGUgbmV3IG9mZmVyLg0KPiA+DQo+ID5BIFVBUyB3 b3VsZCBwcm9iYWJseSBub3QgdXNlIGEgNnh4IHJlc3BvbnNlIHRvIHJlamVjdCBtZWRpYS4NCj4g PihJIGd1ZXNzIGl0IG1pZ2h0IHVzZSA2MDYsIGJ1dCA0ODggd291bGQgYmUgbW9yZSBhcHByb3By aWF0ZS4pDQo+ID5JbiBmYWN0LCBpdCBwcm9iYWJseSB3b3VsZCBub3QgcmVqZWN0IHRoZSByZXF1 ZXN0IGF0IGFsbCwgYnV0IHJhdGhlciANCj4gPndvdWxkIGp1c3QgcmVmdXNlIHRoZSBhZGRlZCBt ZWRpYSBzdHJlYW0uDQo+ID4NCj4gPlRoZSBwb2ludCBiZWluZyBtYWRlIGRvZXNuJ3QgcmVxdWly ZSB0aGF0IHRoZSByZXNwb25zZSBiZSA2eHggb3IgdGhhdCANCml0IA0KPiA+YmUgd2l0aCB0aGUg cHVycG9zZSBvZiByZWZ1c2luZyB0aGUgbWVkaWEuIFNvIEkgdGhpbmsgd2hhdCBpcyBuZWVkZWQg DQo+ID5oZXJlIGlzIHRvIGZpbmQgYSBwbGF1c2libGUgZXhhbXBsZSB0byBtYWtlIHRoZSBwb2lu dC4NCj4gPg0KPiA+QSBnb29kIG9uZSBmb3IgdGhlIHB1cnBvc2UgaGVyZSBtaWdodCBiZSBhIDQ4 OCB0byByZWplY3QgdGhlIG1lZGlhLCBvciANCmEgDQo+ID4gIDQwMSByZXNwb25zZSBhcyBhbm90 aGVyIHNvcnQgb2YgcmVhc29uIGZvciByZWplY3RpbmcgdGhlIHdob2xlIHRoaW5nIA0KPiA+YnV0 IHdhbnRpbmcgdG8gcHJlc2VydmUgd2hhdCB0aGVyZSBpcy4NCj4gPg0KPiA+U2VjdGlvbiA1Og0K PiA+DQo+ID4+ICAgIEEgY2hhbmdlIHRvIHRoZSBzZXNzaW9uIHN0YXRlIGlzIGNvbnNpZGVyZWQg dG8gaGF2ZSBiZWVuIGV4ZWN1dGVkDQo+ID4+ICAgIHdoZW4gdGhlIG5ldyBtZWRpYSBwYXJhbWV0 ZXJzIGFyZSBiZWluZyB1c2VkLiAgVGhlcmVmb3JlLCBhIGNoYW5nZSANCnRvDQo+ID4+ICAgIGEg c3RyZWFtIHN1YmplY3QgdG8gcHJlY29uZGl0aW9ucyBbUkZDNDAzMl0gaXMgY29uc2lkZXJlZCB0 byBoYXZlDQo+ID4+ICAgIGJlZW4gZXhlY3V0ZWQgd2hlbiB0aGUgbmV3IG1lZGlhIHBhcmFtZXRl cnMgc3RhcnQgYmVpbmcgdXNlZDsgbm90DQo+ID4+ICAgIHdoZW4gdGhlIHByZWNvbmRpdGlvbnMg Zm9yIHRoZSBzdHJlYW0gYXJlIG1ldC4gIFVuc3VycHJpc2luZ2x5LCANCnRoZQ0KPiA+PiAgICBV QVMgY29uc2lkZXJzIHRoZSBuZXcgcGFyYW1ldGVycyB0byBiZSBpbiB1c2Ugd2hlbiBpdCBhY3R1 YWxseSANCnN0YXJ0cw0KPiA+PiAgICB1c2luZyB0aGVtLiANCj4gPg0KPiA+SSdtIG5vdCBlbnRp cmVseSBmb2xsb3dpbmcgdGhpcy4gSSB0aGluayB0aGVyZSBtYXkgYmUgYW4gYXNzdW1wdGlvbiAN CmhlcmUgDQo+ID50aGF0IHRoZSBVQUMgaXMgdGhlIG9mZmVyZXIgYW5kIHRoZSBVQVMgdGhlIGFu c3dlcmVyLiBJJ20gZ3Vlc3NpbmcgeW91IA0KPiA+YXJlIHNheWluZyB0aGF0IHRoZSBhbnN3ZXJl ciBjb25zaWRlcnMgdGhlIG5ldyBwYXJhbWV0ZXJzIHRvIGJlIGluIHVzZSANCj4gPndoZW4gaXQg YWN0dWFsbHkgc3RhcnRzIHVzaW5nIHRoZW0uDQo+ID4NCj4gPlNpbmNlIHRoaXMgc2VjdGlvbiBp cyBhYm91dCB0aGUgVUFTIChmb3IgdGhlIHJlaW52aXRlKSwgdGhpcyBwb2ludCBpcyANCj4gPnBy b2JhYmx5IHRoYXQgd2hlbiB0aGUgVUFTIGlzIGFsc28gdGhlIGFuc3dlcmVyIGl0IGNhbiBkZWNp ZGUgd2hlbiB0aGUgDQo+ID5uZXcgbWVkaWEgaXMgaW4gdXNlIGJhc2VkIG9uIHdoZW4gaXQgc3Rh cnRzIHVzaW5nIHRoZW0uDQo+ID4NCj4gPkJ1dCB3aGF0IGhhcHBlbnMgd2hlbiB0aGUgVUFTIGlz IHRoZSBvZmZlcmVyPyBJbiB0aGF0IGNhc2UgSSB0aGluayBpdCANCj4gPm11c3QgYXNzdW1lIHRo ZSBtZWRpYSBpcyBpbiB1c2UgYXMgc29vbiBhcyBpdCBpcyBvZmZlcmVkLiBCdXQgbWF5YmUgDQp0 aGF0IA0KPiA+aXNuJ3QgYWx3YXlzIHRoZSBjYXNlIHdpdGggcHJlY29uZGl0aW9ucy4gSSBkb24n dCB0aGluayBpdCBjYW4gd2FpdCANCnRpbGwgDQo+ID5pdCByZWNlaXZlcyBtZWRpYSwgYmVjYXVz ZSBtZWRpYSBtYXkgYmUgaW4gZmxpZ2h0IHdoZW4gaXQgbWFrZXMgaXRzIA0KPiA+ZGVjaXNpb24u DQo+ID4NCj4gPj4gICAgQXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gOC4zLjEgb2YgUkZDIDMyNjQg W1JGQzMyNjRdLCB0aGUNCj4gPj4gICAgVUFDIGNvbnNpZGVycyB0aGUgbmV3IHBhcmFtZXRlcnMg dG8gYmUgaW4gdXNlIHdoZW4gbWVkaWEgaXMgDQpyZWNlaXZlZA0KPiA+PiAgICBpbiB0aGUgbmV3 IHBvcnQsIHdoaWNoIHNob3VsZCBiZSBpbnRlcnByZXRlZCBhcyBmb2xsb3dzOg0KPiA+PiANCj4g Pj4gICAgICAgUmVjZWl2ZWQsIGluIHRoaXMgY2FzZSwgbWVhbnMgdGhhdCB0aGUgbWVkaWEgaXMg cGFzc2VkIHRvIGEgDQptZWRpYQ0KPiA+PiAgICAgICBzaW5rLiAgVGhpcyBtZWFucyB0aGF0IGlm IHRoZXJlIGlzIGEgcGxheW91dCBidWZmZXIsIHRoZSBhZ2VudA0KPiA+PiAgICAgICB3b3VsZCBj b250aW51ZSB0byBsaXN0ZW4gb24gdGhlIG9sZCBwb3J0IHVudGlsIHRoZSBtZWRpYSBvbiB0aGUN Cj4gPj4gICAgICAgbmV3IHBvcnQgcmVhY2hlZCB0aGUgdG9wIG9mIHRoZSBwbGF5b3V0IGJ1ZmZl ci4gIEF0IHRoYXQgdGltZSwgDQppdA0KPiA+PiAgICAgICBNQVkgY2Vhc2UgbGlzdGVuaW5nIGZv ciBtZWRpYSBvbiB0aGUgb2xkIHBvcnQuDQo+ID4NCj4gPkkgZG9uJ3Qga25vdyB3aGF0IHRoZSBh Ym92ZSBoYXMgdG8gZG8gd2l0aCB0aGUgYmVoYXZpb3Igb2YgdGhlIFVBUy4NCj4gPg0KPiA+PiA5 LiAgQ2xhcmlmaWNhdGlvbnMgb24gVGFyZ2V0IFJlZnJlc2ggUmVxdWVzdHMNCj4gPj4gDQo+ID4+ ICAgIE9uIHJlY2VpdmluZyBhIHRhcmdldCByZWZyZXNoIHJlcXVlc3Qgd2l0aCBhbiB1cGRhdGVk IHJlbW90ZSANCnRhcmdldCwNCj4gPj4gICAgYSBVQVMgdXBkYXRlcyB0aGUgcmVtb3RlIHRhcmdl dCBvZiB0aGUgZGlhbG9nIGltbWVkaWF0ZWx5LiAgVGhpcw0KPiA+PiAgICB1cGRhdGUgcmVwcmVz ZW50cyB0aGUgZXhlY3V0aW9uIG9mIGEgc3RhdGUgY2hhbmdlLiAgVGhlcmVmb3JlLA0KPiA+PiAg ICBmb2xsb3dpbmcgdGhlIHJ1bGVzIGluIFNlY3Rpb24gNSwgVUFTcyBhbHdheXMgcmV0dXJuIDJ4 eCByZXNwb25zZXMgDQp0bw0KPiA+PiAgICB0YXJnZXQgcmVmcmVzaCByZXF1ZXN0cyB0aGF0IHVw ZGF0ZSB0aGUgcmVtb3RlIHRhcmdldC4NCj4gPg0KPiA+VGhpcyBkb2VzIG5vdCBhZGRyZXNzIGNh c2VzIHdoZXJlIHRoZSBVQVMgY2Fubm90IGFjY2VwdCB0aGUgY2hhbmdlIHdpdGggDQoNCj4gPmEg MjAwLiBTb21lIGNhc2VzIHRoYXQgZmFsbCBpbnRvIHRoaXMgY2F0ZWdvcnkgYXJlOg0KPiA+DQo+ ID4tIHJlcXVlc3QgaW5jbHVkZXMgYSBSZXF1aXJlIG9mIGFuIHVuc3VwcG9ydGVkIG9wdGlvbiAo ZS5nLiAxMDByZWwpDQo+ID4tIHJlcXVlc3QgY2Fubm90IGJlIGF1dGhvcml6ZWQNCj4gPi0gc2Vy dmVyIG92ZXJsb2FkDQo+ID4tIHByZWNvbmRpdGlvbiBmYWlsdXJlDQo+ID4NCj4gPkluIGFueSBj YXNlLCBpZiBubyBzdGF0ZSBjaGFuZ2VzIGhhdmUgYmVlbiBtYWRlIHByaW9yIHRvIHRoZSByZXF1 ZXN0IA0KPiA+d2l0aCBhIHRhcmdldCBjaGFuZ2UsIHRoZW4gdGhlcmUgaXMgbm8gaXNzdWUgd2l0 aCByZWplY3RpbmcgdGhlIHRhcmdldCANCj4gPnJlZnJlc2ggaWYgbmVlZCBiZS4NCj4gPg0KPiA+ VGhlIGlzc3VlIHdpdGggdGFyZ2V0IHJlZnJlc2ggaXMgdGhhdCB0aGUgVUEgc2VuZGluZyBpdCBt YXkgaGF2ZSBhbiANCj4gPnVyZ2VudCBuZWVkIGZvciBpdCB0byBiZSBhY2NlcHRlZCwgc2luY2Ug aXQgbWF5IG5vdCBiZSBhYmxlIHRvIA0KPiA+Y29tbXVuaWNhdGUgb24gaXRzIG9sZCBhZGRyZXNz KGVzKSBhbnkgbG9uZ2VyLiBBbmQgaWYgdGhhdCBpcyB0aGUgY2FzZSANCj4gPml0IG1heSBhbHNv IGhhdmUgYW4gdXJnZW50IG5lZWQgdG8gY2hhbmdlIGl0cyBtZWRpYSBhZGRyZXNzZXMgYXMgd2Vs bCANCj4gPmZvciB0aGUgc2FtZSByZWFzb24uIFRoYXQgd291bGQgYmUgbW90aXZhdGlvbiBmb3Ig ZG9pbmcgYm90aCBhdCBvbmNlLg0KPiA+DQo+ID5JZiBhIHJlSU5WSVRFIGluY2x1ZGVzIGEgdGFy Z2V0IGNoYW5nZSwgdGhlbiBpdHMgdmVyeSBkaWZmaWN1bHQgdG8ga25vdyANCg0KPiA+d2hlbiB0 aGUgVUFDIG11c3QgYmVnaW4gdXNpbmcgaXQuIFNvIEkgdGhpbmsgdGhlIFVBUyBtdXN0IGFzc3Vt ZSBpdCANCm11c3QgDQo+ID5iZSBjb25zaWRlcmVkIGluIHVzZSBpbW1lZGlhdGVseS4gSGVuY2Ug aXQgc2hvdWxkICp0cnkqIHRvIGF2b2lkIA0KPiA+cmVqZWN0aW5nIHRoZSByZXF1ZXN0LCBldmVu IGlmIGl0IG11c3QgcmVqZWN0IGFsbCB0aGUgbWVkaWEgaW4gdGhlIA0KPiA+cmVxdWVzdC4gQnV0 IHRoZXJlIGlzIHN0aWxsIGEgcG9zc2liaWxpdHkgdGhhdCBpdCB3aWxsIGhhdmUgdG8gcmVqZWN0 IA0KPiA+ZHVlIHRvIGF1dGhvcml6YXRpb24sIG92ZXJsb2FkLCBldGMuIElmIHRoYXQgaXMgZG9u ZSByaWdodCBhd2F5IGl0cyBubyANCj4gPmRpZmZlcmVudCB0aGFuIGFueSByZXF1ZXN0IHJlamVj dGVkIGJlZm9yZSBhbnkgY2hhbmdlcyBoYXZlIGJlZW4gbWFkZS4NCj4gPg0KPiA+QSBkaWZmaWN1 bHQgY2FzZSBpcyB3aGVyZSBhIHJlSU5WSVRFIGhhcyBiZWVuIGluaXRpYXRlZCwgYW5kIGhhcyBu b3QgDQo+ID5jb21wbGV0ZWQuIChQZXJoYXBzIGl0cyByaW5naW5nLikgVGhlbiB0aGUgVUFDIGxv c2VzIGl0cyBJUCBhZGRyZXNzIG9yIA0KPiA+SVAgY29ubmVjdGl2aXR5IGFuZCBuZWVkcyB0byBt YWtlIGEgdGFyZ2V0IGNoYW5nZS4gU28gaXQgc2VuZHMgYW4gDQpVUERBVEUgDQo+ID53aXRoIHRo ZSB0YXJnZXQgY2hhbmdlLiBXaGF0IGl0IHNob3VsZCBwcm9iYWJseSBkbyBpbiB0aGF0IGNhc2Ug aXMgDQoqbm90KiANCj4gPmluY2x1ZGUgYW4gb2ZmZXIgaW4gdGhlIFVQREFURS4gVGhlbiBpdCBj YW4ndCBiZSByZWplY3RlZCBmb3Igby9hIA0KPiA+cmVhc29ucy4gT25jZSB0aGF0IGlzIGRvbmUg aXQgY2FuIGNvbnRpbnVlIHRoZSBvL2EgcHJvY2VzcywgdXBkYXRpbmcgDQppdHMgDQo+ID5tZWRp YSBhZGRyZXNzZXMgd2hlbiBpdCBoYXMgdGhlIGNoYW5jZS4gT25jZSB0aGUgVUFDIHRhcmdldCBo YXMgDQpjaGFuZ2VkLCANCj4gPnRoZSBVQVMgc2hvdWxkIG5vdCBmYWlsIHRoZSBJTlZJVEUuIElm IG5lZWQgYmUgaXQgc2hvdWxkIHJlamVjdCBhbGwgdGhlIA0KDQo+ID5tZWRpYSBpbiBvcmRlciB0 byBhdm9pZCB0aGF0Lg0KPiA+DQo+ID5Bbm90aGVyIGRpZmZpY3VsdCBjYXNlIGlmIGlmIGEgcmVJ TlZJVEUgaGFzIGJlZW4gaW5pdGlhdGVkIGFuZCB0aGUgVUFTIA0KPiA+ZmluZHMgaXQgbmVlZHMg dG8gY2hhbmdlIGl0cyBhZGRyZXNzLiBTaW1pbGFyIGNvbnNpZGVyYXRpb25zIHRvIGFib3ZlIA0K PiA+c2VlbSB0byBhcHBseS4NCj4gPg0KPiA+RnJhbmtseSwgdGhpcyBpcyBhbGwgdmVyeSBuYXN0 eSwgYW5kIHRob3NlIGluIHRoaXMgc2l0dWF0aW9uIG1heSBoYXZlIA0KPiA+ZmV3IG9wdGlvbnMg Zm9yIHdoYXQgZG8gZG8uIEl0IGZlZWxzIGRlc2VydmluZyBvZiBpdHMgb3duIHRyZWF0bWVudC4g DQo+ID5OYW1lbHkgYSB3aG9sZSBjYWxsIGZsb3cgZG9jdW1lbnQgd2l0aCB2YXJpb3VzIHVzZSBj YXNlcyB3aGVyZSB0YXJnZXQgDQo+ID5jaGFuZ2UgaXMgcmVxdWlyZWQuIFByb2JhYmx5IGEgQkNQ Lg0KPiA+DQo+ID4gICBUaGFua3MsDQo+ID4gICBQYXVsDQo+IA0KDQoNCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1h dGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBt YWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlz IG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJv dmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRl ZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVy cy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25m aWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVh bCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0 aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3Nl IG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVk IGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 003BACA6482575EC_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpo6w8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlBsZWFzZSBzZWUgaW5saW5lcy48L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcy48L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdhbzwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0Pk9LVU1VUkEgU2hpbmppICZsdDtzaGluQHNvZnRm cm9udC5jby5qcCZndDsg0LTT2g0KMjAwOS0wNy0wNyAxODoxNTowODo8YnI+DQo8YnI+DQomZ3Q7 IEhpLDxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGhhdmUgc29tZSBjb21tZW50cy48YnI+DQomZ3Q7 IDxicj4NCiZndDsgUkZDMzI2MSBkZXNjcmliZSBhYm91dCB0aGUgYXRvbWljIHByb2Nlc3MuPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IDggR2VuZXJhbCBVc2VyIEFnZW50IEJlaGF2aW9yPGJyPg0KJmd0 OyAmbmJzcDs4LjIgVUFTIEJlaGF2aW9yPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7Tm90ZSB0aGF0 IHJlcXVlc3QgcHJvY2Vzc2luZyBpcyBhdG9taWMuICZuYnNwO0lmIGEgcmVxdWVzdA0KaXMgYWNj ZXB0ZWQsPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7YWxsIHN0YXRlIGNoYW5nZXMgYXNzb2NpYXRl ZCB3aXRoIGl0IE1VU1QgYmUgcGVyZm9ybWVkLg0KJm5ic3A7SWYgaXQgaXM8YnI+DQomZ3Q7ICZu YnNwOyAmbmJzcDtyZWplY3RlZCwgYWxsIHN0YXRlIGNoYW5nZXMgTVVTVCBOT1QgYmUgcGVyZm9y bWVkLjxicj4NCiZndDsgPGJyPg0KJmd0OyAxMiBEaWFsb2dzPGJyPg0KJmd0OyAmbmJzcDsxMi4y IFJlcXVlc3RzIHdpdGhpbiBhIERpYWxvZzxicj4NCiZndDsgJm5ic3A7MTIuMi4yIFVBUyBCZWhh dmlvcjxicj4NCiZndDsgJm5ic3A7ICZuYnNwO1JlcXVlc3RzIHNlbnQgd2l0aGluIGEgZGlhbG9n LCBhcyBhbnkgb3RoZXIgcmVxdWVzdHMsDQphcmUgYXRvbWljLiAmbmJzcDtJZjxicj4NCiZndDsg Jm5ic3A7ICZuYnNwO2EgcGFydGljdWxhciByZXF1ZXN0IGlzIGFjY2VwdGVkIGJ5IHRoZSBVQVMs IGFsbCB0aGUNCnN0YXRlIGNoYW5nZXM8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDthc3NvY2lhdGVk IHdpdGggaXQgYXJlIHBlcmZvcm1lZC4gJm5ic3A7SWYgdGhlIHJlcXVlc3QNCmlzIHJlamVjdGVk LCBub25lPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7b2YgdGhlIHN0YXRlIGNoYW5nZXMgYXJlIHBl cmZvcm1lZC48YnI+DQomZ3Q7IDxicj4NCiZndDsgMTQgTW9kaWZ5aW5nIGFuIEV4aXN0aW5nIFNl c3Npb248YnI+DQomZ3Q7ICZuYnNwOzE0LjEgVUFDIEJlaGF2aW9yPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7SWYgYSBVQSByZWNlaXZlcyBhIG5vbi0yeHggZmluYWwgcmVzcG9uc2UgdG8gYSByZS1J TlZJVEUsDQp0aGUgc2Vzc2lvbjxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3BhcmFtZXRlcnMgTVVT VCByZW1haW4gdW5jaGFuZ2VkLCBhcyBpZiBubyByZS1JTlZJVEUNCmhhZCBiZWVuIGlzc3VlZC48 YnI+DQomZ3Q7IDxicj4NCiZndDsgYWJvdmUgcnVsZSB3b3JrIGZpbmUgZm9yIHJlLUlOVklURSBh bmQgUFJBQ0suIGJ1dCBJIHRoaW5rIHRoYXQgVVBEQVRFPGJyPg0KJmd0OyBhbmQgcHJlY29uZGl0 aW9uIHByb2NlZHVyZSB3YXMgY29uc2lkZXJlZCBpbnN1ZmZpY2llbnRseSBhYm91dCBhbg0KZXJy b3I8YnI+DQomZ3Q7IHJlc3BvbnNlIHRvIGEgcmUtSU5WSVRFLjxicj4NCiZndDsgPGJyPg0KJmd0 OyBpZiBhbGwgY2hhbmdlcyBleGVjdXRlZCBieSBVUERBVEUgdHJhbnNhY3Rpb25zIGFyZSBleGNs dWRlZCBmcm9tIHRoZTxicj4NCiZndDsgcm9sbGJhY2ssIGFyZSB0aGVyZSBhbnkgcHJvYmxlbXM/ PGJyPg0KJmd0OyA8L3R0PjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1 ZT48dHQ+W0dhb10gQXMgbWVkaWEgbmVnb3RpYXRpb24gb3ZlcmxhcCBtb3JlDQp0aGFuIG9uZSBP L0EgcGFpcnMgc3VjaCBhcyBwcmVjb25kaXRpb24sIHRoZW4gaXQgd2lsbCB1c2UgVVBEQVRFLzIw ME9LDQphcyBzdWJzZXF1ZW50IE8vQSBwYWlyIGFmdGVyIHRoZSBmaXJzdCBPL0EgcGFpcihJTlZJ VEUvMTgzIG9yIDE4My9QUkFDSykuDQpBbmQgaW4gc3VjaCBjYXNlLCB3ZSBjYW4gbm90IGxldCBV UERBVEUvMjAwT0sncyBPL0EgcGFpciBhbG9uZSBhZnRlciB1bi1zdWNjZXNzZnVsDQpSZS1JTlZJ VEUuIFNvLCBJTU8sIG1ha2luZyBhbGwgY2hhbmdlcyBleGVjdXRlZCBieSBVUERBVEUgdHJhbnNh Y3Rpb25zDQpleGNsdWRlZCBmcm9tIHRoZSByb2xsYmFjayBpcyBub3QgbmljZSB3YXkuPC90dD48 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD48YnI+DQomZ3Q7IFRoYXQgaXMsPGJy Pg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOzxicj4NCiZndDsgJm5ic3A7IHwgJm5ic3A7IElOVklURSAmbmJzcDsgJm5i c3A7IHwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7fDxicj4NCiZndDsgJm5ic3A7IHwtLS0tLS0tLS0tLS0tJmd0O3wgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJmd0OyAm bmJzcDsgfCAmbmJzcDsgMTgzICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fCAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7fDxicj4NCiZn dDsgJm5ic3A7IHwmbHQ7LS0tLS0tLS0tLS0tLXwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJmd0OyAmbmJzcDsgfCAmbmJzcDsg UFJBQ0sgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0K Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwO3w8YnI+DQomZ3Q7ICZuYnNwOyB8LS0tLS0tLS0t LS0tLSZndDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7fDxicj4NCiZndDsgJm5ic3A7IHwgJm5ic3A7IDIwMChQUkFDSykgfCAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDt8 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8YnI+DQom Z3Q7ICZuYnNwOyB8Jmx0Oy0tLS0tLS0tLS0tLS18IGlzIGlkZW50aWNhbCB0byAmbmJzcDt8ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJmd0 OyAmbmJzcDsgfCAmbmJzcDsgVVBEQVRFICZuYnNwOyAmbmJzcDsgfCAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyBV UERBVEUgJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAmbmJzcDsgfC0tLS0tLS0tLS0tLS0mZ3Q7 fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNw OyAmbmJzcDt8LS0tLS0tLS0tLS0tLSZndDt8PGJyPg0KJmd0OyAmbmJzcDsgfCAmbmJzcDsgMjAw KFVQREFURSl8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJz cDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7IDIwMChVUERBVEUpfDxicj4NCiZndDsgJm5ic3A7IHwm bHQ7LS0tLS0tLS0tLS0tLXwgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7fCZsdDstLS0tLS0tLS0tLS0tfDxicj4NCiZndDsgJm5i c3A7IHwgJm5ic3A7IDQ4OChJTlZJVEUpfCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8YnI+DQomZ3Q7ICZuYnNwOyB8Jmx0Oy0tLS0tLS0t LS0tLS18ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsg Jm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7fDxicj4NCiZndDsgJm5ic3A7IHwgJm5ic3A7IEFDSyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5i c3A7ICZuYnNwO3w8YnI+DQomZ3Q7ICZuYnNwOyB8LS0tLS0tLS0tLS0tLSZndDt8ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwO3wg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7fDxicj4NCiZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhpcyB1cGRhdGVzIFJGQzMzMTEuPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IEJ1dCBhdCB0aGlzIHBvaW50LCBJIGhhdmUgb25lIGRvdWJ0Ljxicj4N CiZndDsgTWF5IHByZWNvbmRpdGlvbiBwcm9jZWR1cmUgYmUgc3RhcnRlZCBieSBVUERBVEU/PGJy Pg0KJmd0OyA8L3R0PjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48 dHQ+W0dhb10gQXMgdGhlcmUgaXMgbm8gc3BlY2lmaWMgcmVzdHJpY3QNCmFib3V0IHByZWNvbmRp dGlvbiBwcm9jZWR1cmUgc3RhcnRlZCBieSBVUERBVEUsIHRoZW4gVUFDIGNhbiBzZW5kIGEgVVBE QVRFDQphcyBPZmZlcih3aXRoIHByZWNvbmRpdGlvbikgb3V0c2lkZSBvZiBSZS1JTlZJVEUuPC90 dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+PHR0PkJ1dCBpZiB0aGUgcW9z IHN0cmVuZ3RoIGlzIG1hbmRhdG9yeSwgYW5kDQp0aGUgVUFTIGNhbiBub3QgcmVhY2ggdGhlIGRl c2lyZWQgcW9zLCBpdCBNVVNUIHJlamVjdCB0aGUgT2ZmZXIgd2l0aCA1MDQuDQpTbywgYXQgQkNQ IGxldmVsLCB3ZSBzaG91bGQgdHJpZ2dlciBuZXcgc2Vzc2lvbiBtb2RpZmljYXRpb24gd2l0aCBw cmVjb25kaXRpb24NCmluIFJlLUlOVklURSBpbnN0ZWFkIG9mIFVQREFURS48L3R0PjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTI+PHR0Pjxicj4NCiZndDsgJmd0OzQuICZuYnNwO1Byb2JsZW1zIHdp dGggRXJyb3IgUmVzcG9uc2VzIGFuZCBBbHJlYWR5LWV4ZWN1dGVkIENoYW5nZXM8YnI+DQomZ3Q7 ICZndDsgJm5ic3A7IFVzaW5nIGFuIGVycm9yIHJlc3BvbnNlIHRvIHVuZG8gYWxyZWFkeSBleGVj dXRlZCBjaGFuZ2VzDQpwcmVzZW50cyBhbjxicj4NCiZndDsgJmd0OyAmbmJzcDsgYWRkaXRpb25h bCBwcm9ibGVtLiAmbmJzcDtTZWN0aW9uIDQgb2YgW1JGQzMyNjRdIHNwZWNpZmllcw0KcnVsZXMg dG8gYXZvaWQ8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IGdsYXJlIHNpdHVhdGlvbnMgKGkuZS4sIHRv IGF2b2lkIG9mZmVyL2Fuc3dlciBjb2xsaXNpb25zDQppbiByYWNlPGJyPg0KJmd0OyAmZ3Q7ICZu YnNwOyBjb25kaXRpb25zKS4gJm5ic3A7RXZlbiB3aGVuIGJvdGggVUFzIGdlbmVyYXRlIGFuIG9m ZmVyDQphdCB0aGUgc2FtZSB0aW1lLDxicj4NCiZndDsgJmd0OyAmbmJzcDsgdGhlcmUgYXJlIHJ1 bGVzIHRvIGRldGVybWluZSB3aGljaCBvbmUgc2hvdWxkIGJlIHByb2Nlc3NlZA0KZmlyc3QuPGJy Pg0KJmd0OyAmZ3Q7ICZuYnNwOyBIb3dldmVyLCB0aGVyZSBhcmUgbm8gcnVsZXMgdG8gYXZvaWQg YSBjb2xsaXNpb24gYmV0d2Vlbg0KYW4gb2ZmZXIgaW48YnI+DQomZ3Q7ICZndDsgJm5ic3A7IGFu IFVQREFURSByZXF1ZXN0IGFuZCBhbiBlcnJvciByZXNwb25zZSBmb3IgYSByZS1JTlZJVEUuDQom bmJzcDtTaW5jZSBib3RoPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyB0aGUgVVBEQVRFIHJlcXVlc3Qg YW5kIHRoZSBlcnJvciByZXNwb25zZSB3b3VsZCByZXF1ZXN0DQpjaGFuZ2VzLCBpdDxicj4NCiZn dDsgJmd0OyAmbmJzcDsgd291bGQgbm90IGJlIGNsZWFyIHdoaWNoIGNoYW5nZXMgd291bGQgbmVl ZCB0byBiZSBleGVjdXRlZA0KZmlyc3QuPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyBUaGlzIGlzIHll dCBhbm90aGVyIHJlYXNvbiB3aHkgVUFTcyBzaG91bGQgbm90IHVzZSBlcnJvcg0KcmVzcG9uc2Vz IHRvPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyB1bmRvIGFscmVhZHktZXhlY3V0ZWQgY2hhbmdlcy48 YnI+DQomZ3Q7IDxicj4NCiZndDsgSSB0aGluayBnbGFyZSBzaXR1YXRpb25zIG9jY3VyIGluIHRo cmVlIGNhc2VzLjxicj4NCiZndDsgPGJyPg0KJmd0OyAxLjxicj4NCiZndDsgJm5ic3A7fCBVUERB VEUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgNDg4KHJlSU5WSVRFKSB8PGJyPg0KJmd0OyAmbmJzcDt8 LS0tLS0tLS0tXCAmbmJzcDsgLy0tLS0tLS0tLS0tLS0tfDxicj4NCiZndDsgJm5ic3A7fCAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7XCAvICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpB Q0sgJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgWCAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KLS0tLS0tLS0mZ3Q7fDxicj4N CiZndDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7LyBcICZuYnNw OyAmbmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDsg Jm5ic3A7fCZsdDstLS0tLS0tLS8gJm5ic3A7IFwtLS0tLS0tLS0tLS0tJmd0O3w8YnI+DQomZ3Q7 ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0K Jmd0OyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgMjAwKFVQREFURSl8PGJyPg0KJmd0OyAmbmJzcDt8Jmx0Oy0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLXw8YnI+DQomZ3Q7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgPGJyPg0KJmd0OyAyLjxicj4NCiZndDsgJm5ic3A7fCBV UERBVEUgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOw0KJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAmbmJzcDt8LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tJmd0O3w8YnI+DQomZ3Q7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzIwMChVUERBVEUpDQp8PGJyPg0KJmd0OyAm bmJzcDt8Jmx0Oy0tLS0tLS0tXCAmbmJzcDsgLy0tLS0tLS0tLS0tLS0tKzxicj4NCiZndDsgJm5i c3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7XCAvICZuYnNwOyAmbmJzcDsg Jm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDsgJm5ic3A7fCAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFggJm5ic3A7ICZuYnNwOyAmbmJzcDsN CiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDt8PGJyPg0KJmd0OyAmbmJzcDt8ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsvIFwgNDg4KHJlSU5WSVRFKSB8PGJyPg0K Jmd0OyAmbmJzcDt8Jmx0Oy0tLS0tLS0tLyAmbmJzcDsgXC0tLS0tLS0tLS0tLS0tKzxicj4NCiZn dDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7QUNLICZuYnNwOyAmbmJzcDsgfDxicj4NCiZndDsgJm5i c3A7fCAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOw0KLS0tLS0tLS0mZ3Q7fDxicj4NCiZndDsgJm5ic3A7fCAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA8YnI+DQomZ3Q7IDMuPGJyPg0KJmd0OyAm bmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyA0 ODgocmVJTlZJVEUpfDxicj4NCiZndDsgJm5ic3A7fCZsdDstLS0tLS0tLVwgJm5ic3A7IC8tLS0t LS0tLS0tLS0tLXw8YnI+DQomZ3Q7ICZuYnNwO3wgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwO1wgLyAmbmJzcDsgJm5ic3A7ICZuYnNwO0FDSw0KJm5ic3A7ICZuYnNwOyAmbmJzcDt8 PGJyPg0KJmd0OyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgWCAm bmJzcDsgJm5ic3A7ICZuYnNwOy0tLS0tLS0tLSZndDt8PGJyPg0KJmd0OyAmbmJzcDt8ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsvIFwgJm5ic3A7ICZuYnNwOyAmbmJzcDsNCiZu YnNwO1VQREFURSB8PGJyPg0KJmd0OyAmbmJzcDt8ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAvICZuYnNwOyBcLS0tLS0tLS0tLS0tLS18PGJyPg0KJmd0OyAmbmJzcDt8ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOy8gJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KJm5i c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHw8YnI+DQomZ3Q7ICZuYnNwO3wgJm5ic3A7ICZuYnNw OyAmbmJzcDsgLyAmbmJzcDsyMDAoVVBEQVRFKSAmbmJzcDsgJm5ic3A7ICZuYnNwOw0KfDxicj4N CiZndDsgJm5ic3A7fC0tLS0tLS8tLS0tLS0tLS0tLS0tLS0tLS0tLSZndDt8PGJyPg0KJmd0OyAm bmJzcDt8ICZuYnNwOyAmbmJzcDsgLyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOw0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO3w8YnI+DQomZ3Q7ICZu YnNwO3wmbHQ7LS0tLyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyB8PGJyPg0KJmd0OyAmbmJzcDt8ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7PGJyPg0KJmd0OyA8YnI+DQom Z3Q7IDxicj4NCiZndDsgJmd0OzYuICZuYnNwO1VBQyBCZWhhdmlvcjxicj4NCiZndDsgJmd0OyAm bmJzcDsgSW4gb3JkZXIgdG8gY29wZSB3aXRoIHRoaXMgdHlwZSBvZiBVQVMsIGEgVUFDIHRoYXQg cmVjZWl2ZXMNCmFuIGVycm9yPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyByZXNwb25zZSB0byBhIHJl LUlOVklURSBmb3Igd2hpY2ggY2hhbmdlcyBoYXZlIGJlZW4gYWxyZWFkeQ0KZXhlY3V0ZWQ8YnI+ DQomZ3Q7ICZndDsgJm5ic3A7IFNIT1VMRCBnZW5lcmF0ZSBhIG5ldyByZS1JTlZJVEUgb3IgVVBE QVRFIHJlcXVlc3QgaW4gb3JkZXINCnRvIG1ha2U8YnI+DQomZ3Q7ICZndDsgJm5ic3A7IHN1cmUg dGhhdCBib3RoIFVBcyBoYXZlIGEgY29tbW9uIHZpZXcgb2YgdGhlIHN0YXRlIG9mDQp0aGUgc2Vz c2lvbi48YnI+DQomZ3Q7IDxicj4NCiZndDsgSWYgYWxsIGNoYW5nZXMgYXJlIHRoZSByZXN1bHRz IG9mIG9ubHkgcmUtSU5WSVRFIGFuZCBQUkFSSywgSSB0aGluazxicj4NCiZndDsgbmV3IFVQREFU RShvciByZS1JTlZJVEUpIHJlcXVlc3QgaXMgbm90IG5lY2Vzc2FyeS48YnI+DQomZ3Q7IDxicj4N CiZndDsgUmVnYXJkcyw8YnI+DQomZ3Q7IFNoaW5qaTxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IFBhdWwgS3l6aXZhdCAmbHQ7cGt5eml2YXRAY2lzY28uY29tJmd0Ozxicj4NCiZndDsg Jmd0O0dvbnphbG8sPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7VGhhbmtzIGZvciBkb2lu ZyB0aGlzIHdvcmshIEkgZG8gaGF2ZSBzb21lIGNvbW1lbnRzOjxicj4NCiZndDsgJmd0Ozxicj4N CiZndDsgJmd0O1NlY3Rpb24gMy9GaWd1cmUgMTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0 O1RoZSBmaWd1cmUgc2hvd3MgYSA2eHggcmVzcG9uc2UuPGJyPg0KJmd0OyAmZ3Q7VGhlIHRleHQg c2F5cyB0aGF0IHRoZSBVQVMgd2FudHMgdG8gcmVqZWN0IHRoZSBuZXcgb2ZmZXIuPGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7QSBVQVMgd291bGQgcHJvYmFibHkgbm90IHVzZSBhIDZ4eCBy ZXNwb25zZSB0byByZWplY3QgbWVkaWEuPGJyPg0KJmd0OyAmZ3Q7KEkgZ3Vlc3MgaXQgbWlnaHQg dXNlIDYwNiwgYnV0IDQ4OCB3b3VsZCBiZSBtb3JlIGFwcHJvcHJpYXRlLik8YnI+DQomZ3Q7ICZn dDtJbiBmYWN0LCBpdCBwcm9iYWJseSB3b3VsZCBub3QgcmVqZWN0IHRoZSByZXF1ZXN0IGF0IGFs bCwgYnV0DQpyYXRoZXIgPGJyPg0KJmd0OyAmZ3Q7d291bGQganVzdCByZWZ1c2UgdGhlIGFkZGVk IG1lZGlhIHN0cmVhbS48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDtUaGUgcG9pbnQgYmVp bmcgbWFkZSBkb2Vzbid0IHJlcXVpcmUgdGhhdCB0aGUgcmVzcG9uc2UgYmUgNnh4DQpvciB0aGF0 IGl0IDxicj4NCiZndDsgJmd0O2JlIHdpdGggdGhlIHB1cnBvc2Ugb2YgcmVmdXNpbmcgdGhlIG1l ZGlhLiBTbyBJIHRoaW5rIHdoYXQgaXMNCm5lZWRlZCA8YnI+DQomZ3Q7ICZndDtoZXJlIGlzIHRv IGZpbmQgYSBwbGF1c2libGUgZXhhbXBsZSB0byBtYWtlIHRoZSBwb2ludC48YnI+DQomZ3Q7ICZn dDs8YnI+DQomZ3Q7ICZndDtBIGdvb2Qgb25lIGZvciB0aGUgcHVycG9zZSBoZXJlIG1pZ2h0IGJl IGEgNDg4IHRvIHJlamVjdCB0aGUgbWVkaWEsDQpvciBhIDxicj4NCiZndDsgJmd0OyAmbmJzcDs0 MDEgcmVzcG9uc2UgYXMgYW5vdGhlciBzb3J0IG9mIHJlYXNvbiBmb3IgcmVqZWN0aW5nIHRoZQ0K d2hvbGUgdGhpbmcgPGJyPg0KJmd0OyAmZ3Q7YnV0IHdhbnRpbmcgdG8gcHJlc2VydmUgd2hhdCB0 aGVyZSBpcy48YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDtTZWN0aW9uIDU6PGJyPg0KJmd0 OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7QSBjaGFuZ2UgdG8gdGhlIHNl c3Npb24gc3RhdGUgaXMgY29uc2lkZXJlZA0KdG8gaGF2ZSBiZWVuIGV4ZWN1dGVkPGJyPg0KJmd0 OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7d2hlbiB0aGUgbmV3IG1lZGlhIHBhcmFtZXRlcnMgYXJl IGJlaW5nIHVzZWQuDQombmJzcDtUaGVyZWZvcmUsIGEgY2hhbmdlIHRvPGJyPg0KJmd0OyAmZ3Q7 Jmd0OyAmbmJzcDsgJm5ic3A7YSBzdHJlYW0gc3ViamVjdCB0byBwcmVjb25kaXRpb25zIFtSRkM0 MDMyXQ0KaXMgY29uc2lkZXJlZCB0byBoYXZlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5i c3A7YmVlbiBleGVjdXRlZCB3aGVuIHRoZSBuZXcgbWVkaWEgcGFyYW1ldGVycw0Kc3RhcnQgYmVp bmcgdXNlZDsgbm90PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7d2hlbiB0aGUgcHJl Y29uZGl0aW9ucyBmb3IgdGhlIHN0cmVhbSBhcmUgbWV0Lg0KJm5ic3A7VW5zdXJwcmlzaW5nbHks IHRoZTxicj4NCiZndDsgJmd0OyZndDsgJm5ic3A7ICZuYnNwO1VBUyBjb25zaWRlcnMgdGhlIG5l dyBwYXJhbWV0ZXJzIHRvIGJlIGluIHVzZQ0Kd2hlbiBpdCBhY3R1YWxseSBzdGFydHM8YnI+DQom Z3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDt1c2luZyB0aGVtLiA8YnI+DQomZ3Q7ICZndDs8YnI+ DQomZ3Q7ICZndDtJJ20gbm90IGVudGlyZWx5IGZvbGxvd2luZyB0aGlzLiBJIHRoaW5rIHRoZXJl IG1heSBiZSBhbiBhc3N1bXB0aW9uDQpoZXJlIDxicj4NCiZndDsgJmd0O3RoYXQgdGhlIFVBQyBp cyB0aGUgb2ZmZXJlciBhbmQgdGhlIFVBUyB0aGUgYW5zd2VyZXIuIEknbSBndWVzc2luZw0KeW91 IDxicj4NCiZndDsgJmd0O2FyZSBzYXlpbmcgdGhhdCB0aGUgYW5zd2VyZXIgY29uc2lkZXJzIHRo ZSBuZXcgcGFyYW1ldGVycyB0byBiZQ0KaW4gdXNlIDxicj4NCiZndDsgJmd0O3doZW4gaXQgYWN0 dWFsbHkgc3RhcnRzIHVzaW5nIHRoZW0uPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7U2lu Y2UgdGhpcyBzZWN0aW9uIGlzIGFib3V0IHRoZSBVQVMgKGZvciB0aGUgcmVpbnZpdGUpLCB0aGlz IHBvaW50DQppcyA8YnI+DQomZ3Q7ICZndDtwcm9iYWJseSB0aGF0IHdoZW4gdGhlIFVBUyBpcyBh bHNvIHRoZSBhbnN3ZXJlciBpdCBjYW4gZGVjaWRlDQp3aGVuIHRoZSA8YnI+DQomZ3Q7ICZndDtu ZXcgbWVkaWEgaXMgaW4gdXNlIGJhc2VkIG9uIHdoZW4gaXQgc3RhcnRzIHVzaW5nIHRoZW0uPGJy Pg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7QnV0IHdoYXQgaGFwcGVucyB3aGVuIHRoZSBVQVMg aXMgdGhlIG9mZmVyZXI/IEluIHRoYXQgY2FzZSBJIHRoaW5rDQppdCA8YnI+DQomZ3Q7ICZndDtt dXN0IGFzc3VtZSB0aGUgbWVkaWEgaXMgaW4gdXNlIGFzIHNvb24gYXMgaXQgaXMgb2ZmZXJlZC4g QnV0DQptYXliZSB0aGF0IDxicj4NCiZndDsgJmd0O2lzbid0IGFsd2F5cyB0aGUgY2FzZSB3aXRo IHByZWNvbmRpdGlvbnMuIEkgZG9uJ3QgdGhpbmsgaXQgY2FuDQp3YWl0IHRpbGwgPGJyPg0KJmd0 OyAmZ3Q7aXQgcmVjZWl2ZXMgbWVkaWEsIGJlY2F1c2UgbWVkaWEgbWF5IGJlIGluIGZsaWdodCB3 aGVuIGl0IG1ha2VzDQppdHMgPGJyPg0KJmd0OyAmZ3Q7ZGVjaXNpb24uPGJyPg0KJmd0OyAmZ3Q7 PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7QXMgZGVzY3JpYmVkIGluIFNlY3Rpb24g OC4zLjEgb2YgUkZDIDMyNjQgW1JGQzMyNjRdLA0KdGhlPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbmJz cDsgJm5ic3A7VUFDIGNvbnNpZGVycyB0aGUgbmV3IHBhcmFtZXRlcnMgdG8gYmUgaW4gdXNlDQp3 aGVuIG1lZGlhIGlzIHJlY2VpdmVkPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7aW4g dGhlIG5ldyBwb3J0LCB3aGljaCBzaG91bGQgYmUgaW50ZXJwcmV0ZWQNCmFzIGZvbGxvd3M6PGJy Pg0KJmd0OyAmZ3Q7Jmd0OyA8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IFJlY2VpdmVkLCBpbiB0aGlzIGNhc2UsIG1lYW5zIHRoYXQgdGhlDQptZWRpYSBpcyBwYXNzZWQg dG8gYSBtZWRpYTxicj4NCiZndDsgJmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgc2luay4g Jm5ic3A7VGhpcyBtZWFucyB0aGF0IGlmIHRoZXJlDQppcyBhIHBsYXlvdXQgYnVmZmVyLCB0aGUg YWdlbnQ8YnI+DQomZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHdvdWxkIGNvbnRp bnVlIHRvIGxpc3RlbiBvbiB0aGUgb2xkDQpwb3J0IHVudGlsIHRoZSBtZWRpYSBvbiB0aGU8YnI+ DQomZ3Q7ICZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG5ldyBwb3J0IHJlYWNoZWQgdGhl IHRvcCBvZiB0aGUgcGxheW91dA0KYnVmZmVyLiAmbmJzcDtBdCB0aGF0IHRpbWUsIGl0PGJyPg0K Jmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBNQVkgY2Vhc2UgbGlzdGVuaW5nIGZv ciBtZWRpYSBvbiB0aGUNCm9sZCBwb3J0Ljxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O0kg ZG9uJ3Qga25vdyB3aGF0IHRoZSBhYm92ZSBoYXMgdG8gZG8gd2l0aCB0aGUgYmVoYXZpb3Igb2Yg dGhlDQpVQVMuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7Jmd0OyA5LiAmbmJzcDtDbGFy aWZpY2F0aW9ucyBvbiBUYXJnZXQgUmVmcmVzaCBSZXF1ZXN0czxicj4NCiZndDsgJmd0OyZndDsg PGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7T24gcmVjZWl2aW5nIGEgdGFyZ2V0IHJl ZnJlc2ggcmVxdWVzdCB3aXRoIGFuDQp1cGRhdGVkIHJlbW90ZSB0YXJnZXQsPGJyPg0KJmd0OyAm Z3Q7Jmd0OyAmbmJzcDsgJm5ic3A7YSBVQVMgdXBkYXRlcyB0aGUgcmVtb3RlIHRhcmdldCBvZiB0 aGUgZGlhbG9nDQppbW1lZGlhdGVseS4gJm5ic3A7VGhpczxicj4NCiZndDsgJmd0OyZndDsgJm5i c3A7ICZuYnNwO3VwZGF0ZSByZXByZXNlbnRzIHRoZSBleGVjdXRpb24gb2YgYSBzdGF0ZSBjaGFu Z2UuDQombmJzcDtUaGVyZWZvcmUsPGJyPg0KJmd0OyAmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7Zm9s bG93aW5nIHRoZSBydWxlcyBpbiBTZWN0aW9uIDUsIFVBU3MgYWx3YXlzDQpyZXR1cm4gMnh4IHJl c3BvbnNlcyB0bzxicj4NCiZndDsgJmd0OyZndDsgJm5ic3A7ICZuYnNwO3RhcmdldCByZWZyZXNo IHJlcXVlc3RzIHRoYXQgdXBkYXRlIHRoZSByZW1vdGUNCnRhcmdldC48YnI+DQomZ3Q7ICZndDs8 YnI+DQomZ3Q7ICZndDtUaGlzIGRvZXMgbm90IGFkZHJlc3MgY2FzZXMgd2hlcmUgdGhlIFVBUyBj YW5ub3QgYWNjZXB0IHRoZSBjaGFuZ2UNCndpdGggPGJyPg0KJmd0OyAmZ3Q7YSAyMDAuIFNvbWUg Y2FzZXMgdGhhdCBmYWxsIGludG8gdGhpcyBjYXRlZ29yeSBhcmU6PGJyPg0KJmd0OyAmZ3Q7PGJy Pg0KJmd0OyAmZ3Q7LSByZXF1ZXN0IGluY2x1ZGVzIGEgUmVxdWlyZSBvZiBhbiB1bnN1cHBvcnRl ZCBvcHRpb24gKGUuZy4gMTAwcmVsKTxicj4NCiZndDsgJmd0Oy0gcmVxdWVzdCBjYW5ub3QgYmUg YXV0aG9yaXplZDxicj4NCiZndDsgJmd0Oy0gc2VydmVyIG92ZXJsb2FkPGJyPg0KJmd0OyAmZ3Q7 LSBwcmVjb25kaXRpb24gZmFpbHVyZTxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O0luIGFu eSBjYXNlLCBpZiBubyBzdGF0ZSBjaGFuZ2VzIGhhdmUgYmVlbiBtYWRlIHByaW9yIHRvIHRoZSBy ZXF1ZXN0DQo8YnI+DQomZ3Q7ICZndDt3aXRoIGEgdGFyZ2V0IGNoYW5nZSwgdGhlbiB0aGVyZSBp cyBubyBpc3N1ZSB3aXRoIHJlamVjdGluZyB0aGUNCnRhcmdldCA8YnI+DQomZ3Q7ICZndDtyZWZy ZXNoIGlmIG5lZWQgYmUuPGJyPg0KJmd0OyAmZ3Q7PGJyPg0KJmd0OyAmZ3Q7VGhlIGlzc3VlIHdp dGggdGFyZ2V0IHJlZnJlc2ggaXMgdGhhdCB0aGUgVUEgc2VuZGluZyBpdCBtYXkgaGF2ZQ0KYW4g PGJyPg0KJmd0OyAmZ3Q7dXJnZW50IG5lZWQgZm9yIGl0IHRvIGJlIGFjY2VwdGVkLCBzaW5jZSBp dCBtYXkgbm90IGJlIGFibGUgdG8NCjxicj4NCiZndDsgJmd0O2NvbW11bmljYXRlIG9uIGl0cyBv bGQgYWRkcmVzcyhlcykgYW55IGxvbmdlci4gQW5kIGlmIHRoYXQgaXMNCnRoZSBjYXNlIDxicj4N CiZndDsgJmd0O2l0IG1heSBhbHNvIGhhdmUgYW4gdXJnZW50IG5lZWQgdG8gY2hhbmdlIGl0cyBt ZWRpYSBhZGRyZXNzZXMNCmFzIHdlbGwgPGJyPg0KJmd0OyAmZ3Q7Zm9yIHRoZSBzYW1lIHJlYXNv bi4gVGhhdCB3b3VsZCBiZSBtb3RpdmF0aW9uIGZvciBkb2luZyBib3RoIGF0DQpvbmNlLjxicj4N CiZndDsgJmd0Ozxicj4NCiZndDsgJmd0O0lmIGEgcmVJTlZJVEUgaW5jbHVkZXMgYSB0YXJnZXQg Y2hhbmdlLCB0aGVuIGl0cyB2ZXJ5IGRpZmZpY3VsdA0KdG8ga25vdyA8YnI+DQomZ3Q7ICZndDt3 aGVuIHRoZSBVQUMgbXVzdCBiZWdpbiB1c2luZyBpdC4gU28gSSB0aGluayB0aGUgVUFTIG11c3Qg YXNzdW1lDQppdCBtdXN0IDxicj4NCiZndDsgJmd0O2JlIGNvbnNpZGVyZWQgaW4gdXNlIGltbWVk aWF0ZWx5LiBIZW5jZSBpdCBzaG91bGQgKnRyeSogdG8gYXZvaWQNCjxicj4NCiZndDsgJmd0O3Jl amVjdGluZyB0aGUgcmVxdWVzdCwgZXZlbiBpZiBpdCBtdXN0IHJlamVjdCBhbGwgdGhlIG1lZGlh IGluDQp0aGUgPGJyPg0KJmd0OyAmZ3Q7cmVxdWVzdC4gQnV0IHRoZXJlIGlzIHN0aWxsIGEgcG9z c2liaWxpdHkgdGhhdCBpdCB3aWxsIGhhdmUgdG8NCnJlamVjdCA8YnI+DQomZ3Q7ICZndDtkdWUg dG8gYXV0aG9yaXphdGlvbiwgb3ZlcmxvYWQsIGV0Yy4gSWYgdGhhdCBpcyBkb25lIHJpZ2h0IGF3 YXkNCml0cyBubyA8YnI+DQomZ3Q7ICZndDtkaWZmZXJlbnQgdGhhbiBhbnkgcmVxdWVzdCByZWpl Y3RlZCBiZWZvcmUgYW55IGNoYW5nZXMgaGF2ZSBiZWVuDQptYWRlLjxicj4NCiZndDsgJmd0Ozxi cj4NCiZndDsgJmd0O0EgZGlmZmljdWx0IGNhc2UgaXMgd2hlcmUgYSByZUlOVklURSBoYXMgYmVl biBpbml0aWF0ZWQsIGFuZCBoYXMNCm5vdCA8YnI+DQomZ3Q7ICZndDtjb21wbGV0ZWQuIChQZXJo YXBzIGl0cyByaW5naW5nLikgVGhlbiB0aGUgVUFDIGxvc2VzIGl0cyBJUCBhZGRyZXNzDQpvciA8 YnI+DQomZ3Q7ICZndDtJUCBjb25uZWN0aXZpdHkgYW5kIG5lZWRzIHRvIG1ha2UgYSB0YXJnZXQg Y2hhbmdlLiBTbyBpdCBzZW5kcw0KYW4gVVBEQVRFIDxicj4NCiZndDsgJmd0O3dpdGggdGhlIHRh cmdldCBjaGFuZ2UuIFdoYXQgaXQgc2hvdWxkIHByb2JhYmx5IGRvIGluIHRoYXQgY2FzZQ0KaXMg Km5vdCogPGJyPg0KJmd0OyAmZ3Q7aW5jbHVkZSBhbiBvZmZlciBpbiB0aGUgVVBEQVRFLiBUaGVu IGl0IGNhbid0IGJlIHJlamVjdGVkIGZvcg0Kby9hIDxicj4NCiZndDsgJmd0O3JlYXNvbnMuIE9u Y2UgdGhhdCBpcyBkb25lIGl0IGNhbiBjb250aW51ZSB0aGUgby9hIHByb2Nlc3MsIHVwZGF0aW5n DQppdHMgPGJyPg0KJmd0OyAmZ3Q7bWVkaWEgYWRkcmVzc2VzIHdoZW4gaXQgaGFzIHRoZSBjaGFu Y2UuIE9uY2UgdGhlIFVBQyB0YXJnZXQgaGFzDQpjaGFuZ2VkLCA8YnI+DQomZ3Q7ICZndDt0aGUg VUFTIHNob3VsZCBub3QgZmFpbCB0aGUgSU5WSVRFLiBJZiBuZWVkIGJlIGl0IHNob3VsZCByZWpl Y3QNCmFsbCB0aGUgPGJyPg0KJmd0OyAmZ3Q7bWVkaWEgaW4gb3JkZXIgdG8gYXZvaWQgdGhhdC48 YnI+DQomZ3Q7ICZndDs8YnI+DQomZ3Q7ICZndDtBbm90aGVyIGRpZmZpY3VsdCBjYXNlIGlmIGlm IGEgcmVJTlZJVEUgaGFzIGJlZW4gaW5pdGlhdGVkIGFuZA0KdGhlIFVBUyA8YnI+DQomZ3Q7ICZn dDtmaW5kcyBpdCBuZWVkcyB0byBjaGFuZ2UgaXRzIGFkZHJlc3MuIFNpbWlsYXIgY29uc2lkZXJh dGlvbnMgdG8NCmFib3ZlIDxicj4NCiZndDsgJmd0O3NlZW0gdG8gYXBwbHkuPGJyPg0KJmd0OyAm Z3Q7PGJyPg0KJmd0OyAmZ3Q7RnJhbmtseSwgdGhpcyBpcyBhbGwgdmVyeSBuYXN0eSwgYW5kIHRo b3NlIGluIHRoaXMgc2l0dWF0aW9uIG1heQ0KaGF2ZSA8YnI+DQomZ3Q7ICZndDtmZXcgb3B0aW9u cyBmb3Igd2hhdCBkbyBkby4gSXQgZmVlbHMgZGVzZXJ2aW5nIG9mIGl0cyBvd24gdHJlYXRtZW50 Lg0KPGJyPg0KJmd0OyAmZ3Q7TmFtZWx5IGEgd2hvbGUgY2FsbCBmbG93IGRvY3VtZW50IHdpdGgg dmFyaW91cyB1c2UgY2FzZXMgd2hlcmUNCnRhcmdldCA8YnI+DQomZ3Q7ICZndDtjaGFuZ2UgaXMg cmVxdWlyZWQuIFByb2JhYmx5IGEgQkNQLjxicj4NCiZndDsgJmd0Ozxicj4NCiZndDsgJmd0OyAm bmJzcDsgVGhhbmtzLDxicj4NCiZndDsgJmd0OyAmbmJzcDsgUGF1bDxicj4NCiZndDsgPGJyPg0K PC90dD48L2ZvbnQ+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3Vy aXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVk Jm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJv cGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZu YnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlk ZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5i c3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQm bmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5i c3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9u Jm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkm bmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5i c3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtm b3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJz cDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJz cDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJz cDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90 aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2Fn ZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZu YnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5k aXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVl biZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZu YnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 003BACA6482575EC_=-- From gao.yang2@zte.com.cn Tue Jul 7 06:38:47 2009 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 069723A6935 for ; Tue, 7 Jul 2009 06:38:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.169 X-Spam-Level: X-Spam-Status: No, score=-96.169 tagged_above=-999 required=5 tests=[AWL=-3.979, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_37=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 ktweqK-VYNAG for ; Tue, 7 Jul 2009 06:38:45 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 1B8DF3A6E6D for ; Tue, 7 Jul 2009 06:38:42 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111641727820181; Tue, 7 Jul 2009 13:49:02 +0800 (CST) Received: from [10.30.1.239] by [10.30.17.100] with StormMail ESMTP id 12012.4786316380; Tue, 7 Jul 2009 13:58:50 +0800 (CST) In-Reply-To: <4A528AB2.7020206@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 7 Jul 2009 14:05:14 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-07 14:05:30, Serialize complete at 2009-07-07 14:05:30 Content-Type: multipart/alternative; boundary="=_alternative 002175FA482575EC_=" Cc: SIPCORE Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ICBOZXcgcmV2aXNpb24gb2YgdGhlIHJl?= =?gb2312?b?LUlOVklURSBoYW5kbGluZyBkcmFmdA==?= 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, 07 Jul 2009 13:38:47 -0000 This is a multipart message in MIME format. --=_alternative 002175FA482575EC_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNClBhdWwncyB3b3JkcyBhcmUgYWx3YXkgY29uc3RydWN0aXZlLiBBbmQgSSBqdXN0IHdh bnQgdG8gaGF2ZSBhIGZ1cnRoZXIgDQp0YWxrIGFib3V0IHR3byBwYXJ0cyBvZiB0aGUgQ29tbWVu dHM6DQoNCjEuIFRoZSBmZWFzaWJpbGl0eSBvZiB0aGUgd2F5IGluIHRoZSBkcmFmdC4NCg0KMi4g QkNQIGFuZCBzdGFuZGFyZC4NCg0KbW9yZSBpbmxpbmVzLg0KDQpUaGFua3MuDQoNCkdhbw0KDQpQ YXVsIEt5eml2YXQgPHBreXppdmF0QGNpc2NvLmNvbT4g0LTT2iAyMDA5LTA3LTA3IDA3OjM3OjIy Og0KDQo+IEdvbnphbG8sDQo+IA0KPiBUaGFua3MgZm9yIGRvaW5nIHRoaXMgd29yayEgSSBkbyBo YXZlIHNvbWUgY29tbWVudHM6DQo+IA0KPiBTZWN0aW9uIDMvRmlndXJlIDENCj4gDQo+IFRoZSBm aWd1cmUgc2hvd3MgYSA2eHggcmVzcG9uc2UuDQo+IFRoZSB0ZXh0IHNheXMgdGhhdCB0aGUgVUFT IHdhbnRzIHRvIHJlamVjdCB0aGUgbmV3IG9mZmVyLg0KPiANCj4gQSBVQVMgd291bGQgcHJvYmFi bHkgbm90IHVzZSBhIDZ4eCByZXNwb25zZSB0byByZWplY3QgbWVkaWEuDQo+IChJIGd1ZXNzIGl0 IG1pZ2h0IHVzZSA2MDYsIGJ1dCA0ODggd291bGQgYmUgbW9yZSBhcHByb3ByaWF0ZS4pDQo+IElu IGZhY3QsIGl0IHByb2JhYmx5IHdvdWxkIG5vdCByZWplY3QgdGhlIHJlcXVlc3QgYXQgYWxsLCBi dXQgcmF0aGVyIA0KPiB3b3VsZCBqdXN0IHJlZnVzZSB0aGUgYWRkZWQgbWVkaWEgc3RyZWFtLg0K PiANCj4gVGhlIHBvaW50IGJlaW5nIG1hZGUgZG9lc24ndCByZXF1aXJlIHRoYXQgdGhlIHJlc3Bv bnNlIGJlIDZ4eCBvciB0aGF0IGl0IA0KDQo+IGJlIHdpdGggdGhlIHB1cnBvc2Ugb2YgcmVmdXNp bmcgdGhlIG1lZGlhLiBTbyBJIHRoaW5rIHdoYXQgaXMgbmVlZGVkIA0KPiBoZXJlIGlzIHRvIGZp bmQgYSBwbGF1c2libGUgZXhhbXBsZSB0byBtYWtlIHRoZSBwb2ludC4NCj4gDQo+IEEgZ29vZCBv bmUgZm9yIHRoZSBwdXJwb3NlIGhlcmUgbWlnaHQgYmUgYSA0ODggdG8gcmVqZWN0IHRoZSBtZWRp YSwgb3IgYSANCg0KPiAgIDQwMSByZXNwb25zZSBhcyBhbm90aGVyIHNvcnQgb2YgcmVhc29uIGZv ciByZWplY3RpbmcgdGhlIHdob2xlIHRoaW5nIA0KPiBidXQgd2FudGluZyB0byBwcmVzZXJ2ZSB3 aGF0IHRoZXJlIGlzLg0KPiANCj4gU2VjdGlvbiA1Og0KPiANCj4gPiAgICBBIGNoYW5nZSB0byB0 aGUgc2Vzc2lvbiBzdGF0ZSBpcyBjb25zaWRlcmVkIHRvIGhhdmUgYmVlbiBleGVjdXRlZA0KPiA+ ICAgIHdoZW4gdGhlIG5ldyBtZWRpYSBwYXJhbWV0ZXJzIGFyZSBiZWluZyB1c2VkLiAgVGhlcmVm b3JlLCBhIGNoYW5nZSANCnRvDQo+ID4gICAgYSBzdHJlYW0gc3ViamVjdCB0byBwcmVjb25kaXRp b25zIFtSRkM0MDMyXSBpcyBjb25zaWRlcmVkIHRvIGhhdmUNCj4gPiAgICBiZWVuIGV4ZWN1dGVk IHdoZW4gdGhlIG5ldyBtZWRpYSBwYXJhbWV0ZXJzIHN0YXJ0IGJlaW5nIHVzZWQ7IG5vdA0KPiA+ ICAgIHdoZW4gdGhlIHByZWNvbmRpdGlvbnMgZm9yIHRoZSBzdHJlYW0gYXJlIG1ldC4gIFVuc3Vy cHJpc2luZ2x5LCB0aGUNCj4gPiAgICBVQVMgY29uc2lkZXJzIHRoZSBuZXcgcGFyYW1ldGVycyB0 byBiZSBpbiB1c2Ugd2hlbiBpdCBhY3R1YWxseSANCnN0YXJ0cw0KPiA+ICAgIHVzaW5nIHRoZW0u IA0KPiANCj4gSSdtIG5vdCBlbnRpcmVseSBmb2xsb3dpbmcgdGhpcy4gSSB0aGluayB0aGVyZSBt YXkgYmUgYW4gYXNzdW1wdGlvbiBoZXJlIA0KDQo+IHRoYXQgdGhlIFVBQyBpcyB0aGUgb2ZmZXJl ciBhbmQgdGhlIFVBUyB0aGUgYW5zd2VyZXIuIEknbSBndWVzc2luZyB5b3UgDQo+IGFyZSBzYXlp bmcgdGhhdCB0aGUgYW5zd2VyZXIgY29uc2lkZXJzIHRoZSBuZXcgcGFyYW1ldGVycyB0byBiZSBp biB1c2UgDQo+IHdoZW4gaXQgYWN0dWFsbHkgc3RhcnRzIHVzaW5nIHRoZW0uDQo+IA0KPiBTaW5j ZSB0aGlzIHNlY3Rpb24gaXMgYWJvdXQgdGhlIFVBUyAoZm9yIHRoZSByZWludml0ZSksIHRoaXMg cG9pbnQgaXMgDQo+IHByb2JhYmx5IHRoYXQgd2hlbiB0aGUgVUFTIGlzIGFsc28gdGhlIGFuc3dl cmVyIGl0IGNhbiBkZWNpZGUgd2hlbiB0aGUgDQo+IG5ldyBtZWRpYSBpcyBpbiB1c2UgYmFzZWQg b24gd2hlbiBpdCBzdGFydHMgdXNpbmcgdGhlbS4NCj4gDQo+IEJ1dCB3aGF0IGhhcHBlbnMgd2hl biB0aGUgVUFTIGlzIHRoZSBvZmZlcmVyPyBJbiB0aGF0IGNhc2UgSSB0aGluayBpdCANCj4gbXVz dCBhc3N1bWUgdGhlIG1lZGlhIGlzIGluIHVzZSBhcyBzb29uIGFzIGl0IGlzIG9mZmVyZWQuIEJ1 dCBtYXliZSB0aGF0IA0KDQo+IGlzbid0IGFsd2F5cyB0aGUgY2FzZSB3aXRoIHByZWNvbmRpdGlv bnMuIEkgZG9uJ3QgdGhpbmsgaXQgY2FuIHdhaXQgdGlsbCANCg0KPiBpdCByZWNlaXZlcyBtZWRp YSwgYmVjYXVzZSBtZWRpYSBtYXkgYmUgaW4gZmxpZ2h0IHdoZW4gaXQgbWFrZXMgaXRzIA0KPiBk ZWNpc2lvbi4NCj4gDQo+ID4gICAgQXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gOC4zLjEgb2YgUkZD IDMyNjQgW1JGQzMyNjRdLCB0aGUNCj4gPiAgICBVQUMgY29uc2lkZXJzIHRoZSBuZXcgcGFyYW1l dGVycyB0byBiZSBpbiB1c2Ugd2hlbiBtZWRpYSBpcyANCnJlY2VpdmVkDQo+ID4gICAgaW4gdGhl IG5ldyBwb3J0LCB3aGljaCBzaG91bGQgYmUgaW50ZXJwcmV0ZWQgYXMgZm9sbG93czoNCj4gPiAN Cj4gPiAgICAgICBSZWNlaXZlZCwgaW4gdGhpcyBjYXNlLCBtZWFucyB0aGF0IHRoZSBtZWRpYSBp cyBwYXNzZWQgdG8gYSANCm1lZGlhDQo+ID4gICAgICAgc2luay4gIFRoaXMgbWVhbnMgdGhhdCBp ZiB0aGVyZSBpcyBhIHBsYXlvdXQgYnVmZmVyLCB0aGUgYWdlbnQNCj4gPiAgICAgICB3b3VsZCBj b250aW51ZSB0byBsaXN0ZW4gb24gdGhlIG9sZCBwb3J0IHVudGlsIHRoZSBtZWRpYSBvbiB0aGUN Cj4gPiAgICAgICBuZXcgcG9ydCByZWFjaGVkIHRoZSB0b3Agb2YgdGhlIHBsYXlvdXQgYnVmZmVy LiAgQXQgdGhhdCB0aW1lLCANCml0DQo+ID4gICAgICAgTUFZIGNlYXNlIGxpc3RlbmluZyBmb3Ig bWVkaWEgb24gdGhlIG9sZCBwb3J0Lg0KPiANCj4gSSBkb24ndCBrbm93IHdoYXQgdGhlIGFib3Zl IGhhcyB0byBkbyB3aXRoIHRoZSBiZWhhdmlvciBvZiB0aGUgVUFTLg0KPiANCj4gPiA5LiAgQ2xh cmlmaWNhdGlvbnMgb24gVGFyZ2V0IFJlZnJlc2ggUmVxdWVzdHMNCj4gPiANCj4gPiAgICBPbiBy ZWNlaXZpbmcgYSB0YXJnZXQgcmVmcmVzaCByZXF1ZXN0IHdpdGggYW4gdXBkYXRlZCByZW1vdGUg DQp0YXJnZXQsDQo+ID4gICAgYSBVQVMgdXBkYXRlcyB0aGUgcmVtb3RlIHRhcmdldCBvZiB0aGUg ZGlhbG9nIGltbWVkaWF0ZWx5LiAgVGhpcw0KPiA+ICAgIHVwZGF0ZSByZXByZXNlbnRzIHRoZSBl eGVjdXRpb24gb2YgYSBzdGF0ZSBjaGFuZ2UuICBUaGVyZWZvcmUsDQo+ID4gICAgZm9sbG93aW5n IHRoZSBydWxlcyBpbiBTZWN0aW9uIDUsIFVBU3MgYWx3YXlzIHJldHVybiAyeHggcmVzcG9uc2Vz IA0KdG8NCj4gPiAgICB0YXJnZXQgcmVmcmVzaCByZXF1ZXN0cyB0aGF0IHVwZGF0ZSB0aGUgcmVt b3RlIHRhcmdldC4NCj4gDQo+IFRoaXMgZG9lcyBub3QgYWRkcmVzcyBjYXNlcyB3aGVyZSB0aGUg VUFTIGNhbm5vdCBhY2NlcHQgdGhlIGNoYW5nZSB3aXRoIA0KPiBhIDIwMC4gU29tZSBjYXNlcyB0 aGF0IGZhbGwgaW50byB0aGlzIGNhdGVnb3J5IGFyZToNCj4gDQo+IC0gcmVxdWVzdCBpbmNsdWRl cyBhIFJlcXVpcmUgb2YgYW4gdW5zdXBwb3J0ZWQgb3B0aW9uIChlLmcuIDEwMHJlbCkNCj4gLSBy ZXF1ZXN0IGNhbm5vdCBiZSBhdXRob3JpemVkDQo+IC0gc2VydmVyIG92ZXJsb2FkDQo+IC0gcHJl Y29uZGl0aW9uIGZhaWx1cmUNCj4gDQo+IEluIGFueSBjYXNlLCBpZiBubyBzdGF0ZSBjaGFuZ2Vz IGhhdmUgYmVlbiBtYWRlIHByaW9yIHRvIHRoZSByZXF1ZXN0IA0KPiB3aXRoIGEgdGFyZ2V0IGNo YW5nZSwgdGhlbiB0aGVyZSBpcyBubyBpc3N1ZSB3aXRoIHJlamVjdGluZyB0aGUgdGFyZ2V0IA0K PiByZWZyZXNoIGlmIG5lZWQgYmUuDQo+IA0KPiBUaGUgaXNzdWUgd2l0aCB0YXJnZXQgcmVmcmVz aCBpcyB0aGF0IHRoZSBVQSBzZW5kaW5nIGl0IG1heSBoYXZlIGFuIA0KPiB1cmdlbnQgbmVlZCBm b3IgaXQgdG8gYmUgYWNjZXB0ZWQsIHNpbmNlIGl0IG1heSBub3QgYmUgYWJsZSB0byANCj4gY29t bXVuaWNhdGUgb24gaXRzIG9sZCBhZGRyZXNzKGVzKSBhbnkgbG9uZ2VyLiBBbmQgaWYgdGhhdCBp cyB0aGUgY2FzZSANCj4gaXQgbWF5IGFsc28gaGF2ZSBhbiB1cmdlbnQgbmVlZCB0byBjaGFuZ2Ug aXRzIG1lZGlhIGFkZHJlc3NlcyBhcyB3ZWxsIA0KPiBmb3IgdGhlIHNhbWUgcmVhc29uLiBUaGF0 IHdvdWxkIGJlIG1vdGl2YXRpb24gZm9yIGRvaW5nIGJvdGggYXQgb25jZS4NCj4gDQo+IElmIGEg cmVJTlZJVEUgaW5jbHVkZXMgYSB0YXJnZXQgY2hhbmdlLCB0aGVuIGl0cyB2ZXJ5IGRpZmZpY3Vs dCB0byBrbm93IA0KPiB3aGVuIHRoZSBVQUMgbXVzdCBiZWdpbiB1c2luZyBpdC4gU28gSSB0aGlu ayB0aGUgVUFTIG11c3QgYXNzdW1lIGl0IG11c3QgDQoNCj4gYmUgY29uc2lkZXJlZCBpbiB1c2Ug aW1tZWRpYXRlbHkuIEhlbmNlIGl0IHNob3VsZCAqdHJ5KiB0byBhdm9pZCANCj4gcmVqZWN0aW5n IHRoZSByZXF1ZXN0LCBldmVuIGlmIGl0IG11c3QgcmVqZWN0IGFsbCB0aGUgbWVkaWEgaW4gdGhl IA0KPiByZXF1ZXN0LiBCdXQgdGhlcmUgaXMgc3RpbGwgYSBwb3NzaWJpbGl0eSB0aGF0IGl0IHdp bGwgaGF2ZSB0byByZWplY3QgDQo+IGR1ZSB0byBhdXRob3JpemF0aW9uLCBvdmVybG9hZCwgZXRj LiBJZiB0aGF0IGlzIGRvbmUgcmlnaHQgYXdheSBpdHMgbm8gDQo+IGRpZmZlcmVudCB0aGFuIGFu eSByZXF1ZXN0IHJlamVjdGVkIGJlZm9yZSBhbnkgY2hhbmdlcyBoYXZlIGJlZW4gbWFkZS4NCj4g DQoNCltHYW9dIE8vQSBleGNoYW5nZSBjYW4gbm90IGJlIHByb2Nlc3NlZCBpbiBkaWFsb2cvdHJh bnNhY3Rpb24oaW5jbHVkaW5nIA0KSU5WSVRFIGFuZCBVUERBVEUpIHdoaWNoIGlzIHJlamVjdGVk IA0KZHVlIHRvIGF1dGhvcml6YXRpb24sIG92ZXJsb2FkLiBTbywgdGhlcmUgYXJlIG5vdCB0aGUg Y2FzZXMuDQoNCkJ1dCBmb3IgY2F1dGVsLCB3ZSBuZWVkIHRvIGRlbW9uc3RyYXRlIHRoYXQgdGhl cmUgaXMgbm8gY2FzZS9uZWVkIHRvIHNlbmQgDQplcnJvciBjb2RlKG5vbi0yeHgpIGFmdGVyIE8v QSBleGNoYW5nZS4gV2UgY2FuIGRlZHVjZSBhczoNClRocmVlIHByZWNvbmRpdGlvbihJTU8sIHNh dGlzZmllZCk6DQoxLiBPL0EgZXhjaGFuZ2UgaXMgaW4gYXBwbGljYXRpb24gbGV2ZWwgd2hpY2gg aXMgdXBvbiB0aGUgc2lwIGxldmVsLiBBbmQgDQpiZWZvcmUgdGhlIGFwcGxpY2F0aW9uIGxldmVs J3MgcHJvY2Vzc2luZywgc2lwIGxldmVsIHNob3VsZCBnZXQgcmVhZHkuIA0KMi4gVGhlcmUgYXJl IG9ubHkgdHdvIHNvdXJlIG9mIGVycm9yOiBhcHBsaWNhdGlvbiBsZXZlbCBpdHNlbGYgYW5kIHNp cCANCmxldmVsLiANCjMuIFRoaXMgZHJhZnQgdGFsa2VkIGFib3V0IHRoZSB3YXkgb2YgYXZvaWRp bmcgc2VuZGluZyBlcnJvciBjb2RlKG5vbi0yeHgpIA0KZm9yIGFwcGxpY2F0aW9uIGxldmVsJ3Mg cmVhc29uLCBzdWNoIGFzIHJlamVjdGluZyBtZWRpYS9tZWRpYSBzdHJlYW0uIA0KRGVkdWN0aW9u Og0KVGhlbiB0aGUgcmVtYWluaW5nIHBhcnQgaXMgZGVtb25zdHJhdGluZyB0aGVyZSBpcyBubyBj YXNlL25lZWQgdG8gc2VuZCANCmVycm9yIHNlbWFudGljcyBtZXNzYWdlKG5vbi0yeHgvQ2FuY2Vs KSBmb3Igc2lwIGxldmVsJ3MgcmVhc29uIGFmdGVyIE8vQSANCmV4Y2hhbmdlLg0KDQpJZiB0aGUg ZGVkdWN0aW9uIGNhbiBiZSBwcm92ZWQgdG8gYmUgdHJ1ZSwgdGhlbiB0aGUgd2F5IGluIHRoZSBk cmFmdCBpcyANCmZlYXNpYmxlLg0KDQo+IEEgZGlmZmljdWx0IGNhc2UgaXMgd2hlcmUgYSByZUlO VklURSBoYXMgYmVlbiBpbml0aWF0ZWQsIGFuZCBoYXMgbm90IA0KPiBjb21wbGV0ZWQuIChQZXJo YXBzIGl0cyByaW5naW5nLikgVGhlbiB0aGUgVUFDIGxvc2VzIGl0cyBJUCBhZGRyZXNzIG9yIA0K PiBJUCBjb25uZWN0aXZpdHkgYW5kIG5lZWRzIHRvIG1ha2UgYSB0YXJnZXQgY2hhbmdlLiBTbyBp dCBzZW5kcyBhbiBVUERBVEUgDQoNCj4gd2l0aCB0aGUgdGFyZ2V0IGNoYW5nZS4gV2hhdCBpdCBz aG91bGQgcHJvYmFibHkgZG8gaW4gdGhhdCBjYXNlIGlzICpub3QqIA0KDQo+IGluY2x1ZGUgYW4g b2ZmZXIgaW4gdGhlIFVQREFURS4gVGhlbiBpdCBjYW4ndCBiZSByZWplY3RlZCBmb3Igby9hIA0K PiByZWFzb25zLiBPbmNlIHRoYXQgaXMgZG9uZSBpdCBjYW4gY29udGludWUgdGhlIG8vYSBwcm9j ZXNzLCB1cGRhdGluZyBpdHMgDQoNCj4gbWVkaWEgYWRkcmVzc2VzIHdoZW4gaXQgaGFzIHRoZSBj aGFuY2UuIE9uY2UgdGhlIFVBQyB0YXJnZXQgaGFzIGNoYW5nZWQsIA0KDQo+IHRoZSBVQVMgc2hv dWxkIG5vdCBmYWlsIHRoZSBJTlZJVEUuIElmIG5lZWQgYmUgaXQgc2hvdWxkIHJlamVjdCBhbGwg dGhlIA0KPiBtZWRpYSBpbiBvcmRlciB0byBhdm9pZCB0aGF0Lg0KPiANCj4gQW5vdGhlciBkaWZm aWN1bHQgY2FzZSBpZiBpZiBhIHJlSU5WSVRFIGhhcyBiZWVuIGluaXRpYXRlZCBhbmQgdGhlIFVB UyANCj4gZmluZHMgaXQgbmVlZHMgdG8gY2hhbmdlIGl0cyBhZGRyZXNzLiBTaW1pbGFyIGNvbnNp ZGVyYXRpb25zIHRvIGFib3ZlIA0KPiBzZWVtIHRvIGFwcGx5Lg0KPiANCj4gRnJhbmtseSwgdGhp cyBpcyBhbGwgdmVyeSBuYXN0eSwgYW5kIHRob3NlIGluIHRoaXMgc2l0dWF0aW9uIG1heSBoYXZl IA0KPiBmZXcgb3B0aW9ucyBmb3Igd2hhdCBkbyBkby4gSXQgZmVlbHMgZGVzZXJ2aW5nIG9mIGl0 cyBvd24gdHJlYXRtZW50LiANCj4gTmFtZWx5IGEgd2hvbGUgY2FsbCBmbG93IGRvY3VtZW50IHdp dGggdmFyaW91cyB1c2UgY2FzZXMgd2hlcmUgdGFyZ2V0IA0KPiBjaGFuZ2UgaXMgcmVxdWlyZWQu IFByb2JhYmx5IGEgQkNQLg0KPiANCg0KW0dhb10gSSBhbSBhZ3JlZWQgdGhhdCBCQ1Aoc2hvd2lu ZyB3aGF0IGlzIGJldHRlcikgaXMgbmVlZGZ1bCwgYnV0IG5vdCANCmVub3VnaC4gRm9yIGV4YW1w bGUsIGl0IGlzIGEgaGFyZCB3b3JrIHRvIG1ha2Ugb3VyIElNUy9BUyBzeXN0ZW0gDQppbnRlcndv cmtpbmcgd2l0aCBkaWZmZXJlbnQgVUVzKFNJUCkgd2hpY2ggaGFzIGRpZmZlcmVudCBwb2ludHMg b2YgdmlldyANCmZvciBzZXNzaW9uIHN0YXRlIGFmdGVyIHVuLXN1Y2Nlc3NmdWwgUmUtSU5WSVRF Lg0KDQpBbmQgYWJzZW5jZSBvZiB0aGUgc3RhbmRhcmQoc2hvd2luZyB3aGF0IGlzIHJpZ2h0KSBm b3Igc2Vzc2lvbiBzdGF0ZSB3b3VsZCANCm1ha2luZyBlcXVpcG1lbnQtaW50ZXJ3b3JraW5nIGlu ZGV0ZXJtaW5hYmx5Lg0KDQo+ICAgIFRoYW5rcywNCj4gICAgUGF1bA0KPiANCj4gDQo+IA0KDQoN Cg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250 YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3Jn YW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lw aWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBh cmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5p Y2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3 aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBv ZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElm IHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUg b3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1l c3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBo YXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lz dGVtLg0K --=_alternative 002175FA482575EC_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+UGF1bCdzIHdvcmRzIGFyZSBhbHdheSBj b25zdHJ1Y3RpdmUuDQpBbmQgSSBqdXN0IHdhbnQgdG8gaGF2ZSBhIGZ1cnRoZXIgdGFsayBhYm91 dCB0d28gcGFydHMgb2YgdGhlIENvbW1lbnRzOjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+MS4gVGhlIGZlYXNpYmlsaXR5IG9mIHRoZSB3YXkgaW4gdGhl DQpkcmFmdC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PjIuIEJDUCBhbmQgc3RhbmRhcmQuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJzYW5zLXNlcmlmIj5tb3JlIGlubGluZXMuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFua3MuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5HYW88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0 dD5QYXVsIEt5eml2YXQgJmx0O3BreXppdmF0QGNpc2NvLmNvbSZndDsg0LTT2iAyMDA5LTA3LTA3 DQowNzozNzoyMjo8YnI+DQo8YnI+DQomZ3Q7IEdvbnphbG8sPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFRoYW5rcyBmb3IgZG9pbmcgdGhpcyB3b3JrISBJIGRvIGhhdmUgc29tZSBjb21tZW50czo8YnI+ DQomZ3Q7IDxicj4NCiZndDsgU2VjdGlvbiAzL0ZpZ3VyZSAxPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFRoZSBmaWd1cmUgc2hvd3MgYSA2eHggcmVzcG9uc2UuPGJyPg0KJmd0OyBUaGUgdGV4dCBzYXlz IHRoYXQgdGhlIFVBUyB3YW50cyB0byByZWplY3QgdGhlIG5ldyBvZmZlci48YnI+DQomZ3Q7IDxi cj4NCiZndDsgQSBVQVMgd291bGQgcHJvYmFibHkgbm90IHVzZSBhIDZ4eCByZXNwb25zZSB0byBy ZWplY3QgbWVkaWEuPGJyPg0KJmd0OyAoSSBndWVzcyBpdCBtaWdodCB1c2UgNjA2LCBidXQgNDg4 IHdvdWxkIGJlIG1vcmUgYXBwcm9wcmlhdGUuKTxicj4NCiZndDsgSW4gZmFjdCwgaXQgcHJvYmFi bHkgd291bGQgbm90IHJlamVjdCB0aGUgcmVxdWVzdCBhdCBhbGwsIGJ1dCByYXRoZXINCjxicj4N CiZndDsgd291bGQganVzdCByZWZ1c2UgdGhlIGFkZGVkIG1lZGlhIHN0cmVhbS48YnI+DQomZ3Q7 IDxicj4NCiZndDsgVGhlIHBvaW50IGJlaW5nIG1hZGUgZG9lc24ndCByZXF1aXJlIHRoYXQgdGhl IHJlc3BvbnNlIGJlIDZ4eCBvciB0aGF0DQppdCA8YnI+DQomZ3Q7IGJlIHdpdGggdGhlIHB1cnBv c2Ugb2YgcmVmdXNpbmcgdGhlIG1lZGlhLiBTbyBJIHRoaW5rIHdoYXQgaXMgbmVlZGVkDQo8YnI+ DQomZ3Q7IGhlcmUgaXMgdG8gZmluZCBhIHBsYXVzaWJsZSBleGFtcGxlIHRvIG1ha2UgdGhlIHBv aW50Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBBIGdvb2Qgb25lIGZvciB0aGUgcHVycG9zZSBoZXJl IG1pZ2h0IGJlIGEgNDg4IHRvIHJlamVjdCB0aGUgbWVkaWEsDQpvciBhIDxicj4NCiZndDsgJm5i c3A7IDQwMSByZXNwb25zZSBhcyBhbm90aGVyIHNvcnQgb2YgcmVhc29uIGZvciByZWplY3Rpbmcg dGhlIHdob2xlDQp0aGluZyA8YnI+DQomZ3Q7IGJ1dCB3YW50aW5nIHRvIHByZXNlcnZlIHdoYXQg dGhlcmUgaXMuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFNlY3Rpb24gNTo8YnI+DQomZ3Q7IDxicj4N CiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7QSBjaGFuZ2UgdG8gdGhlIHNlc3Npb24gc3RhdGUgaXMg Y29uc2lkZXJlZCB0byBoYXZlDQpiZWVuIGV4ZWN1dGVkPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAm bmJzcDt3aGVuIHRoZSBuZXcgbWVkaWEgcGFyYW1ldGVycyBhcmUgYmVpbmcgdXNlZC4gJm5ic3A7 VGhlcmVmb3JlLA0KYSBjaGFuZ2UgdG88YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO2Egc3Ry ZWFtIHN1YmplY3QgdG8gcHJlY29uZGl0aW9ucyBbUkZDNDAzMl0gaXMgY29uc2lkZXJlZA0KdG8g aGF2ZTxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7YmVlbiBleGVjdXRlZCB3aGVuIHRoZSBu ZXcgbWVkaWEgcGFyYW1ldGVycyBzdGFydA0KYmVpbmcgdXNlZDsgbm90PGJyPg0KJmd0OyAmZ3Q7 ICZuYnNwOyAmbmJzcDt3aGVuIHRoZSBwcmVjb25kaXRpb25zIGZvciB0aGUgc3RyZWFtIGFyZSBt ZXQuICZuYnNwO1Vuc3VycHJpc2luZ2x5LA0KdGhlPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz cDtVQVMgY29uc2lkZXJzIHRoZSBuZXcgcGFyYW1ldGVycyB0byBiZSBpbiB1c2Ugd2hlbg0KaXQg YWN0dWFsbHkgc3RhcnRzPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDt1c2luZyB0aGVtLiA8 YnI+DQomZ3Q7IDxicj4NCiZndDsgSSdtIG5vdCBlbnRpcmVseSBmb2xsb3dpbmcgdGhpcy4gSSB0 aGluayB0aGVyZSBtYXkgYmUgYW4gYXNzdW1wdGlvbg0KaGVyZSA8YnI+DQomZ3Q7IHRoYXQgdGhl IFVBQyBpcyB0aGUgb2ZmZXJlciBhbmQgdGhlIFVBUyB0aGUgYW5zd2VyZXIuIEknbSBndWVzc2lu Zw0KeW91IDxicj4NCiZndDsgYXJlIHNheWluZyB0aGF0IHRoZSBhbnN3ZXJlciBjb25zaWRlcnMg dGhlIG5ldyBwYXJhbWV0ZXJzIHRvIGJlIGluDQp1c2UgPGJyPg0KJmd0OyB3aGVuIGl0IGFjdHVh bGx5IHN0YXJ0cyB1c2luZyB0aGVtLjxicj4NCiZndDsgPGJyPg0KJmd0OyBTaW5jZSB0aGlzIHNl Y3Rpb24gaXMgYWJvdXQgdGhlIFVBUyAoZm9yIHRoZSByZWludml0ZSksIHRoaXMgcG9pbnQNCmlz IDxicj4NCiZndDsgcHJvYmFibHkgdGhhdCB3aGVuIHRoZSBVQVMgaXMgYWxzbyB0aGUgYW5zd2Vy ZXIgaXQgY2FuIGRlY2lkZSB3aGVuDQp0aGUgPGJyPg0KJmd0OyBuZXcgbWVkaWEgaXMgaW4gdXNl IGJhc2VkIG9uIHdoZW4gaXQgc3RhcnRzIHVzaW5nIHRoZW0uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IEJ1dCB3aGF0IGhhcHBlbnMgd2hlbiB0aGUgVUFTIGlzIHRoZSBvZmZlcmVyPyBJbiB0aGF0IGNh c2UgSSB0aGluaw0KaXQgPGJyPg0KJmd0OyBtdXN0IGFzc3VtZSB0aGUgbWVkaWEgaXMgaW4gdXNl IGFzIHNvb24gYXMgaXQgaXMgb2ZmZXJlZC4gQnV0IG1heWJlDQp0aGF0IDxicj4NCiZndDsgaXNu J3QgYWx3YXlzIHRoZSBjYXNlIHdpdGggcHJlY29uZGl0aW9ucy4gSSBkb24ndCB0aGluayBpdCBj YW4gd2FpdA0KdGlsbCA8YnI+DQomZ3Q7IGl0IHJlY2VpdmVzIG1lZGlhLCBiZWNhdXNlIG1lZGlh IG1heSBiZSBpbiBmbGlnaHQgd2hlbiBpdCBtYWtlcyBpdHMNCjxicj4NCiZndDsgZGVjaXNpb24u PGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO0FzIGRlc2NyaWJlZCBpbiBT ZWN0aW9uIDguMy4xIG9mIFJGQyAzMjY0IFtSRkMzMjY0XSwNCnRoZTxicj4NCiZndDsgJmd0OyAm bmJzcDsgJm5ic3A7VUFDIGNvbnNpZGVycyB0aGUgbmV3IHBhcmFtZXRlcnMgdG8gYmUgaW4gdXNl IHdoZW4NCm1lZGlhIGlzIHJlY2VpdmVkPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDtpbiB0 aGUgbmV3IHBvcnQsIHdoaWNoIHNob3VsZCBiZSBpbnRlcnByZXRlZCBhcw0KZm9sbG93czo8YnI+ DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFJlY2VpdmVk LCBpbiB0aGlzIGNhc2UsIG1lYW5zIHRoYXQgdGhlIG1lZGlhDQppcyBwYXNzZWQgdG8gYSBtZWRp YTxicj4NCiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBzaW5rLiAmbmJzcDtUaGlzIG1l YW5zIHRoYXQgaWYgdGhlcmUgaXMNCmEgcGxheW91dCBidWZmZXIsIHRoZSBhZ2VudDxicj4NCiZn dDsgJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB3b3VsZCBjb250aW51ZSB0byBsaXN0ZW4gb24g dGhlIG9sZCBwb3J0DQp1bnRpbCB0aGUgbWVkaWEgb24gdGhlPGJyPg0KJmd0OyAmZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7IG5ldyBwb3J0IHJlYWNoZWQgdGhlIHRvcCBvZiB0aGUgcGxheW91dA0K YnVmZmVyLiAmbmJzcDtBdCB0aGF0IHRpbWUsIGl0PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwOyAmbmJz cDsgJm5ic3A7IE1BWSBjZWFzZSBsaXN0ZW5pbmcgZm9yIG1lZGlhIG9uIHRoZSBvbGQNCnBvcnQu PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgZG9uJ3Qga25vdyB3aGF0IHRoZSBhYm92ZSBoYXMgdG8g ZG8gd2l0aCB0aGUgYmVoYXZpb3Igb2YgdGhlIFVBUy48YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0 OyA5LiAmbmJzcDtDbGFyaWZpY2F0aW9ucyBvbiBUYXJnZXQgUmVmcmVzaCBSZXF1ZXN0czxicj4N CiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO09uIHJlY2VpdmluZyBhIHRh cmdldCByZWZyZXNoIHJlcXVlc3Qgd2l0aCBhbiB1cGRhdGVkDQpyZW1vdGUgdGFyZ2V0LDxicj4N CiZndDsgJmd0OyAmbmJzcDsgJm5ic3A7YSBVQVMgdXBkYXRlcyB0aGUgcmVtb3RlIHRhcmdldCBv ZiB0aGUgZGlhbG9nIGltbWVkaWF0ZWx5Lg0KJm5ic3A7VGhpczxicj4NCiZndDsgJmd0OyAmbmJz cDsgJm5ic3A7dXBkYXRlIHJlcHJlc2VudHMgdGhlIGV4ZWN1dGlvbiBvZiBhIHN0YXRlIGNoYW5n ZS4NCiZuYnNwO1RoZXJlZm9yZSw8YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO2ZvbGxvd2lu ZyB0aGUgcnVsZXMgaW4gU2VjdGlvbiA1LCBVQVNzIGFsd2F5cyByZXR1cm4NCjJ4eCByZXNwb25z ZXMgdG88YnI+DQomZ3Q7ICZndDsgJm5ic3A7ICZuYnNwO3RhcmdldCByZWZyZXNoIHJlcXVlc3Rz IHRoYXQgdXBkYXRlIHRoZSByZW1vdGUgdGFyZ2V0Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGlz IGRvZXMgbm90IGFkZHJlc3MgY2FzZXMgd2hlcmUgdGhlIFVBUyBjYW5ub3QgYWNjZXB0IHRoZSBj aGFuZ2UNCndpdGggPGJyPg0KJmd0OyBhIDIwMC4gU29tZSBjYXNlcyB0aGF0IGZhbGwgaW50byB0 aGlzIGNhdGVnb3J5IGFyZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgLSByZXF1ZXN0IGluY2x1ZGVz IGEgUmVxdWlyZSBvZiBhbiB1bnN1cHBvcnRlZCBvcHRpb24gKGUuZy4gMTAwcmVsKTxicj4NCiZn dDsgLSByZXF1ZXN0IGNhbm5vdCBiZSBhdXRob3JpemVkPGJyPg0KJmd0OyAtIHNlcnZlciBvdmVy bG9hZDxicj4NCiZndDsgLSBwcmVjb25kaXRpb24gZmFpbHVyZTxicj4NCiZndDsgPGJyPg0KJmd0 OyBJbiBhbnkgY2FzZSwgaWYgbm8gc3RhdGUgY2hhbmdlcyBoYXZlIGJlZW4gbWFkZSBwcmlvciB0 byB0aGUgcmVxdWVzdA0KPGJyPg0KJmd0OyB3aXRoIGEgdGFyZ2V0IGNoYW5nZSwgdGhlbiB0aGVy ZSBpcyBubyBpc3N1ZSB3aXRoIHJlamVjdGluZyB0aGUgdGFyZ2V0DQo8YnI+DQomZ3Q7IHJlZnJl c2ggaWYgbmVlZCBiZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIGlzc3VlIHdpdGggdGFyZ2V0 IHJlZnJlc2ggaXMgdGhhdCB0aGUgVUEgc2VuZGluZyBpdCBtYXkgaGF2ZSBhbg0KPGJyPg0KJmd0 OyB1cmdlbnQgbmVlZCBmb3IgaXQgdG8gYmUgYWNjZXB0ZWQsIHNpbmNlIGl0IG1heSBub3QgYmUg YWJsZSB0byA8YnI+DQomZ3Q7IGNvbW11bmljYXRlIG9uIGl0cyBvbGQgYWRkcmVzcyhlcykgYW55 IGxvbmdlci4gQW5kIGlmIHRoYXQgaXMgdGhlDQpjYXNlIDxicj4NCiZndDsgaXQgbWF5IGFsc28g aGF2ZSBhbiB1cmdlbnQgbmVlZCB0byBjaGFuZ2UgaXRzIG1lZGlhIGFkZHJlc3NlcyBhcyB3ZWxs DQo8YnI+DQomZ3Q7IGZvciB0aGUgc2FtZSByZWFzb24uIFRoYXQgd291bGQgYmUgbW90aXZhdGlv biBmb3IgZG9pbmcgYm90aCBhdCBvbmNlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJZiBhIHJlSU5W SVRFIGluY2x1ZGVzIGEgdGFyZ2V0IGNoYW5nZSwgdGhlbiBpdHMgdmVyeSBkaWZmaWN1bHQgdG8N Cmtub3cgPGJyPg0KJmd0OyB3aGVuIHRoZSBVQUMgbXVzdCBiZWdpbiB1c2luZyBpdC4gU28gSSB0 aGluayB0aGUgVUFTIG11c3QgYXNzdW1lIGl0DQptdXN0IDxicj4NCiZndDsgYmUgY29uc2lkZXJl ZCBpbiB1c2UgaW1tZWRpYXRlbHkuIEhlbmNlIGl0IHNob3VsZCAqdHJ5KiB0byBhdm9pZCA8YnI+ DQomZ3Q7IHJlamVjdGluZyB0aGUgcmVxdWVzdCwgZXZlbiBpZiBpdCBtdXN0IHJlamVjdCBhbGwg dGhlIG1lZGlhIGluIHRoZQ0KPGJyPg0KJmd0OyByZXF1ZXN0LiBCdXQgdGhlcmUgaXMgc3RpbGwg YSBwb3NzaWJpbGl0eSB0aGF0IGl0IHdpbGwgaGF2ZSB0byByZWplY3QNCjxicj4NCiZndDsgZHVl IHRvIGF1dGhvcml6YXRpb24sIG92ZXJsb2FkLCBldGMuIElmIHRoYXQgaXMgZG9uZSByaWdodCBh d2F5IGl0cw0Kbm8gPGJyPg0KJmd0OyBkaWZmZXJlbnQgdGhhbiBhbnkgcmVxdWVzdCByZWplY3Rl ZCBiZWZvcmUgYW55IGNoYW5nZXMgaGF2ZSBiZWVuIG1hZGUuPGJyPg0KJmd0OyA8L3R0PjwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48dHQ+W0dhb10gTy9BIGV4Y2hh bmdlIGNhbiBub3QgYmUgcHJvY2Vzc2VkDQppbiBkaWFsb2cvdHJhbnNhY3Rpb24oaW5jbHVkaW5n IElOVklURSBhbmQgVVBEQVRFKSB3aGljaCBpcyByZWplY3RlZCA8L3R0PjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48dHQ+ZHVlIHRvIGF1dGhvcml6YXRpb24sIG92ZXJsb2Fk LiBTbywgdGhlcmUNCmFyZSBub3QgdGhlIGNhc2VzLjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBjb2xvcj1ibHVlPjx0dD5CdXQgZm9yIGNhdXRlbCwgd2UgbmVlZCB0byBkZW1v bnN0cmF0ZQ0KdGhhdCB0aGVyZSBpcyBubyBjYXNlL25lZWQgdG8gc2VuZCBlcnJvciBjb2RlKG5v bi0yeHgpIGFmdGVyIE8vQSBleGNoYW5nZS4NCldlIGNhbiBkZWR1Y2UgYXM6PC90dD48L2ZvbnQ+ DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+PHR0PlRocmVlIHByZWNvbmRpdGlvbihJTU8s IHNhdGlzZmllZCk6PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+PHR0 PjEuIE8vQSBleGNoYW5nZSBpcyBpbiBhcHBsaWNhdGlvbiBsZXZlbA0Kd2hpY2ggaXMgdXBvbiB0 aGUgc2lwIGxldmVsLiBBbmQgYmVmb3JlIHRoZSBhcHBsaWNhdGlvbiBsZXZlbCdzIHByb2Nlc3Np bmcsDQpzaXAgbGV2ZWwgc2hvdWxkIGdldCByZWFkeS4gPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGNvbG9yPWJsdWU+PHR0PjIuIFRoZXJlIGFyZSBvbmx5IHR3byBzb3VyZSBvZiBlcnJv cjogYXBwbGljYXRpb24NCmxldmVsIGl0c2VsZiBhbmQgc2lwIGxldmVsLiA8L3R0PjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48dHQ+My4gVGhpcyBkcmFmdCB0YWxrZWQgYWJv dXQgdGhlIHdheSBvZiBhdm9pZGluZw0Kc2VuZGluZyBlcnJvciBjb2RlKG5vbi0yeHgpIGZvciBh cHBsaWNhdGlvbiBsZXZlbCdzIHJlYXNvbiwgc3VjaCBhcyByZWplY3RpbmcNCm1lZGlhL21lZGlh IHN0cmVhbS4gPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+PHR0PkRl ZHVjdGlvbjo8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48dHQ+VGhl biB0aGUgcmVtYWluaW5nIHBhcnQgaXMgZGVtb25zdHJhdGluZw0KdGhlcmUgaXMgbm8gY2FzZS9u ZWVkIHRvIHNlbmQgZXJyb3Igc2VtYW50aWNzIG1lc3NhZ2Uobm9uLTJ4eC9DYW5jZWwpIGZvcg0K c2lwIGxldmVsJ3MgcmVhc29uIGFmdGVyIE8vQSBleGNoYW5nZS48L3R0PjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48dHQ+SWYgdGhlIGRlZHVjdGlvbiBjYW4gYmUg cHJvdmVkIHRvIGJlIHRydWUsDQp0aGVuIHRoZSB3YXkgaW4gdGhlIGRyYWZ0IGlzIGZlYXNpYmxl LjwvdHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+PGJyPg0KJmd0OyBBIGRpZmZpY3Vs dCBjYXNlIGlzIHdoZXJlIGEgcmVJTlZJVEUgaGFzIGJlZW4gaW5pdGlhdGVkLCBhbmQgaGFzIG5v dA0KPGJyPg0KJmd0OyBjb21wbGV0ZWQuIChQZXJoYXBzIGl0cyByaW5naW5nLikgVGhlbiB0aGUg VUFDIGxvc2VzIGl0cyBJUCBhZGRyZXNzDQpvciA8YnI+DQomZ3Q7IElQIGNvbm5lY3Rpdml0eSBh bmQgbmVlZHMgdG8gbWFrZSBhIHRhcmdldCBjaGFuZ2UuIFNvIGl0IHNlbmRzIGFuDQpVUERBVEUg PGJyPg0KJmd0OyB3aXRoIHRoZSB0YXJnZXQgY2hhbmdlLiBXaGF0IGl0IHNob3VsZCBwcm9iYWJs eSBkbyBpbiB0aGF0IGNhc2UgaXMNCipub3QqIDxicj4NCiZndDsgaW5jbHVkZSBhbiBvZmZlciBp biB0aGUgVVBEQVRFLiBUaGVuIGl0IGNhbid0IGJlIHJlamVjdGVkIGZvciBvL2ENCjxicj4NCiZn dDsgcmVhc29ucy4gT25jZSB0aGF0IGlzIGRvbmUgaXQgY2FuIGNvbnRpbnVlIHRoZSBvL2EgcHJv Y2VzcywgdXBkYXRpbmcNCml0cyA8YnI+DQomZ3Q7IG1lZGlhIGFkZHJlc3NlcyB3aGVuIGl0IGhh cyB0aGUgY2hhbmNlLiBPbmNlIHRoZSBVQUMgdGFyZ2V0IGhhcyBjaGFuZ2VkLA0KPGJyPg0KJmd0 OyB0aGUgVUFTIHNob3VsZCBub3QgZmFpbCB0aGUgSU5WSVRFLiBJZiBuZWVkIGJlIGl0IHNob3Vs ZCByZWplY3QgYWxsDQp0aGUgPGJyPg0KJmd0OyBtZWRpYSBpbiBvcmRlciB0byBhdm9pZCB0aGF0 Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBBbm90aGVyIGRpZmZpY3VsdCBjYXNlIGlmIGlmIGEgcmVJ TlZJVEUgaGFzIGJlZW4gaW5pdGlhdGVkIGFuZCB0aGUNClVBUyA8YnI+DQomZ3Q7IGZpbmRzIGl0 IG5lZWRzIHRvIGNoYW5nZSBpdHMgYWRkcmVzcy4gU2ltaWxhciBjb25zaWRlcmF0aW9ucyB0byBh Ym92ZQ0KPGJyPg0KJmd0OyBzZWVtIHRvIGFwcGx5Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBGcmFu a2x5LCB0aGlzIGlzIGFsbCB2ZXJ5IG5hc3R5LCBhbmQgdGhvc2UgaW4gdGhpcyBzaXR1YXRpb24g bWF5IGhhdmUNCjxicj4NCiZndDsgZmV3IG9wdGlvbnMgZm9yIHdoYXQgZG8gZG8uIEl0IGZlZWxz IGRlc2VydmluZyBvZiBpdHMgb3duIHRyZWF0bWVudC4NCjxicj4NCiZndDsgTmFtZWx5IGEgd2hv bGUgY2FsbCBmbG93IGRvY3VtZW50IHdpdGggdmFyaW91cyB1c2UgY2FzZXMgd2hlcmUgdGFyZ2V0 DQo8YnI+DQomZ3Q7IGNoYW5nZSBpcyByZXF1aXJlZC4gUHJvYmFibHkgYSBCQ1AuPGJyPg0KJmd0 OyA8L3R0PjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48dHQ+W0dh b10gSSBhbSBhZ3JlZWQgdGhhdCBCQ1Aoc2hvd2luZyB3aGF0DQppcyBiZXR0ZXIpIGlzIG5lZWRm dWwsIGJ1dCBub3QgZW5vdWdoLiBGb3IgZXhhbXBsZSwgaXQgaXMgYSBoYXJkIHdvcmsgdG8NCm1h a2Ugb3VyIElNUy9BUyBzeXN0ZW0gaW50ZXJ3b3JraW5nIHdpdGggZGlmZmVyZW50IFVFcyhTSVAp IHdoaWNoIGhhcyBkaWZmZXJlbnQNCnBvaW50cyBvZiB2aWV3IGZvciBzZXNzaW9uIHN0YXRlIGFm dGVyIHVuLXN1Y2Nlc3NmdWwgUmUtSU5WSVRFLjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBjb2xvcj1ibHVlPjx0dD5BbmQgYWJzZW5jZSBvZiB0aGUgc3RhbmRhcmQoc2hvd2lu ZyB3aGF0DQppcyByaWdodCkgZm9yIHNlc3Npb24gc3RhdGUgd291bGQgbWFraW5nIGVxdWlwbWVu dC1pbnRlcndvcmtpbmcgaW5kZXRlcm1pbmFibHkuPC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yPjx0dD48YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtUaGFua3MsPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7UGF1bDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCjwvdHQ+PC9m b250Pg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNw O05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2lu Jm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5i c3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlz Jm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4m bmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGln YXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJl Jm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZu YnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3Rv Jm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7Zmls ZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZp ZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7 dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJz cDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVz c2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZu YnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNw O3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7 QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNz YWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwm bmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtz Y2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZu YnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 002175FA482575EC_=-- From dworley@nortel.com Tue Jul 7 13:02:01 2009 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 ED0D23A683B for ; Tue, 7 Jul 2009 13:02:01 -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=[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 ixirwMGY2fVv for ; Tue, 7 Jul 2009 13:01:39 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 389263A67F0 for ; Tue, 7 Jul 2009 13:01:39 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n67Ju1l14388 for ; Tue, 7 Jul 2009 19:56:01 GMT Received: from [47.141.31.141] ([47.141.31.141]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 15:56:01 -0400 From: "Dale Worley" To: SIPCORE Content-Type: text/plain Organization: Nortel Networks Date: Tue, 07 Jul 2009 15:56:00 -0400 Message-Id: <1246996560.5962.37.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2009 19:56:01.0519 (UTC) FILETIME=[F4194FF0:01C9FF3C] Subject: [sipcore] draft-barnes-sipcore-rfc4244bis - hi-target 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, 07 Jul 2009 20:02:02 -0000 Given the number of hi-target values and the rate at which we have been changing them, perhaps we should have them be values of a single parameter, rather than separate parameters. That would allow extensibility of this set with fewer interoperability problems. E.g., change the BNF to: hi-target = "t" EQUAL ( "noop" / "predetermined" / "reg-uri" / "reg-uri-alias" / "mapped" ) Dale From RIFATYU@nortel.com Tue Jul 7 13:35:03 2009 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 31B313A6A18 for ; Tue, 7 Jul 2009 13:35:03 -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.001, 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 jh+Jkzm-jzGM for ; Tue, 7 Jul 2009 13:35:02 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 2EAA33A682B for ; Tue, 7 Jul 2009 13:35:01 -0700 (PDT) Received: from zcarhxm0.corp.nortel.com (zcarhxm0.corp.nortel.com [47.129.230.95]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n67KVV119584 for ; Tue, 7 Jul 2009 20:31:32 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C9FF42.226DC908" Date: Tue, 7 Jul 2009 16:33:06 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-worley-service-example-03 Thread-Index: Acn/QiH7WIGKBpV6QVW13R14ik1qmg== From: "Rifaat Shekh-Yusef" To: Subject: [sipcore] draft-worley-service-example-03 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, 07 Jul 2009 20:35:03 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01C9FF42.226DC908 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Dale, I think that you need to add more information about the interaction with Session Timers. For example, what is the expected behavior: 1. If Alice is the refresher: Is Alice expected to become the refresher for the new session with the music server? 2. If Bob is the refresher: Is the music server expected to become the new refresher? I am assuming that Bob is expected to keep forwarding the Session Timers RE-INVITEs/UPDATEs between Alice and the music server. Correct? Regards, Rifaat ------_=_NextPart_001_01C9FF42.226DC908 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable [sipcore] draft-worley-service-example-03

Dale,

I think that you need to add more = information about the interaction with Session Timers.

For example, what is the expected = behavior:

1. If Alice is the refresher: Is = Alice expected to become the refresher for the new session with the = music server?
2. If Bob is the refresher: Is = the music server expected to become the new refresher?

I am assuming that Bob is = expected to keep forwarding the Session Timers RE-INVITEs/UPDATEs = between Alice and the music server. Correct?

Regards,
 Rifaat

------_=_NextPart_001_01C9FF42.226DC908-- From dworley@nortel.com Tue Jul 7 13:39:23 2009 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 39CCF3A6E3C for ; Tue, 7 Jul 2009 13:39:23 -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=[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 dcJPB0eIK+TB for ; Tue, 7 Jul 2009 13:39:22 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id E732128C512 for ; Tue, 7 Jul 2009 13:39:04 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n67Jpwl13230 for ; Tue, 7 Jul 2009 19:51:58 GMT Received: from [47.141.31.141] ([47.141.31.141]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 15:51:42 -0400 From: "Dale Worley" To: SIPCORE Content-Type: text/plain Organization: Nortel Networks Date: Tue, 07 Jul 2009 15:51:42 -0400 Message-Id: <1246996302.5962.33.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2009 19:51:43.0263 (UTC) FILETIME=[5A2A92F0:01C9FF3C] 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: Tue, 07 Jul 2009 20:39:23 -0000 The syntax for hi-index restricts each component to be a single digit: hi-index = "index" EQUAL 1*DIGIT *("." 1*DIGIT) I think this is problematic because it allows only nine forks of a request. Better would be to allow integers. I propose that integers through 999 be allowed, on the grounds that 99 should be more than sufficient, so this leaves plenty of headroom, and that numbers through 999 can be stored in small binary formats. The BNF would be changed to: hi-index = "index" EQUAL hi-component *("." hi-component) hi-component = %x31-39 0*2DIGIT There are four instances of "digit(s)" in the text that would be replaced by "integer(s)". Dale From dworley@nortel.com Tue Jul 7 13:39:23 2009 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 56B6F28C2FF for ; Tue, 7 Jul 2009 13:39:23 -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 U9x6AaUAo4-F for ; Tue, 7 Jul 2009 13:39:22 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 742B528C52E for ; Tue, 7 Jul 2009 13:39:05 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n67JjGl11854; Tue, 7 Jul 2009 19:45:16 GMT Received: from [47.141.31.141] ([47.141.31.141]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 7 Jul 2009 15:44:59 -0400 From: "Dale Worley" To: Paul Kyzivat In-Reply-To: <4A4CFEF1.1000006@cisco.com> References: <1246556981.10099.65.camel@victoria-pingtel-com.us.nortel.com> <4A4CFEF1.1000006@cisco.com> Content-Type: text/plain Organization: Nortel Networks Date: Tue, 07 Jul 2009 15:44:58 -0400 Message-Id: <1246995898.5962.27.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 07 Jul 2009 19:45:00.0018 (UTC) FILETIME=[69D04520:01C9FF3B] Cc: SIPCORE 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: Tue, 07 Jul 2009 20:39:23 -0000 On Thu, 2009-07-02 at 14:39 -0400, Paul Kyzivat wrote: > OTOH, this is a revision to an existing RFC which had that ordering > requirement. Its possible that relaxing it might lead to interop problems. Actually, I don't think that RFC 4244 has an ordering requirement. Look at the BNF in section 4.1: History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) hi-entry = hi-targeted-to-uri *( SEMI hi-param ) hi-targeted-to-uri= name-addr hi-param = hi-index / hi-extension hi-index = "index" EQUAL 1*DIGIT *(DOT 1*DIGIT) hi-extension = generic-param > Regarding indicating that the index is required: it can be done in text, > but it can also be done in the BNF, as follows: > > History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) > > hi-entry = hi-targeted-to-uri hi-param-list > > hi-targeted-to-uri = name-addr > > hi-param-list = *(SEMI hi-option) SEMI hi-index *(hi-option) > > hi-option = hi-target / hi-aor / hi-extension > > hi-index = "index" EQUAL 1*DIGIT *("." 1*DIGIT) > > hi-target = "rc" / "cc" / "mp" / "rt" > > hi-aor = "aor" > > hi-extension = generic-param IMHO, though that is possible, it is not a good idea. In general, implementations do not enforce such restrictions in the parser even when it is possible to do so, so such BNF doesn't correspond closely to the implementation. And BNF like this is more complex, making it easier to make errors in both the BNF and its implementation. (E.g., the above rule for "hi-param-list" is missing an instance of "SEMI".) Dale From ietf.hanserik@gmail.com Wed Jul 8 02:32:35 2009 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 23AE228C4C5 for ; Wed, 8 Jul 2009 02:32:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.495 X-Spam-Level: X-Spam-Status: No, score=-2.495 tagged_above=-999 required=5 tests=[AWL=0.103, 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 VHEWik+wduYm for ; Wed, 8 Jul 2009 02:32:34 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id D907428C3E8 for ; Wed, 8 Jul 2009 02:32:33 -0700 (PDT) Received: by ewy26 with SMTP id 26so1409683ewy.37 for ; Wed, 08 Jul 2009 02:32:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=VUoHKCXibHD+3ayYoqCXiN2OApGnVWwijdnlO7S2yaU=; b=UNXWY8xBqaFraVBeGi9uqvafIghwiB6JLHgeWSNPw2FWk/WKQKoHrGmS4x1qZunDZp XxPNEMfZvTKdQGSsUXrzNklaWBeIPqUVOBebJ2ZFAGuB2lKFJa5peLVtQBmD61xkQAxU H5vg4kMu6D5uT99D/30SvFqPWe22bavc2/IAE= 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=JZUUELlW7I1/wh7kgrGi9XAJTtfkJs3hGk64y5PnQ1AQPfkMBFF75r5Pb+5zAAqz5s g+CV6ZpaZkiX1lIQ1MiCxLBf0/do1B4n0jFI4ewVW7LFCbYILzptJS8kJU+rSXOPAlN1 /zvDR7cr5XoiuMxDOiDPdEXp1ChlgOMuFEqZw= MIME-Version: 1.0 Received: by 10.210.129.20 with SMTP id b20mr4995302ebd.83.1247045563955; Wed, 08 Jul 2009 02:32:43 -0700 (PDT) In-Reply-To: <1246996302.5962.33.camel@victoria-pingtel-com.us.nortel.com> References: <1246996302.5962.33.camel@victoria-pingtel-com.us.nortel.com> Date: Wed, 8 Jul 2009 11:32:43 +0200 Message-ID: <9ae56b1e0907080232l12d0acc4kde1a245fcabcd95a@mail.gmail.com> From: Hans Erik van Elburg To: Dale Worley Content-Type: multipart/alternative; boundary=0015174bde14dbb8b9046e2e6b9d Cc: SIPCORE 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: Wed, 08 Jul 2009 09:32:35 -0000 --0015174bde14dbb8b9046e2e6b9d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit First I thought that you had a point, but then after checking 3.6/RFC5234 it turns out that the current syntax is correct. 1*DIGIT, means 1 or more digits, which is entirely correct. Further I don't think that we should restrict the number of digits with some arbitrary limit. /Hans Erik van Elburg On Tue, Jul 7, 2009 at 9:51 PM, Dale Worley wrote: > The syntax for hi-index restricts each component to be a single digit: > > hi-index = "index" EQUAL 1*DIGIT *("." 1*DIGIT) > > I think this is problematic because it allows only nine forks of a > request. Better would be to allow integers. I propose that integers > through 999 be allowed, on the grounds that 99 should be more than > sufficient, so this leaves plenty of headroom, and that numbers through > 999 can be stored in small binary formats. > > The BNF would be changed to: > > hi-index = "index" EQUAL hi-component *("." hi-component) > > hi-component = %x31-39 0*2DIGIT > > There are four instances of "digit(s)" in the text that would be > replaced by "integer(s)". > > Dale > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --0015174bde14dbb8b9046e2e6b9d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
First I thought that you had a point, but then after checking 3.6/RFC5= 234 it turns out that the current syntax is correct.

1*DIGIT, means 1 or more digits, which is entirely correct.

Further I don't think that we should restrict the number= of digits with some arbitrary limit.

/Hans Erik van El= burg


On Tue, Jul 7, 2009 at 9:51 PM, Dale Wor= ley <dworley@nor= tel.com> wrote:
The syntax for hi-index restricts each component to be a single digit:

=A0 hi-index =3D "index" EQUAL 1*DIGIT *("." 1*DIGIT)<= br>
I think this is problematic because it allows only nine forks of a
request. =A0Better would be to allow integers. =A0I propose that integers through 999 be allowed, on the grounds that 99 should be more than
sufficient, so this leaves plenty of headroom, and that numbers through
999 can be stored in small binary formats.

The BNF would be changed to:

=A0 hi-index =3D "index" EQUAL hi-component *("." hi-c= omponent)

=A0 hi-component =3D %x31-39 0*2DIGIT

There are four instances of "digit(s)" in the text that would be<= br> replaced by "integer(s)".

Dale


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

--0015174bde14dbb8b9046e2e6b9d-- From salvatore.loreto@ericsson.com Wed Jul 8 06:50:00 2009 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 C83E33A6A6A for ; Wed, 8 Jul 2009 06:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.375 X-Spam-Level: X-Spam-Status: No, score=-6.375 tagged_above=-999 required=5 tests=[AWL=-0.126, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 QRSKEOwbphPW for ; Wed, 8 Jul 2009 06:49:59 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id C675F3A6B34 for ; Wed, 8 Jul 2009 06:49:58 -0700 (PDT) X-AuditID: c1b4fb3c-b7c04ae0000036a1-53-4a548afa2f7d Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 4E.79.13985.AFA845A4; Wed, 8 Jul 2009 14:03:07 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Jul 2009 14:03:06 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 8 Jul 2009 14:03:05 +0200 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E079E23F6; Wed, 8 Jul 2009 15:03:04 +0300 (EEST) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 9671021A07; Wed, 8 Jul 2009 15:03:04 +0300 (EEST) Received: from localhost.localdomain (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 4D486219CC; Wed, 8 Jul 2009 15:03:04 +0300 (EEST) Message-ID: <4A548AF7.6020505@ericsson.com> Date: Wed, 08 Jul 2009 15:03:03 +0300 From: Salvatore Loreto User-Agent: Thunderbird 2.0.0.21 (X11/20090320) MIME-Version: 1.0 To: Vijay Gurbani References: <4A49AC25.7010602@alcatel-lucent.com> In-Reply-To: <4A49AC25.7010602@alcatel-lucent.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-OriginalArrivalTime: 08 Jul 2009 12:03:05.0691 (UTC) FILETIME=[0D3352B0:01C9FFC4] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] I-D on TCP/SCTP connection reuse 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, 08 Jul 2009 13:50:00 -0000 Hi Vijay, a question more relate to I-D.ietf-sip-connect-reuse that the draft in object. Working on draft-loreto-mmusic-sctp-sdp I have been told that no one has implemented yet TLS/SCTP as described in RFC3436 (due to several technical problems), and instead TSVwg is working on DTLS/SCTP in I-D.ietf-tsvwg-dtls-for-sctp. So maybe it should be opportune recognize this fact also in the I-D.ietf-sip-connect-reuse on Section 11 "Closing a TCP or SCTP connection", note that the *closure alert* is something TLS specific. Here you should talk more in TCP or SCTP specific way, and explain if TCP half closed is supported or not, or SCTP Graceful close. cheers Sal Vijay Gurbani wrote: > Folks: When we had moved connect-reuse ahead for IESG review, we > had decided to take out the parts dealing with reusing TCP and SCTP > connections. The plan was to have a new I-D that documents how to > use TCP and SCTP connection reuse. > > A draft along those lines is now available; please see > http://tools.ietf.org/html/draft-jain-sip-transport-layer-connection-reuse-00. > > > Any comments on it will be most helpful. At this point, we are > not sure where to target it -- sipcore is probably the closest. > But for now, if you can focus on the contents of the draft, that'll > be most helpful. > > Thank you. > > - vijay From eburger@standardstrack.com Wed Jul 8 07:19:35 2009 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 9E0403A6A78 for ; Wed, 8 Jul 2009 07:19:35 -0700 (PDT) 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 tfvKsIebxnTm for ; Wed, 8 Jul 2009 07:19:33 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id B8DDF3A68DE for ; Wed, 8 Jul 2009 07:19:31 -0700 (PDT) Received: from [66.92.144.112] (helo=[192.168.139.23]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MOXyk-0000sg-Ne; Wed, 08 Jul 2009 07:18:36 -0700 Message-Id: From: Eric Burger To: Vijay Gurbani , Paul Kyzivat , Brett Tate , Xavier Marjou In-Reply-To: <4A2C8606.7030302@cisco.com> Content-Type: multipart/signed; boundary=Apple-Mail-123-312874440; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Wed, 8 Jul 2009 08:18:50 -0400 References: <4A2B3F73.6080704@alcatel-lucent.com> <4A2C8606.7030302@cisco.com> X-Mailer: Apple Mail (2.935.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Cc: SIPCORE Subject: [sipcore] Info on INFO 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, 08 Jul 2009 14:19:35 -0000 --Apple-Mail-123-312874440 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Brett - I updated the evil table. Please take a look. Xavier - UAS behavior when receiving a legacy INFO is slightly more complex, because the UAS can reject the request (unlike RFC 2976). Vijay & Paul - Thank you SO MUCH for this thorough review. The work group and the document reflect a change that clearly is not clear enough: this is an advertising model, not an offer/answer model. There was literally one bit of textual shrapnel in Section 4 that might have lead to such confusion. Attila Sipos caught that and I fixed it in this edition of the document. That means the whole discussion of lifetimes and negotiation is moot. Responses inline. On Jun 7, 2009, at 11:31 PM, Paul Kyzivat wrote: > Vijay, > > Wow! A very thorough review!!! I haven't had time to do so. > I just provide a few observations inline on yours. > > Thanks, > Paul > > Vijay Gurbani wrote: >> Sorry for the long review. >> Summary statement: >> This draft is on the right track but has open issues, >> described in the review. >> First of all, thanks for tackling this particular piece of work; >> this is good stuff and it will make life easier for many >> developers. >> That said, the draft needs a substantial amount of work to be ready >> for publication, both at the editorial level and at the content >> level. >> Editorially, it is currently written in a collegial and informal >> style, which is not appropriate for a standards-track document, and >> an >> important one at that. Besides gratuitous commas and run-on >> sentences, the draft also contains phrases like "...and so on", "some >> may think", "It is the hope of this draft's authors", "we could be >> lazy ...", "we require...", "use a totally externally signaled >> channel", "can do stuff", etc. (you get the idea.) I think that >> choosing one author as an editor and allowing him a couple of free >> hours and a pint or two of beer will not be a bad idea ;-) >> General comments (3 comments): >> ------------------------------ >> 1) When talking about entities receiving or sending INFO requests, >> you >> should either stick to "UAS" and "UAC" respectively, or "server" and >> "client", respectively. As the text is now written, in some places >> "UAS" is used and in other, "server" is used. Fixed. >> 2) Should we add a subsection in S7 on INFO refresh (see comment >> number 10 in the next section for more context)? Not necessary - it's always the last thing you receive (not a negotiation). >> 3) I found the Appendix fairly useful as historical context. Is the >> idea to retain it going forward? If so, you may want to edit it >> carefully. Right now it looks like it has been written by two >> co-authors independently and then mashed together: note that SA.1 - >> SA.4 contain pretty much the same information as SA5. >> Substantive content-specific comments (24 comments) I thought about it, but then decided that it really, really does not matter. We've been going at this for two years and two weeks. It is not normative and not substantive. >> --------------------------------------------------- >> 1) S1, third paragraph, sentence on line 9: what you are describing >> here is more akin to a problem of deciding how to render a JPEG image >> instead of supporting it. The sender and receiver both support the >> JPEG image, where "support" means they will send and receive the >> image; it is just that the receiver does not know how to render the >> image because the sender did not provide any hints when it sent the >> image. >> I think you need to phrase the discussion here in that there is a >> multiplicity of ways to render an image received with a "image/jpeg" >> MIME type and that the sender of the image needs to provide some >> hints >> to the receiver on how to render it. In much the same way, the new >> INFO package proposes to provide some hints to the receiver on how to >> make sense of the user-to-user information being exchanged in the >> INFO >> message. Enhanced. If people are still confused, they can read RFC 3458. >> 2) S1, page 5, fourth paragraph, it is stated that "This document >> provides a similar framework for INVITE-based application level >> information exchange." Do you not mean "INFO-based application level >> information exchange instead? Fixed. >> Additional comment in the same paragraph: collect all the places >> where >> you talk about SUBS/NOT in one place and distinguish them from how >> Info packages are supposed to work. Currently, you talk about >> SUBS/NOT, then you talk about INFO, and then circle back to SUBS/NOT >> and hop to INFO to close the paragraph. This leaves the reader going >> back and forth trying to bridge the gap between how SUBS/NOT differs >> from INFO. While this is okay for old SIP hands, new developers who >> do not have the history of SIP embedded in their DNA genomes will be >> completely lost. Fixed. >> 3) S1, page 6, first complete paragraph on that page: I would suggest >> that you replace "near end" and "far end" with something else; for >> instance, instead of saying "If the far end indicates it can >> receive a >> package offered by the near end,..." how about "If one peer indicates >> it can receive a package offered by the the other peer ...". The >> terms "near end" and "far end" are subjective: near to who? far from >> who? Done. >> Same paragraph, you may also want to inform the reader that the >> Recv-Info and Info-Package headers are both defined in this document. >> That is, instead of saying "The Recv-Info header indicates ...", how >> about "The Recv-Info header, defined in this document, >> indicates ...". >> Similarly for the succeeding sentence that discusses Info-Package. Yup. >> 4) Section 3 requires a lot of work, IMHO; more so because this is a >> very important section and lays down the behavior of the >> communicating >> entities. As such, as much as we can avoid ambiguity here and >> provide >> clear instructions to developers, the better off we'd be in the long >> run. The next few issues are around making this section less >> ambiguous. >> S3.1, general comment on the section: it appears that this section >> has been written while keeping a UAS in mind. It will be much better >> if this section was broken down into two subsections, one discussing >> UAS behavior and the other discussing UAC behavior. >> 5) S3.1, first paragraph: As I read this paragraph, is becomes >> obvious >> that if we do not specify in some detail how the negotiation for >> sending Recv-Info is done, we could run into interoperability >> problems. For instance, given the INVITE transaction, I can see at >> least two ways to probe for support of this package: >> i) Initiating-UA triggered INFO package negotiation: >> INVITE sip:... >> Recv-Info: foo, bar >> ... >> 180 Ringing sip:... >> Recv-Info: bar >> or >> ii) Target-UA triggered INFO package negotiation: >> INVITE sip:... >> ... >> 180 Ringing SIP/2.0 >> Recv-Info: foo, bar >> ... >> ACK sip:... >> Recv-Info: bar >> In case (i), the UAS could have indicated support for the INFO >> packages in a 200 as well. In case (i), the ACK will not have any >> Recv-Info headers (please confirm.) >> Now, to make matters more complex, from the table in S5.2, it appears >> that INFO negotiations can be done in a PRACK/200 and an UPDATE/200 >> as >> well. While doing the INFO negotiation in UPDATE/200 is fine, I am >> curious why we would want to do it in PRACK/200, since that >> particular >> transaction is nested within the INVITE transaction (thus adding more >> complexity when it could easily be avoided.) Is that the intent? Are >> we sure we want to add this additional complexity on top of PRACK? >> Is >> there a good reason why we would want to take on additional >> complexity >> introduced by PRACK. If there is, we should at least provide clear >> guidelines. > > There is need to get the negotiation done well before the ACK, so > that the INVO can be used before the request is accepted. (At least > I think it is.) > > That is covered in case (1), but if it is UAS that wants to use it, > then case (2) isn't enough. This could be covered using 18x/prack. > Or it could be covered using UPDATE. > >> So, there are two specific comments here: (1) Provide better >> guidelines to implementers (see case i and ii above) including >> showing >> portions of a SIP message and flow to be more explicit on the intent; >> and (2) determine if we need to do INFO event negotiation in a PRACK, >> and if so, provide better guidelines, including showing call flows >> and >> portions of SIP messages to be more explicit of the intent. Rewritten, and really, really clear this is NOT a negotiation but and advertisement. It is much LESS complex then you thought it was. >> 6) S3.1, page 7, last paragraph, second last line: >> s/the UAS MUST list the preferred Info Package lexically earlier in >> the message./it MUST maintain an ordinal sequence of the preferred >> Info >> Package among others./ People understand the word 'lexical' from SMTP. Only one RFC has the phrase "ordinal sequence": RFC 5401 (3491). It does not have the meaning there we want to use here. >> 7) S3.1, page 8, towards the top of the page it is said that "Listing >> a package multiple times does no harm." I am curious, why even allow >> the listing of the same package multiple times? It will make parsing >> more cumbersome and force the receiving side to maintain a larger set >> of Info packages where some elements may occur multiple times. All >> this can be trivially avoided by just mandating that packages must be >> listed once. Sigh. OK. >> 8) S3.1, the indented "NOTE" in the middle of page 8: I would advise >> to make the text more terse and more formal; something like the >> following (please feel free to edit as you see fit): >> NOTE: While an empty Recv-Info header could be used to indicate >> that the sender does not wish to receive any Info packages, such >> usage will fall short should a richer negotiation strategy be >> required at some later time. Using the value 'nil' makes the >> intent of the sender of the Recv-Info request explicit. Gone. "Just say 'nil.'" >> 9) S3.1, page 8, in the discussion on the second half of that page, I >> am lost as to your intent. The initiating UA sends an INV with >> support for two packages P and R. You do not show what the target UA >> supports -- did it support both packages, or did the target UA send a >> 200 OK with an additional package, T? You then go on to show an ACK >> going from the initiating UA with package R and T. This implies that >> there is an offer/counter-offer/answer type of negotiation, which is >> not what you had outlined in the beginning of Section 3.1. Can the >> target UA add a package that was not present in the Recv-Info header >> of the initiating UA? This is very important to clarify if we want >> to >> get the negotiation right. NO NEGOTIATION ;-) >> 10) S3.1, page 9, the paragraph "In the case of ... specified by this >> document." is a very important one and needs to be highlighted more. >> Essentially, if I read the paragraph correctly, the validity of an >> INFO message is bounded by either of the following two conditions: >> (i) The dialog is terminated normally; or >> (ii) A peer receives a dialog refresh request, but that request >> did not have a Recv-Info header in it. >> Case (i) can be characterized as the normal behavior, after all, if a >> dialog goes away, it makes sense that any state associated with it >> vanishes as well. Case (ii), however, is rather important if the >> intent of the draft is indeed to terminate Info package state if it >> is >> not refreshed by a dialog refresh request. >> Case (ii) implies that Info packages have a lifetime that may be less >> than that of the dialog in which they are contained. If that is >> indeed the case, then a mid-dialog refresh request appears to be a >> means to terminate an Info package state before the dialog itself is >> terminated. This would normally be okay, but brings to the fore >> another important question: what if a dialog usage does not have a >> mid-dialog request but the services of an Info package are no longer >> needed for the duration of the lifetime of the dialog. In such >> a case, should we come up with a specific Info-Expires header? > > This termination mid-dialog is important to ensure that 3pcc > scenarios can work. > > I don't understand your question here. If you want an info usage to > go away mid-dialog, why not use a dialog refresh to cause that? This > would be entirely analogous to termination of a session-timer mid- > session. Agree w/ Paul. Old stuff stayed. >> To make matters worse, while S3.1 appears to state that the Info >> packages may have a lifetime less than that of the dialog they are >> contained in, S4.1, fourth paragraph, appears to contradict this >> assertion. In S4.1, fourth paragraph, it is stated that "The INFO >> method has no lifetime or usage of its own ..." > >> So, some more thoughts on the lifetime of an Info package seem >> appropriate and they should be spelled out in detail in this section. >> Personally, I think that it should be okay to simply bound the >> lifetime of an Info package with that of the dialog and leave it at >> that. Exhorting implementers to expire an Info package if the dialog >> refresh did not include a Recv-Info header seems to be calling for >> more complexity than needed. Are there existing usages of Info that >> require such behavior? > > Any time you do a 3pcc transfer, one side things their dialog is > preserved, while on the other side there have been two distinct > dialogs. If the first of those supported the info pkg, but the 2nd > does not, then you need a way to renegotiate. Precisely. >> 11) S3.2, second paragraph: The second reason for why versioning is >> not supported needs to be made a bit more clear. I would suggest the >> following replacement text (edit as needed): >> A second reason for not supporting a package versioning system >> is that not all payloads are capable of encoding a version >> number. In the end, while it is easy for user agents to >> negotiate Info package support, asking them to also negotiate >> specific package versions closely ties the signaling to a >> specific payload version. Since the payload is to be >> interpreted by a transaction user, such coupling may not be >> beneficial as a general rule. No one was suggesting this. See the updated text. >> 12) S4.1, page 10, last paragraph: I am curious -- why are we >> allowing >> early INFO requests? More so since when they interact with >> forking, they seem to produce undesirable complexity. > > Well, since the poster child has always been DTMF, that is something > that is frequently desired in early dialogs. Precisely. >> RFC2976 does not mention INFO forking in the context of a initiating >> UA receiving multiple INFO messages, which is what is being discussed >> here. RFC2976 does talk about the INFO request forking, but this is >> in the context of a forking proxy sending out multiple INFO requests. >> As such, if we intend to allow the first behavior, i.e., an >> initiating >> UA receiving multiple INFO requests as result of a forked INVITE, >> then >> we'd better say a lot more than this one paragraph on the resulting >> complexity (this small paragraph is the only place in the document >> where early INFO is mentioned.) The behavior in this section for >> such >> a case is inadequately specified: should the initiating UA expect >> INFO >> requests before the provisionals or after the provisionals, or does >> it >> not matter? What if PRACK is used? Should the target UA wait for a >> PRACK before it sends an INFO? And so on. >> IMHO, since we are defining new behavior for INFO, why take on >> additional complexity in the form of burdening the initiating UA with >> receiving multiple INFO requests? Is there a proposed Info package >> that requires such behavior? Or conversely, is there a legacy Info >> usage whose behavior we want to preserve by this complexity? If the >> answer is no, then I really think we should simply mandate that the >> INFO request is to be sent once the dialog has been established. > > Once again I think DTMF gives an example. > You might need to send it during early dialog, and in conjunction > with forking you then may be exchanging them on multiple early > dialogs. Clarified. >> 13) S4.2, second paragraph: I don't understand this -- why is it left >> to the UAC to determine whether it is "appropriate to send that >> payload to the UAS"? Should this not be the task of the Info package >> designer? In other words, all we need to say here is "If the Info >> package defines a payload, the UAC MUST include the payload and the >> MIME type described in the Info package." Clarified. >> 14) S4.2, third paragraph: The sentence here is self-evident; I am >> not >> sure why list this behavior out explicitly. Doesn't hurt? There was a lot of list discussion on this point, so I figured I would head it popping up again. >> 15) S4.2, fourth paragraph: what do you mean by "INFO proper"? I >> presume you either mean RFC2976, or the ad-hoc use of INFO in the >> Internet. If so, please restate as such. If not, please amplify the >> meaning of "INFO proper". Done. >> 16) S4.7, first paragraph, it is stated that the "UAS cannot use the >> CSeq to determine the sequence of INFO messages." I am not sure I >> understand why. Is it not the case that the CSeq number of later >> requests will be higher than the one of previous requests? Sure, >> there will be gaps, but later requests will have a CSeq number bigger >> than previous ones. >> Same section, second paragraph, it is stated that "Since overlapping >> requests will occur even if the application (Info package) does not >> allow it..." -- I don't understand why overlapping would occur if >> the Info package did not allow it? Is it because of some legacy INFO >> usage that behaves in this way? If so, simply state that as the >> reason, and if not, you may want to add text that supports why a >> developer should be prepared to handle overlapped requests if the >> Info >> package prohibits these. Clarified. >> 17) S6, last paragraph: should we not do more than "hope" that >> vendors >> who implement proprietary Info usages submit their mechanisms as Info >> package extension documents? That is, shouldn't we "require" them to >> do ss at least using a SHOULD strength? Because vendor behavior is not a protocol and there is no way to measure it. Absolutely not a RFC 2119 thing. >> 18) S7.1 - S7.11: In certain sub-sections, the text says "This >> section, [...], MUST be present..." Why the singling out of certain >> sections in this manner? Shouldn't it be the case that ALL sections >> MUST be present in an Info package extension document? If they are >> not relevant to that specific package, the package designer can >> simply >> state "N/A". As these sections are now written, if I was an Info >> package designer, I would automatically assume that some sections, >> especially those ones where it does not say that they MUST be >> present, >> can be omitted when documenting my Info package. >> I don't think that is the intent here, is it? It actually is the intent: if there is nothing to say, say nothing. Do we want Info Packages to be the first protocol to try this experiment? >> 19) S7.6 and S7.7: I think the meat of these two sub-sections deals >> with >> overlapped INFO requests, and as such, a new sub-section on this >> topic >> should be added if overlapped requests are to be allowed. The UAC >> generation of INFO requests takes only a paragraph and can be moved >> to >> its own sub-section. Likewise for UAS processing of INFO requests. The UAS/UAC reorganization should make this clearer. >> 20) S7.10, discussion in the middle of the section: The reason for >> not >> mandating TLS is not because there are "few protocol mechanisms to >> enforce this" -- indeed, there are few protocol mechanisms to enforce >> any arbitrary behavior, which is why policing network traffic is so >> lucrative a business model. The main reason why TLS is not >> sufficient >> is because of its hop-by-hop nature, intermediaries will be privy to >> any INFO package contents. Now, there really isn't a way around this >> in SIP unless you do an end-to-end certificate exchange to bootstrap >> TLS. S/MIME, which is given as an option in the draft, is academic >> since I do not believe that many SIP implementations, if any, support >> it at all. >> I am not sure what to say here except that the text needs to be >> cleaned up a bit to inform Info package designers that while TLS is >> better than nothing, it will still leak Info package bodies to >> intermediaries (i.e., remove the "few protocol mechanisms to enforce >> this" sentence.) Those Info implementations that want to protect >> their payload should use S/MIME or some other means to prevent >> intermediary eavesdropping. Clarified. >> 21) S8, in the Info-package-type production rule, why is the dot >> (".") >> used to separate parameters when everywhere else in SIP the >> semi-colon (";") plays the same role? Because I made a mistake that I fixed in the current draft. >> 22) S10: S7.11 asks Info package designers to provide >> complete and syntactically correct SIP messages as examples. >> Ironically, this very issue is violated by your examples :-) >> It would be good to provide complete messages, if possible. Sigh. I did now. I hope they are correct! >> 23) S10.1: The example in this section can also result in a situation >> where package "bar" never gets triggered even though Bob may indeed >> support it. Here's how, and please let me know if I am >> misunderstanding something here: Let's say Bob supported both "foo" >> and "bar". According to your text in S10.1, while Alice supports >> sending "bar", she can send AND receive "foo"; so she only puts "foo" >> in the Recv-Info header. >> Now, when the Recv-Info header reaches Bob, all Bob knows is that >> Alice supports receiving "foo". Bob can receive "bar", but does not >> know that Alice can indeed send "bar". So, "bar" as an Info package >> has inadvertently been cut out. This is not good, right (if I am >> missing something critical here, please do let me know.) >> If the above is indeed true, then we may have a bigger problem on our >> hands. The example in this section got me thinking about the >> distinction between Recv-Info containing package names that can be >> sent and received versus packages that can only be sent (and >> therefore, not received?) The text in S10.1 states that "Alice can >> support sending or receiving "foo" Info packages, and sending "bar" >> Info Packages." Does that mean that Alice cannot receive "bar" >> package? Only send it? >> Is there a distinction between Recv-Info containing package names >> that >> a UAC can "send", "receive" or "send and receive"? S1 starts to >> tease >> this on page 6 when it states that "Each UA enumerates which Info >> Packages it can receive." but it does not finish the discussion; much >> is left unsaid. Does that mean that when a UAC includes an Info >> package name in Recv-Info, it can only receive that type of package >> but cannot send it? In fact, how can a UAC indicate support for Info >> packages that it can send? It looks like a UAC cannot use the >> "Supported" header for this (c.f., S3.1). Similarly, how does a UAC >> include support for Info packages it can send and receive? >> Clearly, if a UAC is capable of receiving an Info package, is it not >> capable of sending it as well? In other words, consider the >> following >> exchange -- a UAC sends: >> INVITE ... >> Recv-Info: A, B >> to which a UAS replies: >> 200 OK ... >> Recv-Info: B >> And the UAC now sends an INFO request with Info package B. So, >> "receive" seems to automatically imply "send", and thereby "send and >> receive" as well. Am I correct or am I just plain missing something >> here? To me at least, this is a rather important distinction that >> ought to be spelled out. Right now I am not sure whether Recv-Info >> implies both receive and send -- I think it does, but portions of the >> draft lead me to believe otherwise. Total misunderstanding - the offending sentence that made it look like it was a negotiation was removed. >> 24) S11: I think what you are trying to do here is to establish a >> Info >> package registry in the same way that we established the tel URI >> parameter registry (RFC5341) and the sip URI parameter registry >> (RFC3969), correct? If so, I agree with the note that this section >> may be a separate document altogether since the mechanics of >> assigning >> an expert review, etc. are described in such registry documents (you >> can use RFC5341 and RFC3969 as templates.) This was language mandated by Keith. Given the reorganization of SIP/ SIPPING, I would offer the section goes away. However, that decision is above my pay grade to decide. >> Nits and editorials (11 comments) >> --------------------------------- >> 1) Abstract, first sentence: Instead of saying, "This document >> defines a new SIP INFO method", probably better to say that >> "This document provides new semantics to the INFO method of >> RFC2976, obsoleting the old usage in a backwards-compatible >> manner." >> My reason for this comment is that this document is not defining >> a new method called INFO as much as it is trying to provide a >> new context and semantics for the use of an existing method called >> INFO. Done >> 2) Abstract, paragraph three: >> s/Be mindful/The reader is urged to be mindful/ What is wrong with the imperative case? >> 3) S1, page 6, last paragraph: >> s/Conversely, this can be/Conversely, this can also be/ I could also be duplicately redundant :-) >> 4) S3, opening paragraph: >> s/To be abundantly clear, as stated/As stated OK >> 5) S3.1, page 8, towards the end of the page: >> s/send form package/send package/ done >> 6) S3.1, page 9: >> s/UA in the dial will/UA in the dialog will/ oops >> 7) S3.1, last paragraph: consider replacing "far-end" with something >> else -- something as such: >> OLD >> If the far-end UA does not indicate support for an Info package that >> the local server requires, the server MAY terminate the session with >> a CANCEL or BYE request. >> NEW >> If the UA receiving the INFO request did not indicate support >> for a required Info package, the sender of the INFO MAY >> terminate the session with a CANCEL or a BYE request. OK >> 8) S4.3, page 13, the indented "NOTE" paragraph at the top of the >> page: I think you can remove this paragraph -- you are mandating that >> a 489 be sent when the UAS receives an INFO message with a package it >> does not understand. That should be it; I think pointing out the >> link >> between INFO and NOTIFY serves only to confuse the issue. As a >> developer, I want to know what to send when I get a request I cannot >> handle. As long as the good RFC tells me to send a 489, so be it. Corrected with the move to 469. >> 9) S4.3, page 13, second paragraph: >> s/but it has no/but the INFO request has no/ >> s/as it sees fit// (i.e., remove "as it sees fit") OK >> 10) S8, first paragraph: >> s/user-to-user data exchange in SIP./INFO method./ >> Same section, second paragraph is redundant and can be easily removed >> without impacting readability or understanding. done >> 11) S12, first paragraph: >> s/improve the security of the Internet./improve the security of >> SIP-based communications./ Sigh. done. --Apple-Mail-123-312874440 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA3MDgxMjE4NTBaMCMGCSqGSIb3 DQEJBDEWBBTeLI4CyfKwwy1PULgW2PFkmcEEpTCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQArBxNkxpT5dSG8E666J2mirYpnDXv9rVmlVJCare84qsst ZsWLysdj58DAhkzCLTuemZNX6zd16FewfPpfBymjloazAkqSF8oxvN7owl9K8c/SUVY1CWdLJR6m 9fM/quWpTcQDgzScoSYKG6qKWQ9Jcarv/pIzyuhfohdmMtH9X2ZuV/YsRQ1psSAKYrM/AmHo+sfR Kh42v8mwajylKhzkrzy9vD5EXGhVUNXJOeCuKVfQnuMqzToFvsTqHbzTfFFp/uaqsTvGlc/uzre+ BaNyuKUiJRtL/KPFUO26zCLDTSYQbdlvxd/4zp5TYz/IOnudYlEuYL3J+I6bWomZ/XYCAAAAAAAA --Apple-Mail-123-312874440-- From mary.barnes@nortel.com Wed Jul 8 08:37:49 2009 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 8FF493A6BF2 for ; Wed, 8 Jul 2009 08:37:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.323 X-Spam-Level: X-Spam-Status: No, score=-6.323 tagged_above=-999 required=5 tests=[AWL=0.276, 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 5VqMW0xR81lV for ; Wed, 8 Jul 2009 08:37:48 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 72E133A6BE3 for ; Wed, 8 Jul 2009 08:37:48 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n68Fc7X13125 for ; Wed, 8 Jul 2009 15:38:08 GMT 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: Wed, 8 Jul 2009 10:40:35 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EDE5C07@zrc2hxm0.corp.nortel.com> In-Reply-To: <1246996560.5962.37.camel@victoria-pingtel-com.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis - hi-target thread-index: Acn/PefPKXQuaNDbRve78uYUpoJ8kAAo4wJA References: <1246996560.5962.37.camel@victoria-pingtel-com.us.nortel.com> From: "Mary Barnes" To: "Dale Worley" , "SIPCORE" Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - hi-target 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, 08 Jul 2009 15:37:49 -0000 Dale, I'm not sure what the alternative you suggest buys us. The current ABNF already provides the concept of a single parameter - the difference I see is whether we have the "t=3D" prepended to the parameter value. I'm not seeing that your ABNF change doesn't add extensibility either. =20 Also, the change to the parameter names hasn't been so much that there are new mechanisms being determined, but rather how we want to annotate the current mechanisms by which the targets are determined. So, I would not anticipate much churn once we get agreement on the tagging. But, we could certainly build extensibility by adding a generic-parm to the set of possible values. However, that suggests to me that we might want an IANA registry for the values. My concern here would be of course, that rather than having the tags reflect how core SIP has determined the new target, folks would be wanting to add tags that are service specific, which contradicts the intent of the hi-target.=20 Regards, Mary.=20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Worley, Dale (BL60:9D30) Sent: Tuesday, July 07, 2009 2:56 PM To: SIPCORE Subject: [sipcore] draft-barnes-sipcore-rfc4244bis - hi-target Given the number of hi-target values and the rate at which we have been changing them, perhaps we should have them be values of a single parameter, rather than separate parameters. That would allow extensibility of this set with fewer interoperability problems. E.g., change the BNF to: hi-target =3D "t" EQUAL ( "noop" / "predetermined" / "reg-uri" / "reg-uri-alias" / "mapped" ) Dale _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From theo@crazygreek.co.uk Wed Jul 8 09:19:31 2009 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 07D713A6B70 for ; Wed, 8 Jul 2009 09:19:31 -0700 (PDT) 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=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 xCcf7E7BuxZX for ; Wed, 8 Jul 2009 09:19:29 -0700 (PDT) Received: from exprod7og123.obsmtp.com (exprod7og123.obsmtp.com [64.18.2.24]) by core3.amsl.com (Postfix) with SMTP id 647A93A6A35 for ; Wed, 8 Jul 2009 09:19:29 -0700 (PDT) Received: from source ([72.14.220.152]) by exprod7ob123.postini.com ([64.18.6.12]) with SMTP ID DSNKSlTHLItcDeNxSRhu+zPEsYgTfFH499+5@postini.com; Wed, 08 Jul 2009 09:19:57 PDT Received: by fg-out-1718.google.com with SMTP id e12so1137564fga.17 for ; Wed, 08 Jul 2009 09:19:52 -0700 (PDT) MIME-Version: 1.0 Sender: theo@crazygreek.co.uk Received: by 10.86.90.13 with SMTP id n13mr2944987fgb.45.1247069992039; Wed, 08 Jul 2009 09:19:52 -0700 (PDT) In-Reply-To: <20090708142947.B8D263A6B34@core3.amsl.com> References: <20090708142947.B8D263A6B34@core3.amsl.com> From: Theo Zourzouvillys Date: Wed, 8 Jul 2009 17:19:32 +0100 X-Google-Sender-Auth: 8db53809bef2d25e Message-ID: <167dfb9b0907080919h32d1b729ya53fb391c8fec1b5@mail.gmail.com> To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: [sipcore] Fwd: New Version Notification for draft-sparks-sipcore-invfix-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, 08 Jul 2009 16:19:31 -0000 I've just submitted this which incorporates feedback and comments received on list from draft-sparks-sip-invfix-03. it would be great if people could go over the draft and give me any comments they may have. ~ Theo ---------- Forwarded message ---------- From: IETF I-D Submission Tool Date: Wed, Jul 8, 2009 at 3:29 PM Subject: New Version Notification for draft-sparks-sipcore-invfix-00 To: theo@voip.co.uk Cc: RjS@nostrum.com Filename: =A0 =A0 =A0 =A0draft-sparks-sipcore-invfix Revision: =A0 =A0 =A0 =A000 Title: =A0 =A0 =A0 =A0 =A0 Correct transaction handling for 200 responses t= o Session Initiation Protocol INVITE requests Creation_date: =A0 2009-07-06 WG ID: =A0 =A0 =A0 =A0 =A0 Independent Submission Number_of_pages: 20 Abstract: This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address an error in the specified handling of success (200 class) responses to INVITE requests. =A0Elements following RFC 3261 exactly will misidentify retransmissions of the request as a new, unassociated, request. =A0The correction involves modifying the INVITE transaction state machines. =A0The correction also changes the way responses that cannot be matched to an existing transaction are handled to address a security risk. --=20 Theo Zourzouvillys Chief Technical Officer VoIP.co.uk http://twitter.com/zourzouvillys http://crazygreek.co.uk/ From dworley@nortel.com Wed Jul 8 11:19:15 2009 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 B79493A6890 for ; Wed, 8 Jul 2009 11:19:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.704 X-Spam-Level: X-Spam-Status: No, score=-6.704 tagged_above=-999 required=5 tests=[AWL=-0.105, 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 wNiFTvVK+Osm for ; Wed, 8 Jul 2009 11:19:15 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 43F693A6A41 for ; Wed, 8 Jul 2009 11:18:46 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n68IInX02248; Wed, 8 Jul 2009 18:18:49 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 14:18:33 -0400 From: "Dale Worley" To: Hans Erik van Elburg In-Reply-To: <9ae56b1e0907080232l12d0acc4kde1a245fcabcd95a@mail.gmail.com> References: <1246996302.5962.33.camel@victoria-pingtel-com.us.nortel.com> <9ae56b1e0907080232l12d0acc4kde1a245fcabcd95a@mail.gmail.com> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 08 Jul 2009 14:18:32 -0400 Message-Id: <1247077112.3712.10.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jul 2009 18:18:33.0511 (UTC) FILETIME=[80D3DB70:01C9FFF8] Cc: SIPCORE 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: Wed, 08 Jul 2009 18:19:15 -0000 On Wed, 2009-07-08 at 11:32 +0200, Hans Erik van Elburg wrote: > First I thought that you had a point, but then after checking > 3.6/RFC5234 it turns out that the current syntax is correct. > > > 1*DIGIT, means 1 or more digits, which is entirely correct. Well, yes, I seem to have overlooked that. OK, cancel my suggestion to change the BNF. That means that we really must change the four instances of "digit(s)" to be "integer(s)" (or number(s)), as the text is now inconsistent with the BNF. Dale From dworley@nortel.com Wed Jul 8 11:22:21 2009 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 450553A6890 for ; Wed, 8 Jul 2009 11:22:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.699 X-Spam-Level: X-Spam-Status: No, score=-6.699 tagged_above=-999 required=5 tests=[AWL=-0.100, 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 REeP4ko6OFlk for ; Wed, 8 Jul 2009 11:22:20 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 3866F3A6A41 for ; Wed, 8 Jul 2009 11:22:17 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n68IKYS02073 for ; Wed, 8 Jul 2009 18:20:34 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 14:22:08 -0400 From: "Dale Worley" To: "Mary Barnes" In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EDE5C07@zrc2hxm0.corp.nortel.com> References: <1246996560.5962.37.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EDE5C07@zrc2hxm0.corp.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 08 Jul 2009 14:22:08 -0400 Message-Id: <1247077328.3712.15.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jul 2009 18:22:08.0626 (UTC) FILETIME=[010BCD20:01C9FFF9] Cc: SIPCORE Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - hi-target 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, 08 Jul 2009 18:22:21 -0000 On Wed, 2009-07-08 at 11:40 -0400, Barnes, Mary (RICH2:AR00) wrote: > I'm not sure what the alternative you suggest buys us. The current ABNF > already provides the concept of a single parameter - the difference I > see is whether we have the "t=" prepended to the parameter value. I'm > not seeing that your ABNF change doesn't add extensibility either. The text currently allows exactly one of 5 parameters. In situations like that, I prefer to model the situation as alternative values of a single parameter (whose value is an enumeration type). > My concern here would be of course, that > rather than having the tags reflect how core SIP has determined the new > target, folks would be wanting to add tags that are service specific, > which contradicts the intent of the hi-target. Yes, I can see quite a danger in that. Ironically, what we are arguing for is *minimizing* extensibility in dimension, in order to avoid proprietary extensions. I concede this point. Dale From dworley@nortel.com Wed Jul 8 11:31:58 2009 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 D5EF63A6BF8 for ; Wed, 8 Jul 2009 11:31:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.694 X-Spam-Level: X-Spam-Status: No, score=-6.694 tagged_above=-999 required=5 tests=[AWL=-0.095, 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 NXp5egF0DhLp for ; Wed, 8 Jul 2009 11:31:58 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id E5A823A6AAD for ; Wed, 8 Jul 2009 11:31:57 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n68IWLX06430 for ; Wed, 8 Jul 2009 18:32:21 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 8 Jul 2009 14:32:08 -0400 From: "Dale Worley" To: "Mary Barnes" In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EDE5C07@zrc2hxm0.corp.nortel.com> References: <1246996560.5962.37.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EDE5C07@zrc2hxm0.corp.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Wed, 08 Jul 2009 14:32:08 -0400 Message-Id: <1247077928.3712.26.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 08 Jul 2009 18:32:08.0751 (UTC) FILETIME=[66BF9BF0:01C9FFFA] Cc: SIPCORE Subject: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax 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, 08 Jul 2009 18:31:58 -0000 I'm curious why the privacy attribute of an hi-targeted-to-uri is specified by adding a header-parameter to the URI, rather than being given as a field-parameter. That is, an example of the current syntax is: ;index=1.2;mapped where I would expect: ;index=1.2;mapped;privacy=history This privacy value is an annotation of the URI, whereas the current syntax incorporates it *into* the URI. And indeed, to reconstitute the actual historical request-URI, one has to remove the Privacy header from the URI part of the name-addr, that is, the stuff inside <...>. (Although given that the historical URI can have had no header parameters (due its use as a request-URI), that processing step is not ambiguous.) In addition, the values of the 4244 Privacy header do not have exactly the same semantics as the same tokens used as values of the Privacy header. I guess that for compatibility with RFC 4244, we have to continue to record privacy and reason information in the URI this way, but I'm curious what the motivation was for this rather unusual way to represent this information. Dale From mary.barnes@nortel.com Wed Jul 8 16:22:22 2009 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 70E7D3A6FD7 for ; Wed, 8 Jul 2009 16:22:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.026 X-Spam-Level: X-Spam-Status: No, score=-6.026 tagged_above=-999 required=5 tests=[AWL=-0.027, BAYES_00=-2.599, J_CHICKENPOX_17=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 6PXtmqaoG5d0 for ; Wed, 8 Jul 2009 16:22:21 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 62E953A6FAF for ; Wed, 8 Jul 2009 16:22:21 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n68NMgX10230 for ; Wed, 8 Jul 2009 23:22:43 GMT 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: Wed, 8 Jul 2009 18:25:10 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EE3811D@zrc2hxm0.corp.nortel.com> In-Reply-To: <1247077928.3712.26.camel@victoria-pingtel-com.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-barnes-sipcore-rfc4244bis - privacy syntax thread-index: Acn/+mdR0JcjC7CxS1in6/wLWjFGCAAJzlfQ References: <1246996560.5962.37.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EDE5C07@zrc2hxm0.corp.nortel.com> <1247077928.3712.26.camel@victoria-pingtel-com.us.nortel.com> From: "Mary Barnes" To: "Dale Worley" Cc: SIPCORE Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax 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, 08 Jul 2009 23:22:22 -0000 The Privacy (and Reason) header parameters are escaped in the URI so that those headers could be reused rather than defining parameters with the same semantics specific to the History-Info header.=20 This mechanism is described in the normative section of 4244/4244bis.=20 This makes absolute sense for the Reason, since we are capturing the exact value. As far as privacy, I'm not sure what you mean with regards to " This privacy value is an annotation of the URI, whereas the current syntax incorporates it *into* the URI." The privacy value isn't incorporated into the URI - it's an escaped parameter. When the hi-entries are referenced, the UAS/application does need to be handle both the Reason and Privacy headers that might be escaped in the URI, but again that's part of the normative behavior for entities that support 4244/4244bis. Mary.=20 -----Original Message----- From: Worley, Dale (BL60:9D30)=20 Sent: Wednesday, July 08, 2009 1:32 PM To: Barnes, Mary (RICH2:AR00) Cc: SIPCORE Subject: draft-barnes-sipcore-rfc4244bis - privacy syntax I'm curious why the privacy attribute of an hi-targeted-to-uri is specified by adding a header-parameter to the URI, rather than being given as a field-parameter. That is, an example of the current syntax is: =20 ;inde= x=3D1 .2;mapped where I would expect: =20 ;index=3D1.2;mapped;pri= vac y=3Dhistory This privacy value is an annotation of the URI, whereas the current syntax incorporates it *into* the URI. And indeed, to reconstitute the actual historical request-URI, one has to remove the Privacy header from the URI part of the name-addr, that is, the stuff inside <...>. (Although given that the historical URI can have had no header parameters (due its use as a request-URI), that processing step is not ambiguous.) In addition, the values of the 4244 Privacy header do not have exactly the same semantics as the same tokens used as values of the Privacy header. I guess that for compatibility with RFC 4244, we have to continue to record privacy and reason information in the URI this way, but I'm curious what the motivation was for this rather unusual way to represent this information. Dale From gao.yang2@zte.com.cn Thu Jul 9 01:55:57 2009 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 747A43A6A31 for ; Thu, 9 Jul 2009 01:55:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.897 X-Spam-Level: X-Spam-Status: No, score=-99.897 tagged_above=-999 required=5 tests=[AWL=1.341, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_71=0.6, RCVD_DOUBLE_IP_LOOSE=0.76, 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 JTNWxXkvXJUU for ; Thu, 9 Jul 2009 01:55:56 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id F23BC3A6988 for ; Thu, 9 Jul 2009 01:55:55 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111641727820181; Thu, 9 Jul 2009 16:39:38 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 12012.6637927919; Thu, 9 Jul 2009 16:49:36 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n698uQU7052279; Thu, 9 Jul 2009 16:56:26 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: SIPCORE MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 9 Jul 2009 16:56:05 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-09 16:56:09, Serialize complete at 2009-07-09 16:56:09 Content-Type: multipart/alternative; boundary="=_alternative 003115AE482575EE_=" X-MAIL: mse2.zte.com.cn n698uQU7052279 Cc: OKUMURA Shinji Subject: [sipcore] Why "rollback" and how "rollback" // New revision of the re-INVITE handling draft 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, 09 Jul 2009 08:55:57 -0000 This is a multipart message in MIME format. --=_alternative 003115AE482575EE_= Content-Type: text/plain; charset="US-ASCII" [as individual] Why "rollback"? Choose the session state is the first step. And the reason is: 1. Obey the original concept of RFC3261; 2. It is the intuitionistic(user point of view) requirement for rejecting session modification. How "rollback"? Choose the solution of how to reach the state is the second step: There are more than one solution for this. Widely discussed solutions are: 1. draft-gaoyang-sipping-session-state-criterion-03 2. draft-camarillo-sipcore-reinvite-00 "draft-gaoyang-sipping-session-state-criterion-03" classify session modifications into different categories and specify different rules for different categories. This proposal has same merits: 1. Has no violation to current RFCs; 2. Has no racing condition problem. But Gonzalo pointed out a problem(I remember Paul said something like this, but not shocked me at that time): Impossible to understand the current state by just looking the call flow; details about the messages would be needed. Though we can avoid it by BCP, it is really a problem in theory which changes the charts' style for our engineers. So, I support "draft-camarillo-sipcore-reinvite-00" now. And we really need the regulation to making equipment interworking about this problem exercisable. =================================== Zip : 210012 Tel : 87211 Tel2 :(+86)-025-52877211 e_mail : gao.yang2@zte.com.cn =================================== -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 003115AE482575EE_= Content-Type: text/html; charset="US-ASCII"
[as individual]

Why "rollback"?
Choose the session state is the first step. And the reason is:
1. Obey the original concept of RFC3261;
2. It is the intuitionistic(user point of view) requirement for rejecting session modification.

How "rollback"?
Choose the solution of how to reach the state is the second step:
There are more than one solution for this. Widely discussed solutions are:
1. draft-gaoyang-sipping-session-state-criterion-03
2. draft-camarillo-sipcore-reinvite-00

"draft-gaoyang-sipping-session-state-criterion-03" classify session modifications into different categories and specify different rules for different categories. This proposal has same merits:
1. Has no violation to current RFCs;
2. Has no racing condition problem.
But Gonzalo pointed out a problem(I remember Paul said something like this, but not shocked me at that time): Impossible to understand the current state by just looking the call flow; details about the messages would be needed. Though we can avoid it by BCP, it is really a problem in theory which changes the charts' style for our engineers.

So, I support "draft-camarillo-sipcore-reinvite-00" now. And we really need the regulation to making equipment interworking about this problem exercisable.

===================================
Zip    : 210012
Tel    : 87211
Tel2   :(+86)-025-52877211
e_mail : gao.yang2@zte.com.cn
===================================
--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 003115AE482575EE_=-- From AUDET@nortel.com Thu Jul 9 11:07:05 2009 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 C692A28C289 for ; Thu, 9 Jul 2009 11:07:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.298 X-Spam-Level: X-Spam-Status: No, score=-6.298 tagged_above=-999 required=5 tests=[AWL=0.301, 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 ev1kz9RWEzpw for ; Thu, 9 Jul 2009 11:07:05 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id B618528C274 for ; Thu, 9 Jul 2009 11:07:04 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n69I7Ti25793 for ; Thu, 9 Jul 2009 18:07:29 GMT 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, 9 Jul 2009 13:07:12 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EE8A67C@zrc2hxm0.corp.nortel.com> In-Reply-To: <1247077928.3712.26.camel@victoria-pingtel-com.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax thread-index: Acn/+nYjiFtEFnrSSlGuT72JznUbRwAxVr0A References: <1246996560.5962.37.camel@victoria-pingtel-com.us.nortel.com><1ECE0EB50388174790F9694F77522CCF1EDE5C07@zrc2hxm0.corp.nortel.com> <1247077928.3712.26.camel@victoria-pingtel-com.us.nortel.com> From: "Francois Audet" To: "Dale Worley" , "Mary Barnes" Cc: SIPCORE Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax 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, 09 Jul 2009 18:07:05 -0000 I guess it's somewhat historical. It's basically saying that the Privacy and Reason "escaped parameters" = would=20 translate into headers if we were to created a request based on it. This whole concept falls into the category of "it came from HTTP so it = must be good (TM)".=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Worley, Dale=20 > (BL60:9D30) > Sent: Wednesday, July 08, 2009 11:32 > To: Barnes, Mary (RICH2:AR00) > Cc: SIPCORE > Subject: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax >=20 > I'm curious why the privacy attribute of an=20 > hi-targeted-to-uri is specified by adding a header-parameter=20 > to the URI, rather than being given as a field-parameter. =20 > That is, an example of the current syntax > is: >=20 > =20 > 6>;index=3D1.2;mapped >=20 > where I would expect: >=20 > =20 > ;index=3D1.2;map > ped;privacy=3Dhistory >=20 > This privacy value is an annotation of the URI, whereas the=20 > current syntax incorporates it *into* the URI. And indeed,=20 > to reconstitute the actual historical request-URI, one has to=20 > remove the Privacy header from the URI part of the name-addr,=20 > that is, the stuff inside <...>. > (Although given that the historical URI can have had no=20 > header parameters (due its use as a request-URI), that=20 > processing step is not > ambiguous.) >=20 > In addition, the values of the 4244 Privacy header do not=20 > have exactly the same semantics as the same tokens used as=20 > values of the Privacy header. >=20 > I guess that for compatibility with RFC 4244, we have to=20 > continue to record privacy and reason information in the URI=20 > this way, but I'm curious what the motivation was for this=20 > rather unusual way to represent this information. >=20 > Dale >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From AUDET@nortel.com Thu Jul 9 14:29:52 2009 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 4BC923A67FF for ; Thu, 9 Jul 2009 14:29:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.318 X-Spam-Level: X-Spam-Status: No, score=-6.318 tagged_above=-999 required=5 tests=[AWL=0.281, 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 O5NAeC1B16NU for ; Thu, 9 Jul 2009 14:29:51 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 046B628C2E3 for ; Thu, 9 Jul 2009 14:29:49 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n69LUCi15423; Thu, 9 Jul 2009 21:30:12 GMT 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, 9 Jul 2009 16:30:10 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EE8ABC1@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A4CFEF1.1000006@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis thread-index: Acn7RI5uAk88CMxtRaey+j8kR2Ix6QFlQE2A References: <1246556981.10099.65.camel@victoria-pingtel-com.us.nortel.com> <4A4CFEF1.1000006@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" , "Dale Worley" Cc: SIPCORE 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, 09 Jul 2009 21:29:52 -0000 Dale, Paul, Good catch. The intent was not to impose an ordering requirement: the intent was to impose that the hi-index parameter be present. Paul: in RFC4244 there was NO ordering requirement. What we are trying to achieve with the ABNF is: - No ordering requirement - There MUST be exactly ONE hi-index - There MUST be 0 or 1 hi-target parameter - There MUST be 0 or 1 hi-aor parameter - There MAY be any number of hi-extension I now see the current ABNF fails miserably to do this... But I don't think it's trivial to express in ABNF. So I think then that Dale's semantic is better, and we just need to clearly state that index must be present, and that there can be only 0 or 1 of each of hi-target and hi-aor. > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Thursday, July 02, 2009 11:40 > To: Worley, Dale (BL60:9D30) > Cc: SIPCORE > Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis >=20 > Dale, >=20 > I agree with your concern about the BNF. A requirement about=20 > the ordering of the params is problematic. >=20 > OTOH, this is a revision to an existing RFC which had that=20 > ordering requirement. Its possible that relaxing it might=20 > lead to interop problems. >=20 > Perhaps the best one can do is put in a recommendation to=20 > make the index first. >=20 > Regarding indicating that the index is required: it can be=20 > done in text, but it can also be done in the BNF, as follows: >=20 > History-Info =3D "History-Info" HCOLON hi-entry *(COMMA hi-entry) >=20 > hi-entry =3D hi-targeted-to-uri hi-param-list >=20 > hi-targeted-to-uri =3D name-addr >=20 > hi-param-list =3D *(SEMI hi-option) SEMI hi-index *(hi-option) >=20 > hi-option =3D hi-target / hi-aor / hi-extension >=20 > hi-index =3D "index" EQUAL 1*DIGIT *("." 1*DIGIT) >=20 > hi-target =3D "rc" / "cc" / "mp" / "rt" >=20 > hi-aor =3D "aor" >=20 > hi-extension =3D generic-param >=20 >=20 > Thanks, > Paul >=20 >=20 > Dale Worley wrote: > > Regarding the BNF for the History-Info header (section 4.1 in the=20 > > draft version of -02): > >=20 > > The current BNF requires that the "index" parameter appear=20 > immediately=20 > > after the URI, whereas other parameters appear after it: > >=20 > > History-Info =3D "History-Info" HCOLON hi-entry *(COMMA hi-entry) > >=20 > > hi-entry =3D hi-targeted-to-uri SEMI hi-index *(SEMI hi-param) > >=20 > > hi-targeted-to-uri =3D name-addr > >=20 > > hi-index =3D "index" EQUAL 1*DIGIT *("." 1*DIGIT) > >=20 > > hi-param =3D hi-target/hi-aor/hi-extension > >=20 > > hi-target =3D "rc" / "cc" / "mp" / "rt" > >=20 > > hi-aor =3D "aor" > >=20 > > hi-extension =3D generic-param > >=20 > > IMHO, this is not a good way to organize the grammar, as it=20 > makes it=20 > > difficult to generate hi-entry's with generic code (there=20 > needs to be=20 > > some way to constrain the "index" parameter to be first),=20 > and violates=20 > > the general rule that the order of parameters is not significant. > >=20 > > I propose to adjust the BNF to: > >=20 > > History-Info =3D "History-Info" HCOLON hi-entry *(COMMA hi-entry) > >=20 > > hi-entry =3D hi-targeted-to-uri *(SEMI hi-param) > >=20 > > hi-targeted-to-uri =3D name-addr > >=20 > > hi-param =3D hi-index / hi-target / hi-aor / hi-extension > >=20 > > hi-index =3D "index" EQUAL 1*DIGIT *("." 1*DIGIT) > >=20 > > hi-target =3D "rc" / "cc" / "mp" / "rt" > >=20 > > hi-aor =3D "aor" > >=20 > > hi-extension =3D generic-param > >=20 > > Of course, the "index" parameter is still mandatory per the=20 > semantic=20 > > constraints listed earlier in section 4.1. > >=20 > > I've also inserted into the hi-index BNF some spaces around the=20 > > instances of "/" for better readability. > >=20 > > Dale > >=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 From pkyzivat@cisco.com Thu Jul 9 15:30:44 2009 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 4128328C287 for ; Thu, 9 Jul 2009 15:30:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.586 X-Spam-Level: X-Spam-Status: No, score=-6.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 H7Fk+KN1o1jD for ; Thu, 9 Jul 2009 15:30:43 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0C6B828C27D for ; Thu, 9 Jul 2009 15:30:43 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,375,1243814400"; d="scan'208";a="211879756" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 09 Jul 2009 22:31:11 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n69MVBJ4016378; Thu, 9 Jul 2009 15:31:11 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n69MVAJg006160; Thu, 9 Jul 2009 22:31:11 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Jul 2009 18:31:10 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 9 Jul 2009 18:31:10 -0400 Message-ID: <4A566FAE.4030901@cisco.com> Date: Thu, 09 Jul 2009 18:31:10 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Francois Audet References: <1246556981.10099.65.camel@victoria-pingtel-com.us.nortel.com> <4A4CFEF1.1000006@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EE8ABC1@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EE8ABC1@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 09 Jul 2009 22:31:10.0359 (UTC) FILETIME=[F56D1270:01CA00E4] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4976; t=1247178671; x=1248042671; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20draft-barnes-sipcore-rfc424 4bis |Sender:=20; bh=hMvZoyBIFQPYeaYnxCjyEM4bNx8aDt5y8+2u9idL6jk=; b=Gm8UqyHTUlSGPkvR4+cJgLztlvZ+CPGztrGJDYuL+PThTlFq0GSw8DIb5n IW0XVbgjMBnJmGr8hnl6kyv9PqehqryI12Trr/4pgosPt5KMG+kyUTGyJCpn yRGRL2H/3z; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: SIPCORE , Dale Worley 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, 09 Jul 2009 22:30:44 -0000 Francois Audet wrote: > Dale, Paul, > > Good catch. > > The intent was not to impose an ordering requirement: the intent was > to impose that the hi-index parameter be present. > > Paul: in RFC4244 there was NO ordering requirement. Yeah. Dale pointed that out. I just assumed it had been carried over. > What we are trying to achieve with the ABNF is: > > - No ordering requirement > - There MUST be exactly ONE hi-index > - There MUST be 0 or 1 hi-target parameter > - There MUST be 0 or 1 hi-aor parameter > - There MAY be any number of hi-extension Its already a restriction that parameters (in general) may appear only once. It gets asked about from time to time. I forget where it says that. So you might not even need to say it. Certainly most of the other header parameter syntaxes don't say it but clearly intend it. But it probably would be helpful to put it in the text. > I now see the current ABNF fails miserably to do this... > But I don't think it's trivial to express in ABNF. As I started to show, it is technically possible. But as Dale responded, and I generally agree, it does make the abnf complex. Also, once you introduce generic-param all bets are off, since syntactically you can match one occurrence against the explicit name and another occurrence against generic-param. > So I think then that Dale's semantic is better, and we > just need to clearly state that index must be present, and > that there can be only 0 or 1 of each of hi-target and hi-aor. I agree. Paul >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Thursday, July 02, 2009 11:40 >> To: Worley, Dale (BL60:9D30) >> Cc: SIPCORE >> Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis >> >> Dale, >> >> I agree with your concern about the BNF. A requirement about >> the ordering of the params is problematic. >> >> OTOH, this is a revision to an existing RFC which had that >> ordering requirement. Its possible that relaxing it might >> lead to interop problems. >> >> Perhaps the best one can do is put in a recommendation to >> make the index first. >> >> Regarding indicating that the index is required: it can be >> done in text, but it can also be done in the BNF, as follows: >> >> History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) >> >> hi-entry = hi-targeted-to-uri hi-param-list >> >> hi-targeted-to-uri = name-addr >> >> hi-param-list = *(SEMI hi-option) SEMI hi-index *(hi-option) >> >> hi-option = hi-target / hi-aor / hi-extension >> >> hi-index = "index" EQUAL 1*DIGIT *("." 1*DIGIT) >> >> hi-target = "rc" / "cc" / "mp" / "rt" >> >> hi-aor = "aor" >> >> hi-extension = generic-param >> >> >> Thanks, >> Paul >> >> >> Dale Worley wrote: >>> Regarding the BNF for the History-Info header (section 4.1 in the >>> draft version of -02): >>> >>> The current BNF requires that the "index" parameter appear >> immediately >>> after the URI, whereas other parameters appear after it: >>> >>> History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) >>> >>> hi-entry = hi-targeted-to-uri SEMI hi-index *(SEMI hi-param) >>> >>> hi-targeted-to-uri = name-addr >>> >>> hi-index = "index" EQUAL 1*DIGIT *("." 1*DIGIT) >>> >>> hi-param = hi-target/hi-aor/hi-extension >>> >>> hi-target = "rc" / "cc" / "mp" / "rt" >>> >>> hi-aor = "aor" >>> >>> hi-extension = generic-param >>> >>> IMHO, this is not a good way to organize the grammar, as it >> makes it >>> difficult to generate hi-entry's with generic code (there >> needs to be >>> some way to constrain the "index" parameter to be first), >> and violates >>> the general rule that the order of parameters is not significant. >>> >>> I propose to adjust the BNF to: >>> >>> History-Info = "History-Info" HCOLON hi-entry *(COMMA hi-entry) >>> >>> hi-entry = hi-targeted-to-uri *(SEMI hi-param) >>> >>> hi-targeted-to-uri = name-addr >>> >>> hi-param = hi-index / hi-target / hi-aor / hi-extension >>> >>> hi-index = "index" EQUAL 1*DIGIT *("." 1*DIGIT) >>> >>> hi-target = "rc" / "cc" / "mp" / "rt" >>> >>> hi-aor = "aor" >>> >>> hi-extension = generic-param >>> >>> Of course, the "index" parameter is still mandatory per the >> semantic >>> constraints listed earlier in section 4.1. >>> >>> I've also inserted into the hi-index BNF some spaces around the >>> instances of "/" for better readability. >>> >>> 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 AUDET@nortel.com Thu Jul 9 16:39:24 2009 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 413DF3A6D5E for ; Thu, 9 Jul 2009 16:39:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.324 X-Spam-Level: X-Spam-Status: No, score=-6.324 tagged_above=-999 required=5 tests=[AWL=0.275, 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 Axix49F-BJFR for ; Thu, 9 Jul 2009 16:39:23 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 43E8B3A69B6 for ; Thu, 9 Jul 2009 16:38:59 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n69NbhR24172; Thu, 9 Jul 2009 23:37:43 GMT 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, 9 Jul 2009 18:39:18 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EE8AD92@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A566FAE.4030901@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis thread-index: AcoA5PsoRUrI3ZO5RaG7Q1fnLGN3wwACXMXA References: <1246556981.10099.65.camel@victoria-pingtel-com.us.nortel.com> <4A4CFEF1.1000006@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EE8ABC1@zrc2hxm0.corp.nortel.com> <4A566FAE.4030901@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" Cc: SIPCORE , Dale Worley 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, 09 Jul 2009 23:39:24 -0000 Ok, cool: we have agreement. I'll put a note to help the reader.=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Thursday, July 09, 2009 15:31 > To: Audet, Francois (SC100:3055) > Cc: Worley, Dale (BL60:9D30); SIPCORE; Barnes, Mary (RICH2:AR00) > Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis >=20 >=20 >=20 > Francois Audet wrote: > > Dale, Paul, > >=20 > > Good catch. > >=20 > > The intent was not to impose an ordering requirement: the=20 > intent was=20 > > to impose that the hi-index parameter be present. > >=20 > > Paul: in RFC4244 there was NO ordering requirement. >=20 > Yeah. Dale pointed that out. I just assumed it had been carried over. >=20 > > What we are trying to achieve with the ABNF is: > >=20 > > - No ordering requirement > > - There MUST be exactly ONE hi-index > > - There MUST be 0 or 1 hi-target parameter > > - There MUST be 0 or 1 hi-aor parameter > > - There MAY be any number of hi-extension >=20 > Its already a restriction that parameters (in general) may=20 > appear only once. It gets asked about from time to time. I=20 > forget where it says that. >=20 > So you might not even need to say it. Certainly most of the=20 > other header parameter syntaxes don't say it but clearly intend it. >=20 > But it probably would be helpful to put it in the text. >=20 > > I now see the current ABNF fails miserably to do this... > > But I don't think it's trivial to express in ABNF. >=20 > As I started to show, it is technically possible. But as Dale=20 > responded, and I generally agree, it does make the abnf=20 > complex. Also, once you introduce generic-param all bets are=20 > off, since syntactically you can match one occurrence against=20 > the explicit name and another occurrence against generic-param. >=20 > > So I think then that Dale's semantic is better, and we just need to=20 > > clearly state that index must be present, and that there=20 > can be only 0=20 > > or 1 of each of hi-target and hi-aor. >=20 > I agree. >=20 > Paul >=20 > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: Thursday, July 02, 2009 11:40 > >> To: Worley, Dale (BL60:9D30) > >> Cc: SIPCORE > >> Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis > >> > >> Dale, > >> > >> I agree with your concern about the BNF. A requirement about the=20 > >> ordering of the params is problematic. > >> > >> OTOH, this is a revision to an existing RFC which had that=20 > ordering=20 > >> requirement. Its possible that relaxing it might lead to interop=20 > >> problems. > >> > >> Perhaps the best one can do is put in a recommendation to make the=20 > >> index first. > >> > >> Regarding indicating that the index is required: it can be done in=20 > >> text, but it can also be done in the BNF, as follows: > >> > >> History-Info =3D "History-Info" HCOLON hi-entry *(COMMA = hi-entry) > >> > >> hi-entry =3D hi-targeted-to-uri hi-param-list > >> > >> hi-targeted-to-uri =3D name-addr > >> > >> hi-param-list =3D *(SEMI hi-option) SEMI hi-index *(hi-option) > >> > >> hi-option =3D hi-target / hi-aor / hi-extension > >> > >> hi-index =3D "index" EQUAL 1*DIGIT *("." 1*DIGIT) > >> > >> hi-target =3D "rc" / "cc" / "mp" / "rt" > >> > >> hi-aor =3D "aor" > >> > >> hi-extension =3D generic-param > >> > >> > >> Thanks, > >> Paul > >> > >> > >> Dale Worley wrote: > >>> Regarding the BNF for the History-Info header (section 4.1 in the=20 > >>> draft version of -02): > >>> > >>> The current BNF requires that the "index" parameter appear > >> immediately > >>> after the URI, whereas other parameters appear after it: > >>> > >>> History-Info =3D "History-Info" HCOLON hi-entry *(COMMA = hi-entry) > >>> > >>> hi-entry =3D hi-targeted-to-uri SEMI hi-index *(SEMI hi-param) > >>> > >>> hi-targeted-to-uri =3D name-addr > >>> > >>> hi-index =3D "index" EQUAL 1*DIGIT *("." 1*DIGIT) > >>> > >>> hi-param =3D hi-target/hi-aor/hi-extension > >>> > >>> hi-target =3D "rc" / "cc" / "mp" / "rt" > >>> > >>> hi-aor =3D "aor" > >>> > >>> hi-extension =3D generic-param > >>> > >>> IMHO, this is not a good way to organize the grammar, as it > >> makes it > >>> difficult to generate hi-entry's with generic code (there > >> needs to be > >>> some way to constrain the "index" parameter to be first), > >> and violates > >>> the general rule that the order of parameters is not significant. > >>> > >>> I propose to adjust the BNF to: > >>> > >>> History-Info =3D "History-Info" HCOLON hi-entry *(COMMA = hi-entry) > >>> > >>> hi-entry =3D hi-targeted-to-uri *(SEMI hi-param) > >>> > >>> hi-targeted-to-uri =3D name-addr > >>> > >>> hi-param =3D hi-index / hi-target / hi-aor / hi-extension > >>> > >>> hi-index =3D "index" EQUAL 1*DIGIT *("." 1*DIGIT) > >>> > >>> hi-target =3D "rc" / "cc" / "mp" / "rt" > >>> > >>> hi-aor =3D "aor" > >>> > >>> hi-extension =3D generic-param > >>> > >>> Of course, the "index" parameter is still mandatory per the > >> semantic > >>> constraints listed earlier in section 4.1. > >>> > >>> I've also inserted into the hi-index BNF some spaces around the=20 > >>> instances of "/" for better readability. > >>> > >>> 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 > >> > >=20 >=20 From shin@softfront.co.jp Thu Jul 9 23:41:26 2009 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 A5EE33A6CEC for ; Thu, 9 Jul 2009 23:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.733 X-Spam-Level: **** X-Spam-Status: No, score=4.733 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, UNPARSEABLE_RELAY=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 sXbJGddwTgTM for ; Thu, 9 Jul 2009 23:41:26 -0700 (PDT) Received: from mail2.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with SMTP id C29833A6923 for ; Thu, 9 Jul 2009 23:41:25 -0700 (PDT) Received: from softfront.co.jp by mail2.softfront.co.jp id AA02644 ; 10 Jul 2009 15:41:51 +0900 From: OKUMURA Shinji To: sipcore@ietf.org Date: Fri, 10 Jul 2009 15:41:49 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.18 (WinNT,501) Message-Id: <6CA0129806DD4shin@softfront.co.jp> Subject: [sipcore] draft-barnes-sipcore-rfc4244bis - hi-targeted-to-uri 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, 10 Jul 2009 06:41:26 -0000 Hi, I have one suggestion. In the draft hi-targeted-to-uri is defined as follows hi-targeted-to-uri = name-addr If there is no special reason for the restriction, I think addr-spec should be added as follows hi-targeted-to-uri = name-addr/addr-spec Regards, Shinji From shin@softfront.co.jp Thu Jul 9 23:43:15 2009 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 6A4C83A6D77 for ; Thu, 9 Jul 2009 23:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.64 X-Spam-Level: **** X-Spam-Status: No, score=4.64 tagged_above=-999 required=5 tests=[AWL=0.093, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, UNPARSEABLE_RELAY=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 I4R3VP589xtl for ; Thu, 9 Jul 2009 23:43:14 -0700 (PDT) Received: from mail2.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with SMTP id 5E86C3A6CEC for ; Thu, 9 Jul 2009 23:43:14 -0700 (PDT) Received: from softfront.co.jp by mail2.softfront.co.jp id AA03332 ; 10 Jul 2009 15:43:36 +0900 From: OKUMURA Shinji To: sipcore@ietf.org Date: Fri, 10 Jul 2009 15:43:35 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.18 (WinNT,501) Message-Id: <7CA0129BFB19Ashin@softfront.co.jp> Subject: [sipcore] history and privacy (draft-barnes-sipcore-rfc4244bis-01) 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, 10 Jul 2009 06:43:15 -0000 Hi, I have some questions. 1. critical When proxy want to insert a hi-entry with "history" and "critical", can these values be encoded in hi-target-to-uri ? "Privacy=history;critical" ? 2. Privacy in the response A request include a Privacy header with "history" and hi-entries without Privacy headers, the last proxy anonymize all hi-entries and remove a Privacy header. UAS returns a response with all anonymized hi-entries and no Privacy header. Should the last proxy( privacy service) insert a "Privacy: history" ? 3. History-Info in the response Should privacy service restore values for History-Info headers that anonymized by itself ? Regards, Shinji From shin@softfront.co.jp Thu Jul 9 23:44:15 2009 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 51C8F3A6B4F for ; Thu, 9 Jul 2009 23:44:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.686 X-Spam-Level: *** X-Spam-Status: No, score=3.686 tagged_above=-999 required=5 tests=[AWL=0.953, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_62=0.6, RELAY_IS_221=2.222, UNPARSEABLE_RELAY=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 hj1YpHY09JQJ for ; Thu, 9 Jul 2009 23:44:14 -0700 (PDT) Received: from mail2.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with SMTP id 66FE93A6CEC for ; Thu, 9 Jul 2009 23:43:44 -0700 (PDT) Received: from softfront.co.jp by mail2.softfront.co.jp id AA03324 ; 10 Jul 2009 15:44:06 +0900 From: OKUMURA Shinji To: SIPCORE Date: Fri, 10 Jul 2009 15:44:05 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.18 (WinNT,501) In-Reply-To: <4A528AB2.7020206@cisco.com> References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com> Message-Id: <8CA0129D1A650shin@softfront.co.jp> Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 10 Jul 2009 06:44:15 -0000 Hi, I have some comments. RFC3261 describe about the atomic process. 8 General User Agent Behavior 8.2 UAS Behavior Note that request processing is atomic. If a request is accepted, all state changes associated with it MUST be performed. If it is rejected, all state changes MUST NOT be performed. 12 Dialogs 12.2 Requests within a Dialog 12.2.2 UAS Behavior Requests sent within a dialog, as any other requests, are atomic. If a particular request is accepted by the UAS, all the state changes associated with it are performed. If the request is rejected, none of the state changes are performed. 14 Modifying an Existing Session 14.1 UAC Behavior If a UA receives a non-2xx final response to a re-INVITE, the session parameters MUST remain unchanged, as if no re-INVITE had been issued. above rule work fine for re-INVITE and PRACK. but I think that UPDATE and precondition procedure was considered insufficiently about an error response to a re-INVITE. if all changes executed by UPDATE transactions are excluded from the rollback, are there any problems? That is, | INVITE | | | |------------->| | | | 183 | | | |<-------------| | | | PRACK | | | |------------->| | | | 200(PRACK) | | | |<-------------| is identical to | | | UPDATE | | UPDATE | |------------->| |------------->| | 200(UPDATE)| | 200(UPDATE)| |<-------------| |<-------------| | 488(INVITE)| | | |<-------------| | | | ACK | | | |------------->| | | This updates RFC3311. But at this point, I have one doubt. May precondition procedure be started by UPDATE? >4. Problems with Error Responses and Already-executed Changes > Using an error response to undo already executed changes presents an > additional problem. Section 4 of [RFC3264] specifies rules to avoid > glare situations (i.e., to avoid offer/answer collisions in race > conditions). Even when both UAs generate an offer at the same time, > there are rules to determine which one should be processed first. > However, there are no rules to avoid a collision between an offer in > an UPDATE request and an error response for a re-INVITE. Since both > the UPDATE request and the error response would request changes, it > would not be clear which changes would need to be executed first. > This is yet another reason why UASs should not use error responses to > undo already-executed changes. I think glare situations occur in three cases. 1. | UPDATE 488(reINVITE) | |---------\ /--------------| | \ / ACK | | X -------->| | / \ | |<--------/ \------------->| | | | 200(UPDATE)| |<---------------------------| | | 2. | UPDATE | |--------------------------->| | 200(UPDATE) | | /--------------| | / | | / 488(reINVITE) | |<---------/-----------------| | / | |<-------/ | | ACK | | -------->| | | 3. | 488(reINVITE)| | /--------------| | / ACK | | / -------->| | / | | / UPDATE | |<-------/-------------------| | / 200(UPDATE) | |------/-------------------->| | / | |<---/ | | >6. UAC Behavior > In order to cope with this type of UAS, a UAC that receives an error > response to a re-INVITE for which changes have been already executed > SHOULD generate a new re-INVITE or UPDATE request in order to make > sure that both UAs have a common view of the state of the session. If all changes are the results of only re-INVITE and PRARK, I think new UPDATE(or re-INVITE) request is not necessary. Regards, Shinji Paul Kyzivat >Gonzalo, > >Thanks for doing this work! I do have some comments: > >Section 3/Figure 1 > >The figure shows a 6xx response. >The text says that the UAS wants to reject the new offer. > >A UAS would probably not use a 6xx response to reject media. >(I guess it might use 606, but 488 would be more appropriate.) >In fact, it probably would not reject the request at all, but rather >would just refuse the added media stream. > >The point being made doesn't require that the response be 6xx or that it >be with the purpose of refusing the media. So I think what is needed >here is to find a plausible example to make the point. > >A good one for the purpose here might be a 488 to reject the media, or a > 401 response as another sort of reason for rejecting the whole thing >but wanting to preserve what there is. > >Section 5: > >> A change to the session state is considered to have been executed >> when the new media parameters are being used. Therefore, a change to >> a stream subject to preconditions [RFC4032] is considered to have >> been executed when the new media parameters start being used; not >> when the preconditions for the stream are met. Unsurprisingly, the >> UAS considers the new parameters to be in use when it actually starts >> using them. > >I'm not entirely following this. I think there may be an assumption here >that the UAC is the offerer and the UAS the answerer. I'm guessing you >are saying that the answerer considers the new parameters to be in use >when it actually starts using them. > >Since this section is about the UAS (for the reinvite), this point is >probably that when the UAS is also the answerer it can decide when the >new media is in use based on when it starts using them. > >But what happens when the UAS is the offerer? In that case I think it >must assume the media is in use as soon as it is offered. But maybe that >isn't always the case with preconditions. I don't think it can wait till >it receives media, because media may be in flight when it makes its >decision. > >> As described in Section 8.3.1 of RFC 3264 [RFC3264], the >> UAC considers the new parameters to be in use when media is received >> in the new port, which should be interpreted as follows: >> >> Received, in this case, means that the media is passed to a media >> sink. This means that if there is a playout buffer, the agent >> would continue to listen on the old port until the media on the >> new port reached the top of the playout buffer. At that time, it >> MAY cease listening for media on the old port. > >I don't know what the above has to do with the behavior of the UAS. > >> 9. Clarifications on Target Refresh Requests >> >> On receiving a target refresh request with an updated remote target, >> a UAS updates the remote target of the dialog immediately. This >> update represents the execution of a state change. Therefore, >> following the rules in Section 5, UASs always return 2xx responses to >> target refresh requests that update the remote target. > >This does not address cases where the UAS cannot accept the change with >a 200. Some cases that fall into this category are: > >- request includes a Require of an unsupported option (e.g. 100rel) >- request cannot be authorized >- server overload >- precondition failure > >In any case, if no state changes have been made prior to the request >with a target change, then there is no issue with rejecting the target >refresh if need be. > >The issue with target refresh is that the UA sending it may have an >urgent need for it to be accepted, since it may not be able to >communicate on its old address(es) any longer. And if that is the case >it may also have an urgent need to change its media addresses as well >for the same reason. That would be motivation for doing both at once. > >If a reINVITE includes a target change, then its very difficult to know >when the UAC must begin using it. So I think the UAS must assume it must >be considered in use immediately. Hence it should *try* to avoid >rejecting the request, even if it must reject all the media in the >request. But there is still a possibility that it will have to reject >due to authorization, overload, etc. If that is done right away its no >different than any request rejected before any changes have been made. > >A difficult case is where a reINVITE has been initiated, and has not >completed. (Perhaps its ringing.) Then the UAC loses its IP address or >IP connectivity and needs to make a target change. So it sends an UPDATE >with the target change. What it should probably do in that case is *not* >include an offer in the UPDATE. Then it can't be rejected for o/a >reasons. Once that is done it can continue the o/a process, updating its >media addresses when it has the chance. Once the UAC target has changed, >the UAS should not fail the INVITE. If need be it should reject all the >media in order to avoid that. > >Another difficult case if if a reINVITE has been initiated and the UAS >finds it needs to change its address. Similar considerations to above >seem to apply. > >Frankly, this is all very nasty, and those in this situation may have >few options for what do do. It feels deserving of its own treatment. >Namely a whole call flow document with various use cases where target >change is required. Probably a BCP. > > Thanks, > Paul From pkyzivat@cisco.com Fri Jul 10 06:26:44 2009 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 23A2028C27D for ; Fri, 10 Jul 2009 06:26:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 gW0pS0evpZWv for ; Fri, 10 Jul 2009 06:26:43 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id E9CC228C1BC for ; Fri, 10 Jul 2009 06:26:42 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.42,378,1243814400"; d="scan'208";a="212161658" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-1.cisco.com with ESMTP; 10 Jul 2009 13:27:07 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6ADR7eh024837; Fri, 10 Jul 2009 06:27:07 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6ADR6qm011761; Fri, 10 Jul 2009 13:27:07 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Jul 2009 09:27:06 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Jul 2009 09:27:06 -0400 Message-ID: <4A5741A9.8030200@cisco.com> Date: Fri, 10 Jul 2009 09:27:05 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: OKUMURA Shinji References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com> <8CA0129D1A650shin@softfront.co.jp> In-Reply-To: <8CA0129D1A650shin@softfront.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2009 13:27:06.0420 (UTC) FILETIME=[1E890740:01CA0162] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=881; t=1247232427; x=1248096427; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20New=20revision=20of=20the=2 0re-INVITE=20handling=20draft |Sender:=20; bh=2H5Xm34LaVcluogoAlAO1Dsib7ul94lKgu00CV1UH5Q=; b=jDQ76tgrZtTAuuPH/4to8ipmimPZVWCXoarj4Hzq2jPdDi41aWxzSn+G5E yzbxp1ndwwTtqE7LVxoZwJvJe8ZIG4vKGJSSzI+hYAr+WalMRZgojCpOAmtQ 5bPnHwzxxp; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 10 Jul 2009 13:26:44 -0000 OKUMURA Shinji wrote: > But at this point, I have one doubt. > May precondition procedure be started by UPDATE? IMO yes it may. But perhaps it SHOULD NOT ??? I think it has always been possible to initiate an in-dialog o/a exchange, with or without preconditions, using UPDATE rather than reINVITE. I guess it would also be possible to start an INVITE/reINVITE without preconditions, and then initiate the use of preconditions with an UPDATE. But I can't think of any good reason why you would want to do that. AFAIK there are only a couple of places where UPDATE is needed, or preferable alternatives: - its needed by UAC for 2nd and subsequent rounds of O/A exchange within an INVITE. - its good for a dialog refresh/target refresh when you *don't* want to do a new O/A. Other uses can be accomplished other ways. Thanks, Paul From mary.barnes@nortel.com Fri Jul 10 09:12:48 2009 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 48C663A6E63 for ; Fri, 10 Jul 2009 09:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.332 X-Spam-Level: X-Spam-Status: No, score=-6.332 tagged_above=-999 required=5 tests=[AWL=0.267, 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 aY+x0elJVA63 for ; Fri, 10 Jul 2009 09:12:47 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 594993A6E5E for ; Fri, 10 Jul 2009 09:12:47 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6AGDCl10441; Fri, 10 Jul 2009 16:13:12 GMT 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: Fri, 10 Jul 2009 11:14:35 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EEDE21D@zrc2hxm0.corp.nortel.com> In-Reply-To: <6CA0129806DD4shin@softfront.co.jp> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis - hi-targeted-to-uri thread-index: AcoBKYpcz2kxjeifS+K4RZGCZCI9LgATh7Fg References: <6CA0129806DD4shin@softfront.co.jp> From: "Mary Barnes" To: "OKUMURA Shinji" , Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - hi-targeted-to-uri 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, 10 Jul 2009 16:12:48 -0000 Hi Shinji, I honestly can't remember if there was a specific reason why we used just name-addr, other than it also encompasses the addr-spec so you get consistency in the format for the field. I'd welcome other opinions on this.=20 Thanks, Mary.=20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of OKUMURA Shinji Sent: Friday, July 10, 2009 1:42 AM To: sipcore@ietf.org Subject: [sipcore] draft-barnes-sipcore-rfc4244bis - hi-targeted-to-uri Hi, I have one suggestion. In the draft hi-targeted-to-uri is defined as follows hi-targeted-to-uri =3D name-addr If there is no special reason for the restriction, I think addr-spec should be added as follows hi-targeted-to-uri =3D name-addr/addr-spec Regards, Shinji _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From AUDET@nortel.com Fri Jul 10 10:19:46 2009 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 9B9863A6E6F for ; Fri, 10 Jul 2009 10:19:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.336 X-Spam-Level: X-Spam-Status: No, score=-7.336 tagged_above=-999 required=5 tests=[AWL=1.263, BAYES_00=-2.599, GB_I_LETTER=-2, 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 xmsEWYDgHUdU for ; Fri, 10 Jul 2009 10:19:45 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 856DE3A6E81 for ; Fri, 10 Jul 2009 10:19:33 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6AHIJj23282; Fri, 10 Jul 2009 17:18:19 GMT 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: Fri, 10 Jul 2009 12:19:53 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EEDE3C8@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EEDE21D@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis - hi-targeted-to-uri thread-index: AcoBKYpcz2kxjeifS+K4RZGCZCI9LgATh7FgAAIT7gA= References: <6CA0129806DD4shin@softfront.co.jp> <1ECE0EB50388174790F9694F77522CCF1EEDE21D@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Mary Barnes" , "OKUMURA Shinji" , Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - hi-targeted-to-uri 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, 10 Jul 2009 17:19:46 -0000 The reason is so that the URI is enclosed in <> which then allows us to separate the URI parameters from the History-Info parameters. For example, if we allowed addr-spec, there would be no clean way to know if a parameter (say "index") was a URI parameter, or a History-Info parameter. Now, if you look at the definition of the Contact header, it has the same problem. Contact can be either name-addr / addr-spec however. So what we did in 3261 is include text in 20.10 that says "If no "<" and ">" are=20 present, all parameters after the URI are header parameters, not URI parameters.". I guess we could have done something similar here, but as you can see, it it very nasty logic. Furthermore, since H-I very often includes header parameters, the value of allowing=20 addr-spec ends up being very low (i.e., you only same a couple of letters "<" and ">" in only simple circumstances. Therefore, using always the "<" ">" makes it much cleaner and simpler, and easier to parse. > -----Original Message----- > From: Barnes, Mary (RICH2:AR00)=20 > Sent: Friday, July 10, 2009 09:15 > To: OKUMURA Shinji; sipcore@ietf.org > Cc: Audet, Francois (SC100:3055) > Subject: RE: [sipcore] draft-barnes-sipcore-rfc4244bis -=20 > hi-targeted-to-uri >=20 > Hi Shinji, >=20 > I honestly can't remember if there was a specific reason why=20 > we used just name-addr, other than it also encompasses the=20 > addr-spec so you get consistency in the format for the field.=20 > I'd welcome other opinions on this.=20 >=20 > Thanks, > Mary.=20 >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of OKUMURA Shinji > Sent: Friday, July 10, 2009 1:42 AM > To: sipcore@ietf.org > Subject: [sipcore] draft-barnes-sipcore-rfc4244bis -=20 > hi-targeted-to-uri >=20 > Hi, >=20 > I have one suggestion. >=20 > In the draft hi-targeted-to-uri is defined as follows >=20 > hi-targeted-to-uri =3D name-addr >=20 > If there is no special reason for the restriction, I think=20 > addr-spec should be added as follows >=20 > hi-targeted-to-uri =3D name-addr/addr-spec >=20 > Regards, > Shinji > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From dworley@nortel.com Fri Jul 10 13:04:57 2009 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 7896228C29D for ; Fri, 10 Jul 2009 13:04:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.682 X-Spam-Level: X-Spam-Status: No, score=-6.682 tagged_above=-999 required=5 tests=[AWL=-0.083, 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 ahmgxy8iDr9T for ; Fri, 10 Jul 2009 13:04:56 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 67E363A6961 for ; Fri, 10 Jul 2009 13:04:56 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6AK5Ll09482; Fri, 10 Jul 2009 20:05:21 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Jul 2009 16:05:03 -0400 From: "Dale Worley" To: OKUMURA Shinji In-Reply-To: <6CA0129806DD4shin@softfront.co.jp> References: <6CA0129806DD4shin@softfront.co.jp> Content-Type: text/plain Organization: Nortel Networks Date: Fri, 10 Jul 2009 16:05:03 -0400 Message-Id: <1247256303.3757.45.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2009 20:05:03.0786 (UTC) FILETIME=[B68DF0A0:01CA0199] Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - hi-targeted-to-uri 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, 10 Jul 2009 20:04:57 -0000 On Fri, 2009-07-10 at 15:41 +0900, OKUMURA Shinji wrote: > In the draft hi-targeted-to-uri is defined as follows > > hi-targeted-to-uri = name-addr > > If there is no special reason for the restriction, I think > addr-spec should be added as follows > > hi-targeted-to-uri = name-addr/addr-spec That is an interesting point. If we made that change, History-Info would have the same overall syntax as Contact, From, To, etc., namely that if the URI was not contained in <...>, the first ';' would start the first header-parameter. On the other hand, Route and Record route do not allow addr-spec, that is, the <...> is mandatory. In SIP 3.0, we should force all these headers to use the same syntax. Dale From dworley@nortel.com Fri Jul 10 13:07:16 2009 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 D015028C2E7 for ; Fri, 10 Jul 2009 13:07:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.679 X-Spam-Level: X-Spam-Status: No, score=-7.679 tagged_above=-999 required=5 tests=[AWL=0.920, BAYES_00=-2.599, GB_I_LETTER=-2, 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 vWRzhZqCOHVF for ; Fri, 10 Jul 2009 13:07:16 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id DED1028C2AF for ; Fri, 10 Jul 2009 13:07:15 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6AK7fl10238; Fri, 10 Jul 2009 20:07:41 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Jul 2009 16:07:11 -0400 From: "Dale Worley" To: "Francois Audet" In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EEDE3C8@zrc2hxm0.corp.nortel.com> References: <6CA0129806DD4shin@softfront.co.jp> <1ECE0EB50388174790F9694F77522CCF1EEDE21D@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EEDE3C8@zrc2hxm0.corp.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Fri, 10 Jul 2009 16:07:10 -0400 Message-Id: <1247256430.3757.48.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2009 20:07:11.0210 (UTC) FILETIME=[02814CA0:01CA019A] Cc: sipcore@ietf.org, OKUMURA Shinji Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - hi-targeted-to-uri 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, 10 Jul 2009 20:07:16 -0000 On Fri, 2009-07-10 at 12:19 -0500, Francois Audet wrote: > I guess we could have done something similar here, but as you > can see, it it very nasty logic. Furthermore, since H-I very > often includes header parameters, the value of allowing > addr-spec ends up being very low (i.e., you only same a couple > of letters "<" and ">" in only simple circumstances. Actually, you could save them any time the URI does not contain ',', ';', or '?'. > Therefore, using always the "<" ">" makes it much cleaner and > simpler, and easier to parse. Although the value of this is relatively low, as we can already parse the complicated case (in To, From, and Contact headers). Dale From dworley@nortel.com Fri Jul 10 13:24:15 2009 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 6802228C361 for ; Fri, 10 Jul 2009 13:24:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.714 X-Spam-Level: X-Spam-Status: No, score=-6.714 tagged_above=-999 required=5 tests=[AWL=-0.115, 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 WnJ5zmkQ5KHa for ; Fri, 10 Jul 2009 13:24:14 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id BFB723A6E83 for ; Fri, 10 Jul 2009 13:24:02 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6AKMmj18067 for ; Fri, 10 Jul 2009 20:22:49 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 10 Jul 2009 16:24:26 -0400 From: "Dale Worley" To: "Francois Audet" In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EE8A67C@zrc2hxm0.corp.nortel.com> References: <1246996560.5962.37.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EDE5C07@zrc2hxm0.corp.nortel.com> <1247077928.3712.26.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EE8A67C@zrc2hxm0.corp.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Fri, 10 Jul 2009 16:24:24 -0400 Message-Id: <1247257464.3757.67.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 10 Jul 2009 20:24:26.0032 (UTC) FILETIME=[6B4E9B00:01CA019C] Cc: SIPCORE Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax 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, 10 Jul 2009 20:24:15 -0000 On Thu, 2009-07-09 at 14:07 -0400, Audet, Francois (SC100:3055) wrote: > It's basically saying that the Privacy and Reason "escaped parameters" would > translate into headers if we were to created a request based on it. I can't see any circumstances where we would want to create a request that included the Privacy or Reason headers from a H-I entry. In regard to Privacy, if its value is "history", that means that the particular H-I URI should be restricted. But that is not the meaning of adding the "Privacy: history" header to a request -- in the latter case, History-Info should not be generated at all. (Which is what I mean when I say "the values of Privacy in History-Info do not have the same semantics as the values of the Privacy header".) In regard to Reason, as far as I can tell, it is attached to an H-I entry to show the response that was received to the request that was sent to that URI. Generating a request based on that H-I entry would create a request to that same URI, containing a Reason header in the request that *predicts* the response that the request will receive. Given that in no case would we want to generate and use (with the implicit headers) a request based on the H-I entry's URI-with-headers, I don't see why these data items are stored in headers attached to the URI. On Wed, 2009-07-08 at 19:25 -0400, Barnes, Mary (RICH2:AR00) wrote: > As far as privacy, I'm not sure what you mean with regards > to " This privacy value is an annotation of the URI, whereas the current > syntax incorporates it *into* the URI." The privacy value isn't > incorporated into the URI - it's an escaped parameter. It's an escaped parameter, but it *is* part of the URI -- see the production "SIP-URI" in section 25.1 of RFC 3261. And if you ask the grammar, "What is the URI part of an H-I entry?" you will get back the 'headers' as part of the URI. Similarly, any device or syntax which admits a SIP URI will allow you to enter a string containing 'headers'. Indeed, there is only one situation where a SIP URI is possible but that URI cannot contain 'headers', and that is as the request-URI of a request. That isn't specified in the syntax (which allows SIP-URI), but is a consequence of the processing in section 19.1.5, which removes the 'headers' from the supplied SIP URI and turns them into message headers. Dale From mary.barnes@nortel.com Fri Jul 10 13:41:08 2009 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 D33DF3A69B4 for ; Fri, 10 Jul 2009 13:41:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.334 X-Spam-Level: X-Spam-Status: No, score=-6.334 tagged_above=-999 required=5 tests=[AWL=0.265, 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 4hsMZiHjj4EW for ; Fri, 10 Jul 2009 13:41:07 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 9D3243A6899 for ; Fri, 10 Jul 2009 13:41:07 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6AKdtj19809 for ; Fri, 10 Jul 2009 20:39:55 GMT 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: Fri, 10 Jul 2009 15:43:30 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EEDE853@zrc2hxm0.corp.nortel.com> In-Reply-To: <1247257464.3757.67.camel@victoria-pingtel-com.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax thread-index: AcoBnGvHKCIaPFDpQf+/3xhnWI6IYwAAJ2rw References: <1246996560.5962.37.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EDE5C07@zrc2hxm0.corp.nortel.com> <1247077928.3712.26.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EE8A67C@zrc2hxm0.corp.nortel.com> <1247257464.3757.67.camel@victoria-pingtel-com.us.nortel.com> From: "Mary Barnes" To: "Dale Worley" , "Francois Audet" Cc: SIPCORE Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax 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, 10 Jul 2009 20:41:08 -0000 A couple points below [MB]. Mary. -----Original Message----- From: Worley, Dale (BL60:9D30)=20 Sent: Friday, July 10, 2009 3:24 PM To: Audet, Francois (SC100:3055) Cc: Barnes, Mary (RICH2:AR00); SIPCORE Subject: RE: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax On Thu, 2009-07-09 at 14:07 -0400, Audet, Francois (SC100:3055) wrote: > It's basically saying that the Privacy and Reason "escaped parameters" > would translate into headers if we were to created a request based on it. I can't see any circumstances where we would want to create a request that included the Privacy or Reason headers from a H-I entry. In regard to Privacy, if its value is "history", that means that the particular H-I URI should be restricted. But that is not the meaning of adding the "Privacy: history" header to a request -- in the latter case, History-Info should not be generated at all. (Which is what I mean when I say "the values of Privacy in History-Info do not have the same semantics as the values of the Privacy header".) In regard to Reason, as far as I can tell, it is attached to an H-I entry to show the response that was received to the request that was sent to that URI. Generating a request based on that H-I entry would create a request to that same URI, containing a Reason header in the request that *predicts* the response that the request will receive. Given that in no case would we want to generate and use (with the implicit headers) a request based on the H-I entry's URI-with-headers, I don't see why these data items are stored in headers attached to the URI. [MB] We discussed this in another thread and the motivation was the reuse of existing headers rather than defining parameters that had the same semantics and values. That was discussed at IETF-55 in Atlanta in the SIPPING WG meeting in November 2002: http://www.ietf.org/proceedings/02nov/slides/sipping-2/sld5.htm And, this makes sense in particular for Reason and perhaps lesser so for Privacy. And, as you say we would never use the Request URIs in these hi-entrys to generate a request so this does not cause any problems. The intent is not to add parameters to the Request URI for any reasons other than to take advantage of the "clever" escaping mechanism provided by HTTP and to avoid defining parameters with the same values as the headers, both of which are not bad ideas. And, the normative text is quite clear that this is the intent. [/MB] On Wed, 2009-07-08 at 19:25 -0400, Barnes, Mary (RICH2:AR00) wrote: > As far as privacy, I'm not sure what you mean with regards to " This=20 > privacy value is an annotation of the URI, whereas the current syntax=20 > incorporates it *into* the URI." The privacy value isn't incorporated > into the URI - it's an escaped parameter. It's an escaped parameter, but it *is* part of the URI -- see the production "SIP-URI" in section 25.1 of RFC 3261. And if you ask the grammar, "What is the URI part of an H-I entry?" you will get back the 'headers' as part of the URI.=20 [MB] See my comment above. Since we have specified clearly in the HI ABNF and in the normative text, this URI needs to be appropriately handled to derive the parameters. And, it is not abnormal to remove the headers that are escaped in the URIs - basic HTTP. =20 Similarly, any device or syntax which admits a SIP URI will allow you to enter a string containing 'headers'. Indeed, there is only one situation where a SIP URI is possible but that URI cannot contain 'headers', and that is as the request-URI of a request. That isn't specified in the syntax (which allows SIP-URI), but is a consequence of the processing in section 19.1.5, which removes the 'headers' from the supplied SIP URI and turns them into message headers. [MB] Exactly and that's why it's not a problem. Since we are capturing a Request URI, there is no conflict between the headers that we escape since no other headers can be escaped in the Request URI.=20 [/MB] Dale From AUDET@nortel.com Fri Jul 10 14:09:15 2009 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 A54643A696D for ; Fri, 10 Jul 2009 14:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.362 X-Spam-Level: X-Spam-Status: No, score=-7.362 tagged_above=-999 required=5 tests=[AWL=1.237, BAYES_00=-2.599, GB_I_LETTER=-2, 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 Bkh0CMUsItO1 for ; Fri, 10 Jul 2009 14:09:14 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 595E83A6C5F for ; Fri, 10 Jul 2009 14:08:44 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6AL7Jj28993; Fri, 10 Jul 2009 21:07:19 GMT 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, 10 Jul 2009 16:08:42 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EEDE8E0@zrc2hxm0.corp.nortel.com> In-Reply-To: <1247256430.3757.48.camel@victoria-pingtel-com.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis - hi-targeted-to-uri thread-index: AcoBmgMvN6UKyxJTTN6I+UQbpS0XZwACI1uw References: <6CA0129806DD4shin@softfront.co.jp> <1ECE0EB50388174790F9694F77522CCF1EEDE21D@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EEDE3C8@zrc2hxm0.corp.nortel.com> <1247256430.3757.48.camel@victoria-pingtel-com.us.nortel.com> From: "Francois Audet" To: "Dale Worley" Cc: sipcore@ietf.org, OKUMURA Shinji Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - hi-targeted-to-uri 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, 10 Jul 2009 21:09:15 -0000 Exactly. In other words, we screwed up on "Contact".=20 > -----Original Message----- > From: Worley, Dale (BL60:9D30)=20 > Sent: Friday, July 10, 2009 13:07 > To: Audet, Francois (SC100:3055) > Cc: Barnes, Mary (RICH2:AR00); OKUMURA Shinji; sipcore@ietf.org > Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis -=20 > hi-targeted-to-uri >=20 > On Fri, 2009-07-10 at 12:19 -0500, Francois Audet wrote: > > I guess we could have done something similar here, but as=20 > you can see,=20 > > it it very nasty logic. Furthermore, since H-I very often includes=20 > > header parameters, the value of allowing addr-spec ends up=20 > being very=20 > > low (i.e., you only same a couple of letters "<" and ">" in only=20 > > simple circumstances. >=20 > Actually, you could save them any time the URI does not=20 > contain ',', ';', or '?'. >=20 > > Therefore, using always the "<" ">" makes it much cleaner=20 > and simpler,=20 > > and easier to parse. >=20 > Although the value of this is relatively low, as we can=20 > already parse the complicated case (in To, From, and Contact headers). >=20 > Dale >=20 >=20 >=20 From AUDET@nortel.com Fri Jul 10 17:36:19 2009 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 15A793A67E7 for ; Fri, 10 Jul 2009 17:36:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.386 X-Spam-Level: X-Spam-Status: No, score=-6.386 tagged_above=-999 required=5 tests=[AWL=0.213, 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 mXJw3wHhli46 for ; Fri, 10 Jul 2009 17:36:18 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id C657C3A67B6 for ; Fri, 10 Jul 2009 17:36:17 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6B0Z3X17327 for ; Sat, 11 Jul 2009 00:35:03 GMT 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: Fri, 10 Jul 2009 19:36:33 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EEDEAB8@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EEDE853@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax thread-index: AcoBnGvHKCIaPFDpQf+/3xhnWI6IYwAAJ2rwAAibeXA= References: <1246996560.5962.37.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EDE5C07@zrc2hxm0.corp.nortel.com> <1247077928.3712.26.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EE8A67C@zrc2hxm0.corp.nortel.com> <1247257464.3757.67.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EEDE853@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Mary Barnes" , "Dale Worley" Cc: SIPCORE Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax 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, 11 Jul 2009 00:36:19 -0000 While it's debatable if it was the right choice back in 2002, it seems a bit late to change it now. Especially since it will not be backwards compatible. > -----Original Message----- > From: Barnes, Mary (RICH2:AR00)=20 > Sent: Friday, July 10, 2009 13:44 > To: Worley, Dale (BL60:9D30); Audet, Francois (SC100:3055) > Cc: SIPCORE > Subject: RE: [sipcore] draft-barnes-sipcore-rfc4244bis -=20 > privacy syntax >=20 > A couple points below [MB]. >=20 > Mary. >=20 > -----Original Message----- > From: Worley, Dale (BL60:9D30) > Sent: Friday, July 10, 2009 3:24 PM > To: Audet, Francois (SC100:3055) > Cc: Barnes, Mary (RICH2:AR00); SIPCORE > Subject: RE: [sipcore] draft-barnes-sipcore-rfc4244bis -=20 > privacy syntax >=20 > On Thu, 2009-07-09 at 14:07 -0400, Audet, Francois (SC100:3055) wrote: > > It's basically saying that the Privacy and Reason "escaped=20 > parameters"=20 > > would translate into headers if we were to created a=20 > request based on it. >=20 > I can't see any circumstances where we would want to create a=20 > request that included the Privacy or Reason headers from a H-I entry. >=20 > In regard to Privacy, if its value is "history", that means=20 > that the particular H-I URI should be restricted. But that=20 > is not the meaning of adding the "Privacy: history" header to=20 > a request -- in the latter case, History-Info should not be=20 > generated at all. (Which is what I mean when I say "the=20 > values of Privacy in History-Info do not have the same=20 > semantics as the values of the Privacy header".) >=20 > In regard to Reason, as far as I can tell, it is attached to=20 > an H-I entry to show the response that was received to the=20 > request that was sent to that URI. Generating a request=20 > based on that H-I entry would create a request to that same=20 > URI, containing a Reason header in the request that=20 > *predicts* the response that the request will receive. >=20 > Given that in no case would we want to generate and use (with=20 > the implicit headers) a request based on the H-I entry's=20 > URI-with-headers, I don't see why these data items are stored=20 > in headers attached to the URI. > [MB] We discussed this in another thread and the motivation=20 > was the reuse of existing headers rather than defining=20 > parameters that had the same semantics and values. That was=20 > discussed at IETF-55 in Atlanta in the SIPPING WG meeting in=20 > November 2002: > http://www.ietf.org/proceedings/02nov/slides/sipping-2/sld5.htm >=20 > And, this makes sense in particular for Reason and perhaps=20 > lesser so for Privacy. And, as you say we would never use=20 > the Request URIs in these hi-entrys to generate a request so=20 > this does not cause any problems. The intent is not to add=20 > parameters to the Request URI for any reasons other than to=20 > take advantage of the "clever" escaping mechanism provided by=20 > HTTP and to avoid defining parameters with the same values as=20 > the headers, both of which are not bad ideas. And, the=20 > normative text is quite clear that this is the intent. [/MB] >=20 > On Wed, 2009-07-08 at 19:25 -0400, Barnes, Mary (RICH2:AR00) wrote: > > As far as privacy, I'm not sure what you mean with regards=20 > to " This=20 > > privacy value is an annotation of the URI, whereas the=20 > current syntax=20 > > incorporates it *into* the URI." The privacy value isn't=20 > incorporated=20 > > into the URI - it's an escaped parameter. >=20 > It's an escaped parameter, but it *is* part of the URI -- see=20 > the production "SIP-URI" in section 25.1 of RFC 3261. And if=20 > you ask the grammar, "What is the URI part of an H-I entry?"=20 > you will get back the 'headers' as part of the URI.=20 > [MB] See my comment above. Since we have specified clearly in=20 > the HI ABNF and in the normative text, this URI needs to be=20 > appropriately handled to derive the parameters. And, it is=20 > not abnormal to remove the headers that are escaped in the=20 > URIs - basic HTTP. =20 >=20 > Similarly, any device or syntax which admits a SIP URI will=20 > allow you to enter a string containing 'headers'. Indeed,=20 > there is only one situation where a SIP URI is possible but=20 > that URI cannot contain 'headers', and that is as the=20 > request-URI of a request. That isn't specified in the syntax=20 > (which allows SIP-URI), but is a consequence of the=20 > processing in section 19.1.5, which removes the 'headers'=20 > from the supplied SIP URI and turns them into message headers. > [MB] Exactly and that's why it's not a problem. Since we are=20 > capturing a Request URI, there is no conflict between the=20 > headers that we escape since no other headers can be escaped=20 > in the Request URI.=20 > [/MB] >=20 > Dale >=20 >=20 >=20 From HKaplan@acmepacket.com Sat Jul 11 11:52:27 2009 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 469B83A6BDD for ; Sat, 11 Jul 2009 11:52:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.511 X-Spam-Level: X-Spam-Status: No, score=-2.511 tagged_above=-999 required=5 tests=[AWL=0.088, 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 2fbn2wUm5xCO for ; Sat, 11 Jul 2009 11:52:26 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4843D3A69D1 for ; Sat, 11 Jul 2009 11:52:26 -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.1.375.2; Sat, 11 Jul 2009 14:52:54 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 11 Jul 2009 14:52:54 -0400 From: Hadriel Kaplan To: Dale Worley , SIPCORE Date: Sat, 11 Jul 2009 14:52:36 -0400 Thread-Topic: [sipcore] draft-kaplan-sip-secure-call-id-00 Thread-Index: Acn1EZJdYktRdGjcTleEdWXQR1R7SANRLNYg Message-ID: References: <1245878312.3748.84.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1245878312.3748.84.camel@victoria-pingtel-com.us.nortel.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-kaplan-sip-secure-call-id-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: Sat, 11 Jul 2009 18:52:27 -0000 Hi Dale, Sorry for not seeing this email last month - I had tuned out the sipcore li= st because I was getting brain-fried trying to follow the 4424bis discussio= n. :) The idea for providing "upgradeability" to have middleboxes stop changing C= all-ID's dynamically for security reasons, is to have them in fact inspect = the Call-ID value for conformance to the draft: namely that a Call-ID value= does not have a '@' token. Clearly a UAC could still create a Call-ID without the '@' token but still = with an IP-Address or hostname embedded in the value, and the current draft= recommends that middleboxes which replace the Call-ID for security reasons= should inspect it for such as well, regardless of that token. =20 Adding a "+)puK>" identifier does not avoid that having to happen. A secur= ity-paranoid middlebox would inspect the value regardless of whether the Ca= ll-ID starts with "+)puK>" or not. So adding it doesn't obviate the need. So in your example of Acme SBC's, the SBC's would need to be upgraded to su= pport the draft, and detect legacy vs. draft-complaint Call-ID's by looking= for the '@' token (and hostname/ip-address), on a per-out-of-dialog-reques= t basis.=20 Furthermore, there are UAC's which already generate Call-ID's compliant to = the current draft, so I wanted to support them as is, without penalizing th= em to have to change. -hadriel > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Dale Worley > Sent: Wednesday, June 24, 2009 5:19 PM > To: SIPCORE > Subject: [sipcore] draft-kaplan-sip-secure-call-id-00 >=20 > The difficulty with draft-kaplan-sip-secure-call-id-00 is that it > provides no mechanism for a B2BUA or other device to switch from > Call-Id-obscuring to Call-Id-preserving behavior, even when the SIP > elements involved are trying to cooperate. >=20 > For example, suppose I'm a SIP network provider with Acme Packet SBCs at > the boundary of my network. Currently, the SBCs obscure Call-Ids for > reasons of commercial secrecy. If I replace some or all of the UAs in > the network with ones that generate Call-Ids according to the draft, > nothing happens -- there's no way for the SBCs to detect that the > Call-IDs conform to the draft, and change their behavior. My only > option is to update *all* the UAs, then reconfigure the SBCs to not > obscure Call-Ids. This is probably unworkable even in enterprise PBX > systems, much less walled-garden service provider networks -- and yet we > want the mechanism to work in open and nearly-open SIP networks. >=20 > What the draft needs is not the current "negative criterion" that > enables B2BUAs to detect Call-Ids that definitely do not conform to the > draft, but a "positive criterion" that enables B2BUAs to detect Call-Ids > that *do* conform to the draft. >=20 > We did this sort of thing before, with the "magic cookie" z9hG4bK in the > branch value to distinguish RFC 3261 from RFC 2453 messages. So let us > define the "new" Call-Id format to be: >=20 > callid =3D "+)puK>" 22*( %x41-5A ; "A"-"Z" > / %x61-7A ; "a"-"z" > / %x30-39 ; "0"-"9" > / "_" > / "." > / "!" ) >=20 > That provides 132 bits of randomness in 28 characters, and most likely a > string of that format has never existed in the history of the world. So > when a B2BUA sees a Call-Id of that format, it can trust that the value > was generated properly and can avoid changing it. >=20 > Dale >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From HKaplan@acmepacket.com Sat Jul 11 12:01:02 2009 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 746173A687A for ; Sat, 11 Jul 2009 12:01:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.516 X-Spam-Level: X-Spam-Status: No, score=-2.516 tagged_above=-999 required=5 tests=[AWL=0.083, 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 jFvV+bFlvW6p for ; Sat, 11 Jul 2009 12:01:01 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 95DDB3A6BDD for ; Sat, 11 Jul 2009 12:01:01 -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.1.375.2; Sat, 11 Jul 2009 15:01:30 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 11 Jul 2009 15:01:30 -0400 From: Hadriel Kaplan To: Paul Kyzivat , Francois Audet Date: Sat, 11 Jul 2009 15:01:14 -0400 Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis Thread-Index: AcoA5RrQh8/9lHnmSmmRlRIIwLOllgBdIFwg Message-ID: References: <1246556981.10099.65.camel@victoria-pingtel-com.us.nortel.com> <4A4CFEF1.1000006@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EE8ABC1@zrc2hxm0.corp.nortel.com> <4A566FAE.4030901@cisco.com> In-Reply-To: <4A566FAE.4030901@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 , Dale Worley 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: Sat, 11 Jul 2009 19:01:02 -0000 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Paul Kyzivat > Sent: Thursday, July 09, 2009 6:31 PM > > > What we are trying to achieve with the ABNF is: > > > > - No ordering requirement > > - There MUST be exactly ONE hi-index > > - There MUST be 0 or 1 hi-target parameter > > - There MUST be 0 or 1 hi-aor parameter > > - There MAY be any number of hi-extension >=20 > Its already a restriction that parameters (in general) may appear only > once. It gets asked about from time to time. I forget where it says that. RFC 3261, section 7.3.1 on Header Field Format, Page 32: Even though an arbitrary number of parameter pairs may be attached to a header field value, any given parameter-name MUST NOT appear more than once. -hadriel From HKaplan@acmepacket.com Sat Jul 11 13:16:41 2009 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 2C40F3A6B04 for ; Sat, 11 Jul 2009 13:16:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.52 X-Spam-Level: X-Spam-Status: No, score=-2.52 tagged_above=-999 required=5 tests=[AWL=0.079, 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 Gsx2q37Xe4wD for ; Sat, 11 Jul 2009 13:16:40 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C245E3A687A for ; Sat, 11 Jul 2009 13:16:39 -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.1.375.2; Sat, 11 Jul 2009 16:17:08 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 11 Jul 2009 16:17:08 -0400 From: Hadriel Kaplan To: Mary Barnes , Dale Worley , Francois Audet Date: Sat, 11 Jul 2009 16:16:51 -0400 Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax Thread-Index: AcoBnGvHKCIaPFDpQf+/3xhnWI6IYwAAJ2rwAC99fZA= Message-ID: References: <1246996560.5962.37.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EDE5C07@zrc2hxm0.corp.nortel.com> <1247077928.3712.26.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EE8A67C@zrc2hxm0.corp.nortel.com> <1247257464.3757.67.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EEDE853@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EEDE853@zrc2hxm0.corp.nortel.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 Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax 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, 11 Jul 2009 20:16:41 -0000 Howdy, I have some warning bell ringing in my head against this idea of changing t= he Request-URI encoded in the HI header (the hi-targeted-to-uri) to include= an embedded Reason or Privacy header. I think the bell is due to the foll= owing concerns: 1) Afaict, the Reason value is not an attribute/property of the URI - it is= the History-Info mechanism's specific rerouting cause, i.e. it's a propert= y of what caused the HI header field to be created, so it's a property of t= he header field. The Privacy header is a little less clear, but again ISTM= that it's a command for the HI mechanism itself, and thus an attribute of = the HI header field. For example, one of the potential actions to be taken= by a Proxy is to remove the HI entry entirely - not just the URI. 2) If it weren't for this added escaped URI header, the hi-targeted-to-uri = would be a literal copy of the original request-URI. (right?) That would p= rovide a clean way of doing troubleshooting and target determination/matchi= ng, without exception checking for special things added by this RFC into th= e URI for its own purposes. 3) If we ever decide to create some way of securing the original URI in HI'= s, for example by signing it, it adds confusion or even breaks the signatur= e if the original URI is not actually left alone. 4) While it may seem that embedded headers could not have appeared in the r= eceived Request-URI to being with, in practice I have seen embedded headers= in received SIP Request-URI's. In particular, in INVITE's created from RE= FER's, and in ENUM-routing cases. In such cases there could theoretically = be ambiguity whether the embedded header came from the HI mechanism vs. the= actual request-URI. 5) The hi-targeted-to-uri can be a tel-uri (right?); can tel-URI's have emb= edded headers? (it's not a SIP-URI) -hadriel > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Mary Barnes > Sent: Friday, July 10, 2009 4:44 PM > To: Dale Worley; Francois Audet > Cc: SIPCORE > Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax >=20 > A couple points below [MB]. >=20 > Mary. >=20 > -----Original Message----- > From: Worley, Dale (BL60:9D30) > Sent: Friday, July 10, 2009 3:24 PM > To: Audet, Francois (SC100:3055) > Cc: Barnes, Mary (RICH2:AR00); SIPCORE > Subject: RE: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax >=20 > On Thu, 2009-07-09 at 14:07 -0400, Audet, Francois (SC100:3055) wrote: > > It's basically saying that the Privacy and Reason "escaped parameters" >=20 > > would translate into headers if we were to created a request based on > it. >=20 > I can't see any circumstances where we would want to create a request > that included the Privacy or Reason headers from a H-I entry. >=20 > In regard to Privacy, if its value is "history", that means that the > particular H-I URI should be restricted. But that is not the meaning of > adding the "Privacy: history" header to a request -- in the latter case, > History-Info should not be generated at all. (Which is what I mean when > I say "the values of Privacy in History-Info do not have the same > semantics as the values of the Privacy header".) >=20 > In regard to Reason, as far as I can tell, it is attached to an H-I > entry to show the response that was received to the request that was > sent to that URI. Generating a request based on that H-I entry would > create a request to that same URI, containing a Reason header in the > request that *predicts* the response that the request will receive. >=20 > Given that in no case would we want to generate and use (with the > implicit headers) a request based on the H-I entry's URI-with-headers, I > don't see why these data items are stored in headers attached to the > URI. > [MB] We discussed this in another thread and the motivation was the > reuse of existing headers rather than defining parameters that had the > same semantics and values. That was discussed at IETF-55 in Atlanta in > the SIPPING WG meeting in November 2002: > http://www.ietf.org/proceedings/02nov/slides/sipping-2/sld5.htm >=20 > And, this makes sense in particular for Reason and perhaps lesser so for > Privacy. And, as you say we would never use the Request URIs in these > hi-entrys to generate a request so this does not cause any problems. > The intent is not to add parameters to the Request URI for any reasons > other than to take advantage of the "clever" escaping mechanism provided > by HTTP and to avoid defining parameters with the same values as the > headers, both of which are not bad ideas. And, the normative text is > quite clear that this is the intent. [/MB] >=20 > On Wed, 2009-07-08 at 19:25 -0400, Barnes, Mary (RICH2:AR00) wrote: > > As far as privacy, I'm not sure what you mean with regards to " This > > privacy value is an annotation of the URI, whereas the current syntax > > incorporates it *into* the URI." The privacy value isn't incorporated >=20 > > into the URI - it's an escaped parameter. >=20 > It's an escaped parameter, but it *is* part of the URI -- see the > production "SIP-URI" in section 25.1 of RFC 3261. And if you ask the > grammar, "What is the URI part of an H-I entry?" you will get back the > 'headers' as part of the URI. > [MB] See my comment above. Since we have specified clearly in the HI > ABNF and in the normative text, this URI needs to be appropriately > handled to derive the parameters. And, it is not abnormal to remove the > headers that are escaped in the URIs - basic HTTP. >=20 > Similarly, any device or syntax which admits a SIP URI will allow you to > enter a string containing 'headers'. Indeed, there is only one > situation where a SIP URI is possible but that URI cannot contain > 'headers', and that is as the request-URI of a request. That isn't > specified in the syntax (which allows SIP-URI), but is a consequence of > the processing in section 19.1.5, which removes the 'headers' from the > supplied SIP URI and turns them into message headers. > [MB] Exactly and that's why it's not a problem. Since we are capturing a > Request URI, there is no conflict between the headers that we escape > since no other headers can be escaped in the Request URI. > [/MB] >=20 > Dale >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From HKaplan@acmepacket.com Sat Jul 11 14:11:38 2009 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 1F8383A6B2E for ; Sat, 11 Jul 2009 14:11:38 -0700 (PDT) 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.075, 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 JJXYEjRdGwFr for ; Sat, 11 Jul 2009 14:11:36 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A001A3A68D4 for ; Sat, 11 Jul 2009 14:11:36 -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.1.375.2; Sat, 11 Jul 2009 17:12:05 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 11 Jul 2009 17:12:02 -0400 From: Hadriel Kaplan To: Hadriel Kaplan , Mary Barnes , Dale Worley , Francois Audet Date: Sat, 11 Jul 2009 17:11:48 -0400 Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax Thread-Index: AcoBnGvHKCIaPFDpQf+/3xhnWI6IYwAAJ2rwAC99fZAABD00QA== Message-ID: References: <1246996560.5962.37.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EDE5C07@zrc2hxm0.corp.nortel.com> <1247077928.3712.26.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EE8A67C@zrc2hxm0.corp.nortel.com> <1247257464.3757.67.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EEDE853@zrc2hxm0.corp.nortel.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 Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax 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, 11 Jul 2009 21:11:38 -0000 Ignore that email - just realized it was done that way in the original RFC4= 424, so we're stuck with it for posterity's sake. Blech. -hadriel > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Hadriel Kaplan > Sent: Saturday, July 11, 2009 4:17 PM > To: Mary Barnes; Dale Worley; Francois Audet > Cc: SIPCORE > Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax >=20 >=20 > Howdy, > I have some warning bell ringing in my head against this idea of changing > the Request-URI encoded in the HI header (the hi-targeted-to-uri) to > include an embedded Reason or Privacy header. I think the bell is due to > the following concerns: >=20 > 1) Afaict, the Reason value is not an attribute/property of the URI - it > is the History-Info mechanism's specific rerouting cause, i.e. it's a > property of what caused the HI header field to be created, so it's a > property of the header field. The Privacy header is a little less clear, > but again ISTM that it's a command for the HI mechanism itself, and thus > an attribute of the HI header field. For example, one of the potential > actions to be taken by a Proxy is to remove the HI entry entirely - not > just the URI. >=20 > 2) If it weren't for this added escaped URI header, the hi-targeted-to-ur= i > would be a literal copy of the original request-URI. (right?) That would > provide a clean way of doing troubleshooting and target > determination/matching, without exception checking for special things > added by this RFC into the URI for its own purposes. >=20 > 3) If we ever decide to create some way of securing the original URI in > HI's, for example by signing it, it adds confusion or even breaks the > signature if the original URI is not actually left alone. >=20 > 4) While it may seem that embedded headers could not have appeared in the > received Request-URI to being with, in practice I have seen embedded > headers in received SIP Request-URI's. In particular, in INVITE's create= d > from REFER's, and in ENUM-routing cases. In such cases there could > theoretically be ambiguity whether the embedded header came from the HI > mechanism vs. the actual request-URI. >=20 > 5) The hi-targeted-to-uri can be a tel-uri (right?); can tel-URI's have > embedded headers? (it's not a SIP-URI) >=20 > -hadriel >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf > > Of Mary Barnes > > Sent: Friday, July 10, 2009 4:44 PM > > To: Dale Worley; Francois Audet > > Cc: SIPCORE > > Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax > > > > A couple points below [MB]. > > > > Mary. > > > > -----Original Message----- > > From: Worley, Dale (BL60:9D30) > > Sent: Friday, July 10, 2009 3:24 PM > > To: Audet, Francois (SC100:3055) > > Cc: Barnes, Mary (RICH2:AR00); SIPCORE > > Subject: RE: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax > > > > On Thu, 2009-07-09 at 14:07 -0400, Audet, Francois (SC100:3055) wrote: > > > It's basically saying that the Privacy and Reason "escaped parameters= " > > > > > would translate into headers if we were to created a request based on > > it. > > > > I can't see any circumstances where we would want to create a request > > that included the Privacy or Reason headers from a H-I entry. > > > > In regard to Privacy, if its value is "history", that means that the > > particular H-I URI should be restricted. But that is not the meaning o= f > > adding the "Privacy: history" header to a request -- in the latter case= , > > History-Info should not be generated at all. (Which is what I mean whe= n > > I say "the values of Privacy in History-Info do not have the same > > semantics as the values of the Privacy header".) > > > > In regard to Reason, as far as I can tell, it is attached to an H-I > > entry to show the response that was received to the request that was > > sent to that URI. Generating a request based on that H-I entry would > > create a request to that same URI, containing a Reason header in the > > request that *predicts* the response that the request will receive. > > > > Given that in no case would we want to generate and use (with the > > implicit headers) a request based on the H-I entry's URI-with-headers, = I > > don't see why these data items are stored in headers attached to the > > URI. > > [MB] We discussed this in another thread and the motivation was the > > reuse of existing headers rather than defining parameters that had the > > same semantics and values. That was discussed at IETF-55 in Atlanta in > > the SIPPING WG meeting in November 2002: > > http://www.ietf.org/proceedings/02nov/slides/sipping-2/sld5.htm > > > > And, this makes sense in particular for Reason and perhaps lesser so fo= r > > Privacy. And, as you say we would never use the Request URIs in these > > hi-entrys to generate a request so this does not cause any problems. > > The intent is not to add parameters to the Request URI for any reasons > > other than to take advantage of the "clever" escaping mechanism provide= d > > by HTTP and to avoid defining parameters with the same values as the > > headers, both of which are not bad ideas. And, the normative text is > > quite clear that this is the intent. [/MB] > > > > On Wed, 2009-07-08 at 19:25 -0400, Barnes, Mary (RICH2:AR00) wrote: > > > As far as privacy, I'm not sure what you mean with regards to " This > > > privacy value is an annotation of the URI, whereas the current syntax > > > incorporates it *into* the URI." The privacy value isn't incorporate= d > > > > > into the URI - it's an escaped parameter. > > > > It's an escaped parameter, but it *is* part of the URI -- see the > > production "SIP-URI" in section 25.1 of RFC 3261. And if you ask the > > grammar, "What is the URI part of an H-I entry?" you will get back the > > 'headers' as part of the URI. > > [MB] See my comment above. Since we have specified clearly in the HI > > ABNF and in the normative text, this URI needs to be appropriately > > handled to derive the parameters. And, it is not abnormal to remove the > > headers that are escaped in the URIs - basic HTTP. > > > > Similarly, any device or syntax which admits a SIP URI will allow you t= o > > enter a string containing 'headers'. Indeed, there is only one > > situation where a SIP URI is possible but that URI cannot contain > > 'headers', and that is as the request-URI of a request. That isn't > > specified in the syntax (which allows SIP-URI), but is a consequence of > > the processing in section 19.1.5, which removes the 'headers' from the > > supplied SIP URI and turns them into message headers. > > [MB] Exactly and that's why it's not a problem. Since we are capturing = a > > Request URI, there is no conflict between the headers that we escape > > since no other headers can be escaped in the Request URI. > > [/MB] > > > > 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 Jul 11 22:00:05 2009 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 52B1228C0ED for ; Sat, 11 Jul 2009 22:00:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.528 X-Spam-Level: X-Spam-Status: No, score=-2.528 tagged_above=-999 required=5 tests=[AWL=0.071, 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 jE+LScKpC1lc for ; Sat, 11 Jul 2009 22:00:02 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 8EA5428B797 for ; Sat, 11 Jul 2009 22:00:01 -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.1.375.2; Sun, 12 Jul 2009 01:00:30 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 12 Jul 2009 01:00:29 -0400 From: Hadriel Kaplan To: SIPCORE Date: Sun, 12 Jul 2009 01:00:28 -0400 Thread-Topic: rfc4244bis: what is an AoR? Thread-Index: AcoCrazV4PjGDXJYQVyso2A4fcXevg== 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] rfc4244bis: what is an AoR? 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, 12 Jul 2009 05:00:05 -0000 Howdy, This may be from left-field, or already discussed previously - if so please= excuse my ignorance. I see the term "AoR" as being somehow treated as an unambiguous term, knowa= ble to a Proxy of the AoR's domain as being an "AoR" on sight. It is then = used in the draft to identify a specific HI URI as the original-target URI = - the identifier to look for when trying to find the "original" request-URI= . Right? So if the Proxy of the AoR's domain is supposed to indicate a SIP-URI is an= AoR, how does it know it? What is the distinguishing parameter or URI syn= tax of an AoR, which makes it different from any-old sip:user@domain SIP-UR= I? For example, is "sip:rai-ad@ietf.org" an AoR? Is "sip:+18005551212@sp.com;= user=3Dphone" an AoR? Is "sip:asd887f9dfkk76690@example.com;gr" an AoR? I'm not trying to be flippant (well, ok I am) but there is no such distingu= ishing characteristic, afaik. It is an abstract concept, and it is just a = specific subset of SIP/SIPS-URIs we use to describe something; but it means= nothing in particular to a Proxy really, does it? For example AoR's are n= ot all/only SIP-URI's that are Registered through a SIP REGISTER transactio= n; they can be statically routed/resolved, or added to a location service v= ia a web page, etc. In some of our specs we consider an AoR to be the huma= n identity, whereas a contact address is a machine, but really there's noth= ing that makes it be a human identity - it could be a group identity, a con= f room phone, a voicemail box, an alias for anther AoR, etc. In fact I'm not even sure it's all of the things we need it to be: for exam= ple a temp GRUU is not usually considered an AoR, afaik. Yet identifying t= he original GRUU from the original request-URI was one of the motivating fa= ctors for Jonathan's ua-loose-routing draft which got us here, no? In fact= , we didn't care if it was an "AoR" whatsoever - if the original UAC used a= request-URI containing the Contact-URI of a UAS, we wanted to know it; if = it used a Tel-URI, we wanted to know that too (and a TEL-URI is not an "AoR= ", afaik). Or am I missing something obvious? (could be - my brain's dead) -hadriel From HKaplan@acmepacket.com Sat Jul 11 23:12:35 2009 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 96CB03A684A for ; Sat, 11 Jul 2009 23:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.531 X-Spam-Level: X-Spam-Status: No, score=-3.531 tagged_above=-999 required=5 tests=[AWL=1.068, BAYES_00=-2.599, GB_I_LETTER=-2] 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 F4HLinp4fkCc for ; Sat, 11 Jul 2009 23:12:34 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 97BF93A6452 for ; Sat, 11 Jul 2009 23:12:34 -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.1.375.2; Sun, 12 Jul 2009 02:13:02 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 12 Jul 2009 02:13:02 -0400 From: Hadriel Kaplan To: SIPCORE Date: Sun, 12 Jul 2009 02:13:00 -0400 Thread-Topic: rfc4424bis: what are these hi-target values for? Thread-Index: AcoCt876p/khqArdRYiPxxudqrglRg== 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] rfc4424bis: what are these hi-target values for? 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, 12 Jul 2009 06:12:35 -0000 Howdy, Another comment from the peanut gallery: I think I've read all the emails on this draft now, as well as the drafts, = and I still have no idea what value the hi-target params bring (the noop/pr= edetermined/reg-uri/reg-uri-alias in draft-01, or the rc/cc/mp/rt in draft-= 02) besides interop issues. I *think* I understand what we need: we need to know when the request was a= ctually re-targeted to a different identity, vs. just routed to the origina= l one; and we need to know/find the "original" request-URI for last target = even if the request-URI in the SIP message we receive has been changed for = other reasons (e.g., Registration resolution). So then I look at these params, and it doesn't grok. I have no idea what a= UAS is supposed to do differently with these different values. "Noop" mad= e sense, in the sense that nothing changed and one wonders why a Proxy both= ered cluttering up the History-Info list with gratuitous entries. The para= m "mp" is the one that makes the most sense, because it's actually for when= re-targeting occurs (right?). So I get why we need that one, and why the = UAS should care about it. Having separate params for "rc"/"cc" doesn't mak= e sense to me - who cares if the location-service learned it through a SIP = REGISTER or just read some tea leaves? The param "rt" seems like a bad con= flation of "noop" and "cc". (really bad) I guess one explanation can be "for troubleshooting purposes", but I'm gues= sing we'll be troubleshooting these troubleshooting purposes, because devic= es will invariably get them wrong, and other devices will invariably use th= em for some actual purpose; or worse, someone will make a middlebox modify = these things to fix them to be what the next-hops expect, or hide why it be= came what it is. :( This is like response codes all over again. I know this is freaky thinking= , but does it really matter *why* a Proxy inserted an HI entry? - what matt= ers is what the UAS receiving them should *do* with it. -Hadriel "confused" Kaplan p.s. these 2-letter param names are really confusing; it was better with sh= ort terms. I don't like making SIP messages longer either, but really the = whole HI mechanism is already an exercise in verbosity. (although since the= y're distinct params, we can always call the param's by their descriptive n= ames and just encode them in 2 letters on the wire - like "loose route" vs.= "lr") From jmpolk@cisco.com Sun Jul 12 00:00:31 2009 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 D401F3A6BEE for ; Sun, 12 Jul 2009 00:00:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.013 X-Spam-Level: X-Spam-Status: No, score=-6.013 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, J_CHICKENPOX_33=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 h8S97t6LDlcg for ; Sun, 12 Jul 2009 00:00:31 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 004653A6BC0 for ; Sun, 12 Jul 2009 00:00:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYGAEYnWUqrR7PD/2dsb2JhbACIPapeiCOPJQWCMwGBVQ X-IronPort-AV: E=Sophos;i="4.42,386,1243814400"; d="scan'208";a="212676822" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 12 Jul 2009 07:01:00 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6C710Ej017796; Sun, 12 Jul 2009 00:01:00 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6C71010014354; Sun, 12 Jul 2009 07:01:00 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 00:01:00 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.0.35]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 00:01:00 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 12 Jul 2009 02:00:58 -0500 To: Hadriel Kaplan , SIPCORE From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 12 Jul 2009 07:01:00.0355 (UTC) FILETIME=[834F8930:01CA02BE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3001; t=1247382060; x=1248246060; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[sipcore]=20rfc4244bis=3A=20what=20is=2 0an=20AoR? |Sender:=20; bh=ZDkYSAJVeYifddSa21yM8oKCo68o+UHbsHc/oO0dRLM=; b=GRShSm9C49zwap1v/1MKfl+MdL2x+XTmInf40fRlmwa7H92pqJGUbvxOQk 1sdMx5fyOeyUtVtSycqI+mQJkqMfF+/VQMr9pNhFxjlmyEr8o9ItUDcbj4pt JresQBJrI9; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 12 Jul 2009 07:00:31 -0000 At 12:00 AM 7/12/2009, Hadriel Kaplan wrote: >Howdy, >This may be from left-field, or already discussed previously - if so >please excuse my ignorance. > >I see the term "AoR" as being somehow treated as an unambiguous >term, knowable to a Proxy of the AoR's domain as being an "AoR" on >sight. It is then used in the draft to identify a specific HI URI >as the original-target URI - the identifier to look for when trying >to find the "original" request-URI. Right? > >So if the Proxy of the AoR's domain is supposed to indicate a >SIP-URI is an AoR, how does it know it? What is the distinguishing >parameter or URI syntax of an AoR, which makes it different from >any-old sip:user@domain SIP-URI? isn't an AOR a SIP:URI that doesn't have a contact host on the domain side of the URI? For example, alice@example.com is an AOR but alice@pc33.example.com is not an AOR *because* of the host part (pc33) to the right of the @ I'm sure this is simplistic I'm also curious if someone knows the secret sauce to this, if there is such an animal... >For example, is "sip:rai-ad@ietf.org" an AoR? I think this one is an AOR >Is "sip:+18005551212@sp.com;user=phone" an AoR? no sure on this one > Is "sip:asd887f9dfkk76690@example.com;gr" an AoR? seem like this one is too >I'm not trying to be flippant (well, ok I am) BTW - you're always flippant, so you don't need to qualify yourself ;-) >but there is no such distinguishing characteristic, afaik. It is an >abstract concept, and it is just a specific subset of SIP/SIPS-URIs >we use to describe something; but it means nothing in particular to >a Proxy really, does it? For example AoR's are not all/only >SIP-URI's that are Registered through a SIP REGISTER transaction; >they can be statically routed/resolved, or added to a location >service via a web page, etc. In some of our specs we consider an >AoR to be the human identity, whereas a contact address is a >machine, but really there's nothing that makes it be a human >identity - it could be a group identity, a conf room phone, a >voicemail box, an alias for anther AoR, etc. > >In fact I'm not even sure it's all of the things we need it to be: >for example a temp GRUU is not usually considered an AoR, >afaik. Yet identifying the original GRUU from the original >request-URI was one of the motivating factors for Jonathan's >ua-loose-routing draft which got us here, no? In fact, we didn't >care if it was an "AoR" whatsoever - if the original UAC used a >request-URI containing the Contact-URI of a UAS, we wanted to know >it; if it used a Tel-URI, we wanted to know that too (and a TEL-URI >is not an "AoR", afaik). Or am I missing something obvious? (could >be - my brain's dead) > >-hadriel >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From HKaplan@acmepacket.com Sun Jul 12 00:46:29 2009 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 A89923A6951 for ; Sun, 12 Jul 2009 00:46:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.266 X-Spam-Level: X-Spam-Status: No, score=-2.266 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, J_CHICKENPOX_33=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 KcdPn-IAw900 for ; Sun, 12 Jul 2009 00:46:29 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C70CD3A6452 for ; Sun, 12 Jul 2009 00:46:28 -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.1.375.2; Sun, 12 Jul 2009 03:46:56 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 12 Jul 2009 03:46:56 -0400 From: Hadriel Kaplan To: "James M. Polk" , SIPCORE Date: Sun, 12 Jul 2009 03:46:55 -0400 Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoCvpJsZKNX/4ThSUufELdpnqPNDwAAETvQ 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] rfc4244bis: what is an AoR? 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, 12 Jul 2009 07:46:29 -0000 > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com] > Sent: Sunday, July 12, 2009 3:01 AM >=20 > isn't an AOR a SIP:URI that doesn't have a contact host on the domain > side of the URI? >=20 > For example, >=20 > alice@example.com is an AOR > but > alice@pc33.example.com is not an AOR *because* > of the host part (pc33) to the right of the @ *You* know pc33 is a hostname. As far as I know, pc33.example.com is a SIP= domain. For example "sip:jmpolk@cisco.com" is an AoR, but so could "sip:j= mpolk@us.cisco.com" be. (and furthermore there's nothing to prevent a host = from running its own SIP domain, afaik) Obviously pc33.example.com itself could know, and that was the point of the= "aor" param being added by the targeted domain presumably, but my issue is= more of a how does even it know? (and secondly, why does it matter if it's= an "AoR"?) For example, if pc33 was a CCM and has an internal static route for "alice@= pc33.example.com" to be routed to a SIP Trunk, was alice an AoR? What if "alice@pc33.example.com" is actually a test-loopback URI on the CCM= itself, or is a specific voicemail box on the CCM (ie, the URI was the con= tact address)? > >I'm not trying to be flippant (well, ok I am) >=20 > BTW - you're always flippant, so you don't need to qualify yourself ;-) Just in case people forget. :) -hadriel From ietf.hanserik@gmail.com Sun Jul 12 02:54:29 2009 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 583C93A68AB for ; Sun, 12 Jul 2009 02:54:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.19 X-Spam-Level: X-Spam-Status: No, score=-2.19 tagged_above=-999 required=5 tests=[AWL=0.409, 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 VdQ3cIo62fBz for ; Sun, 12 Jul 2009 02:54:28 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 859653A67B3 for ; Sun, 12 Jul 2009 02:54:27 -0700 (PDT) Received: by ewy26 with SMTP id 26so1975934ewy.37 for ; Sun, 12 Jul 2009 02:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=utok1XrVFDUlVGS6pR2NAwAKQv/v+eW3Rs1RYz1/CdA=; b=L0jwrZo0s6X/6hxvfzXYtYE0qzW/8L2eUHTUCrBIEjV7fPEygPu2xu2SUW2vYgmcVe eS082SqVomHWmhMJyftMulMMo4LvEsXGbW6Izn8L9lvNmR5EQoCsNliNr6ByBbzgXcB1 rfwPEeNU8o0CvBVX88GWu1lHCbFx1K7fy109g= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=WkfspHiIwrtZo8JEhgp+qLBmv2RaE9ByhE0SamFoHttqcoss7UDvp0gX+uGvxsRQZ3 smdSM9K6wA9nAg3lMrv8ViUviocFL2wXqVbrCKqF5KkXKlsk7eJzAbTIFFTimeDiiOz9 IKOcFy6Qi5US5KVcxZA/ZlThjVm7743uO3xVQ= Received: by 10.210.42.20 with SMTP id p20mr3515883ebp.60.1247392494545; Sun, 12 Jul 2009 02:54:54 -0700 (PDT) Received: from ?192.168.2.100? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 7sm3361001eyg.28.2009.07.12.02.54.53 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 12 Jul 2009 02:54:53 -0700 (PDT) Message-ID: <4A59B2EC.8000609@gmail.com> Date: Sun, 12 Jul 2009 11:54:52 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Hadriel Kaplan References: <1246996560.5962.37.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EDE5C07@zrc2hxm0.corp.nortel.com> <1247077928.3712.26.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EE8A67C@zrc2hxm0.corp.nortel.com> <1247257464.3757.67.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EEDE853@zrc2hxm0.corp.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE , Dale Worley Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax 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, 12 Jul 2009 09:54:29 -0000 Yes, I agreed with most points you raised below. Question is if this can be fixed in a backward compatible way, seems hard unfortunately /Hans Erik Hadriel Kaplan wrote: > Ignore that email - just realized it was done that way in the original RFC4424, so we're stuck with it for posterity's sake. Blech. > > -hadriel > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf >> Of Hadriel Kaplan >> Sent: Saturday, July 11, 2009 4:17 PM >> To: Mary Barnes; Dale Worley; Francois Audet >> Cc: SIPCORE >> Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax >> >> >> Howdy, >> I have some warning bell ringing in my head against this idea of changing >> the Request-URI encoded in the HI header (the hi-targeted-to-uri) to >> include an embedded Reason or Privacy header. I think the bell is due to >> the following concerns: >> >> 1) Afaict, the Reason value is not an attribute/property of the URI - it >> is the History-Info mechanism's specific rerouting cause, i.e. it's a >> property of what caused the HI header field to be created, so it's a >> property of the header field. The Privacy header is a little less clear, >> but again ISTM that it's a command for the HI mechanism itself, and thus >> an attribute of the HI header field. For example, one of the potential >> actions to be taken by a Proxy is to remove the HI entry entirely - not >> just the URI. >> >> 2) If it weren't for this added escaped URI header, the hi-targeted-to-uri >> would be a literal copy of the original request-URI. (right?) That would >> provide a clean way of doing troubleshooting and target >> determination/matching, without exception checking for special things >> added by this RFC into the URI for its own purposes. >> >> 3) If we ever decide to create some way of securing the original URI in >> HI's, for example by signing it, it adds confusion or even breaks the >> signature if the original URI is not actually left alone. >> >> 4) While it may seem that embedded headers could not have appeared in the >> received Request-URI to being with, in practice I have seen embedded >> headers in received SIP Request-URI's. In particular, in INVITE's created >> from REFER's, and in ENUM-routing cases. In such cases there could >> theoretically be ambiguity whether the embedded header came from the HI >> mechanism vs. the actual request-URI. >> >> 5) The hi-targeted-to-uri can be a tel-uri (right?); can tel-URI's have >> embedded headers? (it's not a SIP-URI) >> >> -hadriel >> >> >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>> >> Behalf >> >>> Of Mary Barnes >>> Sent: Friday, July 10, 2009 4:44 PM >>> To: Dale Worley; Francois Audet >>> Cc: SIPCORE >>> Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax >>> >>> A couple points below [MB]. >>> >>> Mary. >>> >>> -----Original Message----- >>> From: Worley, Dale (BL60:9D30) >>> Sent: Friday, July 10, 2009 3:24 PM >>> To: Audet, Francois (SC100:3055) >>> Cc: Barnes, Mary (RICH2:AR00); SIPCORE >>> Subject: RE: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax >>> >>> On Thu, 2009-07-09 at 14:07 -0400, Audet, Francois (SC100:3055) wrote: >>> >>>> It's basically saying that the Privacy and Reason "escaped parameters" >>>> >>>> would translate into headers if we were to created a request based on >>>> >>> it. >>> >>> I can't see any circumstances where we would want to create a request >>> that included the Privacy or Reason headers from a H-I entry. >>> >>> In regard to Privacy, if its value is "history", that means that the >>> particular H-I URI should be restricted. But that is not the meaning of >>> adding the "Privacy: history" header to a request -- in the latter case, >>> History-Info should not be generated at all. (Which is what I mean when >>> I say "the values of Privacy in History-Info do not have the same >>> semantics as the values of the Privacy header".) >>> >>> In regard to Reason, as far as I can tell, it is attached to an H-I >>> entry to show the response that was received to the request that was >>> sent to that URI. Generating a request based on that H-I entry would >>> create a request to that same URI, containing a Reason header in the >>> request that *predicts* the response that the request will receive. >>> >>> Given that in no case would we want to generate and use (with the >>> implicit headers) a request based on the H-I entry's URI-with-headers, I >>> don't see why these data items are stored in headers attached to the >>> URI. >>> [MB] We discussed this in another thread and the motivation was the >>> reuse of existing headers rather than defining parameters that had the >>> same semantics and values. That was discussed at IETF-55 in Atlanta in >>> the SIPPING WG meeting in November 2002: >>> http://www.ietf.org/proceedings/02nov/slides/sipping-2/sld5.htm >>> >>> And, this makes sense in particular for Reason and perhaps lesser so for >>> Privacy. And, as you say we would never use the Request URIs in these >>> hi-entrys to generate a request so this does not cause any problems. >>> The intent is not to add parameters to the Request URI for any reasons >>> other than to take advantage of the "clever" escaping mechanism provided >>> by HTTP and to avoid defining parameters with the same values as the >>> headers, both of which are not bad ideas. And, the normative text is >>> quite clear that this is the intent. [/MB] >>> >>> On Wed, 2009-07-08 at 19:25 -0400, Barnes, Mary (RICH2:AR00) wrote: >>> >>>> As far as privacy, I'm not sure what you mean with regards to " This >>>> privacy value is an annotation of the URI, whereas the current syntax >>>> incorporates it *into* the URI." The privacy value isn't incorporated >>>> >>>> into the URI - it's an escaped parameter. >>>> >>> It's an escaped parameter, but it *is* part of the URI -- see the >>> production "SIP-URI" in section 25.1 of RFC 3261. And if you ask the >>> grammar, "What is the URI part of an H-I entry?" you will get back the >>> 'headers' as part of the URI. >>> [MB] See my comment above. Since we have specified clearly in the HI >>> ABNF and in the normative text, this URI needs to be appropriately >>> handled to derive the parameters. And, it is not abnormal to remove the >>> headers that are escaped in the URIs - basic HTTP. >>> >>> Similarly, any device or syntax which admits a SIP URI will allow you to >>> enter a string containing 'headers'. Indeed, there is only one >>> situation where a SIP URI is possible but that URI cannot contain >>> 'headers', and that is as the request-URI of a request. That isn't >>> specified in the syntax (which allows SIP-URI), but is a consequence of >>> the processing in section 19.1.5, which removes the 'headers' from the >>> supplied SIP URI and turns them into message headers. >>> [MB] Exactly and that's why it's not a problem. Since we are capturing a >>> Request URI, there is no conflict between the headers that we escape >>> since no other headers can be escaped in the Request URI. >>> [/MB] >>> >>> 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 ietf.hanserik@gmail.com Sun Jul 12 03:10:02 2009 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 2DDD73A68A7 for ; Sun, 12 Jul 2009 03:10:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[AWL=0.090, BAYES_00=-2.599, J_CHICKENPOX_33=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 1FKUO9kjDY8P for ; Sun, 12 Jul 2009 03:10:01 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id DE38F3A680F for ; Sun, 12 Jul 2009 03:10:00 -0700 (PDT) Received: by ewy26 with SMTP id 26so1979686ewy.37 for ; Sun, 12 Jul 2009 03:10:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=aZZ9IqAEDFNPsOOqM4xNMqGN5p0KC9MgjslTPVCW2E8=; b=kMf9QWz8iqYsxOHz1OAzB+Tnunv1Lw3fwX8wKnrl+wPQSBQm1Qn6lggyg6TgkQvaJ0 z1dfYSIiYjKpaZtGKIJ2vNuUamQJArP/XiwlIsFO4dZzxRIHEcmzIbXHILxdBNRn7qYm nm34pVJRoxJZpQXImjhxrQoviocrSF/nEDqOE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=j1zK7bd25bBbVAQxky97EffUA+Gjz9u5IozT5+i1aJPoTWfXL65LzcCv9Si/1AsoSW lNQpwQRhajr4Awyh3paJc8zjDCU103ht0V0GZ9aDJ6/rBKVszwn0wVemxW7+C04Q4RAN pENae8UbbxR7wKvSJb6FTozZwShYhz+qCCyIY= Received: by 10.210.102.12 with SMTP id z12mr4683831ebb.89.1247393428324; Sun, 12 Jul 2009 03:10:28 -0700 (PDT) Received: from ?192.168.2.100? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 5sm6928191eyh.40.2009.07.12.03.10.27 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 12 Jul 2009 03:10:28 -0700 (PDT) Message-ID: <4A59B693.9010807@gmail.com> Date: Sun, 12 Jul 2009 12:10:27 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Hadriel Kaplan References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 12 Jul 2009 10:10:02 -0000 Well.. definition of AOR per RFC3261: "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the "public address" of the user." The approach taken is that if a proxy determines that a Request-URI on an incoming request is for a domain that it is responsible for, it performs an abstract-location-server lookup for the URI then this must be an AOR and the proxy tags the H-I entry representimg this uri as being an AOR. To me this seems totally deterministic. BTW a GRUU in this sense is also an AOR. /Hans Erik Hadriel Kaplan wrote: > > > -----Original Message----- From: James M. Polk > > [mailto:jmpolk@cisco.com] Sent: Sunday, July 12, 2009 3:01 AM > > > > isn't an AOR a SIP:URI that doesn't have a contact host on the > > domain side of the URI? > > > > For example, > > > > alice@example.com is an AOR but alice@pc33.example.com is not an > > AOR *because* of the host part (pc33) to the right of the @ > > *You* know pc33 is a hostname. As far as I know, pc33.example.com is > a SIP domain. For example "sip:jmpolk@cisco.com" is an AoR, but so > could "sip:jmpolk@us.cisco.com" be. (and furthermore there's nothing > to prevent a host from running its own SIP domain, afaik) > > Obviously pc33.example.com itself could know, and that was the point > of the "aor" param being added by the targeted domain presumably, but > my issue is more of a how does even it know? (and secondly, why does > it matter if it's an "AoR"?) > > For example, if pc33 was a CCM and has an internal static route for > "alice@pc33.example.com" to be routed to a SIP Trunk, was alice an > AoR? > > What if "alice@pc33.example.com" is actually a test-loopback URI on > the CCM itself, or is a specific voicemail box on the CCM (ie, the > URI was the contact address)? > > > >> I'm not trying to be flippant (well, ok I am) > > BTW - you're always flippant, so you don't need to qualify yourself > > ;-) > > Just in case people forget. :) > > -hadriel _______________________________________________ sipcore > mailing list sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From ietf.hanserik@gmail.com Sun Jul 12 03:19:36 2009 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 5D6143A6A73 for ; Sun, 12 Jul 2009 03:19:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.213 X-Spam-Level: X-Spam-Status: No, score=-3.213 tagged_above=-999 required=5 tests=[AWL=1.386, BAYES_00=-2.599, GB_I_LETTER=-2] 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 rTQPwXK9hQza for ; Sun, 12 Jul 2009 03:19:35 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id D54D43A6A2A for ; Sun, 12 Jul 2009 03:19:34 -0700 (PDT) Received: by ewy26 with SMTP id 26so1981991ewy.37 for ; Sun, 12 Jul 2009 03:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=loDaaB1XOh5LuBonDT/9KBwxt1ADs3kq8gIgX9DPHPg=; b=KOfp0H9vkvdGfG5ZwSOC57Wt2UUz1LpxTF3Xq65VjSuGLqbU6wR9ehMbwUJKQaS436 r4i+uOuldXZ9C9z+tyVLOnm3Z2qEmnzGW+P4UiklvU8cSbemi8qrrSA8E/N68Fca9bJq Mn5kuvNC9aY4W0sQi3edmjOpwVceZJZEsYp2E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=k6YZixBbOSkk+O1mL83IZjA/37DrdIKMSwi3nrbhmgIrGDxQcq0J5YO0AXi+xAkZXj g264tpQp46vAkDEaIPpYP11YmR/VvE9S7K22cOBpDAbPEEom98qVOAlFEJgz6SyM9XI8 52xC2zCMKH+HBtuPxvpuJw3H3WNFoCzKrO+4A= Received: by 10.210.63.18 with SMTP id l18mr4729058eba.67.1247394001466; Sun, 12 Jul 2009 03:20:01 -0700 (PDT) Received: from ?192.168.2.100? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 10sm6964151eyz.21.2009.07.12.03.20.00 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 12 Jul 2009 03:20:01 -0700 (PDT) Message-ID: <4A59B8CB.7050101@gmail.com> Date: Sun, 12 Jul 2009 12:19:55 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Hadriel Kaplan References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] rfc4424bis: what are these hi-target values for? 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, 12 Jul 2009 10:19:36 -0000 Think you are right in that "mp" and "aor" is most important for a UAS that is only interested in target-uri use cases. I.e. the presence of an "mp" tag can be used to make the best guess about what was the original called target. Its absence means the first hi-entry is the best guess. And by looking up the last entry tagged "aor" a UAS can determine the GRUU or alternative AOR which was used to reach it. (Similar as what P-Called-Party-ID is used for in IMS.) /Hans Erik Hadriel Kaplan wrote: > Howdy, > Another comment from the peanut gallery: > I think I've read all the emails on this draft now, as well as the drafts, and I still have no idea what value the hi-target params bring (the noop/predetermined/reg-uri/reg-uri-alias in draft-01, or the rc/cc/mp/rt in draft-02) besides interop issues. > > I *think* I understand what we need: we need to know when the request was actually re-targeted to a different identity, vs. just routed to the original one; and we need to know/find the "original" request-URI for last target even if the request-URI in the SIP message we receive has been changed for other reasons (e.g., Registration resolution). > > So then I look at these params, and it doesn't grok. I have no idea what a UAS is supposed to do differently with these different values. "Noop" made sense, in the sense that nothing changed and one wonders why a Proxy bothered cluttering up the History-Info list with gratuitous entries. The param "mp" is the one that makes the most sense, because it's actually for when re-targeting occurs (right?). So I get why we need that one, and why the UAS should care about it. Having separate params for "rc"/"cc" doesn't make sense to me - who cares if the location-service learned it through a SIP REGISTER or just read some tea leaves? The param "rt" seems like a bad conflation of "noop" and "cc". (really bad) > > I guess one explanation can be "for troubleshooting purposes", but I'm guessing we'll be troubleshooting these troubleshooting purposes, because devices will invariably get them wrong, and other devices will invariably use them for some actual purpose; or worse, someone will make a middlebox modify these things to fix them to be what the next-hops expect, or hide why it became what it is. :( > > This is like response codes all over again. I know this is freaky thinking, but does it really matter *why* a Proxy inserted an HI entry? - what matters is what the UAS receiving them should *do* with it. > > > -Hadriel "confused" Kaplan > > p.s. these 2-letter param names are really confusing; it was better with short terms. I don't like making SIP messages longer either, but really the whole HI mechanism is already an exercise in verbosity. (although since they're distinct params, we can always call the param's by their descriptive names and just encode them in 2 letters on the wire - like "loose route" vs. "lr") > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From jmpolk@cisco.com Sun Jul 12 11:19:14 2009 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 97E3C28C16E for ; Sun, 12 Jul 2009 11:19:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.013 X-Spam-Level: X-Spam-Status: No, score=-6.013 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, J_CHICKENPOX_33=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 JMRTe5RQ68rL for ; Sun, 12 Jul 2009 11:19:13 -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 95ECF28C179 for ; Sun, 12 Jul 2009 11:19:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMGADjGWUqrR7O6/2dsb2JhbACIPalyiCOOTQWECQ X-IronPort-AV: E=Sophos;i="4.42,387,1243814400"; d="scan'208";a="344895355" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 12 Jul 2009 18:19:38 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6CIJcj3018174; Sun, 12 Jul 2009 11:19:38 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6CIJcBD000328; Sun, 12 Jul 2009 18:19:38 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 11:19:38 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.12.85]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 11:19:37 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 12 Jul 2009 13:19:37 -0500 To: Hadriel Kaplan , SIPCORE From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 12 Jul 2009 18:19:37.0928 (UTC) FILETIME=[50E01C80:01CA031D] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1711; t=1247422778; x=1248286778; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[sipcore]=20rfc4244bis=3A=20what=20is=2 0an=20AoR? |Sender:=20; bh=M3x2dtvqMMXha+36OLqQ3WVMPFKDKtk3CgmVg5ePYsY=; b=EXJPxR3gk7U/Ysrimd8U3ZSpBXG86JpeJxREpQgRo3IisMuXGAch/lL0o3 HHw0O2WA1IvUUO/bwvYyQV4FtoHHIz/bMmxyCI7Fm1jj0ZOkrrc5Vajb5c5c hQsHFhu3fa; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 12 Jul 2009 18:19:14 -0000 At 02:46 AM 7/12/2009, Hadriel Kaplan wrote: > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: Sunday, July 12, 2009 3:01 AM > > > > isn't an AOR a SIP:URI that doesn't have a contact host on the domain > > side of the URI? > > > > For example, > > > > alice@example.com is an AOR > > but > > alice@pc33.example.com is not an AOR *because* > > of the host part (pc33) to the right of the @ > >*You* know pc33 is a hostname. As far as I know, pc33.example.com >is a SIP domain. For example "sip:jmpolk@cisco.com" is an AoR, but >so could "sip:jmpolk@us.cisco.com" be. (and furthermore there's >nothing to prevent a host from running its own SIP domain, afaik) fair point >Obviously pc33.example.com itself could know, and that was the point >of the "aor" param being added by the targeted domain presumably, >but my issue is more of a how does even it know? >(and secondly, why does it matter if it's an "AoR"?) I believe the answer here is that an AOR can get retargeted without a redirection (i.e., a 3XX isn't sent to the UAC), but I might be operating on stale info here. >For example, if pc33 was a CCM and has an internal static route for >"alice@pc33.example.com" to be routed to a SIP Trunk, was alice an AoR? > >What if "alice@pc33.example.com" is actually a test-loopback URI on >the CCM itself, or is a specific voicemail box on the CCM (ie, the >URI was the contact address)? > > > > >I'm not trying to be flippant (well, ok I am) > > > > BTW - you're always flippant, so you don't need to qualify yourself ;-) > >Just in case people forget. :) > >-hadriel From jmpolk@cisco.com Sun Jul 12 11:24:23 2009 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 410F228C16A for ; Sun, 12 Jul 2009 11:24:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.013 X-Spam-Level: X-Spam-Status: No, score=-6.013 tagged_above=-999 required=5 tests=[AWL=-0.014, BAYES_00=-2.599, J_CHICKENPOX_33=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 Tv8CEvbEAnS1 for ; Sun, 12 Jul 2009 11:24:22 -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 27AF43A6B76 for ; Sun, 12 Jul 2009 11:24:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMGAGfHWUqrR7PD/2dsb2JhbACIPal1iCOOSwWECQ X-IronPort-AV: E=Sophos;i="4.42,387,1243814400"; d="scan'208";a="344896470" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 12 Jul 2009 18:24:52 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6CIOqsb021587; Sun, 12 Jul 2009 11:24:52 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6CIOqFC014203; Sun, 12 Jul 2009 18:24:52 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 11:24:52 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.12.85]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 11:24:51 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 12 Jul 2009 13:24:51 -0500 To: Hans Erik van Elburg , Hadriel Kaplan From: "James M. Polk" In-Reply-To: <4A59B693.9010807@gmail.com> References: <4A59B693.9010807@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 12 Jul 2009 18:24:51.0859 (UTC) FILETIME=[0BFE2E30:01CA031E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2950; t=1247423092; x=1248287092; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[sipcore]=20rfc4244bis=3A=20what=20is=2 0an=20AoR? |Sender:=20; bh=1XPP8R+4xHoBsIc3rOZyhPxXHHa83ESLXnj+2PJzc20=; b=som35J37D/FhAbJDvoom1KDTbYtHSH5PwxSo+SeTLWTnW7gOCn8o9WOt9M +kwgE/iPR9sw/PP8Vg2syitvP/vWrRvCpj0pU1f2OAGAI9nKpEFPbYfkfGzL v4zDfVCHeA; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 12 Jul 2009 18:24:23 -0000 At 05:10 AM 7/12/2009, Hans Erik van Elburg wrote: >Well.. definition of AOR per RFC3261: > >"Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI > that points to a domain with a location service that can map > the URI to another URI where the user might be available. > Typically, the location service is populated through > registrations. An AOR is frequently thought of as the "public > address" of the user." > >The approach taken is that if a proxy determines that a Request-URI >on an incoming request is for a domain that it is responsible for, >it performs an abstract-location-server lookup for the URI then this >must be an AOR and the proxy tags the H-I entry representimg this >uri as being an AOR. > >To me this seems totally deterministic. > >BTW a GRUU in this sense is also an AOR. err, how isn't a GRUU an ultimate Contact address? AORs do not have hostnames in them, and Contact addresses (typically) do. The point of a GRUU is *this* instance of a UA that is universally routable. That, to me, is a Contact address that has 1 destination UA in mind. This might be splitting hairs though, and I await the masters to comment (JDR, HS, RS, or Fluffy... :-) >/Hans Erik > >Hadriel Kaplan wrote: >> >> > -----Original Message----- From: James M. Polk >> > [mailto:jmpolk@cisco.com] Sent: Sunday, July 12, 2009 3:01 AM >> > >> > isn't an AOR a SIP:URI that doesn't have a contact host on the >> > domain side of the URI? >> > >> > For example, >> > >> > alice@example.com is an AOR but alice@pc33.example.com is not an >> > AOR *because* of the host part (pc33) to the right of the @ >> >> *You* know pc33 is a hostname. As far as I know, pc33.example.com is >> a SIP domain. For example "sip:jmpolk@cisco.com" is an AoR, but so >> could "sip:jmpolk@us.cisco.com" be. (and furthermore there's nothing >> to prevent a host from running its own SIP domain, afaik) >> >> Obviously pc33.example.com itself could know, and that was the point >> of the "aor" param being added by the targeted domain presumably, but >> my issue is more of a how does even it know? (and secondly, why does >> it matter if it's an "AoR"?) >> >> For example, if pc33 was a CCM and has an internal static route for >> "alice@pc33.example.com" to be routed to a SIP Trunk, was alice an >> AoR? >> >> What if "alice@pc33.example.com" is actually a test-loopback URI on >> the CCM itself, or is a specific voicemail box on the CCM (ie, the >> URI was the contact address)? >> >> >> >> I'm not trying to be flippant (well, ok I am) >> > BTW - you're always flippant, so you don't need to qualify yourself >> > ;-) >> >> Just in case people forget. :) >> >> -hadriel _______________________________________________ sipcore >> mailing list sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore From ietf.hanserik@gmail.com Sun Jul 12 14:01:15 2009 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 9C4693A6807 for ; Sun, 12 Jul 2009 14:01:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.971 X-Spam-Level: X-Spam-Status: No, score=-1.971 tagged_above=-999 required=5 tests=[AWL=0.028, BAYES_00=-2.599, J_CHICKENPOX_33=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 vggVSVsWm1UA for ; Sun, 12 Jul 2009 14:01:14 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 5B3763A6C58 for ; Sun, 12 Jul 2009 14:01:14 -0700 (PDT) Received: by ewy26 with SMTP id 26so2174580ewy.37 for ; Sun, 12 Jul 2009 14:01:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:cc:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=U6hNEmyejYagXa8hk72iQlnz0aE9nOnxPDKGiEXxrvw=; b=WiPtBm8eDisrIOVkUyH3dtA79x4SZCvXVV7ivMKMZhw/ZMwiH8+uwRjCEcJrxtMnkG nE9jvbLu32bkoKpEI7SSEsB4fyE3TvoJYNEh+buc5IWFmc9enwnjTvSSr4o4B7sMyW1D u4WHWaXA07oAq55HrwkbRJfvjRti7wIjIPnZo= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; b=Mv69cXV68INDlPLu972hSKlKo/3xwDs+EiAoYQ1HaEzuqFd70aNNwBTWVIwG+H/flR XOsHY9xizul8oc9m/3NOC6K4495pN4f5XIrwatXFQg5+RrHWwGT2x3iLbO66YUf140EL tswQN7xzU0BjTg+qRy7X6o/gDkw7Us5+r7zf0= Received: by 10.210.70.14 with SMTP id s14mr1061319eba.0.1247432501128; Sun, 12 Jul 2009 14:01:41 -0700 (PDT) Received: from ?192.168.2.100? (212-182-129-30.ip.telfort.nl [212.182.129.30]) by mx.google.com with ESMTPS id 28sm4543908eye.36.2009.07.12.14.01.39 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 12 Jul 2009 14:01:40 -0700 (PDT) Message-ID: <4A5A4F33.8020705@gmail.com> Date: Sun, 12 Jul 2009 23:01:39 +0200 From: Hans Erik van Elburg User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: "James M. Polk" References: <4A59B693.9010807@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 12 Jul 2009 21:01:15 -0000 Nope, a GRUU is an AOR like any other, allthough with special property that it is targeted at a specific UA instance or restricted set of UA instances. That you can use it as a contact in INVITEs and responses is not of the essence. See 5.4, 6.1 of the GRUU draft http://[tools.ietf.org/html/draft-ietf-sip-gruu-15]. /Hans Erik James M. Polk wrote: > At 05:10 AM 7/12/2009, Hans Erik van Elburg wrote: >> Well.. definition of AOR per RFC3261: >> >> "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI >> that points to a domain with a location service that can map >> the URI to another URI where the user might be available. >> Typically, the location service is populated through >> registrations. An AOR is frequently thought of as the "public >> address" of the user." >> >> The approach taken is that if a proxy determines that a Request-URI >> on an incoming request is for a domain that it is responsible for, it >> performs an abstract-location-server lookup for the URI then this >> must be an AOR and the proxy tags the H-I entry representimg this uri >> as being an AOR. >> >> To me this seems totally deterministic. >> >> BTW a GRUU in this sense is also an AOR. > > err, how isn't a GRUU an ultimate Contact address? > > AORs do not have hostnames in them, and Contact addresses (typically) > do. The point of a GRUU is *this* instance of a UA that is universally > routable. That, to me, is a Contact address that has 1 destination UA > in mind. > > This might be splitting hairs though, and I await the masters to > comment (JDR, HS, RS, or Fluffy... :-) > > >> /Hans Erik >> >> Hadriel Kaplan wrote: >>> >>> > -----Original Message----- From: James M. Polk >>> > [mailto:jmpolk@cisco.com] Sent: Sunday, July 12, 2009 3:01 AM >>> > >>> > isn't an AOR a SIP:URI that doesn't have a contact host on the >>> > domain side of the URI? >>> > >>> > For example, >>> > >>> > alice@example.com is an AOR but alice@pc33.example.com is not an >>> > AOR *because* of the host part (pc33) to the right of the @ >>> >>> *You* know pc33 is a hostname. As far as I know, pc33.example.com is >>> a SIP domain. For example "sip:jmpolk@cisco.com" is an AoR, but so >>> could "sip:jmpolk@us.cisco.com" be. (and furthermore there's nothing >>> to prevent a host from running its own SIP domain, afaik) >>> >>> Obviously pc33.example.com itself could know, and that was the point >>> of the "aor" param being added by the targeted domain presumably, but >>> my issue is more of a how does even it know? (and secondly, why does >>> it matter if it's an "AoR"?) >>> >>> For example, if pc33 was a CCM and has an internal static route for >>> "alice@pc33.example.com" to be routed to a SIP Trunk, was alice an >>> AoR? >>> >>> What if "alice@pc33.example.com" is actually a test-loopback URI on >>> the CCM itself, or is a specific voicemail box on the CCM (ie, the >>> URI was the contact address)? >>> >>> >>> >> I'm not trying to be flippant (well, ok I am) >>> > BTW - you're always flippant, so you don't need to qualify yourself >>> > ;-) >>> >>> Just in case people forget. :) >>> >>> -hadriel _______________________________________________ sipcore >>> mailing list sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@cisco.com Sun Jul 12 18:18:26 2009 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 61A373A69D9 for ; Sun, 12 Jul 2009 18:18:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.209 X-Spam-Level: X-Spam-Status: No, score=-6.209 tagged_above=-999 required=5 tests=[AWL=-0.210, BAYES_00=-2.599, J_CHICKENPOX_33=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 vWAR0MB+dkTj for ; Sun, 12 Jul 2009 18:18:25 -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 1106A3A6A09 for ; Sun, 12 Jul 2009 18:18:24 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGMoWkpAZnme/2dsb2JhbACzKIgjjhcFhAk X-IronPort-AV: E=Sophos;i="4.42,387,1243814400"; d="scan'208";a="50125308" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 13 Jul 2009 01:18:54 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6D1IsMZ022065; Sun, 12 Jul 2009 21:18:54 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6D1IsJQ009625; Mon, 13 Jul 2009 01:18:54 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 21:18:54 -0400 Received: from [10.86.252.152] ([10.86.252.152]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 21:18:54 -0400 Message-ID: <4A5A8B7D.9060804@cisco.com> Date: Sun, 12 Jul 2009 21:18:53 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Hans Erik van Elburg References: <4A59B693.9010807@gmail.com> In-Reply-To: <4A59B693.9010807@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2009 01:18:54.0083 (UTC) FILETIME=[E31CBD30:01CA0357] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3377; t=1247447934; x=1248311934; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20rfc4244bis=3A=20what=20is=2 0an=20AoR? |Sender:=20 |To:=20Hans=20Erik=20van=20Elburg=20; bh=QAmaOlC8eaK1ApWouRlpQps9FX4HZ5ZSogk0CVO2Sqw=; b=VTjxawVh1go8lcxicCnx9IyOALWZxmgUoL0JBuYQy/VDgwcIOXt7V3R1on urNuU0XZtgCeLWEOhcGKCc3ak+WvPMyr0Tia2cj97w4TZ7ZP5ArwztkafwwF dw5UvDDhZl; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 13 Jul 2009 01:18:26 -0000 I largely agree with Hans. For all intents and purposes, a URI is an AoR if the policy of the domain of that URI says it is an AoR. And note that being an AoR and being a Contact are not mutually exclusive. An AoR can be both. Distinguishing based on the value of the host portion of the URI is not a reliable technique in general, though there might be heuristics that work for a lot of domains. For instance, for some domain x it may be that sip:foo@x is an AoR if it is defined at all, and sip:foo@anything.x is never an AoR. And AFAIK even if the URI contains an ip address rather than a domain name it could still be an AoR. Thanks, Paul Hans Erik van Elburg wrote: > Well.. definition of AOR per RFC3261: > > "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI > that points to a domain with a location service that can map > the URI to another URI where the user might be available. > Typically, the location service is populated through > registrations. An AOR is frequently thought of as the "public > address" of the user." > > The approach taken is that if a proxy determines that a Request-URI on > an incoming request is for a domain that it is responsible for, it > performs an abstract-location-server lookup for the URI then this must > be an AOR and the proxy tags the H-I entry representimg this uri as > being an AOR. > > To me this seems totally deterministic. > > BTW a GRUU in this sense is also an AOR. > > /Hans Erik > > Hadriel Kaplan wrote: >> >> > -----Original Message----- From: James M. Polk >> > [mailto:jmpolk@cisco.com] Sent: Sunday, July 12, 2009 3:01 AM >> > >> > isn't an AOR a SIP:URI that doesn't have a contact host on the >> > domain side of the URI? >> > >> > For example, >> > >> > alice@example.com is an AOR but alice@pc33.example.com is not an >> > AOR *because* of the host part (pc33) to the right of the @ >> >> *You* know pc33 is a hostname. As far as I know, pc33.example.com is >> a SIP domain. For example "sip:jmpolk@cisco.com" is an AoR, but so >> could "sip:jmpolk@us.cisco.com" be. (and furthermore there's nothing >> to prevent a host from running its own SIP domain, afaik) >> >> Obviously pc33.example.com itself could know, and that was the point >> of the "aor" param being added by the targeted domain presumably, but >> my issue is more of a how does even it know? (and secondly, why does >> it matter if it's an "AoR"?) >> >> For example, if pc33 was a CCM and has an internal static route for >> "alice@pc33.example.com" to be routed to a SIP Trunk, was alice an >> AoR? >> >> What if "alice@pc33.example.com" is actually a test-loopback URI on >> the CCM itself, or is a specific voicemail box on the CCM (ie, the >> URI was the contact address)? >> >> >> >> I'm not trying to be flippant (well, ok I am) >> > BTW - you're always flippant, so you don't need to qualify yourself >> > ;-) >> >> Just in case people forget. :) >> >> -hadriel _______________________________________________ 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 Jul 12 18:24:22 2009 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 B0B213A6A37 for ; Sun, 12 Jul 2009 18:24:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.479 X-Spam-Level: X-Spam-Status: No, score=-6.479 tagged_above=-999 required=5 tests=[AWL=0.120, 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 8i6i9ag+ROXV for ; Sun, 12 Jul 2009 18:24: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 C0DE73A69D9 for ; Sun, 12 Jul 2009 18:24:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAI4pWkpAZnmf/2dsb2JhbACzKYgjjhoFhAmBQg X-IronPort-AV: E=Sophos;i="4.42,387,1243814400"; d="scan'208";a="50125527" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Jul 2009 01:24:50 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6D1OoKU017693; Sun, 12 Jul 2009 21:24:50 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6D1Ootr011298; Mon, 13 Jul 2009 01:24:50 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 21:24:50 -0400 Received: from [10.86.252.152] ([10.86.252.152]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 21:24:49 -0400 Message-ID: <4A5A8CDD.2090605@cisco.com> Date: Sun, 12 Jul 2009 21:24:45 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Hans Erik van Elburg References: <1246996560.5962.37.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EDE5C07@zrc2hxm0.corp.nortel.com> <1247077928.3712.26.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EE8A67C@zrc2hxm0.corp.nortel.com> <1247257464.3757.67.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EEDE853@zrc2hxm0.corp.nortel.com> <4A59B2EC.8000609@gmail.com> In-Reply-To: <4A59B2EC.8000609@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2009 01:24:49.0609 (UTC) FILETIME=[B705B390:01CA0358] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8565; t=1247448290; x=1248312290; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20draft-barnes-sipcore-rfc424 4bis=20-=20privacy=20syntax |Sender:=20 |To:=20Hans=20Erik=20van=20Elburg=20; bh=xL0p8dOfcIELTAQ3mQ6iv0t9xsZbZF9K044C4MBRkXE=; b=BFuwhqb9S5zc9SoJ/mumgc8A41GTSuQB9puUojtYNHDCV5bF24U83oFWL0 yDAQlHjO5ZJ/vLMcguZC0KB+sU3AWDFXZ6GH2HOf+AhLGqHaMUPvq/ITyswe 3hwEmUuQ5y; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIPCORE , Dale Worley , Hadriel Kaplan Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax 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, 13 Jul 2009 01:24:22 -0000 I also agree with the points Hadriel raised. The one about the TEL URI is a major one. (And no, there are no header parameters in TEL URIs.) The backward compatibility issue is a real one, but seems like one that needs to be addressed. Thanks, Paul Hans Erik van Elburg wrote: > Yes, I agreed with most points you raised below. Question is if this can > be fixed in a backward compatible way, seems hard unfortunately > > /Hans Erik > > Hadriel Kaplan wrote: >> Ignore that email - just realized it was done that way in the original >> RFC4424, so we're stuck with it for posterity's sake. Blech. >> >> -hadriel >> >> >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>> Behalf >>> Of Hadriel Kaplan >>> Sent: Saturday, July 11, 2009 4:17 PM >>> To: Mary Barnes; Dale Worley; Francois Audet >>> Cc: SIPCORE >>> Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax >>> >>> >>> Howdy, >>> I have some warning bell ringing in my head against this idea of >>> changing >>> the Request-URI encoded in the HI header (the hi-targeted-to-uri) to >>> include an embedded Reason or Privacy header. I think the bell is >>> due to >>> the following concerns: >>> >>> 1) Afaict, the Reason value is not an attribute/property of the URI - it >>> is the History-Info mechanism's specific rerouting cause, i.e. it's a >>> property of what caused the HI header field to be created, so it's a >>> property of the header field. The Privacy header is a little less >>> clear, >>> but again ISTM that it's a command for the HI mechanism itself, and thus >>> an attribute of the HI header field. For example, one of the potential >>> actions to be taken by a Proxy is to remove the HI entry entirely - not >>> just the URI. >>> >>> 2) If it weren't for this added escaped URI header, the >>> hi-targeted-to-uri >>> would be a literal copy of the original request-URI. (right?) That >>> would >>> provide a clean way of doing troubleshooting and target >>> determination/matching, without exception checking for special things >>> added by this RFC into the URI for its own purposes. >>> >>> 3) If we ever decide to create some way of securing the original URI in >>> HI's, for example by signing it, it adds confusion or even breaks the >>> signature if the original URI is not actually left alone. >>> >>> 4) While it may seem that embedded headers could not have appeared in >>> the >>> received Request-URI to being with, in practice I have seen embedded >>> headers in received SIP Request-URI's. In particular, in INVITE's >>> created >>> from REFER's, and in ENUM-routing cases. In such cases there could >>> theoretically be ambiguity whether the embedded header came from the HI >>> mechanism vs. the actual request-URI. >>> >>> 5) The hi-targeted-to-uri can be a tel-uri (right?); can tel-URI's have >>> embedded headers? (it's not a SIP-URI) >>> >>> -hadriel >>> >>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>>> >>> Behalf >>> >>>> Of Mary Barnes >>>> Sent: Friday, July 10, 2009 4:44 PM >>>> To: Dale Worley; Francois Audet >>>> Cc: SIPCORE >>>> Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax >>>> >>>> A couple points below [MB]. >>>> >>>> Mary. >>>> >>>> -----Original Message----- >>>> From: Worley, Dale (BL60:9D30) >>>> Sent: Friday, July 10, 2009 3:24 PM >>>> To: Audet, Francois (SC100:3055) >>>> Cc: Barnes, Mary (RICH2:AR00); SIPCORE >>>> Subject: RE: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax >>>> >>>> On Thu, 2009-07-09 at 14:07 -0400, Audet, Francois (SC100:3055) wrote: >>>> >>>>> It's basically saying that the Privacy and Reason "escaped parameters" >>>>> would translate into headers if we were to created a >>>>> request based on >>>>> >>>> it. >>>> >>>> I can't see any circumstances where we would want to create a request >>>> that included the Privacy or Reason headers from a H-I entry. >>>> >>>> In regard to Privacy, if its value is "history", that means that the >>>> particular H-I URI should be restricted. But that is not the >>>> meaning of >>>> adding the "Privacy: history" header to a request -- in the latter >>>> case, >>>> History-Info should not be generated at all. (Which is what I mean >>>> when >>>> I say "the values of Privacy in History-Info do not have the same >>>> semantics as the values of the Privacy header".) >>>> >>>> In regard to Reason, as far as I can tell, it is attached to an H-I >>>> entry to show the response that was received to the request that was >>>> sent to that URI. Generating a request based on that H-I entry would >>>> create a request to that same URI, containing a Reason header in the >>>> request that *predicts* the response that the request will receive. >>>> >>>> Given that in no case would we want to generate and use (with the >>>> implicit headers) a request based on the H-I entry's >>>> URI-with-headers, I >>>> don't see why these data items are stored in headers attached to the >>>> URI. >>>> [MB] We discussed this in another thread and the motivation was the >>>> reuse of existing headers rather than defining parameters that had the >>>> same semantics and values. That was discussed at IETF-55 in Atlanta in >>>> the SIPPING WG meeting in November 2002: >>>> http://www.ietf.org/proceedings/02nov/slides/sipping-2/sld5.htm >>>> >>>> And, this makes sense in particular for Reason and perhaps lesser so >>>> for >>>> Privacy. And, as you say we would never use the Request URIs in these >>>> hi-entrys to generate a request so this does not cause any problems. >>>> The intent is not to add parameters to the Request URI for any reasons >>>> other than to take advantage of the "clever" escaping mechanism >>>> provided >>>> by HTTP and to avoid defining parameters with the same values as the >>>> headers, both of which are not bad ideas. And, the normative text is >>>> quite clear that this is the intent. [/MB] >>>> >>>> On Wed, 2009-07-08 at 19:25 -0400, Barnes, Mary (RICH2:AR00) wrote: >>>> >>>>> As far as privacy, I'm not sure what you mean with regards to " This >>>>> privacy value is an annotation of the URI, whereas the current syntax >>>>> incorporates it *into* the URI." The privacy value isn't incorporated >>>>> into the URI - it's an escaped parameter. >>>>> >>>> It's an escaped parameter, but it *is* part of the URI -- see the >>>> production "SIP-URI" in section 25.1 of RFC 3261. And if you ask the >>>> grammar, "What is the URI part of an H-I entry?" you will get back the >>>> 'headers' as part of the URI. >>>> [MB] See my comment above. Since we have specified clearly in the HI >>>> ABNF and in the normative text, this URI needs to be appropriately >>>> handled to derive the parameters. And, it is not abnormal to remove the >>>> headers that are escaped in the URIs - basic HTTP. >>>> >>>> Similarly, any device or syntax which admits a SIP URI will allow >>>> you to >>>> enter a string containing 'headers'. Indeed, there is only one >>>> situation where a SIP URI is possible but that URI cannot contain >>>> 'headers', and that is as the request-URI of a request. That isn't >>>> specified in the syntax (which allows SIP-URI), but is a consequence of >>>> the processing in section 19.1.5, which removes the 'headers' from the >>>> supplied SIP URI and turns them into message headers. >>>> [MB] Exactly and that's why it's not a problem. Since we are >>>> capturing a >>>> Request URI, there is no conflict between the headers that we escape >>>> since no other headers can be escaped in the Request URI. >>>> [/MB] >>>> >>>> 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 >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From HKaplan@acmepacket.com Sun Jul 12 19:03:38 2009 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 972AC3A68BD for ; Sun, 12 Jul 2009 19:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.555 X-Spam-Level: X-Spam-Status: No, score=-2.555 tagged_above=-999 required=5 tests=[AWL=0.044, 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 57jQEGs4h58n for ; Sun, 12 Jul 2009 19:03:36 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A6EA13A6870 for ; Sun, 12 Jul 2009 19:03:35 -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.1.375.2; Sun, 12 Jul 2009 22:04:04 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 12 Jul 2009 22:04:04 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg Date: Sun, 12 Jul 2009 22:04:03 -0400 Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoC2Qnd4dNUCUvLRh2JQGrETeGzGAAHyVKQ Message-ID: References: <4A59B693.9010807@gmail.com> In-Reply-To: <4A59B693.9010807@gmail.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 Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 13 Jul 2009 02:03:38 -0000 > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Sunday, July 12, 2009 6:10 AM >=20 > Well.. definition of AOR per RFC3261: >=20 > "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI > that points to a domain with a location service that can map > the URI to another URI where the user might be available. > Typically, the location service is populated through > registrations. An AOR is frequently thought of as the "public > address" of the user." >=20 > The approach taken is that if a proxy determines that a Request-URI on > an incoming request is for a domain that it is responsible for, it > performs an abstract-location-server lookup for the URI then this must > be an AOR and the proxy tags the H-I entry representimg this uri as > being an AOR. > > To me this seems totally deterministic. Afaik, there is no current conceptual field recorded in the abstract locati= on-service by 3261 that defines an entry as an "AoR" vs. just a default rou= te to the PSTN, for example. For example, when a proxy that is authoritative for example.com receives a = request for "sip:2345678901@example.com" form one of its users, it has the = ability to lookup that username in its LS, not find it, change it to "sip:+= 12345678901@example.com" based on local policies, look it up again, and fin= d a match for that. So was the original "sip:2345678901@example.com" an Ao= R? Presumably yes. What if the matching entry's next-hop was from a stati= c route vs. a registered contact? Also presumably yes. What if the matchi= ng entry's next-hop is actually just a default route to a local PSTN gatewa= y? Presumably no it's not an AoR, but how does the Proxy distinguish this = case from the previous two? -hadriel From HKaplan@acmepacket.com Sun Jul 12 19:10:31 2009 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 95FAD3A68AA for ; Sun, 12 Jul 2009 19:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.557 X-Spam-Level: X-Spam-Status: No, score=-2.557 tagged_above=-999 required=5 tests=[AWL=0.042, 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 c7pusxRd1Nwk for ; Sun, 12 Jul 2009 19:10:30 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A97943A683F for ; Sun, 12 Jul 2009 19:10:30 -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.1.375.2; Sun, 12 Jul 2009 22:11:00 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 12 Jul 2009 22:11:00 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg , "James M. Polk" Date: Sun, 12 Jul 2009 22:10:55 -0400 Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoDM/ygnKlj7Hk3RC+UY5H/p15KNAAKje5Q Message-ID: References: <4A59B693.9010807@gmail.com> <4A5A4F33.8020705@gmail.com> In-Reply-To: <4A5A4F33.8020705@gmail.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 Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 13 Jul 2009 02:10:31 -0000 > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Sunday, July 12, 2009 5:02 PM >=20 > Nope, a GRUU is an AOR like any other, allthough with special property > that it is targeted at a specific UA instance or restricted set of UA > instances. That you can use it as a contact in INVITEs and responses is > not of the essence. >=20 > See 5.4, 6.1 of the GRUU draft > http://[tools.ietf.org/html/draft-ietf-sip-gruu-15]. Every time I read that it tells me a GRUU is not an AoR. It has a relation= ship with one, but it isn't one itself. At least in the language the draft= uses. For example: ...Every GRUU is associated with a single AOR and a single instance ID. A registrar MUST be able to determine the instance ID and AOR when presented with a GRUU. In addition, the GRUU, like an AOR, resolves to zero or more contacts. While the AOR resolves to all registered contacts for an AOR, a GRUU resolves only to those contacts whose instance ID matches the one associated with the GRUU. For this reason, a contact with an instance ID is always bound to both a GRUU and its AOR, never just an AOR or just a GRUU. But I'm probably being real nitpicky pedantic. I'm not even sure it really= matters, because I have no idea why we care if a HI entry's URI is an "AoR= " or not. (but that's a topic for another thread :) -hadriel From HKaplan@acmepacket.com Sun Jul 12 19:12:18 2009 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 3399B3A68AA for ; Sun, 12 Jul 2009 19:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 7zLu-e08blfa for ; Sun, 12 Jul 2009 19:12:17 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 6F16F3A683F for ; Sun, 12 Jul 2009 19:12:17 -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.1.375.2; Sun, 12 Jul 2009 22:12:46 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 12 Jul 2009 22:12:46 -0400 From: Hadriel Kaplan To: Paul Kyzivat , Hans Erik van Elburg Date: Sun, 12 Jul 2009 22:12:40 -0400 Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoDV+piBYxWhIWBTqmMTijJD4yWHAAB0oJg Message-ID: References: <4A59B693.9010807@gmail.com> <4A5A8B7D.9060804@cisco.com> In-Reply-To: <4A5A8B7D.9060804@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 Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 13 Jul 2009 02:12:18 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Sunday, July 12, 2009 9:19 PM >=20 > I largely agree with Hans. > For all intents and purposes, a URI is an AoR if the policy of the > domain of that URI says it is an AoR. Yes, it's like porn vs. art: you know it when you see it. ;) > And AFAIK even if the URI contains an ip address rather than a domain > name it could still be an AoR. Yup. -hadriel From pkyzivat@cisco.com Sun Jul 12 19:50:08 2009 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 1D3813A6983 for ; Sun, 12 Jul 2009 19:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.494 X-Spam-Level: X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, 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 zN9bH0+aonfS for ; Sun, 12 Jul 2009 19:50:06 -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 B61AD3A67FF for ; Sun, 12 Jul 2009 19:50:06 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPI9WkpAZnme/2dsb2JhbACzM4gjjhQFhAk X-IronPort-AV: E=Sophos;i="4.42,388,1243814400"; d="scan'208";a="50178767" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 13 Jul 2009 02:50:36 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6D2oaUk019477; Sun, 12 Jul 2009 22:50:36 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6D2oap7012770; Mon, 13 Jul 2009 02:50:36 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 22:50:36 -0400 Received: from [10.86.252.152] ([10.86.252.152]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 22:50:35 -0400 Message-ID: <4A5AA0FA.8080100@cisco.com> Date: Sun, 12 Jul 2009 22:50:34 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Hadriel Kaplan References: <4A59B693.9010807@gmail.com> <4A5A4F33.8020705@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2009 02:50:35.0653 (UTC) FILETIME=[B24DB350:01CA0364] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2067; t=1247453436; x=1248317436; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20rfc4244bis=3A=20what=20is=2 0an=20AoR? |Sender:=20 |To:=20Hadriel=20Kaplan=20; bh=Iu9JQZ1OtqCShTRzaNhanf8Lbf6rfure5NpgPCzBO2A=; b=cHDp1NE07Qe8p2xO/pFca813lElBo1CdYv+56Us/oSvpEusLuzBX2n9Q8A xft9bw/0BP0qaiYgueZE1vndD1kTrjCzT+yXhVYuHxZfO/zfkRCB6wKJ2MLt K7fQcU+YYj; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 13 Jul 2009 02:50:08 -0000 Hadriel Kaplan wrote: > >> -----Original Message----- >> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >> Sent: Sunday, July 12, 2009 5:02 PM >> >> Nope, a GRUU is an AOR like any other, allthough with special property >> that it is targeted at a specific UA instance or restricted set of UA >> instances. That you can use it as a contact in INVITEs and responses is >> not of the essence. >> >> See 5.4, 6.1 of the GRUU draft >> http://[tools.ietf.org/html/draft-ietf-sip-gruu-15]. > > Every time I read that it tells me a GRUU is not an AoR. It has a relationship with one, but it isn't one itself. At least in the language the draft uses. For example: > > ...Every GRUU is associated with a single AOR > and a single instance ID. A registrar MUST be able to determine the > instance ID and AOR when presented with a GRUU. In addition, the > GRUU, like an AOR, resolves to zero or more contacts. While the AOR > resolves to all registered contacts for an AOR, a GRUU resolves only > to those contacts whose instance ID matches the one associated with > the GRUU. For this reason, a contact with an instance ID is always > bound to both a GRUU and its AOR, never just an AOR or just a GRUU. > > But I'm probably being real nitpicky pedantic. I'm not even sure it really matters, because I have no idea why we care if a HI entry's URI is an "AoR" or not. (but that's a topic for another thread :) As another in the cult of nitpicky pedentic people... A gruu does have a lot in common with an AoR. It shares a domain with AoRs, and it is translated using the same location service as an AoR, with much the same algorithms. But in other respects it is not an AoR. But obviously it doesn't meet all our expectations about what an AoR should be. I'm not sure we can provide a yes/no answer to this question. Thanks, Paul _________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From AUDET@nortel.com Sun Jul 12 19:59:14 2009 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 B35153A6827 for ; Sun, 12 Jul 2009 19:59:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.47 X-Spam-Level: X-Spam-Status: No, score=-4.47 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 ACBhCWXmcYIy for ; Sun, 12 Jul 2009 19:59:13 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 509A83A6842 for ; Sun, 12 Jul 2009 19:58:47 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6D2xEe04021; Mon, 13 Jul 2009 02:59:14 GMT Received: from 47.102.153.31 ([47.102.153.31]) by zrc2hxm0.corp.nortel.com ([47.103.123.71]) with Microsoft Exchange Server HTTP-DAV ; Mon, 13 Jul 2009 02:59:13 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Sun, 12 Jul 2009 19:59:11 -0700 From: "Francois Audet" To: Hadriel Kaplan , "Mary Barnes" , "Dale Worley" Message-ID: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax Thread-Index: AcoBnGvHKCIaPFDpQf+/3xhnWI6IYwAAJ2rwAC99fZAABD00QAA+fFFA In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax 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, 13 Jul 2009 02:59:14 -0000 Yeah, exactly. My thoughts too. On Jul11 2009 14:11 , "Hadriel Kaplan" wrote: > > Ignore that email - just realized it was done that way in the original > RFC4424, so we're stuck with it for posterity's sake. Blech. > > -hadriel > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf >> Of Hadriel Kaplan >> Sent: Saturday, July 11, 2009 4:17 PM >> To: Mary Barnes; Dale Worley; Francois Audet >> Cc: SIPCORE >> Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax >> >> >> Howdy, >> I have some warning bell ringing in my head against this idea of changing >> the Request-URI encoded in the HI header (the hi-targeted-to-uri) to >> include an embedded Reason or Privacy header. I think the bell is due to >> the following concerns: >> >> 1) Afaict, the Reason value is not an attribute/property of the URI - it >> is the History-Info mechanism's specific rerouting cause, i.e. it's a >> property of what caused the HI header field to be created, so it's a >> property of the header field. The Privacy header is a little less clear, >> but again ISTM that it's a command for the HI mechanism itself, and thus >> an attribute of the HI header field. For example, one of the potential >> actions to be taken by a Proxy is to remove the HI entry entirely - not >> just the URI. >> >> 2) If it weren't for this added escaped URI header, the hi-targeted-to-uri >> would be a literal copy of the original request-URI. (right?) That would >> provide a clean way of doing troubleshooting and target >> determination/matching, without exception checking for special things >> added by this RFC into the URI for its own purposes. >> >> 3) If we ever decide to create some way of securing the original URI in >> HI's, for example by signing it, it adds confusion or even breaks the >> signature if the original URI is not actually left alone. >> >> 4) While it may seem that embedded headers could not have appeared in the >> received Request-URI to being with, in practice I have seen embedded >> headers in received SIP Request-URI's. In particular, in INVITE's created >> from REFER's, and in ENUM-routing cases. In such cases there could >> theoretically be ambiguity whether the embedded header came from the HI >> mechanism vs. the actual request-URI. >> >> 5) The hi-targeted-to-uri can be a tel-uri (right?); can tel-URI's have >> embedded headers? (it's not a SIP-URI) >> >> -hadriel >> >>> -----Original Message----- >>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf >>> Of Mary Barnes >>> Sent: Friday, July 10, 2009 4:44 PM >>> To: Dale Worley; Francois Audet >>> Cc: SIPCORE >>> Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax >>> >>> A couple points below [MB]. >>> >>> Mary. >>> >>> -----Original Message----- >>> From: Worley, Dale (BL60:9D30) >>> Sent: Friday, July 10, 2009 3:24 PM >>> To: Audet, Francois (SC100:3055) >>> Cc: Barnes, Mary (RICH2:AR00); SIPCORE >>> Subject: RE: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax >>> >>> On Thu, 2009-07-09 at 14:07 -0400, Audet, Francois (SC100:3055) wrote: >>>> It's basically saying that the Privacy and Reason "escaped parameters" >>> >>>> would translate into headers if we were to created a request based on >>> it. >>> >>> I can't see any circumstances where we would want to create a request >>> that included the Privacy or Reason headers from a H-I entry. >>> >>> In regard to Privacy, if its value is "history", that means that the >>> particular H-I URI should be restricted. But that is not the meaning of >>> adding the "Privacy: history" header to a request -- in the latter case, >>> History-Info should not be generated at all. (Which is what I mean when >>> I say "the values of Privacy in History-Info do not have the same >>> semantics as the values of the Privacy header".) >>> >>> In regard to Reason, as far as I can tell, it is attached to an H-I >>> entry to show the response that was received to the request that was >>> sent to that URI. Generating a request based on that H-I entry would >>> create a request to that same URI, containing a Reason header in the >>> request that *predicts* the response that the request will receive. >>> >>> Given that in no case would we want to generate and use (with the >>> implicit headers) a request based on the H-I entry's URI-with-headers, I >>> don't see why these data items are stored in headers attached to the >>> URI. >>> [MB] We discussed this in another thread and the motivation was the >>> reuse of existing headers rather than defining parameters that had the >>> same semantics and values. That was discussed at IETF-55 in Atlanta in >>> the SIPPING WG meeting in November 2002: >>> http://www.ietf.org/proceedings/02nov/slides/sipping-2/sld5.htm >>> >>> And, this makes sense in particular for Reason and perhaps lesser so for >>> Privacy. And, as you say we would never use the Request URIs in these >>> hi-entrys to generate a request so this does not cause any problems. >>> The intent is not to add parameters to the Request URI for any reasons >>> other than to take advantage of the "clever" escaping mechanism provided >>> by HTTP and to avoid defining parameters with the same values as the >>> headers, both of which are not bad ideas. And, the normative text is >>> quite clear that this is the intent. [/MB] >>> >>> On Wed, 2009-07-08 at 19:25 -0400, Barnes, Mary (RICH2:AR00) wrote: >>>> As far as privacy, I'm not sure what you mean with regards to " This >>>> privacy value is an annotation of the URI, whereas the current syntax >>>> incorporates it *into* the URI." The privacy value isn't incorporated >>> >>>> into the URI - it's an escaped parameter. >>> >>> It's an escaped parameter, but it *is* part of the URI -- see the >>> production "SIP-URI" in section 25.1 of RFC 3261. And if you ask the >>> grammar, "What is the URI part of an H-I entry?" you will get back the >>> 'headers' as part of the URI. >>> [MB] See my comment above. Since we have specified clearly in the HI >>> ABNF and in the normative text, this URI needs to be appropriately >>> handled to derive the parameters. And, it is not abnormal to remove the >>> headers that are escaped in the URIs - basic HTTP. >>> >>> Similarly, any device or syntax which admits a SIP URI will allow you to >>> enter a string containing 'headers'. Indeed, there is only one >>> situation where a SIP URI is possible but that URI cannot contain >>> 'headers', and that is as the request-URI of a request. That isn't >>> specified in the syntax (which allows SIP-URI), but is a consequence of >>> the processing in section 19.1.5, which removes the 'headers' from the >>> supplied SIP URI and turns them into message headers. >>> [MB] Exactly and that's why it's not a problem. Since we are capturing a >>> Request URI, there is no conflict between the headers that we escape >>> since no other headers can be escaped in the Request URI. >>> [/MB] >>> >>> 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 AUDET@nortel.com Sun Jul 12 20:10:40 2009 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 16D753A6CA3 for ; Sun, 12 Jul 2009 20:10:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.482 X-Spam-Level: X-Spam-Status: No, score=-4.482 tagged_above=-999 required=5 tests=[AWL=0.050, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 TyZL2yc7-IwW for ; Sun, 12 Jul 2009 20:10:39 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id E5C853A6CA9 for ; Sun, 12 Jul 2009 20:10:38 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6D39OB11334; Mon, 13 Jul 2009 03:09:25 GMT Received: from 47.102.153.31 ([47.102.153.31]) by zrc2hxm0.corp.nortel.com ([47.103.123.71]) with Microsoft Exchange Server HTTP-DAV ; Mon, 13 Jul 2009 03:11:03 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Sun, 12 Jul 2009 20:11:01 -0700 From: "Francois Audet" To: Hadriel Kaplan , SIPCORE Message-ID: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoCrazV4PjGDXJYQVyso2A4fcXevgAud/W9 In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 13 Jul 2009 03:10:40 -0000 On Jul11 2009 22:00 , "Hadriel Kaplan" wrote: > Howdy, > This may be from left-field, or already discussed previously - if so please > excuse my ignorance. > > I see the term "AoR" as being somehow treated as an unambiguous term, knowable > to a Proxy of the AoR's domain as being an "AoR" on sight. It is then used in > the draft to identify a specific HI URI as the original-target URI - the > identifier to look for when trying to find the "original" request-URI. Right? > > So if the Proxy of the AoR's domain is supposed to indicate a SIP-URI is an > AoR, how does it know it? What is the distinguishing parameter or URI syntax > of an AoR, which makes it different from any-old sip:user@domain SIP-URI? > > For example, is "sip:rai-ad@ietf.org" an AoR? Is Yes. > "sip:+18005551212@sp.com;user=phone" an AoR? Is Yes > "sip:asd887f9dfkk76690@example.com;gr" an AoR? Probably not. They are long-term addresses. We are using the RFC 3261 definition: Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the "public address" of the user. > I'm not trying to be flippant (well, ok I am) but there is no such > distinguishing characteristic, afaik. It is an abstract concept, and it is > just a specific subset of SIP/SIPS-URIs we use to describe something; but it > means nothing in particular to a Proxy really, does it? For example AoR's are > not all/only SIP-URI's that are Registered through a SIP REGISTER transaction; > they can be statically routed/resolved, or added to a location service via a > web page, etc. In some of our specs we consider an AoR to be the human > identity, whereas a contact address is a machine, but really there's nothing > that makes it be a human identity - it could be a group identity, a conf room > phone, a voicemail box, an alias for anther AoR, etc. Yes, exactly; they are all that. Key points are: a proxy doesn't mark as AOR an address in a foreign domain. Neither does it mark temporary URIs that are not expected to generically route to a user. In other words, for the purpose of this draft, if a proxy sees something it doesn't "own", it doesn't mark it as AOR. If it is an address in its own domain (e.g., a phone number, an email-looking address, etc.), then it does. > In fact I'm not even sure it's all of the things we need it to be: for example > a temp GRUU is not usually considered an AoR, afaik. Yet identifying the > original GRUU from the original request-URI was one of the motivating factors > for Jonathan's ua-loose-routing draft which got us here, no? In fact, we > didn't care if it was an "AoR" whatsoever - if the original UAC used a > request-URI containing the Contact-URI of a UAS, we wanted to know it; if it > used a Tel-URI, we wanted to know that too (and a TEL-URI is not an "AoR", > afaik). Or am I missing something obvious? (could be - my brain's dead) You are kind of rambling in this paragraph, but I *think* I agree with you. A temp GRUU is not an AOR. Let's backtrack a little bit. It's not like you would just ignore the entries not marked with aor flag. If you are expecting a temp GRUU, then the aor flag is not terribly relevant. > -hadriel > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From AUDET@nortel.com Sun Jul 12 20:13:11 2009 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 160943A6C2E for ; Sun, 12 Jul 2009 20:13:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.19 X-Spam-Level: X-Spam-Status: No, score=-4.19 tagged_above=-999 required=5 tests=[AWL=-0.258, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 D8+b6wCr0DPr for ; Sun, 12 Jul 2009 20:13:10 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 078893A6C37 for ; Sun, 12 Jul 2009 20:13:09 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6D3BuB11496; Mon, 13 Jul 2009 03:11:57 GMT Received: from 47.102.153.31 ([47.102.153.31]) by zrc2hxm0.corp.nortel.com ([47.103.123.71]) with Microsoft Exchange Server HTTP-DAV ; Mon, 13 Jul 2009 03:13:33 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Sun, 12 Jul 2009 20:13:32 -0700 From: "Francois Audet" To: "James M. Polk" , Hadriel Kaplan , SIPCORE Message-ID: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoDZ+ar3fcfvN1lQzKRv4K47FV9XQ== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 13 Jul 2009 03:13:11 -0000 It's the address you would put on a business card. On Jul12 2009 24:00 , "James M. Polk" wrote: > At 12:00 AM 7/12/2009, Hadriel Kaplan wrote: >> Howdy, >> This may be from left-field, or already discussed previously - if so >> please excuse my ignorance. >> >> I see the term "AoR" as being somehow treated as an unambiguous >> term, knowable to a Proxy of the AoR's domain as being an "AoR" on >> sight. It is then used in the draft to identify a specific HI URI >> as the original-target URI - the identifier to look for when trying >> to find the "original" request-URI. Right? >> >> So if the Proxy of the AoR's domain is supposed to indicate a >> SIP-URI is an AoR, how does it know it? What is the distinguishing >> parameter or URI syntax of an AoR, which makes it different from >> any-old sip:user@domain SIP-URI? > > isn't an AOR a SIP:URI that doesn't have a contact host on the domain > side of the URI? > > For example, > > alice@example.com is an AOR > but > alice@pc33.example.com is not an AOR *because* > of the host part (pc33) to the right of the @ > > I'm sure this is simplistic > > I'm also curious if someone knows the secret sauce to this, if there > is such an animal... > > >> For example, is "sip:rai-ad@ietf.org" an AoR? > > I think this one is an AOR > >> Is "sip:+18005551212@sp.com;user=phone" an AoR? > > no sure on this one > >> Is "sip:asd887f9dfkk76690@example.com;gr" an AoR? > > seem like this one is too > > >> I'm not trying to be flippant (well, ok I am) > > BTW - you're always flippant, so you don't need to qualify yourself ;-) > >> but there is no such distinguishing characteristic, afaik. It is an >> abstract concept, and it is just a specific subset of SIP/SIPS-URIs >> we use to describe something; but it means nothing in particular to >> a Proxy really, does it? For example AoR's are not all/only >> SIP-URI's that are Registered through a SIP REGISTER transaction; >> they can be statically routed/resolved, or added to a location >> service via a web page, etc. In some of our specs we consider an >> AoR to be the human identity, whereas a contact address is a >> machine, but really there's nothing that makes it be a human >> identity - it could be a group identity, a conf room phone, a >> voicemail box, an alias for anther AoR, etc. >> >> In fact I'm not even sure it's all of the things we need it to be: >> for example a temp GRUU is not usually considered an AoR, >> afaik. Yet identifying the original GRUU from the original >> request-URI was one of the motivating factors for Jonathan's >> ua-loose-routing draft which got us here, no? In fact, we didn't >> care if it was an "AoR" whatsoever - if the original UAC used a >> request-URI containing the Contact-URI of a UAS, we wanted to know >> it; if it used a Tel-URI, we wanted to know that too (and a TEL-URI >> is not an "AoR", afaik). Or am I missing something obvious? (could >> be - my brain's dead) >> >> -hadriel >> _______________________________________________ >> 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 AUDET@nortel.com Sun Jul 12 20:29:51 2009 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 CDFCA3A6870 for ; Sun, 12 Jul 2009 20:29:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.453 X-Spam-Level: X-Spam-Status: No, score=-4.453 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 KxE06j1Q5ggG for ; Sun, 12 Jul 2009 20:29:51 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id C81A03A67FF for ; Sun, 12 Jul 2009 20:29:50 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6D3UHe07037; Mon, 13 Jul 2009 03:30:17 GMT Received: from 47.102.153.31 ([47.102.153.31]) by zrc2hxm0.corp.nortel.com ([47.103.123.71]) with Microsoft Exchange Server HTTP-DAV ; Mon, 13 Jul 2009 03:30:16 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Sun, 12 Jul 2009 20:30:12 -0700 From: "Francois Audet" To: Hadriel Kaplan , Hans Erik van Elburg Message-ID: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoC2Qnd4dNUCUvLRh2JQGrETeGzGAAHyVKQAByC5Jc= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 13 Jul 2009 03:29:51 -0000 Dude, are you arguing there is no such thing as an AOR? What's your point? On Jul12 2009 19:04 , "Hadriel Kaplan" wrote: > > >> -----Original Message----- >> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >> Sent: Sunday, July 12, 2009 6:10 AM >> >> Well.. definition of AOR per RFC3261: >> >> "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI >> that points to a domain with a location service that can map >> the URI to another URI where the user might be available. >> Typically, the location service is populated through >> registrations. An AOR is frequently thought of as the "public >> address" of the user." >> >> The approach taken is that if a proxy determines that a Request-URI on >> an incoming request is for a domain that it is responsible for, it >> performs an abstract-location-server lookup for the URI then this must >> be an AOR and the proxy tags the H-I entry representimg this uri as >> being an AOR. >> >> To me this seems totally deterministic. > > Afaik, there is no current conceptual field recorded in the abstract > location-service by 3261 that defines an entry as an "AoR" vs. just a default > route to the PSTN, for example. > > For example, when a proxy that is authoritative for example.com receives a > request for "sip:2345678901@example.com" form one of its users, it has the > ability to lookup that username in its LS, not find it, change it to > "sip:+12345678901@example.com" based on local policies, look it up again, and > find a match for that. So was the original "sip:2345678901@example.com" an > AoR? Presumably yes. What if the matching entry's next-hop was from a static > route vs. a registered contact? Also presumably yes. What if the matching > entry's next-hop is actually just a default route to a local PSTN gateway? > Presumably no it's not an AoR, but how does the Proxy distinguish this case > from the previous two? > > -hadriel > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From AUDET@nortel.com Sun Jul 12 20:36:16 2009 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 6892E3A6870 for ; Sun, 12 Jul 2009 20:36:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.463 X-Spam-Level: X-Spam-Status: No, score=-4.463 tagged_above=-999 required=5 tests=[AWL=0.069, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 FbX2x34topdE for ; Sun, 12 Jul 2009 20:36:15 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 580C23A6827 for ; Sun, 12 Jul 2009 20:36:15 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6D3aee07518; Mon, 13 Jul 2009 03:36:40 GMT Received: from 47.102.153.31 ([47.102.153.31]) by zrc2hxm0.corp.nortel.com ([47.103.123.71]) with Microsoft Exchange Server HTTP-DAV ; Mon, 13 Jul 2009 03:36:37 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Sun, 12 Jul 2009 20:36:35 -0700 From: "Francois Audet" To: Hadriel Kaplan , Hans Erik van Elburg , "James M. Polk" Message-ID: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoDM/ygnKlj7Hk3RC+UY5H/p15KNAAKje5QAAM6qkk= In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 13 Jul 2009 03:36:16 -0000 Hadriel, The AOR flag basically means: 1) The proxy is responsible for that domain; AND 2) The proxy recognize the user part as something that it can route. That's it. The really important point is really point 1. Foreign domains for example can't mark as AORs something they don't own. On Jul12 2009 19:10 , "Hadriel Kaplan" wrote: > > >> -----Original Message----- >> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >> Sent: Sunday, July 12, 2009 5:02 PM >> >> Nope, a GRUU is an AOR like any other, allthough with special property >> that it is targeted at a specific UA instance or restricted set of UA >> instances. That you can use it as a contact in INVITEs and responses is >> not of the essence. >> >> See 5.4, 6.1 of the GRUU draft >> http://[tools.ietf.org/html/draft-ietf-sip-gruu-15]. > > Every time I read that it tells me a GRUU is not an AoR. It has a > relationship with one, but it isn't one itself. At least in the language the > draft uses. For example: > > ...Every GRUU is associated with a single AOR > and a single instance ID. A registrar MUST be able to determine the > instance ID and AOR when presented with a GRUU. In addition, the > GRUU, like an AOR, resolves to zero or more contacts. While the AOR > resolves to all registered contacts for an AOR, a GRUU resolves only > to those contacts whose instance ID matches the one associated with > the GRUU. For this reason, a contact with an instance ID is always > bound to both a GRUU and its AOR, never just an AOR or just a GRUU. > > But I'm probably being real nitpicky pedantic. I'm not even sure it really > matters, because I have no idea why we care if a HI entry's URI is an "AoR" or > not. (but that's a topic for another thread :) > > -hadriel > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From HKaplan@acmepacket.com Sun Jul 12 20:41:04 2009 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 D88F73A6C18 for ; Sun, 12 Jul 2009 20:41:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 AVL6T0PqQOe0 for ; Sun, 12 Jul 2009 20:41:04 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 070583A6BD7 for ; Sun, 12 Jul 2009 20:41:04 -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.1.375.2; Sun, 12 Jul 2009 23:41:33 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 12 Jul 2009 23:41:33 -0400 From: Hadriel Kaplan To: Francois Audet , Hans Erik van Elburg Date: Sun, 12 Jul 2009 23:41:25 -0400 Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoC2Qnd4dNUCUvLRh2JQGrETeGzGAAHyVKQAByC5JcAACkJQA== 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 Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 13 Jul 2009 03:41:04 -0000 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Sunday, July 12, 2009 11:30 PM >=20 > Dude, are you arguing there is no such thing as an AOR? >=20 > What's your point? =20 My point is that if we need a Proxy to set an "aor" param (though I'm not s= ure what value there is in setting one), then there needs to be a defined m= echanism for how it decides to do so. Otherwise a domain's Proxy from vend= or X will decide foo is an aor, and vendor Y's will decide foo is not one -= and a UAS will not act the same way for foo. In other words, I need some programmatic way for my system to set a param w= hen it should, and not when it should not; so that my TAC does not get supp= ort calls complaining it should have done it when it didn't, or didn't do i= t when it should have. No? -hadriel From jmpolk@cisco.com Sun Jul 12 21:39:21 2009 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 EB3823A6A2C for ; Sun, 12 Jul 2009 21:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.317 X-Spam-Level: X-Spam-Status: No, score=-6.317 tagged_above=-999 required=5 tests=[AWL=0.282, 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 TCrNRGD-YWvx for ; Sun, 12 Jul 2009 21:39:20 -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 A81CE3A6922 for ; Sun, 12 Jul 2009 21:39:20 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgGAH9XWkqrR7O6/2dsb2JhbACIPqsBiCOOFgWECQ X-IronPort-AV: E=Sophos;i="4.42,388,1243814400"; d="scan'208";a="345351614" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 13 Jul 2009 04:39:51 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6D4dpO7031025; Sun, 12 Jul 2009 21:39:51 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6D4dphb010043; Mon, 13 Jul 2009 04:39:51 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 21:39:50 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.12.85]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 21:39:50 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 12 Jul 2009 23:39:48 -0500 To: "Elwell, John" , Martin.Thomson@andrew.com, sipcore@ietf.org From: "James M. Polk" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00218C372@GBNTHT12009MSX.gb 002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D00218C372@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 13 Jul 2009 04:39:50.0429 (UTC) FILETIME=[F54124D0:01CA0373] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3176; t=1247459991; x=1248323991; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20Use=20of=20term=20=22Location=20Server= 22=20in=20location-conveyance=20draft |Sender:=20; bh=zUu8snlFWzM4upz2nm80LGGDJwTW41+ycdugR4ZKJO8=; b=MqjGO3lqGh1ipobIjg+YsFu6onCFMzZVs+nUW7sYkNeCmzBR3FfP4sXyAv gGjTa6VGrs+MTedAccwSzyw9GWHmfp/wU6mlMA/j8ebub8sE87tannO1ZjWG gJ4Fzz+zdJ; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Subject: Re: [sipcore] Use of term "Location Server" in location-conveyance draft 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, 13 Jul 2009 04:39:22 -0000 john Sorry I missed this note earlier... see below At 01:37 AM 7/3/2009, Elwell, John wrote: >The separate thread arising from my review of the draft has left me very >confused about what exactly the term "Location Server" means in this >draft. > >The draft itself says: >" A [RFC3693] defined "Using > Protocol" describes how a "Location Server" transmits a "Location > Object" to a "Location Recipient" while maintaining the contained > privacy intentions of the Target intact. This document describes the > extension to SIP for how it complies with the Using Protocol > requirements, where the location server is a UA or Proxy Server and > the Location Recipient is another UA or Proxy Server." >My review comments that touched on this subject assumed the above >definition. >According to this, the server that the Location Recipient goes to to >dereference the LbyR URI is NOT a Location Server. But some of the >thread messages have suggested it IS a Location Server. We cannot use >the term Location Server to mean two different things. Can somebody >please clarify? In Geopriv, a Location Server (LS) is an entity that transmits location towards a Location Recipient (LR). This transmission might take that message through another LS before getting to the LR. In SIP terms, a UA or SIP server (of whatever flavor) that inserts location into a message (as a message body or as a dereferencable location URI) is an LS. A B2BUA that completes a call leg that contains location, and regenerates a new SIP request towards another B2BUA or UAS with that location in the new SIP request is also an LS. A proxy that inserts a dereferencable location URI is an LS. A proxy that does not insert a dereferencable location URI is NOT an LS (this time). It is basically performing a repeater function that is not defined in Geopriv. A UAS that understands location (i.e., something close to the Location Conveyance extension) is an LR. A UAS that receives location - but does not understand Location Conveyance - is not an LR (because it doesn't do anything with the location except throw it away). A SIP server that retargets a SIP request after viewing the contained location in that SIP request is also an LR, and because it did something with the location - I think it can be called an LS too (but some might disagree). A good example of this last case is a location source based routing proxy that retargets a R-URI based on the contained location within a SIP request, like say - an INVITE to 911. In this case, that proxy is an LR and an LS. The UAC is a Location Generator (LG) and an LS; and the PSAP call center (i.e., the UAS for the call) is an LS. Confused? :-p Geopriv elements change roles based on what they do, or can do. The only debatable label here is LG, as the label seems to have changed since RFC 3693 (Geopriv Requirements) which I co-authored - and the new doc describing the new functions isn't an RFC yet, and is shifting positions with a couple of its definitions lately (i.e., within the last year). James >John From john.elwell@siemens-enterprise.com Sun Jul 12 23:20:20 2009 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 6C45F3A6C2E for ; Sun, 12 Jul 2009 23:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 kVmu97A9qDet for ; Sun, 12 Jul 2009 23:20:19 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 371263A6BE8 for ; Sun, 12 Jul 2009 23:20:19 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KMP00F0SIYF57@siemenscomms.co.uk> for sipcore@ietf.org; Mon, 13 Jul 2009 07:20:39 +0100 (BST) Date: Mon, 13 Jul 2009 07:20:38 +0100 From: "Elwell, John" In-reply-to: To: "James M. Polk" , Martin.Thomson@andrew.com, sipcore@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00221DBF8@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Use of term "Location Server" in location-conveyance draft Thread-Index: AcoDc/nJIoTkSJbERLKp/n53WBpDsAADMq+A Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D00218C372@GBNTHT12009MSX.gb002.siemens.net> Subject: Re: [sipcore] Use of term "Location Server" in location-conveyance draft 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, 13 Jul 2009 06:20:20 -0000 James, I have to say this is mighty confusing. Basically location-conveyance is an extension to SIP, and therefore its primary purpose is to specify the SIP protocol and the behaviour of the various SIP entities involved. To have an important term that sometimes can mean a SIP entity (the SIP entity that inserts the Geolocation header field) and sometimes something quite unrelated to SIP location conveyance (the entity to which the dereferencing request is sent) strikes me as something we should avoid. In my opinion we should do one of the following: 1. Limit LS to having only one of these meanings, and if necessary introduce a new term for the other case. If this is not possible because it would conflict with other published documents, then do it locally within sip-location-conveyance using appropriate language ("For the purposes of this document, location server means....") 2. Avoid the term LS altogether in this document and define new terms for the various different purposes. John > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com]=20 > Sent: 13 July 2009 05:40 > To: Elwell, John; Martin.Thomson@andrew.com; sipcore@ietf.org > Subject: Re: Use of term "Location Server" in=20 > location-conveyance draft >=20 > john >=20 > Sorry I missed this note earlier... see below >=20 > At 01:37 AM 7/3/2009, Elwell, John wrote: > >The separate thread arising from my review of the draft has=20 > left me very > >confused about what exactly the term "Location Server" means in this > >draft. > > > >The draft itself says: > >" A [RFC3693] defined "Using > > Protocol" describes how a "Location Server" transmits a "Location > > Object" to a "Location Recipient" while maintaining the contained > > privacy intentions of the Target intact. This document=20 > describes the > > extension to SIP for how it complies with the Using Protocol > > requirements, where the location server is a UA or Proxy=20 > Server and > > the Location Recipient is another UA or Proxy Server." > >My review comments that touched on this subject assumed the above > >definition. > >According to this, the server that the Location Recipient goes to to > >dereference the LbyR URI is NOT a Location Server. But some of the > >thread messages have suggested it IS a Location Server. We cannot use > >the term Location Server to mean two different things. Can somebody > >please clarify? >=20 > In Geopriv, a Location Server (LS) is an entity that transmits=20 > location towards a Location Recipient (LR). This transmission might=20 > take that message through another LS before getting to the LR. >=20 > In SIP terms, a UA or SIP server (of whatever flavor) that inserts=20 > location into a message (as a message body or as a dereferencable=20 > location URI) is an LS. >=20 > A B2BUA that completes a call leg that contains location, and=20 > regenerates a new SIP request towards another B2BUA or UAS with that=20 > location in the new SIP request is also an LS. >=20 > A proxy that inserts a dereferencable location URI is an LS. >=20 > A proxy that does not insert a dereferencable location URI is NOT an=20 > LS (this time). It is basically performing a repeater function that=20 > is not defined in Geopriv. >=20 > A UAS that understands location (i.e., something close to the=20 > Location Conveyance extension) is an LR. A UAS that receives=20 > location - but does not understand Location Conveyance - is not an LR=20 > (because it doesn't do anything with the location except=20 > throw it away). >=20 > A SIP server that retargets a SIP request after viewing the contained=20 > location in that SIP request is also an LR, and because it did=20 > something with the location - I think it can be called an LS too (but=20 > some might disagree). >=20 > A good example of this last case is a location source based routing=20 > proxy that retargets a R-URI based on the contained location within a=20 > SIP request, like say - an INVITE to 911. >=20 > In this case, that proxy is an LR and an LS. The UAC is a Location=20 > Generator (LG) and an LS; and the PSAP call center (i.e., the UAS for=20 > the call) is an LS. >=20 > Confused? >=20 > :-p >=20 > Geopriv elements change roles based on what they do, or can do. >=20 > The only debatable label here is LG, as the label seems to have=20 > changed since RFC 3693 (Geopriv Requirements) which I co-authored -=20 > and the new doc describing the new functions isn't an RFC yet, and is=20 > shifting positions with a couple of its definitions lately (i.e.,=20 > within the last year). >=20 > James >=20 >=20 >=20 > >John >=20 >=20 From jmpolk@cisco.com Sun Jul 12 23:55:47 2009 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 AC98D3A687B for ; Sun, 12 Jul 2009 23:55:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.32 X-Spam-Level: X-Spam-Status: No, score=-6.32 tagged_above=-999 required=5 tests=[AWL=0.279, 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 xDW22rauoUXj for ; Sun, 12 Jul 2009 23:55:46 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 57F933A6CAD for ; Sun, 12 Jul 2009 23:55:46 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgGAOd2WkqrR7O6/2dsb2JhbACIPqsZiCOOFgWECQ X-IronPort-AV: E=Sophos;i="4.42,389,1243814400"; d="scan'208";a="185256154" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 13 Jul 2009 06:56:16 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6D6uGVu016467; Sun, 12 Jul 2009 23:56:16 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6D6uGGB016332; Mon, 13 Jul 2009 06:56:16 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 23:56:16 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.12.85]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 12 Jul 2009 23:56:16 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Jul 2009 01:56:11 -0500 To: "Elwell, John" , sipcore@ietf.org From: "James M. Polk" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00221DBF8@GBNTHT12009MSX.gb 002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D00218C372@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00221DBF8@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 13 Jul 2009 06:56:16.0196 (UTC) FILETIME=[045A1040:01CA0387] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=7014; t=1247468176; x=1248332176; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20Use=20of=20term=20=22Location=20Server= 22=20in=20location-conveyance=20draft |Sender:=20; bh=XXRDFL3PaqXFvAwkBHacdaHfLjMOKD6JOy+2FxO0Tac=; b=DkF7zW8yjwQ7FNl3n/bBsyByEwSbPrdUuiohCuS9AXdlbqlQgjUoHT2cM+ C515POeT4T4uSzJflQDKZ286Sx6632ZZKXIIxvn/2C33pyjYXE+/OSWO5CPp FzjD70tHjb; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: "marc Linsner \(mlinsner\)" Subject: Re: [sipcore] Use of term "Location Server" in location-conveyance draft 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, 13 Jul 2009 06:55:47 -0000 John in-line At 01:20 AM 7/13/2009, Elwell, John wrote: >James, > >I have to say this is mighty confusing. Basically location-conveyance is >an extension to SIP, and therefore its primary purpose is to specify the >SIP protocol and the behaviour of the various SIP entities involved. To >have an important term that sometimes can mean a SIP entity (the SIP >entity that inserts the Geolocation header field) and sometimes >something quite unrelated to SIP location conveyance (the entity to >which the dereferencing request is sent) strikes me as something we >should avoid. welcome to my world... ugh >In my opinion we should do one of the following: > >1. Limit LS to having only one of these meanings, and if necessary >introduce a new term for the other case. I thought we had a server entity term defined that was just for dereferences, called a Location Information Server (LIS), but apparently that term was taken (hijacked?) just for Location Configuration Protocols (LCPs) like DHCP and especially HELD. See Martin's recent message clarifying this to me. It was news too. I say especially HELD because it appears that crew actually did the "taking" deed. It appears to me that Location Servers that are essentially peers that communicate location values or references in the signaling path of the original SIP request is a good delineation. Then, having another term defining what entity the location URIs point at (i.e., the dereferencing function) should NOT be called the same thing, this is what I was calling a LIS (Location Information Server), which had a unique function, storing all the PIDF-LOs for the location targets (prior to any dereferencing). > If this is not possible because >it would conflict with other published documents, then do it locally >within sip-location-conveyance using appropriate language ("For the >purposes of this document, location server means....") interesting... that would mean I (or a small group) would be defining a small parallel set of terms that do not go anywhere else except in the case of Conveyance... Can I recommend you send this suggestion (with the WHY!) to Keith Drage? He's the doc shepherd for this ID. That will probably go the farthest. CCing the chairs would always be a good idea. I hope to have the final version ready for WGLC before the milestone date of Sept 09. This will take a little thought once it's solved for, but it's pretty much a global replace function once we come up with a set of terms to use. -01 of conveyance will be out tomorrow, and Spencer Dawkins did a pretty good job at making it easier to read. He didn't address the term confusion though. This term issue aside, I was hoping this -01 version was the version that went to WGLC. >2. Avoid the term LS altogether in this document and define new terms >for the various different purposes. yeah -- that would be what I'd have to do -- if the chairs and the shepherd agree to this. We all can talk live about this in Stockholm hopefully. BTW - if it's not clear yet within this message -- I'm not opposed to doing this (because of the confusion associated with this topic). James >John > > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: 13 July 2009 05:40 > > To: Elwell, John; Martin.Thomson@andrew.com; sipcore@ietf.org > > Subject: Re: Use of term "Location Server" in > > location-conveyance draft > > > > john > > > > Sorry I missed this note earlier... see below > > > > At 01:37 AM 7/3/2009, Elwell, John wrote: > > >The separate thread arising from my review of the draft has > > left me very > > >confused about what exactly the term "Location Server" means in this > > >draft. > > > > > >The draft itself says: > > >" A [RFC3693] defined "Using > > > Protocol" describes how a "Location Server" transmits a "Location > > > Object" to a "Location Recipient" while maintaining the contained > > > privacy intentions of the Target intact. This document > > describes the > > > extension to SIP for how it complies with the Using Protocol > > > requirements, where the location server is a UA or Proxy > > Server and > > > the Location Recipient is another UA or Proxy Server." > > >My review comments that touched on this subject assumed the above > > >definition. > > >According to this, the server that the Location Recipient goes to to > > >dereference the LbyR URI is NOT a Location Server. But some of the > > >thread messages have suggested it IS a Location Server. We cannot use > > >the term Location Server to mean two different things. Can somebody > > >please clarify? > > > > In Geopriv, a Location Server (LS) is an entity that transmits > > location towards a Location Recipient (LR). This transmission might > > take that message through another LS before getting to the LR. > > > > In SIP terms, a UA or SIP server (of whatever flavor) that inserts > > location into a message (as a message body or as a dereferencable > > location URI) is an LS. > > > > A B2BUA that completes a call leg that contains location, and > > regenerates a new SIP request towards another B2BUA or UAS with that > > location in the new SIP request is also an LS. > > > > A proxy that inserts a dereferencable location URI is an LS. > > > > A proxy that does not insert a dereferencable location URI is NOT an > > LS (this time). It is basically performing a repeater function that > > is not defined in Geopriv. > > > > A UAS that understands location (i.e., something close to the > > Location Conveyance extension) is an LR. A UAS that receives > > location - but does not understand Location Conveyance - is not an LR > > (because it doesn't do anything with the location except > > throw it away). > > > > A SIP server that retargets a SIP request after viewing the contained > > location in that SIP request is also an LR, and because it did > > something with the location - I think it can be called an LS too (but > > some might disagree). > > > > A good example of this last case is a location source based routing > > proxy that retargets a R-URI based on the contained location within a > > SIP request, like say - an INVITE to 911. > > > > In this case, that proxy is an LR and an LS. The UAC is a Location > > Generator (LG) and an LS; and the PSAP call center (i.e., the UAS for > > the call) is an LS. > > > > Confused? > > > > :-p > > > > Geopriv elements change roles based on what they do, or can do. > > > > The only debatable label here is LG, as the label seems to have > > changed since RFC 3693 (Geopriv Requirements) which I co-authored - > > and the new doc describing the new functions isn't an RFC yet, and is > > shifting positions with a couple of its definitions lately (i.e., > > within the last year). > > > > James > > > > > > > > >John > > > > From john.elwell@siemens-enterprise.com Mon Jul 13 00:15:07 2009 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 467563A6A46 for ; Mon, 13 Jul 2009 00:15:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 BaflXVsgdvUw for ; Mon, 13 Jul 2009 00:15:06 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 7A16D3A6847 for ; Mon, 13 Jul 2009 00:15:05 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KMP00HBALHYSI@siemenscomms.co.uk> for sipcore@ietf.org; Mon, 13 Jul 2009 08:15:35 +0100 (BST) Date: Mon, 13 Jul 2009 08:15:33 +0100 From: "Elwell, John" In-reply-to: To: "James M. Polk" , sipcore@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00221DC12@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Use of term "Location Server" in location-conveyance draft Thread-Index: AcoDhweayR8gSLSsQdy+HNg6R5GcvwAAi3eA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D00218C372@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00221DBF8@GBNTHT12009MSX.gb002.siemens.net> Cc: "marc Linsner \(mlinsner\)" Subject: Re: [sipcore] Use of term "Location Server" in location-conveyance draft 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, 13 Jul 2009 07:15:07 -0000 James, It occurs to me we already have the term location inserter used in various places in the document, so why don't we stick to this, rather than location server, for the UA or proxy that inserts? Then we could use the term location server for the server you go to to dereference LbyR. I agree with others, by the way, that LIS is not an appropriate term for the latter. John=20 > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com]=20 > Sent: 13 July 2009 07:56 > To: Elwell, John; sipcore@ietf.org > Cc: marc Linsner (mlinsner) > Subject: RE: Use of term "Location Server" in=20 > location-conveyance draft >=20 > John >=20 > in-line >=20 > At 01:20 AM 7/13/2009, Elwell, John wrote: > >James, > > > >I have to say this is mighty confusing. Basically=20 > location-conveyance is > >an extension to SIP, and therefore its primary purpose is to=20 > specify the > >SIP protocol and the behaviour of the various SIP entities=20 > involved. To > >have an important term that sometimes can mean a SIP entity (the SIP > >entity that inserts the Geolocation header field) and sometimes > >something quite unrelated to SIP location conveyance (the entity to > >which the dereferencing request is sent) strikes me as something we > >should avoid. >=20 > welcome to my world... ugh >=20 > >In my opinion we should do one of the following: > > > >1. Limit LS to having only one of these meanings, and if necessary > >introduce a new term for the other case. >=20 > I thought we had a server entity term defined that was just for=20 > dereferences, called a Location Information Server (LIS), but=20 > apparently that term was taken (hijacked?) just for Location=20 > Configuration Protocols (LCPs) like DHCP and especially HELD. See=20 > Martin's recent message clarifying this to me. It was news too. I=20 > say especially HELD because it appears that crew actually did the=20 > "taking" deed. >=20 > It appears to me that Location Servers that are essentially peers=20 > that communicate location values or references in the signaling path=20 > of the original SIP request is a good delineation. >=20 > Then, having another term defining what entity the location URIs=20 > point at (i.e., the dereferencing function) should NOT be called the=20 > same thing, this is what I was calling a LIS (Location Information=20 > Server), which had a unique function, storing all the PIDF-LOs for=20 > the location targets (prior to any dereferencing). >=20 > > If this is not possible because > >it would conflict with other published documents, then do it locally > >within sip-location-conveyance using appropriate language ("For the > >purposes of this document, location server means....") >=20 > interesting... that would mean I (or a small group) would be defining=20 > a small parallel set of terms that do not go anywhere else except in=20 > the case of Conveyance... >=20 > Can I recommend you send this suggestion (with the WHY!) to Keith=20 > Drage? He's the doc shepherd for this ID. That will probably go the=20 > farthest. CCing the chairs would always be a good idea. >=20 > I hope to have the final version ready for WGLC before the milestone=20 > date of Sept 09. >=20 > This will take a little thought once it's solved for, but it's pretty=20 > much a global replace function once we come up with a set of=20 > terms to use. >=20 > -01 of conveyance will be out tomorrow, and Spencer Dawkins did a=20 > pretty good job at making it easier to read. He didn't address the=20 > term confusion though. >=20 > This term issue aside, I was hoping this -01 version was the version=20 > that went to WGLC. >=20 >=20 > >2. Avoid the term LS altogether in this document and define new terms > >for the various different purposes. >=20 > yeah -- that would be what I'd have to do -- if the chairs and the=20 > shepherd agree to this. We all can talk live about this in Stockholm=20 > hopefully. >=20 > BTW - if it's not clear yet within this message -- I'm not opposed to=20 > doing this (because of the confusion associated with this topic). >=20 > James >=20 >=20 > >John > > > > > > > -----Original Message----- > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > Sent: 13 July 2009 05:40 > > > To: Elwell, John; Martin.Thomson@andrew.com; sipcore@ietf.org > > > Subject: Re: Use of term "Location Server" in > > > location-conveyance draft > > > > > > john > > > > > > Sorry I missed this note earlier... see below > > > > > > At 01:37 AM 7/3/2009, Elwell, John wrote: > > > >The separate thread arising from my review of the draft has > > > left me very > > > >confused about what exactly the term "Location Server"=20 > means in this > > > >draft. > > > > > > > >The draft itself says: > > > >" A [RFC3693] defined "Using > > > > Protocol" describes how a "Location Server"=20 > transmits a "Location > > > > Object" to a "Location Recipient" while maintaining=20 > the contained > > > > privacy intentions of the Target intact. This document > > > describes the > > > > extension to SIP for how it complies with the Using Protocol > > > > requirements, where the location server is a UA or Proxy > > > Server and > > > > the Location Recipient is another UA or Proxy Server." > > > >My review comments that touched on this subject assumed the above > > > >definition. > > > >According to this, the server that the Location=20 > Recipient goes to to > > > >dereference the LbyR URI is NOT a Location Server. But=20 > some of the > > > >thread messages have suggested it IS a Location Server.=20 > We cannot use > > > >the term Location Server to mean two different things.=20 > Can somebody > > > >please clarify? > > > > > > In Geopriv, a Location Server (LS) is an entity that transmits > > > location towards a Location Recipient (LR). This=20 > transmission might > > > take that message through another LS before getting to the LR. > > > > > > In SIP terms, a UA or SIP server (of whatever flavor) that inserts > > > location into a message (as a message body or as a dereferencable > > > location URI) is an LS. > > > > > > A B2BUA that completes a call leg that contains location, and > > > regenerates a new SIP request towards another B2BUA or=20 > UAS with that > > > location in the new SIP request is also an LS. > > > > > > A proxy that inserts a dereferencable location URI is an LS. > > > > > > A proxy that does not insert a dereferencable location=20 > URI is NOT an > > > LS (this time). It is basically performing a repeater=20 > function that > > > is not defined in Geopriv. > > > > > > A UAS that understands location (i.e., something close to the > > > Location Conveyance extension) is an LR. A UAS that receives > > > location - but does not understand Location Conveyance -=20 > is not an LR > > > (because it doesn't do anything with the location except > > > throw it away). > > > > > > A SIP server that retargets a SIP request after viewing=20 > the contained > > > location in that SIP request is also an LR, and because it did > > > something with the location - I think it can be called an=20 > LS too (but > > > some might disagree). > > > > > > A good example of this last case is a location source=20 > based routing > > > proxy that retargets a R-URI based on the contained=20 > location within a > > > SIP request, like say - an INVITE to 911. > > > > > > In this case, that proxy is an LR and an LS. The UAC is=20 > a Location > > > Generator (LG) and an LS; and the PSAP call center (i.e.,=20 > the UAS for > > > the call) is an LS. > > > > > > Confused? > > > > > > :-p > > > > > > Geopriv elements change roles based on what they do, or can do. > > > > > > The only debatable label here is LG, as the label seems to have > > > changed since RFC 3693 (Geopriv Requirements) which I=20 > co-authored - > > > and the new doc describing the new functions isn't an RFC=20 > yet, and is > > > shifting positions with a couple of its definitions lately (i.e., > > > within the last year). > > > > > > James > > > > > > > > > > > > >John > > > > > > >=20 >=20 From shin@softfront.co.jp Mon Jul 13 02:11:17 2009 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 848C028C146 for ; Mon, 13 Jul 2009 02:11:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.069 X-Spam-Level: *** X-Spam-Status: No, score=3.069 tagged_above=-999 required=5 tests=[AWL=0.936, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, UNPARSEABLE_RELAY=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 Q3KX-4ByKFWm for ; Mon, 13 Jul 2009 02:11:16 -0700 (PDT) Received: from mail2.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with SMTP id 64B843A6B3D for ; Mon, 13 Jul 2009 02:11:15 -0700 (PDT) Received: from softfront.co.jp by mail2.softfront.co.jp id AA04164 ; 13 Jul 2009 18:11:41 +0900 From: OKUMURA Shinji To: SIPCORE Date: Mon, 13 Jul 2009 18:11:40 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.18 (WinNT,501) In-Reply-To: <1247257464.3757.67.camel@victoria-pingtel-com.us.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF1EDE5C07@zrc2hxm0.corp.nortel.com> <1247077928.3712.26.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EE8A67C@zrc2hxm0.corp.nortel.com> <1247257464.3757.67.camel@victoria-pingtel-com.us.nortel.com> Message-Id: <31CA0399EEB8A1shin@softfront.co.jp> Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax 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, 13 Jul 2009 09:11:17 -0000 Hi, "Dale Worley" >On Thu, 2009-07-09 at 14:07 -0400, Audet, Francois (SC100:3055) wrote: >> It's basically saying that the Privacy and Reason "escaped parameters" would >> translate into headers if we were to created a request based on it. > >I can't see any circumstances where we would want to create a request >that included the Privacy or Reason headers from a H-I entry. > >In regard to Privacy, if its value is "history", that means that the >particular H-I URI should be restricted. But that is not the meaning of >adding the "Privacy: history" header to a request -- in the latter case, >History-Info should not be generated at all. (Which is what I mean when >I say "the values of Privacy in History-Info do not have the same >semantics as the values of the Privacy header".) I have another question in regard to the above. When the entity that add a hi-entity require privacy service to removed it, where should the entity set a priv-value "critical" ? If it set "critical" in Privacy header of the request, all hi-entities are removed. If in hi-targeted-to-uri, the privacy service that does not support "history" will forward the request without the change. Is this correct? Regards, Shinji >In regard to Reason, as far as I can tell, it is attached to an H-I >entry to show the response that was received to the request that was >sent to that URI. Generating a request based on that H-I entry would >create a request to that same URI, containing a Reason header in the >request that *predicts* the response that the request will receive. > >Given that in no case would we want to generate and use (with the >implicit headers) a request based on the H-I entry's URI-with-headers, I >don't see why these data items are stored in headers attached to the >URI. > >On Wed, 2009-07-08 at 19:25 -0400, Barnes, Mary (RICH2:AR00) wrote: >> As far as privacy, I'm not sure what you mean with regards >> to " This privacy value is an annotation of the URI, whereas the current >> syntax incorporates it *into* the URI." The privacy value isn't >> incorporated into the URI - it's an escaped parameter. > >It's an escaped parameter, but it *is* part of the URI -- see the >production "SIP-URI" in section 25.1 of RFC 3261. And if you ask the >grammar, "What is the URI part of an H-I entry?" you will get back the >'headers' as part of the URI. > >Similarly, any device or syntax which admits a SIP URI will allow you to >enter a string containing 'headers'. Indeed, there is only one >situation where a SIP URI is possible but that URI cannot contain >'headers', and that is as the request-URI of a request. That isn't >specified in the syntax (which allows SIP-URI), but is a consequence of >the processing in section 19.1.5, which removes the 'headers' from the >supplied SIP URI and turns them into message headers. > >Dale From shin@softfront.co.jp Mon Jul 13 03:49:14 2009 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 50E5128C2DA for ; Mon, 13 Jul 2009 03:49:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.835 X-Spam-Level: ** X-Spam-Status: No, score=2.835 tagged_above=-999 required=5 tests=[AWL=0.702, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, UNPARSEABLE_RELAY=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 quUgvsrjLzC5 for ; Mon, 13 Jul 2009 03:49:13 -0700 (PDT) Received: from mail2.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with SMTP id 188653A6D4C for ; Mon, 13 Jul 2009 03:48:50 -0700 (PDT) Received: from softfront.co.jp by mail2.softfront.co.jp id AA03472 ; 13 Jul 2009 19:49:18 +0900 From: OKUMURA Shinji To: SIPCORE Date: Mon, 13 Jul 2009 19:49:15 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.18 (WinNT,501) In-Reply-To: <4A528AB2.7020206@cisco.com> References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com> Message-Id: <5DCA03A790E168shin@softfront.co.jp> Cc: gao.yang2@zte.com.cn Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 13 Jul 2009 10:49:14 -0000 Hi, comment inline. Regards, Shinji Paul Kyzivat >Gonzalo, > >Thanks for doing this work! I do have some comments: > >> 9. Clarifications on Target Refresh Requests >> >> On receiving a target refresh request with an updated remote target, >> a UAS updates the remote target of the dialog immediately. This >> update represents the execution of a state change. Therefore, >> following the rules in Section 5, UASs always return 2xx responses to >> target refresh requests that update the remote target. > >This does not address cases where the UAS cannot accept the change with >a 200. Some cases that fall into this category are: > >- request includes a Require of an unsupported option (e.g. 100rel) >- request cannot be authorized >- server overload >- precondition failure > >In any case, if no state changes have been made prior to the request >with a target change, then there is no issue with rejecting the target >refresh if need be. > >The issue with target refresh is that the UA sending it may have an >urgent need for it to be accepted, since it may not be able to >communicate on its old address(es) any longer. And if that is the case >it may also have an urgent need to change its media addresses as well >for the same reason. That would be motivation for doing both at once. > >If a reINVITE includes a target change, then its very difficult to know >when the UAC must begin using it. So I think the UAS must assume it must >be considered in use immediately. Hence it should *try* to avoid >rejecting the request, even if it must reject all the media in the >request. But there is still a possibility that it will have to reject >due to authorization, overload, etc. If that is done right away its no >different than any request rejected before any changes have been made. > >A difficult case is where a reINVITE has been initiated, and has not >completed. (Perhaps its ringing.) Then the UAC loses its IP address or >IP connectivity and needs to make a target change. So it sends an UPDATE >with the target change. What it should probably do in that case is *not* >include an offer in the UPDATE. Then it can't be rejected for o/a >reasons. Once that is done it can continue the o/a process, updating its >media addresses when it has the chance. Once the UAC target has changed, >the UAS should not fail the INVITE. If need be it should reject all the >media in order to avoid that. At this point, IP Address of the UAC has be changed, so the responce of the reINVITE request could probably not be returned to the UAC. And then reINVITE client transaction would return a timeout. Rather it would be better to CANCEL it. Altogether UPDATE transaction SHOULD be excluded from the rollback, I think now. >Another difficult case if if a reINVITE has been initiated and the UAS >finds it needs to change its address. Similar considerations to above >seem to apply. > >Frankly, this is all very nasty, and those in this situation may have >few options for what do do. It feels deserving of its own treatment. >Namely a whole call flow document with various use cases where target >change is required. Probably a BCP. > > Thanks, > Paul From Peter.Dawes@vodafone.com Mon Jul 13 04:11:47 2009 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 735C13A6810 for ; Mon, 13 Jul 2009 04:11:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_84=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 5RO-dlTIKNb0 for ; Mon, 13 Jul 2009 04:11:46 -0700 (PDT) Received: from mailout03.vodafone.com (mailout03.vodafone.com [195.232.224.72]) by core3.amsl.com (Postfix) with ESMTP id 4F1703A67DA for ; Mon, 13 Jul 2009 04:11:45 -0700 (PDT) Received: from mailint03 (localhost [127.0.0.1]) by mailout03 (Postfix) with ESMTP id 28C9111689F for ; Mon, 13 Jul 2009 13:12:14 +0200 (CEST) Received: from mi3.vodafone.com (mi3.vodafone.com [195.232.246.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailint03 (Postfix) with ESMTPS id 1C89A11689B; Mon, 13 Jul 2009 13:12:14 +0200 (CEST) Received: from avoexs01.internal.vodafone.com ([145.230.4.134]) by mi3.vodafone.com (Switch-3.2.0/Switch-3.2.0) with ESMTP id n6DBCCx4019522 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Mon, 13 Jul 2009 13:12:13 +0200 Received: from EITO-MBX02.internal.vodafone.com ([145.230.4.11]) by avoexs01.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jul 2009 13:12:13 +0200 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: Mon, 13 Jul 2009 13:12:11 +0200 Message-ID: In-Reply-To: <1245876685.3748.61.camel@victoria-pingtel-com.us.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-kaplan-sip-session-id-02 Thread-Index: Acn1DaU1pu17VvRRTd+gHdXlHhTG9AOmEHkw References: <1245876685.3748.61.camel@victoria-pingtel-com.us.nortel.com> From: "Dawes, Peter, VF-Group" To: "SIPCORE" , "Hadriel Kaplan" X-OriginalArrivalTime: 13 Jul 2009 11:12:13.0921 (UTC) FILETIME=[C644ED10:01CA03AA] Cc: Dale Worley Subject: Re: [sipcore] draft-kaplan-sip-session-id-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, 13 Jul 2009 11:11:47 -0000 Hello Hadriel, Dale, Regarding the length of the session-id header field, is it really necessary to guarantee global uniqueness and use 128 bits? The uses of this new header field described in -02 are 'troubleshooting' and 'identity verification mechanisms', but troubleshooting will be restricted to relatively short time period after which a session-id value could be reused. Identity verification is not described but does it require a globally unique session-id? Troubleshooting is also the topic of my draft http://tools.ietf.org/html/draft-dawes-sipping-debug-01, which is similar to session-id but also describes how troubleshooting starts and stops, and how entities determine when to add a header field for debugging. According to session-id-02, the session-id header field is present in all dialogs, which implies troubleshooting needs to record everything, potentially at multiple entities some of which may not be involved in the session being investigated, and then post-analyse for the particular session that is targetted for troubleshooting. This seems inefficient, or have I misunderstood? =20 Best Regards, Peter=20 Peter Dawes=20 Group R&D =20 Tel: +44 (0)7717 275009 Fax: +44 (0)1635 234873 =20 E-mail: peter.dawes@vodafone.com =20 www.betavine.net - Web betavine.mobi - Mobile Web =20 Vodafone Group Services Limited=20 Registered Office: Vodafone House, The Connection, Newbury, Berkshire RG14 2FN Registered in England No 3802001 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Dale Worley Sent: 24 June 2009 21:51 To: SIPCORE Subject: [sipcore] draft-kaplan-sip-session-id-02 Looking at draft-kaplan-sip-session-id-02, the shorter the Session-Id header is, the fewer complaints people will have about using it in practice. A couple of things could be done to shorten it: - assign a single-letter abbreviation for the name - use base64 rather than hex encoding Base64 encoding reduces the header value to 22 characters from 32. Dale _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From root@core3.amsl.com Mon Jul 13 04:15:01 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 9C8343A6D6C; Mon, 13 Jul 2009 04:15:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090713111501.9C8343A6D6C@core3.amsl.com> Date: Mon, 13 Jul 2009 04:15:01 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-presence-scaling-requirements-01.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, 13 Jul 2009 11:15:01 -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 : Scaling Requirements for Presence in SIP/SIMPLE Author(s) : A. Houri, et al. Filename : draft-ietf-sipcore-presence-scaling-requirements-01.txt Pages : 9 Date : 2009-07-13 The document provides a set of requirements for enabling inter-domain scaling in presence for SIP/SIMPLE. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-presence-scaling-requirements-01.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-presence-scaling-requirements-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-13040659.I-D@ietf.org> --NextPart-- From gonzalo.camarillo@ericsson.com Mon Jul 13 06:06:58 2009 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 8263E3A6C19 for ; Mon, 13 Jul 2009 06:06:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.142 X-Spam-Level: X-Spam-Status: No, score=-6.142 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 yhbVA0vTYNlD for ; Mon, 13 Jul 2009 06:06:57 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 87FD93A6D29 for ; Mon, 13 Jul 2009 06:06:57 -0700 (PDT) X-AuditID: c1b4fb3e-b7be7ae000001a87-db-4a5b318cf1fa Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 53.C8.06791.C813B5A4; Mon, 13 Jul 2009 15:07:24 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Jul 2009 15:07:24 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Mon, 13 Jul 2009 15:07:23 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1C55B2461; Mon, 13 Jul 2009 16:07:24 +0300 (EEST) Message-ID: <4A5B318B.6020206@ericsson.com> Date: Mon, 13 Jul 2009 16:07:23 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2009 13:07:24.0088 (UTC) FILETIME=[DD0CBB80:01CA03BA] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Adopting the invfix draft as a WG item? 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, 13 Jul 2009 13:06:58 -0000 Folks, the following draft documents important fixes to RFC 3261. http://tools.ietf.org/html/draft-sparks-sipcore-invfix-00 (This draft has been around for a while as draft-sparks-sip-invfix.) Our charter includes working on essential corrections to RFC 3261. Therefore, we would like to ask the WG whether or not we should adopt this draft as a WG item. If we adopt this draft, the idea will be to WGLC it. Then, we would advance it in whatever way we decide essential corrections should be advanced (how to document essential corrections is being discussed in a different thread on this mailing list). Thanks, Gonzalo SIPCORE co-chair From ben@nostrum.com Mon Jul 13 06:30:26 2009 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 63C7728C142 for ; Mon, 13 Jul 2009 06:30:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-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 SZsTQMbi3HwJ for ; Mon, 13 Jul 2009 06:30:25 -0700 (PDT) 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 DD0463A6DD9 for ; Mon, 13 Jul 2009 06:30:24 -0700 (PDT) Received: from [10.0.1.2] (adsl-68-94-0-215.dsl.rcsntx.swbell.net [68.94.0.215]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n6DDUo46090961 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 13 Jul 2009 08:30:51 -0500 (CDT) (envelope-from ben@nostrum.com) Message-Id: From: Ben Campbell To: Gonzalo Camarillo In-Reply-To: <4A5B318B.6020206@ericsson.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Mon, 13 Jul 2009 08:30:45 -0500 References: <4A5B318B.6020206@ericsson.com> X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 68.94.0.215 is authenticated by a trusted mechanism) Cc: SIPCORE Subject: Re: [sipcore] Adopting the invfix draft as a WG item? 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, 13 Jul 2009 13:30:26 -0000 On Jul 13, 2009, at 8:07 AM, Gonzalo Camarillo wrote: > Our charter includes working on essential corrections to RFC 3261. > Therefore, we would like to ask the WG whether or not we should > adopt this draft as a WG item. Yes. Thanks! Ben. From michael@voip.co.uk Mon Jul 13 06:31:07 2009 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 A128D28C2E8 for ; Mon, 13 Jul 2009 06:31:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 OoJDgeDog4B6 for ; Mon, 13 Jul 2009 06:31:07 -0700 (PDT) Received: from na3sys009aog114.obsmtp.com (na3sys009aog114.obsmtp.com [74.125.149.211]) by core3.amsl.com (Postfix) with SMTP id 620FA28C290 for ; Mon, 13 Jul 2009 06:31:06 -0700 (PDT) Received: from source ([72.14.220.154]) by na3sys009aob114.postini.com ([74.125.148.12]) with SMTP ID DSNKSls3OED80wFPTjv6pwOZbOlZV99+JPFF@postini.com; Mon, 13 Jul 2009 06:31:37 PDT Received: by fg-out-1718.google.com with SMTP id d23so382954fga.16 for ; Mon, 13 Jul 2009 06:31:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.86.66.12 with SMTP id o12mr3298568fga.69.1247491896025; Mon, 13 Jul 2009 06:31:36 -0700 (PDT) In-Reply-To: <4A5B318B.6020206@ericsson.com> References: <4A5B318B.6020206@ericsson.com> Date: Mon, 13 Jul 2009 14:31:36 +0100 Message-ID: From: Michael Procter To: Gonzalo Camarillo Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Adopting the invfix draft as a WG item? 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, 13 Jul 2009 13:31:07 -0000 2009/7/13 Gonzalo Camarillo : > > http://tools.ietf.org/html/draft-sparks-sipcore-invfix-00 > > (This draft has been around for a while as draft-sparks-sip-invfix.) > > Our charter includes working on essential corrections to RFC 3261. > Therefore, we would like to ask the WG whether or not we should adopt this > draft as a WG item. I support adopting this draft. Michael From victor.pascual.avila@gmail.com Mon Jul 13 06:35:18 2009 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 07B3A3A6DC2 for ; Mon, 13 Jul 2009 06:35:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.487 X-Spam-Level: X-Spam-Status: No, score=-2.487 tagged_above=-999 required=5 tests=[AWL=0.113, 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 Er9Qz-rhHK3N for ; Mon, 13 Jul 2009 06:35:17 -0700 (PDT) Received: from mail-bw0-f228.google.com (mail-bw0-f228.google.com [209.85.218.228]) by core3.amsl.com (Postfix) with ESMTP id 044173A6DB9 for ; Mon, 13 Jul 2009 06:35:16 -0700 (PDT) Received: by bwz28 with SMTP id 28so154652bwz.37 for ; Mon, 13 Jul 2009 06:35:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=jHnfurmFHgTu4PqQObKTzUdpL6CZ5xm1qxT8OdD93PM=; b=E4EvH5QtPE/jbLb+aiW4qomvVUW8a1ACNdDMWYDqD35DPFP2QrCKxwr2OAvnzYqniL cbRMbPDlddAobNvfJHnv9GaVuJR7iTe4obrRUAK495qKFvx2yjwH0Q20StpBrVyHf863 P4SN8zd1XACOov3JZHcHCKJI62Ei4Sikj/k+o= 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=ORG7PezZFAoRtoBl/1Gn5sGpwszRpFCo+fhZ4BJJTo3a1adI6j0elm39kZMxMzWLTc 9Aeb8pq9I+tVaAY12Zn0JCaCWU6n2sBgkZ2983ZU/yY9HAmMOuVbfE6FPguB8xapQlqi VLTHcBCGcKFXT3ontosO18Q/KwKn3BNdG3UoQ= MIME-Version: 1.0 Received: by 10.204.61.209 with SMTP id u17mr5252738bkh.86.1247492144850; Mon, 13 Jul 2009 06:35:44 -0700 (PDT) In-Reply-To: References: <4A5B318B.6020206@ericsson.com> Date: Mon, 13 Jul 2009 15:35:44 +0200 Message-ID: <618e24240907130635m5e5d3293weba8c98934906c66@mail.gmail.com> From: Victor Pascual Avila To: Gonzalo Camarillo Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: SIPCORE Subject: Re: [sipcore] Adopting the invfix draft as a WG item? 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, 13 Jul 2009 13:35:18 -0000 On Mon, Jul 13, 2009 at 3:31 PM, Michael Procter wrote: > 2009/7/13 Gonzalo Camarillo : >> >> http://tools.ietf.org/html/draft-sparks-sipcore-invfix-00 >> >> (This draft has been around for a while as draft-sparks-sip-invfix.) >> >> Our charter includes working on essential corrections to RFC 3261. >> Therefore, we would like to ask the WG whether or not we should adopt th= is >> draft as a WG item. > > I support adopting this draft. +1 --=20 Victor Pascual =C3=81vila From L.Liess@telekom.de Mon Jul 13 08:59:59 2009 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 0478F28C457 for ; Mon, 13 Jul 2009 08:59:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, J_CHICKENPOX_84=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 vU803WgcY2T4 for ; Mon, 13 Jul 2009 08:59:57 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 3D2F028C177 for ; Mon, 13 Jul 2009 08:59:57 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 13 Jul 2009 18:00:06 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jul 2009 18:00:05 +0200 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 13 Jul 2009 18:00:04 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A00330040F@S4DE9JSAANI.ost.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-kaplan-sip-session-id-02 thread-index: Acn1DaU1pu17VvRRTd+gHdXlHhTG9AOmEHkwAAGgysA= References: <1245876685.3748.61.camel@victoria-pingtel-com.us.nortel.com> From: To: , X-OriginalArrivalTime: 13 Jul 2009 16:00:05.0802 (UTC) FILETIME=[FD1CD0A0:01CA03D2] Cc: sipcore@ietf.org, Gerold.Pinker@telekom.de, dworley@nortel.com, R.Jesske@telekom.de, Martin.Huelsemann@telekom.de Subject: Re: [sipcore] draft-kaplan-sip-session-id-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, 13 Jul 2009 15:59:59 -0000 Peter, we intend to use the Session-ID for traffic monitoring.=20 Personally, I like the debug drafts a lot because it is a quite efficient mechanism for detecting faults quickly but it covers quite different scenarios than Session-ID. We discussed internaly what to use and decided for Session-ID for following reasons:=20 - The monitoring is done by a separate device, we don't use the logfiles of the proxies.=20 - We can not rely on end devices. We already have a lot of end devices in the field which do not have session-ID or debug-id implemented. First SBC in the path has to insert the new ID. Also, the security people whant to use the ID to trace attacks and we assume that the attacker's clients will not insert the debugg-id.=20 - We want to be able to correlate the messages end-to-end also if we do not know in advance if we want to monitor a specific call.=20 - The monitoring is active all the time. The security people want to be able to look what happened in the past. So the global uniqueness requirement makes sense for me.=20 - The hashing is needed because we do not want the calle to see the IP-address of the caller end most devices insert the IP-address in the call-id. =20 Kind regards Laura =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Dawes, Peter, VF-Group > Sent: Monday, July 13, 2009 1:12 PM > To: SIPCORE; Hadriel Kaplan > Cc: Dale Worley > Subject: Re: [sipcore] draft-kaplan-sip-session-id-02 >=20 > Hello Hadriel, Dale, > Regarding the length of the session-id header field, is it really > necessary to guarantee global uniqueness and use 128 bits? The uses of > this new header field described in -02 are 'troubleshooting' and > 'identity verification mechanisms', but troubleshooting will be > restricted to relatively short time period after which a session-id > value could be reused. Identity verification is not described but does > it require a globally unique session-id? >=20 > Troubleshooting is also the topic of my draft > http://tools.ietf.org/html/draft-dawes-sipping-debug-01, which is > similar to session-id but also describes how troubleshooting=20 > starts and > stops, and how entities determine when to add a header field for > debugging. According to session-id-02, the session-id header field is > present in all dialogs, which implies troubleshooting needs to record > everything, potentially at multiple entities some of which may not be > involved in the session being investigated, and then post-analyse for > the particular session that is targetted for troubleshooting.=20 > This seems > inefficient, or have I misunderstood? > =20 > Best Regards, > Peter=20 >=20 >=20 > Peter Dawes=20 > Group R&D > =20 > Tel: +44 (0)7717 275009 > Fax: +44 (0)1635 234873 >=20 > =20 > E-mail: peter.dawes@vodafone.com > =20 > www.betavine.net - Web > betavine.mobi - Mobile Web > =20 > Vodafone Group Services Limited=20 > Registered Office: Vodafone House, The Connection, Newbury, Berkshire > RG14 2FN Registered in England No 3802001 >=20 >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf Of Dale Worley > Sent: 24 June 2009 21:51 > To: SIPCORE > Subject: [sipcore] draft-kaplan-sip-session-id-02 >=20 > Looking at draft-kaplan-sip-session-id-02, the shorter the Session-Id > header is, the fewer complaints people will have about using it in > practice. A couple of things could be done to shorten it: >=20 > - assign a single-letter abbreviation for the name >=20 > - use base64 rather than hex encoding >=20 > Base64 encoding reduces the header value to 22 characters from 32. >=20 > Dale >=20 >=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 AUDET@nortel.com Mon Jul 13 09:10:32 2009 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 9EA803A6E08 for ; Mon, 13 Jul 2009 09:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.369 X-Spam-Level: X-Spam-Status: No, score=-6.369 tagged_above=-999 required=5 tests=[AWL=0.230, 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 q26nFYNCUnLL for ; Mon, 13 Jul 2009 09:10:31 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 5540C3A69BC for ; Mon, 13 Jul 2009 09:10:31 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6DG8bq27455; Mon, 13 Jul 2009 16:08:37 GMT 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, 13 Jul 2009 11:10:10 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EF517C8@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoDV+piBYxWhIWBTqmMTijJD4yWHAAB0oJgAB0atCA= References: <4A59B693.9010807@gmail.com> <4A5A8B7D.9060804@cisco.com> From: "Francois Audet" To: "Hadriel Kaplan" , "Paul Kyzivat" , "Hans Erik van Elburg" Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 13 Jul 2009 16:10:32 -0000 =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: Sunday, July 12, 2009 19:13 > To: Paul Kyzivat; Hans Erik van Elburg > Cc: SIPCORE > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >=20 >=20 >=20 > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Sunday, July 12, 2009 9:19 PM > >=20 > > I largely agree with Hans. > > For all intents and purposes, a URI is an AoR if the policy of the=20 > > domain of that URI says it is an AoR. >=20 > Yes, it's like porn vs. art: you know it when you see it. ;) This is a bad analogy. Only the proxy responsible for an AOR knows that it is an AOR. For = everybody else, it's just a URI. That's why in the procedures in the document, it's only that proxy that = can mark an entry as an AOR. It basically means "I own this address and will route it accordingly". = And then the next entry=20 can be a registered contact, or it can be mapped to another URI (for = example). From HKaplan@acmepacket.com Mon Jul 13 09:15:12 2009 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 532CA3A6EA7 for ; Mon, 13 Jul 2009 09:15:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.562 X-Spam-Level: X-Spam-Status: No, score=-2.562 tagged_above=-999 required=5 tests=[AWL=0.037, 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 hnoKiX53nbTQ for ; Mon, 13 Jul 2009 09:15:11 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 270083A6E87 for ; Mon, 13 Jul 2009 09:15:06 -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.1.375.2; Mon, 13 Jul 2009 12:15:35 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 13 Jul 2009 12:15:35 -0400 From: Hadriel Kaplan To: Francois Audet , SIPCORE Date: Mon, 13 Jul 2009 12:15:35 -0400 Thread-Topic: rfc4244bis: what is "aor" used for? Thread-Index: AcoCrazV4PjGDXJYQVyso2A4fcXevgAud/W9ABm4w4A= 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: [sipcore] rfc4244bis: what is "aor" used for? 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, 13 Jul 2009 16:15:12 -0000 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Sunday, July 12, 2009 11:11 PM >=20 > Let's backtrack a little bit. >=20 > It's not like you would just ignore the entries not marked with aor flag. > If > you are expecting a temp GRUU, then the aor flag is not terribly relevant= . Right, so what *is* relevant about an "aor" flag? What is it used/useful f= or? I *think* the purpose for it is to let a UAS find the request-URI that was = in the message before it got replaced by the registered contact URI. Is th= at right? In other words: along the lines of JDR's original ua-loose-route draft, whe= re the proposal was the req-URI not be changed by a registration resolution= process so that a UAS would get what the UAC sent - this 4244bis draft is = trying to provide that "original" req-URI by tagging it as "aor", and telli= ng the UAS to find the last instance of this flag. But that's not really the right thing to flag, because it's not the right t= hing for the UAS to look for, because: 1) The motivation of the ua-loose-route and target drafts was the UAS cares= about what the UAC *sent*, not what the last proxy saw before it was chang= ed. That may seem like the same thing, but it's not. If I send a request = to "sip:fluffy@cisco.com" and it gets resolved to another pseudonym AoR of = "cullen@cto-proxy.cisco.com" which then is resolved to the UAS contact, the= UAS needs to find "sip:fluffy@cisco.com" - not the last "aor" flag which w= ould be for "cullen@cto-proxy.cisco.com". 2) It is not actually "AoRs" that we care about finding. It's whatever the= request-URI was. It could have been a tel-URI, a GRUU, a service URN (e.g= ., sos), etc.=20 I *think* the URI that actually needs to be found is the last one with an "= mp" param. (or the first one if none have an mp param) In other words, get= the req-URI that the UAC or last retargeter sent. =20 There's still a very difficult problem of how one decides if an "mp" mapped= flag URI was actually a real re-target forwarding event vs. a pseudonym re= solution, but that's a problem any mechanism would have. (And only the UAS = would actually know if the target identity changed or not, afaict) -hadriel From HKaplan@acmepacket.com Mon Jul 13 09:24:33 2009 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 4C7233A6EBB for ; Mon, 13 Jul 2009 09:24:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.564 X-Spam-Level: X-Spam-Status: No, score=-2.564 tagged_above=-999 required=5 tests=[AWL=0.035, 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 EBHuim0NB8Mv for ; Mon, 13 Jul 2009 09:24:32 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 8E0173A6E6B for ; Mon, 13 Jul 2009 09:23:43 -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.1.375.2; Mon, 13 Jul 2009 12:24:06 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 13 Jul 2009 12:24:06 -0400 From: Hadriel Kaplan To: Francois Audet , Paul Kyzivat , "Hans Erik van Elburg" Date: Mon, 13 Jul 2009 12:24:05 -0400 Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoDV+piBYxWhIWBTqmMTijJD4yWHAAB0oJgAB0atCAAAGtdAA== Message-ID: References: <4A59B693.9010807@gmail.com> <4A5A8B7D.9060804@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EF517C8@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EF517C8@zrc2hxm0.corp.nortel.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 Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 13 Jul 2009 16:24:33 -0000 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, July 13, 2009 12:10 PM >=20 > > > > > > I largely agree with Hans. > > > For all intents and purposes, a URI is an AoR if the policy of the > > > domain of that URI says it is an AoR. > > > > Yes, it's like porn vs. art: you know it when you see it. ;) >=20 > This is a bad analogy. > Only the proxy responsible for an AOR knows that it is an AOR. For > everybody else, it's > just a URI. > That's why in the procedures in the document, it's only that proxy that > can mark an > entry as an AOR. > It basically means "I own this address and will route it accordingly". An= d > then the next entry > can be a registered contact, or it can be mapped to another URI (for > example). You're right - to make it analogous, it's like porn vs. art, but only art-c= ritics can say which one it is. In other words, the problem isn't that we= can't find someone to tell us what *they* think it is, the problem is two = such experts (proxies) will not agree. In this thread there have already been 5 people with 6 different opinions o= f what is and is not an "AoR". That's not a good sign. If I build a UAS, do I have to guess which vendor made my domain's authorit= ative proxy, so I can know what types of HI URI's it will and will not flag= as "aor"? -hadriel From AUDET@nortel.com Mon Jul 13 09:28:22 2009 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 43C863A6938 for ; Mon, 13 Jul 2009 09:28:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.373 X-Spam-Level: X-Spam-Status: No, score=-6.373 tagged_above=-999 required=5 tests=[AWL=0.226, 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 vVl4BpOvMtD0 for ; Mon, 13 Jul 2009 09:28:17 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 70FC028C499 for ; Mon, 13 Jul 2009 09:28:15 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6DGSgI22435; Mon, 13 Jul 2009 16:28:42 GMT 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, 13 Jul 2009 11:28:40 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EF51852@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rfc4244bis: what is "aor" used for? thread-index: AcoCrazV4PjGDXJYQVyso2A4fcXevgAud/W9ABm4w4AAAecgIA== References: From: "Francois Audet" To: "Hadriel Kaplan" , "SIPCORE" Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 13 Jul 2009 16:28:22 -0000 Hi Hadriel, The purpose of the AOR flag is to indicate that a location service can say "I found it!" with regards to a Request-URI. If you don't have a flag like this, you end-up with many redundant entries for the same user, and it makes it difficult to distinguish logical retargets. I don't believe the main use case is for the target-URI, because, it's really the last entry before the registered/configured contact that is important, regardless of the flag. It's more for the classical redirections cases that it's useful. And it is more obviously useful when there is "strict routing", it=20 which case there are a bunch of entries that have nothing to do with=20 the actual target. > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Monday, July 13, 2009 09:16 > To: Audet, Francois (SC100:3055); SIPCORE > Subject: rfc4244bis: what is "aor" used for? >=20 >=20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Sunday, July 12, 2009 11:11 PM > >=20 > > Let's backtrack a little bit. > >=20 > > It's not like you would just ignore the entries not marked=20 > with aor flag. > > If > > you are expecting a temp GRUU, then the aor flag is not=20 > terribly relevant. >=20 > Right, so what *is* relevant about an "aor" flag? What is it=20 > used/useful for? >=20 > I *think* the purpose for it is to let a UAS find the=20 > request-URI that was in the message before it got replaced by=20 > the registered contact URI. Is that right? >=20 > In other words: along the lines of JDR's original=20 > ua-loose-route draft, where the proposal was the req-URI not=20 > be changed by a registration resolution process so that a UAS=20 > would get what the UAC sent - this 4244bis draft is trying to=20 > provide that "original" req-URI by tagging it as "aor", and=20 > telling the UAS to find the last instance of this flag. >=20 > But that's not really the right thing to flag, because it's=20 > not the right thing for the UAS to look for, because: >=20 > 1) The motivation of the ua-loose-route and target drafts was=20 > the UAS cares about what the UAC *sent*, not what the last=20 > proxy saw before it was changed. That may seem like the same=20 > thing, but it's not. If I send a request to=20 > "sip:fluffy@cisco.com" and it gets resolved to another=20 > pseudonym AoR of "cullen@cto-proxy.cisco.com" which then is=20 > resolved to the UAS contact, the UAS needs to find=20 > "sip:fluffy@cisco.com" - not the last "aor" flag which would=20 > be for "cullen@cto-proxy.cisco.com". >=20 > 2) It is not actually "AoRs" that we care about finding. =20 > It's whatever the request-URI was. It could have been a=20 > tel-URI, a GRUU, a service URN (e.g., sos), etc.=20 >=20 > I *think* the URI that actually needs to be found is the last=20 > one with an "mp" param. (or the first one if none have an mp=20 > param) In other words, get the req-URI that the UAC or last=20 > retargeter sent. =20 >=20 > There's still a very difficult problem of how one decides if=20 > an "mp" mapped flag URI was actually a real re-target=20 > forwarding event vs. a pseudonym resolution, but that's a=20 > problem any mechanism would have. (And only the UAS would=20 > actually know if the target identity changed or not, afaict) >=20 > -hadriel >=20 From AUDET@nortel.com Mon Jul 13 09:35:32 2009 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 B65AD28C339 for ; Mon, 13 Jul 2009 09:35:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.377 X-Spam-Level: X-Spam-Status: No, score=-6.377 tagged_above=-999 required=5 tests=[AWL=0.222, 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 lMNKKaRzDhtG for ; Mon, 13 Jul 2009 09:35:31 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 1C4373A6E91 for ; Mon, 13 Jul 2009 09:34:38 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6DGYhI23605; Mon, 13 Jul 2009 16:34:43 GMT 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, 13 Jul 2009 11:34:41 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EF5187B@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoDV+piBYxWhIWBTqmMTijJD4yWHAAB0oJgAB0atCAAAGtdAAAAn1zQ References: <4A59B693.9010807@gmail.com> <4A5A8B7D.9060804@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EF517C8@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Hadriel Kaplan" , "Paul Kyzivat" , "Hans Erik van Elburg" Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 13 Jul 2009 16:35:32 -0000 Actually, it would be the content producers, not the art critics...=20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Monday, July 13, 2009 09:24 > To: Audet, Francois (SC100:3055); Paul Kyzivat; Hans Erik van Elburg > Cc: SIPCORE > Subject: RE: [sipcore] rfc4244bis: what is an AoR? >=20 >=20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Monday, July 13, 2009 12:10 PM > >=20 > > > > > > > > I largely agree with Hans. > > > > For all intents and purposes, a URI is an AoR if the=20 > policy of the=20 > > > > domain of that URI says it is an AoR. > > > > > > Yes, it's like porn vs. art: you know it when you see it. ;) > >=20 > > This is a bad analogy. > > Only the proxy responsible for an AOR knows that it is an AOR. For=20 > > everybody else, it's just a URI. > > That's why in the procedures in the document, it's only that proxy=20 > > that can mark an entry as an AOR. > > It basically means "I own this address and will route it=20 > accordingly".=20 > > And then the next entry can be a registered contact, or it can be=20 > > mapped to another URI (for example). >=20 > You're right - to make it analogous, it's like porn vs. art,=20 > but only art-critics can say which one it is. In other=20 > words, the problem isn't that we can't find someone to tell=20 > us what *they* think it is, the problem is two such experts=20 > (proxies) will not agree. >=20 > In this thread there have already been 5 people with 6=20 > different opinions of what is and is not an "AoR". That's=20 > not a good sign. >=20 > If I build a UAS, do I have to guess which vendor made my=20 > domain's authoritative proxy, so I can know what types of HI=20 > URI's it will and will not flag as "aor"? >=20 > -hadriel >=20 From AUDET@nortel.com Mon Jul 13 09:56:17 2009 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 CC3D228C19B for ; Mon, 13 Jul 2009 09:56:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.381 X-Spam-Level: X-Spam-Status: No, score=-6.381 tagged_above=-999 required=5 tests=[AWL=0.218, 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 Sdc6qqrx9iDh for ; Mon, 13 Jul 2009 09:56:17 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 8B32A28C4B5 for ; Mon, 13 Jul 2009 09:55:58 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6DGsiq05471; Mon, 13 Jul 2009 16:54:44 GMT 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, 13 Jul 2009 11:56:12 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EF5190A@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoC2Qnd4dNUCUvLRh2JQGrETeGzGAAHyVKQAByC5JcAACkJQAAb56sw References: From: "Francois Audet" To: "Hadriel Kaplan" , "Hans Erik van Elburg" Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 13 Jul 2009 16:56:17 -0000 To me it's crystal clear. If you are the entity (proxy or redirect server) responsible for=20 the URI, and you find the entry in your location service, you mark as AOR. That means you will now route based on "rules" you have internally, e.g., map it to a contact, etc. If you are a proxy not responsible with this address, you will just forward it unaltered (if you are using loose routing), or you will route it but replace the R-URI with an upstream proxy (if you use strict routing). > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Sunday, July 12, 2009 20:41 > To: Audet, Francois (SC100:3055); Hans Erik van Elburg > Cc: SIPCORE > Subject: RE: [sipcore] rfc4244bis: what is an AoR? >=20 >=20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Sunday, July 12, 2009 11:30 PM > >=20 > > Dude, are you arguing there is no such thing as an AOR? > >=20 > > What's your point? > =20 > My point is that if we need a Proxy to set an "aor" param=20 > (though I'm not sure what value there is in setting one),=20 > then there needs to be a defined mechanism for how it decides=20 > to do so. Otherwise a domain's Proxy from vendor X will=20 > decide foo is an aor, and vendor Y's will decide foo is not=20 > one - and a UAS will not act the same way for foo. >=20 > In other words, I need some programmatic way for my system to=20 > set a param when it should, and not when it should not; so=20 > that my TAC does not get support calls complaining it should=20 > have done it when it didn't, or didn't do it when it should have. No? >=20 > -hadriel >=20 From ietf.hanserik@gmail.com Mon Jul 13 10:06:43 2009 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 E879528C508 for ; Mon, 13 Jul 2009 10:06:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.438 X-Spam-Level: X-Spam-Status: No, score=-2.438 tagged_above=-999 required=5 tests=[AWL=0.160, 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 zJBTiLaqwvHR for ; Mon, 13 Jul 2009 10:06:42 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 3049928C589 for ; Mon, 13 Jul 2009 10:06:13 -0700 (PDT) Received: by ewy26 with SMTP id 26so2683616ewy.37 for ; Mon, 13 Jul 2009 10:06:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=D5znwa48FBLO7kNgw/+j84grbDvdpdWrlpt/qStbRYQ=; b=O7mNk2/gZo/EFYX4ZXzc99PVRG33zZ9A2u9xV/n/F7AT7jbTrGI9vNneOdi36bge6u QkUOod50TT7Qvlhj+toiyfIDJQdebbN5fi8Iiklm72jn7P/XcCcp/7lTS4uy85AjmEZ9 tfHzr584GhWhcE7GDsrUJZah0SoaZYORCt94s= 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=JfHVZdtS6RbK9uMEckDCdHi3hPEVznFLO31dVX+j69gk/rI8zYWKiEXypsN3I4iVQL URaU5Y4NUGbypiPp63O6ygQq4Sx4+rU6FbJ7ulBvQqt7sSzVfQPQ34SRv8cdkdlO+nbK yx7IzAdTk7Bmh8FRbf6IBFpM8k2BFXUTo7iVA= MIME-Version: 1.0 Received: by 10.210.70.14 with SMTP id s14mr1252400eba.67.1247504800439; Mon, 13 Jul 2009 10:06:40 -0700 (PDT) In-Reply-To: References: <9ae56b1e0907130111p68efe801mf83f9eb8fba4a50f@mail.gmail.com> Date: Mon, 13 Jul 2009 19:06:40 +0200 Message-ID: <9ae56b1e0907131006ybeee49dj23b7995fe411d9c4@mail.gmail.com> From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=0015174c3d107c5d8d046e99581f Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 13 Jul 2009 17:06:44 -0000 --0015174c3d107c5d8d046e99581f Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Inline.. /Hans Erik van Elburg On Mon, Jul 13, 2009 at 5:25 PM, Hadriel Kaplan wro= te: > > > Sure if you think the set of URI=92s which have registered or configured > contacts are the whole set of AoR=92s, such that URI=92s which have other= AoR=92s > as their resolution are not AoR=92s and there are no URI=92s which have > registered or configured contacts which are not AoR=92s. > > But I don=92t think that=92s true. > > > > For example, =93sip:hadriel.kaplan@acmepacket.com=94 > may resolve to =93sip:hkaplan@acmepacket.com =94 > which then resolves to a registered contact =96 both of those are AoR=92s= , but > only the second will pass your test. > Both will pass "my" test. The proxy that consults the location service will tag teh 1st with AOR, the ("next" which might be the same) proxy that performs the lookup for the 2nd will tag that one as AOR. I did not intend to restrict the location-service-lookup to only return contacts. > But =93tel:+17813284428=94 will resolve to =93sip:hkaplan@acmepacket.com<= sip%3Ahkaplan@acmepacket.com>=94 > as well, but the tel-URI is not an AoR. > As far a I know the terminating home proxy will not receive a tel:, but a SIP URI if the originating proxy could not transform the TEL URL to a SIP URI it would have to break out to PSTN. I might be wrong. I agree that a TE= L URL is not an AOR. > And for example when a Service Provider=92s proxy receives =93 > sip:+17813284428@sp.com ;user=3Dphone=94, th= e > location service could return a configured next-hop URI of =93 > sip:+17813284428@pstn-gw1.sp.com = =94 > (through an ENUM lookup, for example), to route it to the PSTN. Now it > turns out that configured next-hop is an AoR, and it=92s not really even > configured for that AoR =96 it=92s a default route for all +1781 area cod= es. > How does the proxy know (1) that it=92s a configured next-hop contact an= d not > a configured next-hop AoR, (2) that =93sip:+17813284428@sp.com;user=3Dphone=94 > was NOT in fact an AoR. > Its not an AOR your breaking out for a reason. > -hadriel > > > ------------------------------ > > *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > *Sent:* Monday, July 13, 2009 4:11 AM > *To:* Hadriel Kaplan > *Subject:* Re: [sipcore] rfc4244bis: what is an AoR? > > > > Thats an easy one, if a proxy has arrived in section 16.5/RFC3261 to the > conclusion that: > "If the target set for the request has not been predetermined as > > described above, this implies that the element is responsible for the > domain in the Request-URI, and the element MAY use whatever mechanism > it desires to determine where to send the request. Any of these > > mechanisms can be modeled as accessing an abstract Location Service." > > If the location service returns registered or configured contacts, then i= t > can safely conclude that the Request-URI of the incoming request is an AO= R. > > > > No rocket science. > > > > /Hans Erik van Elburg > > On Mon, Jul 13, 2009 at 5:41 AM, Hadriel Kaplan > wrote: > > > > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Sunday, July 12, 2009 11:30 PM > > > > Dude, are you arguing there is no such thing as an AOR? > > > > What's your point? > > My point is that if we need a Proxy to set an "aor" param (though I'm not > sure what value there is in setting one), then there needs to be a define= d > mechanism for how it decides to do so. Otherwise a domain's Proxy from > vendor X will decide foo is an aor, and vendor Y's will decide foo is not > one - and a UAS will not act the same way for foo. > > In other words, I need some programmatic way for my system to set a param > when it should, and not when it should not; so that my TAC does not get > support calls complaining it should have done it when it didn't, or didn'= t > do it when it should have. No? > > -hadriel > > > --0015174c3d107c5d8d046e99581f Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Inline..

/Hans Erik van Elburg

On Mon, Jul 13, 2009 at 5:25 PM, Hadriel Kap= lan <HKaplan@acmepacket.com> wrote:

=A0

Sure if you think the set of URI= =92s which have registered or configured contacts are the whole set of AoR=92s, such that URI=92s which have other AoR=92s as their resolution are not AoR=92s and there are no URI=92s which have registered or configured contacts which are not AoR=92s.

But I don=92t think that=92s true.= =A0

=A0

For example, =93sip:hadriel.kaplan@a= cmepacket.com=94 may resolve to =93sip:hkaplan@acmepacket.com=94 which then resolves to a registered contact =96 both of those are AoR=92s, but only the second will pass your test.

Both wi= ll pass "my" test. The proxy that consults the location service w= ill tag teh 1st with AOR, the ("next" which might be the same) pr= oxy that performs the lookup for the 2nd will tag that one as AOR. I did no= t intend to restrict the location-service-lookup to only return contacts. =A0

But =93tel:+17813284428=94 will resolve to =93sip:hkaplan@acmepacket.com=94 as well, but the tel-URI is not an AoR.

As far a I know = the terminating home proxy will not receive a tel:, but a SIP URI if the or= iginating proxy could not transform the TEL URL to a SIP URI it would have = to break out to PSTN. I might be wrong. I agree that a TEL URL is not an AO= R.
=A0

And for example when a Service Pro= vider=92s proxy receives =93sip:+17813284428@sp.com;user=3Dphone=94, the location service could return a configured next-hop URI of =93sip:+17813284428@pstn-g= w1.sp.com=94 (through an ENUM lookup, for example), to route it to the PSTN. =A0Now it turns out that configured next-hop is an AoR, and it=92s not really even configured for that AoR =96 it=92s a default route for all +1781 area codes. =A0How does the proxy know (1) that it=92s a configured next-hop con= tact and not a configured next-hop AoR, (2) that =93sip:+17813284428@sp.com;user=3Dpho= ne=94 was NOT in fact an AoR.

Its = not an AOR your breaking out for a reason.
=A0

-hadriel

=A0

From: Ha= ns Erik van Elburg [mailto:ietf.hanserik@gmail.com]
Sent: Monday, July 13, 200= 9 4:11 AM
To: Hadriel Kaplan
Subject: Re: [sipcore] rfc= 4244bis: what is an AoR?

=A0

Thats an easy one, if a proxy has arrived in section 16.5/RFC3261 to the conclusion that:
"If the target set for the request has not been predetermined as

described above, this implies that the element is responsible for the
domain in the Request-URI, and the element MAY use whatever mechanism
it desires to determine where to send the request. Any of these

mechanisms can be modeled as accessing an abstract Location Service."<= /span>

If the location service returns registered or configured contacts, then it can safely conclude that the Request-URI of the incoming request is an A= OR.

=A0

No rocket science.

=A0

/Hans Erik van Elburg

On Mon, Jul 13, 2009 at 5:41 AM, Hadriel Kaplan <HKaplan@acmepacket.com> wrot= e:



> -----Original Message-----
> From: Francois Audet [mailto:audet@nortel.com]
> Sent: Sunday, July 12, 2009 11:30 PM
>
> Dude, are you arguing there is no such thing as an AOR?
>
> What's your point?

My point is that if we need a Proxy to set an "aor" param (though I'm not sure what value there is in setting one), then there ne= eds to be a defined mechanism for how it decides to do so. =A0Otherwise a domain&#= 39;s Proxy from vendor X will decide foo is an aor, and vendor Y's will deci= de foo is not one - and a UAS will not act the same way for foo.

In other words, I need some programmatic way for my system to set a param w= hen it should, and not when it should not; so that my TAC does not get support calls complaining it should have done it when it didn't, or didn't = do it when it should have. =A0No?

-hadriel

=A0


--0015174c3d107c5d8d046e99581f-- From jmpolk@cisco.com Mon Jul 13 10:37:28 2009 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 3B98328C45A for ; Mon, 13 Jul 2009 10:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.327 X-Spam-Level: X-Spam-Status: No, score=-6.327 tagged_above=-999 required=5 tests=[AWL=0.272, 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 CDzKbSekbTH0 for ; Mon, 13 Jul 2009 10:37:26 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0EF4128C61E for ; Mon, 13 Jul 2009 10:36:19 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgGAKANW0qrR7MV/2dsb2JhbACIPrBDiCOOZgWECQ X-IronPort-AV: E=Sophos;i="4.42,391,1243814400"; d="scan'208";a="213275303" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 13 Jul 2009 17:36:49 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6DHanoj018743; Mon, 13 Jul 2009 10:36:49 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6DHanwV023800; Mon, 13 Jul 2009 17:36:49 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jul 2009 10:36:49 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.11.205]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jul 2009 10:36:49 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Jul 2009 12:36:44 -0500 To: "Elwell, John" , sipcore@ietf.org From: "James M. Polk" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00221DC12@GBNTHT12009MSX.gb 002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D00218C372@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00221DBF8@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00221DC12@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 13 Jul 2009 17:36:49.0237 (UTC) FILETIME=[803AB850:01CA03E0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9234; t=1247506609; x=1248370609; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20Use=20of=20term=20=22Location=20Server= 22=20in=20location-conveyance=20draft |Sender:=20; bh=0V7a+Ch2xMYmPloxbRaCuHYLdO+xmmkVysddBOVCOH4=; b=sMqsddkKbzDf+C/g0mNatfDVZsbdYyhGBn3UfqLaDURzw8RY2apwpkghGL RIDFnAQ3mr8GOgExbNxZ7RU+O103o8C5Y3dq03TtwsCNdmT9bK/NXx51Xkmp BK9nhrQsNeRDu3rKGV9ZIeH6Wzn+/fUIzGRfwnrQtnidVOI1kpVnU=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "marc Linsner \(mlinsner\)" Subject: Re: [sipcore] Use of term "Location Server" in location-conveyance draft 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, 13 Jul 2009 17:37:28 -0000 At 02:15 AM 7/13/2009, Elwell, John wrote: >James, > >It occurs to me we already have the term location inserter used in >various places in the document, so why don't we stick to this, rather >than location server, for the UA or proxy that inserts? Then we could >use the term location server for the server you go to to dereference >LbyR. I thought about that - but the Geopriv Arch -00 ID just came out and the 6 authors there decided the LS is the location inserter in their terminology and the LIS is the dereferencer *but* only if a target wants to dereference their own location. If another entity wants to dereference your location, it is not a LIS, it's just an LS. I believe this is even more confusing. BTW - the LIS is who provides a target its DHCP or LLDP-MED or HELD location information too. Meaning, the LIS has to be able to do L2 downloads of LI *and* L7 subscriptions. >I agree with others, by the way, that LIS is not an appropriate term for >the latter. see above, it now *IS* the proper term for the latter, but only if it is the target that's doing it. Talk about shifting roles... >John > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: 13 July 2009 07:56 > > To: Elwell, John; sipcore@ietf.org > > Cc: marc Linsner (mlinsner) > > Subject: RE: Use of term "Location Server" in > > location-conveyance draft > > > > John > > > > in-line > > > > At 01:20 AM 7/13/2009, Elwell, John wrote: > > >James, > > > > > >I have to say this is mighty confusing. Basically > > location-conveyance is > > >an extension to SIP, and therefore its primary purpose is to > > specify the > > >SIP protocol and the behaviour of the various SIP entities > > involved. To > > >have an important term that sometimes can mean a SIP entity (the SIP > > >entity that inserts the Geolocation header field) and sometimes > > >something quite unrelated to SIP location conveyance (the entity to > > >which the dereferencing request is sent) strikes me as something we > > >should avoid. > > > > welcome to my world... ugh > > > > >In my opinion we should do one of the following: > > > > > >1. Limit LS to having only one of these meanings, and if necessary > > >introduce a new term for the other case. > > > > I thought we had a server entity term defined that was just for > > dereferences, called a Location Information Server (LIS), but > > apparently that term was taken (hijacked?) just for Location > > Configuration Protocols (LCPs) like DHCP and especially HELD. See > > Martin's recent message clarifying this to me. It was news too. I > > say especially HELD because it appears that crew actually did the > > "taking" deed. > > > > It appears to me that Location Servers that are essentially peers > > that communicate location values or references in the signaling path > > of the original SIP request is a good delineation. > > > > Then, having another term defining what entity the location URIs > > point at (i.e., the dereferencing function) should NOT be called the > > same thing, this is what I was calling a LIS (Location Information > > Server), which had a unique function, storing all the PIDF-LOs for > > the location targets (prior to any dereferencing). > > > > > If this is not possible because > > >it would conflict with other published documents, then do it locally > > >within sip-location-conveyance using appropriate language ("For the > > >purposes of this document, location server means....") > > > > interesting... that would mean I (or a small group) would be defining > > a small parallel set of terms that do not go anywhere else except in > > the case of Conveyance... > > > > Can I recommend you send this suggestion (with the WHY!) to Keith > > Drage? He's the doc shepherd for this ID. That will probably go the > > farthest. CCing the chairs would always be a good idea. > > > > I hope to have the final version ready for WGLC before the milestone > > date of Sept 09. > > > > This will take a little thought once it's solved for, but it's pretty > > much a global replace function once we come up with a set of > > terms to use. > > > > -01 of conveyance will be out tomorrow, and Spencer Dawkins did a > > pretty good job at making it easier to read. He didn't address the > > term confusion though. > > > > This term issue aside, I was hoping this -01 version was the version > > that went to WGLC. > > > > > > >2. Avoid the term LS altogether in this document and define new terms > > >for the various different purposes. > > > > yeah -- that would be what I'd have to do -- if the chairs and the > > shepherd agree to this. We all can talk live about this in Stockholm > > hopefully. > > > > BTW - if it's not clear yet within this message -- I'm not opposed to > > doing this (because of the confusion associated with this topic). > > > > James > > > > > > >John > > > > > > > > > > -----Original Message----- > > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > > Sent: 13 July 2009 05:40 > > > > To: Elwell, John; Martin.Thomson@andrew.com; sipcore@ietf.org > > > > Subject: Re: Use of term "Location Server" in > > > > location-conveyance draft > > > > > > > > john > > > > > > > > Sorry I missed this note earlier... see below > > > > > > > > At 01:37 AM 7/3/2009, Elwell, John wrote: > > > > >The separate thread arising from my review of the draft has > > > > left me very > > > > >confused about what exactly the term "Location Server" > > means in this > > > > >draft. > > > > > > > > > >The draft itself says: > > > > >" A [RFC3693] defined "Using > > > > > Protocol" describes how a "Location Server" > > transmits a "Location > > > > > Object" to a "Location Recipient" while maintaining > > the contained > > > > > privacy intentions of the Target intact. This document > > > > describes the > > > > > extension to SIP for how it complies with the Using Protocol > > > > > requirements, where the location server is a UA or Proxy > > > > Server and > > > > > the Location Recipient is another UA or Proxy Server." > > > > >My review comments that touched on this subject assumed the above > > > > >definition. > > > > >According to this, the server that the Location > > Recipient goes to to > > > > >dereference the LbyR URI is NOT a Location Server. But > > some of the > > > > >thread messages have suggested it IS a Location Server. > > We cannot use > > > > >the term Location Server to mean two different things. > > Can somebody > > > > >please clarify? > > > > > > > > In Geopriv, a Location Server (LS) is an entity that transmits > > > > location towards a Location Recipient (LR). This > > transmission might > > > > take that message through another LS before getting to the LR. > > > > > > > > In SIP terms, a UA or SIP server (of whatever flavor) that inserts > > > > location into a message (as a message body or as a dereferencable > > > > location URI) is an LS. > > > > > > > > A B2BUA that completes a call leg that contains location, and > > > > regenerates a new SIP request towards another B2BUA or > > UAS with that > > > > location in the new SIP request is also an LS. > > > > > > > > A proxy that inserts a dereferencable location URI is an LS. > > > > > > > > A proxy that does not insert a dereferencable location > > URI is NOT an > > > > LS (this time). It is basically performing a repeater > > function that > > > > is not defined in Geopriv. > > > > > > > > A UAS that understands location (i.e., something close to the > > > > Location Conveyance extension) is an LR. A UAS that receives > > > > location - but does not understand Location Conveyance - > > is not an LR > > > > (because it doesn't do anything with the location except > > > > throw it away). > > > > > > > > A SIP server that retargets a SIP request after viewing > > the contained > > > > location in that SIP request is also an LR, and because it did > > > > something with the location - I think it can be called an > > LS too (but > > > > some might disagree). > > > > > > > > A good example of this last case is a location source > > based routing > > > > proxy that retargets a R-URI based on the contained > > location within a > > > > SIP request, like say - an INVITE to 911. > > > > > > > > In this case, that proxy is an LR and an LS. The UAC is > > a Location > > > > Generator (LG) and an LS; and the PSAP call center (i.e., > > the UAS for > > > > the call) is an LS. > > > > > > > > Confused? > > > > > > > > :-p > > > > > > > > Geopriv elements change roles based on what they do, or can do. > > > > > > > > The only debatable label here is LG, as the label seems to have > > > > changed since RFC 3693 (Geopriv Requirements) which I > > co-authored - > > > > and the new doc describing the new functions isn't an RFC > > yet, and is > > > > shifting positions with a couple of its definitions lately (i.e., > > > > within the last year). > > > > > > > > James > > > > > > > > > > > > > > > > >John > > > > > > > > > > > > From dean.willis@softarmor.com Mon Jul 13 10:41:26 2009 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 6556528C5C2 for ; Mon, 13 Jul 2009 10:41:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.558 X-Spam-Level: X-Spam-Status: No, score=-2.558 tagged_above=-999 required=5 tests=[AWL=0.041, 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 jvHy-YueXBgB for ; Mon, 13 Jul 2009 10:41:25 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 8242328C627 for ; Mon, 13 Jul 2009 10:40:15 -0700 (PDT) Received: from [192.168.2.2] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6DHegku000924 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 13 Jul 2009 12:40:44 -0500 Message-ID: <4A5B7195.6020009@softarmor.com> Date: Mon, 13 Jul 2009 12:40:37 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Hadriel Kaplan References: In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 13 Jul 2009 17:41:26 -0000 Hadriel Kaplan wrote: > 1) The motivation of the ua-loose-route and target drafts was the UAS > cares about what the UAC *sent*, not what the last proxy saw before > it was changed. That may seem like the same thing, but it's not. If > I send a request to "sip:fluffy@cisco.com" and it gets resolved to > another pseudonym AoR of "cullen@cto-proxy.cisco.com" which then is > resolved to the UAS contact, the UAS needs to find > "sip:fluffy@cisco.com" - not the last "aor" flag which would be for > "cullen@cto-proxy.cisco.com". The real problem is even messier: The goal is to find that which was sent by the UAC as modified by intermediaries that claim to be authoritative in doing so. For example, I might have a speed-dial service implemented in a proxy. My UAS sends "sip:6@service.example.com", which is then translated by my proxy to be "sip:voicemailretrieval@example.com;user=dwillis". Another proxy might do contact routing, translating "sip:voicemailretrieval@example.com;user=dwillis" into "sip:192.168.2.23" The voicemail server then needs to find the intermediate translation. In this case, this just happens to be the parameterized AOR of the voicemail server, but it certainly doesn't have to be. It could also be considered as the last mapping operation prior to contact routing, but again, it doesn't have to be; we can add anotehr layer that makes it the next-to-last mapping. > 2) It is not actually "AoRs" that we care about finding. It's > whatever the request-URI was. It could have been a tel-URI, a GRUU, > a service URN (e.g., sos), etc. > > I *think* the URI that actually needs to be found is the last one > with an "mp" param. (or the first one if none have an mp param) In > other words, get the req-URI that the UAC or last retargeter sent. > > There's still a very difficult problem of how one decides if an "mp" > mapped flag URI was actually a real re-target forwarding event vs. a > pseudonym resolution, but that's a problem any mechanism would have. > (And only the UAS would actually know if the target identity changed > or not, afaict) I believe the whole problem is much more readily solved by something closer to Christer's approach: Put the target URI and parameters into a separate header field that is NOT used for routing. This header field might be manipulated by a middlebox (such as my speed-dial service), but at least it doesn't get accidentally twiddled by a routing operation. Solving this problem with H-I seems to me to be gross overkill and an unnecessary exercise in pointless complexity. But that's what we do best around here. -- Dean From pkyzivat@cisco.com Mon Jul 13 10:41:29 2009 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 61FBB28C31D for ; Mon, 13 Jul 2009 10:41:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.587 X-Spam-Level: X-Spam-Status: No, score=-6.587 tagged_above=-999 required=5 tests=[AWL=0.012, 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 FM084N2vWUuT for ; Mon, 13 Jul 2009 10:41:28 -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 E6F7528C590 for ; Mon, 13 Jul 2009 10:40:36 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEABMOW0pAZnmf/2dsb2JhbAC4e4gjjmYFhAk X-IronPort-AV: E=Sophos;i="4.42,391,1243814400"; d="scan'208";a="50212366" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 13 Jul 2009 17:41:07 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6DHf6fJ024785; Mon, 13 Jul 2009 13:41:06 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6DHf0vM021260; Mon, 13 Jul 2009 17:41:06 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jul 2009 13:41:01 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jul 2009 13:41:00 -0400 Message-ID: <4A5B71AC.6050502@cisco.com> Date: Mon, 13 Jul 2009 13:41:00 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Francois Audet References: <1ECE0EB50388174790F9694F77522CCF1EF5190A@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EF5190A@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 13 Jul 2009 17:41:00.0349 (UTC) FILETIME=[15E75ED0:01CA03E1] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2923; t=1247506866; x=1248370866; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20rfc4244bis=3A=20what=20is=2 0an=20AoR? |Sender:=20 |To:=20Francois=20Audet=20; bh=non+3dwZlThN0hWXrFGf+kxpuzE3cvw2m6eweBBHffY=; b=MBAmZjrxgoYPkx8EhvkqLGqKb37pHD1mXWcvDRJQlurp1iyvzYTOiwHK4i X5xUPHXr1y6Tk9XtAaFQuuAi2ICvhKcIEIopz96iOhmb+hbWyKl6NCRta0Qu UBAMQNIlE0; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 13 Jul 2009 17:41:29 -0000 Francois Audet wrote: > To me it's crystal clear. > > If you are the entity (proxy or redirect server) responsible for > the URI, and you find the entry in your location service, you mark > as AOR. > > That means you will now route based on "rules" you have internally, > e.g., map it to a contact, etc. I think some cases are clear, others not so much: - If the proxy translates to a contact that it got from a location service and that entry was placed there by a REGISTER, then the entry should definitely be marked as an AoR - If the proxy translates to a contact that it got from a ocation service, and that entry got there somehow other than REGISTER, then I *think* the entry should still be marked as an AoR. - If the proxy uses some other logic than a "location service" to translate the URI, but it might in other cases use the location service to translate the URI, then I'm not sure. - If the proxy never uses a location service for this URI, but translates it on some other basis, then again I'm not sure. One problem here is that the location service is abstract. There are things that can be done using it, or in another manner. It seems to me that if it *could* have been done with a location service lookup, then the result ought to be the same whether it is or not. Thanks, Paul > If you are a proxy not responsible with this address, you will just > forward it unaltered (if you are using loose routing), or you will > route it but replace the R-URI with an upstream proxy (if you use > strict routing). > >> -----Original Message----- >> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] >> Sent: Sunday, July 12, 2009 20:41 >> To: Audet, Francois (SC100:3055); Hans Erik van Elburg >> Cc: SIPCORE >> Subject: RE: [sipcore] rfc4244bis: what is an AoR? >> >> >> >>> -----Original Message----- >>> From: Francois Audet [mailto:audet@nortel.com] >>> Sent: Sunday, July 12, 2009 11:30 PM >>> >>> Dude, are you arguing there is no such thing as an AOR? >>> >>> What's your point? >> >> My point is that if we need a Proxy to set an "aor" param >> (though I'm not sure what value there is in setting one), >> then there needs to be a defined mechanism for how it decides >> to do so. Otherwise a domain's Proxy from vendor X will >> decide foo is an aor, and vendor Y's will decide foo is not >> one - and a UAS will not act the same way for foo. >> >> In other words, I need some programmatic way for my system to >> set a param when it should, and not when it should not; so >> that my TAC does not get support calls complaining it should >> have done it when it didn't, or didn't do it when it should have. No? >> >> -hadriel >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From AUDET@nortel.com Mon Jul 13 10:46:59 2009 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 A6A5028C507 for ; Mon, 13 Jul 2009 10:46:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.385 X-Spam-Level: X-Spam-Status: No, score=-6.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 bP8Kmw+6Lzk1 for ; Mon, 13 Jul 2009 10:46:59 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 72BB928C5B3 for ; Mon, 13 Jul 2009 10:44:45 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6DHhUq14111; Mon, 13 Jul 2009 17:43:30 GMT 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, 13 Jul 2009 12:45:06 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A5B7195.6020009@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is "aor" used for? thread-index: AcoD4Q+X+9yYmWHBRpucnNEuJOKPGQAAHXqg References: <4A5B7195.6020009@softarmor.com> From: "Francois Audet" To: "Dean Willis" , "Hadriel Kaplan" Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 13 Jul 2009 17:46:59 -0000 =20 > Solving this problem with H-I seems to me to be gross=20 > overkill and an unnecessary exercise in pointless complexity.=20 > But that's what we do best around here. I don't see how this is overkill. We have History-info anyways. Using the 2 header approaches means, well, that we'll have 2 headers = doing the same thing, potentially conflicting with each other. From AUDET@nortel.com Mon Jul 13 11:41:11 2009 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 657DA3A6EAA for ; Mon, 13 Jul 2009 11:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.389 X-Spam-Level: X-Spam-Status: No, score=-6.389 tagged_above=-999 required=5 tests=[AWL=0.210, 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 pCYhTegI2ujz for ; Mon, 13 Jul 2009 11:41:10 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 74D2D28C46E for ; Mon, 13 Jul 2009 11:40:15 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6DIeZI23095; Mon, 13 Jul 2009 18:40:36 GMT 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, 13 Jul 2009 13:39:35 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EF51BFE@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A5B71AC.6050502@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoD4SnwU7KlZPKIRQWb/ghRjXvaBQAB4cCw References: <1ECE0EB50388174790F9694F77522CCF1EF5190A@zrc2hxm0.corp.nortel.com> <4A5B71AC.6050502@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 13 Jul 2009 18:41:11 -0000 =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Monday, July 13, 2009 10:41 > To: Audet, Francois (SC100:3055) > Cc: Hadriel Kaplan; Hans Erik van Elburg; SIPCORE > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >=20 >=20 >=20 > Francois Audet wrote: > > To me it's crystal clear. > >=20 > > If you are the entity (proxy or redirect server)=20 > responsible for the=20 > > URI, and you find the entry in your location service, you=20 > mark as AOR. > >=20 > > That means you will now route based on "rules" you have internally,=20 > > e.g., map it to a contact, etc. >=20 > I think some cases are clear, others not so much: >=20 > - If the proxy translates to a contact that it got from a > location service and that entry was placed there by a REGISTER, > then the entry should definitely be marked as an AoR Agree. > - If the proxy translates to a contact that it got from a > ocation service, and that entry got there somehow other=20 > than REGISTER, > then I *think* the entry should still be marked as an AoR. Yes, agree. > - If the proxy uses some other logic than a "location service" > to translate the URI, but it might in other cases use the > location service to translate the URI, then I'm not sure. > > - If the proxy never uses a location service for this URI, > but translates it on some other basis, then again I'm not sure. >=20 > One problem here is that the location service is abstract.=20 > There are things that can be done using it, or in another=20 > manner. It seems to me that if it *could* have been done with=20 > a location service lookup, then the result ought to be the=20 > same whether it is or not. I think the last two are the same thing. Things like digit manipulation and so forth. I didn't want to alter (or second-guess) the definition of AOR (which is = the realm of RFC 3261), in this draft. I would think that if the proxy doesn't know that it's an AOR, then it = shouldn't mark it as such. So I would expect mechanical digit manipulation to NOT be = marked as AOR. From jmpolk@cisco.com Mon Jul 13 11:51:50 2009 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 5D5A23A69E9 for ; Mon, 13 Jul 2009 11:51:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.331 X-Spam-Level: X-Spam-Status: No, score=-6.331 tagged_above=-999 required=5 tests=[AWL=0.268, 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 NrhpF40N+SHn for ; Mon, 13 Jul 2009 11:51:48 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id D3A6E3A67AD for ; Mon, 13 Jul 2009 11:51:48 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgGAKcfW0qrR7PD/2dsb2JhbACIPrA2iCOOcgWECQ X-IronPort-AV: E=Sophos;i="4.42,392,1243814400"; d="scan'208";a="176510641" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-3.cisco.com with ESMTP; 13 Jul 2009 18:52:19 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6DIqJSD010872; Mon, 13 Jul 2009 11:52:19 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6DIqJqo010757; Mon, 13 Jul 2009 18:52:19 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jul 2009 11:52:19 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.11.205]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jul 2009 11:52:18 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Jul 2009 13:52:14 -0500 To: "Elwell, John" , sipcore@ietf.org From: "James M. Polk" In-Reply-To: <7.1.0.9.2.20090713123111.03a51228@cisco.com> References: <0D5F89FAC29E2C41B98A6A762007F5D00218C372@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00221DBF8@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00221DC12@GBNTHT12009MSX.gb002.siemens.net> <7.1.0.9.2.20090713123111.03a51228@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 13 Jul 2009 18:52:18.0663 (UTC) FILETIME=[0BFA4770:01CA03EB] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10423; t=1247511139; x=1248375139; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20Use=20of=20term=20=22Location=20Server= 22=20in=20location-conveyance=20draft |Sender:=20; bh=4FLMXK77c6J5bS/2qN4iFCGeW1D8OXsQo0qFnDDs0/4=; b=VuUYTDy71RWfbNfjrMT4MpgNwLHTK5fB0OpglGModQm3fkgIf1H+DfOtDI 6tA/YpmyRN2XqzWBZ6yezlEi1UXfAHEOojODF723WDGN1mcH3+F8o/aTQPsy NC1L3PPj6+; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: "marc Linsner \(mlinsner\)" Subject: Re: [sipcore] Use of term "Location Server" in location-conveyance draft 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, 13 Jul 2009 18:51:50 -0000 John How about using the terms - Location Inserter (just how it is defined in the doc now) and - Dereference Server (DS) (instead of Location Server) for the server that UAs subscribe to (using the location URI), to attain a Target's geolocation in a PIDF-LO format. there can't be an acronym for the inserter, because LI means Location Information, and that ought to stay unconfused by this doc. But DS could be the acronym for Dereference Server - and *not* have a limit on who can dereference from it (a target itself or a 3rd party). These would become SIP terms, just as Target in Geopriv is a Presentity in Presence terms. Let me know what you (and others) think about this. This can't make it into the -01 version (which I'm about to submit) since there is no WG consensus on the matter, but that can be achieved fairly quickly though if we try. James At 12:36 PM 7/13/2009, James M. Polk wrote: >At 02:15 AM 7/13/2009, Elwell, John wrote: >>James, >> >>It occurs to me we already have the term location inserter used in >>various places in the document, so why don't we stick to this, rather >>than location server, for the UA or proxy that inserts? Then we could >>use the term location server for the server you go to to dereference >>LbyR. > >I thought about that - but the Geopriv Arch -00 ID just came out and >the 6 authors there decided the LS is the location inserter in their >terminology and the LIS is the dereferencer *but* only if a target >wants to dereference their own location. If another entity wants to >dereference your location, it is not a LIS, it's just an LS. > >I believe this is even more confusing. > >BTW - the LIS is who provides a target its DHCP or LLDP-MED or HELD >location information too. Meaning, the LIS has to be able to do L2 >downloads of LI *and* L7 subscriptions. > > >>I agree with others, by the way, that LIS is not an appropriate term for >>the latter. > >see above, it now *IS* the proper term for the latter, but only if >it is the target that's doing it. > >Talk about shifting roles... > > >>John >> >> > -----Original Message----- >> > From: James M. Polk [mailto:jmpolk@cisco.com] >> > Sent: 13 July 2009 07:56 >> > To: Elwell, John; sipcore@ietf.org >> > Cc: marc Linsner (mlinsner) >> > Subject: RE: Use of term "Location Server" in >> > location-conveyance draft >> > >> > John >> > >> > in-line >> > >> > At 01:20 AM 7/13/2009, Elwell, John wrote: >> > >James, >> > > >> > >I have to say this is mighty confusing. Basically >> > location-conveyance is >> > >an extension to SIP, and therefore its primary purpose is to >> > specify the >> > >SIP protocol and the behaviour of the various SIP entities >> > involved. To >> > >have an important term that sometimes can mean a SIP entity (the SIP >> > >entity that inserts the Geolocation header field) and sometimes >> > >something quite unrelated to SIP location conveyance (the entity to >> > >which the dereferencing request is sent) strikes me as something we >> > >should avoid. >> > >> > welcome to my world... ugh >> > >> > >In my opinion we should do one of the following: >> > > >> > >1. Limit LS to having only one of these meanings, and if necessary >> > >introduce a new term for the other case. >> > >> > I thought we had a server entity term defined that was just for >> > dereferences, called a Location Information Server (LIS), but >> > apparently that term was taken (hijacked?) just for Location >> > Configuration Protocols (LCPs) like DHCP and especially HELD. See >> > Martin's recent message clarifying this to me. It was news too. I >> > say especially HELD because it appears that crew actually did the >> > "taking" deed. >> > >> > It appears to me that Location Servers that are essentially peers >> > that communicate location values or references in the signaling path >> > of the original SIP request is a good delineation. >> > >> > Then, having another term defining what entity the location URIs >> > point at (i.e., the dereferencing function) should NOT be called the >> > same thing, this is what I was calling a LIS (Location Information >> > Server), which had a unique function, storing all the PIDF-LOs for >> > the location targets (prior to any dereferencing). >> > >> > > If this is not possible because >> > >it would conflict with other published documents, then do it locally >> > >within sip-location-conveyance using appropriate language ("For the >> > >purposes of this document, location server means....") >> > >> > interesting... that would mean I (or a small group) would be defining >> > a small parallel set of terms that do not go anywhere else except in >> > the case of Conveyance... >> > >> > Can I recommend you send this suggestion (with the WHY!) to Keith >> > Drage? He's the doc shepherd for this ID. That will probably go the >> > farthest. CCing the chairs would always be a good idea. >> > >> > I hope to have the final version ready for WGLC before the milestone >> > date of Sept 09. >> > >> > This will take a little thought once it's solved for, but it's pretty >> > much a global replace function once we come up with a set of >> > terms to use. >> > >> > -01 of conveyance will be out tomorrow, and Spencer Dawkins did a >> > pretty good job at making it easier to read. He didn't address the >> > term confusion though. >> > >> > This term issue aside, I was hoping this -01 version was the version >> > that went to WGLC. >> > >> > >> > >2. Avoid the term LS altogether in this document and define new terms >> > >for the various different purposes. >> > >> > yeah -- that would be what I'd have to do -- if the chairs and the >> > shepherd agree to this. We all can talk live about this in Stockholm >> > hopefully. >> > >> > BTW - if it's not clear yet within this message -- I'm not opposed to >> > doing this (because of the confusion associated with this topic). >> > >> > James >> > >> > >> > >John >> > > >> > > >> > > > -----Original Message----- >> > > > From: James M. Polk [mailto:jmpolk@cisco.com] >> > > > Sent: 13 July 2009 05:40 >> > > > To: Elwell, John; Martin.Thomson@andrew.com; sipcore@ietf.org >> > > > Subject: Re: Use of term "Location Server" in >> > > > location-conveyance draft >> > > > >> > > > john >> > > > >> > > > Sorry I missed this note earlier... see below >> > > > >> > > > At 01:37 AM 7/3/2009, Elwell, John wrote: >> > > > >The separate thread arising from my review of the draft has >> > > > left me very >> > > > >confused about what exactly the term "Location Server" >> > means in this >> > > > >draft. >> > > > > >> > > > >The draft itself says: >> > > > >" A [RFC3693] defined "Using >> > > > > Protocol" describes how a "Location Server" >> > transmits a "Location >> > > > > Object" to a "Location Recipient" while maintaining >> > the contained >> > > > > privacy intentions of the Target intact. This document >> > > > describes the >> > > > > extension to SIP for how it complies with the Using Protocol >> > > > > requirements, where the location server is a UA or Proxy >> > > > Server and >> > > > > the Location Recipient is another UA or Proxy Server." >> > > > >My review comments that touched on this subject assumed the above >> > > > >definition. >> > > > >According to this, the server that the Location >> > Recipient goes to to >> > > > >dereference the LbyR URI is NOT a Location Server. But >> > some of the >> > > > >thread messages have suggested it IS a Location Server. >> > We cannot use >> > > > >the term Location Server to mean two different things. >> > Can somebody >> > > > >please clarify? >> > > > >> > > > In Geopriv, a Location Server (LS) is an entity that transmits >> > > > location towards a Location Recipient (LR). This >> > transmission might >> > > > take that message through another LS before getting to the LR. >> > > > >> > > > In SIP terms, a UA or SIP server (of whatever flavor) that inserts >> > > > location into a message (as a message body or as a dereferencable >> > > > location URI) is an LS. >> > > > >> > > > A B2BUA that completes a call leg that contains location, and >> > > > regenerates a new SIP request towards another B2BUA or >> > UAS with that >> > > > location in the new SIP request is also an LS. >> > > > >> > > > A proxy that inserts a dereferencable location URI is an LS. >> > > > >> > > > A proxy that does not insert a dereferencable location >> > URI is NOT an >> > > > LS (this time). It is basically performing a repeater >> > function that >> > > > is not defined in Geopriv. >> > > > >> > > > A UAS that understands location (i.e., something close to the >> > > > Location Conveyance extension) is an LR. A UAS that receives >> > > > location - but does not understand Location Conveyance - >> > is not an LR >> > > > (because it doesn't do anything with the location except >> > > > throw it away). >> > > > >> > > > A SIP server that retargets a SIP request after viewing >> > the contained >> > > > location in that SIP request is also an LR, and because it did >> > > > something with the location - I think it can be called an >> > LS too (but >> > > > some might disagree). >> > > > >> > > > A good example of this last case is a location source >> > based routing >> > > > proxy that retargets a R-URI based on the contained >> > location within a >> > > > SIP request, like say - an INVITE to 911. >> > > > >> > > > In this case, that proxy is an LR and an LS. The UAC is >> > a Location >> > > > Generator (LG) and an LS; and the PSAP call center (i.e., >> > the UAS for >> > > > the call) is an LS. >> > > > >> > > > Confused? >> > > > >> > > > :-p >> > > > >> > > > Geopriv elements change roles based on what they do, or can do. >> > > > >> > > > The only debatable label here is LG, as the label seems to have >> > > > changed since RFC 3693 (Geopriv Requirements) which I >> > co-authored - >> > > > and the new doc describing the new functions isn't an RFC >> > yet, and is >> > > > shifting positions with a couple of its definitions lately (i.e., >> > > > within the last year). >> > > > >> > > > James >> > > > >> > > > >> > > > >> > > > >John >> > > > >> > > > >> > >> > From john.elwell@siemens-enterprise.com Mon Jul 13 13:21:31 2009 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 ED17E28C681 for ; Mon, 13 Jul 2009 13:21:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 kBjGleeWEZrt for ; Mon, 13 Jul 2009 13:21:30 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 9C4B228C68B for ; Mon, 13 Jul 2009 13:19:18 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KMQ00J7TLSO11@siemenscomms.co.uk> for sipcore@ietf.org; Mon, 13 Jul 2009 21:19:36 +0100 (BST) Date: Mon, 13 Jul 2009 21:19:34 +0100 From: "Elwell, John" In-reply-to: To: "James M. Polk" , sipcore@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00221E0FD@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Use of term "Location Server" in location-conveyance draft Thread-Index: AcoD4IQAYITpLL8gSBqVCzs0uqyBBgAFlOJw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D00218C372@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00221DBF8@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00221DC12@GBNTHT12009MSX.gb002.siemens.net> Cc: "marc Linsner \(mlinsner\)" Subject: Re: [sipcore] Use of term "Location Server" in location-conveyance draft 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, 13 Jul 2009 20:21:32 -0000 =20 > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com]=20 > Sent: 13 July 2009 18:37 > To: Elwell, John; sipcore@ietf.org > Cc: marc Linsner (mlinsner) > Subject: RE: Use of term "Location Server" in=20 > location-conveyance draft >=20 > At 02:15 AM 7/13/2009, Elwell, John wrote: > >James, > > > >It occurs to me we already have the term location inserter used in > >various places in the document, so why don't we stick to this, rather > >than location server, for the UA or proxy that inserts? Then we could > >use the term location server for the server you go to to dereference > >LbyR. >=20 > I thought about that - but the Geopriv Arch -00 ID just came out and=20 > the 6 authors there decided the LS is the location inserter in their=20 > terminology and the LIS is the dereferencer *but* only if a target=20 > wants to dereference their own location. If another entity wants to=20 > dereference your location, it is not a LIS, it's just an LS. [JRE] That has always been my understanding. >=20 > I believe this is even more confusing. >=20 > BTW - the LIS is who provides a target its DHCP or LLDP-MED or HELD=20 > location information too. Meaning, the LIS has to be able to do L2=20 > downloads of LI *and* L7 subscriptions. >=20 >=20 > >I agree with others, by the way, that LIS is not an=20 > appropriate term for > >the latter. >=20 > see above, it now *IS* the proper term for the latter, but only if it=20 > is the target that's doing it. [JRE] But in the context of sip-location-conveyance, the UAS or a proxy that receives the location will NEVER be the target, so it will NEVER be a LIS when dereferencing occurs. John >=20 > Talk about shifting roles... >=20 >=20 > >John > > > > > -----Original Message----- > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > Sent: 13 July 2009 07:56 > > > To: Elwell, John; sipcore@ietf.org > > > Cc: marc Linsner (mlinsner) > > > Subject: RE: Use of term "Location Server" in > > > location-conveyance draft > > > > > > John > > > > > > in-line > > > > > > At 01:20 AM 7/13/2009, Elwell, John wrote: > > > >James, > > > > > > > >I have to say this is mighty confusing. Basically > > > location-conveyance is > > > >an extension to SIP, and therefore its primary purpose is to > > > specify the > > > >SIP protocol and the behaviour of the various SIP entities > > > involved. To > > > >have an important term that sometimes can mean a SIP=20 > entity (the SIP > > > >entity that inserts the Geolocation header field) and sometimes > > > >something quite unrelated to SIP location conveyance=20 > (the entity to > > > >which the dereferencing request is sent) strikes me as=20 > something we > > > >should avoid. > > > > > > welcome to my world... ugh > > > > > > >In my opinion we should do one of the following: > > > > > > > >1. Limit LS to having only one of these meanings, and if=20 > necessary > > > >introduce a new term for the other case. > > > > > > I thought we had a server entity term defined that was just for > > > dereferences, called a Location Information Server (LIS), but > > > apparently that term was taken (hijacked?) just for Location > > > Configuration Protocols (LCPs) like DHCP and especially HELD. See > > > Martin's recent message clarifying this to me. It was=20 > news too. I > > > say especially HELD because it appears that crew actually did the > > > "taking" deed. > > > > > > It appears to me that Location Servers that are essentially peers > > > that communicate location values or references in the=20 > signaling path > > > of the original SIP request is a good delineation. > > > > > > Then, having another term defining what entity the location URIs > > > point at (i.e., the dereferencing function) should NOT be=20 > called the > > > same thing, this is what I was calling a LIS (Location Information > > > Server), which had a unique function, storing all the PIDF-LOs for > > > the location targets (prior to any dereferencing). > > > > > > > If this is not possible because > > > >it would conflict with other published documents, then=20 > do it locally > > > >within sip-location-conveyance using appropriate=20 > language ("For the > > > >purposes of this document, location server means....") > > > > > > interesting... that would mean I (or a small group) would=20 > be defining > > > a small parallel set of terms that do not go anywhere=20 > else except in > > > the case of Conveyance... > > > > > > Can I recommend you send this suggestion (with the WHY!) to Keith > > > Drage? He's the doc shepherd for this ID. That will=20 > probably go the > > > farthest. CCing the chairs would always be a good idea. > > > > > > I hope to have the final version ready for WGLC before=20 > the milestone > > > date of Sept 09. > > > > > > This will take a little thought once it's solved for, but=20 > it's pretty > > > much a global replace function once we come up with a set of > > > terms to use. > > > > > > -01 of conveyance will be out tomorrow, and Spencer Dawkins did a > > > pretty good job at making it easier to read. He didn't=20 > address the > > > term confusion though. > > > > > > This term issue aside, I was hoping this -01 version was=20 > the version > > > that went to WGLC. > > > > > > > > > >2. Avoid the term LS altogether in this document and=20 > define new terms > > > >for the various different purposes. > > > > > > yeah -- that would be what I'd have to do -- if the chairs and the > > > shepherd agree to this. We all can talk live about this=20 > in Stockholm > > > hopefully. > > > > > > BTW - if it's not clear yet within this message -- I'm=20 > not opposed to > > > doing this (because of the confusion associated with this topic). > > > > > > James > > > > > > > > > >John > > > > > > > > > > > > > -----Original Message----- > > > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > > > Sent: 13 July 2009 05:40 > > > > > To: Elwell, John; Martin.Thomson@andrew.com; sipcore@ietf.org > > > > > Subject: Re: Use of term "Location Server" in > > > > > location-conveyance draft > > > > > > > > > > john > > > > > > > > > > Sorry I missed this note earlier... see below > > > > > > > > > > At 01:37 AM 7/3/2009, Elwell, John wrote: > > > > > >The separate thread arising from my review of the draft has > > > > > left me very > > > > > >confused about what exactly the term "Location Server" > > > means in this > > > > > >draft. > > > > > > > > > > > >The draft itself says: > > > > > >" A [RFC3693] defined "Using > > > > > > Protocol" describes how a "Location Server" > > > transmits a "Location > > > > > > Object" to a "Location Recipient" while maintaining > > > the contained > > > > > > privacy intentions of the Target intact. This document > > > > > describes the > > > > > > extension to SIP for how it complies with the=20 > Using Protocol > > > > > > requirements, where the location server is a UA or Proxy > > > > > Server and > > > > > > the Location Recipient is another UA or Proxy Server." > > > > > >My review comments that touched on this subject=20 > assumed the above > > > > > >definition. > > > > > >According to this, the server that the Location > > > Recipient goes to to > > > > > >dereference the LbyR URI is NOT a Location Server. But > > > some of the > > > > > >thread messages have suggested it IS a Location Server. > > > We cannot use > > > > > >the term Location Server to mean two different things. > > > Can somebody > > > > > >please clarify? > > > > > > > > > > In Geopriv, a Location Server (LS) is an entity that transmits > > > > > location towards a Location Recipient (LR). This > > > transmission might > > > > > take that message through another LS before getting to the LR. > > > > > > > > > > In SIP terms, a UA or SIP server (of whatever flavor)=20 > that inserts > > > > > location into a message (as a message body or as a=20 > dereferencable > > > > > location URI) is an LS. > > > > > > > > > > A B2BUA that completes a call leg that contains location, and > > > > > regenerates a new SIP request towards another B2BUA or > > > UAS with that > > > > > location in the new SIP request is also an LS. > > > > > > > > > > A proxy that inserts a dereferencable location URI is an LS. > > > > > > > > > > A proxy that does not insert a dereferencable location > > > URI is NOT an > > > > > LS (this time). It is basically performing a repeater > > > function that > > > > > is not defined in Geopriv. > > > > > > > > > > A UAS that understands location (i.e., something close to the > > > > > Location Conveyance extension) is an LR. A UAS that receives > > > > > location - but does not understand Location Conveyance - > > > is not an LR > > > > > (because it doesn't do anything with the location except > > > > > throw it away). > > > > > > > > > > A SIP server that retargets a SIP request after viewing > > > the contained > > > > > location in that SIP request is also an LR, and because it did > > > > > something with the location - I think it can be called an > > > LS too (but > > > > > some might disagree). > > > > > > > > > > A good example of this last case is a location source > > > based routing > > > > > proxy that retargets a R-URI based on the contained > > > location within a > > > > > SIP request, like say - an INVITE to 911. > > > > > > > > > > In this case, that proxy is an LR and an LS. The UAC is > > > a Location > > > > > Generator (LG) and an LS; and the PSAP call center (i.e., > > > the UAS for > > > > > the call) is an LS. > > > > > > > > > > Confused? > > > > > > > > > > :-p > > > > > > > > > > Geopriv elements change roles based on what they do,=20 > or can do. > > > > > > > > > > The only debatable label here is LG, as the label=20 > seems to have > > > > > changed since RFC 3693 (Geopriv Requirements) which I > > > co-authored - > > > > > and the new doc describing the new functions isn't an RFC > > > yet, and is > > > > > shifting positions with a couple of its definitions=20 > lately (i.e., > > > > > within the last year). > > > > > > > > > > James > > > > > > > > > > > > > > > > > > > > >John > > > > > > > > > > > > > > > > >=20 >=20 From john.elwell@siemens-enterprise.com Mon Jul 13 13:21:34 2009 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 DE5763A67F3 for ; Mon, 13 Jul 2009 13:21:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 WLWL8Kmm9njs for ; Mon, 13 Jul 2009 13:21:33 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 2450028C6A4 for ; Mon, 13 Jul 2009 13:19:46 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KMQ00J8NLTM11@siemenscomms.co.uk> for sipcore@ietf.org; Mon, 13 Jul 2009 21:20:10 +0100 (BST) Date: Mon, 13 Jul 2009 21:20:08 +0100 From: "Elwell, John" In-reply-to: To: "James M. Polk" , sipcore@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00221E0FE@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Use of term "Location Server" in location-conveyance draft Thread-Index: AcoD6w9BTsJWQhBDSc2CUbG+E4sevQADBl1Q Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D00218C372@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00221DBF8@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00221DC12@GBNTHT12009MSX.gb002.siemens.net> <7.1.0.9.2.20090713123111.03a51228@cisco.com> Cc: "marc Linsner \(mlinsner\)" Subject: Re: [sipcore] Use of term "Location Server" in location-conveyance draft 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, 13 Jul 2009 20:21:35 -0000 That would work. John=20 > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com]=20 > Sent: 13 July 2009 19:52 > To: Elwell, John; sipcore@ietf.org > Cc: marc Linsner (mlinsner) > Subject: RE: Use of term "Location Server" in=20 > location-conveyance draft >=20 > John >=20 > How about using the terms >=20 > - Location Inserter (just how it is defined in the doc now) > and > - Dereference Server (DS) (instead of Location Server) for the server=20 > that UAs subscribe to (using the location URI), to attain a Target's=20 > geolocation in a PIDF-LO format. >=20 > there can't be an acronym for the inserter, because LI means Location=20 > Information, and that ought to stay unconfused by this doc. >=20 > But DS could be the acronym for Dereference Server - and *not* have a=20 > limit on who can dereference from it (a target itself or a 3rd party). >=20 > These would become SIP terms, just as Target in Geopriv is a=20 > Presentity in Presence terms. >=20 > Let me know what you (and others) think about this. >=20 > This can't make it into the -01 version (which I'm about to submit)=20 > since there is no WG consensus on the matter, but that can be=20 > achieved fairly quickly though if we try. >=20 > James >=20 > At 12:36 PM 7/13/2009, James M. Polk wrote: > >At 02:15 AM 7/13/2009, Elwell, John wrote: > >>James, > >> > >>It occurs to me we already have the term location inserter used in > >>various places in the document, so why don't we stick to=20 > this, rather > >>than location server, for the UA or proxy that inserts?=20 > Then we could > >>use the term location server for the server you go to to dereference > >>LbyR. > > > >I thought about that - but the Geopriv Arch -00 ID just came out and=20 > >the 6 authors there decided the LS is the location inserter in their=20 > >terminology and the LIS is the dereferencer *but* only if a target=20 > >wants to dereference their own location. If another entity wants to=20 > >dereference your location, it is not a LIS, it's just an LS. > > > >I believe this is even more confusing. > > > >BTW - the LIS is who provides a target its DHCP or LLDP-MED or HELD=20 > >location information too. Meaning, the LIS has to be able to do L2=20 > >downloads of LI *and* L7 subscriptions. > > > > > >>I agree with others, by the way, that LIS is not an=20 > appropriate term for > >>the latter. > > > >see above, it now *IS* the proper term for the latter, but only if=20 > >it is the target that's doing it. > > > >Talk about shifting roles... > > > > > >>John > >> > >> > -----Original Message----- > >> > From: James M. Polk [mailto:jmpolk@cisco.com] > >> > Sent: 13 July 2009 07:56 > >> > To: Elwell, John; sipcore@ietf.org > >> > Cc: marc Linsner (mlinsner) > >> > Subject: RE: Use of term "Location Server" in > >> > location-conveyance draft > >> > > >> > John > >> > > >> > in-line > >> > > >> > At 01:20 AM 7/13/2009, Elwell, John wrote: > >> > >James, > >> > > > >> > >I have to say this is mighty confusing. Basically > >> > location-conveyance is > >> > >an extension to SIP, and therefore its primary purpose is to > >> > specify the > >> > >SIP protocol and the behaviour of the various SIP entities > >> > involved. To > >> > >have an important term that sometimes can mean a SIP=20 > entity (the SIP > >> > >entity that inserts the Geolocation header field) and sometimes > >> > >something quite unrelated to SIP location conveyance=20 > (the entity to > >> > >which the dereferencing request is sent) strikes me as=20 > something we > >> > >should avoid. > >> > > >> > welcome to my world... ugh > >> > > >> > >In my opinion we should do one of the following: > >> > > > >> > >1. Limit LS to having only one of these meanings, and=20 > if necessary > >> > >introduce a new term for the other case. > >> > > >> > I thought we had a server entity term defined that was just for > >> > dereferences, called a Location Information Server (LIS), but > >> > apparently that term was taken (hijacked?) just for Location > >> > Configuration Protocols (LCPs) like DHCP and especially HELD. See > >> > Martin's recent message clarifying this to me. It was=20 > news too. I > >> > say especially HELD because it appears that crew actually did the > >> > "taking" deed. > >> > > >> > It appears to me that Location Servers that are essentially peers > >> > that communicate location values or references in the=20 > signaling path > >> > of the original SIP request is a good delineation. > >> > > >> > Then, having another term defining what entity the location URIs > >> > point at (i.e., the dereferencing function) should NOT=20 > be called the > >> > same thing, this is what I was calling a LIS (Location=20 > Information > >> > Server), which had a unique function, storing all the=20 > PIDF-LOs for > >> > the location targets (prior to any dereferencing). > >> > > >> > > If this is not possible because > >> > >it would conflict with other published documents, then=20 > do it locally > >> > >within sip-location-conveyance using appropriate=20 > language ("For the > >> > >purposes of this document, location server means....") > >> > > >> > interesting... that would mean I (or a small group)=20 > would be defining > >> > a small parallel set of terms that do not go anywhere=20 > else except in > >> > the case of Conveyance... > >> > > >> > Can I recommend you send this suggestion (with the WHY!) to Keith > >> > Drage? He's the doc shepherd for this ID. That will=20 > probably go the > >> > farthest. CCing the chairs would always be a good idea. > >> > > >> > I hope to have the final version ready for WGLC before=20 > the milestone > >> > date of Sept 09. > >> > > >> > This will take a little thought once it's solved for,=20 > but it's pretty > >> > much a global replace function once we come up with a set of > >> > terms to use. > >> > > >> > -01 of conveyance will be out tomorrow, and Spencer Dawkins did a > >> > pretty good job at making it easier to read. He didn't=20 > address the > >> > term confusion though. > >> > > >> > This term issue aside, I was hoping this -01 version was=20 > the version > >> > that went to WGLC. > >> > > >> > > >> > >2. Avoid the term LS altogether in this document and=20 > define new terms > >> > >for the various different purposes. > >> > > >> > yeah -- that would be what I'd have to do -- if the=20 > chairs and the > >> > shepherd agree to this. We all can talk live about this=20 > in Stockholm > >> > hopefully. > >> > > >> > BTW - if it's not clear yet within this message -- I'm=20 > not opposed to > >> > doing this (because of the confusion associated with this topic). > >> > > >> > James > >> > > >> > > >> > >John > >> > > > >> > > > >> > > > -----Original Message----- > >> > > > From: James M. Polk [mailto:jmpolk@cisco.com] > >> > > > Sent: 13 July 2009 05:40 > >> > > > To: Elwell, John; Martin.Thomson@andrew.com; sipcore@ietf.org > >> > > > Subject: Re: Use of term "Location Server" in > >> > > > location-conveyance draft > >> > > > > >> > > > john > >> > > > > >> > > > Sorry I missed this note earlier... see below > >> > > > > >> > > > At 01:37 AM 7/3/2009, Elwell, John wrote: > >> > > > >The separate thread arising from my review of the draft has > >> > > > left me very > >> > > > >confused about what exactly the term "Location Server" > >> > means in this > >> > > > >draft. > >> > > > > > >> > > > >The draft itself says: > >> > > > >" A [RFC3693] defined "Using > >> > > > > Protocol" describes how a "Location Server" > >> > transmits a "Location > >> > > > > Object" to a "Location Recipient" while maintaining > >> > the contained > >> > > > > privacy intentions of the Target intact. This document > >> > > > describes the > >> > > > > extension to SIP for how it complies with the=20 > Using Protocol > >> > > > > requirements, where the location server is a UA or Proxy > >> > > > Server and > >> > > > > the Location Recipient is another UA or Proxy Server." > >> > > > >My review comments that touched on this subject=20 > assumed the above > >> > > > >definition. > >> > > > >According to this, the server that the Location > >> > Recipient goes to to > >> > > > >dereference the LbyR URI is NOT a Location Server. But > >> > some of the > >> > > > >thread messages have suggested it IS a Location Server. > >> > We cannot use > >> > > > >the term Location Server to mean two different things. > >> > Can somebody > >> > > > >please clarify? > >> > > > > >> > > > In Geopriv, a Location Server (LS) is an entity that=20 > transmits > >> > > > location towards a Location Recipient (LR). This > >> > transmission might > >> > > > take that message through another LS before getting=20 > to the LR. > >> > > > > >> > > > In SIP terms, a UA or SIP server (of whatever=20 > flavor) that inserts > >> > > > location into a message (as a message body or as a=20 > dereferencable > >> > > > location URI) is an LS. > >> > > > > >> > > > A B2BUA that completes a call leg that contains location, and > >> > > > regenerates a new SIP request towards another B2BUA or > >> > UAS with that > >> > > > location in the new SIP request is also an LS. > >> > > > > >> > > > A proxy that inserts a dereferencable location URI is an LS. > >> > > > > >> > > > A proxy that does not insert a dereferencable location > >> > URI is NOT an > >> > > > LS (this time). It is basically performing a repeater > >> > function that > >> > > > is not defined in Geopriv. > >> > > > > >> > > > A UAS that understands location (i.e., something close to the > >> > > > Location Conveyance extension) is an LR. A UAS that receives > >> > > > location - but does not understand Location Conveyance - > >> > is not an LR > >> > > > (because it doesn't do anything with the location except > >> > > > throw it away). > >> > > > > >> > > > A SIP server that retargets a SIP request after viewing > >> > the contained > >> > > > location in that SIP request is also an LR, and=20 > because it did > >> > > > something with the location - I think it can be called an > >> > LS too (but > >> > > > some might disagree). > >> > > > > >> > > > A good example of this last case is a location source > >> > based routing > >> > > > proxy that retargets a R-URI based on the contained > >> > location within a > >> > > > SIP request, like say - an INVITE to 911. > >> > > > > >> > > > In this case, that proxy is an LR and an LS. The UAC is > >> > a Location > >> > > > Generator (LG) and an LS; and the PSAP call center (i.e., > >> > the UAS for > >> > > > the call) is an LS. > >> > > > > >> > > > Confused? > >> > > > > >> > > > :-p > >> > > > > >> > > > Geopriv elements change roles based on what they do,=20 > or can do. > >> > > > > >> > > > The only debatable label here is LG, as the label=20 > seems to have > >> > > > changed since RFC 3693 (Geopriv Requirements) which I > >> > co-authored - > >> > > > and the new doc describing the new functions isn't an RFC > >> > yet, and is > >> > > > shifting positions with a couple of its definitions=20 > lately (i.e., > >> > > > within the last year). > >> > > > > >> > > > James > >> > > > > >> > > > > >> > > > > >> > > > >John > >> > > > > >> > > > > >> > > >> > >=20 >=20 From HKaplan@acmepacket.com Mon Jul 13 13:51:31 2009 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 02A8F28C6C8 for ; Mon, 13 Jul 2009 13:51:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.034, 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 8IlLC7YeYLEh for ; Mon, 13 Jul 2009 13:51:30 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 7665428C332 for ; Mon, 13 Jul 2009 13:49:21 -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.1.375.2; Mon, 13 Jul 2009 16:49:49 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 13 Jul 2009 16:49:49 -0400 From: Hadriel Kaplan To: Francois Audet , SIPCORE Date: Mon, 13 Jul 2009 16:49:48 -0400 Thread-Topic: rfc4244bis: what is "aor" used for? Thread-Index: AcoCrazV4PjGDXJYQVyso2A4fcXevgAud/W9ABm4w4AAAecgIAACT+Bw Message-ID: References: <1ECE0EB50388174790F9694F77522CCF1EF51852@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EF51852@zrc2hxm0.corp.nortel.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] rfc4244bis: what is "aor" used for? 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, 13 Jul 2009 20:51:31 -0000 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, July 13, 2009 12:29 PM >=20 > The purpose of the AOR flag is to indicate that a location > service can say "I found it!" with regards to a Request-URI. >=20 > If you don't have a flag like this, you end-up with many redundant > entries for the same user, and it makes it difficult to distinguish > logical retargets. >=20 > I don't believe the main use case is for the target-URI, because, > it's really the last entry before the registered/configured contact that > is important, regardless of the flag. >=20 > It's more for the classical redirections cases that it's useful. Oooohhhh. Wow, that's not what I read it as - in the draft it says: ...the [aor] parameter indicates that the specific hi-targeted-to-uri that was retargeted was an AOR and thus the previous information in the request-URI may be "lost". Upon receipt of a request or response containing the History-Info header, a UA can determine a "lost" target AOR for a request by traversing the HI entries in reverse order to find the first one tagged with a specific hi-aor parameter. > And it is more obviously useful when there is "strict routing", it > which case there are a bunch of entries that have nothing to do with > the actual target. I thought that in the chain of emails back in June, the claim was there wou= ld be no strict routing mixed with HI, because any proxy/uas supporting HI = must be 3261-compliant to begin with, not 2543. (I could remember that thre= ad incorrectly though) But anyway I don't think it's necessary or sufficient for even that purpose= . I'm thinking that the "mp" param is actually sufficient to cull that lis= t down to what's important. I just can't tell yet if I'm right or wrong ab= out that. -hadriel From HKaplan@acmepacket.com Mon Jul 13 13:58:00 2009 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 722B628C581 for ; Mon, 13 Jul 2009 13:58:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, 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 QpGr677r1Pz9 for ; Mon, 13 Jul 2009 13:57:59 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 8ADE928C3C1 for ; Mon, 13 Jul 2009 13:57:59 -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.1.375.2; Mon, 13 Jul 2009 16:58:28 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 13 Jul 2009 16:58:27 -0400 From: Hadriel Kaplan To: Dean Willis Date: Mon, 13 Jul 2009 16:58:25 -0400 Thread-Topic: [sipcore] rfc4244bis: what is "aor" used for? Thread-Index: AcoD4RmgYPToplphTNGZX+nUfMAJ3gAGmHWg Message-ID: References: <4A5B7195.6020009@softarmor.com> In-Reply-To: <4A5B7195.6020009@softarmor.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 Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 13 Jul 2009 20:58:00 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Monday, July 13, 2009 1:41 PM >=20 > Hadriel Kaplan wrote: >=20 > > 1) The motivation of the ua-loose-route and target drafts was the UAS > > cares about what the UAC *sent*, not what the last proxy saw before > > it was changed. That may seem like the same thing, but it's not. If > > I send a request to "sip:fluffy@cisco.com" and it gets resolved to > > another pseudonym AoR of "cullen@cto-proxy.cisco.com" which then is > > resolved to the UAS contact, the UAS needs to find > > "sip:fluffy@cisco.com" - not the last "aor" flag which would be for > > "cullen@cto-proxy.cisco.com". >=20 > The real problem is even messier: The goal is to find that which was > sent by the UAC as modified by intermediaries that claim to be > authoritative in doing so. Yes, that was what I meant later in that email about: "In other words, get = the req-URI that the UAC or last retargeter sent." The caveat for ua-loose-route and Target was that if the request was re-tar= geted, the "original Req-URI" becomes the new one the retargeter uses. Unf= ortunately, it is really really hard for machines to know when something is= a re-target vs. just a simple re-route to the same user. > I believe the whole problem is much more readily solved by something > closer to Christer's approach: Put the target URI and parameters into a > separate header field that is NOT used for routing. This header field > might be manipulated by a middlebox (such as my speed-dial service), but > at least it doesn't get accidentally twiddled by a routing operation. While I don't disagree the overhead would be a ton less, the actual problem= of knowing when a re-target occurs vs. a simple re-route is no easier. In= other words, when should the Proxy leave the Target header alone vs. overw= rite it. -hadriel From jmpolk@cisco.com Mon Jul 13 13:59:35 2009 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 258603A6DA6 for ; Mon, 13 Jul 2009 13:59:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.323 X-Spam-Level: X-Spam-Status: No, score=-6.323 tagged_above=-999 required=5 tests=[AWL=0.276, 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 F7vqy8QgcImF for ; Mon, 13 Jul 2009 13:59:33 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 6CAE028C37E for ; Mon, 13 Jul 2009 13:59:31 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgGAKc9W0qrR7MV/2dsb2JhbACIPrABiCOPCQWECQ X-IronPort-AV: E=Sophos;i="4.42,392,1243814400"; d="scan'208";a="213392739" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-1.cisco.com with ESMTP; 13 Jul 2009 21:00:02 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6DL02dr019264; Mon, 13 Jul 2009 14:00:02 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6DL023o019193; Mon, 13 Jul 2009 21:00:02 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jul 2009 14:00:01 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.11.205]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jul 2009 14:00:00 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Jul 2009 15:59:55 -0500 To: "Elwell, John" , sipcore@ietf.org From: "James M. Polk" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00221E0FD@GBNTHT12009MSX.gb 002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D00218C372@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00221DBF8@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00221DC12@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00221E0FD@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 13 Jul 2009 21:00:00.0362 (UTC) FILETIME=[E2B4C4A0:01CA03FC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11145; t=1247518802; x=1248382802; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20Use=20of=20term=20=22Location=20Server= 22=20in=20location-conveyance=20draft |Sender:=20; bh=uQTuwyiCg/Vpz6Jl0Dmz1KVFQy7BpGv3rLZCdZB0ra0=; b=rk/yW7Tjfvgkj2XVnWl/JVjKDheHh6mT+8qtaiFy6Da07XYdYjlA6GPBZ5 B1nCrCBdYnGaP7kVujwqJbEeZUCCU+Q8N8pAm3k8N2NGq99npiyknoMpe/Ch CWCcvOGpL0pwJE4xgdSSuqqvwN5nGDd/eqZkYhFBHOFftnnEMP8bk=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "marc Linsner \(mlinsner\)" Subject: Re: [sipcore] Use of term "Location Server" in location-conveyance draft 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, 13 Jul 2009 20:59:35 -0000 At 03:19 PM 7/13/2009, Elwell, John wrote: > > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: 13 July 2009 18:37 > > To: Elwell, John; sipcore@ietf.org > > Cc: marc Linsner (mlinsner) > > Subject: RE: Use of term "Location Server" in > > location-conveyance draft > > > > At 02:15 AM 7/13/2009, Elwell, John wrote: > > >James, > > > > > >It occurs to me we already have the term location inserter used in > > >various places in the document, so why don't we stick to this, rather > > >than location server, for the UA or proxy that inserts? Then we could > > >use the term location server for the server you go to to dereference > > >LbyR. > > > > I thought about that - but the Geopriv Arch -00 ID just came out and > > the 6 authors there decided the LS is the location inserter in their > > terminology and the LIS is the dereferencer *but* only if a target > > wants to dereference their own location. If another entity wants to > > dereference your location, it is not a LIS, it's just an LS. >[JRE] That has always been my understanding. > > > > > I believe this is even more confusing. > > > > BTW - the LIS is who provides a target its DHCP or LLDP-MED or HELD > > location information too. Meaning, the LIS has to be able to do L2 > > downloads of LI *and* L7 subscriptions. > > > > > > >I agree with others, by the way, that LIS is not an > > appropriate term for > > >the latter. > > > > see above, it now *IS* the proper term for the latter, but only if it > > is the target that's doing it. >[JRE] But in the context of sip-location-conveyance, the UAS or a proxy >that receives the location will NEVER be the target, so it will NEVER be >a LIS when dereferencing occurs. that's not true. Conveyance states that a target can take its location URI and subscribe to it to receive its PIDF-LO. This has been in there for a while. Now, which entity does the target subscribe to, the LIS or an LS? James >John > > > > > > Talk about shifting roles... > > > > > > >John > > > > > > > -----Original Message----- > > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > > Sent: 13 July 2009 07:56 > > > > To: Elwell, John; sipcore@ietf.org > > > > Cc: marc Linsner (mlinsner) > > > > Subject: RE: Use of term "Location Server" in > > > > location-conveyance draft > > > > > > > > John > > > > > > > > in-line > > > > > > > > At 01:20 AM 7/13/2009, Elwell, John wrote: > > > > >James, > > > > > > > > > >I have to say this is mighty confusing. Basically > > > > location-conveyance is > > > > >an extension to SIP, and therefore its primary purpose is to > > > > specify the > > > > >SIP protocol and the behaviour of the various SIP entities > > > > involved. To > > > > >have an important term that sometimes can mean a SIP > > entity (the SIP > > > > >entity that inserts the Geolocation header field) and sometimes > > > > >something quite unrelated to SIP location conveyance > > (the entity to > > > > >which the dereferencing request is sent) strikes me as > > something we > > > > >should avoid. > > > > > > > > welcome to my world... ugh > > > > > > > > >In my opinion we should do one of the following: > > > > > > > > > >1. Limit LS to having only one of these meanings, and if > > necessary > > > > >introduce a new term for the other case. > > > > > > > > I thought we had a server entity term defined that was just for > > > > dereferences, called a Location Information Server (LIS), but > > > > apparently that term was taken (hijacked?) just for Location > > > > Configuration Protocols (LCPs) like DHCP and especially HELD. See > > > > Martin's recent message clarifying this to me. It was > > news too. I > > > > say especially HELD because it appears that crew actually did the > > > > "taking" deed. > > > > > > > > It appears to me that Location Servers that are essentially peers > > > > that communicate location values or references in the > > signaling path > > > > of the original SIP request is a good delineation. > > > > > > > > Then, having another term defining what entity the location URIs > > > > point at (i.e., the dereferencing function) should NOT be > > called the > > > > same thing, this is what I was calling a LIS (Location Information > > > > Server), which had a unique function, storing all the PIDF-LOs for > > > > the location targets (prior to any dereferencing). > > > > > > > > > If this is not possible because > > > > >it would conflict with other published documents, then > > do it locally > > > > >within sip-location-conveyance using appropriate > > language ("For the > > > > >purposes of this document, location server means....") > > > > > > > > interesting... that would mean I (or a small group) would > > be defining > > > > a small parallel set of terms that do not go anywhere > > else except in > > > > the case of Conveyance... > > > > > > > > Can I recommend you send this suggestion (with the WHY!) to Keith > > > > Drage? He's the doc shepherd for this ID. That will > > probably go the > > > > farthest. CCing the chairs would always be a good idea. > > > > > > > > I hope to have the final version ready for WGLC before > > the milestone > > > > date of Sept 09. > > > > > > > > This will take a little thought once it's solved for, but > > it's pretty > > > > much a global replace function once we come up with a set of > > > > terms to use. > > > > > > > > -01 of conveyance will be out tomorrow, and Spencer Dawkins did a > > > > pretty good job at making it easier to read. He didn't > > address the > > > > term confusion though. > > > > > > > > This term issue aside, I was hoping this -01 version was > > the version > > > > that went to WGLC. > > > > > > > > > > > > >2. Avoid the term LS altogether in this document and > > define new terms > > > > >for the various different purposes. > > > > > > > > yeah -- that would be what I'd have to do -- if the chairs and the > > > > shepherd agree to this. We all can talk live about this > > in Stockholm > > > > hopefully. > > > > > > > > BTW - if it's not clear yet within this message -- I'm > > not opposed to > > > > doing this (because of the confusion associated with this topic). > > > > > > > > James > > > > > > > > > > > > >John > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > > > > Sent: 13 July 2009 05:40 > > > > > > To: Elwell, John; Martin.Thomson@andrew.com; sipcore@ietf.org > > > > > > Subject: Re: Use of term "Location Server" in > > > > > > location-conveyance draft > > > > > > > > > > > > john > > > > > > > > > > > > Sorry I missed this note earlier... see below > > > > > > > > > > > > At 01:37 AM 7/3/2009, Elwell, John wrote: > > > > > > >The separate thread arising from my review of the draft has > > > > > > left me very > > > > > > >confused about what exactly the term "Location Server" > > > > means in this > > > > > > >draft. > > > > > > > > > > > > > >The draft itself says: > > > > > > >" A [RFC3693] defined "Using > > > > > > > Protocol" describes how a "Location Server" > > > > transmits a "Location > > > > > > > Object" to a "Location Recipient" while maintaining > > > > the contained > > > > > > > privacy intentions of the Target intact. This document > > > > > > describes the > > > > > > > extension to SIP for how it complies with the > > Using Protocol > > > > > > > requirements, where the location server is a UA or Proxy > > > > > > Server and > > > > > > > the Location Recipient is another UA or Proxy Server." > > > > > > >My review comments that touched on this subject > > assumed the above > > > > > > >definition. > > > > > > >According to this, the server that the Location > > > > Recipient goes to to > > > > > > >dereference the LbyR URI is NOT a Location Server. But > > > > some of the > > > > > > >thread messages have suggested it IS a Location Server. > > > > We cannot use > > > > > > >the term Location Server to mean two different things. > > > > Can somebody > > > > > > >please clarify? > > > > > > > > > > > > In Geopriv, a Location Server (LS) is an entity that transmits > > > > > > location towards a Location Recipient (LR). This > > > > transmission might > > > > > > take that message through another LS before getting to the LR. > > > > > > > > > > > > In SIP terms, a UA or SIP server (of whatever flavor) > > that inserts > > > > > > location into a message (as a message body or as a > > dereferencable > > > > > > location URI) is an LS. > > > > > > > > > > > > A B2BUA that completes a call leg that contains location, and > > > > > > regenerates a new SIP request towards another B2BUA or > > > > UAS with that > > > > > > location in the new SIP request is also an LS. > > > > > > > > > > > > A proxy that inserts a dereferencable location URI is an LS. > > > > > > > > > > > > A proxy that does not insert a dereferencable location > > > > URI is NOT an > > > > > > LS (this time). It is basically performing a repeater > > > > function that > > > > > > is not defined in Geopriv. > > > > > > > > > > > > A UAS that understands location (i.e., something close to the > > > > > > Location Conveyance extension) is an LR. A UAS that receives > > > > > > location - but does not understand Location Conveyance - > > > > is not an LR > > > > > > (because it doesn't do anything with the location except > > > > > > throw it away). > > > > > > > > > > > > A SIP server that retargets a SIP request after viewing > > > > the contained > > > > > > location in that SIP request is also an LR, and because it did > > > > > > something with the location - I think it can be called an > > > > LS too (but > > > > > > some might disagree). > > > > > > > > > > > > A good example of this last case is a location source > > > > based routing > > > > > > proxy that retargets a R-URI based on the contained > > > > location within a > > > > > > SIP request, like say - an INVITE to 911. > > > > > > > > > > > > In this case, that proxy is an LR and an LS. The UAC is > > > > a Location > > > > > > Generator (LG) and an LS; and the PSAP call center (i.e., > > > > the UAS for > > > > > > the call) is an LS. > > > > > > > > > > > > Confused? > > > > > > > > > > > > :-p > > > > > > > > > > > > Geopriv elements change roles based on what they do, > > or can do. > > > > > > > > > > > > The only debatable label here is LG, as the label > > seems to have > > > > > > changed since RFC 3693 (Geopriv Requirements) which I > > > > co-authored - > > > > > > and the new doc describing the new functions isn't an RFC > > > > yet, and is > > > > > > shifting positions with a couple of its definitions > > lately (i.e., > > > > > > within the last year). > > > > > > > > > > > > James > > > > > > > > > > > > > > > > > > > > > > > > >John > > > > > > > > > > > > > > > > > > > > > > > > From jmpolk@cisco.com Mon Jul 13 13:59:56 2009 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 4B29F28C2E0 for ; Mon, 13 Jul 2009 13:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.326 X-Spam-Level: X-Spam-Status: No, score=-6.326 tagged_above=-999 required=5 tests=[AWL=0.273, 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 7iBh+A4nLVYI for ; Mon, 13 Jul 2009 13:59:54 -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 D84B73A67F0 for ; Mon, 13 Jul 2009 13:59:54 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjgGAEI9W0qrR7MV/2dsb2JhbACIPrAFiCOPCQWECQ X-IronPort-AV: E=Sophos;i="4.42,392,1243814400"; d="scan'208";a="345890500" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-6.cisco.com with ESMTP; 13 Jul 2009 21:00:25 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6DL0PeO020373; Mon, 13 Jul 2009 14:00:25 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6DL0PPm019869; Mon, 13 Jul 2009 21:00:25 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jul 2009 14:00:25 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.11.205]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 13 Jul 2009 14:00:24 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 13 Jul 2009 16:00:23 -0500 To: "Elwell, John" , sipcore@ietf.org From: "James M. Polk" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00221E0FE@GBNTHT12009MSX.gb 002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D00218C372@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00221DBF8@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00221DC12@GBNTHT12009MSX.gb002.siemens.net> <7.1.0.9.2.20090713123111.03a51228@cisco.com> <0D5F89FAC29E2C41B98A6A762007F5D00221E0FE@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 13 Jul 2009 21:00:24.0974 (UTC) FILETIME=[F16042E0:01CA03FC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12023; t=1247518825; x=1248382825; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20Use=20of=20term=20=22Location=20Server= 22=20in=20location-conveyance=20draft |Sender:=20; bh=rqI1T61JahqA1w7/J97qyGD3mcDVkBXIZt+7bspP0vs=; b=MV5Qxz9ZeLOFRBwVqvWtiR4mPRKoNhvJAbbPc1v8lKRWnIPQQXh6+IhTf+ UlTaOCpg9KgjXl22TkH60pgWlh3hLsU99zAKqyyg3c9JECjNlMTWxqd6ONJv QmGu3UR0NaTPYYeWC+qkqaQfr1Yfp22EnCCXCmpjnkrmaU0Azexq4=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: "marc Linsner \(mlinsner\)" Subject: Re: [sipcore] Use of term "Location Server" in location-conveyance draft 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, 13 Jul 2009 20:59:56 -0000 At 03:20 PM 7/13/2009, Elwell, John wrote: >That would work. cool >John > > > -----Original Message----- > > From: James M. Polk [mailto:jmpolk@cisco.com] > > Sent: 13 July 2009 19:52 > > To: Elwell, John; sipcore@ietf.org > > Cc: marc Linsner (mlinsner) > > Subject: RE: Use of term "Location Server" in > > location-conveyance draft > > > > John > > > > How about using the terms > > > > - Location Inserter (just how it is defined in the doc now) > > and > > - Dereference Server (DS) (instead of Location Server) for the server > > that UAs subscribe to (using the location URI), to attain a Target's > > geolocation in a PIDF-LO format. > > > > there can't be an acronym for the inserter, because LI means Location > > Information, and that ought to stay unconfused by this doc. > > > > But DS could be the acronym for Dereference Server - and *not* have a > > limit on who can dereference from it (a target itself or a 3rd party). > > > > These would become SIP terms, just as Target in Geopriv is a > > Presentity in Presence terms. > > > > Let me know what you (and others) think about this. > > > > This can't make it into the -01 version (which I'm about to submit) > > since there is no WG consensus on the matter, but that can be > > achieved fairly quickly though if we try. > > > > James > > > > At 12:36 PM 7/13/2009, James M. Polk wrote: > > >At 02:15 AM 7/13/2009, Elwell, John wrote: > > >>James, > > >> > > >>It occurs to me we already have the term location inserter used in > > >>various places in the document, so why don't we stick to > > this, rather > > >>than location server, for the UA or proxy that inserts? > > Then we could > > >>use the term location server for the server you go to to dereference > > >>LbyR. > > > > > >I thought about that - but the Geopriv Arch -00 ID just came out and > > >the 6 authors there decided the LS is the location inserter in their > > >terminology and the LIS is the dereferencer *but* only if a target > > >wants to dereference their own location. If another entity wants to > > >dereference your location, it is not a LIS, it's just an LS. > > > > > >I believe this is even more confusing. > > > > > >BTW - the LIS is who provides a target its DHCP or LLDP-MED or HELD > > >location information too. Meaning, the LIS has to be able to do L2 > > >downloads of LI *and* L7 subscriptions. > > > > > > > > >>I agree with others, by the way, that LIS is not an > > appropriate term for > > >>the latter. > > > > > >see above, it now *IS* the proper term for the latter, but only if > > >it is the target that's doing it. > > > > > >Talk about shifting roles... > > > > > > > > >>John > > >> > > >> > -----Original Message----- > > >> > From: James M. Polk [mailto:jmpolk@cisco.com] > > >> > Sent: 13 July 2009 07:56 > > >> > To: Elwell, John; sipcore@ietf.org > > >> > Cc: marc Linsner (mlinsner) > > >> > Subject: RE: Use of term "Location Server" in > > >> > location-conveyance draft > > >> > > > >> > John > > >> > > > >> > in-line > > >> > > > >> > At 01:20 AM 7/13/2009, Elwell, John wrote: > > >> > >James, > > >> > > > > >> > >I have to say this is mighty confusing. Basically > > >> > location-conveyance is > > >> > >an extension to SIP, and therefore its primary purpose is to > > >> > specify the > > >> > >SIP protocol and the behaviour of the various SIP entities > > >> > involved. To > > >> > >have an important term that sometimes can mean a SIP > > entity (the SIP > > >> > >entity that inserts the Geolocation header field) and sometimes > > >> > >something quite unrelated to SIP location conveyance > > (the entity to > > >> > >which the dereferencing request is sent) strikes me as > > something we > > >> > >should avoid. > > >> > > > >> > welcome to my world... ugh > > >> > > > >> > >In my opinion we should do one of the following: > > >> > > > > >> > >1. Limit LS to having only one of these meanings, and > > if necessary > > >> > >introduce a new term for the other case. > > >> > > > >> > I thought we had a server entity term defined that was just for > > >> > dereferences, called a Location Information Server (LIS), but > > >> > apparently that term was taken (hijacked?) just for Location > > >> > Configuration Protocols (LCPs) like DHCP and especially HELD. See > > >> > Martin's recent message clarifying this to me. It was > > news too. I > > >> > say especially HELD because it appears that crew actually did the > > >> > "taking" deed. > > >> > > > >> > It appears to me that Location Servers that are essentially peers > > >> > that communicate location values or references in the > > signaling path > > >> > of the original SIP request is a good delineation. > > >> > > > >> > Then, having another term defining what entity the location URIs > > >> > point at (i.e., the dereferencing function) should NOT > > be called the > > >> > same thing, this is what I was calling a LIS (Location > > Information > > >> > Server), which had a unique function, storing all the > > PIDF-LOs for > > >> > the location targets (prior to any dereferencing). > > >> > > > >> > > If this is not possible because > > >> > >it would conflict with other published documents, then > > do it locally > > >> > >within sip-location-conveyance using appropriate > > language ("For the > > >> > >purposes of this document, location server means....") > > >> > > > >> > interesting... that would mean I (or a small group) > > would be defining > > >> > a small parallel set of terms that do not go anywhere > > else except in > > >> > the case of Conveyance... > > >> > > > >> > Can I recommend you send this suggestion (with the WHY!) to Keith > > >> > Drage? He's the doc shepherd for this ID. That will > > probably go the > > >> > farthest. CCing the chairs would always be a good idea. > > >> > > > >> > I hope to have the final version ready for WGLC before > > the milestone > > >> > date of Sept 09. > > >> > > > >> > This will take a little thought once it's solved for, > > but it's pretty > > >> > much a global replace function once we come up with a set of > > >> > terms to use. > > >> > > > >> > -01 of conveyance will be out tomorrow, and Spencer Dawkins did a > > >> > pretty good job at making it easier to read. He didn't > > address the > > >> > term confusion though. > > >> > > > >> > This term issue aside, I was hoping this -01 version was > > the version > > >> > that went to WGLC. > > >> > > > >> > > > >> > >2. Avoid the term LS altogether in this document and > > define new terms > > >> > >for the various different purposes. > > >> > > > >> > yeah -- that would be what I'd have to do -- if the > > chairs and the > > >> > shepherd agree to this. We all can talk live about this > > in Stockholm > > >> > hopefully. > > >> > > > >> > BTW - if it's not clear yet within this message -- I'm > > not opposed to > > >> > doing this (because of the confusion associated with this topic). > > >> > > > >> > James > > >> > > > >> > > > >> > >John > > >> > > > > >> > > > > >> > > > -----Original Message----- > > >> > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > >> > > > Sent: 13 July 2009 05:40 > > >> > > > To: Elwell, John; Martin.Thomson@andrew.com; sipcore@ietf.org > > >> > > > Subject: Re: Use of term "Location Server" in > > >> > > > location-conveyance draft > > >> > > > > > >> > > > john > > >> > > > > > >> > > > Sorry I missed this note earlier... see below > > >> > > > > > >> > > > At 01:37 AM 7/3/2009, Elwell, John wrote: > > >> > > > >The separate thread arising from my review of the draft has > > >> > > > left me very > > >> > > > >confused about what exactly the term "Location Server" > > >> > means in this > > >> > > > >draft. > > >> > > > > > > >> > > > >The draft itself says: > > >> > > > >" A [RFC3693] defined "Using > > >> > > > > Protocol" describes how a "Location Server" > > >> > transmits a "Location > > >> > > > > Object" to a "Location Recipient" while maintaining > > >> > the contained > > >> > > > > privacy intentions of the Target intact. This document > > >> > > > describes the > > >> > > > > extension to SIP for how it complies with the > > Using Protocol > > >> > > > > requirements, where the location server is a UA or Proxy > > >> > > > Server and > > >> > > > > the Location Recipient is another UA or Proxy Server." > > >> > > > >My review comments that touched on this subject > > assumed the above > > >> > > > >definition. > > >> > > > >According to this, the server that the Location > > >> > Recipient goes to to > > >> > > > >dereference the LbyR URI is NOT a Location Server. But > > >> > some of the > > >> > > > >thread messages have suggested it IS a Location Server. > > >> > We cannot use > > >> > > > >the term Location Server to mean two different things. > > >> > Can somebody > > >> > > > >please clarify? > > >> > > > > > >> > > > In Geopriv, a Location Server (LS) is an entity that > > transmits > > >> > > > location towards a Location Recipient (LR). This > > >> > transmission might > > >> > > > take that message through another LS before getting > > to the LR. > > >> > > > > > >> > > > In SIP terms, a UA or SIP server (of whatever > > flavor) that inserts > > >> > > > location into a message (as a message body or as a > > dereferencable > > >> > > > location URI) is an LS. > > >> > > > > > >> > > > A B2BUA that completes a call leg that contains location, and > > >> > > > regenerates a new SIP request towards another B2BUA or > > >> > UAS with that > > >> > > > location in the new SIP request is also an LS. > > >> > > > > > >> > > > A proxy that inserts a dereferencable location URI is an LS. > > >> > > > > > >> > > > A proxy that does not insert a dereferencable location > > >> > URI is NOT an > > >> > > > LS (this time). It is basically performing a repeater > > >> > function that > > >> > > > is not defined in Geopriv. > > >> > > > > > >> > > > A UAS that understands location (i.e., something close to the > > >> > > > Location Conveyance extension) is an LR. A UAS that receives > > >> > > > location - but does not understand Location Conveyance - > > >> > is not an LR > > >> > > > (because it doesn't do anything with the location except > > >> > > > throw it away). > > >> > > > > > >> > > > A SIP server that retargets a SIP request after viewing > > >> > the contained > > >> > > > location in that SIP request is also an LR, and > > because it did > > >> > > > something with the location - I think it can be called an > > >> > LS too (but > > >> > > > some might disagree). > > >> > > > > > >> > > > A good example of this last case is a location source > > >> > based routing > > >> > > > proxy that retargets a R-URI based on the contained > > >> > location within a > > >> > > > SIP request, like say - an INVITE to 911. > > >> > > > > > >> > > > In this case, that proxy is an LR and an LS. The UAC is > > >> > a Location > > >> > > > Generator (LG) and an LS; and the PSAP call center (i.e., > > >> > the UAS for > > >> > > > the call) is an LS. > > >> > > > > > >> > > > Confused? > > >> > > > > > >> > > > :-p > > >> > > > > > >> > > > Geopriv elements change roles based on what they do, > > or can do. > > >> > > > > > >> > > > The only debatable label here is LG, as the label > > seems to have > > >> > > > changed since RFC 3693 (Geopriv Requirements) which I > > >> > co-authored - > > >> > > > and the new doc describing the new functions isn't an RFC > > >> > yet, and is > > >> > > > shifting positions with a couple of its definitions > > lately (i.e., > > >> > > > within the last year). > > >> > > > > > >> > > > James > > >> > > > > > >> > > > > > >> > > > > > >> > > > >John > > >> > > > > > >> > > > > > >> > > > >> > > > > > From AUDET@nortel.com Mon Jul 13 14:07:42 2009 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 304103A68C2 for ; Mon, 13 Jul 2009 14:07:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.393 X-Spam-Level: X-Spam-Status: No, score=-6.393 tagged_above=-999 required=5 tests=[AWL=0.206, 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 CfwgR+zwL7SZ for ; Mon, 13 Jul 2009 14:07:41 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 4A4913A6DCF for ; Mon, 13 Jul 2009 14:07:41 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6DL7eI01764 for ; Mon, 13 Jul 2009 21:07:40 GMT 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, 13 Jul 2009 16:07:37 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EF51FF9@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rfc4244bis: Open Issues thread-index: AcoD4RmgYPToplphTNGZX+nUfMAJ3gAGmHWgAABnAtA= References: <4A5B7195.6020009@softarmor.com> From: "Francois Audet" To: "SIPCORE" Subject: [sipcore] rfc4244bis: Open Issues 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, 13 Jul 2009 21:07:42 -0000 The email threads for the last few days leads me to believe that we have = the following 2 issues with regards to RFC 4244bis: 1) Do we need the "aor" flag? 2) Do we need the "cc" flag (i.e., "configured contact"). If we did NOT = have the configured contact, flag, then I would think that we would have instead to use = either "registered contact" or "mapped", as appropriate.=20 Let's think about those two issues. =20 From HKaplan@acmepacket.com Mon Jul 13 15:42:39 2009 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 A9E673A69B4 for ; Mon, 13 Jul 2009 15:42:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 qKR4R+dkFMpV for ; Mon, 13 Jul 2009 15:42:39 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D6F963A6997 for ; Mon, 13 Jul 2009 15:42:38 -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.1.375.2; Mon, 13 Jul 2009 18:43:08 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 13 Jul 2009 18:43:08 -0400 From: Hadriel Kaplan To: Francois Audet , SIPCORE Date: Mon, 13 Jul 2009 18:43:05 -0400 Thread-Topic: rfc4244bis: Open Issues Thread-Index: AcoD4RmgYPToplphTNGZX+nUfMAJ3gAGmHWgAABnAtAAA1WScA== Message-ID: References: <4A5B7195.6020009@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF51FF9@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EF51FF9@zrc2hxm0.corp.nortel.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] rfc4244bis: Open Issues 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, 13 Jul 2009 22:42:39 -0000 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Francois Audet > Sent: Monday, July 13, 2009 5:08 PM >=20 > 2) Do we need the "cc" flag (i.e., "configured contact"). If we did NOT > have the configured > contact, flag, then I would think that we would have instead to use > either "registered > contact" or "mapped", as appropriate. I'm not sure we even need to care that it is a contact vs. an aor. The replacement of the AoR in a req-uri to the registered contact is just o= ne among many times it is *not* "mapped", and no "mp" would be added. I.e., I'm curious if we need anything other than "mp". -hadriel From AUDET@nortel.com Mon Jul 13 15:46:01 2009 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 D5CC53A69EA for ; Mon, 13 Jul 2009 15:46:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.396 X-Spam-Level: X-Spam-Status: No, score=-6.396 tagged_above=-999 required=5 tests=[AWL=0.203, 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 AucUkZzvyVLq for ; Mon, 13 Jul 2009 15:46:01 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id F305028C678 for ; Mon, 13 Jul 2009 15:45:59 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6DMkMI17773; Mon, 13 Jul 2009 22:46:22 GMT 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, 13 Jul 2009 17:46:20 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EF521C4@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rfc4244bis: Open Issues thread-index: AcoD4RmgYPToplphTNGZX+nUfMAJ3gAGmHWgAABnAtAAA1WScAAAQZAg References: <4A5B7195.6020009@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF51FF9@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Hadriel Kaplan" , "SIPCORE" Subject: Re: [sipcore] rfc4244bis: Open Issues 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, 13 Jul 2009 22:46:01 -0000 AOR is orthogonal to rc (and MP actually). RC is very useful. It tells you that a specific entry is ephemeral=20 address that replaced the AOR. (i.e., it typically tells you can ignore it).=20 Otherwise, you don't know that it it's a registered contact. > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Monday, July 13, 2009 15:43 > To: Audet, Francois (SC100:3055); SIPCORE > Subject: RE: rfc4244bis: Open Issues >=20 >=20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > > Behalf Of Francois Audet > > Sent: Monday, July 13, 2009 5:08 PM > >=20 > > 2) Do we need the "cc" flag (i.e., "configured contact"). If we did=20 > > NOT have the configured > > contact, flag, then I would think that we would have=20 > instead to use=20 > > either "registered > > contact" or "mapped", as appropriate. >=20 > I'm not sure we even need to care that it is a contact vs. an aor. > The replacement of the AoR in a req-uri to the registered=20 > contact is just one among many times it is *not* "mapped",=20 > and no "mp" would be added. >=20 > I.e., I'm curious if we need anything other than "mp". >=20 > -hadriel >=20 From HKaplan@acmepacket.com Mon Jul 13 15:59:56 2009 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 844623A694D for ; Mon, 13 Jul 2009 15:59:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 svjWOTYt+XaX for ; Mon, 13 Jul 2009 15:59:55 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 6BCD53A68DC for ; Mon, 13 Jul 2009 15:59:55 -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.1.375.2; Mon, 13 Jul 2009 19:00:25 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 13 Jul 2009 19:00:25 -0400 From: Hadriel Kaplan To: Francois Audet , SIPCORE Date: Mon, 13 Jul 2009 19:00:23 -0400 Thread-Topic: rfc4244bis: Open Issues Thread-Index: AcoD4RmgYPToplphTNGZX+nUfMAJ3gAGmHWgAABnAtAAA1WScAAAQZAgAAAkWqA= Message-ID: References: <4A5B7195.6020009@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF51FF9@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EF521C4@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EF521C4@zrc2hxm0.corp.nortel.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] rfc4244bis: Open Issues 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, 13 Jul 2009 22:59:56 -0000 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, July 13, 2009 6:46 PM >=20 > AOR is orthogonal to rc (and MP actually). Yes I agree - aor was a property describing the type of URI in the HI-entry= , whereas all the others are basically reasons the HI-entry's URI changed (= or didn't), or the action that caused it to be what it is, if you prefer to= think of it that way. But that wasn't my point - sorry for the confusion. > RC is very useful. It tells you that a specific entry is ephemeral > address that replaced the AOR. > (i.e., it typically tells you can ignore it). > Otherwise, you don't know that it it's a registered contact. It shouldn't matter. You can ignore anything that doesn't have an "mp" fla= g, period. The rest are all just window dressing - req-uri's that were cha= nged or not, for reasons such as strict-routing, registered contact replace= ment, configured contact replacement, maddr, translations, foobar, etc. =20 The change that matters is re-targeting, because the req-uri's that are imp= ortant are the ones that are created in those cases. That's what the Targe= t/ua-loose-route concepts cared about; that's what Diversion-redirection in= fo cared about; it's what freephone case cares about; it's what the PSAP em= ergency-call case cares about, etc. Right?=20 (they don't all happen to care about the same "mp" instance in the HI list,= but they all care about "mp" entries) -hadriel From AUDET@nortel.com Mon Jul 13 16:06:18 2009 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 5BADE3A6834 for ; Mon, 13 Jul 2009 16:06:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.4 X-Spam-Level: X-Spam-Status: No, score=-6.4 tagged_above=-999 required=5 tests=[AWL=0.199, 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 pJZB1laPn6k9 for ; Mon, 13 Jul 2009 16:06:17 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 48A0B28C32A for ; Mon, 13 Jul 2009 16:05:16 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6DN42q01891; Mon, 13 Jul 2009 23:04:02 GMT 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, 13 Jul 2009 18:05:38 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EF52209@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rfc4244bis: Open Issues thread-index: AcoD4RmgYPToplphTNGZX+nUfMAJ3gAGmHWgAABnAtAAA1WScAAAQZAgAAAkWqAAAHnXYA== References: <4A5B7195.6020009@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF51FF9@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EF521C4@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Hadriel Kaplan" , "SIPCORE" Subject: Re: [sipcore] rfc4244bis: Open Issues 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, 13 Jul 2009 23:06:18 -0000 You need to distinguish between "old RFC 4244" and new. The presence of the tag tells you it's new 4244. =20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Monday, July 13, 2009 16:00 > To: Audet, Francois (SC100:3055); SIPCORE > Subject: RE: rfc4244bis: Open Issues >=20 >=20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Monday, July 13, 2009 6:46 PM > >=20 > > AOR is orthogonal to rc (and MP actually). >=20 > Yes I agree - aor was a property describing the type of URI=20 > in the HI-entry, whereas all the others are basically reasons=20 > the HI-entry's URI changed (or didn't), or the action that=20 > caused it to be what it is, if you prefer to think of it that=20 > way. But that wasn't my point - sorry for the confusion. >=20 >=20 > > RC is very useful. It tells you that a specific entry is ephemeral=20 > > address that replaced the AOR. > > (i.e., it typically tells you can ignore it). > > Otherwise, you don't know that it it's a registered contact. >=20 > It shouldn't matter. You can ignore anything that doesn't=20 > have an "mp" flag, period. The rest are all just window=20 > dressing - req-uri's that were changed or not, for reasons=20 > such as strict-routing, registered contact replacement,=20 > configured contact replacement, maddr, translations, foobar, etc. =20 >=20 > The change that matters is re-targeting, because the=20 > req-uri's that are important are the ones that are created in=20 > those cases. That's what the Target/ua-loose-route concepts=20 > cared about; that's what Diversion-redirection info cared=20 > about; it's what freephone case cares about; it's what the=20 > PSAP emergency-call case cares about, etc. Right?=20 > (they don't all happen to care about the same "mp" instance=20 > in the HI list, but they all care about "mp" entries) >=20 > -hadriel >=20 From dean.willis@softarmor.com Mon Jul 13 16:06:30 2009 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 DF77428C1F2 for ; Mon, 13 Jul 2009 16:06:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 BjJjtaKP902j for ; Mon, 13 Jul 2009 16:06:30 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 1BCF93A6B4E for ; Mon, 13 Jul 2009 16:06:30 -0700 (PDT) Received: from [192.168.2.2] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6DN6vMV004933 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 13 Jul 2009 18:06:59 -0500 Message-ID: <4A5BBE0C.5000301@softarmor.com> Date: Mon, 13 Jul 2009 18:06:52 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Francois Audet References: <4A5B7195.6020009@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com> X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 13 Jul 2009 23:06:31 -0000 Francois Audet wrote: > >> Solving this problem with H-I seems to me to be gross >> overkill and an unnecessary exercise in pointless complexity. >> But that's what we do best around here. > > I don't see how this is overkill. > > We have History-info anyways. > H-I is overkill because it 1) does lots of things, not just this URI and parameter transmission function b) is much bigger than what is required for URI and parameter transmission, and c) doesn't deterministically solve the URI and parameter transmission function. Can you show me a universal algorithm for the UAS to use in figuring out which HI entry is is supposed to use? -- Dean From dean.willis@softarmor.com Mon Jul 13 16:12:25 2009 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 2902B3A6A85 for ; Mon, 13 Jul 2009 16:12:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 mCkqzeASrbck for ; Mon, 13 Jul 2009 16:12:24 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 418183A694D for ; Mon, 13 Jul 2009 16:12:24 -0700 (PDT) Received: from [192.168.2.2] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6DNCp0O005000 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 13 Jul 2009 18:12:53 -0500 Message-ID: <4A5BBF6E.8010105@softarmor.com> Date: Mon, 13 Jul 2009 18:12:46 -0500 From: Dean Willis User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103) MIME-Version: 1.0 To: Hadriel Kaplan References: <4A5B7195.6020009@softarmor.com> In-Reply-To: X-Enigmail-Version: 0.95.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 13 Jul 2009 23:12:25 -0000 Hadriel Kaplan wrote: >> The real problem is even messier: The goal is to find that which >> was sent by the UAC as modified by intermediaries that claim to be >> authoritative in doing so. > > Yes, that was what I meant later in that email about: "In other > words, get the req-URI that the UAC or last retargeter sent." But it's not just a req-URI inserted by a UAC or retarger. A proxy might legitimately add a parameter to the request URI. This is n't a retarget -- using that vocabularly, it might be called a non-retargeting reparameterization. How does that show up in HI? > > The caveat for ua-loose-route and Target was that if the request was > re-targeted, the "original Req-URI" becomes the new one the > retargeter uses. Unfortunately, it is really really hard for > machines to know when something is a re-target vs. just a simple > re-route to the same user. As I believe you asked, do they NEED to know whether this is a retarget or re-route for parameter modification? They clearly need to know whether parameter modification is reequired, but I'd argue that this is an entirely independent problem. > > >> I believe the whole problem is much more readily solved by >> something closer to Christer's approach: Put the target URI and >> parameters into a separate header field that is NOT used for >> routing. This header field might be manipulated by a middlebox >> (such as my speed-dial service), but at least it doesn't get >> accidentally twiddled by a routing operation. > > While I don't disagree the overhead would be a ton less, the actual > problem of knowing when a re-target occurs vs. a simple re-route is > no easier. In other words, when should the Proxy leave the Target > header alone vs. overwrite it. > That's an application-specific question. What function is the proxy here performing? And in what way is the application invocation entangled with request routing? -- Dean From AUDET@nortel.com Mon Jul 13 16:20:36 2009 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 922A128C313 for ; Mon, 13 Jul 2009 16:20:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.403 X-Spam-Level: X-Spam-Status: No, score=-6.403 tagged_above=-999 required=5 tests=[AWL=0.196, 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 KzXQ3EXY9HEB for ; Mon, 13 Jul 2009 16:20:35 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id EB47228C3DE for ; Mon, 13 Jul 2009 16:18:45 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6DNJCI22563; Mon, 13 Jul 2009 23:19:12 GMT 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, 13 Jul 2009 18:19:11 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A5BBE0C.5000301@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is "aor" used for? thread-index: AcoEDqM/XIENvO+JQM+deNhoIRK3fQAAKw3Q References: <4A5B7195.6020009@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com> <4A5BBE0C.5000301@softarmor.com> From: "Francois Audet" To: "Dean Willis" Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 13 Jul 2009 23:20:36 -0000 I assume your question is for "target URI" specifically. You would look at the las entry that is not a "rc/cc/rt". Bingo. Now, your question was loaded. You said "universal" but clearly, it's not Universal because your are strictly looking at solving the TargetURI problem. Furthermore, you are strictly trying to solve the LAST targetURI problem. There are applications that do not use the LAST = but the FIRST targetURI (for example). Lots of Voice mail systems, again, for=20 example, do this. Therefore, it's not Universal. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Monday, July 13, 2009 16:07 > To: Audet, Francois (SC100:3055) > Cc: Hadriel Kaplan; SIPCORE > Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? >=20 > Francois Audet wrote: > > =20 > >> Solving this problem with H-I seems to me to be gross=20 > overkill and an=20 > >> unnecessary exercise in pointless complexity. > >> But that's what we do best around here. > >=20 > > I don't see how this is overkill. > >=20 > > We have History-info anyways. > >=20 >=20 > H-I is overkill because it 1) does lots of things, not just=20 > this URI and parameter transmission function b) is much=20 > bigger than what is required for URI and parameter=20 > transmission, and c) doesn't deterministically solve the URI=20 > and parameter transmission function. >=20 > Can you show me a universal algorithm for the UAS to use in=20 > figuring out which HI entry is is supposed to use? >=20 > -- > Dean >=20 From mary.barnes@nortel.com Mon Jul 13 16:22:05 2009 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 9BBC23A6A2E for ; Mon, 13 Jul 2009 16:22:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.334 X-Spam-Level: X-Spam-Status: No, score=-6.334 tagged_above=-999 required=5 tests=[AWL=0.265, 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 fHe7VhbNSo7O for ; Mon, 13 Jul 2009 16:22:04 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 8A01E3A6834 for ; Mon, 13 Jul 2009 16:22:04 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6DNMWI22697; Mon, 13 Jul 2009 23:22:32 GMT 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: Mon, 13 Jul 2009 18:24:56 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EF5223C@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EF52209@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: Open Issues thread-index: AcoD4RmgYPToplphTNGZX+nUfMAJ3gAGmHWgAABnAtAAA1WScAAAQZAgAAAkWqAAAHnXYAAAjthQ References: <4A5B7195.6020009@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF51FF9@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EF521C4@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EF52209@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Francois Audet" , "Hadriel Kaplan" , "SIPCORE" Subject: Re: [sipcore] rfc4244bis: Open Issues 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, 13 Jul 2009 23:22:05 -0000 One thing that might really help this debate is to get the target-uri usecases updated to describe how they will use these new tags. My understanding as to why we needed to define the discrete tags and "aor" was to handle a rather unfortunate PSTNish 800 service model - I'll let Hans and Christer explain that one. In the end, we tried to just delineate the different approaches whereby the new target was determined per section 16.5 of RFC 3261, since that is really the most we can do. Of course, there's some lack of specificity there which is why we are where we are. =20 Mary.=20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Audet, Francois (SC100:3055) Sent: Monday, July 13, 2009 6:06 PM To: Hadriel Kaplan; SIPCORE Subject: Re: [sipcore] rfc4244bis: Open Issues You need to distinguish between "old RFC 4244" and new. The presence of the tag tells you it's new 4244. =20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > Sent: Monday, July 13, 2009 16:00 > To: Audet, Francois (SC100:3055); SIPCORE > Subject: RE: rfc4244bis: Open Issues >=20 >=20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Monday, July 13, 2009 6:46 PM > >=20 > > AOR is orthogonal to rc (and MP actually). >=20 > Yes I agree - aor was a property describing the type of URI in the=20 > HI-entry, whereas all the others are basically reasons the HI-entry's=20 > URI changed (or didn't), or the action that caused it to be what it=20 > is, if you prefer to think of it that way. But that wasn't my point - > sorry for the confusion. >=20 >=20 > > RC is very useful. It tells you that a specific entry is ephemeral=20 > > address that replaced the AOR. > > (i.e., it typically tells you can ignore it). > > Otherwise, you don't know that it it's a registered contact. >=20 > It shouldn't matter. You can ignore anything that doesn't have an=20 > "mp" flag, period. The rest are all just window dressing - req-uri's=20 > that were changed or not, for reasons such as strict-routing,=20 > registered contact replacement, configured contact replacement, maddr, > translations, foobar, etc. >=20 > The change that matters is re-targeting, because the req-uri's that=20 > are important are the ones that are created in those cases. That's=20 > what the Target/ua-loose-route concepts cared about; that's what=20 > Diversion-redirection info cared about; it's what freephone case cares > about; it's what the PSAP emergency-call case cares about, etc. =20 > Right? > (they don't all happen to care about the same "mp" instance in the HI=20 > list, but they all care about "mp" entries) >=20 > -hadriel >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From mary.barnes@nortel.com Mon Jul 13 16:24:29 2009 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 782D13A6A85 for ; Mon, 13 Jul 2009 16:24:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.336 X-Spam-Level: X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 Bmu51Bz1xkhM for ; Mon, 13 Jul 2009 16:24:28 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id E667D3A6E83 for ; Mon, 13 Jul 2009 16:24:14 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6DNOQI22860; Mon, 13 Jul 2009 23:24:26 GMT 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: Mon, 13 Jul 2009 18:26:52 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EF5223E@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is "aor" used for? thread-index: AcoEDqM/XIENvO+JQM+deNhoIRK3fQAAKw3QAAB57QA= References: <4A5B7195.6020009@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com><4A5BBE0C.5000301@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Francois Audet" , "Dean Willis" Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 13 Jul 2009 23:24:29 -0000 Exactly - 4244/4244bis are application agnostic - the applications use what they need. Per my comment in the other thread, it would be really, really useful to update target-uri use cases to describe how they're using these tags.=20 Mary. -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Audet, Francois (SC100:3055) Sent: Monday, July 13, 2009 6:19 PM To: Dean Willis Cc: SIPCORE; Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? I assume your question is for "target URI" specifically. You would look at the las entry that is not a "rc/cc/rt". Bingo. Now, your question was loaded. You said "universal" but clearly, it's not Universal because your are strictly looking at solving the TargetURI problem. Furthermore, you are strictly trying to solve the LAST targetURI problem. There are applications that do not use the LAST but the FIRST targetURI (for example). Lots of Voice mail systems, again, for example, do this. Therefore, it's not Universal. > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Monday, July 13, 2009 16:07 > To: Audet, Francois (SC100:3055) > Cc: Hadriel Kaplan; SIPCORE > Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? >=20 > Francois Audet wrote: > > =20 > >> Solving this problem with H-I seems to me to be gross > overkill and an > >> unnecessary exercise in pointless complexity. > >> But that's what we do best around here. > >=20 > > I don't see how this is overkill. > >=20 > > We have History-info anyways. > >=20 >=20 > H-I is overkill because it 1) does lots of things, not just this URI=20 > and parameter transmission function b) is much bigger than what is=20 > required for URI and parameter transmission, and c) doesn't=20 > deterministically solve the URI and parameter transmission function. >=20 > Can you show me a universal algorithm for the UAS to use in figuring=20 > out which HI entry is is supposed to use? >=20 > -- > Dean >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From HKaplan@acmepacket.com Mon Jul 13 16:45:39 2009 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 7353928C532 for ; Mon, 13 Jul 2009 16:45:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.568 X-Spam-Level: X-Spam-Status: No, score=-2.568 tagged_above=-999 required=5 tests=[AWL=0.031, 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 dcrTlx33bm2q for ; Mon, 13 Jul 2009 16:45:38 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 3D80A28C4AC for ; Mon, 13 Jul 2009 16:45:38 -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.1.375.2; Mon, 13 Jul 2009 19:46:05 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 13 Jul 2009 19:46:02 -0400 From: Hadriel Kaplan To: Dean Willis Date: Mon, 13 Jul 2009 19:45:54 -0400 Thread-Topic: [sipcore] rfc4244bis: what is "aor" used for? Thread-Index: AcoED3pGpdrdCY/FQeK7COsX412UXwAAPyNA Message-ID: References: <4A5B7195.6020009@softarmor.com> <4A5BBF6E.8010105@softarmor.com> In-Reply-To: <4A5BBF6E.8010105@softarmor.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 Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 13 Jul 2009 23:45:39 -0000 > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com] > Sent: Monday, July 13, 2009 7:13 PM >=20 > Hadriel Kaplan wrote: >=20 > >> The real problem is even messier: The goal is to find that which > >> was sent by the UAC as modified by intermediaries that claim to be > >> authoritative in doing so. > > > > Yes, that was what I meant later in that email about: "In other > > words, get the req-URI that the UAC or last retargeter sent." >=20 > But it's not just a req-URI inserted by a UAC or retarger. A proxy might > legitimately add a parameter to the request URI. This is n't a retarget > -- using that vocabularly, it might be called a non-retargeting > reparameterization. Can you give me an example? What would such a thing be used for, that it r= equires a UAS receiving it in the H-I look at it for some useful purpose? =20 > How does that show up in HI? As just another HI URI that can be ignored by the UAS. And the problem is? > > The caveat for ua-loose-route and Target was that if the request was > > re-targeted, the "original Req-URI" becomes the new one the > > retargeter uses. Unfortunately, it is really really hard for > > machines to know when something is a re-target vs. just a simple > > re-route to the same user. >=20 > As I believe you asked, do they NEED to know whether this is a retarget > or re-route for parameter modification? > They clearly need to know whether parameter modification is reequired, > but I'd argue that this is an entirely independent problem. I have no idea what you mean by "parameter modification". A UAS needs to k= now whether and which req-URI's were created by re-targeting, for it to kno= w what the set of URI's to select from for Target identification, for Origi= nal Called Party vs. Redirection information (e.g., for billing or ISUP gen= eration), for filtering, for prioritization, etc. =20 > > While I don't disagree the overhead would be a ton less, the actual > > problem of knowing when a re-target occurs vs. a simple re-route is > > no easier. In other words, when should the Proxy leave the Target > > header alone vs. overwrite it. >=20 > That's an application-specific question. What function is the proxy here > performing? And in what way is the application invocation entangled with > request routing? I'm confused - are you actually asking what the use-cases are/were for ua-l= oose-route, Diversion-Redirection, et al? You were part of those draft dis= cussions. The problem of how any proxy would know when an identity actuall= y changed or not was also discussed back then. =20 If you buy into the idea that it's application-specific, or that only the U= AS would really know, then you can't have Proxies simply putting in *one* T= arget header, because they'd never know if/when it should be changed before= getting to the UAS. They'd have to create a list of them: one new entry e= very time they re-targeted (or actually one for every time they did NOT abs= olutely know they did NOT retarget, if you can follow that crazy logic). -hadriel From HKaplan@acmepacket.com Mon Jul 13 16:59:49 2009 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 CF64B28C35F for ; Mon, 13 Jul 2009 16:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.569 X-Spam-Level: X-Spam-Status: No, score=-2.569 tagged_above=-999 required=5 tests=[AWL=0.030, 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 VHrMcwIne2Vk for ; Mon, 13 Jul 2009 16:59:49 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BBE0E3A6A85 for ; Mon, 13 Jul 2009 16:59:47 -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.1.375.2; Mon, 13 Jul 2009 20:00:17 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 13 Jul 2009 20:00:15 -0400 From: Hadriel Kaplan To: Francois Audet , SIPCORE Date: Mon, 13 Jul 2009 20:00:08 -0400 Thread-Topic: rfc4244bis: Open Issues Thread-Index: AcoD4RmgYPToplphTNGZX+nUfMAJ3gAGmHWgAABnAtAAA1WScAAAQZAgAAAkWqAAAHnXYAABk5Rg Message-ID: References: <4A5B7195.6020009@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF51FF9@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EF521C4@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EF52209@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EF52209@zrc2hxm0.corp.nortel.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] rfc4244bis: Open Issues 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, 13 Jul 2009 23:59:49 -0000 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, July 13, 2009 7:06 PM >=20 > You need to distinguish between "old RFC 4244" and new. >=20 > The presence of the tag tells you it's new 4244. You lost me - the presence of which tag tells you it's old vs. new, and why= would you care? You mean the presence of any tag? And thus you have tags= that are added so that they can be distinguished from non-tagged HI-entrie= s?? [at this point my brain explodes] -hadriel From AUDET@nortel.com Mon Jul 13 17:13:26 2009 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 C9D3A28C2A8 for ; Mon, 13 Jul 2009 17:13:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.406 X-Spam-Level: X-Spam-Status: No, score=-6.406 tagged_above=-999 required=5 tests=[AWL=0.193, 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 LRwCh1KSQcSy for ; Mon, 13 Jul 2009 17:13:26 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 6C50D28C4D0 for ; Mon, 13 Jul 2009 17:13:18 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6E0Dkx28342; Tue, 14 Jul 2009 00:13:46 GMT 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, 13 Jul 2009 19:13:44 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EF522A1@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rfc4244bis: Open Issues thread-index: AcoD4RmgYPToplphTNGZX+nUfMAJ3gAGmHWgAABnAtAAA1WScAAAQZAgAAAkWqAAAHnXYAABk5RgAADVmuA= References: <4A5B7195.6020009@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF51FF9@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EF521C4@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EF52209@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Hadriel Kaplan" , "SIPCORE" Subject: Re: [sipcore] rfc4244bis: Open Issues 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, 14 Jul 2009 00:13:26 -0000 If there is a tag (anyone), it's 4244bis.=20 If there is none, it's 4244. > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Monday, July 13, 2009 17:00 > To: Audet, Francois (SC100:3055); SIPCORE > Subject: RE: rfc4244bis: Open Issues >=20 >=20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Monday, July 13, 2009 7:06 PM > >=20 > > You need to distinguish between "old RFC 4244" and new. > >=20 > > The presence of the tag tells you it's new 4244. >=20 > You lost me - the presence of which tag tells you it's old=20 > vs. new, and why would you care? You mean the presence of=20 > any tag? And thus you have tags that are added so that they=20 > can be distinguished from non-tagged HI-entries?? [at this=20 > point my brain explodes] >=20 > -hadriel >=20 From root@core3.amsl.com Mon Jul 13 17:15:01 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 35E4928C0FE; Mon, 13 Jul 2009 17:15:00 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090714001501.35E4928C0FE@core3.amsl.com> Date: Mon, 13 Jul 2009 17:15:01 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D ACTION:draft-ietf-sipcore-location-conveyance-01.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, 14 Jul 2009 00:15:01 -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 : Location Conveyance for the Session Initiation Protocol Author(s) : J. Polk, B. Rosen Filename : draft-ietf-sipcore-location-conveyance-01.txt Pages : 48 Date : 2009-7-13 This document defines an extension to the Session Initiation Protocol (SIP) to convey geographic location information from one SIP entity to another SIP entity. The extension covers end-to-end conveyance as well as location-based routing, where SIP servers make routing decisions based on the location of the user agent client. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-01.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-location-conveyance-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-7-13170048.I-D@ietf.org> --NextPart-- From gao.yang2@zte.com.cn Mon Jul 13 17:17:13 2009 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 B251728C666 for ; Mon, 13 Jul 2009 17:17:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.276 X-Spam-Level: X-Spam-Status: No, score=-96.276 tagged_above=-999 required=5 tests=[AWL=0.717, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 jXWvEFEA550n for ; Mon, 13 Jul 2009 17:17:12 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 3216628C6EB for ; Mon, 13 Jul 2009 17:15:16 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 91101727820181; Tue, 14 Jul 2009 08:02:48 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 12012.6637927919; Tue, 14 Jul 2009 08:08:42 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n6E0FhZW095086; Tue, 14 Jul 2009 08:15:43 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <5DCA03A790E168shin@softfront.co.jp> To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 14 Jul 2009 08:15:35 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-14 08:15:42, Serialize complete at 2009-07-14 08:15:42 Content-Type: multipart/alternative; boundary="=_alternative 00016DE0482575F3_=" X-MAIL: mse1.zte.com.cn n6E0FhZW095086 Cc: SIPCORE Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ICBOZXcgcmV2aXNpb24gb2YgdGhlIHJl?= =?gb2312?b?LUlOVklURSBoYW5kbGluZyBkcmFmdA==?= 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, 14 Jul 2009 00:17:13 -0000 This is a multipart message in MIME format. --=_alternative 00016DE0482575F3_= Content-Type: text/plain; charset="US-ASCII" Hi Shinji, By RFC3311, the target refresh UPDATE can refresh the ongoing Re-INVITE, as below: UPDATE is a target refresh request. As specified in RFC 3261 [1], this means that it can update the remote target of a dialog. If a UA uses an UPDATE request or response to modify the remote target while an INVITE transaction is in progress, and it is a UAS for that INVITE transaction, it MUST place the same value into the Contact header field of the 2xx to the INVITE that it placed into the UPDATE request or response. And then, we can get the correct session state by the way proposed in draft-camarillo-sipcore-reinvite-00. Gao >A difficult case is where a reINVITE has been initiated, and has not >completed. (Perhaps its ringing.) Then the UAC loses its IP address or >IP connectivity and needs to make a target change. So it sends an UPDATE >with the target change. What it should probably do in that case is *not* >include an offer in the UPDATE. Then it can't be rejected for o/a >reasons. Once that is done it can continue the o/a process, updating its >media addresses when it has the chance. Once the UAC target has changed, >the UAS should not fail the INVITE. If need be it should reject all the >media in order to avoid that. At this point, IP Address of the UAC has be changed, so the responce of the reINVITE request could probably not be returned to the UAC. And then reINVITE client transaction would return a timeout. Rather it would be better to CANCEL it. Altogether UPDATE transaction SHOULD be excluded from the rollback, I think now. -------------------------------------------------------- ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. This message has been scanned for viruses and Spam by ZTE Anti-Spam system. --=_alternative 00016DE0482575F3_= Content-Type: text/html; charset="US-ASCII"
Hi Shinji,

By RFC3311, the target refresh UPDATE can refresh the ongoing Re-INVITE, as below:

UPDATE is a target refresh request. As specified in RFC 3261 [1],
   this means that it can update the remote target of a dialog. If a UA
   uses an UPDATE request or response to modify the remote target while
   an INVITE transaction is in progress, and it is a UAS for that INVITE
   transaction, it MUST place the same value into the Contact header
   field of the 2xx to the INVITE that it placed into the UPDATE request
   or response.

And then, we can get the correct session state by the way proposed in
draft-camarillo-sipcore-reinvite-00.

Gao



>A difficult case is where a reINVITE has been initiated, and has not
>completed. (Perhaps its ringing.) Then the UAC loses its IP address or
>IP connectivity and needs to make a target change. So it sends an UPDATE
>with the target change. What it should probably do in that case is *not*
>include an offer in the UPDATE. Then it can't be rejected for o/a
>reasons. Once that is done it can continue the o/a process, updating its
>media addresses when it has the chance. Once the UAC target has changed,
>the UAS should not fail the INVITE. If need be it should reject all the
>media in order to avoid that.

At this point, IP Address of the UAC has be changed, so the
responce of the reINVITE request could probably not be returned
to the UAC. And then reINVITE client transaction would return
a timeout. Rather it would be better to CANCEL it.

Altogether UPDATE transaction SHOULD be excluded from the
rollback, I think now. 

--------------------------------------------------------
ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others.
This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender.
This message has been scanned for viruses and Spam by ZTE Anti-Spam system.
--=_alternative 00016DE0482575F3_=-- From HKaplan@acmepacket.com Mon Jul 13 18:42:18 2009 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 D04003A6DA2 for ; Mon, 13 Jul 2009 18:42:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.57 X-Spam-Level: X-Spam-Status: No, score=-2.57 tagged_above=-999 required=5 tests=[AWL=0.029, 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 Dt+t1g+q72fu for ; Mon, 13 Jul 2009 18:42:18 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C80BF28B56A for ; Mon, 13 Jul 2009 18:42:17 -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.1.375.2; Mon, 13 Jul 2009 21:42:47 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 13 Jul 2009 21:42:45 -0400 From: Hadriel Kaplan To: Francois Audet , SIPCORE Date: Mon, 13 Jul 2009 21:42:41 -0400 Thread-Topic: rfc4244bis: Open Issues Thread-Index: AcoD4RmgYPToplphTNGZX+nUfMAJ3gAGmHWgAABnAtAAA1WScAAAQZAgAAAkWqAAAHnXYAABk5RgAADVmuAAAdtcYA== Message-ID: References: <4A5B7195.6020009@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF51FF9@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EF521C4@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EF52209@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EF522A1@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EF522A1@zrc2hxm0.corp.nortel.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] rfc4244bis: Open Issues 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, 14 Jul 2009 01:42:18 -0000 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, July 13, 2009 8:14 PM >=20 > If there is a tag (anyone), it's 4244bis. > If there is none, it's 4244. Got it. Hate it, but got it. :) You're going to hate this idea too, but oh well... the delete key is in eas= y reach... so here goes: I suggest an explicit version tag. The tag appears not in the header field= itself, but in something called a "header-name" part of an "extension-head= er" in ABNF rules per rfc3261. I suggest a new "header-name" value of "R-H= istory-Info". You can pretend the "R" is for Retargeted-History-Info, or R= educed-History-Info, or Revisionist-History-Info. :) This "R-History-Info" extension-header is a multi-instance type, and a Prox= y only ever adds to it if it is changing the received req-uri *and* would h= ave set the "mp" flag for the new URI it is adding. The first RHI entry is= added by the first proxy or UAC based on what it received, like in H-I, ev= en though it's not retargeting to that URI. The extension-header's header-= value is the URI being retargeted to. There are no currently defined heade= r parameters. This RHI header field is not for troubleshooting - it's for actual processi= ng use. Therefore, there is no incrementing index param, no embedded Reaso= n header, and no entries created for anything but retargeted events and the= ir new URI's (and the first one). Privacy does not apply to this on a head= er-by-header basis, and thus there is no embedded Privacy header either - i= f Privacy:history was requested, no RHI fields would be created. Compared with RFC 4244, the RHI header field would produce a smaller subset= of header instances. In some cases significantly smaller. For example, i= n the most common case, only a single RHI header field would be in the mess= age, regardless of how many proxies were crossed. There is also less proce= ssing overhead for every node in the message path. It should be noted that, like RFC 4244, RHI does not produce the smallest l= ist possible of retargets - in some cases an entry is added when the target= user Identity has not changed - the URI has changed to a new one, but unbe= knownst to the Proxy which added it, the Identity of the human may have rem= ained the same. For example an entry for "sip:Robert.Khaled@example.com" a= nd a subsequent entry for "sip:bob@sales.example.com" may both have been ad= ded, even though they are the same abstract target human. A proxy cannot k= now by default that these two targets are the same identity. Only the UAS = would know that, and so it may need to cull the list down further. -hadriel From shin@softfront.co.jp Mon Jul 13 19:32:55 2009 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 6F59F3A6E11 for ; Mon, 13 Jul 2009 19:32:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.201 X-Spam-Level: **** X-Spam-Status: No, score=4.201 tagged_above=-999 required=5 tests=[AWL=-0.946, BAYES_40=-0.185, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_52=0.6, RELAY_IS_221=2.222, UNPARSEABLE_RELAY=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 5zG2lIhKc4Zj for ; Mon, 13 Jul 2009 19:32:54 -0700 (PDT) Received: from mail2.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with SMTP id 590A63A68CF for ; Mon, 13 Jul 2009 19:32:54 -0700 (PDT) Received: from softfront.co.jp by mail2.softfront.co.jp id AA04596 ; 14 Jul 2009 11:33:13 +0900 From: OKUMURA Shinji To: SIPCORE Date: Tue, 14 Jul 2009 11:33:10 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.18 (WinNT,501) In-Reply-To: References: Message-Id: <98CA042B6E0BABshin@softfront.co.jp> Cc: gao.yang2@zte.com.cn Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 14 Jul 2009 02:32:55 -0000 Hi Gao, Do you mean that the session state of the UPDATE transaction is NOT excluded from the rollback, but the dialog state(ie remote target) is excluded from the rollback? gao.yang2@zte.com.cn >Hi Shinji, > >By RFC3311, the target refresh UPDATE can refresh the ongoing Re-INVITE, >as below: > >UPDATE is a target refresh request. As specified in RFC 3261 [1], > this means that it can update the remote target of a dialog. If a UA > uses an UPDATE request or response to modify the remote target while > an INVITE transaction is in progress, and it is a UAS for that INVITE > transaction, it MUST place the same value into the Contact header > field of the 2xx to the INVITE that it placed into the UPDATE request > or response. the above statement means that the 2xx to the INVITE include the same Contact header of the UPDATE request or response. But UPDATE does not modify the Via header of 2xx. Regards, Shinji >And then, we can get the correct session state by the way proposed in >draft-camarillo-sipcore-reinvite-00. > >Gao From gao.yang2@zte.com.cn Mon Jul 13 20:31:25 2009 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 05B6D3A6839 for ; Mon, 13 Jul 2009 20:31:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.113 X-Spam-Level: X-Spam-Status: No, score=-94.113 tagged_above=-999 required=5 tests=[AWL=-4.523, BAYES_50=0.001, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 AvuX2SDYY-wq for ; Mon, 13 Jul 2009 20:31:24 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 383263A67B6 for ; Mon, 13 Jul 2009 20:31:22 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 111641727820181; Tue, 14 Jul 2009 11:14:40 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.99] with StormMail ESMTP id 89631.3579431720; Tue, 14 Jul 2009 11:24:14 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n6E3Vo9x022236; Tue, 14 Jul 2009 11:31:50 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <98CA042B6E0BABshin@softfront.co.jp> To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 14 Jul 2009 11:31:39 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-14 11:31:47, Serialize complete at 2009-07-14 11:31:47 Content-Type: multipart/alternative; boundary="=_alternative 0013617F482575F3_=" X-MAIL: mse1.zte.com.cn n6E3Vo9x022236 Cc: SIPCORE Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ICBOZXcgcmV2aXNpb24gb2YgdGhlIHJl?= =?gb2312?b?LUlOVklURSBoYW5kbGluZyBkcmFmdA==?= 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, 14 Jul 2009 03:31:25 -0000 This is a multipart message in MIME format. --=_alternative 0013617F482575F3_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgU2hpbmppLA0KDQpUYXJnZXQgZnJlc2g6DQpPbmUgdGFyZ2V0IGZyZXNoIGlzIGluIGp1c3Qg b25lIHNpcCB0cmFuc2FjdGlvbiwgbm90IGxpa2Ugc2Vzc2lvbiANCm1vZGlmaWNhdGlvbiBjYW4g b3ZlcmxhcCBtb3JlIHRoYW4gb25lIHNpcCB0cmFuc2FjdGlvbihzdWNoIGFzIA0KcHJlY29uZGl0 aW9uKS4NClNvLCBldmVuIHRoZSBvbmdvaW5nIElOVklURS9SZS1JTlZJVEUgaGFzIHRhcmdldCBm cmVzaCwgdGhlIHRhcmdldCBmcmVzaCANCmluIHRoZSBVUERBVEUgaXMgYSB3aG9sZSBuZXcgb25l LiBBcyBpdCBpcyBhIHdob2xlIG5ldyBvbmUsIG5vdCBwYXJ0IA0Kb2YgdGhlIG9yaWdpbmFsIG9u ZSwgc28gdGhlIHRhcmdldCBmcmVzaCBpbiB0aGUgVVBEQVRFIG11c3Qgbm90IA0KKnJvbGxiYWNr Ki4NCg0KU2Vzc2lvbiBtb2RpZmljYXRpb246DQpXaGVuIHRoZSBPL0EgaW4gVVBEQVRFLzIwME9L IGlzIHBhcnQgb2YgdGhlIG9uZSB0cmlnZ2VyZWQgYnkgDQpJTlZJVEUvUmUtSU5WSVRFLCBpdCBp cyBOT1QgZXhjbHVkZWQgZnJvbSB0aGUgcm9sbGJhY2suIEJ1dCB3aGVuIHRoZSBPL0EgDQppbiAN ClVQREFURS8yMDBPSyBpcyBhIHdob2xlIG5ldyBvbmUsIElNTywgaXQgc2hvdWxkIGV4Y2x1ZGVk IGZyb20gdGhlIA0Kcm9sbGJhY2suDQoNCkJUVywNCkEgc3RhbmRhcmQgcmVndWxhdGlvbiBpcyBy ZWFsbHkgbmVlZGVkIHRvIGVuZCB0aGUgdmVyeSBsb25nIHNlc3Npb24gc3RhdGUgDQpkaXNjdXNz aW9uLg0KDQpBbmQgYXMgd2Ugc2hvdWxkIGhhcyBhIGRldGFpbGVkIGNsYXNzaWZpY2F0aW9uIG9m IHdoaWNoIE8vQSBpcyBwYXJ0IG9mIHRoZSANCm9uZSB0cmlnZ2VyZWQgYnkgSU5WSVRFL1JlLUlO VklURSBhbmQgd2hpY2ggaXMgbm90LCBpZiB3ZSBjaG9vc2UgdGhpcyB3YXkgDQp0byANCnNvbHZl IHRoZSBzZXNzaW9uIHN0YXRlIHByb2JsbSwgbm93IEkgc3VwcG9ydCANCmRyYWZ0LWNhbWFyaWxs by1zaXBjb3JlLXJlaW52aXRlLTAwLiBJJ2QgbGlrZSB0byBjb25jZW50cmF0ZSBvbiB0aGlzIA0K c29sdXRpb24uKEkgZG8gbm90IG1lYW4gYW55IHJlc3RyaWN0IG9uIGFueSB0YWxraW5nIGFyb3Vu ZCBteSBvcmlnaW5hbCANCnByb3Bvc2FsIDopKQ0KDQpUaGFua3MuDQoNCkdhbw0KDQo9PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIFppcCAgICA6IDIxMDAxMg0KIFRlbCAgICA6 IDg3MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCiBlX21haWwgOiBnYW8ueWFuZzJA enRlLmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQoNCk9L VU1VUkEgU2hpbmppIDxzaGluQHNvZnRmcm9udC5jby5qcD4gDQoyMDA5LTA3LTE0IDEwOjMzDQoN CsrVvP7Iyw0KU0lQQ09SRSA8c2lwY29yZUBpZXRmLm9yZz4NCrOty80NCmdhby55YW5nMkB6dGUu Y29tLmNuDQrW98ziDQpSZTogW3NpcGNvcmVdIE5ldyByZXZpc2lvbiBvZiB0aGUgcmUtSU5WSVRF IGhhbmRsaW5nIGRyYWZ0DQoNCg0KDQoNCg0KDQpIaSBHYW8sDQoNCkRvIHlvdSBtZWFuIHRoYXQg dGhlIHNlc3Npb24gc3RhdGUgb2YgdGhlIFVQREFURSB0cmFuc2FjdGlvbiBpcyBOT1QNCmV4Y2x1 ZGVkIGZyb20gdGhlIHJvbGxiYWNrLCBidXQgdGhlIGRpYWxvZyBzdGF0ZShpZSByZW1vdGUgdGFy Z2V0KQ0KaXMgZXhjbHVkZWQgZnJvbSB0aGUgcm9sbGJhY2s/DQoNCmdhby55YW5nMkB6dGUuY29t LmNuDQo+SGkgU2hpbmppLA0KPg0KPkJ5IFJGQzMzMTEsIHRoZSB0YXJnZXQgcmVmcmVzaCBVUERB VEUgY2FuIHJlZnJlc2ggdGhlIG9uZ29pbmcgUmUtSU5WSVRFLCANCj5hcyBiZWxvdzogDQo+DQo+ VVBEQVRFIGlzIGEgdGFyZ2V0IHJlZnJlc2ggcmVxdWVzdC4gQXMgc3BlY2lmaWVkIGluIFJGQyAz MjYxIFsxXSwNCj4gICB0aGlzIG1lYW5zIHRoYXQgaXQgY2FuIHVwZGF0ZSB0aGUgcmVtb3RlIHRh cmdldCBvZiBhIGRpYWxvZy4gSWYgYSBVQQ0KPiAgIHVzZXMgYW4gVVBEQVRFIHJlcXVlc3Qgb3Ig cmVzcG9uc2UgdG8gbW9kaWZ5IHRoZSByZW1vdGUgdGFyZ2V0IHdoaWxlDQo+ICAgYW4gSU5WSVRF IHRyYW5zYWN0aW9uIGlzIGluIHByb2dyZXNzLCBhbmQgaXQgaXMgYSBVQVMgZm9yIHRoYXQgSU5W SVRFDQo+ICAgdHJhbnNhY3Rpb24sIGl0IE1VU1QgcGxhY2UgdGhlIHNhbWUgdmFsdWUgaW50byB0 aGUgQ29udGFjdCBoZWFkZXINCj4gICBmaWVsZCBvZiB0aGUgMnh4IHRvIHRoZSBJTlZJVEUgdGhh dCBpdCBwbGFjZWQgaW50byB0aGUgVVBEQVRFIHJlcXVlc3QNCj4gICBvciByZXNwb25zZS4NCg0K dGhlIGFib3ZlIHN0YXRlbWVudCBtZWFucyB0aGF0IHRoZSAyeHggdG8gdGhlIElOVklURSBpbmNs dWRlIHRoZSBzYW1lDQpDb250YWN0IGhlYWRlciBvZiB0aGUgVVBEQVRFIHJlcXVlc3Qgb3IgcmVz cG9uc2UuIEJ1dCBVUERBVEUgZG9lcyBub3QNCm1vZGlmeSB0aGUgVmlhIGhlYWRlciBvZiAyeHgu DQoNClJlZ2FyZHMsDQpTaGluamkNCg0KPkFuZCB0aGVuLCB3ZSBjYW4gZ2V0IHRoZSBjb3JyZWN0 IHNlc3Npb24gc3RhdGUgYnkgdGhlIHdheSBwcm9wb3NlZCBpbiANCj5kcmFmdC1jYW1hcmlsbG8t c2lwY29yZS1yZWludml0ZS0wMC4gDQo+DQo+R2FvDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlv biBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWls IGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1h aWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUg YXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0 byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4N ClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRl bnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBv ciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUg bWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9m IHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZv ciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 0013617F482575F3_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFNoaW5qaSw8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRhcmdldCBmcmVzaDo8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPk9uZSB0YXJnZXQgZnJlc2gg aXMgaW4ganVzdCBvbmUgc2lwDQp0cmFuc2FjdGlvbiwgbm90IGxpa2Ugc2Vzc2lvbiBtb2RpZmlj YXRpb24gY2FuIG92ZXJsYXAgbW9yZSB0aGFuIG9uZSBzaXANCnRyYW5zYWN0aW9uKHN1Y2ggYXMg cHJlY29uZGl0aW9uKS48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi PlNvLCBldmVuIHRoZSBvbmdvaW5nIElOVklURS9SZS1JTlZJVEUNCmhhcyB0YXJnZXQgZnJlc2gs IHRoZSB0YXJnZXQgZnJlc2ggaW4gdGhlIFVQREFURSBpcyBhIHdob2xlIG5ldyBvbmUuIDxiPkFz DQppdCBpcyBhIHdob2xlIG5ldyBvbmUsIG5vdCBwYXJ0IDwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjxiPm9mIHRoZSBvcmlnaW5hbCBvbmUsIHNvIHRoZSB0 YXJnZXQNCmZyZXNoIGluIHRoZSBVUERBVEUgbXVzdCBub3QgKnJvbGxiYWNrKi48L2I+PC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5TZXNzaW9uIG1vZGlm aWNhdGlvbjo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldoZW4g dGhlIE8vQSBpbiBVUERBVEUvMjAwT0sgaXMgcGFydA0Kb2YgdGhlIG9uZSB0cmlnZ2VyZWQgYnkg SU5WSVRFL1JlLUlOVklURSwgaXQgPC9mb250Pjxmb250IHNpemU9Mj48dHQ+aXMNCk5PVCBleGNs dWRlZCBmcm9tIHRoZSByb2xsYmFjay4gQnV0IHdoZW4gdGhlIDwvdHQ+PC9mb250Pjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5PL0ENCmluIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+VVBEQVRFLzIwME9LPC9mb250Pjxmb250IHNpemU9Mj48dHQ+DQpp cyBhIHdob2xlIG5ldyBvbmUsIElNTywgaXQgc2hvdWxkIGV4Y2x1ZGVkIGZyb20gdGhlIHJvbGxi YWNrLjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+QlRXLDwvdHQ+PC9m b250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+QSBzdGFuZGFyZCByZWd1bGF0aW9uIGlzIHJlYWxs eSBuZWVkZWQgdG8gZW5kIHRoZQ0KdmVyeSBsb25nIHNlc3Npb24gc3RhdGUgZGlzY3Vzc2lvbi48 L3R0PjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PkFuZCBhcyB3ZSBzaG91bGQg aGFzIGEgZGV0YWlsZWQgY2xhc3NpZmljYXRpb24gb2YNCndoaWNoIE8vQSBpcyBwYXJ0IG9mIHRo ZSA8L3R0PjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+b25lDQp0cmlnZ2Vy ZWQgYnkgSU5WSVRFL1JlLUlOVklURTwvZm9udD48Zm9udCBzaXplPTI+PHR0PiBhbmQgd2hpY2gg aXMgbm90LA0KaWYgd2UgY2hvb3NlIHRoaXMgd2F5IHRvIDwvdHQ+PC9mb250Pg0KPGJyPjxmb250 IHNpemU9Mj48dHQ+c29sdmUgdGhlIHNlc3Npb24gc3RhdGUgcHJvYmxtLCBub3cgSSBzdXBwb3J0 IGRyYWZ0LWNhbWFyaWxsby1zaXBjb3JlLXJlaW52aXRlLTAwLg0KSSdkIGxpa2UgdG8gY29uY2Vu dHJhdGUgb24gdGhpcyBzb2x1dGlvbi4oSSBkbyBub3QgbWVhbiBhbnkgcmVzdHJpY3Qgb24NCmFu eSB0YWxraW5nIGFyb3VuZCBteSBvcmlnaW5hbCBwcm9wb3NhbCA6KSk8L3R0PjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTI+PHR0PlRoYW5rcy48L3R0PjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTI+PHR0PkdhbzwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4N CiBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0KIFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIx MTxicj4NCiBUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3MjExPGJyPg0KIGVfbWFpbCA6IGdh by55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+ T0tVTVVSQSBTaGluamkgJmx0O3NoaW5Ac29mdGZyb250LmNvLmpwJmd0OzwvYj4NCjwvZm9udD4N CjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDA5LTA3LTE0IDEwOjMzPC9mb250 Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8 dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+ yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlNJUENP UkUgJmx0O3NpcGNvcmVAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5nYW8ueWFuZzJA enRlLmNvbS5jbjwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtzaXBjb3JlXSBOZXcgcmV2aXNpb24g b2YgdGhlIHJlLUlOVklURQ0KaGFuZGxpbmcgZHJhZnQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0 YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4N Cjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PkhpIEdhbyw8YnI+DQo8YnI+DQpEbyB5 b3UgbWVhbiB0aGF0IHRoZSBzZXNzaW9uIHN0YXRlIG9mIHRoZSBVUERBVEUgdHJhbnNhY3Rpb24g aXMgTk9UPGJyPg0KZXhjbHVkZWQgZnJvbSB0aGUgcm9sbGJhY2ssIGJ1dCB0aGUgZGlhbG9nIHN0 YXRlKGllIHJlbW90ZSB0YXJnZXQpPGJyPg0KaXMgZXhjbHVkZWQgZnJvbSB0aGUgcm9sbGJhY2s/ PGJyPg0KPGJyPg0KZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQomZ3Q7SGkgU2hpbmppLDxicj4N CiZndDs8YnI+DQomZ3Q7QnkgUkZDMzMxMSwgdGhlIHRhcmdldCByZWZyZXNoIFVQREFURSBjYW4g cmVmcmVzaCB0aGUgb25nb2luZyBSZS1JTlZJVEUsDQo8YnI+DQomZ3Q7YXMgYmVsb3c6IDxicj4N CiZndDs8YnI+DQomZ3Q7VVBEQVRFIGlzIGEgdGFyZ2V0IHJlZnJlc2ggcmVxdWVzdC4gQXMgc3Bl Y2lmaWVkIGluIFJGQyAzMjYxIFsxXSw8YnI+DQomZ3Q7ICZuYnNwOyB0aGlzIG1lYW5zIHRoYXQg aXQgY2FuIHVwZGF0ZSB0aGUgcmVtb3RlIHRhcmdldCBvZiBhIGRpYWxvZy4NCklmIGEgVUE8YnI+ DQomZ3Q7ICZuYnNwOyB1c2VzIGFuIFVQREFURSByZXF1ZXN0IG9yIHJlc3BvbnNlIHRvIG1vZGlm eSB0aGUgcmVtb3RlIHRhcmdldA0Kd2hpbGU8YnI+DQomZ3Q7ICZuYnNwOyBhbiBJTlZJVEUgdHJh bnNhY3Rpb24gaXMgaW4gcHJvZ3Jlc3MsIGFuZCBpdCBpcyBhIFVBUyBmb3IgdGhhdA0KSU5WSVRF PGJyPg0KJmd0OyAmbmJzcDsgdHJhbnNhY3Rpb24sIGl0IE1VU1QgcGxhY2UgdGhlIHNhbWUgdmFs dWUgaW50byB0aGUgQ29udGFjdA0KaGVhZGVyPGJyPg0KJmd0OyAmbmJzcDsgZmllbGQgb2YgdGhl IDJ4eCB0byB0aGUgSU5WSVRFIHRoYXQgaXQgcGxhY2VkIGludG8gdGhlIFVQREFURQ0KcmVxdWVz dDxicj4NCiZndDsgJm5ic3A7IG9yIHJlc3BvbnNlLjxicj4NCjxicj4NCnRoZSBhYm92ZSBzdGF0 ZW1lbnQgbWVhbnMgdGhhdCB0aGUgMnh4IHRvIHRoZSBJTlZJVEUgaW5jbHVkZSB0aGUgc2FtZTxi cj4NCkNvbnRhY3QgaGVhZGVyIG9mIHRoZSBVUERBVEUgcmVxdWVzdCBvciByZXNwb25zZS4gQnV0 IFVQREFURSBkb2VzIG5vdDxicj4NCm1vZGlmeSB0aGUgVmlhIGhlYWRlciBvZiAyeHguPGJyPg0K PGJyPg0KUmVnYXJkcyw8YnI+DQpTaGluamk8YnI+DQo8YnI+DQomZ3Q7QW5kIHRoZW4sIHdlIGNh biBnZXQgdGhlIGNvcnJlY3Qgc2Vzc2lvbiBzdGF0ZSBieSB0aGUgd2F5IHByb3Bvc2VkDQppbiA8 YnI+DQomZ3Q7ZHJhZnQtY2FtYXJpbGxvLXNpcGNvcmUtcmVpbnZpdGUtMDAuIDxicj4NCiZndDs8 YnI+DQomZ3Q7R2FvPGJyPg0KPGJyPg0KPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpa VEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZu YnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFp bCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNw O3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29t bXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJz cDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDtt YWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJt aXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtv ZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlz Jm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVk Jm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5i c3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtv ZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5i c3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5 b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZu YnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRv ciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNw O2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0 aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMm bmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJz cDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1T cGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 0013617F482575F3_=-- From HKaplan@acmepacket.com Mon Jul 13 21:00:53 2009 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 CF3713A699F for ; Mon, 13 Jul 2009 21:00:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.571 X-Spam-Level: X-Spam-Status: No, score=-2.571 tagged_above=-999 required=5 tests=[AWL=0.028, 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 m2YvXv-xwZPB for ; Mon, 13 Jul 2009 21:00:53 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E5E233A68D5 for ; Mon, 13 Jul 2009 21:00:52 -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.1.375.2; Tue, 14 Jul 2009 00:01:21 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 14 Jul 2009 00:01:21 -0400 From: Hadriel Kaplan To: Francois Audet , Dean Willis Date: Tue, 14 Jul 2009 00:01:19 -0400 Thread-Topic: [sipcore] rfc4244bis: what is "aor" used for? Thread-Index: AcoEDqM/XIENvO+JQM+deNhoIRK3fQAAKw3QAAbzRkA= Message-ID: References: <4A5B7195.6020009@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com> <4A5BBE0C.5000301@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.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 Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 14 Jul 2009 04:00:53 -0000 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, July 13, 2009 7:19 PM >=20 > I assume your question is for "target URI" specifically. > You would look at the las entry that is not a "rc/cc/rt". > Bingo. Which is the set of "mp", no? =20 Note though that this set's last member is not *necessarily* the one Target= -URI wants - it's the set/list it must walk through (in reverse order of th= e H-I list of "mp" ones) to find the Target-URI. As it walks the list, if = the local UAS believes it represents the URI, it keeps walking backwards - = when it finds one it does not represent, it stops walking up the list and u= ses the last one it found that it *does* represent. That one is the "Targe= t-URI". The UAS knows it "represents" one if it either (a) Registers that URI, or (= b) learned it through P-Associated-URI, or (c) it learned or created a GRUU= for itself, or (d) has some provisioned knowledge that it also represents = that URI. =20 > Now, your question was loaded. You said "universal" but clearly, > it's not Universal because your are strictly looking at solving the > TargetURI problem. Furthermore, you are strictly trying to solve the > LAST targetURI problem. There are applications that do not use the LAST > but the > FIRST targetURI (for example). Lots of Voice mail systems, again, for > example, do this. > Therefore, it's not Universal. Right it's not universal, and no universal algorithm can find the right URI= for all application uses. But I think we can (and should) document what a= lgorithms should be used for the most common applications, so that there's = no confusion on the part of different implementations? (or even just to pro= vide guidance?) For example, a Voicemail system would NOT use the FIRST "mp" entry in the l= ist, nor the LAST. It needs to walk the list backwards to find the closest= "mp" to the end that it can use. Otherwise, a retarget from Alice to Bob = will go to Alice's voicemail, when it should have gone to Bob's. No? -hadriel From shin@softfront.co.jp Mon Jul 13 23:05:34 2009 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 22D563A6C83 for ; Mon, 13 Jul 2009 23:05:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.852 X-Spam-Level: ** X-Spam-Status: No, score=2.852 tagged_above=-999 required=5 tests=[AWL=0.719, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, UNPARSEABLE_RELAY=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 6QxMGj+wxCmZ for ; Mon, 13 Jul 2009 23:05:32 -0700 (PDT) Received: from mail2.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with SMTP id 90E323A69B4 for ; Mon, 13 Jul 2009 23:05:31 -0700 (PDT) Received: from softfront.co.jp by mail2.softfront.co.jp id AA04624 ; 14 Jul 2009 15:04:32 +0900 From: OKUMURA Shinji To: SIPCORE Date: Tue, 14 Jul 2009 15:04:30 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.18 (WinNT,501) In-Reply-To: <4A5741A9.8030200@cisco.com> References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com> <8CA0129D1A650shin@softfront.co.jp> <4A5741A9.8030200@cisco.com> Message-Id: Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 14 Jul 2009 06:05:34 -0000 Hi Paul, Paul Kyzivat > > >OKUMURA Shinji wrote: > >> But at this point, I have one doubt. >> May precondition procedure be started by UPDATE? > >IMO yes it may. But perhaps it SHOULD NOT ??? > >I think it has always been possible to initiate an in-dialog o/a >exchange, with or without preconditions, using UPDATE rather than reINVITE. > >I guess it would also be possible to start an INVITE/reINVITE without >preconditions, and then initiate the use of preconditions with an >UPDATE. But I can't think of any good reason why you would want to do that. >>if all changes executed by UPDATE transactions are excluded from the >>rollback, and if it is precondition case, both UAs need to start new O/A with precondition. At that time, which should UA send new UPDATE or new reINVITE ? Because user confirmation for the rollback is not necessary, I think reINVITE is not necessary. but I'm not sure. Regards, Shinji >AFAIK there are only a couple of places where UPDATE is needed, or >preferable alternatives: > >- its needed by UAC for 2nd and subsequent rounds of O/A exchange > within an INVITE. > >- its good for a dialog refresh/target refresh when you *don't* > want to do a new O/A. > >Other uses can be accomplished other ways. > > Thanks, > Paul From shin@softfront.co.jp Mon Jul 13 23:34:45 2009 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 212DF3A69B4 for ; Mon, 13 Jul 2009 23:34:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.749 X-Spam-Level: ** X-Spam-Status: No, score=2.749 tagged_above=-999 required=5 tests=[AWL=0.616, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, UNPARSEABLE_RELAY=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 ISXSZUWZRKSz for ; Mon, 13 Jul 2009 23:34:44 -0700 (PDT) Received: from mail2.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with SMTP id D3DFB3A68F5 for ; Mon, 13 Jul 2009 23:34:26 -0700 (PDT) Received: from softfront.co.jp by mail2.softfront.co.jp id AA02988 ; 14 Jul 2009 15:32:34 +0900 From: OKUMURA Shinji To: SIPCORE Date: Tue, 14 Jul 2009 15:32:32 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.18 (WinNT,501) Message-Id: Subject: [sipcore] RPR and remote target 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, 14 Jul 2009 06:34:45 -0000 Hi, Although this might already have been discussed, I have one doubt about a remote target. Do reINVITE request and reliable provisional responce refresh a remote target? If it is true, altogether I think -- draft-holmberg-sipping-reINVITE-rollback-00 -- The text is clarified, to indicated that session parameter updates that have been successfully commited during the duration of the re- INVITE transaction are not rolled back in case the re-INVITE fails. Has this draft expired? Regards, Shinji From john.elwell@siemens-enterprise.com Mon Jul 13 23:42:10 2009 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 372943A69E3 for ; Mon, 13 Jul 2009 23:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.581 X-Spam-Level: X-Spam-Status: No, score=-2.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 lpWPPPnySNRh for ; Mon, 13 Jul 2009 23:42:09 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 4DD2B3A6830 for ; Mon, 13 Jul 2009 23:42:09 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KMR00A06EJ9FP@siemenscomms.co.uk> for sipcore@ietf.org; Tue, 14 Jul 2009 07:40:21 +0100 (BST) Date: Tue, 14 Jul 2009 07:40:19 +0100 From: "Elwell, John" To: "James M. Polk" , sipcore@ietf.org, Brian Rosen Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00221E129@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Confusion over target inSIP location-conveyance - and impact on ECRIT phonebcp Thread-Index: AcoETfR87AVYdgYPQCCBhIDhwjtUog== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [sipcore] Confusion over target inSIP location-conveyance - and impact on ECRIT phonebcp 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, 14 Jul 2009 06:42:10 -0000 In 4.2 it states: "The UAC can use whatever means it knows of to verify/refresh its=20 location information before attempting a new request that includes=20 location." "its location information" suggests that the UAC is the target. In 4.3.3 it states: "This document gives no guidance how this is accomplished, given the=20 number of ways a UAC can learn its location" which suggests similar. Similarly in 6.1: "If a UAC does not learn and store its location locally (a GPS chip)=20 or from the network (DHCP or LLDP-MED), the UAC MAY learn its LbyR=20 URI (from DHCP for example)." Which suggests that a UAC inserts its location, not some other location. And later in 6.1: "If a UAC has already conveyed location in the original request of a=20 transaction, and wants to update its location information ..." In 6.2: "If the LbyR URI is sip:, sips: or pres:, and the UAS wants to learn the UAC's location," In 6.2.1: "This=20 means the SIP server is including its version of where it thinks the UAC is, geographically." In 8: "Conveyance of physical location of a UAC raises privacy concerns" and: "In cases where a session set-up is=20 retargeted based on the location of the UAC initiating the call or=20 SIP MESSAGE," All these many examples illustrate an implication that the location target is the UAC. I am sure there are other places too. I found a couple of places that contradict this. In 6.2 it states: "If there=20 is more than one PIDF-LO with different Target identifiers, then=20 the UAC is merely telling the UAS where more than one Target is, and there should not be any conflict." I think there are other places that mention locations of multiple targets in a request, implying they cannot all be the location of the UAC. And in 6.2.1 it states: "The Location Target identified in=20 the PIDF-LO may or may not be the location inserter, or the=20 generator of the request (the UAC or SIP server)." So we have inconsistency as to whether a conveyed location is that of they UAC or not. One document that relies on location-conveyance is ECRIT's phonebcp. In there, I cannot find any reference to a routing entity looking to see whether a conveyed location has the caller as target or not. It just assumes that this is the case. So if we were to agree that a conveyed location is not necessarily the location of the UAC, this will have impact on phonebcp. John From john.elwell@siemens-enterprise.com Mon Jul 13 23:42:11 2009 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 6DBDF3A6A16 for ; Mon, 13 Jul 2009 23:42:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 qfXxCNJDfz21 for ; Mon, 13 Jul 2009 23:42:10 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id AF1BD3A68DC for ; Mon, 13 Jul 2009 23:42:09 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KMR00A32EJTEK@siemenscomms.co.uk> for sipcore@ietf.org; Tue, 14 Jul 2009 07:40:41 +0100 (BST) Date: Tue, 14 Jul 2009 07:40:39 +0100 From: "Elwell, John" In-reply-to: To: "James M. Polk" , sipcore@ietf.org Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00221E12A@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Use of term "Location Server" in location-conveyance draft Thread-Index: AcoD/OZxkrNd2D9IS86TDz8Zof37zwATWyPA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D00218C372@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00221DBF8@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00221DC12@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00221E0FD@GBNTHT12009MSX.gb002.siemens.net> Cc: "marc Linsner \(mlinsner\)" Subject: Re: [sipcore] Use of term "Location Server" in location-conveyance draft 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, 14 Jul 2009 06:42:11 -0000 =20 > -----Original Message----- > From: James M. Polk [mailto:jmpolk@cisco.com]=20 > Sent: 13 July 2009 22:00 > To: Elwell, John; sipcore@ietf.org > Cc: marc Linsner (mlinsner) > Subject: RE: Use of term "Location Server" in=20 > location-conveyance draft >=20 > At 03:19 PM 7/13/2009, Elwell, John wrote: > > > > > > > -----Original Message----- > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > Sent: 13 July 2009 18:37 > > > To: Elwell, John; sipcore@ietf.org > > > Cc: marc Linsner (mlinsner) > > > Subject: RE: Use of term "Location Server" in > > > location-conveyance draft > > > > > > At 02:15 AM 7/13/2009, Elwell, John wrote: > > > >James, > > > > > > > >It occurs to me we already have the term location=20 > inserter used in > > > >various places in the document, so why don't we stick to=20 > this, rather > > > >than location server, for the UA or proxy that inserts?=20 > Then we could > > > >use the term location server for the server you go to to=20 > dereference > > > >LbyR. > > > > > > I thought about that - but the Geopriv Arch -00 ID just=20 > came out and > > > the 6 authors there decided the LS is the location=20 > inserter in their > > > terminology and the LIS is the dereferencer *but* only if a target > > > wants to dereference their own location. If another=20 > entity wants to > > > dereference your location, it is not a LIS, it's just an LS. > >[JRE] That has always been my understanding. > > > > > > > > I believe this is even more confusing. > > > > > > BTW - the LIS is who provides a target its DHCP or=20 > LLDP-MED or HELD > > > location information too. Meaning, the LIS has to be able to do L2 > > > downloads of LI *and* L7 subscriptions. > > > > > > > > > >I agree with others, by the way, that LIS is not an > > > appropriate term for > > > >the latter. > > > > > > see above, it now *IS* the proper term for the latter,=20 > but only if it > > > is the target that's doing it. > >[JRE] But in the context of sip-location-conveyance, the UAS=20 > or a proxy > >that receives the location will NEVER be the target, so it=20 > will NEVER be > >a LIS when dereferencing occurs. >=20 > that's not true. Conveyance states that a target can take its=20 > location URI and subscribe to it to receive its PIDF-LO. This has=20 > been in there for a while. [JRE] Perhaps NEVER is wrong, but HIGHLY UNLIKELY. Why would Bob's UAC (or a proxy) insert Alice's LbyR into a request sent to Alice, such that Alice's UAS receives Alice's LbyR and attempts to dereference? John >=20 > Now, which entity does the target subscribe to, the LIS or an LS? >=20 > James >=20 >=20 > >John > > > > > > > > > > Talk about shifting roles... > > > > > > > > > >John > > > > > > > > > -----Original Message----- > > > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > > > Sent: 13 July 2009 07:56 > > > > > To: Elwell, John; sipcore@ietf.org > > > > > Cc: marc Linsner (mlinsner) > > > > > Subject: RE: Use of term "Location Server" in > > > > > location-conveyance draft > > > > > > > > > > John > > > > > > > > > > in-line > > > > > > > > > > At 01:20 AM 7/13/2009, Elwell, John wrote: > > > > > >James, > > > > > > > > > > > >I have to say this is mighty confusing. Basically > > > > > location-conveyance is > > > > > >an extension to SIP, and therefore its primary purpose is to > > > > > specify the > > > > > >SIP protocol and the behaviour of the various SIP entities > > > > > involved. To > > > > > >have an important term that sometimes can mean a SIP > > > entity (the SIP > > > > > >entity that inserts the Geolocation header field)=20 > and sometimes > > > > > >something quite unrelated to SIP location conveyance > > > (the entity to > > > > > >which the dereferencing request is sent) strikes me as > > > something we > > > > > >should avoid. > > > > > > > > > > welcome to my world... ugh > > > > > > > > > > >In my opinion we should do one of the following: > > > > > > > > > > > >1. Limit LS to having only one of these meanings, and if > > > necessary > > > > > >introduce a new term for the other case. > > > > > > > > > > I thought we had a server entity term defined that=20 > was just for > > > > > dereferences, called a Location Information Server (LIS), but > > > > > apparently that term was taken (hijacked?) just for Location > > > > > Configuration Protocols (LCPs) like DHCP and=20 > especially HELD. See > > > > > Martin's recent message clarifying this to me. It was > > > news too. I > > > > > say especially HELD because it appears that crew=20 > actually did the > > > > > "taking" deed. > > > > > > > > > > It appears to me that Location Servers that are=20 > essentially peers > > > > > that communicate location values or references in the > > > signaling path > > > > > of the original SIP request is a good delineation. > > > > > > > > > > Then, having another term defining what entity the=20 > location URIs > > > > > point at (i.e., the dereferencing function) should NOT be > > > called the > > > > > same thing, this is what I was calling a LIS=20 > (Location Information > > > > > Server), which had a unique function, storing all the=20 > PIDF-LOs for > > > > > the location targets (prior to any dereferencing). > > > > > > > > > > > If this is not possible because > > > > > >it would conflict with other published documents, then > > > do it locally > > > > > >within sip-location-conveyance using appropriate > > > language ("For the > > > > > >purposes of this document, location server means....") > > > > > > > > > > interesting... that would mean I (or a small group) would > > > be defining > > > > > a small parallel set of terms that do not go anywhere > > > else except in > > > > > the case of Conveyance... > > > > > > > > > > Can I recommend you send this suggestion (with the=20 > WHY!) to Keith > > > > > Drage? He's the doc shepherd for this ID. That will > > > probably go the > > > > > farthest. CCing the chairs would always be a good idea. > > > > > > > > > > I hope to have the final version ready for WGLC before > > > the milestone > > > > > date of Sept 09. > > > > > > > > > > This will take a little thought once it's solved for, but > > > it's pretty > > > > > much a global replace function once we come up with a set of > > > > > terms to use. > > > > > > > > > > -01 of conveyance will be out tomorrow, and Spencer=20 > Dawkins did a > > > > > pretty good job at making it easier to read. He didn't > > > address the > > > > > term confusion though. > > > > > > > > > > This term issue aside, I was hoping this -01 version was > > > the version > > > > > that went to WGLC. > > > > > > > > > > > > > > > >2. Avoid the term LS altogether in this document and > > > define new terms > > > > > >for the various different purposes. > > > > > > > > > > yeah -- that would be what I'd have to do -- if the=20 > chairs and the > > > > > shepherd agree to this. We all can talk live about this > > > in Stockholm > > > > > hopefully. > > > > > > > > > > BTW - if it's not clear yet within this message -- I'm > > > not opposed to > > > > > doing this (because of the confusion associated with=20 > this topic). > > > > > > > > > > James > > > > > > > > > > > > > > > >John > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > From: James M. Polk [mailto:jmpolk@cisco.com] > > > > > > > Sent: 13 July 2009 05:40 > > > > > > > To: Elwell, John; Martin.Thomson@andrew.com;=20 > sipcore@ietf.org > > > > > > > Subject: Re: Use of term "Location Server" in > > > > > > > location-conveyance draft > > > > > > > > > > > > > > john > > > > > > > > > > > > > > Sorry I missed this note earlier... see below > > > > > > > > > > > > > > At 01:37 AM 7/3/2009, Elwell, John wrote: > > > > > > > >The separate thread arising from my review of=20 > the draft has > > > > > > > left me very > > > > > > > >confused about what exactly the term "Location Server" > > > > > means in this > > > > > > > >draft. > > > > > > > > > > > > > > > >The draft itself says: > > > > > > > >" A [RFC3693] defined "Using > > > > > > > > Protocol" describes how a "Location Server" > > > > > transmits a "Location > > > > > > > > Object" to a "Location Recipient" while maintaining > > > > > the contained > > > > > > > > privacy intentions of the Target intact.=20 > This document > > > > > > > describes the > > > > > > > > extension to SIP for how it complies with the > > > Using Protocol > > > > > > > > requirements, where the location server is a=20 > UA or Proxy > > > > > > > Server and > > > > > > > > the Location Recipient is another UA or=20 > Proxy Server." > > > > > > > >My review comments that touched on this subject > > > assumed the above > > > > > > > >definition. > > > > > > > >According to this, the server that the Location > > > > > Recipient goes to to > > > > > > > >dereference the LbyR URI is NOT a Location Server. But > > > > > some of the > > > > > > > >thread messages have suggested it IS a Location Server. > > > > > We cannot use > > > > > > > >the term Location Server to mean two different things. > > > > > Can somebody > > > > > > > >please clarify? > > > > > > > > > > > > > > In Geopriv, a Location Server (LS) is an entity=20 > that transmits > > > > > > > location towards a Location Recipient (LR). This > > > > > transmission might > > > > > > > take that message through another LS before=20 > getting to the LR. > > > > > > > > > > > > > > In SIP terms, a UA or SIP server (of whatever flavor) > > > that inserts > > > > > > > location into a message (as a message body or as a > > > dereferencable > > > > > > > location URI) is an LS. > > > > > > > > > > > > > > A B2BUA that completes a call leg that contains=20 > location, and > > > > > > > regenerates a new SIP request towards another B2BUA or > > > > > UAS with that > > > > > > > location in the new SIP request is also an LS. > > > > > > > > > > > > > > A proxy that inserts a dereferencable location=20 > URI is an LS. > > > > > > > > > > > > > > A proxy that does not insert a dereferencable location > > > > > URI is NOT an > > > > > > > LS (this time). It is basically performing a repeater > > > > > function that > > > > > > > is not defined in Geopriv. > > > > > > > > > > > > > > A UAS that understands location (i.e., something=20 > close to the > > > > > > > Location Conveyance extension) is an LR. A UAS=20 > that receives > > > > > > > location - but does not understand Location Conveyance - > > > > > is not an LR > > > > > > > (because it doesn't do anything with the location except > > > > > > > throw it away). > > > > > > > > > > > > > > A SIP server that retargets a SIP request after viewing > > > > > the contained > > > > > > > location in that SIP request is also an LR, and=20 > because it did > > > > > > > something with the location - I think it can be called an > > > > > LS too (but > > > > > > > some might disagree). > > > > > > > > > > > > > > A good example of this last case is a location source > > > > > based routing > > > > > > > proxy that retargets a R-URI based on the contained > > > > > location within a > > > > > > > SIP request, like say - an INVITE to 911. > > > > > > > > > > > > > > In this case, that proxy is an LR and an LS. The UAC is > > > > > a Location > > > > > > > Generator (LG) and an LS; and the PSAP call center (i.e., > > > > > the UAS for > > > > > > > the call) is an LS. > > > > > > > > > > > > > > Confused? > > > > > > > > > > > > > > :-p > > > > > > > > > > > > > > Geopriv elements change roles based on what they do, > > > or can do. > > > > > > > > > > > > > > The only debatable label here is LG, as the label > > > seems to have > > > > > > > changed since RFC 3693 (Geopriv Requirements) which I > > > > > co-authored - > > > > > > > and the new doc describing the new functions isn't an RFC > > > > > yet, and is > > > > > > > shifting positions with a couple of its definitions > > > lately (i.e., > > > > > > > within the last year). > > > > > > > > > > > > > > James > > > > > > > > > > > > > > > > > > > > > > > > > > > > >John > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > >=20 >=20 From pkyzivat@cisco.com Tue Jul 14 06:42:04 2009 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 A9FC63A68DB for ; Tue, 14 Jul 2009 06:42:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.287 X-Spam-Level: X-Spam-Status: No, score=-6.287 tagged_above=-999 required=5 tests=[AWL=-0.288, BAYES_00=-2.599, J_CHICKENPOX_47=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 xFDYjb+EhsHx for ; Tue, 14 Jul 2009 06:42:03 -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 5E0043A6E8F for ; Tue, 14 Jul 2009 06:42:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEMoXEpAZnme/2dsb2JhbAC3bIgjkC0FhAiBQg X-IronPort-AV: E=Sophos;i="4.42,397,1243814400"; d="scan'208";a="50315438" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 14 Jul 2009 13:41:34 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6EDfYDs006419; Tue, 14 Jul 2009 09:41:34 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6EDfbFa024909; Tue, 14 Jul 2009 13:41:37 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 09:41:34 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 09:41:33 -0400 Message-ID: <4A5C8B0D.6010107@cisco.com> Date: Tue, 14 Jul 2009 09:41:33 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Francois Audet References: <1ECE0EB50388174790F9694F77522CCF1EF5190A@zrc2hxm0.corp.nortel.com> <4A5B71AC.6050502@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EF51BFE@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EF51BFE@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jul 2009 13:41:33.0807 (UTC) FILETIME=[CD30C7F0:01CA0488] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4822; t=1247578894; x=1248442894; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20rfc4244bis=3A=20what=20is=2 0an=20AoR? |Sender:=20 |To:=20Francois=20Audet=20; bh=L6kBXVv8XMZsea6zed8yqYYsticFMtEGTlQsKgPi+no=; b=Ggr4n9zz00D3g/VEnjMrEl/A4OiKHrssIJPOGhpOXvv94O+cGTVvA79xdy 4GzeoXQ6f7cHggcrq8PLerpAufwhDWlVwKTPVpXXreZSlInfiQWvObcTTyq7 Gc7B9Ezi/P; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 14 Jul 2009 13:42:04 -0000 Francois, Maybe we can puzzle this out by examining more use cases. You focused on digit manipulation, which is surely one. But there are others. To spell out the digit manipulation case in more detail: A proxy receives a request with sip R-URI in the domain it is responsible for. It sees that the user part is all digits. (E.g sip:81234@example.net) It then applies some sort of digit map it has been provisioned with (possibly per-caller, possibly per-domain) to transform that into some other more globally unique URI - perhaps an E.164 number in its own domain or some other domain, or a TEL URI. (E.g. sip:+12125551234@example.net;user=phone.) It does the translation and then proceeds based on the result. I agree in this case it is wrong to call the incoming R-URI an AOR. A different case is synonyms or aliases: A proxy responsible for example.net receives a request with R-URI sip:phk@example.net. This is not in its location service. But it has a provisioned alias table that says phk is a synonym for paul.kyzivat, so it translates the R-URI to sip:paul.kyzivat@example.net. It then proceeds to process that, which turns out to be in its location service, so it translates it again to sip:line1@phone1.paulk.example.net. Again, I don't think sip:phk@example.net is an AoR in this case. Another case, for forwarding: A proxy responsible for example.net receives a request with R-URI of sip:paul.kyzivat@example.net. There is a location service with an entry registered for sip:line1@phone1.paulk.example.net, but there is also provisioning independent of the location service that says to unconditionally forward all calls to this URI to sip:audet@nortel.com. This is accomplished by R-URI translation. (To ensure that the request will not be rejected as mis-addressed.) In this case I think that sip:paul.kyzivat@example.net *is* an AoR. And one final forwarding case: A proxy responsible for example.net receives a request with R-URI of sip:alice.smith@example.net. Alice used to work for Example Co, but she no longer does, so her URI is "out of service". But the proxy has been provisioned to translate the R-URI of Alice's calls to her old boss' URI: sip:betty.jones@example.net. There will never be an entry in the location service for alice, registrations are not permitted. In this case, in spite of there being no location service involved, I still think sip:alice.smith@example.net is an AoR. So, IMO the bottom line is that whether a URI is an AoR is a policy decision within the domain of the URI. Thanks, Paul Francois Audet wrote: > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Monday, July 13, 2009 10:41 >> To: Audet, Francois (SC100:3055) >> Cc: Hadriel Kaplan; Hans Erik van Elburg; SIPCORE >> Subject: Re: [sipcore] rfc4244bis: what is an AoR? >> >> >> >> Francois Audet wrote: >>> To me it's crystal clear. >>> >>> If you are the entity (proxy or redirect server) >> responsible for the >>> URI, and you find the entry in your location service, you >> mark as AOR. >>> That means you will now route based on "rules" you have internally, >>> e.g., map it to a contact, etc. >> I think some cases are clear, others not so much: >> >> - If the proxy translates to a contact that it got from a >> location service and that entry was placed there by a REGISTER, >> then the entry should definitely be marked as an AoR > > Agree. > >> - If the proxy translates to a contact that it got from a >> ocation service, and that entry got there somehow other >> than REGISTER, >> then I *think* the entry should still be marked as an AoR. > > Yes, agree. > >> - If the proxy uses some other logic than a "location service" >> to translate the URI, but it might in other cases use the >> location service to translate the URI, then I'm not sure. >> >> - If the proxy never uses a location service for this URI, >> but translates it on some other basis, then again I'm not sure. >> >> One problem here is that the location service is abstract. >> There are things that can be done using it, or in another >> manner. It seems to me that if it *could* have been done with >> a location service lookup, then the result ought to be the >> same whether it is or not. > > I think the last two are the same thing. > Things like digit manipulation and so forth. > > I didn't want to alter (or second-guess) the definition of AOR (which is > the realm of RFC 3261), in this draft. > > I would think that if the proxy doesn't know that it's an AOR, then it shouldn't mark > it as such. So I would expect mechanical digit manipulation to NOT be marked as AOR. > > From mary.barnes@nortel.com Tue Jul 14 07:23:21 2009 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 B5C0928C188 for ; Tue, 14 Jul 2009 07:23:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 KOvJR21RtK0h for ; Tue, 14 Jul 2009 07:23:20 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 8B48028C16D for ; Tue, 14 Jul 2009 07:23:20 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6EEKjI22270; Tue, 14 Jul 2009 14:20:45 GMT 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, 14 Jul 2009 09:22:13 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFA0BC4@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: Open Issues thread-index: AcoD4RmgYPToplphTNGZX+nUfMAJ3gAGmHWgAABnAtAAA1WScAAAQZAgAAAkWqAAAHnXYAABk5RgAADVmuAAAdtcYAAbypqA References: <4A5B7195.6020009@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF51FF9@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EF521C4@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EF52209@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EF522A1@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Hadriel Kaplan" , "Francois Audet" , "SIPCORE" Subject: Re: [sipcore] rfc4244bis: Open Issues 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, 14 Jul 2009 14:23:21 -0000 We did consider a version tag (slightly different approach than what you suggest), but in the end the current approach is far simpler than what you suggest and far more inline with the basic extensibility mechanism that was put in 4244. Your proposal takes us back to day one and just defining a new header altogether. Mary.=20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Hadriel Kaplan Sent: Monday, July 13, 2009 8:43 PM To: Audet, Francois (SC100:3055); SIPCORE Subject: Re: [sipcore] rfc4244bis: Open Issues > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Monday, July 13, 2009 8:14 PM >=20 > If there is a tag (anyone), it's 4244bis. > If there is none, it's 4244. Got it. Hate it, but got it. :) You're going to hate this idea too, but oh well... the delete key is in easy reach... so here goes: I suggest an explicit version tag. The tag appears not in the header field itself, but in something called a "header-name" part of an "extension-header" in ABNF rules per rfc3261. I suggest a new "header-name" value of "R-History-Info". You can pretend the "R" is for Retargeted-History-Info, or Reduced-History-Info, or Revisionist-History-Info. :) This "R-History-Info" extension-header is a multi-instance type, and a Proxy only ever adds to it if it is changing the received req-uri *and* would have set the "mp" flag for the new URI it is adding. The first RHI entry is added by the first proxy or UAC based on what it received, like in H-I, even though it's not retargeting to that URI. The extension-header's header-value is the URI being retargeted to. There are no currently defined header parameters. This RHI header field is not for troubleshooting - it's for actual processing use. Therefore, there is no incrementing index param, no embedded Reason header, and no entries created for anything but retargeted events and their new URI's (and the first one). Privacy does not apply to this on a header-by-header basis, and thus there is no embedded Privacy header either - if Privacy:history was requested, no RHI fields would be created. Compared with RFC 4244, the RHI header field would produce a smaller subset of header instances. In some cases significantly smaller. For example, in the most common case, only a single RHI header field would be in the message, regardless of how many proxies were crossed. There is also less processing overhead for every node in the message path. It should be noted that, like RFC 4244, RHI does not produce the smallest list possible of retargets - in some cases an entry is added when the target user Identity has not changed - the URI has changed to a new one, but unbeknownst to the Proxy which added it, the Identity of the human may have remained the same. For example an entry for "sip:Robert.Khaled@example.com" and a subsequent entry for "sip:bob@sales.example.com" may both have been added, even though they are the same abstract target human. A proxy cannot know by default that these two targets are the same identity. Only the UAS would know that, and so it may need to cull the list down further. -hadriel _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Tue Jul 14 07:38:34 2009 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 0DB603A63C9 for ; Tue, 14 Jul 2009 07:38:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.581 X-Spam-Level: X-Spam-Status: No, score=-6.581 tagged_above=-999 required=5 tests=[AWL=0.018, 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 T7aYaiTErEtd for ; Tue, 14 Jul 2009 07:38:30 -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 E99E028C1C5 for ; Tue, 14 Jul 2009 07:38:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAGM1XEpAZnmf/2dsb2JhbAC3eYgjkC0FhAg X-IronPort-AV: E=Sophos;i="4.42,397,1243814400"; d="scan'208";a="50324949" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 14 Jul 2009 14:38:12 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6EEcCNs014803; Tue, 14 Jul 2009 10:38:12 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6EEcCW6008756; Tue, 14 Jul 2009 14:38:12 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 10:38:12 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 10:38:12 -0400 Message-ID: <4A5C9853.8080708@cisco.com> Date: Tue, 14 Jul 2009 10:38:11 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Francois Audet References: <4A5B7195.6020009@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com> <4A5BBE0C.5000301@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jul 2009 14:38:12.0161 (UTC) FILETIME=[B6C47310:01CA0490] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2439; t=1247582292; x=1248446292; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20rfc4244bis=3A=20what=20is=2 0=22aor=22=20used=20for? |Sender:=20 |To:=20Francois=20Audet=20; bh=g8RDClNZBAgJ4vAgXzZnWZyDJ9f+ps6UnGDrzjDyiBc=; b=AiLkHDazdHkZhqrXc12OXd1mGjdCrrVkVnQcsRs+F9QSh2eJuah7gal51E TQHT0G+kRRu+uzNn+5avrA//uRodklKbCteF5IlCfcHgr1bPqpM/U3bmnads mb+84cMJbm; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 14 Jul 2009 14:38:34 -0000 Francois Audet wrote: > I assume your question is for "target URI" specifically. > > You would look at the las entry that is not a "rc/cc/rt". > > Bingo. > > Now, your question was loaded. You said "universal" but clearly, > it's not Universal because your are strictly looking at solving the > TargetURI problem. Furthermore, you are strictly trying to solve the > LAST targetURI problem. There are applications that do not use the LAST but the > FIRST targetURI (for example). Lots of Voice mail systems, again, for > example, do this. > > Therefore, it's not Universal. IMO the above is a hack to get a desired effect in the wrong way - a way that only works in certain restricted circumstances. Specifically, it only works of the VM system used by the final target is the same one as used by the first target. So, with such an algorithm, if I forward my (work) calls to Jonathan and he isn't there then they would have a good chance to end up in my mailbox. But if I forward my calls to you, and you aren't there, then they will not end up in my mailbox. When the call is retargetted, it should be marked as "no voicemail" so that if it isn't answered the proxy for the first target gets to decide alternative handling. Thanks, Paul >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Monday, July 13, 2009 16:07 >> To: Audet, Francois (SC100:3055) >> Cc: Hadriel Kaplan; SIPCORE >> Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? >> >> Francois Audet wrote: >>> >>>> Solving this problem with H-I seems to me to be gross >> overkill and an >>>> unnecessary exercise in pointless complexity. >>>> But that's what we do best around here. >>> I don't see how this is overkill. >>> >>> We have History-info anyways. >>> >> H-I is overkill because it 1) does lots of things, not just >> this URI and parameter transmission function b) is much >> bigger than what is required for URI and parameter >> transmission, and c) doesn't deterministically solve the URI >> and parameter transmission function. >> >> Can you show me a universal algorithm for the UAS to use in >> figuring out which HI entry is is supposed to use? >> >> -- >> Dean >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From pkyzivat@cisco.com Tue Jul 14 08:04:56 2009 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 DC39D28C0DF for ; Tue, 14 Jul 2009 08:04:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.634 X-Spam-Level: X-Spam-Status: No, score=-2.634 tagged_above=-999 required=5 tests=[AWL=-3.930, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_52=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 jK73cGydORiz for ; Tue, 14 Jul 2009 08:04:55 -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 68B653A6C07 for ; Tue, 14 Jul 2009 08:04:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPM7XEpAZnmf/2dsb2JhbAC4SYZjgUCQNAWBLoERgQo/gUI X-IronPort-AV: E=Sophos;i="4.42,397,1243814400"; d="scan'208";a="50378087" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 14 Jul 2009 15:04:36 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6EF4a3v006981; Tue, 14 Jul 2009 11:04:36 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6EF4ajP023558; Tue, 14 Jul 2009 15:04:36 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 11:04:36 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 11:04:36 -0400 Message-ID: <4A5C9E83.5020607@cisco.com> Date: Tue, 14 Jul 2009 11:04:35 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: gao.yang2@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 14 Jul 2009 15:04:36.0224 (UTC) FILETIME=[66F14800:01CA0494] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4501; t=1247583876; x=1248447876; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20=3D?GB2312?B?tPC4tDogUmU6IC BOZXcgcmV2aXNpb24gb2YgdGhl?=3D=0A=20=3D?GB2312?B?IHJlLUlOVkl URSBoYW5kbGluZyBkcmFmdA=3D=3D?=3D |Sender:=20 |To:=20gao.yang2@zte.com.cn; bh=D2Qbltan+YcDitbfLm+GGuwOi+xkp1WzSHWV2u8FBDY=; b=xYuWdtO9uhdMfc3pVuww/0+xiMWirVGRzlaWtWezy7cLUVdgfaNn854FXR 2qPZQkt+bnkqD6zRFeFjYzaC7akH9Ll0se6PR9FAU0gbwo2qJ5Ity7czxwmT axENHn7K0L; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIPCORE , OKUMURA Shinji Subject: Re: [sipcore] =?gb2312?b?tPC4tDogUmU6ICBOZXcgcmV2aXNpb24gb2YgdGhlIHJl?= =?gb2312?b?LUlOVklURSBoYW5kbGluZyBkcmFmdA==?= 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, 14 Jul 2009 15:04:56 -0000 There is a difficult problem when the UAC has an urgent need to change the target and an INVITE is in progress: the routing of responses to the original INVITE, since they are governed by the Via headers of the INVITE, not the target. Perhaps that means that if you have an urgent need to change your address while you have an incomplete INVITE outstanding, you should CANCEL the INVITE and send a new one with the target refresh. OTOH, if the UAS finds itself with that problem it can just initiate a target refresh within the dialog. And in that case, if the INVITE subsequently fails you wouldn't want the target change to be rolled back. Thanks, Paul gao.yang2@zte.com.cn wrote: > > Hi Shinji, > > Target fresh: > One target fresh is in just one sip transaction, not like session > modification can overlap more than one sip transaction(such as > precondition). > So, even the ongoing INVITE/Re-INVITE has target fresh, the target fresh > in the UPDATE is a whole new one. *As it is a whole new one, not part * > *of the original one, so the target fresh in the UPDATE must not > *rollback*.* > > Session modification: > When the O/A in UPDATE/200OK is part of the one triggered by > INVITE/Re-INVITE, it is NOT excluded from the rollback. But when the O/A in > UPDATE/200OK is a whole new one, IMO, it should excluded from the rollback. > > BTW, > A standard regulation is really needed to end the very long session > state discussion. > > And as we should has a detailed classification of which O/A is part of > the one triggered by INVITE/Re-INVITE and which is not, if we choose > this way to > solve the session state problm, now I support > draft-camarillo-sipcore-reinvite-00. I'd like to concentrate on this > solution.(I do not mean any restrict on any talking around my original > proposal :)) > > Thanks. > > Gao > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > > > *OKUMURA Shinji * > > 2009-07-14 10:33 > > > ÊÕ¼þÈË > SIPCORE > ³­ËÍ > gao.yang2@zte.com.cn > Ö÷Ìâ > Re: [sipcore] New revision of the re-INVITE handling draft > > > > > > > > > Hi Gao, > > Do you mean that the session state of the UPDATE transaction is NOT > excluded from the rollback, but the dialog state(ie remote target) > is excluded from the rollback? > > gao.yang2@zte.com.cn > >Hi Shinji, > > > >By RFC3311, the target refresh UPDATE can refresh the ongoing Re-INVITE, > >as below: > > > >UPDATE is a target refresh request. As specified in RFC 3261 [1], > > this means that it can update the remote target of a dialog. If a UA > > uses an UPDATE request or response to modify the remote target while > > an INVITE transaction is in progress, and it is a UAS for that INVITE > > transaction, it MUST place the same value into the Contact header > > field of the 2xx to the INVITE that it placed into the UPDATE request > > or response. > > the above statement means that the 2xx to the INVITE include the same > Contact header of the UPDATE request or response. But UPDATE does not > modify the Via header of 2xx. > > Regards, > Shinji > > >And then, we can get the correct session state by the way proposed in > >draft-camarillo-sipcore-reinvite-00. > > > >Gao > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. > > > ------------------------------------------------------------------------ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Tue Jul 14 08:08:38 2009 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 CFE173A6EF8 for ; Tue, 14 Jul 2009 08:08:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.5 X-Spam-Level: X-Spam-Status: No, score=-6.5 tagged_above=-999 required=5 tests=[AWL=0.099, 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 aX+VzAne6UjA for ; Tue, 14 Jul 2009 08:08:37 -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 17F7B3A6EB7 for ; Tue, 14 Jul 2009 08:08:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAPM7XEpAZnmf/2dsb2JhbAC4SYgjkDQFhAg X-IronPort-AV: E=Sophos;i="4.42,397,1243814400"; d="scan'208";a="50379016" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 14 Jul 2009 15:08:27 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6EF8RSE010898; Tue, 14 Jul 2009 11:08:27 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6EF8RgC026860; Tue, 14 Jul 2009 15:08:27 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 11:08:27 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 11:08:26 -0400 Message-ID: <4A5C9F69.1070701@cisco.com> Date: Tue, 14 Jul 2009 11:08:25 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Hadriel Kaplan References: <4A5B7195.6020009@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com> <4A5BBE0C.5000301@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jul 2009 15:08:26.0867 (UTC) FILETIME=[F06A9C30:01CA0494] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2350; t=1247584107; x=1248448107; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20rfc4244bis=3A=20what=20is=2 0=22aor=22=20used=20for? |Sender:=20 |To:=20Hadriel=20Kaplan=20; bh=T27rEjmkC4mxxpCl3VSW9jvUO2sYtqboFR17R5wtyx4=; b=q+NC9AmSyIcRSHcNPCVfx3ZpUtSVsu0r6oY46t95nokdMH7fTInW/g2zS+ yUSWYjSj3XF/uoI06F2rAQZQAjJXWEceSLomSLPDlH+4P5tpZuC/1sneZsrJ SmnPITWjGB; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 14 Jul 2009 15:08:38 -0000 Hadriel Kaplan wrote: >> -----Original Message----- >> From: Francois Audet [mailto:audet@nortel.com] >> Sent: Monday, July 13, 2009 7:19 PM >> >> I assume your question is for "target URI" specifically. >> You would look at the las entry that is not a "rc/cc/rt". >> Bingo. > > Which is the set of "mp", no? > > Note though that this set's last member is not *necessarily* the one Target-URI wants - it's the set/list it must walk through (in reverse order of the H-I list of "mp" ones) to find the Target-URI. As it walks the list, if the local UAS believes it represents the URI, it keeps walking backwards - when it finds one it does not represent, it stops walking up the list and uses the last one it found that it *does* represent. That one is the "Target-URI". Why would it want the first of those it represents, not the last? Thanks, Paul > The UAS knows it "represents" one if it either (a) Registers that URI, or (b) learned it through P-Associated-URI, or (c) it learned or created a GRUU for itself, or (d) has some provisioned knowledge that it also represents that URI. > > >> Now, your question was loaded. You said "universal" but clearly, >> it's not Universal because your are strictly looking at solving the >> TargetURI problem. Furthermore, you are strictly trying to solve the >> LAST targetURI problem. There are applications that do not use the LAST >> but the >> FIRST targetURI (for example). Lots of Voice mail systems, again, for >> example, do this. >> Therefore, it's not Universal. > > Right it's not universal, and no universal algorithm can find the right URI for all application uses. But I think we can (and should) document what algorithms should be used for the most common applications, so that there's no confusion on the part of different implementations? (or even just to provide guidance?) > > For example, a Voicemail system would NOT use the FIRST "mp" entry in the list, nor the LAST. It needs to walk the list backwards to find the closest "mp" to the end that it can use. Otherwise, a retarget from Alice to Bob will go to Alice's voicemail, when it should have gone to Bob's. No? > > -hadriel > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From HKaplan@acmepacket.com Tue Jul 14 08:09:47 2009 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 66A103A69D4 for ; Tue, 14 Jul 2009 08:09:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.028, 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 oevQA-VxcbYR for ; Tue, 14 Jul 2009 08:09:46 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 22B563A6AB1 for ; Tue, 14 Jul 2009 08:09:14 -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.1.375.2; Tue, 14 Jul 2009 11:09:02 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 14 Jul 2009 11:09:02 -0400 From: Hadriel Kaplan To: Mary Barnes , Francois Audet , SIPCORE Date: Tue, 14 Jul 2009 11:08:54 -0400 Thread-Topic: [sipcore] rfc4244bis: Open Issues Thread-Index: AcoD4RmgYPToplphTNGZX+nUfMAJ3gAGmHWgAABnAtAAA1WScAAAQZAgAAAkWqAAAHnXYAABk5RgAADVmuAAAdtcYAAbypqAAAFynWA= Message-ID: References: <4A5B7195.6020009@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF51FF9@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EF521C4@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EF52209@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EF522A1@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFA0BC4@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EFA0BC4@zrc2hxm0.corp.nortel.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] rfc4244bis: Open Issues 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, 14 Jul 2009 15:09:47 -0000 > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Tuesday, July 14, 2009 10:22 AM > To: Hadriel Kaplan; Francois Audet; SIPCORE > Subject: RE: [sipcore] rfc4244bis: Open Issues >=20 > We did consider a version tag (slightly different approach than what you > suggest), but in the end the current approach is far simpler than what > you suggest and far more inline with the basic extensibility mechanism > that was put in 4244. Your proposal takes us back to day one and just > defining a new header altogether. Yup, that's exactly what it suggests. Press Reset. Let the few that want = to do H-I the old way do it (for troubleshooting?), but do Target, Redirect= ion, 800-service, etc. using R-H-I. The current 4244bis approach is in no way, shape, or form "simpler" than wh= at I am suggesting. It's just lets you carry the old baggage - which is bo= th good and bad. Unless you think this: History-Info: ;index=3D1;mp History-Info: ;index=3D1.1;rt History-Info: ;index=3D1.1.1;rt History-Info: ;index=3D1.1.1.1;rt;aor History-Info: ;index=3D1.1.1.1.1;rt;aor History-Info: ;index=3D1.1.1.1.1.2.1;mp History-Info: ;index=3D1.1.1.1.1.2.1.1;rt History-Info: ;index=3D1.1.1.1.1.2.1.1.1;rt;aor History-Info: ;i= ndex=3D1.1.1.1.1.2.1.1.1.1;rt;aor History-Info: ;index=3D1.1.1.1.1.2.1.1.1.1.= 1;rt;aor History-Info: ;index=3D1.1.1.1.1.2.1.1.1.1.1.1;rc History-Info: ;index=3D1.1.1.1.1.2.1.1.1.1.1.1.1;rt Is simpler than this: R-History-Info: R-History-Info: -hadriel From HKaplan@acmepacket.com Tue Jul 14 08:23:22 2009 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 6C9EC28C254 for ; Tue, 14 Jul 2009 08:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.572 X-Spam-Level: X-Spam-Status: No, score=-2.572 tagged_above=-999 required=5 tests=[AWL=0.027, 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 5rNUa27GNXrT for ; Tue, 14 Jul 2009 08:23:21 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5EB9B3A6E7C for ; Tue, 14 Jul 2009 08:23:21 -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.1.375.2; Tue, 14 Jul 2009 11:20:21 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 14 Jul 2009 11:20:22 -0400 From: Hadriel Kaplan To: Paul Kyzivat Date: Tue, 14 Jul 2009 11:20:20 -0400 Thread-Topic: [sipcore] rfc4244bis: what is "aor" used for? Thread-Index: AcoElPHd5r4AWLvRRcSztLHVoYhIYgAAEOSA Message-ID: References: <4A5B7195.6020009@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com> <4A5BBE0C.5000301@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> <4A5C9F69.1070701@cisco.com> In-Reply-To: <4A5C9F69.1070701@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 Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 14 Jul 2009 15:23:22 -0000 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Tuesday, July 14, 2009 11:08 AM >=20 > Hadriel Kaplan wrote: > >> -----Original Message----- > >> From: Francois Audet [mailto:audet@nortel.com] > >> Sent: Monday, July 13, 2009 7:19 PM > >> > >> I assume your question is for "target URI" specifically. > >> You would look at the las entry that is not a "rc/cc/rt". > >> Bingo. > > > > Which is the set of "mp", no? > > > > Note though that this set's last member is not *necessarily* the one > Target-URI wants - it's the set/list it must walk through (in reverse > order of the H-I list of "mp" ones) to find the Target-URI. As it walks > the list, if the local UAS believes it represents the URI, it keeps > walking backwards - when it finds one it does not represent, it stops > walking up the list and uses the last one it found that it *does* > represent. That one is the "Target-URI". >=20 > Why would it want the first of those it represents, not the last? You mean the "first" in the list being the oldest from the UAS's point of v= iew (and the first in the actual list order)? Because proxies adding retargeted-to URI's are making a guess - they're ass= uming the retargeted to URI is a true retarget; i.e., when they add "mp", t= hey could be wrong. The only one who knows what URI's it is really the sam= e identity for is the UAS. So the UAS goes backwards in the list to find t= he oldest one in the chain that it represents, because that is the point of= actual retargeting. For example, if alice sends a request to "sip:Robert.Khaled@example.com", w= hich gets sent to "sip:bob@sales.example.com" and Bob's UAS receives it aft= er that, the H-I list of ALL "mp" tagged entries will be this: H-I: ;mp H-I: ;mp >From a Target-URI perspective, the Target-URI is actually the first one "si= p:Robert.Khaled@example.com", because it's a pseudonym for the second - the= second "mp" entry was NOT a real retarget, unbeknownst to the proxy which = generated it. (only Bob's UAS could know this in general, although a Proxy = may sometimes know it too in specific circumstances) Alice actually called Robert.Khaled, so for example bob's UAS may well want= to use a different ring or whatever for Robert.Khaled than for bob. That = was the gist of the Target-URI problem - we wanted to know what req-URI Ali= ce generated, unless Alice's request was truly retargeted to a different id= entity. -hadriel From hannes.tschofenig@nsn.com Tue Jul 14 08:39:59 2009 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 01F743A6945; Tue, 14 Jul 2009 08:39:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.402 X-Spam-Level: X-Spam-Status: No, score=-5.402 tagged_above=-999 required=5 tests=[AWL=1.197, 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 sRu8gpnwjKuR; Tue, 14 Jul 2009 08:39:58 -0700 (PDT) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [217.115.75.233]) by core3.amsl.com (Postfix) with ESMTP id C08BA3A6AF8; Tue, 14 Jul 2009 08:39:57 -0700 (PDT) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id n6ECRGXY010879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 14 Jul 2009 14:27:16 +0200 Received: from demuexc024.nsn-intra.net (demuexc024.nsn-intra.net [10.159.32.11]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id n6ECR8mb026601; Tue, 14 Jul 2009 14:27:15 +0200 Received: from FIESEXC015.nsn-intra.net ([10.159.0.23]) by demuexc024.nsn-intra.net with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 14:27:15 +0200 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, 14 Jul 2009 15:29:34 +0300 Message-ID: <3D3C75174CB95F42AD6BCC56E5555B450187F547@FIESEXC015.nsn-intra.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00221E129@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Confusion over target inSIP location-conveyance - and impact on ECRIT phonebcp Thread-Index: AcoETfR87AVYdgYPQCCBhIDhwjtUogALfsdA References: <0D5F89FAC29E2C41B98A6A762007F5D00221E129@GBNTHT12009MSX.gb002.siemens.net> From: "Tschofenig, Hannes (NSN - FI/Espoo)" To: "ext Elwell, John" , "James M. Polk" , , "Brian Rosen" , X-OriginalArrivalTime: 14 Jul 2009 12:27:15.0162 (UTC) FILETIME=[6BA18BA0:01CA047E] Subject: Re: [sipcore] Confusion over target inSIP location-conveyance - and impact on ECRIT phonebcp 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, 14 Jul 2009 15:39:59 -0000 You raise a very good point, John.=20 My response would be that the answer to your question about what the location actually refers to is given in the 'entity' attribute of the element. The problem is only that we say in other places that the info put into this field should be obfuscated: As noted in the "HTTP Enabled Location Delivery (HELD)" [I-D.ietf-geopriv-http-location-delivery] Section 6.6: The LIS MUST NOT include any means of identifying the Device in the PIDF-LO unless it is able to verify that the identifier is correct and inclusion of identity is expressly permitted by a Rule Maker. Therefore, PIDF parameters that contain identity are either omitted or contain unlinked pseudonyms [RFC3693]. A unique, unlinked presentity URI SHOULD be generated by the LIS for the mandatory presence "entity" attribute of the PIDF document. Optional parameters such as the "contact" element and the "deviceID" element [RFC4479] are not used. Ciao Hannes PS: I also did a review some time back http://www.ietf.org/mail-archive/web/geopriv/current/msg06955.html I am not sure all my comments got addressed already :-) >-----Original Message----- >From: sipcore-bounces@ietf.org=20 >[mailto:sipcore-bounces@ietf.org] On Behalf Of ext Elwell, John >Sent: 14 July, 2009 09:40 >To: James M. Polk; sipcore@ietf.org; Brian Rosen >Subject: [sipcore] Confusion over target inSIP=20 >location-conveyance - and impact on ECRIT phonebcp > >In 4.2 it states: >"The UAC can use whatever means it knows of to verify/refresh its=20 > location information before attempting a new request that includes=20 > location." >"its location information" suggests that the UAC is the target. > >In 4.3.3 it states: >"This document gives no guidance how this is accomplished, given the=20 > number of ways a UAC can learn its location" >which suggests similar. > >Similarly in 6.1: >"If a UAC does not learn and store its location locally (a GPS chip)=20 > or from the network (DHCP or LLDP-MED), the UAC MAY learn its LbyR=20 > URI (from DHCP for example)." >Which suggests that a UAC inserts its location, not some other=20 >location. > >And later in 6.1: >"If a UAC has already conveyed location in the original request of a=20 > transaction, and wants to update its location information ..." > >In 6.2: >"If the LbyR URI is > sip:, sips: or pres:, and the UAS wants to learn the UAC's=20 >location," > >In 6.2.1: >"This=20 > means the SIP server is including its version of where it thinks the > UAC is, geographically." > >In 8: >"Conveyance of physical location of a UAC raises privacy concerns" > >and: >"In cases where a session set-up is=20 > retargeted based on the location of the UAC initiating the call or=20 > SIP MESSAGE," > >All these many examples illustrate an implication that the=20 >location target is the UAC. I am sure there are other places too. > >I found a couple of places that contradict this. In 6.2 it states: >"If there=20 > is more than one PIDF-LO with different Target identifiers, then=20 > the UAC is merely telling the UAS where more than one Target is, and > there should not be any conflict." > >I think there are other places that mention locations of=20 >multiple targets in a request, implying they cannot all be the=20 >location of the UAC. > >And in 6.2.1 it states: >"The Location Target identified in=20 > the PIDF-LO may or may not be the location inserter, or the=20 > generator of the request (the UAC or SIP server)." > >So we have inconsistency as to whether a conveyed location is=20 >that of they UAC or not. > >One document that relies on location-conveyance is ECRIT's=20 >phonebcp. In there, I cannot find any reference to a routing=20 >entity looking to see whether a conveyed location has the=20 >caller as target or not. It just assumes that this is the=20 >case. So if we were to agree that a conveyed location is not=20 >necessarily the location of the UAC, this will have impact on phonebcp. > >John > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore > From AUDET@nortel.com Tue Jul 14 08:54:49 2009 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 D8E383A6B32 for ; Tue, 14 Jul 2009 08:54:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.409 X-Spam-Level: X-Spam-Status: No, score=-6.409 tagged_above=-999 required=5 tests=[AWL=0.190, 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 Y2ItmV-eet3Y for ; Tue, 14 Jul 2009 08:54:48 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 58A8428C3A1 for ; Tue, 14 Jul 2009 08:54:25 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6EFpUJ21980; Tue, 14 Jul 2009 15:51:30 GMT 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, 14 Jul 2009 10:51:19 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFA0EA5@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rfc4244bis: Open Issues thread-index: AcoD4RmgYPToplphTNGZX+nUfMAJ3gAGmHWgAABnAtAAA1WScAAAQZAgAAAkWqAAAHnXYAABk5RgAADVmuAAAdtcYAAe35/Q References: <4A5B7195.6020009@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF51FF9@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EF521C4@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EF52209@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EF522A1@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Hadriel Kaplan" , "SIPCORE" Subject: Re: [sipcore] rfc4244bis: Open Issues 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, 14 Jul 2009 15:54:49 -0000 You are right, I do hate it :-) We did consider it, but versioning is not something we do in SIP.=20 We are still on SIP/2.0... =20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Monday, July 13, 2009 18:43 > To: Audet, Francois (SC100:3055); SIPCORE > Subject: RE: rfc4244bis: Open Issues >=20 >=20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Monday, July 13, 2009 8:14 PM > >=20 > > If there is a tag (anyone), it's 4244bis. > > If there is none, it's 4244. >=20 > Got it. Hate it, but got it. :) >=20 > You're going to hate this idea too, but oh well... the delete=20 > key is in easy reach... so here goes: > I suggest an explicit version tag. The tag appears not in=20 > the header field itself, but in something called a=20 > "header-name" part of an "extension-header" in ABNF rules per=20 > rfc3261. I suggest a new "header-name" value of=20 > "R-History-Info". You can pretend the "R" is for=20 > Retargeted-History-Info, or Reduced-History-Info, or=20 > Revisionist-History-Info. :) >=20 > This "R-History-Info" extension-header is a multi-instance=20 > type, and a Proxy only ever adds to it if it is changing the=20 > received req-uri *and* would have set the "mp" flag for the=20 > new URI it is adding. The first RHI entry is added by the=20 > first proxy or UAC based on what it received, like in H-I,=20 > even though it's not retargeting to that URI. The=20 > extension-header's header-value is the URI being retargeted=20 > to. There are no currently defined header parameters. >=20 > This RHI header field is not for troubleshooting - it's for=20 > actual processing use. Therefore, there is no incrementing=20 > index param, no embedded Reason header, and no entries=20 > created for anything but retargeted events and their new=20 > URI's (and the first one). Privacy does not apply to this on=20 > a header-by-header basis, and thus there is no embedded=20 > Privacy header either - if Privacy:history was requested, no=20 > RHI fields would be created. >=20 > Compared with RFC 4244, the RHI header field would produce a=20 > smaller subset of header instances. In some cases=20 > significantly smaller. For example, in the most common case,=20 > only a single RHI header field would be in the message,=20 > regardless of how many proxies were crossed. There is also=20 > less processing overhead for every node in the message path. >=20 > It should be noted that, like RFC 4244, RHI does not produce=20 > the smallest list possible of retargets - in some cases an=20 > entry is added when the target user Identity has not changed=20 > - the URI has changed to a new one, but unbeknownst to the=20 > Proxy which added it, the Identity of the human may have=20 > remained the same. For example an entry for=20 > "sip:Robert.Khaled@example.com" and a subsequent entry for=20 > "sip:bob@sales.example.com" may both have been added, even=20 > though they are the same abstract target human. A proxy=20 > cannot know by default that these two targets are the same=20 > identity. Only the UAS would know that, and so it may need=20 > to cull the list down further. >=20 > -hadriel >=20 >=20 From AUDET@nortel.com Tue Jul 14 08:58:31 2009 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 CBB3B3A6BB8 for ; Tue, 14 Jul 2009 08:58:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.112 X-Spam-Level: X-Spam-Status: No, score=-6.112 tagged_above=-999 required=5 tests=[AWL=-0.113, BAYES_00=-2.599, J_CHICKENPOX_47=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 QSPqWZlV8m1F for ; Tue, 14 Jul 2009 08:58:30 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 87DC43A6B32 for ; Tue, 14 Jul 2009 08:58:30 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6EFtFX08875; Tue, 14 Jul 2009 15:55:16 GMT 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, 14 Jul 2009 10:56:48 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFA0ED2@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A5C8B0D.6010107@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoEiNpbxezCQaSHQVqnl/jkDh99RwAEiPbQ References: <1ECE0EB50388174790F9694F77522CCF1EF5190A@zrc2hxm0.corp.nortel.com> <4A5B71AC.6050502@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EF51BFE@zrc2hxm0.corp.nortel.com> <4A5C8B0D.6010107@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 14 Jul 2009 15:58:31 -0000 Yes, absolutely. This was indeed one of the reason for the "aor" flag. It's very common for Phones to use "raw" digits in=20 Requests-URIs, with dialling prefixes and other garbage=20 (which is clearly wrong according to standard). Then the proxy "fixes" the request-URI by translating to=20 a proper tel-derived SIP URI (for example), removing extraneous dialing prefixes that means nothing the the other end, adding ;user=3Dphone, "+" or phone-context as appropriate. The beauty of the ;aor tag is that the entry that is valid will be tagged with ;aor, but not the "garbagy" one at the begining. When trying to figure out "redirection", this is quite useful. Otherwise, the "garbagy" one at the begining may be falsy interpreted as a redirecting number, when it was not. This is useful for a lot of services. (Now, I will agree that we may be able to do that without a specific aor tag).=20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Tuesday, July 14, 2009 06:42 > To: Audet, Francois (SC100:3055) > Cc: Hadriel Kaplan; Hans Erik van Elburg; SIPCORE > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >=20 > Francois, >=20 > Maybe we can puzzle this out by examining more use cases. > You focused on digit manipulation, which is surely one. But=20 > there are others. >=20 > To spell out the digit manipulation case in more detail: >=20 > A proxy receives a request with sip R-URI in the domain it is=20 > responsible for. It sees that the user part is all digits. (E.g > sip:81234@example.net) It then applies some sort of digit map=20 > it has been provisioned with (possibly per-caller, possibly=20 > per-domain) to transform that into some other more globally=20 > unique URI - perhaps an > E.164 number in its own domain or some other domain, or a TEL=20 > URI. (E.g.=20 > sip:+12125551234@example.net;user=3Dphone.) It does the=20 > translation and then proceeds based on the result. I agree in=20 > this case it is wrong to call the incoming R-URI an AOR. >=20 > A different case is synonyms or aliases: >=20 > A proxy responsible for example.net receives a request with=20 > R-URI sip:phk@example.net. This is not in its location=20 > service. But it has a provisioned alias table that says phk=20 > is a synonym for paul.kyzivat, so it translates the R-URI to=20 > sip:paul.kyzivat@example.net. It then proceeds to process=20 > that, which turns out to be in its location service, so it=20 > translates it again to sip:line1@phone1.paulk.example.net. > Again, I don't think sip:phk@example.net is an AoR in this case. >=20 > Another case, for forwarding: >=20 > A proxy responsible for example.net receives a request with=20 > R-URI of sip:paul.kyzivat@example.net. There is a location=20 > service with an entry registered for=20 > sip:line1@phone1.paulk.example.net, but there is also=20 > provisioning independent of the location service that says to=20 > unconditionally forward all calls to this URI to=20 > sip:audet@nortel.com.=20 > This is accomplished by R-URI translation. (To ensure that=20 > the request will not be rejected as mis-addressed.) >=20 > In this case I think that sip:paul.kyzivat@example.net *is* an AoR. >=20 > And one final forwarding case: >=20 > A proxy responsible for example.net receives a request with=20 > R-URI of sip:alice.smith@example.net. Alice used to work for=20 > Example Co, but she no longer does, so her URI is "out of=20 > service". But the proxy has been provisioned to translate the=20 > R-URI of Alice's calls to her old boss'=20 > URI: sip:betty.jones@example.net. There will never be an=20 > entry in the location service for alice, registrations are=20 > not permitted. >=20 > In this case, in spite of there being no location service=20 > involved, I still think sip:alice.smith@example.net is an AoR. >=20 > So, IMO the bottom line is that whether a URI is an AoR is a=20 > policy decision within the domain of the URI. >=20 > Thanks, > Paul >=20 >=20 > Francois Audet wrote: > > =20 > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Monday, July 13, 2009 10:41 > >> To: Audet, Francois (SC100:3055) > >> Cc: Hadriel Kaplan; Hans Erik van Elburg; SIPCORE > >> Subject: Re: [sipcore] rfc4244bis: what is an AoR? > >> > >> > >> > >> Francois Audet wrote: > >>> To me it's crystal clear. > >>> > >>> If you are the entity (proxy or redirect server) > >> responsible for the > >>> URI, and you find the entry in your location service, you > >> mark as AOR. > >>> That means you will now route based on "rules" you have=20 > internally,=20 > >>> e.g., map it to a contact, etc. > >> I think some cases are clear, others not so much: > >> > >> - If the proxy translates to a contact that it got from a > >> location service and that entry was placed there by a REGISTER, > >> then the entry should definitely be marked as an AoR > >=20 > > Agree. > >=20 > >> - If the proxy translates to a contact that it got from a > >> ocation service, and that entry got there somehow other than=20 > >> REGISTER, > >> then I *think* the entry should still be marked as an AoR. > >=20 > > Yes, agree. > >=20 > >> - If the proxy uses some other logic than a "location service" > >> to translate the URI, but it might in other cases use the > >> location service to translate the URI, then I'm not sure. > >> > >> - If the proxy never uses a location service for this URI, > >> but translates it on some other basis, then again I'm not sure. > >> > >> One problem here is that the location service is abstract.=20 > >> There are things that can be done using it, or in another=20 > manner. It=20 > >> seems to me that if it *could* have been done with a=20 > location service=20 > >> lookup, then the result ought to be the same whether it is or not. > >=20 > > I think the last two are the same thing. > > Things like digit manipulation and so forth. > >=20 > > I didn't want to alter (or second-guess) the definition of=20 > AOR (which=20 > > is the realm of RFC 3261), in this draft. > >=20 > > I would think that if the proxy doesn't know that it's an=20 > AOR, then it=20 > > shouldn't mark it as such. So I would expect mechanical=20 > digit manipulation to NOT be marked as AOR. > >=20 > >=20 >=20 From AUDET@nortel.com Tue Jul 14 09:00:51 2009 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 920063A6945 for ; Tue, 14 Jul 2009 09:00:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.41 X-Spam-Level: X-Spam-Status: No, score=-6.41 tagged_above=-999 required=5 tests=[AWL=0.189, 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 Q7w5ZkVGaG+q for ; Tue, 14 Jul 2009 09:00:50 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 9698F3A67BD for ; Tue, 14 Jul 2009 09:00:50 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6EFwYX09491; Tue, 14 Jul 2009 15:58:34 GMT 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, 14 Jul 2009 10:59:15 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFA0EEC@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A5C9853.8080708@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is "aor" used for? thread-index: AcoEkL4PqnibCc8bTyqkpeoY3jkBdAACx+0A References: <4A5B7195.6020009@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com> <4A5BBE0C.5000301@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> <4A5C9853.8080708@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 14 Jul 2009 16:00:51 -0000 =20 > Specifically, it only works of the VM system used by the=20 > final target is the same one as used by the first target. So,=20 > with such an algorithm, if I forward my (work) calls to=20 > Jonathan and he isn't there then they would have a good=20 > chance to end up in my mailbox. But if I forward my calls to=20 > you, and you aren't there, then they will not end up in my mailbox. >=20 > When the call is retargetted, it should be marked as "no=20 > voicemail" so that if it isn't answered the proxy for the=20 > first target gets to decide alternative handling. You can certainly implement the behavior you describe with=20 history-info (and it HAS been done already, I can assure you). That was the point of my other email. From AUDET@nortel.com Tue Jul 14 09:02:19 2009 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 C29223A68BC for ; Tue, 14 Jul 2009 09:02:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.413 X-Spam-Level: X-Spam-Status: No, score=-6.413 tagged_above=-999 required=5 tests=[AWL=0.186, 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 aY9Yu0lPIcEo for ; Tue, 14 Jul 2009 09:02:19 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id C38F23A6844 for ; Tue, 14 Jul 2009 09:02:18 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6EG18J27775; Tue, 14 Jul 2009 16:01:09 GMT 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, 14 Jul 2009 11:01:07 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFA0EFD@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A5C9F69.1070701@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is "aor" used for? thread-index: AcoElPTzgAUIwqQHRIKnbgYFt1JIiAABzMxQ References: <4A5B7195.6020009@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com> <4A5BBE0C.5000301@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> <4A5C9F69.1070701@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" , "Hadriel Kaplan" Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 14 Jul 2009 16:02:19 -0000 =20 > Why would it want the first of those it represents, not the last? Because of the VM example of your previous email. You call me, I'm forwarded to my admin (I wish). Admin doesn't answer. You get forwarded to my voicemail, not my admin. From AUDET@nortel.com Tue Jul 14 09:05:10 2009 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 513C53A6844 for ; Tue, 14 Jul 2009 09:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.416 X-Spam-Level: X-Spam-Status: No, score=-6.416 tagged_above=-999 required=5 tests=[AWL=0.183, 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 EEJuaRseSpFg for ; Tue, 14 Jul 2009 09:05:09 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 32F0A3A67BD for ; Tue, 14 Jul 2009 09:05:09 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6EG2VJ28583; Tue, 14 Jul 2009 16:02:31 GMT 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, 14 Jul 2009 11:02:02 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFA0F0A@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: Open Issues thread-index: AcoD4RmgYPToplphTNGZX+nUfMAJ3gAGmHWgAABnAtAAA1WScAAAQZAgAAAkWqAAAHnXYAABk5RgAADVmuAAAdtcYAAbypqAAAFynWAAAhhN8A== References: <4A5B7195.6020009@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF51FF9@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EF521C4@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EF52209@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EF522A1@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFA0BC4@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Hadriel Kaplan" , "Mary Barnes" , "SIPCORE" Subject: Re: [sipcore] rfc4244bis: Open Issues 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, 14 Jul 2009 16:05:10 -0000 This is obviously totally against anything anything we've ever done in = SIP (and SDP actually), so I can't take it seriously. =20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Tuesday, July 14, 2009 08:09 > To: Barnes, Mary (RICH2:AR00); Audet, Francois (SC100:3055); SIPCORE > Subject: RE: [sipcore] rfc4244bis: Open Issues >=20 >=20 >=20 > > -----Original Message----- > > From: Mary Barnes [mailto:mary.barnes@nortel.com] > > Sent: Tuesday, July 14, 2009 10:22 AM > > To: Hadriel Kaplan; Francois Audet; SIPCORE > > Subject: RE: [sipcore] rfc4244bis: Open Issues > >=20 > > We did consider a version tag (slightly different approach=20 > than what=20 > > you suggest), but in the end the current approach is far=20 > simpler than=20 > > what you suggest and far more inline with the basic extensibility=20 > > mechanism that was put in 4244. Your proposal takes us back to day=20 > > one and just defining a new header altogether. >=20 > Yup, that's exactly what it suggests. Press Reset. Let the=20 > few that want to do H-I the old way do it (for=20 > troubleshooting?), but do Target, Redirection, 800-service,=20 > etc. using R-H-I. >=20 > The current 4244bis approach is in no way, shape, or form=20 > "simpler" than what I am suggesting. It's just lets you=20 > carry the old baggage - which is both good and bad. >=20 > Unless you think this: > History-Info: ;index=3D1;mp > History-Info: ;index=3D1.1;rt > History-Info: ;index=3D1.1.1;rt > History-Info: ;index=3D1.1.1.1;rt;aor > History-Info: ;index=3D1.1.1.1.1;rt;aor > History-Info: ;index=3D1.1.1.1.1.2.1;mp > History-Info: ;index=3D1.1.1.1.1.2.1.1;rt > History-Info: ;index=3D1.1.1.1.1.2.1.1.1;rt;aor > History-Info:=20 > ;inde > x=3D1.1.1.1.1.2.1.1.1.1;rt;aor > History-Info:=20 > ;index=3D1.1.1.1.1.2.1.1.1.1.1;rt;aor > History-Info:=20 > ;index=3D1.1.1.1.1.2.1.1.1.1.1.1;rc > History-Info:=20 > ;index=3D1.1.1.1.1.2.1.1.1.1.1.1.1;rt >=20 > Is simpler than this: > R-History-Info: > R-History-Info: >=20 > -hadriel >=20 From AUDET@nortel.com Tue Jul 14 09:08:20 2009 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 1EDD328C313 for ; Tue, 14 Jul 2009 09:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.419 X-Spam-Level: X-Spam-Status: No, score=-6.419 tagged_above=-999 required=5 tests=[AWL=0.180, 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 Qm6is23G9Mnr for ; Tue, 14 Jul 2009 09:08:19 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 2A1AC3A695C for ; Tue, 14 Jul 2009 09:08:18 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6EG47X12614; Tue, 14 Jul 2009 16:04:07 GMT 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, 14 Jul 2009 11:05:42 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFA0F29@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is "aor" used for? thread-index: AcoElPHd5r4AWLvRRcSztLHVoYhIYgAAEOSAAAHSyEA= References: <4A5B7195.6020009@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com><4A5BBE0C.5000301@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> <4A5C9F69.1070701@cisco.com> From: "Francois Audet" To: "Hadriel Kaplan" , "Paul Kyzivat" Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 14 Jul 2009 16:08:20 -0000 =20 > For example, if alice sends a request to=20 > "sip:Robert.Khaled@example.com", which gets sent to=20 > "sip:bob@sales.example.com" and Bob's UAS receives it after=20 > that, the H-I list of ALL "mp" tagged entries will be this: >=20 > H-I: ;mp > H-I: ;mp Actually, no. Absolutely not. You'd get: History-Info: ;aor;index=3D1 History-Info: ;aor;mp;index=3D1.1 History-Info: ;rc;index=3D1.1.1 And that is assuming that Robert.Khaled and bob are not known to be the same user by the proxy. If the proxy knows there are the same user (e.g, they are "aliases"), then it would be: History-Info: ;aor;index=3D1 History-Info: ;aor;rt;index=3D1.1 History-Info: ;rc;index=3D1.1.1 From AUDET@nortel.com Tue Jul 14 09:13:04 2009 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 8953728C346 for ; Tue, 14 Jul 2009 09:13:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.421 X-Spam-Level: X-Spam-Status: No, score=-6.421 tagged_above=-999 required=5 tests=[AWL=0.178, 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 tEurTr7HA74A for ; Tue, 14 Jul 2009 09:13:03 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 6A98228C358 for ; Tue, 14 Jul 2009 09:13:03 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6EFkKX07009; Tue, 14 Jul 2009 15:46:20 GMT 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, 14 Jul 2009 10:46:58 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFA0E81@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is "aor" used for? thread-index: AcoEDqM/XIENvO+JQM+deNhoIRK3fQAAKw3QAAbzRkAAG3DxEA== References: <4A5B7195.6020009@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com> <4A5BBE0C.5000301@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Hadriel Kaplan" , "Dean Willis" Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 14 Jul 2009 16:13:04 -0000 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Monday, July 13, 2009 21:01 > To: Audet, Francois (SC100:3055); Dean Willis > Cc: SIPCORE > Subject: RE: [sipcore] rfc4244bis: what is "aor" used for? >=20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Monday, July 13, 2009 7:19 PM > >=20 > > I assume your question is for "target URI" specifically. > > You would look at the las entry that is not a "rc/cc/rt". > > Bingo. >=20 > Which is the set of "mp", no? =20 No, it's the one BEFORE that. It will actually be labelled as "aor". mp is "the one that is mapped to" not "mapped from".=20 Last "aor" is the last called address, and "mp" is the address = representing a different user it was retargeted to. > Right it's not universal, and no universal algorithm can find=20 > the right URI for all application uses. But I think we can=20 > (and should) document what algorithms should be used for the=20 > most common applications, so that there's no confusion on the=20 > part of different implementations? (or even just to provide guidance?) I agree. Once we agree on the tags (presumably in Stockholm), I think we should describe the algorithm for the sample applications we cover in the draft. The main ones will be: (1) target URI,=20 (2) last redirecting-to-other-user-number-and-reason. > For example, a Voicemail system would NOT use the FIRST "mp"=20 > entry in the list, nor the LAST. It needs to walk the list=20 > backwards to find the closest "mp" to the end that it can=20 > use. Otherwise, a retarget from Alice to Bob will go to=20 > Alice's voicemail, when it should have gone to Bob's. No? No. The way most voicemail system work is that it would TRY to go to Alice's voicemail, and if it is not possible, it will go to=20 Bob's. This is certainly the case for Enteprise voicemail systems, and I believe for service providers as well. The reason I say "try", is that if the redirection information=20 is not present for the first hop, it may not be able to do it. This happens when there is a large number of hops (in PSTN) or when the information is stipped off (e.g., when redirecting outside the = enterprise). (Really). Of course, I'm not saying that voicemail systems *should* be necessarily designed like this. I'm just saying that's how most of them work today, and the protocol should allow makeing it possible to retain that = behavior. From HKaplan@acmepacket.com Tue Jul 14 09:17:46 2009 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 EF4E43A6E47 for ; Tue, 14 Jul 2009 09:17:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 5dXj+bCSXvec for ; Tue, 14 Jul 2009 09:17:46 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 279813A696A for ; Tue, 14 Jul 2009 09:17:46 -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.1.375.2; Tue, 14 Jul 2009 12:17:15 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 14 Jul 2009 12:17:15 -0400 From: Hadriel Kaplan To: Francois Audet , Mary Barnes , SIPCORE Date: Tue, 14 Jul 2009 12:17:13 -0400 Thread-Topic: [sipcore] rfc4244bis: Open Issues Thread-Index: AcoD4RmgYPToplphTNGZX+nUfMAJ3gAGmHWgAABnAtAAA1WScAAAQZAgAAAkWqAAAHnXYAABk5RgAADVmuAAAdtcYAAbypqAAAFynWAAAhhN8AAAeTPQ Message-ID: References: <4A5B7195.6020009@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF51FF9@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EF521C4@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EF52209@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EF522A1@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFA0BC4@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFA0F0A@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EFA0F0A@zrc2hxm0.corp.nortel.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] rfc4244bis: Open Issues 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, 14 Jul 2009 16:17:47 -0000 =20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: Tuesday, July 14, 2009 12:02 PM >=20 > This is obviously totally against anything anything we've=20 > ever done in SIP (and SDP actually), so I can't take it seriously. Ummm... What is totally against anything we've done in SIP? Created new he= aders? I was being facetious about the extension-header header-name field being a = "version tag". I was trying to say: don't try to fix H-I to do this stuff;= create a new header (and everytime we create new header(s), they're based = on the extension-header ABNF entry in 3261 technically, afaik). -hadriel From AUDET@nortel.com Tue Jul 14 09:19:48 2009 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 1EDBE28C33B for ; Tue, 14 Jul 2009 09:19:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 6i58WLx6AbJ8 for ; Tue, 14 Jul 2009 09:19:47 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 3248328C35B for ; Tue, 14 Jul 2009 09:19:17 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6EGGXJ01240; Tue, 14 Jul 2009 16:16:34 GMT 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, 14 Jul 2009 11:15:35 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFA0F7C@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rfc4244bis: Do we need rt / mp / rc / cc thread-index: AcoEDqM/XIENvO+JQM+deNhoIRK3fQAAKw3QAAbzRkAAHH9xoA== References: <4A5B7195.6020009@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com> <4A5BBE0C.5000301@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "SIPCORE" Cc: Hadriel Kaplan Subject: [sipcore] rfc4244bis: Do we need rt / mp / rc / cc 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, 14 Jul 2009 16:19:48 -0000 In the current draft, we have opted to be "more precise" instead of = "more simple" with regards with tagging the H-I entries.... As eloquently said by Hadriel, what we really need to know is "what this a redirection (to a different user) or not"? One alternative to having the rc / cc / mp / rt (and nil) tags would be = to only have (say), "mp" (mapped to a different user), "rt" (routed to same = user) and of course "nil" (i.e., no tag because it's a legacy 4244 proxy, or = because the proxy doesn't know). "rc" & "cc" would be included in "rt".=20 This is something that we considered during the development of the = draft, but it seems people at the time preferred more precise tags.=20 I'd like feedback on what are people's views: Option A) As per draft: i.e., rc / cc / mp / rt Option B) Simplified: i.e., mp / rt PS: This says nothing of the "aor" issue, which, as Mary said, related = to other use cases, in particular the Freephone case. From pkyzivat@cisco.com Tue Jul 14 09:30:05 2009 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 4A3B43A68EC for ; Tue, 14 Jul 2009 09:30:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.502 X-Spam-Level: X-Spam-Status: No, score=-6.502 tagged_above=-999 required=5 tests=[AWL=0.097, 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 aaTdqOwrf5Ql for ; Tue, 14 Jul 2009 09:30:04 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 4E0FB3A6BF6 for ; Tue, 14 Jul 2009 09:30:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALNOXEqrR7PE/2dsb2JhbAC5K4gjkDQFhAg X-IronPort-AV: E=Sophos;i="4.42,398,1243814400"; d="scan'208";a="213828056" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-1.cisco.com with ESMTP; 14 Jul 2009 16:28:16 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n6EGSGtt005845; Tue, 14 Jul 2009 09:28:16 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n6EGSFP0005543; Tue, 14 Jul 2009 16:28:16 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 12:28:15 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 12:28:15 -0400 Message-ID: <4A5CB21E.3040608@cisco.com> Date: Tue, 14 Jul 2009 12:28:14 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Francois Audet References: <4A5B7195.6020009@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com> <4A5BBE0C.5000301@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> <4A5C9F69.1070701@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EFA0EFD@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EFA0EFD@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 14 Jul 2009 16:28:15.0214 (UTC) FILETIME=[167E60E0:01CA04A0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1381; t=1247588896; x=1248452896; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20rfc4244bis=3A=20what=20is=2 0=22aor=22=20used=20for? |Sender:=20; bh=lv+utGu9c33zpGdWK2UgffZuOEBI4rajPMaHQPFs36w=; b=MJbLLRn4voSxaSVG6RXS2AHlCNs8vH0ruU8CQ0SsTqu51Mn04wGAUchG70 C6UT0ojt9GALssdpLEWGOJ7D8lbnFjMvdcx06l9oVg95UoyUxy9TLOMCOPZL JnBy8ynJPl; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 14 Jul 2009 16:30:05 -0000 Francois Audet wrote: > >> Why would it want the first of those it represents, not the last? > > Because of the VM example of your previous email. > > You call me, I'm forwarded to my admin (I wish). Admin doesn't answer. > > You get forwarded to my voicemail, not my admin. So, rather than your admin's VM acting as your VM, you have your admin's proxy forwarding to your VM rather than your admin's VM. Its still wrong, because there is no particular reason the forward target, or the proxy for the target, should know anything about your VM. (Maybe in case of your admin it will, but that is just a coincidence.) The point is that to get the right behavior, the server that is doing the retargeting needs to make a *choice* of whether the downstream things should map again if the target isn't available, or should just give up and let the upstream server deal with it. The H-I isn't the right mechanism for expressing choices like that. Callerprefs is intended for things like that, though of course there are many issues with it too. I never liked H-I much, and this whole discussion is confirming my feelings. A long time ago the programming community realized that it was bad practice to have a function behave differently depending upon who called it, or why. But we haven't assimilated that here. Thanks, Paul From HKaplan@acmepacket.com Tue Jul 14 10:19:47 2009 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 291B128C36C for ; Tue, 14 Jul 2009 10:19:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.573 X-Spam-Level: X-Spam-Status: No, score=-2.573 tagged_above=-999 required=5 tests=[AWL=0.026, 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 2oByudtUeay2 for ; Tue, 14 Jul 2009 10:19:46 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E892D3A69C5 for ; Tue, 14 Jul 2009 10:19:13 -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.1.375.2; Tue, 14 Jul 2009 13:07:42 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 14 Jul 2009 13:07:42 -0400 From: Hadriel Kaplan To: Francois Audet , Dean Willis Date: Tue, 14 Jul 2009 13:07:41 -0400 Thread-Topic: [sipcore] rfc4244bis: what is "aor" used for? Thread-Index: AcoEDqM/XIENvO+JQM+deNhoIRK3fQAAKw3QAAbzRkAAG3DxEAAA893Q Message-ID: References: <4A5B7195.6020009@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com> <4A5BBE0C.5000301@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFA0E81@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EFA0E81@zrc2hxm0.corp.nortel.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 Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 14 Jul 2009 17:19:47 -0000 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Tuesday, July 14, 2009 11:47 AM >=20 > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortel.com] > > > Sent: Monday, July 13, 2009 7:19 PM > > > > > > I assume your question is for "target URI" specifically. > > > You would look at the las entry that is not a "rc/cc/rt". > > > Bingo. > > > > Which is the set of "mp", no? >=20 > No, it's the one BEFORE that. It will actually be labelled as "aor". >=20 > mp is "the one that is mapped to" not "mapped from". Yup, that I knew. =20 > Last "aor" is the last called address, and "mp" is the address > representing > a different user it was retargeted to. I was confused why you were saying this, because this is not the semantic t= hat the original target drafts actually wanted. They wanted what the UAC o= r re-targeted actually *sent*, not what the Registrar-Proxy received. But = then I saw there's a new target-uri-delivery draft, which I see now is wher= e this mapped/aor thing came from; and it changed the semantic, even though= it is self-contradictory in the text itself. But I will move that discuss= ion to another thread for that draft. :) -hadriel From HKaplan@acmepacket.com Tue Jul 14 10:53:06 2009 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 8729A3A6B0A for ; Tue, 14 Jul 2009 10:53:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 p9A0BNnFKIMw for ; Tue, 14 Jul 2009 10:53:05 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id A28E53A6835 for ; Tue, 14 Jul 2009 10:53:05 -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.1.375.2; Tue, 14 Jul 2009 13:47:49 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 14 Jul 2009 13:47:49 -0400 From: Hadriel Kaplan To: Francois Audet , Paul Kyzivat Date: Tue, 14 Jul 2009 13:47:48 -0400 Thread-Topic: [sipcore] rfc4244bis: what is "aor" used for? Thread-Index: AcoElPHd5r4AWLvRRcSztLHVoYhIYgAAEOSAAAHSyEAAA31/QA== Message-ID: References: <4A5B7195.6020009@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com><4A5BBE0C.5000301@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> <4A5C9F69.1070701@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EFA0F29@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EFA0F29@zrc2hxm0.corp.nortel.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 Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 14 Jul 2009 17:53:06 -0000 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: Tuesday, July 14, 2009 12:06 PM >=20 > > For example, if alice sends a request to=20 > > "sip:Robert.Khaled@example.com", which gets sent to=20 > > "sip:bob@sales.example.com" and Bob's UAS receives it after=20 > that, the=20 > > H-I list of ALL "mp" tagged entries will be this: > >=20 > > H-I: ;mp > > H-I: ;mp >=20 > Actually, no. Absolutely not. You'd get: >=20 > History-Info: ;aor;index=3D1 > History-Info: ;aor;mp;index=3D1.1 > History-Info: ;rc;index=3D1.1.1 Sorry that was a typo - I meant all the "mp" tagged and the original req-ur= i from Alice would be: H-I: ;aor H-I: ;mp You would NOT get: > History-Info: ;rc;index=3D1.1.1 ...in the list I'm describing, because that is not "mp" tagged - it's in th= e full H-I list sure, but if you weed-out/cull the list to the first entry = and all "mp" tagged ones, you'd get those two. =20 -hadriel= From AUDET@nortel.com Tue Jul 14 10:53:28 2009 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 77DE13A6D12 for ; Tue, 14 Jul 2009 10:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.426 X-Spam-Level: X-Spam-Status: No, score=-6.426 tagged_above=-999 required=5 tests=[AWL=0.173, 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 LULX9C6y8nIA for ; Tue, 14 Jul 2009 10:53:27 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 7848E3A6835 for ; Tue, 14 Jul 2009 10:53:27 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6EHq7J25022; Tue, 14 Jul 2009 17:52:07 GMT 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, 14 Jul 2009 12:51:53 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFA122C@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is "aor" used for? thread-index: AcoElPHd5r4AWLvRRcSztLHVoYhIYgAAEOSAAAHSyEAAA31/QAAAO6FA References: <4A5B7195.6020009@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com><4A5BBE0C.5000301@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> <4A5C9F69.1070701@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EFA0F29@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Hadriel Kaplan" , "Paul Kyzivat" Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 14 Jul 2009 17:53:28 -0000 So you are proposing something that is not backward compatible then. We did talk about the "weeding out" (as opposed to marked) earlier, and decided to "mark" instead of weeding out. In fact, it was in my presentation in San Francisco. The problem with many IETF groups is we keep going in circle. Once we=20 decide something, we should stick to it. Otherwise, it's impossible to make progress.=20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Tuesday, July 14, 2009 10:48 > To: Audet, Francois (SC100:3055); Paul Kyzivat > Cc: Dean Willis; SIPCORE > Subject: RE: [sipcore] rfc4244bis: what is "aor" used for? >=20 >=20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Tuesday, July 14, 2009 12:06 PM > >=20 > > > For example, if alice sends a request to=20 > > > "sip:Robert.Khaled@example.com", which gets sent to=20 > > > "sip:bob@sales.example.com" and Bob's UAS receives it after > > that, the > > > H-I list of ALL "mp" tagged entries will be this: > > >=20 > > > H-I: ;mp > > > H-I: ;mp > >=20 > > Actually, no. Absolutely not. You'd get: > >=20 > > History-Info: ;aor;index=3D1 > > History-Info: ;aor;mp;index=3D1.1 > > History-Info: ;rc;index=3D1.1.1 >=20 > Sorry that was a typo - I meant all the "mp" tagged and the=20 > original req-uri from Alice would be: >=20 > H-I: ;aor > H-I: ;mp >=20 > You would NOT get: > > History-Info: ;rc;index=3D1.1.1 >=20 > ...in the list I'm describing, because that is not "mp"=20 > tagged - it's in the full H-I list sure, but if you=20 > weed-out/cull the list to the first entry and all "mp" tagged=20 > ones, you'd get those two. > =20 > -hadriel >=20 From HKaplan@acmepacket.com Tue Jul 14 10:55:11 2009 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 51DD13A684F for ; Tue, 14 Jul 2009 10:55:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 9Cmd2pmTH-00 for ; Tue, 14 Jul 2009 10:55:10 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 721203A6D56 for ; Tue, 14 Jul 2009 10:55:10 -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.1.375.2; Tue, 14 Jul 2009 13:54:38 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 14 Jul 2009 13:54:35 -0400 From: Hadriel Kaplan To: Francois Audet , Paul Kyzivat Date: Tue, 14 Jul 2009 13:54:28 -0400 Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoEiNpbxezCQaSHQVqnl/jkDh99RwAEiPbQAAQRIlA= Message-ID: References: <1ECE0EB50388174790F9694F77522CCF1EF5190A@zrc2hxm0.corp.nortel.com> <4A5B71AC.6050502@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EF51BFE@zrc2hxm0.corp.nortel.com> <4A5C8B0D.6010107@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EFA0ED2@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EFA0ED2@zrc2hxm0.corp.nortel.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 Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 14 Jul 2009 17:55:11 -0000 =20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: Tuesday, July 14, 2009 11:57 AM >=20 > The beauty of the ;aor tag is that the entry that is valid=20 > will be tagged with ;aor, but not the "garbagy" one at the begining. > When trying to figure out "redirection", this is quite=20 > useful. Otherwise, the "garbagy" one at the begining may be=20 > falsy interpreted as a redirecting number, when it was not. > This is useful for a lot of services. I figured that was why the "aor" tag was trying to be clever, and why targe= t-uri changed the semantic from what Alice sent, to what Bob's registrar-pr= oxy received, but man is that a slippery-slope. Request-URI's usernames an= d domains are changed a LOT, and people add params, and params get lost, du= ring that translation. (for example in ENUM routing params usually go bye-= bye, and ones get swapped in trunk-group routing, etc.) How do you know if the one sent by Alice was wrong, vs. the one the registr= ar received? This thing is going to be a tech-support nightmare. :( -hadriel From HKaplan@acmepacket.com Tue Jul 14 11:03:37 2009 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 5932D3A6B87 for ; Tue, 14 Jul 2009 11:03:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.575 X-Spam-Level: X-Spam-Status: No, score=-2.575 tagged_above=-999 required=5 tests=[AWL=0.024, 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 to-DFSagoP6t for ; Tue, 14 Jul 2009 11:03:36 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 571993A684F for ; Tue, 14 Jul 2009 11:03:36 -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.1.375.2; Tue, 14 Jul 2009 13:59:10 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 14 Jul 2009 13:59:10 -0400 From: Hadriel Kaplan To: Francois Audet , Paul Kyzivat Date: Tue, 14 Jul 2009 13:59:06 -0400 Thread-Topic: [sipcore] rfc4244bis: what is "aor" used for? Thread-Index: AcoElPHd5r4AWLvRRcSztLHVoYhIYgAAEOSAAAHSyEAAA31/QAAAO6FAAAA54xA= Message-ID: References: <4A5B7195.6020009@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com><4A5BBE0C.5000301@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> <4A5C9F69.1070701@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EFA0F29@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFA122C@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EFA122C@zrc2hxm0.corp.nortel.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 Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 14 Jul 2009 18:03:37 -0000 No I think you mis-understand me. Or maybe I misunderstand you. :) I assume that H-I creates, and the UAS will receive ALL entries. (well, I d= on't really believe that, but for sake of this IETF discussion I do) I further assume that a receiving UAS will only look at some of the entries= - effectively reducing the list to smaller set - based on these tags, in s= ome way or other. Is that a dangerous assumption? If the tags can't be us= ed to reduce the list, to let a given application focus on particular entri= es, why are there tags? -hadriel > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: Tuesday, July 14, 2009 1:52 PM > To: Hadriel Kaplan; Paul Kyzivat > Cc: Dean Willis; SIPCORE > Subject: RE: [sipcore] rfc4244bis: what is "aor" used for? >=20 > So you are proposing something that is not backward compatible then. >=20 > We did talk about the "weeding out" (as opposed to marked)=20 > earlier, and decided to "mark" instead of weeding out. In=20 > fact, it was in my presentation in San Francisco. >=20 > The problem with many IETF groups is we keep going in circle.=20 > Once we decide something, we should stick to it. Otherwise,=20 > it's impossible to make progress.=20 >=20 > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Tuesday, July 14, 2009 10:48 > > To: Audet, Francois (SC100:3055); Paul Kyzivat > > Cc: Dean Willis; SIPCORE > > Subject: RE: [sipcore] rfc4244bis: what is "aor" used for? > >=20 > >=20 > >=20 > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortel.com] > > > Sent: Tuesday, July 14, 2009 12:06 PM > > >=20 > > > > For example, if alice sends a request to=20 > > > > "sip:Robert.Khaled@example.com", which gets sent to=20 > > > > "sip:bob@sales.example.com" and Bob's UAS receives it after > > > that, the > > > > H-I list of ALL "mp" tagged entries will be this: > > > >=20 > > > > H-I: ;mp > > > > H-I: ;mp > > >=20 > > > Actually, no. Absolutely not. You'd get: > > >=20 > > > History-Info: ;aor;index=3D1 > > > History-Info: ;aor;mp;index=3D1.1 > > > History-Info: ;rc;index=3D1.1.1 > >=20 > > Sorry that was a typo - I meant all the "mp" tagged and the=20 > original=20 > > req-uri from Alice would be: > >=20 > > H-I: ;aor > > H-I: ;mp > >=20 > > You would NOT get: > > > History-Info: ;rc;index=3D1.1.1 > >=20 > > ...in the list I'm describing, because that is not "mp"=20 > > tagged - it's in the full H-I list sure, but if you=20 > weed-out/cull the=20 > > list to the first entry and all "mp" tagged ones, you'd get=20 > those two. > > =20 > > -hadriel > >=20 > = From AUDET@nortel.com Tue Jul 14 11:07:53 2009 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 B1B8B3A6D12 for ; Tue, 14 Jul 2009 11:07:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.429 X-Spam-Level: X-Spam-Status: No, score=-6.429 tagged_above=-999 required=5 tests=[AWL=0.170, 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 HDcUN-ZtJdbk for ; Tue, 14 Jul 2009 11:07:53 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id AF6963A67FA for ; Tue, 14 Jul 2009 11:07:52 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6EI7JJ01328; Tue, 14 Jul 2009 18:07:20 GMT 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, 14 Jul 2009 13:06:21 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFA1295@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoEiNpbxezCQaSHQVqnl/jkDh99RwAEiPbQAAQRIlAAAGaggA== References: <1ECE0EB50388174790F9694F77522CCF1EF5190A@zrc2hxm0.corp.nortel.com> <4A5B71AC.6050502@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EF51BFE@zrc2hxm0.corp.nortel.com> <4A5C8B0D.6010107@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EFA0ED2@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Hadriel Kaplan" , "Paul Kyzivat" Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 14 Jul 2009 18:07:53 -0000 Why? How do you substantiate what you are saying? The AOR flag is telling what the location service actually USED for=20 routing by the target domain. It can't get more deterministic than that. The fact that SBCs in the middle (or other do-gooders) muck around with addresses is irrelevant, because those guys' don't put the aor flag. And utimately, what you need is the actual URI that=20 was used IN REALITY for the location look-up. Not semi-bogus addresses in between. > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Tuesday, July 14, 2009 10:54 > To: Audet, Francois (SC100:3055); Paul Kyzivat > Cc: Hans Erik van Elburg; SIPCORE > Subject: RE: [sipcore] rfc4244bis: what is an AoR? >=20 > =20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Tuesday, July 14, 2009 11:57 AM > >=20 > > The beauty of the ;aor tag is that the entry that is valid will be=20 > > tagged with ;aor, but not the "garbagy" one at the begining. > > When trying to figure out "redirection", this is quite useful.=20 > > Otherwise, the "garbagy" one at the begining may be falsy=20 > interpreted=20 > > as a redirecting number, when it was not. > > This is useful for a lot of services. >=20 > I figured that was why the "aor" tag was trying to be clever,=20 > and why target-uri changed the semantic from what Alice sent,=20 > to what Bob's registrar-proxy received, but man is that a=20 > slippery-slope. Request-URI's usernames and domains are=20 > changed a LOT, and people add params, and params get lost,=20 > during that translation. (for example in ENUM routing params=20 > usually go bye-bye, and ones get swapped in trunk-group routing, etc.) >=20 > How do you know if the one sent by Alice was wrong, vs. the=20 > one the registrar received? >=20 > This thing is going to be a tech-support nightmare. :( >=20 > -hadriel >=20 From AUDET@nortel.com Tue Jul 14 11:19:29 2009 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 50FEB3A69EB for ; Tue, 14 Jul 2009 11:19:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.431 X-Spam-Level: X-Spam-Status: No, score=-6.431 tagged_above=-999 required=5 tests=[AWL=0.168, 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 ve5POhdgLkjf for ; Tue, 14 Jul 2009 11:19:28 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id EC88E3A69E4 for ; Tue, 14 Jul 2009 11:19:23 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6EIGXX06890; Tue, 14 Jul 2009 18:16:33 GMT 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, 14 Jul 2009 13:18:08 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFA12DA@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is "aor" used for? thread-index: AcoElPHd5r4AWLvRRcSztLHVoYhIYgAAEOSAAAHSyEAAA31/QAAAO6FAAAA54xAAADuzoA== References: <4A5B7195.6020009@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com><4A5BBE0C.5000301@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> <4A5C9F69.1070701@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EFA0F29@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFA122C@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Hadriel Kaplan" , "Paul Kyzivat" Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 14 Jul 2009 18:19:29 -0000 Yes, the tags are looked exactly for that. Reducing the list. Target-URI scenario look at last aor. Voicemail would look at first AOR (typically). Some other applications look at mp in entry after AOR to determine if = there was a change of logical user (i.e., Freephone). I can't imagine anyone looking at the last entry (the cc/rc). However, it is still there because you never that the last hop is the last hop. Specifically, the phone could send, e.g., a 302. Surely, we need to = capture that because an end-user done redirection is just a real as a proxy done redirection, so we can't prune it. The problem with TODAY's implementation of HI is precisely what you are trying to do, i.e., prune out stuff that YOU personally don't think is useful. You have a specific application in mind. But you may be = breaking somebody else's application by "pruning out" the part the other guy = needs. This is EXACTLY what is wrong with current version of RFC 4244. > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Tuesday, July 14, 2009 10:59 > To: Audet, Francois (SC100:3055); Paul Kyzivat > Cc: Dean Willis; SIPCORE > Subject: RE: [sipcore] rfc4244bis: what is "aor" used for? >=20 >=20 > No I think you mis-understand me. > Or maybe I misunderstand you. :) >=20 > I assume that H-I creates, and the UAS will receive ALL=20 > entries. (well, I don't really believe that, but for sake of=20 > this IETF discussion I do) >=20 > I further assume that a receiving UAS will only look at some=20 > of the entries - effectively reducing the list to smaller set=20 > - based on these tags, in some way or other. Is that a=20 > dangerous assumption? If the tags can't be used to reduce=20 > the list, to let a given application focus on particular=20 > entries, why are there tags? From dean.willis@softarmor.com Tue Jul 14 11:42:03 2009 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 0F8733A6778 for ; Tue, 14 Jul 2009 11:42:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.563 X-Spam-Level: X-Spam-Status: No, score=-3.563 tagged_above=-999 required=5 tests=[AWL=1.036, BAYES_00=-2.599, GB_I_LETTER=-2] 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 TfZnl6rdiWUm for ; Tue, 14 Jul 2009 11:42:02 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id DE2BE3A67B5 for ; Tue, 14 Jul 2009 11:42:01 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6EIdXmY016066 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Jul 2009 13:39:34 -0500 Message-Id: From: Dean Willis To: Hadriel Kaplan In-Reply-To: Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 14 Jul 2009 13:39:27 -0500 References: <4A5B7195.6020009@softarmor.com> <4A5BBF6E.8010105@softarmor.com> X-Mailer: Apple Mail (2.935.3) Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 14 Jul 2009 18:42:03 -0000 On Jul 13, 2009, at 6:45 PM, Hadriel Kaplan wrote: > > >> -----Original Message----- >> From: Dean Willis [mailto:dean.willis@softarmor.com] >> Sent: Monday, July 13, 2009 7:13 PM >> >> Hadriel Kaplan wrote: >> >>>> The real problem is even messier: The goal is to find that which >>>> was sent by the UAC as modified by intermediaries that claim to be >>>> authoritative in doing so. >>> >>> Yes, that was what I meant later in that email about: "In other >>> words, get the req-URI that the UAC or last retargeter sent." >> >> But it's not just a req-URI inserted by a UAC or retarger. A proxy >> might >> legitimately add a parameter to the request URI. This is n't a >> retarget >> -- using that vocabularly, it might be called a non-retargeting >> reparameterization. > > Can you give me an example? What would such a thing be used for, > that it requires a UAS receiving it in the H-I look at it for some > useful purpose? > Let's take this out of the context of "request URI" and into "application parameter set", which relieves us of the need to discuss (for this example) where the application parameter set is encoded in the request. Perhaps a variation of the speed-dialer application will serve to illustrate the use case: Assume Alice's mobile operator like to minimize device configuration, instead putting user-specific information, as much as is possible, into a database accessible by its proxies and application servers. Alice calls her voicemail server by pressing and holding "1" on her mobile device. The mobile device (like every other mobile device from this carrier) has been factory configured to invite "sip:voicemail@example.com " in response to pressing and holding "1". Alice's proxy knows that this is a call from Alice to her voicemail service. It knows she has been authenticated and is authorized to access that service. It also knows that Alice's current preferred language is Esperanto, and that she prefers expedited menus from the voice mail server, that the voice mail server either lacks access to or doesn't understand the per-user configuration database and needs this information encoded into the INVITE request, and that Alice's mobile device did not encode the needed information into the request. Consequently, Alice's proxy needs to add her language and menu preferences to the INVITE. Assuming we're using the currently-approved model of R-URI encoding, the proxy can do this by adding appropriate parameters to the request URI. It hasn't changed the target of the request "sip:voicemail@example.com" (although that might get done by the voicemail load-balancing proxy further down the pipe). All it is doing is adding a couple of parameters. > >> How does that show up in HI? > > As just another HI URI that can be ignored by the UAS. And the > problem is? > Was it a retarget? If so, what kind of two-letter code gets applied? >>> The caveat for ua-loose-route and Target was that if the request was >>> re-targeted, the "original Req-URI" becomes the new one the >>> retargeter uses. Unfortunately, it is really really hard for >>> machines to know when something is a re-target vs. just a simple >>> re-route to the same user. >> >> As I believe you asked, do they NEED to know whether this is a >> retarget >> or re-route for parameter modification? >> They clearly need to know whether parameter modification is >> reequired, >> but I'd argue that this is an entirely independent problem. > > I have no idea what you mean by "parameter modification". A UAS > needs to know whether and which req-URI's were created by re- > targeting, for it to know what the set of URI's to select from for > Target identification, for Original Called Party vs. Redirection > information (e.g., for billing or ISUP generation), for filtering, > for prioritization, etc. > Ah. But the UAS also needs to know what application parameters are being sent to it from the upstream, including the UAC. They might be encoded in a URI that was stored in an H-I entry, but if so, which one? > >>> While I don't disagree the overhead would be a ton less, the actual >>> problem of knowing when a re-target occurs vs. a simple re-route is >>> no easier. In other words, when should the Proxy leave the Target >>> header alone vs. overwrite it. >> >> That's an application-specific question. What function is the proxy >> here >> performing? And in what way is the application invocation entangled >> with >> request routing? > > I'm confused - are you actually asking what the use-cases are/were > for ua-loose-route, Diversion-Redirection, et al? You were part of > those draft discussions. The problem of how any proxy would know > when an identity actually changed or not was also discussed back then. > No, I'm saying that we've gotten the delivery of parameters to applications hopelessly intertangled with the routing of the request to the application. This is something like the "locator/identifier" split problem of DNS/IP, but about a thousand times worse. > If you buy into the idea that it's application-specific, or that > only the UAS would really know, then you can't have Proxies simply > putting in *one* Target header, because they'd never know if/when it > should be changed before getting to the UAS. They'd have to create > a list of them: one new entry every time they re-targeted (or > actually one for every time they did NOT absolutely know they did > NOT retarget, if you can follow that crazy logic). Possibly. I think the change rule could be written more simply. As we do with proxies and header fields: If you don't both 1) know what it is and 2) have a specific reason for changing it, then copy it forward. -- Dean From dean.willis@softarmor.com Tue Jul 14 11:52:35 2009 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 3707F3A6A07 for ; Tue, 14 Jul 2009 11:52:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 4LzV+JvZ--C5 for ; Tue, 14 Jul 2009 11:52:34 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id A2AE23A67B5 for ; Tue, 14 Jul 2009 11:52:33 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6EIKuES015931 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Jul 2009 13:20:58 -0500 Message-Id: From: Dean Willis To: Francois Audet In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 14 Jul 2009 13:20:51 -0500 References: <4A5B7195.6020009@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com> <4A5BBE0C.5000301@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> X-Mailer: Apple Mail (2.935.3) Cc: SIPCORE , Hadriel Kaplan Subject: [sipcore] Paraemeter delivery problem (was Re: rfc4244bis: what is "aor" used for?) 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, 14 Jul 2009 18:52:35 -0000 > Dean said: >> H-I is overkill because it 1) does lots of things, not just >> this URI and parameter transmission function b) is much >> bigger than what is required for URI and parameter >> transmission, and c) doesn't deterministically solve the URI >> and parameter transmission function. >> >> Can you show me a universal algorithm for the UAS to use in >> figuring out which HI entry is is supposed to use? > On Jul 13, 2009, at 6:19 PM, Francois Audet replied: > I assume your question is for "target URI" specifically. > > You would look at the las entry that is not a "rc/cc/rt". > > Bingo. > > Now, your question was loaded. You said "universal" but clearly, > it's not Universal because your are strictly looking at solving the > TargetURI problem. Furthermore, you are strictly trying to solve the > LAST targetURI problem. There are applications that do not use the > LAST but the > FIRST targetURI (for example). Lots of Voice mail systems, again, for > example, do this. > > Therefore, it's not Universal. The TargetURI problem was also slightly mis-stated, which is why I believe we as a working group have been confused about what we're trying to accomplish for a long, long time (and why I pushed back on Christer's draft at the time). I really don't care whether the application uses the "first target URI" or the "last target URI". What I care about is whether or not it finds and understands the parameters it needs to get its job done. Let's talk about what "getting the job done" here means; strictly speaking, it means the application can find the information in the request needed to perform the application's function. The possible presence of that information in a request URI is a historical accident that'll I'll go into momentarily. Your assumption that it matters as to which URI the application uses points to the heart of the problem. In HTTP, there was only ONE URI, and the parameters were in that URI. Hence, HTTP applications can use the request-URI for parameter delivery. We started down a path of trying to re-use HTTPs technique, but screwed up our protocol design so that there are now MANY URIs, and it becomes impossible (in a general way) for an application to guess which one it should be using. Alt 1) So the application has to run back up the stack of URIs until it finds one with a parameter it likes, then use that one. This assumes we have a stack of such URIs which is what you are trying to accomplish with rfc4244bis). Alt 2) JDR's "ua-loose-routing" draft tried to restore the "one and only one request-URI" property, thereby letting us use the HTTP model for parameter delivery, but we seem to have found that too radical for SIP 2.0. Fine, let's either fix the problem and move on to SIP 3.0, since it is the best technical answer, or abandon the idea of R-URI encoded parameters entirely. Alt 3) Another model is to use header fields for application parameter delivery. Applications can find header fields easily enough. They can be escaped and pushed into a URI, and we could write text about how any retargeting proxy takes escaped header fields out of the URI and transforms them into "normal" header fields before retargeting the URI, but in our past infinite wisdom we have decided that Header Field Names are Sacred and Require an RFC. This means that every time some application needs to pass parameters "legally" using header fields, the author has to get an RFC passed through our rather long alimentary canal before using it. You may recall I pushed back against this particular piece of process at the time, too. Alt 4) Christer was headed towards an alternate solution: rather than staying with HTTP's parameterization model, we would use Yet Another Header Field (Target), which would be defined so as to allow user- defined parameter-value strings to be passed without requiring an RFC. This works, mostly, except for the cases where we need to be able to write the parameters along with the base URI on a single line. Christer MOSTLY solved this: We initially populate the Target using a Request-URI, then a retargeter copies the old URI into a new Target. But IIRC, that draft didn't go into the "passing forward rules" necessary to preserve parameters across retargets when those parameters need to be preserved. One model is to presume that each retargeting replaces the parameter set, so that any needed preservation is selectively performed by a retargeter, but I don't think we got into that. This all leads back to the heart of the discussion: I believe that the group of folks working on RFC 4244 are so caught up in the enormity of their task that they don't see its essential uselessness in the one case that we're actually chartered to work on: application parameter passing. Sure, History-Info is a great diagnostic tool, but using it for solving the parameter-passing problem is like using that other diagnostic toll, "MRI", to check for a fever: not only is it a very expensive procedure, it doesn't actually answer the question being asked. Yes, we can redesign applications so that they can get their parameters this way, but doing so is rather like redesigning the human body so that its temperature can be read using an MRI by embedding an MRI-readable thermometer in every abdomen. It can be made to work, but it is an overly costly and invasive approach with probable side-effects that we have not begun to consider. -- Dean From dean.willis@softarmor.com Tue Jul 14 13:07:48 2009 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 605A53A67E1 for ; Tue, 14 Jul 2009 13:07:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.594 X-Spam-Level: X-Spam-Status: No, score=-2.594 tagged_above=-999 required=5 tests=[AWL=0.005, 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 j4O6NefKhGA9 for ; Tue, 14 Jul 2009 13:07:47 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 822F23A6826 for ; Tue, 14 Jul 2009 13:07:47 -0700 (PDT) Received: from [192.168.2.103] (cpe-76-182-198-42.tx.res.rr.com [76.182.198.42]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6EK6B9q016839 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Jul 2009 15:06:13 -0500 Message-Id: <1028C0C9-4D33-40AA-AFEC-CF3D87BE16A0@softarmor.com> From: Dean Willis To: "Francois Audet" In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EFA122C@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 14 Jul 2009 15:06:03 -0500 References: <4A5B7195.6020009@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com><4A5BBE0C.5000301@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> <4A5C9F69.1070701@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EFA0F29@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFA122C@zrc2hxm0.corp.nortel.com> X-Mailer: Apple Mail (2.935.3) Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 14 Jul 2009 20:07:48 -0000 On Jul 14, 2009, at 12:51 PM, Francois Audet wrote: > > The problem with many IETF groups is we keep going in circle. Once we > decide something, we should stick to it. Otherwise, it's impossible to > make progress. I disagree. The most severe problem is that once we have made a mistake and recognized the mistake, we keep making the same mistake again and again. That's how we built our current towering edifice of complexity, confusion, and regret. Admittedly, there may be fine lines between convention, tradition, and dogma. We, however, have leapt over all such lines and buried our collective heads in the sand wherein old dogma has been left to fossilize. To rephrase using an experience I had last week: When a scorpion stings you on the bottom, first move elsewhere, then kill the scorpion. Just wiggling and then sitting on it again to see if the experience improves is not a good idea. Fortunately I learned after the second sting, which is something our working group usually doesn't manage to do. Also fortunately, it wasn't a particularly dangerous scorpion ;-). -- Dean From br@brianrosen.net Tue Jul 14 14:04:47 2009 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 4F95A3A68F3 for ; Tue, 14 Jul 2009 14:04:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 p2UqXCR6Z+ra for ; Tue, 14 Jul 2009 14:04:46 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [74.55.202.130]) by core3.amsl.com (Postfix) with ESMTP id 571873A67A5 for ; Tue, 14 Jul 2009 14:04:46 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=BROS3VMxp) by ebru.winwebhosting.com with esmtpa (Exim 4.69) (envelope-from ) id 1MQoKQ-0006HS-JT; Tue, 14 Jul 2009 15:10:18 -0500 From: "Brian Rosen" To: "'Elwell, John'" , "'James M. Polk'" , References: <0D5F89FAC29E2C41B98A6A762007F5D00221E129@GBNTHT12009MSX.gb002.siemens.net> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00221E129@GBNTHT12009MSX.gb002.siemens.net> Date: Tue, 14 Jul 2009 16:10:25 -0400 Message-ID: <020001ca04bf$21910fe0$64b32fa0$@net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcoETfR87AVYdgYPQCCBhIDhwjtUogAcIDYw Content-Language: en-us X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - ebru.winwebhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - brianrosen.net X-Source: X-Source-Args: X-Source-Dir: Subject: Re: [sipcore] Confusion over target inSIP location-conveyance - and impact on ECRIT phonebcp 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, 14 Jul 2009 21:04:47 -0000 I have raised this very issue with James, and verified it with Jon Peterson and Robert Sparks, and the intention is that the Geolocation header can carry the location of any target, the specific target being that identified in the PIDF, and subject to the privacy requirements of that target. It turns out to be useful to do this in a couple of cases I've run across, although I'm somewhat surprised that everyone agreed it is okay to do so. While I guess I could improve phonebcp by making an explicit statement that, when sent to the PSAP, the location in the header must be that of the caller, I do think it's clear enough that it is. I'll do that in the next rev, although I don't want to hold up sending the current version to the IESG over that tidbit. Brian > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > Sent: Tuesday, July 14, 2009 2:40 AM > To: James M. Polk; sipcore@ietf.org; Brian Rosen > Subject: Confusion over target inSIP location-conveyance - and impact > on ECRIT phonebcp > > In 4.2 it states: > "The UAC can use whatever means it knows of to verify/refresh its > location information before attempting a new request that includes > location." > "its location information" suggests that the UAC is the target. > > In 4.3.3 it states: > "This document gives no guidance how this is accomplished, given the > number of ways a UAC can learn its location" > which suggests similar. > > Similarly in 6.1: > "If a UAC does not learn and store its location locally (a GPS chip) > or from the network (DHCP or LLDP-MED), the UAC MAY learn its LbyR > URI (from DHCP for example)." > Which suggests that a UAC inserts its location, not some other > location. > > And later in 6.1: > "If a UAC has already conveyed location in the original request of a > transaction, and wants to update its location information ..." > > In 6.2: > "If the LbyR URI is > sip:, sips: or pres:, and the UAS wants to learn the UAC's > location," > > In 6.2.1: > "This > means the SIP server is including its version of where it thinks the > UAC is, geographically." > > In 8: > "Conveyance of physical location of a UAC raises privacy concerns" > > and: > "In cases where a session set-up is > retargeted based on the location of the UAC initiating the call or > SIP MESSAGE," > > All these many examples illustrate an implication that the location > target is the UAC. I am sure there are other places too. > > I found a couple of places that contradict this. In 6.2 it states: > "If there > is more than one PIDF-LO with different Target identifiers, then > the UAC is merely telling the UAS where more than one Target is, and > there should not be any conflict." > > I think there are other places that mention locations of multiple > targets in a request, implying they cannot all be the location of the > UAC. > > And in 6.2.1 it states: > "The Location Target identified in > the PIDF-LO may or may not be the location inserter, or the > generator of the request (the UAC or SIP server)." > > So we have inconsistency as to whether a conveyed location is that of > they UAC or not. > > One document that relies on location-conveyance is ECRIT's phonebcp. In > there, I cannot find any reference to a routing entity looking to see > whether a conveyed location has the caller as target or not. It just > assumes that this is the case. So if we were to agree that a conveyed > location is not necessarily the location of the UAC, this will have > impact on phonebcp. > > John From AUDET@nortel.com Tue Jul 14 14:13:03 2009 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 D0D013A6984 for ; Tue, 14 Jul 2009 14:13:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.135 X-Spam-Level: X-Spam-Status: No, score=-6.135 tagged_above=-999 required=5 tests=[AWL=-0.136, BAYES_00=-2.599, J_CHICKENPOX_16=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 GZzbOGDb-W88 for ; Tue, 14 Jul 2009 14:13:00 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 8600B3A69DA for ; Tue, 14 Jul 2009 14:10:15 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6EL7Mk10682; Tue, 14 Jul 2009 21:07:22 GMT 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, 14 Jul 2009 16:08:50 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFA17B4@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoEiNpbxezCQaSHQVqnl/jkDh99RwAEiPbQAAQRIlAAAGaggAAExvoQAAGDBiA= References: <1ECE0EB50388174790F9694F77522CCF1EF5190A@zrc2hxm0.corp.nortel.com> <4A5B71AC.6050502@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EF51BFE@zrc2hxm0.corp.nortel.com> <4A5C8B0D.6010107@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EFA0ED2@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFA1295@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Hadriel Kaplan" , "Paul Kyzivat" Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 14 Jul 2009 21:13:03 -0000 I frankly don't think that the "original parameter" passing from one URI to another makes much sense. The meaning of these parameters could be different accross=20 different URIs. E.g., on one URI a token as a Username could be used as a parameter in another one.=20 Or to take one example that was sent on the list earlier, some "dialling code"@domain.com (1@example.com) could be translated to NETAN-type parameters (vm@example.com; play=3Dhadriel_ann.mp3). It could be even worst: one proxy may use a parameter x=3Dblabla to mean something, and another proxy along the way may use the same parameter x=3Dblabla to mean something else. It's not far fetched at all: I've seen a lot of parameter names from different vendors that look very close. At least with H-I, the original parameters WILL be there associated with the proper entry, if you ever need to use them. > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Tuesday, July 14, 2009 13:42 > To: Audet, Francois (SC100:3055); Paul Kyzivat > Cc: Hans Erik van Elburg; SIPCORE > Subject: RE: [sipcore] rfc4244bis: what is an AoR? >=20 > =20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Tuesday, July 14, 2009 2:06 PM > >=20 > > Why? > > How do you substantiate what you are saying? > > The AOR flag is telling what the location service actually USED for=20 > > routing by the target domain. It can't get more deterministic than=20 > > that. >=20 > I was thinking of it from the original use-case scnarios for=20 > target-uri. Target-uri was not originally meant to (only) be=20 > an improved replacement for P-Called-Party-ID. It was=20 > supposed to allow parameters from the original req-uri=20 > created by Alice to be received all the way at Bob. (Dean=20 > seems to think it was meant to let any middle-proxy add to=20 > those as well, but I don't recall that) But I definitely=20 > like the property that you get when it's what the Registrar=20 > saw, because it avoids the translations problem; so I think=20 > I'll just have to give up on the param-passing idea. From AUDET@nortel.com Tue Jul 14 14:16:43 2009 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 DC14C3A67E1 for ; Tue, 14 Jul 2009 14:16:43 -0700 (PDT) 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 7pep70oMRqn2 for ; Tue, 14 Jul 2009 14:16:43 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id D9AB53A6783 for ; Tue, 14 Jul 2009 14:16:42 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6ELFXJ20639; Tue, 14 Jul 2009 21:15:33 GMT 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, 14 Jul 2009 16:15:19 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFA17E4@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is "aor" used for? thread-index: AcoElPHd5r4AWLvRRcSztLHVoYhIYgAAEOSAAAHSyEAAA31/QAAAO6FAAAA54xAAADuzoAAFnoDAAADrHgA= References: <4A5B7195.6020009@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com><4A5BBE0C.5000301@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> <4A5C9F69.1070701@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EFA0F29@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFA122C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFA12DA@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Hadriel Kaplan" , "Paul Kyzivat" Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 14 Jul 2009 21:16:43 -0000 The rc / cc / rt are the ones I would call "fluff". If I was a proxy, and I was trying to do pruning, those are the ones I would drop. Since we can't count on this necessarily happening (especially with older proxies conforming to 4244 only), it's important that the ones who DO matter are labelled properly. That means aor and mp. If we decide to "consolidate" the fluff together, (say, fluff =3D rt | rc | rt) then it's even more obvious. At this point, I'd rather we mark them as fluff for completeness. Before we actually remove anything, I'd really want to do a thorough review of the backward compatibility implications. > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Tuesday, July 14, 2009 13:56 > To: Audet, Francois (SC100:3055); Paul Kyzivat > Cc: Dean Willis; SIPCORE > Subject: RE: [sipcore] rfc4244bis: what is "aor" used for? >=20 > =20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Tuesday, July 14, 2009 2:18 PM > >=20 > > The problem with TODAY's implementation of HI is precisely what you=20 > > are trying to do, i.e., prune out stuff that YOU personally don't=20 > > think is useful. You have a specific application in mind.=20 > But you may=20 > > be breaking somebody else's application by "pruning out"=20 > the part the=20 > > other guy needs. > > This is EXACTLY what is wrong with current version of RFC 4244. >=20 > I don't think so - or at least I'm consciously trying to=20 > avoid that. :)=20 >=20 > I believe that if you reduce the number of params, when to=20 > set them, etc., you will improve interoperability. (and=20 > possibly even improve *operability* and brittle-ness) >=20 > I also hope there are some entry types that are not going to=20 > be useful to any application; because I have a high degree of=20 > confidence not all of them will make it to a UAS in many=20 > cases, in my world. =20 >=20 > So I'm trying to find which subset are actually sufficient=20 > for all reasonable applications, and which are fluff. >=20 > -hadriel >=20 From HKaplan@acmepacket.com Tue Jul 14 14:38:41 2009 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 4BEE73A677D for ; Tue, 14 Jul 2009 14:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 AOwkFBsSkjhj for ; Tue, 14 Jul 2009 14:38:40 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 609CA3A635F for ; Tue, 14 Jul 2009 14:38:40 -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.1.375.2; Tue, 14 Jul 2009 16:41:43 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 14 Jul 2009 16:41:43 -0400 From: Hadriel Kaplan To: Francois Audet , Paul Kyzivat Date: Tue, 14 Jul 2009 16:41:42 -0400 Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoEiNpbxezCQaSHQVqnl/jkDh99RwAEiPbQAAQRIlAAAGaggAAExvoQ Message-ID: References: <1ECE0EB50388174790F9694F77522CCF1EF5190A@zrc2hxm0.corp.nortel.com> <4A5B71AC.6050502@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EF51BFE@zrc2hxm0.corp.nortel.com> <4A5C8B0D.6010107@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EFA0ED2@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFA1295@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EFA1295@zrc2hxm0.corp.nortel.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 Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 14 Jul 2009 21:38:41 -0000 =20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: Tuesday, July 14, 2009 2:06 PM >=20 > Why? > How do you substantiate what you are saying? > The AOR flag is telling what the location service actually=20 > USED for routing by the target domain. It can't get more=20 > deterministic than that. I was thinking of it from the original use-case scnarios for target-uri. T= arget-uri was not originally meant to (only) be an improved replacement for= P-Called-Party-ID. It was supposed to allow parameters from the original = req-uri created by Alice to be received all the way at Bob. (Dean seems to = think it was meant to let any middle-proxy add to those as well, but I don'= t recall that) But I definitely like the property that you get when it's w= hat the Registrar saw, because it avoids the translations problem; so I thi= nk I'll just have to give up on the param-passing idea. > The fact that SBCs in the middle (or other do-gooders) muck=20 > around with addresses is irrelevant, because those guys'=20 > don't put the aor flag. And utimately, what you need is the=20 > actual URI that was used IN REALITY for the location look-up.=20 > Not semi-bogus addresses in between. As much as one would think that's the case, it ain't, afaict. The SBC's do= n't just muck around with addresses, because (surprise) they can implement = a "location-service lookup", are authoritative for a domain, etc. Not in t= he simple case of Alice and Bob being in the same domain, registering, usin= g email-style addresses, etc. But in the inter-domain case, with E.164's a= nd such - everything described for the logic which requires setting the aor= flag would be true (or at least not deterministically false). But I think= you're right, we wouldn't set the aor flag, even if all the criteria are t= rue. -hadriel From HKaplan@acmepacket.com Tue Jul 14 14:38:41 2009 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 7F31E3A635F for ; Tue, 14 Jul 2009 14:38:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 mu9TEtJO-dMo for ; Tue, 14 Jul 2009 14:38:40 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id AB4503A6826 for ; Tue, 14 Jul 2009 14:38:40 -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.1.375.2; Tue, 14 Jul 2009 16:55:57 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Tue, 14 Jul 2009 16:55:57 -0400 From: Hadriel Kaplan To: Francois Audet , Paul Kyzivat Date: Tue, 14 Jul 2009 16:55:56 -0400 Thread-Topic: [sipcore] rfc4244bis: what is "aor" used for? Thread-Index: AcoElPHd5r4AWLvRRcSztLHVoYhIYgAAEOSAAAHSyEAAA31/QAAAO6FAAAA54xAAADuzoAAFnoDA Message-ID: References: <4A5B7195.6020009@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com><4A5BBE0C.5000301@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> <4A5C9F69.1070701@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EFA0F29@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFA122C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFA12DA@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EFA12DA@zrc2hxm0.corp.nortel.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 Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 14 Jul 2009 21:38:41 -0000 =20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: Tuesday, July 14, 2009 2:18 PM >=20 > The problem with TODAY's implementation of HI is precisely=20 > what you are trying to do, i.e., prune out stuff that YOU=20 > personally don't think is useful. You have a specific=20 > application in mind. But you may be breaking somebody else's=20 > application by "pruning out" the part the other guy needs. > This is EXACTLY what is wrong with current version of RFC 4244. I don't think so - or at least I'm consciously trying to avoid that. :)=20 I believe that if you reduce the number of params, when to set them, etc., = you will improve interoperability. (and possibly even improve *operability*= and brittle-ness) I also hope there are some entry types that are not going to be useful to a= ny application; because I have a high degree of confidence not all of them = will make it to a UAS in many cases, in my world. =20 So I'm trying to find which subset are actually sufficient for all reasonab= le applications, and which are fluff. -hadriel= From mary.barnes@nortel.com Tue Jul 14 15:46:25 2009 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 17FBD3A6F2A for ; Tue, 14 Jul 2009 15:46:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.341 X-Spam-Level: X-Spam-Status: No, score=-6.341 tagged_above=-999 required=5 tests=[AWL=0.258, 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 qBRZtTfvpEcy for ; Tue, 14 Jul 2009 15:46:24 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id F41A73A6F39 for ; Tue, 14 Jul 2009 15:46:23 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6EMh1k21015; Tue, 14 Jul 2009 22:43:01 GMT 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, 14 Jul 2009 17:46:35 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFA1972@zrc2hxm0.corp.nortel.com> In-Reply-To: <1028C0C9-4D33-40AA-AFEC-CF3D87BE16A0@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is "aor" used for? thread-index: AcoEv1Un8Rj4JHZtRGaLoUX8Br0GSAAE+cRg References: <4A5B7195.6020009@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com><4A5BBE0C.5000301@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com><4A5C9F69.1070701@cisco.com><1ECE0EB50388174790F9694F77522CCF1EFA0F29@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EFA122C@zrc2hxm0.corp.nortel.com> <1028C0C9-4D33-40AA-AFEC-CF3D87BE16A0@softarmor.com> From: "Mary Barnes" To: "Dean Willis" , "Francois Audet" Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 14 Jul 2009 22:46:25 -0000 I agree this this solution isn't ideal, but we are working from what we have with RFC 3261 (and to a lesser extent RFC 4244 for backwards compatibility). There are organizations (SDOs and vendors) that need a common building block upon which to build their services. I think this solution is far less dangerous than trying to define something uniquely for each service AND having every vendor implement services differently. I think folks are making this far more complex than what it is.=20 And, following on your analogy, if we're just dealing with some small scorpion bites, then we're not doing too bad. It's when we start encountering the rattlers, copperheads and water mocasins that we should be getting really worried. And, the reality is that in Texas, you will come across those things and you just have to deal with them - there is just no way to avoid those critters sometimes. And, I don't think any of us are so stupid that we are stepping on the same scorpion over and over again.=20 So, back to 4244bis, we're just trying to deal with what we have to work with in terms of RFC 3261 - we're being pragmatic and not perfectionist. I don't think any of us has on rose colored glasses that this is ideal. Until we go to SIP 3.0 (or perhaps better yet "four oh"), this is what we have to work with.=20 Regards, Mary. -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Dean Willis Sent: Tuesday, July 14, 2009 3:06 PM To: Audet, Francois (SC100:3055) Cc: SIPCORE; Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? On Jul 14, 2009, at 12:51 PM, Francois Audet wrote: > > The problem with many IETF groups is we keep going in circle. Once we=20 > decide something, we should stick to it. Otherwise, it's impossible to > make progress. I disagree. The most severe problem is that once we have made a mistake and recognized the mistake, we keep making the same mistake again and again. That's how we built our current towering edifice of complexity, confusion, and regret. Admittedly, there may be fine lines between convention, tradition, and dogma. We, however, have leapt over all such lines and buried our collective heads in the sand wherein old dogma has been left to fossilize. To rephrase using an experience I had last week: When a scorpion stings you on the bottom, first move elsewhere, then kill the scorpion. Just wiggling and then sitting on it again to see if the experience improves is not a good idea. Fortunately I learned after the second sting, which is something our working group usually doesn't manage to do. Also fortunately, it wasn't a particularly dangerous scorpion ;-). -- Dean _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From Martin.Thomson@andrew.com Tue Jul 14 18:22:53 2009 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 8C89B3A67D3 for ; Tue, 14 Jul 2009 18:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 XLOrB48nnrnc for ; Tue, 14 Jul 2009 18:22:52 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 66F9E3A67B0 for ; Tue, 14 Jul 2009 18:22:52 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_14_20_10_49 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 14 Jul 2009 20:10:49 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Jul 2009 19:48:33 -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, 14 Jul 2009 19:48:30 -0500 Message-ID: In-Reply-To: <020001ca04bf$21910fe0$64b32fa0$@net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Confusion over target inSIP location-conveyance - andimpact on ECRIT phonebcp Thread-Index: AcoETfR87AVYdgYPQCCBhIDhwjtUogAcIDYwAAnTlvA= References: <0D5F89FAC29E2C41B98A6A762007F5D00221E129@GBNTHT12009MSX.gb002.siemens.net> <020001ca04bf$21910fe0$64b32fa0$@net> From: "Thomson, Martin" To: "Brian Rosen" , "Elwell, John" , "James M. Polk" , X-OriginalArrivalTime: 15 Jul 2009 00:48:33.0648 (UTC) FILETIME=[FADFE700:01CA04E5] Subject: Re: [sipcore] Confusion over target inSIP location-conveyance - andimpact on ECRIT phonebcp 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, 15 Jul 2009 01:22:53 -0000 SSBzdGlsbCBoYXZlbid0IHNlZW4gYW4gZXhwbGFuYXRpb24gb24gaG93IHRvIHJlc29sdmUgdGhl IGlkZW50aXR5IGJpbmRpbmcgcHJvYmxlbSB3aGVuIGxvY2F0aW9uIGlzIHByb3ZpZGVkIGJ5IHJl ZmVyZW5jZS4gIFRoYXQncyBhIHNtYWxsIHRoaW5nIGZvciBwaG9uZS1iY3AsIGJ1dCBub3QgZm9y IGxvY2F0aW9uLWNvbnZleWFuY2UuDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4g RnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2lwY29yZS1ib3VuY2VzQGll dGYub3JnXSBPbg0KPiBCZWhhbGYgT2YgQnJpYW4gUm9zZW4NCj4gU2VudDogV2VkbmVzZGF5LCAx NSBKdWx5IDIwMDkgNjoxMCBBTQ0KPiBUbzogJ0Vsd2VsbCwgSm9obic7ICdKYW1lcyBNLiBQb2xr Jzsgc2lwY29yZUBpZXRmLm9yZw0KPiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIENvbmZ1c2lvbiBv dmVyIHRhcmdldCBpblNJUCBsb2NhdGlvbi1jb252ZXlhbmNlDQo+IC0gYW5kaW1wYWN0IG9uIEVD UklUIHBob25lYmNwDQo+IA0KPiBJIGhhdmUgcmFpc2VkIHRoaXMgdmVyeSBpc3N1ZSB3aXRoIEph bWVzLCBhbmQgdmVyaWZpZWQgaXQgd2l0aCBKb24NCj4gUGV0ZXJzb24NCj4gYW5kIFJvYmVydCBT cGFya3MsIGFuZCB0aGUgaW50ZW50aW9uIGlzIHRoYXQgdGhlIEdlb2xvY2F0aW9uIGhlYWRlciBj YW4NCj4gY2FycnkgdGhlIGxvY2F0aW9uIG9mIGFueSB0YXJnZXQsIHRoZSBzcGVjaWZpYyB0YXJn ZXQgYmVpbmcgdGhhdA0KPiBpZGVudGlmaWVkDQo+IGluIHRoZSBQSURGLCBhbmQgc3ViamVjdCB0 byB0aGUgcHJpdmFjeSByZXF1aXJlbWVudHMgb2YgdGhhdCB0YXJnZXQuDQo+IA0KPiBJdCB0dXJu cyBvdXQgdG8gYmUgdXNlZnVsIHRvIGRvIHRoaXMgaW4gYSBjb3VwbGUgb2YgY2FzZXMgSSd2ZSBy dW4NCj4gYWNyb3NzLA0KPiBhbHRob3VnaCBJJ20gc29tZXdoYXQgc3VycHJpc2VkIHRoYXQgZXZl cnlvbmUgYWdyZWVkIGl0IGlzIG9rYXkgdG8gZG8NCj4gc28uDQo+IA0KPiBXaGlsZSBJIGd1ZXNz IEkgY291bGQgaW1wcm92ZSBwaG9uZWJjcCBieSBtYWtpbmcgYW4gZXhwbGljaXQgc3RhdGVtZW50 DQo+IHRoYXQsDQo+IHdoZW4gc2VudCB0byB0aGUgUFNBUCwgdGhlIGxvY2F0aW9uIGluIHRoZSBo ZWFkZXIgbXVzdCBiZSB0aGF0IG9mIHRoZQ0KPiBjYWxsZXIsIEkgZG8gdGhpbmsgaXQncyBjbGVh ciBlbm91Z2ggdGhhdCBpdCBpcy4NCj4gDQo+IEknbGwgZG8gdGhhdCBpbiB0aGUgbmV4dCByZXYs IGFsdGhvdWdoIEkgZG9uJ3Qgd2FudCB0byBob2xkIHVwIHNlbmRpbmcNCj4gdGhlDQo+IGN1cnJl bnQgdmVyc2lvbiB0byB0aGUgSUVTRyBvdmVyIHRoYXQgdGlkYml0Lg0KPiANCj4gQnJpYW4NCj4g DQo+ID4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiBGcm9tOiBFbHdlbGwsIEpvaG4g W21haWx0bzpqb2huLmVsd2VsbEBzaWVtZW5zLWVudGVycHJpc2UuY29tXQ0KPiA+IFNlbnQ6IFR1 ZXNkYXksIEp1bHkgMTQsIDIwMDkgMjo0MCBBTQ0KPiA+IFRvOiBKYW1lcyBNLiBQb2xrOyBzaXBj b3JlQGlldGYub3JnOyBCcmlhbiBSb3Nlbg0KPiA+IFN1YmplY3Q6IENvbmZ1c2lvbiBvdmVyIHRh cmdldCBpblNJUCBsb2NhdGlvbi1jb252ZXlhbmNlIC0gYW5kIGltcGFjdA0KPiA+IG9uIEVDUklU IHBob25lYmNwDQo+ID4NCj4gPiBJbiA0LjIgaXQgc3RhdGVzOg0KPiA+ICJUaGUgVUFDIGNhbiB1 c2Ugd2hhdGV2ZXIgbWVhbnMgaXQga25vd3Mgb2YgdG8gdmVyaWZ5L3JlZnJlc2ggaXRzDQo+ID4g ICAgbG9jYXRpb24gaW5mb3JtYXRpb24gYmVmb3JlIGF0dGVtcHRpbmcgYSBuZXcgcmVxdWVzdCB0 aGF0IGluY2x1ZGVzDQo+ID4gICAgbG9jYXRpb24uIg0KPiA+ICJpdHMgbG9jYXRpb24gaW5mb3Jt YXRpb24iIHN1Z2dlc3RzIHRoYXQgdGhlIFVBQyBpcyB0aGUgdGFyZ2V0Lg0KPiA+DQo+ID4gSW4g NC4zLjMgaXQgc3RhdGVzOg0KPiA+ICJUaGlzIGRvY3VtZW50IGdpdmVzIG5vIGd1aWRhbmNlIGhv dyB0aGlzIGlzIGFjY29tcGxpc2hlZCwgZ2l2ZW4gdGhlDQo+ID4gICAgbnVtYmVyIG9mIHdheXMg YSBVQUMgY2FuIGxlYXJuIGl0cyBsb2NhdGlvbiINCj4gPiB3aGljaCBzdWdnZXN0cyBzaW1pbGFy Lg0KPiA+DQo+ID4gU2ltaWxhcmx5IGluIDYuMToNCj4gPiAiSWYgYSBVQUMgZG9lcyBub3QgbGVh cm4gYW5kIHN0b3JlIGl0cyBsb2NhdGlvbiBsb2NhbGx5IChhIEdQUyBjaGlwKQ0KPiA+ICAgIG9y IGZyb20gdGhlIG5ldHdvcmsgKERIQ1Agb3IgTExEUC1NRUQpLCB0aGUgVUFDIE1BWSBsZWFybiBp dHMgTGJ5Ug0KPiA+ICAgIFVSSSAoZnJvbSBESENQIGZvciBleGFtcGxlKS4iDQo+ID4gV2hpY2gg c3VnZ2VzdHMgdGhhdCBhIFVBQyBpbnNlcnRzIGl0cyBsb2NhdGlvbiwgbm90IHNvbWUgb3RoZXIN Cj4gPiBsb2NhdGlvbi4NCj4gPg0KPiA+IEFuZCBsYXRlciBpbiA2LjE6DQo+ID4gIklmIGEgVUFD IGhhcyBhbHJlYWR5IGNvbnZleWVkIGxvY2F0aW9uIGluIHRoZSBvcmlnaW5hbCByZXF1ZXN0IG9m IGENCj4gPiAgICB0cmFuc2FjdGlvbiwgYW5kIHdhbnRzIHRvIHVwZGF0ZSBpdHMgbG9jYXRpb24g aW5mb3JtYXRpb24gLi4uIg0KPiA+DQo+ID4gSW4gNi4yOg0KPiA+ICJJZiB0aGUgTGJ5UiBVUkkg aXMNCj4gPiAgICBzaXA6LCBzaXBzOiBvciBwcmVzOiwgYW5kIHRoZSBVQVMgd2FudHMgdG8gbGVh cm4gdGhlIFVBQydzDQo+ID4gbG9jYXRpb24sIg0KPiA+DQo+ID4gSW4gNi4yLjE6DQo+ID4gIlRo aXMNCj4gPiAgICBtZWFucyB0aGUgU0lQIHNlcnZlciBpcyBpbmNsdWRpbmcgaXRzIHZlcnNpb24g b2Ygd2hlcmUgaXQgdGhpbmtzDQo+IHRoZQ0KPiA+ICAgIFVBQyBpcywgZ2VvZ3JhcGhpY2FsbHku Ig0KPiA+DQo+ID4gSW4gODoNCj4gPiAiQ29udmV5YW5jZSBvZiBwaHlzaWNhbCBsb2NhdGlvbiBv ZiBhIFVBQyByYWlzZXMgcHJpdmFjeSBjb25jZXJucyINCj4gPg0KPiA+IGFuZDoNCj4gPiAiSW4g Y2FzZXMgd2hlcmUgYSBzZXNzaW9uIHNldC11cCBpcw0KPiA+ICAgIHJldGFyZ2V0ZWQgYmFzZWQg b24gdGhlIGxvY2F0aW9uIG9mIHRoZSBVQUMgaW5pdGlhdGluZyB0aGUgY2FsbCBvcg0KPiA+ICAg IFNJUCBNRVNTQUdFLCINCj4gPg0KPiA+IEFsbCB0aGVzZSBtYW55IGV4YW1wbGVzIGlsbHVzdHJh dGUgYW4gaW1wbGljYXRpb24gdGhhdCB0aGUgbG9jYXRpb24NCj4gPiB0YXJnZXQgaXMgdGhlIFVB Qy4gSSBhbSBzdXJlIHRoZXJlIGFyZSBvdGhlciBwbGFjZXMgdG9vLg0KPiA+DQo+ID4gSSBmb3Vu ZCBhIGNvdXBsZSBvZiBwbGFjZXMgdGhhdCBjb250cmFkaWN0IHRoaXMuIEluIDYuMiBpdCBzdGF0 ZXM6DQo+ID4gIklmIHRoZXJlDQo+ID4gICAgaXMgbW9yZSB0aGFuIG9uZSBQSURGLUxPIHdpdGgg ZGlmZmVyZW50IFRhcmdldCBpZGVudGlmaWVycywgdGhlbg0KPiA+ICAgIHRoZSBVQUMgaXMgbWVy ZWx5IHRlbGxpbmcgdGhlIFVBUyB3aGVyZSBtb3JlIHRoYW4gb25lIFRhcmdldCBpcywNCj4gYW5k DQo+ID4gICAgdGhlcmUgc2hvdWxkIG5vdCBiZSBhbnkgY29uZmxpY3QuIg0KPiA+DQo+ID4gSSB0 aGluayB0aGVyZSBhcmUgb3RoZXIgcGxhY2VzIHRoYXQgbWVudGlvbiBsb2NhdGlvbnMgb2YgbXVs dGlwbGUNCj4gPiB0YXJnZXRzIGluIGEgcmVxdWVzdCwgaW1wbHlpbmcgdGhleSBjYW5ub3QgYWxs IGJlIHRoZSBsb2NhdGlvbiBvZiB0aGUNCj4gPiBVQUMuDQo+ID4NCj4gPiBBbmQgaW4gNi4yLjEg aXQgc3RhdGVzOg0KPiA+ICJUaGUgTG9jYXRpb24gVGFyZ2V0IGlkZW50aWZpZWQgaW4NCj4gPiAg ICB0aGUgUElERi1MTyBtYXkgb3IgbWF5IG5vdCBiZSB0aGUgbG9jYXRpb24gaW5zZXJ0ZXIsIG9y IHRoZQ0KPiA+ICAgIGdlbmVyYXRvciBvZiB0aGUgcmVxdWVzdCAodGhlIFVBQyBvciBTSVAgc2Vy dmVyKS4iDQo+ID4NCj4gPiBTbyB3ZSBoYXZlIGluY29uc2lzdGVuY3kgYXMgdG8gd2hldGhlciBh IGNvbnZleWVkIGxvY2F0aW9uIGlzIHRoYXQgb2YNCj4gPiB0aGV5IFVBQyBvciBub3QuDQo+ID4N Cj4gPiBPbmUgZG9jdW1lbnQgdGhhdCByZWxpZXMgb24gbG9jYXRpb24tY29udmV5YW5jZSBpcyBF Q1JJVCdzIHBob25lYmNwLg0KPiBJbg0KPiA+IHRoZXJlLCBJIGNhbm5vdCBmaW5kIGFueSByZWZl cmVuY2UgdG8gYSByb3V0aW5nIGVudGl0eSBsb29raW5nIHRvIHNlZQ0KPiA+IHdoZXRoZXIgYSBj b252ZXllZCBsb2NhdGlvbiBoYXMgdGhlIGNhbGxlciBhcyB0YXJnZXQgb3Igbm90LiBJdCBqdXN0 DQo+ID4gYXNzdW1lcyB0aGF0IHRoaXMgaXMgdGhlIGNhc2UuIFNvIGlmIHdlIHdlcmUgdG8gYWdy ZWUgdGhhdCBhIGNvbnZleWVkDQo+ID4gbG9jYXRpb24gaXMgbm90IG5lY2Vzc2FyaWx5IHRoZSBs b2NhdGlvbiBvZiB0aGUgVUFDLCB0aGlzIHdpbGwgaGF2ZQ0KPiA+IGltcGFjdCBvbiBwaG9uZWJj cC4NCj4gPg0KPiA+IEpvaG4NCj4gDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQo+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+IHNpcGNvcmVAaWV0Zi5v cmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZv ciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVn ZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYg eW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0K aW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVz ZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ0K From Martin.Thomson@andrew.com Tue Jul 14 22:28:04 2009 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 B3B0E3A6945 for ; Tue, 14 Jul 2009 22:28:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.053, 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 qiI6yMfEnYya for ; Tue, 14 Jul 2009 22:28:02 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 6D21B3A67D3 for ; Tue, 14 Jul 2009 22:28:02 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_15_00_49_56 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 15 Jul 2009 00:49:56 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 00:27:41 -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: Wed, 15 Jul 2009 00:27:38 -0500 Message-ID: In-Reply-To: <4A5D64E4.4020008@neustar.biz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Confusion over target inSIP location-conveyance - andimpact on ECRIT phonebcp Thread-Index: AcoFCrLk3EWe/cdiSAWepJ/xuty4IgAAFolw References: <0D5F89FAC29E2C41B98A6A762007F5D00221E129@GBNTHT12009MSX.gb002.siemens.net> <020001ca04bf$21910fe0$64b32fa0$@net> <4A5D64E4.4020008@neustar.biz> From: "Thomson, Martin" To: "Jon Peterson" X-OriginalArrivalTime: 15 Jul 2009 05:27:41.0009 (UTC) FILETIME=[F9146410:01CA050C] Cc: sipcore@ietf.org Subject: Re: [sipcore] Confusion over target inSIP location-conveyance - andimpact on ECRIT phonebcp 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, 15 Jul 2009 05:28:05 -0000 SGkgSm9uLA0KDQpIZXJlJ3MgdGhlIHByb2JsZW06DQpJIGFtIHNpcDptdEBhbmRyZXcuY29tLiAg SSB1c2UgSEVMRCBvciBESENQIHRvIHJlcXVlc3QgYSBsb2NhdGlvbiBVUkkuICBUaGlzIGlzIHdo YXQgaXMgcHV0IGluIG15IFNJUCBJTlZJVEUuICBBIHByb3h5IGRlcmVmZXJlbmNlcyB0aGlzIHRv IGRldGVybWluZSB3aGVyZSB0byByb3V0ZSB0aGUgY2FsbC4gIFRoZXkgZW5jb3VudGVyIHByZXM6 djc2bnMzODkwN3Y2ZTA1QGxpcy5leGFtcGxlLmNvbSBpbiB0aGUgcmVzdWx0aW5nIFBJREYtTE8u ICBUaGUgbG9jYXRpb24gaW5mb3JtYXRpb24gaXMgaWdub3JlZDsgaXQncyBub3QgYXBwbGljYWJs ZSB0byB0aGUgcmVxdWVzdGVyLg0KDQpUaGUgc2VydmVyIHRoYXQgcHJvdmlkZXMgdGhlIGxvY2F0 aW9uIGluZm9ybWF0aW9uIGhhcyBubyBiYXNpcyB0byBkZXRlcm1pbmUgdGhhdCB0aGUgZW50aXR5 IG1ha2luZyBhIHJlcXVlc3QgYW5kIHNpcDptdEBhbmRyZXcuY29tIGFyZSBvbmUgYW5kIHRoZSBz YW1lLiAgVGh1cywgaXQgY2Fubm90IG1ha2UgdGhpcyBhc3NlcnRpb24uICBIRUxEIHJlY29tbWVu ZHMgdGhlIGNyZWF0aW9uIG9mIGEgcHNldWRvbnltIGZvciB0aGlzIHJlYXNvbi4NCg0KSG93IGRv IHdlIHJlc29sdmUgdGhpcz8NCg0KV2UgY291bGQgZGVmaW5lIGEgbWVjaGFuaXNtIGZvciBhc3Nl cnRpbmcgc2lwIGlkZW50aXR5IGluIG90aGVyIGRvbWFpbnMsIHN1Y2ggdGhhdCBIRUxEIGNvdWxk IHVzZSBpdC4gIFNvdW5kcyBhIGJpdCBoZWF2eXdlaWdodCB0byBtZS4NCg0KUHJvdmlkaW5nIGEg bGlua2FnZSBiZXR3ZWVuIHRoZSB0d28gaW4gU0lQIG1pZ2h0IHdvcmssIGJ1dCBpdCBzb3VuZHMg bGlrZSB5b3UgZG9uJ3Qgd2FudCB0byBkbyB0aGF0LiAgU2hhbWUsIGJlY2F1c2UgdGhhdCdzIHRo ZSBlYXNpZXN0LiAgT25lIHNpbXBsZSB3YXkgd291bGQgYmUgdG8gYWRkIGEgJzttZScgcGFyYW1l dGVyIHRvIHRoZSBnZW9sb2NhdGlvbiBoZWFkZXIsIHdoaWNoIGxpbmtzIHRoZSBVQUMgKGlkZW50 aWZpZWQgaW4gRnJvbTopIHRvIHRoZSBsb2NhdGlvbiBvYmplY3QsIGlycmVzcGVjdGl2ZSBvZiB0 aGUgaWRlbnRpZmllZCBwcmVzZW50aXR5Lg0KDQotLU1hcnRpbg0KDQpwLnMuIE9uIGEgc2ltaWxh ciB0aHJlYWQsIEkgdGhpbmsgSSByZW1lbWJlciByZWFkaW5nIHRoYXQgc2lwOm10QGFuZHJldy5j b20gaXMgdGhlIHNhbWUgYXMgcHJlczptdEBhbmRyZXcuY29tLiAgSXMgdGhpcyBndWFyYW50ZWVk IHRydXRoLCBvciBqdXN0IGhpZ2hseSBsaWtlbHk/DQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdl LS0tLS0NCj4gRnJvbTogSm9uIFBldGVyc29uIFttYWlsdG86am9uLnBldGVyc29uQG5ldXN0YXIu Yml6XQ0KPiBTZW50OiBXZWRuZXNkYXksIDE1IEp1bHkgMjAwOSAzOjExIFBNDQo+IFRvOiBUaG9t c29uLCBNYXJ0aW4NCj4gQ2M6IEJyaWFuIFJvc2VuOyBFbHdlbGwsIEpvaG47IEphbWVzIE0uIFBv bGs7IHNpcGNvcmVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzaXBjb3JlXSBDb25mdXNpb24g b3ZlciB0YXJnZXQgaW5TSVAgbG9jYXRpb24tY29udmV5YW5jZQ0KPiAtIGFuZGltcGFjdCBvbiBF Q1JJVCBwaG9uZWJjcA0KPiANCj4gDQo+IFRoZXJlIG11c3QgYmUgc29tZXRoaW5nIEknbSBtaXNz aW5nIGluIHRoaXMgZGlzY3Vzc2lvbiwgYnV0IEkndmUgZm91bmQNCj4gdGhpcyBpc3N1ZSB3aXRo IGlkZW50aXR5IGJpbmRpbmcgYSBiaXQgZWx1c2l2ZS4gUElERiBkb2N1bWVudHMgKGxldA0KPiBh bG9uZSBQSURGLUxPIGRvY3VtZW50cykgbmVjZXNzYXJpbHkgY29udGFpbiBhIGZpZWxkIGRlc2ln bmF0aW5nIHRoZQ0KPiBlbnRpdHkgdGhhdCB0aGUgZG9jdW1lbnQgaXMgc3VwcG9zZWQgdG8gcmVw cmVzZW50IC0gdGhlICJlbnRpdHkiDQo+IGF0dHJpYnV0ZSBvZiA8cHJlc2VuY2U+LiBHaXZlbiB0 aGF0IHRoaXMgYXR0cmlidXRlIGNvbnRhaW5zIGEgVVJJLCBpdA0KPiBjYW4gYmUgYXMgc3BlY2lm aWMgb3Igb3BhcXVlIGFzIGlzIG5lY2Vzc2FyeSBmb3IgdGhlIGFwcGxpY2F0aW9uIGluDQo+IHF1 ZXN0aW9uLiBJdCBhcHBlYXJzIHJlZ2FyZGxlc3Mgb2YgaG93IHRoZSBQSURGIGRvY3VtZW50IGlz IGFjcXVpcmVkDQo+IChieQ0KPiByZWZlcmVuY2Ugb3IgYnkgdmFsdWUpLiBJbiB3aGF0IHdheSBp cyB0aGlzIGVsZW1lbnQgaW5zdWZmaWNpZW50DQo+IGV4YWN0bHk/DQo+IA0KPiBJIHdvdWxkIGNl cnRhaW5seSBiZSBza2VwdGljYWwgb2YgYW55IFNJUC1sYXllciBtZWNoYW5pc20gdGhhdCBpcw0K PiBpbnRlbmRlZCB0byBwcm92aWRlIGEgc2VwYXJhdGUgYWNjb3VudCBvZiBob3cgYSBQSURGIGRv Y3VtZW50IGlzDQo+ICJib3VuZCINCj4gdG8gdGhlIGVudGl0eSBpdCByZXByZXNlbnRzLg0KPiAN Cj4gSm9uIFBldGVyc29uDQo+IE5ldVN0YXIsIEluYy4NCj4gDQo+IFRob21zb24sIE1hcnRpbiB3 cm90ZToNCj4gPiBJIHN0aWxsIGhhdmVuJ3Qgc2VlbiBhbiBleHBsYW5hdGlvbiBvbiBob3cgdG8g cmVzb2x2ZSB0aGUgaWRlbnRpdHkNCj4gYmluZGluZyBwcm9ibGVtIHdoZW4gbG9jYXRpb24gaXMg cHJvdmlkZWQgYnkgcmVmZXJlbmNlLiAgVGhhdCdzIGEgc21hbGwNCj4gdGhpbmcgZm9yIHBob25l LWJjcCwgYnV0IG5vdCBmb3IgbG9jYXRpb24tY29udmV5YW5jZS4NCj4gPg0KPiA+DQo+ID4+IC0t LS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4+IEZyb206IHNpcGNvcmUtYm91bmNlc0BpZXRm Lm9yZyBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24NCj4gPj4gQmVoYWxmIE9m IEJyaWFuIFJvc2VuDQo+ID4+IFNlbnQ6IFdlZG5lc2RheSwgMTUgSnVseSAyMDA5IDY6MTAgQU0N Cj4gPj4gVG86ICdFbHdlbGwsIEpvaG4nOyAnSmFtZXMgTS4gUG9sayc7IHNpcGNvcmVAaWV0Zi5v cmcNCj4gPj4gU3ViamVjdDogUmU6IFtzaXBjb3JlXSBDb25mdXNpb24gb3ZlciB0YXJnZXQgaW5T SVAgbG9jYXRpb24tDQo+IGNvbnZleWFuY2UNCj4gPj4gLSBhbmRpbXBhY3Qgb24gRUNSSVQgcGhv bmViY3ANCj4gPj4NCj4gPj4gSSBoYXZlIHJhaXNlZCB0aGlzIHZlcnkgaXNzdWUgd2l0aCBKYW1l cywgYW5kIHZlcmlmaWVkIGl0IHdpdGggSm9uDQo+ID4+IFBldGVyc29uDQo+ID4+IGFuZCBSb2Jl cnQgU3BhcmtzLCBhbmQgdGhlIGludGVudGlvbiBpcyB0aGF0IHRoZSBHZW9sb2NhdGlvbiBoZWFk ZXINCj4gY2FuDQo+ID4+IGNhcnJ5IHRoZSBsb2NhdGlvbiBvZiBhbnkgdGFyZ2V0LCB0aGUgc3Bl Y2lmaWMgdGFyZ2V0IGJlaW5nIHRoYXQNCj4gPj4gaWRlbnRpZmllZA0KPiA+PiBpbiB0aGUgUElE RiwgYW5kIHN1YmplY3QgdG8gdGhlIHByaXZhY3kgcmVxdWlyZW1lbnRzIG9mIHRoYXQgdGFyZ2V0 Lg0KPiA+Pg0KPiA+PiBJdCB0dXJucyBvdXQgdG8gYmUgdXNlZnVsIHRvIGRvIHRoaXMgaW4gYSBj b3VwbGUgb2YgY2FzZXMgSSd2ZSBydW4NCj4gPj4gYWNyb3NzLA0KPiA+PiBhbHRob3VnaCBJJ20g c29tZXdoYXQgc3VycHJpc2VkIHRoYXQgZXZlcnlvbmUgYWdyZWVkIGl0IGlzIG9rYXkgdG8NCj4g ZG8NCj4gPj4gc28uDQo+ID4+DQo+ID4+IFdoaWxlIEkgZ3Vlc3MgSSBjb3VsZCBpbXByb3ZlIHBo b25lYmNwIGJ5IG1ha2luZyBhbiBleHBsaWNpdA0KPiBzdGF0ZW1lbnQNCj4gPj4gdGhhdCwNCj4g Pj4gd2hlbiBzZW50IHRvIHRoZSBQU0FQLCB0aGUgbG9jYXRpb24gaW4gdGhlIGhlYWRlciBtdXN0 IGJlIHRoYXQgb2YNCj4gdGhlDQo+ID4+IGNhbGxlciwgSSBkbyB0aGluayBpdCdzIGNsZWFyIGVu b3VnaCB0aGF0IGl0IGlzLg0KPiA+Pg0KPiA+PiBJJ2xsIGRvIHRoYXQgaW4gdGhlIG5leHQgcmV2 LCBhbHRob3VnaCBJIGRvbid0IHdhbnQgdG8gaG9sZCB1cA0KPiBzZW5kaW5nDQo+ID4+IHRoZQ0K PiA+PiBjdXJyZW50IHZlcnNpb24gdG8gdGhlIElFU0cgb3ZlciB0aGF0IHRpZGJpdC4NCj4gPj4N Cj4gPj4gQnJpYW4NCj4gPj4NCj4gPj4NCj4gPj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQo+ID4+PiBGcm9tOiBFbHdlbGwsIEpvaG4gW21haWx0bzpqb2huLmVsd2VsbEBzaWVtZW5zLWVu dGVycHJpc2UuY29tXQ0KPiA+Pj4gU2VudDogVHVlc2RheSwgSnVseSAxNCwgMjAwOSAyOjQwIEFN DQo+ID4+PiBUbzogSmFtZXMgTS4gUG9sazsgc2lwY29yZUBpZXRmLm9yZzsgQnJpYW4gUm9zZW4N Cj4gPj4+IFN1YmplY3Q6IENvbmZ1c2lvbiBvdmVyIHRhcmdldCBpblNJUCBsb2NhdGlvbi1jb252 ZXlhbmNlIC0gYW5kDQo+IGltcGFjdA0KPiA+Pj4gb24gRUNSSVQgcGhvbmViY3ANCj4gPj4+DQo+ ID4+PiBJbiA0LjIgaXQgc3RhdGVzOg0KPiA+Pj4gIlRoZSBVQUMgY2FuIHVzZSB3aGF0ZXZlciBt ZWFucyBpdCBrbm93cyBvZiB0byB2ZXJpZnkvcmVmcmVzaCBpdHMNCj4gPj4+ICAgIGxvY2F0aW9u IGluZm9ybWF0aW9uIGJlZm9yZSBhdHRlbXB0aW5nIGEgbmV3IHJlcXVlc3QgdGhhdA0KPiBpbmNs dWRlcw0KPiA+Pj4gICAgbG9jYXRpb24uIg0KPiA+Pj4gIml0cyBsb2NhdGlvbiBpbmZvcm1hdGlv biIgc3VnZ2VzdHMgdGhhdCB0aGUgVUFDIGlzIHRoZSB0YXJnZXQuDQo+ID4+Pg0KPiA+Pj4gSW4g NC4zLjMgaXQgc3RhdGVzOg0KPiA+Pj4gIlRoaXMgZG9jdW1lbnQgZ2l2ZXMgbm8gZ3VpZGFuY2Ug aG93IHRoaXMgaXMgYWNjb21wbGlzaGVkLCBnaXZlbg0KPiB0aGUNCj4gPj4+ICAgIG51bWJlciBv ZiB3YXlzIGEgVUFDIGNhbiBsZWFybiBpdHMgbG9jYXRpb24iDQo+ID4+PiB3aGljaCBzdWdnZXN0 cyBzaW1pbGFyLg0KPiA+Pj4NCj4gPj4+IFNpbWlsYXJseSBpbiA2LjE6DQo+ID4+PiAiSWYgYSBV QUMgZG9lcyBub3QgbGVhcm4gYW5kIHN0b3JlIGl0cyBsb2NhdGlvbiBsb2NhbGx5IChhIEdQUw0K PiBjaGlwKQ0KPiA+Pj4gICAgb3IgZnJvbSB0aGUgbmV0d29yayAoREhDUCBvciBMTERQLU1FRCks IHRoZSBVQUMgTUFZIGxlYXJuIGl0cw0KPiBMYnlSDQo+ID4+PiAgICBVUkkgKGZyb20gREhDUCBm b3IgZXhhbXBsZSkuIg0KPiA+Pj4gV2hpY2ggc3VnZ2VzdHMgdGhhdCBhIFVBQyBpbnNlcnRzIGl0 cyBsb2NhdGlvbiwgbm90IHNvbWUgb3RoZXINCj4gPj4+IGxvY2F0aW9uLg0KPiA+Pj4NCj4gPj4+ IEFuZCBsYXRlciBpbiA2LjE6DQo+ID4+PiAiSWYgYSBVQUMgaGFzIGFscmVhZHkgY29udmV5ZWQg bG9jYXRpb24gaW4gdGhlIG9yaWdpbmFsIHJlcXVlc3Qgb2YNCj4gYQ0KPiA+Pj4gICAgdHJhbnNh Y3Rpb24sIGFuZCB3YW50cyB0byB1cGRhdGUgaXRzIGxvY2F0aW9uIGluZm9ybWF0aW9uIC4uLiIN Cj4gPj4+DQo+ID4+PiBJbiA2LjI6DQo+ID4+PiAiSWYgdGhlIExieVIgVVJJIGlzDQo+ID4+PiAg ICBzaXA6LCBzaXBzOiBvciBwcmVzOiwgYW5kIHRoZSBVQVMgd2FudHMgdG8gbGVhcm4gdGhlIFVB QydzDQo+ID4+PiBsb2NhdGlvbiwiDQo+ID4+Pg0KPiA+Pj4gSW4gNi4yLjE6DQo+ID4+PiAiVGhp cw0KPiA+Pj4gICAgbWVhbnMgdGhlIFNJUCBzZXJ2ZXIgaXMgaW5jbHVkaW5nIGl0cyB2ZXJzaW9u IG9mIHdoZXJlIGl0IHRoaW5rcw0KPiA+Pj4NCj4gPj4gdGhlDQo+ID4+DQo+ID4+PiAgICBVQUMg aXMsIGdlb2dyYXBoaWNhbGx5LiINCj4gPj4+DQo+ID4+PiBJbiA4Og0KPiA+Pj4gIkNvbnZleWFu Y2Ugb2YgcGh5c2ljYWwgbG9jYXRpb24gb2YgYSBVQUMgcmFpc2VzIHByaXZhY3kgY29uY2VybnMi DQo+ID4+Pg0KPiA+Pj4gYW5kOg0KPiA+Pj4gIkluIGNhc2VzIHdoZXJlIGEgc2Vzc2lvbiBzZXQt dXAgaXMNCj4gPj4+ICAgIHJldGFyZ2V0ZWQgYmFzZWQgb24gdGhlIGxvY2F0aW9uIG9mIHRoZSBV QUMgaW5pdGlhdGluZyB0aGUgY2FsbA0KPiBvcg0KPiA+Pj4gICAgU0lQIE1FU1NBR0UsIg0KPiA+ Pj4NCj4gPj4+IEFsbCB0aGVzZSBtYW55IGV4YW1wbGVzIGlsbHVzdHJhdGUgYW4gaW1wbGljYXRp b24gdGhhdCB0aGUgbG9jYXRpb24NCj4gPj4+IHRhcmdldCBpcyB0aGUgVUFDLiBJIGFtIHN1cmUg dGhlcmUgYXJlIG90aGVyIHBsYWNlcyB0b28uDQo+ID4+Pg0KPiA+Pj4gSSBmb3VuZCBhIGNvdXBs ZSBvZiBwbGFjZXMgdGhhdCBjb250cmFkaWN0IHRoaXMuIEluIDYuMiBpdCBzdGF0ZXM6DQo+ID4+ PiAiSWYgdGhlcmUNCj4gPj4+ICAgIGlzIG1vcmUgdGhhbiBvbmUgUElERi1MTyB3aXRoIGRpZmZl cmVudCBUYXJnZXQgaWRlbnRpZmllcnMsIHRoZW4NCj4gPj4+ICAgIHRoZSBVQUMgaXMgbWVyZWx5 IHRlbGxpbmcgdGhlIFVBUyB3aGVyZSBtb3JlIHRoYW4gb25lIFRhcmdldCBpcywNCj4gPj4+DQo+ ID4+IGFuZA0KPiA+Pg0KPiA+Pj4gICAgdGhlcmUgc2hvdWxkIG5vdCBiZSBhbnkgY29uZmxpY3Qu Ig0KPiA+Pj4NCj4gPj4+IEkgdGhpbmsgdGhlcmUgYXJlIG90aGVyIHBsYWNlcyB0aGF0IG1lbnRp b24gbG9jYXRpb25zIG9mIG11bHRpcGxlDQo+ID4+PiB0YXJnZXRzIGluIGEgcmVxdWVzdCwgaW1w bHlpbmcgdGhleSBjYW5ub3QgYWxsIGJlIHRoZSBsb2NhdGlvbiBvZg0KPiB0aGUNCj4gPj4+IFVB Qy4NCj4gPj4+DQo+ID4+PiBBbmQgaW4gNi4yLjEgaXQgc3RhdGVzOg0KPiA+Pj4gIlRoZSBMb2Nh dGlvbiBUYXJnZXQgaWRlbnRpZmllZCBpbg0KPiA+Pj4gICAgdGhlIFBJREYtTE8gbWF5IG9yIG1h eSBub3QgYmUgdGhlIGxvY2F0aW9uIGluc2VydGVyLCBvciB0aGUNCj4gPj4+ICAgIGdlbmVyYXRv ciBvZiB0aGUgcmVxdWVzdCAodGhlIFVBQyBvciBTSVAgc2VydmVyKS4iDQo+ID4+Pg0KPiA+Pj4g U28gd2UgaGF2ZSBpbmNvbnNpc3RlbmN5IGFzIHRvIHdoZXRoZXIgYSBjb252ZXllZCBsb2NhdGlv biBpcyB0aGF0DQo+IG9mDQo+ID4+PiB0aGV5IFVBQyBvciBub3QuDQo+ID4+Pg0KPiA+Pj4gT25l IGRvY3VtZW50IHRoYXQgcmVsaWVzIG9uIGxvY2F0aW9uLWNvbnZleWFuY2UgaXMgRUNSSVQncw0K PiBwaG9uZWJjcC4NCj4gPj4+DQo+ID4+IEluDQo+ID4+DQo+ID4+PiB0aGVyZSwgSSBjYW5ub3Qg ZmluZCBhbnkgcmVmZXJlbmNlIHRvIGEgcm91dGluZyBlbnRpdHkgbG9va2luZyB0bw0KPiBzZWUN Cj4gPj4+IHdoZXRoZXIgYSBjb252ZXllZCBsb2NhdGlvbiBoYXMgdGhlIGNhbGxlciBhcyB0YXJn ZXQgb3Igbm90LiBJdA0KPiBqdXN0DQo+ID4+PiBhc3N1bWVzIHRoYXQgdGhpcyBpcyB0aGUgY2Fz ZS4gU28gaWYgd2Ugd2VyZSB0byBhZ3JlZSB0aGF0IGENCj4gY29udmV5ZWQNCj4gPj4+IGxvY2F0 aW9uIGlzIG5vdCBuZWNlc3NhcmlseSB0aGUgbG9jYXRpb24gb2YgdGhlIFVBQywgdGhpcyB3aWxs IGhhdmUNCj4gPj4+IGltcGFjdCBvbiBwaG9uZWJjcC4NCj4gPj4+DQo+ID4+PiBKb2huDQo+ID4+ Pg0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiA+PiBzaXBjb3JlQGlldGYub3JnDQo+ID4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPiA+Pg0KPiA+DQo+ ID4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IFRoaXMg bWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KPiA+ IGNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2YXRlIGlu Zm9ybWF0aW9uLg0KPiA+IElmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ug bm90aWZ5IHRoZSBzZW5kZXINCj4gPiBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5h bC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQo+ID4gdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVk Lg0KPiA+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPiBb bWYyXQ0KPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQo+ID4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gPiBzaXBjb3JlQGlldGYub3JnDQo+ID4gaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+ID4NCj4gDQoNCi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZv ciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVn ZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYg eW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0K aW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVz ZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ0K From jon.peterson@neustar.biz Tue Jul 14 22:28:25 2009 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 44D763A6860 for ; Tue, 14 Jul 2009 22:28:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.499 X-Spam-Level: X-Spam-Status: No, score=-2.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 D1yf9yu4L+KX for ; Tue, 14 Jul 2009 22:28:23 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 7E3863A67FE for ; Tue, 14 Jul 2009 22:28:23 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1247634681; x=1247721081; h=From:Date:Subject:Message-ID:Content-Type:Content-Transfer-Encoding; b=ncfn7kLZtF9jdMsCibxGsFGyQwAjoFIA0pFHA7pfm2B9FIIcXVFCASBlUIlws1rMsLFRp/Erj3zHzL nPxhWhSQ== Received: from ([10.31.13.108]) by stihiron1.va.neustar.com with ESMTP id 5202702.20383205; Wed, 15 Jul 2009 01:11:00 -0400 Message-ID: <4A5D64E4.4020008@neustar.biz> Date: Tue, 14 Jul 2009 22:11:00 -0700 From: Jon Peterson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "Thomson, Martin" References: <0D5F89FAC29E2C41B98A6A762007F5D00221E129@GBNTHT12009MSX.gb002.siemens.net> <020001ca04bf$21910fe0$64b32fa0$@net> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Confusion over target inSIP location-conveyance - andimpact on ECRIT phonebcp 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, 15 Jul 2009 05:28:25 -0000 There must be something I'm missing in this discussion, but I've found this issue with identity binding a bit elusive. PIDF documents (let alone PIDF-LO documents) necessarily contain a field designating the entity that the document is supposed to represent - the "entity" attribute of . Given that this attribute contains a URI, it can be as specific or opaque as is necessary for the application in question. It appears regardless of how the PIDF document is acquired (by reference or by value). In what way is this element insufficient exactly? I would certainly be skeptical of any SIP-layer mechanism that is intended to provide a separate account of how a PIDF document is "bound" to the entity it represents. Jon Peterson NeuStar, Inc. Thomson, Martin wrote: > I still haven't seen an explanation on how to resolve the identity binding problem when location is provided by reference. That's a small thing for phone-bcp, but not for location-conveyance. > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >> Behalf Of Brian Rosen >> Sent: Wednesday, 15 July 2009 6:10 AM >> To: 'Elwell, John'; 'James M. Polk'; sipcore@ietf.org >> Subject: Re: [sipcore] Confusion over target inSIP location-conveyance >> - andimpact on ECRIT phonebcp >> >> I have raised this very issue with James, and verified it with Jon >> Peterson >> and Robert Sparks, and the intention is that the Geolocation header can >> carry the location of any target, the specific target being that >> identified >> in the PIDF, and subject to the privacy requirements of that target. >> >> It turns out to be useful to do this in a couple of cases I've run >> across, >> although I'm somewhat surprised that everyone agreed it is okay to do >> so. >> >> While I guess I could improve phonebcp by making an explicit statement >> that, >> when sent to the PSAP, the location in the header must be that of the >> caller, I do think it's clear enough that it is. >> >> I'll do that in the next rev, although I don't want to hold up sending >> the >> current version to the IESG over that tidbit. >> >> Brian >> >> >>> -----Original Message----- >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>> Sent: Tuesday, July 14, 2009 2:40 AM >>> To: James M. Polk; sipcore@ietf.org; Brian Rosen >>> Subject: Confusion over target inSIP location-conveyance - and impact >>> on ECRIT phonebcp >>> >>> In 4.2 it states: >>> "The UAC can use whatever means it knows of to verify/refresh its >>> location information before attempting a new request that includes >>> location." >>> "its location information" suggests that the UAC is the target. >>> >>> In 4.3.3 it states: >>> "This document gives no guidance how this is accomplished, given the >>> number of ways a UAC can learn its location" >>> which suggests similar. >>> >>> Similarly in 6.1: >>> "If a UAC does not learn and store its location locally (a GPS chip) >>> or from the network (DHCP or LLDP-MED), the UAC MAY learn its LbyR >>> URI (from DHCP for example)." >>> Which suggests that a UAC inserts its location, not some other >>> location. >>> >>> And later in 6.1: >>> "If a UAC has already conveyed location in the original request of a >>> transaction, and wants to update its location information ..." >>> >>> In 6.2: >>> "If the LbyR URI is >>> sip:, sips: or pres:, and the UAS wants to learn the UAC's >>> location," >>> >>> In 6.2.1: >>> "This >>> means the SIP server is including its version of where it thinks >>> >> the >> >>> UAC is, geographically." >>> >>> In 8: >>> "Conveyance of physical location of a UAC raises privacy concerns" >>> >>> and: >>> "In cases where a session set-up is >>> retargeted based on the location of the UAC initiating the call or >>> SIP MESSAGE," >>> >>> All these many examples illustrate an implication that the location >>> target is the UAC. I am sure there are other places too. >>> >>> I found a couple of places that contradict this. In 6.2 it states: >>> "If there >>> is more than one PIDF-LO with different Target identifiers, then >>> the UAC is merely telling the UAS where more than one Target is, >>> >> and >> >>> there should not be any conflict." >>> >>> I think there are other places that mention locations of multiple >>> targets in a request, implying they cannot all be the location of the >>> UAC. >>> >>> And in 6.2.1 it states: >>> "The Location Target identified in >>> the PIDF-LO may or may not be the location inserter, or the >>> generator of the request (the UAC or SIP server)." >>> >>> So we have inconsistency as to whether a conveyed location is that of >>> they UAC or not. >>> >>> One document that relies on location-conveyance is ECRIT's phonebcp. >>> >> In >> >>> there, I cannot find any reference to a routing entity looking to see >>> whether a conveyed location has the caller as target or not. It just >>> assumes that this is the case. So if we were to agree that a conveyed >>> location is not necessarily the location of the UAC, this will have >>> impact on phonebcp. >>> >>> John >>> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From john.elwell@siemens-enterprise.com Tue Jul 14 23:21:17 2009 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 32B643A696B for ; Tue, 14 Jul 2009 23:21:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.582 X-Spam-Level: X-Spam-Status: No, score=-2.582 tagged_above=-999 required=5 tests=[AWL=0.017, 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 Iwad4ENgM77u for ; Tue, 14 Jul 2009 23:21:15 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 8A6193A689E for ; Tue, 14 Jul 2009 23:21:15 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KMT0039688R73@siemenscomms.co.uk> for sipcore@ietf.org; Wed, 15 Jul 2009 07:19:39 +0100 (BST) Date: Wed, 15 Jul 2009 07:19:37 +0100 From: "Elwell, John" In-reply-to: To: "Thomson, Martin" , Jon Peterson Message-id: <0D5F89FAC29E2C41B98A6A762007F5D002264E85@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] Confusion over target inSIP location-conveyance - andimpact on ECRIT phonebcp Thread-Index: AcoFCrLk3EWe/cdiSAWepJ/xuty4IgAAFolwAAHfvzA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D00221E129@GBNTHT12009MSX.gb002.siemens.net> <020001ca04bf$21910fe0$64b32fa0$@net> <4A5D64E4.4020008@neustar.biz> Cc: sipcore@ietf.org Subject: Re: [sipcore] Confusion over target inSIP location-conveyance - andimpact on ECRIT phonebcp 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, 15 Jul 2009 06:21:17 -0000 So this is where we stand, from my point of view. We can pursue one of several directions: 1) We decide that the identifier in the PIDF document is sufficient to identify the target and, where it is important that the target be the SIP requester (e.g., for SIP request routing), that this can easily be determined by comparing the SIP From or PAI with the PIDF target identifier. In this case, we would at least need to change the many places in location-conveyance that imply that the location target is the UAC. We would also need to add something to phonebcp (at its next update) to point this out. 2) We decide that we need something explicit at the SIP level, such as the ";me" parameter to the Geolocation header field that Martin suggested, that says that the location target is indeed the UAC. 3) We decide that the location target MUST be the UAC. Brian tells me there are use cases where greater flexibility would be desirable, however (I don't know what these are). John > -----Original Message----- > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com]=20 > Sent: 15 July 2009 06:28 > To: Jon Peterson > Cc: Brian Rosen; Elwell, John; James M. Polk; sipcore@ietf.org > Subject: RE: [sipcore] Confusion over target inSIP=20 > location-conveyance - andimpact on ECRIT phonebcp >=20 > Hi Jon, >=20 > Here's the problem: > I am sip:mt@andrew.com. I use HELD or DHCP to request a=20 > location URI. This is what is put in my SIP INVITE. A proxy=20 > dereferences this to determine where to route the call. They=20 > encounter pres:v76ns38907v6e05@lis.example.com in the=20 > resulting PIDF-LO. The location information is ignored; it's=20 > not applicable to the requester. >=20 > The server that provides the location information has no=20 > basis to determine that the entity making a request and=20 > sip:mt@andrew.com are one and the same. Thus, it cannot make=20 > this assertion. HELD recommends the creation of a pseudonym=20 > for this reason. >=20 > How do we resolve this? >=20 > We could define a mechanism for asserting sip identity in=20 > other domains, such that HELD could use it. Sounds a bit=20 > heavyweight to me. >=20 > Providing a linkage between the two in SIP might work, but it=20 > sounds like you don't want to do that. Shame, because that's=20 > the easiest. One simple way would be to add a ';me'=20 > parameter to the geolocation header, which links the UAC=20 > (identified in From:) to the location object, irrespective of=20 > the identified presentity. >=20 > --Martin >=20 > p.s. On a similar thread, I think I remember reading that=20 > sip:mt@andrew.com is the same as pres:mt@andrew.com. Is this=20 > guaranteed truth, or just highly likely? >=20 > > -----Original Message----- > > From: Jon Peterson [mailto:jon.peterson@neustar.biz] > > Sent: Wednesday, 15 July 2009 3:11 PM > > To: Thomson, Martin > > Cc: Brian Rosen; Elwell, John; James M. Polk; sipcore@ietf.org > > Subject: Re: [sipcore] Confusion over target inSIP=20 > location-conveyance > > - andimpact on ECRIT phonebcp > >=20 > >=20 > > There must be something I'm missing in this discussion, but=20 > I've found > > this issue with identity binding a bit elusive. PIDF documents (let > > alone PIDF-LO documents) necessarily contain a field designating the > > entity that the document is supposed to represent - the "entity" > > attribute of . Given that this attribute contains=20 > a URI, it > > can be as specific or opaque as is necessary for the application in > > question. It appears regardless of how the PIDF document is acquired > > (by > > reference or by value). In what way is this element insufficient > > exactly? > >=20 > > I would certainly be skeptical of any SIP-layer mechanism that is > > intended to provide a separate account of how a PIDF document is > > "bound" > > to the entity it represents. > >=20 > > Jon Peterson > > NeuStar, Inc. > >=20 > > Thomson, Martin wrote: > > > I still haven't seen an explanation on how to resolve the identity > > binding problem when location is provided by reference. =20 > That's a small > > thing for phone-bcp, but not for location-conveyance. > > > > > > > > >> -----Original Message----- > > >> From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On > > >> Behalf Of Brian Rosen > > >> Sent: Wednesday, 15 July 2009 6:10 AM > > >> To: 'Elwell, John'; 'James M. Polk'; sipcore@ietf.org > > >> Subject: Re: [sipcore] Confusion over target inSIP location- > > conveyance > > >> - andimpact on ECRIT phonebcp > > >> > > >> I have raised this very issue with James, and verified=20 > it with Jon > > >> Peterson > > >> and Robert Sparks, and the intention is that the=20 > Geolocation header > > can > > >> carry the location of any target, the specific target being that > > >> identified > > >> in the PIDF, and subject to the privacy requirements of=20 > that target. > > >> > > >> It turns out to be useful to do this in a couple of=20 > cases I've run > > >> across, > > >> although I'm somewhat surprised that everyone agreed it=20 > is okay to > > do > > >> so. > > >> > > >> While I guess I could improve phonebcp by making an explicit > > statement > > >> that, > > >> when sent to the PSAP, the location in the header must be that of > > the > > >> caller, I do think it's clear enough that it is. > > >> > > >> I'll do that in the next rev, although I don't want to hold up > > sending > > >> the > > >> current version to the IESG over that tidbit. > > >> > > >> Brian > > >> > > >> > > >>> -----Original Message----- > > >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > >>> Sent: Tuesday, July 14, 2009 2:40 AM > > >>> To: James M. Polk; sipcore@ietf.org; Brian Rosen > > >>> Subject: Confusion over target inSIP location-conveyance - and > > impact > > >>> on ECRIT phonebcp > > >>> > > >>> In 4.2 it states: > > >>> "The UAC can use whatever means it knows of to=20 > verify/refresh its > > >>> location information before attempting a new request that > > includes > > >>> location." > > >>> "its location information" suggests that the UAC is the target. > > >>> > > >>> In 4.3.3 it states: > > >>> "This document gives no guidance how this is accomplished, given > > the > > >>> number of ways a UAC can learn its location" > > >>> which suggests similar. > > >>> > > >>> Similarly in 6.1: > > >>> "If a UAC does not learn and store its location locally (a GPS > > chip) > > >>> or from the network (DHCP or LLDP-MED), the UAC MAY learn its > > LbyR > > >>> URI (from DHCP for example)." > > >>> Which suggests that a UAC inserts its location, not some other > > >>> location. > > >>> > > >>> And later in 6.1: > > >>> "If a UAC has already conveyed location in the original=20 > request of > > a > > >>> transaction, and wants to update its location=20 > information ..." > > >>> > > >>> In 6.2: > > >>> "If the LbyR URI is > > >>> sip:, sips: or pres:, and the UAS wants to learn the UAC's > > >>> location," > > >>> > > >>> In 6.2.1: > > >>> "This > > >>> means the SIP server is including its version of=20 > where it thinks > > >>> > > >> the > > >> > > >>> UAC is, geographically." > > >>> > > >>> In 8: > > >>> "Conveyance of physical location of a UAC raises=20 > privacy concerns" > > >>> > > >>> and: > > >>> "In cases where a session set-up is > > >>> retargeted based on the location of the UAC=20 > initiating the call > > or > > >>> SIP MESSAGE," > > >>> > > >>> All these many examples illustrate an implication that=20 > the location > > >>> target is the UAC. I am sure there are other places too. > > >>> > > >>> I found a couple of places that contradict this. In 6.2=20 > it states: > > >>> "If there > > >>> is more than one PIDF-LO with different Target=20 > identifiers, then > > >>> the UAC is merely telling the UAS where more than=20 > one Target is, > > >>> > > >> and > > >> > > >>> there should not be any conflict." > > >>> > > >>> I think there are other places that mention locations=20 > of multiple > > >>> targets in a request, implying they cannot all be the=20 > location of > > the > > >>> UAC. > > >>> > > >>> And in 6.2.1 it states: > > >>> "The Location Target identified in > > >>> the PIDF-LO may or may not be the location inserter, or the > > >>> generator of the request (the UAC or SIP server)." > > >>> > > >>> So we have inconsistency as to whether a conveyed=20 > location is that > > of > > >>> they UAC or not. > > >>> > > >>> One document that relies on location-conveyance is ECRIT's > > phonebcp. > > >>> > > >> In > > >> > > >>> there, I cannot find any reference to a routing entity=20 > looking to > > see > > >>> whether a conveyed location has the caller as target or not. It > > just > > >>> assumes that this is the case. So if we were to agree that a > > conveyed > > >>> location is not necessarily the location of the UAC,=20 > this will have > > >>> impact on phonebcp. > > >>> > > >>> John > > >>> > > >> _______________________________________________ > > >> sipcore mailing list > > >> sipcore@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sipcore > > >> > > > > > >=20 > --------------------------------------------------------------------- > > --------------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > >=20 > --------------------------------------------------------------------- > > --------------------------- > > > [mf2] > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > >=20 >=20 > -------------------------------------------------------------- > ---------------------------------- > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. =20 > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > -------------------------------------------------------------- > ---------------------------------- > [mf2] >=20 From gonzalo.camarillo@ericsson.com Tue Jul 14 23:40:58 2009 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 4694D3A6945 for ; Tue, 14 Jul 2009 23:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.145 X-Spam-Level: X-Spam-Status: No, score=-4.145 tagged_above=-999 required=5 tests=[AWL=-1.896, BAYES_00=-2.599, HELO_EQ_SE=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 OcsBOK4+37-l for ; Tue, 14 Jul 2009 23:40:57 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 183EE3A68F2 for ; Tue, 14 Jul 2009 23:40:56 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-68-4a5d761e3b58 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 2A.28.18827.E167D5A4; Wed, 15 Jul 2009 08:24:30 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Jul 2009 08:24:30 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Wed, 15 Jul 2009 08:24:30 +0200 Received: from [131.160.126.252] (rvi2-126-252.lmf.ericsson.se [131.160.126.252]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 0D95C245F; Wed, 15 Jul 2009 09:24:30 +0300 (EEST) Message-ID: <4A5D761D.8000808@ericsson.com> Date: Wed, 15 Jul 2009 09:24:29 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jul 2009 06:24:30.0311 (UTC) FILETIME=[E92E9770:01CA0514] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] WGLC: draft-ietf-sipcore-info-events-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, 15 Jul 2009 06:40:58 -0000 Hi, we would like to start the WGLC on the following draft. This WGLC will end on July 29th. http://tools.ietf.org/html/draft-ietf-sipcore-info-events-00 Please, send your comments to this list. Thanks, Gonzalo SIPCORE co-chair From Martin.Thomson@andrew.com Tue Jul 14 23:55:07 2009 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 49CBB3A6B10 for ; Tue, 14 Jul 2009 23:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.547 X-Spam-Level: X-Spam-Status: No, score=-2.547 tagged_above=-999 required=5 tests=[AWL=0.052, 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 aW2nPpXqNhf4 for ; Tue, 14 Jul 2009 23:55:06 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 19EB83A6B0B for ; Tue, 14 Jul 2009 23:55:05 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_15_02_00_51 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 15 Jul 2009 02:00:51 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 01:38:36 -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: Wed, 15 Jul 2009 01:38:33 -0500 Message-ID: In-Reply-To: A<0D5F89FAC29E2C41B98A6A762007F5D002264E85@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Confusion over target inSIP location-conveyance -andimpact on ECRIT phonebcp Thread-Index: AcoFCrLk3EWe/cdiSAWepJ/xuty4IgAAFolwAAHfvzAAAOllsA== References: <0D5F89FAC29E2C41B98A6A762007F5D00221E129@GBNTHT12009MSX.gb002.siemens.net> <020001ca04bf$21910fe0$64b32fa0$@net> <4A5D64E4.4020008@neustar.biz> A<0D5F89FAC29E2C41B98A6A762007F5D002264E85@GBNTHT12009MSX.gb002.siemens.net> From: "Thomson, Martin" To: "Elwell, John" , "Jon Peterson" X-OriginalArrivalTime: 15 Jul 2009 06:38:36.0009 (UTC) FILETIME=[E141DD90:01CA0516] Cc: sipcore@ietf.org Subject: Re: [sipcore] Confusion over target inSIP location-conveyance -andimpact on ECRIT phonebcp 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, 15 Jul 2009 06:55:07 -0000 VGhhdCdzIGEgZ29vZCBjaGFyYWN0ZXJpc2F0aW9uIG9mIHRoZSBjaG9pY2UuICBJJ2xsIG5vdGUg dGhhdCB0aGUgY2xlYW51cCBmcm9tIDEgYWxzbyBhcHBsaWVzIHRvIDIuDQoNCkFzIEkgc3RhdGVk LCBhcyBJIGRvbid0IHRoaW5rIHRoYXQgMSBpcyBmZWFzaWJsZSBmb3IgdGhlIGFmb3JlbWVudGlv bmVkIHJlYXNvbnMuICBFaXRoZXIgb2YgMiBvciAzIGFyZSB3b3JrYWJsZS4NCg0KLS1NYXJ0aW4N Cg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBFbHdlbGwsIEpvaG4gW21h aWx0bzpqb2huLmVsd2VsbEBzaWVtZW5zLWVudGVycHJpc2UuY29tXQ0KPiBTZW50OiBXZWRuZXNk YXksIDE1IEp1bHkgMjAwOSA0OjIwIFBNDQo+IFRvOiBUaG9tc29uLCBNYXJ0aW47IEpvbiBQZXRl cnNvbg0KPiBDYzogQnJpYW4gUm9zZW47IEphbWVzIE0uIFBvbGs7IHNpcGNvcmVAaWV0Zi5vcmcN Cj4gU3ViamVjdDogUkU6IFtzaXBjb3JlXSBDb25mdXNpb24gb3ZlciB0YXJnZXQgaW5TSVAgbG9j YXRpb24tY29udmV5YW5jZQ0KPiAtYW5kaW1wYWN0IG9uIEVDUklUIHBob25lYmNwDQo+IA0KPiBT byB0aGlzIGlzIHdoZXJlIHdlIHN0YW5kLCBmcm9tIG15IHBvaW50IG9mIHZpZXcuIFdlIGNhbiBw dXJzdWUgb25lIG9mDQo+IHNldmVyYWwgZGlyZWN0aW9uczoNCj4gDQo+IDEpIFdlIGRlY2lkZSB0 aGF0IHRoZSBpZGVudGlmaWVyIGluIHRoZSBQSURGIGRvY3VtZW50IGlzIHN1ZmZpY2llbnQgdG8N Cj4gaWRlbnRpZnkgdGhlIHRhcmdldCBhbmQsIHdoZXJlIGl0IGlzIGltcG9ydGFudCB0aGF0IHRo ZSB0YXJnZXQgYmUgdGhlDQo+IFNJUCByZXF1ZXN0ZXIgKGUuZy4sIGZvciBTSVAgcmVxdWVzdCBy b3V0aW5nKSwgdGhhdCB0aGlzIGNhbiBlYXNpbHkgYmUNCj4gZGV0ZXJtaW5lZCBieSBjb21wYXJp bmcgdGhlIFNJUCBGcm9tIG9yIFBBSSB3aXRoIHRoZSBQSURGIHRhcmdldA0KPiBpZGVudGlmaWVy LiBJbiB0aGlzIGNhc2UsIHdlIHdvdWxkIGF0IGxlYXN0IG5lZWQgdG8gY2hhbmdlIHRoZSBtYW55 DQo+IHBsYWNlcyBpbiBsb2NhdGlvbi1jb252ZXlhbmNlIHRoYXQgaW1wbHkgdGhhdCB0aGUgbG9j YXRpb24gdGFyZ2V0IGlzDQo+IHRoZQ0KPiBVQUMuIFdlIHdvdWxkIGFsc28gbmVlZCB0byBhZGQg c29tZXRoaW5nIHRvIHBob25lYmNwIChhdCBpdHMgbmV4dA0KPiB1cGRhdGUpIHRvIHBvaW50IHRo aXMgb3V0Lg0KPiANCj4gMikgV2UgZGVjaWRlIHRoYXQgd2UgbmVlZCBzb21ldGhpbmcgZXhwbGlj aXQgYXQgdGhlIFNJUCBsZXZlbCwgc3VjaCBhcw0KPiB0aGUgIjttZSIgcGFyYW1ldGVyIHRvIHRo ZSBHZW9sb2NhdGlvbiBoZWFkZXIgZmllbGQgdGhhdCBNYXJ0aW4NCj4gc3VnZ2VzdGVkLCB0aGF0 IHNheXMgdGhhdCB0aGUgbG9jYXRpb24gdGFyZ2V0IGlzIGluZGVlZCB0aGUgVUFDLg0KPiANCj4g MykgV2UgZGVjaWRlIHRoYXQgdGhlIGxvY2F0aW9uIHRhcmdldCBNVVNUIGJlIHRoZSBVQUMuIEJy aWFuIHRlbGxzIG1lDQo+IHRoZXJlIGFyZSB1c2UgY2FzZXMgd2hlcmUgZ3JlYXRlciBmbGV4aWJp bGl0eSB3b3VsZCBiZSBkZXNpcmFibGUsDQo+IGhvd2V2ZXIgKEkgZG9uJ3Qga25vdyB3aGF0IHRo ZXNlIGFyZSkuDQo+IA0KPiBKb2huDQo+IA0KPiANCj4gPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2Ut LS0tLQ0KPiA+IEZyb206IFRob21zb24sIE1hcnRpbiBbbWFpbHRvOk1hcnRpbi5UaG9tc29uQGFu ZHJldy5jb21dDQo+ID4gU2VudDogMTUgSnVseSAyMDA5IDA2OjI4DQo+ID4gVG86IEpvbiBQZXRl cnNvbg0KPiA+IENjOiBCcmlhbiBSb3NlbjsgRWx3ZWxsLCBKb2huOyBKYW1lcyBNLiBQb2xrOyBz aXBjb3JlQGlldGYub3JnDQo+ID4gU3ViamVjdDogUkU6IFtzaXBjb3JlXSBDb25mdXNpb24gb3Zl ciB0YXJnZXQgaW5TSVANCj4gPiBsb2NhdGlvbi1jb252ZXlhbmNlIC0gYW5kaW1wYWN0IG9uIEVD UklUIHBob25lYmNwDQo+ID4NCj4gPiBIaSBKb24sDQo+ID4NCj4gPiBIZXJlJ3MgdGhlIHByb2Js ZW06DQo+ID4gSSBhbSBzaXA6bXRAYW5kcmV3LmNvbS4gIEkgdXNlIEhFTEQgb3IgREhDUCB0byBy ZXF1ZXN0IGENCj4gPiBsb2NhdGlvbiBVUkkuICBUaGlzIGlzIHdoYXQgaXMgcHV0IGluIG15IFNJ UCBJTlZJVEUuICBBIHByb3h5DQo+ID4gZGVyZWZlcmVuY2VzIHRoaXMgdG8gZGV0ZXJtaW5lIHdo ZXJlIHRvIHJvdXRlIHRoZSBjYWxsLiAgVGhleQ0KPiA+IGVuY291bnRlciBwcmVzOnY3Nm5zMzg5 MDd2NmUwNUBsaXMuZXhhbXBsZS5jb20gaW4gdGhlDQo+ID4gcmVzdWx0aW5nIFBJREYtTE8uICBU aGUgbG9jYXRpb24gaW5mb3JtYXRpb24gaXMgaWdub3JlZDsgaXQncw0KPiA+IG5vdCBhcHBsaWNh YmxlIHRvIHRoZSByZXF1ZXN0ZXIuDQo+ID4NCj4gPiBUaGUgc2VydmVyIHRoYXQgcHJvdmlkZXMg dGhlIGxvY2F0aW9uIGluZm9ybWF0aW9uIGhhcyBubw0KPiA+IGJhc2lzIHRvIGRldGVybWluZSB0 aGF0IHRoZSBlbnRpdHkgbWFraW5nIGEgcmVxdWVzdCBhbmQNCj4gPiBzaXA6bXRAYW5kcmV3LmNv bSBhcmUgb25lIGFuZCB0aGUgc2FtZS4gIFRodXMsIGl0IGNhbm5vdCBtYWtlDQo+ID4gdGhpcyBh c3NlcnRpb24uICBIRUxEIHJlY29tbWVuZHMgdGhlIGNyZWF0aW9uIG9mIGEgcHNldWRvbnltDQo+ ID4gZm9yIHRoaXMgcmVhc29uLg0KPiA+DQo+ID4gSG93IGRvIHdlIHJlc29sdmUgdGhpcz8NCj4g Pg0KPiA+IFdlIGNvdWxkIGRlZmluZSBhIG1lY2hhbmlzbSBmb3IgYXNzZXJ0aW5nIHNpcCBpZGVu dGl0eSBpbg0KPiA+IG90aGVyIGRvbWFpbnMsIHN1Y2ggdGhhdCBIRUxEIGNvdWxkIHVzZSBpdC4g IFNvdW5kcyBhIGJpdA0KPiA+IGhlYXZ5d2VpZ2h0IHRvIG1lLg0KPiA+DQo+ID4gUHJvdmlkaW5n IGEgbGlua2FnZSBiZXR3ZWVuIHRoZSB0d28gaW4gU0lQIG1pZ2h0IHdvcmssIGJ1dCBpdA0KPiA+ IHNvdW5kcyBsaWtlIHlvdSBkb24ndCB3YW50IHRvIGRvIHRoYXQuICBTaGFtZSwgYmVjYXVzZSB0 aGF0J3MNCj4gPiB0aGUgZWFzaWVzdC4gIE9uZSBzaW1wbGUgd2F5IHdvdWxkIGJlIHRvIGFkZCBh ICc7bWUnDQo+ID4gcGFyYW1ldGVyIHRvIHRoZSBnZW9sb2NhdGlvbiBoZWFkZXIsIHdoaWNoIGxp bmtzIHRoZSBVQUMNCj4gPiAoaWRlbnRpZmllZCBpbiBGcm9tOikgdG8gdGhlIGxvY2F0aW9uIG9i amVjdCwgaXJyZXNwZWN0aXZlIG9mDQo+ID4gdGhlIGlkZW50aWZpZWQgcHJlc2VudGl0eS4NCj4g Pg0KPiA+IC0tTWFydGluDQo+ID4NCj4gPiBwLnMuIE9uIGEgc2ltaWxhciB0aHJlYWQsIEkgdGhp bmsgSSByZW1lbWJlciByZWFkaW5nIHRoYXQNCj4gPiBzaXA6bXRAYW5kcmV3LmNvbSBpcyB0aGUg c2FtZSBhcyBwcmVzOm10QGFuZHJldy5jb20uICBJcyB0aGlzDQo+ID4gZ3VhcmFudGVlZCB0cnV0 aCwgb3IganVzdCBoaWdobHkgbGlrZWx5Pw0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFsIE1lc3Nh Z2UtLS0tLQ0KPiA+ID4gRnJvbTogSm9uIFBldGVyc29uIFttYWlsdG86am9uLnBldGVyc29uQG5l dXN0YXIuYml6XQ0KPiA+ID4gU2VudDogV2VkbmVzZGF5LCAxNSBKdWx5IDIwMDkgMzoxMSBQTQ0K PiA+ID4gVG86IFRob21zb24sIE1hcnRpbg0KPiA+ID4gQ2M6IEJyaWFuIFJvc2VuOyBFbHdlbGws IEpvaG47IEphbWVzIE0uIFBvbGs7IHNpcGNvcmVAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFJl OiBbc2lwY29yZV0gQ29uZnVzaW9uIG92ZXIgdGFyZ2V0IGluU0lQDQo+ID4gbG9jYXRpb24tY29u dmV5YW5jZQ0KPiA+ID4gLSBhbmRpbXBhY3Qgb24gRUNSSVQgcGhvbmViY3ANCj4gPiA+DQo+ID4g Pg0KPiA+ID4gVGhlcmUgbXVzdCBiZSBzb21ldGhpbmcgSSdtIG1pc3NpbmcgaW4gdGhpcyBkaXNj dXNzaW9uLCBidXQNCj4gPiBJJ3ZlIGZvdW5kDQo+ID4gPiB0aGlzIGlzc3VlIHdpdGggaWRlbnRp dHkgYmluZGluZyBhIGJpdCBlbHVzaXZlLiBQSURGIGRvY3VtZW50cyAobGV0DQo+ID4gPiBhbG9u ZSBQSURGLUxPIGRvY3VtZW50cykgbmVjZXNzYXJpbHkgY29udGFpbiBhIGZpZWxkIGRlc2lnbmF0 aW5nDQo+IHRoZQ0KPiA+ID4gZW50aXR5IHRoYXQgdGhlIGRvY3VtZW50IGlzIHN1cHBvc2VkIHRv IHJlcHJlc2VudCAtIHRoZSAiZW50aXR5Ig0KPiA+ID4gYXR0cmlidXRlIG9mIDxwcmVzZW5jZT4u IEdpdmVuIHRoYXQgdGhpcyBhdHRyaWJ1dGUgY29udGFpbnMNCj4gPiBhIFVSSSwgaXQNCj4gPiA+ IGNhbiBiZSBhcyBzcGVjaWZpYyBvciBvcGFxdWUgYXMgaXMgbmVjZXNzYXJ5IGZvciB0aGUgYXBw bGljYXRpb24gaW4NCj4gPiA+IHF1ZXN0aW9uLiBJdCBhcHBlYXJzIHJlZ2FyZGxlc3Mgb2YgaG93 IHRoZSBQSURGIGRvY3VtZW50IGlzDQo+IGFjcXVpcmVkDQo+ID4gPiAoYnkNCj4gPiA+IHJlZmVy ZW5jZSBvciBieSB2YWx1ZSkuIEluIHdoYXQgd2F5IGlzIHRoaXMgZWxlbWVudCBpbnN1ZmZpY2ll bnQNCj4gPiA+IGV4YWN0bHk/DQo+ID4gPg0KPiA+ID4gSSB3b3VsZCBjZXJ0YWlubHkgYmUgc2tl cHRpY2FsIG9mIGFueSBTSVAtbGF5ZXIgbWVjaGFuaXNtIHRoYXQgaXMNCj4gPiA+IGludGVuZGVk IHRvIHByb3ZpZGUgYSBzZXBhcmF0ZSBhY2NvdW50IG9mIGhvdyBhIFBJREYgZG9jdW1lbnQgaXMN Cj4gPiA+ICJib3VuZCINCj4gPiA+IHRvIHRoZSBlbnRpdHkgaXQgcmVwcmVzZW50cy4NCj4gPiA+ DQo+ID4gPiBKb24gUGV0ZXJzb24NCj4gPiA+IE5ldVN0YXIsIEluYy4NCj4gPiA+DQo+ID4gPiBU aG9tc29uLCBNYXJ0aW4gd3JvdGU6DQo+ID4gPiA+IEkgc3RpbGwgaGF2ZW4ndCBzZWVuIGFuIGV4 cGxhbmF0aW9uIG9uIGhvdyB0byByZXNvbHZlIHRoZQ0KPiBpZGVudGl0eQ0KPiA+ID4gYmluZGlu ZyBwcm9ibGVtIHdoZW4gbG9jYXRpb24gaXMgcHJvdmlkZWQgYnkgcmVmZXJlbmNlLg0KPiA+IFRo YXQncyBhIHNtYWxsDQo+ID4gPiB0aGluZyBmb3IgcGhvbmUtYmNwLCBidXQgbm90IGZvciBsb2Nh dGlvbi1jb252ZXlhbmNlLg0KPiA+ID4gPg0KPiA+ID4gPg0KLi4uDQoNCi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdlIGlzIGZvciB0aGUgZGVzaWdu YXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWluIHByaXZpbGVnZWQsIHByb3ByaWV0 YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4gIA0KSWYgeW91IGhhdmUgcmVj ZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNlbmRlcg0KaW1tZWRpYXRlbHkg YW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3JpemVkIHVzZSBvZg0KdGhpcyBl bWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpbbWYyXQ0K From jon.peterson@neustar.biz Wed Jul 15 01:13:41 2009 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 2BC433A69A7 for ; Wed, 15 Jul 2009 01:13:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.087, 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 AU7VFuzjj2C1 for ; Wed, 15 Jul 2009 01:13:39 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 3548F3A684C for ; Wed, 15 Jul 2009 01:13:39 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1247644505; x=1247730905; h=From:Date:Subject:Message-ID:Content-Type:Content-Transfer-Encoding; b=nBsPNTilBC5gTQpzHPsv06PH3eV9C+xy0H9+YU2zik9pzlRmUW5S1WzF4nQdxQMfCoTQCvsroUl6n4 DFMGkenw== Received: from ([10.31.13.108]) by stihiron1.va.neustar.com with ESMTP id 5202702.20387359; Wed, 15 Jul 2009 03:54:54 -0400 Message-ID: <4A5D8B4E.6040501@neustar.biz> Date: Wed, 15 Jul 2009 00:54:54 -0700 From: Jon Peterson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: "Thomson, Martin" References: <0D5F89FAC29E2C41B98A6A762007F5D00221E129@GBNTHT12009MSX.gb002.siemens.net> <020001ca04bf$21910fe0$64b32fa0$@net> <4A5D64E4.4020008@neustar.biz> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Confusion over target inSIP location-conveyance - andimpact on ECRIT phonebcp 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, 15 Jul 2009 08:13:41 -0000 My own interest in this discussion has largely been to prevent the conflation of the UAC with the geopriv target. I've argued that the UAC and the entity in the From header field value are not necessarily equivalent for the purposes of geopriv, thanks to aggregator UAs serving many users, such as IP PBXs, gateways and so forth. I've therefore resisted the proposal that the implicit semantics of the Geolocation header be "this is the location of the UAC." I feel less strongly about semantics of "this is the location of the entity in the From header field", be they implicit or explicit semantics. I can certainly imagine a version of the ";me" parameter as an explicit indication of these semantics that would not fall afoul of this conflation. I do wonder, though, if the semantics of "routing-allowed" overlap with the intention behind ";me". Ultimately, a proxy server decides whether or not it will use the location in the SIP request for routing purposes. Your use case below assumes that the proxy server decision to route based on location is dependent on the PIDF referenced in the SIP request indicating the same target as the SIP layer identity. While ";me" is helpful in that case, I'm not sure that this should be the deciding criteria in all cases. "routing-allowed" communicates a less specific indication of "hey, I think you can use this to route the request", something that could be true even if, for whatever reason, the location in the SIP request doesn't represent the target of my SIP-layer identity, because due to some unusual circumstances the From header field of my request can't have a value that represents "me" at the moment - maybe it's an anonymous URI, for example. My point here is that I think agreement on the sorts of policies that proxy servers should enforce has to inform the sorts of indications we feed into that policy. If we need a way to tell the proxy server that a referenced location is appropriate for routing, we might want something more explicit than ";me". To your postscript, I'd have to say no, there's no necessary equivalence between the resources indicated by those two schemes, only convention links them. Jon Peterson NeuStar, Inc. Thomson, Martin wrote: > Hi Jon, > > Here's the problem: > I am sip:mt@andrew.com. I use HELD or DHCP to request a location URI. This is what is put in my SIP INVITE. A proxy dereferences this to determine where to route the call. They encounter pres:v76ns38907v6e05@lis.example.com in the resulting PIDF-LO. The location information is ignored; it's not applicable to the requester. > > The server that provides the location information has no basis to determine that the entity making a request and sip:mt@andrew.com are one and the same. Thus, it cannot make this assertion. HELD recommends the creation of a pseudonym for this reason. > > How do we resolve this? > > We could define a mechanism for asserting sip identity in other domains, such that HELD could use it. Sounds a bit heavyweight to me. > > Providing a linkage between the two in SIP might work, but it sounds like you don't want to do that. Shame, because that's the easiest. One simple way would be to add a ';me' parameter to the geolocation header, which links the UAC (identified in From:) to the location object, irrespective of the identified presentity. > > --Martin > > p.s. On a similar thread, I think I remember reading that sip:mt@andrew.com is the same as pres:mt@andrew.com. Is this guaranteed truth, or just highly likely? > > >> -----Original Message----- >> From: Jon Peterson [mailto:jon.peterson@neustar.biz] >> Sent: Wednesday, 15 July 2009 3:11 PM >> To: Thomson, Martin >> Cc: Brian Rosen; Elwell, John; James M. Polk; sipcore@ietf.org >> Subject: Re: [sipcore] Confusion over target inSIP location-conveyance >> - andimpact on ECRIT phonebcp >> >> >> There must be something I'm missing in this discussion, but I've found >> this issue with identity binding a bit elusive. PIDF documents (let >> alone PIDF-LO documents) necessarily contain a field designating the >> entity that the document is supposed to represent - the "entity" >> attribute of . Given that this attribute contains a URI, it >> can be as specific or opaque as is necessary for the application in >> question. It appears regardless of how the PIDF document is acquired >> (by >> reference or by value). In what way is this element insufficient >> exactly? >> >> I would certainly be skeptical of any SIP-layer mechanism that is >> intended to provide a separate account of how a PIDF document is >> "bound" >> to the entity it represents. >> >> Jon Peterson >> NeuStar, Inc. >> >> Thomson, Martin wrote: >> >>> I still haven't seen an explanation on how to resolve the identity >>> >> binding problem when location is provided by reference. That's a small >> thing for phone-bcp, but not for location-conveyance. >> >>> >>>> -----Original Message----- >>>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>>> Behalf Of Brian Rosen >>>> Sent: Wednesday, 15 July 2009 6:10 AM >>>> To: 'Elwell, John'; 'James M. Polk'; sipcore@ietf.org >>>> Subject: Re: [sipcore] Confusion over target inSIP location- >>>> >> conveyance >> >>>> - andimpact on ECRIT phonebcp >>>> >>>> I have raised this very issue with James, and verified it with Jon >>>> Peterson >>>> and Robert Sparks, and the intention is that the Geolocation header >>>> >> can >> >>>> carry the location of any target, the specific target being that >>>> identified >>>> in the PIDF, and subject to the privacy requirements of that target. >>>> >>>> It turns out to be useful to do this in a couple of cases I've run >>>> across, >>>> although I'm somewhat surprised that everyone agreed it is okay to >>>> >> do >> >>>> so. >>>> >>>> While I guess I could improve phonebcp by making an explicit >>>> >> statement >> >>>> that, >>>> when sent to the PSAP, the location in the header must be that of >>>> >> the >> >>>> caller, I do think it's clear enough that it is. >>>> >>>> I'll do that in the next rev, although I don't want to hold up >>>> >> sending >> >>>> the >>>> current version to the IESG over that tidbit. >>>> >>>> Brian >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>> Sent: Tuesday, July 14, 2009 2:40 AM >>>>> To: James M. Polk; sipcore@ietf.org; Brian Rosen >>>>> Subject: Confusion over target inSIP location-conveyance - and >>>>> >> impact >> >>>>> on ECRIT phonebcp >>>>> >>>>> In 4.2 it states: >>>>> "The UAC can use whatever means it knows of to verify/refresh its >>>>> location information before attempting a new request that >>>>> >> includes >> >>>>> location." >>>>> "its location information" suggests that the UAC is the target. >>>>> >>>>> In 4.3.3 it states: >>>>> "This document gives no guidance how this is accomplished, given >>>>> >> the >> >>>>> number of ways a UAC can learn its location" >>>>> which suggests similar. >>>>> >>>>> Similarly in 6.1: >>>>> "If a UAC does not learn and store its location locally (a GPS >>>>> >> chip) >> >>>>> or from the network (DHCP or LLDP-MED), the UAC MAY learn its >>>>> >> LbyR >> >>>>> URI (from DHCP for example)." >>>>> Which suggests that a UAC inserts its location, not some other >>>>> location. >>>>> >>>>> And later in 6.1: >>>>> "If a UAC has already conveyed location in the original request of >>>>> >> a >> >>>>> transaction, and wants to update its location information ..." >>>>> >>>>> In 6.2: >>>>> "If the LbyR URI is >>>>> sip:, sips: or pres:, and the UAS wants to learn the UAC's >>>>> location," >>>>> >>>>> In 6.2.1: >>>>> "This >>>>> means the SIP server is including its version of where it thinks >>>>> >>>>> >>>> the >>>> >>>> >>>>> UAC is, geographically." >>>>> >>>>> In 8: >>>>> "Conveyance of physical location of a UAC raises privacy concerns" >>>>> >>>>> and: >>>>> "In cases where a session set-up is >>>>> retargeted based on the location of the UAC initiating the call >>>>> >> or >> >>>>> SIP MESSAGE," >>>>> >>>>> All these many examples illustrate an implication that the location >>>>> target is the UAC. I am sure there are other places too. >>>>> >>>>> I found a couple of places that contradict this. In 6.2 it states: >>>>> "If there >>>>> is more than one PIDF-LO with different Target identifiers, then >>>>> the UAC is merely telling the UAS where more than one Target is, >>>>> >>>>> >>>> and >>>> >>>> >>>>> there should not be any conflict." >>>>> >>>>> I think there are other places that mention locations of multiple >>>>> targets in a request, implying they cannot all be the location of >>>>> >> the >> >>>>> UAC. >>>>> >>>>> And in 6.2.1 it states: >>>>> "The Location Target identified in >>>>> the PIDF-LO may or may not be the location inserter, or the >>>>> generator of the request (the UAC or SIP server)." >>>>> >>>>> So we have inconsistency as to whether a conveyed location is that >>>>> >> of >> >>>>> they UAC or not. >>>>> >>>>> One document that relies on location-conveyance is ECRIT's >>>>> >> phonebcp. >> >>>> In >>>> >>>> >>>>> there, I cannot find any reference to a routing entity looking to >>>>> >> see >> >>>>> whether a conveyed location has the caller as target or not. It >>>>> >> just >> >>>>> assumes that this is the case. So if we were to agree that a >>>>> >> conveyed >> >>>>> location is not necessarily the location of the UAC, this will have >>>>> impact on phonebcp. >>>>> >>>>> John >>>>> >>>>> >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> >>> --------------------------------------------------------------------- >>> >> --------------------------- >> >>> This message is for the designated recipient only and may >>> contain privileged, proprietary, or otherwise private information. >>> If you have received it in error, please notify the sender >>> immediately and delete the original. Any unauthorized use of >>> this email is prohibited. >>> --------------------------------------------------------------------- >>> >> --------------------------- >> >>> [mf2] >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> >>> > > ------------------------------------------------------------------------------------------------ > This message is for the designated recipient only and may > contain privileged, proprietary, or otherwise private information. > If you have received it in error, please notify the sender > immediately and delete the original. Any unauthorized use of > this email is prohibited. > ------------------------------------------------------------------------------------------------ > [mf2] > From john.elwell@siemens-enterprise.com Wed Jul 15 02:46:33 2009 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 0DC453A6B49 for ; Wed, 15 Jul 2009 02:46:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.583 X-Spam-Level: X-Spam-Status: No, score=-2.583 tagged_above=-999 required=5 tests=[AWL=0.016, 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 oouR0cTtw8sm for ; Wed, 15 Jul 2009 02:46:32 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 139E53A67DD for ; Wed, 15 Jul 2009 02:46:31 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KMT00F65HS1KX@siemenscomms.co.uk> for sipcore@ietf.org; Wed, 15 Jul 2009 10:45:37 +0100 (BST) Date: Wed, 15 Jul 2009 10:45:33 +0100 From: "Elwell, John" To: sipcore@ietf.org, "James M. Polk" Message-id: <0D5F89FAC29E2C41B98A6A762007F5D002264FAB@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: Comments on location-conveyance-01 Thread-Index: AcoFMP82C3/ND6PNQciCK2jouHTLAg== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: Subject: [sipcore] Comments on location-conveyance-01 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, 15 Jul 2009 09:46:33 -0000 James, Thanks. This has largely addressed the comments I raised in my review of 00 on 2009-07-02. However, I noticed the following minor points: - There is still a reference to LIS in figure 1 / section 3. - "Location Inserters have the ability to provide instructional=20 parameters about location it has inserted." Change "location it has inserted" to "locations they have inserted". - "LbyR refers to a UA=20 including a location URI in a SIP request header field which can be=20 dereferenced by a Location Recipient to retrieve Alice's Location=20 Object, in the form of a PIDF-LO." I still think this is confusing - it is the URI that is dereferenced, not the header field. Also, Alice is not mentioned elsewhere in the paragraph. I would prefer: "LbyR refers to a UA including in a SIP request header field a location URI that can be dereferenced by a Location Recipient to retrieve a Location Object, in the form of a PIDF-LO." - In addition, of course, my concerns in the thread "Confusion over target..." still exist. John From ietf.hanserik@gmail.com Wed Jul 15 04:43:26 2009 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 4FDB83A6974 for ; Wed, 15 Jul 2009 04:43:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 gXlkrZXVQfNH for ; Wed, 15 Jul 2009 04:43:25 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 985043A6862 for ; Wed, 15 Jul 2009 04:43:24 -0700 (PDT) Received: by ewy26 with SMTP id 26so3947372ewy.37 for ; Wed, 15 Jul 2009 04:43:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=3iCJahI6gyuwKBY5Eg2ldcgTmkNdeW+7RvPClNUnA7c=; b=GBjfOHxq77mifYoiWDXo/egxcZDFIKBPxY20qU8fRXmU1oBO/MDINLxmsLbP9LxxIx 8nJLKzmBgC4eBLWbkrKt395hapkGsG22CmhYmXqQTTFW7oZ6JlPPj32LExmc1P2JId+L PNUOJH+m6XRFm2mn/p05KRrNPJPGWQdEmIviI= 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=GWBmYBFEbZcrgOj3S1La5RdHRAZKCZoINDBwIwujCUUBwtKg6lRYh2D2Qog1ueWgjf vlF46O4wxfXcSaqYmW3J3QYHT2I6Wd3VnTi77dHCZOGrfRmE+XqwvFAiIKRLsyAU+AYJ znprLoTdjYXn9qRXH6UAxf17zXP1fduKMScTw= MIME-Version: 1.0 Received: by 10.210.110.5 with SMTP id i5mr7968862ebc.80.1247658206320; Wed, 15 Jul 2009 04:43:26 -0700 (PDT) In-Reply-To: References: <1ECE0EB50388174790F9694F77522CCF1EF51FF9@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EF521C4@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EF52209@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EF522A1@zrc2hxm0.corp.nortel.com> Date: Wed, 15 Jul 2009 13:43:26 +0200 Message-ID: <9ae56b1e0907150443v31e77f6s4ee671d87fd3e72b@mail.gmail.com> From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=0015174bddf8305952046ebd10b9 Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: Open Issues 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, 15 Jul 2009 11:43:26 -0000 --0015174bddf8305952046ebd10b9 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit This is like the Target header we proposed a while ago, but with a change of keeping all the retargets that would qualify for "mp". ( http://tools.ietf.org/html/draft-holmberg-sip-target-uri-delivery-01) I thought that the wg came to consensus that this needs to be resolved with History-Info. If not... /Hans Erik van Elburg On Tue, Jul 14, 2009 at 3:42 AM, Hadriel Kaplan wrote: > > > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Monday, July 13, 2009 8:14 PM > > > > If there is a tag (anyone), it's 4244bis. > > If there is none, it's 4244. > > Got it. Hate it, but got it. :) > > You're going to hate this idea too, but oh well... the delete key is in > easy reach... so here goes: > I suggest an explicit version tag. The tag appears not in the header field > itself, but in something called a "header-name" part of an > "extension-header" in ABNF rules per rfc3261. I suggest a new "header-name" > value of "R-History-Info". You can pretend the "R" is for > Retargeted-History-Info, or Reduced-History-Info, or > Revisionist-History-Info. :) > > This "R-History-Info" extension-header is a multi-instance type, and a > Proxy only ever adds to it if it is changing the received req-uri *and* > would have set the "mp" flag for the new URI it is adding. The first RHI > entry is added by the first proxy or UAC based on what it received, like in > H-I, even though it's not retargeting to that URI. The extension-header's > header-value is the URI being retargeted to. There are no currently defined > header parameters. > > This RHI header field is not for troubleshooting - it's for actual > processing use. Therefore, there is no incrementing index param, no > embedded Reason header, and no entries created for anything but retargeted > events and their new URI's (and the first one). Privacy does not apply to > this on a header-by-header basis, and thus there is no embedded Privacy > header either - if Privacy:history was requested, no RHI fields would be > created. > > Compared with RFC 4244, the RHI header field would produce a smaller subset > of header instances. In some cases significantly smaller. For example, in > the most common case, only a single RHI header field would be in the > message, regardless of how many proxies were crossed. There is also less > processing overhead for every node in the message path. > > It should be noted that, like RFC 4244, RHI does not produce the smallest > list possible of retargets - in some cases an entry is added when the target > user Identity has not changed - the URI has changed to a new one, but > unbeknownst to the Proxy which added it, the Identity of the human may have > remained the same. For example an entry for " > sip:Robert.Khaled@example.com " and a > subsequent entry for "sip:bob@sales.example.com" > may both have been added, even though they are the same abstract target > human. A proxy cannot know by default that these two targets are the same > identity. Only the UAS would know that, and so it may need to cull the list > down further. > > -hadriel > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --0015174bddf8305952046ebd10b9 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
This is like the Target header we proposed a while ago, but with a cha= nge of keeping all the retargets that would qualify for "mp". (http://tools.ietf.org/html/draft-holmberg-sip-target-uri-delivery-01)

I thought that the wg came to consensus that this needs= to be resolved with History-Info. If not...

/Hans E= rik van Elburg

On Tue, Jul 14, 2009 at 3:42 AM, Hadriel Kap= lan <HKaplan= @acmepacket.com> wrote:


> -----Original Message-----
> From: Francois Audet [mailto:audet= @nortel.com]
> Sent: Monday, July 13, 2009 8:14 PM
>
> If there is a tag (anyone), it's 4244bis.
> If there is none, it's 4244.

Got it. =A0Hate it, but got it. :)

You're going to hate this idea too, but oh well... the delete key is in= easy reach... so here goes:
I suggest an explicit version tag. =A0The tag appears not in the header fie= ld itself, but in something called a "header-name" part of an &qu= ot;extension-header" in ABNF rules per rfc3261. =A0I suggest a new &qu= ot;header-name" value of "R-History-Info". =A0You can preten= d the "R" is for Retargeted-History-Info, or Reduced-History-Info= , or Revisionist-History-Info. :)

This "R-History-Info" extension-header is a multi-instance type, = and a Proxy only ever adds to it if it is changing the received req-uri *an= d* would have set the "mp" flag for the new URI it is adding. =A0= The first RHI entry is added by the first proxy or UAC based on what it rec= eived, like in H-I, even though it's not retargeting to that URI. =A0Th= e extension-header's header-value is the URI being retargeted to. =A0Th= ere are no currently defined header parameters.

This RHI header field is not for troubleshooting - it's for actual proc= essing use. =A0Therefore, there is no incrementing index param, no embedded= Reason header, and no entries created for anything but retargeted events a= nd their new URI's (and the first one). =A0Privacy does not apply to th= is on a header-by-header basis, and thus there is no embedded Privacy heade= r either - if Privacy:history was requested, no RHI fields would be created= .

Compared with RFC 4244, the RHI header field would produce a smaller subset= of header instances. =A0In some cases significantly smaller. =A0For exampl= e, in the most common case, only a single RHI header field would be in the = message, regardless of how many proxies were crossed. =A0There is also less= processing overhead for every node in the message path.

It should be noted that, like RFC 4244, RHI does not produce the smallest l= ist possible of retargets - in some cases an entry is added when the target= user Identity has not changed - the URI has changed to a new one, but unbe= knownst to the Proxy which added it, the Identity of the human may have rem= ained the same. =A0For example an entry for "sip:Robert.Khaled@example.com" and a sub= sequent entry for "sip:= bob@sales.example.com" may both have been added, even though they = are the same abstract target human. =A0A proxy cannot know by default that = these two targets are the same identity. =A0Only the UAS would know that, a= nd so it may need to cull the list down further.

-hadriel

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

--0015174bddf8305952046ebd10b9-- From ietf.hanserik@gmail.com Wed Jul 15 05:19:52 2009 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 B41993A6B8D for ; Wed, 15 Jul 2009 05:19:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_47=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 9ojlxR9kJbQH for ; Wed, 15 Jul 2009 05:19:51 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id A76723A68AB for ; Wed, 15 Jul 2009 05:19:50 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so1121775eye.31 for ; Wed, 15 Jul 2009 05:19:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=kZ03csN5IqnWKup+oVHC72uUA9YMhnFaD1UX07nRqPw=; b=UIgleGbWVE1ZgDkYUlrY6bdF8b4nr8dCYX/ipCHxEGdWluG7aQbKTFqtXNZq0QYrPf ov3gexoMUmGTHd8AV+muSJLutP4hD5FSu/z8kgw/AdDiGf3zec45PNqwNVKaUdv2/sBa J2MFpqIjYZ5VD3B/IJJQS35u+pjnlTHMt4mNw= 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=Ga25oIkYm0EgnsR11KnSlIElieDt7bs1zP96k6decimG69iU7d7qbnpAQsNkHcW2w2 iSCollhUis/IvSLjqVRPh/J6gUIBZdC1hNKJOKlSMGAsAJNrPfb//V3os6VzgYDC5tQ2 3oP50VBvyp7v/nkxlJmgFTtKYIL1/wGIFeM1k= MIME-Version: 1.0 Received: by 10.210.112.1 with SMTP id k1mr8074532ebc.11.1247660369000; Wed, 15 Jul 2009 05:19:29 -0700 (PDT) In-Reply-To: <4A5C8B0D.6010107@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF1EF5190A@zrc2hxm0.corp.nortel.com> <4A5B71AC.6050502@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EF51BFE@zrc2hxm0.corp.nortel.com> <4A5C8B0D.6010107@cisco.com> Date: Wed, 15 Jul 2009 14:19:28 +0200 Message-ID: <9ae56b1e0907150519je7cab97x6c1324a302df1a92@mail.gmail.com> From: Hans Erik van Elburg To: Paul Kyzivat Content-Type: multipart/alternative; boundary=0015174bea74183a30046ebd912d Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 15 Jul 2009 12:19:52 -0000 --0015174bea74183a30046ebd912d Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit On Tue, Jul 14, 2009 at 3:41 PM, Paul Kyzivat wrote: > Francois, > > Maybe we can puzzle this out by examining more use cases. > You focused on digit manipulation, which is surely one. But there are > others. > > To spell out the digit manipulation case in more detail: > > A proxy receives a request with sip R-URI in the domain it is responsible > for. It sees that the user part is all digits. (E.g sip:81234@example.net) > It then applies some sort of digit map it has been provisioned with > (possibly per-caller, possibly per-domain) to transform that into some other > more globally unique URI - perhaps an E.164 number in its own domain or some > other domain, or a TEL URI. (E.g. sip:+12125551234@example.net;user=phone.) > It does the translation and then proceeds based on the result. I agree in > this case it is wrong to call the incoming R-URI an AOR. > What property does this not make an AOR? How does it matter whether there are multiple translation steps in a domain? What matters that if I sent something to: sip:81234@example.net that it will be delivered to the intended party. In this sense this is an AOR. I could put this on my business card for example. > > A different case is synonyms or aliases: > > A proxy responsible for example.net receives a request with R-URI > sip:phk@example.net . This is not in its location > service. But it has a provisioned alias table that says phk is a synonym for > paul.kyzivat, so it translates the R-URI to sip:paul.kyzivat@example.net. > It then proceeds to process that, which turns out to be in its location > service, so it translates it again to sip:line1@phone1.paulk.example.net > . > Again, I don't think sip:phk@example.net is an AoR > in this case. > I do think this is an AOR allright. The alias mapping can well be performed by an abstract-location-service. What property does this not make an AOR? How does it matter whether there are multiple translation steps in a domain? What matters that if I sent something to: sip:phk@example.net that it will be delivered to the intended party. In this sense this is an AOR. You could put this on your business card for example. > > Another case, for forwarding: > > A proxy responsible for example.net receives a request with R-URI of > sip:paul.kyzivat@example.net . There is a > location service with an entry registered for > sip:line1@phone1.paulk.example.net , > but there is also provisioning independent of the location service that says > to unconditionally forward all calls to this URI to sip:audet@nortel.com. > This is accomplished by R-URI translation. (To ensure that the request will > not be rejected as mis-addressed.) > > In this case I think that sip:paul.kyzivat@example.net*is* an AoR. > Yes. > > And one final forwarding case: > > A proxy responsible for example.net receives a request with R-URI of > sip:alice.smith@example.net . Alice used to > work for Example Co, but she no longer does, so her URI is "out of service". > But the proxy has been provisioned to translate the R-URI of Alice's calls > to her old boss' URI: sip:betty.jones@example.net. > There will never be an entry in the location service for alice, > registrations are not permitted. > > In this case, in spite of there being no location service involved, I still > think sip:alice.smith@example.net is an > AoR. > Yes, the abstract-location-service returns the address of betty. But this IS really a border case that makes me wonder. > > So, IMO the bottom line is that whether a URI is an AoR is a policy > decision within the domain of the URI. > It is unclear to me what definition of AOR you are using. > > Thanks, > Paul > > > > Francois Audet wrote: > >> >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Monday, July 13, >>> 2009 10:41 >>> To: Audet, Francois (SC100:3055) >>> Cc: Hadriel Kaplan; Hans Erik van Elburg; SIPCORE >>> Subject: Re: [sipcore] rfc4244bis: what is an AoR? >>> >>> >>> >>> Francois Audet wrote: >>> >>>> To me it's crystal clear. >>>> >>>> If you are the entity (proxy or redirect server) >>>> >>> responsible for the >>> >>>> URI, and you find the entry in your location service, you >>>> >>> mark as AOR. >>> >>>> That means you will now route based on "rules" you have internally, >>>> e.g., map it to a contact, etc. >>>> >>> I think some cases are clear, others not so much: >>> >>> - If the proxy translates to a contact that it got from a >>> location service and that entry was placed there by a REGISTER, >>> then the entry should definitely be marked as an AoR >>> >> >> Agree. >> >> - If the proxy translates to a contact that it got from a >>> ocation service, and that entry got there somehow other than REGISTER, >>> then I *think* the entry should still be marked as an AoR. >>> >> >> Yes, agree. >> >> - If the proxy uses some other logic than a "location service" >>> to translate the URI, but it might in other cases use the >>> location service to translate the URI, then I'm not sure. >>> >>> - If the proxy never uses a location service for this URI, >>> but translates it on some other basis, then again I'm not sure. >>> >>> One problem here is that the location service is abstract. There are >>> things that can be done using it, or in another manner. It seems to me that >>> if it *could* have been done with a location service lookup, then the result >>> ought to be the same whether it is or not. >>> >> >> I think the last two are the same thing. >> Things like digit manipulation and so forth. >> >> I didn't want to alter (or second-guess) the definition of AOR (which is >> the realm of RFC 3261), in this draft. >> >> I would think that if the proxy doesn't know that it's an AOR, then it >> shouldn't mark >> it as such. So I would expect mechanical digit manipulation to NOT be >> marked as AOR. >> >> >> --0015174bea74183a30046ebd912d Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable

On Tue, Jul 14, 2009 at 3:41 PM, Paul Ky= zivat <pkyzivat@= cisco.com> wrote:
Francois,

Maybe we can puzzle this out by examining more use cases.
You focused on digit manipulation, which is surely one. But there are other= s.

To spell out the digit manipulation case in more detail:

A proxy receives a request with sip R-URI in the domain it is responsible f= or. It sees that the user part is all digits. (E.g sip:81234@example.net) It then app= lies some sort of digit map it has been provisioned with (possibly per-call= er, possibly per-domain) to transform that into some other more globally un= ique URI - perhaps an E.164 number in its own domain or some other domain, = or a TEL URI. (E.g. sip:+12125551234@example.net;user=3Dphone.) It does the = translation and then proceeds based on the result. I agree in this case it = is wrong to call the incoming R-URI an AOR.

What property does this not make an AOR?
How does it matter whether there are multiple translation steps in= a domain?
=A0

A different case is synonyms or aliases:

A proxy responsible for ex= ample.net receives a request with R-URI sip:phk@example.net. This is not in its loc= ation service. But it has a provisioned alias table that says phk is a syno= nym for paul.kyzivat, so it translates the R-URI to sip:paul.kyzivat@example.net. It then proceeds to process that, which turns out to be in its location= service, so it translates it again to sip:line1@phone1.paulk.example.net.
Again, I don't think sip:phk@example.net is an AoR in this case.

I do think this is an AOR allright. The al= ias mapping can well be performed by an abstract-location-service.
What property does this not make an AOR?
How does it matte= r whether there are multiple translation steps in a domain?
What matters that if I sent something to:=A0sip:phk@example.net=A0that it will be = delivered to the intended party. In this sense this is an AOR. You could pu= t this on your business card for example.

=A0

Another case, for forwarding:

A proxy responsible for ex= ample.net receives a request with R-URI of sip:paul.kyzivat@example.net. T= here is a location service with an entry registered for sip:line1@phone1.pau= lk.example.net, but there is also provisioning independent of the locat= ion service that says to unconditionally forward all calls to this URI to <= a href=3D"mailto:sip%3Aaudet@nortel.com" target=3D"_blank">sip:audet@nortel= .com. This is accomplished by R-URI translation. (To ensure that the re= quest will not be rejected as mis-addressed.)

In this case I think that sip:paul.kyzivat@example.net *is* an AoR.

Yes.
=A0

And one final forwarding case:

A proxy responsible for ex= ample.net receives a request with R-URI of sip:alice.smith@example.net. Ali= ce used to work for Example Co, but she no longer does, so her URI is "= ;out of service". But the proxy has been provisioned to translate the = R-URI of Alice's calls to her old boss' URI: sip:betty.jones@example.net. There will never be an entry in the location service for alice, registra= tions are not permitted.

In this case, in spite of there being no location service involved, I still= think s= ip:alice.smith@example.net is an AoR.

Yes, the abstract-location-service returns= the address of betty. But this IS really a border case that makes me wonde= r.
=A0

So, IMO the bottom line is that whether a URI is an AoR is a policy decisio= n within the domain of the URI.

It is unclear to me what definition of AOR= you are using.
=A0

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



Francois Audet wrote:
=A0
-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Monday, July 13, 2009 10:41
To: Audet, Francois (SC100:3055)
Cc: Hadriel Kaplan; Hans Erik van Elburg; SIPCORE
Subject: Re: [sipcore] rfc4244bis: what is an AoR?



Francois Audet wrote:
To me it's crystal clear.

If you are the entity (proxy or redirect server)
responsible for the
URI, and you find the entry in your location service, you
mark as AOR.
That means you will now route based on "rules" you have internall= y, e.g., map it to a contact, etc.
I think some cases are clear, others not so much:

- If the proxy translates to a contact that it got from a
=A0 location service and that entry was placed there by a REGISTER,
=A0 then the entry should definitely be marked as an AoR

Agree.

- If the proxy translates to a contact that it got from a
=A0 ocation service, and that entry got there somehow other than REGISTER,=
=A0 then I *think* the entry should still be marked as an AoR.

Yes, agree.

- If the proxy uses some other logic than a "location service" =A0 to translate the URI, but it might in other cases use the
=A0 location service to translate the URI, then I'm not sure.

- If the proxy never uses a location service for this URI,
=A0 but translates it on some other basis, then again I'm not sure.
One problem here is that the location service is abstract. There are things= that can be done using it, or in another manner. It seems to me that if it= *could* have been done with a location service lookup, then the result oug= ht to be the same whether it is or not.

I think the last two are the same thing.
Things like digit manipulation and so forth.

I didn't want to alter (or second-guess) the definition of AOR (which i= s the realm of RFC 3261), in this draft.

I would think that if the proxy doesn't know that it's an AOR, then= it shouldn't mark
it as such. So I would expect mechanical digit manipulation to NOT be marke= d as AOR.



--0015174bea74183a30046ebd912d-- From ietf.hanserik@gmail.com Wed Jul 15 05:47:48 2009 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 42CC13A6B27 for ; Wed, 15 Jul 2009 05:47:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 aB3k+8MpXAAs for ; Wed, 15 Jul 2009 05:47:47 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id 2113C3A680C for ; Wed, 15 Jul 2009 05:47:46 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so1125886eye.31 for ; Wed, 15 Jul 2009 05:47:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=YO1tT9XynOQc8mGMRBs9LQrzKzdQt+bEK73pLwIgMno=; b=MBij7xlicsocm8mTLhxvpY9wM2wiIatntF1vTR9hfVwoWQ3Rh51T2qMJJHYQyv9sp+ yhhRt/IxNHU94VWRZKmgaAMd9wx7N6PjRTt98xgN3LdZxOugsKlVSejlfEpwtB5PNv6K lAnJpan+2+gz0MYmluAEbGM+JZo6Fu94RQ85Y= 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=I2rWjxvUK7ji6nrwK/AQf/WUG7qCE+qI1/G5qATAfWwg/tjYc6EwbdyP/uO9lzN0w6 1YJ4LINrPJEBiLJ/6PCYjZeGh2ojKx4FO/ZzRmdwpj+6i+0mY9M26POGfa54uK2MfH5F j1kcPIFv+MMqSZyIONdaBFwp/z90j36/nwu+Q= MIME-Version: 1.0 Received: by 10.210.110.5 with SMTP id i5mr8033951ebc.80.1247661651528; Wed, 15 Jul 2009 05:40:51 -0700 (PDT) In-Reply-To: References: <4A5B7195.6020009@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com> <4A5BBE0C.5000301@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> Date: Wed, 15 Jul 2009 14:40:51 +0200 Message-ID: <9ae56b1e0907150540x2f7802c9sae24e777c1c517b4@mail.gmail.com> From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=0015174bddf88a0fc6046ebddd01 Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 15 Jul 2009 12:47:48 -0000 --0015174bddf88a0fc6046ebddd01 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit In this case you would better rely on the last aor tagged entry. /Hans Erik van Elburg On Tue, Jul 14, 2009 at 6:01 AM, Hadriel Kaplan wrote: > For example, a Voicemail system would NOT use the FIRST "mp" entry in the > list, nor the LAST. It needs to walk the list backwards to find the closest > "mp" to the end that it can use. Otherwise, a retarget from Alice to Bob > will go to Alice's voicemail, when it should have gone to Bob's. No? > --0015174bddf88a0fc6046ebddd01 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
In this case you would better rely on the last aor tagged entry.
=
/Hans Erik van Elburg


On Tue, Jul 14, 2009 at 6:01 AM, Hadriel= Kaplan <HKa= plan@acmepacket.com> wrote:
For example, a Voicemail system would NOT u= se the FIRST "mp" entry in the list, nor the LAST. =A0It needs to= walk the list backwards to find the closest "mp" to the end that= it can use. =A0Otherwise, a retarget from Alice to Bob will go to Alice= 9;s voicemail, when it should have gone to Bob's. =A0No?

--0015174bddf88a0fc6046ebddd01-- From ietf.hanserik@gmail.com Wed Jul 15 06:06:42 2009 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 0511C3A6BC4 for ; Wed, 15 Jul 2009 06:06:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.457 X-Spam-Level: X-Spam-Status: No, score=-2.457 tagged_above=-999 required=5 tests=[AWL=0.141, 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 NwpWxyj28aHA for ; Wed, 15 Jul 2009 06:06:37 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 6987E3A67A7 for ; Wed, 15 Jul 2009 06:06:37 -0700 (PDT) Received: by ewy26 with SMTP id 26so3999891ewy.37 for ; Wed, 15 Jul 2009 06:05:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=yu7o5jqoVlrc1+thRsCJksqNAs0DLOT9Y7rwp40822k=; b=myH9e3hGuu217gwPdnS0G1J1bZkXeN/oy5i8WLqCTLGOLUOKM7uT4fP1Dnhcg7Ph8m sDqxuuPQ9C6KXKi45JnIdDFYVfQo7ZDk+Y3uSl39CUaUGAMFpdSkFG//Yk15kiRIMEVs MNDkNaUAJQNsYG/8d14C+R20mUF7FB8ZF/kPs= 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=f8jfmhTrJfzwLNKQkDaILI9ZE/1kJG0zbRNSOs3lJ/OVTMrG+VVSDnMly4Lc87wKCz FEtWLCaTikQKn4mbItgE+L15b993sA2yX8ehvrq2v0CDoIR2sS2ulFjbwU++ggoapwmD swrYQOPhHJxTic2AIsw/zft9haWK3wzfIbq7Q= MIME-Version: 1.0 Received: by 10.210.67.4 with SMTP id p4mr8076386eba.13.1247663115167; Wed, 15 Jul 2009 06:05:15 -0700 (PDT) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EFA17E4@zrc2hxm0.corp.nortel.com> References: <4A5C9F69.1070701@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EFA0F29@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFA122C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFA12DA@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFA17E4@zrc2hxm0.corp.nortel.com> Date: Wed, 15 Jul 2009 15:05:15 +0200 Message-ID: <9ae56b1e0907150605w3d1ace04qc511b3fab525d52d@mail.gmail.com> From: Hans Erik van Elburg To: Francois Audet Content-Type: multipart/alternative; boundary=0015174c3f4cc7672b046ebe349b Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is "aor" used for? 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, 15 Jul 2009 13:06:42 -0000 --0015174c3f4cc7672b046ebe349b Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I agree with your fluff consolidation proposal. It would resolve issues. /Hans Erik van Elburg On Tue, Jul 14, 2009 at 11:15 PM, Francois Audet wrote: > The rc / cc / rt are the ones I would call "fluff". > > If I was a proxy, and I was trying to do pruning, those > are the ones I would drop. > > Since we can't count on this necessarily happening (especially > with older proxies conforming to 4244 only), it's important > that the ones who DO matter are labelled properly. That means > aor and mp. > > If we decide to "consolidate" the fluff together, > (say, fluff = rt | rc | rt) then it's even more obvious. > > At this point, I'd rather we mark them as fluff > for completeness. Before we actually remove anything, I'd > really want to do a thorough review of the backward compatibility > implications. > > > -----Original Message----- > > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com] > > Sent: Tuesday, July 14, 2009 13:56 > > To: Audet, Francois (SC100:3055); Paul Kyzivat > > Cc: Dean Willis; SIPCORE > > Subject: RE: [sipcore] rfc4244bis: what is "aor" used for? > > > > > > > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortel.com] > > > Sent: Tuesday, July 14, 2009 2:18 PM > > > > > > The problem with TODAY's implementation of HI is precisely what you > > > are trying to do, i.e., prune out stuff that YOU personally don't > > > think is useful. You have a specific application in mind. > > But you may > > > be breaking somebody else's application by "pruning out" > > the part the > > > other guy needs. > > > This is EXACTLY what is wrong with current version of RFC 4244. > > > > I don't think so - or at least I'm consciously trying to > > avoid that. :) > > > > I believe that if you reduce the number of params, when to > > set them, etc., you will improve interoperability. (and > > possibly even improve *operability* and brittle-ness) > > > > I also hope there are some entry types that are not going to > > be useful to any application; because I have a high degree of > > confidence not all of them will make it to a UAS in many > > cases, in my world. > > > > So I'm trying to find which subset are actually sufficient > > for all reasonable applications, and which are fluff. > > > > -hadriel > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --0015174c3f4cc7672b046ebe349b Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
I agree with your fluff consolidation proposal.
It would res= olve issues.

/Hans Erik van Elburg

On Tue, Jul 14, 2009 at 11:15 PM, Francois A= udet <audet@nortel= .com> wrote:
The rc / cc / rt are the ones I would call "fluff".

If I was a proxy, and I was trying to do pruning, those
are the ones I would drop.

Since we can't count on this necessarily happening (especially
with older proxies conforming to 4244 only), it's important
that the ones who DO matter are labelled properly. That means
aor and mp.

If we decide to "consolidate" the fluff together,
(say, fluff =3D rt | rc | rt) then it's even more obvious.

At this point, I'd rather we mark them as fluff
for completeness. Before we actually remove anything, I'd
really want to do a thorough review of the backward compatibility
implications.

> -----Original Message-----
> From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]
> Sent: Tuesday, July 14, 2009 13:56
> To: Audet, Francois (SC100:3055); Paul Kyzivat
> Cc: Dean Willis; SIPCORE
> Subject: RE: [sipcore] rfc4244bis: what is "aor" used for? >
>
>
> > -----Original Message----= -
> > From: Francois Audet [mailto:= audet@nortel.com]
> > Sent: Tuesday, July 14, 2009 2:18 PM
> >
> > The problem with TODAY's implementation of HI is precisely wh= at you
> > are trying to do, i.e., prune out stuff that YOU personally don&#= 39;t
> > think is useful. You have a specific application in mind.
> But you may
> > be breaking somebody else's application by "pruning out&= quot;
> the part the
> > other guy needs.
> > This is EXACTLY what is wrong with current version of RFC 4244. >
> I don't think so - or at least I'm consciously trying to
> avoid that. :)
>
> I believe that if you reduce the number of params, when to
> set them, etc., you will improve interoperability. (and
> possibly even improve *operability* and brittle-ness)
>
> I also hope there are some entry types that are not going to
> be useful to any application; because I have a high degree of
> confidence not all of them will make it to a UAS in many
> cases, in my world.
>
> So I'm trying to find which subset are actually sufficient
> for all reasonable applications, and which are fluff.
>
> -hadriel
>
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--0015174c3f4cc7672b046ebe349b-- From pkyzivat@cisco.com Wed Jul 15 06:32:49 2009 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 716C028C0E7 for ; Wed, 15 Jul 2009 06:32:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.256 X-Spam-Level: X-Spam-Status: No, score=-2.256 tagged_above=-999 required=5 tests=[AWL=-4.152, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_34=0.6, J_CHICKENPOX_52=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 DWplj2LmRMOQ for ; Wed, 15 Jul 2009 06:32:47 -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 8AB183A6AB8 for ; Wed, 15 Jul 2009 06:32:47 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAKl3XUpAZnme/2dsb2JhbAC3RYZjgUCRDAWBL4ERgQo/gUI X-IronPort-AV: E=Sophos;i="4.42,404,1243814400"; d="scan'208";a="50486315" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 15 Jul 2009 13:32:44 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6FDWiMI024800; Wed, 15 Jul 2009 09:32:44 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6FDWiIg012027; Wed, 15 Jul 2009 13:32:44 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 09:32:44 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 09:32:44 -0400 Message-ID: <4A5DDA7B.5040800@cisco.com> Date: Wed, 15 Jul 2009 09:32:43 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: gao.yang2@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 15 Jul 2009 13:32:44.0071 (UTC) FILETIME=[BBDB3B70:01CA0550] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9694; t=1247664764; x=1248528764; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20=3D?GB2312?B?tPC4tDogUmU6IFtzaXBjb3JlXS C08Li0OiBSZTogIE5ldyByZQ=3D=3D?=3D=0A=20=3D?GB2312?B?dmlzaW9 uIG9mIHRoZSByZS1JTlZJVEUgaGFuZGxpbmcgZHJhZnQ=3D?=3D |Sender:=20 |To:=20gao.yang2@zte.com.cn; bh=JBg2xNGUoMNv4+VzWPcVSjpxWA7uP/kUjtcPbQjnqpE=; b=qRqYJtsOhD3asz57YIJZBgf/841DAQ+rkd3eyky7QIjSOvOLbd/WXPxMKc pGQkO5nfc0T3xvSD9fKZAxiD8TeMuIEd5YA0XRWQIdvJpFOLedNmB80ER7/D gtVnbgOFBH; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIPCORE , OKUMURA Shinji Subject: Re: [sipcore] =?gb2312?b?tPC4tDogUmU6ICC08Li0OiBSZTogIE5ldyByZXZpc2lv?= =?gb2312?b?biBvZiB0aGUgcmUtSU5WSVRFIGhhbmRsaW5nIGRyYWZ0?= 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, 15 Jul 2009 13:32:49 -0000 gao.yang2@zte.com.cn wrote: > > Hi Paul, > > As Ini-INVITE and it's reponses has different routing to susquent > request, including Re-INVITE and UPDATE, then it is better to Cancel the > ongoing Ini-INVITE and following a new Ini-INVITE(BTW, I think sending a > new Ini-INVITE with replace is same). That is consistent with point I was making. > While considering Re-INVITE, having the same *routing set* as subsequent > UPDATE, it may send target refresh UPDATE during ongoing Re-INVITE. If > there is something wrong with transporting Re-INVITE's response, there > will be the same problem with transporting UPDATE. I don't agree - the responses to the reinvite are a problem even though the UPDATE is not. Suppose UAC for reINVITE gets a new IP address, different from the one it included in the contact and via of the reINVITE. And assume for simplicity that there are no Record-Route's. If the UAC decides to fix this by sending an UPDATE before completion of the reINVITE, then it may succeed in getting the remote target changed at the UAS. But the UAS is still obligated to send the remaining responses to the address in the Via, which is the old address. If the old address is now non-functional then the responses won't arrive and the reINVITE will time out. Even though it times out, it still can have the desired effect of changing the target, so long as that isn't rolled back when the reINVITE times out. An alternative would be to CANCEL the reINVITE and then send a new request to refresh the dialog. But there is a problem here: CANCEL is not a target refresh request. So even if it reaches its target and does its job, the response is likely not to arrive. Nor is the 487 response to the canceled reINVITE. So while this might work, there will be no way for the UAC to know it worked. So now I'm thinking that the UPDATE, is the right first step. If the UPDATE is successful, then a CANCEL could be sent (using the new Contact) to terminate the reINVITE early. In that case the response to the CANCEL should be received even though the response to the reINVITE will not be. After that, and perhaps a delay, a new reINVITE - a retry of the earlier one - could be attempted using the new address. This all hinges on the mid-invite UPDATE-based target refresh not being rolled back when the invite fails. > And then, the UA can > terminate the session/call. So, sending target refresh UPDATE during > ongoing Re-INVITE is not bad(than after the Re-INVITE). I guess we ultimately agree here. > There is another interesting case for changing address problem: > Considering wireless access network and UA's roam, UA get into a visited > domain which can afford IMS accessing beyond GPRS accessing. Then the > session need to be transfered to the new P-CSCF in the current visited > domain. In this use case, just refresh UA's target is not enough because > of the original P-CSCF should not be in the dialog's route set and the > new P-CSCF must be in the route set. Sending a new INVITE to replace the > original session and dialog is needed. Well, that is a problem for IMS. However we can consider the earlier failure scenario when there are Record-Route entries. In general I don't think it affects the analysis at all. The proxies in the route-set are supposed to accept the target refresh. Thanks, Paul > Thanks. > > Gao > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > > > *Paul Kyzivat * > > 2009-07-14 23:04 > > > ÊÕ¼þÈË > gao.yang2@zte.com.cn > ³­ËÍ > OKUMURA Shinji , SIPCORE > Ö÷Ìâ > Re: [sipcore] ´ð¸´: Re: New revision of the re-INVITE handling draft > > > > > > > > > There is a difficult problem when the UAC has an urgent need to change > the target and an INVITE is in progress: the routing of responses to the > original INVITE, since they are governed by the Via headers of the > INVITE, not the target. > > Perhaps that means that if you have an urgent need to change your > address while you have an incomplete INVITE outstanding, you should > CANCEL the INVITE and send a new one with the target refresh. > > OTOH, if the UAS finds itself with that problem it can just initiate a > target refresh within the dialog. And in that case, if the INVITE > subsequently fails you wouldn't want the target change to be rolled back. > > Thanks, > Paul > > gao.yang2@zte.com.cn wrote: > > > > Hi Shinji, > > > > Target fresh: > > One target fresh is in just one sip transaction, not like session > > modification can overlap more than one sip transaction(such as > > precondition). > > So, even the ongoing INVITE/Re-INVITE has target fresh, the target fresh > > in the UPDATE is a whole new one. *As it is a whole new one, not part * > > *of the original one, so the target fresh in the UPDATE must not > > *rollback*.* > > > > Session modification: > > When the O/A in UPDATE/200OK is part of the one triggered by > > INVITE/Re-INVITE, it is NOT excluded from the rollback. But when the > O/A in > > UPDATE/200OK is a whole new one, IMO, it should excluded from the > rollback. > > > > BTW, > > A standard regulation is really needed to end the very long session > > state discussion. > > > > And as we should has a detailed classification of which O/A is part of > > the one triggered by INVITE/Re-INVITE and which is not, if we choose > > this way to > > solve the session state problm, now I support > > draft-camarillo-sipcore-reinvite-00. I'd like to concentrate on this > > solution.(I do not mean any restrict on any talking around my original > > proposal :)) > > > > Thanks. > > > > Gao > > > > =================================== > > Zip : 210012 > > Tel : 87211 > > Tel2 :(+86)-025-52877211 > > e_mail : gao.yang2@zte.com.cn > > =================================== > > > > > > *OKUMURA Shinji * > > > > 2009-07-14 10:33 > > > > > > ÊÕ¼þÈË > > SIPCORE > > ³­ËÍ > > gao.yang2@zte.com.cn > > Ö÷Ìâ > > Re: [sipcore] New revision of the re-INVITE handling > draft > > > > > > > > > > > > > > > > > > Hi Gao, > > > > Do you mean that the session state of the UPDATE transaction is NOT > > excluded from the rollback, but the dialog state(ie remote target) > > is excluded from the rollback? > > > > gao.yang2@zte.com.cn > > >Hi Shinji, > > > > > >By RFC3311, the target refresh UPDATE can refresh the ongoing > Re-INVITE, > > >as below: > > > > > >UPDATE is a target refresh request. As specified in RFC 3261 [1], > > > this means that it can update the remote target of a dialog. If a UA > > > uses an UPDATE request or response to modify the remote target while > > > an INVITE transaction is in progress, and it is a UAS for that > INVITE > > > transaction, it MUST place the same value into the Contact header > > > field of the 2xx to the INVITE that it placed into the UPDATE > request > > > or response. > > > > the above statement means that the 2xx to the INVITE include the same > > Contact header of the UPDATE request or response. But UPDATE does not > > modify the Via header of 2xx. > > > > Regards, > > Shinji > > > > >And then, we can get the correct session state by the way proposed in > > >draft-camarillo-sipcore-reinvite-00. > > > > > >Gao > > > > > > > > -------------------------------------------------------- > > ZTE Information Security Notice: The information contained in this > mail is solely property of the sender's organization. This mail > communication is confidential. Recipients named above are obligated to > maintain secrecy and are not permitted to disclose the contents of this > communication to others. > > This email and any files transmitted with it are confidential and > intended solely for the use of the individual or entity to whom they are > addressed. If you have received this email in error please notify the > originator of the message. Any views expressed in this message are those > of the individual sender. > > This message has been scanned for viruses and Spam by ZTE Anti-Spam > system. > > > > > > ------------------------------------------------------------------------ > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. From mary.barnes@nortel.com Wed Jul 15 07:07:58 2009 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 86F743A69E7 for ; Wed, 15 Jul 2009 07:07:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.344 X-Spam-Level: X-Spam-Status: No, score=-6.344 tagged_above=-999 required=5 tests=[AWL=0.255, 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 kq6CCRxbgcXX for ; Wed, 15 Jul 2009 07:07:57 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 588CC3A68AB for ; Wed, 15 Jul 2009 07:07:57 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6FE6YF15385; Wed, 15 Jul 2009 14:06:35 GMT 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: Wed, 15 Jul 2009 09:08:37 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFE0860@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EFA0F7C@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: Do we need rt / mp / rc / cc thread-index: AcoEDqM/XIENvO+JQM+deNhoIRK3fQAAKw3QAAbzRkAAHH9xoAAt/EuA References: <4A5B7195.6020009@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com><4A5BBE0C.5000301@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFA0F7C@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Francois Audet" , "SIPCORE" Cc: Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: Do we need rt / mp / rc / cc 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, 15 Jul 2009 14:07:58 -0000 After thinking about this some, I'd still prefer to keep Option A. as I recall there was a good reason for the more precise values, although that may have been before we had the "aor" tag.=20 On the surface, simpler might be better although in terms of implementation if "rc" and "cc" are handled the same then it's really no big deal. And, the "rc" and "cc" do provide a bit more information for the debug use case. Mary.=20 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Audet, Francois (SC100:3055) Sent: Tuesday, July 14, 2009 11:16 AM To: SIPCORE Cc: Hadriel Kaplan Subject: [sipcore] rfc4244bis: Do we need rt / mp / rc / cc In the current draft, we have opted to be "more precise" instead of "more simple" with regards with tagging the H-I entries.... As eloquently said by Hadriel, what we really need to know is "what this a redirection (to a different user) or not"? One alternative to having the rc / cc / mp / rt (and nil) tags would be to only have (say), "mp" (mapped to a different user), "rt" (routed to same user) and of course "nil" (i.e., no tag because it's a legacy 4244 proxy, or because the proxy doesn't know). "rc" & "cc" would be included in "rt".=20 This is something that we considered during the development of the draft, but it seems people at the time preferred more precise tags.=20 I'd like feedback on what are people's views: Option A) As per draft: i.e., rc / cc / mp / rt Option B) Simplified: i.e., mp / rt PS: This says nothing of the "aor" issue, which, as Mary said, related to other use cases, in particular the Freephone case. _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Wed Jul 15 07:16:38 2009 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 9BE2C3A6B40 for ; Wed, 15 Jul 2009 07:16:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.122 X-Spam-Level: X-Spam-Status: No, score=-6.122 tagged_above=-999 required=5 tests=[AWL=-0.123, BAYES_00=-2.599, J_CHICKENPOX_47=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 79IIkWpg17wr for ; Wed, 15 Jul 2009 07:16:37 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 151103A68B5 for ; Wed, 15 Jul 2009 07:16:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJqAXUpAZnmf/2dsb2JhbAC3cYgjkQ4FhAmBQg X-IronPort-AV: E=Sophos;i="4.42,404,1243814400"; d="scan'208";a="214343279" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 15 Jul 2009 14:12:14 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6FECErR017312; Wed, 15 Jul 2009 10:12:14 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6FECEwP006582; Wed, 15 Jul 2009 14:12:14 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 10:12:14 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 10:12:13 -0400 Message-ID: <4A5DE3BD.2050306@cisco.com> Date: Wed, 15 Jul 2009 10:12:13 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Hans Erik van Elburg References: <1ECE0EB50388174790F9694F77522CCF1EF5190A@zrc2hxm0.corp.nortel.com> <4A5B71AC.6050502@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EF51BFE@zrc2hxm0.corp.nortel.com> <4A5C8B0D.6010107@cisco.com> <9ae56b1e0907150519je7cab97x6c1324a302df1a92@mail.gmail.com> In-Reply-To: <9ae56b1e0907150519je7cab97x6c1324a302df1a92@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jul 2009 14:12:13.0939 (UTC) FILETIME=[40686430:01CA0556] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9129; t=1247667134; x=1248531134; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20rfc4244bis=3A=20what=20is=2 0an=20AoR? |Sender:=20 |To:=20Hans=20Erik=20van=20Elburg=20; bh=RjAV8d5xKvMLb0V2crHWvVFFaF2mXGEdeXU6peekKj8=; b=odbrFB95gWFIkCXeoNNsvoi4lEXu91Ej/oucG+RmqSIMH6lfbLfGHXkIsq xI3ZvzN8ND2i+ota9weeOcEfZumjjtXZvZjxUn56zHU0E1x0efJqJ8o4nZxD rXAHGxE15K; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 15 Jul 2009 14:16:38 -0000 Inline. [Note that somewhere along the way my original examples got mangled by something that expanded url-looking things into links. I've whacked those out where I have caught them.] Hans Erik van Elburg wrote: > > > On Tue, Jul 14, 2009 at 3:41 PM, Paul Kyzivat > wrote: > > Francois, > > Maybe we can puzzle this out by examining more use cases. > You focused on digit manipulation, which is surely one. But there > are others. > > To spell out the digit manipulation case in more detail: > > A proxy receives a request with sip R-URI in the domain it is > responsible for. It sees that the user part is all digits. (E.g > sip:81234@example.net) It then > applies some sort of digit map it has been provisioned with > (possibly per-caller, possibly per-domain) to transform that into > some other more globally unique URI - perhaps an E.164 number in its > own domain or some other domain, or a TEL URI. (E.g. > sip:+12125551234@example.net;user=phone.) It does the > translation and then proceeds based on the result. I agree in this > case it is wrong to call the incoming R-URI an AOR. > > > What property does this not make an AOR? > How does it matter whether there are multiple translation steps in a domain? > What matters that if I sent something to: sip:81234@example.net > that it will be delivered to the > intended party. In this sense this is an AOR. I could put this on my > business card for example. Its really questionable whether you could put this on your business card or not. It depends on the mechanics of the translation. For instance, a large company with many branches may have dial plans that allow short digit strings for numbers in the branch, longer digit strings for numbers at other branches, and even longer, or at least different, dial strings for e.164 numbers. In particular, the short, branch-specific, dial strings are ambiguous within the domain of the enterprise. They can be rendered unambiguous in multiple ways: - they can be put into a uri with a branch-specific (or dial plan specific) domain name. - they can be encoded with a phone-context that indicates the branch or dial plan - they can be put into a uri with a company-wide domain name, which then is ambiguous. The proxy can then resolve the ambiguity based on the source of the request. The first two cases could potentially be considered AoRs, but the latter one cannot not. Even the first two may not be valid on business cards if the company chooses not to recognize such addresses from outside its domain. > A different case is synonyms or aliases: > > A proxy responsible for example.net receives a > request with R-URI sip:phk@example.net > This is not in its location service. > But it has a provisioned alias table that says phk is a synonym for > paul.kyzivat, so it translates the R-URI to > sip:paul.kyzivat@example.net. It then proceeds to process > that, which turns out to be in its location service, so it > translates it again to sip:line1@phone1.paulk.example.net. > Again, I don't think sip:phk@example.net is an AoR in this case. > > I do think this is an AOR allright. The alias mapping can well be > performed by an abstract-location-service. That is part of my issue. The proxy may use a location service as part of its processing, but can perform other logic as well. And the location service can be updated by REGISTER, but can also have entries come/go in other ways. So, is something an AoR because the proxy gets the translation from the location service? Or is it because the translation it performs *could* have come from a location service? Or is it because the proxy has a policy that says "this URI in my domain is an AoR". > What property does this not make an AOR? > How does it matter whether there are multiple translation steps in a domain? > What matters that if I sent something to: sip:phk@example.net > that it will be delivered to the intended > party. In this sense this is an AOR. You could put this on your business > card for example. I agree it *could* be an AoR. But I don't know that it MUST be an AoR. > Another case, for forwarding: > > A proxy responsible for example.net receives a > request with R-URI of sip:paul.kyzivat@example.net. > There is a location service > with an entry registered for sip:line1@phone1.paulk.example.net, > but there is also > provisioning independent of the location service that says to > unconditionally forward all calls to this URI to > sip:audet@nortel.com. This is > accomplished by R-URI translation. (To ensure that the request will > not be rejected as mis-addressed.) > > In this case I think that sip:paul.kyzivat@example.net > *is* an AoR. > > Yes. > > And one final forwarding case: > > A proxy responsible for example.net receives a > request with R-URI of sip:alice.smith@example.net. > Alice used to work for > Example Co, but she no longer does, so her URI is "out of service". > But the proxy has been provisioned to translate the R-URI of Alice's > calls to her old boss' URI: sip:betty.jones@example.net. > There will never be an entry > in the location service for alice, registrations are not permitted. > > In this case, in spite of there being no location service involved, > I still think sip:alice.smith@example.net is an AoR. > > Yes, the abstract-location-service returns the address of betty. But > this IS really a border case that makes me wonder. > > So, IMO the bottom line is that whether a URI is an AoR is a policy > decision within the domain of the URI. > > It is unclear to me what definition of AOR you are using. I am taking at face value that AoR (Address of *Record*) is based on a *record* of the domain, which almost by definition is a matter of policy. And I am pointing out that we don't have a definition of AoR that both useful operationally and that meets every day expectations. > Thanks, > Paul > > > > Francois Audet wrote: > > > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com > ] Sent: Monday, July 13, 2009 10:41 > To: Audet, Francois (SC100:3055) > Cc: Hadriel Kaplan; Hans Erik van Elburg; SIPCORE > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > > > > Francois Audet wrote: > > To me it's crystal clear. > > If you are the entity (proxy or redirect server) > > responsible for the > > URI, and you find the entry in your location service, you > > mark as AOR. > > That means you will now route based on "rules" you have > internally, e.g., map it to a contact, etc. > > I think some cases are clear, others not so much: > > - If the proxy translates to a contact that it got from a > location service and that entry was placed there by a > REGISTER, > then the entry should definitely be marked as an AoR > > > Agree. > > - If the proxy translates to a contact that it got from a > ocation service, and that entry got there somehow other > than REGISTER, > then I *think* the entry should still be marked as an AoR. > > > Yes, agree. > > - If the proxy uses some other logic than a "location service" > to translate the URI, but it might in other cases use the > location service to translate the URI, then I'm not sure. > > - If the proxy never uses a location service for this URI, > but translates it on some other basis, then again I'm not > sure. > > One problem here is that the location service is abstract. > There are things that can be done using it, or in another > manner. It seems to me that if it *could* have been done > with a location service lookup, then the result ought to be > the same whether it is or not. > > > I think the last two are the same thing. > Things like digit manipulation and so forth. > > I didn't want to alter (or second-guess) the definition of AOR > (which is the realm of RFC 3261), in this draft. > > I would think that if the proxy doesn't know that it's an AOR, > then it shouldn't mark > it as such. So I would expect mechanical digit manipulation to > NOT be marked as AOR. > > > From Peter.Dawes@vodafone.com Wed Jul 15 07:47:02 2009 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 5D17D3A6CED for ; Wed, 15 Jul 2009 07:47:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.999 X-Spam-Level: X-Spam-Status: No, score=-3.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, J_CHICKENPOX_84=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 6w+d+M2X1gZp for ; Wed, 15 Jul 2009 07:47:01 -0700 (PDT) Received: from mailout06.vodafone.com (mailout06.vodafone.com [195.232.224.75]) by core3.amsl.com (Postfix) with ESMTP id E28A03A6BF0 for ; Wed, 15 Jul 2009 07:47:00 -0700 (PDT) Received: from mailint06 (localhost [127.0.0.1]) by mailout06 (Postfix) with ESMTP id A0FEA84895 for ; Wed, 15 Jul 2009 16:46:45 +0200 (CEST) Received: from mi1.vodafone.com (mi1.vodafone.com [195.232.246.138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailint06 (Postfix) with ESMTPS id 9489E84255; Wed, 15 Jul 2009 16:46:45 +0200 (CEST) Received: from avoexs02.internal.vodafone.com ([145.230.4.135]) by mi1.vodafone.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id n6FEkfVY009667 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NO); Wed, 15 Jul 2009 16:46:44 +0200 Received: from EITO-MBX02.internal.vodafone.com ([145.230.4.11]) by avoexs02.internal.vodafone.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 16:46:45 +0200 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: Wed, 15 Jul 2009 16:46:40 +0200 Message-ID: In-Reply-To: <40FB0FFB97588246A1BEFB05759DC8A00330040F@S4DE9JSAANI.ost.t-com.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-kaplan-sip-session-id-02 Thread-Index: Acn1DaU1pu17VvRRTd+gHdXlHhTG9AOmEHkwAAGgysAAavX4kA== References: <1245876685.3748.61.camel@victoria-pingtel-com.us.nortel.com> <40FB0FFB97588246A1BEFB05759DC8A00330040F@S4DE9JSAANI.ost.t-com.de> From: "Dawes, Peter, VF-Group" To: , X-OriginalArrivalTime: 15 Jul 2009 14:46:45.0106 (UTC) FILETIME=[12EB6520:01CA055B] Cc: sipcore@ietf.org, Gerold.Pinker@telekom.de, dworley@nortel.com, R.Jesske@telekom.de, Martin.Huelsemann@telekom.de Subject: Re: [sipcore] draft-kaplan-sip-session-id-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, 15 Jul 2009 14:47:02 -0000 Hello Laura, Thanks for the very interesting extra perspective. Does your traffic monitoring solution pass all SIP signalling through this 'separate device for monitoring', and does this device record all network activity all the time? I ask because one thing that the session-id-02 draft does not seem to help with is how you identity a particular session you are interested in. Since session-id is very similar to Call-ID, it doesn't seem very different from recording everything and then searching based on Call-ID. I agree with you that a solution should not rely on end devices, although ideally end devices are included in troubleshooting. Draft http://tools.ietf.org/html/draft-dawes-sipping-debug-01 also does not rely on end devices (in 5.2 it says that the first proxy in the path can insert the new P-Debug-ID header), but I should probably revise the draft structure to make the responsibilities of each entity (UAC, Proxy, UAS, etc.) clearer. =20 Best regards, Peter =20 -----Original Message----- From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20 Sent: 13 July 2009 17:00 To: Dawes, Peter, VF-Group; HKaplan@acmepacket.com Cc: dworley@nortel.com; sipcore@ietf.org; R.Jesske@telekom.de; Martin.Huelsemann@telekom.de; Gerold.Pinker@telekom.de Subject: RE: [sipcore] draft-kaplan-sip-session-id-02 Peter, we intend to use the Session-ID for traffic monitoring.=20 Personally, I like the debug drafts a lot because it is a quite efficient mechanism for detecting faults quickly but it covers quite different scenarios than Session-ID. We discussed internaly what to use and decided for Session-ID for following reasons:=20 - The monitoring is done by a separate device, we don't use the logfiles of the proxies.=20 - We can not rely on end devices. We already have a lot of end devices in the field which do not have session-ID or debug-id implemented. First SBC in the path has to insert the new ID. Also, the security people whant to use the ID to trace attacks and we assume that the attacker's clients will not insert the debugg-id.=20 - We want to be able to correlate the messages end-to-end also if we do not know in advance if we want to monitor a specific call.=20 - The monitoring is active all the time. The security people want to be able to look what happened in the past. So the global uniqueness requirement makes sense for me.=20 - The hashing is needed because we do not want the calle to see the IP-address of the caller end most devices insert the IP-address in the call-id. =20 Kind regards Laura =20 > -----Original Message----- > From: sipcore-bounces@ietf.org > [mailto:sipcore-bounces@ietf.org] On Behalf Of Dawes, Peter, VF-Group > Sent: Monday, July 13, 2009 1:12 PM > To: SIPCORE; Hadriel Kaplan > Cc: Dale Worley > Subject: Re: [sipcore] draft-kaplan-sip-session-id-02 >=20 > Hello Hadriel, Dale, > Regarding the length of the session-id header field, is it really=20 > necessary to guarantee global uniqueness and use 128 bits? The uses of > this new header field described in -02 are 'troubleshooting' and=20 > 'identity verification mechanisms', but troubleshooting will be=20 > restricted to relatively short time period after which a session-id=20 > value could be reused. Identity verification is not described but does > it require a globally unique session-id? >=20 > Troubleshooting is also the topic of my draft=20 > http://tools.ietf.org/html/draft-dawes-sipping-debug-01, which is=20 > similar to session-id but also describes how troubleshooting starts=20 > and stops, and how entities determine when to add a header field for=20 > debugging. According to session-id-02, the session-id header field is=20 > present in all dialogs, which implies troubleshooting needs to record=20 > everything, potentially at multiple entities some of which may not be=20 > involved in the session being investigated, and then post-analyse for=20 > the particular session that is targetted for troubleshooting. > This seems > inefficient, or have I misunderstood? > =20 > Best Regards, > Peter >=20 >=20 > Peter Dawes > Group R&D > =20 > Tel: +44 (0)7717 275009 > Fax: +44 (0)1635 234873 >=20 > =20 > E-mail: peter.dawes@vodafone.com > =20 > www.betavine.net - Web > betavine.mobi - Mobile Web > =20 > Vodafone Group Services Limited > Registered Office: Vodafone House, The Connection, Newbury, Berkshire > RG14 2FN Registered in England No 3802001 >=20 >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > Behalf Of Dale Worley > Sent: 24 June 2009 21:51 > To: SIPCORE > Subject: [sipcore] draft-kaplan-sip-session-id-02 >=20 > Looking at draft-kaplan-sip-session-id-02, the shorter the Session-Id=20 > header is, the fewer complaints people will have about using it in=20 > practice. A couple of things could be done to shorten it: >=20 > - assign a single-letter abbreviation for the name >=20 > - use base64 rather than hex encoding >=20 > Base64 encoding reduces the header value to 22 characters from 32. >=20 > Dale >=20 >=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 ietf.hanserik@gmail.com Wed Jul 15 08:17:14 2009 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 0C1BB3A6EC5 for ; Wed, 15 Jul 2009 08:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.198 X-Spam-Level: X-Spam-Status: No, score=-2.198 tagged_above=-999 required=5 tests=[AWL=-0.200, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_47=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 IZ-3jkbyaMFV for ; Wed, 15 Jul 2009 08:17:12 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id 59A9C3A6E51 for ; Wed, 15 Jul 2009 08:17:11 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so1153056eye.31 for ; Wed, 15 Jul 2009 08:16:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=OqUp3WYgOpyuQbBF4QKGj12i2szEMhRVr6sorNb7hQU=; b=Om+hbmteujFdgTtSP3UzAUKg1eStTL9n+2mhZblT2flEOD3ScjrdZbTAl89KEmTR0p 1kIphH2uJSd7qBcp4MPpeO3ELvwTwMStvrX1wzXUVgTyKqzm+oOPcv/mMJQ9fh0+8/+J USQCUgRHUK6xPeL6wtaYeyHwgdJ7jaIJTOHa4= 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=tNqxl10Nqo0xG+t65/TQ2rg0Ch3I50Ey3F4Hi1z+utey4bCxVu7Hey8HJPHknFoL2R HD60Yjvud1zSqMK7V5YVfG5sAkIe0c0lEah8ORSDEGvUUJhhfcF3kze9TZ4QR1hS/5l3 Dsbdu2VRG7SaNpdE55QRL4QgVCUcUqwCOAyNU= MIME-Version: 1.0 Received: by 10.211.179.6 with SMTP id g6mr8257163ebp.49.1247670555352; Wed, 15 Jul 2009 08:09:15 -0700 (PDT) In-Reply-To: <4A5DE3BD.2050306@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF1EF5190A@zrc2hxm0.corp.nortel.com> <4A5B71AC.6050502@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EF51BFE@zrc2hxm0.corp.nortel.com> <4A5C8B0D.6010107@cisco.com> <9ae56b1e0907150519je7cab97x6c1324a302df1a92@mail.gmail.com> <4A5DE3BD.2050306@cisco.com> Date: Wed, 15 Jul 2009 17:09:15 +0200 Message-ID: <9ae56b1e0907150809r70e2dc2fo64a78be54e2c5c7c@mail.gmail.com> From: Hans Erik van Elburg To: Paul Kyzivat Content-Type: multipart/alternative; boundary=0015174c1dc8401292046ebff024 Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 15 Jul 2009 15:17:14 -0000 --0015174c1dc8401292046ebff024 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit (sip:81234@example.net --> (example.net proxy instance 1) --> sip:+12125551234@example.net;user=phone (example.net proxy instance 2) --> contact) Ok, your point is whether a number belonging to a private number plan is also an AOR right? Then the question is if the proxy-instance-1 that translates this to a globally routable URI should tag this as an aor. I think it does not really matter in this case whether it tags the entry or not. What is important is that proxy-instance-2 that receives the request targeted at the domain that it is responsible for tags the entry as aor. But I still think that it would not do any harm if the proxy instance 1 would mark the entry with aor, allthough this might be counterintuitive in some very peculiar cases. /Hans Erik van Elburg On Wed, Jul 15, 2009 at 4:12 PM, Paul Kyzivat wrote: > Inline. > > [Note that somewhere along the way my original examples got mangled by > something that expanded url-looking things into links. I've > whacked those out where I have caught them.] > > Hans Erik van Elburg wrote: > >> >> >> On Tue, Jul 14, 2009 at 3:41 PM, Paul Kyzivat > pkyzivat@cisco.com>> wrote: >> >> Francois, >> >> Maybe we can puzzle this out by examining more use cases. >> You focused on digit manipulation, which is surely one. But there >> are others. >> >> To spell out the digit manipulation case in more detail: >> >> A proxy receives a request with sip R-URI in the domain it is >> responsible for. It sees that the user part is all digits. (E.g >> sip:81234@example.net ) It then >> applies some sort of digit map it has been provisioned with >> (possibly per-caller, possibly per-domain) to transform that into >> some other more globally unique URI - perhaps an E.164 number in its >> own domain or some other domain, or a TEL URI. (E.g. >> sip:+12125551234@example.net ;user=phone.) >> It does the >> translation and then proceeds based on the result. I agree in this >> case it is wrong to call the incoming R-URI an AOR. >> >> >> What property does this not make an AOR? >> How does it matter whether there are multiple translation steps in a >> domain? >> What matters that if I sent something to: sip:81234@example.netthat it will be delivered to the intended party. In this sense this is an >> AOR. I could put this on my business card for example. >> > > Its really questionable whether you could put this on your business card or > not. It depends on the mechanics of the translation. > > For instance, a large company with many branches may have dial plans that > allow short digit strings for numbers in the branch, longer digit strings > for numbers at other branches, and even longer, or at least different, dial > strings for e.164 numbers. > > In particular, the short, branch-specific, dial strings are ambiguous > within the domain of the enterprise. They can be rendered unambiguous in > multiple ways: > - they can be put into a uri with a branch-specific (or dial plan > specific) domain name. > - they can be encoded with a phone-context that indicates the branch > or dial plan > - they can be put into a uri with a company-wide domain name, which > then is ambiguous. The proxy can then resolve the ambiguity based > on the source of the request. > > The first two cases could potentially be considered AoRs, but the latter > one cannot not. Even the first two may not be valid on business cards if the > company chooses not to recognize such addresses from outside its domain. > > A different case is synonyms or aliases: >> >> A proxy responsible for example.net receives a >> request with R-URI sip:phk@example.net >> This is not in its location service. >> But it has a provisioned alias table that says phk is a synonym for >> paul.kyzivat, so it translates the R-URI to >> sip:paul.kyzivat@example.net . It then >> proceeds to process >> that, which turns out to be in its location service, so it >> translates it again to sip:line1@phone1.paulk.example.net >> . >> Again, I don't think sip:phk@example.net is an >> AoR in this case. >> I do think this is an AOR allright. The alias mapping can well be >> performed by an abstract-location-service. >> > > That is part of my issue. The proxy may use a location service as part of > its processing, but can perform other logic as well. And the location > service can be updated by REGISTER, but can also have entries come/go in > other ways. > > So, is something an AoR because the proxy gets the translation from the > location service? Or is it because the translation it performs *could* have > come from a location service? Or is it because the proxy has a policy that > says "this URI in my domain is an AoR". > > What property does this not make an AOR? >> How does it matter whether there are multiple translation steps in a >> domain? >> What matters that if I sent something to: sip:phk@example.netthat it will be delivered to the intended party. In this sense this is an >> AOR. You could put this on your business card for example. >> > > I agree it *could* be an AoR. But I don't know that it MUST be an AoR. > > Another case, for forwarding: >> >> A proxy responsible for example.net receives a >> request with R-URI of sip:paul.kyzivat@example.net >> . >> There is a location service >> with an entry registered for sip:line1@phone1.paulk.example.net >> , >> but there is also >> provisioning independent of the location service that says to >> unconditionally forward all calls to this URI to >> sip:audet@nortel.com . This is >> accomplished by R-URI translation. (To ensure that the request will >> not be rejected as mis-addressed.) >> >> In this case I think that sip:paul.kyzivat@example.net >> *is* an AoR. >> Yes. >> And one final forwarding case: >> >> A proxy responsible for example.net receives a >> request with R-URI of sip:alice.smith@example.net >> . >> Alice used to work for >> Example Co, but she no longer does, so her URI is "out of service". >> But the proxy has been provisioned to translate the R-URI of Alice's >> calls to her old boss' URI: sip:betty.jones@example.net >> . >> There will never be an entry >> in the location service for alice, registrations are not permitted. >> >> In this case, in spite of there being no location service involved, >> I still think sip:alice.smith@example.netis an AoR. >> >> Yes, the abstract-location-service returns the address of betty. But this >> IS really a border case that makes me wonder. >> >> So, IMO the bottom line is that whether a URI is an AoR is a policy >> decision within the domain of the URI. >> >> It is unclear to me what definition of AOR you are using. >> > > I am taking at face value that AoR (Address of *Record*) is based on a > *record* of the domain, which almost by definition is a matter of policy. > > And I am pointing out that we don't have a definition of AoR that both > useful operationally and that meets every day expectations. > > > Thanks, >> Paul >> >> >> >> Francois Audet wrote: >> >> >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com >> ] Sent: Monday, July 13, 2009 10:41 >> To: Audet, Francois (SC100:3055) >> Cc: Hadriel Kaplan; Hans Erik van Elburg; SIPCORE >> Subject: Re: [sipcore] rfc4244bis: what is an AoR? >> >> >> >> Francois Audet wrote: >> >> To me it's crystal clear. >> >> If you are the entity (proxy or redirect server) >> >> responsible for the >> >> URI, and you find the entry in your location service, you >> >> mark as AOR. >> >> That means you will now route based on "rules" you have >> internally, e.g., map it to a contact, etc. >> >> I think some cases are clear, others not so much: >> >> - If the proxy translates to a contact that it got from a >> location service and that entry was placed there by a >> REGISTER, >> then the entry should definitely be marked as an AoR >> >> >> Agree. >> >> - If the proxy translates to a contact that it got from a >> ocation service, and that entry got there somehow other >> than REGISTER, >> then I *think* the entry should still be marked as an AoR. >> >> >> Yes, agree. >> >> - If the proxy uses some other logic than a "location service" >> to translate the URI, but it might in other cases use the >> location service to translate the URI, then I'm not sure. >> >> - If the proxy never uses a location service for this URI, >> but translates it on some other basis, then again I'm not >> sure. >> >> One problem here is that the location service is abstract. >> There are things that can be done using it, or in another >> manner. It seems to me that if it *could* have been done >> with a location service lookup, then the result ought to be >> the same whether it is or not. >> >> >> I think the last two are the same thing. >> Things like digit manipulation and so forth. >> >> I didn't want to alter (or second-guess) the definition of AOR >> (which is the realm of RFC 3261), in this draft. >> >> I would think that if the proxy doesn't know that it's an AOR, >> then it shouldn't mark >> it as such. So I would expect mechanical digit manipulation to >> NOT be marked as AOR. >> >> >> >> --0015174c1dc8401292046ebff024 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
(sip:81234@example.net = --> (example.net proxy instance 1) --= > sip:+12125551234@e= xample.net;user=3Dphone (example.net= =A0proxy instance 2) --> contact)

Ok, your point is whether a number belonging to a private num= ber plan is also an AOR right?

Then the question i= s if the proxy-instance-1 that translates this to a globally routable URI s= hould tag this as an aor. I think it does not really matter in this case wh= ether it tags the entry or not. What is important is that proxy-instance-2 = that receives the request targeted at the domain that it is responsible for= tags the entry as aor.=A0

But I still think that it would not do any harm if the = proxy instance 1 would mark the entry with aor, allthough this might be cou= nterintuitive in some very peculiar cases.

/Hans Erik van Elburg


On Wed, Jul 15, 2009 at 4:12 PM, Paul Ky= zivat <pkyzivat@= cisco.com> wrote:
Inline.

[Note that somewhere along the way my original examples got mangled by some= thing that expanded url-looking things into <mailto...> links. I'= ve whacked those out where I have caught them.]


Hans Erik van Elburg wrote:


On Tue, Jul 14, 2009 at 3:41 PM, Paul Kyzivat <pkyzivat@cisco.com <mailto:pkyzivat@cisco.com>>= ; wrote:

=A0 =A0Francois,

=A0 =A0Maybe we can puzzle this out by examining more use cases.
=A0 =A0You focused on digit manipulation, which is surely one. But there =A0 =A0are others.

=A0 =A0To spell out the digit manipulation case in more detail:

=A0 =A0A proxy receives a request with sip R-URI in the domain it is
=A0 =A0responsible for. It sees that the user part is all digits. (E.g
=A0 =A0sip:81= 234@example.net) It then
=A0 =A0applies some sort of digit map it has been provisioned with
=A0 =A0(possibly per-caller, possibly per-domain) to transform that into =A0 =A0some other more globally unique URI - perhaps an E.164 number in it= s
=A0 =A0own domain or some other domain, or a TEL URI. (E.g.
=A0 =A0sip:+12125551234@example.net;user=3Dphone.) It does the
=A0 =A0translation and then proceeds based on the result. I agree in this<= br> =A0 =A0case it is wrong to call the incoming R-URI an AOR.


What property does this not make an AOR?
How does it matter whether there are multiple translation steps in a domain= ?
What matters that if I sent something to: sip:81234@example.net that it will be deliv= ered to the intended party. In this sense this is an AOR. I could put this = on my business card for example.

Its really questionable whether you could put this on your business card or= not. It depends on the mechanics of the translation.

For instance, a large company with many branches may have dial plans that a= llow short digit strings for numbers in the branch, longer digit strings fo= r numbers at other branches, and even longer, or at least different, dial s= trings for e.164 numbers.

In particular, the short, branch-specific, dial strings are ambiguous withi= n the domain of the enterprise. They can be rendered unambiguous in multipl= e ways:
- they can be put into a uri with a branch-specific (or dial plan
=A0specific) domain name.
- they can be encoded with a phone-context that indicates the branch
=A0or dial plan
- they can be put into a uri with a company-wide domain name, which
=A0then is ambiguous. The proxy can then resolve the ambiguity based
=A0on the source of the request.

The first two cases could potentially be considered AoRs, but the latter on= e cannot not. Even the first two may not be valid on business cards if the = company chooses not to recognize such addresses from outside its domain.

=A0 =A0A different case is synonyms or aliases:

=A0 =A0A proxy responsible for example.net receives a
=A0 =A0request with R-URI sip:phk@example.net
=A0 =A0This is not in its location service.
=A0 =A0But it has a provisioned alias table that says phk is a synonym for=
=A0 =A0paul.kyzivat, so it translates the R-URI to
=A0 =A0sip:paul.kyzivat@example.net. It then proceeds to process
=A0 =A0that, which turns out to be in its location service, so it
=A0 =A0translates it again to sip:line1@phone1.paulk.example.net.
=A0 =A0Again, I don't think sip:phk@example.net is an AoR in this case.
I do think this is an AOR allright. The alias mapping can well be performed= by an abstract-location-service.

That is part of my issue. The proxy may use a location service as part of i= ts processing, but can perform other logic as well. And the location servic= e can be updated by REGISTER, but can also have entries come/go in other wa= ys.

So, is something an AoR because the proxy gets the translation from the loc= ation service? Or is it because the translation it performs *could* have co= me from a location service? Or is it because the proxy has a policy that sa= ys "this URI in my domain is an AoR".


What property does this not make an AOR?
How does it matter whether there are multiple translation steps in a domain= ?
What matters that if I sent something to: sip:phk@example.net that it will be delivered= to the intended party. In this sense this is an AOR. You could put this on= your business card for example.

I agree it *could* be an AoR. But I don't know that it MUST be an AoR.<= br>
=A0 =A0Another case, for forwarding:

=A0 =A0A proxy responsible for example.net <= http://example.net> receives a

=A0 =A0request with R-URI of sip:paul.kyzivat@example.net.
=A0 =A0There is a location service
=A0 =A0with an entry registered for sip:line1@phone1.paulk.example.net,=
=A0 =A0but there is also
=A0 =A0provisioning independent of the location service that says to
=A0 =A0unconditionally forward all calls to this URI to
=A0 =A0sip:aud= et@nortel.com. This is
=A0 =A0accomplished by R-URI translation. (To ensure that the request will=
=A0 =A0not be rejected as mis-addressed.)

=A0 =A0In this case I think that sip:paul.kyzivat@example.net
=A0 =A0*is* an AoR.
Yes.
=A0 =A0 =A0And one final forwarding case:

=A0 =A0A proxy responsible for example.net <= http://example.net> receives a

=A0 =A0request with R-URI of sip:alice.smith@example.net.
=A0 =A0Alice used to work for
=A0 =A0Example Co, but she no longer does, so her URI is "out of serv= ice".
=A0 =A0But the proxy has been provisioned to translate the R-URI of Alice&= #39;s
=A0 =A0calls to her old boss' URI: sip:betty.jones@example.net.
=A0 =A0There will never be an entry
=A0 =A0in the location service for alice, registrations are not permitted.=

=A0 =A0In this case, in spite of there being no location service involved,=
=A0 =A0I still think sip:alice.smith@example.net is an AoR.

Yes, the abstract-location-service returns the address of betty. But this I= S really a border case that makes me wonder.

=A0 =A0So, IMO the bottom line is that whether a URI is an AoR is a policy=
=A0 =A0decision within the domain of the URI.

It is unclear to me what definition of AOR you are using.

I am taking at face value that AoR (Address of *Record*) is based on a *rec= ord* of the domain, which almost by definition is a matter of policy.

And I am pointing out that we don't have a definition of AoR that both = useful operationally and that meets every day expectations.
=


=A0 =A0 =A0 =A0 =A0 Thanks,
=A0 =A0 =A0 =A0 =A0 Paul



=A0 =A0Francois Audet wrote:

=A0 =A0 =A0 =A0
=A0 =A0 =A0 =A0 =A0 =A0-----Original Message-----
=A0 =A0 =A0 =A0 =A0 =A0From: Paul Kyzivat [mailto:pkyzivat@cisco.com
=A0 =A0 =A0 =A0 =A0 =A0<mailto:pkyzivat@cisco.com>] Sent: Monday, July 13, 2009 10:= 41
=A0 =A0 =A0 =A0 =A0 =A0To: Audet, Francois (SC100:3055)
=A0 =A0 =A0 =A0 =A0 =A0Cc: Hadriel Kaplan; Hans Erik van Elburg; SIPCORE =A0 =A0 =A0 =A0 =A0 =A0Subject: Re: [sipcore] rfc4244bis: what is an AoR?<= br>


=A0 =A0 =A0 =A0 =A0 =A0Francois Audet wrote:

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0To me it's crystal clear.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0If you are the entity (proxy or redirect se= rver)

=A0 =A0 =A0 =A0 =A0 =A0responsible for the

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0URI, and you find the entry in your locatio= n service, you

=A0 =A0 =A0 =A0 =A0 =A0mark as AOR.

=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0That means you will now route based on &quo= t;rules" you have
=A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0internally, e.g., map it to a contact, etc.=

=A0 =A0 =A0 =A0 =A0 =A0I think some cases are clear, others not so much:
=A0 =A0 =A0 =A0 =A0 =A0- If the proxy translates to a contact that it got = from a
=A0 =A0 =A0 =A0 =A0 =A0 =A0location service and that entry was placed ther= e by a
=A0 =A0 =A0 =A0 =A0 =A0REGISTER,
=A0 =A0 =A0 =A0 =A0 =A0 =A0then the entry should definitely be marked as a= n AoR


=A0 =A0 =A0 =A0Agree.

=A0 =A0 =A0 =A0 =A0 =A0- If the proxy translates to a contact that it got = from a
=A0 =A0 =A0 =A0 =A0 =A0 =A0ocation service, and that entry got there someh= ow other
=A0 =A0 =A0 =A0 =A0 =A0than REGISTER,
=A0 =A0 =A0 =A0 =A0 =A0 =A0then I *think* the entry should still be marked= as an AoR.


=A0 =A0 =A0 =A0Yes, agree.

=A0 =A0 =A0 =A0 =A0 =A0- If the proxy uses some other logic than a "l= ocation service"
=A0 =A0 =A0 =A0 =A0 =A0 =A0to translate the URI, but it might in other cas= es use the
=A0 =A0 =A0 =A0 =A0 =A0 =A0location service to translate the URI, then I&#= 39;m not sure.

=A0 =A0 =A0 =A0 =A0 =A0- If the proxy never uses a location service for th= is URI,
=A0 =A0 =A0 =A0 =A0 =A0 =A0but translates it on some other basis, then aga= in I'm not
=A0 =A0 =A0 =A0 =A0 =A0sure.

=A0 =A0 =A0 =A0 =A0 =A0One problem here is that the location service is ab= stract.
=A0 =A0 =A0 =A0 =A0 =A0There are things that can be done using it, or in a= nother
=A0 =A0 =A0 =A0 =A0 =A0manner. It seems to me that if it *could* have been= done
=A0 =A0 =A0 =A0 =A0 =A0with a location service lookup, then the result oug= ht to be
=A0 =A0 =A0 =A0 =A0 =A0the same whether it is or not.


=A0 =A0 =A0 =A0I think the last two are the same thing.
=A0 =A0 =A0 =A0Things like digit manipulation and so forth.

=A0 =A0 =A0 =A0I didn't want to alter (or second-guess) the definition= of AOR
=A0 =A0 =A0 =A0(which is the realm of RFC 3261), in this draft.

=A0 =A0 =A0 =A0I would think that if the proxy doesn't know that it= 9;s an AOR,
=A0 =A0 =A0 =A0then it shouldn't mark
=A0 =A0 =A0 =A0it as such. So I would expect mechanical digit manipulation= to
=A0 =A0 =A0 =A0NOT be marked as AOR.




--0015174c1dc8401292046ebff024-- From pkyzivat@cisco.com Wed Jul 15 09:14:59 2009 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 1A8933A6A6B for ; Wed, 15 Jul 2009 09:14:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.772 X-Spam-Level: X-Spam-Status: No, score=-2.772 tagged_above=-999 required=5 tests=[AWL=-3.468, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 Wd0f+irWhwWi for ; Wed, 15 Jul 2009 09:14:58 -0700 (PDT) Received: from sj-iport-4.cisco.com (sj-iport-4.cisco.com [171.68.10.86]) by core3.amsl.com (Postfix) with ESMTP id 308E33A6A6C for ; Wed, 15 Jul 2009 09:14:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHOcXUqrR7PD/2dsb2JhbAC5LYZjgUCRFgWBL4IbP4FC X-IronPort-AV: E=Sophos;i="4.42,405,1243814400"; d="scan'208";a="39507839" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-4.cisco.com with ESMTP; 15 Jul 2009 16:13:58 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6FGDwP7011206; Wed, 15 Jul 2009 09:13:58 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n6FGDrN3013801; Wed, 15 Jul 2009 16:13:57 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 12:13:57 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 12:13:56 -0400 Message-ID: <4A5E0044.1090509@cisco.com> Date: Wed, 15 Jul 2009 12:13:56 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: gao.yang2@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jul 2009 16:13:56.0990 (UTC) FILETIME=[415D89E0:01CA0567] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1191; t=1247674438; x=1248538438; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20=3D?GB2312?B?tPC4tDogUmU6ILTwuLQ6IFJlOi Bbc2lwY29yZV0gtPC4tDogUg=3D=3D?=3D=0A=20=3D?GB2312?B?ZTogIE5 ldyByZXZpc2lvbiBvZiB0aGUgcmUtSU5WSVRFIGhhbmRsaW5nIGRyYQ=3D=3 D?=3D=0A=20=3D?GB2312?B?ZnQ=3D?=3D |Sender:=20; bh=64TPZhLXI3pSAmfKqkF2heiC3h5I4C2r/TGg8bepz70=; b=RZT71VGxfm3P0du1kLubJ/XMyCFRhVLdiCLxBOttvvoGKt/EM3pmCYdPWt 79O0ShTEeM6CLimXV89Chshl2LkbgG7wgP0mZPNl/GNh+HCqDARZtBiSKelq RdNpbBYx84; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: SIPCORE , OKUMURA Shinji Subject: Re: [sipcore] =?gb2312?b?tPC4tDogUmU6ILTwuLQ6IFJlOiAgtPC4tDogUmU6ICBO?= =?gb2312?b?ZXcgcmV2aXNpb24gb2YgdGhlIHJlLUlOVklURSBoYW5kbGluZyBkcmFmdA==?= 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, 15 Jul 2009 16:14:59 -0000 gao.yang2@zte.com.cn wrote: > If the UAC decides to fix this by sending an UPDATE before completion of > the reINVITE, then it may succeed in getting the remote target changed > at the UAS. But the *UAS is still obligated to send the remaining > responses to the address in the Via, which is the old address. * > > [Gao] It is in RFC3261, but RFC3311 has the definition as: > > from RFC3311: > UPDATE is a target refresh request. As specified in RFC 3261 [1], > this means that it can update the remote target of a dialog. If a UA > uses an UPDATE request or response to modify the remote target while > *an INVITE transaction is in progress*, and it is a UAS for that INVITE > transaction, it *MUST place the same value into the Contact header* > * field of the 2xx to the INVITE that it placed into the UPDATE request* > * or response*. > > So, it should be the new address here. You miss my point. Its not about the Contact placed *in* the 2xx response. Its about the address to which the response is delivered. That is dictated by the Via headers in the INVITE request. Those are not affected by the target refresh. Thanks, Paul From AUDET@nortel.com Wed Jul 15 09:50:08 2009 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 70C4B3A6F3E for ; Wed, 15 Jul 2009 09:50:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.447 X-Spam-Level: X-Spam-Status: No, score=-6.447 tagged_above=-999 required=5 tests=[AWL=0.151, 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 8ZNmEDVyT2G2 for ; Wed, 15 Jul 2009 09:50:07 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id A0D353A6F42 for ; Wed, 15 Jul 2009 09:48:58 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6FGIaF26962; Wed, 15 Jul 2009 16:18:36 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0568.11D67EAE" Date: Wed, 15 Jul 2009 11:19:46 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFE0C85@zrc2hxm0.corp.nortel.com> In-Reply-To: <9ae56b1e0907150443v31e77f6s4ee671d87fd3e72b@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: Open Issues thread-index: AcoFQX3av74jwgwNSnOa8dGN07YI+QAJoTQA References: <1ECE0EB50388174790F9694F77522CCF1EF51FF9@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EF521C4@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EF52209@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EF522A1@zrc2hxm0.corp.nortel.com> <9ae56b1e0907150443v31e77f6s4ee671d87fd3e72b@mail.gmail.com> From: "Francois Audet" To: "Hans Erik van Elburg" , "Hadriel Kaplan" Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: Open Issues 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, 15 Jul 2009 16:50:08 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0568.11D67EAE Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, we did. =20 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Wednesday, July 15, 2009 04:43 To: Hadriel Kaplan Cc: Audet, Francois (SC100:3055); SIPCORE Subject: Re: [sipcore] rfc4244bis: Open Issues =09 =09 This is like the Target header we proposed a while ago, but with a = change of keeping all the retargets that would qualify for "mp". = (http://tools.ietf.org/html/draft-holmberg-sip-target-uri-delivery-01) I thought that the wg came to consensus that this needs to be resolved = with History-Info. If not... /Hans Erik van Elburg =09 =09 On Tue, Jul 14, 2009 at 3:42 AM, Hadriel Kaplan = wrote: =09 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] =09 > Sent: Monday, July 13, 2009 8:14 PM > > If there is a tag (anyone), it's 4244bis. > If there is none, it's 4244. =09 =09 Got it. Hate it, but got it. :) =09 You're going to hate this idea too, but oh well... the delete key is = in easy reach... so here goes: I suggest an explicit version tag. The tag appears not in the header = field itself, but in something called a "header-name" part of an = "extension-header" in ABNF rules per rfc3261. I suggest a new = "header-name" value of "R-History-Info". You can pretend the "R" is for = Retargeted-History-Info, or Reduced-History-Info, or = Revisionist-History-Info. :) =09 This "R-History-Info" extension-header is a multi-instance type, and a = Proxy only ever adds to it if it is changing the received req-uri *and* = would have set the "mp" flag for the new URI it is adding. The first = RHI entry is added by the first proxy or UAC based on what it received, = like in H-I, even though it's not retargeting to that URI. The = extension-header's header-value is the URI being retargeted to. There = are no currently defined header parameters. =09 This RHI header field is not for troubleshooting - it's for actual = processing use. Therefore, there is no incrementing index param, no = embedded Reason header, and no entries created for anything but = retargeted events and their new URI's (and the first one). Privacy does = not apply to this on a header-by-header basis, and thus there is no = embedded Privacy header either - if Privacy:history was requested, no = RHI fields would be created. =09 Compared with RFC 4244, the RHI header field would produce a smaller = subset of header instances. In some cases significantly smaller. For = example, in the most common case, only a single RHI header field would = be in the message, regardless of how many proxies were crossed. There = is also less processing overhead for every node in the message path. =09 It should be noted that, like RFC 4244, RHI does not produce the = smallest list possible of retargets - in some cases an entry is added = when the target user Identity has not changed - the URI has changed to a = new one, but unbeknownst to the Proxy which added it, the Identity of = the human may have remained the same. For example an entry for = "sip:Robert.Khaled@example.com = " and a subsequent entry for "sip:bob@sales.example.com = " may both have been added, even = though they are the same abstract target human. A proxy cannot know by = default that these two targets are the same identity. Only the UAS = would know that, and so it may need to cull the list down further. =09 -hadriel =09 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore =09 ------_=_NextPart_001_01CA0568.11D67EAE Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yes,=20 we did.
 

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: Wednesday, July 15, = 2009=20 04:43
To: Hadriel Kaplan
Cc: Audet, Francois = (SC100:3055);=20 SIPCORE
Subject: Re: [sipcore] rfc4244bis: Open=20 Issues

This is like the Target header we proposed a while ago, but with = a change=20 of keeping all the retargets that would qualify for "mp". (http://tools.ietf.org/html/draft-holmberg-sip-target-uri-delivery-01= )

I thought that the wg came to consensus that this needs to be = resolved=20 with History-Info. If not...

/Hans Erik van = Elburg

On Tue, Jul 14, 2009 at 3:42 AM, Hadriel = Kaplan <HKaplan@acmepacket.com>=20 wrote:


> -----Original Message-----
> = From: Francois=20 Audet [mailto:audet@nortel.com]
> Sent: Monday, July 13, 2009 8:14 = PM
>
> If=20 there is a tag (anyone), it's 4244bis.
> If there is none, = it's=20 4244.

Got it.  Hate it, but got it. = :)

You're going=20 to hate this idea too, but oh well... the delete key is in easy = reach... so=20 here goes:
I suggest an explicit version tag.  The tag = appears not=20 in the header field itself, but in something called a "header-name" = part of=20 an "extension-header" in ABNF rules per rfc3261.  I suggest a = new=20 "header-name" value of "R-History-Info".  You can pretend the = "R" is=20 for Retargeted-History-Info, or Reduced-History-Info, or=20 Revisionist-History-Info. :)

This "R-History-Info" = extension-header=20 is a multi-instance type, and a Proxy only ever adds to it if it is = changing=20 the received req-uri *and* would have set the "mp" flag for the new = URI it=20 is adding.  The first RHI entry is added by the first proxy or = UAC=20 based on what it received, like in H-I, even though it's not = retargeting to=20 that URI.  The extension-header's header-value is the URI being = retargeted to.  There are no currently defined header=20 parameters.

This RHI header field is not for troubleshooting = - it's=20 for actual processing use.  Therefore, there is no incrementing = index=20 param, no embedded Reason header, and no entries created for = anything but=20 retargeted events and their new URI's (and the first one). =  Privacy=20 does not apply to this on a header-by-header basis, and thus there = is no=20 embedded Privacy header either - if Privacy:history was requested, = no RHI=20 fields would be created.

Compared with RFC 4244, the RHI = header field=20 would produce a smaller subset of header instances.  In some = cases=20 significantly smaller.  For example, in the most common case, = only a=20 single RHI header field would be in the message, regardless of how = many=20 proxies were crossed.  There is also less processing overhead = for every=20 node in the message path.

It should be noted that, like RFC = 4244, RHI=20 does not produce the smallest list possible of retargets - in some = cases an=20 entry is added when the target user Identity has not changed - the = URI has=20 changed to a new one, but unbeknownst to the Proxy which added it, = the=20 Identity of the human may have remained the same.  For example = an entry=20 for "sip:Robert.Khaled@example= .com"=20 and a subsequent entry for "sip:bob@sales.example.com= " may=20 both have been added, even though they are the same abstract target = human.=20  A proxy cannot know by default that these two targets are the = same=20 identity.  Only the UAS would know that, and so it may need to = cull the=20 list down further.

-hadriel

__________________________________________= _____
sipcore=20 mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

------_=_NextPart_001_01CA0568.11D67EAE-- From AUDET@nortel.com Wed Jul 15 12:53:27 2009 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 1B37628C155 for ; Wed, 15 Jul 2009 12:53:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.453 X-Spam-Level: X-Spam-Status: No, score=-6.453 tagged_above=-999 required=5 tests=[AWL=0.146, 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 FTnPdZd4GbRb for ; Wed, 15 Jul 2009 12:53:26 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 0E33D28C154 for ; Wed, 15 Jul 2009 12:53:25 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6FJmZF27463; Wed, 15 Jul 2009 19:48:35 GMT 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: Wed, 15 Jul 2009 14:48:52 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFE1215@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EFE0860@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: Do we need rt / mp / rc / cc thread-index: AcoEDqM/XIENvO+JQM+deNhoIRK3fQAAKw3QAAbzRkAAHH9xoAAt/EuAAAksXYA= References: <4A5B7195.6020009@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com><4A5BBE0C.5000301@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFA0F7C@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFE0860@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Mary Barnes" , "SIPCORE" Cc: Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: Do we need rt / mp / rc / cc 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, 15 Jul 2009 19:53:27 -0000 I think indeed the aor; flag may actually solve the issue. But yes, let's think about it. In earlier versions, the "mp" flag was representing the "mapped from" address instead of the mapped to address", and there was no "aor". Then we switched it around to have the "aor" mean "I've found this address in my location service as my own". The reason we need something like this is that most algorithm work by looking at the previous target of significance. This is why we have the aor flag now: it marks the proper target. The problem with logic like "look at the previous target" instead of using a marking is that the previous target may be wrong. It may be one of those "fluff" entries. This is a big problem with current 4244. If we were to package all the fluff together, then the combination of aor (previous target) and then the the "map" (on the next target is useful). Everything else (i.e., the fluff) implies the same user. An alternative would be to have only a flag for the previous target, i.e., "aor-mp" and "aor-same", and then everything else is fluff. > -----Original Message----- > From: Barnes, Mary (RICH2:AR00)=20 > Sent: Wednesday, July 15, 2009 07:09 > To: Audet, Francois (SC100:3055); SIPCORE > Cc: Hadriel Kaplan > Subject: RE: [sipcore] rfc4244bis: Do we need rt / mp / rc / cc >=20 > After thinking about this some, I'd still prefer to keep=20 > Option A. as I recall there was a good reason for the more=20 > precise values, although that may have been before we had the=20 > "aor" tag.=20 >=20 > On the surface, simpler might be better although in terms of=20 > implementation if "rc" and "cc" are handled the same then=20 > it's really no big deal. And, the "rc" and "cc" do provide a=20 > bit more information for the debug use case. From jmpolk@cisco.com Wed Jul 15 13:10:14 2009 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 AFA1A3A6F3B for ; Wed, 15 Jul 2009 13:10:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.333 X-Spam-Level: X-Spam-Status: No, score=-6.333 tagged_above=-999 required=5 tests=[AWL=0.266, 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 CPWeqnVn0A4c for ; Wed, 15 Jul 2009 13:10:13 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 20AC03A6EA3 for ; Wed, 15 Jul 2009 13:10:13 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikHADvUXUqrR7PD/2dsb2JhbACIQ7B/iCORDAWECQ X-IronPort-AV: E=Sophos;i="4.42,406,1243814400"; d="scan'208";a="186442392" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-2.cisco.com with ESMTP; 15 Jul 2009 20:09:47 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6FK9lwM011612; Wed, 15 Jul 2009 13:09:47 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6FK9l8U016844; Wed, 15 Jul 2009 20:09:47 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 13:09:47 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.4.19]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 13:09:46 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 15 Jul 2009 15:09:45 -0500 To: "Elwell, John" , sipcore@ietf.org From: "James M. Polk" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00221E12A@GBNTHT12009MSX.gb 002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D00218C372@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00221DBF8@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00221DC12@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00221E0FD@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D00221E12A@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 15 Jul 2009 20:09:46.0798 (UTC) FILETIME=[334EE4E0:01CA0588] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1764; t=1247688587; x=1248552587; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20Use=20of=20term=20=22Location=20Server= 22=20in=20location-conveyance=20draft |Sender:=20; bh=mNbNf8f3ibYfC/gpqV9QLjjyPZkYKtrO4cn5UVgD68o=; b=s6rRx/9/UXv8tCzbnLuDP+vGHL3KcZJBatYqLfcBMO+PYH1HUEEAxKQYWj 5acOva6tp0VZzA0t2KI3PqS1J7DqfXzWZxUkwMVwwYFYAV+eEwXKKoafTDsq aBS5jgKGiL; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: "marc Linsner \(mlinsner\)" Subject: Re: [sipcore] Use of term "Location Server" in location-conveyance draft 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, 15 Jul 2009 20:10:14 -0000 At 01:40 AM 7/14/2009, Elwell, John wrote: > > > > BTW - the LIS is who provides a target its DHCP or > > LLDP-MED or HELD > > > > location information too. Meaning, the LIS has to be able to do L2 > > > > downloads of LI *and* L7 subscriptions. > > > > > > > > > > > > >I agree with others, by the way, that LIS is not an > > > > appropriate term for > > > > >the latter. > > > > > > > > see above, it now *IS* the proper term for the latter, > > but only if it > > > > is the target that's doing it. > > >[JRE] But in the context of sip-location-conveyance, the UAS > > or a proxy > > >that receives the location will NEVER be the target, so it > > will NEVER be > > >a LIS when dereferencing occurs. > > > > that's not true. Conveyance states that a target can take its > > location URI and subscribe to it to receive its PIDF-LO. This has > > been in there for a while. >[JRE] Perhaps NEVER is wrong, but HIGHLY UNLIKELY. Why would Bob's UAC >(or a proxy) insert Alice's LbyR into a request sent to Alice, such that >Alice's UAS receives Alice's LbyR and attempts to dereference? I don't believe Bob would sent Alice her location URI to be dereferenced by Alice, but I don't believe we ought to prevent it. I do see Alice receiving several of her friends' (i.e., buddy's) locations, say at a shopping mall, and then telling Carol where all their friends are in one message. I have 2 daughters, 21 and 11, and the 21 yr old asked a couple of years ago when this can be possible so she can use it. The 11 yr old is just starting to understand how this can be used. Operators may not configure this ability, but the protocol shouldn't prevent it from all operators being able to offer the capability. >John From HKaplan@acmepacket.com Wed Jul 15 13:57:51 2009 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 2360D28C179 for ; Wed, 15 Jul 2009 13:57:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.022, 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 aLJTT6jWD9LL for ; Wed, 15 Jul 2009 13:57:47 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D6ACF28C13E for ; Wed, 15 Jul 2009 13:57:46 -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.1.375.2; Wed, 15 Jul 2009 16:55:29 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 15 Jul 2009 16:55:27 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg Date: Wed, 15 Jul 2009 16:55:25 -0400 Thread-Topic: [sipcore] rfc4244bis: Open Issues Thread-Index: AcoFQZE5+TKzXVNMSoWi9iy44NTGTwATAuTg Message-ID: References: <1ECE0EB50388174790F9694F77522CCF1EF51FF9@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EF521C4@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EF52209@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EF522A1@zrc2hxm0.corp.nortel.com> <9ae56b1e0907150443v31e77f6s4ee671d87fd3e72b@mail.gmail.com> In-Reply-To: <9ae56b1e0907150443v31e77f6s4ee671d87fd3e72b@mail.gmail.com> 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_E6C2E8958BA59A4FB960963D475F7AC31969D2944Dmail_" MIME-Version: 1.0 Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: Open Issues 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, 15 Jul 2009 20:57:51 -0000 --_000_E6C2E8958BA59A4FB960963D475F7AC31969D2944Dmail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Yup, and I also thought it would be good to try to solve it with an already= -existing mechanism (ie, H-I). But if in the end we find doing that is really complicated or confusing, it= 's not like we can't change our minds. Right now though, I'm not sure if doing it in a new header is any easier th= an incorporating it into H-I. Clearly it would be a lot more verbose (ther= e'd be a lot more fluff) in H-I, but if a machine can programmatically/dete= rministically reduce it to the same set of info a new header would have had= without a lot of processing effort or room for error, then that's fine wit= h me. -hadriel ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] Sent: Wednesday, July 15, 2009 7:43 AM To: Hadriel Kaplan Cc: Francois Audet; SIPCORE Subject: Re: [sipcore] rfc4244bis: Open Issues This is like the Target header we proposed a while ago, but with a change o= f keeping all the retargets that would qualify for "mp". (http://tools.ietf= .org/html/draft-holmberg-sip-target-uri-delivery-01) I thought that the wg came to consensus that this needs to be resolved with= History-Info. If not... /Hans Erik van Elburg On Tue, Jul 14, 2009 at 3:42 AM, Hadriel Kaplan > wrote: --_000_E6C2E8958BA59A4FB960963D475F7AC31969D2944Dmail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Yup, and I also thought it would be go= od to try to solve it with an already-existing mechanism (ie, H-I).

But if in the end we find doing that i= s really complicated or confusing, it’s not like we can’t change = our minds.

Right now though, I’m not sure i= f doing it in a new header is any easier than incorporating it into H-I. &nbs= p;Clearly it would be a lot more verbose (there’d be a lot more fluff) in H-I, = but if a machine can programmatically/deterministically reduce it to the same s= et of info a new header would have had without a lot of processing effort or r= oom for error, then that’s fine with me.

 

-hadriel

 

From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
Sent: Wednesday, July 15, 20= 09 7:43 AM
To: Hadriel Kaplan
Cc: Francois Audet; SIPCORE
Subject: Re: [sipcore] rfc42= 44bis: Open Issues

 

This is like the Target header we proposed a while ago, but with a change of keeping all the retargets that would qualify for "mp". = (http://tools.ietf.org/html/draft-holmberg-sip-target-uri-delivery-01= )

 

I thought that the wg came to consensus that this needs to be resol= ved with History-Info. If not...


/Hans Erik van Elburg

On Tue, Jul 14, 2009 at 3:42 AM, Hadriel Kaplan <HKaplan@acmepacket.com> wrote= :




 

--_000_E6C2E8958BA59A4FB960963D475F7AC31969D2944Dmail_-- From jmpolk@cisco.com Wed Jul 15 14:35:20 2009 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 165653A6C8C for ; Wed, 15 Jul 2009 14:35:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.336 X-Spam-Level: X-Spam-Status: No, score=-6.336 tagged_above=-999 required=5 tests=[AWL=0.263, 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 pHZZogG+R7Gt for ; Wed, 15 Jul 2009 14:35:18 -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 7B5523A6C78 for ; Wed, 15 Jul 2009 14:35:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMNAK/nXUqrR7MV/2dsb2JhbAAwiBOwbIgjLAiQXgWCJw0NBQiBOw X-IronPort-AV: E=Sophos;i="4.42,406,1243814400"; d="scan'208";a="86196188" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-5.cisco.com with ESMTP; 15 Jul 2009 21:34:20 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6FLYKxA027702; Wed, 15 Jul 2009 14:34:20 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6FLYKED017946; Wed, 15 Jul 2009 21:34:20 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 14:34:20 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.4.19]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 14:34:19 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 15 Jul 2009 16:34:18 -0500 To: "Thomson, Martin" , "Jon Peterson" From: "James M. Polk" In-Reply-To: References: <0D5F89FAC29E2C41B98A6A762007F5D00221E129@GBNTHT12009MSX.gb002.siemens.net> <020001ca04bf$21910fe0$64b32fa0$@net> <4A5D64E4.4020008@neustar.biz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 15 Jul 2009 21:34:19.0766 (UTC) FILETIME=[03086160:01CA0594] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=10630; t=1247693660; x=1248557660; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[sipcore]=20Confusion=20over=20target=2 0inSIP=20location-conveyance=0A=20=20-=09andimpact=20on=20EC RIT=20phonebcp |Sender:=20; bh=1mfYyYT7v2qqsl0rBk1Et9Rc6/7mlzb3iVdgV28SXC8=; b=B8Vms0CRu9QkxfWtaXdBnW7vjcfJo6tpHSzAy1e9MUm5liOGxkpYHwuvyT lFmwkml7SLTnwPfcQST9+hLmTnAnN0ECmGUjLL3+ndFPoH0ivk4mf0h3unnz ctpPu6ENOAktDEwcidgLlnCk7Yl6O4+tKvHeNsgVJVH+I7MOmerm8=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sipcore@ietf.org Subject: Re: [sipcore] Confusion over target inSIP location-conveyance - andimpact on ECRIT phonebcp 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, 15 Jul 2009 21:35:20 -0000 At 12:27 AM 7/15/2009, Thomson, Martin wrote: >Hi Jon, > >Here's the problem: >I am sip:mt@andrew.com. I use HELD or DHCP to request a location >URI. This is what is put in my SIP INVITE. A proxy dereferences >this to determine where to route the call. They encounter >pres:v76ns38907v6e05@lis.example.com in the resulting PIDF-LO. The >location information is ignored; it's not applicable to the requester. I'm having problems parsing this paragraph - and I believe you are conflating two issues that aren't the same. In the above example, you same you are entity=sip:mt@andrew.com for any prsence document. DHCP or HELD hands you a location URI that you don't show us in your example. In the presence document, what element or attribute is the pres:v76ns38907v6e05@lis.example.com found? Is this in the entity= attribute? If so, it's unlinkable -- unless the receiver understands the link between v76ns38907v6e05@lis.example.com and mt@andrew.com However, how I'm reading the pres:v76ns38907v6e05@lis.example.com URI, this looks an awful lot like a location URI (because of the '...@lis...' ). The entity= pres: URI shouldn't be something that's on a LIS in the way you use that term in the Geopriv Architecture. The entity= attribute is more like an AOR that identifies you - Martin - as what the presence document is about (unless you want your presence document to be unlinkable except for your buddies). >The server that provides the location information has no basis to >determine that the entity making a request and sip:mt@andrew.com are >one and the same. Thus, it cannot make this assertion. HELD >recommends the creation of a pseudonym for this reason. > >How do we resolve this? > >We could define a mechanism for asserting sip identity in other >domains, such that HELD could use it. Sounds a bit heavyweight to me. I don't get this connection - to how the LIS will somehow understand the layer 7 identity of a client it sends it's location URI to. How's that gonna work exactly? More importantly, how's that *not* going to violate the understanding that LCPs never link identity with LCI? >Providing a linkage between the two in SIP might work, but it sounds >like you don't want to do that. Shame, because that's the >easiest. One simple way would be to add a ';me' parameter to the >geolocation header, which links the UAC (identified in From:) to the >location object, irrespective of the identified presentity. this totally blows up the idea of unkinkable pseudonyms that are a requirement from RFC 3693 - and I'm not going there unless everyone in both WGs agree, since that's an established security mechanism. >--Martin > >p.s. On a similar thread, I think I remember reading that >sip:mt@andrew.com is the same as pres:mt@andrew.com. Is this >guaranteed truth, or just highly likely? > > > -----Original Message----- > > From: Jon Peterson [mailto:jon.peterson@neustar.biz] > > Sent: Wednesday, 15 July 2009 3:11 PM > > To: Thomson, Martin > > Cc: Brian Rosen; Elwell, John; James M. Polk; sipcore@ietf.org > > Subject: Re: [sipcore] Confusion over target inSIP location-conveyance > > - andimpact on ECRIT phonebcp > > > > > > There must be something I'm missing in this discussion, but I've found > > this issue with identity binding a bit elusive. PIDF documents (let > > alone PIDF-LO documents) necessarily contain a field designating the > > entity that the document is supposed to represent - the "entity" > > attribute of . Given that this attribute contains a URI, it > > can be as specific or opaque as is necessary for the application in > > question. It appears regardless of how the PIDF document is acquired > > (by > > reference or by value). In what way is this element insufficient > > exactly? > > > > I would certainly be skeptical of any SIP-layer mechanism that is > > intended to provide a separate account of how a PIDF document is > > "bound" > > to the entity it represents. > > > > Jon Peterson > > NeuStar, Inc. > > > > Thomson, Martin wrote: > > > I still haven't seen an explanation on how to resolve the identity > > binding problem when location is provided by reference. That's a small > > thing for phone-bcp, but not for location-conveyance. > > > > > > > > >> -----Original Message----- > > >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > > >> Behalf Of Brian Rosen > > >> Sent: Wednesday, 15 July 2009 6:10 AM > > >> To: 'Elwell, John'; 'James M. Polk'; sipcore@ietf.org > > >> Subject: Re: [sipcore] Confusion over target inSIP location- > > conveyance > > >> - andimpact on ECRIT phonebcp > > >> > > >> I have raised this very issue with James, and verified it with Jon > > >> Peterson > > >> and Robert Sparks, and the intention is that the Geolocation header > > can > > >> carry the location of any target, the specific target being that > > >> identified > > >> in the PIDF, and subject to the privacy requirements of that target. > > >> > > >> It turns out to be useful to do this in a couple of cases I've run > > >> across, > > >> although I'm somewhat surprised that everyone agreed it is okay to > > do > > >> so. > > >> > > >> While I guess I could improve phonebcp by making an explicit > > statement > > >> that, > > >> when sent to the PSAP, the location in the header must be that of > > the > > >> caller, I do think it's clear enough that it is. > > >> > > >> I'll do that in the next rev, although I don't want to hold up > > sending > > >> the > > >> current version to the IESG over that tidbit. > > >> > > >> Brian > > >> > > >> > > >>> -----Original Message----- > > >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > >>> Sent: Tuesday, July 14, 2009 2:40 AM > > >>> To: James M. Polk; sipcore@ietf.org; Brian Rosen > > >>> Subject: Confusion over target inSIP location-conveyance - and > > impact > > >>> on ECRIT phonebcp > > >>> > > >>> In 4.2 it states: > > >>> "The UAC can use whatever means it knows of to verify/refresh its > > >>> location information before attempting a new request that > > includes > > >>> location." > > >>> "its location information" suggests that the UAC is the target. > > >>> > > >>> In 4.3.3 it states: > > >>> "This document gives no guidance how this is accomplished, given > > the > > >>> number of ways a UAC can learn its location" > > >>> which suggests similar. > > >>> > > >>> Similarly in 6.1: > > >>> "If a UAC does not learn and store its location locally (a GPS > > chip) > > >>> or from the network (DHCP or LLDP-MED), the UAC MAY learn its > > LbyR > > >>> URI (from DHCP for example)." > > >>> Which suggests that a UAC inserts its location, not some other > > >>> location. > > >>> > > >>> And later in 6.1: > > >>> "If a UAC has already conveyed location in the original request of > > a > > >>> transaction, and wants to update its location information ..." > > >>> > > >>> In 6.2: > > >>> "If the LbyR URI is > > >>> sip:, sips: or pres:, and the UAS wants to learn the UAC's > > >>> location," > > >>> > > >>> In 6.2.1: > > >>> "This > > >>> means the SIP server is including its version of where it thinks > > >>> > > >> the > > >> > > >>> UAC is, geographically." > > >>> > > >>> In 8: > > >>> "Conveyance of physical location of a UAC raises privacy concerns" > > >>> > > >>> and: > > >>> "In cases where a session set-up is > > >>> retargeted based on the location of the UAC initiating the call > > or > > >>> SIP MESSAGE," > > >>> > > >>> All these many examples illustrate an implication that the location > > >>> target is the UAC. I am sure there are other places too. > > >>> > > >>> I found a couple of places that contradict this. In 6.2 it states: > > >>> "If there > > >>> is more than one PIDF-LO with different Target identifiers, then > > >>> the UAC is merely telling the UAS where more than one Target is, > > >>> > > >> and > > >> > > >>> there should not be any conflict." > > >>> > > >>> I think there are other places that mention locations of multiple > > >>> targets in a request, implying they cannot all be the location of > > the > > >>> UAC. > > >>> > > >>> And in 6.2.1 it states: > > >>> "The Location Target identified in > > >>> the PIDF-LO may or may not be the location inserter, or the > > >>> generator of the request (the UAC or SIP server)." > > >>> > > >>> So we have inconsistency as to whether a conveyed location is that > > of > > >>> they UAC or not. > > >>> > > >>> One document that relies on location-conveyance is ECRIT's > > phonebcp. > > >>> > > >> In > > >> > > >>> there, I cannot find any reference to a routing entity looking to > > see > > >>> whether a conveyed location has the caller as target or not. It > > just > > >>> assumes that this is the case. So if we were to agree that a > > conveyed > > >>> location is not necessarily the location of the UAC, this will have > > >>> impact on phonebcp. > > >>> > > >>> John > > >>> > > >> _______________________________________________ > > >> sipcore mailing list > > >> sipcore@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sipcore > > >> > > > > > > --------------------------------------------------------------------- > > --------------------------- > > > This message is for the designated recipient only and may > > > contain privileged, proprietary, or otherwise private information. > > > If you have received it in error, please notify the sender > > > immediately and delete the original. Any unauthorized use of > > > this email is prohibited. > > > --------------------------------------------------------------------- > > --------------------------- > > > [mf2] > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] From HKaplan@acmepacket.com Wed Jul 15 14:51:14 2009 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 21F403A6927 for ; Wed, 15 Jul 2009 14:51:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 Oye6GjmZh08I for ; Wed, 15 Jul 2009 14:51:13 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id E9A7E3A68D2 for ; Wed, 15 Jul 2009 14:51:12 -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.1.375.2; Wed, 15 Jul 2009 17:46:50 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 15 Jul 2009 17:46:50 -0400 From: Hadriel Kaplan To: SIPCORE Date: Wed, 15 Jul 2009 17:46:47 -0400 Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoFRoWh2hBP5wjyQIWzHzootDGkMgASGu2gAAAGFAA= 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 Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 15 Jul 2009 21:51:14 -0000 > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Wednesday, July 15, 2009 8:19 AM >=20 > How does it matter whether there are multiple translation steps in a > domain? > What matters that if I sent something to:=A0sip:81234@example.net=A0that = it > will be delivered to the intended party. In this sense this is an AOR. I > could put this on my business card for example. I think part of the confusion (at least for me) is using the term "AoR" and= a tag named "aor". It's just not the cut-and-dried what is or is not an A= oR, imho. The rules by which systems change one URI to another URI can eas= ily be viewed/described as performing a location-service lookup. Just beca= use a system implements those rules in a regex replacement, route tables, E= NUM lookup, HSS lookup, or whatever, doesn't matter - they don't know when = the URI they've changed it from was an AoR or not. =20 I think what you guys are saying is "it doesn't matter" - all that matters = is that a URI of a domain for which the proxy is responsible, which is used= by that proxy for a location-service lookup, actually be tagged with "aor"= . It's ok if that tags things which aren't "AoR's" in the classic sense, a= nd thus more H-I entries are tagged than are really needed, because the UAS= will ignore them. Is that right? -hadriel From jmpolk@cisco.com Wed Jul 15 14:51:46 2009 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 485583A6C58 for ; Wed, 15 Jul 2009 14:51:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.339 X-Spam-Level: X-Spam-Status: No, score=-6.339 tagged_above=-999 required=5 tests=[AWL=0.260, 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 RJuEsg4S5wWi for ; Wed, 15 Jul 2009 14:51:44 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id CFE733A68D2 for ; Wed, 15 Jul 2009 14:51:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMNADPrXUqrR7PD/2dsb2JhbAAwiBOwYIgjLAiQYAWCJwwBDQUIgTuJZg X-IronPort-AV: E=Sophos;i="4.42,406,1243814400"; d="scan'208";a="214550478" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 15 Jul 2009 21:49:31 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6FLnV0d007329; Wed, 15 Jul 2009 14:49:31 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6FLnVvP001166; Wed, 15 Jul 2009 21:49:31 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 14:49:31 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.4.19]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 14:49:30 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 15 Jul 2009 16:49:29 -0500 To: "Elwell, John" , "Thomson, Martin" , Jon Peterson From: "James M. Polk" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D002264E85@GBNTHT12009MSX.gb 002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D00221E129@GBNTHT12009MSX.gb002.siemens.net> <020001ca04bf$21910fe0$64b32fa0$@net> <4A5D64E4.4020008@neustar.biz> <0D5F89FAC29E2C41B98A6A762007F5D002264E85@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 15 Jul 2009 21:49:31.0056 (UTC) FILETIME=[22343300:01CA0596] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12168; t=1247694571; x=1248558571; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[sipcore]=20Confusion=20over=20target=2 0inSIP=20location-conveyance=0A=20=20-=20andimpact=20on=20EC RIT=20phonebcp |Sender:=20; bh=0RuVW9l8FjO3SqwkBL0EqclCVSTo/IPF5WkD5GQ/iCc=; b=hU/QdbZ4X2peJJpiD5RrECWvjfyhJxhGOyjdVOOWc8cSFaheCH/t0FGZjY x07/JOtUhLScNl9ZRQY3Up0CSzgaIHKoLLH1QZvxN7PxXPyV1vuKfaLpzvdN KHBKkyN/xz; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: sipcore@ietf.org Subject: Re: [sipcore] Confusion over target inSIP location-conveyance - andimpact on ECRIT phonebcp 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, 15 Jul 2009 21:51:46 -0000 At 01:19 AM 7/15/2009, Elwell, John wrote: >So this is where we stand, from my point of view. We can pursue one of >several directions: > >1) We decide that the identifier in the PIDF document is sufficient to >identify the target and, where it is important that the target be the >SIP requester (e.g., for SIP request routing), that this can easily be >determined by comparing the SIP From or PAI with the PIDF target >identifier. In this case, we would at least need to change the many >places in location-conveyance that imply that the location target is the >UAC. Linking the SIP signaling identity to the presence document entity mandates that there be zero possibility of "unlinkable pseudonyms" as stated in RFC 3693. Further, this prevents a SIP request from having more than one PIDF-LO from difference targets in the same message. As an alternative, we can advise that when a UAC knows a particular request will have to be routed based on the provided location, that the entity= attribute match the From header. This means only a change in phoneBCP, since there is a unique Geolocation-Error header value for this linkable to be present, though it doesn't suggest the From and entity= be the same (which could be added). >We would also need to add something to phonebcp (at its next >update) to point this out. > >2) We decide that we need something explicit at the SIP level, such as >the ";me" parameter to the Geolocation header field that Martin >suggested, that says that the location target is indeed the UAC. this kills the capabilities for unlinkable pseudonyms that are required because of RFC 3693. Martin's example problem doesn't make sense to me yet, because it appears that he claims the proxy will get a location URI *in* the PIDF-LO (where there is no place for one now). >3) We decide that the location target MUST be the UAC. Brian tells me >there are use cases where greater flexibility would be desirable, >however (I don't know what these are). see my earlier email for one good one that the younger generation wants already; there are others too. >John > > > > -----Original Message----- > > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > Sent: 15 July 2009 06:28 > > To: Jon Peterson > > Cc: Brian Rosen; Elwell, John; James M. Polk; sipcore@ietf.org > > Subject: RE: [sipcore] Confusion over target inSIP > > location-conveyance - andimpact on ECRIT phonebcp > > > > Hi Jon, > > > > Here's the problem: > > I am sip:mt@andrew.com. I use HELD or DHCP to request a > > location URI. This is what is put in my SIP INVITE. A proxy > > dereferences this to determine where to route the call. They > > encounter pres:v76ns38907v6e05@lis.example.com in the > > resulting PIDF-LO. The location information is ignored; it's > > not applicable to the requester. > > > > The server that provides the location information has no > > basis to determine that the entity making a request and > > sip:mt@andrew.com are one and the same. Thus, it cannot make > > this assertion. HELD recommends the creation of a pseudonym > > for this reason. > > > > How do we resolve this? > > > > We could define a mechanism for asserting sip identity in > > other domains, such that HELD could use it. Sounds a bit > > heavyweight to me. > > > > Providing a linkage between the two in SIP might work, but it > > sounds like you don't want to do that. Shame, because that's > > the easiest. One simple way would be to add a ';me' > > parameter to the geolocation header, which links the UAC > > (identified in From:) to the location object, irrespective of > > the identified presentity. > > > > --Martin > > > > p.s. On a similar thread, I think I remember reading that > > sip:mt@andrew.com is the same as pres:mt@andrew.com. Is this > > guaranteed truth, or just highly likely? > > > > > -----Original Message----- > > > From: Jon Peterson [mailto:jon.peterson@neustar.biz] > > > Sent: Wednesday, 15 July 2009 3:11 PM > > > To: Thomson, Martin > > > Cc: Brian Rosen; Elwell, John; James M. Polk; sipcore@ietf.org > > > Subject: Re: [sipcore] Confusion over target inSIP > > location-conveyance > > > - andimpact on ECRIT phonebcp > > > > > > > > > There must be something I'm missing in this discussion, but > > I've found > > > this issue with identity binding a bit elusive. PIDF documents (let > > > alone PIDF-LO documents) necessarily contain a field designating the > > > entity that the document is supposed to represent - the "entity" > > > attribute of . Given that this attribute contains > > a URI, it > > > can be as specific or opaque as is necessary for the application in > > > question. It appears regardless of how the PIDF document is acquired > > > (by > > > reference or by value). In what way is this element insufficient > > > exactly? > > > > > > I would certainly be skeptical of any SIP-layer mechanism that is > > > intended to provide a separate account of how a PIDF document is > > > "bound" > > > to the entity it represents. > > > > > > Jon Peterson > > > NeuStar, Inc. > > > > > > Thomson, Martin wrote: > > > > I still haven't seen an explanation on how to resolve the identity > > > binding problem when location is provided by reference. > > That's a small > > > thing for phone-bcp, but not for location-conveyance. > > > > > > > > > > > >> -----Original Message----- > > > >> From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On > > > >> Behalf Of Brian Rosen > > > >> Sent: Wednesday, 15 July 2009 6:10 AM > > > >> To: 'Elwell, John'; 'James M. Polk'; sipcore@ietf.org > > > >> Subject: Re: [sipcore] Confusion over target inSIP location- > > > conveyance > > > >> - andimpact on ECRIT phonebcp > > > >> > > > >> I have raised this very issue with James, and verified > > it with Jon > > > >> Peterson > > > >> and Robert Sparks, and the intention is that the > > Geolocation header > > > can > > > >> carry the location of any target, the specific target being that > > > >> identified > > > >> in the PIDF, and subject to the privacy requirements of > > that target. > > > >> > > > >> It turns out to be useful to do this in a couple of > > cases I've run > > > >> across, > > > >> although I'm somewhat surprised that everyone agreed it > > is okay to > > > do > > > >> so. > > > >> > > > >> While I guess I could improve phonebcp by making an explicit > > > statement > > > >> that, > > > >> when sent to the PSAP, the location in the header must be that of > > > the > > > >> caller, I do think it's clear enough that it is. > > > >> > > > >> I'll do that in the next rev, although I don't want to hold up > > > sending > > > >> the > > > >> current version to the IESG over that tidbit. > > > >> > > > >> Brian > > > >> > > > >> > > > >>> -----Original Message----- > > > >>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > >>> Sent: Tuesday, July 14, 2009 2:40 AM > > > >>> To: James M. Polk; sipcore@ietf.org; Brian Rosen > > > >>> Subject: Confusion over target inSIP location-conveyance - and > > > impact > > > >>> on ECRIT phonebcp > > > >>> > > > >>> In 4.2 it states: > > > >>> "The UAC can use whatever means it knows of to > > verify/refresh its > > > >>> location information before attempting a new request that > > > includes > > > >>> location." > > > >>> "its location information" suggests that the UAC is the target. > > > >>> > > > >>> In 4.3.3 it states: > > > >>> "This document gives no guidance how this is accomplished, given > > > the > > > >>> number of ways a UAC can learn its location" > > > >>> which suggests similar. > > > >>> > > > >>> Similarly in 6.1: > > > >>> "If a UAC does not learn and store its location locally (a GPS > > > chip) > > > >>> or from the network (DHCP or LLDP-MED), the UAC MAY learn its > > > LbyR > > > >>> URI (from DHCP for example)." > > > >>> Which suggests that a UAC inserts its location, not some other > > > >>> location. > > > >>> > > > >>> And later in 6.1: > > > >>> "If a UAC has already conveyed location in the original > > request of > > > a > > > >>> transaction, and wants to update its location > > information ..." > > > >>> > > > >>> In 6.2: > > > >>> "If the LbyR URI is > > > >>> sip:, sips: or pres:, and the UAS wants to learn the UAC's > > > >>> location," > > > >>> > > > >>> In 6.2.1: > > > >>> "This > > > >>> means the SIP server is including its version of > > where it thinks > > > >>> > > > >> the > > > >> > > > >>> UAC is, geographically." > > > >>> > > > >>> In 8: > > > >>> "Conveyance of physical location of a UAC raises > > privacy concerns" > > > >>> > > > >>> and: > > > >>> "In cases where a session set-up is > > > >>> retargeted based on the location of the UAC > > initiating the call > > > or > > > >>> SIP MESSAGE," > > > >>> > > > >>> All these many examples illustrate an implication that > > the location > > > >>> target is the UAC. I am sure there are other places too. > > > >>> > > > >>> I found a couple of places that contradict this. In 6.2 > > it states: > > > >>> "If there > > > >>> is more than one PIDF-LO with different Target > > identifiers, then > > > >>> the UAC is merely telling the UAS where more than > > one Target is, > > > >>> > > > >> and > > > >> > > > >>> there should not be any conflict." > > > >>> > > > >>> I think there are other places that mention locations > > of multiple > > > >>> targets in a request, implying they cannot all be the > > location of > > > the > > > >>> UAC. > > > >>> > > > >>> And in 6.2.1 it states: > > > >>> "The Location Target identified in > > > >>> the PIDF-LO may or may not be the location inserter, or the > > > >>> generator of the request (the UAC or SIP server)." > > > >>> > > > >>> So we have inconsistency as to whether a conveyed > > location is that > > > of > > > >>> they UAC or not. > > > >>> > > > >>> One document that relies on location-conveyance is ECRIT's > > > phonebcp. > > > >>> > > > >> In > > > >> > > > >>> there, I cannot find any reference to a routing entity > > looking to > > > see > > > >>> whether a conveyed location has the caller as target or not. It > > > just > > > >>> assumes that this is the case. So if we were to agree that a > > > conveyed > > > >>> location is not necessarily the location of the UAC, > > this will have > > > >>> impact on phonebcp. > > > >>> > > > >>> John > > > >>> > > > >> _______________________________________________ > > > >> sipcore mailing list > > > >> sipcore@ietf.org > > > >> https://www.ietf.org/mailman/listinfo/sipcore > > > >> > > > > > > > > > > --------------------------------------------------------------------- > > > --------------------------- > > > > This message is for the designated recipient only and may > > > > contain privileged, proprietary, or otherwise private information. > > > > If you have received it in error, please notify the sender > > > > immediately and delete the original. Any unauthorized use of > > > > this email is prohibited. > > > > > > --------------------------------------------------------------------- > > > --------------------------- > > > > [mf2] > > > > _______________________________________________ > > > > sipcore mailing list > > > > sipcore@ietf.org > > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > > > -------------------------------------------------------------- > > ---------------------------------- > > This message is for the designated recipient only and may > > contain privileged, proprietary, or otherwise private information. > > If you have received it in error, please notify the sender > > immediately and delete the original. Any unauthorized use of > > this email is prohibited. > > -------------------------------------------------------------- > > ---------------------------------- > > [mf2] > > From AUDET@nortel.com Wed Jul 15 14:55:39 2009 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 24C343A6927 for ; Wed, 15 Jul 2009 14:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.455 X-Spam-Level: X-Spam-Status: No, score=-6.455 tagged_above=-999 required=5 tests=[AWL=0.144, 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 wOlr35XwquJ6 for ; Wed, 15 Jul 2009 14:55:38 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id F21C83A6C7B for ; Wed, 15 Jul 2009 14:55:37 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6FLX8F24928; Wed, 15 Jul 2009 21:33:08 GMT 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, 15 Jul 2009 16:33:05 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFE154F@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EFE1215@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: Do we need rt / mp / rc / cc thread-index: AcoEDqM/XIENvO+JQM+deNhoIRK3fQAAKw3QAAbzRkAAHH9xoAAt/EuAAAksXYAABluQoA== References: <4A5B7195.6020009@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com><4A5BBE0C.5000301@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EFA0F7C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EFE0860@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFE1215@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "SIPCORE" Cc: Hans Erik van Elburg , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: Do we need rt / mp / rc / cc 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, 15 Jul 2009 21:55:39 -0000 Mary, Hans and I have consulsted, and we have the following position on this topic: 1) We need the separate "aor" flag=20 2) We need the "mp" flag 3) We have no particular preference on the "fluff" versus "cc / rc / rt" = issue Others? From HKaplan@acmepacket.com Wed Jul 15 14:56:35 2009 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 D71623A691F for ; Wed, 15 Jul 2009 14:56:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.577 X-Spam-Level: X-Spam-Status: No, score=-2.577 tagged_above=-999 required=5 tests=[AWL=0.022, 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 4nx7vMKHI9xU for ; Wed, 15 Jul 2009 14:56:35 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 0E1513A68D2 for ; Wed, 15 Jul 2009 14:56:35 -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.1.375.2; Wed, 15 Jul 2009 17:55:52 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 15 Jul 2009 17:55:53 -0400 From: Hadriel Kaplan To: Francois Audet , SIPCORE Date: Wed, 15 Jul 2009 17:55:52 -0400 Thread-Topic: [sipcore] rfc4244bis: Do we need rt / mp / rc / cc Thread-Index: AcoEDqM/XIENvO+JQM+deNhoIRK3fQAAKw3QAAbzRkAAHH9xoAAt/EuAAAksXYAABluQoAAAtOew Message-ID: References: <4A5B7195.6020009@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com><4A5BBE0C.5000301@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EFA0F7C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EFE0860@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFE1215@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFE154F@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EFE154F@zrc2hxm0.corp.nortel.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: Hans Erik van Elburg Subject: Re: [sipcore] rfc4244bis: Do we need rt / mp / rc / cc 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, 15 Jul 2009 21:56:35 -0000 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Wednesday, July 15, 2009 5:33 PM >=20 > Mary, Hans and I have consulsted, and we have > the following position on this topic: >=20 > 1) We need the separate "aor" flag Yup. > 2) We need the "mp" flag Probably. > 3) We have no particular preference on the "fluff" versus "cc / rc / rt" > issue Dunno yet. I think if it's clearly spelled out as ONLY useful for manual/h= uman troubleshooting purposes (like a Response's reason-phrase), then it'd = be safer. -hadriel From AUDET@nortel.com Wed Jul 15 14:57:49 2009 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 6B9193A6F4C for ; Wed, 15 Jul 2009 14:57:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.456 X-Spam-Level: X-Spam-Status: No, score=-6.456 tagged_above=-999 required=5 tests=[AWL=0.143, 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 GNYkAHs9qgrF for ; Wed, 15 Jul 2009 14:57:48 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 493623A68D2 for ; Wed, 15 Jul 2009 14:57:48 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6FLt0F14343; Wed, 15 Jul 2009 21:55:00 GMT 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, 15 Jul 2009 16:56:36 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoFRoWh2hBP5wjyQIWzHzootDGkMgASGu2gAAAGFAAAAfQZ4A== References: From: "Francois Audet" To: "Hadriel Kaplan" , "SIPCORE" Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 15 Jul 2009 21:57:49 -0000 Well, sort of. But I can't think of cases where the tag "aor" would not be applied to somthing that is not an AOR. It is certainly true that not all AORs will be tagged. In my mind, the tag meant "I recorgnize this as being the AOR I'm responsible for, and that I'm using for the database dip". > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Hadriel Kaplan > Sent: Wednesday, July 15, 2009 14:47 > To: SIPCORE > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >=20 >=20 >=20 > > -----Original Message----- > > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > Sent: Wednesday, July 15, 2009 8:19 AM > >=20 > > How does it matter whether there are multiple translation=20 > steps in a=20 > > domain? > > What matters that if I sent something to:=A0 > sip:81234@example.net=A0that=20 > > it will be delivered to the intended party. In this sense=20 > this is an=20 > > AOR. I could put this on my business card for example. >=20 > I think part of the confusion (at least for me) is using the=20 > term "AoR" and a tag named "aor". It's just not the=20 > cut-and-dried what is or is not an AoR, imho. The rules by=20 > which systems change one URI to another URI can easily be=20 > viewed/described as performing a location-service lookup. =20 > Just because a system implements those rules in a regex=20 > replacement, route tables, ENUM lookup, HSS lookup, or=20 > whatever, doesn't matter - they don't know when the URI=20 > they've changed it from was an AoR or not. =20 >=20 > I think what you guys are saying is "it doesn't matter" - all=20 > that matters is that a URI of a domain for which the proxy is=20 > responsible, which is used by that proxy for a=20 > location-service lookup, actually be tagged with "aor". It's=20 > ok if that tags things which aren't "AoR's" in the classic=20 > sense, and thus more H-I entries are tagged than are really=20 > needed, because the UAS will ignore them. Is that right? >=20 > -hadriel > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From AUDET@nortel.com Wed Jul 15 14:58:04 2009 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 9E18B3A6F55 for ; Wed, 15 Jul 2009 14:58:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.458 X-Spam-Level: X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 PPKJsa5v+YJL for ; Wed, 15 Jul 2009 14:58:03 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 9D1463A68D2 for ; Wed, 15 Jul 2009 14:58:03 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6FLu5F14408; Wed, 15 Jul 2009 21:56:05 GMT 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, 15 Jul 2009 16:57:13 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F04FAF2@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: Do we need rt / mp / rc / cc thread-index: AcoEDqM/XIENvO+JQM+deNhoIRK3fQAAKw3QAAbzRkAAHH9xoAAt/EuAAAksXYAABluQoAAAtOewAABKynA= References: <4A5B7195.6020009@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF51A47@zrc2hxm0.corp.nortel.com><4A5BBE0C.5000301@softarmor.com><1ECE0EB50388174790F9694F77522CCF1EF52230@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EFA0F7C@zrc2hxm0.corp.nortel.com><1ECE0EB50388174790F9694F77522CCF1EFE0860@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFE1215@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EFE154F@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Hadriel Kaplan" , "SIPCORE" Cc: Hans Erik van Elburg Subject: Re: [sipcore] rfc4244bis: Do we need rt / mp / rc / cc 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, 15 Jul 2009 21:58:04 -0000 All right! Looks like are on same wavelength!=20 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Wednesday, July 15, 2009 14:56 > To: Audet, Francois (SC100:3055); SIPCORE > Cc: Barnes, Mary (RICH2:AR00); Barnes, Mary (RICH2:AR00);=20 > Hans Erik van Elburg; Christer Holmberg > Subject: RE: [sipcore] rfc4244bis: Do we need rt / mp / rc / cc >=20 >=20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Wednesday, July 15, 2009 5:33 PM > >=20 > > Mary, Hans and I have consulsted, and we have the following=20 > position=20 > > on this topic: > >=20 > > 1) We need the separate "aor" flag >=20 > Yup. >=20 > > 2) We need the "mp" flag >=20 > Probably. >=20 > > 3) We have no particular preference on the "fluff" versus=20 > "cc / rc / rt" > > issue >=20 > Dunno yet. I think if it's clearly spelled out as ONLY=20 > useful for manual/human troubleshooting purposes (like a=20 > Response's reason-phrase), then it'd be safer. >=20 > -hadriel >=20 From jmpolk@cisco.com Wed Jul 15 14:58:09 2009 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 2747B3A6F60 for ; Wed, 15 Jul 2009 14:58:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.342 X-Spam-Level: X-Spam-Status: No, score=-6.342 tagged_above=-999 required=5 tests=[AWL=0.257, 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 XDjWygpiS0fP for ; Wed, 15 Jul 2009 14:58:07 -0700 (PDT) Received: from sj-iport-3.cisco.com (sj-iport-3.cisco.com [171.71.176.72]) by core3.amsl.com (Postfix) with ESMTP id D6B403A68D2 for ; Wed, 15 Jul 2009 14:58:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMNAK3rXUqrR7O6/2dsb2JhbAAwiBOwaYgjLAiQYAWCJwwBEgiBOw X-IronPort-AV: E=Sophos;i="4.42,406,1243814400"; d="scan'208";a="177221369" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-3.cisco.com with ESMTP; 15 Jul 2009 21:51:45 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6FLpjon008954; Wed, 15 Jul 2009 14:51:45 -0700 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6FLpimG002927; Wed, 15 Jul 2009 21:51:45 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 14:51:45 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.4.19]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 14:51:44 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 15 Jul 2009 16:51:43 -0500 To: "Thomson, Martin" , "Elwell, John" , "Jon Peterson" From: "James M. Polk" In-Reply-To: References: <0D5F89FAC29E2C41B98A6A762007F5D00221E129@GBNTHT12009MSX.gb002.siemens.net> <020001ca04bf$21910fe0$64b32fa0$@net> <4A5D64E4.4020008@neustar.biz> <0D5F89FAC29E2C41B98A6A762007F5D002264E85@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 15 Jul 2009 21:51:44.0572 (UTC) FILETIME=[71C91FC0:01CA0596] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5908; t=1247694705; x=1248558705; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[sipcore]=20Confusion=20over=20target=2 0inSIP=20location-conveyance=0A=20=20-andimpact=20on=20ECRIT =20phonebcp |Sender:=20; bh=GVRQg7V5PlByfLjGpgW76FSN+fiUyVVX5sYQS7gEwMg=; b=WUvOVZMrq3LMpiRqMzyNaOsyBP9jtFmcWEb2jQTpWLahG/3NshlSzQXxeo 8si2xOzd0HdGMOkI+FNXRZy/Xn7fztlc63q+NUowTZFQvhONHmXnyLfkxGjy AtqjDDUVBj; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: sipcore@ietf.org Subject: Re: [sipcore] Confusion over target inSIP location-conveyance -andimpact on ECRIT phonebcp 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, 15 Jul 2009 21:58:09 -0000 2 & 3 fly in the face of existing requirements from existing and relevant RFCs within Geopriv.' 1 already covered, and can be made more explicit with very minor additions. James At 01:38 AM 7/15/2009, Thomson, Martin wrote: >That's a good characterisation of the choice. I'll note that the >cleanup from 1 also applies to 2. > >As I stated, as I don't think that 1 is feasible for the >aforementioned reasons. Either of 2 or 3 are workable. > >--Martin > > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > Sent: Wednesday, 15 July 2009 4:20 PM > > To: Thomson, Martin; Jon Peterson > > Cc: Brian Rosen; James M. Polk; sipcore@ietf.org > > Subject: RE: [sipcore] Confusion over target inSIP location-conveyance > > -andimpact on ECRIT phonebcp > > > > So this is where we stand, from my point of view. We can pursue one of > > several directions: > > > > 1) We decide that the identifier in the PIDF document is sufficient to > > identify the target and, where it is important that the target be the > > SIP requester (e.g., for SIP request routing), that this can easily be > > determined by comparing the SIP From or PAI with the PIDF target > > identifier. In this case, we would at least need to change the many > > places in location-conveyance that imply that the location target is > > the > > UAC. We would also need to add something to phonebcp (at its next > > update) to point this out. > > > > 2) We decide that we need something explicit at the SIP level, such as > > the ";me" parameter to the Geolocation header field that Martin > > suggested, that says that the location target is indeed the UAC. > > > > 3) We decide that the location target MUST be the UAC. Brian tells me > > there are use cases where greater flexibility would be desirable, > > however (I don't know what these are). > > > > John > > > > > > > -----Original Message----- > > > From: Thomson, Martin [mailto:Martin.Thomson@andrew.com] > > > Sent: 15 July 2009 06:28 > > > To: Jon Peterson > > > Cc: Brian Rosen; Elwell, John; James M. Polk; sipcore@ietf.org > > > Subject: RE: [sipcore] Confusion over target inSIP > > > location-conveyance - andimpact on ECRIT phonebcp > > > > > > Hi Jon, > > > > > > Here's the problem: > > > I am sip:mt@andrew.com. I use HELD or DHCP to request a > > > location URI. This is what is put in my SIP INVITE. A proxy > > > dereferences this to determine where to route the call. They > > > encounter pres:v76ns38907v6e05@lis.example.com in the > > > resulting PIDF-LO. The location information is ignored; it's > > > not applicable to the requester. > > > > > > The server that provides the location information has no > > > basis to determine that the entity making a request and > > > sip:mt@andrew.com are one and the same. Thus, it cannot make > > > this assertion. HELD recommends the creation of a pseudonym > > > for this reason. > > > > > > How do we resolve this? > > > > > > We could define a mechanism for asserting sip identity in > > > other domains, such that HELD could use it. Sounds a bit > > > heavyweight to me. > > > > > > Providing a linkage between the two in SIP might work, but it > > > sounds like you don't want to do that. Shame, because that's > > > the easiest. One simple way would be to add a ';me' > > > parameter to the geolocation header, which links the UAC > > > (identified in From:) to the location object, irrespective of > > > the identified presentity. > > > > > > --Martin > > > > > > p.s. On a similar thread, I think I remember reading that > > > sip:mt@andrew.com is the same as pres:mt@andrew.com. Is this > > > guaranteed truth, or just highly likely? > > > > > > > -----Original Message----- > > > > From: Jon Peterson [mailto:jon.peterson@neustar.biz] > > > > Sent: Wednesday, 15 July 2009 3:11 PM > > > > To: Thomson, Martin > > > > Cc: Brian Rosen; Elwell, John; James M. Polk; sipcore@ietf.org > > > > Subject: Re: [sipcore] Confusion over target inSIP > > > location-conveyance > > > > - andimpact on ECRIT phonebcp > > > > > > > > > > > > There must be something I'm missing in this discussion, but > > > I've found > > > > this issue with identity binding a bit elusive. PIDF documents (let > > > > alone PIDF-LO documents) necessarily contain a field designating > > the > > > > entity that the document is supposed to represent - the "entity" > > > > attribute of . Given that this attribute contains > > > a URI, it > > > > can be as specific or opaque as is necessary for the application in > > > > question. It appears regardless of how the PIDF document is > > acquired > > > > (by > > > > reference or by value). In what way is this element insufficient > > > > exactly? > > > > > > > > I would certainly be skeptical of any SIP-layer mechanism that is > > > > intended to provide a separate account of how a PIDF document is > > > > "bound" > > > > to the entity it represents. > > > > > > > > Jon Peterson > > > > NeuStar, Inc. > > > > > > > > Thomson, Martin wrote: > > > > > I still haven't seen an explanation on how to resolve the > > identity > > > > binding problem when location is provided by reference. > > > That's a small > > > > thing for phone-bcp, but not for location-conveyance. > > > > > > > > > > >... > >------------------------------------------------------------------------------------------------ >This message is for the designated recipient only and may >contain privileged, proprietary, or otherwise private information. >If you have received it in error, please notify the sender >immediately and delete the original. Any unauthorized use of >this email is prohibited. >------------------------------------------------------------------------------------------------ >[mf2] From AUDET@nortel.com Wed Jul 15 15:04:48 2009 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 8534E3A6B08 for ; Wed, 15 Jul 2009 15:04:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.159 X-Spam-Level: X-Spam-Status: No, score=-6.159 tagged_above=-999 required=5 tests=[AWL=-0.161, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_47=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 oEspHso+o5Ij for ; Wed, 15 Jul 2009 15:04:46 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id B06D93A6F4A for ; Wed, 15 Jul 2009 15:04:41 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6FL06F08357; Wed, 15 Jul 2009 21:00:06 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA058F.6966FF82" Date: Wed, 15 Jul 2009 16:01:22 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1EFE1463@zrc2hxm0.corp.nortel.com> In-Reply-To: <9ae56b1e0907150809r70e2dc2fo64a78be54e2c5c7c@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoFXj29EmhneEZDSBaxQgJnrUms/AAMKGTw References: <1ECE0EB50388174790F9694F77522CCF1EF5190A@zrc2hxm0.corp.nortel.com> <4A5B71AC.6050502@cisco.com> <1ECE0EB50388174790F9694F77522CCF1EF51BFE@zrc2hxm0.corp.nortel.com> <4A5C8B0D.6010107@cisco.com> <9ae56b1e0907150519je7cab97x6c1324a302df1a92@mail.gmail.com> <4A5DE3BD.2050306@cisco.com> <9ae56b1e0907150809r70e2dc2fo64a78be54e2c5c7c@mail.gmail.com> From: "Francois Audet" To: "Hans Erik van Elburg" , "Paul Kyzivat" Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 15 Jul 2009 22:04:48 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA058F.6966FF82 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If 81234@example.net is globablly routable, sure, it can be an AOR. And = YES the proxy example.net could flag it as such. =20 In this case, you'd get History-Info: ;index=3D1;aor;rt, = = ;user=3Dphone>;aor;rt, etc. =20 But if it's not because 81234@example.net is NOT an alias for = sip:+12125551234@example.net = ;user=3Dphone, then it's not an AOR. ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Wednesday, July 15, 2009 08:09 To: Paul Kyzivat Cc: Audet, Francois (SC100:3055); Hadriel Kaplan; SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? =09 =09 (sip:81234@example.net --> = (example.net proxy instance 1) --> sip:+12125551234@example.net = ;user=3Dphone (example.net = proxy instance 2) --> contact) Ok, your point is whether a number belonging to a private number plan = is also an AOR right? Then the question is if the proxy-instance-1 that translates this to a = globally routable URI should tag this as an aor. I think it does not = really matter in this case whether it tags the entry or not. What is = important is that proxy-instance-2 that receives the request targeted at = the domain that it is responsible for tags the entry as aor.=20 But I still think that it would not do any harm if the proxy instance 1 = would mark the entry with aor, allthough this might be counterintuitive = in some very peculiar cases. /Hans Erik van Elburg On Wed, Jul 15, 2009 at 4:12 PM, Paul Kyzivat = wrote: =09 Inline. =09 [Note that somewhere along the way my original examples got mangled by = something that expanded url-looking things into links. I've = whacked those out where I have caught them.]=20 Hans Erik van Elburg wrote: =09 On Tue, Jul 14, 2009 at 3:41 PM, Paul Kyzivat > wrote: =09 Francois, =09 Maybe we can puzzle this out by examining more use cases. You focused on digit manipulation, which is surely one. But there are others. =09 To spell out the digit manipulation case in more detail: =09 A proxy receives a request with sip R-URI in the domain it is responsible for. It sees that the user part is all digits. (E.g sip:81234@example.net ) It then applies some sort of digit map it has been provisioned with (possibly per-caller, possibly per-domain) to transform that into some other more globally unique URI - perhaps an E.164 number in = its own domain or some other domain, or a TEL URI. (E.g. sip:+12125551234@example.net = ;user=3Dphone.) It does the translation and then proceeds based on the result. I agree in this case it is wrong to call the incoming R-URI an AOR. =09 =09 What property does this not make an AOR? How does it matter whether there are multiple translation steps in a = domain? What matters that if I sent something to: sip:81234@example.net = that it will be delivered to the = intended party. In this sense this is an AOR. I could put this on my = business card for example. =09 Its really questionable whether you could put this on your business = card or not. It depends on the mechanics of the translation. =09 For instance, a large company with many branches may have dial plans = that allow short digit strings for numbers in the branch, longer digit = strings for numbers at other branches, and even longer, or at least = different, dial strings for e.164 numbers. =09 In particular, the short, branch-specific, dial strings are ambiguous = within the domain of the enterprise. They can be rendered unambiguous in = multiple ways: - they can be put into a uri with a branch-specific (or dial plan specific) domain name. - they can be encoded with a phone-context that indicates the branch or dial plan - they can be put into a uri with a company-wide domain name, which then is ambiguous. The proxy can then resolve the ambiguity based on the source of the request. =09 The first two cases could potentially be considered AoRs, but the = latter one cannot not. Even the first two may not be valid on business = cards if the company chooses not to recognize such addresses from = outside its domain.=20 A different case is synonyms or aliases: =09 A proxy responsible for example.net receives a request with R-URI sip:phk@example.net = =20 This is not in its location service. But it has a provisioned alias table that says phk is a synonym = for paul.kyzivat, so it translates the R-URI to sip:paul.kyzivat@example.net = . It then proceeds to process that, which turns out to be in its location service, so it translates it again to sip:line1@phone1.paulk.example.net = . Again, I don't think sip:phk@example.net = is an AoR in this case.=20 I do think this is an AOR allright. The alias mapping can well be = performed by an abstract-location-service. =09 That is part of my issue. The proxy may use a location service as part = of its processing, but can perform other logic as well. And the location = service can be updated by REGISTER, but can also have entries come/go in = other ways. =09 So, is something an AoR because the proxy gets the translation from = the location service? Or is it because the translation it performs = *could* have come from a location service? Or is it because the proxy = has a policy that says "this URI in my domain is an AoR".=20 What property does this not make an AOR? How does it matter whether there are multiple translation steps in a = domain? What matters that if I sent something to: sip:phk@example.net = that it will be delivered to the = intended party. In this sense this is an AOR. You could put this on your = business card for example. =09 I agree it *could* be an AoR. But I don't know that it MUST be an AoR. =09 =09 Another case, for forwarding: =09 A proxy responsible for example.net receives = a=20 request with R-URI of sip:paul.kyzivat@example.net = . There is a location service with an entry registered for sip:line1@phone1.paulk.example.net = , but there is also provisioning independent of the location service that says to unconditionally forward all calls to this URI to sip:audet@nortel.com . This is accomplished by R-URI translation. (To ensure that the request = will not be rejected as mis-addressed.) =09 In this case I think that sip:paul.kyzivat@example.net = =20 *is* an AoR.=20 Yes. And one final forwarding case: =09 =09 A proxy responsible for example.net receives = a=20 request with R-URI of sip:alice.smith@example.net = . Alice used to work for Example Co, but she no longer does, so her URI is "out of = service". But the proxy has been provisioned to translate the R-URI of = Alice's calls to her old boss' URI: sip:betty.jones@example.net = . There will never be an entry in the location service for alice, registrations are not = permitted. =09 In this case, in spite of there being no location service = involved, I still think sip:alice.smith@example.net = is an AoR. =09 Yes, the abstract-location-service returns the address of betty. But = this IS really a border case that makes me wonder. =09 So, IMO the bottom line is that whether a URI is an AoR is a = policy decision within the domain of the URI. =09 It is unclear to me what definition of AOR you are using. =09 I am taking at face value that AoR (Address of *Record*) is based on a = *record* of the domain, which almost by definition is a matter of = policy. =09 And I am pointing out that we don't have a definition of AoR that both = useful operationally and that meets every day expectations.=20 Thanks, Paul =09 =09 =09 Francois Audet wrote: =09 =20 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com ] Sent: Monday, July 13, 2009 = 10:41 To: Audet, Francois (SC100:3055) Cc: Hadriel Kaplan; Hans Erik van Elburg; SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? =09 =09 =09 Francois Audet wrote: =09 To me it's crystal clear. =09 If you are the entity (proxy or redirect server) =09 responsible for the =09 URI, and you find the entry in your location service, = you =09 mark as AOR. =09 That means you will now route based on "rules" you = have internally, e.g., map it to a contact, etc. =09 I think some cases are clear, others not so much: =09 - If the proxy translates to a contact that it got from a location service and that entry was placed there by a REGISTER, then the entry should definitely be marked as an AoR =09 =09 Agree. =09 - If the proxy translates to a contact that it got from a ocation service, and that entry got there somehow other than REGISTER, then I *think* the entry should still be marked as an = AoR. =09 =09 Yes, agree. =09 - If the proxy uses some other logic than a "location = service" to translate the URI, but it might in other cases use = the location service to translate the URI, then I'm not = sure. =09 - If the proxy never uses a location service for this URI, but translates it on some other basis, then again I'm = not sure. =09 One problem here is that the location service is abstract. There are things that can be done using it, or in another manner. It seems to me that if it *could* have been done with a location service lookup, then the result ought to = be the same whether it is or not. =09 =09 I think the last two are the same thing. Things like digit manipulation and so forth. =09 I didn't want to alter (or second-guess) the definition of AOR (which is the realm of RFC 3261), in this draft. =09 I would think that if the proxy doesn't know that it's an AOR, then it shouldn't mark it as such. So I would expect mechanical digit manipulation to NOT be marked as AOR. =09 =09 =09 =09 ------_=_NextPart_001_01CA058F.6966FF82 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
If 81234@example.net is globablly = routable,=20 sure, it can be an AOR. And YES the proxy example.net could flag it as=20 such.
 
In=20 this case, you'd get
History-Info: <sip:81224@example.com>;index=3D1;aor;rt, = <sip:+12125551234@example.net;user=3Dphone>;aor;rt, = etc.
 

But if it's not because 81234@example.net is NOT an alias = for sip:+12125551234@example.net;user=3Dphone, then it's not an=20 AOR.

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: Wednesday, July 15, = 2009=20 08:09
To: Paul Kyzivat
Cc: Audet, Francois = (SC100:3055);=20 Hadriel Kaplan; SIPCORE
Subject: Re: [sipcore] rfc4244bis: = what is=20 an AoR?

(sip:81234@example.net=20 --> (example.net proxy instance = 1) -->=20 sip:+12125551234@example= .net;user=3Dphone=20 (example.net proxy instance 2) = -->=20 contact)

Ok, your point is whether a number belonging to a private number = plan is=20 also an AOR right?

Then the question is if the proxy-instance-1 that translates this = to a=20 globally routable URI should tag this as an aor. I think it does not = really=20 matter in this case whether it tags the entry or not. What is = important is=20 that proxy-instance-2 that receives the request targeted at the domain = that it=20 is responsible for tags the entry as aor. 

But I still think that it would not do any harm if the proxy = instance 1=20 would mark the entry with aor, allthough this might be = counterintuitive in=20 some very peculiar cases.

/Hans Erik van Elburg


On Wed, Jul 15, 2009 at 4:12 PM, Paul Kyzivat = <pkyzivat@cisco.com> = wrote:
Inline.

[Note=20 that somewhere along the way my original examples got mangled by = something=20 that expanded url-looking things into <mailto...> links. I've = whacked=20 those out where I have caught them.]


Hans Erik van Elburg wrote:


On=20 Tue, Jul 14, 2009 at 3:41 PM, Paul Kyzivat <pkyzivat@cisco.com=20 <mailto:pkyzivat@cisco.com>> = wrote:

 =20  Francois,

   Maybe we can puzzle this out = by=20 examining more use cases.
   You focused on digit=20 manipulation, which is surely one. But there
   are=20 others.

   To spell out the digit manipulation = case in=20 more detail:

   A proxy receives a request with = sip R-URI=20 in the domain it is
   responsible for. It sees that = the user=20 part is all digits. (E.g
   sip:81234@example.net) It then
  =  applies=20 some sort of digit map it has been provisioned with
 =20  (possibly per-caller, possibly per-domain) to transform that = into
   some other more globally unique URI - perhaps = an=20 E.164 number in its
   own domain or some other = domain, or a=20 TEL URI. (E.g.
   sip:+12125551234@example.net;user=3Dphone.) It = does=20 the
   translation and then proceeds based on the = result. I=20 agree in this
   case it is wrong to call the = incoming R-URI=20 an AOR.


What property does this not make an AOR?
How = does it=20 matter whether there are multiple translation steps in a = domain?
What=20 matters that if I sent something to: sip:81234@example.net that it will be = delivered to the=20 intended party. In this sense this is an AOR. I could put this on = my=20 business card for example.

Its really = questionable=20 whether you could put this on your business card or not. It depends = on the=20 mechanics of the translation.

For instance, a large company = with many=20 branches may have dial plans that allow short digit strings for = numbers in=20 the branch, longer digit strings for numbers at other branches, and = even=20 longer, or at least different, dial strings for e.164 = numbers.

In=20 particular, the short, branch-specific, dial strings are ambiguous = within=20 the domain of the enterprise. They can be rendered unambiguous in = multiple=20 ways:
- they can be put into a uri with a branch-specific (or = dial=20 plan
 specific) domain name.
- they can be encoded with a = phone-context that indicates the branch
 or dial plan
- = they can=20 be put into a uri with a company-wide domain name, = which
 then is=20 ambiguous. The proxy can then resolve the ambiguity = based
 on the=20 source of the request.

The first two cases could potentially = be=20 considered AoRs, but the latter one cannot not. Even the first two = may not=20 be valid on business cards if the company chooses not to recognize = such=20 addresses from outside its domain.


 =20  A different case is synonyms or aliases:

  =  A proxy=20 responsible for example.net=20 receives a
   request with R-URI sip:phk@example.net
   This is = not in its=20 location service.
   But it has a provisioned alias = table=20 that says phk is a synonym for
   paul.kyzivat, so it = translates the R-URI to
   sip:paul.kyzivat@example.net. It then proceeds = to=20 process
   that, which turns out to be in its = location=20 service, so it
   translates it again to sip:line1@phone1.paulk.example.net.
 =20  Again, I don't think sip:phk@example.net is an AoR in this case. =
I do=20 think this is an AOR allright. The alias mapping can well be = performed by=20 an abstract-location-service.

That is = part of my=20 issue. The proxy may use a location service as part of its = processing, but=20 can perform other logic as well. And the location service can be = updated by=20 REGISTER, but can also have entries come/go in other = ways.

So, is=20 something an AoR because the proxy gets the translation from the = location=20 service? Or is it because the translation it performs *could* have = come from=20 a location service? Or is it because the proxy has a policy that = says "this=20 URI in my domain is an AoR".


What=20 property does this not make an AOR?
How does it matter whether = there=20 are multiple translation steps in a domain?
What matters that = if I sent=20 something to: sip:phk@example.net that it will be delivered = to the=20 intended party. In this sense this is an AOR. You could put this = on your=20 business card for example.

I agree it = *could* be=20 an AoR. But I don't know that it MUST be an AoR.

 =20  Another case, for forwarding:

   A proxy=20 responsible for example.net=20 <http://example.net>=20 receives a

   request with R-URI of sip:paul.kyzivat@example.net.
  =  There is a=20 location service
   with an entry registered for sip:line1@phone1.paulk.example.net,
  =  but=20 there is also
   provisioning independent of the = location=20 service that says to
   unconditionally forward all = calls to=20 this URI to
   sip:audet@nortel.com. This is
 =20  accomplished by R-URI translation. (To ensure that the = request=20 will
   not be rejected as = mis-addressed.)

 =20  In this case I think that sip:paul.kyzivat@example.net
  =  *is* an=20 AoR.
Yes.
     And one final forwarding=20 case:

   A proxy responsible for example.net <http://example.net>=20 receives a

   request with R-URI of sip:alice.smith@example.net.
  =  Alice used=20 to work for
   Example Co, but she no longer does, so = her URI=20 is "out of service".
   But the proxy has been = provisioned to=20 translate the R-URI of Alice's
   calls to her old = boss' URI:=20 sip:betty.jones@example.net.
  =  There will=20 never be an entry
   in the location service for = alice,=20 registrations are not permitted.

   In this case, = in=20 spite of there being no location service involved,
  =  I still=20 think sip:alice.smith@example.net is an = AoR.

Yes, the=20 abstract-location-service returns the address of betty. But this = IS really=20 a border case that makes me wonder.

   So, IMO = the bottom=20 line is that whether a URI is an AoR is a policy
  =  decision=20 within the domain of the URI.

It is unclear to me what = definition=20 of AOR you are using.

I am taking at = face value=20 that AoR (Address of *Record*) is based on a *record* of the domain, = which=20 almost by definition is a matter of policy.

And I am pointing = out=20 that we don't have a definition of AoR that both useful = operationally and=20 that meets every day expectations.


 =20         Thanks,
        =  =20 Paul



   Francois Audet = wrote:

 =20      
         =20  -----Original Message-----
        =  =20  From: Paul Kyzivat [mailto:pkyzivat@cisco.com
      =    =20  <mailto:pkyzivat@cisco.com>] Sent: Monday, July 13, = 2009=20 10:41
           To: Audet, = Francois=20 (SC100:3055)
           Cc: = Hadriel=20 Kaplan; Hans Erik van Elburg; SIPCORE
      =  =20    Subject: Re: [sipcore] rfc4244bis: what is an=20 AoR?



          =  Francois=20 Audet wrote:

            =  =20  To me it's crystal clear.

        =  =20      If you are the entity (proxy or redirect=20 server)

          =  responsible for=20 the

              =  URI, and=20 you find the entry in your location service, you

  =  =20        mark as AOR.

    =    =20        That means you will now route based on = "rules"=20 you have
             =20  internally, e.g., map it to a contact, etc.

  =  =20        I think some cases are clear, others = not so=20 much:

           - If the = proxy=20 translates to a contact that it got from a
      =  =20      location service and that entry was placed = there by=20 a
           REGISTER,
  =  =20          then the entry should definitely = be=20 marked as an AoR


     =20  Agree.

           - If = the=20 proxy translates to a contact that it got from a
    =  =20        ocation service, and that entry got = there=20 somehow other
           than=20 REGISTER,
             then = I=20 *think* the entry should still be marked as an = AoR.


 =20      Yes, agree.

        =  =20  - If the proxy uses some other logic than a "location=20 service"
             to = translate=20 the URI, but it might in other cases use the
    =  =20        location service to translate the URI, = then I'm=20 not sure.

           - If the = proxy=20 never uses a location service for this URI,
    =    =20      but translates it on some other basis, then = again I'm=20 not
          =  sure.

   =20        One problem here is that the location = service=20 is abstract.
           There are = things=20 that can be done using it, or in another
      =  =20    manner. It seems to me that if it *could* have been=20 done
           with a location = service=20 lookup, then the result ought to be
        =  =20  the same whether it is or not.


    =  =20  I think the last two are the same thing.
    =  =20  Things like digit manipulation and so forth.

  =  =20    I didn't want to alter (or second-guess) the = definition of=20 AOR
       (which is the realm of RFC = 3261), in=20 this draft.

       I would think that = if the=20 proxy doesn't know that it's an AOR,
      =  then it=20 shouldn't mark
       it as such. So I = would expect=20 mechanical digit manipulation to
       NOT = be=20 marked as=20 AOR.




------_=_NextPart_001_01CA058F.6966FF82-- From jmpolk@cisco.com Wed Jul 15 15:15:19 2009 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 1423F3A6F4A for ; Wed, 15 Jul 2009 15:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.345 X-Spam-Level: X-Spam-Status: No, score=-6.345 tagged_above=-999 required=5 tests=[AWL=0.254, 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 lucwJ6WvkJ0U for ; Wed, 15 Jul 2009 15:15:17 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 8C1783A6C7B for ; Wed, 15 Jul 2009 15:15:17 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiMNAIfxXUqrR7O6/2dsb2JhbAAwiBOwZYgjLAiQWgWCJw0KAwUIgTuJZg X-IronPort-AV: E=Sophos;i="4.42,406,1243814400"; d="scan'208";a="186483143" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-2.cisco.com with ESMTP; 15 Jul 2009 22:08:48 +0000 Received: from sj-core-4.cisco.com (sj-core-4.cisco.com [171.68.223.138]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6FM8mAw013915; Wed, 15 Jul 2009 15:08:48 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-4.cisco.com (8.13.8/8.14.3) with ESMTP id n6FM8mI7021885; Wed, 15 Jul 2009 22:08:48 GMT Received: from xfe-sjc-211.amer.cisco.com ([171.70.151.174]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 15:08:47 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.4.19]) by xfe-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 15:08:46 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 15 Jul 2009 17:08:45 -0500 To: Jon Peterson , "Thomson, Martin" From: "James M. Polk" In-Reply-To: <4A5D8B4E.6040501@neustar.biz> References: <0D5F89FAC29E2C41B98A6A762007F5D00221E129@GBNTHT12009MSX.gb002.siemens.net> <020001ca04bf$21910fe0$64b32fa0$@net> <4A5D64E4.4020008@neustar.biz> <4A5D8B4E.6040501@neustar.biz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 15 Jul 2009 22:08:46.0633 (UTC) FILETIME=[D2FB4190:01CA0598] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12544; t=1247695728; x=1248559728; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[sipcore]=20Confusion=20over=20target=2 0inSIP=20location-conveyance=0A=20=20-=09andimpact=20on=20EC RIT=20phonebcp |Sender:=20; bh=SZiRhFYnbJE33Slfn/WvOwKDpMlGfXjetqXi+MvbTQM=; b=kuODKpizktdN/BGDzr7JDoSmU+1hOK+S6XcwkHsQfACJta7ET2LmiWvG0z VI5c4NzUU9z0gCV/o/mhnFRxXJTy9Pm6OcfU5iH2xoYv4SaTeRrw7H+Hpwja N1YbNtQh5q; Authentication-Results: sj-dkim-2; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: sipcore@ietf.org Subject: Re: [sipcore] Confusion over target inSIP location-conveyance - andimpact on ECRIT phonebcp 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, 15 Jul 2009 22:15:19 -0000 I'm concerned that, as Jon says, the UAC might not have knowledge it is sending a SIP request that a proxy somewhere downstream decides it needs that location to use for routing. We have the routing-allowed=no to prevent this from occurring, regardless of the ":me" header parameter. I'm also concerned how a downstream proxy inserter of a target's location will understand if the target doesn't want to be linkable to the presence document? What Conveyance -01 has now: We have the Geolocation-Error code 400 that informs a location inserter that the routing-allowed needs to be 'yes' to properly process this SIP request. We have the Geolocation-Error code 201 that informs a location inserter that the entity= attribute is unlinkable, and needs to be rectified. I didn't add that it ought to match the From header, but I have no issues adding that text. That's easy and would be clean if the WG thinks that's a good way forward. The phoneBCP can articulate their particular use-case better. James At 02:54 AM 7/15/2009, Jon Peterson wrote: >My own interest in this discussion has largely been to prevent the >conflation of the UAC with the geopriv target. I've argued that the >UAC and the entity in the From header field value are not >necessarily equivalent for the purposes of geopriv, thanks to >aggregator UAs serving many users, such as IP PBXs, gateways and so >forth. I've therefore resisted the proposal that the implicit >semantics of the Geolocation header be "this is the location of the >UAC." I feel less strongly about semantics of "this is the location >of the entity in the From header field", be they implicit or >explicit semantics. I can certainly imagine a version of the ";me" >parameter as an explicit indication of these semantics that would >not fall afoul of this conflation. > >I do wonder, though, if the semantics of "routing-allowed" overlap >with the intention behind ";me". Ultimately, a proxy server decides >whether or not it will use the location in the SIP request for >routing purposes. Your use case below assumes that the proxy server >decision to route based on location is dependent on the PIDF >referenced in the SIP request indicating the same target as the SIP >layer identity. While ";me" is helpful in that case, I'm not sure >that this should be the deciding criteria in all cases. >"routing-allowed" communicates a less specific indication of "hey, I >think you can use this to route the request", something that could >be true even if, for whatever reason, the location in the SIP >request doesn't represent the target of my SIP-layer identity, >because due to some unusual circumstances the From header field of >my request can't have a value that represents "me" at the moment - >maybe it's an anonymous URI, for example. > >My point here is that I think agreement on the sorts of policies >that proxy servers should enforce has to inform the sorts of >indications we feed into that policy. If we need a way to tell the >proxy server that a referenced location is appropriate for routing, >we might want something more explicit than ";me". > >To your postscript, I'd have to say no, there's no necessary >equivalence between the resources indicated by those two schemes, >only convention links them. > >Jon Peterson >NeuStar, Inc. > >Thomson, Martin wrote: >>Hi Jon, >> >>Here's the problem: >>I am sip:mt@andrew.com. I use HELD or DHCP to request a location >>URI. This is what is put in my SIP INVITE. A proxy dereferences >>this to determine where to route the call. They encounter >>pres:v76ns38907v6e05@lis.example.com in the resulting PIDF-LO. The >>location information is ignored; it's not applicable to the requester. >> >>The server that provides the location information has no basis to >>determine that the entity making a request and sip:mt@andrew.com >>are one and the same. Thus, it cannot make this assertion. HELD >>recommends the creation of a pseudonym for this reason. >> >>How do we resolve this? >> >>We could define a mechanism for asserting sip identity in other >>domains, such that HELD could use it. Sounds a bit heavyweight to me. >> >>Providing a linkage between the two in SIP might work, but it >>sounds like you don't want to do that. Shame, because that's the >>easiest. One simple way would be to add a ';me' parameter to the >>geolocation header, which links the UAC (identified in From:) to >>the location object, irrespective of the identified presentity. >> >>--Martin >> >>p.s. On a similar thread, I think I remember reading that >>sip:mt@andrew.com is the same as pres:mt@andrew.com. Is this >>guaranteed truth, or just highly likely? >> >> >>>-----Original Message----- >>>From: Jon Peterson [mailto:jon.peterson@neustar.biz] >>>Sent: Wednesday, 15 July 2009 3:11 PM >>>To: Thomson, Martin >>>Cc: Brian Rosen; Elwell, John; James M. Polk; sipcore@ietf.org >>>Subject: Re: [sipcore] Confusion over target inSIP location-conveyance >>>- andimpact on ECRIT phonebcp >>> >>> >>>There must be something I'm missing in this discussion, but I've found >>>this issue with identity binding a bit elusive. PIDF documents (let >>>alone PIDF-LO documents) necessarily contain a field designating the >>>entity that the document is supposed to represent - the "entity" >>>attribute of . Given that this attribute contains a URI, it >>>can be as specific or opaque as is necessary for the application in >>>question. It appears regardless of how the PIDF document is acquired >>>(by >>>reference or by value). In what way is this element insufficient >>>exactly? >>> >>>I would certainly be skeptical of any SIP-layer mechanism that is >>>intended to provide a separate account of how a PIDF document is >>>"bound" >>>to the entity it represents. >>> >>>Jon Peterson >>>NeuStar, Inc. >>> >>>Thomson, Martin wrote: >>> >>>>I still haven't seen an explanation on how to resolve the identity >>>> >>>binding problem when location is provided by reference. That's a small >>>thing for phone-bcp, but not for location-conveyance. >>> >>>> >>>>>-----Original Message----- >>>>>From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>>>>Behalf Of Brian Rosen >>>>>Sent: Wednesday, 15 July 2009 6:10 AM >>>>>To: 'Elwell, John'; 'James M. Polk'; sipcore@ietf.org >>>>>Subject: Re: [sipcore] Confusion over target inSIP location- >>>>> >>>conveyance >>> >>>>>- andimpact on ECRIT phonebcp >>>>> >>>>>I have raised this very issue with James, and verified it with Jon >>>>>Peterson >>>>>and Robert Sparks, and the intention is that the Geolocation header >>>>> >>>can >>> >>>>>carry the location of any target, the specific target being that >>>>>identified >>>>>in the PIDF, and subject to the privacy requirements of that target. >>>>> >>>>>It turns out to be useful to do this in a couple of cases I've run >>>>>across, >>>>>although I'm somewhat surprised that everyone agreed it is okay to >>>>> >>>do >>> >>>>>so. >>>>> >>>>>While I guess I could improve phonebcp by making an explicit >>>>> >>>statement >>> >>>>>that, >>>>>when sent to the PSAP, the location in the header must be that of >>>>> >>>the >>> >>>>>caller, I do think it's clear enough that it is. >>>>> >>>>>I'll do that in the next rev, although I don't want to hold up >>>>> >>>sending >>> >>>>>the >>>>>current version to the IESG over that tidbit. >>>>> >>>>>Brian >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>>Sent: Tuesday, July 14, 2009 2:40 AM >>>>>>To: James M. Polk; sipcore@ietf.org; Brian Rosen >>>>>>Subject: Confusion over target inSIP location-conveyance - and >>>>>> >>>impact >>> >>>>>>on ECRIT phonebcp >>>>>> >>>>>>In 4.2 it states: >>>>>>"The UAC can use whatever means it knows of to verify/refresh its >>>>>> location information before attempting a new request that >>>>>> >>>includes >>> >>>>>> location." >>>>>>"its location information" suggests that the UAC is the target. >>>>>> >>>>>>In 4.3.3 it states: >>>>>>"This document gives no guidance how this is accomplished, given >>>>>> >>>the >>> >>>>>> number of ways a UAC can learn its location" >>>>>>which suggests similar. >>>>>> >>>>>>Similarly in 6.1: >>>>>>"If a UAC does not learn and store its location locally (a GPS >>>>>> >>>chip) >>> >>>>>> or from the network (DHCP or LLDP-MED), the UAC MAY learn its >>>>>> >>>LbyR >>> >>>>>> URI (from DHCP for example)." >>>>>>Which suggests that a UAC inserts its location, not some other >>>>>>location. >>>>>> >>>>>>And later in 6.1: >>>>>>"If a UAC has already conveyed location in the original request of >>>>>> >>>a >>> >>>>>> transaction, and wants to update its location information ..." >>>>>> >>>>>>In 6.2: >>>>>>"If the LbyR URI is >>>>>> sip:, sips: or pres:, and the UAS wants to learn the UAC's >>>>>>location," >>>>>> >>>>>>In 6.2.1: >>>>>>"This >>>>>> means the SIP server is including its version of where it thinks >>>>>> >>>>>> >>>>>the >>>>> >>>>> >>>>>> UAC is, geographically." >>>>>> >>>>>>In 8: >>>>>>"Conveyance of physical location of a UAC raises privacy concerns" >>>>>> >>>>>>and: >>>>>>"In cases where a session set-up is >>>>>> retargeted based on the location of the UAC initiating the call >>>>>> >>>or >>> >>>>>> SIP MESSAGE," >>>>>> >>>>>>All these many examples illustrate an implication that the location >>>>>>target is the UAC. I am sure there are other places too. >>>>>> >>>>>>I found a couple of places that contradict this. In 6.2 it states: >>>>>>"If there >>>>>> is more than one PIDF-LO with different Target identifiers, then >>>>>> the UAC is merely telling the UAS where more than one Target is, >>>>>> >>>>>> >>>>>and >>>>> >>>>> >>>>>> there should not be any conflict." >>>>>> >>>>>>I think there are other places that mention locations of multiple >>>>>>targets in a request, implying they cannot all be the location of >>>>>> >>>the >>> >>>>>>UAC. >>>>>> >>>>>>And in 6.2.1 it states: >>>>>>"The Location Target identified in >>>>>> the PIDF-LO may or may not be the location inserter, or the >>>>>> generator of the request (the UAC or SIP server)." >>>>>> >>>>>>So we have inconsistency as to whether a conveyed location is that >>>>>> >>>of >>> >>>>>>they UAC or not. >>>>>> >>>>>>One document that relies on location-conveyance is ECRIT's >>>>>> >>>phonebcp. >>> >>>>>In >>>>> >>>>> >>>>>>there, I cannot find any reference to a routing entity looking to >>>>>> >>>see >>> >>>>>>whether a conveyed location has the caller as target or not. It >>>>>> >>>just >>> >>>>>>assumes that this is the case. So if we were to agree that a >>>>>> >>>conveyed >>> >>>>>>location is not necessarily the location of the UAC, this will have >>>>>>impact on phonebcp. >>>>>> >>>>>>John >>>>>> >>>>>> >>>>>_______________________________________________ >>>>>sipcore mailing list >>>>>sipcore@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>>>> >>>>--------------------------------------------------------------------- >>>> >>>--------------------------- >>> >>>>This message is for the designated recipient only and may >>>>contain privileged, proprietary, or otherwise private information. >>>>If you have received it in error, please notify the sender >>>>immediately and delete the original. Any unauthorized use of >>>>this email is prohibited. >>>>--------------------------------------------------------------------- >>>> >>>--------------------------- >>> >>>>[mf2] >>>>_______________________________________________ >>>>sipcore mailing list >>>>sipcore@ietf.org >>>>https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> >> >>------------------------------------------------------------------------------------------------ >>This message is for the designated recipient only and may >>contain privileged, proprietary, or otherwise private information. >>If you have received it in error, please notify the sender >>immediately and delete the original. Any unauthorized use of >>this email is prohibited. >>------------------------------------------------------------------------------------------------ >>[mf2] >> From jmpolk@cisco.com Wed Jul 15 15:21:04 2009 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 CF64F3A6C8E for ; Wed, 15 Jul 2009 15:21:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.347 X-Spam-Level: X-Spam-Status: No, score=-6.347 tagged_above=-999 required=5 tests=[AWL=0.252, 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 VIvYE5sagqzh for ; Wed, 15 Jul 2009 15:21:03 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id D7AEE3A69BF for ; Wed, 15 Jul 2009 15:21:03 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AikHAGnzXUqrR7PD/2dsb2JhbACIQ7BTiCORCwWECQ X-IronPort-AV: E=Sophos;i="4.42,406,1243814400"; d="scan'208";a="214564759" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 15 Jul 2009 22:14:15 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6FMEFDM026968; Wed, 15 Jul 2009 15:14:15 -0700 Received: from xbh-sjc-221.amer.cisco.com (xbh-sjc-221.cisco.com [128.107.191.63]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6FMEFtQ029498; Wed, 15 Jul 2009 22:14:15 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 15:14:15 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.4.19]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 15:14:15 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 15 Jul 2009 17:14:14 -0500 To: "Elwell, John" , sipcore@ietf.org From: "James M. Polk" In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D002264FAB@GBNTHT12009MSX.gb 002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D002264FAB@GBNTHT12009MSX.gb002.siemens.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 15 Jul 2009 22:14:15.0235 (UTC) FILETIME=[96D7F130:01CA0599] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1896; t=1247696055; x=1248560055; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20Comments=20on=20location-conveyance-01 |Sender:=20; bh=s5IjMMnejHicR51mDalaOrG1Zl3W6xXFUjozUnrJQNI=; b=FLwHbjd7V+WvypiaL/wdJol8bbnjglt1obx0kagayO4veg7Ins89vQ3W/r BkKOziFD8J18H0jzLga/a3tgZPHz7MSZGsdZHedosK2N2y6pw0ZbY+I0lzU4 3Qyw3RTTKB; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [sipcore] Comments on location-conveyance-01 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, 15 Jul 2009 22:21:04 -0000 At 04:45 AM 7/15/2009, Elwell, John wrote: >James, > >Thanks. This has largely addressed the comments I raised in my review of >00 on 2009-07-02. However, I noticed the following minor points: > >- There is still a reference to LIS in figure 1 / section 3. thanks, I thought I got all of the LIS acronyms out, and will take this one out as well. >- "Location Inserters have the ability to provide instructional > parameters about location it has inserted." >Change "location it has inserted" to "locations they have inserted". got it >- "LbyR refers to a UA > including a location URI in a SIP request header field which can be > dereferenced by a Location Recipient to retrieve Alice's Location > Object, in the form of a PIDF-LO." >I still think this is confusing - it is the URI that is dereferenced, >not the header field. Also, Alice is not mentioned elsewhere in the >paragraph. >I would prefer: >"LbyR refers to a UA including in a SIP request header field a location >URI that can be dereferenced by a Location Recipient to retrieve a >Location Object, in the form of a PIDF-LO." for the most part, I'm eliminated "LbyR" from the doc (as this acronym is confusing to some), except in a few cases where I haven't figured out yet how to same the same thing without using the acronym. This is one of those cases, but I'll work on it, probably based on what you offered above. >- In addition, of course, my concerns in the thread "Confusion over >target..." still exist. I'm taking in all the comments in the last day before circling back and addressing this one - which I plan on doing later today or tomorrow. Briefly, I think each piece of text you copied needs a bit of the surrounding text for context, and are largely (or completely) consistent. My message to follow will talk per quote about that. >John From HKaplan@acmepacket.com Wed Jul 15 15:50:10 2009 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 A391F28C168 for ; Wed, 15 Jul 2009 15:50:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 ThHdBVaNlFUh for ; Wed, 15 Jul 2009 15:50:09 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D1AE628C170 for ; Wed, 15 Jul 2009 15:49:56 -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.1.375.2; Wed, 15 Jul 2009 18:48:01 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 15 Jul 2009 18:47:59 -0400 From: Hadriel Kaplan To: SIPCORE Date: Wed, 15 Jul 2009 18:47:59 -0400 Thread-Topic: rfc4244bis: backwards compatibility Thread-Index: AcoFnk1A+VLjc5mQTgSM2qI5+V4Wlg== 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: "draft-barnes-sipcore-rfc4244bis@tools.ietf.org" Subject: [sipcore] rfc4244bis: backwards compatibility 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, 15 Jul 2009 22:50:10 -0000 And now for a horse of a different color... The section on backwards compatibility states: Proxies conforming to this specification tag the hi-entry parameters with an hi-target parameter. The hi-target and hi-aor parameters did not exist in [RFC4244]; therefore, [RFC4244] implementations do not tag the hi-entry parameters. This tagging allows for distinguishing entries that were added by an [RFC4244] entity, versus one that was added by an entity conforming to this specification. So what is a UAS to do with entries that were created by an RFC4244 device,= and not tagged as "aor" nor "mp"? Does it: 1) Treat them as implicitly tagged with both. 2) Treat them as implicitly tagged with neither. 3) Treat them as implicitly tagged with one or the other. By "treat them" I mean for the purpose of narrowing down the list of entrie= s (i.e., removing fluff), as well as for any application-specific usage of = such entries. Furthermore, since a Proxy modifies a previous H-I entry by adding an "aor"= tag if it treated its URI as a AoR - what does a Proxy which receives a pr= evious H-I entry that does not have any tag do - can/should it still add an= "aor" tag to that entry if it handles it as an AoR? (note that this means= a UAS will receive a H-I entry which does not have a "mp" or any fluff tag= but does have an "aor" tag) -hadriel From pkyzivat@cisco.com Wed Jul 15 16:02:10 2009 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 33B953A6A56 for ; Wed, 15 Jul 2009 16:02:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.354 X-Spam-Level: X-Spam-Status: No, score=-6.354 tagged_above=-999 required=5 tests=[AWL=0.245, 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 yK5Kik0BOwjG for ; Wed, 15 Jul 2009 16:02:09 -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 D0C673A67FB for ; Wed, 15 Jul 2009 16:02:08 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAMf8XUpAZnmf/2dsb2JhbAC4cYgjkREFgj+BTA X-IronPort-AV: E=Sophos;i="4.42,406,1243814400"; d="scan'208";a="50594823" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 15 Jul 2009 22:51:13 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6FMpCBV023971; Wed, 15 Jul 2009 18:51:12 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6FMpCCZ029046; Wed, 15 Jul 2009 22:51:12 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 18:51:12 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 18:51:12 -0400 Message-ID: <4A5E5D5F.80908@cisco.com> Date: Wed, 15 Jul 2009 18:51:11 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Francois Audet References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jul 2009 22:51:12.0419 (UTC) FILETIME=[C0635F30:01CA059E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3446; t=1247698272; x=1248562272; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20rfc4244bis=3A=20what=20is=2 0an=20AoR? |Sender:=20 |To:=20Francois=20Audet=20; bh=J3TFtvaRNwGeJJhRQCV/KBXqwWZ6My3HJmVl9AyXpE0=; b=EV9v8UiPwFEMgv5qLwPWoV7TxQq47inUm49PrQgcnWDyZBCl9yIh/3LS5I nI28lwd5B5rLUJ2qYxhTMnt5Hsmbb3zk6RrpXrT4+rG9CgeK4vfHflP9f8ly kWLU1xYnkc; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 15 Jul 2009 23:02:10 -0000 Francois Audet wrote: > Well, sort of. > > But I can't think of cases where the tag "aor" would not be applied > to somthing that is not an AOR. > > It is certainly true that not all AORs will be tagged. > > In my mind, the tag meant "I recorgnize this as being the > AOR I'm responsible for, and that I'm using for the database dip". I think I agree with Francois, but that definition is circular. I'm saying "its an AOR if somebody from its domain *says* its an AOR." But I don't think thats enough - I've seen too many cases when people are willing to assert things that make no sense. If you just got an address from DHCP, then you had better not assert that some URI containing that is an AOR. I think the meaning of the URI needs to be stable over some reasonably long period of time before it qualifies as an AOR. But the meaning of "meaning" is also a bit squishy there. It doesn't have to represent the same *person* (or call center addresses aren't AORs), and it doesn't have to represent the same device. It just has to represent some stable "role" or "presentity" or something. Nor, IMO, does it have to translate to something else. While it might be unusual, it is *possible* for an AOR to resolve directly to a UAS. And if it does translate to something else, it need not be via a location service, though that is a common way. Thanks, Paul >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Hadriel Kaplan >> Sent: Wednesday, July 15, 2009 14:47 >> To: SIPCORE >> Subject: Re: [sipcore] rfc4244bis: what is an AoR? >> >> >> >>> -----Original Message----- >>> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >>> Sent: Wednesday, July 15, 2009 8:19 AM >>> >>> How does it matter whether there are multiple translation >> steps in a >>> domain? >>> What matters that if I sent something to: >> sip:81234@example.net that >>> it will be delivered to the intended party. In this sense >> this is an >>> AOR. I could put this on my business card for example. >> I think part of the confusion (at least for me) is using the >> term "AoR" and a tag named "aor". It's just not the >> cut-and-dried what is or is not an AoR, imho. The rules by >> which systems change one URI to another URI can easily be >> viewed/described as performing a location-service lookup. >> Just because a system implements those rules in a regex >> replacement, route tables, ENUM lookup, HSS lookup, or >> whatever, doesn't matter - they don't know when the URI >> they've changed it from was an AoR or not. >> >> I think what you guys are saying is "it doesn't matter" - all >> that matters is that a URI of a domain for which the proxy is >> responsible, which is used by that proxy for a >> location-service lookup, actually be tagged with "aor". It's >> ok if that tags things which aren't "AoR's" in the classic >> sense, and thus more H-I entries are tagged than are really >> needed, because the UAS will ignore them. Is that right? >> >> -hadriel >> _______________________________________________ >> 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 AUDET@nortel.com Wed Jul 15 16:07:30 2009 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 27C1C3A6F78 for ; Wed, 15 Jul 2009 16:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.458 X-Spam-Level: X-Spam-Status: No, score=-6.458 tagged_above=-999 required=5 tests=[AWL=0.141, 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 YCG7-C3UOuK1 for ; Wed, 15 Jul 2009 16:07:29 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 0B9563A6C41 for ; Wed, 15 Jul 2009 16:07:28 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6FN7RF10781; Wed, 15 Jul 2009 23:07:27 GMT 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, 15 Jul 2009 18:07:15 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F04FC27@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rfc4244bis: backwards compatibility thread-index: AcoFnk1A+VLjc5mQTgSM2qI5+V4WlgAAJUOw References: From: "Francois Audet" To: "Hadriel Kaplan" , "SIPCORE" Cc: draft-barnes-sipcore-rfc4244bis@tools.ietf.org Subject: Re: [sipcore] rfc4244bis: backwards compatibility 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, 15 Jul 2009 23:07:30 -0000 > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Wednesday, July 15, 2009 15:48 > To: SIPCORE > Cc: draft-barnes-sipcore-rfc4244bis@tools.ietf.org > Subject: rfc4244bis: backwards compatibility >=20 > And now for a horse of a different color... >=20 > The section on backwards compatibility states: > Proxies conforming to this specification tag the hi-entry=20 > parameters > with an hi-target parameter. The hi-target and hi-aor=20 > parameters did > not exist in [RFC4244]; therefore, [RFC4244] implementations do not > tag the hi-entry parameters. This tagging allows for=20 > distinguishing > entries that were added by an [RFC4244] entity, versus one that was > added by an entity conforming to this specification. >=20 > So what is a UAS to do with entries that were created by an=20 > RFC4244 device, and not tagged as "aor" nor "mp"? >=20 > Does it: > 1) Treat them as implicitly tagged with both. > 2) Treat them as implicitly tagged with neither. > 3) Treat them as implicitly tagged with one or the other. >=20 > By "treat them" I mean for the purpose of narrowing down the=20 > list of entries (i.e., removing fluff), as well as for any=20 > application-specific usage of such entries. It reverts back to old RFC 4244 behavior, i.e., If (manufacturer-or-service-provider =3D=3D X1) then Y1() else if (manufacturer-or-service-provider =3D=3D X2) then Y2() else if (manufacturer-or-service-provider=3D=3D X3) then Y3() else Y4() (Half joking). Seriously, it did what it did before. It's not going to work any better = with non-conforming proxies. When it sees the tag, it reduces the ambiguity. Otherwise, it's = basically doing what it did before. Now, what if it didn't support HI before? I would think that you would basically just implement the new 4244 and ignore the non-tagged entries, i.e., treat them a fluff. > Furthermore, since a Proxy modifies a previous H-I entry by=20 > adding an "aor" tag if it treated its URI as a AoR - what=20 > does a Proxy which receives a previous H-I entry that does=20 > not have any tag do - can/should it still add an "aor" tag to=20 > that entry if it handles it as an AoR? (note that this means=20 > a UAS will receive a H-I entry which does not have a "mp" or=20 > any fluff tag but does have an "aor" tag) Yes, you could have that. I believe that is covered in the spec. There are procedures in the steps (both for Proxies and Redirect server) that explains that they populate the entry on behalf of the previous hop. This applies obviously if "the previous hop" was not RFC 4424 compliant, or if the previous hop was a UAC (which wouldn't normally include=20 HI). In this case, proxy/redirect-server includes the entry on it's' behalf. This is actually unchanged from 4244 (althoug it's much more explicit in this draft). The other case is when the entry is there, but it's not tagged. Then yes, the proxy would tag it too. From Martin.Thomson@andrew.com Wed Jul 15 16:10:20 2009 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 61D5C3A6F78 for ; Wed, 15 Jul 2009 16:10:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.548 X-Spam-Level: X-Spam-Status: No, score=-2.548 tagged_above=-999 required=5 tests=[AWL=0.051, 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 qPhIKQrTcvft for ; Wed, 15 Jul 2009 16:10:18 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 3E7263A6B66 for ; Wed, 15 Jul 2009 16:10:17 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_15_18_32_31 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Wed, 15 Jul 2009 18:32:30 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 18:10:14 -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: Wed, 15 Jul 2009 18:10:10 -0500 Message-ID: In-Reply-To: <4A5D8B4E.6040501@neustar.biz> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Confusion over target inSIP location-conveyance - andimpact on ECRIT phonebcp Thread-Index: AcoFIZK7jY4Dz8XWQLOlMYHtC+DsVAAfa4hA References: <0D5F89FAC29E2C41B98A6A762007F5D00221E129@GBNTHT12009MSX.gb002.siemens.net> <020001ca04bf$21910fe0$64b32fa0$@net> <4A5D64E4.4020008@neustar.biz> <4A5D8B4E.6040501@neustar.biz> From: "Thomson, Martin" To: "Jon Peterson" X-OriginalArrivalTime: 15 Jul 2009 23:10:14.0057 (UTC) FILETIME=[68DB8190:01CA05A1] Cc: sipcore@ietf.org Subject: Re: [sipcore] Confusion over target inSIP location-conveyance - andimpact on ECRIT phonebcp 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, 15 Jul 2009 23:10:20 -0000 VGhhbmtzIEpvbiwgdGhhdCdzIHJlYWxseSBoZWxwZnVsLiAgSSBoYWRuJ3QgdGhvdWdodCBhYm91 dCB0aGUgVUFDL0Zyb20gZGlzY29ubmVjdCBpbiB0aGF0IHdheS4NCg0KVGhlIGV4cGxpY2l0IGlu ZGljYXRpb24gaXMgdmVyeSBtdWNoIHdoYXQgSSdtIGxvb2tpbmcgZm9yLiAgVGhpcyBjYW4gZWl0 aGVyIGxpbmsgdGhlIGlkZW50aXR5IGluIHRoZSBGcm9tIHdpdGggdGhlIHByZXNlbnRpdHk7IG9y IC0gYXMgSSBwcmVmZXIgLSBsaW5rIHRoZSBpZGVudGl0eSBpbiB0aGUgRnJvbSB0byB0aGUgbG9j YXRpb24gaW4gdGhlIFBJREYtTE8uICBUaGUgY3VycmVudCB2ZXJzaW9uIG9mIGNvbnZleWFuY2Ug b25seSBvZmZlcnMgZXJyb3JzIGluIHRoaXMgY2FzZS4gIEl0IHdvdWxkIGJlIG11Y2ggYmV0dGVy IHRvIGVuc3VyZSB0aGF0IHRoZSBjYWxsIHN1Y2NlZWRzLCBlc3BlY2lhbGx5IHNpbmNlIHRoZSBV QUMgbGlrZWx5IGhhcyBubyBtZWFucyB0byBjb3JyZWN0IHRoaXMgc29ydCBvZiBlcnJvciBpbiBt YW55IGNpcmN1bXN0YW5jZXMuDQoNCldpdGggYSBjb3JyZWN0aW9uIHRvIGl0cyBzZW1hbnRpY3Mg dG8gZWl0aGVyIG9mIHRoZSBhYm92ZSwgcm91dGluZy1hbGxvd2VkIGNvdWxkIHdvcmsuICBIb3dl dmVyLCBpdCBtaWdodCBiZSBiZXR0ZXIgdGhlbiB0byByZW1vdmUgdGhlIGZvbGxvd2luZyBjb25z dHJhaW50Og0KDQogICBUaGUgInJvdXRpbmctYWxsb3dlZCIgaGVhZGVyIGZpZWxkIHBhcmFtZXRl ciBpcyBhIGdsb2JhbCBwYXJhbWV0ZXINCiAgIG92ZXIgYW55IChhbmQgYWxsL2VhY2gpIGxvY2F0 aW9uVmFsdWVzLi4uDQoNCldpdGggcmVzcGVjdCB0byBteSBxdWVzdGlvbiBvbiBwcmVzL3NpcC9z aXBzLCB0aGF0IG1ha2VzIHRoaXMgYmluZGluZyBldmVuIG1vcmUgaW1wb3J0YW50LiAgRXZlbiB0 aGUgZXhhbXBsZXMgYXNzdW1lIHRoYXQgc2lwOmFsaWNlQGV4YW1wbGUuY29tID09IHByZXM6YWxp Y2VAZXhhbXBsZS5jb20uDQoNCi0tTWFydGluDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0t LS0NCj4gRnJvbTogSm9uIFBldGVyc29uIFttYWlsdG86am9uLnBldGVyc29uQG5ldXN0YXIuYml6 XQ0KPiBTZW50OiBXZWRuZXNkYXksIDE1IEp1bHkgMjAwOSA1OjU1IFBNDQo+IFRvOiBUaG9tc29u LCBNYXJ0aW4NCj4gQ2M6IEJyaWFuIFJvc2VuOyBFbHdlbGwsIEpvaG47IEphbWVzIE0uIFBvbGs7 IHNpcGNvcmVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzaXBjb3JlXSBDb25mdXNpb24gb3Zl ciB0YXJnZXQgaW5TSVAgbG9jYXRpb24tY29udmV5YW5jZQ0KPiAtIGFuZGltcGFjdCBvbiBFQ1JJ VCBwaG9uZWJjcA0KPiANCj4gDQo+IE15IG93biBpbnRlcmVzdCBpbiB0aGlzIGRpc2N1c3Npb24g aGFzIGxhcmdlbHkgYmVlbiB0byBwcmV2ZW50IHRoZQ0KPiBjb25mbGF0aW9uIG9mIHRoZSBVQUMg d2l0aCB0aGUgZ2VvcHJpdiB0YXJnZXQuIEkndmUgYXJndWVkIHRoYXQgdGhlIFVBQw0KPiBhbmQg dGhlIGVudGl0eSBpbiB0aGUgRnJvbSBoZWFkZXIgZmllbGQgdmFsdWUgYXJlIG5vdCBuZWNlc3Nh cmlseQ0KPiBlcXVpdmFsZW50IGZvciB0aGUgcHVycG9zZXMgb2YgZ2VvcHJpdiwgdGhhbmtzIHRv IGFnZ3JlZ2F0b3IgVUFzDQo+IHNlcnZpbmcNCj4gbWFueSB1c2Vycywgc3VjaCBhcyBJUCBQQlhz LCBnYXRld2F5cyBhbmQgc28gZm9ydGguIEkndmUgdGhlcmVmb3JlDQo+IHJlc2lzdGVkIHRoZSBw cm9wb3NhbCB0aGF0IHRoZSBpbXBsaWNpdCBzZW1hbnRpY3Mgb2YgdGhlIEdlb2xvY2F0aW9uDQo+ IGhlYWRlciBiZSAidGhpcyBpcyB0aGUgbG9jYXRpb24gb2YgdGhlIFVBQy4iIEkgZmVlbCBsZXNz IHN0cm9uZ2x5IGFib3V0DQo+IHNlbWFudGljcyBvZiAidGhpcyBpcyB0aGUgbG9jYXRpb24gb2Yg dGhlIGVudGl0eSBpbiB0aGUgRnJvbSBoZWFkZXINCj4gZmllbGQiLCBiZSB0aGV5IGltcGxpY2l0 IG9yIGV4cGxpY2l0IHNlbWFudGljcy4gSSBjYW4gY2VydGFpbmx5IGltYWdpbmUNCj4gYSB2ZXJz aW9uIG9mIHRoZSAiO21lIiBwYXJhbWV0ZXIgYXMgYW4gZXhwbGljaXQgaW5kaWNhdGlvbiBvZiB0 aGVzZQ0KPiBzZW1hbnRpY3MgdGhhdCB3b3VsZCBub3QgZmFsbCBhZm91bCBvZiB0aGlzIGNvbmZs YXRpb24uDQo+IA0KPiBJIGRvIHdvbmRlciwgdGhvdWdoLCBpZiB0aGUgc2VtYW50aWNzIG9mICJy b3V0aW5nLWFsbG93ZWQiIG92ZXJsYXAgd2l0aA0KPiB0aGUgaW50ZW50aW9uIGJlaGluZCAiO21l Ii4gVWx0aW1hdGVseSwgYSBwcm94eSBzZXJ2ZXIgZGVjaWRlcyB3aGV0aGVyDQo+IG9yIG5vdCBp dCB3aWxsIHVzZSB0aGUgbG9jYXRpb24gaW4gdGhlIFNJUCByZXF1ZXN0IGZvciByb3V0aW5nDQo+ IHB1cnBvc2VzLg0KPiBZb3VyIHVzZSBjYXNlIGJlbG93IGFzc3VtZXMgdGhhdCB0aGUgcHJveHkg c2VydmVyIGRlY2lzaW9uIHRvIHJvdXRlDQo+IGJhc2VkIG9uIGxvY2F0aW9uIGlzIGRlcGVuZGVu dCBvbiB0aGUgUElERiByZWZlcmVuY2VkIGluIHRoZSBTSVANCj4gcmVxdWVzdA0KPiBpbmRpY2F0 aW5nIHRoZSBzYW1lIHRhcmdldCBhcyB0aGUgU0lQIGxheWVyIGlkZW50aXR5LiBXaGlsZSAiO21l IiBpcw0KPiBoZWxwZnVsIGluIHRoYXQgY2FzZSwgSSdtIG5vdCBzdXJlIHRoYXQgdGhpcyBzaG91 bGQgYmUgdGhlIGRlY2lkaW5nDQo+IGNyaXRlcmlhIGluIGFsbCBjYXNlcy4gInJvdXRpbmctYWxs b3dlZCIgY29tbXVuaWNhdGVzIGEgbGVzcyBzcGVjaWZpYw0KPiBpbmRpY2F0aW9uIG9mICJoZXks IEkgdGhpbmsgeW91IGNhbiB1c2UgdGhpcyB0byByb3V0ZSB0aGUgcmVxdWVzdCIsDQo+IHNvbWV0 aGluZyB0aGF0IGNvdWxkIGJlIHRydWUgZXZlbiBpZiwgZm9yIHdoYXRldmVyIHJlYXNvbiwgdGhl IGxvY2F0aW9uDQo+IGluIHRoZSBTSVAgcmVxdWVzdCBkb2Vzbid0IHJlcHJlc2VudCB0aGUgdGFy Z2V0IG9mIG15IFNJUC1sYXllcg0KPiBpZGVudGl0eSwgYmVjYXVzZSBkdWUgdG8gc29tZSB1bnVz dWFsIGNpcmN1bXN0YW5jZXMgdGhlIEZyb20gaGVhZGVyDQo+IGZpZWxkIG9mIG15IHJlcXVlc3Qg Y2FuJ3QgaGF2ZSBhIHZhbHVlIHRoYXQgcmVwcmVzZW50cyAibWUiIGF0IHRoZQ0KPiBtb21lbnQg LSBtYXliZSBpdCdzIGFuIGFub255bW91cyBVUkksIGZvciBleGFtcGxlLg0KPiANCj4gTXkgcG9p bnQgaGVyZSBpcyB0aGF0IEkgdGhpbmsgYWdyZWVtZW50IG9uIHRoZSBzb3J0cyBvZiBwb2xpY2ll cyB0aGF0DQo+IHByb3h5IHNlcnZlcnMgc2hvdWxkIGVuZm9yY2UgaGFzIHRvIGluZm9ybSB0aGUg c29ydHMgb2YgaW5kaWNhdGlvbnMgd2UNCj4gZmVlZCBpbnRvIHRoYXQgcG9saWN5LiBJZiB3ZSBu ZWVkIGEgd2F5IHRvIHRlbGwgdGhlIHByb3h5IHNlcnZlciB0aGF0IGENCj4gcmVmZXJlbmNlZCBs b2NhdGlvbiBpcyBhcHByb3ByaWF0ZSBmb3Igcm91dGluZywgd2UgbWlnaHQgd2FudCBzb21ldGhp bmcNCj4gbW9yZSBleHBsaWNpdCB0aGFuICI7bWUiLg0KPiANCj4gVG8geW91ciBwb3N0c2NyaXB0 LCBJJ2QgaGF2ZSB0byBzYXkgbm8sIHRoZXJlJ3Mgbm8gbmVjZXNzYXJ5DQo+IGVxdWl2YWxlbmNl DQo+IGJldHdlZW4gdGhlIHJlc291cmNlcyBpbmRpY2F0ZWQgYnkgdGhvc2UgdHdvIHNjaGVtZXMs IG9ubHkgY29udmVudGlvbg0KPiBsaW5rcyB0aGVtLg0KPiANCj4gSm9uIFBldGVyc29uDQo+IE5l dVN0YXIsIEluYy4NCj4gDQo+IFRob21zb24sIE1hcnRpbiB3cm90ZToNCj4gPiBIaSBKb24sDQo+ ID4NCj4gPiBIZXJlJ3MgdGhlIHByb2JsZW06DQo+ID4gSSBhbSBzaXA6bXRAYW5kcmV3LmNvbS4g IEkgdXNlIEhFTEQgb3IgREhDUCB0byByZXF1ZXN0IGEgbG9jYXRpb24NCj4gVVJJLiAgVGhpcyBp cyB3aGF0IGlzIHB1dCBpbiBteSBTSVAgSU5WSVRFLiAgQSBwcm94eSBkZXJlZmVyZW5jZXMgdGhp cw0KPiB0byBkZXRlcm1pbmUgd2hlcmUgdG8gcm91dGUgdGhlIGNhbGwuICBUaGV5IGVuY291bnRl cg0KPiBwcmVzOnY3Nm5zMzg5MDd2NmUwNUBsaXMuZXhhbXBsZS5jb20gaW4gdGhlIHJlc3VsdGlu ZyBQSURGLUxPLiAgVGhlDQo+IGxvY2F0aW9uIGluZm9ybWF0aW9uIGlzIGlnbm9yZWQ7IGl0J3Mg bm90IGFwcGxpY2FibGUgdG8gdGhlIHJlcXVlc3Rlci4NCj4gPg0KPiA+IFRoZSBzZXJ2ZXIgdGhh dCBwcm92aWRlcyB0aGUgbG9jYXRpb24gaW5mb3JtYXRpb24gaGFzIG5vIGJhc2lzIHRvDQo+IGRl dGVybWluZSB0aGF0IHRoZSBlbnRpdHkgbWFraW5nIGEgcmVxdWVzdCBhbmQgc2lwOm10QGFuZHJl dy5jb20gYXJlDQo+IG9uZSBhbmQgdGhlIHNhbWUuICBUaHVzLCBpdCBjYW5ub3QgbWFrZSB0aGlz IGFzc2VydGlvbi4gIEhFTEQNCj4gcmVjb21tZW5kcyB0aGUgY3JlYXRpb24gb2YgYSBwc2V1ZG9u eW0gZm9yIHRoaXMgcmVhc29uLg0KPiA+DQo+ID4gSG93IGRvIHdlIHJlc29sdmUgdGhpcz8NCj4g Pg0KPiA+IFdlIGNvdWxkIGRlZmluZSBhIG1lY2hhbmlzbSBmb3IgYXNzZXJ0aW5nIHNpcCBpZGVu dGl0eSBpbiBvdGhlcg0KPiBkb21haW5zLCBzdWNoIHRoYXQgSEVMRCBjb3VsZCB1c2UgaXQuICBT b3VuZHMgYSBiaXQgaGVhdnl3ZWlnaHQgdG8gbWUuDQo+ID4NCj4gPiBQcm92aWRpbmcgYSBsaW5r YWdlIGJldHdlZW4gdGhlIHR3byBpbiBTSVAgbWlnaHQgd29yaywgYnV0IGl0IHNvdW5kcw0KPiBs aWtlIHlvdSBkb24ndCB3YW50IHRvIGRvIHRoYXQuICBTaGFtZSwgYmVjYXVzZSB0aGF0J3MgdGhl IGVhc2llc3QuDQo+IE9uZSBzaW1wbGUgd2F5IHdvdWxkIGJlIHRvIGFkZCBhICc7bWUnIHBhcmFt ZXRlciB0byB0aGUgZ2VvbG9jYXRpb24NCj4gaGVhZGVyLCB3aGljaCBsaW5rcyB0aGUgVUFDIChp ZGVudGlmaWVkIGluIEZyb206KSB0byB0aGUgbG9jYXRpb24NCj4gb2JqZWN0LCBpcnJlc3BlY3Rp dmUgb2YgdGhlIGlkZW50aWZpZWQgcHJlc2VudGl0eS4NCj4gPg0KPiA+IC0tTWFydGluDQo+ID4N Cj4gPiBwLnMuIE9uIGEgc2ltaWxhciB0aHJlYWQsIEkgdGhpbmsgSSByZW1lbWJlciByZWFkaW5n IHRoYXQNCj4gc2lwOm10QGFuZHJldy5jb20gaXMgdGhlIHNhbWUgYXMgcHJlczptdEBhbmRyZXcu Y29tLiAgSXMgdGhpcw0KPiBndWFyYW50ZWVkIHRydXRoLCBvciBqdXN0IGhpZ2hseSBsaWtlbHk/ DQo+ID4NCj4gPg0KPiA+PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+PiBGcm9tOiBK b24gUGV0ZXJzb24gW21haWx0bzpqb24ucGV0ZXJzb25AbmV1c3Rhci5iaXpdDQo+ID4+IFNlbnQ6 IFdlZG5lc2RheSwgMTUgSnVseSAyMDA5IDM6MTEgUE0NCj4gPj4gVG86IFRob21zb24sIE1hcnRp bg0KPiA+PiBDYzogQnJpYW4gUm9zZW47IEVsd2VsbCwgSm9objsgSmFtZXMgTS4gUG9sazsgc2lw Y29yZUBpZXRmLm9yZw0KPiA+PiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIENvbmZ1c2lvbiBvdmVy IHRhcmdldCBpblNJUCBsb2NhdGlvbi0NCj4gY29udmV5YW5jZQ0KPiA+PiAtIGFuZGltcGFjdCBv biBFQ1JJVCBwaG9uZWJjcA0KPiA+Pg0KPiA+Pg0KPiA+PiBUaGVyZSBtdXN0IGJlIHNvbWV0aGlu ZyBJJ20gbWlzc2luZyBpbiB0aGlzIGRpc2N1c3Npb24sIGJ1dCBJJ3ZlDQo+IGZvdW5kDQo+ID4+ IHRoaXMgaXNzdWUgd2l0aCBpZGVudGl0eSBiaW5kaW5nIGEgYml0IGVsdXNpdmUuIFBJREYgZG9j dW1lbnRzIChsZXQNCj4gPj4gYWxvbmUgUElERi1MTyBkb2N1bWVudHMpIG5lY2Vzc2FyaWx5IGNv bnRhaW4gYSBmaWVsZCBkZXNpZ25hdGluZyB0aGUNCj4gPj4gZW50aXR5IHRoYXQgdGhlIGRvY3Vt ZW50IGlzIHN1cHBvc2VkIHRvIHJlcHJlc2VudCAtIHRoZSAiZW50aXR5Ig0KPiA+PiBhdHRyaWJ1 dGUgb2YgPHByZXNlbmNlPi4gR2l2ZW4gdGhhdCB0aGlzIGF0dHJpYnV0ZSBjb250YWlucyBhIFVS SSwNCj4gaXQNCj4gPj4gY2FuIGJlIGFzIHNwZWNpZmljIG9yIG9wYXF1ZSBhcyBpcyBuZWNlc3Nh cnkgZm9yIHRoZSBhcHBsaWNhdGlvbiBpbg0KPiA+PiBxdWVzdGlvbi4gSXQgYXBwZWFycyByZWdh cmRsZXNzIG9mIGhvdyB0aGUgUElERiBkb2N1bWVudCBpcyBhY3F1aXJlZA0KPiA+PiAoYnkNCj4g Pj4gcmVmZXJlbmNlIG9yIGJ5IHZhbHVlKS4gSW4gd2hhdCB3YXkgaXMgdGhpcyBlbGVtZW50IGlu c3VmZmljaWVudA0KPiA+PiBleGFjdGx5Pw0KPiA+Pg0KPiA+PiBJIHdvdWxkIGNlcnRhaW5seSBi ZSBza2VwdGljYWwgb2YgYW55IFNJUC1sYXllciBtZWNoYW5pc20gdGhhdCBpcw0KPiA+PiBpbnRl bmRlZCB0byBwcm92aWRlIGEgc2VwYXJhdGUgYWNjb3VudCBvZiBob3cgYSBQSURGIGRvY3VtZW50 IGlzDQo+ID4+ICJib3VuZCINCj4gPj4gdG8gdGhlIGVudGl0eSBpdCByZXByZXNlbnRzLg0KPiA+ Pg0KPiA+PiBKb24gUGV0ZXJzb24NCj4gPj4gTmV1U3RhciwgSW5jLg0KPiA+Pg0KPiA+PiBUaG9t c29uLCBNYXJ0aW4gd3JvdGU6DQo+ID4+DQo+ID4+PiBJIHN0aWxsIGhhdmVuJ3Qgc2VlbiBhbiBl eHBsYW5hdGlvbiBvbiBob3cgdG8gcmVzb2x2ZSB0aGUgaWRlbnRpdHkNCj4gPj4+DQo+ID4+IGJp bmRpbmcgcHJvYmxlbSB3aGVuIGxvY2F0aW9uIGlzIHByb3ZpZGVkIGJ5IHJlZmVyZW5jZS4gIFRo YXQncyBhDQo+IHNtYWxsDQo+ID4+IHRoaW5nIGZvciBwaG9uZS1iY3AsIGJ1dCBub3QgZm9yIGxv Y2F0aW9uLWNvbnZleWFuY2UuDQo+ID4+DQo+ID4+Pg0KPiA+Pj4+IC0tLS0tT3JpZ2luYWwgTWVz c2FnZS0tLS0tDQo+ID4+Pj4gRnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXQ0KPiBPbg0KPiA+Pj4+IEJlaGFsZiBPZiBCcmlhbiBS b3Nlbg0KPiA+Pj4+IFNlbnQ6IFdlZG5lc2RheSwgMTUgSnVseSAyMDA5IDY6MTAgQU0NCj4gPj4+ PiBUbzogJ0Vsd2VsbCwgSm9obic7ICdKYW1lcyBNLiBQb2xrJzsgc2lwY29yZUBpZXRmLm9yZw0K PiA+Pj4+IFN1YmplY3Q6IFJlOiBbc2lwY29yZV0gQ29uZnVzaW9uIG92ZXIgdGFyZ2V0IGluU0lQ IGxvY2F0aW9uLQ0KPiA+Pj4+DQo+ID4+IGNvbnZleWFuY2UNCj4gPj4NCj4gPj4+PiAtIGFuZGlt cGFjdCBvbiBFQ1JJVCBwaG9uZWJjcA0KPiA+Pj4+DQo+ID4+Pj4gSSBoYXZlIHJhaXNlZCB0aGlz IHZlcnkgaXNzdWUgd2l0aCBKYW1lcywgYW5kIHZlcmlmaWVkIGl0IHdpdGggSm9uDQo+ID4+Pj4g UGV0ZXJzb24NCj4gPj4+PiBhbmQgUm9iZXJ0IFNwYXJrcywgYW5kIHRoZSBpbnRlbnRpb24gaXMg dGhhdCB0aGUgR2VvbG9jYXRpb24NCj4gaGVhZGVyDQo+ID4+Pj4NCj4gPj4gY2FuDQo+ID4+DQo+ ID4+Pj4gY2FycnkgdGhlIGxvY2F0aW9uIG9mIGFueSB0YXJnZXQsIHRoZSBzcGVjaWZpYyB0YXJn ZXQgYmVpbmcgdGhhdA0KPiA+Pj4+IGlkZW50aWZpZWQNCj4gPj4+PiBpbiB0aGUgUElERiwgYW5k IHN1YmplY3QgdG8gdGhlIHByaXZhY3kgcmVxdWlyZW1lbnRzIG9mIHRoYXQNCj4gdGFyZ2V0Lg0K PiA+Pj4+DQo+ID4+Pj4gSXQgdHVybnMgb3V0IHRvIGJlIHVzZWZ1bCB0byBkbyB0aGlzIGluIGEg Y291cGxlIG9mIGNhc2VzIEkndmUgcnVuDQo+ID4+Pj4gYWNyb3NzLA0KPiA+Pj4+IGFsdGhvdWdo IEknbSBzb21ld2hhdCBzdXJwcmlzZWQgdGhhdCBldmVyeW9uZSBhZ3JlZWQgaXQgaXMgb2theSB0 bw0KPiA+Pj4+DQo+ID4+IGRvDQo+ID4+DQo+ID4+Pj4gc28uDQo+ID4+Pj4NCj4gPj4+PiBXaGls ZSBJIGd1ZXNzIEkgY291bGQgaW1wcm92ZSBwaG9uZWJjcCBieSBtYWtpbmcgYW4gZXhwbGljaXQN Cj4gPj4+Pg0KPiA+PiBzdGF0ZW1lbnQNCj4gPj4NCj4gPj4+PiB0aGF0LA0KPiA+Pj4+IHdoZW4g c2VudCB0byB0aGUgUFNBUCwgdGhlIGxvY2F0aW9uIGluIHRoZSBoZWFkZXIgbXVzdCBiZSB0aGF0 IG9mDQo+ID4+Pj4NCj4gPj4gdGhlDQo+ID4+DQo+ID4+Pj4gY2FsbGVyLCBJIGRvIHRoaW5rIGl0 J3MgY2xlYXIgZW5vdWdoIHRoYXQgaXQgaXMuDQo+ID4+Pj4NCj4gPj4+PiBJJ2xsIGRvIHRoYXQg aW4gdGhlIG5leHQgcmV2LCBhbHRob3VnaCBJIGRvbid0IHdhbnQgdG8gaG9sZCB1cA0KPiA+Pj4+ DQo+ID4+IHNlbmRpbmcNCj4gPj4NCj4gPj4+PiB0aGUNCj4gPj4+PiBjdXJyZW50IHZlcnNpb24g dG8gdGhlIElFU0cgb3ZlciB0aGF0IHRpZGJpdC4NCj4gPj4+Pg0KPiA+Pj4+IEJyaWFuDQo+ID4+ Pj4NCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ ID4+Pj4+IEZyb206IEVsd2VsbCwgSm9obiBbbWFpbHRvOmpvaG4uZWx3ZWxsQHNpZW1lbnMtZW50 ZXJwcmlzZS5jb21dDQo+ID4+Pj4+IFNlbnQ6IFR1ZXNkYXksIEp1bHkgMTQsIDIwMDkgMjo0MCBB TQ0KPiA+Pj4+PiBUbzogSmFtZXMgTS4gUG9sazsgc2lwY29yZUBpZXRmLm9yZzsgQnJpYW4gUm9z ZW4NCj4gPj4+Pj4gU3ViamVjdDogQ29uZnVzaW9uIG92ZXIgdGFyZ2V0IGluU0lQIGxvY2F0aW9u LWNvbnZleWFuY2UgLSBhbmQNCj4gPj4+Pj4NCj4gPj4gaW1wYWN0DQo+ID4+DQo+ID4+Pj4+IG9u IEVDUklUIHBob25lYmNwDQo+ID4+Pj4+DQo+ID4+Pj4+IEluIDQuMiBpdCBzdGF0ZXM6DQo+ID4+ Pj4+ICJUaGUgVUFDIGNhbiB1c2Ugd2hhdGV2ZXIgbWVhbnMgaXQga25vd3Mgb2YgdG8gdmVyaWZ5 L3JlZnJlc2ggaXRzDQo+ID4+Pj4+ICAgIGxvY2F0aW9uIGluZm9ybWF0aW9uIGJlZm9yZSBhdHRl bXB0aW5nIGEgbmV3IHJlcXVlc3QgdGhhdA0KPiA+Pj4+Pg0KPiA+PiBpbmNsdWRlcw0KPiA+Pg0K PiA+Pj4+PiAgICBsb2NhdGlvbi4iDQo+ID4+Pj4+ICJpdHMgbG9jYXRpb24gaW5mb3JtYXRpb24i IHN1Z2dlc3RzIHRoYXQgdGhlIFVBQyBpcyB0aGUgdGFyZ2V0Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJ biA0LjMuMyBpdCBzdGF0ZXM6DQo+ID4+Pj4+ICJUaGlzIGRvY3VtZW50IGdpdmVzIG5vIGd1aWRh bmNlIGhvdyB0aGlzIGlzIGFjY29tcGxpc2hlZCwgZ2l2ZW4NCj4gPj4+Pj4NCj4gPj4gdGhlDQo+ ID4+DQo+ID4+Pj4+ICAgIG51bWJlciBvZiB3YXlzIGEgVUFDIGNhbiBsZWFybiBpdHMgbG9jYXRp b24iDQo+ID4+Pj4+IHdoaWNoIHN1Z2dlc3RzIHNpbWlsYXIuDQo+ID4+Pj4+DQo+ID4+Pj4+IFNp bWlsYXJseSBpbiA2LjE6DQo+ID4+Pj4+ICJJZiBhIFVBQyBkb2VzIG5vdCBsZWFybiBhbmQgc3Rv cmUgaXRzIGxvY2F0aW9uIGxvY2FsbHkgKGEgR1BTDQo+ID4+Pj4+DQo+ID4+IGNoaXApDQo+ID4+ DQo+ID4+Pj4+ICAgIG9yIGZyb20gdGhlIG5ldHdvcmsgKERIQ1Agb3IgTExEUC1NRUQpLCB0aGUg VUFDIE1BWSBsZWFybiBpdHMNCj4gPj4+Pj4NCj4gPj4gTGJ5Ug0KPiA+Pg0KPiA+Pj4+PiAgICBV UkkgKGZyb20gREhDUCBmb3IgZXhhbXBsZSkuIg0KPiA+Pj4+PiBXaGljaCBzdWdnZXN0cyB0aGF0 IGEgVUFDIGluc2VydHMgaXRzIGxvY2F0aW9uLCBub3Qgc29tZSBvdGhlcg0KPiA+Pj4+PiBsb2Nh dGlvbi4NCj4gPj4+Pj4NCj4gPj4+Pj4gQW5kIGxhdGVyIGluIDYuMToNCj4gPj4+Pj4gIklmIGEg VUFDIGhhcyBhbHJlYWR5IGNvbnZleWVkIGxvY2F0aW9uIGluIHRoZSBvcmlnaW5hbCByZXF1ZXN0 DQo+IG9mDQo+ID4+Pj4+DQo+ID4+IGENCj4gPj4NCj4gPj4+Pj4gICAgdHJhbnNhY3Rpb24sIGFu ZCB3YW50cyB0byB1cGRhdGUgaXRzIGxvY2F0aW9uIGluZm9ybWF0aW9uIC4uLiINCj4gPj4+Pj4N Cj4gPj4+Pj4gSW4gNi4yOg0KPiA+Pj4+PiAiSWYgdGhlIExieVIgVVJJIGlzDQo+ID4+Pj4+ICAg IHNpcDosIHNpcHM6IG9yIHByZXM6LCBhbmQgdGhlIFVBUyB3YW50cyB0byBsZWFybiB0aGUgVUFD J3MNCj4gPj4+Pj4gbG9jYXRpb24sIg0KPiA+Pj4+Pg0KPiA+Pj4+PiBJbiA2LjIuMToNCj4gPj4+ Pj4gIlRoaXMNCj4gPj4+Pj4gICAgbWVhbnMgdGhlIFNJUCBzZXJ2ZXIgaXMgaW5jbHVkaW5nIGl0 cyB2ZXJzaW9uIG9mIHdoZXJlIGl0DQo+IHRoaW5rcw0KPiA+Pj4+Pg0KPiA+Pj4+Pg0KPiA+Pj4+ IHRoZQ0KPiA+Pj4+DQo+ID4+Pj4NCj4gPj4+Pj4gICAgVUFDIGlzLCBnZW9ncmFwaGljYWxseS4i DQo+ID4+Pj4+DQo+ID4+Pj4+IEluIDg6DQo+ID4+Pj4+ICJDb252ZXlhbmNlIG9mIHBoeXNpY2Fs IGxvY2F0aW9uIG9mIGEgVUFDIHJhaXNlcyBwcml2YWN5DQo+IGNvbmNlcm5zIg0KPiA+Pj4+Pg0K PiA+Pj4+PiBhbmQ6DQo+ID4+Pj4+ICJJbiBjYXNlcyB3aGVyZSBhIHNlc3Npb24gc2V0LXVwIGlz DQo+ID4+Pj4+ICAgIHJldGFyZ2V0ZWQgYmFzZWQgb24gdGhlIGxvY2F0aW9uIG9mIHRoZSBVQUMg aW5pdGlhdGluZyB0aGUNCj4gY2FsbA0KPiA+Pj4+Pg0KPiA+PiBvcg0KPiA+Pg0KPiA+Pj4+PiAg ICBTSVAgTUVTU0FHRSwiDQo+ID4+Pj4+DQo+ID4+Pj4+IEFsbCB0aGVzZSBtYW55IGV4YW1wbGVz IGlsbHVzdHJhdGUgYW4gaW1wbGljYXRpb24gdGhhdCB0aGUNCj4gbG9jYXRpb24NCj4gPj4+Pj4g dGFyZ2V0IGlzIHRoZSBVQUMuIEkgYW0gc3VyZSB0aGVyZSBhcmUgb3RoZXIgcGxhY2VzIHRvby4N Cj4gPj4+Pj4NCj4gPj4+Pj4gSSBmb3VuZCBhIGNvdXBsZSBvZiBwbGFjZXMgdGhhdCBjb250cmFk aWN0IHRoaXMuIEluIDYuMiBpdA0KPiBzdGF0ZXM6DQo+ID4+Pj4+ICJJZiB0aGVyZQ0KPiA+Pj4+ PiAgICBpcyBtb3JlIHRoYW4gb25lIFBJREYtTE8gd2l0aCBkaWZmZXJlbnQgVGFyZ2V0IGlkZW50 aWZpZXJzLA0KPiB0aGVuDQo+ID4+Pj4+ICAgIHRoZSBVQUMgaXMgbWVyZWx5IHRlbGxpbmcgdGhl IFVBUyB3aGVyZSBtb3JlIHRoYW4gb25lIFRhcmdldA0KPiBpcywNCj4gPj4+Pj4NCj4gPj4+Pj4N Cj4gPj4+PiBhbmQNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+Pj4+ICAgIHRoZXJlIHNob3VsZCBub3Qg YmUgYW55IGNvbmZsaWN0LiINCj4gPj4+Pj4NCj4gPj4+Pj4gSSB0aGluayB0aGVyZSBhcmUgb3Ro ZXIgcGxhY2VzIHRoYXQgbWVudGlvbiBsb2NhdGlvbnMgb2YgbXVsdGlwbGUNCj4gPj4+Pj4gdGFy Z2V0cyBpbiBhIHJlcXVlc3QsIGltcGx5aW5nIHRoZXkgY2Fubm90IGFsbCBiZSB0aGUgbG9jYXRp b24gb2YNCj4gPj4+Pj4NCj4gPj4gdGhlDQo+ID4+DQo+ID4+Pj4+IFVBQy4NCj4gPj4+Pj4NCj4g Pj4+Pj4gQW5kIGluIDYuMi4xIGl0IHN0YXRlczoNCj4gPj4+Pj4gIlRoZSBMb2NhdGlvbiBUYXJn ZXQgaWRlbnRpZmllZCBpbg0KPiA+Pj4+PiAgICB0aGUgUElERi1MTyBtYXkgb3IgbWF5IG5vdCBi ZSB0aGUgbG9jYXRpb24gaW5zZXJ0ZXIsIG9yIHRoZQ0KPiA+Pj4+PiAgICBnZW5lcmF0b3Igb2Yg dGhlIHJlcXVlc3QgKHRoZSBVQUMgb3IgU0lQIHNlcnZlcikuIg0KPiA+Pj4+Pg0KPiA+Pj4+PiBT byB3ZSBoYXZlIGluY29uc2lzdGVuY3kgYXMgdG8gd2hldGhlciBhIGNvbnZleWVkIGxvY2F0aW9u IGlzDQo+IHRoYXQNCj4gPj4+Pj4NCj4gPj4gb2YNCj4gPj4NCj4gPj4+Pj4gdGhleSBVQUMgb3Ig bm90Lg0KPiA+Pj4+Pg0KPiA+Pj4+PiBPbmUgZG9jdW1lbnQgdGhhdCByZWxpZXMgb24gbG9jYXRp b24tY29udmV5YW5jZSBpcyBFQ1JJVCdzDQo+ID4+Pj4+DQo+ID4+IHBob25lYmNwLg0KPiA+Pg0K PiA+Pj4+IEluDQo+ID4+Pj4NCj4gPj4+Pg0KPiA+Pj4+PiB0aGVyZSwgSSBjYW5ub3QgZmluZCBh bnkgcmVmZXJlbmNlIHRvIGEgcm91dGluZyBlbnRpdHkgbG9va2luZyB0bw0KPiA+Pj4+Pg0KPiA+ PiBzZWUNCj4gPj4NCj4gPj4+Pj4gd2hldGhlciBhIGNvbnZleWVkIGxvY2F0aW9uIGhhcyB0aGUg Y2FsbGVyIGFzIHRhcmdldCBvciBub3QuIEl0DQo+ID4+Pj4+DQo+ID4+IGp1c3QNCj4gPj4NCj4g Pj4+Pj4gYXNzdW1lcyB0aGF0IHRoaXMgaXMgdGhlIGNhc2UuIFNvIGlmIHdlIHdlcmUgdG8gYWdy ZWUgdGhhdCBhDQo+ID4+Pj4+DQo+ID4+IGNvbnZleWVkDQo+ID4+DQo+ID4+Pj4+IGxvY2F0aW9u IGlzIG5vdCBuZWNlc3NhcmlseSB0aGUgbG9jYXRpb24gb2YgdGhlIFVBQywgdGhpcyB3aWxsDQo+ IGhhdmUNCj4gPj4+Pj4gaW1wYWN0IG9uIHBob25lYmNwLg0KPiA+Pj4+Pg0KPiA+Pj4+PiBKb2hu DQo+ID4+Pj4+DQo+ID4+Pj4+DQo+ID4+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCj4gPj4+PiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiA+Pj4+IHNp cGNvcmVAaWV0Zi5vcmcNCj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL3NpcGNvcmUNCj4gPj4+Pg0KPiA+Pj4+DQo+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+ID4+ Pg0KPiA+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gPj4NCj4gPj4+IFRoaXMgbWVz c2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KPiA+Pj4g Y29udGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5m b3JtYXRpb24uDQo+ID4+PiBJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxlYXNl IG5vdGlmeSB0aGUgc2VuZGVyDQo+ID4+PiBpbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmln aW5hbC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQo+ID4+PiB0aGlzIGVtYWlsIGlzIHByb2hp Yml0ZWQuDQo+ID4+PiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+IC0tDQo+ID4+Pg0KPiA+PiAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gPj4NCj4gPj4+IFttZjJdDQo+ID4+PiBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+Pj4gc2lwY29yZSBtYWlsaW5nIGxp c3QNCj4gPj4+IHNpcGNvcmVAaWV0Zi5vcmcNCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21h aWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPiA+Pj4NCj4gPj4+DQo+ID4NCj4gPiAtLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ID4gVGhpcyBtZXNzYWdlIGlzIGZv ciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQo+ID4gY29udGFpbiBwcml2 aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3JtYXRpb24uDQo+ ID4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlcg0KPiA+IGltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVuYXV0 aG9yaXplZCB1c2Ugb2YNCj4gPiB0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQo+ID4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPiA+IFttZjJdDQo+ID4NCj4g DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KVGhpcyBtZXNzYWdl IGlzIGZvciB0aGUgZGVzaWduYXRlZCByZWNpcGllbnQgb25seSBhbmQgbWF5DQpjb250YWluIHBy aXZpbGVnZWQsIHByb3ByaWV0YXJ5LCBvciBvdGhlcndpc2UgcHJpdmF0ZSBpbmZvcm1hdGlvbi4g IA0KSWYgeW91IGhhdmUgcmVjZWl2ZWQgaXQgaW4gZXJyb3IsIHBsZWFzZSBub3RpZnkgdGhlIHNl bmRlcg0KaW1tZWRpYXRlbHkgYW5kIGRlbGV0ZSB0aGUgb3JpZ2luYWwuICBBbnkgdW5hdXRob3Jp emVkIHVzZSBvZg0KdGhpcyBlbWFpbCBpcyBwcm9oaWJpdGVkLg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpbbWYyXQ0K From AUDET@nortel.com Wed Jul 15 16:16:05 2009 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 0E32528C16C for ; Wed, 15 Jul 2009 16:16:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.459 X-Spam-Level: X-Spam-Status: No, score=-6.459 tagged_above=-999 required=5 tests=[AWL=0.140, 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 NwNoFzdXvMUl for ; Wed, 15 Jul 2009 16:16:04 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id EBA5728C151 for ; Wed, 15 Jul 2009 16:16:03 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6FNEAF22159; Wed, 15 Jul 2009 23:14:10 GMT 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, 15 Jul 2009 18:14:19 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A5E5D5F.80908@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoFoDJwHUbnPh6fRPutXaYkKcNsPAAANwRg References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <4A5E5D5F.80908@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 15 Jul 2009 23:16:05 -0000 =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Wednesday, July 15, 2009 15:51 > To: Audet, Francois (SC100:3055) > Cc: Hadriel Kaplan; SIPCORE > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >=20 >=20 >=20 > Francois Audet wrote: > > Well, sort of. > >=20 > > But I can't think of cases where the tag "aor" would not be=20 > applied to=20 > > somthing that is not an AOR. > >=20 > > It is certainly true that not all AORs will be tagged. > >=20 > > In my mind, the tag meant "I recorgnize this as being the AOR I'm=20 > > responsible for, and that I'm using for the database dip". >=20 > I think I agree with Francois, but that definition is circular. >=20 > I'm saying "its an AOR if somebody from its domain *says* its an AOR." Yes. Agree. > But I don't think thats enough - I've seen too many cases=20 > when people are willing to assert things that make no sense.=20 > If you just got an address from DHCP, then you had better not=20 > assert that some URI containing that is an AOR. >=20 > I think the meaning of the URI needs to be stable over some=20 > reasonably long period of time before it qualifies as an AOR.=20 > But the meaning of "meaning" is also a bit squishy there. It=20 > doesn't have to represent the same *person* (or call center=20 > addresses aren't AORs), and it doesn't have to represent the=20 > same device. It just has to represent some stable "role" or=20 > "presentity" or something. >=20 > Nor, IMO, does it have to translate to something else. While=20 > it might be unusual, it is *possible* for an AOR to resolve=20 > directly to a UAS. >=20 > And if it does translate to something else, it need not be=20 > via a location service, though that is a common way. Yes, but let's remember that this tag we called "aor" in this draft is meant for a specific purpose, i.e., isolating the important=20 URIs from the "fluff". So the job of UASs and upstream proxies is easier. It's not like we are going to give a plaque of congratulations=20 saying "Genuine AOR (tm)" or anything like that. The point is not to define something as an ARO. The point is to mark an address has having value for the domain, in resolving it using it's location service. Like somebody else said (think it was Hadriel), this is lower-case "aor: the tag" as opposed to upper-case "AOR: the classic definition". If we can think of a better tag name, maybe it would help. I personally like "aor" because frankly, even for a AOR, you can't know a URI is an AOR, unless you are the pornographer responsible for minting it = :-) From pkyzivat@cisco.com Wed Jul 15 16:27:06 2009 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 CE3903A6C8C for ; Wed, 15 Jul 2009 16:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.359 X-Spam-Level: X-Spam-Status: No, score=-6.359 tagged_above=-999 required=5 tests=[AWL=0.240, 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 rYjlBhlkbIWc for ; Wed, 15 Jul 2009 16:26:59 -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 B09D928C14F for ; Wed, 15 Jul 2009 16:26:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACsCXkqrR7O6/2dsb2JhbAC4aogjkRAFgjQLgUw X-IronPort-AV: E=Sophos;i="4.42,407,1243814400"; d="scan'208";a="347468296" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 15 Jul 2009 23:25:14 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6FNPE9N008588; Wed, 15 Jul 2009 16:25:14 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6FNPD8O025902; Wed, 15 Jul 2009 23:25:14 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 19:25:13 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 19:25:13 -0400 Message-ID: <4A5E6558.8000108@cisco.com> Date: Wed, 15 Jul 2009 19:25:12 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Francois Audet References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jul 2009 23:25:13.0225 (UTC) FILETIME=[80CDA790:01CA05A3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3360; t=1247700314; x=1248564314; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20rfc4244bis=3A=20what=20is=2 0an=20AoR? |Sender:=20; bh=Ef9DshZueyNks8liVhxizPwhxfVCXZnePs1sx1us+wY=; b=N4NAGoIFawCSKL6PZ4hyYmPSjvdq9AzQLHy1VET27xqkU7+NIGBXiMwg8j 0rCVSCM2mk/0kctmByLyR1BilFCjnYFHkJ83iouvSOfik3QvJjRxLolxKBbM UKSR37oazc; Authentication-Results: sj-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 15 Jul 2009 23:27:07 -0000 If the tag is "aor" then I think it had better mean the same thing ans AOR or AoR. And in the process help to tighten up the definition of that. Having it mean "something like AoR, but not quite" is IMO a *really* bad idea. If it really is different than AoR, then it had better be called something else, and given a clear definition that justifies a new concept. AFAIK the point here is to identify the URI as an Address of Record. If we had a clear unambiguous definition of that, which was also consistent with common understanding of the term (by those who *ought* to know), then I don't think we would be having this discussion. Thanks, Paul Francois Audet wrote: > > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Wednesday, July 15, 2009 15:51 >> To: Audet, Francois (SC100:3055) >> Cc: Hadriel Kaplan; SIPCORE >> Subject: Re: [sipcore] rfc4244bis: what is an AoR? >> >> >> >> Francois Audet wrote: >>> Well, sort of. >>> >>> But I can't think of cases where the tag "aor" would not be >> applied to >>> somthing that is not an AOR. >>> >>> It is certainly true that not all AORs will be tagged. >>> >>> In my mind, the tag meant "I recorgnize this as being the AOR I'm >>> responsible for, and that I'm using for the database dip". >> I think I agree with Francois, but that definition is circular. >> >> I'm saying "its an AOR if somebody from its domain *says* its an AOR." > > Yes. Agree. > >> But I don't think thats enough - I've seen too many cases >> when people are willing to assert things that make no sense. >> If you just got an address from DHCP, then you had better not >> assert that some URI containing that is an AOR. >> >> I think the meaning of the URI needs to be stable over some >> reasonably long period of time before it qualifies as an AOR. >> But the meaning of "meaning" is also a bit squishy there. It >> doesn't have to represent the same *person* (or call center >> addresses aren't AORs), and it doesn't have to represent the >> same device. It just has to represent some stable "role" or >> "presentity" or something. >> >> Nor, IMO, does it have to translate to something else. While >> it might be unusual, it is *possible* for an AOR to resolve >> directly to a UAS. >> >> And if it does translate to something else, it need not be >> via a location service, though that is a common way. > > Yes, but let's remember that this tag we called "aor" in this draft is > meant for a specific purpose, i.e., isolating the important > URIs from the "fluff". So the job of UASs and upstream proxies > is easier. > > It's not like we are going to give a plaque of congratulations > saying "Genuine AOR (tm)" or anything like that. The point is not > to define something as an ARO. The point is to mark an address > has having value for the domain, in resolving it using it's location > service. > > Like somebody else said (think it was Hadriel), this is lower-case > "aor: the tag" as opposed to upper-case "AOR: the classic definition". > > If we can think of a better tag name, maybe it would help. I personally > like "aor" because frankly, even for a AOR, you can't know a URI > is an AOR, unless you are the pornographer responsible for minting it :-) > From AUDET@nortel.com Wed Jul 15 16:39:21 2009 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 838BE3A6C16 for ; Wed, 15 Jul 2009 16:39:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.461 X-Spam-Level: X-Spam-Status: No, score=-6.461 tagged_above=-999 required=5 tests=[AWL=0.138, 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 Vf84cII2puOQ for ; Wed, 15 Jul 2009 16:39:20 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 0940A3A6C39 for ; Wed, 15 Jul 2009 16:39:13 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6FNZoF23360; Wed, 15 Jul 2009 23:35:50 GMT 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, 15 Jul 2009 18:36:44 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A5E6558.8000108@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoFo4e4qats/hO7QSm/k4ukbm9wxwAAOV6A References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 15 Jul 2009 23:39:21 -0000 "aor" means it is "an AOR that I own AND I used for a location service dip".=20 I don't know if you view that as "different" or not. I guess it's debatable. Again, in my humble opinion, a URI is an AOR only if the domain responsible says so. And the way it knows it's an AOR is if=20 it can use it for the location service dip.=20 If people don't agree with the statement, then perhaps we should change the name of the parameter. =20 > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Wednesday, July 15, 2009 16:25 > To: Audet, Francois (SC100:3055) > Cc: Hadriel Kaplan; SIPCORE > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >=20 > If the tag is "aor" then I think it had better mean the same=20 > thing ans AOR or AoR. And in the process help to tighten up=20 > the definition of that. >=20 > Having it mean "something like AoR, but not quite" is IMO a=20 > *really* bad idea. >=20 > If it really is different than AoR, then it had better be=20 > called something else, and given a clear definition that=20 > justifies a new concept. >=20 > AFAIK the point here is to identify the URI as an Address of=20 > Record. If we had a clear unambiguous definition of that,=20 > which was also consistent with common understanding of the=20 > term (by those who *ought* to know), then I don't think we=20 > would be having this discussion. >=20 > Thanks, > Paul From HKaplan@acmepacket.com Wed Jul 15 17:19:39 2009 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 42EA028C1BD for ; Wed, 15 Jul 2009 17:19:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 UWkIabdfZbdF for ; Wed, 15 Jul 2009 17:19:38 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 0D8C428C11C for ; Wed, 15 Jul 2009 17:18:51 -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.1.375.2; Wed, 15 Jul 2009 20:19:09 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 15 Jul 2009 20:19:09 -0400 From: Hadriel Kaplan To: Francois Audet , SIPCORE Date: Wed, 15 Jul 2009 20:19:08 -0400 Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoFRoWh2hBP5wjyQIWzHzootDGkMgASGu2gAAAGFAAAAfQZ4AACliEQ Message-ID: References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.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] rfc4244bis: what is an AoR? 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, 16 Jul 2009 00:19:39 -0000 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Wednesday, July 15, 2009 5:57 PM >=20 > But I can't think of cases where the tag "aor" would not be applied > to somthing that is not an AOR. I think there are cases where an "aor" tag would be applied to something th= at's not an AoR, and probably vice-versa. But maybe I'm not thinking about= this quite right. Example-1: ENUM is used widely, as both a means of performing "pure" E.164 = number to AoR resolution, Number Portability, inter-domain routing, intra-d= omain routing, and even registered contact routing. An ENUM query can be d= escribed as a location-service lookup. Proxies performing an ENUM query do= n't necessarily know what type of URI they are performing that query for. = So if they get a request for "sip:+1234567890@sp.com" and do the query and = the result makes it change it for inter-domain routing, then the original U= RI was not a AoR; if the result made it send it to a UAS/gateway directly, = then it was an AoR. Right? Since the proxy won't know when, it will have = to tag it as AoR every time, no? Example-2: it is not rare for the req-uri sent to the proxy with which it d= oes a lookup to not actually be the AoR per se - for example, the proxy may= receive a req-uri of "sip:+123456790@proxy1.sp.com". It resolves this to = the registered contact for the "real" AoR of "sip:234567890@sp.com" - by "r= eal" I mean the one registered and known by the UAS. Now one could say the= proxy should have added that real AoR in an H-I entry as another intermedi= ate/internal step before resolution, because in theory the URI used for the= resolution was the real AoR not the req-uri received; but that's getting i= nto the internal mechanics of how the proxy was implemented. For example t= he proxy may have done an ENUM lookup using only the username, and not know= the "real" AoR's domain portion was different. It was authoritative for "= proxy1.sp.com" (it's also authoritative for "sp.com"), and it did a locatio= n lookup using "sip:+123456790@proxy1.sp.com", so all the conditions were m= et - but it's not the actual AoR the UAS needs to see, nor what we would co= nsider a "classic" AoR (not what one would put on a business card, for exam= ple). No? -hadriel From gao.yang2@zte.com.cn Wed Jul 15 17:24:45 2009 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 7A5303A6A56; Wed, 15 Jul 2009 17:24:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.318 X-Spam-Level: X-Spam-Status: No, score=-94.318 tagged_above=-999 required=5 tests=[AWL=-1.528, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 HOgv5mskkF2y; Wed, 15 Jul 2009 17:24:44 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id CE81928C195; Wed, 15 Jul 2009 17:23:45 -0700 (PDT) Received: from [10.30.17.99] by mx6.zte.com.cn with surfront esmtp id 91102001811080; Thu, 16 Jul 2009 08:10:49 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.99] with StormMail ESMTP id 46629.5659058387; Thu, 16 Jul 2009 08:16:10 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n6G0NpV9008191; Thu, 16 Jul 2009 08:23:51 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4A5E0044.1090509@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 16 Jul 2009 08:23:44 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-16 08:23:53, Serialize complete at 2009-07-16 08:23:53 Content-Type: multipart/alternative; boundary="=_alternative 00022D0C482575F5_=" X-MAIL: mse1.zte.com.cn n6G0NpV9008191 Cc: SIPCORE , OKUMURA Shinji , sipcore-bounces@ietf.org Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ICC08Li0OiBSZTogtPC4tDogUmU6ICA=?= =?gb2312?b?tPC4tDogUmU6ICBOZXcgcmV2aXNpb24gb2YgdGhlIHJlLUlOVklURSBoYW5k?= =?gb2312?b?bGluZyBkcmFmdA==?= 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, 16 Jul 2009 00:24:45 -0000 This is a multipart message in MIME format. --=_alternative 00022D0C482575F5_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCkkgY2F0Y2ggeW91ciBwb2ludCBub3cuIFlvdSBtZWFuIHRoYXQgdGhlIG1pZGRsZS1i b3gsIHN1Y2ggYXMgcHJveHksIA0KYWRkaW5nIFZpYSBpbiB0aGUgSU5WSVRFLiBUaGVuIHRoZSBw cm94eSBpcyBub3cgbm9uLWZ1bmN0aW9uYWwsIG1ha2luZyB0aGUgDQpyZXNwb25zZSB1bnJlYWNo YWJsZS4NCg0KQnV0IEkgdGhpbmsgdGhlIHNvbHV0aW9ucyBzaG91bGQgbm90IGJlIGluIHByb3Rv Y29sIGxldmVsLiBUaGUgc29sdXRpb25zIA0KY2FuIGJlOg0KDQoxLiBGYXVsdCB0b2xlcmFuY2Uu IChpZS4gY3Jhc2hpbmcgb2YgUC1DU0NGL1MtQ1NDRikNCg0KMi4gSXNzdWUgbmV3IElOVklURSBy ZXBsYWNlIHRoZSBvbGQgb25lLiAoaWUuIGNoYW5naW5nIFAtQ1NDRikNCg0KVGhhbmtzLg0KDQpH YW8NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAyMTAw MTINCiBUZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9tYWls IDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQoNCg0KDQpQYXVsIEt5eml2YXQgPHBreXppdmF0QGNpc2NvLmNvbT4gDQq3orz+yMs6ICBz aXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMDktMDctMTYgMDA6MTMNCg0KytW8/sjLDQpnYW8u eWFuZzJAenRlLmNvbS5jbg0Ks63LzQ0KU0lQQ09SRSA8c2lwY29yZUBpZXRmLm9yZz4sIE9LVU1V UkEgU2hpbmppIDxzaGluQHNvZnRmcm9udC5jby5qcD4NCtb3zOINClJlOiBbc2lwY29yZV0gtPC4 tDogUmU6ILTwuLQ6IFJlOiAgtPC4tDogUmU6ICBOZXcgcmV2aXNpb24gb2YgdGhlIA0KcmUtSU5W SVRFIGhhbmRsaW5nIGRyYWZ0DQoNCg0KDQoNCg0KDQoNCg0KZ2FvLnlhbmcyQHp0ZS5jb20uY24g d3JvdGU6DQoNCj4gSWYgdGhlIFVBQyBkZWNpZGVzIHRvIGZpeCB0aGlzIGJ5IHNlbmRpbmcgYW4g VVBEQVRFIGJlZm9yZSBjb21wbGV0aW9uIG9mDQo+IHRoZSByZUlOVklURSwgdGhlbiBpdCBtYXkg c3VjY2VlZCBpbiBnZXR0aW5nIHRoZSByZW1vdGUgdGFyZ2V0IGNoYW5nZWQNCj4gYXQgdGhlIFVB Uy4gQnV0IHRoZSAqVUFTIGlzIHN0aWxsIG9ibGlnYXRlZCB0byBzZW5kIHRoZSByZW1haW5pbmcN Cj4gcmVzcG9uc2VzIHRvIHRoZSBhZGRyZXNzIGluIHRoZSBWaWEsIHdoaWNoIGlzIHRoZSBvbGQg YWRkcmVzcy4gKg0KPiANCj4gW0dhb10gSXQgaXMgaW4gUkZDMzI2MSwgYnV0IFJGQzMzMTEgaGFz IHRoZSBkZWZpbml0aW9uIGFzOg0KPiANCj4gZnJvbSBSRkMzMzExOg0KPiBVUERBVEUgaXMgYSB0 YXJnZXQgcmVmcmVzaCByZXF1ZXN0LiBBcyBzcGVjaWZpZWQgaW4gUkZDIDMyNjEgWzFdLA0KPiAg ICB0aGlzIG1lYW5zIHRoYXQgaXQgY2FuIHVwZGF0ZSB0aGUgcmVtb3RlIHRhcmdldCBvZiBhIGRp YWxvZy4gSWYgYSBVQQ0KPiAgICB1c2VzIGFuIFVQREFURSByZXF1ZXN0IG9yIHJlc3BvbnNlIHRv IG1vZGlmeSB0aGUgcmVtb3RlIHRhcmdldCB3aGlsZQ0KPiAgICAqYW4gSU5WSVRFIHRyYW5zYWN0 aW9uIGlzIGluIHByb2dyZXNzKiwgYW5kIGl0IGlzIGEgVUFTIGZvciB0aGF0IA0KSU5WSVRFDQo+ ICAgIHRyYW5zYWN0aW9uLCBpdCAqTVVTVCBwbGFjZSB0aGUgc2FtZSB2YWx1ZSBpbnRvIHRoZSBD b250YWN0IGhlYWRlcioNCj4gKiAgIGZpZWxkIG9mIHRoZSAyeHggdG8gdGhlIElOVklURSB0aGF0 IGl0IHBsYWNlZCBpbnRvIHRoZSBVUERBVEUgDQpyZXF1ZXN0Kg0KPiAqICAgb3IgcmVzcG9uc2Uq Lg0KPiANCj4gU28sIGl0IHNob3VsZCBiZSB0aGUgbmV3IGFkZHJlc3MgaGVyZS4NCg0KWW91IG1p c3MgbXkgcG9pbnQuDQoNCkl0cyBub3QgYWJvdXQgdGhlIENvbnRhY3QgcGxhY2VkICppbiogdGhl IDJ4eCByZXNwb25zZS4NCkl0cyBhYm91dCB0aGUgYWRkcmVzcyB0byB3aGljaCB0aGUgcmVzcG9u c2UgaXMgZGVsaXZlcmVkLg0KVGhhdCBpcyBkaWN0YXRlZCBieSB0aGUgVmlhIGhlYWRlcnMgaW4g dGhlIElOVklURSByZXF1ZXN0Lg0KVGhvc2UgYXJlIG5vdCBhZmZlY3RlZCBieSB0aGUgdGFyZ2V0 IHJlZnJlc2guDQoNCiAgICAgICAgICAgICAgICAgVGhhbmtzLA0KICAgICAgICAgICAgICAgICBQ YXVsDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lw Y29yZSBtYWlsaW5nIGxpc3QNCnNpcGNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2Vj dXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBz b2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNv bW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBv YmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlz Y2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlz IGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFs IGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50 aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlz IGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3Nh Z2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUg aW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3Igdmly dXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 00022D0C482575F5_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBjYXRjaCB5b3VyIHBvaW50IG5vdy4g WW91IG1lYW4gdGhhdA0KdGhlIG1pZGRsZS1ib3gsIHN1Y2ggYXMgcHJveHksIGFkZGluZyBWaWEg aW4gdGhlIElOVklURS4gVGhlbiB0aGUgcHJveHkNCjwvZm9udD48Zm9udCBzaXplPTI+PHR0Pmlz IG5vdyBub24tZnVuY3Rpb25hbDwvdHQ+PC9mb250Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNl cmlmIj4sDQptYWtpbmcgdGhlIHJlc3BvbnNlIHVucmVhY2hhYmxlLjwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QnV0IEkgdGhpbmsgdGhlIHNvbHV0aW9u cyBzaG91bGQgbm90DQpiZSBpbiBwcm90b2NvbCBsZXZlbC4gVGhlIHNvbHV0aW9ucyBjYW4gYmU6 PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4xLiBGYXVs dCB0b2xlcmFuY2UuIChpZS4gY3Jhc2hpbmcgb2YNClAtQ1NDRi9TLUNTQ0YpPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4yLiBJc3N1ZSBuZXcgSU5WSVRF IHJlcGxhY2UgdGhlIG9sZA0Kb25lLiAoaWUuIGNoYW5naW5nIFAtQ1NDRik8L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcy48L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdhbzwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT08YnI+DQogWmlwICZuYnNwOyAmbmJzcDs6IDIxMDAxMjxicj4NCiBUZWwgJm5i c3A7ICZuYnNwOzogODcyMTE8YnI+DQogVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxi cj4NCiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbjxicj4NCj09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRo PTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0xIGZhY2U9 InNhbnMtc2VyaWYiPjxiPlBhdWwgS3l6aXZhdCAmbHQ7cGt5eml2YXRAY2lzY28uY29tJmd0Ozwv Yj4NCjwvZm9udD4NCjxicj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAm bmJzcDtzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+MjAwOS0wNy0xNiAwMDoxMzwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8 dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdo dD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRk Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5nYW8ueWFuZzJAenRlLmNvbS5jbjwvZm9u dD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFj ZT0ic2Fucy1zZXJpZiI+U0lQQ09SRSAmbHQ7c2lwY29yZUBpZXRmLm9yZyZndDssIE9LVU1VUkEN ClNoaW5qaSAmbHQ7c2hpbkBzb2Z0ZnJvbnQuY28uanAmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10 b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5S ZTogW3NpcGNvcmVdILTwuLQ6IFJlOiC08Li0OiBSZToNCiZuYnNwO7TwuLQ6IFJlOiAmbmJzcDtO ZXcgcmV2aXNpb24gb2YgdGhlIHJlLUlOVklURSBoYW5kbGluZyBkcmFmdDwvZm9udD48L3RhYmxl Pg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxi cj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+PGJyPg0KPGJyPg0K Z2FvLnlhbmcyQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KPGJyPg0KJmd0OyBJZiB0aGUgVUFDIGRl Y2lkZXMgdG8gZml4IHRoaXMgYnkgc2VuZGluZyBhbiBVUERBVEUgYmVmb3JlIGNvbXBsZXRpb24N Cm9mPGJyPg0KJmd0OyB0aGUgcmVJTlZJVEUsIHRoZW4gaXQgbWF5IHN1Y2NlZWQgaW4gZ2V0dGlu ZyB0aGUgcmVtb3RlIHRhcmdldCBjaGFuZ2VkPGJyPg0KJmd0OyBhdCB0aGUgVUFTLiBCdXQgdGhl ICpVQVMgaXMgc3RpbGwgb2JsaWdhdGVkIHRvIHNlbmQgdGhlIHJlbWFpbmluZzxicj4NCiZndDsg cmVzcG9uc2VzIHRvIHRoZSBhZGRyZXNzIGluIHRoZSBWaWEsIHdoaWNoIGlzIHRoZSBvbGQgYWRk cmVzcy4gKjxicj4NCiZndDsgPGJyPg0KJmd0OyBbR2FvXSBJdCBpcyBpbiBSRkMzMjYxLCBidXQg UkZDMzMxMSBoYXMgdGhlIGRlZmluaXRpb24gYXM6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IGZyb20g UkZDMzMxMTo8YnI+DQomZ3Q7IFVQREFURSBpcyBhIHRhcmdldCByZWZyZXNoIHJlcXVlc3QuIEFz IHNwZWNpZmllZCBpbiBSRkMgMzI2MSBbMV0sPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7dGhpcyBt ZWFucyB0aGF0IGl0IGNhbiB1cGRhdGUgdGhlIHJlbW90ZSB0YXJnZXQgb2YgYQ0KZGlhbG9nLiBJ ZiBhIFVBPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7dXNlcyBhbiBVUERBVEUgcmVxdWVzdCBvciBy ZXNwb25zZSB0byBtb2RpZnkgdGhlIHJlbW90ZQ0KdGFyZ2V0IHdoaWxlPGJyPg0KJmd0OyAmbmJz cDsgJm5ic3A7KmFuIElOVklURSB0cmFuc2FjdGlvbiBpcyBpbiBwcm9ncmVzcyosIGFuZCBpdCBp cyBhIFVBUw0KZm9yIHRoYXQgSU5WSVRFPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7dHJhbnNhY3Rp b24sIGl0ICpNVVNUIHBsYWNlIHRoZSBzYW1lIHZhbHVlIGludG8gdGhlIENvbnRhY3QNCmhlYWRl cio8YnI+DQomZ3Q7ICogJm5ic3A7IGZpZWxkIG9mIHRoZSAyeHggdG8gdGhlIElOVklURSB0aGF0 IGl0IHBsYWNlZCBpbnRvIHRoZSBVUERBVEUNCnJlcXVlc3QqPGJyPg0KJmd0OyAqICZuYnNwOyBv ciByZXNwb25zZSouPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFNvLCBpdCBzaG91bGQgYmUgdGhlIG5l dyBhZGRyZXNzIGhlcmUuPGJyPg0KPGJyPg0KWW91IG1pc3MgbXkgcG9pbnQuPGJyPg0KPGJyPg0K SXRzIG5vdCBhYm91dCB0aGUgQ29udGFjdCBwbGFjZWQgKmluKiB0aGUgMnh4IHJlc3BvbnNlLjxi cj4NCkl0cyBhYm91dCB0aGUgYWRkcmVzcyB0byB3aGljaCB0aGUgcmVzcG9uc2UgaXMgZGVsaXZl cmVkLjxicj4NClRoYXQgaXMgZGljdGF0ZWQgYnkgdGhlIFZpYSBoZWFkZXJzIGluIHRoZSBJTlZJ VEUgcmVxdWVzdC48YnI+DQpUaG9zZSBhcmUgbm90IGFmZmVjdGVkIGJ5IHRoZSB0YXJnZXQgcmVm cmVzaC48YnI+DQo8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KVGhhbmtzLDxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpQYXVsPGJyPg0KX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpzaXBjb3JlIG1haWxpbmcgbGlz dDxicj4NCnNpcGNvcmVAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NpcGNvcmU8YnI+DQo8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCjxicj48cHJl Pg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7 VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJz cDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhl Jm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJz cDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50 cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZu YnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNw O3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZu YnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4N ClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNt aXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDth bmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZu YnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7 dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZu YnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNw O2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmln aW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdz Jm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZu YnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0K VGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2Zv ciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtB bnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 00022D0C482575F5_=-- From HKaplan@acmepacket.com Wed Jul 15 17:25:27 2009 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 0AFA63A6CAC for ; Wed, 15 Jul 2009 17:25:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 LNax0UlwV-xx for ; Wed, 15 Jul 2009 17:25:25 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BAF713A6927 for ; Wed, 15 Jul 2009 17:25:25 -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.1.375.2; Wed, 15 Jul 2009 20:25:17 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Wed, 15 Jul 2009 20:25:17 -0400 From: Hadriel Kaplan To: Francois Audet , SIPCORE Date: Wed, 15 Jul 2009 20:25:15 -0400 Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoFRoWh2hBP5wjyQIWzHzootDGkMgASGu2gAAAGFAAAAfQZ4AAFHSTA Message-ID: References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.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] rfc4244bis: what is an AoR? 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, 16 Jul 2009 00:25:27 -0000 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Wednesday, July 15, 2009 5:57 PM >=20 > It is certainly true that not all AORs will be tagged. I don't disagree with you on that, but it worries me. The assumption I was= going on was that the H-I list could be reduced to the set only tagged wit= h "aor" and "mp"; would having entries not tagged "aor" which are in fact A= oR's break that? Or would those entries not matter either. (ie, would they= be AoR's from a technical aspect but not necessary for consideration in ap= p-specific uses of H-I entries?) -hadriel From pkyzivat@cisco.com Wed Jul 15 18:34:56 2009 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 7E5AF3A6B5B for ; Wed, 15 Jul 2009 18:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.363 X-Spam-Level: X-Spam-Status: No, score=-6.363 tagged_above=-999 required=5 tests=[AWL=0.236, 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 HxhL77kkN37f for ; Wed, 15 Jul 2009 18:34:55 -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 70E7D3A6CBE for ; Wed, 15 Jul 2009 18:34:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACsgXkpAZnmf/2dsb2JhbAC4X4gjkQwFgjSBVw X-IronPort-AV: E=Sophos;i="4.42,408,1243814400"; d="scan'208";a="86256260" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-5.cisco.com with ESMTP; 16 Jul 2009 01:35:13 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6G1ZD5A017932; Wed, 15 Jul 2009 21:35:13 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6G1Z9FJ001142; Thu, 16 Jul 2009 01:35:13 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 21:35:07 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 21:35:04 -0400 Message-ID: <4A5E83CB.4090701@cisco.com> Date: Wed, 15 Jul 2009 21:35:07 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Francois Audet References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2009 01:35:04.0884 (UTC) FILETIME=[A4FE7740:01CA05B5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1996; t=1247708113; x=1248572113; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20rfc4244bis=3A=20what=20is=2 0an=20AoR? |Sender:=20 |To:=20Francois=20Audet=20; bh=W5QGjPQGwWdKDayzUgF8syxoiHfTw4+o6h6pnfn6zbc=; b=MjT4Y2lIrGf9+l0+d6T0hIl0VQBmFDWQ46NzMbEFrQ28kpSlXjXkvOOg6w WCx3CXIjprHcfBbNEWZOiO0GN6Tdg895ROjq+27jihb05hYVl5yXP4B8Ne0x MMMHIzYWvd; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 16 Jul 2009 01:34:56 -0000 Francois Audet wrote: > "aor" means it is "an AOR that I own AND I used for a > location service dip". Hmm. the AND part is a bit troubling for me. In this context the tag isn't added unless there is a translation following it, so saying "AND I translated it" is ok by me. But IMO things can be AORs without ever using a location service. My example with alice and betty is one such case. Now perhaps we can argue that if you translate an R-URI (rather than adding a Route header), then by definition what you did was use a location service. If so then I guess I am ok, but that seems odd. Paul > I don't know if you view that as "different" or not. I guess > it's debatable. > > Again, in my humble opinion, a URI is an AOR only if the domain > responsible says so. And the way it knows it's an AOR is if > it can use it for the location service dip. > > If people don't agree with the statement, then perhaps we should > change the name of the parameter. > >> -----Original Message----- >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] >> Sent: Wednesday, July 15, 2009 16:25 >> To: Audet, Francois (SC100:3055) >> Cc: Hadriel Kaplan; SIPCORE >> Subject: Re: [sipcore] rfc4244bis: what is an AoR? >> >> If the tag is "aor" then I think it had better mean the same >> thing ans AOR or AoR. And in the process help to tighten up >> the definition of that. >> >> Having it mean "something like AoR, but not quite" is IMO a >> *really* bad idea. >> >> If it really is different than AoR, then it had better be >> called something else, and given a clear definition that >> justifies a new concept. >> >> AFAIK the point here is to identify the URI as an Address of >> Record. If we had a clear unambiguous definition of that, >> which was also consistent with common understanding of the >> term (by those who *ought* to know), then I don't think we >> would be having this discussion. >> >> Thanks, >> Paul > From fanyanping@huawei.com Wed Jul 15 18:47:56 2009 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 8954C3A6FA7 for ; Wed, 15 Jul 2009 18:47:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.705 X-Spam-Level: X-Spam-Status: No, score=0.705 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, FH_RELAY_NODNS=1.451, HELO_MISMATCH_COM=0.553, J_CHICKENPOX_34=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_65=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 Z2SQ6VgOcyUG for ; Wed, 15 Jul 2009 18:47:55 -0700 (PDT) Received: from szxga04-in.huawei.com (unknown [119.145.14.67]) by core3.amsl.com (Postfix) with ESMTP id F06FE3A6CAC for ; Wed, 15 Jul 2009 18:47:54 -0700 (PDT) Received: from huawei.com (szxga04-in [172.24.2.12]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMU0069YQCGHG@szxga04-in.huawei.com> for sipcore@ietf.org; Thu, 16 Jul 2009 09:48:16 +0800 (CST) Received: from huawei.com ([172.24.1.33]) by szxga04-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTP id <0KMU009PMQCGDB@szxga04-in.huawei.com> for sipcore@ietf.org; Thu, 16 Jul 2009 09:48:16 +0800 (CST) Received: from f00134301 ([10.85.29.39]) by szxml06-in.huawei.com (iPlanet Messaging Server 5.2 HotFix 2.14 (built Aug 8 2006)) with ESMTPA id <0KMU00IQFQCG02@szxml06-in.huawei.com> for sipcore@ietf.org; Thu, 16 Jul 2009 09:48:16 +0800 (CST) Date: Thu, 16 Jul 2009 09:48:16 +0800 From: fanyanping In-reply-to: <1ECE0EB50388174790F9694F77522CCF1EFE0971@zrc2hxm0.corp.nortel.com> To: 'Mary Barnes' Message-id: <006701ca05b7$7cca7ec0$271d550a@china.huawei.com> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 X-Mailer: Microsoft Office Outlook 11 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Thread-index: AcoFNlntOLq1SWlmTaKZc0Shyx0KmwAIHCywABYVBLA= Cc: sipcore@ietf.org Subject: Re: [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, 16 Jul 2009 01:47:56 -0000 Hi mary, my response are inline below [nancy] , thanks:) > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Wednesday, July 15, 2009 10:46 PM > To: fanyanping > Subject: RE: [sipcore] rfc4244bis > > Hi Nancy, > > My responses are inline below [MB]. Note, it does not look > like your original message went to the mailing list. Feel > free to respond to the mailing list. > > Regards, > Mary. > > -----Original Message----- > From: fanyanping [mailto:fanyanping@huawei.com] > Sent: Wednesday, July 15, 2009 5:24 AM > To: sipcore-bounces@ietf.org > Cc: Barnes, Mary (RICH2:AR00) > Subject: Re: [sipcore] rfc4244bis > > > Hi mary, > > I have read the draft of draft-barnes-sipcore-rfc4244bis-02.txt, there > are some issues i don't understand clearly, as blow: > 1, section 4.1 mentions > UAC that wants to ensure that privacy not be applied to its identity > MUST include a Privacy header with a priv- value of "none." > > but section 6.3.1(Privacy in the History-Info Header) doesn't has > relevant description, can a proxy include a Privacy header > with a priv- > value of "none" to a specifical hi-entry?? how to handle > the "none" in > different cases? > > [MB] We have not precluded the use of "none". We did have a > long debate > that the "none" in the hi-entry cannot override a privacy > header at the > request level. And, section 4.1 is discussing privacy at the request > level. So, I'm not sure what additional functionality you might get if > you added "none" to a specific hi-entry - in a sense that's > the default > IF there is no privacy header at the request level.[/MB] [nancy] I get it , thanks, review RFC3323, i find i make a mistake,:) > > 2,section 6.1 mentions > The hi-target is added for a hi-entry when it is first added in a > History-Info header field > > but in the previous draft, the hi-target is not added for a hi-entry > when it is first added in a History-Info header field, it is added to > the last hi-entry received in the request > > compare the two methods, what is the advantage of the first one? i see > that rosenberg's target-uri-delivery draft adopts the second one > > [MB] You are correct - we have changed the solution approach. > The reason > we've done so is that we want to capture the mechanism by > which the new > target was determined. At that point in time, as well, we > can determine > whether the previous target (i.e., the one in the incoming > Request) was > an "aor". So, we now tag the previous entry with the "aor" tag if > appropriate. The first method does add some complexity for the 3xx > handling, which is why you see a lot more text for that in the new > version. The second approach was trying to be consistent with how the > entries are tagged with the "Reason" header. But, we decided that by > tagging the new hi-entry we are actually capturing more (accurate) > information. We have tried to be precise in the text, so if you can > point out any text that makes this unclear, that would be > very helpful. > [/MB] [nancy] previously, the reason header and hi-target parameter in the hi-entry are matched, but now i need to find the next hi-entry's hi-target parameter when see a reason header,it makes me a a bit confused. :) > > ps: > can somebody give me an answer about the following questions? > I don't > find > the exact description in RFC 3261, thanks in advance!!! > > 1, how does the proxy handle the request which the > request-URI includes > a maddr parameter in different cases? > [MB] This is described in section 16.5 of RFC 3261: > "If the Request-URI of the request contains an maddr parameter, the > Request-URI MUST be placed into the target set as the only target > URI, and the proxy MUST proceed to Section 16.6." > > So, the only thing the proxy can do is to use the maddr parameter - > i.e., it's the new target. This hi-entry would be tagged as > "rt". And, > in this case the previous entry is NOT tagged as an "aor".[/MB] [nancy] you mean the request-URI should be replaced with the address in the maddr parameter?? or delete the maddr in the reqest-URI and add it to the route header?? > > > 2, If the domain of request-URI indicates is not that the proxy be > responsible for,what actions should the proxy be taken? > [MB] Again per section 16.5: > "If the domain of the Request-URI indicates a domain this > element is > not responsible for, the Request-URI MUST be placed into the target > set as the only target, and the element MUST proceed to the task of > Request Forwarding (Section 16.6)." > > So, the only thing the proxy can do is to forward the request to the > next hop proxy. This entry would be tagged as "rt". And, in > this case > the previous entry is NOT tagged as an "aor". [/MB] [nancy] you mean don't change the request-URI ,and add the address of next hop proxy to the route header,right? > > IMHO, the two cases are not retarget > [MB] In the document the term "retarget" is used in the most general > sense (as it was in RFC 4244) to cover all of these cases - i.e., > forwardings (ala "rt") as well as the other cases - basically > encompassing the process described in section 16.5 of RFC 3261. The > primary purpose that term really serves is to make the > document far less > wordy and easier to read.[/MB] > [nancy] I see the definition of 'retarget' in your draft as below: The term "retarget" is used in this document to refer both to the process of a Proxy Server/User Agent Client (UAC) changing a Uniform Resource Identifier (URI) in a request based on the rules for determining request targets as described in Section 16.5 of [RFC3261] and the subsequent forwarding of that request as described in section 16.6 of [RFC3261]. what 's the mean of "subsequent forwarding"?? i see that it needs to change the reqeust-URI first, right?? in this way, the ordinary forwarding can not be included in "retarget",such as the second question i describe as before. > > Best Regards. > > > nancy > > ******************************************************************* > This email and its attachments contain confidential information from > HUAWEI, which is intended only for the person or entity whose > address is > listed above. > Any use of the information contained herein in any way (including, but > not limited to, total or partial disclosure, reproduction, or > dissemination) by persons > other than the intended recipient(s) is prohibited. If you > receive this > e-mail in error, please notify the sender by phone or email > immediately > and delete it! > ******************************************************************* > From jmpolk@cisco.com Wed Jul 15 21:02:57 2009 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 A63CB3A6851; Wed, 15 Jul 2009 21:02:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.353 X-Spam-Level: X-Spam-Status: No, score=-6.353 tagged_above=-999 required=5 tests=[AWL=0.246, 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 x3Gam41rupcz; Wed, 15 Jul 2009 21:02:56 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 790143A6870; Wed, 15 Jul 2009 21:02:56 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwFABdDXkqrR7PD/2dsb2JhbACIQ69siCORDgWCNQ2BSQ X-IronPort-AV: E=Sophos;i="4.42,408,1243814400"; d="scan'208";a="214658636" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-1.cisco.com with ESMTP; 16 Jul 2009 04:01:50 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6G41ofc007410; Wed, 15 Jul 2009 21:01:50 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6G41olP018638; Thu, 16 Jul 2009 04:01:50 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 21:01:50 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.4.19]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Wed, 15 Jul 2009 21:01:49 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 15 Jul 2009 23:01:48 -0500 To: "Tschofenig, Hannes (NSN - FI/Espoo)" , "ext Elwell, John" , , "Brian Rosen" , From: "James M. Polk" In-Reply-To: <3D3C75174CB95F42AD6BCC56E5555B450187F547@FIESEXC015.nsn-in tra.net> References: <0D5F89FAC29E2C41B98A6A762007F5D00221E129@GBNTHT12009MSX.gb002.siemens.net> <3D3C75174CB95F42AD6BCC56E5555B450187F547@FIESEXC015.nsn-intra.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 16 Jul 2009 04:01:49.0889 (UTC) FILETIME=[252F9B10:01CA05CA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=5251; t=1247716910; x=1248580910; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20RE=3A=20[sipcore]=20Confusion=20over=20target=2 0inSIP=20location-conveyance=0A=20=20-=20and=20impact=20on=2 0ECRIT=20phonebcp |Sender:=20; bh=MQGWQn9fXuLSlswV0lMkTfs32A4v66oLudv3yeQziOA=; b=rXI9H38yGaSnL4xV8EFENzvHxH8w5EHnCVCB4BUBcoB/d13XE+IGctFYZH 0am9mXesYQwXqoFugaaoyhK16DUCM0a59hM8OrmmnQcrrY0jbN3SCnAqqb3I sbl+n1rH2L; Authentication-Results: sj-dkim-3; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Subject: Re: [sipcore] Confusion over target inSIP location-conveyance - and impact on ECRIT phonebcp 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, 16 Jul 2009 04:02:57 -0000 At 07:29 AM 7/14/2009, Tschofenig, Hannes (NSN - FI/Espoo) wrote: >You raise a very good point, John. > >My response would be that the answer to your question about what the >location actually refers to is given in the 'entity' attribute of the > element. The problem is only that we say in other places that >the info put into this field should be obfuscated: > > As noted in the "HTTP Enabled Location Delivery (HELD)" > [I-D.ietf-geopriv-http-location-delivery] Section 6.6: > > The LIS MUST NOT include any means of identifying the Device in > the PIDF-LO unless it is able to verify that the identifier is > correct and inclusion of identity is expressly permitted by a Rule > Maker. Therefore, PIDF parameters that contain identity are > either omitted or contain unlinked pseudonyms [RFC3693]. A > unique, unlinked presentity URI SHOULD be generated by the LIS for > the mandatory presence "entity" attribute of the PIDF document. > Optional parameters such as the "contact" element and the > "deviceID" element [RFC4479] are not used. Hannes - "identifying the Device" is something bad, and I agree with you. But -- that's not what the 'entity=' attribute is for. The 'entity= attribute' specifically is the presentity's URI (see RFC 4479). Geopriv doesn't exactly have presentities, we have targets - yet targets use a present document. So, while the device ID should not be included in the XML, the entity= has to be. BTW - the text from [I-D.ietf-geopriv-http-location-delivery] Section 6.6 confuses the two forms of identity, and needs to be changed. There's device ID -- which RFC 4479 talks about being the MAC address. There's entity= attribute, which is the presentity's identity, such as a Layer 7 AOR like URI. these are completely different. James >Ciao >Hannes > >PS: I also did a review some time back >http://www.ietf.org/mail-archive/web/geopriv/current/msg06955.html >I am not sure all my comments got addressed already :-) > > >-----Original Message----- > >From: sipcore-bounces@ietf.org > >[mailto:sipcore-bounces@ietf.org] On Behalf Of ext Elwell, John > >Sent: 14 July, 2009 09:40 > >To: James M. Polk; sipcore@ietf.org; Brian Rosen > >Subject: [sipcore] Confusion over target inSIP > >location-conveyance - and impact on ECRIT phonebcp > > > >In 4.2 it states: > >"The UAC can use whatever means it knows of to verify/refresh its > > location information before attempting a new request that includes > > location." > >"its location information" suggests that the UAC is the target. > > > >In 4.3.3 it states: > >"This document gives no guidance how this is accomplished, given the > > number of ways a UAC can learn its location" > >which suggests similar. > > > >Similarly in 6.1: > >"If a UAC does not learn and store its location locally (a GPS chip) > > or from the network (DHCP or LLDP-MED), the UAC MAY learn its LbyR > > URI (from DHCP for example)." > >Which suggests that a UAC inserts its location, not some other > >location. > > > >And later in 6.1: > >"If a UAC has already conveyed location in the original request of a > > transaction, and wants to update its location information ..." > > > >In 6.2: > >"If the LbyR URI is > > sip:, sips: or pres:, and the UAS wants to learn the UAC's > >location," > > > >In 6.2.1: > >"This > > means the SIP server is including its version of where it thinks the > > UAC is, geographically." > > > >In 8: > >"Conveyance of physical location of a UAC raises privacy concerns" > > > >and: > >"In cases where a session set-up is > > retargeted based on the location of the UAC initiating the call or > > SIP MESSAGE," > > > >All these many examples illustrate an implication that the > >location target is the UAC. I am sure there are other places too. > > > >I found a couple of places that contradict this. In 6.2 it states: > >"If there > > is more than one PIDF-LO with different Target identifiers, then > > the UAC is merely telling the UAS where more than one Target is, and > > there should not be any conflict." > > > >I think there are other places that mention locations of > >multiple targets in a request, implying they cannot all be the > >location of the UAC. > > > >And in 6.2.1 it states: > >"The Location Target identified in > > the PIDF-LO may or may not be the location inserter, or the > > generator of the request (the UAC or SIP server)." > > > >So we have inconsistency as to whether a conveyed location is > >that of they UAC or not. > > > >One document that relies on location-conveyance is ECRIT's > >phonebcp. In there, I cannot find any reference to a routing > >entity looking to see whether a conveyed location has the > >caller as target or not. It just assumes that this is the > >case. So if we were to agree that a conveyed location is not > >necessarily the location of the UAC, this will have impact on phonebcp. > > > >John > > > >_______________________________________________ > >sipcore mailing list > >sipcore@ietf.org > >https://www.ietf.org/mailman/listinfo/sipcore > > From shin@softfront.co.jp Wed Jul 15 22:24:16 2009 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 5B70F3A657C for ; Wed, 15 Jul 2009 22:24:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.994 X-Spam-Level: ** X-Spam-Status: No, score=2.994 tagged_above=-999 required=5 tests=[AWL=0.261, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_62=0.6, RELAY_IS_221=2.222, UNPARSEABLE_RELAY=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 OT+6C4r4Rq3p for ; Wed, 15 Jul 2009 22:24:15 -0700 (PDT) Received: from mail2.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with SMTP id AB3843A6ACF for ; Wed, 15 Jul 2009 22:24:09 -0700 (PDT) Received: from softfront.co.jp by mail2.softfront.co.jp id AA04332 ; 16 Jul 2009 13:29:26 +0900 From: OKUMURA Shinji To: SIPCORE Date: Thu, 16 Jul 2009 13:29:24 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.18 (WinNT,501) In-Reply-To: References: Message-Id: <14CA05CDFF6935shin@softfront.co.jp> Cc: gao.yang2@zte.com.cn Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 16 Jul 2009 05:24:16 -0000 Hi, Gao I seem you don't still catch his point. He has been talking about a Via header of not a proxy but an UAC. the server transaction send a responce of the reINVITE to the old address of an UAC, even if UPDATE request had refreshed UAC's local target(ie. IP address). It is a basic rule described in RFC3261. RFC3311 does NOT change it. Regards, Shinji gao.yang2@zte.com.cn >Hi, > >I catch your point now. You mean that the middle-box, such as proxy, >adding Via in the INVITE. Then the proxy is now non-functional, making the >response unreachable. > >But I think the solutions should not be in protocol level. The solutions >can be: > >1. Fault tolerance. (ie. crashing of P-CSCF/S-CSCF) > >2. Issue new INVITE replace the old one. (ie. changing P-CSCF) > >Thanks. > >Gao > >=================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn >=================================== > > > >Paul Kyzivat > >gao.yang2@zte.com.cn wrote: > >> If |he UAC decides to fix this by sending an UPDATE before completion of >> the reINVITE, then it may succeed in getting the remote target changed >> at the UAS. But the *UAS is still obligated to send the remaining >> responses to the address in the Via, which is the old address. * >> >> [Gao] It is in RFC3261, but RFC3311 has the definition as: >> >> from RFC3311: >> UPDATE is a target refresh request. As specified in RFC 3261 [1], >> this means that it can update the remote target of a dialog. If a UA >> uses an UPDATE request or response to modify the remote target while >> *an INVITE transaction is in progress*, and it is a UAS for that INVITE >> transaction, it *MUST place the same value into the Contact header* >> * field of the 2xx to the INVITE that it placed into the UPDATE request* >> * or response*. >> >> So, it should be the new address here. > >You miss my point. > >Its not about the Contact placed *in* the 2xx response. >Its about the address to which the response is delivered. >That is dictated by the Via headers in the INVITE request. >Those are not affected by the target refresh. > > Thanks, > Paul From ietf.hanserik@gmail.com Thu Jul 16 00:03:03 2009 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 57D583A6A2C for ; Thu, 16 Jul 2009 00:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.464 X-Spam-Level: X-Spam-Status: No, score=-2.464 tagged_above=-999 required=5 tests=[AWL=0.134, 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 jY04yR3BDEG6 for ; Thu, 16 Jul 2009 00:03:01 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 48D363A68ED for ; Thu, 16 Jul 2009 00:03:00 -0700 (PDT) Received: by ewy26 with SMTP id 26so4594607ewy.37 for ; Thu, 16 Jul 2009 00:01:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=g7C3G7Aas6P/FsWmUxKzhMuDRU6KNxvR5N8eANM9bVY=; b=KZGd3ZWXCYIf0P/by0HIuyxYj/KhZUFSux8OvzyPULCSOy0LAvm2nAxIuE/Fwf4Ha/ Pu3cIpJt7QEE8hOwYhjgtZwCFDAWrgq8Sz7f2bdvziAiu5yPyQqkm1tcOf7rgxoDTjPl +DUuzFu+mJPVJeivZoGsqNkI2I9waVfHHkT9g= 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=Oqr3G2fdNCPRBgScUMsozojYTNc/NDrdkZssnEeNe8MYfAddyNTAZbWfbtN4HycGd/ eS92J4nc5zWrVDhzhC8fYunBCwhwKd1IuHZj49ISzUwFlibiC6Z7/NJ9Z4C2g5D/Lc6H E8G1kTBDmDNTgp0pjRg44C7CV7uuvJEiVKN3w= MIME-Version: 1.0 Received: by 10.211.199.11 with SMTP id b11mr9235519ebq.57.1247727690540; Thu, 16 Jul 2009 00:01:30 -0700 (PDT) In-Reply-To: References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> Date: Thu, 16 Jul 2009 09:01:30 +0200 Message-ID: <9ae56b1e0907160001u54c095e8o3761f9294a36a456@mail.gmail.com> From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=0015175933a6c56a7a046ecd3dae Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 16 Jul 2009 07:03:03 -0000 --0015175933a6c56a7a046ecd3dae Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit inline... /Hans Erik van Elburg On Thu, Jul 16, 2009 at 2:19 AM, Hadriel Kaplan wrote: > > > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Wednesday, July 15, 2009 5:57 PM > > > > But I can't think of cases where the tag "aor" would not be applied > > to somthing that is not an AOR. > > I think there are cases where an "aor" tag would be applied to something > that's not an AoR, and probably vice-versa. But maybe I'm not thinking > about this quite right. > > Example-1: ENUM is used widely, as both a means of performing "pure" E.164 > number to AoR resolution, Number Portability, inter-domain routing, > intra-domain routing, and even registered contact routing. An ENUM query > can be described as a location-service lookup. Proxies performing an ENUM > query don't necessarily know what type of URI they are performing that query > for. So if they get a request for "sip:+1234567890@sp.com" > and do the query and the result makes it change it for inter-domain routing, > then the original URI was not a AoR; if the result made it send it to a > UAS/gateway directly, then it was an AoR. Right? Since the proxy won't > know when, it will have to tag it as AoR every time, no? In IMS this would be completely clear to me as not being one qualifying for an aor tag, as it is proxy that acts on behalf of the originating user that would perform the ENUM dip to be able to know where to route the request. First when it enters the proxy(-instance) that acts on behalf of a terminating user the aor tagging would start. As for genuine SIP proxies this distinction does not seem to be specified we are having this debate. > > Example-2: it is not rare for the req-uri sent to the proxy with which it > does a lookup to not actually be the AoR per se - for example, the proxy may > receive a req-uri of "sip:+123456790@proxy1.sp.com". > It resolves this to the registered contact for the "real" AoR of " > sip:234567890@sp.com " - by "real" I mean the one > registered and known by the UAS. Now one could say the proxy should have > added that real AoR in an H-I entry as another intermediate/internal step > before resolution, because in theory the URI used for the resolution was the > real AoR not the req-uri received; but that's getting into the internal > mechanics of how the proxy was implemented. For example the proxy may have > done an ENUM lookup using only the username, and not know the "real" AoR's > domain portion was different. It was authoritative for "proxy1.sp.com" > (it's also authoritative for "sp.com"), and it did a location lookup using > "sip:+123456790@proxy1.sp.com ", so all > the conditions were met - but it's n > ot the actual AoR the UAS needs to see, nor what we would consider a > "classic" AoR (not what one would put on a business card, for example). No? No ;-) You would not perform an ENUM dip for a SIP URI destined for your domain, would you? Also H-I is tracking internal retargets for some reason. > > > -hadriel > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --0015175933a6c56a7a046ecd3dae Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable inline...
/Hans Erik van Elburg


On Thu, Jul 16, 2009 at 2:19 AM, Hadriel= Kaplan <HKa= plan@acmepacket.com> wrote:


> -----Original Message-----
> From: Francois Audet [mailto:audet= @nortel.com]
> Sent: Wednesday, July 15, 2009 5:57 PM
>
> But I can't think of cases where the tag "aor" would not= be applied
> to somthing that is not an AOR.

I think there are cases where an "aor" tag would be applied= to something that's not an AoR, and probably vice-versa. =A0But maybe = I'm not thinking about this quite right.

Example-1: ENUM is used widely, as both a means of performing "pure&qu= ot; E.164 number to AoR resolution, Number Portability, inter-domain routin= g, intra-domain routing, and even registered contact routing. =A0An ENUM qu= ery can be described as a location-service lookup. =A0Proxies performing an= ENUM query don't necessarily know what type of URI they are performing= that query for. =A0So if they get a request for "sip:+1234567890@sp.com" and do the query= and the result makes it change it for inter-domain routing, then the origi= nal URI was not a AoR; if the result made it send it to a UAS/gateway direc= tly, then it was an AoR. =A0Right? =A0Since the proxy won't know when, = it will have to tag it as AoR every time, no?

In IMS this would be completely clear to me as not bein= g one qualifying for an aor tag, as it is proxy that acts on behalf of the = originating user that would perform the ENUM dip to be able to know where t= o route the request. First when it enters the proxy(-instance) that acts on= behalf of a terminating user the aor tagging would start.

As for genuine SIP proxies =A0this distinction does not= seem to be specified we are having this debate.
=A0

Example-2: it is not rare for the req-uri sent to the proxy with which it d= oes a lookup to not actually be the AoR per se - for example, the proxy may= receive a req-uri of "sip:+123456790@proxy1.sp.com". =A0It resolves this to the reg= istered contact for the "real" AoR of "sip:234567890@sp.com" - by "real" I= mean the one registered and known by the UAS. =A0Now one could say the pro= xy should have added that real AoR in an H-I entry as another intermediate/= internal step before resolution, because in theory the URI used for the res= olution was the real AoR not the req-uri received; but that's getting i= nto the internal mechanics of how the proxy was implemented. =A0For example= the proxy may have done an ENUM lookup using only the username, and not kn= ow the "real" AoR's domain portion was different. =A0It was a= uthoritative for "p= roxy1.sp.com" (it's also authoritative for "sp.com"), and it did a location loo= kup using "sip:+12= 3456790@proxy1.sp.com", so all the conditions were met - but it= 9;s n
=A0ot the actual AoR the UAS needs to see, nor what we would consider a &qu= ot;classic" AoR (not what one would put on a business card, for exampl= e). =A0No?

No ;-)

You would not perform an ENUM dip for a SIP URI destined for your domain, w= ould you?
Also H-I is tracking internal retargets for some reason= .

=A0


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

--0015175933a6c56a7a046ecd3dae-- From ietf.hanserik@gmail.com Thu Jul 16 00:35:36 2009 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 0B6223A68CB for ; Thu, 16 Jul 2009 00:35:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.448 X-Spam-Level: X-Spam-Status: No, score=-2.448 tagged_above=-999 required=5 tests=[AWL=0.150, 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 LClxz6FFe7aP for ; Thu, 16 Jul 2009 00:35:34 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.27]) by core3.amsl.com (Postfix) with ESMTP id E57FE3A6774 for ; Thu, 16 Jul 2009 00:35:33 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so1272425eye.31 for ; Thu, 16 Jul 2009 00:33:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=lolp0UXRn0vn24sDgP3EQL1Xj+vQMKEe+M0q2WgG+rY=; b=NL5QCUnT2PBCcgLATJRVy8oQIrtLbZwEXj0DFXUImSRDsaQNVsGMX/1eU4jTFS3wpT sSONGGLL8dlZt2WewltzaUGusbscq5FXEQsLePYlgCikmrH70OHrYBvTYo81aS9wucrT tnxzSsi96Sy0oSvdDsyNt8tPPMQoKy8mYuAYE= 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=wQey0N1PP+Z6glsCmEkO1gPznoy0M70VvIVwU5mbzQc52amUyqWRUX4PeSudpGgNRl gcX1XLvF8ufGNWeKwEiJTQIXm8+j0avPeckiU6Brg2Pn0dHm5W/RpmglyahDQR7iPeCf Err+QRaPu5Nuz6Sg25iuSBF7/87UhlKKnsnkM= MIME-Version: 1.0 Received: by 10.210.53.1 with SMTP id b1mr9298838eba.62.1247729586038; Thu, 16 Jul 2009 00:33:06 -0700 (PDT) In-Reply-To: <4A5E83CB.4090701@cisco.com> References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com> <4A5E83CB.4090701@cisco.com> Date: Thu, 16 Jul 2009 09:33:05 +0200 Message-ID: <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> From: Hans Erik van Elburg To: Paul Kyzivat Content-Type: multipart/alternative; boundary=0015174c3f0ac06aa8046ecdaef7 Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 16 Jul 2009 07:35:36 -0000 --0015174c3f0ac06aa8046ecdaef7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'd like to understand what is wrong with the RFC3261 definition of AOR? "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that points to a domain with a location service that can map the URI to another URI where the user might be available. Typically, the location service is populated through registrations. An AOR is frequently thought of as the "public address" of the user." Currently I think it is the best we have, can we agree to adopt that as leading for the tagging procedure? /Hans Erik van Elburg On Thu, Jul 16, 2009 at 3:35 AM, Paul Kyzivat wrote: > > > Francois Audet wrote: > >> "aor" means it is "an AOR that I own AND I used for a >> location service dip". >> > > Hmm. the AND part is a bit troubling for me. > In this context the tag isn't added unless there is a translation following > it, so saying "AND I translated it" is ok by me. > But IMO things can be AORs without ever using a location service. My > example with alice and betty is one such case. > > Now perhaps we can argue that if you translate an R-URI (rather than adding > a Route header), then by definition what you did was use a location service. > If so then I guess I am ok, but that seems odd. > > Paul > > > I don't know if you view that as "different" or not. I guess >> it's debatable. >> >> Again, in my humble opinion, a URI is an AOR only if the domain >> responsible says so. And the way it knows it's an AOR is if it can use it >> for the location service dip. >> If people don't agree with the statement, then perhaps we should >> change the name of the parameter. >> >>> -----Original Message----- >>> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Wednesday, July 15, >>> 2009 16:25 >>> To: Audet, Francois (SC100:3055) >>> Cc: Hadriel Kaplan; SIPCORE >>> Subject: Re: [sipcore] rfc4244bis: what is an AoR? >>> >>> If the tag is "aor" then I think it had better mean the same thing ans >>> AOR or AoR. And in the process help to tighten up the definition of that. >>> >>> Having it mean "something like AoR, but not quite" is IMO a *really* bad >>> idea. >>> >>> If it really is different than AoR, then it had better be called >>> something else, and given a clear definition that justifies a new concept. >>> >>> AFAIK the point here is to identify the URI as an Address of Record. If >>> we had a clear unambiguous definition of that, which was also consistent >>> with common understanding of the term (by those who *ought* to know), then I >>> don't think we would be having this discussion. >>> >>> Thanks, >>> Paul >>> >> >> _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --0015174c3f0ac06aa8046ecdaef7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'd like to understand what is wrong with the RFC3261 definition of AOR= ?=A0

"Address-of-Record: An address-of-record (AOR)= is a SIP or SIPS URI that points to a domain with a location service that = can map the URI to another URI where the user might be available. Typically= , the location service is populated through registrations. An AOR is freque= ntly thought of as the "public address" of the user."

Currently I think it is the best we have, can we agree = to adopt that as leading for the tagging procedure?

/Hans Erik van Elburg

On Thu, Jul 16, 2009 at 3:35 AM, Paul Kyziva= t <pkyzivat@cisc= o.com> wrote:


Francois Audet wrote:
"aor" means it is "an AOR that I own AND I used for a
location service dip".

Hmm. the AND part is a bit troubling for me.
In this context the tag isn't added unless there is a translation follo= wing it, so saying "AND I translated it" is ok by me.
But IMO things can be AORs without ever using a location service. My exampl= e with alice and betty is one such case.

Now perhaps we can argue that if you translate an R-URI (rather than adding= a Route header), then by definition what you did was use a location servic= e. If so then I guess I am ok, but that seems odd.

=A0 =A0 =A0 =A0Paul


I don't know if you view that as "different" or not. I guess<= br> it's debatable.

Again, in my humble opinion, a URI is an AOR only if the domain
responsible says so. And the way it knows it's an AOR is if it can use = it for the location service dip.
If people don't agree with the statement, then perhaps we should
change the name of the parameter. =A0
-----Original Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Wednesday, July 15, 2009 16:25
To: Audet, Francois (SC100:3055)
Cc: Hadriel Kaplan; SIPCORE
Subject: Re: [sipcore] rfc4244bis: what is an AoR?

If the tag is "aor" then I think it had better mean the same thin= g ans AOR or AoR. And in the process help to tighten up the definition of t= hat.

Having it mean "something like AoR, but not quite" is IMO a *real= ly* bad idea.

If it really is different than AoR, then it had better be called something = else, and given a clear definition that justifies a new concept.

AFAIK the point here is to identify the URI as an Address of Record. If we = had a clear unambiguous definition of that, which was also consistent with = common understanding of the term (by those who *ought* to know), then I don= 't think we would be having this discussion.

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

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

--0015174c3f0ac06aa8046ecdaef7-- From ietf.hanserik@gmail.com Thu Jul 16 00:56:36 2009 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 A1CE33A6A5D for ; Thu, 16 Jul 2009 00:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.478 X-Spam-Level: X-Spam-Status: No, score=-2.478 tagged_above=-999 required=5 tests=[AWL=0.120, 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 EeRJQU9y9fWi for ; Thu, 16 Jul 2009 00:56:35 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id 84FDD3A67EA for ; Thu, 16 Jul 2009 00:56:35 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so1274803eye.31 for ; Thu, 16 Jul 2009 00:56:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=45b9fiM9jXkp+ZneDJO+Hczgz9HdKKxt46ldDEC1Aoo=; b=QpuYzzJxJePR8uoZ7m7xPxltU1DMW3em4Y5+s0m2MaL02MuQp6dfHeBHuhQLbgazTk 8ch+pPp7FVkTYZm0Nol4DXRdUHefpqy8xbCltAk1qXaL/y8aWJDw3HCOCRWVnf10V8Yh MM1/79eiXSkb/83BTRBDwrbn58I9P2BWrVAHY= 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=AXo7f2Fq1Gt9OWk2DCCRXs8qRMm2qSSGYY2KZUvzPEF21o9QCQOBdev8lMSLWS6JwG bAbLlUxAAAcsVRkO6EnraK8Rybw93cNnxFBTPvoTwx4BbkCHjyRDN2S0SvGySXLj3n4q IuegFvyuzA9gysYLaT/I+Y8jlzvWN42Tn4ELk= MIME-Version: 1.0 Received: by 10.210.63.18 with SMTP id l18mr9385184eba.71.1247730969651; Thu, 16 Jul 2009 00:56:09 -0700 (PDT) In-Reply-To: References: Date: Thu, 16 Jul 2009 09:56:09 +0200 Message-ID: <9ae56b1e0907160056vd2be5ael217db76f7f69ab16@mail.gmail.com> From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=0015174c43c238a97a046ece0188 Cc: SIPCORE , "draft-barnes-sipcore-rfc4244bis@tools.ietf.org" Subject: Re: [sipcore] rfc4244bis: backwards compatibility 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, 16 Jul 2009 07:56:36 -0000 --0015174c43c238a97a046ece0188 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I still do not like this implicit versioning requirement on the tags. Either we do versioning or we don't, but do not fold it in to the meaning of the other tags. Get the feeling that the only reason that the fluff tags (cc, rc, rt) exist is because of this implicit versioning requirement. I vote for no versioning. Do n't thisnk that it is required. /Hans Erik van Elburg On Thu, Jul 16, 2009 at 12:47 AM, Hadriel Kaplan wrote: > This tagging allows for distinguishing > entries that were added by an [RFC4244] entity, versus one that was > added by an entity conforming to this specification. > --0015174c43c238a97a046ece0188 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I still do not like this implicit versioning requirement on the tags. Eithe= r we do versioning or we don't, but do not fold it in to the meaning of= the other tags.

Get the feeling that the only reason th= at the fluff tags (cc, rc, rt) exist is because of this implicit versioning= requirement.

I vote for no versioning. Do n't thisnk that it is = required.

/Hans Erik van Elburg


On Thu, Jul 16, 2009 at 12:47 AM, Hadrie= l Kaplan <HK= aplan@acmepacket.com> wrote:
This tagging allows for distinguishing
=A0 entries that were added by an [RFC4244] entity, versus one that was =A0 added by an entity conforming to this specification.

--0015174c43c238a97a046ece0188-- From john.elwell@siemens-enterprise.com Thu Jul 16 01:05:14 2009 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 72B043A6A5D for ; Thu, 16 Jul 2009 01:05:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 LrCvAO+GjFtH for ; Thu, 16 Jul 2009 01:05:13 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 456DB3A6A2C for ; Thu, 16 Jul 2009 01:05:06 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KMV0036Z7RHJ6@siemenscomms.co.uk> for sipcore@ietf.org; Thu, 16 Jul 2009 09:04:29 +0100 (BST) Date: Thu, 16 Jul 2009 09:04:27 +0100 From: "Elwell, John" In-reply-to: <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> To: Hans Erik van Elburg , Paul Kyzivat Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoF6CVRUPlMKkb7SrWHqBtgx6wCgwAAvgVQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com> <4A5E83CB.4090701@cisco.com> <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 16 Jul 2009 08:05:14 -0000 >From that definition, I believe every entry in H-I except the last (i.e., the Request-URI received by the UAS) would be an AOR. If not, the request would not have got this far, because it would not have found a domain that could route it. Is my understanding correct? If so, what is the point of the "AOR" indicator in H-I, if all but the last are marked "AOR"? Perhaps there is one exception to the assumption above. A URI containing an IP address would perhaps not be considered an AOR, because it does not point to a domain. John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Hans Erik van Elburg > Sent: 16 July 2009 08:33 > To: Paul Kyzivat > Cc: SIPCORE; Hadriel Kaplan > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >=20 > I'd like to understand what is wrong with the RFC3261=20 > definition of AOR? =20 >=20 > "Address-of-Record: An address-of-record (AOR) is a SIP or=20 > SIPS URI that points to a domain with a location service that=20 > can map the URI to another URI where the user might be=20 > available. Typically, the location service is populated=20 > through registrations. An AOR is frequently thought of as the=20 > "public address" of the user." >=20 > Currently I think it is the best we have, can we agree to=20 > adopt that as leading for the tagging procedure? >=20 > /Hans Erik van Elburg >=20 >=20 > On Thu, Jul 16, 2009 at 3:35 AM, Paul Kyzivat=20 > wrote: >=20 >=20 >=20 >=20 > Francois Audet wrote: > =09 >=20 > "aor" means it is "an AOR that I own AND I used for a > location service dip".=20 > =09 >=20 >=20 > Hmm. the AND part is a bit troubling for me. > In this context the tag isn't added unless there is a=20 > translation following it, so saying "AND I translated it" is ok by me. > But IMO things can be AORs without ever using a=20 > location service. My example with alice and betty is one such case. > =09 > Now perhaps we can argue that if you translate an R-URI=20 > (rather than adding a Route header), then by definition what=20 > you did was use a location service. If so then I guess I am=20 > ok, but that seems odd. > =09 > Paul=20 >=20 >=20 >=20 > I don't know if you view that as "different" or=20 > not. I guess > it's debatable. > =09 > Again, in my humble opinion, a URI is an AOR=20 > only if the domain > responsible says so. And the way it knows it's=20 > an AOR is if it can use it for the location service dip.=20 > If people don't agree with the statement, then=20 > perhaps we should > change the name of the parameter. =20 > =09 >=20 > -----Original Message----- > From: Paul Kyzivat=20 > [mailto:pkyzivat@cisco.com] Sent: Wednesday, July 15, 2009 16:25 > To: Audet, Francois (SC100:3055) > Cc: Hadriel Kaplan; SIPCORE > Subject: Re: [sipcore] rfc4244bis: what=20 > is an AoR? > =09 > If the tag is "aor" then I think it had=20 > better mean the same thing ans AOR or AoR. And in the process=20 > help to tighten up the definition of that. > =09 > Having it mean "something like AoR, but=20 > not quite" is IMO a *really* bad idea. > =09 > If it really is different than AoR,=20 > then it had better be called something else, and given a=20 > clear definition that justifies a new concept. > =09 > AFAIK the point here is to identify the=20 > URI as an Address of Record. If we had a clear unambiguous=20 > definition of that, which was also consistent with common=20 > understanding of the term (by those who *ought* to know),=20 > then I don't think we would be having this discussion. > =09 > Thanks, > Paul > =09 >=20 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > =09 >=20 >=20 >=20 From gao.yang2@zte.com.cn Thu Jul 16 01:29:49 2009 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 B569028C153 for ; Thu, 16 Jul 2009 01:29:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.763 X-Spam-Level: X-Spam-Status: No, score=-93.763 tagged_above=-999 required=5 tests=[AWL=-1.573, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_62=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 Tu7OgtGoN+TF for ; Thu, 16 Jul 2009 01:29:48 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 961183A6C61 for ; Thu, 16 Jul 2009 01:29:44 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 91101727820181; Thu, 16 Jul 2009 12:44:36 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 85804.5385067488; Thu, 16 Jul 2009 12:50:31 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n6G4vZWo061785; Thu, 16 Jul 2009 12:57:35 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <14CA05CDFF6935shin@softfront.co.jp> To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 16 Jul 2009 12:57:23 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-16 12:57:32, Serialize complete at 2009-07-16 12:57:32 Content-Type: multipart/alternative; boundary="=_alternative 001B3AC4482575F5_=" X-MAIL: mse1.zte.com.cn n6G4vZWo061785 Cc: SIPCORE Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ICBOZXcgcmV2aXNpb24gb2YgdGhlIHJl?= =?gb2312?b?LUlOVklURSBoYW5kbGluZyBkcmFmdA==?= 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, 16 Jul 2009 08:29:49 -0000 This is a multipart message in MIME format. --=_alternative 001B3AC4482575F5_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNClRoZW4sIGl0IHNlZW1zIGEgcmVhbCBwcm9ibGVtIGZvciBpbmNvbnNpc3RlbmN5IG9m IHJlZnJlc2hlZCB0YXJnZXQgYW5kIA0KZGlzcGF0Y2hpbmcgcnVsZSBieSBWaWEuIA0KDQpQYXVs IGhhcyBnaXZlbiBvdXQgc29tZSBCQ1Agd2F5LiBEbyB5b3UgaGF2ZSBzb21lIHRob3VnaHQgYWJv dXQgc29sdXRpb25zIA0KaW4gdGhlb3J5Pw0KDQpUaGFua3MuDQoNCkdhbw0KDQo9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PQ0KIFppcCAgICA6IDIxMDAxMg0KIFRlbCAgICA6IDg3 MjExDQogVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCiBlX21haWwgOiBnYW8ueWFuZzJAenRl LmNvbS5jbg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQoNCk9LVU1V UkEgU2hpbmppIDxzaGluQHNvZnRmcm9udC5jby5qcD4gDQoyMDA5LTA3LTE2IDEyOjI5DQoNCsrV vP7Iyw0KU0lQQ09SRSA8c2lwY29yZUBpZXRmLm9yZz4NCrOty80NCmdhby55YW5nMkB6dGUuY29t LmNuLCBQYXVsIEt5eml2YXQgPHBreXppdmF0QGNpc2NvLmNvbT4NCtb3zOINClJlOiBbc2lwY29y ZV0gTmV3IHJldmlzaW9uIG9mIHRoZSByZS1JTlZJVEUgaGFuZGxpbmcgZHJhZnQNCg0KDQoNCg0K DQoNCkhpLCBHYW8NCg0KSSBzZWVtIHlvdSBkb24ndCBzdGlsbCBjYXRjaCBoaXMgcG9pbnQuIEhl IGhhcyBiZWVuIHRhbGtpbmcgYWJvdXQNCmEgVmlhIGhlYWRlciBvZiBub3QgYSBwcm94eSBidXQg YW4gVUFDLiB0aGUgc2VydmVyIHRyYW5zYWN0aW9uIHNlbmQNCmEgcmVzcG9uY2Ugb2YgdGhlIHJl SU5WSVRFIHRvIHRoZSBvbGQgYWRkcmVzcyBvZiBhbiBVQUMsIGV2ZW4gaWYNClVQREFURSByZXF1 ZXN0IGhhZCByZWZyZXNoZWQgVUFDJ3MgbG9jYWwgdGFyZ2V0KGllLiBJUCBhZGRyZXNzKS4NCg0K SXQgaXMgYSBiYXNpYyBydWxlIGRlc2NyaWJlZCBpbiBSRkMzMjYxLiBSRkMzMzExIGRvZXMgTk9U IGNoYW5nZSBpdC4NCg0KUmVnYXJkcywNClNoaW5qaQ0KDQpnYW8ueWFuZzJAenRlLmNvbS5jbg0K PkhpLA0KPg0KPkkgY2F0Y2ggeW91ciBwb2ludCBub3cuIFlvdSBtZWFuIHRoYXQgdGhlIG1pZGRs ZS1ib3gsIHN1Y2ggYXMgcHJveHksIA0KPmFkZGluZyBWaWEgaW4gdGhlIElOVklURS4gVGhlbiB0 aGUgcHJveHkgaXMgbm93IG5vbi1mdW5jdGlvbmFsLCBtYWtpbmcgDQp0aGUgDQo+cmVzcG9uc2Ug dW5yZWFjaGFibGUuDQo+DQo+QnV0IEkgdGhpbmsgdGhlIHNvbHV0aW9ucyBzaG91bGQgbm90IGJl IGluIHByb3RvY29sIGxldmVsLiBUaGUgc29sdXRpb25zIA0KPmNhbiBiZToNCj4NCj4xLiBGYXVs dCB0b2xlcmFuY2UuIChpZS4gY3Jhc2hpbmcgb2YgUC1DU0NGL1MtQ1NDRikNCj4NCj4yLiBJc3N1 ZSBuZXcgSU5WSVRFIHJlcGxhY2UgdGhlIG9sZCBvbmUuIChpZS4gY2hhbmdpbmcgUC1DU0NGKQ0K Pg0KPlRoYW5rcy4NCj4NCj5HYW8NCj4NCj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KPiBaaXAgICAgOiAyMTAwMTINCj4gVGVsICAgIDogODcyMTENCj4gVGVsMiAgIDooKzg2 KS0wMjUtNTI4NzcyMTENCj4gZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj49PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPg0KPg0KPg0KPlBhdWwgS3l6aXZhdCA8cGt5 eml2YXRAY2lzY28uY29tPiANCj4NCj5nYW8ueWFuZzJAenRlLmNvbS5jbiB3cm90ZToNCj4NCj4+ IElmIHxoZSBVQUMgZGVjaWRlcyB0byBmaXggdGhpcyBieSBzZW5kaW5nIGFuIFVQREFURSBiZWZv cmUgY29tcGxldGlvbiANCm9mDQo+PiB0aGUgcmVJTlZJVEUsIHRoZW4gaXQgbWF5IHN1Y2NlZWQg aW4gZ2V0dGluZyB0aGUgcmVtb3RlIHRhcmdldCBjaGFuZ2VkDQo+PiBhdCB0aGUgVUFTLiBCdXQg dGhlICpVQVMgaXMgc3RpbGwgb2JsaWdhdGVkIHRvIHNlbmQgdGhlIHJlbWFpbmluZw0KPj4gcmVz cG9uc2VzIHRvIHRoZSBhZGRyZXNzIGluIHRoZSBWaWEsIHdoaWNoIGlzIHRoZSBvbGQgYWRkcmVz cy4gKg0KPj4gDQo+PiBbR2FvXSBJdCBpcyBpbiBSRkMzMjYxLCBidXQgUkZDMzMxMSBoYXMgdGhl IGRlZmluaXRpb24gYXM6DQo+PiANCj4+IGZyb20gUkZDMzMxMToNCj4+IFVQREFURSBpcyBhIHRh cmdldCByZWZyZXNoIHJlcXVlc3QuIEFzIHNwZWNpZmllZCBpbiBSRkMgMzI2MSBbMV0sDQo+PiAg ICB0aGlzIG1lYW5zIHRoYXQgaXQgY2FuIHVwZGF0ZSB0aGUgcmVtb3RlIHRhcmdldCBvZiBhIGRp YWxvZy4gSWYgYSBVQQ0KPj4gICAgdXNlcyBhbiBVUERBVEUgcmVxdWVzdCBvciByZXNwb25zZSB0 byBtb2RpZnkgdGhlIHJlbW90ZSB0YXJnZXQgd2hpbGUNCj4+ICAgICphbiBJTlZJVEUgdHJhbnNh Y3Rpb24gaXMgaW4gcHJvZ3Jlc3MqLCBhbmQgaXQgaXMgYSBVQVMgZm9yIHRoYXQgDQpJTlZJVEUN Cj4+ICAgIHRyYW5zYWN0aW9uLCBpdCAqTVVTVCBwbGFjZSB0aGUgc2FtZSB2YWx1ZSBpbnRvIHRo ZSBDb250YWN0IGhlYWRlcioNCj4+ICogICBmaWVsZCBvZiB0aGUgMnh4IHRvIHRoZSBJTlZJVEUg dGhhdCBpdCBwbGFjZWQgaW50byB0aGUgVVBEQVRFIA0KcmVxdWVzdCoNCj4+ICogICBvciByZXNw b25zZSouDQo+PiANCj4+IFNvLCBpdCBzaG91bGQgYmUgdGhlIG5ldyBhZGRyZXNzIGhlcmUuDQo+ DQo+WW91IG1pc3MgbXkgcG9pbnQuDQo+DQo+SXRzIG5vdCBhYm91dCB0aGUgQ29udGFjdCBwbGFj ZWQgKmluKiB0aGUgMnh4IHJlc3BvbnNlLg0KPkl0cyBhYm91dCB0aGUgYWRkcmVzcyB0byB3aGlj aCB0aGUgcmVzcG9uc2UgaXMgZGVsaXZlcmVkLg0KPlRoYXQgaXMgZGljdGF0ZWQgYnkgdGhlIFZp YSBoZWFkZXJzIGluIHRoZSBJTlZJVEUgcmVxdWVzdC4NCj5UaG9zZSBhcmUgbm90IGFmZmVjdGVk IGJ5IHRoZSB0YXJnZXQgcmVmcmVzaC4NCj4NCj4gICAgICAgICAgICAgICAgIFRoYW5rcywNCj4g ICAgICAgICAgICAgICAgIFBhdWwNCg0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5 IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5 IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5p Y2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdh dGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3Nl IHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFp bCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQg aW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0 byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFp bCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBB bnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2 aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMg YW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 001B3AC4482575F5_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhlbiwgaXQgc2VlbXMgYSByZWFsIHBy b2JsZW0gZm9yIGluY29uc2lzdGVuY3kNCm9mIHJlZnJlc2hlZCB0YXJnZXQgYW5kIGRpc3BhdGNo aW5nIHJ1bGUgYnkgVmlhLiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNh bnMtc2VyaWYiPlBhdWwgaGFzIGdpdmVuIG91dCBzb21lIEJDUCB3YXkuIERvDQp5b3UgaGF2ZSBz b21lIHRob3VnaHQgYWJvdXQgc29sdXRpb25zIGluIHRoZW9yeT88L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcy48L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdhbzwvZm9udD4NCjxicj4NCjxicj48Zm9u dCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT08YnI+DQogWmlwICZuYnNwOyAmbmJzcDs6IDIxMDAxMjxicj4NCiBUZWwgJm5ic3A7ICZu YnNwOzogODcyMTE8YnI+DQogVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiBl X21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+ DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPjxiPk9LVU1VUkEgU2hpbmppICZsdDtzaGluQHNvZnRmcm9udC5jby5qcCZndDs8L2I+ DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+MjAwOS0wNy0xNiAx MjoyOTwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj5TSVBDT1JFICZsdDtzaXBjb3JlQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249 dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+s63LzTwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ Z2FvLnlhbmcyQHp0ZS5jb20uY24sIFBhdWwgS3l6aXZhdCAmbHQ7cGt5eml2YXRAY2lzY28uY29t Jmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9u dCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBz aXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtzaXBjb3JlXSBOZXcgcmV2aXNpb24gb2YgdGhl IHJlLUlOVklURQ0KaGFuZGxpbmcgZHJhZnQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4N Cjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PkhpLCBHYW88YnI+DQo8YnI+DQpJIHNlZW0geW91 IGRvbid0IHN0aWxsIGNhdGNoIGhpcyBwb2ludC4gSGUgaGFzIGJlZW4gdGFsa2luZyBhYm91dDxi cj4NCmEgVmlhIGhlYWRlciBvZiBub3QgYSBwcm94eSBidXQgYW4gVUFDLiB0aGUgc2VydmVyIHRy YW5zYWN0aW9uIHNlbmQ8YnI+DQphIHJlc3BvbmNlIG9mIHRoZSByZUlOVklURSB0byB0aGUgb2xk IGFkZHJlc3Mgb2YgYW4gVUFDLCBldmVuIGlmPGJyPg0KVVBEQVRFIHJlcXVlc3QgaGFkIHJlZnJl c2hlZCBVQUMncyBsb2NhbCB0YXJnZXQoaWUuIElQIGFkZHJlc3MpLjxicj4NCjxicj4NCkl0IGlz IGEgYmFzaWMgcnVsZSBkZXNjcmliZWQgaW4gUkZDMzI2MS4gUkZDMzMxMSBkb2VzIE5PVCBjaGFu Z2UgaXQuPGJyPg0KPGJyPg0KUmVnYXJkcyw8YnI+DQpTaGluamk8YnI+DQo8YnI+DQpnYW8ueWFu ZzJAenRlLmNvbS5jbjxicj4NCiZndDtIaSw8YnI+DQomZ3Q7PGJyPg0KJmd0O0kgY2F0Y2ggeW91 ciBwb2ludCBub3cuIFlvdSBtZWFuIHRoYXQgdGhlIG1pZGRsZS1ib3gsIHN1Y2ggYXMgcHJveHks DQo8YnI+DQomZ3Q7YWRkaW5nIFZpYSBpbiB0aGUgSU5WSVRFLiBUaGVuIHRoZSBwcm94eSBpcyBu b3cgbm9uLWZ1bmN0aW9uYWwsIG1ha2luZw0KdGhlIDxicj4NCiZndDtyZXNwb25zZSB1bnJlYWNo YWJsZS48YnI+DQomZ3Q7PGJyPg0KJmd0O0J1dCBJIHRoaW5rIHRoZSBzb2x1dGlvbnMgc2hvdWxk IG5vdCBiZSBpbiBwcm90b2NvbCBsZXZlbC4gVGhlIHNvbHV0aW9ucw0KPGJyPg0KJmd0O2NhbiBi ZTo8YnI+DQomZ3Q7PGJyPg0KJmd0OzEuIEZhdWx0IHRvbGVyYW5jZS4gKGllLiBjcmFzaGluZyBv ZiBQLUNTQ0YvUy1DU0NGKTxicj4NCiZndDs8YnI+DQomZ3Q7Mi4gSXNzdWUgbmV3IElOVklURSBy ZXBsYWNlIHRoZSBvbGQgb25lLiAoaWUuIGNoYW5naW5nIFAtQ1NDRik8YnI+DQomZ3Q7PGJyPg0K Jmd0O1RoYW5rcy48YnI+DQomZ3Q7PGJyPg0KJmd0O0dhbzxicj4NCiZndDs8YnI+DQomZ3Q7PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQomZ3Q7IFppcCAmbmJzcDsgJm5i c3A7OiAyMTAwMTI8YnI+DQomZ3Q7IFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiZndDsg VGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiZndDsgZV9tYWlsIDogZ2FvLnlh bmcyQHp0ZS5jb20uY248YnI+DQomZ3Q7PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT08YnI+DQomZ3Q7PGJyPg0KJmd0Ozxicj4NCiZndDs8YnI+DQomZ3Q7UGF1bCBLeXppdmF0ICZs dDtwa3l6aXZhdEBjaXNjby5jb20mZ3Q7IDxicj4NCiZndDs8YnI+DQomZ3Q7Z2FvLnlhbmcyQHp0 ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0Ozxicj4NCiZndDsmZ3Q7IElmIHxoZSBVQUMgZGVjaWRl cyB0byBmaXggdGhpcyBieSBzZW5kaW5nIGFuIFVQREFURSBiZWZvcmUgY29tcGxldGlvbg0Kb2Y8 YnI+DQomZ3Q7Jmd0OyB0aGUgcmVJTlZJVEUsIHRoZW4gaXQgbWF5IHN1Y2NlZWQgaW4gZ2V0dGlu ZyB0aGUgcmVtb3RlIHRhcmdldA0KY2hhbmdlZDxicj4NCiZndDsmZ3Q7IGF0IHRoZSBVQVMuIEJ1 dCB0aGUgKlVBUyBpcyBzdGlsbCBvYmxpZ2F0ZWQgdG8gc2VuZCB0aGUgcmVtYWluaW5nPGJyPg0K Jmd0OyZndDsgcmVzcG9uc2VzIHRvIHRoZSBhZGRyZXNzIGluIHRoZSBWaWEsIHdoaWNoIGlzIHRo ZSBvbGQgYWRkcmVzcy4NCio8YnI+DQomZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyBbR2FvXSBJdCBp cyBpbiBSRkMzMjYxLCBidXQgUkZDMzMxMSBoYXMgdGhlIGRlZmluaXRpb24gYXM6PGJyPg0KJmd0 OyZndDsgPGJyPg0KJmd0OyZndDsgZnJvbSBSRkMzMzExOjxicj4NCiZndDsmZ3Q7IFVQREFURSBp cyBhIHRhcmdldCByZWZyZXNoIHJlcXVlc3QuIEFzIHNwZWNpZmllZCBpbiBSRkMgMzI2MSBbMV0s PGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwO3RoaXMgbWVhbnMgdGhhdCBpdCBjYW4gdXBkYXRl IHRoZSByZW1vdGUgdGFyZ2V0IG9mDQphIGRpYWxvZy4gSWYgYSBVQTxicj4NCiZndDsmZ3Q7ICZu YnNwOyAmbmJzcDt1c2VzIGFuIFVQREFURSByZXF1ZXN0IG9yIHJlc3BvbnNlIHRvIG1vZGlmeSB0 aGUNCnJlbW90ZSB0YXJnZXQgd2hpbGU8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7KmFuIElO VklURSB0cmFuc2FjdGlvbiBpcyBpbiBwcm9ncmVzcyosIGFuZCBpdCBpcw0KYSBVQVMgZm9yIHRo YXQgSU5WSVRFPGJyPg0KJmd0OyZndDsgJm5ic3A7ICZuYnNwO3RyYW5zYWN0aW9uLCBpdCAqTVVT VCBwbGFjZSB0aGUgc2FtZSB2YWx1ZSBpbnRvIHRoZQ0KQ29udGFjdCBoZWFkZXIqPGJyPg0KJmd0 OyZndDsgKiAmbmJzcDsgZmllbGQgb2YgdGhlIDJ4eCB0byB0aGUgSU5WSVRFIHRoYXQgaXQgcGxh Y2VkIGludG8gdGhlDQpVUERBVEUgcmVxdWVzdCo8YnI+DQomZ3Q7Jmd0OyAqICZuYnNwOyBvciBy ZXNwb25zZSouPGJyPg0KJmd0OyZndDsgPGJyPg0KJmd0OyZndDsgU28sIGl0IHNob3VsZCBiZSB0 aGUgbmV3IGFkZHJlc3MgaGVyZS48YnI+DQomZ3Q7PGJyPg0KJmd0O1lvdSBtaXNzIG15IHBvaW50 Ljxicj4NCiZndDs8YnI+DQomZ3Q7SXRzIG5vdCBhYm91dCB0aGUgQ29udGFjdCBwbGFjZWQgKmlu KiB0aGUgMnh4IHJlc3BvbnNlLjxicj4NCiZndDtJdHMgYWJvdXQgdGhlIGFkZHJlc3MgdG8gd2hp Y2ggdGhlIHJlc3BvbnNlIGlzIGRlbGl2ZXJlZC48YnI+DQomZ3Q7VGhhdCBpcyBkaWN0YXRlZCBi eSB0aGUgVmlhIGhlYWRlcnMgaW4gdGhlIElOVklURSByZXF1ZXN0Ljxicj4NCiZndDtUaG9zZSBh cmUgbm90IGFmZmVjdGVkIGJ5IHRoZSB0YXJnZXQgcmVmcmVzaC48YnI+DQomZ3Q7PGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 IFRoYW5rcyw8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDsgUGF1bDxicj4NCjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJy PjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTom bmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhp cyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJz cDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFp bCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNp cGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNw O3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90 Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRl bnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3Ro ZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0 cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZu YnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7 dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkm bmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNw O0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWls Jm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNw O29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7 dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7 YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5k ZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5i c3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZu YnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 001B3AC4482575F5_=-- From shin@softfront.co.jp Thu Jul 16 01:42:34 2009 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 18B7528C15A for ; Thu, 16 Jul 2009 01:42:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.971 X-Spam-Level: ** X-Spam-Status: No, score=2.971 tagged_above=-999 required=5 tests=[AWL=0.238, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_62=0.6, RELAY_IS_221=2.222, UNPARSEABLE_RELAY=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 SgxAsj+hyIva for ; Thu, 16 Jul 2009 01:42:33 -0700 (PDT) Received: from mail2.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with SMTP id DAEE028C153 for ; Thu, 16 Jul 2009 01:42:32 -0700 (PDT) Received: from softfront.co.jp by mail2.softfront.co.jp id AA05372 ; 16 Jul 2009 15:39:49 +0900 From: OKUMURA Shinji To: SIPCORE Date: Thu, 16 Jul 2009 15:39:47 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.18 (WinNT,501) In-Reply-To: References: Message-Id: <53CA05E0360584shin@softfront.co.jp> Subject: [sipcore] target refresh during an incomplete reINVITE-transaction 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, 16 Jul 2009 08:42:34 -0000 Hi Gao, I think this issue may be discussed previously. During an incomplete reINVITE-transaction, if UAC's IP address is changed, UAC behavior when sending the UPDATE request to refresh local target MAY send CANCEL DO NOT expect 4xx responce for reINVITE If necessary, send new reINVITE (in the same dialog) UAS behavior when receiving the UPDATE request to refresh remote target If tactful, MAY send 4xx responce for reINVITE DO expect CANCEL Server transaction (nearest UAC) If very very tactful, would forward 4xx to new IP address. but I'm not sure it cause no problem. Regards, Shinji gao.yang2@zte.com.cn >Hi, > >Then, it seems a real problem for inconsistency of refreshed target and >dispatching rule by Via. > >Paul has given out some BCP way. Do you have some thought about solutions >in theory? > >Thanks. > >Gao > >=================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn >=================================== > >OKUMURA Shinji >2009-07-16 12:29 > >Hi, Gao > >I seem you don't still catch his point. He has been talking about >a Via header of not a proxy but an UAC. the server transaction send >a responce of the reINVITE to the old address of an UAC, even if >UPDATE request had refreshed UAC's local target(ie. IP address). > >It is a basic rule described in RFC3261. RFC3311 does NOT change it. > >Regards, >Shinji > >gao.yang2@zte.com.cn >>Hi, >> >>I catch your point now. You mean that the middle-box, such as proxy, >>adding Via in the INVITE. Then the proxy is now non-functional, making the >>response unreachable. >> >>But I think the solutions should not be in protocol level. The solutions >>can be: >> >>1. Fault tolerance. (ie. crashing of P-CSCF/S-CSCF) >> >>2. Issue new INVITE replace the old one. (ie. changing P-CSCF) >> >>Thanks. >> >>Gao >> >>=================================== >> Zip : 210012 >> Tel : 87211 >> Tel2 :(+86)-025-52877211 >> e_mail : gao.yang2@zte.com.cn >>=================================== >> >> >> >>Paul Kyzivat >> >>gao.yang2@zte.com.cn wrote: >> >>> If |he UAC decides to fix this by sending an UPDATE before completion of >>> the reINVITE, then it may succeed in getting the remote target changed >>> at the UAS. But the *UAS is still obligated to send the remaining >>> responses to the address in the Via, which is the old address. * >>> >>> [Gao] It is in RFC3261, but RFC3311 has the definition as: >>> >>> from RFC3311: >>> UPDATE is a target refresh request. As specified in RFC 3261 [1], >>> this means that it can update the remote target of a dialog. If a UA >>> uses an UPDATE request or response to modify the remote target while >>> *an INVITE transaction is in progress*, and it is a UAS for that INVITE >>> transaction, it *MUST place the same value into the Contact header* >>> * field of the 2xx to the INVITE that it placed into the UPDATE request* >>> * or response*. >>> >>> So, it should be the new address here. >> >>You miss my point. >> >>Its not about the Contact placed *in* the 2xx response. >>Its about the address to which the response is delivered. >>That is dictated by the Via headers in the INVITE request. >>Those are not affected by the target refresh. >> >> Thanks, >> Paul From gao.yang2@zte.com.cn Thu Jul 16 01:43:04 2009 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 80CE528C144 for ; Thu, 16 Jul 2009 01:43:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.948 X-Spam-Level: X-Spam-Status: No, score=-93.948 tagged_above=-999 required=5 tests=[AWL=-3.558, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_82=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 xo4eNLnXD3gY for ; Thu, 16 Jul 2009 01:43:03 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 7479728C150 for ; Thu, 16 Jul 2009 01:43:02 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 111641727820181; Thu, 16 Jul 2009 15:54:37 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.99] with StormMail ESMTP id 46629.5385067488; Thu, 16 Jul 2009 16:05:26 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n6G88HXd058702; Thu, 16 Jul 2009 16:08:17 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <52CA05DFFAAB1Ashin@softfront.co.jp> To: OKUMURA Shinji MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 16 Jul 2009 16:08:00 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-16 16:08:09, Serialize complete at 2009-07-16 16:08:09 Content-Type: multipart/alternative; boundary="=_alternative 002CAE4F482575F5_=" X-MAIL: mse2.zte.com.cn n6G88HXd058702 Cc: SIPCORE Subject: [sipcore] =?gb2312?b?tPC4tDogdGFyZ2V0IHJlZnJlc2ggZHVyaW5nIGFuIGlu?= =?gb2312?b?Y29tcGxldGUgcmVJTlZJVEUtdHJhbnNhY3Rpb24=?= 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, 16 Jul 2009 08:43:04 -0000 This is a multipart message in MIME format. --=_alternative 002CAE4F482575F5_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgU2hpbmppLA0KDQpJTU8sIGl0IGlzIG5vdCBlbGVnYW50IHNvbHV0aW9uLCBhczoNCjEuIFRo aXMgaXMgYSBhZGRpdGlvbmFsIHJlcXVpcmVtZW50IGZvciBVQSBhbmQgcHJveHkuIA0KMi4gRnVy dGhlciB0aGUgcmVzcG9uc2Uob2YgSU5WSVRFL1JlLUlOVklURSkgY2FuIGJlIDR4eCBvciAyeHgs IGFuZCB0aGUgDQpkaWZmZXJlbmNlIG1heSBoYXMgaW1wYWN0IG9uIHNlc3Npb24gc3RhdGUuDQoN CkkgaGF2ZSBhIHJhdyB3YXk6DQoNCkFzIGl0IGlzIGJlY2F1c2Ugb2YgdGhlIGluY29uc2lzdGVu Y3kgb2YgcmVmcmVzaGVkIHRhcmdldCBhbmQgZGlzcGF0Y2hpbmcgDQpydWxlIGJ5IFZpYSwgYW5k IFVBUyBoYXMgZ2V0IHRoZSByZWZyZXNoZWQgdGFyZ2V0IGJ5IFVQREFURSwgc28gdGhlIFVBUyAN CmNhbiBtb2RpZnkgdGhlIGxhc3QgVmlhIGhlYWRlcih3aGljaCBpcyBmb3JtZWQgYnkgVUFDIGFj Y29yZGluZyB0byBpdHMgDQphZGRyZXNzKSB0byBiZSB0aGUgbmV3IGFkZHJlc3Mgb2YgVUFDLiBC dXQgSSBhbSBub3Qgc3VyZSBpcyB0aGVyZSBhbnkgDQpwcm94eSB3aWxsIGNoZWNrIHRoZSBWaWEg aGVhZGVycy4NCg0KVGhlIG1lbnRpb25lZCBjYXNlIGlzIHRoYXQgdGhlIHJlc3BvbnNlIGlzIGFm dGVyIHRoZSBVUERBVEUoYnkgVUFTJ3MgDQp2aWV3KS4gSWYgdGhlIGZpbmFsIHJlc3BvbnNlIGlz IGJlZm9yZSB0aGUgVURQQVRFKGJ5IFVBUydzIHZpZXcpOg0KMnh4IGNhc2U6IFRoZSByZXRyYW5z bWlzc2lvbiBvZiAyeHggc2hvdWxkIHVzZSBtb2RpZmllZCBWaWEgaGVhZGVyLg0KNHh4IGNhc2U6 IDR4eCBpcyBob3AtYnktaG9wLCBzbyB0aGUgNHh4IHdpbGwgYmUgc2VudCB0byB0aGUgb2xkIGFk ZHJlc3Mgb2YgDQpVQUMuIFNvLCBpdCBjYW4gYmUgbWlzc2VkLiBUaGUgVUFDJ3MgdGltZXIgZm9y IGZpbmFsIHJlc3BvbnNlIHdpbGwgZmlyZShhcyANCjQwOCksIGFuZCBpdCBjYW4gc2VuZCBhIG5l dyBSZS1JTlZJVEUgb3IganVzdCB0ZXJtaW5hdGUgdGhlIHNlc3Npb24uDQoNClRoYW5rcy4NCg0K R2FvDQoNCg0KDQoNCk9LVU1VUkEgU2hpbmppIDxzaGluQHNvZnRmcm9udC5jby5qcD4gDQoyMDA5 LTA3LTE2IDE0OjM4DQoNCsrVvP7Iyw0KU0lQQ09SRSA8c2lwY29yZUBpZXRmLm9yZz4NCrOty80N Cmdhby55YW5nMkB6dGUuY29tLmNuLCBQYXVsIEt5eml2YXQgPHBreXppdmF0QGNpc2NvLmNvbT4N Ctb3zOINCnRhcmdldCByZWZyZXNoIGR1cmluZyBhbiBpbmNvbXBsZXRlIHJlSU5WSVRFLXRyYW5z YWN0aW9uDQoNCg0KDQoNCg0KDQpIaSBHYW8sDQoNCkkgdGhpbmsgdGhpcyBpc3N1ZSBtYXkgYmUg ZGlzY3Vzc2VkIHByZXZpb3VzbHkuDQoNCkR1cmluZyBhbiBpbmNvbXBsZXRlIHJlSU5WSVRFLXRy YW5zYWN0aW9uLCBpZiBVQUMncyBJUCBhZGRyZXNzDQppcyBjaGFuZ2VkLA0KDQpVQUMgYmVoYXZp b3Igd2hlbiBzZW5kaW5nIHRoZSBVUERBVEUgcmVxdWVzdCB0byByZWZyZXNoIGxvY2FsIHRhcmdl dA0KICBNQVkgc2VuZCBDQU5DRUwNCiAgRE8gTk9UIGV4cGVjdCA0eHggcmVzcG9uY2UgZm9yIHJl SU5WSVRFDQogIElmIG5lY2Vzc2FyeSwgc2VuZCBuZXcgcmVJTlZJVEUgKGluIHRoZSBzYW1lIGRp YWxvZykNCg0KVUFTIGJlaGF2aW9yIHdoZW4gcmVjZWl2aW5nIHRoZSBVUERBVEUgcmVxdWVzdCB0 byByZWZyZXNoIHJlbW90ZSB0YXJnZXQNCiAgSWYgdGFjdGZ1bCwgTUFZIHNlbmQgNHh4IHJlc3Bv bmNlIGZvciByZUlOVklURQ0KICBETyBleHBlY3QgQ0FOQ0VMDQoNClNlcnZlciB0cmFuc2FjdGlv biAobmVhcmVzdCBVQUMpDQogIElmIHZlcnkgdmVyeSB0YWN0ZnVsLCB3b3VsZCBmb3J3YXJkIDR4 eCB0byBuZXcgSVAgYWRkcmVzcy4NCiAgYnV0IEknbSBub3Qgc3VyZSBpdCBjYXVzZSBubyBwcm9i bGVtLg0KDQpSZWdhcmRzLA0KU2hpbmppDQoNCmdhby55YW5nMkB6dGUuY29tLmNuDQo+SGksDQo+ DQo+VGhlbiwgaXQgc2VlbXMgYSByZWFsIHByb2JsZW0gZm9yIGluY29uc2lzdGVuY3kgb2YgcmVm cmVzaGVkIHRhcmdldCBhbmQgDQo+ZGlzcGF0Y2hpbmcgcnVsZSBieSBWaWEuIA0KPg0KPlBhdWwg aGFzIGdpdmVuIG91dCBzb21lIEJDUCB3YXkuIERvIHlvdSBoYXZlIHNvbWUgdGhvdWdodCBhYm91 dCBzb2x1dGlvbnMgDQoNCj5pbiB0aGVvcnk/DQo+DQo+VGhhbmtzLg0KPg0KPkdhbw0KPg0KPj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+IFppcCAgICA6IDIxMDAxMg0KPiBU ZWwgICAgOiA4NzIxMQ0KPiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KPiBlX21haWwgOiBn YW8ueWFuZzJAenRlLmNvbS5jbg0KPj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 DQo+DQo+T0tVTVVSQSBTaGluamkgPHNoaW5Ac29mdGZyb250LmNvLmpwPiANCj4yMDA5LTA3LTE2 IDEyOjI5DQo+DQo+SGksIEdhbw0KPg0KPkkgc2VlbSB5b3UgZG9uJ3Qgc3RpbGwgY2F0Y2ggaGlz IHBvaW50LiBIZSBoYXMgYmVlbiB0YWxraW5nIGFib3V0DQo+YSBWaWEgaGVhZGVyIG9mIG5vdCBh IHByb3h5IGJ1dCBhbiBVQUMuIHRoZSBzZXJ2ZXIgdHJhbnNhY3Rpb24gc2VuZA0KPmEgcmVzcG9u Y2Ugb2YgdGhlIHJlSU5WSVRFIHRvIHRoZSBvbGQgYWRkcmVzcyBvZiBhbiBVQUMsIGV2ZW4gaWYN Cj5VUERBVEUgcmVxdWVzdCBoYWQgcmVmcmVzaGVkIFVBQydzIGxvY2FsIHRhcmdldChpZS4gSVAg YWRkcmVzcykuDQo+DQo+SXQgaXMgYSBiYXNpYyBydWxlIGRlc2NyaWJlZCBpbiBSRkMzMjYxLiBS RkMzMzExIGRvZXMgTk9UIGNoYW5nZSBpdC4NCj4NCj5SZWdhcmRzLA0KPlNoaW5qaQ0KPg0KPmdh by55YW5nMkB6dGUuY29tLmNuDQo+PkhpLA0KPj4NCj4+SSBjYXRjaCB5b3VyIHBvaW50IG5vdy4g WW91IG1lYW4gdGhhdCB0aGUgbWlkZGxlLWJveCwgc3VjaCBhcyBwcm94eSwgDQo+PmFkZGluZyBW aWEgaW4gdGhlIElOVklURS4gVGhlbiB0aGUgcHJveHkgaXMgbm93IG5vbi1mdW5jdGlvbmFsLCBt YWtpbmcgDQp0aGUgDQo+PnJlc3BvbnNlIHVucmVhY2hhYmxlLg0KPj4NCj4+QnV0IEkgdGhpbmsg dGhlIHNvbHV0aW9ucyBzaG91bGQgbm90IGJlIGluIHByb3RvY29sIGxldmVsLiBUaGUgc29sdXRp b25zIA0KDQo+PmNhbiBiZToNCj4+DQo+PjEuIEZhdWx0IHRvbGVyYW5jZS4gKGllLiBjcmFzaGlu ZyBvZiBQLUNTQ0YvUy1DU0NGKQ0KPj4NCj4+Mi4gSXNzdWUgbmV3IElOVklURSByZXBsYWNlIHRo ZSBvbGQgb25lLiAoaWUuIGNoYW5naW5nIFAtQ1NDRikNCj4+DQo+PlRoYW5rcy4NCj4+DQo+Pkdh bw0KPj4NCj4+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4+IFppcCAgICA6 IDIxMDAxMg0KPj4gVGVsICAgIDogODcyMTENCj4+IFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjEx DQo+PiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbg0KPj49PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PQ0KPj4NCj4+DQo+Pg0KPj5QYXVsIEt5eml2YXQgPHBreXppdmF0QGNp c2NvLmNvbT4gDQo+Pg0KPj5nYW8ueWFuZzJAenRlLmNvbS5jbiB3cm90ZToNCj4+DQo+Pj4gSWYg fGhlIFVBQyBkZWNpZGVzIHRvIGZpeCB0aGlzIGJ5IHNlbmRpbmcgYW4gVVBEQVRFIGJlZm9yZSBj b21wbGV0aW9uIA0Kb2YNCj4+PiB0aGUgcmVJTlZJVEUsIHRoZW4gaXQgbWF5IHN1Y2NlZWQgaW4g Z2V0dGluZyB0aGUgcmVtb3RlIHRhcmdldCBjaGFuZ2VkDQo+Pj4gYXQgdGhlIFVBUy4gQnV0IHRo ZSAqVUFTIGlzIHN0aWxsIG9ibGlnYXRlZCB0byBzZW5kIHRoZSByZW1haW5pbmcNCj4+PiByZXNw b25zZXMgdG8gdGhlIGFkZHJlc3MgaW4gdGhlIFZpYSwgd2hpY2ggaXMgdGhlIG9sZCBhZGRyZXNz LiAqDQo+Pj4gDQo+Pj4gW0dhb10gSXQgaXMgaW4gUkZDMzI2MSwgYnV0IFJGQzMzMTEgaGFzIHRo ZSBkZWZpbml0aW9uIGFzOg0KPj4+IA0KPj4+IGZyb20gUkZDMzMxMToNCj4+PiBVUERBVEUgaXMg YSB0YXJnZXQgcmVmcmVzaCByZXF1ZXN0LiBBcyBzcGVjaWZpZWQgaW4gUkZDIDMyNjEgWzFdLA0K Pj4+ICAgIHRoaXMgbWVhbnMgdGhhdCBpdCBjYW4gdXBkYXRlIHRoZSByZW1vdGUgdGFyZ2V0IG9m IGEgZGlhbG9nLiBJZiBhIA0KVUENCj4+PiAgICB1c2VzIGFuIFVQREFURSByZXF1ZXN0IG9yIHJl c3BvbnNlIHRvIG1vZGlmeSB0aGUgcmVtb3RlIHRhcmdldCANCndoaWxlDQo+Pj4gICAgKmFuIElO VklURSB0cmFuc2FjdGlvbiBpcyBpbiBwcm9ncmVzcyosIGFuZCBpdCBpcyBhIFVBUyBmb3IgdGhh dCANCklOVklURQ0KPj4+ICAgIHRyYW5zYWN0aW9uLCBpdCAqTVVTVCBwbGFjZSB0aGUgc2FtZSB2 YWx1ZSBpbnRvIHRoZSBDb250YWN0IGhlYWRlcioNCj4+PiAqICAgZmllbGQgb2YgdGhlIDJ4eCB0 byB0aGUgSU5WSVRFIHRoYXQgaXQgcGxhY2VkIGludG8gdGhlIFVQREFURSANCnJlcXVlc3QqDQo+ Pj4gKiAgIG9yIHJlc3BvbnNlKi4NCj4+PiANCj4+PiBTbywgaXQgc2hvdWxkIGJlIHRoZSBuZXcg YWRkcmVzcyBoZXJlLg0KPj4NCj4+WW91IG1pc3MgbXkgcG9pbnQuDQo+Pg0KPj5JdHMgbm90IGFi b3V0IHRoZSBDb250YWN0IHBsYWNlZCAqaW4qIHRoZSAyeHggcmVzcG9uc2UuDQo+Pkl0cyBhYm91 dCB0aGUgYWRkcmVzcyB0byB3aGljaCB0aGUgcmVzcG9uc2UgaXMgZGVsaXZlcmVkLg0KPj5UaGF0 IGlzIGRpY3RhdGVkIGJ5IHRoZSBWaWEgaGVhZGVycyBpbiB0aGUgSU5WSVRFIHJlcXVlc3QuDQo+ PlRob3NlIGFyZSBub3QgYWZmZWN0ZWQgYnkgdGhlIHRhcmdldCByZWZyZXNoLg0KPj4NCj4+ICAg ICAgICAgICAgICAgICBUaGFua3MsDQo+PiAgICAgICAgICAgICAgICAgUGF1bA0KDQoNCg0KDQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t DQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFp bmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2Fu aXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGll bnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJl IG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNh dGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0 aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2Yg dGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5 b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9y aWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNz YWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFz IGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3Rl bS4NCg== --=_alternative 002CAE4F482575F5_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIFNoaW5qaSw8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5JTU8sIGl0IGlzIG5vdCBlbGVnYW50IHNvbHV0aW9u LCBhczo8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PjEuIFRoaXMgaXMgYSBhZGRp dGlvbmFsIHJlcXVpcmVtZW50IGZvciBVQSBhbmQgcHJveHkuDQo8L3R0PjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTI+PHR0PjIuIEZ1cnRoZXIgdGhlIHJlc3BvbnNlKG9mIElOVklURS9SZS1JTlZJ VEUpIGNhbiBiZQ0KNHh4IG9yIDJ4eCwgYW5kIHRoZSBkaWZmZXJlbmNlIG1heSBoYXMgaW1wYWN0 IG9uIHNlc3Npb24gc3RhdGUuPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0 dD5JIGhhdmUgYSByYXcgd2F5OjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48 dHQ+QXMgaXQgaXMgYmVjYXVzZSBvZiB0aGUgaW5jb25zaXN0ZW5jeSBvZiByZWZyZXNoZWQNCnRh cmdldCBhbmQgZGlzcGF0Y2hpbmcgcnVsZSBieSBWaWEsIGFuZCBVQVMgaGFzIGdldCB0aGUgcmVm cmVzaGVkIHRhcmdldA0KYnkgVVBEQVRFLCBzbyB0aGUgVUFTIGNhbiBtb2RpZnkgdGhlIGxhc3Qg VmlhIGhlYWRlcih3aGljaCBpcyBmb3JtZWQgYnkNClVBQyBhY2NvcmRpbmcgdG8gaXRzIGFkZHJl c3MpIHRvIGJlIHRoZSBuZXcgYWRkcmVzcyBvZiBVQUMuIDxiPkJ1dCBJIGFtDQpub3Qgc3VyZSBp cyB0aGVyZSBhbnkgcHJveHkgd2lsbCBjaGVjayB0aGUgVmlhIGhlYWRlcnMuPC9iPjwvdHQ+PC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+VGhlIG1lbnRpb25lZCBjYXNlIGlzIHRo YXQgdGhlIHJlc3BvbnNlIGlzIGFmdGVyIHRoZQ0KVVBEQVRFKGJ5IFVBUydzIHZpZXcpLiBJZiB0 aGUgZmluYWwgcmVzcG9uc2UgaXMgYmVmb3JlIHRoZSBVRFBBVEUoYnkgVUFTJ3MNCnZpZXcpOjwv dHQ+PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+Mnh4IGNhc2U6IFRoZSByZXRyYW5zbWlz c2lvbiBvZiAyeHggc2hvdWxkIHVzZSBtb2RpZmllZA0KVmlhIGhlYWRlci48L3R0PjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTI+PHR0PjR4eCBjYXNlOiA0eHggaXMgaG9wLWJ5LWhvcCwgc28gdGhl IDR4eCB3aWxsIGJlIHNlbnQNCnRvIHRoZSBvbGQgYWRkcmVzcyBvZiBVQUMuIFNvLCBpdCBjYW4g YmUgbWlzc2VkLiBUaGUgVUFDJ3MgdGltZXIgZm9yIGZpbmFsDQpyZXNwb25zZSB3aWxsIGZpcmUo YXMgNDA4KSwgYW5kIGl0IGNhbiBzZW5kIGEgbmV3IFJlLUlOVklURSBvciBqdXN0IHRlcm1pbmF0 ZQ0KdGhlIHNlc3Npb24uPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5U aGFua3MuPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5HYW88L3R0Pjwv Zm9udD4NCjxicj4NCjxicj4NCjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZh bGlnbj10b3A+DQo8dGQgd2lkdGg9MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48 Yj5PS1VNVVJBIFNoaW5qaSAmbHQ7c2hpbkBzb2Z0ZnJvbnQuY28uanAmZ3Q7PC9iPg0KPC9mb250 Pg0KPHA+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMDktMDctMTYgMTQ6Mzg8L2Zv bnQ+DQo8dGQgd2lkdGg9NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrV vP7IyzwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+U0lQ Q09SRSAmbHQ7c2lwY29yZUBpZXRmLm9yZyZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0 ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808 L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmdhby55YW5n MkB6dGUuY29tLmNuLCBQYXVsIEt5eml2YXQgJmx0O3BreXppdmF0QGNpc2NvLmNvbSZndDs8L2Zv bnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPnRhcmdldCByZWZyZXNoIGR1cmluZyBhbiBpbmNvbXBsZXRlDQpyZUlO VklURS10cmFuc2FjdGlvbjwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJy Pjxmb250IHNpemU9Mj48dHQ+SGkgR2FvLDxicj4NCjxicj4NCkkgdGhpbmsgdGhpcyBpc3N1ZSBt YXkgYmUgZGlzY3Vzc2VkIHByZXZpb3VzbHkuPGJyPg0KPGJyPg0KRHVyaW5nIGFuIGluY29tcGxl dGUgcmVJTlZJVEUtdHJhbnNhY3Rpb24sIGlmIFVBQydzIElQIGFkZHJlc3M8YnI+DQppcyBjaGFu Z2VkLDxicj4NCjxicj4NClVBQyBiZWhhdmlvciB3aGVuIHNlbmRpbmcgdGhlIFVQREFURSByZXF1 ZXN0IHRvIHJlZnJlc2ggbG9jYWwgdGFyZ2V0PGJyPg0KICZuYnNwO01BWSBzZW5kIENBTkNFTDxi cj4NCiAmbmJzcDtETyBOT1QgZXhwZWN0IDR4eCByZXNwb25jZSBmb3IgcmVJTlZJVEU8YnI+DQog Jm5ic3A7SWYgbmVjZXNzYXJ5LCBzZW5kIG5ldyByZUlOVklURSAoaW4gdGhlIHNhbWUgZGlhbG9n KTxicj4NCjxicj4NClVBUyBiZWhhdmlvciB3aGVuIHJlY2VpdmluZyB0aGUgVVBEQVRFIHJlcXVl c3QgdG8gcmVmcmVzaCByZW1vdGUgdGFyZ2V0PGJyPg0KICZuYnNwO0lmIHRhY3RmdWwsIE1BWSBz ZW5kIDR4eCByZXNwb25jZSBmb3IgcmVJTlZJVEU8YnI+DQogJm5ic3A7RE8gZXhwZWN0IENBTkNF TDxicj4NCjxicj4NClNlcnZlciB0cmFuc2FjdGlvbiAobmVhcmVzdCBVQUMpPGJyPg0KICZuYnNw O0lmIHZlcnkgdmVyeSB0YWN0ZnVsLCB3b3VsZCBmb3J3YXJkIDR4eCB0byBuZXcgSVAgYWRkcmVz cy48YnI+DQogJm5ic3A7YnV0IEknbSBub3Qgc3VyZSBpdCBjYXVzZSBubyBwcm9ibGVtLjwvdHQ+ PC9mb250Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+PGJyPg0KUmVnYXJkcyw8YnI+DQpTaGluamk8 YnI+DQo8YnI+DQpnYW8ueWFuZzJAenRlLmNvbS5jbjxicj4NCiZndDtIaSw8YnI+DQomZ3Q7PGJy Pg0KJmd0O1RoZW4sIGl0IHNlZW1zIGEgcmVhbCBwcm9ibGVtIGZvciBpbmNvbnNpc3RlbmN5IG9m IHJlZnJlc2hlZCB0YXJnZXQNCmFuZCA8YnI+DQomZ3Q7ZGlzcGF0Y2hpbmcgcnVsZSBieSBWaWEu IDxicj4NCiZndDs8YnI+DQomZ3Q7UGF1bCBoYXMgZ2l2ZW4gb3V0IHNvbWUgQkNQIHdheS4gRG8g eW91IGhhdmUgc29tZSB0aG91Z2h0IGFib3V0IHNvbHV0aW9ucw0KPGJyPg0KJmd0O2luIHRoZW9y eT88YnI+DQomZ3Q7PGJyPg0KJmd0O1RoYW5rcy48YnI+DQomZ3Q7PGJyPg0KJmd0O0dhbzxicj4N CiZndDs8YnI+DQomZ3Q7PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQom Z3Q7IFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQomZ3Q7IFRlbCAmbmJzcDsgJm5ic3A7 OiA4NzIxMTxicj4NCiZndDsgVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiZn dDsgZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQomZ3Q7PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT08YnI+DQomZ3Q7PGJyPg0KJmd0O09LVU1VUkEgU2hpbmppICZs dDtzaGluQHNvZnRmcm9udC5jby5qcCZndDsgPGJyPg0KJmd0OzIwMDktMDctMTYgMTI6Mjk8YnI+ DQomZ3Q7PGJyPg0KJmd0O0hpLCBHYW88YnI+DQomZ3Q7PGJyPg0KJmd0O0kgc2VlbSB5b3UgZG9u J3Qgc3RpbGwgY2F0Y2ggaGlzIHBvaW50LiBIZSBoYXMgYmVlbiB0YWxraW5nIGFib3V0PGJyPg0K Jmd0O2EgVmlhIGhlYWRlciBvZiBub3QgYSBwcm94eSBidXQgYW4gVUFDLiB0aGUgc2VydmVyIHRy YW5zYWN0aW9uIHNlbmQ8YnI+DQomZ3Q7YSByZXNwb25jZSBvZiB0aGUgcmVJTlZJVEUgdG8gdGhl IG9sZCBhZGRyZXNzIG9mIGFuIFVBQywgZXZlbiBpZjxicj4NCiZndDtVUERBVEUgcmVxdWVzdCBo YWQgcmVmcmVzaGVkIFVBQydzIGxvY2FsIHRhcmdldChpZS4gSVAgYWRkcmVzcykuPGJyPg0KJmd0 Ozxicj4NCiZndDtJdCBpcyBhIGJhc2ljIHJ1bGUgZGVzY3JpYmVkIGluIFJGQzMyNjEuIFJGQzMz MTEgZG9lcyBOT1QgY2hhbmdlIGl0Ljxicj4NCiZndDs8YnI+DQomZ3Q7UmVnYXJkcyw8YnI+DQom Z3Q7U2hpbmppPGJyPg0KJmd0Ozxicj4NCiZndDtnYW8ueWFuZzJAenRlLmNvbS5jbjxicj4NCiZn dDsmZ3Q7SGksPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0O0kgY2F0Y2ggeW91ciBwb2ludCBu b3cuIFlvdSBtZWFuIHRoYXQgdGhlIG1pZGRsZS1ib3gsIHN1Y2ggYXMgcHJveHksDQo8YnI+DQom Z3Q7Jmd0O2FkZGluZyBWaWEgaW4gdGhlIElOVklURS4gVGhlbiB0aGUgcHJveHkgaXMgbm93IG5v bi1mdW5jdGlvbmFsLA0KbWFraW5nIHRoZSA8YnI+DQomZ3Q7Jmd0O3Jlc3BvbnNlIHVucmVhY2hh YmxlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDtCdXQgSSB0aGluayB0aGUgc29sdXRpb25z IHNob3VsZCBub3QgYmUgaW4gcHJvdG9jb2wgbGV2ZWwuIFRoZQ0Kc29sdXRpb25zIDxicj4NCiZn dDsmZ3Q7Y2FuIGJlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsxLiBGYXVsdCB0b2xlcmFu Y2UuIChpZS4gY3Jhc2hpbmcgb2YgUC1DU0NGL1MtQ1NDRik8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Mi4gSXNzdWUgbmV3IElOVklURSByZXBsYWNlIHRoZSBvbGQgb25lLiAoaWUuIGNoYW5n aW5nIFAtQ1NDRik8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7VGhhbmtzLjxicj4NCiZndDsm Z3Q7PGJyPg0KJmd0OyZndDtHYW88YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQomZ3Q7Jmd0OyBaaXAgJm5ic3A7ICZuYnNw OzogMjEwMDEyPGJyPg0KJmd0OyZndDsgVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KJmd0 OyZndDsgVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiZndDsmZ3Q7IGVfbWFp bCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KJmd0OyZndDs9PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PTxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7UGF1bCBLeXppdmF0ICZsdDtwa3l6aXZhdEBjaXNjby5jb20mZ3Q7IDxi cj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDtnYW8ueWFuZzJAenRlLmNvbS5jbiB3cm90ZTo8YnI+ DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBJZiB8aGUgVUFDIGRlY2lkZXMgdG8gZml4IHRo aXMgYnkgc2VuZGluZyBhbiBVUERBVEUgYmVmb3JlDQpjb21wbGV0aW9uIG9mPGJyPg0KJmd0OyZn dDsmZ3Q7IHRoZSByZUlOVklURSwgdGhlbiBpdCBtYXkgc3VjY2VlZCBpbiBnZXR0aW5nIHRoZSBy ZW1vdGUgdGFyZ2V0DQpjaGFuZ2VkPGJyPg0KJmd0OyZndDsmZ3Q7IGF0IHRoZSBVQVMuIEJ1dCB0 aGUgKlVBUyBpcyBzdGlsbCBvYmxpZ2F0ZWQgdG8gc2VuZCB0aGUgcmVtYWluaW5nPGJyPg0KJmd0 OyZndDsmZ3Q7IHJlc3BvbnNlcyB0byB0aGUgYWRkcmVzcyBpbiB0aGUgVmlhLCB3aGljaCBpcyB0 aGUgb2xkIGFkZHJlc3MuDQoqPGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBb R2FvXSBJdCBpcyBpbiBSRkMzMjYxLCBidXQgUkZDMzMxMSBoYXMgdGhlIGRlZmluaXRpb24gYXM6 PGJyPg0KJmd0OyZndDsmZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBmcm9tIFJGQzMzMTE6PGJyPg0K Jmd0OyZndDsmZ3Q7IFVQREFURSBpcyBhIHRhcmdldCByZWZyZXNoIHJlcXVlc3QuIEFzIHNwZWNp ZmllZCBpbiBSRkMgMzI2MQ0KWzFdLDxicj4NCiZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7dGhp cyBtZWFucyB0aGF0IGl0IGNhbiB1cGRhdGUgdGhlIHJlbW90ZSB0YXJnZXQNCm9mIGEgZGlhbG9n LiBJZiBhIFVBPGJyPg0KJmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDt1c2VzIGFuIFVQREFURSBy ZXF1ZXN0IG9yIHJlc3BvbnNlIHRvIG1vZGlmeQ0KdGhlIHJlbW90ZSB0YXJnZXQgd2hpbGU8YnI+ DQomZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyphbiBJTlZJVEUgdHJhbnNhY3Rpb24gaXMgaW4g cHJvZ3Jlc3MqLCBhbmQgaXQNCmlzIGEgVUFTIGZvciB0aGF0IElOVklURTxicj4NCiZndDsmZ3Q7 Jmd0OyAmbmJzcDsgJm5ic3A7dHJhbnNhY3Rpb24sIGl0ICpNVVNUIHBsYWNlIHRoZSBzYW1lIHZh bHVlIGludG8NCnRoZSBDb250YWN0IGhlYWRlcio8YnI+DQomZ3Q7Jmd0OyZndDsgKiAmbmJzcDsg ZmllbGQgb2YgdGhlIDJ4eCB0byB0aGUgSU5WSVRFIHRoYXQgaXQgcGxhY2VkIGludG8NCnRoZSBV UERBVEUgcmVxdWVzdCo8YnI+DQomZ3Q7Jmd0OyZndDsgKiAmbmJzcDsgb3IgcmVzcG9uc2UqLjxi cj4NCiZndDsmZ3Q7Jmd0OyA8YnI+DQomZ3Q7Jmd0OyZndDsgU28sIGl0IHNob3VsZCBiZSB0aGUg bmV3IGFkZHJlc3MgaGVyZS48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7WW91IG1pc3MgbXkg cG9pbnQuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0O0l0cyBub3QgYWJvdXQgdGhlIENvbnRh Y3QgcGxhY2VkICppbiogdGhlIDJ4eCByZXNwb25zZS48YnI+DQomZ3Q7Jmd0O0l0cyBhYm91dCB0 aGUgYWRkcmVzcyB0byB3aGljaCB0aGUgcmVzcG9uc2UgaXMgZGVsaXZlcmVkLjxicj4NCiZndDsm Z3Q7VGhhdCBpcyBkaWN0YXRlZCBieSB0aGUgVmlhIGhlYWRlcnMgaW4gdGhlIElOVklURSByZXF1 ZXN0Ljxicj4NCiZndDsmZ3Q7VGhvc2UgYXJlIG5vdCBhZmZlY3RlZCBieSB0aGUgdGFyZ2V0IHJl ZnJlc2guPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBh dWw8YnI+DQo8YnI+DQo8L3R0PjwvZm9udD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0lu Zm9ybWF0aW9uJm5ic3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3Jt YXRpb24mbmJzcDtjb250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMm bmJzcDtzb2xlbHkmbmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3Mm bmJzcDtvcmdhbml6YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9u Jm5ic3A7aXMmbmJzcDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5i c3A7YWJvdmUmbmJzcDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5i c3A7c2VjcmVjeSZuYnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNw O3RvJm5ic3A7ZGlzY2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhp cyZuYnNwO2NvbW11bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFp bCZuYnNwO2FuZCZuYnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRo Jm5ic3A7aXQmbmJzcDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRl ZCZuYnNwO3NvbGVseSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhl Jm5ic3A7aW5kaXZpZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5i c3A7dGhleSZuYnNwO2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hh dmUmbmJzcDtyZWNlaXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3Im bmJzcDtwbGVhc2UmbmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2Vk Jm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3Nh Z2UmbmJzcDtoYXMmbmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMm bmJzcDthbmQmbmJzcDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtz eXN0ZW0uDQo8L3ByZT4= --=_alternative 002CAE4F482575F5_=-- From ietf.hanserik@gmail.com Thu Jul 16 04:22:54 2009 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 285383A6C69 for ; Thu, 16 Jul 2009 04:22:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.498 X-Spam-Level: X-Spam-Status: No, score=-2.498 tagged_above=-999 required=5 tests=[AWL=0.100, 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 ZPDLBaj8rAaV for ; Thu, 16 Jul 2009 04:22:52 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.24]) by core3.amsl.com (Postfix) with ESMTP id A95C53A6904 for ; Thu, 16 Jul 2009 04:22:51 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so14304eye.31 for ; Thu, 16 Jul 2009 04:21:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=WpvWOqF8EeCXtwqImJH1TWWFa/KAHol/4FG6GIB68KU=; b=jsIxDqTNKW5nWu+boHGLFZjiogtbv/fzWjCfa3j5tXM+DrBMzT0b+GtTFSek13o0bs 2vdztGfr7QbppU/yuWo7MbO9zGSLRnBKs9IxYTpjOoPahL18y7z5BCvHbtVH83QG9AVF 16wrYs3Zh2nQ3nRxFEuiTjMXc8x5I6PoY9VQ4= 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=lRfC4xPbm1LW1+uM/EjiDo7liru7kd+Ik3GD1OwyWnXhz8cpHwXh+YfZniendafTcr qmG8pPO+IwMZeNO6glpgasgO05/wNLXqHEOz/QrF8bOgNY7p3X+Z/2e4kz3UqvP1SWuu 7YFYc3I7YHThCCGp5ipRw1xBqGONUdZTNwST0= MIME-Version: 1.0 Received: by 10.210.60.8 with SMTP id i8mr6190041eba.41.1247743301569; Thu, 16 Jul 2009 04:21:41 -0700 (PDT) In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D00226554F@GBNTHT12009MSX.gb002.siemens.net> References: <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com> <4A5E83CB.4090701@cisco.com> <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0907160217k75052336na7f4d5db16d79efc@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D00226554F@GBNTHT12009MSX.gb002.siemens.net> Date: Thu, 16 Jul 2009 13:21:41 +0200 Message-ID: <9ae56b1e0907160421j7777ddemf269c1bd0ea36dc3@mail.gmail.com> From: Hans Erik van Elburg To: "Elwell, John" Content-Type: multipart/alternative; boundary=0015174c334e42d12b046ed0e075 Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 16 Jul 2009 11:22:54 -0000 --0015174c334e42d12b046ed0e075 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Hi John, The only reason that the aor tag was introduced, is to allow a UAS to retrieve the aor that was used before it was replaced with the contact of that UAS. The same semantics that P-Called-Party-ID (RFC3455) has today. We can also live with P-Called-Party-ID, but I understood that the majority wants to resolve all these requirements with one core-SIP header i.e. History-Info. So what do you think would be the proper definition for the foo tag? Would tightening the definition to only apply to the home proxy of the called user help? Is a URI only an AOR when it is replaced with a registered contact address? (This would do for the retrieval of the called AOR by the UAS.) /Hans Erik van Elburg On Thu, Jul 16, 2009 at 12:21 PM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > Hans Erik, > > Either these entities don't modify the Request-URI (and therefore don't > generate a H-I entry) or they consider themselves responsible for that > domain and change the Request-URI. Whether or not they really are > responsible for the domain, by changing the Request-URI they are > assuming responsibility, and therefore would qualify for adding 'aor' to > the H-I entry. Certainly they could easily "misinterpret" the spec in > that way. > Of course you can assume responsibility when your not responsible for the domain, you cant claim that this implies that your responsible for the domain. If implementors use nonsensical reasoning then nonsensical systems will result. There is nothing that we can do about that, other then employ other implementors that apply proper reasoning. > > So we have nodes that "misinterpret" the spec (because the definition of > AOR is too loose) and insert 'aor' when they shouldn't, and legacy nodes > that don't insert 'aor' when they should (or misinterpret the spec and > fail to add 'aor'. So what really is the value of this tag? > Same. > > For this tag to be of any value, we need a much tighter definition of > AOR (or if we change the name of the tag to 'foo', a much tighter > definition of foo). Unless we can come up with a tight definition, I am > not at all convinced we are going down a path that is really likely to > improve interoperability. > Agree that we need an unambiguous definition. > > John > > > > -----Original Message----- > > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > Sent: 16 July 2009 10:18 > > To: Elwell, John > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > > > > Proxies that are not responsible for the domain, routing > > proxies, statesless proxies, SIP aware firewalls, SBC's in > > their role of SBC, P-CSCF, would not mark it with an aor tag. > > So not all H-I entries will be marked with aor. > > > > Also given this defintion, TEL-URL will never be marked an AOR. > > > > > > /Hans Erik van Elburg > > > > > > > > On Thu, Jul 16, 2009 at 10:04 AM, Elwell, John > > wrote: > > > > > > From that definition, I believe every entry in H-I > > except the last > > (i.e., the Request-URI received by the UAS) would be an > > AOR. If not, the > > request would not have got this far, because it would > > not have found a > > domain that could route it. > > > > Is my understanding correct? If so, what is the point > > of the "AOR" > > indicator in H-I, if all but the last are marked "AOR"? > > > > Perhaps there is one exception to the assumption above. > > A URI containing > > an IP address would perhaps not be considered an AOR, > > because it does > > not point to a domain. > > > > John > > > > > > > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Hans > > Erik van Elburg > > > Sent: 16 July 2009 08:33 > > > To: Paul Kyzivat > > > Cc: SIPCORE; Hadriel Kaplan > > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > > > > > > I'd like to understand what is wrong with the RFC3261 > > > definition of AOR? > > > > > > "Address-of-Record: An address-of-record (AOR) is a SIP or > > > SIPS URI that points to a domain with a location service that > > > can map the URI to another URI where the user might be > > > available. Typically, the location service is populated > > > through registrations. An AOR is frequently thought of as the > > > "public address" of the user." > > > > > > Currently I think it is the best we have, can we agree to > > > adopt that as leading for the tagging procedure? > > > > > > /Hans Erik van Elburg > > > > > > > > > On Thu, Jul 16, 2009 at 3:35 AM, Paul Kyzivat > > > wrote: > > > > > > > > > > > > > > > Francois Audet wrote: > > > > > > > > > "aor" means it is "an AOR that I own > > AND I used for a > > > location service dip". > > > > > > > > > > > > Hmm. the AND part is a bit troubling for me. > > > In this context the tag isn't added unless there is a > > > translation following it, so saying "AND I translated > > it" is ok by me. > > > But IMO things can be AORs without ever using a > > > location service. My example with alice and betty is > > one such case. > > > > > > Now perhaps we can argue that if you translate an R-URI > > > (rather than adding a Route header), then by definition what > > > you did was use a location service. If so then I guess I am > > > ok, but that seems odd. > > > > > > Paul > > > > > > > > > > > > I don't know if you view that as "different" or > > > not. I guess > > > it's debatable. > > > > > > Again, in my humble opinion, a URI is an AOR > > > only if the domain > > > responsible says so. And the way it knows it's > > > an AOR is if it can use it for the location service dip. > > > If people don't agree with the statement, then > > > perhaps we should > > > change the name of the parameter. > > > > > > > > > -----Original Message----- > > > From: Paul Kyzivat > > > [mailto:pkyzivat@cisco.com] Sent: Wednesday, July 15, > > 2009 16:25 > > > To: Audet, Francois (SC100:3055) > > > Cc: Hadriel Kaplan; SIPCORE > > > Subject: Re: [sipcore] rfc4244bis: what > > > is an AoR? > > > > > > If the tag is "aor" then I think it had > > > better mean the same thing ans AOR or AoR. And in the process > > > help to tighten up the definition of that. > > > > > > Having it mean "something like AoR, but > > > not quite" is IMO a *really* bad idea. > > > > > > If it really is different than AoR, > > > then it had better be called something else, and given a > > > clear definition that justifies a new concept. > > > > > > AFAIK the point here is to identify the > > > URI as an Address of Record. If we had a clear unambiguous > > > definition of that, which was also consistent with common > > > understanding of the term (by those who *ought* to know), > > > then I don't think we would be having this discussion. > > > > > > Thanks, > > > Paul > > > > > > > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > > > > > > > > > > > > > --0015174c334e42d12b046ed0e075 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi John,

The only reason that the aor ta= g was introduced, is to allow a UAS to retrieve the aor that was used befor= e it was replaced with the contact of that UAS. The same semantics that P-C= alled-Party-ID (RFC3455) has today.

We can also live with P-Called-Party-ID, but I understo= od that the majority wants to resolve all these requirements with one core-= SIP header i.e. History-Info.

So what do you think= would be the proper definition for the foo tag?

Would tightening the definition to only apply to the ho= me proxy of the called user help?
Is a URI only an AOR when it is= replaced with a registered contact address? (This would do for the retriev= al of the called AOR by the UAS.)

/Hans Erik van Elburg


On Thu, Jul 16, 2009 at 12:21 PM, Elwell= , John <john.elwell@siemens-enterprise.com> wrote:
Hans Erik,

Either these entities don't modify the Request-URI (and therefore don&#= 39;t
generate a H-I entry) or they consider themselves responsible for that
domain and change the Request-URI. Whether or not they really are
responsible for the domain, by changing the Request-URI they are
assuming responsibility, and therefore would qualify for adding 'aor= 9; to
the H-I entry. Certainly they could easily "misinterpret" the spe= c in
that way.

Of course you can assume responsibility wh= en your not responsible for the domain, you cant claim that this implies th= at your responsible for the domain. If implementors use nonsensical=A0reaso= ning=A0then nonsensical systems will result. There is nothing that we can d= o about that, other then employ other implementors that apply proper=A0reas= oning.
=A0

So we have nodes that "misinterpret" the spec (because the defini= tion of
AOR is too loose) and insert 'aor' when they shouldn't, and leg= acy nodes
that don't insert 'aor' when they should (or misinterpret the s= pec and
fail to add 'aor'. So what really is the value of this tag?

Same.
=A0

For this tag to be of any value, we need a much tighter definition of
AOR (or if we change the name of the tag to 'foo', a much tighter definition of foo). Unless we can come up with a tight definition, I am
not at all convinced we are going down a path that is really likely to
improve interoperability.

Agree that = we need an=A0unambiguous=A0definition.=A0

John


> -----Original Message-----
> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
> Sent: 16 July 2009 10:18
> To: Elwell, John
> Subject: Re: [sipcore] rfc4244bis: what is an AoR?
>
> Proxies that are not responsible for the domain, =A0routing
> proxies, statesless proxies, SIP aware firewalls, SBC's in
> their role of SBC, P-CSCF, would not mark it with an aor tag.
> So not all H-I entries will be marked with aor.
>
> Also given this defintion, TEL-URL will never be marked an AOR.
>
>
> /Hans Erik van Elburg
>
>
>
> On Thu, Jul 16, 2009 at 10:04 AM, Elwell, John
> <john.elwell@= siemens-enterprise.com> wrote:
>
>
> =A0 =A0 =A0 From that definition, I believe every entry in H-I
> except the last
> =A0 =A0 =A0 (i.e., the Request-URI received by the UAS) would be an > AOR. If not, the
> =A0 =A0 =A0 request would not have got this far, because it would
> not have found a
> =A0 =A0 =A0 domain that could route it.
>
> =A0 =A0 =A0 Is my understanding correct? If so, what is the point
> of the "AOR"
> =A0 =A0 =A0 indicator in H-I, if all but the last are marked "AOR= "?
>
> =A0 =A0 =A0 Perhaps there is one exception to the assumption above. > A URI containing
> =A0 =A0 =A0 an IP address would perhaps not be considered an AOR,
> because it does
> =A0 =A0 =A0 not point to a domain.
>
> =A0 =A0 =A0 John
>
>
>
> =A0 =A0 =A0 > -----Original Message-----
> =A0 =A0 =A0 > From: sip= core-bounces@ietf.org
>
> =A0 =A0 =A0 > [mailto:s= ipcore-bounces@ietf.org] On Behalf Of Hans
> Erik van Elburg
> =A0 =A0 =A0 > Sent: 16 July 2009 08:33
> =A0 =A0 =A0 > To: Paul Kyzivat
> =A0 =A0 =A0 > Cc: SIPCORE; Hadriel Kaplan
> =A0 =A0 =A0 > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > =A0 =A0 =A0 >
> =A0 =A0 =A0 > I'd like to understand what is wrong with the RFC= 3261
> =A0 =A0 =A0 > definition of AOR?
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > "Address-of-Record: An address-of-record (AOR) i= s a SIP or
> =A0 =A0 =A0 > SIPS URI that points to a domain with a location serv= ice that
> =A0 =A0 =A0 > can map the URI to another URI where the user might b= e
> =A0 =A0 =A0 > available. Typically, the location service is populat= ed
> =A0 =A0 =A0 > through registrations. An AOR is frequently thought o= f as the
> =A0 =A0 =A0 > "public address" of the user."
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > Currently I think it is the best we have, can we agre= e to
> =A0 =A0 =A0 > adopt that as leading for the tagging procedure?
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > /Hans Erik van Elburg
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > On Thu, Jul 16, 2009 at 3:35 AM, Paul Kyzivat
> =A0 =A0 =A0 > <pkyzivat@ci= sco.com> wrote:
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 Francois Audet wrote:
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 "aor" means it = is "an AOR that I own
> AND I used for a
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 location service dip"= ;.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 Hmm. the AND part is a bit troubling for = me.
> =A0 =A0 =A0 > =A0 =A0 =A0 In this context the tag isn't added u= nless there is a
> =A0 =A0 =A0 > translation following it, so saying "AND I trans= lated
> it" is ok by me.
> =A0 =A0 =A0 > =A0 =A0 =A0 But IMO things can be AORs without ever u= sing a
> =A0 =A0 =A0 > location service. My example with alice and betty is<= br> > one such case.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 Now perhaps we can argue that if you tran= slate an R-URI
> =A0 =A0 =A0 > (rather than adding a Route header), then by definiti= on what
> =A0 =A0 =A0 > you did was use a location service. If so then I gues= s I am
> =A0 =A0 =A0 > ok, but that seems odd.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0Paul
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 I don't know if you v= iew that as "different" or
> =A0 =A0 =A0 > not. I guess
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 it's debatable.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 Again, in my humble opini= on, a URI is an AOR
> =A0 =A0 =A0 > only if the domain
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 responsible says so. And = the way it knows it's
> =A0 =A0 =A0 > an AOR is if it can use it for the location service d= ip.
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 If people don't agree= with the statement, then
> =A0 =A0 =A0 > perhaps we should
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 change the name of the pa= rameter.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 -----Orig= inal Message-----
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 From: Pau= l Kyzivat
> =A0 =A0 =A0 > [mailto:pkyziva= t@cisco.com] Sent: Wednesday, July 15,
> 2009 16:25
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 To: Audet= , Francois (SC100:3055)
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Cc: Hadri= el Kaplan; SIPCORE
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Subject: = Re: [sipcore] rfc4244bis: what
> =A0 =A0 =A0 > is an AoR?
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If the ta= g is "aor" then I think it had
> =A0 =A0 =A0 > better mean the same thing ans AOR or AoR. And in the= process
> =A0 =A0 =A0 > help to tighten up the definition of that.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Having it= mean "something like AoR, but
> =A0 =A0 =A0 > not quite" is IMO a *really* bad idea.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 If it rea= lly is different than AoR,
> =A0 =A0 =A0 > then it had better be called something else, and give= n a
> =A0 =A0 =A0 > clear definition that justifies a new concept.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 AFAIK the= point here is to identify the
> =A0 =A0 =A0 > URI as an Address of Record. If we had a clear unambi= guous
> =A0 =A0 =A0 > definition of that, which was also consistent with co= mmon
> =A0 =A0 =A0 > understanding of the term (by those who *ought* to kn= ow),
> =A0 =A0 =A0 > then I don't think we would be having this discus= sion.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0Thanks,
> =A0 =A0 =A0 > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0Paul
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > =A0 =A0 =A0 _________________________________________= ______
> =A0 =A0 =A0 > =A0 =A0 =A0 sipcore mailing list
> =A0 =A0 =A0 > =A0 =A0 =A0 sipco= re@ietf.org
> =A0 =A0 =A0 > =A0 =A0 =A0 https://www.ietf.org/mailman/listinfo/si= pcore
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
>
>
>
>

--0015174c334e42d12b046ed0e075-- From drage@alcatel-lucent.com Thu Jul 16 04:40:36 2009 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 801AE3A6CE2 for ; Thu, 16 Jul 2009 04:40:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.002 X-Spam-Level: X-Spam-Status: No, score=-3.002 tagged_above=-999 required=5 tests=[AWL=-0.753, 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 0UUHrStD7eNn for ; Thu, 16 Jul 2009 04:40:35 -0700 (PDT) Received: from smail2.alcatel.fr (smail2.alcatel.fr [64.208.49.57]) by core3.amsl.com (Postfix) with ESMTP id 99A643A694E for ; Thu, 16 Jul 2009 04:40:33 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail2.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n6GB9dsV021075 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Thu, 16 Jul 2009 13:10:44 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Thu, 16 Jul 2009 13:10:35 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , Francois Audet Date: Thu, 16 Jul 2009 13:10:35 +0200 Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoFo9w3rc9bbN34Th6DpXoY4c7pmwAWlkPQ Message-ID: References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> In-Reply-To: <4A5E6558.8000108@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.57 on 155.132.188.80 Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 16 Jul 2009 11:40:36 -0000 Agree with Paul. In terms of process, I understand the current definition of the tag is base= d on the RFC 3261 defn of AOR. How do we need to change that definition to = represent what people now understand. (current text follows) o AOR indicator: The AOR indicator is to mark an URI entry as being an Address Of Record. and o AOR indicator (hi-aor): An optional parameter for the History-Info indicating that the hi-targeted-to-uri is an Address Of Record (as defined in section 6/[RFC3261]) . The hi-aor parameter is added by a proxy or redirect server to a hi-entry when it recognizes the URI in the last entry as a URI in its abstract location service (and then it can be routed accordingly). Therefore, the hi-aor parameter (i.e., "aor") is not added for a hi-entry when it is first added in a History-Info header field, but rather is added when the retargeting actually occurs - i.e., the parameter indicates that the specific hi-targeted-to-uri that was retargeted was an AOR and thus the previous information in the request-URI may be "lost". Upon receipt of a request or response containing the History-Info header, a UA can determine a "lost" target AOR for a request by traversing the HI entries in reverse order to find the first one tagged with a specific hi-aor parameter. Then we can think of a name. Keith > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Thursday, July 16, 2009 12:25 AM > To: Francois Audet > Cc: SIPCORE; Hadriel Kaplan > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >=20 > If the tag is "aor" then I think it had better mean the same=20 > thing ans AOR or AoR. And in the process help to tighten up=20 > the definition of that. >=20 > Having it mean "something like AoR, but not quite" is IMO a=20 > *really* bad idea. >=20 > If it really is different than AoR, then it had better be=20 > called something else, and given a clear definition that=20 > justifies a new concept. >=20 > AFAIK the point here is to identify the URI as an Address of=20 > Record. If we had a clear unambiguous definition of that,=20 > which was also consistent with common understanding of the=20 > term (by those who *ought* to know), then I don't think we=20 > would be having this discussion. >=20 > Thanks, > Paul >=20 > Francois Audet wrote: > > =20 > >=20 > >> -----Original Message----- > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > >> Sent: Wednesday, July 15, 2009 15:51 > >> To: Audet, Francois (SC100:3055) > >> Cc: Hadriel Kaplan; SIPCORE > >> Subject: Re: [sipcore] rfc4244bis: what is an AoR? > >> > >> > >> > >> Francois Audet wrote: > >>> Well, sort of. > >>> > >>> But I can't think of cases where the tag "aor" would not be > >> applied to > >>> somthing that is not an AOR. > >>> > >>> It is certainly true that not all AORs will be tagged. > >>> > >>> In my mind, the tag meant "I recorgnize this as being the AOR I'm=20 > >>> responsible for, and that I'm using for the database dip". > >> I think I agree with Francois, but that definition is circular. > >> > >> I'm saying "its an AOR if somebody from its domain *says*=20 > its an AOR." > >=20 > > Yes. Agree. > >=20 > >> But I don't think thats enough - I've seen too many cases=20 > when people=20 > >> are willing to assert things that make no sense. > >> If you just got an address from DHCP, then you had better=20 > not assert=20 > >> that some URI containing that is an AOR. > >> > >> I think the meaning of the URI needs to be stable over some=20 > >> reasonably long period of time before it qualifies as an AOR. > >> But the meaning of "meaning" is also a bit squishy there.=20 > It doesn't=20 > >> have to represent the same *person* (or call center=20 > addresses aren't=20 > >> AORs), and it doesn't have to represent the same device.=20 > It just has=20 > >> to represent some stable "role" or "presentity" or something. > >> > >> Nor, IMO, does it have to translate to something else.=20 > While it might=20 > >> be unusual, it is *possible* for an AOR to resolve=20 > directly to a UAS. > >> > >> And if it does translate to something else, it need not be via a=20 > >> location service, though that is a common way. > >=20 > > Yes, but let's remember that this tag we called "aor" in=20 > this draft is=20 > > meant for a specific purpose, i.e., isolating the important=20 > URIs from=20 > > the "fluff". So the job of UASs and upstream proxies is easier. > >=20 > > It's not like we are going to give a plaque of=20 > congratulations saying=20 > > "Genuine AOR (tm)" or anything like that. The point is not=20 > to define=20 > > something as an ARO. The point is to mark an address has=20 > having value=20 > > for the domain, in resolving it using it's location service. > >=20 > > Like somebody else said (think it was Hadriel), this is lower-case > > "aor: the tag" as opposed to upper-case "AOR: the classic=20 > definition". > >=20 > > If we can think of a better tag name, maybe it would help. I=20 > > personally like "aor" because frankly, even for a AOR, you=20 > can't know=20 > > a URI is an AOR, unless you are the pornographer responsible for=20 > > minting it :-) > >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From bernard_aboba@hotmail.com Thu Jul 16 00:08:35 2009 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 903DA3A67EA; Thu, 16 Jul 2009 00:08:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.274 X-Spam-Level: X-Spam-Status: No, score=-2.274 tagged_above=-999 required=5 tests=[AWL=0.324, 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 dlNn-3YZGL1j; Thu, 16 Jul 2009 00:08:34 -0700 (PDT) Received: from blu0-omc1-s18.blu0.hotmail.com (blu0-omc1-s18.blu0.hotmail.com [65.55.116.29]) by core3.amsl.com (Postfix) with ESMTP id BCB873A6811; Thu, 16 Jul 2009 00:08:34 -0700 (PDT) Received: from BLU137-W10 ([65.55.116.7]) by blu0-omc1-s18.blu0.hotmail.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 00:06:21 -0700 Message-ID: Content-Type: multipart/alternative; boundary="_7dc895d1-ce61-475e-865a-9ded2d442fbc_" X-Originating-IP: [216.31.230.230] From: Bernard Aboba To: , , , , , Date: Thu, 16 Jul 2009 00:06:22 -0700 Importance: Normal In-Reply-To: References: <0D5F89FAC29E2C41B98A6A762007F5D00221E129@GBNTHT12009MSX.gb002.siemens.net> <3D3C75174CB95F42AD6BCC56E5555B450187F547@FIESEXC015.nsn-intra.net> MIME-Version: 1.0 X-OriginalArrivalTime: 16 Jul 2009 07:06:21.0991 (UTC) FILETIME=[ECAC4B70:01CA05E3] X-Mailman-Approved-At: Thu, 16 Jul 2009 05:12:44 -0700 Subject: Re: [sipcore] [Geopriv] Confusion over target inSIP location-conveyance - and impact on ECRIT phonebcp 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, 16 Jul 2009 07:08:35 -0000 --_7dc895d1-ce61-475e-865a-9ded2d442fbc_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable > Geopriv doesn't exactly have presentities=2C we have targets - yet=20 > targets use a presence document. So=2C while the device ID should not be= =20 > included in the XML=2C the entity=3D has to be. Therein lies the rub. The presentity and target have different identities.= They're not even at the same layer. =20 And both may differ from the identity in the From: field.=20 > BTW - the text from [I-D.ietf-geopriv-http-location-delivery] Section=20 > 6.6 confuses the two forms of identity=2C and needs to be changed. I'm not sure it confuses them=2C but the guidance may not be sound. In par= ticular=2C there are security consequences. --_7dc895d1-ce61-475e-865a-9ded2d442fbc_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable >=3B Geopriv doesn't exactly have presentities=2C we have targets - yet <= br>>=3B targets use a presence document. So=2C while the device ID should= not be
>=3B included in the XML=2C the entity=3D has to be.

T= herein lies the rub. =3B The presentity and target have different ident= ities. They're not even at the same layer. =3B
And both may differ = from the identity in the From: field.

>=3B BTW - the text from [I= -D.ietf-geopriv-http-location-delivery] Section
>=3B 6.6 confuses the= two forms of identity=2C and needs to be changed.

I'm not sure it c= onfuses them=2C but the guidance may not be sound. =3B In particular=2C= there are security consequences.
= --_7dc895d1-ce61-475e-865a-9ded2d442fbc_-- From john.elwell@siemens-enterprise.com Thu Jul 16 05:19:32 2009 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 AFE7A3A6D00 for ; Thu, 16 Jul 2009 05:19:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.584 X-Spam-Level: X-Spam-Status: No, score=-2.584 tagged_above=-999 required=5 tests=[AWL=0.015, 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 TVpeZ7Usqg5Q for ; Thu, 16 Jul 2009 05:19:31 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 039D63A6D4D for ; Thu, 16 Jul 2009 05:19:03 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KMV00J6XJJR2L@siemenscomms.co.uk> for sipcore@ietf.org; Thu, 16 Jul 2009 13:19:03 +0100 (BST) Date: Thu, 16 Jul 2009 13:19:04 +0100 From: "Elwell, John" In-reply-to: <9ae56b1e0907160421j7777ddemf269c1bd0ea36dc3@mail.gmail.com> To: Hans Erik van Elburg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D00226566D@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoGB5tzMjWisKJKQ1ywL0vR4IJMogAB7lsg Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com> <4A5E83CB.4090701@cisco.com> <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0907160217k75052336na7f4d5db16d79efc@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D00226554F@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0907160421j7777ddemf269c1bd0ea36dc3@mail.gmail.com> Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 16 Jul 2009 12:19:32 -0000 The semantics for P-Called-Party-ID are indeed a lot clearer. John=20 > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 > Sent: 16 July 2009 12:22 > To: Elwell, John > Cc: SIPCORE > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >=20 > Hi John, >=20 > The only reason that the aor tag was introduced, is to allow=20 > a UAS to retrieve the aor that was used before it was=20 > replaced with the contact of that UAS. The same semantics=20 > that P-Called-Party-ID (RFC3455) has today. >=20 > We can also live with P-Called-Party-ID, but I understood=20 > that the majority wants to resolve all these requirements=20 > with one core-SIP header i.e. History-Info. >=20 > So what do you think would be the proper definition for the foo tag? >=20 > Would tightening the definition to only apply to the home=20 > proxy of the called user help? > Is a URI only an AOR when it is replaced with a registered=20 > contact address? (This would do for the retrieval of the=20 > called AOR by the UAS.) >=20 > /Hans Erik van Elburg >=20 >=20 >=20 > On Thu, Jul 16, 2009 at 12:21 PM, Elwell, John=20 > wrote: >=20 >=20 > Hans Erik, > =09 > Either these entities don't modify the Request-URI (and=20 > therefore don't > generate a H-I entry) or they consider themselves=20 > responsible for that > domain and change the Request-URI. Whether or not they=20 > really are > responsible for the domain, by changing the Request-URI they are > assuming responsibility, and therefore would qualify=20 > for adding 'aor' to > the H-I entry. Certainly they could easily=20 > "misinterpret" the spec in > that way. > =09 >=20 >=20 > Of course you can assume responsibility when your not=20 > responsible for the domain, you cant claim that this implies=20 > that your responsible for the domain. If implementors use=20 > nonsensical reasoning then nonsensical systems will result.=20 > There is nothing that we can do about that, other then employ=20 > other implementors that apply proper reasoning. > =20 >=20 >=20 > So we have nodes that "misinterpret" the spec (because=20 > the definition of > AOR is too loose) and insert 'aor' when they shouldn't,=20 > and legacy nodes > that don't insert 'aor' when they should (or=20 > misinterpret the spec and > fail to add 'aor'. So what really is the value of this tag? > =09 >=20 >=20 > Same. > =20 >=20 >=20 > For this tag to be of any value, we need a much tighter=20 > definition of > AOR (or if we change the name of the tag to 'foo', a=20 > much tighter > definition of foo). Unless we can come up with a tight=20 > definition, I am > not at all convinced we are going down a path that is=20 > really likely to > improve interoperability. > =09 >=20 >=20 > Agree that we need an unambiguous definition.=20 >=20 > =09 > John > =09 >=20 >=20 > > -----Original Message----- > > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > =09 > > Sent: 16 July 2009 10:18 > > To: Elwell, John > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > > > > Proxies that are not responsible for the domain, routing > > proxies, statesless proxies, SIP aware firewalls, SBC's in > > their role of SBC, P-CSCF, would not mark it with an aor tag. > > So not all H-I entries will be marked with aor. > > > > Also given this defintion, TEL-URL will never be=20 > marked an AOR. > > > > > > /Hans Erik van Elburg > > > > > > > > On Thu, Jul 16, 2009 at 10:04 AM, Elwell, John > > wrote: > > > > > > From that definition, I believe every entry in H-I > > except the last > > (i.e., the Request-URI received by the UAS) would be an > > AOR. If not, the > > request would not have got this far, because it would > > not have found a > > domain that could route it. > > > > Is my understanding correct? If so, what is the point > > of the "AOR" > > indicator in H-I, if all but the last are marked "AOR"? > > > > Perhaps there is one exception to the assumption above. > > A URI containing > > an IP address would perhaps not be considered an AOR, > > because it does > > not point to a domain. > > > > John > > > > > > > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org > > > > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Hans > > Erik van Elburg > > > Sent: 16 July 2009 08:33 > > > To: Paul Kyzivat > > > Cc: SIPCORE; Hadriel Kaplan > > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > > > > > > I'd like to understand what is wrong with the RFC3261 > > > definition of AOR? > > > > > > "Address-of-Record: An address-of-record=20 > (AOR) is a SIP or > > > SIPS URI that points to a domain with a=20 > location service that > > > can map the URI to another URI where the user might be > > > available. Typically, the location service is=20 > populated > > > through registrations. An AOR is frequently=20 > thought of as the > > > "public address" of the user." > > > > > > Currently I think it is the best we have, can=20 > we agree to > > > adopt that as leading for the tagging procedure? > > > > > > /Hans Erik van Elburg > > > > > > > > > On Thu, Jul 16, 2009 at 3:35 AM, Paul Kyzivat > > > wrote: > > > > > > > > > > > > > > > Francois Audet wrote: > > > > > > > > > "aor" means it is "an AOR that I own > > AND I used for a > > > location service dip". > > > > > > > > > > > > Hmm. the AND part is a bit troubling for me. > > > In this context the tag isn't added=20 > unless there is a > > > translation following it, so saying "AND I translated > > it" is ok by me. > > > But IMO things can be AORs without ever using a > > > location service. My example with alice and betty is > > one such case. > > > > > > Now perhaps we can argue that if you=20 > translate an R-URI > > > (rather than adding a Route header), then by=20 > definition what > > > you did was use a location service. If so=20 > then I guess I am > > > ok, but that seems odd. > > > > > > Paul > > > > > > > > > > > > I don't know if you view that=20 > as "different" or > > > not. I guess > > > it's debatable. > > > > > > Again, in my humble opinion, a=20 > URI is an AOR > > > only if the domain > > > responsible says so. And the=20 > way it knows it's > > > an AOR is if it can use it for the location=20 > service dip. > > > If people don't agree with the=20 > statement, then > > > perhaps we should > > > change the name of the parameter. > > > > > > > > > -----Original Message----- > > > From: Paul Kyzivat > > > [mailto:pkyzivat@cisco.com] Sent: Wednesday, July 15, > > 2009 16:25 > > > To: Audet, Francois (SC100:3055) > > > Cc: Hadriel Kaplan; SIPCORE > > > Subject: Re: [sipcore]=20 > rfc4244bis: what > > > is an AoR? > > > > > > If the tag is "aor"=20 > then I think it had > > > better mean the same thing ans AOR or AoR.=20 > And in the process > > > help to tighten up the definition of that. > > > > > > Having it mean=20 > "something like AoR, but > > > not quite" is IMO a *really* bad idea. > > > > > > If it really is=20 > different than AoR, > > > then it had better be called something else,=20 > and given a > > > clear definition that justifies a new concept. > > > > > > AFAIK the point here is=20 > to identify the > > > URI as an Address of Record. If we had a=20 > clear unambiguous > > > definition of that, which was also consistent=20 > with common > > > understanding of the term (by those who=20 > *ought* to know), > > > then I don't think we would be having this discussion. > > > > > > Thanks, > > > Paul > > > > > > > > > > > > _______________________________________________ > > > sipcore mailing list > > > sipcore@ietf.org > > > https://www.ietf.org/mailman/listinfo/sipcore > > > > > > > > > > > > > > > > > > > > > =09 >=20 >=20 >=20 From bruno.chatras@orange-ftgroup.com Thu Jul 16 05:25:52 2009 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 CD3CE28C196 for ; Thu, 16 Jul 2009 05:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.448 X-Spam-Level: X-Spam-Status: No, score=-0.448 tagged_above=-999 required=5 tests=[AWL=1.800, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 DkMnxhOh1EM2 for ; Thu, 16 Jul 2009 05:25:52 -0700 (PDT) Received: from R-MAIL2.rd.francetelecom.com (r-mail2.rd.francetelecom.com [217.108.152.42]) by core3.amsl.com (Postfix) with ESMTP id A26B43A68E1 for ; Thu, 16 Jul 2009 05:25:51 -0700 (PDT) Received: from ftrdmel0.rd.francetelecom.fr ([10.192.128.56]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 14:26:22 +0200 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0610.A0B57837" Date: Thu, 16 Jul 2009 14:26:21 +0200 Message-ID: <9ECCF01B52E7AB408A7EB853526421414BA6D8@ftrdmel0.rd.francetelecom.fr> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Rfc4244bis: Reason in the History-Info Header field Thread-Index: AcoGEKAtDpD2w4f0TjmhKYBLNz3LXQ== From: To: X-OriginalArrivalTime: 16 Jul 2009 12:26:22.0732 (UTC) FILETIME=[A134DCC0:01CA0610] Subject: [sipcore] Rfc4244bis: Reason in the History-Info Header field 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, 16 Jul 2009 12:25:53 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0610.A0B57837 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable I just noticed that there is a difference about the Reason header between Version -01 and -02 of draft-barnes-sipcore-rfc4244bis although it is not listed in Clause 13. Version -01 contained the following statement: "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". This statement does not appear anymore in version -02. In version -02, the timeout case is covered by a new paragraph but the "internal events" case (e.g. event occuring as a result of an internal application logic decision) does not seem to be covered. Has this been done on purpose? If yes, I believe we need an alternative parameter to convey the "reason" (i.e. the name of the so-called internal event) that has trigerred the retargeting. If not, we need to specify how the Reason header is populated in such cases, in particular how to set the "protocol" element (protocol =3D "SIP" / "Q.850" / token) of the Reason header field. BC =20 ------_=_NextPart_001_01CA0610.A0B57837 Content-Type: text/html; charset="US-ASCII" Content-Transfer-Encoding: quoted-printable Rfc4244bis: Reason in the History-Info Header field

I just noticed that there is a = difference about the Reason header between Version -01 and -02 of = draft-barnes-sipcore-rfc4244bis although it is not listed in Clause = 13.

Version -01 contained the following = statement: "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". This statement does not appear anymore in version = -02. In version -02, the timeout case is covered by a new paragraph but = the "internal events" case (e.g. event occuring as a result of = an internal application logic decision) does not seem to be = covered.

Has this been done on purpose? If yes, = I believe we need an alternative parameter to convey the = "reason" (i.e. the name of the so-called internal event) that = has trigerred the retargeting. If not, we need to specify how the Reason = header is populated in such cases, in particular how to set the = "protocol" element (protocol =3D "SIP" / "Q.850" / = token) of the Reason header = field.

BC







 

------_=_NextPart_001_01CA0610.A0B57837-- From ian.elz@ericsson.com Thu Jul 16 06:53:04 2009 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 553353A6AEF for ; Thu, 16 Jul 2009 06:53:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.249 X-Spam-Level: X-Spam-Status: No, score=-5.249 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_34=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_65=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 tC78Qd63cBur for ; Thu, 16 Jul 2009 06:53:03 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 723203A6ABF for ; Thu, 16 Jul 2009 06:53:02 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-8d-4a5f30dd1169 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 4D.03.00514.DD03F5A4; Thu, 16 Jul 2009 15:53:33 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Jul 2009 15:53:33 +0200 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: Thu, 16 Jul 2009 15:53:32 +0200 Message-ID: In-Reply-To: <006701ca05b7$7cca7ec0$271d550a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis Thread-Index: AcoGHM5Rm2IAvDFbQ1Wky+vmMBibLw== References: <1ECE0EB50388174790F9694F77522CCF1EFE0971@zrc2hxm0.corp.nortel.com> <006701ca05b7$7cca7ec0$271d550a@china.huawei.com> From: "Ian Elz" To: "fanyanping" , "Mary Barnes" X-OriginalArrivalTime: 16 Jul 2009 13:53:33.0546 (UTC) FILETIME=[CF03BCA0:01CA061C] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [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, 16 Jul 2009 13:53:04 -0000 Nancy, Mary, We have discussed this issue previously. The key issues are outside the scope of the 4244bis draft and needs to be discussed separately. The issue with RFC3323 is that this RFC only discusses privacy from an originating and terminating user perspective. Separate discussions are required on how privacy for 3rd party identities included in a sip messages is handled. The current interpretation that you cannot override what is included in the Privacy header results in two specific issues: - originating user includes a Privacy value of user/header/id which means that the 3rd party identity has the same privacy. If the 3rd party identity should be allowed then this may impact services which use the third party identity. The example which has been quoted is the Freephone call where the Freephone number is used for call handling. This is inconvenient for services which need to use this information. - originating user explicitly specifies "Privacy: none" in the originating request. This means that the 3rd party identity cannot be protected. This has much more serious impact as it makes SIP as defined 'not fit for purpose' in most regulated telephony environments. This is due to regulatory requirements to allow the privacy for each user to be specified and handled correctly. This however is outside the scope of the H-I changes but I would suggest that the new draft specifically allows the inclusion of the 'none' value in the escaped Privacy header in the hi-targeted-to-uri. Ian -----Original Message----- From: fanyanping [mailto:fanyanping@huawei.com]=20 Sent: 16 July 2009 02:48 To: 'Mary Barnes' Cc: sipcore@ietf.org Subject: Re: [sipcore] rfc4244bis Hi mary, my response are inline below [nancy] , thanks:) > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Wednesday, July 15, 2009 10:46 PM > To: fanyanping > Subject: RE: [sipcore] rfc4244bis >=20 > Hi Nancy, >=20 > My responses are inline below [MB]. Note, it does not look like your=20 > original message went to the mailing list. Feel free to respond to the > mailing list. >=20 > Regards, > Mary.=20 >=20 > -----Original Message----- > From: fanyanping [mailto:fanyanping@huawei.com] > Sent: Wednesday, July 15, 2009 5:24 AM > To: sipcore-bounces@ietf.org > Cc: Barnes, Mary (RICH2:AR00) > Subject: Re: [sipcore] rfc4244bis >=20 >=20 > Hi mary, >=20 > I have read the draft of draft-barnes-sipcore-rfc4244bis-02.txt, there > are some issues i don't understand clearly, as blow: > 1, section 4.1 mentions > UAC that wants to ensure that privacy not be applied to its identity=20 > MUST include a Privacy header with a priv- value of "none." >=20 > but section 6.3.1(Privacy in the History-Info Header) doesn't has=20 > relevant description, can a proxy include a Privacy header with a=20 > priv- value of "none" to a specifical hi-entry?? how to handle the=20 > "none" in different cases? >=20 > [MB] We have not precluded the use of "none". We did have a long=20 > debate that the "none" in the hi-entry cannot override a privacy=20 > header at the request level. And, section 4.1 is discussing privacy=20 > at the request level. So, I'm not sure what additional functionality=20 > you might get if you added "none" to a specific hi-entry - in a sense=20 > that's the default IF there is no privacy header at the request=20 > level.[/MB] [nancy] I get it , thanks, review RFC3323, i find i make a mistake,:) >=20 > 2,section 6.1 mentions > The hi-target is added for a hi-entry when it is first added in a=20 > History-Info header field >=20 > but in the previous draft, the hi-target is not added for a hi-entry=20 > when it is first added in a History-Info header field, it is added to > the last hi-entry received in the request >=20 > compare the two methods, what is the advantage of the first one? i see > that rosenberg's target-uri-delivery draft adopts the second one >=20 > [MB] You are correct - we have changed the solution approach.=20 > The reason > we've done so is that we want to capture the mechanism by which the=20 > new target was determined. At that point in time, as well, we can=20 > determine whether the previous target (i.e., the one in the incoming > Request) was > an "aor". So, we now tag the previous entry with the "aor" tag if=20 > appropriate. The first method does add some complexity for the 3xx=20 > handling, which is why you see a lot more text for that in the new=20 > version. The second approach was trying to be consistent with how the=20 > entries are tagged with the "Reason" header. But, we decided that by=20 > tagging the new hi-entry we are actually capturing more (accurate)=20 > information. We have tried to be precise in the text, so if you can=20 > point out any text that makes this unclear, that would be very=20 > helpful. > [/MB] =20 [nancy] previously, the reason header and hi-target parameter in the hi-entry are matched, but now i need to find the next hi-entry's hi-target parameter when see a reason header,it makes me a a bit confused. :) >=20 > ps: > can somebody give me an answer about the following questions?=20 > I don't > find > the exact description in RFC 3261, thanks in advance!!! =20 >=20 > 1, how does the proxy handle the request which the request-URI=20 > includes a maddr parameter in different cases? > [MB] This is described in section 16.5 of RFC 3261: > "If the Request-URI of the request contains an maddr parameter, the > Request-URI MUST be placed into the target set as the only target > URI, and the proxy MUST proceed to Section 16.6." >=20 > So, the only thing the proxy can do is to use the maddr parameter -=20 > i.e., it's the new target. This hi-entry would be tagged as "rt".=20 > And, in this case the previous entry is NOT tagged as an "aor".[/MB] [nancy] you mean the request-URI should be replaced with the address in the maddr parameter?? or delete the maddr in the reqest-URI and add it to the route header?? >=20 >=20 > 2, If the domain of request-URI indicates is not that the proxy be=20 > responsible for,what actions should the proxy be taken? > [MB] Again per section 16.5: > "If the domain of the Request-URI indicates a domain this element=20 > is > not responsible for, the Request-URI MUST be placed into the target > set as the only target, and the element MUST proceed to the task of > Request Forwarding (Section 16.6)." >=20 > So, the only thing the proxy can do is to forward the request to the=20 > next hop proxy. This entry would be tagged as "rt". And, in this=20 > case the previous entry is NOT tagged as an "aor". [/MB] [nancy] you mean don't change the request-URI ,and add the address of next hop proxy to the route header,right? =20 >=20 > IMHO, the two cases are not retarget > [MB] In the document the term "retarget" is used in the most general=20 > sense (as it was in RFC 4244) to cover all of these cases - i.e.,=20 > forwardings (ala "rt") as well as the other cases - basically=20 > encompassing the process described in section 16.5 of RFC 3261. The=20 > primary purpose that term really serves is to make the document far=20 > less wordy and easier to read.[/MB] >=20 [nancy] I see the definition of 'retarget' in your draft as below: The term "retarget" is used in this document to refer both to the process of a Proxy Server/User Agent Client (UAC) changing a Uniform Resource Identifier (URI) in a request based on the rules for determining request targets as described in Section 16.5 of [RFC3261] and the subsequent forwarding of that request as described in section 16.6 of [RFC3261]. what 's the mean of "subsequent forwarding"?? i see that it needs to change the reqeust-URI first, right?? in this way, the ordinary forwarding can not be included in "retarget",such as the second question i describe as before. >=20 > Best Regards. >=20 > =20 > nancy >=20 > ******************************************************************* > This email and its attachments contain confidential information from=20 > HUAWEI, which is intended only for the person or entity whose address=20 > is listed above. > Any use of the information contained herein in any way (including, but > not limited to, total or partial disclosure, reproduction, or > dissemination) by persons > other than the intended recipient(s) is prohibited. If you receive=20 > this e-mail in error, please notify the sender by phone or email=20 > immediately and delete it! > ******************************************************************* >=20 From pkyzivat@cisco.com Thu Jul 16 07:07:31 2009 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 3599D3A6D52 for ; Thu, 16 Jul 2009 07:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.505 X-Spam-Level: X-Spam-Status: No, score=-6.505 tagged_above=-999 required=5 tests=[AWL=0.094, 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 5qd8WJE5VKip for ; Thu, 16 Jul 2009 07:07:30 -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 AC1783A6B97 for ; Thu, 16 Jul 2009 07:07:29 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAF/RXkpAZnme/2dsb2JhbAC4XogjkQkFgjSBVw X-IronPort-AV: E=Sophos;i="4.42,411,1243814400"; d="scan'208";a="50602313" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 16 Jul 2009 14:07:58 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6GE7w5r013079; Thu, 16 Jul 2009 10:07:58 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6GE7vFZ006640; Thu, 16 Jul 2009 14:07:57 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 10:07:57 -0400 Received: from [10.86.246.154] ([10.86.246.154]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 10:07:57 -0400 Message-ID: <4A5F3436.8090308@cisco.com> Date: Thu, 16 Jul 2009 10:07:50 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Hans Erik van Elburg References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com> <4A5E83CB.4090701@cisco.com> <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> In-Reply-To: <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2009 14:07:57.0429 (UTC) FILETIME=[D1EDD250:01CA061E] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=4983; t=1247753278; x=1248617278; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20rfc4244bis=3A=20what=20is=2 0an=20AoR? |Sender:=20 |To:=20Hans=20Erik=20van=20Elburg=20; bh=UV21PuVwuj35FHdblsCMjQZJHQOtqfN1Dc+NXv1mfH8=; b=XB/avrwrMkWvQ+HRguDcz1f5LVQ8QwDy1lM8baNYJrXXjCSsVxKXofjGOX Zx+EN5b10AuPOr7aUmkPYW1p+ogy7D5/zrmCwydcVyhEKNS/84+EDX/hJ/zE 92z57SrOTj; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 16 Jul 2009 14:07:31 -0000 Hans Erik van Elburg wrote: > I'd like to understand what is wrong with the RFC3261 definition of AOR? OK, rather than continuing to trust my memory I went back and reviewed the definition of AOR and Location Service in 3261, as well as the discussion around the use of the latter. I conclude that the existing definition of AOR is at least close, and that most of the cases I listed before fit within it. In particular, it seems that any translation of the incoming R-URI into a new value for the target set, except values received via 3xx responses, can be construed as coming from the use of a location service. This includes db lookups (such as ENUM) and algorithmic transformations. I see a couple of cases that that aren't covered by the above that IMO ought to be considered AORs: - If I become the owner of domain kyzivat.com, have it point to a server of mine, and establish a UA on that server that responds to sip:paul@kyzivat.com, then IMO sip:paul@kyzivat.com ought to be considered an AOR even though there is no location service and no domain proxy involved in accessing it. This wouldn't be important to the H-I discussion very often. But it might be if a request reached it, and it then chose to return a 3xx response. In that case I would think it should mark its own H-I entry as an AOR. - TEL URIs are currently never AORs because the def of AOR says they must be sip or sips URIs. But I think it makes a lot of sense to consider TEL URIs to be AORs. I do however realize this may be controversial. Aside from discussing if something should be tweaked to address these two cases I guess I am ok with the 3261 definition. Thanks, Paul > "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI that > points to a domain with a location service that can map the URI to > another URI where the user might be available. Typically, the location > service is populated through registrations. An AOR is frequently thought > of as the "public address" of the user." > > Currently I think it is the best we have, can we agree to adopt that as > leading for the tagging procedure? > > /Hans Erik van Elburg > > On Thu, Jul 16, 2009 at 3:35 AM, Paul Kyzivat > wrote: > > > > Francois Audet wrote: > > "aor" means it is "an AOR that I own AND I used for a > location service dip". > > > Hmm. the AND part is a bit troubling for me. > In this context the tag isn't added unless there is a translation > following it, so saying "AND I translated it" is ok by me. > But IMO things can be AORs without ever using a location service. My > example with alice and betty is one such case. > > Now perhaps we can argue that if you translate an R-URI (rather than > adding a Route header), then by definition what you did was use a > location service. If so then I guess I am ok, but that seems odd. > > Paul > > > I don't know if you view that as "different" or not. I guess > it's debatable. > > Again, in my humble opinion, a URI is an AOR only if the domain > responsible says so. And the way it knows it's an AOR is if it > can use it for the location service dip. > If people don't agree with the statement, then perhaps we should > change the name of the parameter. > > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com > ] Sent: Wednesday, July 15, 2009 > 16:25 > To: Audet, Francois (SC100:3055) > Cc: Hadriel Kaplan; SIPCORE > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > > If the tag is "aor" then I think it had better mean the same > thing ans AOR or AoR. And in the process help to tighten up > the definition of that. > > Having it mean "something like AoR, but not quite" is IMO a > *really* bad idea. > > If it really is different than AoR, then it had better be > called something else, and given a clear definition that > justifies a new concept. > > AFAIK the point here is to identify the URI as an Address of > Record. If we had a clear unambiguous definition of that, > which was also consistent with common understanding of the > term (by those who *ought* to know), then I don't think we > would be having this discussion. > > Thanks, > Paul > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > From mary.barnes@nortel.com Thu Jul 16 07:09:15 2009 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 9DEFB3A6D52 for ; Thu, 16 Jul 2009 07:09:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.348 X-Spam-Level: X-Spam-Status: No, score=-6.348 tagged_above=-999 required=5 tests=[AWL=0.250, 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 Lmb+aQtMdHn9 for ; Thu, 16 Jul 2009 07:09:14 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id DB3753A6BFE for ; Thu, 16 Jul 2009 07:09:12 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6GE9fw17733; Thu, 16 Jul 2009 14:09:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA061E.F71413C6" Date: Thu, 16 Jul 2009 09:11:23 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F05003A@zrc2hxm0.corp.nortel.com> In-Reply-To: <9ae56b1e0907160056vd2be5ael217db76f7f69ab16@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: rfc4244bis: backwards compatibility thread-index: AcoF6uwn7HYUSskfT7CcZlKYRrPgwQAM1M/g References: <9ae56b1e0907160056vd2be5ael217db76f7f69ab16@mail.gmail.com> From: "Mary Barnes" To: "Hans Erik van Elburg" , "Hadriel Kaplan" Cc: SIPCORE , draft-barnes-sipcore-rfc4244bis@tools.ietf.org Subject: Re: [sipcore] rfc4244bis: backwards compatibility 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, 16 Jul 2009 14:09:15 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA061E.F71413C6 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I think versioning is somewhat of a misnomer for what we're doing here. We are relying entirely on normal SIP extensibility mechanisms whereby an entity that needs a certain parameter needs to be able to handle the fact that another entity might not support the header or specific parameters. And, from the 4244 perspective, this requirement is already there since History-Info is optional. An application that relies on the new tags needs to have default behavior when the tags are not there. The reason we want to tag all the entries added by entities that do understand what these tags mean, is so that an application has a level of confidence that the specific hi-entry is NOT one that they care about - that might just help them be able to make use of an entry that isn't tagged, for example. From the protocol perspective, the objective is to provide as complete of information as possible (a core requirement for History-Info) - it's up to the specific application to figure out how relevant each bit of information is. =20 Mary.=20 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Thursday, July 16, 2009 2:56 AM To: Hadriel Kaplan Cc: SIPCORE; draft-barnes-sipcore-rfc4244bis@tools.ietf.org Subject: Re: rfc4244bis: backwards compatibility I still do not like this implicit versioning requirement on the tags. Either we do versioning or we don't, but do not fold it in to the meaning of the other tags.=20 Get the feeling that the only reason that the fluff tags (cc, rc, rt) exist is because of this implicit versioning requirement. I vote for no versioning. Do n't thisnk that it is required. /Hans Erik van Elburg On Thu, Jul 16, 2009 at 12:47 AM, Hadriel Kaplan wrote: This tagging allows for distinguishing entries that were added by an [RFC4244] entity, versus one that was added by an entity conforming to this specification. ------_=_NextPart_001_01CA061E.F71413C6 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
I=20 think versioning is somewhat of a misnomer for what we're doing = here.=20  We are relying entirely on normal SIP extensibility mechanisms = whereby an=20 entity that needs a certain parameter needs to be able to handle the = fact that=20 another entity might not support the header or specific parameters. =  And,=20 from the 4244 perspective, this requirement is already there since = History-Info=20 is optional. An application that relies on the new tags needs to have = default=20 behavior when the tags are not there.  The reason we want to tag = all the=20 entries added by entities that do understand what these tags mean, is so = that an=20 application has a level of confidence that the specific hi-entry is NOT = one that=20 they care about - that might just help them be able to make use of an = entry that=20 isn't tagged, for example.  From the protocol perspective, the = objective is=20 to provide as complete of information as possible (a core requirement = for=20 History-Info) - it's up to the specific application to figure out how = relevant=20 each bit of information is.
 
Mary.=20

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: Thursday, July 16, = 2009 2:56=20 AM
To: Hadriel Kaplan
Cc: SIPCORE;=20 draft-barnes-sipcore-rfc4244bis@tools.ietf.org
Subject: Re:=20 rfc4244bis: backwards compatibility

I still do not like this implicit versioning requirement on = the tags.=20 Either we do versioning or we don't, but do not fold it in to the = meaning of the=20 other tags.

Get the feeling that the only reason that the fluff tags (cc, rc, = rt) exist=20 is because of this implicit versioning requirement.

I vote for no versioning. Do n't thisnk that it is required.

/Hans Erik van Elburg


On Thu, Jul 16, 2009 at 12:47 AM, Hadriel = Kaplan <HKaplan@acmepacket.com>=20 wrote:
This tagging allows for = distinguishing
 =20 entries that were added by an [RFC4244] entity, versus one that = was
 =20 added by an entity conforming to this=20 specification.

------_=_NextPart_001_01CA061E.F71413C6-- From AUDET@nortel.com Thu Jul 16 08:26:08 2009 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 F11D028C198 for ; Thu, 16 Jul 2009 08:26:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.462 X-Spam-Level: X-Spam-Status: No, score=-6.462 tagged_above=-999 required=5 tests=[AWL=0.137, 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 wje0RmTCYFJ2 for ; Thu, 16 Jul 2009 08:26:06 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id A6CC13A6D45 for ; Thu, 16 Jul 2009 08:26:05 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6GFOeD02073; Thu, 16 Jul 2009 15:24:40 GMT 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, 16 Jul 2009 10:25:52 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F050229@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoFRoWh2hBP5wjyQIWzHzootDGkMgASGu2gAAAGFAAAAfQZ4AACliEQACH8yyA= References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Hadriel Kaplan" , "SIPCORE" Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 16 Jul 2009 15:26:08 -0000 Hi Hadriel, In my humble opinion, those 2 examples are in fact AORs. I.e., they "map" to another URI where the user may be available. > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Wednesday, July 15, 2009 17:19 > To: Audet, Francois (SC100:3055); SIPCORE > Subject: RE: [sipcore] rfc4244bis: what is an AoR? >=20 >=20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Wednesday, July 15, 2009 5:57 PM > >=20 > > But I can't think of cases where the tag "aor" would not be=20 > applied to=20 > > somthing that is not an AOR. >=20 > I think there are cases where an "aor" tag would be applied=20 > to something that's not an AoR, and probably vice-versa. But=20 > maybe I'm not thinking about this quite right. >=20 > Example-1: ENUM is used widely, as both a means of performing=20 > "pure" E.164 number to AoR resolution, Number Portability,=20 > inter-domain routing, intra-domain routing, and even=20 > registered contact routing. An ENUM query can be described=20 > as a location-service lookup. Proxies performing an ENUM=20 > query don't necessarily know what type of URI they are=20 > performing that query for. So if they get a request for=20 > "sip:+1234567890@sp.com" and do the query and the result=20 > makes it change it for inter-domain routing, then the=20 > original URI was not a AoR; if the result made it send it to=20 > a UAS/gateway directly, then it was an AoR. Right? Since=20 > the proxy won't know when, it will have to tag it as AoR=20 > every time, no? >=20 > Example-2: it is not rare for the req-uri sent to the proxy=20 > with which it does a lookup to not actually be the AoR per se=20 > - for example, the proxy may receive a req-uri of=20 > "sip:+123456790@proxy1.sp.com". It resolves this to the=20 > registered contact for the "real" AoR of=20 > "sip:234567890@sp.com" - by "real" I mean the one registered=20 > and known by the UAS. Now one could say the proxy should=20 > have added that real AoR in an H-I entry as another=20 > intermediate/internal step before resolution, because in=20 > theory the URI used for the resolution was the real AoR not=20 > the req-uri received; but that's getting into the internal=20 > mechanics of how the proxy was implemented. For example the=20 > proxy may have done an ENUM lookup using only the username,=20 > and not know the "real" AoR's domain portion was different. =20 > It was authoritative for "proxy1.sp.com" (it's also=20 > authoritative for "sp.com"), and it did a location lookup=20 > using "sip:+123456790@proxy1.sp.com", so all the conditions=20 > were met - but it's not the actual AoR the UAS needs to see,=20 > nor what we would consider a "classic" AoR (not what one=20 > would put on a business card, for example). No? >=20 > -hadriel >=20 From AUDET@nortel.com Thu Jul 16 08:35:39 2009 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 4311B3A67AC for ; Thu, 16 Jul 2009 08:35:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.464 X-Spam-Level: X-Spam-Status: No, score=-6.464 tagged_above=-999 required=5 tests=[AWL=0.135, 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 4EQyO2orj--0 for ; Thu, 16 Jul 2009 08:35:38 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 0D1863A6C7F for ; Thu, 16 Jul 2009 08:35:37 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6GFYQD03346; Thu, 16 Jul 2009 15:34:26 GMT 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, 16 Jul 2009 10:36:02 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F050278@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoFRoWh2hBP5wjyQIWzHzootDGkMgASGu2gAAAGFAAAAfQZ4AAFHSTAAB+cnZA= References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Hadriel Kaplan" , "SIPCORE" Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 16 Jul 2009 15:35:39 -0000 In my opinion, if a proxy does a Call Forwarding (for example), on a number that it believes it owns, in fact that is an AOR and would be marked as such. Where this gets form complicated, and where I think you have a point, is when using phone numbers (say, embedded in a SIP URI, but where the domain is effectively meaningless). A proxy may redirect, say, sip:+18005551212@att.com;user=3Dphone to sip:+14084444419@example.com;user=3Dphone. This type of stuff has created problems for us before. Using the current draft rules, the second entry would be marked with mp, and the first one may or may not be marked with aor. And that's where the ambiguity is. Specifically, most algorithm need the first entry, not the second. But you don't know that it was a "redirection" unless you look at the second one. I believe=20 anything that relies on "go to X and look at X-1" (or X+1) is risky since the entry may not be there. It would be better if the non-fluff entry was always flagged. I don't think our draft today achieves this with the specific case of "mapped". One potential way around this would be to move the "mp" tag back to mean "the entry that was mapped" instead of leaving it where it is now, on the second entry, as "the number it was mapped too". Or maybe have aor-same and aor-mapped. Comments? > -----Original Message----- > From: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Sent: Wednesday, July 15, 2009 17:25 > To: Audet, Francois (SC100:3055); SIPCORE > Subject: RE: [sipcore] rfc4244bis: what is an AoR? >=20 >=20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Wednesday, July 15, 2009 5:57 PM > >=20 > > It is certainly true that not all AORs will be tagged. >=20 > I don't disagree with you on that, but it worries me. The=20 > assumption I was going on was that the H-I list could be=20 > reduced to the set only tagged with "aor" and "mp"; would=20 > having entries not tagged "aor" which are in fact AoR's break=20 > that? Or would those entries not matter either. (ie, would=20 > they be AoR's from a technical aspect but not necessary for=20 > consideration in app-specific uses of H-I entries?) >=20 > -hadriel >=20 From AUDET@nortel.com Thu Jul 16 08:42:29 2009 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 2F2FA28C193 for ; Thu, 16 Jul 2009 08:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.465 X-Spam-Level: X-Spam-Status: No, score=-6.465 tagged_above=-999 required=5 tests=[AWL=0.134, 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 A9-VMb8buHq5 for ; Thu, 16 Jul 2009 08:42:28 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id D4F2028C180 for ; Thu, 16 Jul 2009 08:42:27 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6GFgsw19922; Thu, 16 Jul 2009 15:42:54 GMT 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, 16 Jul 2009 10:42:25 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F0502A4@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoFo9w3rc9bbN34Th6DpXoY4c7pmwAWlkPQAAtdmeA= References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com><4A5E5D5F.80908@cisco.com><1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> From: "Francois Audet" To: "DRAGE, Keith (Keith)" , "Paul Kyzivat" Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 16 Jul 2009 15:42:29 -0000 Right, what's missing in there is a qualifier that only the entity responsible for the domain in the entry can mark it as an AOR. To me this is self-obvious in RFC 3261. You can't=20 recognize an AOR just by looking at a URI. You HAVE to be the domain of the URI to know if it's an AOR. But we can certainly make that clear in the text. > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: Thursday, July 16, 2009 04:11 > To: Paul Kyzivat; Audet, Francois (SC100:3055) > Cc: SIPCORE; Hadriel Kaplan > Subject: RE: [sipcore] rfc4244bis: what is an AoR? >=20 > Agree with Paul. >=20 > In terms of process, I understand the current definition of=20 > the tag is based on the RFC 3261 defn of AOR. How do we need=20 > to change that definition to represent what people now=20 > understand. (current text follows) >=20 > o AOR indicator: The AOR indicator is to mark an URI=20 > entry as being > an Address Of Record. >=20 > and >=20 > o AOR indicator (hi-aor): An optional parameter for the=20 > History-Info > indicating that the hi-targeted-to-uri is an Address Of=20 > Record (as > defined in section 6/[RFC3261]) . The hi-aor parameter is added > by a proxy or redirect server to a hi-entry when it=20 > recognizes the > URI in the last entry as a URI in its abstract location service > (and then it can be routed accordingly). Therefore, the hi-aor > parameter (i.e., "aor") is not added for a hi-entry when it is > first added in a History-Info header field, but rather is added > when the retargeting actually occurs - i.e., the parameter > indicates that the specific hi-targeted-to-uri that was=20 > retargeted > was an AOR and thus the previous information in the request-URI > may be "lost". Upon receipt of a request or response containing > the History-Info header, a UA can determine a "lost" target AOR > for a request by traversing the HI entries in reverse order to > find the first one tagged with a specific hi-aor parameter. >=20 > Then we can think of a name. >=20 > Keith >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > > Sent: Thursday, July 16, 2009 12:25 AM > > To: Francois Audet > > Cc: SIPCORE; Hadriel Kaplan > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > >=20 > > If the tag is "aor" then I think it had better mean the=20 > same thing ans=20 > > AOR or AoR. And in the process help to tighten up the definition of=20 > > that. > >=20 > > Having it mean "something like AoR, but not quite" is IMO a > > *really* bad idea. > >=20 > > If it really is different than AoR, then it had better be called=20 > > something else, and given a clear definition that justifies a new=20 > > concept. > >=20 > > AFAIK the point here is to identify the URI as an Address=20 > of Record.=20 > > If we had a clear unambiguous definition of that, which was also=20 > > consistent with common understanding of the term (by those=20 > who *ought*=20 > > to know), then I don't think we would be having this discussion. > >=20 > > Thanks, > > Paul > >=20 > > Francois Audet wrote: > > > =20 > > >=20 > > >> -----Original Message----- > > >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > >> Sent: Wednesday, July 15, 2009 15:51 > > >> To: Audet, Francois (SC100:3055) > > >> Cc: Hadriel Kaplan; SIPCORE > > >> Subject: Re: [sipcore] rfc4244bis: what is an AoR? > > >> > > >> > > >> > > >> Francois Audet wrote: > > >>> Well, sort of. > > >>> > > >>> But I can't think of cases where the tag "aor" would not be > > >> applied to > > >>> somthing that is not an AOR. > > >>> > > >>> It is certainly true that not all AORs will be tagged. > > >>> > > >>> In my mind, the tag meant "I recorgnize this as being=20 > the AOR I'm=20 > > >>> responsible for, and that I'm using for the database dip". > > >> I think I agree with Francois, but that definition is circular. > > >> > > >> I'm saying "its an AOR if somebody from its domain *says* > > its an AOR." > > >=20 > > > Yes. Agree. > > >=20 > > >> But I don't think thats enough - I've seen too many cases > > when people > > >> are willing to assert things that make no sense. > > >> If you just got an address from DHCP, then you had better > > not assert > > >> that some URI containing that is an AOR. > > >> > > >> I think the meaning of the URI needs to be stable over some=20 > > >> reasonably long period of time before it qualifies as an AOR. > > >> But the meaning of "meaning" is also a bit squishy there.=20 > > It doesn't > > >> have to represent the same *person* (or call center > > addresses aren't > > >> AORs), and it doesn't have to represent the same device.=20 > > It just has > > >> to represent some stable "role" or "presentity" or something. > > >> > > >> Nor, IMO, does it have to translate to something else.=20 > > While it might > > >> be unusual, it is *possible* for an AOR to resolve > > directly to a UAS. > > >> > > >> And if it does translate to something else, it need not be via a=20 > > >> location service, though that is a common way. > > >=20 > > > Yes, but let's remember that this tag we called "aor" in > > this draft is > > > meant for a specific purpose, i.e., isolating the important > > URIs from > > > the "fluff". So the job of UASs and upstream proxies is easier. > > >=20 > > > It's not like we are going to give a plaque of > > congratulations saying > > > "Genuine AOR (tm)" or anything like that. The point is not > > to define > > > something as an ARO. The point is to mark an address has > > having value > > > for the domain, in resolving it using it's location service. > > >=20 > > > Like somebody else said (think it was Hadriel), this is lower-case > > > "aor: the tag" as opposed to upper-case "AOR: the classic > > definition". > > >=20 > > > If we can think of a better tag name, maybe it would help. I=20 > > > personally like "aor" because frankly, even for a AOR, you > > can't know > > > a URI is an AOR, unless you are the pornographer responsible for=20 > > > minting it :-) > > >=20 > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore > >=20 >=20 From AUDET@nortel.com Thu Jul 16 08:44:38 2009 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 CACAC3A69D9 for ; Thu, 16 Jul 2009 08:44:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.466 X-Spam-Level: X-Spam-Status: No, score=-6.466 tagged_above=-999 required=5 tests=[AWL=0.132, 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 YJvE95bRBbbw for ; Thu, 16 Jul 2009 08:44:37 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 8003B3A67AC for ; Thu, 16 Jul 2009 08:44:37 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6GFj0w20485; Thu, 16 Jul 2009 15:45:00 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA062C.5AFF5762" Date: Thu, 16 Jul 2009 10:44:50 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F0502BA@zrc2hxm0.corp.nortel.com> In-Reply-To: <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoF57j/ITCgheiaQxSCHZhpJtIViAARJWjQ References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com> <4A5E83CB.4090701@cisco.com> <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> From: "Francois Audet" To: "Hans Erik van Elburg" , "Paul Kyzivat" Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 16 Jul 2009 15:44:38 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA062C.5AFF5762 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yep, and I thing this definion is EXACTLY what we are using in the = document. ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Thursday, July 16, 2009 00:33 To: Paul Kyzivat Cc: Audet, Francois (SC100:3055); SIPCORE; Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? =09 =09 I'd like to understand what is wrong with the RFC3261 definition of = AOR? =20 "Address-of-Record: An address-of-record (AOR) is a SIP or SIPS URI = that points to a domain with a location service that can map the URI to = another URI where the user might be available. Typically, the location = service is populated through registrations. An AOR is frequently thought = of as the "public address" of the user." Currently I think it is the best we have, can we agree to adopt that as = leading for the tagging procedure? /Hans Erik van Elburg =09 =09 On Thu, Jul 16, 2009 at 3:35 AM, Paul Kyzivat = wrote: =09 Francois Audet wrote: =09 "aor" means it is "an AOR that I own AND I used for a location service dip".=20 =09 Hmm. the AND part is a bit troubling for me. In this context the tag isn't added unless there is a translation = following it, so saying "AND I translated it" is ok by me. But IMO things can be AORs without ever using a location service. My = example with alice and betty is one such case. =09 Now perhaps we can argue that if you translate an R-URI (rather than = adding a Route header), then by definition what you did was use a = location service. If so then I guess I am ok, but that seems odd. =09 Paul=20 I don't know if you view that as "different" or not. I guess it's debatable. =09 Again, in my humble opinion, a URI is an AOR only if the domain responsible says so. And the way it knows it's an AOR is if it can = use it for the location service dip.=20 If people don't agree with the statement, then perhaps we should change the name of the parameter. =20 =09 -----Original Message----- From: Paul Kyzivat [mailto:pkyzivat@cisco.com] Sent: Wednesday, July = 15, 2009 16:25 To: Audet, Francois (SC100:3055) Cc: Hadriel Kaplan; SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? =09 If the tag is "aor" then I think it had better mean the same thing = ans AOR or AoR. And in the process help to tighten up the definition of = that. =09 Having it mean "something like AoR, but not quite" is IMO a *really* = bad idea. =09 If it really is different than AoR, then it had better be called = something else, and given a clear definition that justifies a new = concept. =09 AFAIK the point here is to identify the URI as an Address of Record. = If we had a clear unambiguous definition of that, which was also = consistent with common understanding of the term (by those who *ought* = to know), then I don't think we would be having this discussion. =09 Thanks, Paul =09 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore =09 ------_=_NextPart_001_01CA062C.5AFF5762 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
Yep,=20 and I thing this definion is EXACTLY what we are using in the=20 document.

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: Thursday, July 16, = 2009=20 00:33
To: Paul Kyzivat
Cc: Audet, Francois = (SC100:3055);=20 SIPCORE; Hadriel Kaplan
Subject: Re: [sipcore] rfc4244bis: = what is=20 an AoR?

I'd like to understand what is wrong with the RFC3261 = definition of=20 AOR? 

"Address-of-Record: An address-of-record (AOR) is a SIP or SIPS = URI that=20 points to a domain with a location service that can map the URI to = another URI=20 where the user might be available. Typically, the location service is=20 populated through registrations. An AOR is frequently thought of as = the=20 "public address" of the user."

Currently I think it is the best we have, can we agree to adopt = that as=20 leading for the tagging procedure?

/Hans Erik van Elburg

On Thu, Jul 16, 2009 at 3:35 AM, Paul Kyzivat = <pkyzivat@cisco.com> = wrote:


Francois Audet wrote:
"aor"=20 means it is "an AOR that I own AND I used for a
location = service dip".=20

Hmm. the AND part is a bit troubling = for=20 me.
In this context the tag isn't added unless there is a = translation=20 following it, so saying "AND I translated it" is ok by me.
But = IMO things=20 can be AORs without ever using a location service. My example with = alice and=20 betty is one such case.

Now perhaps we can argue that if you=20 translate an R-URI (rather than adding a Route header), then by = definition=20 what you did was use a location service. If so then I guess I am ok, = but=20 that seems odd.

     =20  Paul


I=20 don't know if you view that as "different" or not. I guess
it's = debatable.

Again, in my humble opinion, a URI is an AOR = only if the=20 domain
responsible says so. And the way it knows it's an AOR is = if it=20 can use it for the location service dip.
If people don't agree = with=20 the statement, then perhaps we should
change the name of the = parameter.=20  
-----Original=20 Message-----
From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 Sent: Wednesday, July 15, 2009 16:25
To: Audet, Francois=20 (SC100:3055)
Cc: Hadriel Kaplan; SIPCORE
Subject: Re: = [sipcore]=20 rfc4244bis: what is an AoR?

If the tag is "aor" then I = think it=20 had better mean the same thing ans AOR or AoR. And in the = process help=20 to tighten up the definition of that.

Having it mean = "something=20 like AoR, but not quite" is IMO a *really* bad idea.

If = it really=20 is different than AoR, then it had better be called something = else, and=20 given a clear definition that justifies a new = concept.

AFAIK the=20 point here is to identify the URI as an Address of Record. If we = had a=20 clear unambiguous definition of that, which was also consistent = with=20 common understanding of the term (by those who *ought* to know), = then I=20 don't think we would be having this discussion.

  =  =20    Thanks,
     =20 =  Paul

_____________________________= __________________
sipcore=20 mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

------_=_NextPart_001_01CA062C.5AFF5762-- From AUDET@nortel.com Thu Jul 16 08:50:35 2009 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 5FC1128C225 for ; Thu, 16 Jul 2009 08:50:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.467 X-Spam-Level: X-Spam-Status: No, score=-6.467 tagged_above=-999 required=5 tests=[AWL=0.131, 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 l+9go+Zgolwm for ; Thu, 16 Jul 2009 08:50:34 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 34DE728C193 for ; Thu, 16 Jul 2009 08:50:33 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6GFp3w22260; Thu, 16 Jul 2009 15:51:03 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA062D.16042D1C" Date: Thu, 16 Jul 2009 10:50:03 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F0502D8@zrc2hxm0.corp.nortel.com> In-Reply-To: <9ae56b1e0907160001u54c095e8o3761f9294a36a456@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoF40D/AyK56Z52Tz6KS4NliReDgwASSzgw References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <9ae56b1e0907160001u54c095e8o3761f9294a36a456@mail.gmail.com> From: "Francois Audet" To: "Hans Erik van Elburg" , "Hadriel Kaplan" Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 16 Jul 2009 15:50:35 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA062D.16042D1C Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable =20 Example-1: ENUM is used widely, as both a means of performing "pure" = E.164 number to AoR resolution, Number Portability, inter-domain = routing, intra-domain routing, and even registered contact routing. An = ENUM query can be described as a location-service lookup. Proxies = performing an ENUM query don't necessarily know what type of URI they = are performing that query for. So if they get a request for = "sip:+1234567890@sp.com " and do the = query and the result makes it change it for inter-domain routing, then = the original URI was not a AoR; if the result made it send it to a = UAS/gateway directly, then it was an AoR. Right? Since the proxy won't = know when, it will have to tag it as AoR every time, no? In IMS this would be completely clear to me as not being one qualifying = for an aor tag, as it is proxy that acts on behalf of the originating = user that would perform the ENUM dip to be able to know where to route = the request. First when it enters the proxy(-instance) that acts on = behalf of a terminating user the aor tagging would start. As for genuine SIP proxies this distinction does not seem to be = specified we are having this debate. I have this feeling that I'm missing a suttlety here because of my lack = of knowledge of IMS.... =20 Say I call sip:+1234567890@sp.com = ;user=3Dphone. My proxy is "sp.com", right?=20 =20 Then sp.net does ENUM query. Then it forwards the request to whatever = the result of the ENUM query was, say sip:+1234567890@example.com = ;user=3Dphone. Correct? =20 So the ;aor tag would be added by example.com. Is this what you are = saying? =20 If so, I think I agree. ------_=_NextPart_001_01CA062D.16042D1C Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
 

Example-1:=20 ENUM is used widely, as both a means of performing "pure" E.164 = number to=20 AoR resolution, Number Portability, inter-domain routing, = intra-domain=20 routing, and even registered contact routing.  An ENUM query = can be=20 described as a location-service lookup.  Proxies performing an = ENUM=20 query don't necessarily know what type of URI they are performing = that query=20 for.  So if they get a request for "sip:+1234567890@sp.com" = and do=20 the query and the result makes it change it for inter-domain = routing, then=20 the original URI was not a AoR; if the result made it send it to a=20 UAS/gateway directly, then it was an AoR.  Right?  Since = the proxy=20 won't know when, it will have to tag it as AoR every time, = no?

In IMS this would be completely clear to me as not being one = qualifying=20 for an aor tag, as it is proxy that acts on behalf of the originating = user=20 that would perform the ENUM dip to be able to know where to route the = request.=20 First when it enters the proxy(-instance) that acts on behalf of a = terminating=20 user the aor tagging would start.

As for genuine SIP proxies  this distinction does not seem = to be=20 specified we are having this debate.
I have=20 this feeling that I'm missing a suttlety here because of my lack of = knowledge of=20 IMS....
 
Say I=20 call sip:+1234567890@sp.com;user=3Dphone. My proxy is = "sp.com",=20 right?
 
Then sp.net does ENUM query. Then it forwards the request = to=20 whatever the result of the ENUM query was, say sip:+1234567890@example.com;user=3Dphone.=20 Correct?
 
So the=20 ;aor tag would be added by example.com. Is this what you are=20 saying?
 
If so,=20 I think I agree.
------_=_NextPart_001_01CA062D.16042D1C-- From HKaplan@acmepacket.com Thu Jul 16 08:54:16 2009 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 02CB53A6D8B for ; Thu, 16 Jul 2009 08:54:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 Rnm7V3LF7cIC for ; Thu, 16 Jul 2009 08:54:15 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 1B08828C1CB for ; Thu, 16 Jul 2009 08:54: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.1.375.2; Thu, 16 Jul 2009 11:54:28 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 16 Jul 2009 11:54:28 -0400 From: Hadriel Kaplan To: SIPCORE , Hans Erik van Elburg Date: Thu, 16 Jul 2009 11:54:26 -0400 Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoF40/YrAyccMz5QVChzp/Hfa1QpwAQ/LggAABd0nA= 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] rfc4244bis: what is an AoR? 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, 16 Jul 2009 15:54:16 -0000 > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > Sent: Thursday, July 16, 2009 3:02 AM >=20 > inline... > /Hans Erik van Elburg >=20 > In IMS this would be completely clear to me as not being one qualifying > for an aor tag, as it is proxy that acts on behalf of the originating use= r > that would perform the ENUM dip to be able to know where to route the > request. First when it enters the proxy(-instance) that acts on behalf of > a terminating user the aor tagging would start. I'm not sure this is possible in IMS (I'm not one of the folks that follow = 3GPP in my company), but assume a SIP request came into an I-BCF from an En= terprise IP-PBX. The I-BCF does an ENUM dip for the target "sip:+123456789= 01@sp.com;user=3Dphone", and the result makes it either (1) route it to ano= ther I-BCF and another Enterprise behind that, vs. (2) in another case it m= akes it route it to a PSTN-GW, vs. (3) route it to an S-CSCF and ultimate P= -CSCF/UE beyond that. Was the number it did the ENUM query with an AoR in = all these cases? Should it be tagged with "aor" in all 3 cases? > You would not perform an ENUM dip for a SIP URI destined for your domain, > would you? Yup, I sure would. In fact it happens all the time. -hadriel From mary.barnes@nortel.com Thu Jul 16 09:07:26 2009 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 6720C3A6DB6 for ; Thu, 16 Jul 2009 09:07:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.453 X-Spam-Level: X-Spam-Status: No, score=-5.453 tagged_above=-999 required=5 tests=[AWL=-0.654, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_65=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 KcVwnEec4tWD for ; Thu, 16 Jul 2009 09:07:25 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id E07163A6930 for ; Thu, 16 Jul 2009 09:07:24 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6GG5KD08705; Thu, 16 Jul 2009 16:05:21 GMT 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: Thu, 16 Jul 2009 11:08:53 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F050359@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Privacy "none" (was RE: [sipcore] rfc4244bis thread-index: AcoGHM5Rm2IAvDFbQ1Wky+vmMBibLwABgGWA References: <1ECE0EB50388174790F9694F77522CCF1EFE0971@zrc2hxm0.corp.nortel.com> <006701ca05b7$7cca7ec0$271d550a@china.huawei.com> From: "Mary Barnes" To: "Ian Elz" , "fanyanping" Cc: sipcore@ietf.org Subject: [sipcore] Privacy "none" (was RE: 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, 16 Jul 2009 16:07:26 -0000 Ian, Thanks for the response. Just one question below [MB]. Mary. -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com]=20 Sent: Thursday, July 16, 2009 8:54 AM To: fanyanping; Barnes, Mary (RICH2:AR00) Cc: sipcore@ietf.org Subject: RE: [sipcore] rfc4244bis Nancy, Mary, We have discussed this issue previously. The key issues are outside the scope of the 4244bis draft and needs to be discussed separately. The issue with RFC3323 is that this RFC only discusses privacy from an originating and terminating user perspective. Separate discussions are required on how privacy for 3rd party identities included in a sip messages is handled. The current interpretation that you cannot override what is included in the Privacy header results in two specific issues: - originating user includes a Privacy value of user/header/id which means that the 3rd party identity has the same privacy. If the 3rd party identity should be allowed then this may impact services which use the third party identity. The example which has been quoted is the Freephone call where the Freephone number is used for call handling. This is inconvenient for services which need to use this information. - originating user explicitly specifies "Privacy: none" in the originating request. This means that the 3rd party identity cannot be protected. This has much more serious impact as it makes SIP as defined 'not fit for purpose' in most regulated telephony environments. This is due to regulatory requirements to allow the privacy for each user to be specified and handled correctly. This however is outside the scope of the H-I changes but I would suggest that the new draft specifically allows the inclusion of the 'none' value in the escaped Privacy header in the hi-targeted-to-uri. [MB] Are you suggesting that we allow this "none" even in the case where there is for example, a privacy header "history" at the request level? I'm not so comfortable with that as it overrides what the UAC might have included in the original request. If that's not what your suggesting, what would adding "none" to an entry give you anyways? An entity cannot arbitrarily add "none" to entries added by another entity nor can it override policy. [/MB] Ian -----Original Message----- From: fanyanping [mailto:fanyanping@huawei.com] Sent: 16 July 2009 02:48 To: 'Mary Barnes' Cc: sipcore@ietf.org Subject: Re: [sipcore] rfc4244bis Hi mary, my response are inline below [nancy] , thanks:) > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Wednesday, July 15, 2009 10:46 PM > To: fanyanping > Subject: RE: [sipcore] rfc4244bis >=20 > Hi Nancy, >=20 > My responses are inline below [MB]. Note, it does not look like your=20 > original message went to the mailing list. Feel free to respond to the > mailing list. >=20 > Regards, > Mary.=20 >=20 > -----Original Message----- > From: fanyanping [mailto:fanyanping@huawei.com] > Sent: Wednesday, July 15, 2009 5:24 AM > To: sipcore-bounces@ietf.org > Cc: Barnes, Mary (RICH2:AR00) > Subject: Re: [sipcore] rfc4244bis >=20 >=20 > Hi mary, >=20 > I have read the draft of draft-barnes-sipcore-rfc4244bis-02.txt, there > are some issues i don't understand clearly, as blow: > 1, section 4.1 mentions > UAC that wants to ensure that privacy not be applied to its identity=20 > MUST include a Privacy header with a priv- value of "none." >=20 > but section 6.3.1(Privacy in the History-Info Header) doesn't has=20 > relevant description, can a proxy include a Privacy header with a > priv- value of "none" to a specifical hi-entry?? how to handle the=20 > "none" in different cases? >=20 > [MB] We have not precluded the use of "none". We did have a long=20 > debate that the "none" in the hi-entry cannot override a privacy=20 > header at the request level. And, section 4.1 is discussing privacy=20 > at the request level. So, I'm not sure what additional functionality=20 > you might get if you added "none" to a specific hi-entry - in a sense=20 > that's the default IF there is no privacy header at the request=20 > level.[/MB] [nancy] I get it , thanks, review RFC3323, i find i make a mistake,:) >=20 > 2,section 6.1 mentions > The hi-target is added for a hi-entry when it is first added in a=20 > History-Info header field >=20 > but in the previous draft, the hi-target is not added for a hi-entry=20 > when it is first added in a History-Info header field, it is added to > the last hi-entry received in the request >=20 > compare the two methods, what is the advantage of the first one? i see > that rosenberg's target-uri-delivery draft adopts the second one >=20 > [MB] You are correct - we have changed the solution approach.=20 > The reason > we've done so is that we want to capture the mechanism by which the=20 > new target was determined. At that point in time, as well, we can=20 > determine whether the previous target (i.e., the one in the incoming > Request) was > an "aor". So, we now tag the previous entry with the "aor" tag if=20 > appropriate. The first method does add some complexity for the 3xx=20 > handling, which is why you see a lot more text for that in the new=20 > version. The second approach was trying to be consistent with how the=20 > entries are tagged with the "Reason" header. But, we decided that by=20 > tagging the new hi-entry we are actually capturing more (accurate)=20 > information. We have tried to be precise in the text, so if you can=20 > point out any text that makes this unclear, that would be very=20 > helpful. > [/MB] =20 [nancy] previously, the reason header and hi-target parameter in the hi-entry are matched, but now i need to find the next hi-entry's hi-target parameter when see a reason header,it makes me a a bit confused. :) >=20 > ps: > can somebody give me an answer about the following questions?=20 > I don't > find > the exact description in RFC 3261, thanks in advance!!! =20 >=20 > 1, how does the proxy handle the request which the request-URI=20 > includes a maddr parameter in different cases? > [MB] This is described in section 16.5 of RFC 3261: > "If the Request-URI of the request contains an maddr parameter, the > Request-URI MUST be placed into the target set as the only target > URI, and the proxy MUST proceed to Section 16.6." >=20 > So, the only thing the proxy can do is to use the maddr parameter -=20 > i.e., it's the new target. This hi-entry would be tagged as "rt". > And, in this case the previous entry is NOT tagged as an "aor".[/MB] [nancy] you mean the request-URI should be replaced with the address in the maddr parameter?? or delete the maddr in the reqest-URI and add it to the route header?? >=20 >=20 > 2, If the domain of request-URI indicates is not that the proxy be=20 > responsible for,what actions should the proxy be taken? > [MB] Again per section 16.5: > "If the domain of the Request-URI indicates a domain this element=20 > is > not responsible for, the Request-URI MUST be placed into the target > set as the only target, and the element MUST proceed to the task of > Request Forwarding (Section 16.6)." >=20 > So, the only thing the proxy can do is to forward the request to the=20 > next hop proxy. This entry would be tagged as "rt". And, in this=20 > case the previous entry is NOT tagged as an "aor". [/MB] [nancy] you mean don't change the request-URI ,and add the address of next hop proxy to the route header,right? =20 >=20 > IMHO, the two cases are not retarget > [MB] In the document the term "retarget" is used in the most general=20 > sense (as it was in RFC 4244) to cover all of these cases - i.e.,=20 > forwardings (ala "rt") as well as the other cases - basically=20 > encompassing the process described in section 16.5 of RFC 3261. The=20 > primary purpose that term really serves is to make the document far=20 > less wordy and easier to read.[/MB] >=20 [nancy] I see the definition of 'retarget' in your draft as below: The term "retarget" is used in this document to refer both to the process of a Proxy Server/User Agent Client (UAC) changing a Uniform Resource Identifier (URI) in a request based on the rules for determining request targets as described in Section 16.5 of [RFC3261] and the subsequent forwarding of that request as described in section 16.6 of [RFC3261]. what 's the mean of "subsequent forwarding"?? i see that it needs to change the reqeust-URI first, right?? in this way, the ordinary forwarding can not be included in "retarget",such as the second question i describe as before. >=20 > Best Regards. >=20 > =20 > nancy >=20 > ******************************************************************* > This email and its attachments contain confidential information from=20 > HUAWEI, which is intended only for the person or entity whose address=20 > is listed above. > Any use of the information contained herein in any way (including, but > not limited to, total or partial disclosure, reproduction, or > dissemination) by persons > other than the intended recipient(s) is prohibited. If you receive=20 > this e-mail in error, please notify the sender by phone or email=20 > immediately and delete it! > ******************************************************************* >=20 From AUDET@nortel.com Thu Jul 16 09:14:29 2009 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 AE9BC3A6930 for ; Thu, 16 Jul 2009 09:14:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.469 X-Spam-Level: X-Spam-Status: No, score=-6.469 tagged_above=-999 required=5 tests=[AWL=0.130, 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 gnENkTVmylpQ for ; Thu, 16 Jul 2009 09:14:28 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id CC81D3A67AC for ; Thu, 16 Jul 2009 09:13:47 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6GGCjw00469; Thu, 16 Jul 2009 16:12:46 GMT 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, 16 Jul 2009 11:11:49 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F050388@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A5F3436.8090308@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoGHtYXIm/SdjKSRm617d7OntvYUAADr/pQ References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com> <4A5E83CB.4090701@cisco.com> <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> <4A5F3436.8090308@cisco.com> From: "Francois Audet" To: "Paul Kyzivat" , "Hans Erik van Elburg" Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 16 Jul 2009 16:14:29 -0000 Ok, it seems we are reaching the same conclusions.=20 (This is why we took care to really go back to reading 3261 when writting this draft). In any case, see below: > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Thursday, July 16, 2009 07:08 > To: Hans Erik van Elburg > Cc: Audet, Francois (SC100:3055); SIPCORE; Hadriel Kaplan > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >=20 >=20 >=20 > Hans Erik van Elburg wrote: > > I'd like to understand what is wrong with the RFC3261=20 > definition of AOR?=20 >=20 > OK, rather than continuing to trust my memory I went back and=20 > reviewed the definition of AOR and Location Service in 3261,=20 > as well as the discussion around the use of the latter. >=20 > I conclude that the existing definition of AOR is at least=20 > close, and that most of the cases I listed before fit within it. >=20 > In particular, it seems that any translation of the incoming=20 > R-URI into a new value for the target set, except values=20 > received via 3xx responses, can be construed as coming from=20 > the use of a location service. This includes db lookups (such=20 > as ENUM) and algorithmic transformations. >=20 > I see a couple of cases that that aren't covered by the=20 > above that IMO ought to be considered AORs: > - If I become the owner of domain kyzivat.com, have it point to > a server of mine, and establish a UA on that server that=20 > responds to > sip:paul@kyzivat.com, then IMO sip:paul@kyzivat.com ought to be > considered an AOR even though there is no location service and no > domain proxy involved in accessing it. >=20 > This wouldn't be important to the H-I discussion very often. But > it might be if a request reached it, and it then chose to return a > 3xx response. In that case I would think it should mark its own H-I > entry as an AOR. I would actually consider that to be a location service. It's kind of trivial obviously, it sends it kyzivat@localhost, but it's still there. And it does route it to paul instead of peter or mary. > - TEL URIs are currently never AORs because the def of AOR says they > must be sip or sips URIs. But I think it makes a lot of sense to > consider TEL URIs to be AORs. I do however realize this may be > controversial. Yes, agree. Definition in 3261 explicitly covers only SIP and SIPS. I think we all know there are lots of unanswered questions about=20 usage of Tel URIs in SIP. Not sure what we can do about it for now. We specifically avoided getting into this rat-hole in the draft. > Aside from discussing if something should be tweaked to=20 > address these two cases I guess I am ok with the 3261 definition. Excellent! From AUDET@nortel.com Thu Jul 16 09:19:53 2009 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 9DD883A67AC for ; Thu, 16 Jul 2009 09:19:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.47 X-Spam-Level: X-Spam-Status: No, score=-6.47 tagged_above=-999 required=5 tests=[AWL=0.129, 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 44nQziSv5Pru for ; Thu, 16 Jul 2009 09:19:52 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 9A4F03A6891 for ; Thu, 16 Jul 2009 09:19:52 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6GGI5w02058; Thu, 16 Jul 2009 16:18:05 GMT 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, 16 Jul 2009 11:18:02 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F0503B7@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoFo9w3rc9bbN34Th6DpXoY4c7pmwAWlkPQAAyKiTA= References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com><4A5E5D5F.80908@cisco.com><1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> From: "Francois Audet" To: "DRAGE, Keith (Keith)" , "Paul Kyzivat" Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 16 Jul 2009 16:19:53 -0000 I'll do the following changes: o AOR indicator: The AOR indicator is to mark an URI entry as being recognized as an Address Of Record by the domain of the entry. and o AOR indicator (hi-aor): An optional parameter for the History-Info indicating that the hi-targeted-to-uri is recognized as an Address = Of=20 Record (as defined in section 6/[RFC3261]) by the domain of the=20 entry. [...] I therefore don't think we need to change the name. > -----Original Message----- > From: DRAGE, Keith (Keith) [mailto:drage@alcatel-lucent.com]=20 > Sent: Thursday, July 16, 2009 04:11 > To: Paul Kyzivat; Audet, Francois (SC100:3055) > Cc: SIPCORE; Hadriel Kaplan > Subject: RE: [sipcore] rfc4244bis: what is an AoR? >=20 > Agree with Paul. >=20 > In terms of process, I understand the current definition of=20 > the tag is based on the RFC 3261 defn of AOR. How do we need=20 > to change that definition to represent what people now=20 > understand. (current text follows) >=20 > o AOR indicator: The AOR indicator is to mark an URI=20 > entry as being > an Address Of Record. >=20 > and >=20 > o AOR indicator (hi-aor): An optional parameter for the=20 > History-Info > indicating that the hi-targeted-to-uri is an Address Of=20 > Record (as > defined in section 6/[RFC3261]) . The hi-aor parameter is added > by a proxy or redirect server to a hi-entry when it=20 > recognizes the > URI in the last entry as a URI in its abstract location service > (and then it can be routed accordingly). Therefore, the hi-aor > parameter (i.e., "aor") is not added for a hi-entry when it is > first added in a History-Info header field, but rather is added > when the retargeting actually occurs - i.e., the parameter > indicates that the specific hi-targeted-to-uri that was=20 > retargeted > was an AOR and thus the previous information in the request-URI > may be "lost". Upon receipt of a request or response containing > the History-Info header, a UA can determine a "lost" target AOR > for a request by traversing the HI entries in reverse order to > find the first one tagged with a specific hi-aor parameter. >=20 > Then we can think of a name. From ian.elz@ericsson.com Thu Jul 16 09:35:50 2009 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 1E3313A6930 for ; Thu, 16 Jul 2009 09:35:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.135 X-Spam-Level: X-Spam-Status: No, score=-3.135 tagged_above=-999 required=5 tests=[AWL=-2.686, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_34=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_65=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 TmrXRrGpEABy for ; Thu, 16 Jul 2009 09:35:48 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 0A6373A68C8 for ; Thu, 16 Jul 2009 09:35:47 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-bc-4a5f52ef0298 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id C9.6B.18827.FE25F5A4; Thu, 16 Jul 2009 18:18:56 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.1830); Thu, 16 Jul 2009 18:18:55 +0200 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: Thu, 16 Jul 2009 18:18:54 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F050359@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Privacy "none" (was RE: [sipcore] rfc4244bis Thread-Index: AcoGHM5Rm2IAvDFbQ1Wky+vmMBibLwABgGWAAANAbyA= References: <1ECE0EB50388174790F9694F77522CCF1EFE0971@zrc2hxm0.corp.nortel.com> <006701ca05b7$7cca7ec0$271d550a@china.huawei.com> <1ECE0EB50388174790F9694F77522CCF1F050359@zrc2hxm0.corp.nortel.com> From: "Ian Elz" To: "Mary Barnes" , "fanyanping" X-OriginalArrivalTime: 16 Jul 2009 16:18:55.0813 (UTC) FILETIME=[1DE40F50:01CA0631] X-Brightmail-Tracker: AAAAAA== Cc: sipcore@ietf.org Subject: Re: [sipcore] Privacy "none" (was RE: 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, 16 Jul 2009 16:35:50 -0000 Mary, The problem that we have is that the 3rd party cannot explicitly specify the privacy setting for his uri contained in the H-I entry. Under the present interpretation inserting a value of 'none' in the H-I entry would not have any effect. In future discussions about 3rd party privacy the current interpretation may be changed to a point where a value of 'none' in the H-I entry may be able to explicitly identify the Privacy of the 3rd party header in the H-I irrespective of what is included in the Privacy header. I will admit that if 4244bis specifically states that 'none' may be included in the H-I entry this may lead to confusion. As long as the possibility to include the value 'none' in the escapes header parameter of the hi-targeted-to-uri is not excluded then it may be better to deal with this case when discussions relating to 3rd party privacy are held. Do you think that a separate discussion on third party privacy is something that should be undertaken in sipcore and what is the best way to start this discussion, a draft or just a discussion paper? Regards Ian -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com]=20 Sent: 16 July 2009 17:09 To: Ian Elz; fanyanping Cc: sipcore@ietf.org Subject: Privacy "none" (was RE: [sipcore] rfc4244bis Ian, Thanks for the response. Just one question below [MB]. Mary. -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com] Sent: Thursday, July 16, 2009 8:54 AM To: fanyanping; Barnes, Mary (RICH2:AR00) Cc: sipcore@ietf.org Subject: RE: [sipcore] rfc4244bis Nancy, Mary, We have discussed this issue previously. The key issues are outside the scope of the 4244bis draft and needs to be discussed separately. The issue with RFC3323 is that this RFC only discusses privacy from an originating and terminating user perspective. Separate discussions are required on how privacy for 3rd party identities included in a sip messages is handled. The current interpretation that you cannot override what is included in the Privacy header results in two specific issues: - originating user includes a Privacy value of user/header/id which means that the 3rd party identity has the same privacy. If the 3rd party identity should be allowed then this may impact services which use the third party identity. The example which has been quoted is the Freephone call where the Freephone number is used for call handling. This is inconvenient for services which need to use this information. - originating user explicitly specifies "Privacy: none" in the originating request. This means that the 3rd party identity cannot be protected. This has much more serious impact as it makes SIP as defined 'not fit for purpose' in most regulated telephony environments. This is due to regulatory requirements to allow the privacy for each user to be specified and handled correctly. This however is outside the scope of the H-I changes but I would suggest that the new draft specifically allows the inclusion of the 'none' value in the escaped Privacy header in the hi-targeted-to-uri. [MB] Are you suggesting that we allow this "none" even in the case where there is for example, a privacy header "history" at the request level? I'm not so comfortable with that as it overrides what the UAC might have included in the original request. If that's not what your suggesting, what would adding "none" to an entry give you anyways? An entity cannot arbitrarily add "none" to entries added by another entity nor can it override policy. [/MB] Ian -----Original Message----- From: fanyanping [mailto:fanyanping@huawei.com] Sent: 16 July 2009 02:48 To: 'Mary Barnes' Cc: sipcore@ietf.org Subject: Re: [sipcore] rfc4244bis Hi mary, my response are inline below [nancy] , thanks:) > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Wednesday, July 15, 2009 10:46 PM > To: fanyanping > Subject: RE: [sipcore] rfc4244bis >=20 > Hi Nancy, >=20 > My responses are inline below [MB]. Note, it does not look like your=20 > original message went to the mailing list. Feel free to respond to the > mailing list. >=20 > Regards, > Mary.=20 >=20 > -----Original Message----- > From: fanyanping [mailto:fanyanping@huawei.com] > Sent: Wednesday, July 15, 2009 5:24 AM > To: sipcore-bounces@ietf.org > Cc: Barnes, Mary (RICH2:AR00) > Subject: Re: [sipcore] rfc4244bis >=20 >=20 > Hi mary, >=20 > I have read the draft of draft-barnes-sipcore-rfc4244bis-02.txt, there > are some issues i don't understand clearly, as blow: > 1, section 4.1 mentions > UAC that wants to ensure that privacy not be applied to its identity=20 > MUST include a Privacy header with a priv- value of "none." >=20 > but section 6.3.1(Privacy in the History-Info Header) doesn't has=20 > relevant description, can a proxy include a Privacy header with a > priv- value of "none" to a specifical hi-entry?? how to handle the=20 > "none" in different cases? >=20 > [MB] We have not precluded the use of "none". We did have a long=20 > debate that the "none" in the hi-entry cannot override a privacy=20 > header at the request level. And, section 4.1 is discussing privacy=20 > at the request level. So, I'm not sure what additional functionality=20 > you might get if you added "none" to a specific hi-entry - in a sense=20 > that's the default IF there is no privacy header at the request=20 > level.[/MB] [nancy] I get it , thanks, review RFC3323, i find i make a mistake,:) >=20 > 2,section 6.1 mentions > The hi-target is added for a hi-entry when it is first added in a=20 > History-Info header field >=20 > but in the previous draft, the hi-target is not added for a hi-entry=20 > when it is first added in a History-Info header field, it is added to > the last hi-entry received in the request >=20 > compare the two methods, what is the advantage of the first one? i see > that rosenberg's target-uri-delivery draft adopts the second one >=20 > [MB] You are correct - we have changed the solution approach.=20 > The reason > we've done so is that we want to capture the mechanism by which the=20 > new target was determined. At that point in time, as well, we can=20 > determine whether the previous target (i.e., the one in the incoming > Request) was > an "aor". So, we now tag the previous entry with the "aor" tag if=20 > appropriate. The first method does add some complexity for the 3xx=20 > handling, which is why you see a lot more text for that in the new=20 > version. The second approach was trying to be consistent with how the=20 > entries are tagged with the "Reason" header. But, we decided that by=20 > tagging the new hi-entry we are actually capturing more (accurate)=20 > information. We have tried to be precise in the text, so if you can=20 > point out any text that makes this unclear, that would be very=20 > helpful. > [/MB] =20 [nancy] previously, the reason header and hi-target parameter in the hi-entry are matched, but now i need to find the next hi-entry's hi-target parameter when see a reason header,it makes me a a bit confused. :) >=20 > ps: > can somebody give me an answer about the following questions?=20 > I don't > find > the exact description in RFC 3261, thanks in advance!!! =20 >=20 > 1, how does the proxy handle the request which the request-URI=20 > includes a maddr parameter in different cases? > [MB] This is described in section 16.5 of RFC 3261: > "If the Request-URI of the request contains an maddr parameter, the > Request-URI MUST be placed into the target set as the only target > URI, and the proxy MUST proceed to Section 16.6." >=20 > So, the only thing the proxy can do is to use the maddr parameter -=20 > i.e., it's the new target. This hi-entry would be tagged as "rt". > And, in this case the previous entry is NOT tagged as an "aor".[/MB] [nancy] you mean the request-URI should be replaced with the address in the maddr parameter?? or delete the maddr in the reqest-URI and add it to the route header?? >=20 >=20 > 2, If the domain of request-URI indicates is not that the proxy be=20 > responsible for,what actions should the proxy be taken? > [MB] Again per section 16.5: > "If the domain of the Request-URI indicates a domain this element=20 > is > not responsible for, the Request-URI MUST be placed into the target > set as the only target, and the element MUST proceed to the task of > Request Forwarding (Section 16.6)." >=20 > So, the only thing the proxy can do is to forward the request to the=20 > next hop proxy. This entry would be tagged as "rt". And, in this=20 > case the previous entry is NOT tagged as an "aor". [/MB] [nancy] you mean don't change the request-URI ,and add the address of next hop proxy to the route header,right? =20 >=20 > IMHO, the two cases are not retarget > [MB] In the document the term "retarget" is used in the most general=20 > sense (as it was in RFC 4244) to cover all of these cases - i.e.,=20 > forwardings (ala "rt") as well as the other cases - basically=20 > encompassing the process described in section 16.5 of RFC 3261. The=20 > primary purpose that term really serves is to make the document far=20 > less wordy and easier to read.[/MB] >=20 [nancy] I see the definition of 'retarget' in your draft as below: The term "retarget" is used in this document to refer both to the process of a Proxy Server/User Agent Client (UAC) changing a Uniform Resource Identifier (URI) in a request based on the rules for determining request targets as described in Section 16.5 of [RFC3261] and the subsequent forwarding of that request as described in section 16.6 of [RFC3261]. what 's the mean of "subsequent forwarding"?? i see that it needs to change the reqeust-URI first, right?? in this way, the ordinary forwarding can not be included in "retarget",such as the second question i describe as before. >=20 > Best Regards. >=20 > =20 > nancy >=20 > ******************************************************************* > This email and its attachments contain confidential information from=20 > HUAWEI, which is intended only for the person or entity whose address=20 > is listed above. > Any use of the information contained herein in any way (including, but > not limited to, total or partial disclosure, reproduction, or > dissemination) by persons > other than the intended recipient(s) is prohibited. If you receive=20 > this e-mail in error, please notify the sender by phone or email=20 > immediately and delete it! > ******************************************************************* >=20 From mary.barnes@nortel.com Thu Jul 16 09:37:51 2009 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 A7AD53A6891 for ; Thu, 16 Jul 2009 09:37:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.448 X-Spam-Level: X-Spam-Status: No, score=-5.448 tagged_above=-999 required=5 tests=[AWL=-0.649, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_65=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 aTgPA5EIi3v7 for ; Thu, 16 Jul 2009 09:37:50 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 2D9673A6D66 for ; Thu, 16 Jul 2009 09:37:50 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6GGVcD12500; Thu, 16 Jul 2009 16:31:38 GMT 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: Thu, 16 Jul 2009 11:35:38 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F05040D@zrc2hxm0.corp.nortel.com> In-Reply-To: <006701ca05b7$7cca7ec0$271d550a@china.huawei.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis thread-index: AcoFNlntOLq1SWlmTaKZc0Shyx0KmwAIHCywABYVBLAAIIP/UA== References: <1ECE0EB50388174790F9694F77522CCF1EFE0971@zrc2hxm0.corp.nortel.com> <006701ca05b7$7cca7ec0$271d550a@china.huawei.com> From: "Mary Barnes" To: "fanyanping" Cc: sipcore@ietf.org Subject: Re: [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, 16 Jul 2009 16:37:51 -0000 Hi Nancy, I'll skip the first point, since Ian responded to that and I to that response. Additional comments below [MB2], noting that all the sections I reference below are from RFC 3261. I will note that you really can't read 4244bis in isolation - it's described carefully within the context of section 16.5 (Determining Request Targets) and section 16.6 (Request forwarding).=20 Mary.=20 -----Original Message----- From: fanyanping [mailto:fanyanping@huawei.com]=20 Sent: Wednesday, July 15, 2009 8:48 PM To: Barnes, Mary (RICH2:AR00) Cc: sipcore@ietf.org Subject: RE: [sipcore] rfc4244bis Hi mary, my response are inline below [nancy] , thanks:) > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Wednesday, July 15, 2009 10:46 PM > To: fanyanping > Subject: RE: [sipcore] rfc4244bis >=20 > Hi Nancy, >=20 > My responses are inline below [MB]. Note, it does not look like your=20 > original message went to the mailing list. Feel free to respond to the > mailing list. >=20 > Regards, > Mary.=20 >=20 > -----Original Message----- > From: fanyanping [mailto:fanyanping@huawei.com] > Sent: Wednesday, July 15, 2009 5:24 AM > To: sipcore-bounces@ietf.org > Cc: Barnes, Mary (RICH2:AR00) > Subject: Re: [sipcore] rfc4244bis >=20 >=20 > Hi mary, >=20 > I have read the draft of draft-barnes-sipcore-rfc4244bis-02.txt, there > are some issues i don't understand clearly, as blow: > 1, section 4.1 mentions > UAC that wants to ensure that privacy not be applied to its identity=20 > MUST include a Privacy header with a priv- value of "none." >=20 > but section 6.3.1(Privacy in the History-Info Header) doesn't has=20 > relevant description, can a proxy include a Privacy header with a=20 > priv- value of "none" to a specifical hi-entry?? how to handle the=20 > "none" in different cases? >=20 > [MB] We have not precluded the use of "none". We did have a long=20 > debate that the "none" in the hi-entry cannot override a privacy=20 > header at the request level. And, section 4.1 is discussing privacy=20 > at the request level. So, I'm not sure what additional functionality=20 > you might get if you added "none" to a specific hi-entry - in a sense=20 > that's the default IF there is no privacy header at the request=20 > level.[/MB] [nancy] I get it , thanks, review RFC3323, i find i make a mistake,:) >=20 > 2,section 6.1 mentions > The hi-target is added for a hi-entry when it is first added in a=20 > History-Info header field >=20 > but in the previous draft, the hi-target is not added for a hi-entry=20 > when it is first added in a History-Info header field, it is added to > the last hi-entry received in the request >=20 > compare the two methods, what is the advantage of the first one? i see > that rosenberg's target-uri-delivery draft adopts the second one >=20 > [MB] You are correct - we have changed the solution approach.=20 > The reason > we've done so is that we want to capture the mechanism by which the=20 > new target was determined. At that point in time, as well, we can=20 > determine whether the previous target (i.e., the one in the incoming > Request) was > an "aor". So, we now tag the previous entry with the "aor" tag if=20 > appropriate. The first method does add some complexity for the 3xx=20 > handling, which is why you see a lot more text for that in the new=20 > version. The second approach was trying to be consistent with how the=20 > entries are tagged with the "Reason" header. But, we decided that by=20 > tagging the new hi-entry we are actually capturing more (accurate)=20 > information. We have tried to be precise in the text, so if you can=20 > point out any text that makes this unclear, that would be very=20 > helpful. > [/MB] =20 [nancy] previously, the reason header and hi-target parameter in the hi-entry are matched, but now i need to find the next hi-entry's hi-target parameter when see a reason header,it makes me a a bit confused. :) [MB2] No. You would use the hi-target parameter associated with the entry that has the reason header (in the current version). The hi-target parameter tells you the mechanism by which that hi-targeted-to-uri was determined - we have to capture it when we capture the request-URI or we lose that information. The Reason still tells you why that hi-targeted-to-uri was later retargeted. So, when you first add the hi-entry, the only optional field you would have with 4244bis is the hi-target. When the Request-uri as reflected by the hi-targeted-to-uri is "retargeted", then the Reason and "aor" parameters may be added (if appropriate conditions are met). In general, the UAS/application wouldn't usually care about the last hi-entry, which would only have the hi-target (if the last entity supports 4244bis). But, we don't know that this is the last entry when we add the hi-target parameter.=20 [/MB2] >=20 > ps: > can somebody give me an answer about the following questions?=20 > I don't > find > the exact description in RFC 3261, thanks in advance!!! =20 >=20 > 1, how does the proxy handle the request which the request-URI=20 > includes a maddr parameter in different cases? > [MB] This is described in section 16.5 of RFC 3261: > "If the Request-URI of the request contains an maddr parameter, the > Request-URI MUST be placed into the target set as the only target > URI, and the proxy MUST proceed to Section 16.6." >=20 > So, the only thing the proxy can do is to use the maddr parameter -=20 > i.e., it's the new target. This hi-entry would be tagged as "rt".=20 > And, in this case the previous entry is NOT tagged as an "aor".[/MB] [nancy] you mean the request-URI should be replaced with the address in the maddr parameter?? or delete the maddr in the reqest-URI and add it to the route header?? [MB2] In section 16.5 the proxy is building the target list. The use of the target list to build the outgoing request is described in section 16.6. So, with the maddr, that is the only parameter in the target list, thus when the outgoing request is built the maddr parameter will be the Request-URI in the outgoing request. The processing for the route header is described separately in section 16.4. [/MB2] >=20 >=20 > 2, If the domain of request-URI indicates is not that the proxy be=20 > responsible for,what actions should the proxy be taken? > [MB] Again per section 16.5: > "If the domain of the Request-URI indicates a domain this element=20 > is > not responsible for, the Request-URI MUST be placed into the target > set as the only target, and the element MUST proceed to the task of > Request Forwarding (Section 16.6)." >=20 > So, the only thing the proxy can do is to forward the request to the=20 > next hop proxy. This entry would be tagged as "rt". And, in this=20 > case the previous entry is NOT tagged as an "aor". [/MB] [nancy] you mean don't change the request-URI ,and add the address of next hop proxy to the route header,right? =20 [MB2] Correct. Per my note above the processing for the route header is described in section 16.4. and it's added to the request in step 4 of section 16.6 That's entirely independent of the determination of the target list in section 16.5 and is transparent to the processing for the History-Info header. [/MB2] >=20 > IMHO, the two cases are not retarget > [MB] In the document the term "retarget" is used in the most general=20 > sense (as it was in RFC 4244) to cover all of these cases - i.e.,=20 > forwardings (ala "rt") as well as the other cases - basically=20 > encompassing the process described in section 16.5 of RFC 3261. The=20 > primary purpose that term really serves is to make the document far=20 > less wordy and easier to read.[/MB] >=20 [nancy] I see the definition of 'retarget' in your draft as below: The term "retarget" is used in this document to refer both to the process of a Proxy Server/User Agent Client (UAC) changing a Uniform Resource Identifier (URI) in a request based on the rules for determining request targets as described in Section 16.5 of [RFC3261] and the subsequent forwarding of that request as described in section 16.6 of [RFC3261]. what 's the mean of "subsequent forwarding"?? i see that it needs to change the reqeust-URI first, right?? in this way, the ordinary forwarding can not be included in "retarget",such as the second question i describe as before. [MB2] the term "subsequent forwarding" is specifically referencing the processing in section 16.6 (Request Forwarding). The request URI for the outgoing request is determined as described in section 16.6 using the target list built in section 16.5 [/MB2] >=20 > Best Regards. >=20 > =20 > nancy >=20 > ******************************************************************* > This email and its attachments contain confidential information from=20 > HUAWEI, which is intended only for the person or entity whose address=20 > is listed above. > Any use of the information contained herein in any way (including, but > not limited to, total or partial disclosure, reproduction, or > dissemination) by persons > other than the intended recipient(s) is prohibited. If you receive=20 > this e-mail in error, please notify the sender by phone or email=20 > immediately and delete it! > ******************************************************************* >=20 From mary.barnes@nortel.com Thu Jul 16 10:18:12 2009 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 4EF1428C1B2 for ; Thu, 16 Jul 2009 10:18:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.442 X-Spam-Level: X-Spam-Status: No, score=-5.442 tagged_above=-999 required=5 tests=[AWL=-0.643, BAYES_00=-2.599, J_CHICKENPOX_34=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_65=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 v3+jL6K03LFE for ; Thu, 16 Jul 2009 10:18:11 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id EC6153A6DAA for ; Thu, 16 Jul 2009 10:18:09 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6GHGwD19155; Thu, 16 Jul 2009 17:16:58 GMT 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: Thu, 16 Jul 2009 12:21:00 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F050519@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Privacy "none" (was RE: [sipcore] rfc4244bis thread-index: AcoGHM5Rm2IAvDFbQ1Wky+vmMBibLwABgGWAAANAbyAAAYKzgA== References: <1ECE0EB50388174790F9694F77522CCF1EFE0971@zrc2hxm0.corp.nortel.com> <006701ca05b7$7cca7ec0$271d550a@china.huawei.com> <1ECE0EB50388174790F9694F77522CCF1F050359@zrc2hxm0.corp.nortel.com> From: "Mary Barnes" To: "Ian Elz" , "fanyanping" Cc: sipcore@ietf.org, sipcore-chairs@tools.ietf.org Subject: Re: [sipcore] Privacy "none" (was RE: 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, 16 Jul 2009 17:18:12 -0000 Hi Ian, I think a paper/draft on this issue would be very useful for fleshing out this problem. It is somewhat beyond the strict charter of SIPCORE at this point, so I'd defer to the chairs as to whether we should take the discussion directly to SIPCORE or DISPATCH. The latter of course is fine with me and may well help us to first determine the scope of the potential work. Thanks, Mary. -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com]=20 Sent: Thursday, July 16, 2009 11:19 AM To: Barnes, Mary (RICH2:AR00); fanyanping Cc: sipcore@ietf.org Subject: RE: Privacy "none" (was RE: [sipcore] rfc4244bis Mary, The problem that we have is that the 3rd party cannot explicitly specify the privacy setting for his uri contained in the H-I entry. Under the present interpretation inserting a value of 'none' in the H-I entry would not have any effect. In future discussions about 3rd party privacy the current interpretation may be changed to a point where a value of 'none' in the H-I entry may be able to explicitly identify the Privacy of the 3rd party header in the H-I irrespective of what is included in the Privacy header. I will admit that if 4244bis specifically states that 'none' may be included in the H-I entry this may lead to confusion. As long as the possibility to include the value 'none' in the escapes header parameter of the hi-targeted-to-uri is not excluded then it may be better to deal with this case when discussions relating to 3rd party privacy are held. Do you think that a separate discussion on third party privacy is something that should be undertaken in sipcore and what is the best way to start this discussion, a draft or just a discussion paper? Regards Ian -----Original Message----- From: Mary Barnes [mailto:mary.barnes@nortel.com] Sent: 16 July 2009 17:09 To: Ian Elz; fanyanping Cc: sipcore@ietf.org Subject: Privacy "none" (was RE: [sipcore] rfc4244bis Ian, Thanks for the response. Just one question below [MB]. Mary. -----Original Message----- From: Ian Elz [mailto:ian.elz@ericsson.com] Sent: Thursday, July 16, 2009 8:54 AM To: fanyanping; Barnes, Mary (RICH2:AR00) Cc: sipcore@ietf.org Subject: RE: [sipcore] rfc4244bis Nancy, Mary, We have discussed this issue previously. The key issues are outside the scope of the 4244bis draft and needs to be discussed separately. The issue with RFC3323 is that this RFC only discusses privacy from an originating and terminating user perspective. Separate discussions are required on how privacy for 3rd party identities included in a sip messages is handled. The current interpretation that you cannot override what is included in the Privacy header results in two specific issues: - originating user includes a Privacy value of user/header/id which means that the 3rd party identity has the same privacy. If the 3rd party identity should be allowed then this may impact services which use the third party identity. The example which has been quoted is the Freephone call where the Freephone number is used for call handling. This is inconvenient for services which need to use this information. - originating user explicitly specifies "Privacy: none" in the originating request. This means that the 3rd party identity cannot be protected. This has much more serious impact as it makes SIP as defined 'not fit for purpose' in most regulated telephony environments. This is due to regulatory requirements to allow the privacy for each user to be specified and handled correctly. This however is outside the scope of the H-I changes but I would suggest that the new draft specifically allows the inclusion of the 'none' value in the escaped Privacy header in the hi-targeted-to-uri. [MB] Are you suggesting that we allow this "none" even in the case where there is for example, a privacy header "history" at the request level? I'm not so comfortable with that as it overrides what the UAC might have included in the original request. If that's not what your suggesting, what would adding "none" to an entry give you anyways? An entity cannot arbitrarily add "none" to entries added by another entity nor can it override policy. [/MB] Ian -----Original Message----- From: fanyanping [mailto:fanyanping@huawei.com] Sent: 16 July 2009 02:48 To: 'Mary Barnes' Cc: sipcore@ietf.org Subject: Re: [sipcore] rfc4244bis Hi mary, my response are inline below [nancy] , thanks:) > -----Original Message----- > From: Mary Barnes [mailto:mary.barnes@nortel.com] > Sent: Wednesday, July 15, 2009 10:46 PM > To: fanyanping > Subject: RE: [sipcore] rfc4244bis >=20 > Hi Nancy, >=20 > My responses are inline below [MB]. Note, it does not look like your=20 > original message went to the mailing list. Feel free to respond to the > mailing list. >=20 > Regards, > Mary.=20 >=20 > -----Original Message----- > From: fanyanping [mailto:fanyanping@huawei.com] > Sent: Wednesday, July 15, 2009 5:24 AM > To: sipcore-bounces@ietf.org > Cc: Barnes, Mary (RICH2:AR00) > Subject: Re: [sipcore] rfc4244bis >=20 >=20 > Hi mary, >=20 > I have read the draft of draft-barnes-sipcore-rfc4244bis-02.txt, there > are some issues i don't understand clearly, as blow: > 1, section 4.1 mentions > UAC that wants to ensure that privacy not be applied to its identity=20 > MUST include a Privacy header with a priv- value of "none." >=20 > but section 6.3.1(Privacy in the History-Info Header) doesn't has=20 > relevant description, can a proxy include a Privacy header with a > priv- value of "none" to a specifical hi-entry?? how to handle the=20 > "none" in different cases? >=20 > [MB] We have not precluded the use of "none". We did have a long=20 > debate that the "none" in the hi-entry cannot override a privacy=20 > header at the request level. And, section 4.1 is discussing privacy=20 > at the request level. So, I'm not sure what additional functionality=20 > you might get if you added "none" to a specific hi-entry - in a sense=20 > that's the default IF there is no privacy header at the request=20 > level.[/MB] [nancy] I get it , thanks, review RFC3323, i find i make a mistake,:) >=20 > 2,section 6.1 mentions > The hi-target is added for a hi-entry when it is first added in a=20 > History-Info header field >=20 > but in the previous draft, the hi-target is not added for a hi-entry=20 > when it is first added in a History-Info header field, it is added to > the last hi-entry received in the request >=20 > compare the two methods, what is the advantage of the first one? i see > that rosenberg's target-uri-delivery draft adopts the second one >=20 > [MB] You are correct - we have changed the solution approach.=20 > The reason > we've done so is that we want to capture the mechanism by which the=20 > new target was determined. At that point in time, as well, we can=20 > determine whether the previous target (i.e., the one in the incoming > Request) was > an "aor". So, we now tag the previous entry with the "aor" tag if=20 > appropriate. The first method does add some complexity for the 3xx=20 > handling, which is why you see a lot more text for that in the new=20 > version. The second approach was trying to be consistent with how the=20 > entries are tagged with the "Reason" header. But, we decided that by=20 > tagging the new hi-entry we are actually capturing more (accurate)=20 > information. We have tried to be precise in the text, so if you can=20 > point out any text that makes this unclear, that would be very=20 > helpful. > [/MB] =20 [nancy] previously, the reason header and hi-target parameter in the hi-entry are matched, but now i need to find the next hi-entry's hi-target parameter when see a reason header,it makes me a a bit confused. :) >=20 > ps: > can somebody give me an answer about the following questions?=20 > I don't > find > the exact description in RFC 3261, thanks in advance!!! =20 >=20 > 1, how does the proxy handle the request which the request-URI=20 > includes a maddr parameter in different cases? > [MB] This is described in section 16.5 of RFC 3261: > "If the Request-URI of the request contains an maddr parameter, the > Request-URI MUST be placed into the target set as the only target > URI, and the proxy MUST proceed to Section 16.6." >=20 > So, the only thing the proxy can do is to use the maddr parameter -=20 > i.e., it's the new target. This hi-entry would be tagged as "rt". > And, in this case the previous entry is NOT tagged as an "aor".[/MB] [nancy] you mean the request-URI should be replaced with the address in the maddr parameter?? or delete the maddr in the reqest-URI and add it to the route header?? >=20 >=20 > 2, If the domain of request-URI indicates is not that the proxy be=20 > responsible for,what actions should the proxy be taken? > [MB] Again per section 16.5: > "If the domain of the Request-URI indicates a domain this element=20 > is > not responsible for, the Request-URI MUST be placed into the target > set as the only target, and the element MUST proceed to the task of > Request Forwarding (Section 16.6)." >=20 > So, the only thing the proxy can do is to forward the request to the=20 > next hop proxy. This entry would be tagged as "rt". And, in this=20 > case the previous entry is NOT tagged as an "aor". [/MB] [nancy] you mean don't change the request-URI ,and add the address of next hop proxy to the route header,right? =20 >=20 > IMHO, the two cases are not retarget > [MB] In the document the term "retarget" is used in the most general=20 > sense (as it was in RFC 4244) to cover all of these cases - i.e.,=20 > forwardings (ala "rt") as well as the other cases - basically=20 > encompassing the process described in section 16.5 of RFC 3261. The=20 > primary purpose that term really serves is to make the document far=20 > less wordy and easier to read.[/MB] >=20 [nancy] I see the definition of 'retarget' in your draft as below: The term "retarget" is used in this document to refer both to the process of a Proxy Server/User Agent Client (UAC) changing a Uniform Resource Identifier (URI) in a request based on the rules for determining request targets as described in Section 16.5 of [RFC3261] and the subsequent forwarding of that request as described in section 16.6 of [RFC3261]. what 's the mean of "subsequent forwarding"?? i see that it needs to change the reqeust-URI first, right?? in this way, the ordinary forwarding can not be included in "retarget",such as the second question i describe as before. >=20 > Best Regards. >=20 > =20 > nancy >=20 > ******************************************************************* > This email and its attachments contain confidential information from=20 > HUAWEI, which is intended only for the person or entity whose address=20 > is listed above. > Any use of the information contained herein in any way (including, but > not limited to, total or partial disclosure, reproduction, or > dissemination) by persons > other than the intended recipient(s) is prohibited. If you receive=20 > this e-mail in error, please notify the sender by phone or email=20 > immediately and delete it! > ******************************************************************* >=20 From ietf.hanserik@gmail.com Thu Jul 16 13:19:40 2009 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 5439828C1F6 for ; Thu, 16 Jul 2009 13:19:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.512 X-Spam-Level: X-Spam-Status: No, score=-2.512 tagged_above=-999 required=5 tests=[AWL=0.086, 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 plhXNzi7EVnD for ; Thu, 16 Jul 2009 13:19:39 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.25]) by core3.amsl.com (Postfix) with ESMTP id BBA3928C0E1 for ; Thu, 16 Jul 2009 13:19:38 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so107214eye.31 for ; Thu, 16 Jul 2009 13:20:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=LMkQegq8WO4VOSYEWqbRrp5I7ySEngS6fzajlgkpoMo=; b=UOsB1pU74w6pe7wpqdkJa8QE8skxmBWUmxCtfe4wZrVGiviT8QPdcTWCE3Xuqvum22 b44UXOHnU3Pw9Jx9+OyBzDioN044HBBXlXkPg9Ffl7eY8pT3UHHA9JqzPUfaAa/Q9ElE T6V7rKMQwq1K8aiPbH8mR+UWAGwWOAwOCFdvQ= 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=eC7WDG6YVPYOPe/IVp69xLmwyrksaPJKAjc5kwlZBppTk400jrU66934rgqfIxs4gU 8si71Vkj55XLO+FHY0Df47uypj5+zWyM/cioKMo/zKq4vhDLqggCka2lxZtkGatC4xUq +DP3KhvFQJ7Q77Mqu7WspNZVXHcGe8moDZ8wA= MIME-Version: 1.0 Received: by 10.210.18.8 with SMTP id 8mr203287ebr.85.1247775609385; Thu, 16 Jul 2009 13:20:09 -0700 (PDT) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F0502D8@zrc2hxm0.corp.nortel.com> References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <9ae56b1e0907160001u54c095e8o3761f9294a36a456@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1F0502D8@zrc2hxm0.corp.nortel.com> Date: Thu, 16 Jul 2009 22:20:08 +0200 Message-ID: <9ae56b1e0907161320l6b8d911fy74d3da8214adefe8@mail.gmail.com> From: Hans Erik van Elburg To: Francois Audet Content-Type: multipart/alternative; boundary=0015174c43d8f4f5a2046ed865d1 Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 16 Jul 2009 20:19:40 -0000 --0015174c43d8f4f5a2046ed865d1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit yes /Hans Erik van Elburg On Thu, Jul 16, 2009 at 5:50 PM, Francois Audet wrote: > > > Example-1: ENUM is used widely, as both a means of performing "pure" >> E.164 number to AoR resolution, Number Portability, inter-domain routing, >> intra-domain routing, and even registered contact routing. An ENUM query >> can be described as a location-service lookup. Proxies performing an ENUM >> query don't necessarily know what type of URI they are performing that query >> for. So if they get a request for "sip:+1234567890@sp.com" >> and do the query and the result makes it change it for inter-domain routing, >> then the original URI was not a AoR; if the result made it send it to a >> UAS/gateway directly, then it was an AoR. Right? Since the proxy won't >> know when, it will have to tag it as AoR every time, no? > > > In IMS this would be completely clear to me as not being one qualifying for > an aor tag, as it is proxy that acts on behalf of the originating user that > would perform the ENUM dip to be able to know where to route the request. > First when it enters the proxy(-instance) that acts on behalf of a > terminating user the aor tagging would start. > > As for genuine SIP proxies this distinction does not seem to be specified > we are having this debate. > > I have this feeling that I'm missing a suttlety here because of my lack of > knowledge of IMS.... > > Say I call sip:+1234567890@sp.com ;user=phone. > My proxy is "sp.com", right? > > Then sp.net does ENUM query. Then it forwards the request to whatever the > result of the ENUM query was, say sip:+1234567890@example.com<+1234567890@example.com>;user=phone. > Correct? > > So the ;aor tag would be added by example.com. Is this what you are > saying? > > If so, I think I agree. > --0015174c43d8f4f5a2046ed865d1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable yes

/Hans Erik van Elburg


On Thu, Jul 16, 2009 at 5:50 PM, Francoi= s Audet <audet@nor= tel.com> wrote:
=A0

Example-1:=20 ENUM is used widely, as both a means of performing "pure" E.1= 64 number to=20 AoR resolution, Number Portability, inter-domain routing, intra-domain= =20 routing, and even registered contact routing. =A0An ENUM query can be= =20 described as a location-service lookup. =A0Proxies performing an ENUM= =20 query don't necessarily know what type of URI they are performing t= hat query=20 for. =A0So if they get a request for "sip:+1234567890@sp.com" and do= =20 the query and the result makes it change it for inter-domain routing, t= hen=20 the original URI was not a AoR; if the result made it send it to a=20 UAS/gateway directly, then it was an AoR. =A0Right? =A0Since the proxy= =20 won't know when, it will have to tag it as AoR every time, no?

In IMS this would be completely clear to me as not being one qualify= ing=20 for an aor tag, as it is proxy that acts on behalf of the originating use= r=20 that would perform the ENUM dip to be able to know where to route the req= uest.=20 First when it enters the proxy(-instance) that acts on behalf of a termin= ating=20 user the aor tagging would start.

As for genuine SIP proxies =A0this distinction does not seem to be= =20 specified we are having this debate.
I have= =20 this feeling that I'm missing a suttlety here because of my lack of kno= wledge of=20 IMS....
= =A0
Say I=20 call sip:+1234567890@sp.com;user= =3Dphone. My proxy is "sp.= com",=20 right?
= =A0
Then=A0sp.net does ENUM query. Then it fo= rwards the request to=20 whatever the result of the ENUM query was, say = sip:+1234567890@example.com;user=3Dphone.=20 Correct?
= =A0
So the=20 ;aor tag would be added by example.com. Is this what you are=20 saying?
= =A0
If so,=20 I think I agree.

--0015174c43d8f4f5a2046ed865d1-- From AUDET@nortel.com Thu Jul 16 13:38:32 2009 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 C8B2528C20A for ; Thu, 16 Jul 2009 13:38:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.476 X-Spam-Level: X-Spam-Status: No, score=-6.476 tagged_above=-999 required=5 tests=[AWL=0.123, 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 eJhFZPlh8AXj for ; Thu, 16 Jul 2009 13:38:32 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id BD7CF3A6DE2 for ; Thu, 16 Jul 2009 13:38:31 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6GKcww18825; Thu, 16 Jul 2009 20:38:58 GMT 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, 16 Jul 2009 15:38:10 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com> In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoF6CVRUPlMKkb7SrWHqBtgx6wCgwAAvgVQABgn/cA= References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com><4A5E5D5F.80908@cisco.com><1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com><4A5E6558.8000108@cisco.com><1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com><4A5E83CB.4090701@cisco.com><9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Elwell, John" , "Hans Erik van Elburg" , "Paul Kyzivat" Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 16 Jul 2009 20:38:32 -0000 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Elwell, John > Sent: Thursday, July 16, 2009 01:04 > To: Hans Erik van Elburg; Paul Kyzivat > Cc: SIPCORE; Hadriel Kaplan > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >=20 > From that definition, I believe every entry in H-I except the=20 > last (i.e., the Request-URI received by the UAS) would be an=20 > AOR. If not, the request would not have got this far, because=20 > it would not have found a domain that could route it. No, this is false: not all entries will be aors. For example, I call you, my request gets routed to elwell@10.10.15.12 = (your registered contact). You send a 302 to john@example.com, and it recurses = all the way to john@192.168.15.12 (another registered contact). In this case, you'll have an entry in the middle (elwell@10.10.15.12) = that is not=20 an AOR. > Is my understanding correct? If so, what is the point of the "AOR" > indicator in H-I, if all but the last are marked "AOR"? The point of AOR is marking useful entries differently than pointless ones. There are lots of other examples. You have to remember that in H-I, = normally all proxies are supposed to add entries even if they don't own the = domain, and even if they don't change anything. - I send a request to sip:elwell@siemens-enterprise.com from = sip:audet@nortel.com. My proxy adds the entry sip:elwell@siemens-enterprise.com, but it = doesn't mark it as AOR because it doesn't own it. It will only be marked as AOR by = YOUR proxy when it reaches it. - Strict-routing. None of the strict-routing proxy addresses would be = marked as AOR. - Manual digit manipulation done by outgoing proxies (i.e., = sip:60114901234567@nortel.com will not be marked as AOR). When it ultimately gets mapped to = sip:+4901234567@siemens- enterprise.com;user=3Dphone) by YOUR proxy (as per first bullet), then = it gets marked. The AOR marking allows to eliminate a lot of redundant (in best case) or = innacurate entries=20 and facilitate parsing of H-I by UAS. =20 From pkyzivat@cisco.com Thu Jul 16 15:52:39 2009 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 630143A69AB for ; Thu, 16 Jul 2009 15:52:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.515 X-Spam-Level: X-Spam-Status: No, score=-6.515 tagged_above=-999 required=5 tests=[AWL=0.084, 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 eSKENNVXHD34 for ; Thu, 16 Jul 2009 15:52:38 -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 DFCBE3A688C for ; Thu, 16 Jul 2009 15:52:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHBMX0pAZnmf/2dsb2JhbAC4WYgjkRQFhA0 X-IronPort-AV: E=Sophos;i="4.42,413,1243814400"; d="scan'208";a="50658416" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 16 Jul 2009 22:53:10 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6GMrAAh031911; Thu, 16 Jul 2009 18:53:10 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6GMrA5Y018208; Thu, 16 Jul 2009 22:53:10 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 18:53:10 -0400 Received: from [10.86.246.18] ([10.86.246.18]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 18:53:09 -0400 Message-ID: <4A5FAF4E.4030901@cisco.com> Date: Thu, 16 Jul 2009 18:53:02 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Francois Audet References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <9ae56b1e0907160001u54c095e8o3761f9294a36a456@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1F0502D8@zrc2hxm0.corp.nortel.com> In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F0502D8@zrc2hxm0.corp.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 16 Jul 2009 22:53:09.0800 (UTC) FILETIME=[30C40A80:01CA0668] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=3407; t=1247784790; x=1248648790; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20rfc4244bis=3A=20what=20is=2 0an=20AoR? |Sender:=20 |To:=20Francois=20Audet=20; bh=wIU75hVfUJ/PmCT1GcApNE1K3KBizX61e8nT/U+C1/o=; b=0b2ccKcm/lqWsgvOO2HopaSnTVv4YMohwN/vA0rZjPEssloES/Vtp0/qdk 3CIF86ITmP637zQHCCB/Tfd8YTDM41cr4eucsXYxQt4oATDqGQbwktJrbDrj b8Kui63ZV3; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 16 Jul 2009 22:52:39 -0000 I am not understanding. Inline Francois Audet wrote: > > > Example-1: ENUM is used widely, as both a means of performing > "pure" E.164 number to AoR resolution, Number Portability, > inter-domain routing, intra-domain routing, and even registered > contact routing. An ENUM query can be described as a > location-service lookup. Proxies performing an ENUM query don't > necessarily know what type of URI they are performing that query > for. So if they get a request for "sip:+1234567890@sp.com" > and do the query and the > result makes it change it for inter-domain routing, then the > original URI was not a AoR; if the result made it send it to a > UAS/gateway directly, then it was an AoR. Right? Since the > proxy won't know when, it will have to tag it as AoR every time, no? > > > In IMS this would be completely clear to me as not being one > qualifying for an aor tag, as it is proxy that acts on behalf of the > originating user that would perform the ENUM dip to be able to know > where to route the request. First when it enters the > proxy(-instance) that acts on behalf of a terminating user the aor > tagging would start. > > As for genuine SIP proxies this distinction does not seem to be > specified we are having this debate. > > I have this feeling that I'm missing a suttlety here because of my lack > of knowledge of IMS.... > > Say I call sip:+1234567890@sp.com;user=phone. My proxy is "sp.com", > right? > > Then sp.net does ENUM query. If we assume that ENUM qualifies as a location service (and I am now convinced that it does), then this URI *is* an AOR in sp.com. > Then it forwards the request to whatever > the result of the ENUM query was, say sip:+1234567890@example.com;user=phone. Correct? > > So the ;aor tag would be added by example.com. Is this what you are saying? That URI can also be an AOR. I agree that sip:+1234567890@sp.com;user=phone probably *should* not be an AOR if sp.com is not responsible for that phone number. But does that mean we should exclude ENUM from being considered a location service? Or must we dice things finer, and say that if translate with ENUM and the result happens to be in your own domain then it was an AOR, but if it wasn't in your own domain then it wasn't an AOR? This gets into the whole TEL URI thing. IMO a TEL URI ought to be considered an AOR, and *everybody* is allowed to make that determination, not just its "domain". (It has no domain.) But when you start putting tel uri syntax into sip URIs it gets ugly. I guess some say you are not allowed to form such a thing unless the domain *is* the owner of the phone number. But that is an unreasonable approach. IMO the user part is just another name in that domain, and is valid or not according to that domain. If it chooses to interpret as an E.164 number, and use ENUM to translate it, then that is its business. And superficially that makes it an AOR. Thanks, Paul > If so, I think I agree. > > > ------------------------------------------------------------------------ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From eburger@standardstrack.com Thu Jul 16 16:08:13 2009 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 454793A6DF9 for ; Thu, 16 Jul 2009 16:08:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.546 X-Spam-Level: X-Spam-Status: No, score=-2.546 tagged_above=-999 required=5 tests=[AWL=0.052, 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 i3Cwe0wp6oUd for ; Thu, 16 Jul 2009 16:08:12 -0700 (PDT) Received: from gs19.inmotionhosting.com (gs19.inmotionhosting.com [205.134.252.251]) by core3.amsl.com (Postfix) with ESMTP id 843BD3A6DEE for ; Thu, 16 Jul 2009 16:08:12 -0700 (PDT) Received: from neustargw.va.neustar.com ([209.173.53.233] helo=[10.31.32.168]) by gs19.inmotionhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1MRa46-0004K1-Gd for sipcore@ietf.org; Thu, 16 Jul 2009 16:08:38 -0700 Message-Id: <44F700B5-1F7F-4732-86A0-76D7E7083AE6@standardstrack.com> From: Eric Burger To: SIPCORE Content-Type: multipart/signed; boundary=Apple-Mail-27-1043066244; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Thu, 16 Jul 2009 19:08:41 -0400 X-Mailer: Apple Mail (2.935.3) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gs19.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - standardstrack.com X-Source: X-Source-Args: X-Source-Dir: Subject: [sipcore] INFO draft 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, 16 Jul 2009 23:08:13 -0000 --Apple-Mail-27-1043066244 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit The silence is deafening. Please +1 or -1, as the WGLC is underway. If you're too tired of the topic, just +1 to prove you read the email. http://www.ietf.org/internet-drafts/draft-ietf-sipcore-info-events-00.txt --Apple-Mail-27-1043066244 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGPTCCBjkw ggUhoAMCAQICEC+VK1RLWxrF8KJZDR9k8p8wDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBVU0VS VFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYwNAYDVQQD Ey1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWwwHhcNMDgwODEz MDAwMDAwWhcNMDkwODEzMjM1OTU5WjCB4TE1MDMGA1UECxMsQ29tb2RvIFRydXN0IE5ldHdvcmsg LSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFuZCBDb25kaXRpb25zIG9m IHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkxHzAdBgNVBAsTFihjKTIwMDMg Q29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0VyaWMgQnVyZ2VyMSkwJwYJKoZIhvcNAQkBFhplYnVy Z2VyQHN0YW5kYXJkc3RyYWNrLmNvbTCCASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBAMTF RRoA4LgOACMFph0aomRC/UpqoA5C/d6DUTOvTMrYSEqkjwnU4zxDtBcHlcB4AxKAov00MYsUvEU4 loz7BHjfDjv76AIkcwu33VYQbzGmarVnyaXsVb6f/cyRL3fPT0VOVO2tQAEEgwg//CX0jN8Kn2jH uXD/HEvko7cmpL3Pwevf3+DwB61v7ca79PpEZfn/WhaqRKA4uVNPj/JbieeaLo2v/0RJzrEElZK0 pHCqxiD3mQ8ossPkA9fUCSxLlbdMcPU3be5x8vt8Q8mYTXF5Z3d9RZmYrmNkvTQtdzVpfYWr/hgV Xqm9tByOOAR+hoN3FKbubR/OrAHL9yDAd4sCAwEAAaOCAhwwggIYMB8GA1UdIwQYMBaAFImCZ33E nSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRDWgutb7b8R/L7G3Y3D+molAA3VzAOBgNVHQ8BAf8E BAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYBBAGyMQEDBQIwEQYJ YIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEBMCswKQYIKwYBBQUHAgEW HWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8EgZ0wgZowTKBKoEiGRmh0dHA6 Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRF bWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2RvLm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVu dEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMGwGCCsGAQUFBwEBBGAwXjA2BggrBgEFBQcwAoYq aHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQUFBQ2xpZW50Q0EuY3J0MCQGCCsGAQUFBzABhhho dHRwOi8vb2NzcC5jb21vZG9jYS5jb20wJQYDVR0RBB4wHIEaZWJ1cmdlckBzdGFuZGFyZHN0cmFj ay5jb20wDQYJKoZIhvcNAQEFBQADggEBAGeBR7NPCvrY3GQoIi49JOuciatY2r4st905Jw1etp6J umFFWlaCBl11tFSclk/3S45B+lUv3SEvG4CEjUByPScprVmCqHR+y8BAQaB/CV+N1y14x3MbhJ+Z 8XDGKeUXuuyGd9w0l3/t/QPid6TRXQjQFrLPFs1IALuNpNiFMHEF/xFbMG1Z2vznR/gSPlePekoZ TqcExIDBNZTBebpZqwAXzPpedNNOclbMLFLWDMOAozVRpkfjI0eiFsk8SF1Ho1Gb9Bx8DeG4peE2 KRVOR9FFnZZgBpFjXYRcglsMOSKCY8HgE+NGvbbqbrMoBV/BlYyxRXwfti71RL9Zs2Cq1eQxggP8 MIID+AIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExh a2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8v d3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRp Y2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkNH2TynzAJBgUrDgMCGgUAoIICDTAYBgkqhkiG 9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA3MTYyMzA4NDJaMCMGCSqGSIb3 DQEJBDEWBBQ7HCUdeEdvttUkdYSGur4ON9z3LDCB1AYJKwYBBAGCNxAEMYHGMIHDMIGuMQswCQYD VQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVU aGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2 MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsAhAv lStUS1saxfCiWQ0fZPKfMIHWBgsqhkiG9w0BCRACCzGBxqCBwzCBrjELMAkGA1UEBhMCVVMxCzAJ BgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVT VCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVU Ti1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQL5UrVEtbGsXwolkN H2TynzANBgkqhkiG9w0BAQEFAASCAQCHWKxh6XMeYAryArBVq2uK/17YAj0xK9/9l0yicNrYWNEs u3i/cXwAD25+ntjVFs8PsbT0ExSYlrA1X1sWXkH+7UKjLVv4fxvCbq7PdSZJPcl/6dT1R0nrQang NI3Pjqmz8KYw5K1J2mPalsHjs7JW08b388lDpfSaTtTsHKcU5jTXAUPPmtqygnZPssdIS2EblW5F nKvvkaU3A/ebrVGIcW9y5PXhaWbxGvc7+NyfTnMXQq1GSWtWbR4O+TTuzhG68+tf8CgaE1/JqqFT a76zD5GG1phoiyP1CY59HJJBjpqSS5s+Hu/hvKh0CGzwywEayn5H2RnLRgb6V9OQ47DwAAAAAAAA --Apple-Mail-27-1043066244-- From pkyzivat@cisco.com Thu Jul 16 16:08:23 2009 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 9A64B3A6E0B for ; Thu, 16 Jul 2009 16:08:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.675 X-Spam-Level: X-Spam-Status: No, score=-1.675 tagged_above=-999 required=5 tests=[AWL=-4.771, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_42=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_82=0.6, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 vJj25hHFZL3w for ; Thu, 16 Jul 2009 16:08:22 -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 1540B28C1FA for ; Thu, 16 Jul 2009 16:08:22 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHJPX0pAZnme/2dsb2JhbAC4ZoZjgUCRFQWBMIEPgQxCgUU X-IronPort-AV: E=Sophos;i="4.42,413,1243814400"; d="scan'208";a="50707155" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-1.cisco.com with ESMTP; 16 Jul 2009 23:08:54 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6GN8s9V030641; Thu, 16 Jul 2009 19:08:54 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6GN8sfu028210; Thu, 16 Jul 2009 23:08:54 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 19:08:54 -0400 Received: from [10.86.246.18] ([10.86.246.18]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 16 Jul 2009 19:08:53 -0400 Message-ID: <4A5FB302.7080102@cisco.com> Date: Thu, 16 Jul 2009 19:08:50 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: gao.yang2@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 16 Jul 2009 23:08:53.0835 (UTC) FILETIME=[637459B0:01CA066A] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6682; t=1247785734; x=1248649734; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20=3D?GB2312?B?tPC4tDogdGFyZ2V0IHJlZnJlc2 ggZHVyaW5nIGFuIGluY29tcA=3D=3D?=3D=0A=20=3D?GB2312?B?bGV0ZSB yZUlOVklURS10cmFuc2FjdGlvbg=3D=3D?=3D |Sender:=20 |To:=20gao.yang2@zte.com.cn; bh=Wr6O3CFUJxXKnHBt/xPcwoOVT5OxA899nRCml4pGyW8=; b=XS6f+63zkKvys3oo4fAopN6VzCIeLtOTF7/xSSy8D/nIcEOL2Mo2KKk472 4u+nhO/exBoVNU8QA3l/uk4+k6HbGtyBZRut8LGepGtY7NxJOsgZQK7PmfgI oFmi3o1Udd; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIPCORE , OKUMURA Shinji Subject: Re: [sipcore] =?gb2312?b?tPC4tDogdGFyZ2V0IHJlZnJlc2ggZHVyaW5nIGFuIGlu?= =?gb2312?b?Y29tcGxldGUgcmVJTlZJVEUtdHJhbnNhY3Rpb24=?= 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, 16 Jul 2009 23:08:23 -0000 IMO it is a bad idea, dangerous precedent, and not very functional, to have the UAS modifying the Via when receiving a target refresh. This is way out of line. Also, its not that unusual for middleboxes to obscure Vias, in which case the UAS won't even find the entry that needs to be modified. The use case is an infrequent one, though it could be important. I spelled out how this could be handled without fixing the Via, and that is all consistent with current rules. The only thing that is required is that the target refresh by the UPDATE must not be rolled back if the enclosing INVITE fails. IMO that is reasonable, even if it is a special case. Thanks, Paul gao.yang2@zte.com.cn wrote: > > Hi Shinji, > > IMO, it is not elegant solution, as: > 1. This is a additional requirement for UA and proxy. > 2. Further the response(of INVITE/Re-INVITE) can be 4xx or 2xx, and the > difference may has impact on session state. > > I have a raw way: > > As it is because of the inconsistency of refreshed target and > dispatching rule by Via, and UAS has get the refreshed target by UPDATE, > so the UAS can modify the last Via header(which is formed by UAC > according to its address) to be the new address of UAC. *But I am not > sure is there any proxy will check the Via headers.* > > The mentioned case is that the response is after the UPDATE(by UAS's > view). If the final response is before the UDPATE(by UAS's view): > 2xx case: The retransmission of 2xx should use modified Via header. > 4xx case: 4xx is hop-by-hop, so the 4xx will be sent to the old address > of UAC. So, it can be missed. The UAC's timer for final response will > fire(as 408), and it can send a new Re-INVITE or just terminate the > session. > > Thanks. > > Gao > > > > *OKUMURA Shinji * > > 2009-07-16 14:38 > > > ÊÕ¼þÈË > SIPCORE > ³­ËÍ > gao.yang2@zte.com.cn, Paul Kyzivat > Ö÷Ìâ > target refresh during an incomplete reINVITE-transaction > > > > > > > > > Hi Gao, > > I think this issue may be discussed previously. > > During an incomplete reINVITE-transaction, if UAC's IP address > is changed, > > UAC behavior when sending the UPDATE request to refresh local target > MAY send CANCEL > DO NOT expect 4xx responce for reINVITE > If necessary, send new reINVITE (in the same dialog) > > UAS behavior when receiving the UPDATE request to refresh remote target > If tactful, MAY send 4xx responce for reINVITE > DO expect CANCEL > > Server transaction (nearest UAC) > If very very tactful, would forward 4xx to new IP address. > but I'm not sure it cause no problem. > > Regards, > Shinji > > gao.yang2@zte.com.cn > >Hi, > > > >Then, it seems a real problem for inconsistency of refreshed target and > >dispatching rule by Via. > > > >Paul has given out some BCP way. Do you have some thought about solutions > >in theory? > > > >Thanks. > > > >Gao > > > >=================================== > > Zip : 210012 > > Tel : 87211 > > Tel2 :(+86)-025-52877211 > > e_mail : gao.yang2@zte.com.cn > >=================================== > > > >OKUMURA Shinji > >2009-07-16 12:29 > > > >Hi, Gao > > > >I seem you don't still catch his point. He has been talking about > >a Via header of not a proxy but an UAC. the server transaction send > >a responce of the reINVITE to the old address of an UAC, even if > >UPDATE request had refreshed UAC's local target(ie. IP address). > > > >It is a basic rule described in RFC3261. RFC3311 does NOT change it. > > > >Regards, > >Shinji > > > >gao.yang2@zte.com.cn > >>Hi, > >> > >>I catch your point now. You mean that the middle-box, such as proxy, > >>adding Via in the INVITE. Then the proxy is now non-functional, > making the > >>response unreachable. > >> > >>But I think the solutions should not be in protocol level. The solutions > >>can be: > >> > >>1. Fault tolerance. (ie. crashing of P-CSCF/S-CSCF) > >> > >>2. Issue new INVITE replace the old one. (ie. changing P-CSCF) > >> > >>Thanks. > >> > >>Gao > >> > >>=================================== > >> Zip : 210012 > >> Tel : 87211 > >> Tel2 :(+86)-025-52877211 > >> e_mail : gao.yang2@zte.com.cn > >>=================================== > >> > >> > >> > >>Paul Kyzivat > >> > >>gao.yang2@zte.com.cn wrote: > >> > >>> If |he UAC decides to fix this by sending an UPDATE before > completion of > >>> the reINVITE, then it may succeed in getting the remote target changed > >>> at the UAS. But the *UAS is still obligated to send the remaining > >>> responses to the address in the Via, which is the old address. * > >>> > >>> [Gao] It is in RFC3261, but RFC3311 has the definition as: > >>> > >>> from RFC3311: > >>> UPDATE is a target refresh request. As specified in RFC 3261 [1], > >>> this means that it can update the remote target of a dialog. If a UA > >>> uses an UPDATE request or response to modify the remote target while > >>> *an INVITE transaction is in progress*, and it is a UAS for that > INVITE > >>> transaction, it *MUST place the same value into the Contact header* > >>> * field of the 2xx to the INVITE that it placed into the UPDATE > request* > >>> * or response*. > >>> > >>> So, it should be the new address here. > >> > >>You miss my point. > >> > >>Its not about the Contact placed *in* the 2xx response. > >>Its about the address to which the response is delivered. > >>That is dictated by the Via headers in the INVITE request. > >>Those are not affected by the target refresh. > >> > >> Thanks, > >> Paul > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. From AUDET@nortel.com Thu Jul 16 17:34:30 2009 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 C810A3A6B01 for ; Thu, 16 Jul 2009 17:34:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.471 X-Spam-Level: X-Spam-Status: No, score=-4.471 tagged_above=-999 required=5 tests=[AWL=0.061, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 tSOUeQa4hXCn for ; Thu, 16 Jul 2009 17:34:30 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id DA9FF3A687D for ; Thu, 16 Jul 2009 17:34:29 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6H0YpG28776; Fri, 17 Jul 2009 00:34:51 GMT Received: from 47.102.152.117 ([47.102.152.117]) by zrc2hxm0.corp.nortel.com ([47.103.123.71]) with Microsoft Exchange Server HTTP-DAV ; Fri, 17 Jul 2009 00:34:43 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 16 Jul 2009 17:34:39 -0700 From: "Francois Audet" To: Eric Burger , SIPCORE Message-ID: Thread-Topic: [sipcore] INFO draft Thread-Index: AcoGdl42bAFN96CVTb6cpiF+8lqpjA== In-Reply-To: <44F700B5-1F7F-4732-86A0-76D7E7083AE6@standardstrack.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Subject: Re: [sipcore] INFO draft 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, 17 Jul 2009 00:34:30 -0000 +2 On Jul16 2009 16:08 , "Eric Burger" wrote: > The silence is deafening. Please +1 or -1, as the WGLC is underway. If > you're too tired of the topic, just +1 to prove you read the email. > > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-info-events-00.txt > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From AUDET@nortel.com Thu Jul 16 17:37:12 2009 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 413643A6B01 for ; Thu, 16 Jul 2009 17:37:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.477 X-Spam-Level: X-Spam-Status: No, score=-4.477 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, RCVD_NUMERIC_HELO=2.067] 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 MQ55THvYPo6q for ; Thu, 16 Jul 2009 17:37:11 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 420A23A6DA8 for ; Thu, 16 Jul 2009 17:37:11 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6H0Zuk12422; Fri, 17 Jul 2009 00:35:56 GMT Received: from 47.102.152.117 ([47.102.152.117]) by zrc2hxm0.corp.nortel.com ([47.103.123.71]) with Microsoft Exchange Server HTTP-DAV ; Fri, 17 Jul 2009 00:37:03 +0000 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Thu, 16 Jul 2009 17:37:02 -0700 From: "Francois Audet" To: Paul Kyzivat Message-ID: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoGdrNymXGLk6cITOGzbIG/niCWIg== In-Reply-To: <4A5FAF4E.4030901@cisco.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 17 Jul 2009 00:37:12 -0000 >> Say I call sip:+1234567890@sp.com;user=phone. My proxy is "sp.com", >> right? >> >> Then sp.net does ENUM query. > > If we assume that ENUM qualifies as a location service (and I am now > convinced that it does), then this URI *is* an AOR in sp.com. No, because it's not the right domain. It's doing the ENUM on a phone number. So it really has nothing to do with a SIP scheme (a condition for AOR, remember?). And in fact, it goes to example.com, not sp.com From jmh@joelhalpern.com Thu Jul 16 19:04:44 2009 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 E617B28C255 for ; Thu, 16 Jul 2009 19:04:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.443 X-Spam-Level: X-Spam-Status: No, score=-3.443 tagged_above=-999 required=5 tests=[AWL=0.156, BAYES_00=-2.599, 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 yXltjZZjzEXd for ; Thu, 16 Jul 2009 19:04:44 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by core3.amsl.com (Postfix) with ESMTP id 59ED428C287 for ; Thu, 16 Jul 2009 19:04:19 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id BBEBD434029; Thu, 16 Jul 2009 19:04:52 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-248.clppva.btas.verizon.net [71.161.52.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 50669430390; Thu, 16 Jul 2009 19:04:51 -0700 (PDT) Message-ID: <4A5FDC3E.2000101@joelhalpern.com> Date: Thu, 16 Jul 2009 22:04:46 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Francois Audet References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 17 Jul 2009 02:04:45 -0000 Actually, I think it (the domain that was on the right hand side of the R-URI, and that is performing the ENUM lookup) is "the right" domain. Of course, this turns on deciding what a SIP URI with a user part that happens to be digits is. As far as I can tell, it ought to be a SIP UIR. Therefore, if a proxy in domain sp.com receives a SIP R-URI of sip:+123456789@sp.com;user=phone (with the right number of digits, sorry), then sp.com is the responsible domain. The fact that the proxy does not actually care if the target is within sp.com, and will use ENUM, and send the call on wherever ENUM tells it does not change the fact that the R-URI indicated his domain, the proxy understand the domain, and understand the rules of the domain. That domain just has a lot of implicit registration, and an ENUM based location service. So be it. (Now, at least in my opinion, if any proxy outside of sp.com tries that trick it is just plain wrong. But that is, I think, a different discussion.) Yours, Joel Francois Audet wrote: > >>> Say I call sip:+1234567890@sp.com;user=phone. My proxy is "sp.com", >>> right? >>> >>> Then sp.net does ENUM query. >> If we assume that ENUM qualifies as a location service (and I am now >> convinced that it does), then this URI *is* an AOR in sp.com. > > No, because it's not the right domain. It's doing the ENUM on a phone > number. So it really has nothing to do with a SIP scheme (a condition > for AOR, remember?). > > And in fact, it goes to example.com, not sp.com > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From HKaplan@acmepacket.com Thu Jul 16 20:50:52 2009 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 845AD3A6843 for ; Thu, 16 Jul 2009 20:50:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.579 X-Spam-Level: X-Spam-Status: No, score=-2.579 tagged_above=-999 required=5 tests=[AWL=0.020, 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 1lC1Ctx-zlm8 for ; Thu, 16 Jul 2009 20:50:51 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id F41DF3A69BF for ; Thu, 16 Jul 2009 20:50:45 -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.1.375.2; Thu, 16 Jul 2009 23:51:16 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 16 Jul 2009 23:51:15 -0400 From: Hadriel Kaplan To: Eric Burger , SIPCORE Date: Thu, 16 Jul 2009 23:51:11 -0400 Thread-Topic: [sipcore] INFO draft Thread-Index: AcoGamCEbr/TYLwQSqufEma3vfH35wAJ1r4w Message-ID: References: <44F700B5-1F7F-4732-86A0-76D7E7083AE6@standardstrack.com> In-Reply-To: <44F700B5-1F7F-4732-86A0-76D7E7083AE6@standardstrack.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] INFO draft 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, 17 Jul 2009 03:50:52 -0000 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Eric Burger > Sent: Thursday, July 16, 2009 7:09 PM > To: SIPCORE > Subject: [sipcore] INFO draft >=20 > The silence is deafening. Please +1 or -1, as the WGLC is underway. If > you're too tired of the topic, just +1 to prove you read the email. >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-info-events-00.txt +1 (but I didn't read the email) -hadriel From gao.yang2@zte.com.cn Thu Jul 16 21:39:16 2009 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 8BCB93A6943; Thu, 16 Jul 2009 21:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -92.339 X-Spam-Level: X-Spam-Status: No, score=-92.339 tagged_above=-999 required=5 tests=[AWL=-2.549, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_42=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_64=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_82=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 ZrEjgLflVgR1; Thu, 16 Jul 2009 21:39:14 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id E780B3A6953; Thu, 16 Jul 2009 21:39:03 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 91102001811080; Fri, 17 Jul 2009 12:26:25 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 85804.5659058387; Fri, 17 Jul 2009 12:32:24 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n6H4daRn054210; Fri, 17 Jul 2009 12:39:36 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4A5FB302.7080102@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Fri, 17 Jul 2009 12:39:25 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-17 12:39:33, Serialize complete at 2009-07-17 12:39:33 Content-Type: multipart/alternative; boundary="=_alternative 001995B7482575F6_=" X-MAIL: mse1.zte.com.cn n6H4daRn054210 Cc: SIPCORE , OKUMURA Shinji , sipcore-bounces@ietf.org Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ICC08Li0OiB0YXJnZXQgcmVmcmVzaCBk?= =?gb2312?b?dXJpbmcgYW4gaW5jb21wbGV0ZSByZUlOVklURS10cmFuc2FjdGlvbg==?= 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, 17 Jul 2009 04:39:16 -0000 This is a multipart message in MIME format. --=_alternative 001995B7482575F6_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 aW5saW5lcy4NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAg OiAyMTAwMTINCiBUZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQog ZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQoNCg0KDQpQYXVsIEt5eml2YXQgPHBreXppdmF0QGNpc2NvLmNvbT4gDQq3orz+ yMs6ICBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMDktMDctMTcgMDc6MDgNCg0KytW8/sjL DQpnYW8ueWFuZzJAenRlLmNvbS5jbg0Ks63LzQ0KU0lQQ09SRSA8c2lwY29yZUBpZXRmLm9yZz4s IE9LVU1VUkEgU2hpbmppIDxzaGluQHNvZnRmcm9udC5jby5qcD4NCtb3zOINClJlOiBbc2lwY29y ZV0gtPC4tDogdGFyZ2V0IHJlZnJlc2ggZHVyaW5nIGFuIGluY29tcGxldGUgDQpyZUlOVklURS10 cmFuc2FjdGlvbg0KDQoNCg0KDQoNCg0KSU1PIGl0IGlzIGEgYmFkIGlkZWEsIGRhbmdlcm91cyBw cmVjZWRlbnQsIGFuZCBub3QgdmVyeSBmdW5jdGlvbmFsLCB0bw0KaGF2ZSB0aGUgVUFTIG1vZGlm eWluZyB0aGUgVmlhIHdoZW4gcmVjZWl2aW5nIGEgdGFyZ2V0IHJlZnJlc2guDQoNClRoaXMgaXMg d2F5IG91dCBvZiBsaW5lLiBBbHNvLCBpdHMgbm90IHRoYXQgdW51c3VhbCBmb3IgbWlkZGxlYm94 ZXMgdG8NCm9ic2N1cmUgVmlhcywgaW4gd2hpY2ggY2FzZSB0aGUgVUFTIHdvbid0IGV2ZW4gZmlu ZCB0aGUgZW50cnkgdGhhdCBuZWVkcw0KdG8gYmUgbW9kaWZpZWQuDQoNCltHYW9dIElNTywgd2hl biBtaWRkbGVib3hlcyBhY3QgYXMgQjJCVUEsIGl0IGlzIHJlYXNvbmFibGUgdG8gb2JzY3VyZSAN ClZpYXMuIEFuZCBpdCBpcyB0aGUgQjJCVUEncyBVQVMgbmVlZCB0byBtb2RpZnkgdGhlIGxhc3Qg VmlhIHdoaWxlIA0KdHJhbnNmZXJpbmcgdGhlIHJlc3BvbnNlLg0KT3RoZXIgcHJveHkgYmVoYXZp b3JpbmcgbWlkZGxlYm94IHNob3VsZCBub3QgZG8gc28uIEJ1dCBJIGFkbWl0IHRoYXQgdGhlcmUg DQphcmUgbWlkZGxlYm94cyB3aGljaCBhcmVuJ3QgQjJCVUEgZG9pbmcgYXMgeW91IHNhaWQgaW4g Y3VycmVudCBuZXR3b3JrLiBTbw0Ko6wgSU1PLCBpdCAqc2hvdWxkIG5vdCogYmUgYmFkKCppZiog aXQgaXMgZGVmaW5lZCBhcyBlYXJseSBhcyBSRkMzMjYxLCBpdCANCm1heSBiZSBPSyksIGJ1dCBu b3QgcHJhY3RpY2FsIGluIGN1cnJlbnQgbmV0d29yay4NCg0KVGhlIHVzZSBjYXNlIGlzIGFuIGlu ZnJlcXVlbnQgb25lLCB0aG91Z2ggaXQgY291bGQgYmUgaW1wb3J0YW50LiBJIHNwZWxsZWQgDQoN Cm91dCBob3cgdGhpcyBjb3VsZCBiZSBoYW5kbGVkIHdpdGhvdXQgZml4aW5nIHRoZSBWaWEsIGFu ZCB0aGF0DQppcyBhbGwgY29uc2lzdGVudCB3aXRoIGN1cnJlbnQgcnVsZXMuDQoNCltHYW9dIEkg YWdyZWUgd2l0aCB5b3UuIEJ1dCBhcyB0aGUgbW92aW5nIHNwZWVkIGlzIGZhc3RlcihzdWNoIGFz IG1vcmUgYW5kIA0KbW9yZSBoaWdoIHNwZWVkIHRyYWlucyBpbiBDaGluYSksIHRoZSBwcm9iYWJp bGl0eSBvZiBsb3Npbmcgb2xkIElQIEFjY2VzcyANCndoaWxlIG1vdmluZyBtYXkgYmUgaW5jcmVh c2VpbmcuIFNvLiB0aGUgc29sdXRpb24gaXMgbmVlZGZ1bC4gQW5kIHlvdXIgd2F5IA0KaXMgT0sg YXMgSSBzYWlkIGluIHByZXZpb3VzIG1haWxzLg0KDQogIFRoZSBvbmx5IHRoaW5nIHRoYXQgaXMg cmVxdWlyZWQgaXMNCnRoYXQgdGhlIHRhcmdldCByZWZyZXNoIGJ5IHRoZSBVUERBVEUgbXVzdCBu b3QgYmUgcm9sbGVkIGJhY2sgaWYgdGhlDQplbmNsb3NpbmcgSU5WSVRFIGZhaWxzLiBJTU8gdGhh dCBpcyByZWFzb25hYmxlLCBldmVuIGlmIGl0IGlzIGEgc3BlY2lhbA0KY2FzZS4NCg0KW0dhb10g SU1PLCBkcmFmdC1jYW1hcmlsbG8tc2lwY29yZS1yZWludml0ZS0wMCBoYXMgbm8gY29uZmxpY3Qg d2l0aCB0aGlzLg0KDQoNCiAgICAgICAgICAgICAgICAgVGhhbmtzLA0KICAgICAgICAgICAgICAg ICBQYXVsDQoNCmdhby55YW5nMkB6dGUuY29tLmNuIHdyb3RlOg0KPiANCj4gSGkgU2hpbmppLA0K PiANCj4gSU1PLCBpdCBpcyBub3QgZWxlZ2FudCBzb2x1dGlvbiwgYXM6DQo+IDEuIFRoaXMgaXMg YSBhZGRpdGlvbmFsIHJlcXVpcmVtZW50IGZvciBVQSBhbmQgcHJveHkuDQo+IDIuIEZ1cnRoZXIg dGhlIHJlc3BvbnNlKG9mIElOVklURS9SZS1JTlZJVEUpIGNhbiBiZSA0eHggb3IgMnh4LCBhbmQg dGhlIA0KPiBkaWZmZXJlbmNlIG1heSBoYXMgaW1wYWN0IG9uIHNlc3Npb24gc3RhdGUuDQo+IA0K PiBJIGhhdmUgYSByYXcgd2F5Og0KPiANCj4gQXMgaXQgaXMgYmVjYXVzZSBvZiB0aGUgaW5jb25z aXN0ZW5jeSBvZiByZWZyZXNoZWQgdGFyZ2V0IGFuZCANCj4gZGlzcGF0Y2hpbmcgcnVsZSBieSBW aWEsIGFuZCBVQVMgaGFzIGdldCB0aGUgcmVmcmVzaGVkIHRhcmdldCBieSBVUERBVEUsIA0KDQo+ IHNvIHRoZSBVQVMgY2FuIG1vZGlmeSB0aGUgbGFzdCBWaWEgaGVhZGVyKHdoaWNoIGlzIGZvcm1l ZCBieSBVQUMgDQo+IGFjY29yZGluZyB0byBpdHMgYWRkcmVzcykgdG8gYmUgdGhlIG5ldyBhZGRy ZXNzIG9mIFVBQy4gKkJ1dCBJIGFtIG5vdCANCj4gc3VyZSBpcyB0aGVyZSBhbnkgcHJveHkgd2ls bCBjaGVjayB0aGUgVmlhIGhlYWRlcnMuDQo+IA0KPiBUaGUgbWVudGlvbmVkIGNhc2UgaXMgdGhh dCB0aGUgcmVzcG9uc2UgaXMgYWZ0ZXIgdGhlIFVQREFURShieSBVQVMncyANCj4gdmlldykuIElm IHRoZSBmaW5hbCByZXNwb25zZSBpcyBiZWZvcmUgdGhlIFVEUEFURShieSBVQVMncyB2aWV3KToN Cj4gMnh4IGNhc2U6IFRoZSByZXRyYW5zbWlzc2lvbiBvZiAyeHggc2hvdWxkIHVzZSBtb2RpZmll ZCBWaWEgaGVhZGVyLg0KPiA0eHggY2FzZTogNHh4IGlzIGhvcC1ieS1ob3AsIHNvIHRoZSA0eHgg d2lsbCBiZSBzZW50IHRvIHRoZSBvbGQgYWRkcmVzcyANCj4gb2YgVUFDLiBTbywgaXQgY2FuIGJl IG1pc3NlZC4gVGhlIFVBQydzIHRpbWVyIGZvciBmaW5hbCByZXNwb25zZSB3aWxsIA0KPiBmaXJl KGFzIDQwOCksIGFuZCBpdCBjYW4gc2VuZCBhIG5ldyBSZS1JTlZJVEUgb3IganVzdCB0ZXJtaW5h dGUgdGhlIA0KPiBzZXNzaW9uLg0KPiANCj4gVGhhbmtzLg0KPiANCj4gR2FvDQo+IA0KPiANCj4g DQo+ICpPS1VNVVJBIFNoaW5qaSA8c2hpbkBzb2Z0ZnJvbnQuY28uanA+Kg0KPiANCj4gMjAwOS0w Ny0xNiAxNDozOA0KPiANCj4gDQo+IMrVvP7Iyw0KPiAgICAgICAgICAgICAgICBTSVBDT1JFIDxz aXBjb3JlQGlldGYub3JnPg0KPiCzrcvNDQo+ICAgICAgICAgICAgICAgIGdhby55YW5nMkB6dGUu Y29tLmNuLCBQYXVsIEt5eml2YXQgPHBreXppdmF0QGNpc2NvLmNvbT4NCj4g1vfM4g0KPiAgICAg ICAgICAgICAgICB0YXJnZXQgcmVmcmVzaCBkdXJpbmcgYW4gaW5jb21wbGV0ZSByZUlOVklURS10 cmFuc2FjdGlvbg0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IEhpIEdhbywNCj4g DQo+IEkgdGhpbmsgdGhpcyBpc3N1ZSBtYXkgYmUgZGlzY3Vzc2VkIHByZXZpb3VzbHkuDQo+IA0K PiBEdXJpbmcgYW4gaW5jb21wbGV0ZSByZUlOVklURS10cmFuc2FjdGlvbiwgaWYgVUFDJ3MgSVAg YWRkcmVzcw0KPiBpcyBjaGFuZ2VkLA0KPiANCj4gVUFDIGJlaGF2aW9yIHdoZW4gc2VuZGluZyB0 aGUgVVBEQVRFIHJlcXVlc3QgdG8gcmVmcmVzaCBsb2NhbCB0YXJnZXQNCj4gIE1BWSBzZW5kIENB TkNFTA0KPiAgRE8gTk9UIGV4cGVjdCA0eHggcmVzcG9uY2UgZm9yIHJlSU5WSVRFDQo+ICBJZiBu ZWNlc3NhcnksIHNlbmQgbmV3IHJlSU5WSVRFIChpbiB0aGUgc2FtZSBkaWFsb2cpDQo+IA0KPiBV QVMgYmVoYXZpb3Igd2hlbiByZWNlaXZpbmcgdGhlIFVQREFURSByZXF1ZXN0IHRvIHJlZnJlc2gg cmVtb3RlIHRhcmdldA0KPiAgSWYgdGFjdGZ1bCwgTUFZIHNlbmQgNHh4IHJlc3BvbmNlIGZvciBy ZUlOVklURQ0KPiAgRE8gZXhwZWN0IENBTkNFTA0KPiANCj4gU2VydmVyIHRyYW5zYWN0aW9uIChu ZWFyZXN0IFVBQykNCj4gIElmIHZlcnkgdmVyeSB0YWN0ZnVsLCB3b3VsZCBmb3J3YXJkIDR4eCB0 byBuZXcgSVAgYWRkcmVzcy4NCj4gIGJ1dCBJJ20gbm90IHN1cmUgaXQgY2F1c2Ugbm8gcHJvYmxl bS4NCj4gDQo+IFJlZ2FyZHMsDQo+IFNoaW5qaQ0KPiANCj4gZ2FvLnlhbmcyQHp0ZS5jb20uY24N Cj4gID5IaSwNCj4gID4NCj4gID5UaGVuLCBpdCBzZWVtcyBhIHJlYWwgcHJvYmxlbSBmb3IgaW5j b25zaXN0ZW5jeSBvZiByZWZyZXNoZWQgdGFyZ2V0IA0KYW5kDQo+ICA+ZGlzcGF0Y2hpbmcgcnVs ZSBieSBWaWEuDQo+ICA+DQo+ICA+UGF1bCBoYXMgZ2l2ZW4gb3V0IHNvbWUgQkNQIHdheS4gRG8g eW91IGhhdmUgc29tZSB0aG91Z2h0IGFib3V0IA0Kc29sdXRpb25zDQo+ICA+aW4gdGhlb3J5Pw0K PiAgPg0KPiAgPlRoYW5rcy4NCj4gID4NCj4gID5HYW8NCj4gID4NCj4gID49PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQ0KPiAgPiBaaXAgICAgOiAyMTAwMTINCj4gID4gVGVsICAg IDogODcyMTENCj4gID4gVGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCj4gID4gZV9tYWlsIDog Z2FvLnlhbmcyQHp0ZS5jb20uY24NCj4gID49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KPiAgPg0KPiAgPk9LVU1VUkEgU2hpbmppIDxzaGluQHNvZnRmcm9udC5jby5qcD4NCj4g ID4yMDA5LTA3LTE2IDEyOjI5DQo+ICA+DQo+ICA+SGksIEdhbw0KPiAgPg0KPiAgPkkgc2VlbSB5 b3UgZG9uJ3Qgc3RpbGwgY2F0Y2ggaGlzIHBvaW50LiBIZSBoYXMgYmVlbiB0YWxraW5nIGFib3V0 DQo+ICA+YSBWaWEgaGVhZGVyIG9mIG5vdCBhIHByb3h5IGJ1dCBhbiBVQUMuIHRoZSBzZXJ2ZXIg dHJhbnNhY3Rpb24gc2VuZA0KPiAgPmEgcmVzcG9uY2Ugb2YgdGhlIHJlSU5WSVRFIHRvIHRoZSBv bGQgYWRkcmVzcyBvZiBhbiBVQUMsIGV2ZW4gaWYNCj4gID5VUERBVEUgcmVxdWVzdCBoYWQgcmVm cmVzaGVkIFVBQydzIGxvY2FsIHRhcmdldChpZS4gSVAgYWRkcmVzcykuDQo+ICA+DQo+ICA+SXQg aXMgYSBiYXNpYyBydWxlIGRlc2NyaWJlZCBpbiBSRkMzMjYxLiBSRkMzMzExIGRvZXMgTk9UIGNo YW5nZSBpdC4NCj4gID4NCj4gID5SZWdhcmRzLA0KPiAgPlNoaW5qaQ0KPiAgPg0KPiAgPmdhby55 YW5nMkB6dGUuY29tLmNuDQo+ICA+PkhpLA0KPiAgPj4NCj4gID4+SSBjYXRjaCB5b3VyIHBvaW50 IG5vdy4gWW91IG1lYW4gdGhhdCB0aGUgbWlkZGxlLWJveCwgc3VjaCBhcyBwcm94eSwNCj4gID4+ YWRkaW5nIFZpYSBpbiB0aGUgSU5WSVRFLiBUaGVuIHRoZSBwcm94eSBpcyBub3cgbm9uLWZ1bmN0 aW9uYWwsIA0KPiBtYWtpbmcgdGhlDQo+ICA+PnJlc3BvbnNlIHVucmVhY2hhYmxlLg0KPiAgPj4N Cj4gID4+QnV0IEkgdGhpbmsgdGhlIHNvbHV0aW9ucyBzaG91bGQgbm90IGJlIGluIHByb3RvY29s IGxldmVsLiBUaGUgDQpzb2x1dGlvbnMNCj4gID4+Y2FuIGJlOg0KPiAgPj4NCj4gID4+MS4gRmF1 bHQgdG9sZXJhbmNlLiAoaWUuIGNyYXNoaW5nIG9mIFAtQ1NDRi9TLUNTQ0YpDQo+ICA+Pg0KPiAg Pj4yLiBJc3N1ZSBuZXcgSU5WSVRFIHJlcGxhY2UgdGhlIG9sZCBvbmUuIChpZS4gY2hhbmdpbmcg UC1DU0NGKQ0KPiAgPj4NCj4gID4+VGhhbmtzLg0KPiAgPj4NCj4gID4+R2FvDQo+ICA+Pg0KPiAg Pj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiAgPj4gWmlwICAgIDogMjEw MDEyDQo+ICA+PiBUZWwgICAgOiA4NzIxMQ0KPiAgPj4gVGVsMiAgIDooKzg2KS0wMjUtNTI4Nzcy MTENCj4gID4+IGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuDQo+ICA+Pj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQo+ICA+Pg0KPiAgPj4NCj4gID4+DQo+ICA+PlBhdWwg S3l6aXZhdCA8cGt5eml2YXRAY2lzY28uY29tPg0KPiAgPj4NCj4gID4+Z2FvLnlhbmcyQHp0ZS5j b20uY24gd3JvdGU6DQo+ICA+Pg0KPiAgPj4+IElmIHxoZSBVQUMgZGVjaWRlcyB0byBmaXggdGhp cyBieSBzZW5kaW5nIGFuIFVQREFURSBiZWZvcmUgDQo+IGNvbXBsZXRpb24gb2YNCj4gID4+PiB0 aGUgcmVJTlZJVEUsIHRoZW4gaXQgbWF5IHN1Y2NlZWQgaW4gZ2V0dGluZyB0aGUgcmVtb3RlIHRh cmdldCANCmNoYW5nZWQNCj4gID4+PiBhdCB0aGUgVUFTLiBCdXQgdGhlICpVQVMgaXMgc3RpbGwg b2JsaWdhdGVkIHRvIHNlbmQgdGhlIHJlbWFpbmluZw0KPiAgPj4+IHJlc3BvbnNlcyB0byB0aGUg YWRkcmVzcyBpbiB0aGUgVmlhLCB3aGljaCBpcyB0aGUgb2xkIGFkZHJlc3MuICoNCj4gID4+Pg0K PiAgPj4+IFtHYW9dIEl0IGlzIGluIFJGQzMyNjEsIGJ1dCBSRkMzMzExIGhhcyB0aGUgZGVmaW5p dGlvbiBhczoNCj4gID4+Pg0KPiAgPj4+IGZyb20gUkZDMzMxMToNCj4gID4+PiBVUERBVEUgaXMg YSB0YXJnZXQgcmVmcmVzaCByZXF1ZXN0LiBBcyBzcGVjaWZpZWQgaW4gUkZDIDMyNjEgWzFdLA0K PiAgPj4+ICAgIHRoaXMgbWVhbnMgdGhhdCBpdCBjYW4gdXBkYXRlIHRoZSByZW1vdGUgdGFyZ2V0 IG9mIGEgZGlhbG9nLiBJZiANCmEgVUENCj4gID4+PiAgICB1c2VzIGFuIFVQREFURSByZXF1ZXN0 IG9yIHJlc3BvbnNlIHRvIG1vZGlmeSB0aGUgcmVtb3RlIHRhcmdldCANCndoaWxlDQo+ICA+Pj4g ICAgKmFuIElOVklURSB0cmFuc2FjdGlvbiBpcyBpbiBwcm9ncmVzcyosIGFuZCBpdCBpcyBhIFVB UyBmb3IgdGhhdCANCg0KPiBJTlZJVEUNCj4gID4+PiAgICB0cmFuc2FjdGlvbiwgaXQgKk1VU1Qg cGxhY2UgdGhlIHNhbWUgdmFsdWUgaW50byB0aGUgQ29udGFjdCANCmhlYWRlcioNCj4gID4+PiAq ICAgZmllbGQgb2YgdGhlIDJ4eCB0byB0aGUgSU5WSVRFIHRoYXQgaXQgcGxhY2VkIGludG8gdGhl IFVQREFURSANCj4gcmVxdWVzdCoNCj4gID4+PiAqICAgb3IgcmVzcG9uc2UqLg0KPiAgPj4+DQo+ ICA+Pj4gU28sIGl0IHNob3VsZCBiZSB0aGUgbmV3IGFkZHJlc3MgaGVyZS4NCj4gID4+DQo+ICA+ PllvdSBtaXNzIG15IHBvaW50Lg0KPiAgPj4NCj4gID4+SXRzIG5vdCBhYm91dCB0aGUgQ29udGFj dCBwbGFjZWQgKmluKiB0aGUgMnh4IHJlc3BvbnNlLg0KPiAgPj5JdHMgYWJvdXQgdGhlIGFkZHJl c3MgdG8gd2hpY2ggdGhlIHJlc3BvbnNlIGlzIGRlbGl2ZXJlZC4NCj4gID4+VGhhdCBpcyBkaWN0 YXRlZCBieSB0aGUgVmlhIGhlYWRlcnMgaW4gdGhlIElOVklURSByZXF1ZXN0Lg0KPiAgPj5UaG9z ZSBhcmUgbm90IGFmZmVjdGVkIGJ5IHRoZSB0YXJnZXQgcmVmcmVzaC4NCj4gID4+DQo+ICA+PiAg ICAgICAgICAgICAgICAgVGhhbmtzLA0KPiAgPj4gICAgICAgICAgICAgICAgIFBhdWwNCj4gDQo+ IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4gWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0 aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgDQppcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNl bmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gDQppcyBjb25maWRl bnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBz ZWNyZWN5IA0KYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBv ZiB0aGlzIGNvbW11bmljYXRpb24gdG8gDQpvdGhlcnMuDQo+IFRoaXMgZW1haWwgYW5kIGFueSBm aWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIA0KaW50ZW5kZWQg c29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRo ZXkgYXJlIA0KYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVy cm9yIHBsZWFzZSBub3RpZnkgdGhlIA0Kb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZp ZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIA0Kb2YgdGhlIGluZGl2aWR1 YWwgc2VuZGVyLg0KPiBUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBh bmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIA0Kc3lzdGVtLg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3Jl QGlldGYub3JnDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUN Cg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVy J3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwu IFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5 IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBj b21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21p dHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhl IHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNz ZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlm eSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0 aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVz c2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNw YW0gc3lzdGVtLg0K --=_alternative 001995B7482575F6_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmlubGluZXMuPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj49PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PTxicj4NCiBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0KIFRl bCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiBUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3 MjExPGJyPg0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUg d2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+PGI+UGF1bCBLeXppdmF0ICZsdDtwa3l6aXZhdEBjaXNjby5jb20m Z3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+ yMs6ICZuYnNwO3NpcGNvcmUtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDA5LTA3LTE3IDA3OjA4PC9mb250Pg0KPHRkIHdpZHRoPTcz JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWdu PXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+ DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPmdhby55YW5nMkB6dGUuY29tLmNu PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj5TSVBDT1JFICZsdDtzaXBjb3JlQGlldGYub3JnJmd0OywgT0tV TVVSQQ0KU2hpbmppICZsdDtzaGluQHNvZnRmcm9udC5jby5qcCZndDs8L2ZvbnQ+DQo8dHIgdmFs aWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPtb3zOI8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPlJlOiBbc2lwY29yZV0gtPC4tDogdGFyZ2V0IHJlZnJlc2gNCmR1cmluZyBhbiBpbmNvbXBs ZXRlIHJlSU5WSVRFLXRyYW5zYWN0aW9uPC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5JTU8gaXQgaXMgYSBiYWQgaWRlYSwgZGFuZ2Vyb3Vz IHByZWNlZGVudCwgYW5kIG5vdA0KdmVyeSBmdW5jdGlvbmFsLCB0bzxicj4NCmhhdmUgdGhlIFVB UyBtb2RpZnlpbmcgdGhlIFZpYSB3aGVuIHJlY2VpdmluZyBhIHRhcmdldCByZWZyZXNoLjxicj4N Cjxicj4NClRoaXMgaXMgd2F5IG91dCBvZiBsaW5lLiBBbHNvLCBpdHMgbm90IHRoYXQgdW51c3Vh bCBmb3IgbWlkZGxlYm94ZXMgdG88YnI+DQpvYnNjdXJlIFZpYXMsIGluIHdoaWNoIGNhc2UgdGhl IFVBUyB3b24ndCBldmVuIGZpbmQgdGhlIGVudHJ5IHRoYXQgbmVlZHM8YnI+DQp0byBiZSBtb2Rp ZmllZC48L3R0PjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTI+PHR0PltHYW9dIElNTywg d2hlbiBtaWRkbGVib3hlcyBhY3QgYXMgQjJCVUEsIGl0IGlzIHJlYXNvbmFibGUNCnRvIG9ic2N1 cmUgVmlhcy4gQW5kIGl0IGlzIHRoZSBCMkJVQSdzIFVBUyBuZWVkIHRvIG1vZGlmeSB0aGUgbGFz dCBWaWENCndoaWxlIHRyYW5zZmVyaW5nIHRoZSByZXNwb25zZS48L3R0PjwvZm9udD4NCjxicj48 Zm9udCBzaXplPTI+PHR0Pk90aGVyIHByb3h5IGJlaGF2aW9yaW5nIG1pZGRsZWJveCBzaG91bGQg bm90IGRvIHNvLg0KQnV0IEkgYWRtaXQgdGhhdCB0aGVyZSBhcmUgbWlkZGxlYm94cyB3aGljaCBh cmVuJ3QgQjJCVUEgZG9pbmcgYXMgeW91IHNhaWQNCmluIGN1cnJlbnQgbmV0d29yay4gU2+jrCBJ TU8sIGl0ICpzaG91bGQgbm90KiBiZSBiYWQoKmlmKiBpdCBpcyBkZWZpbmVkDQphcyBlYXJseSBh cyBSRkMzMjYxLCBpdCBtYXkgYmUgT0spLCBidXQgbm90IHByYWN0aWNhbCBpbiBjdXJyZW50IG5l dHdvcmsuPGJyPg0KPGJyPg0KVGhlIHVzZSBjYXNlIGlzIGFuIGluZnJlcXVlbnQgb25lLCB0aG91 Z2ggaXQgY291bGQgYmUgaW1wb3J0YW50LiBJIHNwZWxsZWQNCjwvdHQ+PC9mb250Pg0KPGJyPjxm b250IHNpemU9Mj48dHQ+b3V0IGhvdyB0aGlzIGNvdWxkIGJlIGhhbmRsZWQgd2l0aG91dCBmaXhp bmcgdGhlIFZpYSwNCmFuZCB0aGF0PGJyPg0KaXMgYWxsIGNvbnNpc3RlbnQgd2l0aCBjdXJyZW50 IHJ1bGVzLjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+W0dhb10gSSBh Z3JlZSB3aXRoIHlvdS4gQnV0IGFzIHRoZSBtb3Zpbmcgc3BlZWQgaXMNCmZhc3RlcihzdWNoIGFz IG1vcmUgYW5kIG1vcmUgaGlnaCBzcGVlZCB0cmFpbnMgaW4gQ2hpbmEpLCB0aGUgcHJvYmFiaWxp dHkNCm9mIGxvc2luZyBvbGQgSVAgQWNjZXNzIHdoaWxlIG1vdmluZyBtYXkgYmUgaW5jcmVhc2Vp bmcuIFNvLiB0aGUgc29sdXRpb24NCmlzIG5lZWRmdWwuIEFuZCB5b3VyIHdheSBpcyBPSyBhcyBJ IHNhaWQgaW4gcHJldmlvdXMgbWFpbHMuPC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6 ZT0yPjx0dD4mbmJzcDsgVGhlIG9ubHkgdGhpbmcgdGhhdCBpcyByZXF1aXJlZCBpczxicj4NCnRo YXQgdGhlIHRhcmdldCByZWZyZXNoIGJ5IHRoZSBVUERBVEUgbXVzdCBub3QgYmUgcm9sbGVkIGJh Y2sgaWYgdGhlPGJyPg0KZW5jbG9zaW5nIElOVklURSBmYWlscy4gSU1PIHRoYXQgaXMgcmVhc29u YWJsZSwgZXZlbiBpZiBpdCBpcyBhIHNwZWNpYWw8YnI+DQpjYXNlLjxicj4NCjwvdHQ+PC9mb250 Pg0KPGJyPjxmb250IHNpemU9Mj48dHQ+W0dhb10gSU1PLCBkcmFmdC1jYW1hcmlsbG8tc2lwY29y ZS1yZWludml0ZS0wMCBoYXMNCm5vIGNvbmZsaWN0IHdpdGggdGhpcy48L3R0PjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTI+PHR0Pjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7DQpUaGFua3MsPGJyPg0KICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNClBhdWw8YnI+DQo8 YnI+DQpnYW8ueWFuZzJAenRlLmNvbS5jbiB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsgSGkg U2hpbmppLDxicj4NCiZndDsgPGJyPg0KJmd0OyBJTU8sIGl0IGlzIG5vdCBlbGVnYW50IHNvbHV0 aW9uLCBhczo8YnI+DQomZ3Q7IDEuIFRoaXMgaXMgYSBhZGRpdGlvbmFsIHJlcXVpcmVtZW50IGZv ciBVQSBhbmQgcHJveHkuPGJyPg0KJmd0OyAyLiBGdXJ0aGVyIHRoZSByZXNwb25zZShvZiBJTlZJ VEUvUmUtSU5WSVRFKSBjYW4gYmUgNHh4IG9yIDJ4eCwgYW5kDQp0aGUgPGJyPg0KJmd0OyBkaWZm ZXJlbmNlIG1heSBoYXMgaW1wYWN0IG9uIHNlc3Npb24gc3RhdGUuPGJyPg0KJmd0OyA8YnI+DQom Z3Q7IEkgaGF2ZSBhIHJhdyB3YXk6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFzIGl0IGlzIGJlY2F1 c2Ugb2YgdGhlIGluY29uc2lzdGVuY3kgb2YgcmVmcmVzaGVkIHRhcmdldCBhbmQgPGJyPg0KJmd0 OyBkaXNwYXRjaGluZyBydWxlIGJ5IFZpYSwgYW5kIFVBUyBoYXMgZ2V0IHRoZSByZWZyZXNoZWQg dGFyZ2V0IGJ5IFVQREFURSwNCjxicj4NCiZndDsgc28gdGhlIFVBUyBjYW4gbW9kaWZ5IHRoZSBs YXN0IFZpYSBoZWFkZXIod2hpY2ggaXMgZm9ybWVkIGJ5IFVBQyA8YnI+DQomZ3Q7IGFjY29yZGlu ZyB0byBpdHMgYWRkcmVzcykgdG8gYmUgdGhlIG5ldyBhZGRyZXNzIG9mIFVBQy4gKkJ1dCBJIGFt DQpub3QgPGJyPg0KJmd0OyBzdXJlIGlzIHRoZXJlIGFueSBwcm94eSB3aWxsIGNoZWNrIHRoZSBW aWEgaGVhZGVycy48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhlIG1lbnRpb25lZCBjYXNlIGlzIHRo YXQgdGhlIHJlc3BvbnNlIGlzIGFmdGVyIHRoZSBVUERBVEUoYnkgVUFTJ3MNCjxicj4NCiZndDsg dmlldykuIElmIHRoZSBmaW5hbCByZXNwb25zZSBpcyBiZWZvcmUgdGhlIFVEUEFURShieSBVQVMn cyB2aWV3KTo8YnI+DQomZ3Q7IDJ4eCBjYXNlOiBUaGUgcmV0cmFuc21pc3Npb24gb2YgMnh4IHNo b3VsZCB1c2UgbW9kaWZpZWQgVmlhIGhlYWRlci48YnI+DQomZ3Q7IDR4eCBjYXNlOiA0eHggaXMg aG9wLWJ5LWhvcCwgc28gdGhlIDR4eCB3aWxsIGJlIHNlbnQgdG8gdGhlIG9sZCBhZGRyZXNzDQo8 YnI+DQomZ3Q7IG9mIFVBQy4gU28sIGl0IGNhbiBiZSBtaXNzZWQuIFRoZSBVQUMncyB0aW1lciBm b3IgZmluYWwgcmVzcG9uc2Ugd2lsbA0KPGJyPg0KJmd0OyBmaXJlKGFzIDQwOCksIGFuZCBpdCBj YW4gc2VuZCBhIG5ldyBSZS1JTlZJVEUgb3IganVzdCB0ZXJtaW5hdGUgdGhlDQo8YnI+DQomZ3Q7 IHNlc3Npb24uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rcy48YnI+DQomZ3Q7IDxicj4NCiZn dDsgR2FvPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAqT0tVTVVS QSBTaGluamkgJmx0O3NoaW5Ac29mdGZyb250LmNvLmpwJmd0Oyo8YnI+DQomZ3Q7IDxicj4NCiZn dDsgMjAwOS0wNy0xNiAxNDozODxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsg ytW8/sjLPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwO1NJUENPUkUNCiZsdDtzaXBjb3JlQGlldGYub3JnJmd0Ozxi cj4NCiZndDsgs63LzTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtnYW8ueWFuZzJAenRlLmNvbS5jbiwNClBhdWwg S3l6aXZhdCAmbHQ7cGt5eml2YXRAY2lzY28uY29tJmd0Ozxicj4NCiZndDsg1vfM4jxicj4NCiZn dDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDt0YXJnZXQNCnJlZnJlc2ggZHVyaW5nIGFuIGluY29tcGxldGUgcmVJTlZJVEUtdHJh bnNhY3Rpb248YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsg PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEhp IEdhbyw8YnI+DQomZ3Q7IDxicj4NCiZndDsgSSB0aGluayB0aGlzIGlzc3VlIG1heSBiZSBkaXNj dXNzZWQgcHJldmlvdXNseS48YnI+DQomZ3Q7IDxicj4NCiZndDsgRHVyaW5nIGFuIGluY29tcGxl dGUgcmVJTlZJVEUtdHJhbnNhY3Rpb24sIGlmIFVBQydzIElQIGFkZHJlc3M8YnI+DQomZ3Q7IGlz IGNoYW5nZWQsPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFVBQyBiZWhhdmlvciB3aGVuIHNlbmRpbmcg dGhlIFVQREFURSByZXF1ZXN0IHRvIHJlZnJlc2ggbG9jYWwgdGFyZ2V0PGJyPg0KJmd0OyAmbmJz cDtNQVkgc2VuZCBDQU5DRUw8YnI+DQomZ3Q7ICZuYnNwO0RPIE5PVCBleHBlY3QgNHh4IHJlc3Bv bmNlIGZvciByZUlOVklURTxicj4NCiZndDsgJm5ic3A7SWYgbmVjZXNzYXJ5LCBzZW5kIG5ldyBy ZUlOVklURSAoaW4gdGhlIHNhbWUgZGlhbG9nKTxicj4NCiZndDsgPGJyPg0KJmd0OyBVQVMgYmVo YXZpb3Igd2hlbiByZWNlaXZpbmcgdGhlIFVQREFURSByZXF1ZXN0IHRvIHJlZnJlc2ggcmVtb3Rl IHRhcmdldDxicj4NCiZndDsgJm5ic3A7SWYgdGFjdGZ1bCwgTUFZIHNlbmQgNHh4IHJlc3BvbmNl IGZvciByZUlOVklURTxicj4NCiZndDsgJm5ic3A7RE8gZXhwZWN0IENBTkNFTDxicj4NCiZndDsg PGJyPg0KJmd0OyBTZXJ2ZXIgdHJhbnNhY3Rpb24gKG5lYXJlc3QgVUFDKTxicj4NCiZndDsgJm5i c3A7SWYgdmVyeSB2ZXJ5IHRhY3RmdWwsIHdvdWxkIGZvcndhcmQgNHh4IHRvIG5ldyBJUCBhZGRy ZXNzLjxicj4NCiZndDsgJm5ic3A7YnV0IEknbSBub3Qgc3VyZSBpdCBjYXVzZSBubyBwcm9ibGVt Ljxicj4NCiZndDsgPGJyPg0KJmd0OyBSZWdhcmRzLDxicj4NCiZndDsgU2hpbmppPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7SGks PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7VGhlbiwgaXQgc2VlbXMg YSByZWFsIHByb2JsZW0gZm9yIGluY29uc2lzdGVuY3kgb2YgcmVmcmVzaGVkDQp0YXJnZXQgYW5k PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7ZGlzcGF0Y2hpbmcgcnVsZSBieSBWaWEuPGJyPg0KJmd0OyAm bmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7UGF1bCBoYXMgZ2l2ZW4gb3V0IHNvbWUgQkNQ IHdheS4gRG8geW91IGhhdmUgc29tZSB0aG91Z2h0DQphYm91dCBzb2x1dGlvbnM8YnI+DQomZ3Q7 ICZuYnNwOyZndDtpbiB0aGVvcnk/PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJz cDsmZ3Q7VGhhbmtzLjxicj4NCiZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0O0dh bzxicj4NCiZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0Oz09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IFppcCAmbmJzcDsgJm5i c3A7OiAyMTAwMTI8YnI+DQomZ3Q7ICZuYnNwOyZndDsgVGVsICZuYnNwOyAmbmJzcDs6IDg3MjEx PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IFRlbDIgJm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+ DQomZ3Q7ICZuYnNwOyZndDsgZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQomZ3Q7 ICZuYnNwOyZndDs9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCiZndDsg Jm5ic3A7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0O09LVU1VUkEgU2hpbmppICZsdDtzaGluQHNv ZnRmcm9udC5jby5qcCZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsyMDA5LTA3LTE2IDEyOjI5PGJy Pg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7SGksIEdhbzxicj4NCiZndDsg Jm5ic3A7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0O0kgc2VlbSB5b3UgZG9uJ3Qgc3RpbGwgY2F0 Y2ggaGlzIHBvaW50LiBIZSBoYXMgYmVlbiB0YWxraW5nDQphYm91dDxicj4NCiZndDsgJm5ic3A7 Jmd0O2EgVmlhIGhlYWRlciBvZiBub3QgYSBwcm94eSBidXQgYW4gVUFDLiB0aGUgc2VydmVyIHRy YW5zYWN0aW9uDQpzZW5kPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7YSByZXNwb25jZSBvZiB0aGUgcmVJ TlZJVEUgdG8gdGhlIG9sZCBhZGRyZXNzIG9mIGFuIFVBQywNCmV2ZW4gaWY8YnI+DQomZ3Q7ICZu YnNwOyZndDtVUERBVEUgcmVxdWVzdCBoYWQgcmVmcmVzaGVkIFVBQydzIGxvY2FsIHRhcmdldChp ZS4gSVAgYWRkcmVzcykuPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7 SXQgaXMgYSBiYXNpYyBydWxlIGRlc2NyaWJlZCBpbiBSRkMzMjYxLiBSRkMzMzExIGRvZXMgTk9U DQpjaGFuZ2UgaXQuPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7UmVn YXJkcyw8YnI+DQomZ3Q7ICZuYnNwOyZndDtTaGluamk8YnI+DQomZ3Q7ICZuYnNwOyZndDs8YnI+ DQomZ3Q7ICZuYnNwOyZndDtnYW8ueWFuZzJAenRlLmNvbS5jbjxicj4NCiZndDsgJm5ic3A7Jmd0 OyZndDtIaSw8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0 O0kgY2F0Y2ggeW91ciBwb2ludCBub3cuIFlvdSBtZWFuIHRoYXQgdGhlIG1pZGRsZS1ib3gsDQpz dWNoIGFzIHByb3h5LDxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDthZGRpbmcgVmlhIGluIHRoZSBJ TlZJVEUuIFRoZW4gdGhlIHByb3h5IGlzIG5vdyBub24tZnVuY3Rpb25hbCwNCjxicj4NCiZndDsg bWFraW5nIHRoZTxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDtyZXNwb25zZSB1bnJlYWNoYWJsZS48 YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0O0J1dCBJIHRo aW5rIHRoZSBzb2x1dGlvbnMgc2hvdWxkIG5vdCBiZSBpbiBwcm90b2NvbA0KbGV2ZWwuIFRoZSBz b2x1dGlvbnM8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Y2FuIGJlOjxicj4NCiZndDsgJm5ic3A7 Jmd0OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7MS4gRmF1bHQgdG9sZXJhbmNlLiAoaWUu IGNyYXNoaW5nIG9mIFAtQ1NDRi9TLUNTQ0YpPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0Ozxicj4N CiZndDsgJm5ic3A7Jmd0OyZndDsyLiBJc3N1ZSBuZXcgSU5WSVRFIHJlcGxhY2UgdGhlIG9sZCBv bmUuIChpZS4gY2hhbmdpbmcNClAtQ1NDRik8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7PGJyPg0K Jmd0OyAmbmJzcDsmZ3Q7Jmd0O1RoYW5rcy48YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7PGJyPg0K Jmd0OyAmbmJzcDsmZ3Q7Jmd0O0dhbzxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDs8YnI+DQomZ3Q7 ICZuYnNwOyZndDsmZ3Q7PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQom Z3Q7ICZuYnNwOyZndDsmZ3Q7IFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+DQomZ3Q7ICZu YnNwOyZndDsmZ3Q7IFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiZndDsgJm5ic3A7Jmd0 OyZndDsgVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiZndDsgJm5ic3A7Jmd0 OyZndDsgZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248YnI+DQomZ3Q7ICZuYnNwOyZndDsm Z3Q7PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQomZ3Q7ICZuYnNwOyZn dDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDs8 YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7UGF1bCBLeXppdmF0ICZsdDtwa3l6aXZhdEBjaXNjby5j b20mZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDtn YW8ueWFuZzJAenRlLmNvbS5jbiB3cm90ZTo8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7PGJyPg0K Jmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsgSWYgfGhlIFVBQyBkZWNpZGVzIHRvIGZpeCB0aGlzIGJ5 IHNlbmRpbmcgYW4gVVBEQVRFDQpiZWZvcmUgPGJyPg0KJmd0OyBjb21wbGV0aW9uIG9mPGJyPg0K Jmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsgdGhlIHJlSU5WSVRFLCB0aGVuIGl0IG1heSBzdWNjZWVk IGluIGdldHRpbmcgdGhlDQpyZW1vdGUgdGFyZ2V0IGNoYW5nZWQ8YnI+DQomZ3Q7ICZuYnNwOyZn dDsmZ3Q7Jmd0OyBhdCB0aGUgVUFTLiBCdXQgdGhlICpVQVMgaXMgc3RpbGwgb2JsaWdhdGVkIHRv DQpzZW5kIHRoZSByZW1haW5pbmc8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyByZXNwb25z ZXMgdG8gdGhlIGFkZHJlc3MgaW4gdGhlIFZpYSwgd2hpY2ggaXMgdGhlDQpvbGQgYWRkcmVzcy4g Kjxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZn dDsgW0dhb10gSXQgaXMgaW4gUkZDMzI2MSwgYnV0IFJGQzMzMTEgaGFzIHRoZSBkZWZpbml0aW9u DQphczo8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyZn dDsmZ3Q7IGZyb20gUkZDMzMxMTo8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyBVUERBVEUg aXMgYSB0YXJnZXQgcmVmcmVzaCByZXF1ZXN0LiBBcyBzcGVjaWZpZWQNCmluIFJGQyAzMjYxIFsx XSw8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7dGhpcyBtZWFucyB0 aGF0IGl0IGNhbiB1cGRhdGUgdGhlDQpyZW1vdGUgdGFyZ2V0IG9mIGEgZGlhbG9nLiBJZiBhIFVB PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwO3VzZXMgYW4gVVBEQVRF IHJlcXVlc3Qgb3IgcmVzcG9uc2UNCnRvIG1vZGlmeSB0aGUgcmVtb3RlIHRhcmdldCB3aGlsZTxi cj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsqYW4gSU5WSVRFIHRyYW5z YWN0aW9uIGlzIGluIHByb2dyZXNzKiwNCmFuZCBpdCBpcyBhIFVBUyBmb3IgdGhhdCA8YnI+DQom Z3Q7IElOVklURTxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDt0cmFu c2FjdGlvbiwgaXQgKk1VU1QgcGxhY2UgdGhlIHNhbWUNCnZhbHVlIGludG8gdGhlIENvbnRhY3Qg aGVhZGVyKjxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7ICogJm5ic3A7IGZpZWxkIG9mIHRo ZSAyeHggdG8gdGhlIElOVklURSB0aGF0IGl0DQpwbGFjZWQgaW50byB0aGUgVVBEQVRFIDxicj4N CiZndDsgcmVxdWVzdCo8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyAqICZuYnNwOyBvciBy ZXNwb25zZSouPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZn dDsmZ3Q7Jmd0OyBTbywgaXQgc2hvdWxkIGJlIHRoZSBuZXcgYWRkcmVzcyBoZXJlLjxicj4NCiZn dDsgJm5ic3A7Jmd0OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7WW91IG1pc3MgbXkgcG9p bnQuPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDtJdHMg bm90IGFib3V0IHRoZSBDb250YWN0IHBsYWNlZCAqaW4qIHRoZSAyeHggcmVzcG9uc2UuPGJyPg0K Jmd0OyAmbmJzcDsmZ3Q7Jmd0O0l0cyBhYm91dCB0aGUgYWRkcmVzcyB0byB3aGljaCB0aGUgcmVz cG9uc2UgaXMgZGVsaXZlcmVkLjxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDtUaGF0IGlzIGRpY3Rh dGVkIGJ5IHRoZSBWaWEgaGVhZGVycyBpbiB0aGUgSU5WSVRFIHJlcXVlc3QuPGJyPg0KJmd0OyAm bmJzcDsmZ3Q7Jmd0O1Rob3NlIGFyZSBub3QgYWZmZWN0ZWQgYnkgdGhlIHRhcmdldCByZWZyZXNo Ljxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNClRoYW5r cyw8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNClBhdWw8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KJmd0OyBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90 aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMNCm1haWwgaXMgc29sZWx5IHBy b3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0 aW9uDQppcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRl ZCB0byBtYWludGFpbiBzZWNyZWN5DQphbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2Ug dGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0bw0Kb3RoZXJzLjxicj4NCiZndDsg VGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVu dGlhbCBhbmQNCmludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBv ciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZQ0KYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZl ZCB0aGlzIGVtYWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3INCm9mIHRo ZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ug b2YgdGhlIGluZGl2aWR1YWwNCnNlbmRlci48YnI+DQomZ3Q7IFRoaXMgbWVzc2FnZSBoYXMgYmVl biBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0NCnN5c3RlbS48 YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4N CnNpcGNvcmUgbWFpbGluZyBsaXN0PGJyPg0Kc2lwY29yZUBpZXRmLm9yZzxicj4NCmh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZTxicj4NCjwvdHQ+PC9mb250Pg0K PGJyPg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNw O05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2lu Jm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5i c3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlz Jm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4m bmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGln YXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJl Jm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZu YnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3Rv Jm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7Zmls ZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZp ZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7 dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJz cDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVz c2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZu YnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNw O3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7 QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNz YWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwm bmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtz Y2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZu YnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 001995B7482575F6_=-- From ietf.hanserik@gmail.com Fri Jul 17 00:40:16 2009 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 922773A6A15 for ; Fri, 17 Jul 2009 00:40:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.523 X-Spam-Level: X-Spam-Status: No, score=-2.523 tagged_above=-999 required=5 tests=[AWL=0.075, 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 3j9UTK54tb-Z for ; Fri, 17 Jul 2009 00:40:15 -0700 (PDT) Received: from ey-out-2122.google.com (ey-out-2122.google.com [74.125.78.26]) by core3.amsl.com (Postfix) with ESMTP id AB0313A69ED for ; Fri, 17 Jul 2009 00:40:14 -0700 (PDT) Received: by ey-out-2122.google.com with SMTP id 22so168877eye.31 for ; Fri, 17 Jul 2009 00:40:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=nbxPi/V3vY7thFRzAdZQhcMrV7yeV6G7YuBufpeslEE=; b=bN8N2EsqjId/RSFO5s5MGTTBdpl4uNA+cTGeRtZARUaHs/T0Bdv4X4k9Q+hk+cNH2h iZI+wnGVn5/+KgSut2FrqkpgZA6jZ2g3Yj0DRHsSv2b6S6qrqzpEZO3xahBcQ0vNqtdH SpTj4YHGjMGlzFdWIUC9pWpV2H3AWVvJu8Rv0= 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=IrP9NHQO8R3rfT7zBYi1UoC7y4XhUXSH7OxD26GzbvPiP0jwUby1fGIjedvtUEW0nX 3/YbDPzWYT5rVYx/bTb2AWIBLt8laoSXyA9gKJ6lezmVks1BVjVhD373blAo45Jb/dRS AOmyDkRLq6PNGER9n8TzK25vUYFnAojB2LpZ8= MIME-Version: 1.0 Received: by 10.210.62.3 with SMTP id k3mr879141eba.96.1247816444968; Fri, 17 Jul 2009 00:40:44 -0700 (PDT) In-Reply-To: <4A5FDC3E.2000101@joelhalpern.com> References: <4A5FDC3E.2000101@joelhalpern.com> Date: Fri, 17 Jul 2009 09:40:44 +0200 Message-ID: <9ae56b1e0907170040l5287344fy96103bfc8a11c32@mail.gmail.com> From: Hans Erik van Elburg To: "Joel M. Halpern" Content-Type: multipart/alternative; boundary=0015174bf1f0f28803046ee1e7a1 Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 17 Jul 2009 07:40:16 -0000 --0015174bf1f0f28803046ee1e7a1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit sounds reasonable. /Hans Erik van Elburg On Fri, Jul 17, 2009 at 4:04 AM, Joel M. Halpern wrote: > Actually, I think it (the domain that was on the right hand side of the > R-URI, and that is performing the ENUM lookup) is "the right" domain. > Of course, this turns on deciding what a SIP URI with a user part that > happens to be digits is. > As far as I can tell, it ought to be a SIP UIR. > Therefore, if a proxy in domain sp.com receives a SIP R-URI of > sip:+123456789@sp.com ;user=phone (with the > right number of digits, sorry), then sp.com is the responsible domain. > The fact that the proxy does not actually care if the target is within > sp.com, and will use ENUM, and send the call on wherever ENUM tells it > does not change the fact that the R-URI indicated his domain, the proxy > understand the domain, and understand the rules of the domain. That domain > just has a lot of implicit registration, and an ENUM based location service. > So be it. > > (Now, at least in my opinion, if any proxy outside of sp.com tries that > trick it is just plain wrong. But that is, I think, a different > discussion.) > > Yours, > Joel > > Francois Audet wrote: > >> >> Say I call sip:+1234567890@sp.com ;user=phone. >>>> My proxy is "sp.com", >>>> right? >>>> Then sp.net does ENUM query. >>>> >>> If we assume that ENUM qualifies as a location service (and I am now >>> convinced that it does), then this URI *is* an AOR in sp.com. >>> >> >> No, because it's not the right domain. It's doing the ENUM on a phone >> number. So it really has nothing to do with a SIP scheme (a condition >> for AOR, remember?). >> >> And in fact, it goes to example.com, not sp.com >> >> _______________________________________________ >> 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 > --0015174bf1f0f28803046ee1e7a1 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable sounds reasonable.

/Hans Erik van Elburg


On Fri, Jul 17, 2009 at 4:04 AM, Joel M.= Halpern <jmh@j= oelhalpern.com> wrote:
Actually, I think it =A0(the domain that was on the right hand side of the = R-URI, and that is performing the ENUM lookup) is "the right" dom= ain.
Of course, this turns on deciding what a SIP URI with a user part that happ= ens to be digits is.
As far as I can tell, it ought to be a SIP UIR.
Therefore, if a proxy in domain sp.com receives a SIP R-URI of sip:+123456789@sp.com;user=3Dphone (with the ri= ght number of digits, sorry), then sp.com is the responsible domain. =A0The fact that the proxy does n= ot actually care if the target is within sp.com, and will use ENUM, and send the call on wherever EN= UM tells it does not change the fact that the R-URI indicated his domain, t= he proxy understand the domain, and understand the rules of the domain. =A0= That domain just has a lot of implicit registration, and an ENUM based loca= tion service. =A0So be it.

(Now, at least in my opinion, if any proxy outside of sp.com tries that trick it is just plain wrong. = =A0But that is, I think, a different discussion.)

Yours,
Joel

Francois Audet wrote:

Say I call = sip:+1234567890@sp.com;user=3Dphone. My proxy is "sp.com",
right?
=A0Then sp.net does ENUM qu= ery.
If we assume that ENUM qualifies as a location service (and I am now
convinced that it does), then this URI *is* an AOR in sp.com.

No, because it's not the right domain. It's doing the ENUM on a pho= ne
number. So it really has nothing to do with a SIP scheme (a condition
for AOR, remember?).

And in fact, it goes to ex= ample.com, not sp.com
_______________________________________________
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

--0015174bf1f0f28803046ee1e7a1-- From shin@softfront.co.jp Fri Jul 17 01:36:28 2009 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 4CBF83A6A11 for ; Fri, 17 Jul 2009 01:36:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.151 X-Spam-Level: **** X-Spam-Status: No, score=4.151 tagged_above=-999 required=5 tests=[AWL=-0.982, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_42=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_82=0.6, J_CHICKENPOX_92=0.6, RELAY_IS_221=2.222, UNPARSEABLE_RELAY=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 BJ+rh4kad4rR for ; Fri, 17 Jul 2009 01:36:27 -0700 (PDT) Received: from mail2.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with SMTP id F1F3B3A696D for ; Fri, 17 Jul 2009 01:36:26 -0700 (PDT) Received: from softfront.co.jp by mail2.softfront.co.jp id AA00632 ; 17 Jul 2009 17:36:56 +0900 From: OKUMURA Shinji To: SIPCORE Date: Fri, 17 Jul 2009 17:36:53 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.19 (WinNT,501) In-Reply-To: <4A5FB302.7080102@cisco.com> References: <4A5FB302.7080102@cisco.com> Message-Id: Cc: gao.yang2@zte.com.cn Subject: Re: [sipcore] target refresh during an incomplete reINVITE-transaction 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, 17 Jul 2009 08:36:28 -0000 Hi Paul, Paul Kyzivat >IMO it is a bad idea, dangerous precedent, and not very functional, to >have the UAS modifying the Via when receiving a target refresh. > >This is way out of line. Also, its not that unusual for middleboxes to >obscure Vias, in which case the UAS won't even find the entry that needs >to be modified. > >The use case is an infrequent one, though it could be important. I >spelled out how this could be handled without fixing the Via, and that >is all consistent with current rules. The only thing that is required is >that the target refresh by the UPDATE must not be rolled back if the >enclosing INVITE fails. IMO that is reasonable, even if it is a special >case. I agree. And I have a battery of question regarding to this procedure. Q1. MUST no session parameter(ie. O/A state) that belong to the UPDATE transaction be also rolled back? (I think no-rollback.) Q2. If no-rollback, then in precondition case, IS it necessary that UAC send new reINVITE with a precondition to revert to the pre-INVITE state? (I'm confused.) Q3. MUST no session parameter(ie. O/A state) that belong to 1st reINVITE and PRACK transaction be also rolled back? (I think rollback probably. it cause no problem.) Q4. Do a reINVITE request and it's reliable provisional responce refresh a remote target? (I think NO, under the current RFCs.) I want to hear expert's opinion and wish the draft to give the answer. If these already discussed previously, please provide me the pointer to that discussion. Regards, Shinji > Thanks, > Paul > >gao.yang2@zte.com.cn wrote: >> >> Hi Shinji, >> >> IMO, it is not elegant solution, as: >> 1. This is a additional requirement for UA and proxy. >> 2. Further the response(of INVITE/Re-INVITE) can be 4xx or 2xx, and the >> difference may has impact on session state. >> >> I have a raw way: >> >> As it is because of the inconsistency of refreshed target and >> dispatching rule by Via, and UAS has get the refreshed target by UPDATE, >> so the UAS can modify the last Via header(which is formed by UAC >> according to its address) to be the new address of UAC. *But I am not >> sure is there any proxy will check the Via headers.* >> >> The mentioned case is that the response is after the UPDATE(by UAS's >> view). If the final response is before the UDPATE(by UAS's view): >> 2xx case: The retransmission of 2xx should use modified Via header. >> 4xx case: 4xx is hop-by-hop, so the 4xx will be sent to the old address >> of UAC. So, it can be missed. The UAC's timer for final response will >> fire(as 408), and it can send a new Re-INVITE or just terminate the >> session. >> >> Thanks. >> >> Gao >> >> *OKUMURA Shinji * >> Hi Gao, >> >> I think this issue may be discussed previously. >> >> During an incomplete reINVITE-transaction, if UAC's IP address >> is changed, >> >> UAC behavior when sending the UPDATE request to refresh local target >> MAY send CANCEL >> DO NOT expect 4xx responce for reINVITE >> If necessary, send new reINVITE (in the same dialog) >> >> UAS behavior when receiving the UPDATE request to refresh remote target >> If tactful, MAY send 4xx responce for reINVITE >> DO expect CANCEL >> >> Server transaction (nearest UAC) >> If very very tactful, would forward 4xx to new IP address. >> but I'm not sure it cause no problem. >> >> Regards, >> Shinji >> >> gao.yang2@zte.com.cn >> >Hi, >> > >> >Then, it seems a real problem for inconsistency of refreshed target and >> >dispatching rule by Via. >> > >> >Paul has given out some BCP way. Do you have some thought about solutions >> >in theory? >> > >> >Thanks. >> > >> >Gao >> > >> >=================================== >> > Zip : 210012 >> > Tel : 87211 >> > Tel2 :(+86)-025-52877211 >> > e_mail : gao.yang2@zte.com.cn >> >=================================== >> > >> >OKUMURA Shinji >> >2009-07-16 12:29 >> > >> >Hi, Gao >> > >> >I seem you don't still catch his point. He has been talking about >> >a Via header of not a proxy but an UAC. the server transaction send >> >a responce of the reINVITE to the old address of an UAC, even if >> >UPDATE request had refreshed UAC's local target(ie. IP address). >> > >> >It is a basic rule described in RFC3261. RFC3311 does NOT change it. >> > >> >Regards, >> >Shinji >> > >> >gao.yang2@zte.com.cn >> >>Hi, >> >> >> >>I catch your point now. You mean that the middle-box, such as proxy, >> >>adding Via in the INVITE. Then the proxy is now non-functional, making the >> >>response unreachable. >> >> >> >>But I think the solutions should not be in protocol level. The solutions >> >>can be: >> >> >> >>1. Fault tolerance. (ie. crashing of P-CSCF/S-CSCF) >> >> >> >>2. Issue new INVITE replace the old one. (ie. changing P-CSCF) >> >> >> >>Thanks. >> >> >> >>Gao >> >> >> >>=================================== >> >> Zip : 210012 >> >> Tel : 87211 >> >> Tel2 :(+86)-025-52877211 >> >> e_mail : gao.yang2@zte.com.cn >> >>=================================== >> >> >> >> >> >> >> >>Paul Kyzivat >> >> >> >>gao.yang2@zte.com.cn wrote: >> >> >> >>> If |he UAC decides to fix this by sending an UPDATE before completion of >> >>> the reINVITE, then it may succeed in getting the remote target changed >> >>> at the UAS. But the *UAS is still obligated to send the remaining >> >>> responses to the address in the Via, which is the old address. * >> >>> >> >>> [Gao] It is in RFC3261, but RFC3311 has the definition as: >> >>> >> >>> from RFC3311: >> >>> UPDATE is a target refresh request. As specified in RFC 3261 [1], >> >>> this means that it can update the remote target of a dialog. If a UA >> >>> uses an UPDATE request or response to modify the remote target while >> >>> *an INVITE transaction is in progress*, and it is a UAS for that INVITE >> >>> transaction, it *MUST place the same value into the Contact header* >> >>> * field of the 2xx to the INVITE that it placed into the UPDATE request* >> >>> * or response*. >> >>> >> >>> So, it should be the new address here. >> >> >> >>You miss my point. >> >> >> >>Its not about the Contact placed *in* the 2xx response. >> >>Its about the address to which the response is delivered. >> >>That is dictated by the Via headers in the INVITE request. >> >>Those are not affected by the target refresh. >> >> >> >> Thanks, >> >> Paul From john.elwell@siemens-enterprise.com Fri Jul 17 03:43:35 2009 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 364FD3A6BE0 for ; Fri, 17 Jul 2009 03:43:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 vkSnr507FIdE for ; Fri, 17 Jul 2009 03:43:34 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 8A10F3A6B05 for ; Fri, 17 Jul 2009 03:43:20 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KMX0072L9SYM2@siemenscomms.co.uk> for sipcore@ietf.org; Fri, 17 Jul 2009 11:43:46 +0100 (BST) Date: Fri, 17 Jul 2009 11:43:48 +0100 From: "Elwell, John" In-reply-to: <1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com> To: Francois Audet , Hans Erik van Elburg , Paul Kyzivat Message-id: <0D5F89FAC29E2C41B98A6A762007F5D002265A67@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoF6CVRUPlMKkb7SrWHqBtgx6wCgwAAvgVQABgn/cAAH8aPEA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com> <4A5E83CB.4090701@cisco.com> <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com> Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 17 Jul 2009 10:43:35 -0000 =20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: 16 July 2009 21:38 > To: Elwell, John; Hans Erik van Elburg; Paul Kyzivat > Cc: SIPCORE; Hadriel Kaplan > Subject: RE: [sipcore] rfc4244bis: what is an AoR? >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org=20 > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: Thursday, July 16, 2009 01:04 > > To: Hans Erik van Elburg; Paul Kyzivat > > Cc: SIPCORE; Hadriel Kaplan > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > >=20 > > From that definition, I believe every entry in H-I except the=20 > > last (i.e., the Request-URI received by the UAS) would be an=20 > > AOR. If not, the request would not have got this far, because=20 > > it would not have found a domain that could route it. >=20 > No, this is false: not all entries will be aors. >=20 > For example, I call you, my request gets routed to=20 > elwell@10.10.15.12 (your > registered contact). You send a 302 to john@example.com, and=20 > it recurses all the way > to john@192.168.15.12 (another registered contact). >=20 > In this case, you'll have an entry in the middle=20 > (elwell@10.10.15.12) that is not=20 > an AOR. [JRE] OK, I had forgotten about redirection. >=20 > > Is my understanding correct? If so, what is the point of the "AOR" > > indicator in H-I, if all but the last are marked "AOR"? >=20 > The point of AOR is marking useful entries differently than pointless > ones. >=20 > There are lots of other examples. You have to remember that=20 > in H-I, normally > all proxies are supposed to add entries even if they don't=20 > own the domain, > and even if they don't change anything. >=20 > - I send a request to sip:elwell@siemens-enterprise.com from=20 > sip:audet@nortel.com. > My proxy adds the entry sip:elwell@siemens-enterprise.com,=20 > but it doesn't mark it > as AOR because it doesn't own it. It will only be marked as=20 > AOR by YOUR proxy when > it reaches it. [JRE] Well, the point is it gets marked as AOR at some point, so the fact that not all entries mark it as AOR is irrelevant. >=20 > - Strict-routing. None of the strict-routing proxy addresses=20 > would be marked as AOR. >=20 > - Manual digit manipulation done by outgoing proxies (i.e.,=20 > sip:60114901234567@nortel.com > will not be marked as AOR). When it ultimately gets mapped=20 > to sip:+4901234567@siemens- > enterprise.com;user=3Dphone) by YOUR proxy (as per first=20 > bullet), then it gets marked. >=20 > The AOR marking allows to eliminate a lot of redundant (in=20 > best case) or innacurate entries=20 > and facilitate parsing of H-I by UAS. [JRE] I appreciate the intent, but I am just concern about the looseness of the definition. John > =20 >=20 From john.elwell@siemens-enterprise.com Fri Jul 17 03:46:24 2009 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 68D5E3A6855 for ; Fri, 17 Jul 2009 03:46:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.585 X-Spam-Level: X-Spam-Status: No, score=-2.585 tagged_above=-999 required=5 tests=[AWL=0.014, 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 IV61fVQjtvwl for ; Fri, 17 Jul 2009 03:46:23 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 46CE83A6A6A for ; Fri, 17 Jul 2009 03:46:22 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KMX0078R9Y3M2@siemenscomms.co.uk> for sipcore@ietf.org; Fri, 17 Jul 2009 11:46:51 +0100 (BST) Date: Fri, 17 Jul 2009 11:46:53 +0100 From: "Elwell, John" In-reply-to: <1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com> To: Francois Audet , Hans Erik van Elburg , Paul Kyzivat Message-id: <0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoF6CVRUPlMKkb7SrWHqBtgx6wCgwAAvgVQABgn/cAAH/S/oA== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com> <4A5E83CB.4090701@cisco.com> <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com> Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 17 Jul 2009 10:46:24 -0000 =20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: 16 July 2009 21:38 > To: Elwell, John; Hans Erik van Elburg; Paul Kyzivat > Cc: SIPCORE; Hadriel Kaplan > Subject: RE: [sipcore] rfc4244bis: what is an AoR? >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org=20 > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Elwell, John > > Sent: Thursday, July 16, 2009 01:04 > > To: Hans Erik van Elburg; Paul Kyzivat > > Cc: SIPCORE; Hadriel Kaplan > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > >=20 > > From that definition, I believe every entry in H-I except the=20 > > last (i.e., the Request-URI received by the UAS) would be an=20 > > AOR. If not, the request would not have got this far, because=20 > > it would not have found a domain that could route it. >=20 > No, this is false: not all entries will be aors. >=20 > For example, I call you, my request gets routed to=20 > elwell@10.10.15.12 (your > registered contact). You send a 302 to john@example.com, and=20 > it recurses all the way > to john@192.168.15.12 (another registered contact). >=20 > In this case, you'll have an entry in the middle=20 > (elwell@10.10.15.12) that is not=20 > an AOR. [JRE] Thinking about this further, I believe this DOES fit the definition for AOR. In other words, my UAS is responsible for 10.10.15.12 and its "location service" tells it that the contact for elwell is john@192.168.15.12. John >=20 > > Is my understanding correct? If so, what is the point of the "AOR" > > indicator in H-I, if all but the last are marked "AOR"? >=20 > The point of AOR is marking useful entries differently than pointless > ones. >=20 > There are lots of other examples. You have to remember that=20 > in H-I, normally > all proxies are supposed to add entries even if they don't=20 > own the domain, > and even if they don't change anything. >=20 > - I send a request to sip:elwell@siemens-enterprise.com from=20 > sip:audet@nortel.com. > My proxy adds the entry sip:elwell@siemens-enterprise.com,=20 > but it doesn't mark it > as AOR because it doesn't own it. It will only be marked as=20 > AOR by YOUR proxy when > it reaches it. >=20 > - Strict-routing. None of the strict-routing proxy addresses=20 > would be marked as AOR. >=20 > - Manual digit manipulation done by outgoing proxies (i.e.,=20 > sip:60114901234567@nortel.com > will not be marked as AOR). When it ultimately gets mapped=20 > to sip:+4901234567@siemens- > enterprise.com;user=3Dphone) by YOUR proxy (as per first=20 > bullet), then it gets marked. >=20 > The AOR marking allows to eliminate a lot of redundant (in=20 > best case) or innacurate entries=20 > and facilitate parsing of H-I by UAS. > =20 >=20 From pkyzivat@cisco.com Fri Jul 17 06:00:19 2009 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 B08AC28C23C for ; Fri, 17 Jul 2009 06:00:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.367 X-Spam-Level: X-Spam-Status: No, score=-6.367 tagged_above=-999 required=5 tests=[AWL=0.232, 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 jMzYXUll01xL for ; Fri, 17 Jul 2009 06:00:18 -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 8678D3A6BC3 for ; Fri, 17 Jul 2009 06:00:18 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHISYEpAZnme/2dsb2JhbAC3GYgjkHEFhA0 X-IronPort-AV: E=Sophos;i="4.42,417,1243814400"; d="scan'208";a="50743453" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 17 Jul 2009 12:58:29 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6HCwTRg016652; Fri, 17 Jul 2009 08:58:29 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6HCwTeL004655; Fri, 17 Jul 2009 12:58:29 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 08:58:29 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 08:58:28 -0400 Message-ID: <4A607574.8040604@cisco.com> Date: Fri, 17 Jul 2009 08:58:28 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Francois Audet References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2009 12:58:28.0595 (UTC) FILETIME=[4785FC30:01CA06DE] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1105; t=1247835509; x=1248699509; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20rfc4244bis=3A=20what=20is=2 0an=20AoR? |Sender:=20 |To:=20Francois=20Audet=20; bh=S2c3tBjI7b/HTQRk3LaDs0d0/LEl6HRRi90HUrHKUME=; b=Nu/iFJhKUo9vLdG/SyylXSeVJyKHycrU8lQc07qBdO7x5OHYPZSqDPvCc/ GhBPCoa/+5G5AYzi2/jUkpY7YtDg4KzuZVM23IC/M3ZfdJiV3OE3/IS0Jj1N f50XcYtGEn; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 17 Jul 2009 13:00:19 -0000 Francois Audet wrote: > >>> Say I call sip:+1234567890@sp.com;user=phone. My proxy is "sp.com", >>> right? >>> >>> Then sp.net does ENUM query. >> If we assume that ENUM qualifies as a location service (and I am now >> convinced that it does), then this URI *is* an AOR in sp.com. > > No, because it's not the right domain. It's doing the ENUM on a phone > number. Its doing an ENUM on a phone number from the user part of a sip URI with domain name sp.com. Assuming its the sp.com domain that is doing the ENUM query, then it is the *right* domain. If the proxy was not responsible for the sp.com domain then it shouldn't be doing the translation, using ENUM or anything else. > So it really has nothing to do with a SIP scheme (a condition > for AOR, remember?). > > And in fact, it goes to example.com, not sp.com What does that have to do with anything? If this number was looked up in a location service that was populated via REGISTER, and the result was in example.com you wouldn't be arguing that meant this couldn't be an AOR. Thanks, Paul From BPenfield@acmepacket.com Fri Jul 17 06:09:52 2009 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 42C6928C2EC for ; Fri, 17 Jul 2009 06:09:52 -0700 (PDT) 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 33RzXLyCN0Gw for ; Fri, 17 Jul 2009 06:09:51 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 1AA5D28C2EB for ; Fri, 17 Jul 2009 06:08:56 -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.1.375.2; Fri, 17 Jul 2009 08:56:11 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 17 Jul 2009 08:56:10 -0400 From: Bob Penfield To: Eric Burger , SIPCORE Date: Fri, 17 Jul 2009 08:56:09 -0400 Thread-Topic: [sipcore] INFO draft Thread-Index: AcoGamCEbr/TYLwQSqufEma3vfH35wAc0AAw Message-ID: References: <44F700B5-1F7F-4732-86A0-76D7E7083AE6@standardstrack.com> In-Reply-To: <44F700B5-1F7F-4732-86A0-76D7E7083AE6@standardstrack.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] INFO draft 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, 17 Jul 2009 13:09:52 -0000 I finally read the new draft, and I do have some comments. 1) In Section 3.2 (UAC Behavior) it says: If the UAS does not send any Recv-Info headers in a message, then the list of supported Info Packages does not change. But then it says: A UAC MUST cease sending INFO requests for a given INFO package when the UAC receives an "INVITE dialog usage" request or response (for session establishment or target refresh) that does not contain a Recv-Info header listing the given Info Package.=20 This implies that the UAC must stop sending INFO requests for a given package if there are no Recv-Info headers in a received request or response. Suggest the following: A UAC MUST cease sending INFO requests for a given INFO package when the UAC receives an "INVITE dialog usage" request or response (for session establishment or target refresh) that contains a Recv-Info header that does not list the given Info Package.=20 2) Section 3.2 should mention that a 469 response does not destroy the INVITE dialog usage. If the application determines that the dialog usage cannot continue due to the 469 response, it should send a BYE to terminate the dialog usage. 3) The example in 10.1 does not include the mandatory Content-Disposition header. cheers, (-:bob -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Eric Burger Sent: Thursday, July 16, 2009 7:09 PM To: SIPCORE Subject: [sipcore] INFO draft The silence is deafening. Please +1 or -1, as the WGLC is underway. If =20 you're too tired of the topic, just +1 to prove you read the email. http://www.ietf.org/internet-drafts/draft-ietf-sipcore-info-events-00.txt= From mlinsner@cisco.com Fri Jul 17 06:16:47 2009 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 4B8633A6E41 for ; Fri, 17 Jul 2009 06:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.335 X-Spam-Level: X-Spam-Status: No, score=-6.335 tagged_above=-999 required=5 tests=[AWL=0.264, 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 bn39ZVqH7HKV for ; Fri, 17 Jul 2009 06:16:45 -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 9BA433A67C1 for ; Fri, 17 Jul 2009 06:16:45 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAKADgWYEqrR7O6/2dsb2JhbAAwtnGIIy0IkDsFgigNCgMFCIE+iW8 X-IronPort-AV: E=Sophos;i="4.42,417,1243814400"; d="scan'208";a="348666566" Received: from sj-dkim-2.cisco.com ([171.71.179.186]) by sj-iport-6.cisco.com with ESMTP; 17 Jul 2009 13:15:44 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6HDFiIZ021448; Fri, 17 Jul 2009 06:15:44 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6HDFh8a002960; Fri, 17 Jul 2009 13:15:43 GMT Received: from xmb-rtp-205.amer.cisco.com ([64.102.31.59]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 09:15:42 -0400 Received: from [10.116.195.116] ([10.116.195.116]) by xmb-rtp-205.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 09:15:41 -0400 User-Agent: Microsoft-Entourage/12.19.0.090515 Date: Fri, 17 Jul 2009 09:15:39 -0400 From: Marc Linsner To: , "Thomson, Martin" Message-ID: Thread-Topic: [sipcore] Confusion over target inSIP location-conveyance - andimpact on ECRIT phonebcp Thread-Index: AcoG4K2xdzOVsq3tQUS5+gNHkkj09g== In-Reply-To: Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 17 Jul 2009 13:15:41.0582 (UTC) FILETIME=[AF3B4AE0:01CA06E0] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12497; t=1247836544; x=1248700544; c=relaxed/simple; s=sjdkim2002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=mlinsner@cisco.com; z=From:=20Marc=20Linsner=20 |Subject:=20FW=3A=20[sipcore]=20Confusion=20over=20target=2 0inSIP=20location-conveyance=20-=0A=20andimpact=20on=20ECRIT =20phonebcp |Sender:=20; bh=i2IsJWBdKBlMe/onIPcQZlYaYRLueflBGkDWbFWjhkA=; b=KHZ084hmHcC6Wrqfwj5hbtXgfXFm0IaCvGgPwzZLb+WsvxmmIYzIEHw1dc yCxGX7xwv7jR7tb58WX1rM7aX3+G8F2K9vSX6VC9z0BAiMPaCrSQkh2TXNUo R/h5pzXkMU; Authentication-Results: sj-dkim-2; header.From=mlinsner@cisco.com; dkim=pass ( sig from cisco.com/sjdkim2002 verified; ); Cc: sipcore@ietf.org Subject: [sipcore] FW: Confusion over target inSIP location-conveyance - andimpact on ECRIT phonebcp 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, 17 Jul 2009 13:16:47 -0000 Jon, Martin, In reviewing RFC4479, I'm struggling with the premise that one can convey a location value via SIP in a document that has no Person component in the Presentity. My interpretation of RFC4479 is that a Presence document MUST contain Person data within the Presentity data model, it's the top of the hierarchy. Therefore lack of Person data renders the document not valid. I've always viewed the locationResponse sent from a HELD server as Location Configuration Information (LCI), equivalent to LCI returned by DHCP (or LLDPMED). (Of course, this is contrary to the implication in the HELD draft and might need to be addressed before publication.) Hence, the LCI data is not a valid Presence document until the UA completes/changes the Presentity attributes. I'm not sure overriding the Person data (or lack thereof) in the Presentity by simply appending ";me" is correct, nor should it be allowed. This runs contrary to the premise that the two documents should stand alone without dependencies on one another. What am I missing? -Marc- >My own interest in this discussion has largely been to prevent the >conflation of the UAC with the geopriv target. I've argued that the >UAC and the entity in the From header field value are not >necessarily equivalent for the purposes of geopriv, thanks to >aggregator UAs serving many users, such as IP PBXs, gateways and so >forth. I've therefore resisted the proposal that the implicit >semantics of the Geolocation header be "this is the location of the >UAC." I feel less strongly about semantics of "this is the location >of the entity in the From header field", be they implicit or >explicit semantics. I can certainly imagine a version of the ";me" >parameter as an explicit indication of these semantics that would >not fall afoul of this conflation. > >I do wonder, though, if the semantics of "routing-allowed" overlap >with the intention behind ";me". Ultimately, a proxy server decides >whether or not it will use the location in the SIP request for >routing purposes. Your use case below assumes that the proxy server >decision to route based on location is dependent on the PIDF >referenced in the SIP request indicating the same target as the SIP >layer identity. While ";me" is helpful in that case, I'm not sure >that this should be the deciding criteria in all cases. >"routing-allowed" communicates a less specific indication of "hey, I >think you can use this to route the request", something that could >be true even if, for whatever reason, the location in the SIP >request doesn't represent the target of my SIP-layer identity, >because due to some unusual circumstances the From header field of >my request can't have a value that represents "me" at the moment - >maybe it's an anonymous URI, for example. > >My point here is that I think agreement on the sorts of policies >that proxy servers should enforce has to inform the sorts of >indications we feed into that policy. If we need a way to tell the >proxy server that a referenced location is appropriate for routing, >we might want something more explicit than ";me". > >To your postscript, I'd have to say no, there's no necessary >equivalence between the resources indicated by those two schemes, >only convention links them. > >Jon Peterson >NeuStar, Inc. > >Thomson, Martin wrote: >>Hi Jon, >> >>Here's the problem: >>I am sip:mt@andrew.com. I use HELD or DHCP to request a location >>URI. This is what is put in my SIP INVITE. A proxy dereferences >>this to determine where to route the call. They encounter >>pres:v76ns38907v6e05@lis.example.com in the resulting PIDF-LO. The >>location information is ignored; it's not applicable to the requester. >> >>The server that provides the location information has no basis to >>determine that the entity making a request and sip:mt@andrew.com >>are one and the same. Thus, it cannot make this assertion. HELD >>recommends the creation of a pseudonym for this reason. >> >>How do we resolve this? >> >>We could define a mechanism for asserting sip identity in other >>domains, such that HELD could use it. Sounds a bit heavyweight to me. >> >>Providing a linkage between the two in SIP might work, but it >>sounds like you don't want to do that. Shame, because that's the >>easiest. One simple way would be to add a ';me' parameter to the >>geolocation header, which links the UAC (identified in From:) to >>the location object, irrespective of the identified presentity. >> >>--Martin >> >>p.s. On a similar thread, I think I remember reading that >>sip:mt@andrew.com is the same as pres:mt@andrew.com. Is this >>guaranteed truth, or just highly likely? >> >> >>>-----Original Message----- >>>From: Jon Peterson [mailto:jon.peterson@neustar.biz] >>>Sent: Wednesday, 15 July 2009 3:11 PM >>>To: Thomson, Martin >>>Cc: Brian Rosen; Elwell, John; James M. Polk; sipcore@ietf.org >>>Subject: Re: [sipcore] Confusion over target inSIP location-conveyance >>>- andimpact on ECRIT phonebcp >>> >>> >>>There must be something I'm missing in this discussion, but I've found >>>this issue with identity binding a bit elusive. PIDF documents (let >>>alone PIDF-LO documents) necessarily contain a field designating the >>>entity that the document is supposed to represent - the "entity" >>>attribute of . Given that this attribute contains a URI, it >>>can be as specific or opaque as is necessary for the application in >>>question. It appears regardless of how the PIDF document is acquired >>>(by >>>reference or by value). In what way is this element insufficient >>>exactly? >>> >>>I would certainly be skeptical of any SIP-layer mechanism that is >>>intended to provide a separate account of how a PIDF document is >>>"bound" >>>to the entity it represents. >>> >>>Jon Peterson >>>NeuStar, Inc. >>> >>>Thomson, Martin wrote: >>> >>>>I still haven't seen an explanation on how to resolve the identity >>>> >>>binding problem when location is provided by reference. That's a small >>>thing for phone-bcp, but not for location-conveyance. >>> >>>> >>>>>-----Original Message----- >>>>>From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>>>>Behalf Of Brian Rosen >>>>>Sent: Wednesday, 15 July 2009 6:10 AM >>>>>To: 'Elwell, John'; 'James M. Polk'; sipcore@ietf.org >>>>>Subject: Re: [sipcore] Confusion over target inSIP location- >>>>> >>>conveyance >>> >>>>>- andimpact on ECRIT phonebcp >>>>> >>>>>I have raised this very issue with James, and verified it with Jon >>>>>Peterson >>>>>and Robert Sparks, and the intention is that the Geolocation header >>>>> >>>can >>> >>>>>carry the location of any target, the specific target being that >>>>>identified >>>>>in the PIDF, and subject to the privacy requirements of that target. >>>>> >>>>>It turns out to be useful to do this in a couple of cases I've run >>>>>across, >>>>>although I'm somewhat surprised that everyone agreed it is okay to >>>>> >>>do >>> >>>>>so. >>>>> >>>>>While I guess I could improve phonebcp by making an explicit >>>>> >>>statement >>> >>>>>that, >>>>>when sent to the PSAP, the location in the header must be that of >>>>> >>>the >>> >>>>>caller, I do think it's clear enough that it is. >>>>> >>>>>I'll do that in the next rev, although I don't want to hold up >>>>> >>>sending >>> >>>>>the >>>>>current version to the IESG over that tidbit. >>>>> >>>>>Brian >>>>> >>>>> >>>>> >>>>>>-----Original Message----- >>>>>>From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>>Sent: Tuesday, July 14, 2009 2:40 AM >>>>>>To: James M. Polk; sipcore@ietf.org; Brian Rosen >>>>>>Subject: Confusion over target inSIP location-conveyance - and >>>>>> >>>impact >>> >>>>>>on ECRIT phonebcp >>>>>> >>>>>>In 4.2 it states: >>>>>>"The UAC can use whatever means it knows of to verify/refresh its >>>>>> location information before attempting a new request that >>>>>> >>>includes >>> >>>>>> location." >>>>>>"its location information" suggests that the UAC is the target. >>>>>> >>>>>>In 4.3.3 it states: >>>>>>"This document gives no guidance how this is accomplished, given >>>>>> >>>the >>> >>>>>> number of ways a UAC can learn its location" >>>>>>which suggests similar. >>>>>> >>>>>>Similarly in 6.1: >>>>>>"If a UAC does not learn and store its location locally (a GPS >>>>>> >>>chip) >>> >>>>>> or from the network (DHCP or LLDP-MED), the UAC MAY learn its >>>>>> >>>LbyR >>> >>>>>> URI (from DHCP for example)." >>>>>>Which suggests that a UAC inserts its location, not some other >>>>>>location. >>>>>> >>>>>>And later in 6.1: >>>>>>"If a UAC has already conveyed location in the original request of >>>>>> >>>a >>> >>>>>> transaction, and wants to update its location information ..." >>>>>> >>>>>>In 6.2: >>>>>>"If the LbyR URI is >>>>>> sip:, sips: or pres:, and the UAS wants to learn the UAC's >>>>>>location," >>>>>> >>>>>>In 6.2.1: >>>>>>"This >>>>>> means the SIP server is including its version of where it thinks >>>>>> >>>>>> >>>>>the >>>>> >>>>> >>>>>> UAC is, geographically." >>>>>> >>>>>>In 8: >>>>>>"Conveyance of physical location of a UAC raises privacy concerns" >>>>>> >>>>>>and: >>>>>>"In cases where a session set-up is >>>>>> retargeted based on the location of the UAC initiating the call >>>>>> >>>or >>> >>>>>> SIP MESSAGE," >>>>>> >>>>>>All these many examples illustrate an implication that the location >>>>>>target is the UAC. I am sure there are other places too. >>>>>> >>>>>>I found a couple of places that contradict this. In 6.2 it states: >>>>>>"If there >>>>>> is more than one PIDF-LO with different Target identifiers, then >>>>>> the UAC is merely telling the UAS where more than one Target is, >>>>>> >>>>>> >>>>>and >>>>> >>>>> >>>>>> there should not be any conflict." >>>>>> >>>>>>I think there are other places that mention locations of multiple >>>>>>targets in a request, implying they cannot all be the location of >>>>>> >>>the >>> >>>>>>UAC. >>>>>> >>>>>>And in 6.2.1 it states: >>>>>>"The Location Target identified in >>>>>> the PIDF-LO may or may not be the location inserter, or the >>>>>> generator of the request (the UAC or SIP server)." >>>>>> >>>>>>So we have inconsistency as to whether a conveyed location is that >>>>>> >>>of >>> >>>>>>they UAC or not. >>>>>> >>>>>>One document that relies on location-conveyance is ECRIT's >>>>>> >>>phonebcp. >>> >>>>>In >>>>> >>>>> >>>>>>there, I cannot find any reference to a routing entity looking to >>>>>> >>>see >>> >>>>>>whether a conveyed location has the caller as target or not. It >>>>>> >>>just >>> >>>>>>assumes that this is the case. So if we were to agree that a >>>>>> >>>conveyed >>> >>>>>>location is not necessarily the location of the UAC, this will have >>>>>>impact on phonebcp. >>>>>> >>>>>>John >>>>>> >>>>>> >>>>>_______________________________________________ >>>>>sipcore mailing list >>>>>sipcore@ietf.org >>>>>https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>>>> >>>>--------------------------------------------------------------------- >>>> >>>--------------------------- >>> >>>>This message is for the designated recipient only and may >>>>contain privileged, proprietary, or otherwise private information. >>>>If you have received it in error, please notify the sender >>>>immediately and delete the original. Any unauthorized use of >>>>this email is prohibited. >>>>--------------------------------------------------------------------- >>>> >>>--------------------------- >>> >>>>[mf2] >>>>_______________________________________________ >>>>sipcore mailing list >>>>sipcore@ietf.org >>>>https://www.ietf.org/mailman/listinfo/sipcore >>>> >>>> >> >>------------------------------------------------------------------------------ ------------------ >>This message is for the designated recipient only and may >>contain privileged, proprietary, or otherwise private information. >>If you have received it in error, please notify the sender >>immediately and delete the original. Any unauthorized use of >>this email is prohibited. >>------------------------------------------------------------------------------ ------------------ >>[mf2] >> From jmh@joelhalpern.com Fri Jul 17 06:20:20 2009 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 5F81E3A6C7B for ; Fri, 17 Jul 2009 06:20:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.779 X-Spam-Level: X-Spam-Status: No, score=-2.779 tagged_above=-999 required=5 tests=[AWL=-0.514, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334] 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 ykkivvbQtv3b for ; Fri, 17 Jul 2009 06:20:19 -0700 (PDT) Received: from morbo.mail.tigertech.net (morbo.mail.tigertech.net [67.131.251.54]) by core3.amsl.com (Postfix) with ESMTP id B9F9B3A68B3 for ; Fri, 17 Jul 2009 06:20:19 -0700 (PDT) Received: from hermes.mail.tigertech.net (hermes.mail.tigertech.net [64.62.209.72]) by morbo.tigertech.net (Postfix) with ESMTP id 2A081A3774 for ; Fri, 17 Jul 2009 06:07:47 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by hermes.tigertech.net (Postfix) with ESMTP id 1834C437E53; Fri, 17 Jul 2009 06:07:17 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at hermes.tigertech.net Received: from [10.10.10.100] (pool-71-161-52-248.clppva.btas.verizon.net [71.161.52.248]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by hermes.tigertech.net (Postfix) with ESMTP id 7D1A8437E4A; Fri, 17 Jul 2009 06:07:16 -0700 (PDT) Message-ID: <4A60777F.5030606@joelhalpern.com> Date: Fri, 17 Jul 2009 09:07:11 -0400 From: "Joel M. Halpern" User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: SIPCORE References: <44F700B5-1F7F-4732-86A0-76D7E7083AE6@standardstrack.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] INFO draft 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, 17 Jul 2009 13:20:20 -0000 +1 Yes, I remember and mostly understood the discussion of the issue. Yes, I have actually read the draft, and it does a good job of addressing the issue. Let's get it done. Joel Hadriel Kaplan wrote: >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf >> Of Eric Burger >> Sent: Thursday, July 16, 2009 7:09 PM >> To: SIPCORE >> Subject: [sipcore] INFO draft >> >> The silence is deafening. Please +1 or -1, as the WGLC is underway. If >> you're too tired of the topic, just +1 to prove you read the email. >> >> http://www.ietf.org/internet-drafts/draft-ietf-sipcore-info-events-00.txt > > +1 (but I didn't read the email) > > -hadriel > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From john.elwell@siemens-enterprise.com Fri Jul 17 06:31:13 2009 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 70DE33A69E3 for ; Fri, 17 Jul 2009 06:31:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.586 X-Spam-Level: X-Spam-Status: No, score=-2.586 tagged_above=-999 required=5 tests=[AWL=0.013, 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 1g3muIr2tMzQ for ; Fri, 17 Jul 2009 06:31:12 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 4E0EC3A6822 for ; Fri, 17 Jul 2009 06:31:12 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KMX00G75G8V1Y@siemenscomms.co.uk> for sipcore@ietf.org; Fri, 17 Jul 2009 14:02:55 +0100 (BST) Date: Fri, 17 Jul 2009 14:02:53 +0100 From: "Elwell, John" In-reply-to: <44F700B5-1F7F-4732-86A0-76D7E7083AE6@standardstrack.com> To: Eric Burger , SIPCORE Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0022A2AFC@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] INFO draft Thread-Index: AcoGamLM4uosCMomRR23r4ZiLAuoUAAdH3ng Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <44F700B5-1F7F-4732-86A0-76D7E7083AE6@standardstrack.com> Subject: Re: [sipcore] INFO draft 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, 17 Jul 2009 13:31:13 -0000 +1=20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Eric Burger > Sent: 17 July 2009 00:09 > To: SIPCORE > Subject: [sipcore] INFO draft >=20 > The silence is deafening. Please +1 or -1, as the WGLC is=20 > underway. If =20 > you're too tired of the topic, just +1 to prove you read the email. >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-info-ev > ents-00.txt >=20 From L.Liess@telekom.de Fri Jul 17 06:51:40 2009 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 64F7E3A68B0 for ; Fri, 17 Jul 2009 06:51:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.649 X-Spam-Level: X-Spam-Status: No, score=-4.649 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_DE=0.35, J_CHICKENPOX_84=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 YfBgZTnqA+Gk for ; Fri, 17 Jul 2009 06:51:39 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 740C23A68B3 for ; Fri, 17 Jul 2009 06:51:38 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 17 Jul 2009 15:52:02 +0200 Received: from S4DE9JSAANI.ost.t-com.de ([10.125.177.223]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 15:52:01 +0200 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, 17 Jul 2009 15:52:00 +0200 Message-ID: <40FB0FFB97588246A1BEFB05759DC8A003337B38@S4DE9JSAANI.ost.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-kaplan-sip-session-id-02 Thread-Index: Acn1DaU1pu17VvRRTd+gHdXlHhTG9AOmEHkwAAGgysAAavX4kAAkYXUw X-Message-Flag: Follow up References: <1245876685.3748.61.camel@victoria-pingtel-com.us.nortel.com><40FB0FFB97588246A1BEFB05759DC8A00330040F@S4DE9JSAANI.ost.t-com.de> From: To: X-OriginalArrivalTime: 17 Jul 2009 13:52:01.0906 (UTC) FILETIME=[C2CE5520:01CA06E5] Cc: HKaplan@acmepacket.com, sipcore@ietf.org, dworley@nortel.com, R.Jesske@telekom.de, Martin.Huelsemann@telekom.de Subject: Re: [sipcore] draft-kaplan-sip-session-id-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: Fri, 17 Jul 2009 13:51:40 -0000 Peter, Currently we have a B2BUA (instead of a proxy) and a PSTN gateway.=20 One of the reasons for using a B2BUA is to avoid that the callee knows = the IP-address of the caller.(This requirement came in from the guys = dealing with security and privacy.) So, there are two different dialogs = with two different Call-IDs on both sides of the B2BUA.=20 =20 The monitoring is done for every network element. All incomming and = outgoing messages are written in logfiles by the monitoring system. = These logfiles have nothing in common with the logfiles generated by the = network elements. The logfiles are used:=20 1)by the operation people, to identify failures (debugging)=20 2)by the security people, to trace calls in case they suspect that user = passwords were stolen.=20 3)for billing, as a verification in case of discrepancies between the = DT accounting data and the accounting data of the customer ( private = customers or other carriers) In principle, we need a mean to convey the Call-ID of the A-side dialog = in the B-side messages, in order to be able to corelate the A-side = dialog with the B-side dialog. This is what the Session-ID does. Because = we down't want the callee to know the IP-address of the caller, the = B2BUA hashes the Call-ID before writing it in the Session-ID. The = monitoring system has to know the hash key. =20 Kind regards Laura =20 =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Dawes, Peter, VF-Group > Sent: Wednesday, July 15, 2009 4:47 PM > To: Liess, Laura; HKaplan@acmepacket.com > Cc: sipcore@ietf.org; Pinker, Gerold; dworley@nortel.com;=20 > Jesske, Roland; H=FClsemann, Martin > Subject: Re: [sipcore] draft-kaplan-sip-session-id-02 >=20 > Hello Laura, > Thanks for the very interesting extra perspective. Does your traffic > monitoring solution pass all SIP signalling through this 'separate > device for monitoring', and does this device record all=20 > network activity > all the time? I ask because one thing that the session-id-02=20 > draft does > not seem to help with is how you identity a particular session you are > interested in. Since session-id is very similar to Call-ID, it doesn't > seem very different from recording everything and then searching based > on Call-ID. > I agree with you that a solution should not rely on end devices, > although ideally end devices are included in troubleshooting. Draft > http://tools.ietf.org/html/draft-dawes-sipping-debug-01 also does not > rely on end devices (in 5.2 it says that the first proxy in=20 > the path can > insert the new P-Debug-ID header), but I should probably revise the > draft structure to make the responsibilities of each entity=20 > (UAC, Proxy, > UAS, etc.) clearer. =20 >=20 > Best regards, > Peter >=20 > =20 >=20 > -----Original Message----- > From: L.Liess@telekom.de [mailto:L.Liess@telekom.de]=20 > Sent: 13 July 2009 17:00 > To: Dawes, Peter, VF-Group; HKaplan@acmepacket.com > Cc: dworley@nortel.com; sipcore@ietf.org; R.Jesske@telekom.de; > Martin.Huelsemann@telekom.de; Gerold.Pinker@telekom.de > Subject: RE: [sipcore] draft-kaplan-sip-session-id-02 >=20 > Peter, >=20 > we intend to use the Session-ID for traffic monitoring.=20 > Personally, I like the debug drafts a lot because it is a quite > efficient mechanism for detecting faults quickly but it covers quite > different scenarios than Session-ID. We discussed internaly=20 > what to use > and decided for Session-ID for following reasons:=20 >=20 > - The monitoring is done by a separate device, we don't use=20 > the logfiles > of the proxies.=20 > - We can not rely on end devices. We already have a lot of=20 > end devices > in the field which do not have session-ID or debug-id=20 > implemented. First > SBC in the path has to insert the new ID. Also, the security people > whant to use the ID to trace attacks and we assume that the attacker's > clients will not insert the debugg-id.=20 > - We want to be able to correlate the messages end-to-end=20 > also if we do > not know in advance if we want to monitor a specific call.=20 > - The monitoring is active all the time. The security people=20 > want to be > able to look what happened in the past. So the global uniqueness > requirement makes sense for me.=20 > - The hashing is needed because we do not want the calle to see the > IP-address of the caller end most devices insert the IP-address in the > call-id. =20 >=20 > Kind regards > Laura > =20 >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of Dawes,=20 > Peter, VF-Group > > Sent: Monday, July 13, 2009 1:12 PM > > To: SIPCORE; Hadriel Kaplan > > Cc: Dale Worley > > Subject: Re: [sipcore] draft-kaplan-sip-session-id-02 > >=20 > > Hello Hadriel, Dale, > > Regarding the length of the session-id header field, is it really=20 > > necessary to guarantee global uniqueness and use 128 bits?=20 > The uses of >=20 > > this new header field described in -02 are 'troubleshooting' and=20 > > 'identity verification mechanisms', but troubleshooting will be=20 > > restricted to relatively short time period after which a session-id=20 > > value could be reused. Identity verification is not=20 > described but does >=20 > > it require a globally unique session-id? > >=20 > > Troubleshooting is also the topic of my draft=20 > > http://tools.ietf.org/html/draft-dawes-sipping-debug-01, which is=20 > > similar to session-id but also describes how troubleshooting starts=20 > > and stops, and how entities determine when to add a header=20 > field for=20 > > debugging. According to session-id-02, the session-id=20 > header field is=20 > > present in all dialogs, which implies troubleshooting needs=20 > to record=20 > > everything, potentially at multiple entities some of which=20 > may not be=20 > > involved in the session being investigated, and then=20 > post-analyse for=20 > > the particular session that is targetted for troubleshooting. > > This seems > > inefficient, or have I misunderstood? > > =20 > > Best Regards, > > Peter > >=20 > >=20 > > Peter Dawes > > Group R&D > > =20 > > Tel: +44 (0)7717 275009 > > Fax: +44 (0)1635 234873 > >=20 > > =20 > > E-mail: peter.dawes@vodafone.com > > =20 > > www.betavine.net - Web > > betavine.mobi - Mobile Web > > =20 > > Vodafone Group Services Limited > > Registered Office: Vodafone House, The Connection, Newbury,=20 > Berkshire > > RG14 2FN Registered in England No 3802001 > >=20 > >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > > Behalf Of Dale Worley > > Sent: 24 June 2009 21:51 > > To: SIPCORE > > Subject: [sipcore] draft-kaplan-sip-session-id-02 > >=20 > > Looking at draft-kaplan-sip-session-id-02, the shorter the=20 > Session-Id=20 > > header is, the fewer complaints people will have about using it in=20 > > practice. A couple of things could be done to shorten it: > >=20 > > - assign a single-letter abbreviation for the name > >=20 > > - use base64 rather than hex encoding > >=20 > > Base64 encoding reduces the header value to 22 characters from 32. > >=20 > > Dale > >=20 > >=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 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From HKaplan@acmepacket.com Fri Jul 17 07:51:42 2009 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 23D4328C1F6 for ; Fri, 17 Jul 2009 07:51:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.58 X-Spam-Level: X-Spam-Status: No, score=-2.58 tagged_above=-999 required=5 tests=[AWL=0.019, 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 agpf7yK5lpz4 for ; Fri, 17 Jul 2009 07:51:41 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id C9E0528C1DF for ; Fri, 17 Jul 2009 07:51:40 -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.1.375.2; Fri, 17 Jul 2009 10:52:12 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 17 Jul 2009 10:52:11 -0400 From: Hadriel Kaplan To: Francois Audet , Paul Kyzivat Date: Fri, 17 Jul 2009 10:52:11 -0400 Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoGdrNymXGLk6cITOGzbIG/niCWIgAdaQdw Message-ID: References: <4A5FAF4E.4030901@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 Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 17 Jul 2009 14:51:42 -0000 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Thursday, July 16, 2009 8:37 PM >=20 > >> Say I call sip:+1234567890@sp.com;user=3Dphone. My proxy is "sp.com", > >> right? > >> > >> Then sp.net does ENUM query. Did you intend for this to be "sp.net" and thus a different domain from "sp= .com"? Or was that a typo? I am assuming it was a typo. > > If we assume that ENUM qualifies as a location service (and I am now > > convinced that it does), then this URI *is* an AOR in sp.com. >=20 > No, because it's not the right domain. It's doing the ENUM on a phone > number. So it really has nothing to do with a SIP scheme (a condition > for AOR, remember?). Regardless of whether ENUM is doing it on a phone number sans domain or not= , it MUST be marked as an "aor". Think of it this way: Suppose you call "sip:+18005551212@sp.com", and sp.com does an ENUM lookup = on 18005551212, and the NAPTR result translated it to the non-800 specific = number for it. The freephone-model/redirection-usage NEEDs to see that 180= 05551212. No? That's also why I think you'd want Tel-URI's - because sp.com could have re= ceived a Tel-URI with it and done that ENUM lookup. > And in fact, it goes to example.com, not sp.com So? As far as the sp.com Proxy cares, it has done an ENUM lookup and gotte= n a result which changes the req-uri and makes it route the call. As far a= s it knows, "sip:+1234567890@example.com" is a contact address of a PSTN-Ga= teway or registered UA, in which case per the rules "sip:+1234567890@sp.com= " WAS an AoR; whereas if "sip:+1234567890@example.com" is another peer doma= in then it's not an AoR?? -hadriel From HKaplan@acmepacket.com Fri Jul 17 09:29:14 2009 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 8B5163A6834 for ; Fri, 17 Jul 2009 09:29:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.58 X-Spam-Level: X-Spam-Status: No, score=-3.58 tagged_above=-999 required=5 tests=[AWL=1.019, BAYES_00=-2.599, GB_I_LETTER=-2] 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 ZMOtnvqg3Fvv for ; Fri, 17 Jul 2009 09:29:13 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 539823A6AFD for ; Fri, 17 Jul 2009 09:28:46 -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.1.375.2; Fri, 17 Jul 2009 12:29:02 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 17 Jul 2009 12:29:02 -0400 From: Hadriel Kaplan To: Dale Worley , SIPCORE Date: Fri, 17 Jul 2009 12:29:01 -0400 Thread-Topic: [sipcore] draft-kaplan-sip-session-id-02 Thread-Index: Acn1DbJ5BeZbnlIJQsu41Pvck+Z2IAR7ZeVQ Message-ID: References: <1245876685.3748.61.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1245876685.3748.61.camel@victoria-pingtel-com.us.nortel.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-kaplan-sip-session-id-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: Fri, 17 Jul 2009 16:29:14 -0000 Hey Dale, inline... > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Dale Worley >=20 > Looking at draft-kaplan-sip-session-id-02, the shorter the Session-Id > header is, the fewer complaints people will have about using it in > practice. A couple of things could be done to shorten it: >=20 > - assign a single-letter abbreviation for the name That was asked for in the draft (see section 7.1). =20 > - use base64 rather than hex encoding >=20 > Base64 encoding reduces the header value to 22 characters from 32. Is that 10 character savings really worth anything? I guess I don't really= care, either way. -hadriel From HKaplan@acmepacket.com Fri Jul 17 10:07:00 2009 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 C3D3528C2F3 for ; Fri, 17 Jul 2009 10:07:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 sgK0XACRyenH for ; Fri, 17 Jul 2009 10:06:59 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id BC56028C2F0 for ; Fri, 17 Jul 2009 10:06:59 -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.1.375.2; Fri, 17 Jul 2009 13:07:31 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 17 Jul 2009 13:07:31 -0400 From: Hadriel Kaplan To: "Dawes, Peter, VF-Group" , SIPCORE Date: Fri, 17 Jul 2009 13:07:31 -0400 Thread-Topic: [sipcore] draft-kaplan-sip-session-id-02 Thread-Index: Acn1DaU1pu17VvRRTd+gHdXlHhTG9AOmEHkwANV0/KA= Message-ID: References: <1245876685.3748.61.camel@victoria-pingtel-com.us.nortel.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: Dale Worley Subject: Re: [sipcore] draft-kaplan-sip-session-id-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: Fri, 17 Jul 2009 17:07:00 -0000 Hi Peter, comments inline... > -----Original Message----- > From: Dawes, Peter, VF-Group [mailto:Peter.Dawes@vodafone.com] > Sent: Monday, July 13, 2009 7:12 AM >=20 > Hello Hadriel, Dale, > Regarding the length of the session-id header field, is it really > necessary to guarantee global uniqueness and use 128 bits? The uses of > this new header field described in -02 are 'troubleshooting' and > 'identity verification mechanisms', but troubleshooting will be > restricted to relatively short time period after which a session-id > value could be reused. Identity verification is not described but does > it require a globally unique session-id? The draft mentions it could be used as part of an identity verification mec= hanism, but it's beyond the scope of the draft. Really the draft is focuse= d on the header value being useful for identification for troubleshooting p= urposes. While a 16-byte value might seem overly large for such use, SIP s= essions can last indefinitely, not just for a short duration; and since the= value is a random one and can just by coincidence overlap with another fro= m a different session (because each UA creates it), I thought it safer to e= rror on the side of caution with 128-bit randomness. > Troubleshooting is also the topic of my draft > http://tools.ietf.org/html/c, which is > similar to session-id but also describes how troubleshooting starts and > stops, and how entities determine when to add a header field for > debugging. According to session-id-02, the session-id header field is > present in all dialogs, which implies troubleshooting needs to record > everything, potentially at multiple entities some of which may not be > involved in the session being investigated, and then post-analyse for > the particular session that is targetted for troubleshooting. This seems > inefficient, or have I misunderstood? The Session-ID header-value is just there for any troubleshooting use - whe= ther an operator/system actually chooses to debug a given session or not do= es not matter. For example, I would expect (and have seen) probes/monitors= used which collect all signaling and store it for long periods of time, fo= r later analysis. That analysis could be for troubleshooting, fraud invest= igation, whatever. For example, the proposed SIP CLF format(s) tries to pr= ovide some correlation of messages on both sides of a B2BUA - this Session-= ID allows one to do that as well in a CLF, or even with just a sniffer type= trace without a CLF from the B2BUA. With the draft-dawes-sipping-debug-01 concept, for example, you need to tel= l the UA what debug-id value to use, because you don't have a Session-ID he= ader value at your disposal. If you had one, you could just tell it to set= a param to "true" or whatever, to indicate to proxies to generate logs for= the message. Right? That way it's not some header-value only usable/avai= lable by a draft-dawes-sipping-debug-01 subscribe/notification mechanism in= particular (which I think is one of only many ways to do debugging) - but = rather a value which crosses B2BUA's/forks available for any debugging mech= anism to use. -hadriel From jon.peterson@neustar.biz Fri Jul 17 10:42:29 2009 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 3ED9C28C2BF for ; Fri, 17 Jul 2009 10:42:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.521 X-Spam-Level: X-Spam-Status: No, score=-2.521 tagged_above=-999 required=5 tests=[AWL=0.078, 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 U4X8+9g48gKv for ; Fri, 17 Jul 2009 10:42:27 -0700 (PDT) Received: from neustar.com (ns6.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 4BE2128C10E for ; Fri, 17 Jul 2009 10:42:27 -0700 (PDT) DKIM-Signature: a=rsa-sha1; d=neustar.biz; s=neustarbiz; c=simple/simple; q=dns; t=1247852577; x=1247938977; h=From:Date:Subject:Message-ID:Content-Type:Content-Transfer-Encoding; b=Y/Qukvqn6tbQ+JNppHZG+1H4IlROABPdWTcZygH1RgN7mTynYzQepHemkjQVnGgsBVs5QRBtIHZdww rTc1Hwfg== Received: from ([10.31.13.105]) by stihiron1.va.neustar.com with ESMTP id 5202702.20496726; Fri, 17 Jul 2009 13:42:40 -0400 Message-ID: <4A60B810.60405@neustar.biz> Date: Fri, 17 Jul 2009 10:42:40 -0700 From: Jon Peterson User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Marc Linsner References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org, "Thomson, Martin" Subject: Re: [sipcore] FW: Confusion over target inSIP location-conveyance - andimpact on ECRIT phonebcp 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, 17 Jul 2009 17:42:29 -0000 I don't think it's fair to say that a URI generated by the HELD server is this case cannot designate a "Person" per the data model. It merely doesn't designate a person with an address-of-record style name (like the Presentity URI, which is what I gather you'd prefer to see in the entity attribute). A person can be the resource identified by any number of URIs, and there's no requirement that they all display human-readable niceties. At a high level, I think you can cast this problem as linking that pseudonym with a well-known URI of the user. Moreover, considering the applicability of geopriv broadly, I would hesitate to assert that presence documents must be about people, perhaps especially for the case where presence documents contain location information. We've talked many times about tracking inanimate objects like palettes with geopriv, for example. RFC4479 is certainly written from the perspective that presence is about people, and although there are people involved in the location of palettes (notably the owner/shipper of the palette, who probably would act as a Rule Maker and thus exert the "person"-level controls per the data model), it is not the location of those people we are tracking, but the location of a separate target. Finally, I do think there is a distinction architecturally between this usage of HELD and of LCP, since effectively the HELD server here acts as an LG, not as a LIS. While we can argue the wisdom of this approach, I think the role it instantiates in the architecture is not especially ambiguous. Jon Peterson NeuStar, Inc. Marc Linsner wrote: > Jon, Martin, > > In reviewing RFC4479, I'm struggling with the premise that one can convey a > location value via SIP in a document that has no Person component in the > Presentity. My interpretation of RFC4479 is that a Presence document MUST > contain Person data within the Presentity data model, it's the top of the > hierarchy. Therefore lack of Person data renders the document not valid. > I've always viewed the locationResponse sent from a HELD server as Location > Configuration Information (LCI), equivalent to LCI returned by DHCP (or > LLDPMED). (Of course, this is contrary to the implication in the HELD draft > and might need to be addressed before publication.) Hence, the LCI data is > not a valid Presence document until the UA completes/changes the Presentity > attributes. > > I'm not sure overriding the Person data (or lack thereof) in the Presentity > by simply appending ";me" is correct, nor should it be allowed. This runs > contrary to the premise that the two documents should stand alone without > dependencies on one another. > > What am I missing? > > -Marc- > > > > >> My own interest in this discussion has largely been to prevent the >> conflation of the UAC with the geopriv target. I've argued that the >> UAC and the entity in the From header field value are not >> necessarily equivalent for the purposes of geopriv, thanks to >> aggregator UAs serving many users, such as IP PBXs, gateways and so >> forth. I've therefore resisted the proposal that the implicit >> semantics of the Geolocation header be "this is the location of the >> UAC." I feel less strongly about semantics of "this is the location >> of the entity in the From header field", be they implicit or >> explicit semantics. I can certainly imagine a version of the ";me" >> parameter as an explicit indication of these semantics that would >> not fall afoul of this conflation. >> >> I do wonder, though, if the semantics of "routing-allowed" overlap >> with the intention behind ";me". Ultimately, a proxy server decides >> whether or not it will use the location in the SIP request for >> routing purposes. Your use case below assumes that the proxy server >> decision to route based on location is dependent on the PIDF >> referenced in the SIP request indicating the same target as the SIP >> layer identity. While ";me" is helpful in that case, I'm not sure >> that this should be the deciding criteria in all cases. >> "routing-allowed" communicates a less specific indication of "hey, I >> think you can use this to route the request", something that could >> be true even if, for whatever reason, the location in the SIP >> request doesn't represent the target of my SIP-layer identity, >> because due to some unusual circumstances the From header field of >> my request can't have a value that represents "me" at the moment - >> maybe it's an anonymous URI, for example. >> >> My point here is that I think agreement on the sorts of policies >> that proxy servers should enforce has to inform the sorts of >> indications we feed into that policy. If we need a way to tell the >> proxy server that a referenced location is appropriate for routing, >> we might want something more explicit than ";me". >> >> To your postscript, I'd have to say no, there's no necessary >> equivalence between the resources indicated by those two schemes, >> only convention links them. >> >> Jon Peterson >> NeuStar, Inc. >> >> Thomson, Martin wrote: >> >>> Hi Jon, >>> >>> Here's the problem: >>> I am sip:mt@andrew.com. I use HELD or DHCP to request a location >>> URI. This is what is put in my SIP INVITE. A proxy dereferences >>> this to determine where to route the call. They encounter >>> pres:v76ns38907v6e05@lis.example.com in the resulting PIDF-LO. The >>> location information is ignored; it's not applicable to the requester. >>> >>> The server that provides the location information has no basis to >>> determine that the entity making a request and sip:mt@andrew.com >>> are one and the same. Thus, it cannot make this assertion. HELD >>> recommends the creation of a pseudonym for this reason. >>> >>> How do we resolve this? >>> >>> We could define a mechanism for asserting sip identity in other >>> domains, such that HELD could use it. Sounds a bit heavyweight to me. >>> >>> Providing a linkage between the two in SIP might work, but it >>> sounds like you don't want to do that. Shame, because that's the >>> easiest. One simple way would be to add a ';me' parameter to the >>> geolocation header, which links the UAC (identified in From:) to >>> the location object, irrespective of the identified presentity. >>> >>> --Martin >>> >>> p.s. On a similar thread, I think I remember reading that >>> sip:mt@andrew.com is the same as pres:mt@andrew.com. Is this >>> guaranteed truth, or just highly likely? >>> >>> >>> >>>> -----Original Message----- >>>> From: Jon Peterson [mailto:jon.peterson@neustar.biz] >>>> Sent: Wednesday, 15 July 2009 3:11 PM >>>> To: Thomson, Martin >>>> Cc: Brian Rosen; Elwell, John; James M. Polk; sipcore@ietf.org >>>> Subject: Re: [sipcore] Confusion over target inSIP location-conveyance >>>> - andimpact on ECRIT phonebcp >>>> >>>> >>>> There must be something I'm missing in this discussion, but I've found >>>> this issue with identity binding a bit elusive. PIDF documents (let >>>> alone PIDF-LO documents) necessarily contain a field designating the >>>> entity that the document is supposed to represent - the "entity" >>>> attribute of . Given that this attribute contains a URI, it >>>> can be as specific or opaque as is necessary for the application in >>>> question. It appears regardless of how the PIDF document is acquired >>>> (by >>>> reference or by value). In what way is this element insufficient >>>> exactly? >>>> >>>> I would certainly be skeptical of any SIP-layer mechanism that is >>>> intended to provide a separate account of how a PIDF document is >>>> "bound" >>>> to the entity it represents. >>>> >>>> Jon Peterson >>>> NeuStar, Inc. >>>> >>>> Thomson, Martin wrote: >>>> >>>> >>>>> I still haven't seen an explanation on how to resolve the identity >>>>> >>>>> >>>> binding problem when location is provided by reference. That's a small >>>> thing for phone-bcp, but not for location-conveyance. >>>> >>>> >>>>>> -----Original Message----- >>>>>> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>>>>> Behalf Of Brian Rosen >>>>>> Sent: Wednesday, 15 July 2009 6:10 AM >>>>>> To: 'Elwell, John'; 'James M. Polk'; sipcore@ietf.org >>>>>> Subject: Re: [sipcore] Confusion over target inSIP location- >>>>>> >>>>>> >>>> conveyance >>>> >>>> >>>>>> - andimpact on ECRIT phonebcp >>>>>> >>>>>> I have raised this very issue with James, and verified it with Jon >>>>>> Peterson >>>>>> and Robert Sparks, and the intention is that the Geolocation header >>>>>> >>>>>> >>>> can >>>> >>>> >>>>>> carry the location of any target, the specific target being that >>>>>> identified >>>>>> in the PIDF, and subject to the privacy requirements of that target. >>>>>> >>>>>> It turns out to be useful to do this in a couple of cases I've run >>>>>> across, >>>>>> although I'm somewhat surprised that everyone agreed it is okay to >>>>>> >>>>>> >>>> do >>>> >>>> >>>>>> so. >>>>>> >>>>>> While I guess I could improve phonebcp by making an explicit >>>>>> >>>>>> >>>> statement >>>> >>>> >>>>>> that, >>>>>> when sent to the PSAP, the location in the header must be that of >>>>>> >>>>>> >>>> the >>>> >>>> >>>>>> caller, I do think it's clear enough that it is. >>>>>> >>>>>> I'll do that in the next rev, although I don't want to hold up >>>>>> >>>>>> >>>> sending >>>> >>>> >>>>>> the >>>>>> current version to the IESG over that tidbit. >>>>>> >>>>>> Brian >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>>> Sent: Tuesday, July 14, 2009 2:40 AM >>>>>>> To: James M. Polk; sipcore@ietf.org; Brian Rosen >>>>>>> Subject: Confusion over target inSIP location-conveyance - and >>>>>>> >>>>>>> >>>> impact >>>> >>>> >>>>>>> on ECRIT phonebcp >>>>>>> >>>>>>> In 4.2 it states: >>>>>>> "The UAC can use whatever means it knows of to verify/refresh its >>>>>>> location information before attempting a new request that >>>>>>> >>>>>>> >>>> includes >>>> >>>> >>>>>>> location." >>>>>>> "its location information" suggests that the UAC is the target. >>>>>>> >>>>>>> In 4.3.3 it states: >>>>>>> "This document gives no guidance how this is accomplished, given >>>>>>> >>>>>>> >>>> the >>>> >>>> >>>>>>> number of ways a UAC can learn its location" >>>>>>> which suggests similar. >>>>>>> >>>>>>> Similarly in 6.1: >>>>>>> "If a UAC does not learn and store its location locally (a GPS >>>>>>> >>>>>>> >>>> chip) >>>> >>>> >>>>>>> or from the network (DHCP or LLDP-MED), the UAC MAY learn its >>>>>>> >>>>>>> >>>> LbyR >>>> >>>> >>>>>>> URI (from DHCP for example)." >>>>>>> Which suggests that a UAC inserts its location, not some other >>>>>>> location. >>>>>>> >>>>>>> And later in 6.1: >>>>>>> "If a UAC has already conveyed location in the original request of >>>>>>> >>>>>>> >>>> a >>>> >>>> >>>>>>> transaction, and wants to update its location information ..." >>>>>>> >>>>>>> In 6.2: >>>>>>> "If the LbyR URI is >>>>>>> sip:, sips: or pres:, and the UAS wants to learn the UAC's >>>>>>> location," >>>>>>> >>>>>>> In 6.2.1: >>>>>>> "This >>>>>>> means the SIP server is including its version of where it thinks >>>>>>> >>>>>>> >>>>>>> >>>>>> the >>>>>> >>>>>> >>>>>> >>>>>>> UAC is, geographically." >>>>>>> >>>>>>> In 8: >>>>>>> "Conveyance of physical location of a UAC raises privacy concerns" >>>>>>> >>>>>>> and: >>>>>>> "In cases where a session set-up is >>>>>>> retargeted based on the location of the UAC initiating the call >>>>>>> >>>>>>> >>>> or >>>> >>>> >>>>>>> SIP MESSAGE," >>>>>>> >>>>>>> All these many examples illustrate an implication that the location >>>>>>> target is the UAC. I am sure there are other places too. >>>>>>> >>>>>>> I found a couple of places that contradict this. In 6.2 it states: >>>>>>> "If there >>>>>>> is more than one PIDF-LO with different Target identifiers, then >>>>>>> the UAC is merely telling the UAS where more than one Target is, >>>>>>> >>>>>>> >>>>>>> >>>>>> and >>>>>> >>>>>> >>>>>> >>>>>>> there should not be any conflict." >>>>>>> >>>>>>> I think there are other places that mention locations of multiple >>>>>>> targets in a request, implying they cannot all be the location of >>>>>>> >>>>>>> >>>> the >>>> >>>> >>>>>>> UAC. >>>>>>> >>>>>>> And in 6.2.1 it states: >>>>>>> "The Location Target identified in >>>>>>> the PIDF-LO may or may not be the location inserter, or the >>>>>>> generator of the request (the UAC or SIP server)." >>>>>>> >>>>>>> So we have inconsistency as to whether a conveyed location is that >>>>>>> >>>>>>> >>>> of >>>> >>>> >>>>>>> they UAC or not. >>>>>>> >>>>>>> One document that relies on location-conveyance is ECRIT's >>>>>>> >>>>>>> >>>> phonebcp. >>>> >>>> >>>>>> In >>>>>> >>>>>> >>>>>> >>>>>>> there, I cannot find any reference to a routing entity looking to >>>>>>> >>>>>>> >>>> see >>>> >>>> >>>>>>> whether a conveyed location has the caller as target or not. It >>>>>>> >>>>>>> >>>> just >>>> >>>> >>>>>>> assumes that this is the case. So if we were to agree that a >>>>>>> >>>>>>> >>>> conveyed >>>> >>>> >>>>>>> location is not necessarily the location of the UAC, this will have >>>>>>> impact on phonebcp. >>>>>>> >>>>>>> John >>>>>>> >>>>>>> >>>>>>> >>>>>> _______________________________________________ >>>>>> sipcore mailing list >>>>>> sipcore@ietf.org >>>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>>> >>>>>> >>>>>> >>>>> --------------------------------------------------------------------- >>>>> >>>>> >>>> --------------------------- >>>> >>>> >>>>> This message is for the designated recipient only and may >>>>> contain privileged, proprietary, or otherwise private information. >>>>> If you have received it in error, please notify the sender >>>>> immediately and delete the original. Any unauthorized use of >>>>> this email is prohibited. >>>>> --------------------------------------------------------------------- >>>>> >>>>> >>>> --------------------------- >>>> >>>> >>>>> [mf2] >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>>>> >>>>> >>> ------------------------------------------------------------------------------ >>> > ------------------ > >>> This message is for the designated recipient only and may >>> contain privileged, proprietary, or otherwise private information. >>> If you have received it in error, please notify the sender >>> immediately and delete the original. Any unauthorized use of >>> this email is prohibited. >>> ------------------------------------------------------------------------------ >>> > ------------------ > >>> [mf2] >>> >>> > > > > From pkyzivat@cisco.com Fri Jul 17 12:21:07 2009 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 C465F3A6C89 for ; Fri, 17 Jul 2009 12:21:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.371 X-Spam-Level: X-Spam-Status: No, score=-6.371 tagged_above=-999 required=5 tests=[AWL=0.228, 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 3VgoMQmZjMt6 for ; Fri, 17 Jul 2009 12:21:06 -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 B361E3A69A3 for ; Fri, 17 Jul 2009 12:21:05 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAIJrYEpAZnmf/2dsb2JhbAC4C4gjkQAFgjqBUw X-IronPort-AV: E=Sophos;i="4.43,223,1246838400"; d="scan'208";a="50795600" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 17 Jul 2009 19:21:38 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6HJLcLF014629; Fri, 17 Jul 2009 15:21:38 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6HJLcnE011866; Fri, 17 Jul 2009 19:21:38 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 15:21:38 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 15:21:37 -0400 Message-ID: <4A60CF41.4040706@cisco.com> Date: Fri, 17 Jul 2009 15:21:37 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Eric Burger References: <44F700B5-1F7F-4732-86A0-76D7E7083AE6@standardstrack.com> In-Reply-To: <44F700B5-1F7F-4732-86A0-76D7E7083AE6@standardstrack.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 17 Jul 2009 19:21:37.0787 (UTC) FILETIME=[CE264CB0:01CA0713] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=12580; t=1247858498; x=1248722498; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20INFO=20draft |Sender:=20 |To:=20Eric=20Burger=20; bh=L/EA4p/p6nx3ylCBEcX71DiCT+kMwFQPOG/BTvttahY=; b=PNSo4TgxzpkGYzU7BAnAUYPvVR2uh/B6jwV2h2B10qnPNAGLtgHcJcN/MB zSmuHo8m9ZqroHL4xd/UkMYO7hINzGRU5OoIYMDNRxb6e3VbvvCINnjJd+mK ATfBMnqhwE; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIPCORE Subject: Re: [sipcore] INFO draft 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, 17 Jul 2009 19:21:07 -0000 Eric, This doc is in better shape than most others at this stage. I did find some things, though mostly nits at this point. A couple rise above the nit level. Section 1: > This draft addresses these deficiencies and provides a > framework for explicit negotiation of capabilities and content > context using "Info Packages". I thought this was considered to be an "advertisement", not a "negotiation". Section 3.1: > Recall the UAC of an INVITE may choose to receive (be a UAS for) INFO > methods. This UA may chose not to offer any packages in the initial > INVITE and subsequently advertise packages from the target UA's > subsequent responses, in order to support third-party call control > [RFC3725]. Not sure this is adequate. There is no way for a UA to indicate what it wishes to send, and sending/receiving are not symmetric. So announcing you will receive what the other end will receive doesn't make sense. But waiting for a subsequent message before indicating what you will receive can make sense in some cases. Section 3.4: > This means the initiating UA is willing to receive from Info Packages > P and R. > This indicates the target UA is willing to receive from Info Packages > R and T. > The target UA can now send from package R to the initiating UA. > Moreover, in this example, the target UA may not send from package P, > as P no longer is in the initiating UA's Info Package set. The phrasing is odd. I would recommend changing "from [Info] package" to "[Info] package". The example in this section also leaves me scratching my head a bit. While the actions and the implications all seem "correct", the plausibility of the case seems a bit suspect. I don't know if it is intended to be plausible, or just "possible" to make the example. Specifically, I'm thinking there is an *implication* that Alice removed P from the ACK because it hadn't been mentioned by Bob in the response. If that is intended, then I don't understand *why* there would be such a causal relationship between those two things. At best it would only make sense due to some special properties of the P and R package semantics. Section 4.1: > That Info Package token MUST match one of the Info Packages the UAS > indicated support for during the negotiation described in Section 3. There is that "negotiation" word again! > A UAC MUST NOT use the INFO method outside an INVITE dialog usage. > The INFO method has no lifetime or usage of its own, as it is > inexorably linked to that of the INVITE. When the INVITE-created > session terminates, that signals the termination of the negotiated > Info Packages. A UAS that receives an INFO message after the INVITE > dialog usage terminates MUST respond with a 481 Call Does Not Exist. This seems to apply to legacy usage as well (as it should). But perhaps it is not clear enough. I have encountered problems with that. I would recommend being very explicit that this applies to legacy usage, and was the intent of 2976 as well. > The session identifiers defined in RFC 3261 [RFC3261] must match > those of the provisional or final responses to the INVITE. As a > result, INFO requests cannot fork. The UAC may send INFO requests > once the UAS has sent the Recv-Info header field value, indicating > what the UAS supports. > > The converse is not true during initial session establishment. The > initiating UA of the first INVITE MUST be prepared to receive > multiple INFO requests, as the first INVITE may fork. Since session > negotiation has not completed, and we allow early INFO requests, > multiple target UAs may respond. This initial session establishment > phase is the only time the UAS need be prepared to receive multiple > INFO requests, as one would expect there may be messages from non- > authoritative forked dialogs prior to their termination. The point of the above is good, but the wording is problematic to me. Specifically "The converse" bothers me because it isn't the converse of anything. The point is that even though a given INFO cannot fork, an INVITE *can* fork, and the Initiating UAC must be prepared to receive INFO on any and all resulting INVITE dialog usages, whether early or final. How about the following for the second paragraph above: However, because an initial INVITE may fork, the initiating UA of the first INVITE MUST be prepared to receive INFO requests on any and all dialogs, early and confirmed, that result. Section 4.2: > If the Info Package definition directs the UAC to send a request > without a payload, the UAC MUST send the INFO request without a body. The above partially contradicts the next paragraph. So, I suggest replacing above with: If the Info Package definition directs the UAC to send a request without a payload and nothing else about the message requires a body part, the UAC MUST send the INFO request without a body. (I left the last requirement at MUST strength, but I wonder if it ought to be that strong.) It would also probably read better if this were moved down just before: > If there is no payload for the Info Package, they UAC MAY omit the > Content-Disposition header. Regarding the following: > NOTE: We could be lazy and even save 33 octets by allowing the UAC > to construct a non-multipart MIME payload without a Content- > Disposition header. However, mandating the presence makes parsing > considerably easier, and it is easier to have it required now than > run into a problem later. I guess this would be defining a per-request-type default for C-D. AFAIK we don't have that now, though we do have per-content-type C-D defaults. The more of that we do the more complex the rules become for inferring the right thing. And we also have the issue of legacy use of INFO, which futher complicates things. So I agree its better to require this. Section 4.3: > If a UAS receives an INFO request, it MUST send a final response. A > UAS MUST send a 200 OK response for an INFO request with no message > body and no Info-Package header if the UAS received the INFO request > on an existing session. This protocol action supports legacy use of > INFO as a keep-alive mechanism. I know this is trying to preserve legacy behavior. But the MUST is still a bit strong. In particular, it must still be possible to reject the message for cause. In particular, the UAS must be able to send a 401 response if it is requiring per-message authentication and the necessary info is missing or wrong. And it must be able to send a 500 response if the CSeq is too small. And there are probably other cases where error responses are appropriate. So how about: If a UAS receives an INFO request, it MUST send a final response. A UAS MUST send a 200 OK response for an INFO request with no message body and no Info-Package header if there is no non-INFO-specific reason to reject the message. This protocol action supports legacy use of INFO as a keep-alive mechanism. Or maybe this can be better related to the last paragraph in this section, which does address the sending of such errors. Currently it isn't clear that paragraph applies to this case. > If the UAS receives an INFO request with an Info-Package the UAS > advertised with a Recv-Info in the last session state update and the > body of the INFO request is an appropriate MIME type for the Info > Package, the UAS MUST send a 200 OK response. I think it would be useful to add a note clarifying this: NOTE: Errors in info-package-specific or application-specific processing of the Info Package, other than MIME type conformance, are not to result in a failure response. > 4.5. Behavior of Registrars > > Registrars receiving a REGISTER request that includes Recv-Info > headers MAY store such information and use it for routing purposes. > How the registrar uses this information is beyond the scope of this > document. Hmm. I don't recall this. Maybe I've just forgotten. It seems a bit mysterious and unmotivated. Without some normative behavior, it seems useless. AFAIK there are no comparable statements for other headers that might be equally interesting for routing purposes. If you want the possibility of having the capability to route based on the ability to receive particular info packages, then we should probably add a new callee-capability that could be used for this purpose. Section 7.5: > The UAS MUST enumerate every MIME type associated with the Info > Packages advertised in the UAS' Recv-Info header the UAS is willing > to receive. If a UAC sends a body that includes something not > enumerated by the UAS, this is a protocol error and the UAS MUST > respond appropriately. I'm really confused here by the use of UAC and UAS (vs. Initiating UA and Target UA, and generally what this is about. Enumerate *where*? Is this saying that the message containing Recv-Info must also include an Accept header enumerating the content-types associated with the packages it lists? If so, must it accept *all* the content-types associated with a package? Or if the package supports alternative content types, can it simply accept a subset that works for the package? Section 8: > extension-method = INFOm / token This is supposed to be updating 3261, so I think this is supposed to be: extension-method /= INFOm / token > Info-package-param = token name=value not allowed for params??? s/token/generic-param/ Section 9.5: > Please add the following registration to the Content-Disposition > registry. The description suitable for the IANA registry is as > follows. > > The payload of the message carrying this Content-Disposition header > field value is the payload of an Info Package. The above is missing the "following registration" giving the name of the C-D being defined. Section A.2: > Some uses of INFO can tolerate this fate sharing of the INFO message > over the entire session. For example, in the SIP-T usage, it may be > acceptable for a call to fail, or to tear down the call, if one > cannot deliver the associated SS7 information. The same is usually > true for DTMF. However, it may not be acceptable for a call to fail > if, for example, a DTMF buffer overflows. Then again, for some > services, that may be the exact desired behavior. This is another case where all the words are true, but the implication is not. Specifically, if the DTMF buffer were to overflow, that would be an application level issue. It would not cause the INFO message carrying it to fail, and so would not cause the INVITE-usage to fail. Section A.3: > There is no throttling mechanism for INFO. Consider that most call > signaling occurs on the order of 7-10 messages per 3 minutes, > although with a burst of 5-7 messages in one second during call > setup. DTMF tones occur in bursts at a rate of up to 20 messages per > second. This is a considerably higher rate than for call signaling. > Sending constant GPS location updates, on the other hand, would incur > an undue burden on SIP Proxies along the path. *Which* other hand is being referenced? (There seem to be two other hands.) How about: Sending constant GPS location updates would place an even larger burden on SIP Proxies along the path. Section A.4: > path. In fact, SIUBSCRIBE/NOTIFY is your only option if you need to > exchange data outside a communications session. This is a little overreaching. Perhaps: path. In fact, SIUBSCRIBE/NOTIFY is your only SIP signaling path option if you need to exchange data outside a communications session. Of course you subsequently mention MESSAGE, which is another exception. Section A.5.4: Maybe I'm mising something, but the content of this section seems in direct conflict with the mechanism defined in this draft. Its like this section is left over from a year or two ago before we decided to go with info packages. What am I not getting? That's it. I could find nothing else. Thanks!!! Paul From ietf.hanserik@gmail.com Fri Jul 17 13:13:22 2009 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 711BD28C1EF for ; Fri, 17 Jul 2009 13:13:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.471 X-Spam-Level: X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.127, 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 Ys+f7mljvh3w for ; Fri, 17 Jul 2009 13:13:21 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 3A7E43A6F00 for ; Fri, 17 Jul 2009 13:12:54 -0700 (PDT) Received: by ewy26 with SMTP id 26so1132073ewy.37 for ; Fri, 17 Jul 2009 13:13:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=3EkOUZ2QhUYZv1pwJYx53cJJE5XLcRmnhQ6caTjJDxI=; b=nnUDo/aZlV1GPh9+4QmnWv922E2It44Adml92r64m76E3cEfWqjajjYFPWUCod4aN9 TQ+l09FiolE/pJ4elpEB9QbGZys7e/w0dYESVqxJnCEtSiaLNtR36ugy1UrvpiLRkFVU DgUJdQeanjp1Rvavc6yyRPXkyAPqRCnAdG1NY= 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=DPonEgNo2C+10wRPEuZVaN6QcqmQ3Ar+2QhAX8An5+gdXklXEk6V0rvap474N6Ehsl vlOnwqJqFPuXIsowrp38Lek0F2Z5QsShK35GyoILDEbPfGhCHWTlpQgs31nosL8NvCjn NUbNfTG14LFQmG0Ngae80ZdOU46cDLhgiSBxY= MIME-Version: 1.0 Received: by 10.210.79.3 with SMTP id c3mr1778643ebb.84.1247861605752; Fri, 17 Jul 2009 13:13:25 -0700 (PDT) In-Reply-To: References: <4A5FAF4E.4030901@cisco.com> Date: Fri, 17 Jul 2009 22:13:25 +0200 Message-ID: <9ae56b1e0907171313u6b7e09c3hd0eee3399a4ae681@mail.gmail.com> From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=0015174c4616bd6043046eec6b24 Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 17 Jul 2009 20:13:22 -0000 --0015174c4616bd6043046eec6b24 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit inline... /Hans Erik van Elburg On Fri, Jul 17, 2009 at 4:52 PM, Hadriel Kaplan wrote: > > > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: Thursday, July 16, 2009 8:37 PM > > > > >> Say I call sip:+1234567890@sp.com ;user=phone. > My proxy is "sp.com", > > >> right? > > >> > > >> Then sp.net does ENUM query. > > Did you intend for this to be "sp.net" and thus a different domain from " > sp.com"? Or was that a typo? I am assuming it was a typo. > > > > > If we assume that ENUM qualifies as a location service (and I am now > > > convinced that it does), then this URI *is* an AOR in sp.com. > > > > No, because it's not the right domain. It's doing the ENUM on a phone > > number. So it really has nothing to do with a SIP scheme (a condition > > for AOR, remember?). > > Regardless of whether ENUM is doing it on a phone number sans domain or > not, it MUST be marked as an "aor". Think of it this way: > Suppose you call "sip:+18005551212@sp.com ", > and sp.com does an ENUM lookup on 18005551212, and the NAPTR result > translated it to the non-800 specific number for it. The > freephone-model/redirection-usage NEEDs to see that 18005551212. No? No. The aor tag has nothing todo with the freephone case, for that case the "mp" tag or in its absence the first H-I entry is important to be able to determine the original called target. > > > That's also why I think you'd want Tel-URI's - because sp.com could have > received a Tel-URI with it and done that ENUM lookup. > > > And in fact, it goes to example.com, not sp.com > > So? As far as the sp.com Proxy cares, it has done an ENUM lookup and > gotten a result which changes the req-uri and makes it route the call. As > far as it knows, "sip:+1234567890@example.com" > is a contact address of a PSTN-Gateway or registered UA, in which case per > the rules "sip:+1234567890@sp.com " WAS an > AoR; whereas if "sip:+1234567890@example.com" > is another peer domain then it's not an AoR?? > The question is if it matters in this case. > > -hadriel > --0015174c4616bd6043046eec6b24 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable inline...
/Hans Erik van Elburg


On Fri, Jul 17, 2009 at 4:52 PM, Hadriel= Kaplan <HKa= plan@acmepacket.com> wrote:


> -----Original Message-----
> From: Francois Audet [mailto:audet= @nortel.com]
> Sent: Thursday, July 16, 2009 8:37 PM
>
> >> Say I call sip:= +1234567890@sp.com;user=3Dphone. My proxy is "sp.com",
> >> right?
> >>
> >> Then sp.net d= oes ENUM query.

Did you intend for this to be "sp.net" and thus a different domain f= rom "sp.com"? =A0= Or was that a typo? =A0I am assuming it was a typo.


> > If we assume that ENUM qualifies as a location service (and I am = now
> > convinced that it does), then this URI *is* an AOR in sp.com.
>
> No, because it's not the right domain. It's doing the ENUM on = a phone
> number. So it really has nothing to do with a SIP scheme (a condition<= br> > for AOR, remember?).

Regardless of whether ENUM is doing it on a phone number sans domain = or not, it MUST be marked as an "aor". =A0Think of it this way: Suppose you call "sip:+= 18005551212@sp.com", and sp.com does an ENUM lookup on 18005551212, and the NAPTR result tran= slated it to the non-800 specific number for it. =A0The freephone-model/red= irection-usage NEEDs to see that 18005551212. No?

No. The aor tag has nothing todo with the freephone cas= e, for that case the "mp" tag or in its absence =A0the first H-I = entry is important to be able to determine the original called target.

=A0


That's also why I think you'd want Tel-URI's - because sp.com could have received a Tel-U= RI with it and done that ENUM lookup.

> And in fact, it goes to example.com, not sp.com<= /a>

So? =A0As far as the sp.c= om Proxy cares, it has done an ENUM lookup and gotten a result which ch= anges the req-uri and makes it route the call. =A0As far as it knows, "= ;sip:+1234567890@example= .com" is a contact address of a PSTN-Gateway or registered UA, in = which case per the rules "sip:+1234567890@sp.com" WAS an AoR; whereas if "sip:+1234567890@example.com&quo= t; is another peer domain then it's not an AoR??

The questio= n is if it matters in this case.
=A0

-hadriel

--0015174c4616bd6043046eec6b24-- From jmpolk@cisco.com Fri Jul 17 14:02:43 2009 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 75A833A6DD8 for ; Fri, 17 Jul 2009 14:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.385 X-Spam-Level: X-Spam-Status: No, score=-6.385 tagged_above=-999 required=5 tests=[AWL=0.214, 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 Q2Wn1yU+0jvy for ; Fri, 17 Jul 2009 14:02:41 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 848DA3A67E4 for ; Fri, 17 Jul 2009 14:02:41 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhoMAB+EYEqrR7MV/2dsb2JhbAAwiBOvX4gjLQiQSQWCKA0KAwUIgT6Jbw X-IronPort-AV: E=Sophos;i="4.43,223,1246838400"; d="scan'208";a="187395595" Received: from sj-dkim-1.cisco.com ([171.71.179.21]) by sj-iport-2.cisco.com with ESMTP; 17 Jul 2009 21:03:14 +0000 Received: from sj-core-5.cisco.com (sj-core-5.cisco.com [171.71.177.238]) by sj-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6HL3Fsw025118; Fri, 17 Jul 2009 14:03:15 -0700 Received: from xbh-sjc-211.amer.cisco.com (xbh-sjc-211.cisco.com [171.70.151.144]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id n6HL3FW2019831; Fri, 17 Jul 2009 21:03:15 GMT Received: from xfe-sjc-212.amer.cisco.com ([171.70.151.187]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 14:03:14 -0700 Received: from jmpolk-wxp01.cisco.com ([10.89.9.13]) by xfe-sjc-212.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 17 Jul 2009 14:03:14 -0700 X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 17 Jul 2009 16:03:13 -0500 To: Jon Peterson , Marc Linsner From: "James M. Polk" In-Reply-To: <4A60B810.60405@neustar.biz> References: <4A60B810.60405@neustar.biz> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Message-ID: X-OriginalArrivalTime: 17 Jul 2009 21:03:14.0455 (UTC) FILETIME=[000C0270:01CA0722] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=16034; t=1247864595; x=1248728595; c=relaxed/simple; s=sjdkim1004; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=jmpolk@cisco.com; z=From:=20=22James=20M.=20Polk=22=20 |Subject:=20Re=3A=20[sipcore]=20FW=3A=20Confusion=20over=20 target=20inSIP=0A=20=20location-conveyance=20-=20andimpact=2 0on=20ECRIT=20phonebcp |Sender:=20; bh=aY0P9453jFkqqnMqusO6DW7zVRzKAhWu7sNfu0It+rg=; b=CK1HzA1T2lMJExSanzJ0n27WytnyNbu0aNdJ26J09sKG18Y6h18af7HBjM tGN/rETESnZD0M253CSm40C/21eX8wLKtVndgJNxC7S1XQfU969Nue/Yvi94 VHu3FzHapnJwIaWjEwRbMWuFEAJxJR+83iwzqaSyy8XF29p6uoUzI=; Authentication-Results: sj-dkim-1; header.From=jmpolk@cisco.com; dkim=pass ( sig from cisco.com/sjdkim1004 verified; ); Cc: sipcore@ietf.org, "Thomson, Martin" Subject: Re: [sipcore] FW: Confusion over target inSIP location-conveyance - andimpact on ECRIT phonebcp 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, 17 Jul 2009 21:02:43 -0000 Jon Specific to your last paragraph below, I think Marc is arguing that this HELD server doesn't form a RFC 4479 (or is it 3863?) compliant PIDF in the first place. James BTW - I don't believe he is arguing that Geopriv MUST treat everything like it's a person (we all know Geopriv covers much more than people), but if it *is* a person (that's the target), that person should be treated according to 4479, not as a palette. ;-) At 12:42 PM 7/17/2009, Jon Peterson wrote: >I don't think it's fair to say that a URI generated by the HELD >server is this case cannot designate a "Person" per the data model. >It merely doesn't designate a person with an address-of-record style >name (like the Presentity URI, which is what I gather you'd prefer >to see in the entity attribute). A person can be the resource >identified by any number of URIs, and there's no requirement that >they all display human-readable niceties. At a high level, I think >you can cast this problem as linking that pseudonym with a >well-known URI of the user. > >Moreover, considering the applicability of geopriv broadly, I would >hesitate to assert that presence documents must be about people, >perhaps especially for the case where presence documents contain >location information. We've talked many times about tracking >inanimate objects like palettes with geopriv, for example. RFC4479 >is certainly written from the perspective that presence is about >people, and although there are people involved in the location of >palettes (notably the owner/shipper of the palette, who probably >would act as a Rule Maker and thus exert the "person"-level controls >per the data model), it is not the location of those people we are >tracking, but the location of a separate target. > >Finally, I do think there is a distinction architecturally between >this usage of HELD and of LCP, since effectively the HELD server >here acts as an LG, not as a LIS. While we can argue the wisdom of >this approach, I think the role it instantiates in the architecture >is not especially ambiguous. > >Jon Peterson >NeuStar, Inc. > >Marc Linsner wrote: >>Jon, Martin, >> >>In reviewing RFC4479, I'm struggling with the premise that one can convey a >>location value via SIP in a document that has no Person component in the >>Presentity. My interpretation of RFC4479 is that a Presence document MUST >>contain Person data within the Presentity data model, it's the top of the >>hierarchy. Therefore lack of Person data renders the document not valid. >>I've always viewed the locationResponse sent from a HELD server as Location >>Configuration Information (LCI), equivalent to LCI returned by DHCP (or >>LLDPMED). (Of course, this is contrary to the implication in the HELD draft >>and might need to be addressed before publication.) Hence, the LCI data is >>not a valid Presence document until the UA completes/changes the Presentity >>attributes. >> >>I'm not sure overriding the Person data (or lack thereof) in the Presentity >>by simply appending ";me" is correct, nor should it be allowed. This runs >>contrary to the premise that the two documents should stand alone without >>dependencies on one another. >> >>What am I missing? >> >>-Marc- >> >> >> >> >>>My own interest in this discussion has largely been to prevent the >>>conflation of the UAC with the geopriv target. I've argued that the >>>UAC and the entity in the From header field value are not >>>necessarily equivalent for the purposes of geopriv, thanks to >>>aggregator UAs serving many users, such as IP PBXs, gateways and so >>>forth. I've therefore resisted the proposal that the implicit >>>semantics of the Geolocation header be "this is the location of the >>>UAC." I feel less strongly about semantics of "this is the location >>>of the entity in the From header field", be they implicit or >>>explicit semantics. I can certainly imagine a version of the ";me" >>>parameter as an explicit indication of these semantics that would >>>not fall afoul of this conflation. >>> >>>I do wonder, though, if the semantics of "routing-allowed" overlap >>>with the intention behind ";me". Ultimately, a proxy server decides >>>whether or not it will use the location in the SIP request for >>>routing purposes. Your use case below assumes that the proxy server >>>decision to route based on location is dependent on the PIDF >>>referenced in the SIP request indicating the same target as the SIP >>>layer identity. While ";me" is helpful in that case, I'm not sure >>>that this should be the deciding criteria in all cases. >>>"routing-allowed" communicates a less specific indication of "hey, I >>>think you can use this to route the request", something that could >>>be true even if, for whatever reason, the location in the SIP >>>request doesn't represent the target of my SIP-layer identity, >>>because due to some unusual circumstances the From header field of >>>my request can't have a value that represents "me" at the moment - >>>maybe it's an anonymous URI, for example. >>> >>>My point here is that I think agreement on the sorts of policies >>>that proxy servers should enforce has to inform the sorts of >>>indications we feed into that policy. If we need a way to tell the >>>proxy server that a referenced location is appropriate for routing, >>>we might want something more explicit than ";me". >>> >>>To your postscript, I'd have to say no, there's no necessary >>>equivalence between the resources indicated by those two schemes, >>>only convention links them. >>> >>>Jon Peterson >>>NeuStar, Inc. >>> >>>Thomson, Martin wrote: >>> >>>>Hi Jon, >>>> >>>>Here's the problem: >>>>I am sip:mt@andrew.com. I use HELD or DHCP to request a location >>>>URI. This is what is put in my SIP INVITE. A proxy dereferences >>>>this to determine where to route the call. They encounter >>>>pres:v76ns38907v6e05@lis.example.com in the resulting PIDF-LO. The >>>>location information is ignored; it's not applicable to the requester. >>>> >>>>The server that provides the location information has no basis to >>>>determine that the entity making a request and sip:mt@andrew.com >>>>are one and the same. Thus, it cannot make this assertion. HELD >>>>recommends the creation of a pseudonym for this reason. >>>> >>>>How do we resolve this? >>>> >>>>We could define a mechanism for asserting sip identity in other >>>>domains, such that HELD could use it. Sounds a bit heavyweight to me. >>>> >>>>Providing a linkage between the two in SIP might work, but it >>>>sounds like you don't want to do that. Shame, because that's the >>>>easiest. One simple way would be to add a ';me' parameter to the >>>>geolocation header, which links the UAC (identified in From:) to >>>>the location object, irrespective of the identified presentity. >>>> >>>>--Martin >>>> >>>>p.s. On a similar thread, I think I remember reading that >>>>sip:mt@andrew.com is the same as pres:mt@andrew.com. Is this >>>>guaranteed truth, or just highly likely? >>>> >>>> >>>> >>>>>-----Original Message----- >>>>>From: Jon Peterson [mailto:jon.peterson@neustar.biz] >>>>>Sent: Wednesday, 15 July 2009 3:11 PM >>>>>To: Thomson, Martin >>>>>Cc: Brian Rosen; Elwell, John; James M. Polk; sipcore@ietf.org >>>>>Subject: Re: [sipcore] Confusion over target inSIP location-conveyance >>>>>- andimpact on ECRIT phonebcp >>>>> >>>>> >>>>>There must be something I'm missing in this discussion, but I've found >>>>>this issue with identity binding a bit elusive. PIDF documents (let >>>>>alone PIDF-LO documents) necessarily contain a field designating the >>>>>entity that the document is supposed to represent - the "entity" >>>>>attribute of . Given that this attribute contains a URI, it >>>>>can be as specific or opaque as is necessary for the application in >>>>>question. It appears regardless of how the PIDF document is acquired >>>>>(by >>>>>reference or by value). In what way is this element insufficient >>>>>exactly? >>>>> >>>>>I would certainly be skeptical of any SIP-layer mechanism that is >>>>>intended to provide a separate account of how a PIDF document is >>>>>"bound" >>>>>to the entity it represents. >>>>> >>>>>Jon Peterson >>>>>NeuStar, Inc. >>>>> >>>>>Thomson, Martin wrote: >>>>> >>>>> >>>>>>I still haven't seen an explanation on how to resolve the identity >>>>>> >>>>>> >>>>>binding problem when location is provided by reference. That's a small >>>>>thing for phone-bcp, but not for location-conveyance. >>>>> >>>>> >>>>>>>-----Original Message----- >>>>>>>From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On >>>>>>>Behalf Of Brian Rosen >>>>>>>Sent: Wednesday, 15 July 2009 6:10 AM >>>>>>>To: 'Elwell, John'; 'James M. Polk'; sipcore@ietf.org >>>>>>>Subject: Re: [sipcore] Confusion over target inSIP location- >>>>>>> >>>>>>> >>>>>conveyance >>>>> >>>>> >>>>>>>- andimpact on ECRIT phonebcp >>>>>>> >>>>>>>I have raised this very issue with James, and verified it with Jon >>>>>>>Peterson >>>>>>>and Robert Sparks, and the intention is that the Geolocation header >>>>>>> >>>>>>> >>>>>can >>>>> >>>>> >>>>>>>carry the location of any target, the specific target being that >>>>>>>identified >>>>>>>in the PIDF, and subject to the privacy requirements of that target. >>>>>>> >>>>>>>It turns out to be useful to do this in a couple of cases I've run >>>>>>>across, >>>>>>>although I'm somewhat surprised that everyone agreed it is okay to >>>>>>> >>>>>>> >>>>>do >>>>> >>>>> >>>>>>>so. >>>>>>> >>>>>>>While I guess I could improve phonebcp by making an explicit >>>>>>> >>>>>>> >>>>>statement >>>>> >>>>> >>>>>>>that, >>>>>>>when sent to the PSAP, the location in the header must be that of >>>>>>> >>>>>>> >>>>>the >>>>> >>>>> >>>>>>>caller, I do think it's clear enough that it is. >>>>>>> >>>>>>>I'll do that in the next rev, although I don't want to hold up >>>>>>> >>>>>>> >>>>>sending >>>>> >>>>> >>>>>>>the >>>>>>>current version to the IESG over that tidbit. >>>>>>> >>>>>>>Brian >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>>-----Original Message----- >>>>>>>>From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] >>>>>>>>Sent: Tuesday, July 14, 2009 2:40 AM >>>>>>>>To: James M. Polk; sipcore@ietf.org; Brian Rosen >>>>>>>>Subject: Confusion over target inSIP location-conveyance - and >>>>>>>> >>>>>>>> >>>>>impact >>>>> >>>>> >>>>>>>>on ECRIT phonebcp >>>>>>>> >>>>>>>>In 4.2 it states: >>>>>>>>"The UAC can use whatever means it knows of to verify/refresh its >>>>>>>> location information before attempting a new request that >>>>>>>> >>>>>>>> >>>>>includes >>>>> >>>>> >>>>>>>> location." >>>>>>>>"its location information" suggests that the UAC is the target. >>>>>>>> >>>>>>>>In 4.3.3 it states: >>>>>>>>"This document gives no guidance how this is accomplished, given >>>>>>>> >>>>>>>> >>>>>the >>>>> >>>>> >>>>>>>> number of ways a UAC can learn its location" >>>>>>>>which suggests similar. >>>>>>>> >>>>>>>>Similarly in 6.1: >>>>>>>>"If a UAC does not learn and store its location locally (a GPS >>>>>>>> >>>>>>>> >>>>>chip) >>>>> >>>>> >>>>>>>> or from the network (DHCP or LLDP-MED), the UAC MAY learn its >>>>>>>> >>>>>>>> >>>>>LbyR >>>>> >>>>> >>>>>>>> URI (from DHCP for example)." >>>>>>>>Which suggests that a UAC inserts its location, not some other >>>>>>>>location. >>>>>>>> >>>>>>>>And later in 6.1: >>>>>>>>"If a UAC has already conveyed location in the original request of >>>>>>>> >>>>>>>> >>>>>a >>>>> >>>>> >>>>>>>> transaction, and wants to update its location information ..." >>>>>>>> >>>>>>>>In 6.2: >>>>>>>>"If the LbyR URI is >>>>>>>> sip:, sips: or pres:, and the UAS wants to learn the UAC's >>>>>>>>location," >>>>>>>> >>>>>>>>In 6.2.1: >>>>>>>>"This >>>>>>>> means the SIP server is including its version of where it thinks >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>the >>>>>>> >>>>>>> >>>>>>> >>>>>>>> UAC is, geographically." >>>>>>>> >>>>>>>>In 8: >>>>>>>>"Conveyance of physical location of a UAC raises privacy concerns" >>>>>>>> >>>>>>>>and: >>>>>>>>"In cases where a session set-up is >>>>>>>> retargeted based on the location of the UAC initiating the call >>>>>>>> >>>>>>>> >>>>>or >>>>> >>>>> >>>>>>>> SIP MESSAGE," >>>>>>>> >>>>>>>>All these many examples illustrate an implication that the location >>>>>>>>target is the UAC. I am sure there are other places too. >>>>>>>> >>>>>>>>I found a couple of places that contradict this. In 6.2 it states: >>>>>>>>"If there >>>>>>>> is more than one PIDF-LO with different Target identifiers, then >>>>>>>> the UAC is merely telling the UAS where more than one Target is, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>and >>>>>>> >>>>>>> >>>>>>> >>>>>>>> there should not be any conflict." >>>>>>>> >>>>>>>>I think there are other places that mention locations of multiple >>>>>>>>targets in a request, implying they cannot all be the location of >>>>>>>> >>>>>>>> >>>>>the >>>>> >>>>> >>>>>>>>UAC. >>>>>>>> >>>>>>>>And in 6.2.1 it states: >>>>>>>>"The Location Target identified in >>>>>>>> the PIDF-LO may or may not be the location inserter, or the >>>>>>>> generator of the request (the UAC or SIP server)." >>>>>>>> >>>>>>>>So we have inconsistency as to whether a conveyed location is that >>>>>>>> >>>>>>>> >>>>>of >>>>> >>>>> >>>>>>>>they UAC or not. >>>>>>>> >>>>>>>>One document that relies on location-conveyance is ECRIT's >>>>>>>> >>>>>>>> >>>>>phonebcp. >>>>> >>>>> >>>>>>>In >>>>>>> >>>>>>> >>>>>>> >>>>>>>>there, I cannot find any reference to a routing entity looking to >>>>>>>> >>>>>>>> >>>>>see >>>>> >>>>> >>>>>>>>whether a conveyed location has the caller as target or not. It >>>>>>>> >>>>>>>> >>>>>just >>>>> >>>>> >>>>>>>>assumes that this is the case. So if we were to agree that a >>>>>>>> >>>>>>>> >>>>>conveyed >>>>> >>>>> >>>>>>>>location is not necessarily the location of the UAC, this will have >>>>>>>>impact on phonebcp. >>>>>>>> >>>>>>>>John >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>_______________________________________________ >>>>>>>sipcore mailing list >>>>>>>sipcore@ietf.org >>>>>>>https://www.ietf.org/mailman/listinfo/sipcore >>>>>>> >>>>>>> >>>>>>> >>>>>>--------------------------------------------------------------------- >>>>>> >>>>>> >>>>>--------------------------- >>>>> >>>>> >>>>>>This message is for the designated recipient only and may >>>>>>contain privileged, proprietary, or otherwise private information. >>>>>>If you have received it in error, please notify the sender >>>>>>immediately and delete the original. Any unauthorized use of >>>>>>this email is prohibited. >>>>>>--------------------------------------------------------------------- >>>>>> >>>>>> >>>>>--------------------------- >>>>> >>>>> >>>>>>[mf2] >>>>>>_______________________________________________ >>>>>>sipcore mailing list >>>>>>sipcore@ietf.org >>>>>>https://www.ietf.org/mailman/listinfo/sipcore >>>>>> >>>>>> >>>>>> >>>>------------------------------------------------------------------------------ >>>> >>------------------ >> >>>>This message is for the designated recipient only and may >>>>contain privileged, proprietary, or otherwise private information. >>>>If you have received it in error, please notify the sender >>>>immediately and delete the original. Any unauthorized use of >>>>this email is prohibited. >>>>------------------------------------------------------------------------------ >>>> >>------------------ >> >>>>[mf2] >>>> >>>> >> >> >> >> > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From HKaplan@acmepacket.com Fri Jul 17 14:43:23 2009 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 89FBF3A6EFF for ; Fri, 17 Jul 2009 14:43:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.001, 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 ORj23TJIg-KC for ; Fri, 17 Jul 2009 14:43:17 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 1BD933A690B for ; Fri, 17 Jul 2009 14:43:06 -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.1.375.2; Fri, 17 Jul 2009 17:43:38 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 17 Jul 2009 17:43:38 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg Date: Fri, 17 Jul 2009 17:43:37 -0400 Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoHGxj+vQo9Uv2tRNSdIrNhmJoOSgAC8mAQ Message-ID: References: <4A5FAF4E.4030901@cisco.com> <9ae56b1e0907171313u6b7e09c3hd0eee3399a4ae681@mail.gmail.com> In-Reply-To: <9ae56b1e0907171313u6b7e09c3hd0eee3399a4ae681@mail.gmail.com> 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_E6C2E8958BA59A4FB960963D475F7AC3196C795F89mail_" MIME-Version: 1.0 Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 17 Jul 2009 21:43:23 -0000 --_000_E6C2E8958BA59A4FB960963D475F7AC3196C795F89mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable I'm confused (I know, not a hard thing to make me be apparently :(). In a previous chain of emails I thought the purpose of the "mp" flag was to= indicate a retarget happened, but that the subsequent "aor" flagged URI wa= s what would actually be used for applications, because it is the "cleaned-= up" form of the URI being retargeted to, since it actually identifies what = the authoritative domain which got it claims it location-service routed wit= h. Your response indicates that the "mp" flagged URI would actually be used by= the application, even when it does not have an "aor" flag (as it would not= in this case). Which is it? Or are the cases different for different application uses, fo= r which flags are important? -hadriel ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] Sent: Friday, July 17, 2009 4:13 PM To: Hadriel Kaplan Cc: Francois Audet; Paul Kyzivat; SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? inline... /Hans Erik van Elburg On Fri, Jul 17, 2009 at 4:52 PM, Hadriel Kaplan > wrote: > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Thursday, July 16, 2009 8:37 PM > > >> Say I call sip:+1234567890@sp.com;u= ser=3Dphone. My proxy is "sp.com", > >> right? > >> > >> Then sp.net does ENUM query. Did you intend for this to be "sp.net" and thus a different = domain from "sp.com"? Or was that a typo? I am assuming it= was a typo. > > If we assume that ENUM qualifies as a location service (and I am now > > convinced that it does), then this URI *is* an AOR in sp.com. > > No, because it's not the right domain. It's doing the ENUM on a phone > number. So it really has nothing to do with a SIP scheme (a condition > for AOR, remember?). Regardless of whether ENUM is doing it on a phone number sans domain or not= , it MUST be marked as an "aor". Think of it this way: Suppose you call "sip:+18005551212@sp.com", and sp.com does an ENUM lookup on 18005551212, and the = NAPTR result translated it to the non-800 specific number for it. The free= phone-model/redirection-usage NEEDs to see that 18005551212. No? No. The aor tag has nothing todo with the freephone case, for that case the= "mp" tag or in its absence the first H-I entry is important to be able to= determine the original called target. That's also why I think you'd want Tel-URI's - because sp.com could have received a Tel-URI with it and done that ENUM lookup. > And in fact, it goes to example.com, not sp.com So? As far as the sp.com Proxy cares, it has done an ENUM l= ookup and gotten a result which changes the req-uri and makes it route the = call. As far as it knows, "sip:+1234567890@example.com" is a contact address of a PSTN-Gateway or registered = UA, in which case per the rules "sip:+1234567890@sp.com" WAS an AoR; whereas if "sip:+1234567890@example.com" is another peer domain then it's not an = AoR?? The question is if it matters in this case. -hadriel --_000_E6C2E8958BA59A4FB960963D475F7AC3196C795F89mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

I’m confused (I know, not a hard thing to make me be apparently L).

In a previous chain of emails I though= t the purpose of the “mp” flag was to indicate a retarget happene= d, but that the subsequent “aor” flagged URI was what would actual= ly be used for applications, because it is the “cleaned-up” form of t= he URI being retargeted to, since it actually identifies what the authoritativ= e domain which got it claims it location-service routed with.

 

Your response indicates that the ̶= 0;mp” flagged URI would actually be used by the application, even when it does no= t have an “aor” flag (as it would not in this case).

 

Which is it?  Or are the cases di= fferent for different application uses, for which flags are important?

 

-hadriel

 

From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
Sent: Friday, July 17, 2009 = 4:13 PM
To: Hadriel Kaplan
Cc: Francois Audet; Paul Kyzivat; SIPC= ORE
Subject: Re: [sipcore] rfc42= 44bis: what is an AoR?

 

inline...
/Hans Erik van Elburg

On Fri, Jul 17, 2009 at 4:52 PM, Hadriel Kaplan <HKaplan@acmepacket.com> wrote= :



> -----Original Message-----
> From: Francois Audet [mailto:audet= @nortel.com]

> Sent: Thursd= ay, July 16, 2009 8:37 PM
>
> >> Say I call sip:= +1234567890@sp.com;user=3Dphone. My proxy is "sp.com&qu= ot;,
> >> right?
> >>
> >> Then sp.net d= oes ENUM query.

Did you intend fo= r this to be "sp.net" an= d thus a different domain from "sp.= com"?  Or was that a typo?  I am assuming it was a typo.


> > If we assume that ENUM qualifies as a location service (and I am = now
> > convinced that it does), then this URI *is* an AOR in sp.com.
>
> No, because it's not the right domain. It's doing the ENUM on a phone<= br> > number. So it really has nothing to do with a SIP scheme (a condition<= br> > for AOR, remember?).

Regardless of whether ENUM is doing it on a phone number sans domai= n or not, it MUST be marked as an "aor".  Think of it this way: Suppose you call "sip:+= 18005551212@sp.com", and sp.com does an ENUM loo= kup on 18005551212, and the NAPTR result translated it to the non-800 specific num= ber for it.  The freephone-model/redirection-usage NEEDs to see that 18005551212. No?

 

No. The aor tag has nothing todo with the freephone case, for that = case the "mp" tag or in its absence  the first H-I entry is impor= tant to be able to determine the original called target.

 

 



That's also why I think you'd want Tel-URI's - because sp.com could have received a Tel-URI with it and done= that ENUM lookup.


> And in fact, it goes to example.com, not sp.com

So?  As far as the sp.com Proxy cares, it has done an ENUM lookup and gotten a result which changes t= he req-uri and makes it route the call.  As far as it knows, "sip:+1234567890@example.com= " is a contact address of a PSTN-Gateway or registered UA, in which case per = the rules "sip:+1234567890@s= p.com" WAS an AoR; whereas if "sip:+1234567890@example.com" is another peer domain then it's not an AoR??

 

The question is if it matters in this case.

 


-hadriel

 

--_000_E6C2E8958BA59A4FB960963D475F7AC3196C795F89mail_-- From HKaplan@acmepacket.com Fri Jul 17 14:50:48 2009 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 2A7553A6B53 for ; Fri, 17 Jul 2009 14:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=0.002, 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 RMK+jlyX7JC1 for ; Fri, 17 Jul 2009 14:50:47 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id D99EB3A6EFF for ; Fri, 17 Jul 2009 14:50:44 -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.1.375.2; Fri, 17 Jul 2009 17:51:17 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 17 Jul 2009 17:51:17 -0400 From: Hadriel Kaplan To: "Dawes, Peter, VF-Group" , "L.Liess@telekom.de" Date: Fri, 17 Jul 2009 17:51:16 -0400 Thread-Topic: [sipcore] draft-kaplan-sip-session-id-02 Thread-Index: Acn1DaU1pu17VvRRTd+gHdXlHhTG9AOmEHkwAAGgysAAavX4kABqQ4Zw Message-ID: References: <1245876685.3748.61.camel@victoria-pingtel-com.us.nortel.com> <40FB0FFB97588246A1BEFB05759DC8A00330040F@S4DE9JSAANI.ost.t-com.de> 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" , "Gerold.Pinker@telekom.de" , "dworley@nortel.com" , "R.Jesske@telekom.de" , "Martin.Huelsemann@telekom.de" Subject: Re: [sipcore] draft-kaplan-sip-session-id-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: Fri, 17 Jul 2009 21:50:48 -0000 > -----Original Message----- > From: Dawes, Peter, VF-Group [mailto:Peter.Dawes@vodafone.com] > Sent: Wednesday, July 15, 2009 10:47 AM > Subject: RE: [sipcore] draft-kaplan-sip-session-id-02 >=20 > Hello Laura, > Thanks for the very interesting extra perspective. Does your traffic > monitoring solution pass all SIP signalling through this 'separate > device for monitoring', and does this device record all network activity > all the time? I ask because one thing that the session-id-02 draft does > not seem to help with is how you identity a particular session you are > interested in. Since session-id is very similar to Call-ID, it doesn't > seem very different from recording everything and then searching based > on Call-ID. With regards to identifying a particular session you're interested in, I'm = not sure if you mean that in the sense of: 1) Once I know I want Session X, how do I find the messages for it?=20 Or... 2) How do I even decide Session X is what I want to log? =20 The answer to the first question is: using the Session-ID. And Session-ID = is different from a Call-ID, purely because it gets through B2BUA's. If yo= u determine you want to find all SIP messages from a given Call-ID, you hav= e to take into account that the Call-ID changes along the path. Some of th= e devices change it due to security reasons, which is what I wrote http://t= ools.ietf.org/html/draft-kaplan-sip-secure-call-id-00 to try to avoid - but= some devices change it for very different, unavoidable reasons. You can r= ecord everything all day long, but you have to figure out what inbound dial= og is associated with what outbound dialog(s) in the B2BUA's along the path= , to actually troubleshoot it. So Session-ID is to solve that problem. For the question (2) semantically that is more of a "filter" question, than= an identifier once the filter is triggered. It's just asking "what filter= s do I want to use, in order to choose which calls to debug?" In other wor= ds, deciding what session to analyze is a separate thing from identifying w= hich messages are part of the same session. In your debug draft, the "filt= er" is the set of things in the XML identified by the and <= stop-trigger> elements, for things like target URI's and time. The debug d= raft just ties those together with the message identifier, so that it can o= nly be done in real-time, and in a certain way. (I think) -hadriel From ietf.hanserik@gmail.com Fri Jul 17 23:57:44 2009 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 3086928C335 for ; Fri, 17 Jul 2009 23:57:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.002 X-Spam-Level: X-Spam-Status: No, score=0.002 tagged_above=-999 required=5 tests=[BAYES_50=0.001, 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 dKlBWZilrAb1 for ; Fri, 17 Jul 2009 23:57:42 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 64F963A697C for ; Fri, 17 Jul 2009 23:54:58 -0700 (PDT) Received: by ewy26 with SMTP id 26so1322437ewy.37 for ; Fri, 17 Jul 2009 23:54:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=zWPCapddPl+eYCUiAuoBt3Oml8DBL+0MjzZwZaBjefM=; b=JtVTLnNWgzggrLnizue/TU00Bhv4OUCmmaBxStklAIRtne0VxJxeR9xx9ukYnARR4q 5WBL2/2ZWRtVLfGRGzQGqw1w9Sb1veCBfrAf25ndLAidZIEKXq+IunBtX0Aml3Woa42c 1xTybl9yNukashbrscyCk9U1TSQ4whbnFTPxw= 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=Ii/B8cFlONh5XeZOiZtkxaRcj4x8qnUOECbBVGiK6Z/ZmJOCv+cUIWrR0b7gXbXG8A zR0Nlts0fTEQiDy1MVpofIEf93Vboir3yQqZ+RsjnBIbPmLjns/pzjw3GwZ792to7PZe GXUExHUfZu3022pC6+L+GrlOYl5doIebE3cOY= MIME-Version: 1.0 Received: by 10.210.76.6 with SMTP id y6mr816364eba.4.1247900094514; Fri, 17 Jul 2009 23:54:54 -0700 (PDT) In-Reply-To: References: <4A5FAF4E.4030901@cisco.com> <9ae56b1e0907171313u6b7e09c3hd0eee3399a4ae681@mail.gmail.com> Date: Sat, 18 Jul 2009 08:54:54 +0200 Message-ID: <9ae56b1e0907172354q353f23ffla9fd0c6a0f55d2cd@mail.gmail.com> From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=0015174be074d94879046ef56147 Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 18 Jul 2009 06:57:44 -0000 --0015174be074d94879046ef56147 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Yes the relevant flags are dependent on what you in your role of UAS would like to retrieve. The rules would be very simple. To retrieve the addressed target (freephone, etc): - traverse all H-I entries backward until an "mp" entry is found, if found this is the addressed target - if no "mp" found take the first H-I entry - if no History-Info header take the Request-URI value To retrieve the last aor before it was overwritten by contact address (similar as P-Called-Party-ID): - traverse all H-I entries backward until an "aor" entry is found, if found this is the last AOR used /Hans Erik van Elburg On Fri, Jul 17, 2009 at 11:43 PM, Hadriel Kaplan wr= ote: > I=92m confused (I know, not a hard thing to make me be apparently L). > > In a previous chain of emails I thought the purpose of the =93mp=94 flag = was to > indicate a retarget happened, but that the subsequent =93aor=94 flagged U= RI was > what would actually be used for applications, because it is the =93cleane= d-up=94 > form of the URI being retargeted to, since it actually identifies what th= e > authoritative domain which got it claims it location-service routed with. > > > > Your response indicates that the =93mp=94 flagged URI would actually be u= sed by > the application, even when it does not have an =93aor=94 flag (as it woul= d not > in this case). > > > > Which is it? Or are the cases different for different application uses, > for which flags are important? > > > > -hadriel > > > ------------------------------ > > *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > *Sent:* Friday, July 17, 2009 4:13 PM > *To:* Hadriel Kaplan > *Cc:* Francois Audet; Paul Kyzivat; SIPCORE > > *Subject:* Re: [sipcore] rfc4244bis: what is an AoR? > > > > inline... > /Hans Erik van Elburg > > On Fri, Jul 17, 2009 at 4:52 PM, Hadriel Kaplan > wrote: > > > > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > > Sent: Thursday, July 16, 2009 8:37 PM > > > > >> Say I call sip:+1234567890@sp.com ;user= =3Dphone. > My proxy is "sp.com", > > >> right? > > >> > > >> Then sp.net does ENUM query. > > Did you intend for this to be "sp.net" and thus a different domain from " > sp.com"? Or was that a typo? I am assuming it was a typo. > > > > > If we assume that ENUM qualifies as a location service (and I am now > > > convinced that it does), then this URI *is* an AOR in sp.com. > > > > No, because it's not the right domain. It's doing the ENUM on a phone > > number. So it really has nothing to do with a SIP scheme (a condition > > for AOR, remember?). > > Regardless of whether ENUM is doing it on a phone number sans domain or > not, it MUST be marked as an "aor". Think of it this way: > Suppose you call "sip:+18005551212@sp.com ", > and sp.com does an ENUM lookup on 18005551212, and the NAPTR result > translated it to the non-800 specific number for it. The > freephone-model/redirection-usage NEEDs to see that 18005551212. No? > > > > No. The aor tag has nothing todo with the freephone case, for that case t= he > "mp" tag or in its absence the first H-I entry is important to be able t= o > determine the original called target. > > > > > > > > That's also why I think you'd want Tel-URI's - because sp.com could have > received a Tel-URI with it and done that ENUM lookup. > > > > And in fact, it goes to example.com, not sp.com > > So? As far as the sp.com Proxy cares, it has done an ENUM lookup and > gotten a result which changes the req-uri and makes it route the call. A= s > far as it knows, "sip:+1234567890@example.com" > is a contact address of a PSTN-Gateway or registered UA, in which case pe= r > the rules "sip:+1234567890@sp.com " WAS an > AoR; whereas if "sip:+1234567890@example.com" > is another peer domain then it's not an AoR?? > > > > The question is if it matters in this case. > > > > > -hadriel > > > --0015174be074d94879046ef56147 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
Yes the relevant flags are dependent on what you in your role of UAS w= ould like =A0to retrieve.

The rules would be very simpl= e.

To retrieve the addressed target (freephone, etc):=A0=
- traverse all H-I entries backward until an "mp" entry is f= ound, if found this is the addressed target
- if no "mp"= ; found take the first H-I entry
- if no History-Info header take= the Request-URI value

To retrieve the last aor before it was overwritten by c= ontact address=A0(similar as P-Called-Party-ID):=A0
- traver= se all H-I entries backward until an "aor" entry is found, if fou= nd this is the last AOR used

/Hans Erik van Elburg

On Fri, Jul 17, 2009 at 11:43 PM, Hadriel Ka= plan <HKapla= n@acmepacket.com> wrote:

I=92m confused (I know, not a hard thing to make me be apparently L<= span style=3D"font-size:10.0pt;font-family:Arial;color:navy">).

In a previous chain of emails I though= t the purpose of the =93mp=94 flag was to indicate a retarget happened, but that the subsequent =93aor=94 flagged URI was what would actually be used for applications, because it is the =93cleaned-up=94 form of the URI being retargeted to, since it actually identifies what the authoritativ= e domain which got it claims it location-service routed with.

=A0

Your response indicates that the =93mp= =94 flagged URI would actually be used by the application, even when it does no= t have an =93aor=94 flag (as it would not in this case).

=A0

Which is it?=A0 Or are the cases diffe= rent for different application uses, for which flags are important?

=A0

-hadriel

=A0

From: Hans Eri= k van Elburg [mailto:ietf.h= anserik@gmail.com]
Sent: Friday, July 17, 2009 = 4:13 PM
To: Hadriel Kaplan
Cc: Francois Audet; Paul Kyz= ivat; SIPCORE


Subject: Re: [sipcore] rfc42= 44bis: what is an AoR?

=A0

inline...
/Hans Erik van Elburg

On Fri, Jul 17, 2009 at 4:52 PM, Hadriel Kaplan <HKaplan@acmepacket.com> wrot= e:



> -----Original Message-----
> From: Francois Audet [mailto:audet@nortel.com]

> Sent: Thursday, July 16, 2009 8:37 PM
>
> >> Say I call sip:+1234567890@sp.com;user=3Dphone. My proxy is "sp.com&qu= ot;,
> >> right?
> >>
> >> Then sp.net d= oes ENUM query.

Did you intend for this to be "sp.net" an= d thus a different domain from "sp.= com"? =A0Or was that a typo? =A0I am assuming it was a typo.


> > If we assume that ENUM qualifies as a location service (and I am = now
> > convinced that it does), then this URI *is* an AOR in sp.com.
>
> No, because it's not the right domain. It's doing the ENUM on = a phone
> number. So it really has nothing to do with a SIP scheme (a condition<= br> > for AOR, remember?).

Regardless of whether ENUM is doing it on a phone number sans domain or not, it MUST be marked as an "aor". =A0Think of it this way:
Suppose you call "sip:+18005551212@sp.com", and sp.com does an ENUM loo= kup on 18005551212, and the NAPTR result translated it to the non-800 specific num= ber for it. =A0The freephone-model/redirection-usage NEEDs to see that 18005551212. No?

=A0

No. The aor tag has nothing todo with the freephone case, for that case the "mp" tag or in its absence =A0the first H-I entry is importan= t to be able to determine the original called target.

=A0

=A0



That's also why I think you'd want Tel-URI's - because sp.com could have received a Tel-U= RI with it and done that ENUM lookup.


> And in fact, it goes to example.com, not sp.com

So? =A0As far as the sp.com<= /a> Proxy cares, it has done an ENUM lookup and gotten a result which changes t= he req-uri and makes it route the call. =A0As far as it knows, "sip:+12345678= 90@example.com" is a contact address of a PSTN-Gateway or registered UA, in which case per = the rules "sip:+1234567890@sp.com" WAS an AoR; whereas if "sip:+1234567890@example.com" is another peer domain then it's not an AoR??

=A0

The question is if it matters in this case.

=A0


-hadriel

=A0


--0015174be074d94879046ef56147-- From HKaplan@acmepacket.com Sat Jul 18 09:12:00 2009 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 DDFE33A6A5E for ; Sat, 18 Jul 2009 09:12:00 -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 lKiOYN9un-vq for ; Sat, 18 Jul 2009 09:11:52 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 37FF33A68F2 for ; Sat, 18 Jul 2009 09:11:52 -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.1.375.2; Sat, 18 Jul 2009 12:11:41 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sat, 18 Jul 2009 12:11:40 -0400 From: Hadriel Kaplan To: Hans Erik van Elburg Date: Sat, 18 Jul 2009 12:11:38 -0400 Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoHdLUdY9OeHMbHQVK2xQ/NHVH5bgATJPZg Message-ID: References: <4A5FAF4E.4030901@cisco.com> <9ae56b1e0907171313u6b7e09c3hd0eee3399a4ae681@mail.gmail.com> <9ae56b1e0907172354q353f23ffla9fd0c6a0f55d2cd@mail.gmail.com> In-Reply-To: <9ae56b1e0907172354q353f23ffla9fd0c6a0f55d2cd@mail.gmail.com> 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_E6C2E8958BA59A4FB960963D475F7AC3196C7960C9mail_" MIME-Version: 1.0 Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 18 Jul 2009 16:12:01 -0000 --_000_E6C2E8958BA59A4FB960963D475F7AC3196C7960C9mail_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Doesn't it seem wrong/dangerous to you that one application would use the "= mp" flagged entry as a target, while another application uses the "aor" fla= gged entry as a target? I mean really they're all looking for "targets", r= ight? One's just looking for the "last redirected-to" target, and the othe= r's looking for the "last resolved-to" target. No? The point made by Francois in one of the emails (which made a lot of sense = to me) was that you basically had to use the "aor" ones because anything el= se is just that local proxy's view of what its routing to, including any lo= cally-specific "ugliness", pre-translation et al; whereas the "aor" one was= what the actual targeted domain saw and used for location-service resoluti= on and therefore was "authoritative". -hadriel ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] Sent: Saturday, July 18, 2009 2:55 AM To: Hadriel Kaplan Cc: Francois Audet; Paul Kyzivat; SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? Yes the relevant flags are dependent on what you in your role of UAS would = like to retrieve. The rules would be very simple. To retrieve the addressed target (freephone, etc): - traverse all H-I entries backward until an "mp" entry is found, if found = this is the addressed target - if no "mp" found take the first H-I entry - if no History-Info header take the Request-URI value To retrieve the last aor before it was overwritten by contact address (simi= lar as P-Called-Party-ID): - traverse all H-I entries backward until an "aor" entry is found, if found= this is the last AOR used /Hans Erik van Elburg On Fri, Jul 17, 2009 at 11:43 PM, Hadriel Kaplan > wrote: I'm confused (I know, not a hard thing to make me be apparently :(). In a previous chain of emails I thought the purpose of the "mp" flag was to= indicate a retarget happened, but that the subsequent "aor" flagged URI wa= s what would actually be used for applications, because it is the "cleaned-= up" form of the URI being retargeted to, since it actually identifies what = the authoritative domain which got it claims it location-service routed wit= h. Your response indicates that the "mp" flagged URI would actually be used by= the application, even when it does not have an "aor" flag (as it would not= in this case). Which is it? Or are the cases different for different application uses, fo= r which flags are important? -hadriel ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] Sent: Friday, July 17, 2009 4:13 PM To: Hadriel Kaplan Cc: Francois Audet; Paul Kyzivat; SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? inline... /Hans Erik van Elburg On Fri, Jul 17, 2009 at 4:52 PM, Hadriel Kaplan > wrote: > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Thursday, July 16, 2009 8:37 PM > > >> Say I call sip:+1234567890@sp.com;u= ser=3Dphone. My proxy is "sp.com", > >> right? > >> > >> Then sp.net does ENUM query. Did you intend for this to be "sp.net" and thus a different = domain from "sp.com"? Or was that a typo? I am assuming it= was a typo. > > If we assume that ENUM qualifies as a location service (and I am now > > convinced that it does), then this URI *is* an AOR in sp.com. > > No, because it's not the right domain. It's doing the ENUM on a phone > number. So it really has nothing to do with a SIP scheme (a condition > for AOR, remember?). Regardless of whether ENUM is doing it on a phone number sans domain or not= , it MUST be marked as an "aor". Think of it this way: Suppose you call "sip:+18005551212@sp.com", and sp.com does an ENUM lookup on 18005551212, and the = NAPTR result translated it to the non-800 specific number for it. The free= phone-model/redirection-usage NEEDs to see that 18005551212. No? No. The aor tag has nothing todo with the freephone case, for that case the= "mp" tag or in its absence the first H-I entry is important to be able to= determine the original called target. That's also why I think you'd want Tel-URI's - because sp.com could have received a Tel-URI with it and done that ENUM lookup. > And in fact, it goes to example.com, not sp.com So? As far as the sp.com Proxy cares, it has done an ENUM l= ookup and gotten a result which changes the req-uri and makes it route the = call. As far as it knows, "sip:+1234567890@example.com" is a contact address of a PSTN-Gateway or registered = UA, in which case per the rules "sip:+1234567890@sp.com" WAS an AoR; whereas if "sip:+1234567890@example.com" is another peer domain then it's not an = AoR?? The question is if it matters in this case. -hadriel --_000_E6C2E8958BA59A4FB960963D475F7AC3196C7960C9mail_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Doesn’t it seem wrong/dangerous = to you that one application would use the “mp” flagged entry as a target, while another application uses the “aor” flagged entry = as a target?  I mean really they’re all looking for “targets= 221;, right?  One’s just looking for the “last redirected-toR= 21; target, and the other’s looking for the “last resolved-to”= ; target.  No?

 

The point made by Francois in one of t= he emails (which made a lot of sense to me) was that you basically had to use = the “aor” ones because anything else is just that local proxy’s view of what it= s routing to, including any locally-specific “ugliness”, pre-tran= slation et al; whereas the “aor” one was what the actual targeted domai= n saw and used for location-service resolution and therefore was “autho= ritative”.

 

-hadriel

 

From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
Sent: Saturday, July 18, 200= 9 2:55 AM
To: Hadriel Kaplan
Cc: Francois Audet; Paul Kyzivat; SIPC= ORE
Subject: Re: [sipcore] rfc42= 44bis: what is an AoR?

 

Yes the relevant flags are dependent on what you in your role of UA= S would like  to retrieve.

 

The rules would be very simple.

 

To retrieve the addressed target (freephone, etc): =

- traverse all H-I entries backward until an "mp" entry i= s found, if found this is the addressed target

- if no "mp" found take the first H-I entry

- if no History-Info header take the Request-URI value

 

To retrieve the last aor before it was overwritten by contact address (similar as P-Called-Party-ID): =

- traverse all H-I entries backward until an "aor" entry = is found, if found this is the last AOR used

 

/Hans Erik van Elburg

On Fri, Jul 17, 2009 at 11:43 PM, Hadriel Kaplan <HKaplan@acmepacket.com> wrote= :

I’m confused (I know, not a hard thing to make me b= e apparently L= ).

In a previous chain of emails I thought the purpose of th= e “mp” flag was to indicate a retarget happened, but that the subsequent “aor” flagged URI was what would actually be used fo= r applications, because it is the “cleaned-up” form of the URI be= ing retargeted to, since it actually identifies what the authoritative domain w= hich got it claims it location-service routed with.

 

Your response indicates that the “mp” flagged= URI would actually be used by the application, even when it does not have an “aor” flag (as it would not in this case).

 

Which is it?  Or are the cases different for differe= nt application uses, for which flags are important?

 

-hadriel

 

From: = Hans Erik van Elburg [mailto:ietf.hanserik@gma= il.com]
Sent: Friday, July 17, 2009 = 4:13 PM
To: Hadriel Kaplan
Cc: Francois Audet; Paul Kyzivat; SIPC= ORE


Subject: Re: [sipcore] rfc42= 44bis: what is an AoR?

 

<= span style=3D'font-size:12.0pt'>inline...
/Hans Erik van Elburg

On Fri, Jul 17, 2009 at 4:52 PM, Hadriel Kaplan <HKaplan@acmepacket= .com> wrote:



> -----Original Message-----
> From: Francois Audet [mailto:audet@nortel.com]

<= span style=3D'font-size:12.0pt'>> Sent: Thursday, July 16, 2009 8:37 PM
>
> >> Say I call sip:+1234567890@sp.com;user=3Dphone. My proxy is &quo= t;sp.com",
> >> right?
> >>
> >> Then sp.net d= oes ENUM query.

<= span style=3D'font-size:12.0pt'>Did you intend for this to be "sp.net" and thus a differ= ent domain from "sp.com&qu= ot;?  Or was that a typo?  I am assuming it was a typo.


> > If we assume that ENUM qualifies as a location service (and I am = now
> > convinced that it does), then this URI *is* an AOR in sp.com.
>
> No, because it's not the right domain. It's doing the ENUM on a phone<= br> > number. So it really has nothing to do with a SIP scheme (a condition<= br> > for AOR, remember?).

Regardless of whether ENUM is doing it on a phone number sans domain or not, it MUST b= e marked as an "aor".  Think of it this way:
Suppose you call "sip:+18005551212@sp.com", and sp.com does an ENUM lookup on 18005551212, and the NA= PTR result translated it to the non-800 specific number for it.  The freephone-model/redirection-usage NEEDs to see that 18005551212. No?

 

No. The aor tag has nothing todo with the freephone case, for that case the "mp" tag or in its absence  the first H-I entry is important= to be able to determine the original called target.

 

 



That's also why I think you'd want Tel-URI's - because sp.com could have received a Tel-URI with it and done= that ENUM lookup.

<= span style=3D'font-size:12.0pt'>
> And in fact, it goes to example.com, not sp.com

So?  As far as the sp.com = Proxy cares, it has done an ENUM lookup and gotten a result which changes the req= -uri and makes it route the call.  As far as it knows, "sip:+1234= 567890@example.com" is a contact address of a PSTN-Gateway or registered UA, in which case per = the rules "sip:+1234567890@sp.com" WAS an AoR; whereas if "sip:+1234567890@example.com" is another peer dom= ain then it's not an AoR??

 

The question is if it matters in this case.

 


-hadriel

 

 

--_000_E6C2E8958BA59A4FB960963D475F7AC3196C7960C9mail_-- From ietf.hanserik@gmail.com Sun Jul 19 01:30:17 2009 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 5B6CA3A68DA for ; Sun, 19 Jul 2009 01:30:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.298 X-Spam-Level: X-Spam-Status: No, score=-1.298 tagged_above=-999 required=5 tests=[AWL=1.300, 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 ewNR64nSQoD4 for ; Sun, 19 Jul 2009 01:30:15 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id CE07C3A68C5 for ; Sun, 19 Jul 2009 01:30:14 -0700 (PDT) Received: by ewy26 with SMTP id 26so1700733ewy.37 for ; Sun, 19 Jul 2009 01:30:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=m7hEDdhQE0XuuEldvV0vHdlCptng3VDX1VSAlwndFsw=; b=PZJMJfMRmNn0yjSwILon85aTVvBtwwCiY8x+r6SX0cK3SMGieUlP4pOFCmrWwquarB WcpnfYdTNFCIUUMi3k+fQSCvgz11ztrZgUUL7NxIlIsomHwGx+Ybx6uc/uwTSks1YqBe 7NvvuBE+VtJ5UupkmFM/nSweR/o4+B36HshsE= 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=nP6Vg+ZO7ODEqEf8cRbCFGC0jjaPE/QAd3dc+6mBZ94EmRVkEgLTYXfs0yilv+1hmZ j2nQqjJ9OqoO5fyU5nVWsVPm8vwo9d4H5NsNPnI9AI4q5ve8XhVg4lATwPmb3FNFz2RS hlr+wCdE6yFXz/gL33Ubs0Qlg/A401e5FXMkU= MIME-Version: 1.0 Received: by 10.210.53.1 with SMTP id b1mr2038059eba.62.1247992212106; Sun, 19 Jul 2009 01:30:12 -0700 (PDT) In-Reply-To: References: <4A5FAF4E.4030901@cisco.com> <9ae56b1e0907171313u6b7e09c3hd0eee3399a4ae681@mail.gmail.com> <9ae56b1e0907172354q353f23ffla9fd0c6a0f55d2cd@mail.gmail.com> Date: Sun, 19 Jul 2009 10:30:12 +0200 Message-ID: <9ae56b1e0907190130h7038db2dr8ac0ef793b57eed8@mail.gmail.com> From: Hans Erik van Elburg To: Hadriel Kaplan Content-Type: multipart/alternative; boundary=0015174c3f0a7c3072046f0ad4b1 Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 19 Jul 2009 08:30:17 -0000 --0015174c3f0a7c3072046f0ad4b1 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable No not really, it is only different application retrieving different bits o= f information. What is important is that they can extract this information. /Hans Erik van Elburg On Sat, Jul 18, 2009 at 6:11 PM, Hadriel Kaplan wro= te: > > > Doesn=92t it seem wrong/dangerous to you that one application would use t= he > =93mp=94 flagged entry as a target, while another application uses the = =93aor=94 > flagged entry as a target? I mean really they=92re all looking for =93ta= rgets=94, > right? One=92s just looking for the =93last redirected-to=94 target, and= the > other=92s looking for the =93last resolved-to=94 target. No? > > > > The point made by Francois in one of the emails (which made a lot of sens= e > to me) was that you basically had to use the =93aor=94 ones because anyth= ing > else is just that local proxy=92s view of what its routing to, including = any > locally-specific =93ugliness=94, pre-translation et al; whereas the =93ao= r=94 one > was what the actual targeted domain saw and used for location-service > resolution and therefore was =93authoritative=94. > > > > -hadriel > > > ------------------------------ > > *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > *Sent:* Saturday, July 18, 2009 2:55 AM > > *To:* Hadriel Kaplan > *Cc:* Francois Audet; Paul Kyzivat; SIPCORE > *Subject:* Re: [sipcore] rfc4244bis: what is an AoR? > > > > Yes the relevant flags are dependent on what you in your role of UAS woul= d > like to retrieve. > > > > The rules would be very simple. > > > > To retrieve the addressed target (freephone, etc): > > - traverse all H-I entries backward until an "mp" entry is found, if foun= d > this is the addressed target > > - if no "mp" found take the first H-I entry > > - if no History-Info header take the Request-URI value > > > > To retrieve the last aor before it was overwritten by contact > address (similar as P-Called-Party-ID): > > - traverse all H-I entries backward until an "aor" entry is found, if fou= nd > this is the last AOR used > > > > /Hans Erik van Elburg > > On Fri, Jul 17, 2009 at 11:43 PM, Hadriel Kaplan > wrote: > > I=92m confused (I know, not a hard thing to make me be apparently L). > > In a previous chain of emails I thought the purpose of the =93mp=94 flag = was to > indicate a retarget happened, but that the subsequent =93aor=94 flagged U= RI was > what would actually be used for applications, because it is the =93cleane= d-up=94 > form of the URI being retargeted to, since it actually identifies what th= e > authoritative domain which got it claims it location-service routed with. > > > > Your response indicates that the =93mp=94 flagged URI would actually be u= sed by > the application, even when it does not have an =93aor=94 flag (as it woul= d not > in this case). > > > > Which is it? Or are the cases different for different application uses, > for which flags are important? > > > > -hadriel > > > ------------------------------ > > *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > *Sent:* Friday, July 17, 2009 4:13 PM > *To:* Hadriel Kaplan > *Cc:* Francois Audet; Paul Kyzivat; SIPCORE > > > *Subject:* Re: [sipcore] rfc4244bis: what is an AoR? > > > > inline... > /Hans Erik van Elburg > > On Fri, Jul 17, 2009 at 4:52 PM, Hadriel Kaplan > wrote: > > > > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > > Sent: Thursday, July 16, 2009 8:37 PM > > > > >> Say I call sip:+1234567890@sp.com ;user= =3Dphone. > My proxy is "sp.com", > > >> right? > > >> > > >> Then sp.net does ENUM query. > > Did you intend for this to be "sp.net" and thus a different domain from " > sp.com"? Or was that a typo? I am assuming it was a typo. > > > > > If we assume that ENUM qualifies as a location service (and I am now > > > convinced that it does), then this URI *is* an AOR in sp.com. > > > > No, because it's not the right domain. It's doing the ENUM on a phone > > number. So it really has nothing to do with a SIP scheme (a condition > > for AOR, remember?). > > Regardless of whether ENUM is doing it on a phone number sans domain or > not, it MUST be marked as an "aor". Think of it this way: > Suppose you call "sip:+18005551212@sp.com ", > and sp.com does an ENUM lookup on 18005551212, and the NAPTR result > translated it to the non-800 specific number for it. The > freephone-model/redirection-usage NEEDs to see that 18005551212. No? > > > > No. The aor tag has nothing todo with the freephone case, for that case t= he > "mp" tag or in its absence the first H-I entry is important to be able t= o > determine the original called target. > > > > > > > > That's also why I think you'd want Tel-URI's - because sp.com could have > received a Tel-URI with it and done that ENUM lookup. > > > > And in fact, it goes to example.com, not sp.com > > So? As far as the sp.com Proxy cares, it has done an ENUM lookup and > gotten a result which changes the req-uri and makes it route the call. A= s > far as it knows, "sip:+1234567890@example.com" > is a contact address of a PSTN-Gateway or registered UA, in which case pe= r > the rules "sip:+1234567890@sp.com " WAS an > AoR; whereas if "sip:+1234567890@example.com" > is another peer domain then it's not an AoR?? > > > > The question is if it matters in this case. > > > > > -hadriel > > > > > --0015174c3f0a7c3072046f0ad4b1 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable
No not really, it is only different application retrieving different b= its of information. What is important is that they can extract this informa= tion.

/Hans Erik van Elburg


On Sat, Jul 18, 2009 at 6:11 PM, Hadriel= Kaplan <HKa= plan@acmepacket.com> wrote:

=A0

Doesn=92t it seem wrong/dangerous to you that one application would use the =93mp=94 flagged entry as a target, while another application uses the =93aor=94 flagged entry as a target?=A0 I mean really they=92re all looking for =93targets=94, right?=A0 One=92s just looking for the =93last redirected-to=94 target, and the other=92s looking for the =93last resolved-to=94 target.=A0 No?

=A0

The point made by Francois in one of t= he emails (which made a lot of sense to me) was that you basically had to use = the =93aor=94 ones because anything else is just that local proxy=92s view of what its routing to, including any locally-specific =93ugliness=94, pre-translation et al; whereas the =93aor=94 one was what the actual targeted domain saw and used for location-service resolution and therefore was =93authorita= tive=94.

=A0

-hadriel

=A0

From: Hans Eri= k van Elburg [mailto:ietf.h= anserik@gmail.com]
Sent: Saturday, July 18, 200= 9 2:55 AM


To: Hadriel Kaplan
Cc: Francois Audet; Paul Kyz= ivat; SIPCORE
Subject: Re: [sipcore] rfc42= 44bis: what is an AoR?

=A0

Yes the relevant flags are dependent on what you in your role of UAS would like =A0to retrieve.

=A0

The rules would be very simple.

=A0

To retrieve the addressed target (freephone, etc):=A0

- traverse all H-I entries backward until an "mp" entry is found, if found this is the addressed target

- if no "mp" found take the first H-I entry

- if no History-Info header take the Request-URI value

=A0

To retrieve the last aor before it was overwritten by contact address=A0(similar as P-Called-Party-ID):=A0

- traverse all H-I entries backward until an "aor" entry is found, if found this is the last AOR used

=A0

/Hans Erik van Elburg

On Fri, Jul 17, 2009 at 11:43 PM, Hadriel Kaplan <HKaplan@acmepacket.com> wro= te:

I=92m confused (I know, not a hard thi= ng to make me be apparently L= ).

In a previous chain of emails I though= t the purpose of the =93mp=94 flag was to indicate a retarget happened, but that the subsequent =93aor=94 flagged URI was what would actually be used for applications, because it is the =93cleaned-up=94 form of the URI being retargeted to, since it actually identifies what the authoritative domain w= hich got it claims it location-service routed with.

=A0

Your response indicates that the =93mp= =94 flagged URI would actually be used by the application, even when it does not have an =93aor=94 flag (as it would not in this case).

=A0

Which is it?=A0 Or are the cases diffe= rent for different application uses, for which flags are important?

=A0

-hadriel

=A0

From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
Sent: Friday, July 17, 2009 = 4:13 PM
To: Hadriel Kaplan
Cc: Francois Audet; Paul Kyz= ivat; SIPCORE


Subject: Re: [sipcore] rfc42= 44bis: what is an AoR?

=A0

inline...
/Hans Erik van Elburg

On Fri, Jul 17, 2009 at 4:52 PM, Hadriel Kaplan <HKaplan@acmepacket.com> wrote:



> -----Original Message-----
> From: Francois Audet [mailto:audet@nortel.com]

> Sent: Thursday, July 16, 2009 8:37 P= M
>
> >> Say I call sip:+1234567890@sp.com;user=3Dphone. My proxy is "sp.com",
> >> right?
> >>
> >> Then sp.net d= oes ENUM query.

Did you intend for this to be "sp.net" and thus a differen= t domain from "sp.com&qu= ot;? =A0Or was that a typo? =A0I am assuming it was a typo.


> > If we assume that ENUM qualifies as a location service (and I am = now
> > convinced that it does), then this URI *is* an AOR in sp.com.
>
> No, because it's not the right domain. It's doing the ENUM on = a phone
> number. So it really has nothing to do with a SIP scheme (a condition<= br> > for AOR, remember?).

Regardless of whether ENUM is doing it on a phone number sans domain or not, it MUST b= e marked as an "aor". =A0Think of it this way:
Suppose you call "sip:+18005551212@sp.com", and sp.com does an ENUM lookup on 18005551212, and the= NAPTR result translated it to the non-800 specific number for it. =A0The freephone-model/redirection-usage NEEDs to see that 18005551212. No?=

=A0

No. The aor tag has nothing todo with the freephone case, for that case the "mp" tag or in its absence =A0the first H-I entry is important to be able to determine the original called target.

=A0

=A0



That's also why I think you'd want Tel-URI's - because sp.com could have received a Tel-U= RI with it and done that ENUM lookup.


> And in fact, it goes to example.com, not sp.com

So? =A0As far as the sp.com Pro= xy cares, it has done an ENUM lookup and gotten a result which changes the req= -uri and makes it route the call. =A0As far as it knows, "sip:+1234567890@example= .com" is a contact address of a PSTN-Gateway or registered UA, in which case per = the rules "sip:+1234567890@sp.com" WAS an AoR; whereas if "sip:+1234567890@example.com" is another pee= r domain then it's not an AoR??

=A0

The question is if it matters in this case.

=A0


-hadriel

=A0

=A0


--0015174c3f0a7c3072046f0ad4b1-- From dworley@nortel.com Sun Jul 19 12:55:07 2009 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 8AB693A69A5 for ; Sun, 19 Jul 2009 12:55:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.38 X-Spam-Level: X-Spam-Status: No, score=-5.38 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_24_48=1.219, 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 jJIOojCH-nuK for ; Sun, 19 Jul 2009 12:55:06 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 9FD3C3A6894 for ; Sun, 19 Jul 2009 12:55:06 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6JJrIM18055 for ; Sun, 19 Jul 2009 19:53:18 GMT Received: from [47.141.31.239] ([47.141.31.239]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 19 Jul 2009 15:55:00 -0400 From: "Dale Worley" To: "sipcore@ietf.org" In-Reply-To: References: <1245876685.3748.61.camel@victoria-pingtel-com.us.nortel.com> <40FB0FFB97588246A1BEFB05759DC8A00330040F@S4DE9JSAANI.ost.t-com.de> Content-Type: text/plain Organization: Nortel Networks Date: Fri, 17 Jul 2009 22:14:43 -0400 Message-Id: <1247883283.4025.2.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2009 19:55:01.0099 (UTC) FILETIME=[CD0AF3B0:01CA08AA] Subject: Re: [sipcore] draft-kaplan-sip-session-id-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, 19 Jul 2009 19:55:07 -0000 The Session-Id has a tremendous advantage over the "secure Call-Id": In a system that is not tightly managed by a central authority, middleboxes have no way of knowing whether a UA is generating "secure Call-Ids" or not. So they must replace all Call-Ids, subverting the UAs that are generating secure Call-Ids. But (absent malice on the part of UAs), Session-Ids are known to be secure, and middleboxes know not to replace them. So I think we should deprecate draft-kaplan-sip-secure-call-id in favor of draft-kaplan-sip-session-id. Dale From dworley@nortel.com Sun Jul 19 13:02:13 2009 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 6E98D3A6AC7 for ; Sun, 19 Jul 2009 13:02:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.989 X-Spam-Level: X-Spam-Status: No, score=-5.989 tagged_above=-999 required=5 tests=[AWL=0.610, 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 iaUQOi4kO9by for ; Sun, 19 Jul 2009 13:02:12 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 7C79F3A69A5 for ; Sun, 19 Jul 2009 13:02:12 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6JJrMM18061 for ; Sun, 19 Jul 2009 19:53:22 GMT Received: from [47.141.31.239] ([47.141.31.239]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Sun, 19 Jul 2009 15:55:01 -0400 From: "Dale Worley" To: SIPCORE Content-Type: text/plain Organization: Nortel Networks Date: Sun, 19 Jul 2009 15:55:00 -0400 Message-Id: <1248033300.4025.14.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 19 Jul 2009 19:55:02.0177 (UTC) FILETIME=[CDAF7110:01CA08AA] Subject: [sipcore] draft-barnes-sip-rfc4244bis-02: Supported: histinfo 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, 19 Jul 2009 20:02:13 -0000 There's another element that I do not understand in draft-barnes-sip-rfc4244bis (that is also copied from RFC 4244): The use of the 'histinfo' option-tag. Whereas RFC 3261 makes it clear that option-tags are to be used to test whether elements support extensions, in RFC 4244, histinfo is used (like so many option-tags) to request activation of optional processing. In the case of History-Info, there are no interoperation problems if an element adds History-Info but another element does not understand it. This means that there is no need to have an option-tag whose absence suppresses adding History-Info. In this case we can start to normalize the situation by allowing elements to add History-Info to requests/responses that do not contain "Supported: histinfo". Dale From HKaplan@acmepacket.com Sun Jul 19 17:55:54 2009 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 19BE328C161 for ; Sun, 19 Jul 2009 17:55:54 -0700 (PDT) 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 cx8vf5lolfUh for ; Sun, 19 Jul 2009 17:55:53 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 0A4C028C162 for ; Sun, 19 Jul 2009 17:54:02 -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.1.375.2; Sun, 19 Jul 2009 20:54:01 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Sun, 19 Jul 2009 20:53:59 -0400 From: Hadriel Kaplan To: Dale Worley , "sipcore@ietf.org" Date: Sun, 19 Jul 2009 20:53:59 -0400 Thread-Topic: [sipcore] draft-kaplan-sip-session-id-02 Thread-Index: AcoIqtSPtz9zA6BtTM6gsU7oe1O8AwAJuwTQ Message-ID: References: <1245876685.3748.61.camel@victoria-pingtel-com.us.nortel.com> <40FB0FFB97588246A1BEFB05759DC8A00330040F@S4DE9JSAANI.ost.t-com.de> <1247883283.4025.2.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1247883283.4025.2.camel@victoria-pingtel-com.us.nortel.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-kaplan-sip-session-id-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, 20 Jul 2009 00:55:54 -0000 Hi Dale, The thing is they're really trying to solve different things, though I know= I didn't do a good job explaining it at the last WG meeting. :( The secure-call-id is trying to provide a real Call-ID value which middlebo= xes won't change - for middleboxes that change it for the specific purpose = of privacy or topology-hiding. And by that I mean a real Call-ID: useful f= or dialog matching, the dialog-events package, and any of the things a Call= -ID value is used in (there are many, as you know). People put Call-ID values in all sorts of things, and expect it to work end= -to-end, and are "surprised" when something in the middle changed them. So= secure-call-id is trying to provide a Call-ID that won't be changed by tho= se middleboxes. It *will* still be changed by other B2BUA's, for example m= any IP-PBX's and App Servers change the Call-ID, and will continue doing so= . It's ok that they do - most of the applications which use Call-ID's are = targeted to those IP-PBXs/App-Servers, and they have some other reasons for= changing them. Session-ID is for something different: a session identifier which crosses a= ny form of middlebox including real/full B2BUA's, but is not used for the d= ialog-matching type things a Call-ID is used for. When I tried to use it f= or some of those other things, I got feedback with concern that it was subv= erting the Call-ID mechanism - if a B2BUA changed the Call-ID then it was u= nwise of me to try to second-guess it and bypass its replacement. I agreed= with that concern, so Session-ID is for troubleshooting purposes only at t= his time. So the two mechanisms are not at odds, nor are they alternatives for the sa= me thing. A middlebox which replaces Call-ID's *does* know if it's a secure-call-id. = If it has no '@', and no IP Addr/hostname format in it, it's sufficiently = benign to not change. -hadriel > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Dale Worley >=20 > The Session-Id has a tremendous advantage over the "secure Call-Id": In > a system that is not tightly managed by a central authority, middleboxes > have no way of knowing whether a UA is generating "secure Call-Ids" or > not. So they must replace all Call-Ids, subverting the UAs that are > generating secure Call-Ids. But (absent malice on the part of UAs), > Session-Ids are known to be secure, and middleboxes know not to replace > them. So I think we should deprecate draft-kaplan-sip-secure-call-id in > favor of draft-kaplan-sip-session-id. >=20 > Dale From gonzalo.camarillo@ericsson.com Mon Jul 20 01:01:18 2009 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 DE2793A6A88 for ; Mon, 20 Jul 2009 01:01:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.249 X-Spam-Level: X-Spam-Status: No, score=-4.249 tagged_above=-999 required=5 tests=[AWL=-2.000, BAYES_00=-2.599, HELO_EQ_SE=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 Oqiw0m4oZTmR for ; Mon, 20 Jul 2009 01:01:16 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id AC3233A6D16 for ; Mon, 20 Jul 2009 01:01:15 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-0d-4a64241982c9 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 4C.80.18827.914246A4; Mon, 20 Jul 2009 10:00:26 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 09:59:11 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 09:59:10 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 5521E245F; Mon, 20 Jul 2009 10:59:10 +0300 (EEST) Message-ID: <4A6423CE.7010601@ericsson.com> Date: Mon, 20 Jul 2009 10:59:10 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2009 07:59:10.0603 (UTC) FILETIME=[F6F71DB0:01CA090F] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] WGLC: draft-ietf-sipcore-location-conveyance-01.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, 20 Jul 2009 08:01:19 -0000 Folks, we would like to start the WGLC of the following draft: http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance-01 This WGLC will end on August 7th. Note that there are ongoing threads discussing this draft on the list. The idea is to take those comments as WGLC comments. Also note that we have another WGLC in parallel at this point (info events, whose WGLC ends on July 29th). We have chosen to have this partial overlap between the two WGLCs in order to take advantage of the extra cycles people put in on reviewing drafts during the pre-IETF week. Given that we have canceled the second SIPCORE session in Stockholm, we believe this is a reasonable amount of work for folks following this WG. Keith will be the PROTO shepherd for this draft. Thanks, Gonzalo SIPCORE co-chair From gonzalo.camarillo@ericsson.com Mon Jul 20 01:12:34 2009 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 0927D3A6D14 for ; Mon, 20 Jul 2009 01:12:34 -0700 (PDT) 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=[AWL=-1.000, BAYES_00=-2.599, HELO_EQ_SE=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 j6eJ-GY-Io9U for ; Mon, 20 Jul 2009 01:12:33 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id D4BAD3A6AFC for ; Mon, 20 Jul 2009 01:12:32 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-15-4a642684155b Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id DF.A1.18827.486246A4; Mon, 20 Jul 2009 10:10:44 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 10:09:02 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 10:09:01 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id C3A99245F for ; Mon, 20 Jul 2009 11:09:01 +0300 (EEST) Message-ID: <4A64261D.6020206@ericsson.com> Date: Mon, 20 Jul 2009 11:09:01 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: SIPCORE References: <4A5B318B.6020206@ericsson.com> In-Reply-To: <4A5B318B.6020206@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2009 08:09:02.0032 (UTC) FILETIME=[577C0500:01CA0911] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Adopting the invfix draft as a WG item? 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, 20 Jul 2009 08:12:34 -0000 Hi, thanks for the feedback. We will be asking the authors of this draft to submit it as a SIPCORE WG item after the blackout period. Thanks, Gonzalo SIPCORE co-chair Gonzalo Camarillo wrote: > Folks, > > the following draft documents important fixes to RFC 3261. > > http://tools.ietf.org/html/draft-sparks-sipcore-invfix-00 > > (This draft has been around for a while as draft-sparks-sip-invfix.) > > Our charter includes working on essential corrections to RFC 3261. > Therefore, we would like to ask the WG whether or not we should adopt > this draft as a WG item. > > If we adopt this draft, the idea will be to WGLC it. Then, we would > advance it in whatever way we decide essential corrections should be > advanced (how to document essential corrections is being discussed in a > different thread on this mailing list). > > Thanks, > > Gonzalo > SIPCORE co-chair > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From gonzalo.camarillo@ericsson.com Mon Jul 20 01:23:58 2009 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 EDB5E3A6A2E for ; Mon, 20 Jul 2009 01:23:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.916 X-Spam-Level: X-Spam-Status: No, score=-4.916 tagged_above=-999 required=5 tests=[AWL=1.333, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 9QecojcleM7B for ; Mon, 20 Jul 2009 01:23:58 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 8688C3A68BE for ; Mon, 20 Jul 2009 01:23:57 -0700 (PDT) X-AuditID: c1b4fb3c-b7ba4ae0000038c0-41-4a642966e57a Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 13.FC.14528.669246A4; Mon, 20 Jul 2009 10:23:02 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 10:23:02 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 10:23:02 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id DEEDB245F; Mon, 20 Jul 2009 11:23:01 +0300 (EEST) Message-ID: <4A642965.9000803@ericsson.com> Date: Mon, 20 Jul 2009 11:23:01 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: sipcore@ietf.org References: <20090504221501.62CC83A6C6D@core3.amsl.com> <4A15D085.9070704@nostrum.com> <4A420EB3.6020308@ericsson.com> In-Reply-To: <4A420EB3.6020308@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2009 08:23:02.0168 (UTC) FILETIME=[4C3E9980:01CA0913] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-sec-flows-00.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, 20 Jul 2009 08:23:59 -0000 Hi, again, we would like to encourage people to have a look at this draft. Don't forget that this is an official SIPCORE WG item. Cheers, Gonzalo Gonzalo Camarillo wrote: > Folks, > > we would like to encourage people once more to have a look at this draft > and send their comments to the list. > > Thanks, > > Gonzalo > SIPCORE co-chair > > Adam Roach wrote: >> [as chair] >> >> I'd like to thank Brian for taking over editorship of this document, >> which has been mostly complete (pending some syntax issues) for >> several years now. Keeping in mind that this document is an adopted >> SIPCORE working group item, I would encourage everyone to read over >> it, and provide comments to the list. Even a quick note saying >> something like "I read through this, understood it, and think the >> examples are correct" is useful. >> >> Of course, something like "I untarred the examples and independently >> verified them with my own implementation" would be spectacular. >> >> /a >> >> >> Internet-Drafts@ietf.org wrote: >>> 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-00.txt >>> Pages : 59 >>> Date : 2009-05-04 >>> >>> 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-00.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. >>> >>> ------------------------------------------------------------------------ >>> >>> _______________________________________________ >>> 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 Jul 20 07:25:08 2009 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 CEFD33A6837 for ; Mon, 20 Jul 2009 07:25:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.099 X-Spam-Level: X-Spam-Status: No, score=-5.099 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, J_CHICKENPOX_42=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_65=0.6, J_CHICKENPOX_82=0.6, J_CHICKENPOX_92=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 7nNOv+FyDJcL for ; Mon, 20 Jul 2009 07:25:07 -0700 (PDT) Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by core3.amsl.com (Postfix) with ESMTP id 6DE3B3A682B for ; Mon, 20 Jul 2009 07:25:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAB8bZEpAZnmf/2dsb2JhbAC5KogjjicFgj2BT4FE X-IronPort-AV: E=Sophos;i="4.43,234,1246838400"; d="scan'208";a="187726438" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-2.cisco.com with ESMTP; 20 Jul 2009 14:24:59 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6KEOx4A004694; Mon, 20 Jul 2009 10:24:59 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6KEOxjX023303; Mon, 20 Jul 2009 14:24:59 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 10:24:59 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 10:24:59 -0400 Message-ID: <4A647E3A.6050106@cisco.com> Date: Mon, 20 Jul 2009 10:24:58 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: OKUMURA Shinji References: <4A5FB302.7080102@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 20 Jul 2009 14:24:59.0121 (UTC) FILETIME=[DC8EA610:01CA0945] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=8003; t=1248099899; x=1248963899; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20target=20refresh=20during=2 0an=20incomplete=20reINVITE-transaction |Sender:=20 |To:=20OKUMURA=20Shinji=20; bh=a9h4XgA+fvmysAmJu25fwIJhDtqXNree3SrCqICXDXI=; b=m6/Uo3itCwIQ8fJzi0b/6RYuuVrutptyHtUXxudwdRqe7WYBEq0z6TwNGf OvS4w4n50VSUrsqOKr0pKU0YnRJh92PXqXKNo++z9tmnqhaKzT8Cw/MT+0sd yinZQ7ae7k; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] target refresh during an incomplete reINVITE-transaction 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, 20 Jul 2009 14:25:08 -0000 Shinji, Comments inline OKUMURA Shinji wrote: > Hi Paul, > > Paul Kyzivat >> IMO it is a bad idea, dangerous precedent, and not very functional, to >> have the UAS modifying the Via when receiving a target refresh. >> >> This is way out of line. Also, its not that unusual for middleboxes to >> obscure Vias, in which case the UAS won't even find the entry that needs >> to be modified. >> >> The use case is an infrequent one, though it could be important. I >> spelled out how this could be handled without fixing the Via, and that >> is all consistent with current rules. The only thing that is required is >> that the target refresh by the UPDATE must not be rolled back if the >> enclosing INVITE fails. IMO that is reasonable, even if it is a special >> case. > > I agree. And I have a battery of question regarding to this > procedure. > > Q1. MUST no session parameter(ie. O/A state) that belong to > the UPDATE transaction be also rolled back? > (I think no-rollback.) I think we should treat these as independent questions. I don't view the need to *not* roll back a target refresh as an argument for or against rolling back O/A state. If we follow draft-camarillo-sipping-reinvite-00 on this, then as I read it, the O/A state is bound and will not be rolled back if and only if it has begun to be *used*, whereas the remote target will be treated as being used *immediately* and so will never be rolled back. > Q2. If no-rollback, then in precondition case, IS it necessary > that UAC send new reINVITE with a precondition to revert > to the pre-INVITE state? > (I'm confused.) According to same draft (IIUC) if the preconditions haven't been resolved yet then they are not "in use" and so will indeed be rolled back. Gonzalo: that's right isn't it? > Q3. MUST no session parameter(ie. O/A state) that belong to > 1st reINVITE and PRACK transaction be also rolled back? > (I think rollback probably. it cause no problem.) I don't understand the question. What is special about the 1st reINVITE? I assume it is the same as any reINVITE. The first *INVITE* (establishing the dialog) is different, but if that fails you have no call, so everything is rolled back. > Q4. Do a reINVITE request and it's reliable provisional responce > refresh a remote target? > (I think NO, under the current RFCs.) Yes, I think they do. Doesn't Gonzalo's draft already say that? Thanks, Paul > I want to hear expert's opinion and wish the draft to give > the answer. > > If these already discussed previously, please provide me > the pointer to that discussion. > > Regards, > Shinji > >> Thanks, >> Paul >> >> gao.yang2@zte.com.cn wrote: >>> Hi Shinji, >>> >>> IMO, it is not elegant solution, as: >>> 1. This is a additional requirement for UA and proxy. >>> 2. Further the response(of INVITE/Re-INVITE) can be 4xx or 2xx, and the >>> difference may has impact on session state. >>> >>> I have a raw way: >>> >>> As it is because of the inconsistency of refreshed target and >>> dispatching rule by Via, and UAS has get the refreshed target by UPDATE, >>> so the UAS can modify the last Via header(which is formed by UAC >>> according to its address) to be the new address of UAC. *But I am not >>> sure is there any proxy will check the Via headers.* >>> >>> The mentioned case is that the response is after the UPDATE(by UAS's >>> view). If the final response is before the UDPATE(by UAS's view): >>> 2xx case: The retransmission of 2xx should use modified Via header. >>> 4xx case: 4xx is hop-by-hop, so the 4xx will be sent to the old address >>> of UAC. So, it can be missed. The UAC's timer for final response will >>> fire(as 408), and it can send a new Re-INVITE or just terminate the >>> session. >>> >>> Thanks. >>> >>> Gao >>> >>> *OKUMURA Shinji * >>> Hi Gao, >>> >>> I think this issue may be discussed previously. >>> >>> During an incomplete reINVITE-transaction, if UAC's IP address >>> is changed, >>> >>> UAC behavior when sending the UPDATE request to refresh local target >>> MAY send CANCEL >>> DO NOT expect 4xx responce for reINVITE >>> If necessary, send new reINVITE (in the same dialog) >>> >>> UAS behavior when receiving the UPDATE request to refresh remote target >>> If tactful, MAY send 4xx responce for reINVITE >>> DO expect CANCEL >>> >>> Server transaction (nearest UAC) >>> If very very tactful, would forward 4xx to new IP address. >>> but I'm not sure it cause no problem. >>> >>> Regards, >>> Shinji >>> >>> gao.yang2@zte.com.cn >>> >Hi, >>> > >>> >Then, it seems a real problem for inconsistency of refreshed target and >>> >dispatching rule by Via. >>> > >>> >Paul has given out some BCP way. Do you have some thought about solutions >>> >in theory? >>> > >>> >Thanks. >>> > >>> >Gao >>> > >>> >=================================== >>> > Zip : 210012 >>> > Tel : 87211 >>> > Tel2 :(+86)-025-52877211 >>> > e_mail : gao.yang2@zte.com.cn >>> >=================================== >>> > >>> >OKUMURA Shinji >>> >2009-07-16 12:29 >>> > >>> >Hi, Gao >>> > >>> >I seem you don't still catch his point. He has been talking about >>> >a Via header of not a proxy but an UAC. the server transaction send >>> >a responce of the reINVITE to the old address of an UAC, even if >>> >UPDATE request had refreshed UAC's local target(ie. IP address). >>> > >>> >It is a basic rule described in RFC3261. RFC3311 does NOT change it. >>> > >>> >Regards, >>> >Shinji >>> > >>> >gao.yang2@zte.com.cn >>> >>Hi, >>> >> >>> >>I catch your point now. You mean that the middle-box, such as proxy, >>> >>adding Via in the INVITE. Then the proxy is now non-functional, making the >>> >>response unreachable. >>> >> >>> >>But I think the solutions should not be in protocol level. The solutions >>> >>can be: >>> >> >>> >>1. Fault tolerance. (ie. crashing of P-CSCF/S-CSCF) >>> >> >>> >>2. Issue new INVITE replace the old one. (ie. changing P-CSCF) >>> >> >>> >>Thanks. >>> >> >>> >>Gao >>> >> >>> >>=================================== >>> >> Zip : 210012 >>> >> Tel : 87211 >>> >> Tel2 :(+86)-025-52877211 >>> >> e_mail : gao.yang2@zte.com.cn >>> >>=================================== >>> >> >>> >> >>> >> >>> >>Paul Kyzivat >>> >> >>> >>gao.yang2@zte.com.cn wrote: >>> >> >>> >>> If |he UAC decides to fix this by sending an UPDATE before completion of >>> >>> the reINVITE, then it may succeed in getting the remote target changed >>> >>> at the UAS. But the *UAS is still obligated to send the remaining >>> >>> responses to the address in the Via, which is the old address. * >>> >>> >>> >>> [Gao] It is in RFC3261, but RFC3311 has the definition as: >>> >>> >>> >>> from RFC3311: >>> >>> UPDATE is a target refresh request. As specified in RFC 3261 [1], >>> >>> this means that it can update the remote target of a dialog. If a UA >>> >>> uses an UPDATE request or response to modify the remote target while >>> >>> *an INVITE transaction is in progress*, and it is a UAS for that INVITE >>> >>> transaction, it *MUST place the same value into the Contact header* >>> >>> * field of the 2xx to the INVITE that it placed into the UPDATE request* >>> >>> * or response*. >>> >>> >>> >>> So, it should be the new address here. >>> >> >>> >>You miss my point. >>> >> >>> >>Its not about the Contact placed *in* the 2xx response. >>> >>Its about the address to which the response is delivered. >>> >>That is dictated by the Via headers in the INVITE request. >>> >>Those are not affected by the target refresh. >>> >> >>> >> Thanks, >>> >> Paul > From Martin.Huelsemann@telekom.de Mon Jul 20 08:40:57 2009 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 785E33A6D75 for ; Mon, 20 Jul 2009 08:40:57 -0700 (PDT) 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 969Vv8gpTn0S for ; Mon, 20 Jul 2009 08:40:54 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 2A0753A6C79 for ; Mon, 20 Jul 2009 08:40:53 -0700 (PDT) Received: from s4de9jsaanm.mgb.telekom.de (HELO S4DE9JSAANM.ost.t-com.de) ([10.125.177.122]) by tcmail81.telekom.de with ESMTP; 20 Jul 2009 17:40:47 +0200 Received: from S4DE9JSAAIL.ost.t-com.de ([10.125.177.200]) by S4DE9JSAANM.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Mon, 20 Jul 2009 17:40:47 +0200 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, 20 Jul 2009 17:40:46 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-kaplan-sip-session-id-02 Thread-Index: AcoIqtSPtz9zA6BtTM6gsU7oe1O8AwAJuwTQAB4q6xA= References: <1245876685.3748.61.camel@victoria-pingtel-com.us.nortel.com><40FB0FFB97588246A1BEFB05759DC8A00330040F@S4DE9JSAANI.ost.t-com.de><1247883283.4025.2.camel@victoria-pingtel-com.us.nortel.com> From: To: , , X-OriginalArrivalTime: 20 Jul 2009 15:40:47.0056 (UTC) FILETIME=[73567500:01CA0950] Subject: Re: [sipcore] draft-kaplan-sip-session-id-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, 20 Jul 2009 15:40:57 -0000 Hi Hadriel, what could be the solution for the case that there is a concatenation of = full B2BUAs? E.g. there are several App Servers, and the application is = targetting the last App Server in the signalling path or respectively = needs to match a certain dialog at this AS. I think even a = secure-call-id won't be successfull here? BR, Martin =20 > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] Im Auftrag von Hadriel Kaplan > Gesendet: Montag, 20. Juli 2009 02:54 > An: Dale Worley; sipcore@ietf.org > Betreff: Re: [sipcore] draft-kaplan-sip-session-id-02 >=20 > Hi Dale, > The thing is they're really trying to solve different things,=20 > though I know I didn't do a good job explaining it at the=20 > last WG meeting. :( >=20 > The secure-call-id is trying to provide a real Call-ID value=20 > which middleboxes won't change - for middleboxes that change=20 > it for the specific purpose of privacy or topology-hiding. =20 > And by that I mean a real Call-ID: useful for dialog=20 > matching, the dialog-events package, and any of the things a=20 > Call-ID value is used in (there are many, as you know). >=20 > People put Call-ID values in all sorts of things, and expect=20 > it to work end-to-end, and are "surprised" when something in=20 > the middle changed them. So secure-call-id is trying to=20 > provide a Call-ID that won't be changed by those middleboxes.=20 > It *will* still be changed by other B2BUA's, for example=20 > many IP-PBX's and App Servers change the Call-ID, and will=20 > continue doing so. It's ok that they do - most of the=20 > applications which use Call-ID's are targeted to those=20 > IP-PBXs/App-Servers, and they have some other reasons for=20 > changing them. >=20 > Session-ID is for something different: a session identifier=20 > which crosses any form of middlebox including real/full=20 > B2BUA's, but is not used for the dialog-matching type things=20 > a Call-ID is used for. When I tried to use it for some of=20 > those other things, I got feedback with concern that it was=20 > subverting the Call-ID mechanism - if a B2BUA changed the=20 > Call-ID then it was unwise of me to try to second-guess it=20 > and bypass its replacement. I agreed with that concern, so=20 > Session-ID is for troubleshooting purposes only at this time. >=20 > So the two mechanisms are not at odds, nor are they=20 > alternatives for the same thing. >=20 > A middlebox which replaces Call-ID's *does* know if it's a=20 > secure-call-id. If it has no '@', and no IP Addr/hostname=20 > format in it, it's sufficiently benign to not change. >=20 > -hadriel >=20 > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On=20 > > Behalf Of Dale Worley > >=20 > > The Session-Id has a tremendous advantage over the "secure=20 > Call-Id": =20 > > In a system that is not tightly managed by a central authority,=20 > > middleboxes have no way of knowing whether a UA is=20 > generating "secure=20 > > Call-Ids" or not. So they must replace all Call-Ids,=20 > subverting the=20 > > UAs that are generating secure Call-Ids. But (absent malice on the=20 > > part of UAs), Session-Ids are known to be secure, and=20 > middleboxes know=20 > > not to replace them. So I think we should deprecate=20 > > draft-kaplan-sip-secure-call-id in favor of=20 > draft-kaplan-sip-session-id. > >=20 > > Dale >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From HKaplan@acmepacket.com Mon Jul 20 14:15:36 2009 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 BF71D3A67D7 for ; Mon, 20 Jul 2009 14:15:36 -0700 (PDT) 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.000, 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 AEi82dSf+Tqc for ; Mon, 20 Jul 2009 14:15:26 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 288E93A6DDC for ; Mon, 20 Jul 2009 14:15:26 -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.1.375.2; Mon, 20 Jul 2009 17:10:00 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Mon, 20 Jul 2009 17:10:00 -0400 From: Hadriel Kaplan To: "Martin.Huelsemann@telekom.de" , "dworley@nortel.com" , "sipcore@ietf.org" Date: Mon, 20 Jul 2009 17:09:59 -0400 Thread-Topic: [sipcore] draft-kaplan-sip-session-id-02 Thread-Index: AcoIqtSPtz9zA6BtTM6gsU7oe1O8AwAJuwTQAB4q6xAADJX2cA== Message-ID: References: <1245876685.3748.61.camel@victoria-pingtel-com.us.nortel.com><40FB0FFB97588246A1BEFB05759DC8A00330040F@S4DE9JSAANI.ost.t-com.de><1247883283.4025.2.camel@victoria-pingtel-com.us.nortel.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 Subject: Re: [sipcore] draft-kaplan-sip-session-id-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, 20 Jul 2009 21:15:36 -0000 Hi Martin,=20 Correct - secure-call-id won't fix it if a B2BUA changes the Call-ID and so= mething breaks due to that (because secure-call-id is a Call-ID). =20 The other draft mechanism (session-id) tried to do that originally, but met= with derision for not being able to fix everything possible in all cases.= =20 -hadriel > -----Original Message----- > From: Martin.Huelsemann@telekom.de [mailto:Martin.Huelsemann@telekom.de] > Sent: Monday, July 20, 2009 11:41 AM >=20 > what could be the solution for the case that there is a concatenation of > full B2BUAs? E.g. there are several App Servers, and the application is > targetting the last App Server in the signalling path or respectively > needs to match a certain dialog at this AS. I think even a secure-call-id > won't be successfull here? From Martin.Huelsemann@telekom.de Tue Jul 21 00:44:16 2009 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 E5C9C3A686E for ; Tue, 21 Jul 2009 00:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.534 X-Spam-Level: X-Spam-Status: No, score=-1.534 tagged_above=-999 required=5 tests=[AWL=-1.715, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, HELO_EQ_DE=0.35, MANGLED_LOAN=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 vfvpO5LrccN7 for ; Tue, 21 Jul 2009 00:44:16 -0700 (PDT) Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id B8CC43A67EE for ; Tue, 21 Jul 2009 00:44:14 -0700 (PDT) Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 21 Jul 2009 09:43:54 +0200 Received: from S4DE9JSAAIL.ost.t-com.de ([10.125.177.200]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 09:43:54 +0200 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: Tue, 21 Jul 2009 09:43:53 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-kaplan-sip-session-id-02 Thread-Index: AcoIqtSPtz9zA6BtTM6gsU7oe1O8AwAJuwTQAB4q6xAADJX2cAAWKS/A References: <1245876685.3748.61.camel@victoria-pingtel-com.us.nortel.com><40FB0FFB97588246A1BEFB05759DC8A00330040F@S4DE9JSAANI.ost.t-com.de><1247883283.4025.2.camel@victoria-pingtel-com.us.nortel.com> From: To: , , X-OriginalArrivalTime: 21 Jul 2009 07:43:54.0498 (UTC) FILETIME=[FF565620:01CA09D6] Subject: Re: [sipcore] draft-kaplan-sip-session-id-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, 21 Jul 2009 07:44:17 -0000 Hi Hadriel, but perhaps it would nevertheless be worth to describe the session-id = mechanism as a solution for some problems under certain conditions. = Perhaps also a recommendation can be included that because of the = restrictions implementors should be careful when using it, and that it = is only valid for certain network architectures. BR, Martin > -----Urspr=FCngliche Nachricht----- > Von: Hadriel Kaplan [mailto:HKaplan@acmepacket.com]=20 > Gesendet: Montag, 20. Juli 2009 23:10 > An: H=FClsemann, Martin; dworley@nortel.com; sipcore@ietf.org > Betreff: RE: [sipcore] draft-kaplan-sip-session-id-02 >=20 >=20 > Hi Martin,=20 >=20 > Correct - secure-call-id won't fix it if a B2BUA changes the=20 > Call-ID and something breaks due to that (because=20 > secure-call-id is a Call-ID). =20 >=20 > The other draft mechanism (session-id) tried to do that=20 > originally, but met with derision for not being able to fix=20 > everything possible in all cases.=20 >=20 > -hadriel >=20 > > -----Original Message----- > > From: Martin.Huelsemann@telekom.de=20 > > [mailto:Martin.Huelsemann@telekom.de] > > Sent: Monday, July 20, 2009 11:41 AM > >=20 > > what could be the solution for the case that there is a=20 > concatenation=20 > > of full B2BUAs? E.g. there are several App Servers, and the=20 > > application is targetting the last App Server in the=20 > signalling path=20 > > or respectively needs to match a certain dialog at this AS. I think=20 > > even a secure-call-id won't be successfull here? >=20 From AUDET@nortel.com Tue Jul 21 10:44:40 2009 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 AF9103A6A35 for ; Tue, 21 Jul 2009 10:44:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 V6UKyBHbLClB for ; Tue, 21 Jul 2009 10:44:39 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 1F16E3A695D for ; Tue, 21 Jul 2009 10:44:38 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6LHgfx15631; Tue, 21 Jul 2009 17:42:41 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0A2A.C013FD04" Date: Tue, 21 Jul 2009 12:43:25 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F155AEC@zrc2hxm0.corp.nortel.com> In-Reply-To: <9ae56b1e0907170040l5287344fy96103bfc8a11c32@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoGsecaT/rF7i/rQRKVb2/toS9k6wDeNEWg References: <4A5FDC3E.2000101@joelhalpern.com> <9ae56b1e0907170040l5287344fy96103bfc8a11c32@mail.gmail.com> From: "Francois Audet" To: "Hans Erik van Elburg" , "Joel M. Halpern" Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 21 Jul 2009 17:44:40 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0A2A.C013FD04 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable So, we are saying it is an ;aor after all? ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Friday, July 17, 2009 00:41 To: Joel M. Halpern Cc: Audet, Francois (SC100:3055); SIPCORE; Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? =09 =09 sounds reasonable.=20 /Hans Erik van Elburg =09 =09 =09 On Fri, Jul 17, 2009 at 4:04 AM, Joel M. Halpern = wrote: =09 Actually, I think it (the domain that was on the right hand side of = the R-URI, and that is performing the ENUM lookup) is "the right" = domain. Of course, this turns on deciding what a SIP URI with a user part that = happens to be digits is. As far as I can tell, it ought to be a SIP UIR. Therefore, if a proxy in domain sp.com receives a SIP R-URI of = sip:+123456789@sp.com ;user=3Dphone = (with the right number of digits, sorry), then sp.com is the responsible = domain. The fact that the proxy does not actually care if the target is = within sp.com, and will use ENUM, and send the call on wherever ENUM = tells it does not change the fact that the R-URI indicated his domain, = the proxy understand the domain, and understand the rules of the domain. = That domain just has a lot of implicit registration, and an ENUM based = location service. So be it. =09 (Now, at least in my opinion, if any proxy outside of sp.com tries = that trick it is just plain wrong. But that is, I think, a different = discussion.) =09 Yours, Joel =09 Francois Audet wrote: =09 Say I call sip:+1234567890@sp.com = ;user=3Dphone. My proxy is "sp.com", right? Then sp.net does ENUM query. =09 If we assume that ENUM qualifies as a location service (and I am now convinced that it does), then this URI *is* an AOR in sp.com. =09 No, because it's not the right domain. It's doing the ENUM on a phone number. So it really has nothing to do with a SIP scheme (a condition for AOR, remember?). =09 And in fact, it goes to example.com, not sp.com =09 =09 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore =09 =09 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore =09 ------_=_NextPart_001_01CA0A2A.C013FD04 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
So, we=20 are saying it is an ;aor after all?

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: Friday, July 17, = 2009=20 00:41
To: Joel M. Halpern
Cc: Audet, Francois=20 (SC100:3055); SIPCORE; Hadriel Kaplan
Subject: Re: [sipcore] = rfc4244bis: what is an AoR?

sounds reasonable.

/Hans Erik van Elburg


On Fri, Jul 17, 2009 at 4:04 AM, Joel M. = Halpern <jmh@joelhalpern.com> = wrote:
Actually,=20 I think it  (the domain that was on the right hand side of the = R-URI,=20 and that is performing the ENUM lookup) is "the right" domain.
Of = course,=20 this turns on deciding what a SIP URI with a user part that happens = to be=20 digits is.
As far as I can tell, it ought to be a SIP = UIR.
Therefore,=20 if a proxy in domain sp.com=20 receives a SIP R-URI of sip:+123456789@sp.com;user=3Dphone (with the = right number of=20 digits, sorry), then sp.com is the=20 responsible domain.  The fact that the proxy does not actually = care if=20 the target is within sp.com, and=20 will use ENUM, and send the call on wherever ENUM tells it does not = change=20 the fact that the R-URI indicated his domain, the proxy understand = the=20 domain, and understand the rules of the domain.  That domain = just has a=20 lot of implicit registration, and an ENUM based location service. =  So=20 be it.

(Now, at least in my opinion, if any proxy outside of = sp.com tries that trick = it is just=20 plain wrong.  But that is, I think, a different=20 discussion.)

Yours,
Joel

Francois Audet wrote:

Say=20 I call sip:+1234567890@sp.com;user=3Dphone. My = proxy is "sp.com",
right?
 Then sp.net does ENUM=20 query.
If we assume that ENUM qualifies as a = location=20 service (and I am now
convinced that it does), then this URI = *is* an=20 AOR in sp.com.

No, because it's = not the=20 right domain. It's doing the ENUM on a phone
number. So it = really has=20 nothing to do with a SIP scheme (a condition
for AOR,=20 remember?).

And in fact, it goes to example.com, not sp.com

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

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

------_=_NextPart_001_01CA0A2A.C013FD04-- From AUDET@nortel.com Tue Jul 21 10:46:14 2009 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 21D393A689A for ; Tue, 21 Jul 2009 10:46:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 sp7HL-9ux1Er for ; Tue, 21 Jul 2009 10:46:13 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id E61943A67D9 for ; Tue, 21 Jul 2009 10:46:05 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6LHjta09848; Tue, 21 Jul 2009 17:45:55 GMT 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, 21 Jul 2009 12:45:53 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com> In-Reply-To: A<0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoF6CVRUPlMKkb7SrWHqBtgx6wCgwAAvgVQABgn/cAAH/S/oADX36qg References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com> <4A5E83CB.4090701@cisco.com> <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com> A<0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Elwell, John" , "Hans Erik van Elburg" , "Paul Kyzivat" Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 21 Jul 2009 17:46:14 -0000 > > In this case, you'll have an entry in the middle > > (elwell@10.10.15.12) that is not > > an AOR. > [JRE] Thinking about this further, I believe this DOES fit=20 > the definition for AOR. In other words, my UAS is responsible for > 10.10.15.12 and its "location service" tells it that the=20 > contact for elwell is john@192.168.15.12. Exactly. From AUDET@nortel.com Tue Jul 21 10:55:19 2009 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 C056F3A6AAA for ; Tue, 21 Jul 2009 10:55:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.468 X-Spam-Level: X-Spam-Status: No, score=-5.468 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 3pvJPiE1CpZx for ; Tue, 21 Jul 2009 10:55:18 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 0CE353A6813 for ; Tue, 21 Jul 2009 10:55:17 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6LHrSx17578; Tue, 21 Jul 2009 17:53:28 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0A2C.45366C5A" Date: Tue, 21 Jul 2009 12:54:18 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F155B2A@zrc2hxm0.corp.nortel.com> In-Reply-To: <9ae56b1e0907172354q353f23ffla9fd0c6a0f55d2cd@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoHdKn5kQ6iDCPLSWagZ07zsP5o9gCtyYyg References: <4A5FAF4E.4030901@cisco.com> <9ae56b1e0907171313u6b7e09c3hd0eee3399a4ae681@mail.gmail.com> <9ae56b1e0907172354q353f23ffla9fd0c6a0f55d2cd@mail.gmail.com> From: "Francois Audet" To: "Hans Erik van Elburg" , "Hadriel Kaplan" Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 21 Jul 2009 17:55:19 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0A2C.45366C5A Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable By "first H-I entry", you mean the "first from the end", i.e., "the = last", right? ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Friday, July 17, 2009 23:55 To: Hadriel Kaplan Cc: Audet, Francois (SC100:3055); Paul Kyzivat; SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? =09 =09 Yes the relevant flags are dependent on what you in your role of UAS = would like to retrieve. The rules would be very simple.=20 To retrieve the addressed target (freephone, etc):=20 - traverse all H-I entries backward until an "mp" entry is found, if = found this is the addressed target - if no "mp" found take the first H-I entry - if no History-Info header take the Request-URI value To retrieve the last aor before it was overwritten by contact address = (similar as P-Called-Party-ID):=20 - traverse all H-I entries backward until an "aor" entry is found, if = found this is the last AOR used /Hans Erik van Elburg =09 =09 On Fri, Jul 17, 2009 at 11:43 PM, Hadriel Kaplan = wrote: =09 I=92m confused (I know, not a hard thing to make me be apparently = :-(). In a previous chain of emails I thought the purpose of the =93mp=94 = flag was to indicate a retarget happened, but that the subsequent = =93aor=94 flagged URI was what would actually be used for applications, = because it is the =93cleaned-up=94 form of the URI being retargeted to, = since it actually identifies what the authoritative domain which got it = claims it location-service routed with. =20 Your response indicates that the =93mp=94 flagged URI would actually = be used by the application, even when it does not have an =93aor=94 flag = (as it would not in this case). =20 Which is it? Or are the cases different for different application = uses, for which flags are important? =20 -hadriel =20 =09 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Friday, July 17, 2009 4:13 PM To: Hadriel Kaplan Cc: Francois Audet; Paul Kyzivat; SIPCORE =09 Subject: Re: [sipcore] rfc4244bis: what is an AoR? =09 =20 inline... /Hans Erik van Elburg =09 =09 On Fri, Jul 17, 2009 at 4:52 PM, Hadriel Kaplan = wrote: =09 =09 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Thursday, July 16, 2009 8:37 PM > > >> Say I call sip:+1234567890@sp.com = ;user=3Dphone. My proxy is "sp.com", > >> right? > >> > >> Then sp.net does ENUM query. Did you intend for this to be "sp.net" and thus a different domain = from "sp.com"? Or was that a typo? I am assuming it was a typo. =09 =09 > > If we assume that ENUM qualifies as a location service (and I am = now > > convinced that it does), then this URI *is* an AOR in sp.com. > > No, because it's not the right domain. It's doing the ENUM on a = phone > number. So it really has nothing to do with a SIP scheme (a = condition > for AOR, remember?). Regardless of whether ENUM is doing it on a phone number sans domain = or not, it MUST be marked as an "aor". Think of it this way: Suppose you call "sip:+18005551212@sp.com = ", and sp.com does an ENUM lookup = on 18005551212, and the NAPTR result translated it to the non-800 = specific number for it. The freephone-model/redirection-usage NEEDs to = see that 18005551212. No? =20 No. The aor tag has nothing todo with the freephone case, for that = case the "mp" tag or in its absence the first H-I entry is important to = be able to determine the original called target. =20 =20 =09 =09 That's also why I think you'd want Tel-URI's - because sp.com could = have received a Tel-URI with it and done that ENUM lookup. =09 > And in fact, it goes to example.com, not sp.com So? As far as the sp.com Proxy cares, it has done an ENUM lookup and = gotten a result which changes the req-uri and makes it route the call. = As far as it knows, "sip:+1234567890@example.com = " is a contact address of a = PSTN-Gateway or registered UA, in which case per the rules = "sip:+1234567890@sp.com " WAS an = AoR; whereas if "sip:+1234567890@example.com = " is another peer domain then = it's not an AoR?? =20 The question is if it matters in this case. =20 =09 -hadriel =20 ------_=_NextPart_001_01CA0A2C.45366C5A Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
By=20 "first H-I entry", you mean the "first from the end", i.e., "the last",=20 right?

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: Friday, July 17, = 2009=20 23:55
To: Hadriel Kaplan
Cc: Audet, Francois = (SC100:3055);=20 Paul Kyzivat; SIPCORE
Subject: Re: [sipcore] rfc4244bis: = what is an=20 AoR?

Yes the relevant flags are dependent on what you in your role of = UAS=20 would like  to retrieve.

The rules would be very simple.

To retrieve the addressed target (freephone, etc): 
- traverse all H-I entries backward until an "mp" entry is found, = if=20 found this is the addressed target
- if no "mp" found take the first H-I entry
- if no History-Info header take the Request-URI value

To retrieve the last aor before it was overwritten by contact=20 address (similar as P-Called-Party-ID): 
- traverse all H-I entries backward until an "aor" entry is = found, if=20 found this is the last AOR used

/Hans Erik van Elburg

On Fri, Jul 17, 2009 at 11:43 PM, Hadriel = Kaplan <HKaplan@acmepacket.com>=20 wrote:

I=92m = confused (I=20 know, not a hard thing to make me be apparently L).

In a = previous chain=20 of emails I thought the purpose of the =93mp=94 flag was to indicate = a retarget=20 happened, but that the subsequent =93aor=94 flagged URI was what = would actually=20 be used for applications, because it is the =93cleaned-up=94 form of = the URI=20 being retargeted to, since it actually identifies what the = authoritative=20 domain which got it claims it location-service routed=20 with.

 

Your = response=20 indicates that the =93mp=94 flagged URI would actually be used by = the=20 application, even when it does not have an =93aor=94 flag (as it = would not in=20 this case).

 

Which is = it? =20 Or are the cases different for different application uses, for which = flags=20 are important?

 

-hadriel

 

From: Hans=20 Erik van Elburg [mailto:ietf.hanserik@gmail.com]
Sent: Friday, July 17, 2009 = 4:13=20 PM
To: Hadriel=20 Kaplan
Cc: = Francois Audet;=20 Paul Kyzivat; SIPCORE


Subject: Re:=20 [sipcore] rfc4244bis: what is an AoR?

 

inline...
/Hans Erik van=20 Elburg

On Fri,=20 Jul 17, 2009 at 4:52 PM, Hadriel Kaplan <HKaplan@acmepacket.com> = wrote:



> -----Original = Message-----
>=20 From: Francois Audet [mailto:audet@nortel.com]

> Sent: Thursday, July 16, 2009 8:37=20 PM
>
> >> Say I call sip:+1234567890@sp.com;user=3Dphone. My proxy is = "sp.com",
> >> = right?
> >>
> >> Then sp.net does ENUM query.

Did you intend for this to be "sp.net" and thus a = different domain=20 from "sp.com"? =  Or was that a=20 typo?  I am assuming it was a typo.


> > If we = assume=20 that ENUM qualifies as a location service (and I am now
> > = convinced that it does), then this URI *is* an AOR in sp.com.
>
> = No, because=20 it's not the right domain. It's doing the ENUM on a phone
> = number. So=20 it really has nothing to do with a SIP scheme (a condition
> = for AOR,=20 remember?).

Regardless of whether ENUM is doing it on = a phone=20 number sans domain or not, it MUST be marked as an "aor". =  Think of it=20 this way:
Suppose you call "sip:+18005551212@sp.com", and sp.com does an ENUM lookup on 18005551212, and = the NAPTR=20 result translated it to the non-800 specific number for it. =  The=20 freephone-model/redirection-usage NEEDs to see that 18005551212.=20 No?

 

No. The=20 aor tag has nothing todo with the freephone case, for that case the = "mp" tag=20 or in its absence  the first H-I entry is important to be able = to=20 determine the original called target.

 

 



That's also why I think you'd = want=20 Tel-URI's - because sp.com could=20 have received a Tel-URI with it and done that ENUM=20 lookup.


> And in fact, it goes to example.com, not = sp.com

So?=20  As far as the sp.com Proxy=20 cares, it has done an ENUM lookup and gotten a result which = changes the=20 req-uri and makes it route the call.  As far as it knows, "sip:+1234567890@example.com" is a contact = address of a=20 PSTN-Gateway or registered UA, in which case per the rules "sip:+1234567890@sp.com" WAS an AoR; whereas if = "sip:+1234567890@example.com" is another peer = domain then=20 it's not an AoR??

 

The=20 question is if it matters in this case.

 


-hadriel

 

=
------_=_NextPart_001_01CA0A2C.45366C5A-- From AUDET@nortel.com Tue Jul 21 11:05:11 2009 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 0F1263A6A8C for ; Tue, 21 Jul 2009 11:05:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.468 X-Spam-Level: X-Spam-Status: No, score=-5.468 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 Alpz-Z6gfNAc for ; Tue, 21 Jul 2009 11:05:09 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 05EDB3A697B for ; Tue, 21 Jul 2009 11:05:08 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6LI4xa17592; Tue, 21 Jul 2009 18:04:59 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0A2D.C17FE1B4" Date: Tue, 21 Jul 2009 13:04:55 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F155B6A@zrc2hxm0.corp.nortel.com> In-Reply-To: <9ae56b1e0907190130h7038db2dr8ac0ef793b57eed8@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoISyR5SD0wr58hQrSLz8r+aGXU9gB4RFEA References: <4A5FAF4E.4030901@cisco.com> <9ae56b1e0907171313u6b7e09c3hd0eee3399a4ae681@mail.gmail.com> <9ae56b1e0907172354q353f23ffla9fd0c6a0f55d2cd@mail.gmail.com> <9ae56b1e0907190130h7038db2dr8ac0ef793b57eed8@mail.gmail.com> From: "Francois Audet" To: "Hans Erik van Elburg" , "Hadriel Kaplan" Cc: SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 21 Jul 2009 18:05:11 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0A2D.C17FE1B4 Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable In this particular example of address target, wouln't just using the = same algorith, i.e., pick the last entry with "aor" actually work? =20 Yes, it could have both an "mp" and an "aor" flag. ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Sunday, July 19, 2009 01:30 To: Hadriel Kaplan Cc: Audet, Francois (SC100:3055); Paul Kyzivat; SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? =09 =09 No not really, it is only different application retrieving different = bits of information. What is important is that they can extract this = information. /Hans Erik van Elburg =09 =09 =09 On Sat, Jul 18, 2009 at 6:11 PM, Hadriel Kaplan = wrote: =09 =20 Doesn=92t it seem wrong/dangerous to you that one application would = use the =93mp=94 flagged entry as a target, while another application = uses the =93aor=94 flagged entry as a target? I mean really they=92re = all looking for =93targets=94, right? One=92s just looking for the = =93last redirected-to=94 target, and the other=92s looking for the = =93last resolved-to=94 target. No? =20 The point made by Francois in one of the emails (which made a lot of = sense to me) was that you basically had to use the =93aor=94 ones = because anything else is just that local proxy=92s view of what its = routing to, including any locally-specific =93ugliness=94, = pre-translation et al; whereas the =93aor=94 one was what the actual = targeted domain saw and used for location-service resolution and = therefore was =93authoritative=94. =20 -hadriel =20 =09 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Saturday, July 18, 2009 2:55 AM =09 To: Hadriel Kaplan Cc: Francois Audet; Paul Kyzivat; SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? =09 =20 Yes the relevant flags are dependent on what you in your role of UAS = would like to retrieve. =20 The rules would be very simple. =20 To retrieve the addressed target (freephone, etc):=20 - traverse all H-I entries backward until an "mp" entry is found, if = found this is the addressed target - if no "mp" found take the first H-I entry - if no History-Info header take the Request-URI value =20 To retrieve the last aor before it was overwritten by contact address = (similar as P-Called-Party-ID):=20 - traverse all H-I entries backward until an "aor" entry is found, if = found this is the last AOR used =20 /Hans Erik van Elburg On Fri, Jul 17, 2009 at 11:43 PM, Hadriel Kaplan = wrote: I=92m confused (I know, not a hard thing to make me be apparently = :-(). In a previous chain of emails I thought the purpose of the =93mp=94 = flag was to indicate a retarget happened, but that the subsequent = =93aor=94 flagged URI was what would actually be used for applications, = because it is the =93cleaned-up=94 form of the URI being retargeted to, = since it actually identifies what the authoritative domain which got it = claims it location-service routed with. =20 Your response indicates that the =93mp=94 flagged URI would actually = be used by the application, even when it does not have an =93aor=94 flag = (as it would not in this case). =20 Which is it? Or are the cases different for different application = uses, for which flags are important? =20 -hadriel =20 =09 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Friday, July 17, 2009 4:13 PM To: Hadriel Kaplan Cc: Francois Audet; Paul Kyzivat; SIPCORE =09 Subject: Re: [sipcore] rfc4244bis: what is an AoR? =20 inline... /Hans Erik van Elburg On Fri, Jul 17, 2009 at 4:52 PM, Hadriel Kaplan = wrote: =09 =09 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Thursday, July 16, 2009 8:37 PM > > >> Say I call sip:+1234567890@sp.com = ;user=3Dphone. My proxy is "sp.com", > >> right? > >> > >> Then sp.net does ENUM query. Did you intend for this to be "sp.net" and thus a different domain = from "sp.com"? Or was that a typo? I am assuming it was a typo. =09 =09 > > If we assume that ENUM qualifies as a location service (and I am = now > > convinced that it does), then this URI *is* an AOR in sp.com. > > No, because it's not the right domain. It's doing the ENUM on a = phone > number. So it really has nothing to do with a SIP scheme (a = condition > for AOR, remember?). Regardless of whether ENUM is doing it on a phone number sans domain = or not, it MUST be marked as an "aor". Think of it this way: Suppose you call "sip:+18005551212@sp.com = ", and sp.com does an ENUM lookup = on 18005551212, and the NAPTR result translated it to the non-800 = specific number for it. The freephone-model/redirection-usage NEEDs to = see that 18005551212. No? =20 No. The aor tag has nothing todo with the freephone case, for that = case the "mp" tag or in its absence the first H-I entry is important to = be able to determine the original called target. =20 =20 =09 =09 That's also why I think you'd want Tel-URI's - because sp.com could = have received a Tel-URI with it and done that ENUM lookup. =09 > And in fact, it goes to example.com, not sp.com So? As far as the sp.com Proxy cares, it has done an ENUM lookup and = gotten a result which changes the req-uri and makes it route the call. = As far as it knows, "sip:+1234567890@example.com = " is a contact address of a = PSTN-Gateway or registered UA, in which case per the rules = "sip:+1234567890@sp.com " WAS an = AoR; whereas if "sip:+1234567890@example.com = " is another peer domain then = it's not an AoR?? =20 The question is if it matters in this case. =20 =09 -hadriel =20 =20 ------_=_NextPart_001_01CA0A2D.C17FE1B4 Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
In=20 this particular example of address target, wouln't just using the same = algorith,=20 i.e., pick the last entry with "aor" actually work?
 
Yes,=20 it could have both an "mp" and an "aor" flag.

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: Sunday, July 19, = 2009=20 01:30
To: Hadriel Kaplan
Cc: Audet, Francois = (SC100:3055);=20 Paul Kyzivat; SIPCORE
Subject: Re: [sipcore] rfc4244bis: = what is an=20 AoR?

No not really, it is only different application retrieving = different bits=20 of information. What is important is that they can extract this=20 information.

/Hans Erik van Elburg


On Sat, Jul 18, 2009 at 6:11 PM, Hadriel = Kaplan <HKaplan@acmepacket.com>=20 wrote:

 

Doesn=92t = it seem=20 wrong/dangerous to you that one application would use the =93mp=94 = flagged entry=20 as a target, while another application uses the =93aor=94 flagged = entry as a=20 target?  I mean really they=92re all looking for =93targets=94, = right? =20 One=92s just looking for the =93last redirected-to=94 target, and = the other=92s=20 looking for the =93last resolved-to=94 target.  = No?

 

The point = made by=20 Francois in one of the emails (which made a lot of sense to me) was = that you=20 basically had to use the =93aor=94 ones because anything else is = just that local=20 proxy=92s view of what its routing to, including any = locally-specific=20 =93ugliness=94, pre-translation et al; whereas the =93aor=94 one was = what the actual=20 targeted domain saw and used for location-service resolution and = therefore=20 was =93authoritative=94.

 

-hadriel

 

From: Hans=20 Erik van Elburg [mailto:ietf.hanserik@gmail.com]
Sent: Saturday, July 18, 2009 = 2:55=20 AM


To: Hadriel=20 Kaplan
Cc: = Francois Audet;=20 Paul Kyzivat; SIPCORE
Subject: Re: [sipcore] = rfc4244bis: what=20 is an AoR?

 

Yes the=20 relevant flags are dependent on what you in your role of UAS would = like=20  to retrieve.

 

The=20 rules would be very simple.

 

To=20 retrieve the addressed target (freephone,=20 etc): 

-=20 traverse all H-I entries backward until an "mp" entry is found, if = found=20 this is the addressed target

- if no=20 "mp" found take the first H-I entry

- if no=20 History-Info header take the Request-URI = value

 

To=20 retrieve the last aor before it was overwritten by contact=20 address (similar as = P-Called-Party-ID): 

-=20 traverse all H-I entries backward until an "aor" entry is found, if = found=20 this is the last AOR used

 

/Hans Erik van Elburg

On Fri,=20 Jul 17, 2009 at 11:43 PM, Hadriel Kaplan <HKaplan@acmepacket.com> = wrote:

I=92m = confused (I=20 know, not a hard thing to make me be apparently L).

In a = previous chain=20 of emails I thought the purpose of the =93mp=94 flag was to indicate = a retarget=20 happened, but that the subsequent =93aor=94 flagged URI was what = would actually=20 be used for applications, because it is the =93cleaned-up=94 form of = the URI=20 being retargeted to, since it actually identifies what the = authoritative=20 domain which got it claims it location-service routed=20 with.

 

Your = response=20 indicates that the =93mp=94 flagged URI would actually be used by = the=20 application, even when it does not have an =93aor=94 flag (as it = would not in=20 this case).

 

Which is = it? =20 Or are the cases different for different application uses, for which = flags=20 are important?

 

-hadriel

 

From: Hans=20 Erik van Elburg [mailto:ietf.hanserik@gmail.com]
Sent: Friday, July 17, 2009 = 4:13=20 PM
To: Hadriel=20 Kaplan
Cc: = Francois Audet;=20 Paul Kyzivat; SIPCORE


Subject: Re: [sipcore] = rfc4244bis: what=20 is an AoR?

 

inline...
/Hans Erik van=20 Elburg

On Fri,=20 Jul 17, 2009 at 4:52 PM, Hadriel Kaplan <HKaplan@acmepacket.com> = wrote:



> -----Original = Message-----
>=20 From: Francois Audet [mailto:audet@nortel.com]

> Sent: Thursday, July 16, 2009 8:37=20 PM
>
> >> Say I call sip:+1234567890@sp.com;user=3Dphone. My proxy is = "sp.com",
> >> = right?
> >>
> >> Then sp.net does ENUM query.

Did you intend for this to be "sp.net" and thus a = different domain=20 from "sp.com"? =  Or was that a=20 typo?  I am assuming it was a typo.


> > If we = assume=20 that ENUM qualifies as a location service (and I am now
> > = convinced that it does), then this URI *is* an AOR in sp.com.
>
> = No, because=20 it's not the right domain. It's doing the ENUM on a phone
> = number. So=20 it really has nothing to do with a SIP scheme (a condition
> = for AOR,=20 remember?).

Regardless of whether ENUM is doing it on = a phone=20 number sans domain or not, it MUST be marked as an "aor". =  Think of it=20 this way:
Suppose you call "sip:+18005551212@sp.com", and sp.com does an ENUM lookup on 18005551212, and = the NAPTR=20 result translated it to the non-800 specific number for it. =  The=20 freephone-model/redirection-usage NEEDs to see that 18005551212.=20 No?

 

No. The=20 aor tag has nothing todo with the freephone case, for that case the = "mp" tag=20 or in its absence  the first H-I entry is important to be able = to=20 determine the original called target.

 

 



That's also why I think you'd = want=20 Tel-URI's - because sp.com could=20 have received a Tel-URI with it and done that ENUM=20 lookup.


> And in fact, it goes to example.com, not = sp.com

So?=20  As far as the sp.com Proxy=20 cares, it has done an ENUM lookup and gotten a result which = changes the=20 req-uri and makes it route the call.  As far as it knows, "sip:+1234567890@example.com" is a contact = address of a=20 PSTN-Gateway or registered UA, in which case per the rules "sip:+1234567890@sp.com" WAS an AoR; whereas if = "sip:+1234567890@example.com" is another peer = domain then=20 it's not an AoR??

 

The=20 question is if it matters in this case.

 


-hadriel

 

 


------_=_NextPart_001_01CA0A2D.C17FE1B4-- From john.elwell@siemens-enterprise.com Tue Jul 21 13:30:15 2009 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 9FFAF28C371 for ; Tue, 21 Jul 2009 13:30:15 -0700 (PDT) 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 pbAiM2QSyA2N for ; Tue, 21 Jul 2009 13:30:14 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id AE95428C369 for ; Tue, 21 Jul 2009 13:30:14 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KN500I6EEL0TO@siemenscomms.co.uk> for sipcore@ietf.org; Tue, 21 Jul 2009 21:07:48 +0100 (BST) Date: Tue, 21 Jul 2009 21:07:47 +0100 From: "Elwell, John" In-reply-to: <1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com> To: Francois Audet , Hans Erik van Elburg , Paul Kyzivat Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0022A3616@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoF6CVRUPlMKkb7SrWHqBtgx6wCgwAAvgVQABgn/cAAH/S/oADX36qgAATaVgA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com> <4A5E83CB.4090701@cisco.com> <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com> Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 21 Jul 2009 20:30:15 -0000 =20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: 21 July 2009 18:46 > To: Elwell, John; Hans Erik van Elburg; Paul Kyzivat > Cc: SIPCORE; Hadriel Kaplan > Subject: RE: [sipcore] rfc4244bis: what is an AoR? >=20 >=20 > > > In this case, you'll have an entry in the middle > > > (elwell@10.10.15.12) that is not > > > an AOR. > > [JRE] Thinking about this further, I believe this DOES fit=20 > > the definition for AOR. In other words, my UAS is responsible for > > 10.10.15.12 and its "location service" tells it that the=20 > > contact for elwell is john@192.168.15.12. >=20 > Exactly. >=20 Francois, I'm confused, because I thought you were arguing that it was not an AOR in this redirection case. I had originally postulated that in most cases all but the last H-I entry would be marked AOR, and you cited this as an example where it wouldn't be marked as an AOR. But now you agree it would be marked as an AOR, which seems to support my original hypothesis. John From AUDET@nortel.com Tue Jul 21 13:59:42 2009 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 AA3853A6EA6 for ; Tue, 21 Jul 2009 13:59:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.469 X-Spam-Level: X-Spam-Status: No, score=-5.469 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, DNS_FROM_OPENWHOIS=1.13, 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 9vY3q2caoHVa for ; Tue, 21 Jul 2009 13:59:42 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id B1B633A6E98 for ; Tue, 21 Jul 2009 13:59:41 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6LKxBa09541; Tue, 21 Jul 2009 20:59:11 GMT 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, 21 Jul 2009 15:59:09 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F1A339E@zrc2hxm0.corp.nortel.com> In-Reply-To: A<0D5F89FAC29E2C41B98A6A762007F5D0022A3616@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoF6CVRUPlMKkb7SrWHqBtgx6wCgwAAvgVQABgn/cAAH/S/oADX36qgAATaVgAAAdl4gA== References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com> <4A5E83CB.4090701@cisco.com> <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com> A<0D5F89FAC29E2C41B98A6A762007F5D0022A3616@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Elwell, John" , "Hans Erik van Elburg" , "Paul Kyzivat" Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 21 Jul 2009 20:59:42 -0000 Re-reading this (again).=20 I don't believe 10.10.15.12 fits the "domain" criteria in the definition of AOR. So it would not be an AOR. =20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Tuesday, July 21, 2009 13:08 > To: Audet, Francois (SC100:3055); Hans Erik van Elburg; Paul Kyzivat > Cc: SIPCORE; Hadriel Kaplan > Subject: RE: [sipcore] rfc4244bis: what is an AoR? >=20 > =20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: 21 July 2009 18:46 > > To: Elwell, John; Hans Erik van Elburg; Paul Kyzivat > > Cc: SIPCORE; Hadriel Kaplan > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > >=20 > >=20 > > > > In this case, you'll have an entry in the middle > > > > (elwell@10.10.15.12) that is not > > > > an AOR. > > > [JRE] Thinking about this further, I believe this DOES fit the=20 > > > definition for AOR. In other words, my UAS is responsible for > > > 10.10.15.12 and its "location service" tells it that the=20 > contact for=20 > > > elwell is john@192.168.15.12. > >=20 > > Exactly. > >=20 >=20 > Francois, >=20 > I'm confused, because I thought you were arguing that it was=20 > not an AOR in this redirection case. I had originally=20 > postulated that in most cases all but the last H-I entry=20 > would be marked AOR, and you cited this as an example where=20 > it wouldn't be marked as an AOR. But now you agree it would=20 > be marked as an AOR, which seems to support my original hypothesis. >=20 > John >=20 From Martin.Thomson@andrew.com Tue Jul 21 18:46:42 2009 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 4EFB13A68B5 for ; Tue, 21 Jul 2009 18:46:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.144 X-Spam-Level: X-Spam-Status: No, score=-1.144 tagged_above=-999 required=5 tests=[AWL=-0.959, BAYES_40=-0.185] 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 DHQ86YL3aRhg for ; Tue, 21 Jul 2009 18:46:41 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 58BDB3A68A6 for ; Tue, 21 Jul 2009 18:46:41 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_21_21_09_02 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from aopexbh2.andrew.com [10.86.20.25] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Tue, 21 Jul 2009 21:09:02 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by aopexbh2.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 21 Jul 2009 20:46:38 -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, 21 Jul 2009 20:46:37 -0500 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-ietf-sipcore-event-rate-control and average rate Thread-Index: AcoKbkBduECwUQuGSGmNYGVX4SYKSQ== From: "Thomson, Martin" To: X-OriginalArrivalTime: 22 Jul 2009 01:46:38.0719 (UTC) FILETIME=[4107C8F0:01CA0A6E] Subject: [sipcore] draft-ietf-sipcore-event-rate-control and average rate 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, 22 Jul 2009 01:46:42 -0000 VGhpcyBkb2N1bWVudCBpcyB3ZWxsIHdyaXR0ZW4gYW5kIHRob3JvdWdoLiAgSSBoYXZlIG5vIGNv bmNlcm5zIHdpdGggdGhlIHByb2JsZW0gc3RhdGVtZW50IGFuZCBzb2x1dGlvbiBkZXNjcmlwdGlv biBmb3IgbWluLSBhbmQgbWF4LWludGVydmFsLg0KDQpBdmVyYWdlLWludGVydmFsIGlzIHNvbWV0 aGluZyBvZiBhIGNvbmNlcm4uICBUaGUgdXNlIGNhc2UgZG9lc24ndCBzZWVtIHBhcnRpY3VsYXJs eSByZWxldmFudC4gIFRyYWNraW5nIGNhbiByZXN1bHQgaW4gY29uc3RhbnQgc3RhdGUgY2hhbmdl cywgd2hlcmUgbm90aWZpY2F0aW9ucyBhcmUgZ2VuZXJhdGVkIGF0IG1pbi1pbnRlcnZhbC4gIFVz ZSBjYXNlcyBmb3IgdGhpcyBzZWVtIHRvIGJlIG1vcmUgaW4gdGhlIHNhbWUgY2FtcCBhcyBtYXgt aW50ZXJ2YWwuICBHaXZlbiB0aGF0LCBhbmQgdGhlIGluY3JlYXNlZCBjb21wbGV4aXR5LCBJIHN0 cnVnZ2xlIHdpdGggdGhlIGp1c3RpZmljYXRpb24gZm9yIHRoaXMgcGFyYW1ldGVyLg0KDQpPbmUg dW5mb3J0dW5hdGUgY29uc2VxdWVuY2Ugb2YgYXZlcmFnZS1pbnRlcnZhbCBpcyB0aGF0IHRoZSBt b3N0IGludGVyZXN0aW5nIHRpbWVzIHJlc3VsdCBpbiB0aGUgZmV3ZXN0IG5vdGlmaWNhdGlvbnMu ICBGb3IgYSBjb250aW51b3VzbHkgY2hhbmdpbmcgZWxlbWVudCwgYSBwZXJpb2Qgb2YgY29uc3Rh bnQgY2hhbmdlcyBnZW5lcmF0ZXMgbm90aWZpY2F0aW9ucyBhdCBtaW4taW50ZXJ2YWwuICBJbW1l ZGlhdGVseSBhZnRlciBhIHBlcmlvZCBvZiBjb25zdGFudCBub3RpZmljYXRpb25zIGNvbmNsdWRl cywgdGhlIGF2ZXJhZ2UtaW50ZXJ2YWwgZW5mb3JjZXMgdGhlIGxvbmdlc3QgdGltZW91dC4gIEEg ZmluYWwgc21hbGwgY2hhbmdlIG1pZ2h0IG5vdCBwYXNzIGEgdHJpZ2dlciwgYnV0IGNvdWxkIHN0 aWxsIGJlIHVzZWZ1bC4gIEdpdmVuIHRoYXQgY29udGludW91cyB2YWx1ZXMsIGxpa2UgbG9jYXRp b24sIGdlbmVyYWxseSBkb24ndCBzdG9wIGNoYW5naW5nIGF0IHRob3NlIGNvbnZlbmllbnQgaW50 ZXJ2YWxzLCB0aGlzIG9ubHkgcHJvbG9uZ3MgdGhlIHRpbWUgYmVmb3JlIGFueSBmaW5hbCBzbWFs bCBtb3ZlbWVudHMgYXJlIGtub3duLg0KDQpQZXJoYXBzIGl0IG1pZ2h0IGJlIHN1Z2dlc3RlZCB0 aGF0IG1pbi1pbnRlcnZhbCBiZSB1c2VkIG9uZSBsYXN0IHRpbWUgZm9yIGNvbnRpbnVvdXMgdmFs dWVzIHRvIGF2b2lkIHRoYXQgcHJvYmxlbS4gIEkgZG9uJ3Qga25vdy4NCg0KT24gYSBkaWZmZXJl bnQgdG9waWM6IDYwcy4gIEknZCBsaWtlIHRvIHByb3Bvc2UgYW4gZXhwYW5zaW9uIHRvIHRoZSBk ZWZpbml0aW9uIG9mIGF2ZXJhZ2UtaW50ZXJ2YWwuICBBcyBzcGVjaWZpZWQsIHRoZSBhbGdvcml0 aG0gcmVhY2hlcyBzdGFibGUgc3RhdGUgNjBzIGFmdGVyIGFueSBmb3JtIG9mIGV2ZW50LiAgSG93 ZXZlciwgdGhpcyB2YWx1ZSBpcyBvbmx5IGVmZmVjdGl2ZSBvdmVyIGEgc2hvcnQgcmFuZ2Ugb2Yg YXZlcmFnZS1pbnRlcnZhbCB2YWx1ZXMuICBPdXRzaWRlIHRoYXQgcmFuZ2UsIGl0IG9ubHkgc2Vy dmVzIHRvIGdlbmVyYXRlIHN0cmFuZ2UgYmVoYXZpb3VyLiAgTWF5YmU6DQogDQogYXZlcmFnZS1p bnRlcnZhbC1wYXJhbSA9ICAgImF2ZXJhZ2UtaW50ZXJ2YWwiIEVRVUFMIGRlbHRhLXNlY29uZHMg WyAiLyIgZGVsdGEtc2Vjb25kcyBdDQoNCkdpdmluZyB0aGUgd2F0Y2hlciBzb21lIGFiaWxpdHkg dG8gaW5mbHVlbmNlIHRoZSBwZXJpb2QgaGVscCB3aXRoIGRpZmZlcmVudCBldmVudCByYXRlcyAo YW4gYXZlcmFnZSBvZiAxMDBzIGRvZXNuJ3Qgd29yayBwYXJ0aWN1bGFybHkgd2VsbCBhcyBzcGVj aWZpZWQpLiAgQSBkZWZhdWx0IHRoYXQgaXMgYmFzZWQgb24gdGhlIGFjdHVhbCB2YWx1ZSAoYXZl cmFnZS1pbnRlcnZhbCB4IDEwKSBtaWdodCBhbHNvIGJlIGJldHRlciB0aGFuIGEgZml4ZWQgdmFs dWUuICANCg0KS2VlcCBpbiBtaW5kIGhvd2V2ZXIsIHRoYXQgdGhpcyBjb3VsZCByZXF1aXJlIGxh cmdlciBhbW91bnRzIG9mIFBBIHN0YXRlIC0gdGhlIHN0YXRlIHJlcXVpcmVkIGluIGNhbGN1bGF0 aW5nIHRoZSB0aW1lb3V0IG92ZXIgbG9uZ2VyIGludGVydmFscyB3aXRoIGhpZ2ggbm90aWZpY2F0 aW9uIHJhdGVzIGlzIHNpZ25pZmljYW50ICh1cCB0byBwZXJpb2QgLyBtaW4taW50ZXJ2YWwgdGlt ZXN0YW1wcyBuZWVkIHRvIGJlIG1haW50YWluZWQpLg0KDQpOb3RlOiBpdCdzIHdvcnRoIG5vdGlu ZyB0aGF0IG1pbi1pbnRlcnZhbCBhbmQgYXZlcmFnZS1pbnRlcnZhbCBlZmZlY3RpdmVseSBjb21i aW5lIHRvIHByb2R1Y2UgbWF4LWludGVydmFsOg0KDQogIEVmZmVjdGl2ZSBtYXgtaW50ZXJ2YWwg PSBNSU4obWF4LWludGVydmFsLCBhdmVyYWdlLWludGVydmFsIF4gMiAvIG1pbi1pbnRlcnZhbCkN Cg0KLS1NYXJ0aW4NCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpUaGlzIG1lc3NhZ2UgaXMgZm9yIHRoZSBkZXNpZ25hdGVkIHJlY2lwaWVudCBvbmx5IGFu ZCBtYXkNCmNvbnRhaW4gcHJpdmlsZWdlZCwgcHJvcHJpZXRhcnksIG9yIG90aGVyd2lzZSBwcml2 YXRlIGluZm9ybWF0aW9uLiAgDQpJZiB5b3UgaGF2ZSByZWNlaXZlZCBpdCBpbiBlcnJvciwgcGxl YXNlIG5vdGlmeSB0aGUgc2VuZGVyDQppbW1lZGlhdGVseSBhbmQgZGVsZXRlIHRoZSBvcmlnaW5h bC4gIEFueSB1bmF1dGhvcml6ZWQgdXNlIG9mDQp0aGlzIGVtYWlsIGlzIHByb2hpYml0ZWQuDQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClttZjJdDQo= From john.elwell@siemens-enterprise.com Wed Jul 22 00:00:47 2009 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 2C68428C0E9 for ; Wed, 22 Jul 2009 00:00:47 -0700 (PDT) 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.000, 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 1EcgmWEjVq+J for ; Wed, 22 Jul 2009 00:00:46 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 3AD793A6995 for ; Wed, 22 Jul 2009 00:00:46 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KN60090A6XL1M@siemenscomms.co.uk> for sipcore@ietf.org; Wed, 22 Jul 2009 07:20:09 +0100 (BST) Date: Wed, 22 Jul 2009 07:20:08 +0100 From: "Elwell, John" In-reply-to: <1ECE0EB50388174790F9694F77522CCF1F1A339E@zrc2hxm0.corp.nortel.com> To: Francois Audet , Hans Erik van Elburg , Paul Kyzivat Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0022A3667@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoF6CVRUPlMKkb7SrWHqBtgx6wCgwAAvgVQABgn/cAAH/S/oADX36qgAATaVgAAAdl4gAATblIA Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com> <4A5E83CB.4090701@cisco.com> <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0022A3616@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F1A339E@zrc2hxm0.corp.nortel.com> Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 22 Jul 2009 07:00:47 -0000 Many deployments today use IP address instead of domain (e.g., for a SIP-PBX), so are we saying that any URIs with a SIP-PBX IP address, say, are not AORs? This seems to underline the point that the RFC 3261 definition of AOR seems to be open to different interpretations. John=20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: 21 July 2009 21:59 > To: Elwell, John; Hans Erik van Elburg; Paul Kyzivat > Cc: SIPCORE; Hadriel Kaplan > Subject: RE: [sipcore] rfc4244bis: what is an AoR? >=20 > Re-reading this (again).=20 >=20 > I don't believe 10.10.15.12 fits the "domain" criteria in the=20 > definition > of AOR. So it would not be an AOR. >=20 > =20 >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > > Sent: Tuesday, July 21, 2009 13:08 > > To: Audet, Francois (SC100:3055); Hans Erik van Elburg; Paul Kyzivat > > Cc: SIPCORE; Hadriel Kaplan > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortel.com] > > > Sent: 21 July 2009 18:46 > > > To: Elwell, John; Hans Erik van Elburg; Paul Kyzivat > > > Cc: SIPCORE; Hadriel Kaplan > > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > > >=20 > > >=20 > > > > > In this case, you'll have an entry in the middle > > > > > (elwell@10.10.15.12) that is not > > > > > an AOR. > > > > [JRE] Thinking about this further, I believe this DOES fit the=20 > > > > definition for AOR. In other words, my UAS is responsible for > > > > 10.10.15.12 and its "location service" tells it that the=20 > > contact for=20 > > > > elwell is john@192.168.15.12. > > >=20 > > > Exactly. > > >=20 > >=20 > > Francois, > >=20 > > I'm confused, because I thought you were arguing that it was=20 > > not an AOR in this redirection case. I had originally=20 > > postulated that in most cases all but the last H-I entry=20 > > would be marked AOR, and you cited this as an example where=20 > > it wouldn't be marked as an AOR. But now you agree it would=20 > > be marked as an AOR, which seems to support my original hypothesis. > >=20 > > John > >=20 >=20 From ietf.hanserik@gmail.com Wed Jul 22 00:38:59 2009 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 00D053A6906 for ; Wed, 22 Jul 2009 00:38:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.165 X-Spam-Level: X-Spam-Status: No, score=-2.165 tagged_above=-999 required=5 tests=[AWL=0.433, 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 Y6RZKIbOFewo for ; Wed, 22 Jul 2009 00:38:57 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id D939C3A692D for ; Wed, 22 Jul 2009 00:38:37 -0700 (PDT) Received: by ewy26 with SMTP id 26so5985ewy.37 for ; Wed, 22 Jul 2009 00:35:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=bwRHesK0nJh2mOR1LwZWtEgUt1JEpHna6UOINIFK94U=; b=LTZuxmylGapNZojT8rBXwOSk59YArsrrUg1qx4IX+7FH/TF44dpL0u5NMjoHDDhHyw L4P5SDNzCSU+Kx8cXNjXc/TWIw1cpXl+DclKp32A92Xe/oU2JGThYW4uJhHIi9FpehAf mFgI0f2pEGSmTnF38Son5ZyP9O9VDMEGyAnrA= 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=MP22vAAgI1QfjGWGDR4fA9tN4QrX4Le3BRCnA15mwHvy4UdGi+NT75brj17MWQVGKU RxpuXh5wkXErEpOWS8IrsWjjxKNwGe+xXVIh4/vpu+zxf2J9f2h27UVELCRdnxM+qrRy F8+N+8g3DLN96Ka49Ig+hNgHK9aTw2YhsaHn8= MIME-Version: 1.0 Received: by 10.210.126.18 with SMTP id y18mr648075ebc.70.1248248120639; Wed, 22 Jul 2009 00:35:20 -0700 (PDT) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F155B2A@zrc2hxm0.corp.nortel.com> References: <4A5FAF4E.4030901@cisco.com> <9ae56b1e0907171313u6b7e09c3hd0eee3399a4ae681@mail.gmail.com> <9ae56b1e0907172354q353f23ffla9fd0c6a0f55d2cd@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1F155B2A@zrc2hxm0.corp.nortel.com> Date: Wed, 22 Jul 2009 09:35:20 +0200 Message-ID: <9ae56b1e0907220035l7ae50042x2f71dabcae331e9@mail.gmail.com> From: Hans Erik van Elburg To: Francois Audet Content-Type: multipart/alternative; boundary=0015174989f6d2824c046f466985 Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 22 Jul 2009 07:38:59 -0000 --0015174989f6d2824c046f466985 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Assuming that you are talking about "- if no "mp" found take the first H-I entry" Then I really ment the first from teh begionning, as in this case no mappin= g occured the first entry must be the best guess for the addressed target. /Hans Erik van Elburg On Tue, Jul 21, 2009 at 7:54 PM, Francois Audet wrote: > By "first H-I entry", you mean the "first from the end", i.e., "the > last", right? > > ------------------------------ > *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > *Sent:* Friday, July 17, 2009 23:55 > *To:* Hadriel Kaplan > *Cc:* Audet, Francois (SC100:3055); Paul Kyzivat; SIPCORE > > *Subject:* Re: [sipcore] rfc4244bis: what is an AoR? > > Yes the relevant flags are dependent on what you in your role of UAS > would like to retrieve. > > The rules would be very simple. > To retrieve the addressed target (freephone, etc): > - traverse all H-I entries backward until an "mp" entry is found, if foun= d > this is the addressed target > - if no "mp" found take the first H-I entry > - if no History-Info header take the Request-URI value > > To retrieve the last aor before it was overwritten by contact > address (similar as P-Called-Party-ID): > - traverse all H-I entries backward until an "aor" entry is found, if > found this is the last AOR used > > /Hans Erik van Elburg > > On Fri, Jul 17, 2009 at 11:43 PM, Hadriel Kaplan = wrote: > >> I=92m confused (I know, not a hard thing to make me be apparently L). >> >> In a previous chain of emails I thought the purpose of the =93mp=94 flag= was >> to indicate a retarget happened, but that the subsequent =93aor=94 flagg= ed URI >> was what would actually be used for applications, because it is the >> =93cleaned-up=94 form of the URI being retargeted to, since it actually >> identifies what the authoritative domain which got it claims it >> location-service routed with. >> >> >> >> Your response indicates that the =93mp=94 flagged URI would actually be = used >> by the application, even when it does not have an =93aor=94 flag (as it = would >> not in this case). >> >> >> >> Which is it? Or are the cases different for different application uses, >> for which flags are important? >> >> >> >> -hadriel >> >> >> ------------------------------ >> >> *From:* Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] >> *Sent:* Friday, July 17, 2009 4:13 PM >> *To:* Hadriel Kaplan >> *Cc:* Francois Audet; Paul Kyzivat; SIPCORE >> >> *Subject:* Re: [sipcore] rfc4244bis: what is an AoR? >> >> >> >> inline... >> /Hans Erik van Elburg >> >> On Fri, Jul 17, 2009 at 4:52 PM, Hadriel Kaplan >> wrote: >> >> >> >> > -----Original Message----- >> > From: Francois Audet [mailto:audet@nortel.com] >> >> > Sent: Thursday, July 16, 2009 8:37 PM >> > >> > >> Say I call sip:+1234567890@sp.com ;user= =3Dphone. >> My proxy is "sp.com", >> > >> right? >> > >> >> > >> Then sp.net does ENUM query. >> >> Did you intend for this to be "sp.net" and thus a different domain from = " >> sp.com"? Or was that a typo? I am assuming it was a typo. >> >> >> > > If we assume that ENUM qualifies as a location service (and I am now >> > > convinced that it does), then this URI *is* an AOR in sp.com. >> > >> > No, because it's not the right domain. It's doing the ENUM on a phone >> > number. So it really has nothing to do with a SIP scheme (a condition >> > for AOR, remember?). >> >> Regardless of whether ENUM is doing it on a phone number sans domain or >> not, it MUST be marked as an "aor". Think of it this way: >> Suppose you call "sip:+18005551212@sp.com "= , >> and sp.com does an ENUM lookup on 18005551212, and the NAPTR result >> translated it to the non-800 specific number for it. The >> freephone-model/redirection-usage NEEDs to see that 18005551212. No? >> >> >> >> No. The aor tag has nothing todo with the freephone case, for that case >> the "mp" tag or in its absence the first H-I entry is important to be a= ble >> to determine the original called target. >> >> >> >> >> >> >> >> That's also why I think you'd want Tel-URI's - because sp.com could have >> received a Tel-URI with it and done that ENUM lookup. >> >> >> > And in fact, it goes to example.com, not sp.com >> >> So? As far as the sp.com Proxy cares, it has done an ENUM lookup and >> gotten a result which changes the req-uri and makes it route the call. = As >> far as it knows, "sip:+1234567890@example.com" >> is a contact address of a PSTN-Gateway or registered UA, in which case p= er >> the rules "sip:+1234567890@sp.com " WAS an >> AoR; whereas if "sip:+1234567890@example.com" >> is another peer domain then it's not an AoR?? >> >> >> >> The question is if it matters in this case. >> >> >> >> >> -hadriel >> >> >> > > --0015174989f6d2824c046f466985 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Assuming that you are talking about "- if no "= mp" found take the first H-I entry"

The= n I really ment the first from teh begionning, as in this case no mapping o= ccured the first entry must be the best guess for the addressed target.

/Hans Erik van Elburg


On Tue, Jul 21, 2009 at 7:54 PM, Francoi= s Audet <audet@nor= tel.com> wrote:
By=20 "first H-I entry", you mean the "first from the end", i= .e., "the last",=20 right?

From: Hans Erik= van Elburg=20 [mailto:ietf= .hanserik@gmail.com]
Sent: Friday, July 17, 2009=20 23:55
To: Hadriel Kaplan
Cc: Audet, Francois (SC100:3= 055);=20 Paul Kyzivat; SIPCORE

Subject: Re: [sipcore] rfc4244bis: what is an=20 AoR?

Yes the relevant flags are dependent on what you in your role of UAS= =20 would like =A0to retrieve.

The rules would be very simple.

To retrieve the addressed target (freephone, etc):=A0
- traverse all H-I entries backward until an "mp" entry is= found, if=20 found this is the addressed target
- if no "mp" found take the first H-I entry
- if no History-Info header take the Request-URI value

To retrieve the last aor before it was overwritten by contact=20 address=A0(similar as P-Called-Party-ID):=A0
- traverse all H-I entries backward until an "aor" entry i= s found, if=20 found this is the last AOR used

/Hans Erik van Elburg

On Fri, Jul 17, 2009 at 11:43 PM, Hadriel Kapl= an <HKaplan@acmepacket.com>=20 wrote:

I=92m confused (I=20 know, not a hard thing to make me be apparently L).

In a previous chain=20 of emails I thought the purpose of the =93mp=94 flag was to indicate a = retarget=20 happened, but that the subsequent =93aor=94 flagged URI was what would = actually=20 be used for applications, because it is the =93cleaned-up=94 form of th= e URI=20 being retargeted to, since it actually identifies what the authoritativ= e=20 domain which got it claims it location-service routed=20 with.

=A0

Your response=20 indicates that the =93mp=94 flagged URI would actually be used by the= =20 application, even when it does not have an =93aor=94 flag (as it would = not in=20 this case).

=A0

Which is it?=A0=20 Or are the cases different for different application uses, for which fl= ags=20 are important?

=A0

-hadriel

=A0

From: Hans=20 Erik van Elburg [mailto:ietf.hanserik@gmail.com]
Sent: Friday, July 17, 2009 4:13=20 PM
To: Hadriel=20 Kaplan
Cc: Francois A= udet;=20 Paul Kyzivat; SIPCORE


Subject: Re:=20 [sipcore] rfc4244bis: what is an AoR?

=A0

inline...
/Hans Erik van= =20 Elburg

On Fri,=20 Jul 17, 2009 at 4:52 PM, Hadriel Kaplan <HKaplan@acmepacket.com> wrote:



> -----Original Message-----
>=20 From: Francois Audet [mailto:audet@nortel.com]

> Sent: Thursday, July 16, 2009 8:37= =20 PM
>
> >> Say I call sip:+1234567890@sp.com;user=3Dphone. My= proxy is "sp.com"= ;,
> >>=20 right?
> >>
> >> Then sp.net does ENUM query.

Did you intend for this to be "sp.net" and thus a differen= t domain=20 from "sp.com"= ? =A0Or was that a=20 typo? =A0I am assuming it was a typo.


> > If we assume= =20 that ENUM qualifies as a location service (and I am now
> >=20 convinced that it does), then this URI *is* an AOR in sp.com.
>
> No, because=20 it's not the right domain. It's doing the ENUM on a phone
&g= t; number. So=20 it really has nothing to do with a SIP scheme (a condition
> for = AOR,=20 remember?).

Regardless of whether ENUM is doing it on a phone=20 number sans domain or not, it MUST be marked as an "aor". =A0= Think of it=20 this way:
Suppose you call "sip:+18005551212@sp.com", and sp.com does an ENUM lookup on 180= 05551212, and the NAPTR=20 result translated it to the non-800 specific number for it. =A0The=20 freephone-model/redirection-usage NEEDs to see that 18005551212.=20 No?

=A0

No. The=20 aor tag has nothing todo with the freephone case, for that case the &qu= ot;mp" tag=20 or in its absence =A0the first H-I entry is important to be able to=20 determine the original called target.

=A0

=A0



That's also why I think you'd want=20 Tel-URI's - because s= p.com could=20 have received a Tel-URI with it and done that ENUM=20 lookup.


> And in fact, it goes to example.com, not sp.com

So?=20 =A0As far as the sp.com Proxy=20 cares, it has done an ENUM lookup and gotten a result which changes t= he=20 req-uri and makes it route the call. =A0As far as it knows, "sip:+1234= 567890@example.com" is a contact address of a=20 PSTN-Gateway or registered UA, in which case per the rules "sip:+1234567890= @sp.com" WAS an AoR; whereas if "sip:+1234567890@example.com&qu= ot; is another peer domain then=20 it's not an AoR??

=A0

The=20 question is if it matters in this case.

=A0


-hadriel

=A0

=

--0015174989f6d2824c046f466985-- From ietf.hanserik@gmail.com Wed Jul 22 00:41:28 2009 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 73FE93A6D42 for ; Wed, 22 Jul 2009 00:41:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.273 X-Spam-Level: X-Spam-Status: No, score=-2.273 tagged_above=-999 required=5 tests=[AWL=0.325, 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 0IBivNY52Ndd for ; Wed, 22 Jul 2009 00:41:26 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 520DB3A6BD1 for ; Wed, 22 Jul 2009 00:41:26 -0700 (PDT) Received: by ewy26 with SMTP id 26so8009ewy.37 for ; Wed, 22 Jul 2009 00:40:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=zh0ac+om2S+p4lrON2l880q55/hljYzfI89Prti39yI=; b=wSj4MomtxYpJ6K1w8xT8B7nfHekKGFH3b3zvEsvH91v4TZTS3OUXvlAv2jCkYAujUb bYPtM+YFNMDJiwnt64AQdIiOEaG0Mv5NQvYgijSPfp0cWtx9gFLheTKtJ3sXd3ULh3KR LAFItiSGdmUpkhjFI5MPRhWAfbBBy78ZgaTgQ= 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=ls2cn6BI6fhjgQuBKU0Wy0lPTOSBaOXJqBrKnp1zXUcWTFIcsHnU59TZqWLkynTTu9 qwrHySAPRZP4xNIIznV3q2fVTr9RsY4I4kxam265LnffvRh5A3RUYdLGPV0pdX9wonXJ qEFrPrNrQsa1JeFyo8A9zc2fMt1HCedssxb78= MIME-Version: 1.0 Received: by 10.211.178.8 with SMTP id f8mr4863348ebp.91.1248248440404; Wed, 22 Jul 2009 00:40:40 -0700 (PDT) In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0022A3667@GBNTHT12009MSX.gb002.siemens.net> References: <4A5E83CB.4090701@cisco.com> <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3616@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F1A339E@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3667@GBNTHT12009MSX.gb002.siemens.net> Date: Wed, 22 Jul 2009 09:40:40 +0200 Message-ID: <9ae56b1e0907220040k53ba2cdcp190803631e79a90e@mail.gmail.com> From: Hans Erik van Elburg To: "Elwell, John" Content-Type: multipart/alternative; boundary=0015174c3c66e1b9f2046f467c80 Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 22 Jul 2009 07:41:28 -0000 --0015174c3c66e1b9f2046f467c80 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'm confused to what is the question here, are we talking about a UAS or a proxy? /Hans Erik van Elburg On Wed, Jul 22, 2009 at 8:20 AM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > Many deployments today use IP address instead of domain (e.g., for a > SIP-PBX), so are we saying that any URIs with a SIP-PBX IP address, say, > are not AORs? This seems to underline the point that the RFC 3261 > definition of AOR seems to be open to different interpretations. > > John > > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: 21 July 2009 21:59 > > To: Elwell, John; Hans Erik van Elburg; Paul Kyzivat > > Cc: SIPCORE; Hadriel Kaplan > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > > > > Re-reading this (again). > > > > I don't believe 10.10.15.12 fits the "domain" criteria in the > > definition > > of AOR. So it would not be an AOR. > > > > > > > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Tuesday, July 21, 2009 13:08 > > > To: Audet, Francois (SC100:3055); Hans Erik van Elburg; Paul Kyzivat > > > Cc: SIPCORE; Hadriel Kaplan > > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > > > > > > > > > > > > > -----Original Message----- > > > > From: Francois Audet [mailto:audet@nortel.com] > > > > Sent: 21 July 2009 18:46 > > > > To: Elwell, John; Hans Erik van Elburg; Paul Kyzivat > > > > Cc: SIPCORE; Hadriel Kaplan > > > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > > > > > > > > > > > > > > In this case, you'll have an entry in the middle > > > > > > (elwell@10.10.15.12) that is not > > > > > > an AOR. > > > > > [JRE] Thinking about this further, I believe this DOES fit the > > > > > definition for AOR. In other words, my UAS is responsible for > > > > > 10.10.15.12 and its "location service" tells it that the > > > contact for > > > > > elwell is john@192.168.15.12. > > > > > > > > Exactly. > > > > > > > > > > Francois, > > > > > > I'm confused, because I thought you were arguing that it was > > > not an AOR in this redirection case. I had originally > > > postulated that in most cases all but the last H-I entry > > > would be marked AOR, and you cited this as an example where > > > it wouldn't be marked as an AOR. But now you agree it would > > > be marked as an AOR, which seems to support my original hypothesis. > > > > > > John > > > > > > --0015174c3c66e1b9f2046f467c80 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable I'm confused to what is the question here, are we talking about a UAS o= r a proxy?

/Hans Erik van Elburg


On Wed, Jul 22, 2009 at 8:20 AM, Elwell,= John <john.elwell@siemens-enterprise.com> wrote:
Many deployments today use IP address instead of domain (e.g., for a
SIP-PBX), so are we saying that any URIs with a SIP-PBX IP address, say, are not AORs? This seems to underline the point that the RFC 3261
definition of AOR seems to be open to different interpretations.

John

> -----Original Message-----
> From: Francois Audet [mailto:audet= @nortel.com]
> Sent: 21 July 2009 21:59
> To: Elwell, John; Hans Erik van Elburg; Paul Kyzivat
> Cc: SIPCORE; Hadriel Kaplan
> Subject: RE: [sipcore] rfc4244bis: what is an AoR?
>
> Re-reading this (again).
>
> I don't believe 10.10.15.12 fits the "domain" criteria i= n the
> definition
> of AOR. So it would not be an AOR.
>
>
>
> > -----Original Message-----
> > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]
> > Sent: Tuesday, July 21, 2009 13:08
> > To: Audet, Francois (SC100:3055); Hans Erik van Elburg; Paul Kyzi= vat
> > Cc: SIPCORE; Hadriel Kaplan
> > Subject: RE: [sipcore] rfc4244bis: what is an AoR?
> >
> >
> >
> > > -----Original Message-----
> > > From: Francois Audet [mailto:audet@nortel.com]
> > > Sent: 21 July 2009 18:46
> > > To: Elwell, John; Hans Erik van Elburg; Paul Kyzivat
> > > Cc: SIPCORE; Hadriel Kaplan
> > > Subject: RE: [sipcore] rfc4244bis: what is an AoR?
> > >
> > >
> > > > > In this case, you'll have an entry in the midd= le
> > > > > (elwell@10.1= 0.15.12) that is not
> > > > > an AOR.
> > > > [JRE] Thinking about this further, I believe this DOES = fit the
> > > > definition for AOR. In other words, my UAS is responsib= le for
> > > > 10.10.15.12 and its "location service" tells = it that the
> > contact for
> > > > elwell is john@19= 2.168.15.12.
> > >
> > > Exactly.
> > >
> >
> > Francois,
> >
> > I'm confused, because I thought you were arguing that it was<= br> > > not an AOR in this redirection case. I had originally
> > postulated that in most cases all but the last H-I entry
> > would be marked AOR, and you cited this as an example where
> > it wouldn't be marked as an AOR. But now you agree it would > > be marked as an AOR, which seems to support my original hypothesi= s.
> >
> > John
> >
>

--0015174c3c66e1b9f2046f467c80-- From john.elwell@siemens-enterprise.com Wed Jul 22 00:50:32 2009 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 0F6AA28C345 for ; Wed, 22 Jul 2009 00:50:32 -0700 (PDT) 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 Mdwhc1XTsOsW for ; Wed, 22 Jul 2009 00:50:31 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 060E228C10C for ; Wed, 22 Jul 2009 00:50:31 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KN600E1LB2SBL@siemenscomms.co.uk> for sipcore@ietf.org; Wed, 22 Jul 2009 08:49:40 +0100 (BST) Date: Wed, 22 Jul 2009 08:49:38 +0100 From: "Elwell, John" In-reply-to: <9ae56b1e0907220040k53ba2cdcp190803631e79a90e@mail.gmail.com> To: Hans Erik van Elburg Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0022A36A0@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoKn9nKy6x65bPNQYKmxEbpwTTIGgAAG9cQ Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <4A5E83CB.4090701@cisco.com> <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3616@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F1A339E@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3667@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0907220040k53ba2cdcp190803631e79a90e@mail.gmail.com> Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 22 Jul 2009 07:50:32 -0000 Hans Erik, When the subject came up we were talking about redirect servers, i.e., anything that issues a 3xx response. This may or may not be a device that acts as a UAS for some requests. So if I receive sip:john@123.123.123.123 and redirect it elsewhere, was that URI an AOR or not? According to the RFC 3261 definition that Francois cited, I think it is, i.e., I look up the URI in my location server, find a contact and redirect to it. John > -----Original Message----- > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 > Sent: 22 July 2009 08:41 > To: Elwell, John > Cc: Francois Audet; Paul Kyzivat; SIPCORE; Hadriel Kaplan > Subject: Re: [sipcore] rfc4244bis: what is an AoR? >=20 > I'm confused to what is the question here, are we talking=20 > about a UAS or a proxy?=20 >=20 > /Hans Erik van Elburg >=20 >=20 >=20 > On Wed, Jul 22, 2009 at 8:20 AM, Elwell, John=20 > wrote: >=20 >=20 > Many deployments today use IP address instead of domain=20 > (e.g., for a > SIP-PBX), so are we saying that any URIs with a SIP-PBX=20 > IP address, say, > are not AORs? This seems to underline the point that=20 > the RFC 3261 > definition of AOR seems to be open to different interpretations. > =09 > John > =09 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > =09 > > Sent: 21 July 2009 21:59 > > To: Elwell, John; Hans Erik van Elburg; Paul Kyzivat > > Cc: SIPCORE; Hadriel Kaplan > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > > > > Re-reading this (again). > > > > I don't believe 10.10.15.12 fits the "domain" criteria in the > > definition > > of AOR. So it would not be an AOR. > > > > > > > > > -----Original Message----- > > > From: Elwell, John=20 > [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Tuesday, July 21, 2009 13:08 > > > To: Audet, Francois (SC100:3055); Hans Erik van=20 > Elburg; Paul Kyzivat > > > Cc: SIPCORE; Hadriel Kaplan > > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > > > > > > > > > > > > > -----Original Message----- > > > > From: Francois Audet [mailto:audet@nortel.com] > > > > Sent: 21 July 2009 18:46 > > > > To: Elwell, John; Hans Erik van Elburg; Paul Kyzivat > > > > Cc: SIPCORE; Hadriel Kaplan > > > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > > > > > > > > > > > > > > In this case, you'll have an entry in the middle > > > > > > (elwell@10.10.15.12) that is not > > > > > > an AOR. > > > > > [JRE] Thinking about this further, I believe=20 > this DOES fit the > > > > > definition for AOR. In other words, my UAS is=20 > responsible for > > > > > 10.10.15.12 and its "location service" tells it that the > > > contact for > > > > > elwell is john@192.168.15.12. > > > > > > > > Exactly. > > > > > > > > > > Francois, > > > > > > I'm confused, because I thought you were arguing that it was > > > not an AOR in this redirection case. I had originally > > > postulated that in most cases all but the last H-I entry > > > would be marked AOR, and you cited this as an example where > > > it wouldn't be marked as an AOR. But now you agree it would > > > be marked as an AOR, which seems to support my=20 > original hypothesis. > > > > > > John > > > > > > =09 >=20 >=20 >=20 From ietf.hanserik@gmail.com Wed Jul 22 02:24:01 2009 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 8FEEB28C2D3 for ; Wed, 22 Jul 2009 02:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.338 X-Spam-Level: X-Spam-Status: No, score=-2.338 tagged_above=-999 required=5 tests=[AWL=0.260, 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 M3oLRXDw3DAy for ; Wed, 22 Jul 2009 02:24:00 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 9EEDD3A6D21 for ; Wed, 22 Jul 2009 02:23:58 -0700 (PDT) Received: by ewy26 with SMTP id 26so56738ewy.37 for ; Wed, 22 Jul 2009 02:23:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=0n/Q1No1A5Zhiht8AW43bHgn4WDp4ZL3EfuihF4LXNE=; b=Gbd25ozcL3n4n94EYrthvIhPie04oI5s0K5qqGzPhMHB1Zd1jJYcuvlaeXLtJkKR51 Jv+GwgvEEE+wyaa9rG6dMz8+NhkKv/UYoLh3E7Cpa840gL+7JvRYiWGNico9vVIVzXwR XFVhwhl3nEeCArABA1D1lX+G3qJKynPJzZ+rk= 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=E3uGYZRwj24jz3wu86nutG6twMW3FOQ/H38jWt+1bhEoKWTi1X/h28olIwXn+GiXtv U1de0PRQDirRciTPE9PTgM6SPImngz6tb3nwuFPW+6E6RCInQx5djuy8QBiKsg0k8bb+ qixsO0rkC6rXddcdquXsny6ajGnV7CXNNh1B4= MIME-Version: 1.0 Received: by 10.210.78.7 with SMTP id a7mr1369208ebb.35.1248254592593; Wed, 22 Jul 2009 02:23:12 -0700 (PDT) In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0022A36A0@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3616@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F1A339E@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3667@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0907220040k53ba2cdcp190803631e79a90e@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A36A0@GBNTHT12009MSX.gb002.siemens.net> Date: Wed, 22 Jul 2009 11:23:12 +0200 Message-ID: <9ae56b1e0907220223u64f1fe48xb06e337fa6332662@mail.gmail.com> From: Hans Erik van Elburg To: "Elwell, John" Content-Type: multipart/alternative; boundary=000e0cd1e6a694b37b046f47eb80 Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 22 Jul 2009 09:24:01 -0000 --000e0cd1e6a694b37b046f47eb80 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Yes your right. This might be a nasty case, as it would result in the wrong aor being retrieved by the next UAS being redirected to. This could be resolved by not letting redirect servers tag aor's, but only let proxies responsible for the domain do that. /Hans Erik van Elburg On Wed, Jul 22, 2009 at 9:49 AM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > Hans Erik, > > When the subject came up we were talking about redirect servers, i.e., > anything that issues a 3xx response. This may or may not be a device > that acts as a UAS for some requests. > > So if I receive sip:john@123.123.123.123 and > redirect it elsewhere, was > that URI an AOR or not? According to the RFC 3261 definition that > Francois cited, I think it is, i.e., I look up the URI in my location > server, find a contact and redirect to it. > > John > > > -----Original Message----- > > From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] > > Sent: 22 July 2009 08:41 > > To: Elwell, John > > Cc: Francois Audet; Paul Kyzivat; SIPCORE; Hadriel Kaplan > > Subject: Re: [sipcore] rfc4244bis: what is an AoR? > > > > I'm confused to what is the question here, are we talking > > about a UAS or a proxy? > > > > /Hans Erik van Elburg > > > > > > > > On Wed, Jul 22, 2009 at 8:20 AM, Elwell, John > > wrote: > > > > > > Many deployments today use IP address instead of domain > > (e.g., for a > > SIP-PBX), so are we saying that any URIs with a SIP-PBX > > IP address, say, > > are not AORs? This seems to underline the point that > > the RFC 3261 > > definition of AOR seems to be open to different interpretations. > > > > John > > > > > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortel.com] > > > > > Sent: 21 July 2009 21:59 > > > To: Elwell, John; Hans Erik van Elburg; Paul Kyzivat > > > Cc: SIPCORE; Hadriel Kaplan > > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > > > > > > Re-reading this (again). > > > > > > I don't believe 10.10.15.12 fits the "domain" criteria in the > > > definition > > > of AOR. So it would not be an AOR. > > > > > > > > > > > > > -----Original Message----- > > > > From: Elwell, John > > [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Tuesday, July 21, 2009 13:08 > > > > To: Audet, Francois (SC100:3055); Hans Erik van > > Elburg; Paul Kyzivat > > > > Cc: SIPCORE; Hadriel Kaplan > > > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > From: Francois Audet [mailto:audet@nortel.com] > > > > > Sent: 21 July 2009 18:46 > > > > > To: Elwell, John; Hans Erik van Elburg; Paul Kyzivat > > > > > Cc: SIPCORE; Hadriel Kaplan > > > > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > > > > > > > > > > > > > > > > > In this case, you'll have an entry in the middle > > > > > > > (elwell@10.10.15.12) that is not > > > > > > > an AOR. > > > > > > [JRE] Thinking about this further, I believe > > this DOES fit the > > > > > > definition for AOR. In other words, my UAS is > > responsible for > > > > > > 10.10.15.12 and its "location service" tells it that the > > > > contact for > > > > > > elwell is john@192.168.15.12. > > > > > > > > > > Exactly. > > > > > > > > > > > > > Francois, > > > > > > > > I'm confused, because I thought you were arguing that it was > > > > not an AOR in this redirection case. I had originally > > > > postulated that in most cases all but the last H-I entry > > > > would be marked AOR, and you cited this as an example where > > > > it wouldn't be marked as an AOR. But now you agree it would > > > > be marked as an AOR, which seems to support my > > original hypothesis. > > > > > > > > John > > > > > > > > > > > > > > > > --000e0cd1e6a694b37b046f47eb80 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes your right.

This might be a nasty case, as it would = result in the wrong aor being retrieved by the next UAS being redirected to= .=A0

This could be resolved by not letting redirec= t servers tag aor's, but only let proxies responsible for the domain do= that.

/Hans Erik van Elburg


On Wed, Jul 22, 2009 at 9:49 AM, Elwell,= John <john.elwell@siemens-enterprise.com> wrote:
Hans Erik,

When the subject came up we were talking about redirect servers, i.e.,
anything that issues a 3xx response. This may or may not be a device
that acts as a UAS for some requests.

So if I receive sip:john@123.= 123.123.123 and redirect it elsewhere, was
that URI an AOR or not? According to the RFC 3261 definition that
Francois cited, I think it is, i.e., I look up the URI in my location
server, find a contact and redirect to it.

John

> -----Original Message-----
> From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
> Sent: 22 July 2009 08:41
> To: Elwell, John
> Cc: Francois Audet; Paul Kyzivat; SIPCORE; Hadriel Kaplan
> Subject: Re: [sipcore] rfc4244bis: what is an AoR?
>
> I'm confused to what is the question here, are we talking
> about a UAS or a proxy?
>
> /Hans Erik van Elburg
>
>
>
> On Wed, Jul 22, 2009 at 8:20 AM, Elwell, John
> <john.elwell@= siemens-enterprise.com> wrote:
>
>
> =A0 =A0 =A0 Many deployments today use IP address instead of domain > (e.g., for a
> =A0 =A0 =A0 SIP-PBX), so are we saying that any URIs with a SIP-PBX > IP address, say,
> =A0 =A0 =A0 are not AORs? This seems to underline the point that
> the RFC 3261
> =A0 =A0 =A0 definition of AOR seems to be open to different interpreta= tions.
>
> =A0 =A0 =A0 John
>
>
> =A0 =A0 =A0 > -----Original Message-----
> =A0 =A0 =A0 > From: Francois Audet [mailto:audet@nortel.com]
>
> =A0 =A0 =A0 > Sent: 21 July 2009 21:59
> =A0 =A0 =A0 > To: Elwell, John; Hans Erik van Elburg; Paul Kyzivat<= br> > =A0 =A0 =A0 > Cc: SIPCORE; Hadriel Kaplan
> =A0 =A0 =A0 > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > =A0 =A0 =A0 >
> =A0 =A0 =A0 > Re-reading this (again).
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > I don't believe 10.10.15.12 fits the "domain= " criteria in the
> =A0 =A0 =A0 > definition
> =A0 =A0 =A0 > of AOR. So it would not be an AOR.
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 >
> =A0 =A0 =A0 > > -----Original Message-----
> =A0 =A0 =A0 > > From: Elwell, John
> [mailto:john.elw= ell@siemens-enterprise.com]
> =A0 =A0 =A0 > > Sent: Tuesday, July 21, 2009 13:08
> =A0 =A0 =A0 > > To: Audet, Francois (SC100:3055); Hans Erik van<= br> > Elburg; Paul Kyzivat
> =A0 =A0 =A0 > > Cc: SIPCORE; Hadriel Kaplan
> =A0 =A0 =A0 > > Subject: RE: [sipcore] rfc4244bis: what is an Ao= R?
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > > -----Original Message-----
> =A0 =A0 =A0 > > > From: Francois Audet [mailto:audet@nortel.com]
> =A0 =A0 =A0 > > > Sent: 21 July 2009 18:46
> =A0 =A0 =A0 > > > To: Elwell, John; Hans Erik van Elburg; Pau= l Kyzivat
> =A0 =A0 =A0 > > > Cc: SIPCORE; Hadriel Kaplan
> =A0 =A0 =A0 > > > Subject: RE: [sipcore] rfc4244bis: what is = an AoR?
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > > > > In this case, you'll have an = entry in the middle
> =A0 =A0 =A0 > > > > > (elwell@10.10.15.12) that is not
> =A0 =A0 =A0 > > > > > an AOR.
> =A0 =A0 =A0 > > > > [JRE] Thinking about this further, I b= elieve
> this DOES fit the
> =A0 =A0 =A0 > > > > definition for AOR. In other words, my= UAS is
> responsible for
> =A0 =A0 =A0 > > > > 10.10.15.12 and its "location ser= vice" tells it that the
> =A0 =A0 =A0 > > contact for
> =A0 =A0 =A0 > > > > elwell is john@192.168.15.12.
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > > > Exactly.
> =A0 =A0 =A0 > > >
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > Francois,
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > I'm confused, because I thought you were arg= uing that it was
> =A0 =A0 =A0 > > not an AOR in this redirection case. I had origi= nally
> =A0 =A0 =A0 > > postulated that in most cases all but the last H= -I entry
> =A0 =A0 =A0 > > would be marked AOR, and you cited this as an ex= ample where
> =A0 =A0 =A0 > > it wouldn't be marked as an AOR. But now you= agree it would
> =A0 =A0 =A0 > > be marked as an AOR, which seems to support my > original hypothesis.
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 > > John
> =A0 =A0 =A0 > >
> =A0 =A0 =A0 >
>
>
>
>

--000e0cd1e6a694b37b046f47eb80-- From gonzalo.camarillo@ericsson.com Wed Jul 22 02:56:36 2009 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 2EB2728C1EE for ; Wed, 22 Jul 2009 02:56:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.2 X-Spam-Level: X-Spam-Status: No, score=-5.2 tagged_above=-999 required=5 tests=[AWL=1.049, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 O1LtRcF+q18p for ; Wed, 22 Jul 2009 02:56:34 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 623223A6BC8 for ; Wed, 22 Jul 2009 02:56:34 -0700 (PDT) X-AuditID: c1b4fb3c-b7ba4ae0000038c0-fe-4a66e2256303 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 0D.F4.14528.522E66A4; Wed, 22 Jul 2009 11:55:49 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 11:55:49 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 22 Jul 2009 11:55:48 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 848662461; Wed, 22 Jul 2009 12:55:48 +0300 (EEST) Message-ID: <4A66E224.2010900@ericsson.com> Date: Wed, 22 Jul 2009 12:55:48 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Paul Kyzivat References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com> In-Reply-To: <4A528AB2.7020206@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2009 09:55:48.0876 (UTC) FILETIME=[971654C0:01CA0AB2] X-Brightmail-Tracker: AAAAAA== Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 22 Jul 2009 09:56:36 -0000 Hi Paul, thanks for your comments. Answers inline: Paul Kyzivat wrote: > Gonzalo, > > Thanks for doing this work! I do have some comments: > > Section 3/Figure 1 > > The figure shows a 6xx response. > The text says that the UAS wants to reject the new offer. > > A UAS would probably not use a 6xx response to reject media. > (I guess it might use 606, but 488 would be more appropriate.) > In fact, it probably would not reject the request at all, but rather > would just refuse the added media stream. > > The point being made doesn't require that the response be 6xx or that it > be with the purpose of refusing the media. So I think what is needed > here is to find a plausible example to make the point. > > A good one for the purpose here might be a 488 to reject the media, or a > 401 response as another sort of reason for rejecting the whole thing > but wanting to preserve what there is. yes, I agree that a 488 response would be more appropriate. I will change that in the draft. > > Section 5: > >> A change to the session state is considered to have been executed >> when the new media parameters are being used. Therefore, a change to >> a stream subject to preconditions [RFC4032] is considered to have >> been executed when the new media parameters start being used; not >> when the preconditions for the stream are met. Unsurprisingly, the >> UAS considers the new parameters to be in use when it actually starts >> using them. > > I'm not entirely following this. I think there may be an assumption here > that the UAC is the offerer and the UAS the answerer. I'm guessing you > are saying that the answerer considers the new parameters to be in use > when it actually starts using them. > > Since this section is about the UAS (for the reinvite), this point is > probably that when the UAS is also the answerer it can decide when the > new media is in use based on when it starts using them. > > But what happens when the UAS is the offerer? In that case I think it > must assume the media is in use as soon as it is offered. But maybe that > isn't always the case with preconditions. I don't think it can wait till > it receives media, because media may be in flight when it makes its > decision. yes, the draft assumes that the UAS is the answerer because that was the use case being discussed originally. However, you are right that we should also cover the case where the UAS is the offerer. I will look into it and add text about it in the draft. > >> As described in Section 8.3.1 of RFC 3264 [RFC3264], the >> UAC considers the new parameters to be in use when media is received >> in the new port, which should be interpreted as follows: >> >> Received, in this case, means that the media is passed to a media >> sink. This means that if there is a playout buffer, the agent >> would continue to listen on the old port until the media on the >> new port reached the top of the playout buffer. At that time, it >> MAY cease listening for media on the old port. > > I don't know what the above has to do with the behavior of the UAS. The UAC needs to know when the new parameters are in use in order to implement the normative behavior in Section 6: ... a UAC that receives an error response to a re-INVITE for which changes have been already executed ... In any case, I will clarify all this when I write the text about the UAS being the offerer because this type of behavior has to do with being the offerer or the answerer, not the UAC or the UAS. >> 9. Clarifications on Target Refresh Requests the current text is a straw man that puts target refreshes in the same category as any other change. The other option we talked about in the past was to special case them so that they are treated differently. You seem to like the latter option better. What do you think about the following text?
The remote target of a dialog is a special type of state information because of its essential role in the exchange of SIP messages between UAs in a dialog. A UA involved in a dialog receives the remote target of the dialog from the remote UA. The UA uses the remote target to send SIP requests to the remote UA. The remote target is a piece of state information that is not meant to be negotiated. When a UAC changes its address, the UAC simply communicates its new address to the UAS in order to remain reachable by the UAS. As described in , a UAS starts using the new remote target as soon as the target refresh request is received, regardless of the response the UAS generates to that request. That is, even if the UAS generates an error response to the target refresh request, the UAS needs to update the dialog's remote target URI. The fact that a target refresh request updates the remote target regardless of the response it triggers implies that target refresh requests are not atomic. That is, an error response to a target refresh request will keep all changes associated to the request from being performed except for the refresh of the remote target, which will be performed anyway.
Cheers, Gonzalo From AUDET@nortel.com Wed Jul 22 07:31:23 2009 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 483533A6833 for ; Wed, 22 Jul 2009 07:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.093 X-Spam-Level: X-Spam-Status: No, score=-6.093 tagged_above=-999 required=5 tests=[AWL=0.506, 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 hE-C+tj51dXL for ; Wed, 22 Jul 2009 07:31:22 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 304A93A67DA for ; Wed, 22 Jul 2009 07:31:22 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6ME4wW28448; Wed, 22 Jul 2009 14:04:58 GMT 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, 22 Jul 2009 09:06:21 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F1A39AF@zrc2hxm0.corp.nortel.com> In-Reply-To: A<0D5F89FAC29E2C41B98A6A762007F5D0022A3667@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoF6CVRUPlMKkb7SrWHqBtgx6wCgwAAvgVQABgn/cAAH/S/oADX36qgAATaVgAAAdl4gAATblIAABAxhiA= References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com> <4A5E83CB.4090701@cisco.com> <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0022A3616@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F1A339E@zrc2hxm0.corp.nortel.com> A<0D5F89FAC29E2C41B98A6A762007F5D0022A3667@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Elwell, John" , "Hans Erik van Elburg" , "Paul Kyzivat" Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 22 Jul 2009 14:31:23 -0000 No, it points to the fact that people don't follow RFC 3261 properly. Perhaps the best thing to do is saying that "Some domains use IP address(es) as domain names; in this case URIs with domain names can be marked with the "aor" tag. Domains that use proper DNS domain names instead of IP addresses would not mark=20 URIs with IP addresses as domains with the "aor" tag." PS: There is another alternative. We could stick to the rule of using proper domain names for AORs. But then, UAs would have to use them in Request-URIs, To and From, and if they want to avoid DNS, then they'd have to use Route header (or maddr). That is cleaner, but it a bigger change for existing deployments. > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Tuesday, July 21, 2009 23:20 > To: Audet, Francois (SC100:3055); Hans Erik van Elburg; Paul Kyzivat > Cc: SIPCORE; Hadriel Kaplan > Subject: RE: [sipcore] rfc4244bis: what is an AoR? >=20 > Many deployments today use IP address instead of domain=20 > (e.g., for a SIP-PBX), so are we saying that any URIs with a=20 > SIP-PBX IP address, say, are not AORs? This seems to=20 > underline the point that the RFC 3261 definition of AOR seems=20 > to be open to different interpretations. >=20 > John=20 >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: 21 July 2009 21:59 > > To: Elwell, John; Hans Erik van Elburg; Paul Kyzivat > > Cc: SIPCORE; Hadriel Kaplan > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > >=20 > > Re-reading this (again).=20 > >=20 > > I don't believe 10.10.15.12 fits the "domain" criteria in the=20 > > definition of AOR. So it would not be an AOR. > >=20 > > =20 > >=20 > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Tuesday, July 21, 2009 13:08 > > > To: Audet, Francois (SC100:3055); Hans Erik van Elburg;=20 > Paul Kyzivat > > > Cc: SIPCORE; Hadriel Kaplan > > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Francois Audet [mailto:audet@nortel.com] > > > > Sent: 21 July 2009 18:46 > > > > To: Elwell, John; Hans Erik van Elburg; Paul Kyzivat > > > > Cc: SIPCORE; Hadriel Kaplan > > > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > > > >=20 > > > >=20 > > > > > > In this case, you'll have an entry in the middle > > > > > > (elwell@10.10.15.12) that is not an AOR. > > > > > [JRE] Thinking about this further, I believe this=20 > DOES fit the=20 > > > > > definition for AOR. In other words, my UAS is responsible for > > > > > 10.10.15.12 and its "location service" tells it that the > > > contact for > > > > > elwell is john@192.168.15.12. > > > >=20 > > > > Exactly. > > > >=20 > > >=20 > > > Francois, > > >=20 > > > I'm confused, because I thought you were arguing that it=20 > was not an=20 > > > AOR in this redirection case. I had originally postulated that in=20 > > > most cases all but the last H-I entry would be marked=20 > AOR, and you=20 > > > cited this as an example where it wouldn't be marked as=20 > an AOR. But=20 > > > now you agree it would be marked as an AOR, which seems=20 > to support=20 > > > my original hypothesis. > > >=20 > > > John > > >=20 > >=20 >=20 From john.elwell@siemens-enterprise.com Wed Jul 22 07:46:21 2009 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 5D3E83A68AE for ; Wed, 22 Jul 2009 07:46:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.567 X-Spam-Level: X-Spam-Status: No, score=-2.567 tagged_above=-999 required=5 tests=[AWL=0.032, 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 KJYyJBg2xp2U for ; Wed, 22 Jul 2009 07:46:20 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id B8BD13A6403 for ; Wed, 22 Jul 2009 07:46:19 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KN600G22U79L4@siemenscomms.co.uk> for sipcore@ietf.org; Wed, 22 Jul 2009 15:42:45 +0100 (BST) Date: Wed, 22 Jul 2009 15:42:31 +0100 From: "Elwell, John" In-reply-to: <1ECE0EB50388174790F9694F77522CCF1F1A39AF@zrc2hxm0.corp.nortel.com> To: Francois Audet , Hans Erik van Elburg , Paul Kyzivat Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0022A39CE@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] rfc4244bis: what is an AoR? Thread-Index: AcoF6CVRUPlMKkb7SrWHqBtgx6wCgwAAvgVQABgn/cAAH/S/oADX36qgAATaVgAAAdl4gAATblIAABAxhiAAAXHJ8A== Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com> <4A5E83CB.4090701@cisco.com> <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0022A3616@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F1A339E@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0022A3667@GBNTHT12009MSX.gb002.siemens.net> <"1ECE0EB50388174790F969 4F77522CCF1F1A39AF"@zrc2hxm0.corp.nortel.com> Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 22 Jul 2009 14:46:21 -0000 Francois, I think you are saying that we must make a distinction between domain names and host names, and likewise between IP addresses associated with domain names and IP addresses associated with host names. So a request aimed at sip:john@example.com, when redirected or forwarded, would be marked as an AOR if example.com is a domain name but not if example.com is a host name. Similarly for sip:john@123.123.123.123, depending on whether it represents a domain name or a host name. Do I understand you correctly? John > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: 22 July 2009 15:06 > To: Elwell, John; Hans Erik van Elburg; Paul Kyzivat > Cc: SIPCORE; Hadriel Kaplan > Subject: RE: [sipcore] rfc4244bis: what is an AoR? >=20 > No, it points to the fact that people don't follow RFC 3261 properly. >=20 > Perhaps the best thing to do is saying that "Some domains use > IP address(es) as domain names; in this case URIs with domain > names can be marked with the "aor" tag. Domains that use proper > DNS domain names instead of IP addresses would not mark=20 > URIs with IP addresses as domains with the "aor" tag." >=20 > PS: There is another alternative. We could stick to the rule > of using proper domain names for AORs. But then, UAs would have > to use them in Request-URIs, To and From, and if they want to avoid > DNS, then they'd have to use Route header (or maddr). That is cleaner, > but it a bigger change for existing deployments. >=20 > > -----Original Message----- > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > > Sent: Tuesday, July 21, 2009 23:20 > > To: Audet, Francois (SC100:3055); Hans Erik van Elburg; Paul Kyzivat > > Cc: SIPCORE; Hadriel Kaplan > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > >=20 > > Many deployments today use IP address instead of domain=20 > > (e.g., for a SIP-PBX), so are we saying that any URIs with a=20 > > SIP-PBX IP address, say, are not AORs? This seems to=20 > > underline the point that the RFC 3261 definition of AOR seems=20 > > to be open to different interpretations. > >=20 > > John=20 > >=20 > > > -----Original Message----- > > > From: Francois Audet [mailto:audet@nortel.com] > > > Sent: 21 July 2009 21:59 > > > To: Elwell, John; Hans Erik van Elburg; Paul Kyzivat > > > Cc: SIPCORE; Hadriel Kaplan > > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > > >=20 > > > Re-reading this (again).=20 > > >=20 > > > I don't believe 10.10.15.12 fits the "domain" criteria in the=20 > > > definition of AOR. So it would not be an AOR. > > >=20 > > > =20 > > >=20 > > > > -----Original Message----- > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > Sent: Tuesday, July 21, 2009 13:08 > > > > To: Audet, Francois (SC100:3055); Hans Erik van Elburg;=20 > > Paul Kyzivat > > > > Cc: SIPCORE; Hadriel Kaplan > > > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > > > >=20 > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Francois Audet [mailto:audet@nortel.com] > > > > > Sent: 21 July 2009 18:46 > > > > > To: Elwell, John; Hans Erik van Elburg; Paul Kyzivat > > > > > Cc: SIPCORE; Hadriel Kaplan > > > > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > > > > >=20 > > > > >=20 > > > > > > > In this case, you'll have an entry in the middle > > > > > > > (elwell@10.10.15.12) that is not an AOR. > > > > > > [JRE] Thinking about this further, I believe this=20 > > DOES fit the=20 > > > > > > definition for AOR. In other words, my UAS is=20 > responsible for > > > > > > 10.10.15.12 and its "location service" tells it that the > > > > contact for > > > > > > elwell is john@192.168.15.12. > > > > >=20 > > > > > Exactly. > > > > >=20 > > > >=20 > > > > Francois, > > > >=20 > > > > I'm confused, because I thought you were arguing that it=20 > > was not an=20 > > > > AOR in this redirection case. I had originally=20 > postulated that in=20 > > > > most cases all but the last H-I entry would be marked=20 > > AOR, and you=20 > > > > cited this as an example where it wouldn't be marked as=20 > > an AOR. But=20 > > > > now you agree it would be marked as an AOR, which seems=20 > > to support=20 > > > > my original hypothesis. > > > >=20 > > > > John > > > >=20 > > >=20 > >=20 >=20 From AUDET@nortel.com Wed Jul 22 08:40:44 2009 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 198613A6820 for ; Wed, 22 Jul 2009 08:40:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.185 X-Spam-Level: X-Spam-Status: No, score=-6.185 tagged_above=-999 required=5 tests=[AWL=0.414, 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 YaU+gC9lencD for ; Wed, 22 Jul 2009 08:40:42 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id E0DBB3A68AE for ; Wed, 22 Jul 2009 08:40:41 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6MFGrr17416; Wed, 22 Jul 2009 15:16:53 GMT 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, 22 Jul 2009 10:18:35 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F1A3B90@zrc2hxm0.corp.nortel.com> In-Reply-To: A<0D5F89FAC29E2C41B98A6A762007F5D0022A39CE@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoF6CVRUPlMKkb7SrWHqBtgx6wCgwAAvgVQABgn/cAAH/S/oADX36qgAATaVgAAAdl4gAATblIAABAxhiAAAXHJ8AABVyIA References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com> <4A5E83CB.4090701@cisco.com> <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0022A3616@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F1A339E@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0022A3667@GBNTHT12009MSX.gb002.siemens.net> <"1ECE0EB5038! 8174790F9 69 4F77522CC F1F1A39AF"@zrc2hxm0.corp.nortel.com> A<0D5F89FAC29E2C41B98A6A762007F5D0022A39CE@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Elwell, John" , "Hans Erik van Elburg" , "Paul Kyzivat" Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 22 Jul 2009 15:40:44 -0000 Yes, and also, as per Hans' previous mail, the domain in question that marks the entry as aor MUST be the one who owns the IP address. You are correct. Makes sense?=20 > -----Original Message----- > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com]=20 > Sent: Wednesday, July 22, 2009 07:43 > To: Audet, Francois (SC100:3055); Hans Erik van Elburg; Paul Kyzivat > Cc: SIPCORE; Hadriel Kaplan > Subject: RE: [sipcore] rfc4244bis: what is an AoR? >=20 > Francois, >=20 > I think you are saying that we must make a distinction=20 > between domain names and host names, and likewise between IP=20 > addresses associated with domain names and IP addresses=20 > associated with host names. So a request aimed at=20 > sip:john@example.com, when redirected or forwarded, would be=20 > marked as an AOR if example.com is a domain name but not if=20 > example.com is a host name. Similarly for=20 > sip:john@123.123.123.123, depending on whether it represents=20 > a domain name or a host name. Do I understand you correctly? >=20 > John >=20 > > -----Original Message----- > > From: Francois Audet [mailto:audet@nortel.com] > > Sent: 22 July 2009 15:06 > > To: Elwell, John; Hans Erik van Elburg; Paul Kyzivat > > Cc: SIPCORE; Hadriel Kaplan > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > >=20 > > No, it points to the fact that people don't follow RFC 3261=20 > properly. > >=20 > > Perhaps the best thing to do is saying that "Some domains use IP=20 > > address(es) as domain names; in this case URIs with domain=20 > names can=20 > > be marked with the "aor" tag. Domains that use proper DNS=20 > domain names=20 > > instead of IP addresses would not mark URIs with IP addresses as=20 > > domains with the "aor" tag." > >=20 > > PS: There is another alternative. We could stick to the=20 > rule of using=20 > > proper domain names for AORs. But then, UAs would have to=20 > use them in=20 > > Request-URIs, To and From, and if they want to avoid DNS,=20 > then they'd=20 > > have to use Route header (or maddr). That is cleaner, but=20 > it a bigger=20 > > change for existing deployments. > >=20 > > > -----Original Message----- > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > Sent: Tuesday, July 21, 2009 23:20 > > > To: Audet, Francois (SC100:3055); Hans Erik van Elburg;=20 > Paul Kyzivat > > > Cc: SIPCORE; Hadriel Kaplan > > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > > >=20 > > > Many deployments today use IP address instead of domain=20 > (e.g., for a=20 > > > SIP-PBX), so are we saying that any URIs with a SIP-PBX=20 > IP address,=20 > > > say, are not AORs? This seems to underline the point that the RFC=20 > > > 3261 definition of AOR seems to be open to different=20 > > > interpretations. > > >=20 > > > John > > >=20 > > > > -----Original Message----- > > > > From: Francois Audet [mailto:audet@nortel.com] > > > > Sent: 21 July 2009 21:59 > > > > To: Elwell, John; Hans Erik van Elburg; Paul Kyzivat > > > > Cc: SIPCORE; Hadriel Kaplan > > > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > > > >=20 > > > > Re-reading this (again).=20 > > > >=20 > > > > I don't believe 10.10.15.12 fits the "domain" criteria in the=20 > > > > definition of AOR. So it would not be an AOR. > > > >=20 > > > > =20 > > > >=20 > > > > > -----Original Message----- > > > > > From: Elwell, John [mailto:john.elwell@siemens-enterprise.com] > > > > > Sent: Tuesday, July 21, 2009 13:08 > > > > > To: Audet, Francois (SC100:3055); Hans Erik van Elburg; > > > Paul Kyzivat > > > > > Cc: SIPCORE; Hadriel Kaplan > > > > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > > > > >=20 > > > > > =20 > > > > >=20 > > > > > > -----Original Message----- > > > > > > From: Francois Audet [mailto:audet@nortel.com] > > > > > > Sent: 21 July 2009 18:46 > > > > > > To: Elwell, John; Hans Erik van Elburg; Paul Kyzivat > > > > > > Cc: SIPCORE; Hadriel Kaplan > > > > > > Subject: RE: [sipcore] rfc4244bis: what is an AoR? > > > > > >=20 > > > > > >=20 > > > > > > > > In this case, you'll have an entry in the middle > > > > > > > > (elwell@10.10.15.12) that is not an AOR. > > > > > > > [JRE] Thinking about this further, I believe this > > > DOES fit the > > > > > > > definition for AOR. In other words, my UAS is > > responsible for > > > > > > > 10.10.15.12 and its "location service" tells it that the > > > > > contact for > > > > > > > elwell is john@192.168.15.12. > > > > > >=20 > > > > > > Exactly. > > > > > >=20 > > > > >=20 > > > > > Francois, > > > > >=20 > > > > > I'm confused, because I thought you were arguing that it > > > was not an > > > > > AOR in this redirection case. I had originally > > postulated that in > > > > > most cases all but the last H-I entry would be marked > > > AOR, and you > > > > > cited this as an example where it wouldn't be marked as > > > an AOR. But > > > > > now you agree it would be marked as an AOR, which seems > > > to support > > > > > my original hypothesis. > > > > >=20 > > > > > John > > > > >=20 > > > >=20 > > >=20 > >=20 >=20 From AUDET@nortel.com Wed Jul 22 09:05:10 2009 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 D27AE3A68F6 for ; Wed, 22 Jul 2009 09:05:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.219 X-Spam-Level: X-Spam-Status: No, score=-6.219 tagged_above=-999 required=5 tests=[AWL=0.379, 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 zeYW4DGFasz3 for ; Wed, 22 Jul 2009 09:05:09 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id AF87C3A68ED for ; Wed, 22 Jul 2009 09:05:08 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6MFD4r16396; Wed, 22 Jul 2009 15:13:04 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0ADF.221C29CC" Date: Wed, 22 Jul 2009 10:14:38 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F1A3B6E@zrc2hxm0.corp.nortel.com> In-Reply-To: <9ae56b1e0907220035l7ae50042x2f71dabcae331e9@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] rfc4244bis: what is an AoR? thread-index: AcoKnv0A6ufncdk+TamcPHq7lE+n6QANse3w References: <4A5FAF4E.4030901@cisco.com> <9ae56b1e0907171313u6b7e09c3hd0eee3399a4ae681@mail.gmail.com> <9ae56b1e0907172354q353f23ffla9fd0c6a0f55d2cd@mail.gmail.com> <1ECE0EB50388174790F9694F77522CCF1F155B2A@zrc2hxm0.corp.nortel.com> <9ae56b1e0907220035l7ae50042x2f71dabcae331e9@mail.gmail.com> From: "Francois Audet" To: "Hans Erik van Elburg" Cc: SIPCORE , Hadriel Kaplan Subject: Re: [sipcore] rfc4244bis: what is an AoR? 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, 22 Jul 2009 16:05:10 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0ADF.221C29CC Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable Why would you use the first??? =20 It seems to me the last is more likely to be useful. E.g., I call = sip:conferencing@example.com. I get redirected to = sip:conferencing@example.com;confnumber=3D87365352. =20 The useful target URI is the last one, not the first one. =20 Anyways, I guess it points to the fact of WHY we NEED H-I for target URI = if there are use cases for first and use cases for last entry, for = example... =20 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Wednesday, July 22, 2009 00:35 To: Audet, Francois (SC100:3055) Cc: Hadriel Kaplan; Paul Kyzivat; SIPCORE Subject: Re: [sipcore] rfc4244bis: what is an AoR? =09 =09 Assuming that you are talking about "- if no "mp" found take the first = H-I entry"=20 Then I really ment the first from teh begionning, as in this case no = mapping occured the first entry must be the best guess for the addressed = target. /Hans Erik van Elburg =09 =09 =09 On Tue, Jul 21, 2009 at 7:54 PM, Francois Audet = wrote: =09 By "first H-I entry", you mean the "first from the end", i.e., "the = last", right? ________________________________ =09 From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 =09 Sent: Friday, July 17, 2009 23:55 To: Hadriel Kaplan Cc: Audet, Francois (SC100:3055); Paul Kyzivat; SIPCORE=20 Subject: Re: [sipcore] rfc4244bis: what is an AoR? =09 Yes the relevant flags are dependent on what you in your role of UAS = would like to retrieve. The rules would be very simple.=20 To retrieve the addressed target (freephone, etc):=20 - traverse all H-I entries backward until an "mp" entry is found, if = found this is the addressed target - if no "mp" found take the first H-I entry - if no History-Info header take the Request-URI value To retrieve the last aor before it was overwritten by contact address = (similar as P-Called-Party-ID):=20 - traverse all H-I entries backward until an "aor" entry is found, if = found this is the last AOR used /Hans Erik van Elburg =09 =09 On Fri, Jul 17, 2009 at 11:43 PM, Hadriel Kaplan = wrote: =09 I=92m confused (I know, not a hard thing to make me be apparently = :-(). In a previous chain of emails I thought the purpose of the =93mp=94 = flag was to indicate a retarget happened, but that the subsequent = =93aor=94 flagged URI was what would actually be used for applications, = because it is the =93cleaned-up=94 form of the URI being retargeted to, = since it actually identifies what the authoritative domain which got it = claims it location-service routed with. =20 Your response indicates that the =93mp=94 flagged URI would actually = be used by the application, even when it does not have an =93aor=94 flag = (as it would not in this case). =20 Which is it? Or are the cases different for different application = uses, for which flags are important? =20 -hadriel =20 =09 ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Friday, July 17, 2009 4:13 PM To: Hadriel Kaplan Cc: Francois Audet; Paul Kyzivat; SIPCORE =09 Subject: Re: [sipcore] rfc4244bis: what is an AoR? =09 =20 inline... /Hans Erik van Elburg =09 =09 On Fri, Jul 17, 2009 at 4:52 PM, Hadriel Kaplan = wrote: =09 =09 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: Thursday, July 16, 2009 8:37 PM > > >> Say I call sip:+1234567890@sp.com = ;user=3Dphone. My proxy is "sp.com", > >> right? > >> > >> Then sp.net does ENUM query. Did you intend for this to be "sp.net" and thus a different domain = from "sp.com"? Or was that a typo? I am assuming it was a typo. =09 =09 > > If we assume that ENUM qualifies as a location service (and I am = now > > convinced that it does), then this URI *is* an AOR in sp.com. > > No, because it's not the right domain. It's doing the ENUM on a = phone > number. So it really has nothing to do with a SIP scheme (a = condition > for AOR, remember?). Regardless of whether ENUM is doing it on a phone number sans domain = or not, it MUST be marked as an "aor". Think of it this way: Suppose you call "sip:+18005551212@sp.com = ", and sp.com does an ENUM lookup = on 18005551212, and the NAPTR result translated it to the non-800 = specific number for it. The freephone-model/redirection-usage NEEDs to = see that 18005551212. No? =20 No. The aor tag has nothing todo with the freephone case, for that = case the "mp" tag or in its absence the first H-I entry is important to = be able to determine the original called target. =20 =20 =09 =09 That's also why I think you'd want Tel-URI's - because sp.com could = have received a Tel-URI with it and done that ENUM lookup. =09 > And in fact, it goes to example.com, not sp.com So? As far as the sp.com Proxy cares, it has done an ENUM lookup = and gotten a result which changes the req-uri and makes it route the = call. As far as it knows, "sip:+1234567890@example.com = " is a contact address of a = PSTN-Gateway or registered UA, in which case per the rules = "sip:+1234567890@sp.com " WAS an = AoR; whereas if "sip:+1234567890@example.com = " is another peer domain then = it's not an AoR?? =20 The question is if it matters in this case. =20 =09 -hadriel =20 ------_=_NextPart_001_01CA0ADF.221C29CC Content-Type: text/html; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable
Why=20 would you use the first???
 
It=20 seems to me the last is more likely to be useful. E.g., I call=20 sip:conferencing@example.com. I get redirected to=20 sip:conferencing@example.com;confnumber=3D87365352.
 
The=20 useful target URI is the last one, not the first = one.
 
Anyways, I guess it points to the fact of WHY we NEED H-I for = target URI=20 if there are use cases for first and use cases for last entry, for=20 example...
 

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: Wednesday, July 22, = 2009=20 00:35
To: Audet, Francois (SC100:3055)
Cc: Hadriel = Kaplan;=20 Paul Kyzivat; SIPCORE
Subject: Re: [sipcore] rfc4244bis: = what is an=20 AoR?

Assuming that you are talking about "- if no "mp" = found take=20 the first H-I entry"

Then I really ment the first from teh begionning, as in this case = no=20 mapping occured the first entry must be the best guess for the = addressed=20 target.

/Hans Erik van Elburg


On Tue, Jul 21, 2009 at 7:54 PM, Francois = Audet <audet@nortel.com>=20 wrote:
By "first H-I = entry", you=20 mean the "first from the end", i.e., "the last",=20 right?

From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com] =
Sent: Friday,=20 July 17, 2009 23:55
To: Hadriel Kaplan
Cc: = Audet,=20 Francois (SC100:3055); Paul Kyzivat; SIPCORE

Subject: Re: [sipcore] rfc4244bis: what = is an=20 AoR?

Yes the relevant flags are dependent on what you in your role = of UAS=20 would like  to retrieve.

The rules would be very simple.=20

To retrieve the addressed target (freephone, = etc): 
- traverse all H-I entries backward until an "mp" entry is = found, if=20 found this is the addressed target
- if no "mp" found take the first H-I entry
- if no History-Info header take the Request-URI value

To retrieve the last aor before it was overwritten by contact = address (similar as P-Called-Party-ID): 
- traverse all H-I entries backward until an "aor" entry is = found, if=20 found this is the last AOR used

/Hans Erik van Elburg

On Fri, Jul 17, 2009 at 11:43 PM, Hadriel = Kaplan=20 <HKaplan@acmepacket.com> wrote:

I=92m = confused (I=20 know, not a hard thing to make me be apparently = L).

In a = previous=20 chain of emails I thought the purpose of the =93mp=94 flag was = to indicate a=20 retarget happened, but that the subsequent =93aor=94 flagged URI = was what=20 would actually be used for applications, because it is the = =93cleaned-up=94=20 form of the URI being retargeted to, since it actually = identifies what=20 the authoritative domain which got it claims it location-service = routed=20 with.

 

Your = response=20 indicates that the =93mp=94 flagged URI would actually be used = by the=20 application, even when it does not have an =93aor=94 flag (as it = would not=20 in this case).

 

Which = is=20 it?  Or are the cases different for different application = uses, for=20 which flags are important?

 

-hadriel

 

From:=20 Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]
Sent: Friday, July 17, = 2009 4:13=20 PM
To: = Hadriel=20 Kaplan
Cc: = Francois=20 Audet; Paul Kyzivat; SIPCORE


Subject: Re:=20 [sipcore] rfc4244bis: what is an AoR?

 

inline...
/Hans Erik = van=20 Elburg

On=20 Fri, Jul 17, 2009 at 4:52 PM, Hadriel Kaplan <HKaplan@acmepacket.com> = wrote:



> -----Original = Message-----
>=20 From: Francois Audet [mailto:audet@nortel.com]

> Sent: Thursday, July 16, 2009 = 8:37=20 PM
>
> >> Say I call sip:+1234567890@sp.com;user=3Dphone. My = proxy is "sp.com",
> = >>=20 right?
> >>
> >> Then sp.net does ENUM = query.

Did you intend for this to be "sp.net" and thus a = different=20 domain from "sp.com"?  Or=20 was that a typo?  I am assuming it was a = typo.


> >=20 If we assume that ENUM qualifies as a location service (and I am = now
> > convinced that it does), then this URI *is* an = AOR in=20 sp.com.
>
> No,=20 because it's not the right domain. It's doing the ENUM on a=20 phone
> number. So it really has nothing to do with a SIP = scheme=20 (a condition
> for AOR, = remember?).

Regardless of whether ENUM is doing it = on a=20 phone number sans domain or not, it MUST be marked as an "aor".=20  Think of it this way:
Suppose you call "sip:+18005551212@sp.com", and sp.com does an ENUM lookup on 18005551212, = and the=20 NAPTR result translated it to the non-800 specific number for = it.=20  The freephone-model/redirection-usage NEEDs to see that=20 18005551212. No?

 

No.=20 The aor tag has nothing todo with the freephone case, for that = case the=20 "mp" tag or in its absence  the first H-I entry is = important to be=20 able to determine the original called = target.

 

 



That's also why I think = you'd want=20 Tel-URI's - because sp.com=20 could have received a Tel-URI with it and done that ENUM=20 lookup.


> And in fact, = it goes to=20 example.com, not sp.com

So?  As far as the sp.com Proxy cares, = it has done=20 an ENUM lookup and gotten a result which changes the req-uri = and makes=20 it route the call.  As far as it knows, "sip:+1234567890@example.com" is a contact = address of=20 a PSTN-Gateway or registered UA, in which case per the rules = "sip:+1234567890@sp.com" WAS an AoR; = whereas if "sip:+1234567890@example.com" is another = peer domain=20 then it's not an AoR??

 

The=20 question is if it matters in this case.

 


-hadriel

 

=

------_=_NextPart_001_01CA0ADF.221C29CC-- From AUDET@nortel.com Wed Jul 22 22:02:16 2009 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 A6FF43A6AAF for ; Wed, 22 Jul 2009 22:02:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.274 X-Spam-Level: X-Spam-Status: No, score=-6.274 tagged_above=-999 required=5 tests=[AWL=0.325, 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 47WB0TIk0UTy for ; Wed, 22 Jul 2009 22:02:14 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id BAA823A68CE for ; Wed, 22 Jul 2009 22:02:13 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6N4tZO00169 for ; Thu, 23 Jul 2009 04:55:35 GMT 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, 22 Jul 2009 23:57:15 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F201CE4@zrc2hxm0.corp.nortel.com> In-Reply-To: A<0D5F89FAC29E2C41B98A6A762007F5D0022A39CE@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: draft-barnes-sipcore-rfc4244bis & target-URI: Summary of where we are thread-index: AcoF6CVRUPlMKkb7SrWHqBtgx6wCgwAAvgVQABgn/cAAH/S/oADX36qgAATaVgAAAdl4gAATblIAABAxhiAAAXHJ8AAcxRAQ References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com> <4A5E83CB.4090701@cisco.com> <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0022A3616@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F1A339E@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0022A3667@GBNTHT12009MSX.gb002.siemens.net> <"1ECE0EB5038! 8174790F9 69 4F77522CC F1F1A39AF"@zrc2hxm0.corp.nortel.com> A<0D5F89FAC29E2C41B98A6A762007F5D0022A39CE@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "SIPCORE" Subject: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summary of where we are 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, 23 Jul 2009 05:02:16 -0000 Hi all, In preparation for the meeting next week, I'm writting a Summary of = where we are with draft-barnes-sipcore-rfc4244bis and target-URI with regards to=20 mailing list discussions. target-URI draft: The authors have stopped updating the target-URI to focus their=20 energies on the 4244bis draft instead. The idea is that once we solve the issues remaining with 4244bis, targetURI will be realigned with 4244bis. This means that the nature of targetURI draft may change: it could become a "use case" illustating use cases and call flows for various target URI scenarios. So participants are invited to NOT to read the target-URI draft. aor tag:=20 It seems that after much discussion on mailing list, after much initial confusion, people came around and agree that the definition from the = draft does make sense, and does represent an AOR, as per the meaning in RFC 3261. Specifically, a URI entry is marked as "aor" when a proxy responsible = for the URI recognizes it as an AOR (i.e., it uses it for a location server = dip). One question asked on the list is how to treat IP addresses as domains? Can entries using IP addresses be AORs? The answer to that question is that when a domain uses an IP address as a domain name instead of a proper DNS domain name, yes, it can be considered an AOR. This will need to be clarified in an upcoming = version. We might want to confirm this in Stockholm. There appears to be no = other open issues regarding the aor tag. =20 rc / cc / rt tags:=20 These where created to be "precise" in their definition (i.e., = mechanical),=20 but it appears that they all represent "fluff". In other words, they = are not=20 normally used by algorithms. One idea being considered is "grouping" = them=20 together under a single "fluff" tag (proper name to be determined).=20 No strong opinion against the grouping idea.=20 Another approach suggested was to not mark them at all (i.e., no tag). The concern about this approach is that in the current model, all rfc4244bis proxies/redirect servers will mark ALL entries, while RFC 4244 (old) will not, thereby allowing for distinguishing the = entries, and allowing backward compatibility. We would therefore need to define another mechanism in parallel for each entry (e.g., another tag?) for=20 backward compatibility. Yet another approach (suggested last meeting), was to not include the "fluff" items at all. Again, this suffers from backward compatibility issues. There wasn't much discussion of this particular approach on=20 the list. A resolution for this particular issue, i.e., "rc/cc/rt" vs "fluff" vs "no tag" vs "no entry" is required. Seems like a good topic for = Stockholm. mp tag:=20 In the current draft, the "mp" tag represent the "mapped-TO" address,=20 not the mapped-FROM address. Unlike the "fluff" parameters, it means a=20 "user different from the previous one".=20 target-URI algorithm for UAS: There were some questions on the list about algorithms for picking the "target URI parameter: is it the last "mp"-marked tag or is it the last "aor" tag. It seems that the answer to this question may be different based on what the assumptions people have about what is in fact a "target URI". It is not clear if we need to describe this in the draft, or even indeed if it actually makes a difference. privacy:=20 RFC 3323 was written with a 2-party model. Some of the wording in=20 the documents was changed from 4244 to adapt to individual=20 H-I entries. It is not clear if further enhancements to RFC 3323 are required. We are inviting people to look at it. I believe this is it. Thanks. From john.elwell@siemens-enterprise.com Thu Jul 23 00:34:00 2009 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 B845C3A67B6 for ; Thu, 23 Jul 2009 00:34:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.574 X-Spam-Level: X-Spam-Status: No, score=-2.574 tagged_above=-999 required=5 tests=[AWL=0.025, 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 1AEWsv-vPapX for ; Thu, 23 Jul 2009 00:33:59 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id 6FF0A3A68AC for ; Thu, 23 Jul 2009 00:33:59 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KN80061Y4A9N1@siemenscomms.co.uk> for sipcore@ietf.org; Thu, 23 Jul 2009 08:18:09 +0100 (BST) Date: Thu, 23 Jul 2009 08:18:08 +0100 From: "Elwell, John" In-reply-to: <1ECE0EB50388174790F9694F77522CCF1F201CE4@zrc2hxm0.corp.nortel.com> To: Francois Audet , SIPCORE Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0022E981E@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summary ofwhere we are Thread-Index: AcoF6CVRUPlMKkb7SrWHqBtgx6wCgwAAvgVQABgn/cAAH/S/oADX36qgAATaVgAAAdl4gAATblIAABAxhiAAAXHJ8AAcxRAQAAXUPBA= Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com> <4A5E83CB.4090701@cisco.com> <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0022A3616@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F1A339E@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0022A3667@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC29E2C41B98A6A762007F5D0022A39CE@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F201CE4@zrc2hxm0.corp.nortel.com> Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summary ofwhere we are 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, 23 Jul 2009 07:34:00 -0000 =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Francois Audet > Sent: 23 July 2009 05:57 > To: SIPCORE > Subject: [sipcore] draft-barnes-sipcore-rfc4244bis &=20 > target-URI: Summary ofwhere we are >=20 > Hi all, >=20 > In preparation for the meeting next week, I'm writting a=20 > Summary of where we > are with draft-barnes-sipcore-rfc4244bis and target-URI with=20 > regards to=20 > mailing list discussions. >=20 > target-URI draft: >=20 > The authors have stopped updating the target-URI to focus their=20 > energies on the 4244bis draft instead. >=20 > The idea is that once we solve the issues remaining=20 > with 4244bis, > targetURI will be realigned with 4244bis. This means that the > nature of targetURI draft may change: it could become a "use > case" illustating use cases and call flows for various target > URI scenarios. >=20 > So participants are invited to NOT to read the target-URI draft. >=20 >=20 > aor tag:=20 >=20 > It seems that after much discussion on mailing list,=20 > after much initial > confusion, people came around and agree that the=20 > definition from the draft does > make sense, and does represent an AOR, as per the=20 > meaning in RFC 3261. >=20 > Specifically, a URI entry is marked as "aor" when a=20 > proxy responsible for > the URI recognizes it as an AOR (i.e., it uses it for a=20 > location server dip). [JRE] It might also be worth mentioning that there was discussion about redirects. My understanding was that a redirecting entity could also mark a URI as an AOR. >=20 > One question asked on the list is how to treat IP=20 > addresses as domains? > Can entries using IP addresses be AORs? >=20 > The answer to that question is that when a domain uses=20 > an IP address > as a domain name instead of a proper DNS domain name,=20 > yes, it can > be considered an AOR. This will need to be clarified in=20 > an upcoming version. >=20 > We might want to confirm this in Stockholm. There=20 > appears to be no other > open issues regarding the aor tag. >=20 > =20 > rc / cc / rt tags:=20 >=20 > These where created to be "precise" in their definition=20 > (i.e., mechanical),=20 > but it appears that they all represent "fluff". In=20 > other words, they are not=20 > normally used by algorithms. One idea being considered=20 > is "grouping" them=20 > together under a single "fluff" tag (proper name to be=20 > determined).=20 > No strong opinion against the grouping idea.=20 >=20 > Another approach suggested was to not mark them at all=20 > (i.e., no tag). > The concern about this approach is that in the current=20 > model, all > rfc4244bis proxies/redirect servers will mark ALL entries, while > RFC 4244 (old) will not, thereby allowing for=20 > distinguishing the entries, > and allowing backward compatibility. We would therefore=20 > need to define > another mechanism in parallel for each entry (e.g.,=20 > another tag?) for=20 > backward compatibility. >=20 > Yet another approach (suggested last meeting), was to=20 > not include the > "fluff" items at all. Again, this suffers from backward=20 > compatibility > issues. There wasn't much discussion of this particular=20 > approach on=20 > the list. >=20 > A resolution for this particular issue, i.e.,=20 > "rc/cc/rt" vs "fluff" vs > "no tag" vs "no entry" is required. Seems like a good=20 > topic for Stockholm. >=20 >=20 > mp tag:=20 >=20 > In the current draft, the "mp" tag represent the=20 > "mapped-TO" address,=20 > not the mapped-FROM address. Unlike the "fluff"=20 > parameters, it means a=20 > "user different from the previous one".=20 [JRE] So when I query my location server and get back a new URI, how do I know whether it represents a different user? [JRE] So (ignoring v1 systems), we can receive URIs with the following tags: - 'mp' and 'aor' - 'mp' and not 'aor' - 'fluff' and 'aor' - 'fluff' and not 'aor' I don't recall seeing anything that describes what each of these 4 possibilities means. John >=20 >=20 > target-URI algorithm for UAS: >=20 > There were some questions on the list about algorithms=20 > for picking > the "target URI parameter: is it the last "mp"-marked=20 > tag or is it > the last "aor" tag. It seems that the answer to this=20 > question may > be different based on what the assumptions people have=20 > about what > is in fact a "target URI". It is not clear if we need=20 > to describe > this in the draft, or even indeed if it actually makes a > difference. >=20 >=20 > privacy:=20 >=20 > RFC 3323 was written with a 2-party model. Some of the=20 > wording in=20 > the documents was changed from 4244 to adapt to individual=20 > H-I entries. >=20 > It is not clear if further enhancements to RFC 3323 are=20 > required. > We are inviting people to look at it. >=20 > I believe this is it. >=20 > Thanks. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From gonzalo.camarillo@ericsson.com Thu Jul 23 00:46:45 2009 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 0D49A3A6838; Thu, 23 Jul 2009 00:46:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.273 X-Spam-Level: X-Spam-Status: No, score=-5.273 tagged_above=-999 required=5 tests=[AWL=0.976, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 Pbdo3-ynwERR; Thu, 23 Jul 2009 00:46:44 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A5CE83A6765; Thu, 23 Jul 2009 00:46:43 -0700 (PDT) X-AuditID: c1b4fb3c-b7ba4ae0000038c0-e2-4a6814fd0f91 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id BC.A1.14528.DF4186A4; Thu, 23 Jul 2009 09:45:01 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 09:43:55 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 09:43:55 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 363A62461; Thu, 23 Jul 2009 10:43:55 +0300 (EEST) Message-ID: <4A6814BB.8030809@ericsson.com> Date: Thu, 23 Jul 2009 10:43:55 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: wang.libo@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2009 07:43:55.0499 (UTC) FILETIME=[54C293B0:01CA0B69] X-Brightmail-Tracker: AAAAAA== Cc: gao.yang2@zte.com.cn, SIPCORE , sipcore-bounces@ietf.org Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 23 Jul 2009 07:46:45 -0000 Hi, > In order to make "Already-executed Changes" clear, the draft should > state > when UAS/UAC start to listen on the new port, and when UAS/UAC use > new media parameters. It's essential for users to find the right state, I > think. > yes, it is essential. In any case, the draft will not define anything new in this respect. We will use the definition in RFC 3264 and clarify it if needed. Thanks for your comments, Gonzalo From ietf.hanserik@gmail.com Thu Jul 23 01:02:17 2009 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 B4CB53A6817 for ; Thu, 23 Jul 2009 01:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.381 X-Spam-Level: X-Spam-Status: No, score=-2.381 tagged_above=-999 required=5 tests=[AWL=0.217, 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 YSe-kucMbYPt for ; Thu, 23 Jul 2009 01:02:16 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id 785323A6765 for ; Thu, 23 Jul 2009 01:02:16 -0700 (PDT) Received: by ewy26 with SMTP id 26so785390ewy.37 for ; Thu, 23 Jul 2009 00:59:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=EGTDO/qQpbfpV+v/V4Y97GlPPA3kAkTr3B3A14FMdz8=; b=aVRTfAKdhta4bsCQKWc3F6nE9YxDYfmzYuDF2STdr1VwfNXj+NgXybnUaw4mZciDv7 Fcai/OFaDdWTBdVWbqE+vCoqoOp0Nunm8W3Xa+qE4reDy2pi4xb8v4CgmvBcPx3jOToj dO+QRbtGvBrRrWo0PsC8lSkgYTNAdL6kr8m+k= 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=ZzL+Z07XnAlRxwYRgbdl0B1koCH7qR4gSrHZvu4ntNMT2ysobn7rGzgmN0/H3oLfdG Odfw0UdGLCDbUoI3AiU8k3MMz1iCoZUPHJ8OjhJakKNx8mOaB5dHwYr6+KfVXAMHKHtE tF5sxaTzozR4/HNpaWwsIq5f+1G+ME9gHgzWs= MIME-Version: 1.0 Received: by 10.210.144.8 with SMTP id r8mr286389ebd.96.1248335951899; Thu, 23 Jul 2009 00:59:11 -0700 (PDT) In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0022E981E@GBNTHT12009MSX.gb002.siemens.net> References: <1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3616@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F1A339E@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3667@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0022A39CE@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F201CE4@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0022E981E@GBNTHT12009MSX.gb002.siemens.net> Date: Thu, 23 Jul 2009 09:59:11 +0200 Message-ID: <9ae56b1e0907230059j3002d52ds33747aa3f101c63c@mail.gmail.com> From: Hans Erik van Elburg To: "Elwell, John" Content-Type: multipart/alternative; boundary=0015174beb84f92dde046f5adcf7 Cc: SIPCORE Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summary ofwhere we are 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, 23 Jul 2009 08:02:17 -0000 --0015174beb84f92dde046f5adcf7 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit As the tags have clearly defined meanings and they are orthogonal, finding two tags on an entry does not alter their meaning. So there is no need to define the meanings of combinations. "mp" means that the entry has been added to teh history due to some mapping-translation. And "aor" means that the entry has been input to retarget operation by a proxy that was responsible for the uri in the entry. /Hans Erik van Elburg On Thu, Jul 23, 2009 at 9:18 AM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > [JRE] So (ignoring v1 systems), we can receive URIs with the following > tags: > - 'mp' and 'aor' > - 'mp' and not 'aor' > - 'fluff' and 'aor' > - 'fluff' and not 'aor' > I don't recall seeing anything that describes what each of these 4 > possibilities means. > --0015174beb84f92dde046f5adcf7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
As the tags have clearly defined meanings and they are orthogonal, fin= ding two tags on an entry does not alter their meaning. So there is no need= to define the meanings of combinations.

"mp&= quot; means that the entry has been added to teh history due to some mappin= g-translation. And "aor" means =A0that the entry has been input t= o retarget operation by a proxy that was responsible for the uri in the ent= ry.=A0

/Hans Erik van Elburg

On Thu, Jul 23, 2009 at 9:18 AM, Elwell, Joh= n <john.elwell@siemens-enterprise.com> wrote:
[JRE] So (ignoring v1 systems), we can rece= ive URIs with the following
tags:
- 'mp' and 'aor'
- 'mp' and not 'aor'
- 'fluff' and 'aor'
- 'fluff' and not 'aor'
I don't recall seeing anything that describes what each of these 4
possibilities means.

--0015174beb84f92dde046f5adcf7-- From ietf.hanserik@gmail.com Thu Jul 23 01:06:21 2009 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 06C0A3A6953 for ; Thu, 23 Jul 2009 01:06:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.412 X-Spam-Level: X-Spam-Status: No, score=-2.412 tagged_above=-999 required=5 tests=[AWL=0.186, 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 n5aqGWIUe4Ij for ; Thu, 23 Jul 2009 01:06:20 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id B1A523A693B for ; Thu, 23 Jul 2009 01:06:19 -0700 (PDT) Received: by ewy26 with SMTP id 26so788263ewy.37 for ; Thu, 23 Jul 2009 01:04:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=bAdQeuucyPSnMIy2VjKRV41gJabkuKwQHxYCmUqusm8=; b=MCgp4lBvasKm/Us3KI/3A2mpwUtEDcrlua9uSipFEobgjkJsI5M+JV8y484Bf+8X5X +nKDgqOYTQYkKBdIQmznkl/Garm4LDQAVo9UUhQywHhFN8Sgavz0EgADpj8sHMy1KCIh Ff3/UC8FfJgrhTMD2yc7dDfGt3TD9rIkENkGA= 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=iI9qWO6jg43FhuhsJx59jJrgAzjIdjTYNuN64Zv1iTol42OAgeipzJwVib5OaI1M23 +BLSgXK3UcGVFUIIsYKVhAvGc4LjdYZi1iV6pWdgXi6phMiY02+7LxrpJmNUlGnlbc62 HFfJlyIKRJta/CXh1I7vRXTJTbIu2//aRZ+Oo= MIME-Version: 1.0 Received: by 10.210.65.2 with SMTP id n2mr5145984eba.44.1248336290251; Thu, 23 Jul 2009 01:04:50 -0700 (PDT) In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F201CE4@zrc2hxm0.corp.nortel.com> References: <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3616@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F1A339E@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3667@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0022A39CE@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F201CE4@zrc2hxm0.corp.nortel.com> Date: Thu, 23 Jul 2009 10:04:50 +0200 Message-ID: <9ae56b1e0907230104u3957a145mcac1f1445b796d1b@mail.gmail.com> From: Hans Erik van Elburg To: Francois Audet Content-Type: multipart/alternative; boundary=0015174c150e24031a046f5af11f Cc: SIPCORE Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summary of where we are 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, 23 Jul 2009 08:06:21 -0000 --0015174c150e24031a046f5af11f Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit As said before the algorithms for a UAS are very clear. To retrieve the addressed target (freephone, etc) (Main thing that target-uri draft was after.): - traverse all H-I entries backward until an "mp" entry is found, if found this is the addressed target - if no "mp" found take the first H-I entry - if no History-Info header take the Request-URI value To retrieve the last aor before it was overwritten by contact address (similar as P-Called-Party-ID): - traverse all H-I entries backward until an "aor" entry is found, if found this is the last AOR used Both values can be the same in a lot of situations. But they will not always be. /Hans Erik van Elburg On Thu, Jul 23, 2009 at 6:57 AM, Francois Audet wrote: > target-URI algorithm for UAS: > > There were some questions on the list about algorithms for picking > the "target URI parameter: is it the last "mp"-marked tag or is it > the last "aor" tag. It seems that the answer to this question may > be different based on what the assumptions people have about what > is in fact a "target URI". It is not clear if we need to describe > this in the draft, or even indeed if it actually makes a > difference. > --0015174c150e24031a046f5af11f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable As said before the algorithms for a UAS are very clear.

= To retrieve the addressed target (freephone, etc) (Main thing that target-= uri draft was after.):=A0
- traverse all H-I entries backward until an "mp" entry is f= ound, if found this is the addressed target
- if no "mp"= ; found take the first H-I entry
- if no History-Info header take= the Request-URI value

To retrieve the last aor before it was overwritten by c= ontact address=A0(similar as P-Called-Party-ID):=A0
- traver= se all H-I entries backward until an "aor" entry is found, if fou= nd this is the last AOR used

Both values can be the same in a lot of si= tuations. But they will not always be.

/Hans Erik = van Elburg


On Thu, Jul 23, 2009 at 6:57 AM, Francoi= s Audet <audet@nor= tel.com> wrote:
target-URI algorithm for UAS:

=A0 =A0 =A0 =A0There were some questions on the list about algorithms for = picking
=A0 =A0 =A0 =A0the "target URI parameter: is it the last "mp&quo= t;-marked tag or is it
=A0 =A0 =A0 =A0the last "aor" tag. It seems that the answer to t= his question may
=A0 =A0 =A0 =A0be different based on what the assumptions people have abou= t what
=A0 =A0 =A0 =A0is in fact a "target URI". It is not clear if we = need to describe
=A0 =A0 =A0 =A0this in the draft, or even indeed if it actually makes a =A0 =A0 =A0 =A0difference.

--0015174c150e24031a046f5af11f-- From john.elwell@siemens-enterprise.com Thu Jul 23 02:00:41 2009 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 D7CC83A6903 for ; Thu, 23 Jul 2009 02:00:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.576 X-Spam-Level: X-Spam-Status: No, score=-2.576 tagged_above=-999 required=5 tests=[AWL=0.023, 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 43C97urz7Sr4 for ; Thu, 23 Jul 2009 02:00:41 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id D92B03A6817 for ; Thu, 23 Jul 2009 02:00:40 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KN800AAQ7UATD@siemenscomms.co.uk> for sipcore@ietf.org; Thu, 23 Jul 2009 09:34:58 +0100 (BST) Date: Thu, 23 Jul 2009 09:34:56 +0100 From: "Elwell, John" In-reply-to: <9ae56b1e0907230104u3957a145mcac1f1445b796d1b@mail.gmail.com> To: Hans Erik van Elburg , Francois Audet Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0022E989D@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summaryof where we are Thread-Index: AcoLbJ2NE4NmJ7vRS2ehutpQAWD4KwAAsaow Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3616@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F1A339E@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3667@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0022A39CE@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F201CE4@zrc2hxm0.corp.nortel.com> <9ae56b1e0907230104u3957a145mcac1f1445b796d1b@mail.gmail.com> Cc: SIPCORE Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summaryof where we are 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, 23 Jul 2009 09:00:41 -0000 =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Hans Erik van Elburg > Sent: 23 July 2009 09:05 > To: Francois Audet > Cc: SIPCORE > Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis &=20 > target-URI: Summaryof where we are >=20 > As said before the algorithms for a UAS are very clear.=20 >=20 > To retrieve the addressed target (freephone, etc) (Main thing=20 > that target-uri draft was after.):=20 > - traverse all H-I entries backward until an "mp" entry is=20 > found, if found this is the addressed target > - if no "mp" found take the first H-I entry > - if no History-Info header take the Request-URI value [JRE] Would it not be better to use the To URI in this case? The Request-URI is very unlikely to contain the addressed target. >=20 > To retrieve the last aor before it was overwritten by contact=20 > address (similar as P-Called-Party-ID):=20 > - traverse all H-I entries backward until an "aor" entry is=20 > found, if found this is the last AOR used [JRE] And if none found? >=20 > Both values can be the same in a lot of situations. But they=20 > will not always be. [JRE] A common situation might be as follows. Caller dials freephone number (or group number, or whatever). Proxy resolves this to an AOR, and because that same proxy is responsible for that domain, it resolves it further to a contact URI. If the proxy populates H-I with both the AOR and the contact URI, the algorithm above would work. However, I don't think there is anything in the document to mandate that, so a simple implementation would only insert the contact URI (assuming the freephone number is already there). I don't think either H-I entry would be marked as either AOR or MP in this case, would they? John >=20 > /Hans Erik van Elburg >=20 >=20 >=20 > On Thu, Jul 23, 2009 at 6:57 AM, Francois Audet=20 > wrote: >=20 >=20 > target-URI algorithm for UAS: > =09 > There were some questions on the list about=20 > algorithms for picking > the "target URI parameter: is it the last=20 > "mp"-marked tag or is it > the last "aor" tag. It seems that the answer to=20 > this question may > be different based on what the assumptions=20 > people have about what > is in fact a "target URI". It is not clear if we=20 > need to describe > this in the draft, or even indeed if it actually makes a > difference. >=20 >=20 >=20 From wang.libo@zte.com.cn Thu Jul 23 02:02:43 2009 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 787CF3A693B; Thu, 23 Jul 2009 02:02:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.486 X-Spam-Level: X-Spam-Status: No, score=-99.486 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, MIME_BASE64_TEXT=1.753, RCVD_DOUBLE_IP_LOOSE=0.76, 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 P1m5wGkbg5xA; Thu, 23 Jul 2009 02:02:42 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 39AAC3A685F; Thu, 23 Jul 2009 02:02:42 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 91102001811080; Thu, 23 Jul 2009 15:17:50 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 85804.5060307279; Thu, 23 Jul 2009 15:23:57 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n6N7UxND048911; Thu, 23 Jul 2009 15:30:59 +0800 (CST) (envelope-from wang.libo@zte.com.cn) In-Reply-To: <4A66E224.2010900@ericsson.com> To: Gonzalo Camarillo MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0 August 18, 2005 Message-ID: From: wang.libo@zte.com.cn Date: Thu, 23 Jul 2009 15:30:20 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-23 15:30:49, Serialize complete at 2009-07-23 15:30:49 Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 X-MAIL: mse2.zte.com.cn n6N7UxND048911 Cc: gao.yang2@zte.com.cn, SIPCORE , sipcore-bounces@ietf.org Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 23 Jul 2009 09:02:43 -0000 SGmjrA0KDQogIEluIG9yZGVyIHRvIG1ha2UgIkFscmVhZHktZXhlY3V0ZWQgQ2hhbmdlcyIgY2xl YXIsIHRoZSBkcmFmdCBzaG91bGQgDQpzdGF0ZSANCndoZW4gVUFTL1VBQyBzdGFydCB0byBsaXN0 ZW4gb24gdGhlIG5ldyBwb3J0LCBhbmQgd2hlbiBVQVMvVUFDIHVzZSANCm5ldyBtZWRpYSBwYXJh bWV0ZXJzLiBJdCdzIGVzc2VudGlhbCBmb3IgdXNlcnMgdG8gZmluZCB0aGUgcmlnaHQgc3RhdGUs IEkgDQp0aGluay4NCg0KVGhlcmUgbWF5IGJlIHRocmVlIGNob2ljZXMsIHdoZW4gMjAwT0sgaXMg c2VudCxvciBvZmZlci9hbnN3ZXIgcGFpciBpcyANCmZpbmlzaCwNCm9yIHByZWNvbmRpdGlvbnMg YXJlIG1ldC4NCg0KSU1PIFVBUyBzaG91bGQgc3RhcnQgdG8gbGlzdGVuIG9uIHRoZSBuZXcgcG9y dCB3aGVuIDIwME9LIGlzIHNlbnQsIA0Kd2hlbiB1c2VyIG1ha2VzIGhpcy9oZXIgZGVjaXNpb24g dG8gYWNjZXB0IHRoZSByZS1JbnZpdGUuDQpCdXQgSSdtIG5vdCBzdXJlIGFib3V0IHRoZSBVQUMs IHNob3VsZCBpdCBzdGFydCB0byB1c2UgdGhlIG5ldyBwYXJhbWV0ZXJzIA0KYWZ0ZXIgcmVjZWl2 ZSAyMDBPSz8NCg0KDQpSZWdhcmRzLg0KRXJpYw0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJp dHkgTm90aWNlOiBUaGUgaW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xl bHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11 bmljYXRpb24gaXMgY29uZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxp Z2F0ZWQgdG8gbWFpbnRhaW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xv c2UgdGhlIGNvbnRlbnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVt YWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFu ZCBpbnRlbmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5 IHRvIHdob20gdGhleSBhcmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVt YWlsIGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2Uu IEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5k aXZpZHVhbCBzZW5kZXIuDQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNl cyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIHN5c3RlbS4NCg== From gao.yang2@zte.com.cn Thu Jul 23 02:12:48 2009 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 21F243A6A66 for ; Thu, 23 Jul 2009 02:12:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.775 X-Spam-Level: X-Spam-Status: No, score=-96.775 tagged_above=-999 required=5 tests=[AWL=-2.180, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, J_CHICKENPOX_33=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, MIME_8BIT_HEADER=0.3, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 Sd35OllXldtl for ; Thu, 23 Jul 2009 02:12:47 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 8DD393A6AA7 for ; Thu, 23 Jul 2009 02:12:45 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111641727820181; Thu, 23 Jul 2009 16:54:34 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 85804.2980680612; Thu, 23 Jul 2009 17:05:07 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n6N9CIdO044997; Thu, 23 Jul 2009 17:12:20 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: wang.libo@zte.com.cn X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 23 Jul 2009 17:11:56 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-23 17:12:07 MIME-Version: 1.0 Content-type: text/plain; charset=UTF-8 Content-transfer-encoding: base64 X-MAIL: mse2.zte.com.cn n6N9CIdO044997 Cc: sipcore-bounces@ietf.org, SIPCORE , OKUMURA Shinji Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ICBOZXcgcmV2aXNpb24gb2YgdGhlIHJl?= =?gb2312?b?LUlOVklURSBoYW5kbGluZyBkcmFmdA==?= 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, 23 Jul 2009 09:12:48 -0000 DQpIaSwNCg0KSSBkb24ndCBrbm93IHdheSBtYWlsIGxpc3QncyAqc29tZXRpbWVzKiBoYXMgcHJv YmxlbSBpbiBkaXNwYWN0aW5nIG15IG1haWwuDQoNCkZvciB5b3VyIHF1ZXN0aW9uOg0KDQpJbiBm YWN0LCB0aGlzIGlzIGEgYmFja3dvcmQtY29tcGF0aWJsZSBwcm9ibGVtLiBBbmQgSU1P77yMaXQg Z2l2ZXMgb3V0IGEgd2F5DQp0byBzeW5jaHJvbml6ZSBzZXNzaW9uIHN0YXRlIGZvciBVQUMgYW5k IFVBUy4gV2hpY2ggc2Vzc2lvbiBzdGF0ZSBmb3INCnN5bmNocm9uaXphdGlvbiBpcyBwcm9wZXIg Y2FuIGJlIGRlZHVjZWQgZnJvbSBtZWRpYSBzdHJlYW1zICppbiB1c2UqLiBTbywNCnRoaXMgaXMg dGhlIHNhbWUgcXVlc3Rpb24gYXMgKmluIHVzZSogZGVmaW5pdGlvbi4NCg0KVGhhbmtzLg0KDQpH YW8NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAyMTAw MTINCiBUZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9tYWls IDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09DQoNCg0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgV2FuZ0xpQm8xMzU2ODEv dXMgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAg ICAgICBlci96dGVfbHRkICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICDmlLbku7bkurogDQogICAgICAgICAgICAgMjAwOS0wNy0y MyAxNjo0NiAgICAgICAgICBHYW9ZYW5nMTQwMTk3L3VzZXIvenRlX2x0ZEB6dGVfbHRkICANCiAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICDmioTpgIEgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICBHb256YWxvIENhbWFyaWxsbyAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDxHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb20+LCAg IA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgUGF1bCBLeXppdmF0IDxw a3l6aXZhdEBjaXNjby5jb20+LCAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBPS1VNVVJBIFNoaW5qaSAgICAgICAgICAgICAgICAgICAgICANCiAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIDxzaGluQHNvZnRmcm9udC5jby5qcD4sIFNJUENPUkUg ICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgPHNpcGNvcmVAaWV0 Zi5vcmc+LCAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgICAgICAgICAgICANCiAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICDkuLvpopggDQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICDnrZTlpI06 IFJlOiBbc2lwY29yZV0gTmV3IHJldmlzaW9uIG9mIA0KICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgdGhlIHJlLUlOVklURSBoYW5kbGluZyBkcmFmdCAgICAgICAgDQogICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoRG9jdW1lbnQgbGluazog6auY5oms MTQwMTk3KSAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAN CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIA0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgDQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICANCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIA0KDQoNCg0KaGksDQoNCiAgIFBpdHkgY2FuJ3QgcmVjZWl2 ZSB5b3VyIG1haWxzIGRpc3BhdGNoZWQgZnJvbSB0aGUgbGlzdCA9Xz0hIQ0KDQogICBJIHJlYWQg dGhlIGRyYWZ0IGFnYWluLiBJdCBzZWVtcyB0aGUgc3RhdGVzIGFyZSB1c2VsZXNzLklmIHJlLUlO VklURSBpcw0KYWNjZXB0ZWQsDQpldmVyeXRoaW5nIGlzIG9rLkFuZCBpZiByZS1JTlZJVEUgaXMg cmVqZWN0ZWQsIFVBQyBnZW5lcmF0ZSBhIG5ldyByZS1JTlZJVEUNCndpdGgNCm9sZCBzdGF0ZSwg dGhleSBkb24ndCBuZWVkIHRvIGNvbmNlcm4gYWJvdXQgd2hpY2ggc3RhdGUgdGhleSB3ZXJlIGF0 LiBJcyBpdA0KcmlnaHQ/DQoNCg0KDQo2LiAgVUFDIEJlaGF2aW9yDQoNCiAgIFRoZSBiZWhhdmlv ciBvZiBhIFVBQyBjb21tdW5pY2F0aW5nIHdpdGggYSBVQVMgdGhhdCBzdXBwb3J0cyB0aGlzDQog ICBzcGVjaWZpY2F0aW9uIChpLmUuLCBhIFVBUyB0aGF0IGZvbGxvd3MgdGhlIGd1aWRlbGluZXMg aW4gU2VjdGlvbiA1KQ0KICAgaXMgc3RyYWlnaHQgZm9yd2FyZC4gIEhvd2V2ZXIsIGEgVUFDIG1h eSBmYWNlIGEgbGVnYWN5IFVBUyB0aGF0IHVzZXMNCiAgIGFuIGVycm9yIHJlc3BvbnNlIHRvIHVu ZG8gYWxyZWFkeS1leGVjdXRlZCBjaGFuZ2VzIHdpdGhpbiBhIHJlLQ0KICAgSU5WSVRFLg0KDQog ICBJbiBvcmRlciB0byBjb3BlIHdpdGggdGhpcyB0eXBlIG9mIFVBUywgYSBVQUMgdGhhdCByZWNl aXZlcyBhbiBlcnJvcg0KICAgcmVzcG9uc2UgdG8gYSByZS1JTlZJVEUgZm9yIHdoaWNoIGNoYW5n ZXMgaGF2ZSBiZWVuIGFscmVhZHkgZXhlY3V0ZWQNCiAgIFNIT1VMRCBnZW5lcmF0ZSBhIG5ldyBy ZS1JTlZJVEUgb3IgVVBEQVRFIHJlcXVlc3QgaW4gb3JkZXIgdG8gbWFrZQ0KICAgc3VyZSB0aGF0 IGJvdGggVUFzIGhhdmUgYSBjb21tb24gdmlldyBvZiB0aGUgc3RhdGUgb2YgdGhlIHNlc3Npb24u DQogICBUaGUgcHVycG9zZSBvZiB0aGlzIG5ldyBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UgaXMgdG8g c3luY2hyb25pemUgYm90aA0KICAgVUFzLCBub3QgdG8gcmVxdWVzdCBjaGFuZ2VzIHRoYXQgdGhl IFVBUyBtYXkgY2hvb3NlIHRvIHJlamVjdC4NCiAgIFRoZXJlZm9yZSwgdGhlIHNlc3Npb24gcGFy YW1ldGVycyBpbiB0aGUgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlIFNIT1VMRA0KICAgYmUgYXMgY2xv c2UgYXMgdGhvc2UgaW4gdGhlIHByZS1yZS1JTlZJVEUgc3RhdGUgYXMgcG9zc2libGUuDQoNCg0K DQoNCg0KDQpHYW9ZYW5nMTQwMTk3L3VzZXIvenRlX2x0ZCDlhpnkuo4gMjAwOS0wNy0yMyAxNjox MTowNToNCg0KPiBIaSwNCj4NCj4gSSBhbSBhZ3JlZSB3aXRoIEdvbnphbG8uIEFuZCBXYW5nIExp Ym8obXkgY29sbGVhZ3VlKSdzIHF1ZXN0aW9uIGlzDQo+IHRoZSBzYW1lIGFzIFNoaW5qaSdzLiBB Y2Nlc3NvcnkgaXMgbXkgbWFpbCBmb3IgU2hpbmppKGJ1dCBJIGRvbid0DQo+IGtub3cgd2h5IHRo aXMgbWFpbCB3YXMgbm90IGRpc3BhdGNoZWQgYnkgbWFpbCBsaXN0KS4NCj4NCj4gTXkgbWVhbnMg aXMgdGhhdCB0aW1lIHBvaW50IG9mICJpbiB1c2UiIGhhcyBubyBpbXBhY3Qgb24gdGhlDQo+IHJh dGlvbmFsaXR5IG9mIHRoZSB3YXkobmV3IFVQREFURS8yMDBPSykgaGFuZGxpbmcgc2Vzc2lvbiBz dGF0ZSdzDQo+IHJvbGxiYWNrIGhlcmUuDQo+IFRoZSByYXRpb25hbGl0eSBvZiBjaG9vc2VkIHNl c3Npb24gc3RhdGUgZm9yIHJvbGxiYWNrIGlzIHNlcGFyYXRlDQo+IGZyb20gdGhlIHdheSBwcm9w b3NlZCBieSBkcmFmdC1jYW1hcmlsbG8tc2lwY29yZS1yZWludml0ZS0wMC4gSXQgaXMNCj4gUkZD MzI2NCBjb25jZXJuZWQuIEFuZCBhcyBSRkMzMjY0IGRvZXMgbm90IGNvbnNpZGVyIHNlc3Npb24N Cj4gbW9kaWZpY2F0aW9uIG92ZXJsYXBzIG1vcmUgdGhhbiBvbmUgTy9BIHBhaXJzLCBzdWNoIGFz IHByZWNvbmRpdGlvbiwNCj4gd2UgbmVlZCBjbGFyaWZpY2F0aW9uIGZvciBpdC4gQnV0IEkgdGhp bmsgaXQgY2FuIGJlIGEgc2VwYXJhdGUgdGV4dC4NCj4NCj4gVGhhbmtzLg0KPg0KPiBHYW8NCj4N Cj4gLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vL21h aWwgZm9yDQo+IFNoaW5qaS8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vDQo+DQo+IEhpIFNoaW5qaSwNCj4NCj4gQWJvdXQgbm9uLTJ4eCBv ZiBSZS1JTlZJVEU6DQo+IFRoZSB3YXkgcHJvcG9zZWQgaW4gZHJhZnQtY2FtYXJpbGxvLXNpcGNv cmUtcmVpbnZpdGUtMDAgaXMNCj4gKmZvcmJpZGluZyogbm9uLTJ4eCBvZiBSZS1JTlZJVEUgYWZ0 ZXIgTy9BLg0KPiBTbywgeW91ciBleGFtcGxlIGlzIG5vdCBleGlzdCBhbG9uZyB0aGUgd2F5IG9m IGRyYWZ0LWNhbWFyaWxsby0NCj4gc2lwY29yZS1yZWludml0ZS0wMC4gQW5kIHRoZSBhbHRlcm5h dGl2ZSB3YXkgZm9yIHJlamVjdGluZyBzZXNzaW4NCj4gbW9kaWZpY2F0aW9uIGhlcmUgaXMgdXNp bmcgYSBuZXcgVVBEQVRFLzIwME9LICBiZWZvcmUgdGhlIDJ4eCBvZiBSZS0NCj4gSU5WSVRFLiBJ IHRoaW5rIGl0IGlzIGVmZmVjdGl2ZSBoZXJlLiBXaGF0J3MgeW91ciBwb2ludHM/DQo+DQo+IEFi b3V0ICJpbiB1c2UiOg0KPg0KPiBUaGUgbWVhbmluZyBvZiAiaW4gdXNlIihhcyBkZWZpbmVkIGlu IFJGQzMyNjQpOiBXaGVuIGFuc3dlcmVyIHNlbmQNCj4gbmV3IG1lZGlhIHN0cmVhbShvciBzZW5k IG1lZGlhIHVzaW5nIG5ldyBwYXJhbWV0ZXJzKSwgbWVkaWEgaXMgImluDQo+IHVzZSIuIEFuZCBm b3Igb2ZmZXJlciwgaXQgY29uc2lkZXJzIHRoZSBuZXcgcGFyYW1ldGVycyB0byBiZSBpbiB1c2UN Cj4gd2hlbiAobmV3KSBtZWRpYSBpcyByZWNlaXZlZCBvciB1c2luZyBuZXcgcGFyYW1ldGVycy4N Cj4gU28sIHRoZSBtZWFuaW5nIG9mICJpbiB1c2UiIGlzIHF1aXQgY2xlYXIgaGVyZS4NCj4NCj4g VGhlIHRpbWUgcG9pbnQgb2YgImluIHVzZSI6IGl0IGlzIGRlcGVuZGVudCBvbiBjYXNlczoNCj4N Cj4gQ2FzZSAxOiBDaGFuZ2luZyBhdWRpbyBzdHJlYW0ncyBjb2RlYyB3aXRob3V0IHByZWNvbmRp dGlvbiBhbmQNCj4gYWRkaW5nIHZlZGlvIHN0cmVhbSB3aXRoIHByZWNvbmRpdGlvbi4NCj4gTW9k aWZpY2F0aW9uIG9mIGF1ZGlvIHdvdWxkIGJlICJpbiB1c2UiIGJlZm9yZSBwcmVjb25kaXRpb24g c2F0aXNmaWVkLg0KPg0KPiBDYXNlIDI6IENoYW5naW5nIGF1ZGlvIHN0cmVhbSdzIGNvZGVjIHdp dGggcHJlY29uZGl0aW9uIGFuZCBhbmQNCj4gYWRkaW5nIHZlZGlvIHN0cmVhbSB3aXRoIHByZWNv bmRpdGlvbi4NCj4gTW9kaWZpY2F0aW9uIG9mIGF1ZGlvIHdvdWxkIGJlICJpbiB1c2UiIG9uIHRo ZSBwb2ludCBvZg0KcHJlY29uZGl0aW9uc2F0aXNmaWVkLg0KPg0KPiBDYXNlIDM6IEFkZGluZyB2 ZWRpbyBzdHJlYW0gd2l0aCBwcmVjb25kaXRpb24sIHdoaWNoIG5lZWRzIHVzZXIncw0KZGVjaXNp b24uDQo+IEFzIGluIHByZWNvbmRpdG9uIHVzZSBjYXNlcywgdXNlciBvZiBVQVMgb25seSBoYXMg dGhlIGNoYW5jZSB0bw0KPiBkZWNpZGUgYWNjZXB0aW5nL3JlamVjdGluZyBzZXNzaW9uIG1vZGlm aWNhdGlvbiBhZnRlciBwcmVjb25kaXRpb24NCnNhdGlzZmllZC4NCj4gVmVkaW9uIHN0cmVhbSB3 b3VsZCBiZSAiaW4gdXNlIiBhZnRlciBwcmVjb25kaXRpb24gc2F0aXNmaWVkLg0KPg0KPiBXaGls ZSB1c2luZyBhIG5ldyBVUERBVEUvMjAwT0sgcGFpciBiZWZvcmUgZmluYWwgcmVzcG9uc2Ugb2Yg UmUtDQo+IElOVklURSwgdGhlIHRpbWUgcG9pbnQgb2YgImluIHVzZSIgaGFzIG5vIGltcGFjdCBv biB0aGUgc2Vzc2lvbiBzdGF0ZS4NCj4NCj4gVGhhbmtzLg0KPg0KPiBHYW8NCj4NCj4gLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy9lbmQgb2YgdGhlIG1haWwgZm9y DQo+IFNoaW5qaS8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8NCj4NCj4gPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gIFpp cCAgICA6IDIxMDAxMg0KPiAgVGVsICAgIDogODcyMTENCj4gIFRlbDIgICA6KCs4NiktMDI1LTUy ODc3MjExDQo+ICBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbg0KPiA9PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PQ0KPg0KPiBHb256YWxvIENhbWFyaWxsbyA8R29uemFsby5D YW1hcmlsbG9AZXJpY3Nzb24uY29tPg0KPiAyMDA5LTA3LTIzIDE1OjQzDQo+DQo+IOaUtuS7tuS6 ug0KPg0KPiB3YW5nLmxpYm9AenRlLmNvbS5jbg0KPg0KPiDmioTpgIENCj4NCj4gZ2FvLnlhbmcy QHp0ZS5jb20uY24sIFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAY2lzY28uY29tPiwgU0lQQ09SRQ0K PiA8c2lwY29yZUBpZXRmLm9yZz4sIHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZw0KPg0KPiDkuLvp opgNCj4NCj4gUmU6IFtzaXBjb3JlXSBOZXcgcmV2aXNpb24gb2YgdGhlIHJlLUlOVklURSBoYW5k bGluZyBkcmFmdA0KPg0KPiBIaSwNCj4NCj4gPiAgIEluIG9yZGVyIHRvIG1ha2UgIkFscmVhZHkt ZXhlY3V0ZWQgQ2hhbmdlcyIgY2xlYXIsIHRoZSBkcmFmdCBzaG91bGQNCj4gPiBzdGF0ZQ0KPiA+ IHdoZW4gVUFTL1VBQyBzdGFydCB0byBsaXN0ZW4gb24gdGhlIG5ldyBwb3J0LCBhbmQgd2hlbiBV QVMvVUFDIHVzZQ0KPiA+IG5ldyBtZWRpYSBwYXJhbWV0ZXJzLiBJdCdzIGVzc2VudGlhbCBmb3Ig dXNlcnMgdG8gZmluZCB0aGUgcmlnaHQgc3RhdGUsDQpJDQo+ID4gdGhpbmsuDQo+ID4NCj4NCj4g eWVzLCBpdCBpcyBlc3NlbnRpYWwuIEluIGFueSBjYXNlLCB0aGUgZHJhZnQgd2lsbCBub3QgZGVm aW5lIGFueXRoaW5nDQo+IG5ldyBpbiB0aGlzIHJlc3BlY3QuIFdlIHdpbGwgdXNlIHRoZSBkZWZp bml0aW9uIGluIFJGQyAzMjY0IGFuZCBjbGFyaWZ5DQo+IGl0IGlmIG5lZWRlZC4NCj4NCj4gVGhh bmtzIGZvciB5b3VyIGNvbW1lbnRzLA0KPg0KPiBHb256YWxvDQo+DQoNCg0KLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1h dGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBt YWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlz IG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJv dmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRl ZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVy cy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25m aWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVh bCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2Vp dmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0 aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3Nl IG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVk IGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K From ietf.hanserik@gmail.com Thu Jul 23 02:14:52 2009 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 F00B628C14F for ; Thu, 23 Jul 2009 02:14:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.436 X-Spam-Level: X-Spam-Status: No, score=-2.436 tagged_above=-999 required=5 tests=[AWL=0.162, 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 mnyRBkmK--7G for ; Thu, 23 Jul 2009 02:14:51 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id AF7EC28C1B1 for ; Thu, 23 Jul 2009 02:14:40 -0700 (PDT) Received: by ewy26 with SMTP id 26so823965ewy.37 for ; Thu, 23 Jul 2009 02:14:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=HvNQFtMPtx9wgbgAZo4G8rw6z/uD/yw3ZtfQQyV00Lc=; b=Car7sTd2emq2JqXnhmtD9xPboo9k0hofL38AksJx4goLuW6xkopXkrOmmS2TXdFWt3 Rw7UBXiK5G1EUjWJaUUNAOtQMiWanll5q/v36+qcZqQ0LX4NNFhCW8Gvy73V3lo169BX O66VjzaHuC8+sdwBrCcYNe1cII+9s/K6H9ynE= 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=YiDNI7VWf3VpgSg0SUVCAffZAjhSdi7N91bFdWDb+GOEdwok0w2wrU5/NxOp8KggJV u+JVyCQLiusdeK1Lq4+YQO5LkSsb/LXt2QzS/XfoEzNCOXXhaQRaff8qtmO+gfxNXNnh lPXg917swezMwMXnzCsP2p/Fn167JAoROlc0o= MIME-Version: 1.0 Received: by 10.210.89.7 with SMTP id m7mr2243816ebb.92.1248338669142; Thu, 23 Jul 2009 01:44:29 -0700 (PDT) In-Reply-To: <0D5F89FAC29E2C41B98A6A762007F5D0022E989D@GBNTHT12009MSX.gb002.siemens.net> References: <0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3616@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F1A339E@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3667@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0022A39CE@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F201CE4@zrc2hxm0.corp.nortel.com> <9ae56b1e0907230104u3957a145mcac1f1445b796d1b@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D0022E989D@GBNTHT12009MSX.gb002.siemens.net> Date: Thu, 23 Jul 2009 10:44:29 +0200 Message-ID: <9ae56b1e0907230144q5abdafe8k7d21e944d6f68212@mail.gmail.com> From: Hans Erik van Elburg To: "Elwell, John" Content-Type: multipart/alternative; boundary=0015174be874ef053f046f5b7e21 Cc: SIPCORE Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summaryof where we are 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, 23 Jul 2009 09:14:53 -0000 --0015174be874ef053f046f5b7e21 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit inline as [HE]... /Hans Erik van Elburg On Thu, Jul 23, 2009 at 10:34 AM, Elwell, John < john.elwell@siemens-enterprise.com> wrote: > > > To retrieve the addressed target (freephone, etc) (Main thing > > that target-uri draft was after.): > > - traverse all H-I entries backward until an "mp" entry is > > found, if found this is the addressed target > > - if no "mp" found take the first H-I entry > > - if no History-Info header take the Request-URI value > [JRE] Would it not be better to use the To URI in this case? The > Request-URI is very unlikely to contain the addressed target. > [HE] Not sure To URI is also very unreliable. Maybe we should say in that case that the addressed target could not be determined reliably. > > > > > To retrieve the last aor before it was overwritten by contact > > address (similar as P-Called-Party-ID): > > - traverse all H-I entries backward until an "aor" entry is > > found, if found this is the last AOR used > [JRE] And if none found? [HE] Then the info is not available. > > Both values can be the same in a lot of situations. But they > > will not always be. > [JRE] A common situation might be as follows. Caller dials freephone > number (or group number, or whatever). Proxy resolves this to an AOR, > and because that same proxy is responsible for that domain, it resolves > it further to a contact URI. If the proxy populates H-I with both the > AOR and the contact URI, the algorithm above would work. However, I > don't think there is anything in the document to mandate that, so a > simple implementation would only insert the contact URI (assuming the > freephone number is already there). I don't think either H-I entry would > be marked as either AOR or MP in this case, would they? > [HE] I think they would. I believe the 4244bis and also 4244 explicitly require internal retargets to also be recorded. > > > > > On Thu, Jul 23, 2009 at 6:57 AM, Francois Audet > > wrote: > > > > > > target-URI algorithm for UAS: > > > > There were some questions on the list about > > algorithms for picking > > the "target URI parameter: is it the last > > "mp"-marked tag or is it > > the last "aor" tag. It seems that the answer to > > this question may > > be different based on what the assumptions > > people have about what > > is in fact a "target URI". It is not clear if we > > need to describe > > this in the draft, or even indeed if it actually makes a > > difference. > > > > > > > --0015174be874ef053f046f5b7e21 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
inline as [HE]...

/Hans Erik van Elburg

On Thu, Jul 23, 2009 at 10:34 AM, Elwell, Jo= hn <john.elwell@siemens-enterprise.com> wrote:

> To retrieve the addressed target (freephone, etc) (Main thing
> that target-uri draft was after.):
> - traverse all H-I entries backward until an "mp" entry is > found, if found this is the addressed target
> - if no "mp" found take the first H-I entry
> - if no History-Info header take the Request-URI value
[JRE] Would it not be better to use the To URI in this case? The
Request-URI is very unlikely to contain the addressed target.
[HE] Not sure To URI is also very= unreliable. Maybe we should say in that case that =A0the addressed target = could not be determined reliably.
=A0

>
> To retrieve the last aor before it was overwritten by contact
> address (similar as P-Called-Party-ID):
> - traverse all H-I entries backward until an "aor" entry is<= br> > found, if found this is the last AOR used
[JRE] And if none found?
[HE] Then the info is not a= vailable.
=A0
> Both values can be the same in a lot of situations. But they
> will not always be.
[JRE] A common situation might be as follows. Caller dials freephone<= br> number (or group number, or whatever). Proxy resolves this to an AOR,
and because that same proxy is responsible for that domain, it resolves
it further to a contact URI. If the proxy populates H-I with both the
AOR and the contact URI, the algorithm above would work. However, I
don't think there is anything in the document to mandate that, so a
simple implementation would only insert the contact URI (assuming the
freephone number is already there). I don't think either H-I entry woul= d
be marked as either AOR or MP in this case, would they?
[HE] I think they would. I= believe the 4244bis and also 4244 explicitly require internal retargets to= also be recorded.
=A0

>
> On Thu, Jul 23, 2009 at 6:57 AM, Francois Audet
> <audet@nortel.com> wrote= :
>
>
> =A0 =A0 =A0 target-URI algorithm for UAS:
>
> =A0 =A0 =A0 =A0 =A0 =A0 =A0There were some questions on the list about=
> algorithms for picking
> =A0 =A0 =A0 =A0 =A0 =A0 =A0the "target URI parameter: is it the l= ast
> "mp"-marked tag or is it
> =A0 =A0 =A0 =A0 =A0 =A0 =A0the last "aor" tag. It seems that= the answer to
> this question may
> =A0 =A0 =A0 =A0 =A0 =A0 =A0be different based on what the assumptions<= br> > people have about what
> =A0 =A0 =A0 =A0 =A0 =A0 =A0is in fact a "target URI". It is = not clear if we
> need to describe
> =A0 =A0 =A0 =A0 =A0 =A0 =A0this in the draft, or even indeed if it act= ually makes a
> =A0 =A0 =A0 =A0 =A0 =A0 =A0difference.
>
>
>

--0015174be874ef053f046f5b7e21-- From wang.libo@zte.com.cn Thu Jul 23 02:17:59 2009 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 71A653A67B3; Thu, 23 Jul 2009 02:17:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -90.39 X-Spam-Level: X-Spam-Status: No, score=-90.39 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 tOPC-upnTy8J; Thu, 23 Jul 2009 02:17:58 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 496F23A6838; Thu, 23 Jul 2009 02:17:57 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111642001811080; Thu, 23 Jul 2009 16:28:33 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 85804.5060307279; Thu, 23 Jul 2009 16:39:27 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n6N8kUR6024894; Thu, 23 Jul 2009 16:46:32 +0800 (CST) (envelope-from wang.libo@zte.com.cn) In-Reply-To: To: gao.yang2@zte.com.cn MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: wang.libo@zte.com.cn Date: Thu, 23 Jul 2009 16:46:05 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-23 16:46:20, Serialize complete at 2009-07-23 16:46:20 Content-Type: multipart/alternative; boundary="=_alternative 002FCAF2482575FC_=" X-MAIL: mse2.zte.com.cn n6N8kUR6024894 Cc: sipcore-bounces@ietf.org, SIPCORE , OKUMURA Shinji Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ICBOZXcgcmV2aXNpb24gb2YgdGhlIHJl?= =?gb2312?b?LUlOVklURSBoYW5kbGluZyBkcmFmdA==?= 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, 23 Jul 2009 09:17:59 -0000 This is a multipart message in MIME format. --=_alternative 002FCAF2482575FC_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 aGksDQoNCiAgIFBpdHkgY2FuJ3QgcmVjZWl2ZSB5b3VyIG1haWxzIGRpc3BhdGNoZWQgZnJvbSB0 aGUgbGlzdCA9Xz0hIQ0KDQogICBJIHJlYWQgdGhlIGRyYWZ0IGFnYWluLiBJdCBzZWVtcyB0aGUg c3RhdGVzIGFyZSB1c2VsZXNzLklmIHJlLUlOVklURSBpcyANCmFjY2VwdGVkLA0KZXZlcnl0aGlu ZyBpcyBvay5BbmQgaWYgcmUtSU5WSVRFIGlzIHJlamVjdGVkLCBVQUMgZ2VuZXJhdGUgYSBuZXcg DQpyZS1JTlZJVEUgd2l0aCANCm9sZCBzdGF0ZSwgdGhleSBkb24ndCBuZWVkIHRvIGNvbmNlcm4g YWJvdXQgd2hpY2ggc3RhdGUgdGhleSB3ZXJlIGF0LiBJcyANCml0IHJpZ2h0Pw0KDQoNCg0KNi4g IFVBQyBCZWhhdmlvcg0KDQogICBUaGUgYmVoYXZpb3Igb2YgYSBVQUMgY29tbXVuaWNhdGluZyB3 aXRoIGEgVUFTIHRoYXQgc3VwcG9ydHMgdGhpcw0KICAgc3BlY2lmaWNhdGlvbiAoaS5lLiwgYSBV QVMgdGhhdCBmb2xsb3dzIHRoZSBndWlkZWxpbmVzIGluIFNlY3Rpb24gNSkNCiAgIGlzIHN0cmFp Z2h0IGZvcndhcmQuICBIb3dldmVyLCBhIFVBQyBtYXkgZmFjZSBhIGxlZ2FjeSBVQVMgdGhhdCB1 c2VzDQogICBhbiBlcnJvciByZXNwb25zZSB0byB1bmRvIGFscmVhZHktZXhlY3V0ZWQgY2hhbmdl cyB3aXRoaW4gYSByZS0NCiAgIElOVklURS4NCg0KICAgSW4gb3JkZXIgdG8gY29wZSB3aXRoIHRo aXMgdHlwZSBvZiBVQVMsIGEgVUFDIHRoYXQgcmVjZWl2ZXMgYW4gZXJyb3INCiAgIHJlc3BvbnNl IHRvIGEgcmUtSU5WSVRFIGZvciB3aGljaCBjaGFuZ2VzIGhhdmUgYmVlbiBhbHJlYWR5IGV4ZWN1 dGVkDQogICBTSE9VTEQgZ2VuZXJhdGUgYSBuZXcgcmUtSU5WSVRFIG9yIFVQREFURSByZXF1ZXN0 IGluIG9yZGVyIHRvIG1ha2UNCiAgIHN1cmUgdGhhdCBib3RoIFVBcyBoYXZlIGEgY29tbW9uIHZp ZXcgb2YgdGhlIHN0YXRlIG9mIHRoZSBzZXNzaW9uLg0KICAgVGhlIHB1cnBvc2Ugb2YgdGhpcyBu ZXcgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlIGlzIHRvIHN5bmNocm9uaXplIGJvdGgNCiAgIFVBcywg bm90IHRvIHJlcXVlc3QgY2hhbmdlcyB0aGF0IHRoZSBVQVMgbWF5IGNob29zZSB0byByZWplY3Qu DQogICBUaGVyZWZvcmUsIHRoZSBzZXNzaW9uIHBhcmFtZXRlcnMgaW4gdGhlIG9mZmVyL2Fuc3dl ciBleGNoYW5nZSBTSE9VTEQNCiAgIGJlIGFzIGNsb3NlIGFzIHRob3NlIGluIHRoZSBwcmUtcmUt SU5WSVRFIHN0YXRlIGFzIHBvc3NpYmxlLg0KDQoNCg0KDQoNCg0KR2FvWWFuZzE0MDE5Ny91c2Vy L3p0ZV9sdGQg0LTT2iAyMDA5LTA3LTIzIDE2OjExOjA1Og0KDQo+IEhpLA0KPiANCj4gSSBhbSBh Z3JlZSB3aXRoIEdvbnphbG8uIEFuZCBXYW5nIExpYm8obXkgY29sbGVhZ3VlKSdzIHF1ZXN0aW9u IGlzIA0KPiB0aGUgc2FtZSBhcyBTaGluamkncy4gQWNjZXNzb3J5IGlzIG15IG1haWwgZm9yIFNo aW5qaShidXQgSSBkb24ndCANCj4ga25vdyB3aHkgdGhpcyBtYWlsIHdhcyBub3QgZGlzcGF0Y2hl ZCBieSBtYWlsIGxpc3QpLg0KPiANCj4gTXkgbWVhbnMgaXMgdGhhdCB0aW1lIHBvaW50IG9mICJp biB1c2UiIGhhcyBubyBpbXBhY3Qgb24gdGhlIA0KPiByYXRpb25hbGl0eSBvZiB0aGUgd2F5KG5l dyBVUERBVEUvMjAwT0spIGhhbmRsaW5nIHNlc3Npb24gc3RhdGUncyANCj4gcm9sbGJhY2sgaGVy ZS4NCj4gVGhlIHJhdGlvbmFsaXR5IG9mIGNob29zZWQgc2Vzc2lvbiBzdGF0ZSBmb3Igcm9sbGJh Y2sgaXMgc2VwYXJhdGUgDQo+IGZyb20gdGhlIHdheSBwcm9wb3NlZCBieSBkcmFmdC1jYW1hcmls bG8tc2lwY29yZS1yZWludml0ZS0wMC4gSXQgaXMgDQo+IFJGQzMyNjQgY29uY2VybmVkLiBBbmQg YXMgUkZDMzI2NCBkb2VzIG5vdCBjb25zaWRlciBzZXNzaW9uIA0KPiBtb2RpZmljYXRpb24gb3Zl cmxhcHMgbW9yZSB0aGFuIG9uZSBPL0EgcGFpcnMsIHN1Y2ggYXMgcHJlY29uZGl0aW9uLA0KPiB3 ZSBuZWVkIGNsYXJpZmljYXRpb24gZm9yIGl0LiBCdXQgSSB0aGluayBpdCBjYW4gYmUgYSBzZXBh cmF0ZSB0ZXh0Lg0KPiANCj4gVGhhbmtzLg0KPiANCj4gR2FvDQo+IA0KPiAvLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vbWFpbCBmb3IgDQo+IFNoaW5q aS8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vDQo+IA0KPiBIaSBTaGluamksDQo+IA0KPiBBYm91dCBub24tMnh4IG9mIFJlLUlOVklURToN Cj4gVGhlIHdheSBwcm9wb3NlZCBpbiBkcmFmdC1jYW1hcmlsbG8tc2lwY29yZS1yZWludml0ZS0w MCBpcyANCj4gKmZvcmJpZGluZyogbm9uLTJ4eCBvZiBSZS1JTlZJVEUgYWZ0ZXIgTy9BLg0KPiBT bywgeW91ciBleGFtcGxlIGlzIG5vdCBleGlzdCBhbG9uZyB0aGUgd2F5IG9mIGRyYWZ0LWNhbWFy aWxsby0NCj4gc2lwY29yZS1yZWludml0ZS0wMC4gQW5kIHRoZSBhbHRlcm5hdGl2ZSB3YXkgZm9y IHJlamVjdGluZyBzZXNzaW4gDQo+IG1vZGlmaWNhdGlvbiBoZXJlIGlzIHVzaW5nIGEgbmV3IFVQ REFURS8yMDBPSyAgYmVmb3JlIHRoZSAyeHggb2YgUmUtDQo+IElOVklURS4gSSB0aGluayBpdCBp cyBlZmZlY3RpdmUgaGVyZS4gV2hhdCdzIHlvdXIgcG9pbnRzPw0KPiANCj4gQWJvdXQgImluIHVz ZSI6DQo+IA0KPiBUaGUgbWVhbmluZyBvZiAiaW4gdXNlIihhcyBkZWZpbmVkIGluIFJGQzMyNjQp OiBXaGVuIGFuc3dlcmVyIHNlbmQgDQo+IG5ldyBtZWRpYSBzdHJlYW0ob3Igc2VuZCBtZWRpYSB1 c2luZyBuZXcgcGFyYW1ldGVycyksIG1lZGlhIGlzICJpbiANCj4gdXNlIi4gQW5kIGZvciBvZmZl cmVyLCBpdCBjb25zaWRlcnMgdGhlIG5ldyBwYXJhbWV0ZXJzIHRvIGJlIGluIHVzZSANCj4gd2hl biAobmV3KSBtZWRpYSBpcyByZWNlaXZlZCBvciB1c2luZyBuZXcgcGFyYW1ldGVycy4NCj4gU28s IHRoZSBtZWFuaW5nIG9mICJpbiB1c2UiIGlzIHF1aXQgY2xlYXIgaGVyZS4NCj4gDQo+IFRoZSB0 aW1lIHBvaW50IG9mICJpbiB1c2UiOiBpdCBpcyBkZXBlbmRlbnQgb24gY2FzZXM6DQo+IA0KPiBD YXNlIDE6IENoYW5naW5nIGF1ZGlvIHN0cmVhbSdzIGNvZGVjIHdpdGhvdXQgcHJlY29uZGl0aW9u IGFuZCANCj4gYWRkaW5nIHZlZGlvIHN0cmVhbSB3aXRoIHByZWNvbmRpdGlvbi4NCj4gTW9kaWZp Y2F0aW9uIG9mIGF1ZGlvIHdvdWxkIGJlICJpbiB1c2UiIGJlZm9yZSBwcmVjb25kaXRpb24gc2F0 aXNmaWVkLg0KPiANCj4gQ2FzZSAyOiBDaGFuZ2luZyBhdWRpbyBzdHJlYW0ncyBjb2RlYyB3aXRo IHByZWNvbmRpdGlvbiBhbmQgYW5kIA0KPiBhZGRpbmcgdmVkaW8gc3RyZWFtIHdpdGggcHJlY29u ZGl0aW9uLg0KPiBNb2RpZmljYXRpb24gb2YgYXVkaW8gd291bGQgYmUgImluIHVzZSIgb24gdGhl IHBvaW50IG9mIA0KcHJlY29uZGl0aW9uc2F0aXNmaWVkLg0KPiANCj4gQ2FzZSAzOiBBZGRpbmcg dmVkaW8gc3RyZWFtIHdpdGggcHJlY29uZGl0aW9uLCB3aGljaCBuZWVkcyB1c2VyJ3MgDQpkZWNp c2lvbi4NCj4gQXMgaW4gcHJlY29uZGl0b24gdXNlIGNhc2VzLCB1c2VyIG9mIFVBUyBvbmx5IGhh cyB0aGUgY2hhbmNlIHRvIA0KPiBkZWNpZGUgYWNjZXB0aW5nL3JlamVjdGluZyBzZXNzaW9uIG1v ZGlmaWNhdGlvbiBhZnRlciBwcmVjb25kaXRpb24gDQpzYXRpc2ZpZWQuIA0KPiBWZWRpb24gc3Ry ZWFtIHdvdWxkIGJlICJpbiB1c2UiIGFmdGVyIHByZWNvbmRpdGlvbiBzYXRpc2ZpZWQuDQo+IA0K PiBXaGlsZSB1c2luZyBhIG5ldyBVUERBVEUvMjAwT0sgcGFpciBiZWZvcmUgZmluYWwgcmVzcG9u c2Ugb2YgUmUtDQo+IElOVklURSwgdGhlIHRpbWUgcG9pbnQgb2YgImluIHVzZSIgaGFzIG5vIGlt cGFjdCBvbiB0aGUgc2Vzc2lvbiBzdGF0ZS4NCj4gDQo+IFRoYW5rcy4NCj4gDQo+IEdhbw0KPiAN Cj4gLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy9lbmQgb2YgdGhl IG1haWwgZm9yIA0KPiBTaGluamkvLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vDQo+IA0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KPiAgWmlwICAgIDogMjEwMDEyDQo+ICBUZWwgICAgOiA4NzIxMQ0KPiAgVGVsMiAgIDoo Kzg2KS0wMjUtNTI4NzcyMTENCj4gIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuDQo+ID09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQo+IA0KPiBHb256YWxvIENhbWFyaWxs byA8R29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24uY29tPiANCj4gMjAwOS0wNy0yMyAxNTo0Mw0K PiANCj4gytW8/sjLDQo+IA0KPiB3YW5nLmxpYm9AenRlLmNvbS5jbg0KPiANCj4gs63LzQ0KPiAN Cj4gZ2FvLnlhbmcyQHp0ZS5jb20uY24sIFBhdWwgS3l6aXZhdCA8cGt5eml2YXRAY2lzY28uY29t PiwgU0lQQ09SRSANCj4gPHNpcGNvcmVAaWV0Zi5vcmc+LCBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5v cmcNCj4gDQo+INb3zOINCj4gDQo+IFJlOiBbc2lwY29yZV0gTmV3IHJldmlzaW9uIG9mIHRoZSBy ZS1JTlZJVEUgaGFuZGxpbmcgZHJhZnQNCj4gDQo+IEhpLA0KPiANCj4gPiAgIEluIG9yZGVyIHRv IG1ha2UgIkFscmVhZHktZXhlY3V0ZWQgQ2hhbmdlcyIgY2xlYXIsIHRoZSBkcmFmdCBzaG91bGQg DQo+ID4gc3RhdGUgDQo+ID4gd2hlbiBVQVMvVUFDIHN0YXJ0IHRvIGxpc3RlbiBvbiB0aGUgbmV3 IHBvcnQsIGFuZCB3aGVuIFVBUy9VQUMgdXNlIA0KPiA+IG5ldyBtZWRpYSBwYXJhbWV0ZXJzLiBJ dCdzIGVzc2VudGlhbCBmb3IgdXNlcnMgdG8gZmluZCB0aGUgcmlnaHQgDQpzdGF0ZSwgSSANCj4g PiB0aGluay4NCj4gPiANCj4gDQo+IHllcywgaXQgaXMgZXNzZW50aWFsLiBJbiBhbnkgY2FzZSwg dGhlIGRyYWZ0IHdpbGwgbm90IGRlZmluZSBhbnl0aGluZw0KPiBuZXcgaW4gdGhpcyByZXNwZWN0 LiBXZSB3aWxsIHVzZSB0aGUgZGVmaW5pdGlvbiBpbiBSRkMgMzI2NCBhbmQgY2xhcmlmeQ0KPiBp dCBpZiBuZWVkZWQuDQo+IA0KPiBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMsDQo+IA0KPiBHb256 YWxvDQo+IA0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZv cm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUg c2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRl bnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBz ZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2Yg dGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0 cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBm b3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBh ZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNl IG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3Nl ZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRo aXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBB bnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 002FCAF2482575FC_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPmhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Jm5ic3A7ICZuYnNwO1BpdHkgY2FuJ3Qg cmVjZWl2ZSB5b3VyDQptYWlscyBkaXNwYXRjaGVkIGZyb20gdGhlIGxpc3QgPV89ISE8L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyAmbmJzcDtJ IHJlYWQgdGhlIGRyYWZ0IGFnYWluLg0KSXQgc2VlbXMgdGhlIHN0YXRlcyBhcmUgdXNlbGVzcy5J ZiByZS1JTlZJVEUgaXMgYWNjZXB0ZWQsPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJz YW5zLXNlcmlmIj5ldmVyeXRoaW5nIGlzIG9rLkFuZCBpZiByZS1JTlZJVEUgaXMNCnJlamVjdGVk LCBVQUMgZ2VuZXJhdGUgYSBuZXcgcmUtSU5WSVRFIHdpdGggPC9mb250Pg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5vbGQgc3RhdGUsIHRoZXkgZG9uJ3QgbmVlZCB0byBjb25j ZXJuDQphYm91dCB3aGljaCBzdGF0ZSB0aGV5IHdlcmUgYXQuIElzIGl0IHJpZ2h0PzwvZm9udD4N Cjxicj4NCjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9IzAwMjA0MSBmYWNlPSJD b3VyaWVyIE5ldyI+PGI+Ni4gJm5ic3A7VUFDIEJlaGF2aW9yPC9iPjwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDtUaGUgYmVoYXZp b3Igb2YgYSBVQUMNCmNvbW11bmljYXRpbmcgd2l0aCBhIFVBUyB0aGF0IHN1cHBvcnRzIHRoaXM8 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsgJm5ic3A7 c3BlY2lmaWNhdGlvbiAoaS5lLiwgYQ0KVUFTIHRoYXQgZm9sbG93cyB0aGUgZ3VpZGVsaW5lcyBp biBTZWN0aW9uIDUpPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+ Jm5ic3A7ICZuYnNwO2lzIHN0cmFpZ2h0IGZvcndhcmQuICZuYnNwO0hvd2V2ZXIsDQphIFVBQyBt YXkgZmFjZSBhIGxlZ2FjeSBVQVMgdGhhdCB1c2VzPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO2FuIGVycm9yIHJlc3BvbnNlIHRvIHVuZG8N CmFscmVhZHktZXhlY3V0ZWQgY2hhbmdlcyB3aXRoaW4gYSByZS08L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij4mbmJzcDsgJm5ic3A7SU5WSVRFLjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDtJbiBv cmRlciB0byBjb3BlIHdpdGgNCnRoaXMgdHlwZSBvZiBVQVMsPGI+IGEgVUFDIHRoYXQgcmVjZWl2 ZXMgYW4gZXJyb3I8L2I+PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5l dyI+PGI+Jm5ic3A7ICZuYnNwO3Jlc3BvbnNlIHRvIGEgcmUtSU5WSVRFDQpmb3Igd2hpY2ggY2hh bmdlcyBoYXZlIGJlZW4gYWxyZWFkeSBleGVjdXRlZDwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48Yj4mbmJzcDsgJm5ic3A7U0hPVUxEIGdlbmVyYXRlIGEg bmV3DQpyZS1JTlZJVEUgb3IgVVBEQVRFIHJlcXVlc3QgaW4gb3JkZXIgdG8gbWFrZTwvYj48L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3Ij48Yj4mbmJzcDsgJm5ic3A7 c3VyZSB0aGF0IGJvdGggVUFzDQpoYXZlIGEgY29tbW9uIHZpZXcgb2YgdGhlIHN0YXRlIG9mIHRo ZSBzZXNzaW9uLjwvYj48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNvdXJpZXIgTmV3 Ij4mbmJzcDsgJm5ic3A7VGhlIHB1cnBvc2Ugb2YgdGhpcyBuZXcNCm9mZmVyL2Fuc3dlciBleGNo YW5nZSBpcyB0byBzeW5jaHJvbml6ZSBib3RoPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNl PSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO1VBcywgbm90IHRvIHJlcXVlc3QgY2hhbmdlcw0K dGhhdCB0aGUgVUFTIG1heSBjaG9vc2UgdG8gcmVqZWN0LjwvZm9udD4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0iQ291cmllciBOZXciPiZuYnNwOyAmbmJzcDtUaGVyZWZvcmUsIHRoZSBzZXNzaW9u DQpwYXJhbWV0ZXJzIGluIHRoZSBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UgU0hPVUxEPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDb3VyaWVyIE5ldyI+Jm5ic3A7ICZuYnNwO2JlIGFzIGNs b3NlIGFzIHRob3NlIGluDQp0aGUgcHJlLXJlLUlOVklURSBzdGF0ZSBhcyBwb3NzaWJsZS48L2Zv bnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi Pjxicj4NCjwvZm9udD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkdhb1lhbmcxNDAxOTcv dXNlci96dGVfbHRkINC009ogMjAwOS0wNy0yMyAxNjoxMTowNTo8YnI+DQo8YnI+DQomZ3Q7IEhp LDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IEkgYW0g YWdyZWUgd2l0aCBHb256YWxvLiBBbmQgV2FuZyBMaWJvKG15IGNvbGxlYWd1ZSkncyBxdWVzdGlv biBpcw0KPGJyPg0KJmd0OyB0aGUgc2FtZSBhcyBTaGluamkncy4gQWNjZXNzb3J5IGlzIG15IG1h aWwgZm9yIFNoaW5qaShidXQgSSBkb24ndA0KPGJyPg0KJmd0OyBrbm93IHdoeSB0aGlzIG1haWwg d2FzIG5vdCBkaXNwYXRjaGVkIGJ5IG1haWwgbGlzdCkuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgTXkgbWVhbnMgaXMgdGhhdCB0aW1lIHBvaW50IG9m ICZxdW90O2luIHVzZSZxdW90OyBoYXMgbm8gaW1wYWN0IG9uDQp0aGUgPGJyPg0KJmd0OyByYXRp b25hbGl0eSBvZiB0aGUgd2F5KG5ldyBVUERBVEUvMjAwT0spIGhhbmRsaW5nIHNlc3Npb24gc3Rh dGUncw0KPGJyPg0KJmd0OyByb2xsYmFjayBoZXJlLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyBUaGUgcmF0aW9uYWxpdHkgb2YgY2hvb3NlZCBzZXNzaW9uIHN0YXRlIGZv cg0Kcm9sbGJhY2sgaXMgc2VwYXJhdGUgPGJyPg0KJmd0OyBmcm9tIHRoZSB3YXkgcHJvcG9zZWQg YnkgZHJhZnQtY2FtYXJpbGxvLXNpcGNvcmUtcmVpbnZpdGUtMDAuIEl0IGlzDQo8YnI+DQomZ3Q7 IFJGQzMyNjQgY29uY2VybmVkLiBBbmQgYXMgUkZDMzI2NCBkb2VzIG5vdCBjb25zaWRlciBzZXNz aW9uIDxicj4NCiZndDsgbW9kaWZpY2F0aW9uIG92ZXJsYXBzIG1vcmUgdGhhbiBvbmUgTy9BIHBh aXJzLCBzdWNoIGFzIHByZWNvbmRpdGlvbiw8YnI+DQomZ3Q7IHdlIG5lZWQgY2xhcmlmaWNhdGlv biBmb3IgaXQuIEJ1dCBJIHRoaW5rIGl0IGNhbiBiZSBhIHNlcGFyYXRlIHRleHQuPC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgVGhhbmtzLjwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IEdhbzwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IC8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy9tYWlsIGZvciA8YnI+DQomZ3Q7IFNo aW5qaS8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsg SGkgU2hpbmppLDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQom Z3Q7IEFib3V0IG5vbi0yeHggb2YgUmUtSU5WSVRFOjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyBUaGUgd2F5IHByb3Bvc2VkIGluIGRyYWZ0LWNhbWFyaWxsby1zaXBjb3Jl LXJlaW52aXRlLTAwDQppcyA8YnI+DQomZ3Q7ICpmb3JiaWRpbmcqIG5vbi0yeHggb2YgUmUtSU5W SVRFIGFmdGVyIE8vQS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgU28s IHlvdXIgZXhhbXBsZSBpcyBub3QgZXhpc3QgYWxvbmcgdGhlIHdheSBvZg0KZHJhZnQtY2FtYXJp bGxvLTxicj4NCiZndDsgc2lwY29yZS1yZWludml0ZS0wMC4gQW5kIHRoZSBhbHRlcm5hdGl2ZSB3 YXkgZm9yIHJlamVjdGluZyBzZXNzaW4NCjxicj4NCiZndDsgbW9kaWZpY2F0aW9uIGhlcmUgaXMg dXNpbmcgYSBuZXcgVVBEQVRFLzIwME9LICZuYnNwO2JlZm9yZSB0aGUgMnh4DQpvZiBSZS08YnI+ DQomZ3Q7IElOVklURS4gSSB0aGluayBpdCBpcyBlZmZlY3RpdmUgaGVyZS4gV2hhdCdzIHlvdXIg cG9pbnRzPzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7 IEFib3V0ICZxdW90O2luIHVzZSZxdW90Ozo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgPGJyPg0KJmd0OyBUaGUgbWVhbmluZyBvZiAmcXVvdDtpbiB1c2UmcXVvdDsoYXMg ZGVmaW5lZCBpbiBSRkMzMjY0KTogV2hlbiBhbnN3ZXJlcg0Kc2VuZCA8YnI+DQomZ3Q7IG5ldyBt ZWRpYSBzdHJlYW0ob3Igc2VuZCBtZWRpYSB1c2luZyBuZXcgcGFyYW1ldGVycyksIG1lZGlhIGlz ICZxdW90O2luDQo8YnI+DQomZ3Q7IHVzZSZxdW90Oy4gQW5kIGZvciBvZmZlcmVyLCBpdCBjb25z aWRlcnMgdGhlIG5ldyBwYXJhbWV0ZXJzIHRvIGJlDQppbiB1c2UgPGJyPg0KJmd0OyB3aGVuIChu ZXcpIG1lZGlhIGlzIHJlY2VpdmVkIG9yIHVzaW5nIG5ldyBwYXJhbWV0ZXJzLjwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyBTbywgdGhlIG1lYW5pbmcgb2YgJnF1b3Q7aW4g dXNlJnF1b3Q7IGlzIHF1aXQNCmNsZWFyIGhlcmUuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgVGhlIHRpbWUgcG9pbnQgb2YgJnF1b3Q7aW4gdXNlJnF1 b3Q7OiBpdCBpcyBkZXBlbmRlbnQgb24gY2FzZXM6PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgQ2FzZSAxOiBDaGFuZ2luZyBhdWRpbyBzdHJlYW0ncyBj b2RlYyB3aXRob3V0IHByZWNvbmRpdGlvbiBhbmQgPGJyPg0KJmd0OyBhZGRpbmcgdmVkaW8gc3Ry ZWFtIHdpdGggcHJlY29uZGl0aW9uLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jmd0OyBNb2RpZmljYXRpb24gb2YgYXVkaW8gd291bGQgYmUgJnF1b3Q7aW4gdXNlJnF1b3Q7DQpi ZWZvcmUgcHJlY29uZGl0aW9uIHNhdGlzZmllZC48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBDYXNlIDI6IENoYW5naW5nIGF1ZGlvIHN0cmVhbSdzIGNv ZGVjIHdpdGggcHJlY29uZGl0aW9uIGFuZCBhbmQgPGJyPg0KJmd0OyBhZGRpbmcgdmVkaW8gc3Ry ZWFtIHdpdGggcHJlY29uZGl0aW9uLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jmd0OyBNb2RpZmljYXRpb24gb2YgYXVkaW8gd291bGQgYmUgJnF1b3Q7aW4gdXNlJnF1b3Q7DQpv biB0aGUgcG9pbnQgb2YgcHJlY29uZGl0aW9uc2F0aXNmaWVkLjwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IENhc2UgMzogQWRkaW5nIHZlZGlvIHN0cmVh bSB3aXRoIHByZWNvbmRpdGlvbiwgd2hpY2ggbmVlZHMgdXNlcidzDQpkZWNpc2lvbi48L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgQXMgaW4gcHJlY29uZGl0b24gdXNlIGNh c2VzLCB1c2VyIG9mIFVBUyBvbmx5DQpoYXMgdGhlIGNoYW5jZSB0byA8YnI+DQomZ3Q7IGRlY2lk ZSBhY2NlcHRpbmcvcmVqZWN0aW5nIHNlc3Npb24gbW9kaWZpY2F0aW9uIGFmdGVyIHByZWNvbmRp dGlvbg0Kc2F0aXNmaWVkLiA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg VmVkaW9uIHN0cmVhbSB3b3VsZCBiZSAmcXVvdDtpbiB1c2UmcXVvdDsgYWZ0ZXINCnByZWNvbmRp dGlvbiBzYXRpc2ZpZWQuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxi cj4NCiZndDsgV2hpbGUgdXNpbmcgYSBuZXcgVVBEQVRFLzIwME9LIHBhaXIgYmVmb3JlIGZpbmFs IHJlc3BvbnNlIG9mIFJlLTxicj4NCiZndDsgSU5WSVRFLCB0aGUgdGltZSBwb2ludCBvZiAmcXVv dDtpbiB1c2UmcXVvdDsgaGFzIG5vIGltcGFjdCBvbiB0aGUNCnNlc3Npb24gc3RhdGUuPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgVGhhbmtzLjwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IEdhbzwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IC8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vZW5kIG9mIHRoZSBtYWlsIGZvciA8YnI+DQom Z3Q7IFNoaW5qaS8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy88L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0 OyA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCiZndDsgJm5ic3A7Wmlw ICZuYnNwOyAmbmJzcDs6IDIxMDAxMjxicj4NCiZndDsgJm5ic3A7VGVsICZuYnNwOyAmbmJzcDs6 IDg3MjExPGJyPg0KJmd0OyAmbmJzcDtUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3MjExPGJy Pg0KJmd0OyAmbmJzcDtlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbjxicj4NCiZndDsgPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBHb256YWxvIENhbWFyaWxsbyAmbHQ7R29uemFsby5D YW1hcmlsbG9AZXJpY3Nzb24uY29tJmd0OyA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgMjAwOS0wNy0yMyAxNTo0MzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyA8YnI+DQomZ3Q7IMrVvP7IyzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyA8YnI+DQomZ3Q7IHdhbmcubGlib0B6dGUuY29tLmNuPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgs63LzTwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IGdhby55YW5nMkB6dGUuY29tLmNuLCBQYXVs IEt5eml2YXQgJmx0O3BreXppdmF0QGNpc2NvLmNvbSZndDssIFNJUENPUkUNCjxicj4NCiZndDsg Jmx0O3NpcGNvcmVAaWV0Zi5vcmcmZ3Q7LCBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyDW98ziPC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgUmU6IFtzaXBjb3JlXSBO ZXcgcmV2aXNpb24gb2YgdGhlIHJlLUlOVklURSBoYW5kbGluZyBkcmFmdDwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IEhpLDxicj4NCiZndDsgPGJyPg0K Jmd0OyAmZ3Q7ICZuYnNwOyBJbiBvcmRlciB0byBtYWtlICZxdW90O0FscmVhZHktZXhlY3V0ZWQg Q2hhbmdlcyZxdW90Ow0KY2xlYXIsIHRoZSBkcmFmdCBzaG91bGQgPGJyPg0KJmd0OyAmZ3Q7IHN0 YXRlIDxicj4NCiZndDsgJmd0OyB3aGVuIFVBUy9VQUMgc3RhcnQgdG8gbGlzdGVuIG9uIHRoZSBu ZXcgcG9ydCwgYW5kIHdoZW4gVUFTL1VBQw0KdXNlIDxicj4NCiZndDsgJmd0OyBuZXcgbWVkaWEg cGFyYW1ldGVycy4gSXQncyBlc3NlbnRpYWwgZm9yIHVzZXJzIHRvIGZpbmQgdGhlIHJpZ2h0DQpz dGF0ZSwgSSA8YnI+DQomZ3Q7ICZndDsgdGhpbmsuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsg PGJyPg0KJmd0OyB5ZXMsIGl0IGlzIGVzc2VudGlhbC4gSW4gYW55IGNhc2UsIHRoZSBkcmFmdCB3 aWxsIG5vdCBkZWZpbmUgYW55dGhpbmc8YnI+DQomZ3Q7IG5ldyBpbiB0aGlzIHJlc3BlY3QuIFdl IHdpbGwgdXNlIHRoZSBkZWZpbml0aW9uIGluIFJGQyAzMjY0IGFuZCBjbGFyaWZ5PGJyPg0KJmd0 OyBpdCBpZiBuZWVkZWQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5rcyBmb3IgeW91ciBjb21t ZW50cyw8YnI+DQomZ3Q7IDxicj4NCiZndDsgR29uemFsbzxicj4NCiZndDsgPGJyPg0KPC9mb250 PjwvdHQ+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5i c3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7 aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkm bmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1Ro aXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFs LiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2Js aWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDth cmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhl Jm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7 dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtm aWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29u ZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJz cDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZu YnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRy ZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlz Jm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5i c3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJz cDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21l c3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVh bCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNw O3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5 Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 002FCAF2482575FC_=-- From pkyzivat@cisco.com Thu Jul 23 06:13:22 2009 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 DA2453A6A86 for ; Thu, 23 Jul 2009 06:13:22 -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=[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 BtOxxKiGJN7S for ; Thu, 23 Jul 2009 06:13:21 -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 91D123A67B2 for ; Thu, 23 Jul 2009 06:13:21 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEP+Z0qrR7PD/2dsb2JhbAC3fIglkQoFhA0 X-IronPort-AV: E=Sophos;i="4.43,254,1246838400"; d="scan'208";a="352439644" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 23 Jul 2009 13:12:47 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6NDClc5020650; Thu, 23 Jul 2009 06:12:47 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6NDCi4E010006; Thu, 23 Jul 2009 13:12:46 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 09:12:45 -0400 Received: from [10.86.250.172] ([10.86.250.172]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 09:12:45 -0400 Message-ID: <4A6861CC.5030300@cisco.com> Date: Thu, 23 Jul 2009 09:12:44 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com> <4A66E224.2010900@ericsson.com> In-Reply-To: <4A66E224.2010900@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2009 13:12:45.0601 (UTC) FILETIME=[44D13910:01CA0B97] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=6454; t=1248354767; x=1249218767; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20New=20revision=20of=20the=2 0re-INVITE=20handling=20draft |Sender:=20; bh=nYRLy5v+HHm8oJBUHXBVMtX/9dCWUQax3jaXByNm0IA=; b=Vc/swKRUThVVZc6Q/Hhi9F1iQEAcLXioNfvbHwWnVvW5+cKQ9PZEnI0RqF 9mmn74xOA/yGZt7uY5ERXS8dQBG+JXIrHbp7gTC76QEouqQliuFchEJg2t3T 8s0nSmOus9; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 23 Jul 2009 13:13:22 -0000 Gonzalo, I agree with all you say below, except at the very end about target refresh. If target refreshes are to be accepted even if the request fails, then it is possible to hijack a session even if authentication is being used for signaling. IMO a target refresh must be ignored in at least *some* cases when the request is rejected. We could enumerate these cases individually, or simply state that it will only be accepted if the request is accepted. (In case of reINVITE, that would be if it was accepted sufficiently to return a 2xx or a 1xx.) This will encourage using a *simple* request to do an essential target refresh, rather than a complex one that has a chance of failing. Perhaps it won't work in all cases, but such is life. Thanks, Paul Gonzalo Camarillo wrote: > Hi Paul, > > thanks for your comments. Answers inline: > > Paul Kyzivat wrote: >> Gonzalo, >> >> Thanks for doing this work! I do have some comments: >> >> Section 3/Figure 1 >> >> The figure shows a 6xx response. >> The text says that the UAS wants to reject the new offer. >> >> A UAS would probably not use a 6xx response to reject media. >> (I guess it might use 606, but 488 would be more appropriate.) >> In fact, it probably would not reject the request at all, but rather >> would just refuse the added media stream. >> >> The point being made doesn't require that the response be 6xx or that >> it be with the purpose of refusing the media. So I think what is >> needed here is to find a plausible example to make the point. >> >> A good one for the purpose here might be a 488 to reject the media, or >> a 401 response as another sort of reason for rejecting the whole >> thing but wanting to preserve what there is. > > yes, I agree that a 488 response would be more appropriate. I will > change that in the draft. > >> >> Section 5: >> >>> A change to the session state is considered to have been executed >>> when the new media parameters are being used. Therefore, a change to >>> a stream subject to preconditions [RFC4032] is considered to have >>> been executed when the new media parameters start being used; not >>> when the preconditions for the stream are met. Unsurprisingly, the >>> UAS considers the new parameters to be in use when it actually starts >>> using them. >> >> I'm not entirely following this. I think there may be an assumption >> here that the UAC is the offerer and the UAS the answerer. I'm >> guessing you are saying that the answerer considers the new parameters >> to be in use when it actually starts using them. >> >> Since this section is about the UAS (for the reinvite), this point is >> probably that when the UAS is also the answerer it can decide when the >> new media is in use based on when it starts using them. >> >> But what happens when the UAS is the offerer? In that case I think it >> must assume the media is in use as soon as it is offered. But maybe >> that isn't always the case with preconditions. I don't think it can >> wait till it receives media, because media may be in flight when it >> makes its decision. > > yes, the draft assumes that the UAS is the answerer because that was the > use case being discussed originally. However, you are right that we > should also cover the case where the UAS is the offerer. I will look > into it and add text about it in the draft. > >> >>> As described in Section 8.3.1 of RFC 3264 [RFC3264], the >>> UAC considers the new parameters to be in use when media is received >>> in the new port, which should be interpreted as follows: >>> >>> Received, in this case, means that the media is passed to a media >>> sink. This means that if there is a playout buffer, the agent >>> would continue to listen on the old port until the media on the >>> new port reached the top of the playout buffer. At that time, it >>> MAY cease listening for media on the old port. >> >> I don't know what the above has to do with the behavior of the UAS. > > The UAC needs to know when the new parameters are in use in order to > implement the normative behavior in Section 6: > > ... a UAC that receives an error response to a re-INVITE for which > changes have been already executed ... > > In any case, I will clarify all this when I write the text about the UAS > being the offerer because this type of behavior has to do with being the > offerer or the answerer, not the UAC or the UAS. > > >>> 9. Clarifications on Target Refresh Requests > > the current text is a straw man that puts target refreshes in the same > category as any other change. The other option we talked about in the > past was to special case them so that they are treated differently. You > seem to like the latter option better. What do you think about the > following text? > > >
anchor="sec-atom"> > > The remote target of a dialog is a special type of state information > because of its essential role in the exchange of SIP messages between > UAs in a dialog. A UA involved in a dialog receives the remote target > of the dialog from the remote UA. The UA uses the remote target to > send SIP requests to the remote UA. > > > The remote target is a piece of state information that is not meant to > be negotiated. When a UAC changes its address, the UAC simply > communicates its new address to the UAS in order to remain reachable > by the UAS. As described in , a UAS > starts using the new remote target as soon as the target refresh > request is received, regardless of the response the UAS generates to > that request. That is, even if the UAS generates an error response to > the target refresh request, the UAS needs to update the dialog's > remote target URI. > > > The fact that a target refresh request updates the remote target > regardless of the response it triggers implies that target refresh > requests are not atomic. That is, an error response to a target > refresh request will keep all changes associated to the request from > being performed except for the refresh of the remote target, which > will be performed anyway. > >
> > > Cheers, > > Gonzalo > From pkyzivat@cisco.com Thu Jul 23 06:23:58 2009 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 271B53A68E7 for ; Thu, 23 Jul 2009 06:23:58 -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=[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 19uYa-6jCbVk for ; Thu, 23 Jul 2009 06:23:57 -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 0AE093A67B3 for ; Thu, 23 Jul 2009 06:23:39 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEACABaEpAZnmf/2dsb2JhbAC4N4glkQwFhA0 X-IronPort-AV: E=Sophos;i="4.43,254,1246838400"; d="scan'208";a="51535594" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-1.cisco.com with ESMTP; 23 Jul 2009 13:22:04 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6NDM4SD020089; Thu, 23 Jul 2009 09:22:04 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6NDM4qR005772; Thu, 23 Jul 2009 13:22:04 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 09:22:04 -0400 Received: from [10.86.250.172] ([10.86.250.172]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 09:22:04 -0400 Message-ID: <4A6863FB.6070509@cisco.com> Date: Thu, 23 Jul 2009 09:22:03 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Hans Erik van Elburg References: <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3616@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F1A339E@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3667@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0022A39CE@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F201CE4@zrc2hxm0.corp.nortel.com> <9ae56b1e0907230104u3957a145mcac1f1445b796d1b@mail.gmail.com> In-Reply-To: <9ae56b1e0907230104u3957a145mcac1f1445b796d1b@mail.gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2009 13:22:04.0234 (UTC) FILETIME=[91C9DAA0:01CA0B98] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2003; t=1248355324; x=1249219324; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20draft-barnes-sipcore-rfc424 4bis=20&=20target-URI=3A=20Summary=0A=20of=20where=20we=20ar e |Sender:=20 |To:=20Hans=20Erik=20van=20Elburg=20; bh=lNOvj3Bp+zX23vfvIjKuni8AlRUpaCt1ESBqzExktUI=; b=IKGupLXq9TFVThc+EHHDw4Wx5nLqIXdxds0YJDy12I6+qfnHHMVSvap+mz /Lvx7XIZu5pole/HYRw5jvvxVNZOmoIxRKKyAv/8Nh/HukQ7XTw9ZnYnLjv6 vx4NhCw7Nl; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: SIPCORE Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summary of where we are 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, 23 Jul 2009 13:23:58 -0000 Hans Erik van Elburg wrote: > As said before the algorithms for a UAS are very clear. > > To retrieve the addressed target (freephone, etc) (Main thing that > target-uri draft was after.): > - traverse all H-I entries backward until an "mp" entry is found, if > found this is the addressed target > - if no "mp" found take the first H-I entry > - if no History-Info header take the Request-URI value > > To retrieve the last aor before it was overwritten by contact > address (similar as P-Called-Party-ID): > - traverse all H-I entries backward until an "aor" entry is found, if > found this is the last AOR used > > Both values can be the same in a lot of situations. But they will not > always be. I'm confused here. IIUC there has been a change to that the 'mp' tag marks the "mapped to" URI rather than the "mapped from" URI. If so then I don't see how the two are likely to be interchangable in many if any cases. If 'mp' marks the "mapped from" URI then I guess there would be a lot of equivalence. Thanks, Paul > /Hans Erik van Elburg > > > On Thu, Jul 23, 2009 at 6:57 AM, Francois Audet > wrote: > > target-URI algorithm for UAS: > > There were some questions on the list about algorithms for > picking > the "target URI parameter: is it the last "mp"-marked tag or > is it > the last "aor" tag. It seems that the answer to this question may > be different based on what the assumptions people have about what > is in fact a "target URI". It is not clear if we need to describe > this in the draft, or even indeed if it actually makes a > difference. > > > > ------------------------------------------------------------------------ > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From wang.libo@zte.com.cn Thu Jul 23 06:32:36 2009 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 D0E253A69F2 for ; Thu, 23 Jul 2009 06:32:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.938 X-Spam-Level: X-Spam-Status: No, score=-94.938 tagged_above=-999 required=5 tests=[AWL=-4.548, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, J_CHICKENPOX_42=0.6, J_CHICKENPOX_62=0.6, J_CHICKENPOX_63=0.6, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 o9qByyoQoL7W for ; Thu, 23 Jul 2009 06:32:35 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 5B7EC3A672F for ; Thu, 23 Jul 2009 06:32:34 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 91101727820181; Thu, 23 Jul 2009 19:47:32 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 85804.3579431720; Thu, 23 Jul 2009 19:24:35 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n6NBVtw5039261; Thu, 23 Jul 2009 19:31:56 +0800 (CST) (envelope-from wang.libo@zte.com.cn) In-Reply-To: To: gao.yang2@zte.com.cn MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.2 September 26, 2006 Message-ID: From: wang.libo@zte.com.cn Date: Thu, 23 Jul 2009 19:31:39 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-23 19:31:43, Serialize complete at 2009-07-23 19:31:43 Content-Type: multipart/alternative; boundary="=_alternative 003EF366482575FC_=" X-MAIL: mse1.zte.com.cn n6NBVtw5039261 Cc: sipcore-bounces@ietf.org, SIPCORE , OKUMURA Shinji Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ICBOZXcgcmV2aXNpb24gb2YgdGhlIHJl?= =?gb2312?b?LUlOVklURSBoYW5kbGluZyBkcmFmdA==?= 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, 23 Jul 2009 13:32:36 -0000 This is a multipart message in MIME format. --=_alternative 003EF366482575FC_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGmjrA0KDQogIEl0IHNlZW1zIHRoYXQgY2xlYXIgZGVmaW5pdGlvbiBvZiAibGVnYWN5IFVBUyIg aXMgbmVjZXNzYXJ5IHRvby4NCg0KQWxzbywgaWYgdGhlIFVBQyBzZW5kcyBhIHJlLUlOVklURSB3 aXRoIFNEUCB0aGF0IGlzICJzZW5kb25seSIsDQpkb2VzIHRoZSBVQUMgaGF2ZSBydWxlcyB0byBk ZXRlcm1pbmUgd2hldGhlciB0aGUgVUFTIHVzZSB0aGUgbmV3IA0KcGFyYW10ZXJzLCANCm9yIG5v dD8NCg0KUmVnYXJkcywNCkVyaWMNCg0KDQoNCg0KR2FvWWFuZzE0MDE5Ny91c2VyL3p0ZV9sdGQg 0LTT2iAyMDA5LTA3LTIzIDE3OjExOjU2Og0KDQo+IEhpLA0KPiANCj4gSSBkb24ndCBrbm93IHdh eSBtYWlsIGxpc3QncyAqc29tZXRpbWVzKiBoYXMgcHJvYmxlbSBpbiBkaXNwYWN0aW5nIG15IA0K bWFpbC4NCj4gDQo+IEZvciB5b3VyIHF1ZXN0aW9uOg0KPiANCj4gSW4gZmFjdCwgdGhpcyBpcyBh IGJhY2t3b3JkLWNvbXBhdGlibGUgcHJvYmxlbS4gQW5kIElNT6OsaXQgZ2l2ZXMgDQo+IG91dCBh IHdheSB0byBzeW5jaHJvbml6ZSBzZXNzaW9uIHN0YXRlIGZvciBVQUMgYW5kIFVBUy4gV2hpY2gg DQo+IHNlc3Npb24gc3RhdGUgZm9yIHN5bmNocm9uaXphdGlvbiBpcyBwcm9wZXIgY2FuIGJlIGRl ZHVjZWQgZnJvbSANCj4gbWVkaWEgc3RyZWFtcyAqaW4gdXNlKi4gU28sIHRoaXMgaXMgdGhlIHNh bWUgcXVlc3Rpb24gYXMgKmluIHVzZSogDQpkZWZpbml0aW9uLg0KPiANCj4gVGhhbmtzLg0KPiAN Cj4gR2FvDQo+IA0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiAgWmlw ICAgIDogMjEwMDEyDQo+ICBUZWwgICAgOiA4NzIxMQ0KPiAgVGVsMiAgIDooKzg2KS0wMjUtNTI4 NzcyMTENCj4gIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuDQo+ID09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09DQo+IA0KPiBXYW5nTGlCbzEzNTY4MS91c2VyL3p0ZV9sdGQN Cj4gMjAwOS0wNy0yMyAxNjo0Ng0KPiANCj4gytW8/sjLDQo+IA0KPiBHYW9ZYW5nMTQwMTk3L3Vz ZXIvenRlX2x0ZEB6dGVfbHRkDQo+IA0KPiCzrcvNDQo+IA0KPiBHb256YWxvIENhbWFyaWxsbyA8 R29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24uY29tPiwgUGF1bCBLeXppdmF0IA0KPiA8cGt5eml2 YXRAY2lzY28uY29tPiwgT0tVTVVSQSBTaGluamkgPHNoaW5Ac29mdGZyb250LmNvLmpwPiwgU0lQ Q09SRQ0KPiA8c2lwY29yZUBpZXRmLm9yZz4sIHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZw0KPiAN Cj4g1vfM4g0KPiANCj4gtPC4tDogUmU6IFtzaXBjb3JlXSBOZXcgcmV2aXNpb24gb2YgdGhlIHJl LUlOVklURSBoYW5kbGluZyBkcmFmdA0KPiANCj4gaGksDQo+IA0KPiAgICBQaXR5IGNhbid0IHJl Y2VpdmUgeW91ciBtYWlscyBkaXNwYXRjaGVkIGZyb20gdGhlIGxpc3QgPV89ISENCj4gDQo+ICAg IEkgcmVhZCB0aGUgZHJhZnQgYWdhaW4uIEl0IHNlZW1zIHRoZSBzdGF0ZXMgYXJlIHVzZWxlc3Mu SWYgcmUtDQo+IElOVklURSBpcyBhY2NlcHRlZCwNCj4gZXZlcnl0aGluZyBpcyBvay5BbmQgaWYg cmUtSU5WSVRFIGlzIHJlamVjdGVkLCBVQUMgZ2VuZXJhdGUgYSBuZXcgDQo+IHJlLUlOVklURSB3 aXRoIA0KPiBvbGQgc3RhdGUsIHRoZXkgZG9uJ3QgbmVlZCB0byBjb25jZXJuIGFib3V0IHdoaWNo IHN0YXRlIHRoZXkgd2VyZSANCj4gYXQuIElzIGl0IHJpZ2h0Pw0KPiANCj4gNi4gIFVBQyBCZWhh dmlvcg0KPiANCj4gICAgVGhlIGJlaGF2aW9yIG9mIGEgVUFDIGNvbW11bmljYXRpbmcgd2l0aCBh IFVBUyB0aGF0IHN1cHBvcnRzIHRoaXMNCj4gICAgc3BlY2lmaWNhdGlvbiAoaS5lLiwgYSBVQVMg dGhhdCBmb2xsb3dzIHRoZSBndWlkZWxpbmVzIGluIFNlY3Rpb24gNSkNCj4gICAgaXMgc3RyYWln aHQgZm9yd2FyZC4gIEhvd2V2ZXIsIGEgVUFDIG1heSBmYWNlIGEgbGVnYWN5IFVBUyB0aGF0IHVz ZXMNCj4gICAgYW4gZXJyb3IgcmVzcG9uc2UgdG8gdW5kbyBhbHJlYWR5LWV4ZWN1dGVkIGNoYW5n ZXMgd2l0aGluIGEgcmUtDQo+ICAgIElOVklURS4NCj4gDQo+ICAgIEluIG9yZGVyIHRvIGNvcGUg d2l0aCB0aGlzIHR5cGUgb2YgVUFTLCBhIFVBQyB0aGF0IHJlY2VpdmVzIGFuIGVycm9yDQo+ICAg IHJlc3BvbnNlIHRvIGEgcmUtSU5WSVRFIGZvciB3aGljaCBjaGFuZ2VzIGhhdmUgYmVlbiBhbHJl YWR5IGV4ZWN1dGVkDQo+ICAgIFNIT1VMRCBnZW5lcmF0ZSBhIG5ldyByZS1JTlZJVEUgb3IgVVBE QVRFIHJlcXVlc3QgaW4gb3JkZXIgdG8gbWFrZQ0KPiAgICBzdXJlIHRoYXQgYm90aCBVQXMgaGF2 ZSBhIGNvbW1vbiB2aWV3IG9mIHRoZSBzdGF0ZSBvZiB0aGUgc2Vzc2lvbi4NCj4gICAgVGhlIHB1 cnBvc2Ugb2YgdGhpcyBuZXcgb2ZmZXIvYW5zd2VyIGV4Y2hhbmdlIGlzIHRvIHN5bmNocm9uaXpl IGJvdGgNCj4gICAgVUFzLCBub3QgdG8gcmVxdWVzdCBjaGFuZ2VzIHRoYXQgdGhlIFVBUyBtYXkg Y2hvb3NlIHRvIHJlamVjdC4NCj4gICAgVGhlcmVmb3JlLCB0aGUgc2Vzc2lvbiBwYXJhbWV0ZXJz IGluIHRoZSBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UgU0hPVUxEDQo+ICAgIGJlIGFzIGNsb3NlIGFz IHRob3NlIGluIHRoZSBwcmUtcmUtSU5WSVRFIHN0YXRlIGFzIHBvc3NpYmxlLg0KPiANCj4gDQoN Cj4gDQo+IEdhb1lhbmcxNDAxOTcvdXNlci96dGVfbHRkINC009ogMjAwOS0wNy0yMyAxNjoxMTow NToNCj4gDQo+ID4gSGksDQo+ID4gDQo+ID4gSSBhbSBhZ3JlZSB3aXRoIEdvbnphbG8uIEFuZCBX YW5nIExpYm8obXkgY29sbGVhZ3VlKSdzIHF1ZXN0aW9uIGlzIA0KPiA+IHRoZSBzYW1lIGFzIFNo aW5qaSdzLiBBY2Nlc3NvcnkgaXMgbXkgbWFpbCBmb3IgU2hpbmppKGJ1dCBJIGRvbid0IA0KPiA+ IGtub3cgd2h5IHRoaXMgbWFpbCB3YXMgbm90IGRpc3BhdGNoZWQgYnkgbWFpbCBsaXN0KS4NCj4g PiANCj4gPiBNeSBtZWFucyBpcyB0aGF0IHRpbWUgcG9pbnQgb2YgImluIHVzZSIgaGFzIG5vIGlt cGFjdCBvbiB0aGUgDQo+ID4gcmF0aW9uYWxpdHkgb2YgdGhlIHdheShuZXcgVVBEQVRFLzIwME9L KSBoYW5kbGluZyBzZXNzaW9uIHN0YXRlJ3MgDQo+ID4gcm9sbGJhY2sgaGVyZS4NCj4gPiBUaGUg cmF0aW9uYWxpdHkgb2YgY2hvb3NlZCBzZXNzaW9uIHN0YXRlIGZvciByb2xsYmFjayBpcyBzZXBh cmF0ZSANCj4gPiBmcm9tIHRoZSB3YXkgcHJvcG9zZWQgYnkgZHJhZnQtY2FtYXJpbGxvLXNpcGNv cmUtcmVpbnZpdGUtMDAuIEl0IGlzIA0KPiA+IFJGQzMyNjQgY29uY2VybmVkLiBBbmQgYXMgUkZD MzI2NCBkb2VzIG5vdCBjb25zaWRlciBzZXNzaW9uIA0KPiA+IG1vZGlmaWNhdGlvbiBvdmVybGFw cyBtb3JlIHRoYW4gb25lIE8vQSBwYWlycywgc3VjaCBhcyBwcmVjb25kaXRpb24sDQo+ID4gd2Ug bmVlZCBjbGFyaWZpY2F0aW9uIGZvciBpdC4gQnV0IEkgdGhpbmsgaXQgY2FuIGJlIGEgc2VwYXJh dGUgdGV4dC4NCj4gPiANCj4gPiBUaGFua3MuDQo+ID4gDQo+ID4gR2FvDQo+ID4gDQo+ID4gLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vL21haWwgZm9y IA0KPiA+IFNoaW5qaS8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vDQo+ID4gDQo+ID4gSGkgU2hpbmppLA0KPiA+IA0KPiA+IEFib3V0IG5v bi0yeHggb2YgUmUtSU5WSVRFOg0KPiA+IFRoZSB3YXkgcHJvcG9zZWQgaW4gZHJhZnQtY2FtYXJp bGxvLXNpcGNvcmUtcmVpbnZpdGUtMDAgaXMgDQo+ID4gKmZvcmJpZGluZyogbm9uLTJ4eCBvZiBS ZS1JTlZJVEUgYWZ0ZXIgTy9BLg0KPiA+IFNvLCB5b3VyIGV4YW1wbGUgaXMgbm90IGV4aXN0IGFs b25nIHRoZSB3YXkgb2YgZHJhZnQtY2FtYXJpbGxvLQ0KPiA+IHNpcGNvcmUtcmVpbnZpdGUtMDAu IEFuZCB0aGUgYWx0ZXJuYXRpdmUgd2F5IGZvciByZWplY3Rpbmcgc2Vzc2luIA0KPiA+IG1vZGlm aWNhdGlvbiBoZXJlIGlzIHVzaW5nIGEgbmV3IFVQREFURS8yMDBPSyAgYmVmb3JlIHRoZSAyeHgg b2YgUmUtDQo+ID4gSU5WSVRFLiBJIHRoaW5rIGl0IGlzIGVmZmVjdGl2ZSBoZXJlLiBXaGF0J3Mg eW91ciBwb2ludHM/DQo+ID4gDQo+ID4gQWJvdXQgImluIHVzZSI6DQo+ID4gDQo+ID4gVGhlIG1l YW5pbmcgb2YgImluIHVzZSIoYXMgZGVmaW5lZCBpbiBSRkMzMjY0KTogV2hlbiBhbnN3ZXJlciBz ZW5kIA0KPiA+IG5ldyBtZWRpYSBzdHJlYW0ob3Igc2VuZCBtZWRpYSB1c2luZyBuZXcgcGFyYW1l dGVycyksIG1lZGlhIGlzICJpbiANCj4gPiB1c2UiLiBBbmQgZm9yIG9mZmVyZXIsIGl0IGNvbnNp ZGVycyB0aGUgbmV3IHBhcmFtZXRlcnMgdG8gYmUgaW4gdXNlIA0KPiA+IHdoZW4gKG5ldykgbWVk aWEgaXMgcmVjZWl2ZWQgb3IgdXNpbmcgbmV3IHBhcmFtZXRlcnMuDQo+ID4gU28sIHRoZSBtZWFu aW5nIG9mICJpbiB1c2UiIGlzIHF1aXQgY2xlYXIgaGVyZS4NCj4gPiANCj4gPiBUaGUgdGltZSBw b2ludCBvZiAiaW4gdXNlIjogaXQgaXMgZGVwZW5kZW50IG9uIGNhc2VzOg0KPiA+IA0KPiA+IENh c2UgMTogQ2hhbmdpbmcgYXVkaW8gc3RyZWFtJ3MgY29kZWMgd2l0aG91dCBwcmVjb25kaXRpb24g YW5kIA0KPiA+IGFkZGluZyB2ZWRpbyBzdHJlYW0gd2l0aCBwcmVjb25kaXRpb24uDQo+ID4gTW9k aWZpY2F0aW9uIG9mIGF1ZGlvIHdvdWxkIGJlICJpbiB1c2UiIGJlZm9yZSBwcmVjb25kaXRpb24g c2F0aXNmaWVkLg0KPiA+IA0KPiA+IENhc2UgMjogQ2hhbmdpbmcgYXVkaW8gc3RyZWFtJ3MgY29k ZWMgd2l0aCBwcmVjb25kaXRpb24gYW5kIGFuZCANCj4gPiBhZGRpbmcgdmVkaW8gc3RyZWFtIHdp dGggcHJlY29uZGl0aW9uLg0KPiA+IE1vZGlmaWNhdGlvbiBvZiBhdWRpbyB3b3VsZCBiZSAiaW4g dXNlIiBvbiB0aGUgcG9pbnQgb2YgDQo+IHByZWNvbmRpdGlvbnNhdGlzZmllZC4NCj4gPiANCj4g PiBDYXNlIDM6IEFkZGluZyB2ZWRpbyBzdHJlYW0gd2l0aCBwcmVjb25kaXRpb24sIHdoaWNoIG5l ZWRzIHVzZXIncyANCmRlY2lzaW9uLg0KPiA+IEFzIGluIHByZWNvbmRpdG9uIHVzZSBjYXNlcywg dXNlciBvZiBVQVMgb25seSBoYXMgdGhlIGNoYW5jZSB0byANCj4gPiBkZWNpZGUgYWNjZXB0aW5n L3JlamVjdGluZyBzZXNzaW9uIG1vZGlmaWNhdGlvbiBhZnRlciBwcmVjb25kaXRpb24NCj4gc2F0 aXNmaWVkLiANCj4gPiBWZWRpb24gc3RyZWFtIHdvdWxkIGJlICJpbiB1c2UiIGFmdGVyIHByZWNv bmRpdGlvbiBzYXRpc2ZpZWQuDQo+ID4gDQo+ID4gV2hpbGUgdXNpbmcgYSBuZXcgVVBEQVRFLzIw ME9LIHBhaXIgYmVmb3JlIGZpbmFsIHJlc3BvbnNlIG9mIFJlLQ0KPiA+IElOVklURSwgdGhlIHRp bWUgcG9pbnQgb2YgImluIHVzZSIgaGFzIG5vIGltcGFjdCBvbiB0aGUgc2Vzc2lvbiBzdGF0ZS4N Cj4gPiANCj4gPiBUaGFua3MuDQo+ID4gDQo+ID4gR2FvDQo+ID4gDQo+ID4gLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy9lbmQgb2YgdGhlIG1haWwgZm9yIA0KPiA+ IFNoaW5qaS8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8NCj4gPiANCj4gPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiA+ ICBaaXAgICAgOiAyMTAwMTINCj4gPiAgVGVsICAgIDogODcyMTENCj4gPiAgVGVsMiAgIDooKzg2 KS0wMjUtNTI4NzcyMTENCj4gPiAgZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj4gPiA9 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiA+IA0KPiA+IEdvbnphbG8gQ2Ft YXJpbGxvIDxHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb20+IA0KPiA+IDIwMDktMDctMjMg MTU6NDMNCj4gPiANCj4gPiDK1bz+yMsNCj4gPiANCj4gPiB3YW5nLmxpYm9AenRlLmNvbS5jbg0K PiA+IA0KPiA+ILOty80NCj4gPiANCj4gPiBnYW8ueWFuZzJAenRlLmNvbS5jbiwgUGF1bCBLeXpp dmF0IDxwa3l6aXZhdEBjaXNjby5jb20+LCBTSVBDT1JFIA0KPiA+IDxzaXBjb3JlQGlldGYub3Jn Piwgc2lwY29yZS1ib3VuY2VzQGlldGYub3JnDQo+ID4gDQo+ID4g1vfM4g0KPiA+IA0KPiA+IFJl OiBbc2lwY29yZV0gTmV3IHJldmlzaW9uIG9mIHRoZSByZS1JTlZJVEUgaGFuZGxpbmcgZHJhZnQN Cj4gPiANCj4gPiBIaSwNCj4gPiANCj4gPiA+ICAgSW4gb3JkZXIgdG8gbWFrZSAiQWxyZWFkeS1l eGVjdXRlZCBDaGFuZ2VzIiBjbGVhciwgdGhlIGRyYWZ0IA0Kc2hvdWxkIA0KPiA+ID4gc3RhdGUg DQo+ID4gPiB3aGVuIFVBUy9VQUMgc3RhcnQgdG8gbGlzdGVuIG9uIHRoZSBuZXcgcG9ydCwgYW5k IHdoZW4gVUFTL1VBQyB1c2UgDQo+ID4gPiBuZXcgbWVkaWEgcGFyYW1ldGVycy4gSXQncyBlc3Nl bnRpYWwgZm9yIHVzZXJzIHRvIGZpbmQgdGhlIA0KcmlnaHRzdGF0ZSwgSSANCj4gPiA+IHRoaW5r Lg0KPiA+ID4gDQo+ID4gDQo+ID4geWVzLCBpdCBpcyBlc3NlbnRpYWwuIEluIGFueSBjYXNlLCB0 aGUgZHJhZnQgd2lsbCBub3QgZGVmaW5lIGFueXRoaW5nDQo+ID4gbmV3IGluIHRoaXMgcmVzcGVj dC4gV2Ugd2lsbCB1c2UgdGhlIGRlZmluaXRpb24gaW4gUkZDIDMyNjQgYW5kIA0KY2xhcmlmeQ0K PiA+IGl0IGlmIG5lZWRlZC4NCj4gPiANCj4gPiBUaGFua3MgZm9yIHlvdXIgY29tbWVudHMsDQo+ ID4gDQo+ID4gR29uemFsbw0KPiA+IA0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBO b3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBw cm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNh dGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRl ZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0 aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwg YW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGlu dGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8g d2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55 IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlk dWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFu ZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 003EF366482575FC_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpo6w8L2ZvbnQ+DQo8YnI+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZuYnNwOyBJdCBzZWVtcyB0aGF0IGNs ZWFyIGRlZmluaXRpb24NCm9mIDwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPiZxdW90O2xlZ2FjeSBV QVMmcXVvdDsgaXMgbmVjZXNzYXJ5IHRvby48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPkFsc28sIGlmIHRoZSBVQUMgc2VuZHMgYSByZS1JTlZJVEUgd2l0aCBTRFAgdGhh dCBpcw0KJnF1b3Q7c2VuZG9ubHkmcXVvdDssPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj5kb2VzIHRoZSBVQUMgaGF2ZSBydWxlcyB0byBkZXRlcm1pbmUgd2hldGhlciB0aGUgVUFT DQp1c2UgdGhlIG5ldyBwYXJhbXRlcnMsIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+b3Igbm90PzwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+UmVnYXJk cyw8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkVyaWM8L2ZvbnQ+PC90dD4NCjxi cj4NCjxicj4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkdhb1lhbmcxNDAxOTcv dXNlci96dGVfbHRkINC009ogMjAwOS0wNy0yMyAxNzoxMTo1Njo8YnI+DQo8YnI+DQomZ3Q7IEhp LDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IEkgZG9u J3Qga25vdyB3YXkgbWFpbCBsaXN0J3MgKnNvbWV0aW1lcyogaGFzIHByb2JsZW0gaW4gZGlzcGFj dGluZw0KbXkgbWFpbC48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJy Pg0KJmd0OyBGb3IgeW91ciBxdWVzdGlvbjo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6 ZT0yPiZndDsgPGJyPg0KJmd0OyBJbiBmYWN0LCB0aGlzIGlzIGEgYmFja3dvcmQtY29tcGF0aWJs ZSBwcm9ibGVtLiBBbmQgSU1Po6xpdCBnaXZlcw0KPGJyPg0KJmd0OyBvdXQgYSB3YXkgdG8gc3lu Y2hyb25pemUgc2Vzc2lvbiBzdGF0ZSBmb3IgVUFDIGFuZCBVQVMuIFdoaWNoIDxicj4NCiZndDsg c2Vzc2lvbiBzdGF0ZSBmb3Igc3luY2hyb25pemF0aW9uIGlzIHByb3BlciBjYW4gYmUgZGVkdWNl ZCBmcm9tIDxicj4NCiZndDsgbWVkaWEgc3RyZWFtcyAqaW4gdXNlKi4gU28sIHRoaXMgaXMgdGhl IHNhbWUgcXVlc3Rpb24gYXMgKmluIHVzZSoNCmRlZmluaXRpb24uPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgVGhhbmtzLjwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IEdhbzwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ID09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PGJyPg0KJmd0OyAmbmJzcDtaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0K Jmd0OyAmbmJzcDtUZWwgJm5ic3A7ICZuYnNwOzogODcyMTE8YnI+DQomZ3Q7ICZuYnNwO1RlbDIg Jm5ic3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQomZ3Q7ICZuYnNwO2VfbWFpbCA6IGdhby55 YW5nMkB6dGUuY29tLmNuPGJyPg0KJmd0OyA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IFdh bmdMaUJvMTM1NjgxL3VzZXIvenRlX2x0ZDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXpl PTI+Jmd0OyAyMDA5LTA3LTIzIDE2OjQ2PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IDxicj4NCiZndDsgytW8/sjLPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7IDxicj4NCiZndDsgR2FvWWFuZzE0MDE5Ny91c2VyL3p0ZV9sdGRAenRlX2x0ZDwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ILOty808L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyBHb256YWxvIENhbWFy aWxsbyAmbHQ7R29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24uY29tJmd0OywgUGF1bCBLeXppdmF0 DQo8YnI+DQomZ3Q7ICZsdDtwa3l6aXZhdEBjaXNjby5jb20mZ3Q7LCBPS1VNVVJBIFNoaW5qaSAm bHQ7c2hpbkBzb2Z0ZnJvbnQuY28uanAmZ3Q7LA0KU0lQQ09SRTxicj4NCiZndDsgJmx0O3NpcGNv cmVAaWV0Zi5vcmcmZ3Q7LCBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgPGJyPg0KJmd0OyDW98ziPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgtPC4tDogUmU6IFtzaXBjb3JlXSBOZXcg cmV2aXNpb24gb2YgdGhlIHJlLUlOVklURSBoYW5kbGluZyBkcmFmdDwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7IGhpLDwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtQaXR5IGNhbid0IHJl Y2VpdmUgeW91ciBtYWlscyBkaXNwYXRjaGVkIGZyb20gdGhlIGxpc3QNCj1fPSEhPC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO0kg cmVhZCB0aGUgZHJhZnQgYWdhaW4uIEl0IHNlZW1zIHRoZSBzdGF0ZXMgYXJlIHVzZWxlc3MuSWYN CnJlLTxicj4NCiZndDsgSU5WSVRFIGlzIGFjY2VwdGVkLDwvZm9udD48L3R0Pg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+Jmd0OyBldmVyeXRoaW5nIGlzIG9rLkFuZCBpZiByZS1JTlZJVEUgaXMgcmVq ZWN0ZWQsDQpVQUMgZ2VuZXJhdGUgYSBuZXcgPGJyPg0KJmd0OyByZS1JTlZJVEUgd2l0aCA8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgb2xkIHN0YXRlLCB0aGV5IGRvbid0 IG5lZWQgdG8gY29uY2VybiBhYm91dCB3aGljaA0Kc3RhdGUgdGhleSB3ZXJlIDxicj4NCiZndDsg YXQuIElzIGl0IHJpZ2h0PzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyA8 YnI+DQomZ3Q7IDYuICZuYnNwO1VBQyBCZWhhdmlvcjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+Jmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtUaGUgYmVoYXZpb3Igb2YgYSBV QUMgY29tbXVuaWNhdGluZyB3aXRoIGEgVUFTIHRoYXQgc3VwcG9ydHMNCnRoaXM8L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO3NwZWNpZmljYXRpb24g KGkuZS4sIGEgVUFTIHRoYXQNCmZvbGxvd3MgdGhlIGd1aWRlbGluZXMgaW4gU2VjdGlvbiA1KTwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5ic3A7aXMgc3Ry YWlnaHQgZm9yd2FyZC4gJm5ic3A7SG93ZXZlciwNCmEgVUFDIG1heSBmYWNlIGEgbGVnYWN5IFVB UyB0aGF0IHVzZXM8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7 ICZuYnNwO2FuIGVycm9yIHJlc3BvbnNlIHRvIHVuZG8gYWxyZWFkeS1leGVjdXRlZA0KY2hhbmdl cyB3aXRoaW4gYSByZS08L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5i c3A7ICZuYnNwO0lOVklURS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7SW4gb3JkZXIgdG8gY29wZSB3aXRoIHRoaXMgdHlwZSBv ZiBVQVMsIGEgVUFDIHRoYXQgcmVjZWl2ZXMNCmFuIGVycm9yPC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAmbmJzcDtyZXNwb25zZSB0byBhIHJlLUlOVklURSBm b3Igd2hpY2gNCmNoYW5nZXMgaGF2ZSBiZWVuIGFscmVhZHkgZXhlY3V0ZWQ8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO1NIT1VMRCBnZW5lcmF0ZSBh IG5ldyByZS1JTlZJVEUNCm9yIFVQREFURSByZXF1ZXN0IGluIG9yZGVyIHRvIG1ha2U8L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO3N1cmUgdGhhdCBi b3RoIFVBcyBoYXZlIGEgY29tbW9uDQp2aWV3IG9mIHRoZSBzdGF0ZSBvZiB0aGUgc2Vzc2lvbi48 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJm5ic3A7ICZuYnNwO1RoZSBw dXJwb3NlIG9mIHRoaXMgbmV3IG9mZmVyL2Fuc3dlcg0KZXhjaGFuZ2UgaXMgdG8gc3luY2hyb25p emUgYm90aDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmbmJzcDsgJm5i c3A7VUFzLCBub3QgdG8gcmVxdWVzdCBjaGFuZ2VzIHRoYXQNCnRoZSBVQVMgbWF5IGNob29zZSB0 byByZWplY3QuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZuYnNwOyAm bmJzcDtUaGVyZWZvcmUsIHRoZSBzZXNzaW9uIHBhcmFtZXRlcnMNCmluIHRoZSBvZmZlci9hbnN3 ZXIgZXhjaGFuZ2UgU0hPVUxEPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 ICZuYnNwOyAmbmJzcDtiZSBhcyBjbG9zZSBhcyB0aG9zZSBpbiB0aGUgcHJlLXJlLUlOVklURQ0K c3RhdGUgYXMgcG9zc2libGUuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 IDxicj4NCiZndDsgPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 IDxicj4NCiZndDsgR2FvWWFuZzE0MDE5Ny91c2VyL3p0ZV9sdGQg0LTT2iAyMDA5LTA3LTIzIDE2 OjExOjA1Ojxicj4NCiZndDsgPGJyPg0KJmd0OyAmZ3Q7IEhpLDwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBJIGFtIGFncmVlIHdpdGgg R29uemFsby4gQW5kIFdhbmcgTGlibyhteSBjb2xsZWFndWUpJ3MgcXVlc3Rpb24NCmlzIDxicj4N CiZndDsgJmd0OyB0aGUgc2FtZSBhcyBTaGluamkncy4gQWNjZXNzb3J5IGlzIG15IG1haWwgZm9y IFNoaW5qaShidXQgSSBkb24ndA0KPGJyPg0KJmd0OyAmZ3Q7IGtub3cgd2h5IHRoaXMgbWFpbCB3 YXMgbm90IGRpc3BhdGNoZWQgYnkgbWFpbCBsaXN0KS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZv bnQgc2l6ZT0yPiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgTXkgbWVhbnMgaXMgdGhhdCB0aW1l IHBvaW50IG9mICZxdW90O2luIHVzZSZxdW90OyBoYXMgbm8gaW1wYWN0DQpvbiB0aGUgPGJyPg0K Jmd0OyAmZ3Q7IHJhdGlvbmFsaXR5IG9mIHRoZSB3YXkobmV3IFVQREFURS8yMDBPSykgaGFuZGxp bmcgc2Vzc2lvbiBzdGF0ZSdzDQo8YnI+DQomZ3Q7ICZndDsgcm9sbGJhY2sgaGVyZS48L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyBUaGUgcmF0aW9uYWxpdHkgb2Yg Y2hvb3NlZCBzZXNzaW9uIHN0YXRlDQpmb3Igcm9sbGJhY2sgaXMgc2VwYXJhdGUgPGJyPg0KJmd0 OyAmZ3Q7IGZyb20gdGhlIHdheSBwcm9wb3NlZCBieSBkcmFmdC1jYW1hcmlsbG8tc2lwY29yZS1y ZWludml0ZS0wMC4NCkl0IGlzIDxicj4NCiZndDsgJmd0OyBSRkMzMjY0IGNvbmNlcm5lZC4gQW5k IGFzIFJGQzMyNjQgZG9lcyBub3QgY29uc2lkZXIgc2Vzc2lvbiA8YnI+DQomZ3Q7ICZndDsgbW9k aWZpY2F0aW9uIG92ZXJsYXBzIG1vcmUgdGhhbiBvbmUgTy9BIHBhaXJzLCBzdWNoIGFzIHByZWNv bmRpdGlvbiw8YnI+DQomZ3Q7ICZndDsgd2UgbmVlZCBjbGFyaWZpY2F0aW9uIGZvciBpdC4gQnV0 IEkgdGhpbmsgaXQgY2FuIGJlIGEgc2VwYXJhdGUNCnRleHQuPC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoYW5rcy48L2ZvbnQ+PC90 dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgR2FvPC9m b250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7 IC8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy9tYWls IGZvcg0KPGJyPg0KJmd0OyAmZ3Q7IFNoaW5qaS8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEhpIFNoaW5qaSw8L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgQWJvdXQgbm9u LTJ4eCBvZiBSZS1JTlZJVEU6PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7 ICZndDsgVGhlIHdheSBwcm9wb3NlZCBpbiBkcmFmdC1jYW1hcmlsbG8tc2lwY29yZS1yZWludml0 ZS0wMA0KaXMgPGJyPg0KJmd0OyAmZ3Q7ICpmb3JiaWRpbmcqIG5vbi0yeHggb2YgUmUtSU5WSVRF IGFmdGVyIE8vQS48L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyBT bywgeW91ciBleGFtcGxlIGlzIG5vdCBleGlzdCBhbG9uZyB0aGUNCndheSBvZiBkcmFmdC1jYW1h cmlsbG8tPGJyPg0KJmd0OyAmZ3Q7IHNpcGNvcmUtcmVpbnZpdGUtMDAuIEFuZCB0aGUgYWx0ZXJu YXRpdmUgd2F5IGZvciByZWplY3Rpbmcgc2Vzc2luDQo8YnI+DQomZ3Q7ICZndDsgbW9kaWZpY2F0 aW9uIGhlcmUgaXMgdXNpbmcgYSBuZXcgVVBEQVRFLzIwME9LICZuYnNwO2JlZm9yZSB0aGUNCjJ4 eCBvZiBSZS08YnI+DQomZ3Q7ICZndDsgSU5WSVRFLiBJIHRoaW5rIGl0IGlzIGVmZmVjdGl2ZSBo ZXJlLiBXaGF0J3MgeW91ciBwb2ludHM/PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEFib3V0ICZxdW90O2luIHVzZSZxdW90Ozo8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg VGhlIG1lYW5pbmcgb2YgJnF1b3Q7aW4gdXNlJnF1b3Q7KGFzIGRlZmluZWQgaW4gUkZDMzI2NCk6 IFdoZW4NCmFuc3dlcmVyIHNlbmQgPGJyPg0KJmd0OyAmZ3Q7IG5ldyBtZWRpYSBzdHJlYW0ob3Ig c2VuZCBtZWRpYSB1c2luZyBuZXcgcGFyYW1ldGVycyksIG1lZGlhIGlzDQomcXVvdDtpbiA8YnI+ DQomZ3Q7ICZndDsgdXNlJnF1b3Q7LiBBbmQgZm9yIG9mZmVyZXIsIGl0IGNvbnNpZGVycyB0aGUg bmV3IHBhcmFtZXRlcnMgdG8NCmJlIGluIHVzZSA8YnI+DQomZ3Q7ICZndDsgd2hlbiAobmV3KSBt ZWRpYSBpcyByZWNlaXZlZCBvciB1c2luZyBuZXcgcGFyYW1ldGVycy48L2ZvbnQ+PC90dD4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyBTbywgdGhlIG1lYW5pbmcgb2YgJnF1b3Q7aW4g dXNlJnF1b3Q7IGlzDQpxdWl0IGNsZWFyIGhlcmUuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IFRoZSB0aW1lIHBvaW50IG9mICZxdW90 O2luIHVzZSZxdW90OzogaXQgaXMgZGVwZW5kZW50IG9uIGNhc2VzOjwvZm9udD48L3R0Pg0KPGJy Pjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBDYXNlIDE6IENoYW5n aW5nIGF1ZGlvIHN0cmVhbSdzIGNvZGVjIHdpdGhvdXQgcHJlY29uZGl0aW9uIGFuZA0KPGJyPg0K Jmd0OyAmZ3Q7IGFkZGluZyB2ZWRpbyBzdHJlYW0gd2l0aCBwcmVjb25kaXRpb24uPC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZndDsgTW9kaWZpY2F0aW9uIG9mIGF1ZGlv IHdvdWxkIGJlICZxdW90O2luDQp1c2UmcXVvdDsgYmVmb3JlIHByZWNvbmRpdGlvbiBzYXRpc2Zp ZWQuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZndDsgPGJyPg0KJmd0 OyAmZ3Q7IENhc2UgMjogQ2hhbmdpbmcgYXVkaW8gc3RyZWFtJ3MgY29kZWMgd2l0aCBwcmVjb25k aXRpb24gYW5kIGFuZA0KPGJyPg0KJmd0OyAmZ3Q7IGFkZGluZyB2ZWRpbyBzdHJlYW0gd2l0aCBw cmVjb25kaXRpb24uPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZndDsg TW9kaWZpY2F0aW9uIG9mIGF1ZGlvIHdvdWxkIGJlICZxdW90O2luDQp1c2UmcXVvdDsgb24gdGhl IHBvaW50IG9mIDxicj4NCiZndDsgcHJlY29uZGl0aW9uc2F0aXNmaWVkLjwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBDYXNlIDM6IEFk ZGluZyB2ZWRpbyBzdHJlYW0gd2l0aCBwcmVjb25kaXRpb24sIHdoaWNoIG5lZWRzIHVzZXIncw0K ZGVjaXNpb24uPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZndDsgQXMg aW4gcHJlY29uZGl0b24gdXNlIGNhc2VzLCB1c2VyIG9mIFVBUw0Kb25seSBoYXMgdGhlIGNoYW5j ZSB0byA8YnI+DQomZ3Q7ICZndDsgZGVjaWRlIGFjY2VwdGluZy9yZWplY3Rpbmcgc2Vzc2lvbiBt b2RpZmljYXRpb24gYWZ0ZXIgcHJlY29uZGl0aW9uPGJyPg0KJmd0OyBzYXRpc2ZpZWQuIDwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmZ3Q7IFZlZGlvbiBzdHJlYW0gd291 bGQgYmUgJnF1b3Q7aW4gdXNlJnF1b3Q7DQphZnRlciBwcmVjb25kaXRpb24gc2F0aXNmaWVkLjwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0 OyBXaGlsZSB1c2luZyBhIG5ldyBVUERBVEUvMjAwT0sgcGFpciBiZWZvcmUgZmluYWwgcmVzcG9u c2Ugb2YNClJlLTxicj4NCiZndDsgJmd0OyBJTlZJVEUsIHRoZSB0aW1lIHBvaW50IG9mICZxdW90 O2luIHVzZSZxdW90OyBoYXMgbm8gaW1wYWN0IG9uDQp0aGUgc2Vzc2lvbiBzdGF0ZS48L2ZvbnQ+ PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgVGhh bmtzLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmZ3Q7IDxicj4NCiZn dDsgJmd0OyBHYW88L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyA8 YnI+DQomZ3Q7ICZndDsgLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8v Ly9lbmQgb2YgdGhlIG1haWwgZm9yDQo8YnI+DQomZ3Q7ICZndDsgU2hpbmppLy8vLy8vLy8vLy8v Ly8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLy8vLzwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyA9PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4NCiZndDsgJmd0OyAmbmJzcDtaaXAgJm5ic3A7 ICZuYnNwOzogMjEwMDEyPGJyPg0KJmd0OyAmZ3Q7ICZuYnNwO1RlbCAmbmJzcDsgJm5ic3A7OiA4 NzIxMTxicj4NCiZndDsgJmd0OyAmbmJzcDtUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3MjEx PGJyPg0KJmd0OyAmZ3Q7ICZuYnNwO2VfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0K Jmd0OyAmZ3Q7ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9mb250PjwvdHQ+ DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEdvbnphbG8g Q2FtYXJpbGxvICZsdDtHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb20mZ3Q7IDwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0OyAmZ3Q7IDIwMDktMDctMjMgMTU6NDM8L2Zv bnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsg ytW8/sjLPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZndDsgPGJyPg0K Jmd0OyAmZ3Q7IHdhbmcubGlib0B6dGUuY29tLmNuPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj4mZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7ILOty808L2ZvbnQ+PC90dD4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPiZndDsgJmd0OyA8YnI+DQomZ3Q7ICZndDsgZ2FvLnlhbmcyQHp0ZS5j b20uY24sIFBhdWwgS3l6aXZhdCAmbHQ7cGt5eml2YXRAY2lzY28uY29tJmd0OywNClNJUENPUkUg PGJyPg0KJmd0OyAmZ3Q7ICZsdDtzaXBjb3JlQGlldGYub3JnJmd0Oywgc2lwY29yZS1ib3VuY2Vz QGlldGYub3JnPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mZ3Q7ICZndDsgPGJy Pg0KJmd0OyAmZ3Q7INb3zOI8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDsg Jmd0OyA8YnI+DQomZ3Q7ICZndDsgUmU6IFtzaXBjb3JlXSBOZXcgcmV2aXNpb24gb2YgdGhlIHJl LUlOVklURSBoYW5kbGluZyBkcmFmdDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBIaSw8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAm Z3Q7ICZndDsgJm5ic3A7IEluIG9yZGVyIHRvIG1ha2UgJnF1b3Q7QWxyZWFkeS1leGVjdXRlZCBD aGFuZ2VzJnF1b3Q7DQpjbGVhciwgdGhlIGRyYWZ0IHNob3VsZCA8YnI+DQomZ3Q7ICZndDsgJmd0 OyBzdGF0ZSA8YnI+DQomZ3Q7ICZndDsgJmd0OyB3aGVuIFVBUy9VQUMgc3RhcnQgdG8gbGlzdGVu IG9uIHRoZSBuZXcgcG9ydCwgYW5kIHdoZW4gVUFTL1VBQw0KdXNlIDxicj4NCiZndDsgJmd0OyAm Z3Q7IG5ldyBtZWRpYSBwYXJhbWV0ZXJzLiBJdCdzIGVzc2VudGlhbCBmb3IgdXNlcnMgdG8gZmlu ZCB0aGUNCnJpZ2h0c3RhdGUsIEkgPGJyPg0KJmd0OyAmZ3Q7ICZndDsgdGhpbmsuPGJyPg0KJmd0 OyAmZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyB5ZXMsIGl0IGlzIGVz c2VudGlhbC4gSW4gYW55IGNhc2UsIHRoZSBkcmFmdCB3aWxsIG5vdCBkZWZpbmUNCmFueXRoaW5n PGJyPg0KJmd0OyAmZ3Q7IG5ldyBpbiB0aGlzIHJlc3BlY3QuIFdlIHdpbGwgdXNlIHRoZSBkZWZp bml0aW9uIGluIFJGQyAzMjY0IGFuZA0KY2xhcmlmeTxicj4NCiZndDsgJmd0OyBpdCBpZiBuZWVk ZWQuPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBUaGFua3MgZm9yIHlvdXIgY29tbWVu dHMsPGJyPg0KJmd0OyAmZ3Q7IDxicj4NCiZndDsgJmd0OyBHb256YWxvPGJyPg0KJmd0OyAmZ3Q7 IDxicj4NCjwvZm9udD48L3R0Pg0KPGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJz cDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2Nv bnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZu YnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXph dGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNw O2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNw O2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5i c3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNj bG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVu aWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5i c3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNw O2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5 Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlk dWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7 YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2Vp dmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZu YnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNw O21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNw O3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZu YnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZu YnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNw O1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJl Pg== --=_alternative 003EF366482575FC_=-- From ietf.hanserik@gmail.com Thu Jul 23 06:34:58 2009 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 546E43A683B for ; Thu, 23 Jul 2009 06:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.454 X-Spam-Level: X-Spam-Status: No, score=-2.454 tagged_above=-999 required=5 tests=[AWL=0.144, 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 l2FrfIKM5OXM for ; Thu, 23 Jul 2009 06:34:57 -0700 (PDT) Received: from mail-ew0-f226.google.com (mail-ew0-f226.google.com [209.85.219.226]) by core3.amsl.com (Postfix) with ESMTP id D06CD3A672F for ; Thu, 23 Jul 2009 06:34:56 -0700 (PDT) Received: by ewy26 with SMTP id 26so978045ewy.37 for ; Thu, 23 Jul 2009 06:34:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=sbtlVg+J/revCIPFMPBwWeh4AroYiThpeUKIqX9V6Xc=; b=c8LsEhiStSdjhHFVhyyhJDyWyIDVeyXhFToiJDKxJGuoGQ6KXQmXQoxT4Mf5qOyRoE e4qIbS3W4vMVmpmObMnWf3THDE7MwiUwf1LVck4Vmgt62SP1735qyTyV2ssolsvBr22S A1oaLMEWCzFn0IxPNUz7s5hCnUjYOrCVeOAdM= 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=nqd9zjfhAjzYrDjxBUHq/x+Yk3EuWOfv/DuT+whWevVXq/BcsVBLDK3Pp0AzS2zJ8+ /knstfcPqYmH9pjJztwTTbejDAvObFxtgDxzgqAx7kxR9EPzmaZUyxFpceaIIb4pBjQv SRRjq0zmPAqnLbHzMCsNSjvWqooGDHVhdNdQU= MIME-Version: 1.0 Received: by 10.210.142.10 with SMTP id p10mr2224720ebd.43.1248356075344; Thu, 23 Jul 2009 06:34:35 -0700 (PDT) In-Reply-To: <4A6863FB.6070509@cisco.com> References: <0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3616@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F1A339E@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3667@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0022A39CE@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F201CE4@zrc2hxm0.corp.nortel.com> <9ae56b1e0907230104u3957a145mcac1f1445b796d1b@mail.gmail.com> <4A6863FB.6070509@cisco.com> Date: Thu, 23 Jul 2009 15:34:35 +0200 Message-ID: <9ae56b1e0907230634i69e2756bw8b986ea0fbaa9d@mail.gmail.com> From: Hans Erik van Elburg To: Paul Kyzivat Content-Type: multipart/alternative; boundary=0015174c1c466c922f046f5f8cc4 Cc: SIPCORE Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summary of where we are 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, 23 Jul 2009 13:34:58 -0000 --0015174c1c466c922f046f5f8cc4 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Not sure what you mean with interchangeability. Only thing I said is that both algorithms may often result in returning the same URI. In a lot of cases they will not, as they are retrieving different type of information. /Hans Erik van Elburg On Thu, Jul 23, 2009 at 3:22 PM, Paul Kyzivat wrote: > > > Hans Erik van Elburg wrote: > >> As said before the algorithms for a UAS are very clear. >> >> To retrieve the addressed target (freephone, etc) (Main thing that >> target-uri draft was after.): - traverse all H-I entries backward until an >> "mp" entry is found, if found this is the addressed target >> - if no "mp" found take the first H-I entry >> - if no History-Info header take the Request-URI value >> >> To retrieve the last aor before it was overwritten by contact address >> (similar as P-Called-Party-ID): - traverse all H-I entries backward until an >> "aor" entry is found, if found this is the last AOR used >> >> Both values can be the same in a lot of situations. But they will not >> always be. >> > > I'm confused here. IIUC there has been a change to that the 'mp' tag marks > the "mapped to" URI rather than the "mapped from" URI. If so then I don't > see how the two are likely to be interchangable in many if any cases. If > 'mp' marks the "mapped from" URI then I guess there would be a lot of > equivalence. > > Thanks, > Paul > > /Hans Erik van Elburg >> >> >> On Thu, Jul 23, 2009 at 6:57 AM, Francois Audet > audet@nortel.com>> wrote: >> >> target-URI algorithm for UAS: >> >> There were some questions on the list about algorithms for >> picking >> the "target URI parameter: is it the last "mp"-marked tag or >> is it >> the last "aor" tag. It seems that the answer to this question >> may >> be different based on what the assumptions people have about >> what >> is in fact a "target URI". It is not clear if we need to >> describe >> this in the draft, or even indeed if it actually makes a >> difference. >> >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> > --0015174c1c466c922f046f5f8cc4 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Not sure what you mean with interchangeability. Only thing I said is that b= oth algorithms may often result in returning the same URI. In a lot of case= s they will not, as they are retrieving different type of information.

/Hans Erik van Elburg


On Thu, Jul 23, 2009 at 3:22 PM, Paul Ky= zivat <pkyzivat@= cisco.com> wrote:


Hans Erik van Elburg wrote:
As said before the algorithms for a UAS are very clear.

To retrieve the addressed target (freephone, etc) (Main thing that target-u= ri draft was after.): - traverse all H-I entries backward until an "mp= " entry is found, if found this is the addressed target
- if no "mp" found take the first H-I entry
- if no History-Info header take the Request-URI value

To retrieve the last aor before it was overwritten by contact address (simi= lar as P-Called-Party-ID): - traverse all H-I entries backward until an &qu= ot;aor" entry is found, if found this is the last AOR used

Both values can be the same in a lot of situations. But they will not alway= s be.

I'm confused here. IIUC there has been a change to that the 'mp'= ; tag marks the "mapped to" URI rather than the "mapped from= " URI. If so then I don't see how the two are likely to be interch= angable in many if any cases. If 'mp' marks the "mapped from&q= uot; URI then I guess there would be a lot of equivalence.

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

/Hans Erik van Elburg



On Thu, Jul 23, 2009 at 6:57 AM, Francois Audet <audet@nortel.com <mailto:audet@nortel.com>> wrot= e:

=A0 =A0target-URI algorithm for UAS:

=A0 =A0 =A0 =A0 =A0 There were some questions on the list about algorithms= for
=A0 =A0picking
=A0 =A0 =A0 =A0 =A0 the "target URI parameter: is it the last "m= p"-marked tag or
=A0 =A0is it
=A0 =A0 =A0 =A0 =A0 the last "aor" tag. It seems that the answer= to this question may
=A0 =A0 =A0 =A0 =A0 be different based on what the assumptions people have= about what
=A0 =A0 =A0 =A0 =A0 is in fact a "target URI". It is not clear i= f we need to describe
=A0 =A0 =A0 =A0 =A0 this in the draft, or even indeed if it actually makes= a
=A0 =A0 =A0 =A0 =A0 difference.



------------------------------------------------------------------------

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

--0015174c1c466c922f046f5f8cc4-- From gonzalo.camarillo@ericsson.com Thu Jul 23 06:36:11 2009 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 6C5513A683B for ; Thu, 23 Jul 2009 06:36:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.381 X-Spam-Level: X-Spam-Status: No, score=-5.381 tagged_above=-999 required=5 tests=[AWL=0.868, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 ru44FwT2ZQ2l for ; Thu, 23 Jul 2009 06:36:10 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 94BBF3A6A04 for ; Thu, 23 Jul 2009 06:36:09 -0700 (PDT) X-AuditID: c1b4fb3c-b7bc4ae000004197-21-4a68672633f2 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id FC.65.16791.627686A4; Thu, 23 Jul 2009 15:35:34 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 15:35:18 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 15:35:18 +0200 Received: from [131.160.37.44] (EV001E681B5FE2.lmf.ericsson.se [131.160.37.44]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 29B312450; Thu, 23 Jul 2009 16:35:18 +0300 (EEST) Message-ID: <4A686715.3070909@ericsson.com> Date: Thu, 23 Jul 2009 16:35:17 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Paul Kyzivat References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com> <4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com> In-Reply-To: <4A6861CC.5030300@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2009 13:35:18.0499 (UTC) FILETIME=[6B351330:01CA0B9A] X-Brightmail-Tracker: AAAAAA== Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 23 Jul 2009 13:36:11 -0000 Hi Paul, > This will encourage using a *simple* request to do an essential target > refresh, rather than a complex one that has a chance of failing. Yes, I agree with you. I think we can get what you are looking for by keeping the text that is currently in the draft (i.e., re-INVITEs remain atomic and an error response rolls everything back, including the target refresh), by adding a description of why piggybacking other changes in a target refresh request is a bad idea (the new text would include a discussion on the Via problem and on legacy UASs responding with an error response even if changes have been executed), and by discouraging the use of re-INVITEs that update the target and perform other changes at the same time (we probably need to go as far as to say that one SHOULD NOT do it). I agree with you that encouraging the use of "simple" requests will be better than specifying complex behavior just to cover corner cases. Thanks, Gonzalo Paul Kyzivat wrote: > Gonzalo, > > I agree with all you say below, except at the very end about target > refresh. > > If target refreshes are to be accepted even if the request fails, then > it is possible to hijack a session even if authentication is being used > for signaling. > > IMO a target refresh must be ignored in at least *some* cases when the > request is rejected. We could enumerate these cases individually, or > simply state that it will only be accepted if the request is accepted. > (In case of reINVITE, that would be if it was accepted sufficiently to > return a 2xx or a 1xx.) > > This will encourage using a *simple* request to do an essential target > refresh, rather than a complex one that has a chance of failing. Perhaps > it won't work in all cases, but such is life. > > Thanks, > Paul > > Gonzalo Camarillo wrote: >> Hi Paul, >> >> thanks for your comments. Answers inline: >> >> Paul Kyzivat wrote: >>> Gonzalo, >>> >>> Thanks for doing this work! I do have some comments: >>> >>> Section 3/Figure 1 >>> >>> The figure shows a 6xx response. >>> The text says that the UAS wants to reject the new offer. >>> >>> A UAS would probably not use a 6xx response to reject media. >>> (I guess it might use 606, but 488 would be more appropriate.) >>> In fact, it probably would not reject the request at all, but rather >>> would just refuse the added media stream. >>> >>> The point being made doesn't require that the response be 6xx or that >>> it be with the purpose of refusing the media. So I think what is >>> needed here is to find a plausible example to make the point. >>> >>> A good one for the purpose here might be a 488 to reject the media, >>> or a 401 response as another sort of reason for rejecting the whole >>> thing but wanting to preserve what there is. >> >> yes, I agree that a 488 response would be more appropriate. I will >> change that in the draft. >> >>> >>> Section 5: >>> >>>> A change to the session state is considered to have been executed >>>> when the new media parameters are being used. Therefore, a >>>> change to >>>> a stream subject to preconditions [RFC4032] is considered to have >>>> been executed when the new media parameters start being used; not >>>> when the preconditions for the stream are met. Unsurprisingly, the >>>> UAS considers the new parameters to be in use when it actually >>>> starts >>>> using them. >>> >>> I'm not entirely following this. I think there may be an assumption >>> here that the UAC is the offerer and the UAS the answerer. I'm >>> guessing you are saying that the answerer considers the new >>> parameters to be in use when it actually starts using them. >>> >>> Since this section is about the UAS (for the reinvite), this point is >>> probably that when the UAS is also the answerer it can decide when >>> the new media is in use based on when it starts using them. >>> >>> But what happens when the UAS is the offerer? In that case I think it >>> must assume the media is in use as soon as it is offered. But maybe >>> that isn't always the case with preconditions. I don't think it can >>> wait till it receives media, because media may be in flight when it >>> makes its decision. >> >> yes, the draft assumes that the UAS is the answerer because that was >> the use case being discussed originally. However, you are right that >> we should also cover the case where the UAS is the offerer. I will >> look into it and add text about it in the draft. >> >>> >>>> As described in Section 8.3.1 of RFC 3264 [RFC3264], the >>>> UAC considers the new parameters to be in use when media is received >>>> in the new port, which should be interpreted as follows: >>>> >>>> Received, in this case, means that the media is passed to a media >>>> sink. This means that if there is a playout buffer, the agent >>>> would continue to listen on the old port until the media on the >>>> new port reached the top of the playout buffer. At that time, it >>>> MAY cease listening for media on the old port. >>> >>> I don't know what the above has to do with the behavior of the UAS. >> >> The UAC needs to know when the new parameters are in use in order to >> implement the normative behavior in Section 6: >> >> ... a UAC that receives an error response to a re-INVITE for which >> changes have been already executed ... >> >> In any case, I will clarify all this when I write the text about the >> UAS being the offerer because this type of behavior has to do with >> being the offerer or the answerer, not the UAC or the UAS. >> >> >>>> 9. Clarifications on Target Refresh Requests >> >> the current text is a straw man that puts target refreshes in the same >> category as any other change. The other option we talked about in the >> past was to special case them so that they are treated differently. >> You seem to like the latter option better. What do you think about the >> following text? >> >> >>
> anchor="sec-atom"> >> >> The remote target of a dialog is a special type of state information >> because of its essential role in the exchange of SIP messages between >> UAs in a dialog. A UA involved in a dialog receives the remote target >> of the dialog from the remote UA. The UA uses the remote target to >> send SIP requests to the remote UA. >> >> >> The remote target is a piece of state information that is not meant to >> be negotiated. When a UAC changes its address, the UAC simply >> communicates its new address to the UAS in order to remain reachable >> by the UAS. As described in , a UAS >> starts using the new remote target as soon as the target refresh >> request is received, regardless of the response the UAS generates to >> that request. That is, even if the UAS generates an error response to >> the target refresh request, the UAS needs to update the dialog's >> remote target URI. >> >> >> The fact that a target refresh request updates the remote target >> regardless of the response it triggers implies that target refresh >> requests are not atomic. That is, an error response to a target >> refresh request will keep all changes associated to the request from >> being performed except for the refresh of the remote target, which >> will be performed anyway. >> >>
>> >> >> Cheers, >> >> Gonzalo >> From gao.yang2@zte.com.cn Thu Jul 23 06:40:48 2009 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 171C93A672F for ; Thu, 23 Jul 2009 06:40:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -95.526 X-Spam-Level: X-Spam-Status: No, score=-95.526 tagged_above=-999 required=5 tests=[AWL=-2.736, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 aThXbNLduZRr for ; Thu, 23 Jul 2009 06:40:47 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 733D73A69F2 for ; Thu, 23 Jul 2009 06:40:46 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111641727820181; Thu, 23 Jul 2009 21:22:05 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 85804.1727820181; Thu, 23 Jul 2009 21:32:39 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n6NDeDpu080297 for ; Thu, 23 Jul 2009 21:40:13 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: To: wang.libo@zte.com.cn MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 23 Jul 2009 21:39:37 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-23 21:39:58, Serialize complete at 2009-07-23 21:39:58 Content-Type: multipart/alternative; boundary="=_alternative 004B102B482575FC_=" X-MAIL: mse1.zte.com.cn n6NDeDpu080297 Cc: SIPCORE , OKUMURA Shinji Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ICBOZXcgcmV2aXNpb24gb2YgdGhlIHJl?= =?gb2312?b?LUlOVklURSBoYW5kbGluZyBkcmFmdA==?= 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, 23 Jul 2009 13:40:48 -0000 This is a multipart message in MIME format. --=_alternative 004B102B482575FC_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCnBsZWFzZSBzZWUgaW5saW5lcy4NCg0KVGhhbmtzDQoNCkdhbw0KDQoNCi8vLy8vLy8v Ly8vLy8NCg0KDQpIaaOsDQoNCiAgSXQgc2VlbXMgdGhhdCBjbGVhciBkZWZpbml0aW9uIG9mICJs ZWdhY3kgVUFTIiBpcyBuZWNlc3NhcnkgdG9vLg0KDQpbR2FvXSBJTU+jrFVBUyBub3QgYmVoYXZp bmcgYXMgaW4gdGhlIGRyYWZ0IGlzICJsZWdhY3kgVUFTIi4gRm9yIGRldGFpbHMsIA0KdGhhdCBp cyBVQVMgc2VuZGluZyBub24tMnh4IGFmdGVyIE8vQSBwYWlyKHMpLg0KVGhhdCdzIG15IHVuZGVy c3RhbmRpbmcgb2YgImxlZ2FjeSBVQVMiLCBidXQgSSBhbSBub3Qgc3VyZSBpdCBpcyB0aGUgc2Ft ZSANCmFzIHRoZSBvcmlnaW5hbCB0aG91Z2h0IG9mIEdvbnphbG8uIA0KIA0KDQpBbHNvLCBpZiB0 aGUgVUFDIHNlbmRzIGEgcmUtSU5WSVRFIHdpdGggU0RQIHRoYXQgaXMgInNlbmRvbmx5IiwNCmRv ZXMgdGhlIFVBQyBoYXZlIHJ1bGVzIHRvIGRldGVybWluZSB3aGV0aGVyIHRoZSBVQVMgdXNlIHRo ZSBuZXcgDQpwYXJhbXRlcnMsIA0Kb3Igbm90Pw0KDQpbR2FvXSBBcyB0aGUgT2ZmZXIgc2VudCBi eSBVQUMgdXNpbmcgInNlbmRvbmx5IiwgdGhlIFVBUyB3b3VsZCBub3QgdXNlIG5ldyANCnBhcmFt dGVycyBpbiBzZW5kIGRpcmVjdGlvbi4NClRoZW4gbGV0J3MgY29uc2lkZXIgdGhlIHJlY3YgZGly ZWN0aW9uOg0KQnkgUkZDMzI2NCwgYW5zd2VyZXIgc2hvdWxkIGxpc3RlbiB1c2luZyBib3RoIHRo ZSAqbmV3KiBhbmQgKm9sZCogDQpwYXJhbXRlcnMgdW50aWwgbWVkaWEgdXNpbmcgKm5ldyogcGFy YW10ZXJzIGNvbWVzLiBTbywgd2hlbiBVQUMgZ2V0IHRoZSANCmFuc3dlciwgaXQgY2FuIGZpZ3Vy ZSBvdXQgdGhhdCBVQUMgaGFzIGJlZ3VuIHRvIHJlY3YgbWVkaWEgdXNpbmcgKm5ldyogDQpwYXJh bXRlcnMuDQoNClVudGlsIGhlcmUsIHRoaW5ncyBpcyB1bmRlciBjb250cm9sIG9mICBSRkMzMjY0 J3MgZGVmaW5pdGlvbi4gDQoNCkJ1dCBJJ2QgbGlrZSB0byBleHRlbmQgdGhpcyBjYXNlIGNvbnNp ZGVyaW5nIHByZWNvbmRpdGlvbi4NCk1lZGlhIG1vZGlmaWNhdGlvbiBpbiBSRkMzMjY0IGp1c3Qg aGFzIG9uZSBPL0EgcGFpci4gQW5kIHRoZSBhbnN3ZXIgaXMgDQp0cmVhdGVkIGFzIGFjY2VwdCBv ZiBvZmZlci4gQnV0IGl0IGlzIG5vdCB0aGUgY2FzZSB3aGlsZSBjb25zaWRlcmluZyANCnByZWNv bmRpdGlvbjogdXNlciBvZiBhbnN3ZXJlciBvbmx5IGhhdmUgdGhlIGNoYW5jZSBmb3IgZGVjaXNp b24gb2YgDQphY2NlcHRhbmNlIGFmdGVyIHByZWNvbmRpdGlvbiBzYXRpc2ZpZWQuIEJlZm9yZSBw cmVjb25kaXRpb24gc2F0aXNmaWVkLCANCnRoZXJlIGNhbiBiZSBtb3JlIHRoYW4gb25lIE8vQSBw YWlycy4gDQoNClRoZSBvZmZlcmVyIG1heSB3YWl0IGFuc3dlcmVyIHN0YXJ0IHRvIHVzZSAqbmV3 KiBwYXJhbXRlcnMgZmlzcnQsIGFuZCB0YWtlIA0KaXQgYXMgdHJpZ2dlci4gQnV0IGFzIFNEUCBp cyAic2VuZG9ubHkiLCBhbnN3ZXJlciB3b3VsZCBub3Qgc2VuZCBtZWRpYSB0byANCm9mZmVyZXIu IFNvLCB0aGUgcHJvcGVyIHRyaWdnZXIgaGVyZSBjYW4gYmUgMnh4IG9mIHRoZSBSZS1JTlZJVEUu IEFuZCB0aGlzIA0KaXMgZW5oYW5jZW1lbnQgZm9yIFJGQzMyNjQuIEkgdGhpbmsgaXQgc2hvdWxk IGJlIG5vdGVkIGRvd24uDQoNCkkgdGhpbmsgaXQgY2FuIGJlIGEgc2VwYXJhdGUgdGV4dC4gDQoN CiJkcmFmdC1jYW1hcmlsbG8tc2lwY29yZS1yZWludml0ZS0wMCIgaXMgYWltZWQgZm9yIGNvcnJl Y3Rpb24gb2YgUkZDMzI2MS4gDQpXaGlsZSB3aGF0IHdlIHRhbGtlZCBub3cgaXMgY29ycmVjdGlv biBvZiBSRkMzMjY0LiBJIHRoaW5rIHdlIGNhbiBkbyBpdCANCnNlcGFyYXRlbHkuDQoNClJlZ2Fy ZHMsDQpFcmljDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRo ZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBv ZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBj b25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWlu dGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVu dHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBm aWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNv bGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5 IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3Ig cGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4 cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRl ci4NClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5 IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 004B102B482575FC_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+cGxlYXNlIHNlZSBpbmxpbmVzLjwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5HYW88L2ZvbnQ+DQo8 YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPi8vLy8vLy8vLy8v Ly88L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi Pkhpo6w8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPiZu YnNwOyBJdCBzZWVtcyB0aGF0IGNsZWFyIGRlZmluaXRpb24NCm9mIDwvZm9udD48Zm9udCBzaXpl PTI+PHR0PiZxdW90O2xlZ2FjeSBVQVMmcXVvdDsgaXMgbmVjZXNzYXJ5IHRvby48L3R0PjwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48dHQ+W0dhb10gSU1Po6xVQVMg bm90IGJlaGF2aW5nIGFzIGluIHRoZQ0KZHJhZnQgaXMgJnF1b3Q7bGVnYWN5IFVBUzwvdHQ+PC9m b250Pjxmb250IHNpemU9Mj48dHQ+JnF1b3Q7LiBGb3IgZGV0YWlscywNCnRoYXQgaXMgVUFTIHNl bmRpbmcgbm9uLTJ4eCBhZnRlciBPL0EgcGFpcihzKS48L3R0PjwvZm9udD4NCjxicj48Zm9udCBz aXplPTI+PHR0PlRoYXQncyBteSB1bmRlcnN0YW5kaW5nIG9mICZxdW90O2xlZ2FjeSBVQVMmcXVv dDssDQpidXQgSSBhbSBub3Qgc3VyZSBpdCBpcyB0aGUgc2FtZSBhcyB0aGUgb3JpZ2luYWwgdGhv dWdodCBvZiBHb256YWxvLiA8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PiZuYnNw OzwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9Mj48dHQ+QWxzbywgaWYgdGhlIFVB QyBzZW5kcyBhIHJlLUlOVklURSB3aXRoIFNEUCB0aGF0IGlzDQomcXVvdDtzZW5kb25seSZxdW90 Oyw8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTI+PHR0PmRvZXMgdGhlIFVBQyBoYXZlIHJ1 bGVzIHRvIGRldGVybWluZSB3aGV0aGVyIHRoZSBVQVMNCnVzZSB0aGUgbmV3IHBhcmFtdGVycywg PC90dD48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5vciBub3Q/PC90dD48L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+PHR0PltHYW9dIEFzIHRoZSBPZmZlciBz ZW50IGJ5IFVBQyB1c2luZyAmcXVvdDtzZW5kb25seSZxdW90OywNCnRoZSBVQVMgd291bGQgbm90 IHVzZSBuZXcgcGFyYW10ZXJzIGluIHNlbmQgZGlyZWN0aW9uLjwvdHQ+PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBjb2xvcj1ibHVlPjx0dD5UaGVuIGxldCdzIGNvbnNpZGVyIHRoZSByZWN2IGRp cmVjdGlvbjo8L3R0PjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgY29sb3I9Ymx1ZT48dHQ+Qnkg UkZDMzI2NCwgYW5zd2VyZXIgc2hvdWxkIGxpc3RlbiB1c2luZw0KYm90aCB0aGUgKm5ldyogYW5k ICpvbGQqIHBhcmFtdGVycyB1bnRpbCBtZWRpYSB1c2luZyAqbmV3KiBwYXJhbXRlcnMgY29tZXMu DQpTbywgd2hlbiBVQUMgZ2V0IHRoZSBhbnN3ZXIsIGl0IGNhbiBmaWd1cmUgb3V0IHRoYXQgVUFD IGhhcyBiZWd1biB0byByZWN2DQptZWRpYSB1c2luZyAqbmV3KiBwYXJhbXRlcnMuPC90dD48L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+PHR0PlVudGlsIGhlcmUsIHRo aW5ncyBpcyB1bmRlciBjb250cm9sIG9mDQombmJzcDtSRkMzMjY0J3MgZGVmaW5pdGlvbi4gPC90 dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+PHR0PkJ1dCBJJ2Qg bGlrZSB0byBleHRlbmQgdGhpcyBjYXNlIGNvbnNpZGVyaW5nDQpwcmVjb25kaXRpb24uPC90dD48 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGNvbG9yPWJsdWU+PHR0Pk1lZGlhIG1vZGlmaWNhdGlv biBpbiBSRkMzMjY0IGp1c3QgaGFzDQpvbmUgTy9BIHBhaXIuIEFuZCB0aGUgYW5zd2VyIGlzIHRy ZWF0ZWQgYXMgYWNjZXB0IG9mIG9mZmVyLiBCdXQgaXQgaXMgbm90DQp0aGUgY2FzZSB3aGlsZSBj b25zaWRlcmluZyBwcmVjb25kaXRpb246IHVzZXIgb2YgYW5zd2VyZXIgb25seSBoYXZlIHRoZQ0K Y2hhbmNlIGZvciBkZWNpc2lvbiBvZiBhY2NlcHRhbmNlIGFmdGVyIHByZWNvbmRpdGlvbiBzYXRp c2ZpZWQuIEJlZm9yZQ0KcHJlY29uZGl0aW9uIHNhdGlzZmllZCwgdGhlcmUgY2FuIGJlIG1vcmUg dGhhbiBvbmUgTy9BIHBhaXJzLiA8L3R0PjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg Y29sb3I9Ymx1ZT48dHQ+VGhlIG9mZmVyZXIgbWF5IHdhaXQgYW5zd2VyZXIgc3RhcnQgdG8NCnVz ZSAqbmV3KiBwYXJhbXRlcnMgZmlzcnQsIGFuZCB0YWtlIGl0IGFzIHRyaWdnZXIuIEJ1dCBhcyBT RFAgaXMgJnF1b3Q7c2VuZG9ubHkmcXVvdDssDQphbnN3ZXJlciB3b3VsZCBub3Qgc2VuZCBtZWRp YSB0byBvZmZlcmVyLiBTbywgdGhlIHByb3BlciB0cmlnZ2VyIGhlcmUgY2FuDQpiZSAyeHggb2Yg dGhlIFJlLUlOVklURS4gQW5kIHRoaXMgaXMgZW5oYW5jZW1lbnQgZm9yIFJGQzMyNjQuIEkgdGhp bmsgaXQNCnNob3VsZCBiZSBub3RlZCBkb3duLjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBjb2xvcj1ibHVlPjx0dD5JIHRoaW5rIGl0IGNhbiBiZSBhIHNlcGFyYXRlIHRleHQu IDwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBjb2xvcj1ibHVlPjx0dD4mcXVv dDtkcmFmdC1jYW1hcmlsbG8tc2lwY29yZS1yZWludml0ZS0wMCZxdW90Ow0KaXMgYWltZWQgZm9y IGNvcnJlY3Rpb24gb2YgUkZDMzI2MS4gV2hpbGUgd2hhdCB3ZSB0YWxrZWQgbm93IGlzIGNvcnJl Y3Rpb24NCm9mIFJGQzMyNjQuIEkgdGhpbmsgd2UgY2FuIGRvIGl0IHNlcGFyYXRlbHkuPC90dD48 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yPjx0dD5SZWdhcmRzLDwvdHQ+PC9mb250Pg0K PGJyPjxmb250IHNpemU9Mj48dHQ+RXJpYzwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0K PGJyPjxwcmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGlj ZTombmJzcDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7 dGhpcyZuYnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2Ym bmJzcDt0aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7 bWFpbCZuYnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtS ZWNpcGllbnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZu YnNwO3RvJm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7 bm90Jm5ic3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2Nv bnRlbnRzJm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7 b3RoZXJzLg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJz cDt0cmFuc21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlh bCZuYnNwO2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5i c3A7dXNlJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRp dHkmbmJzcDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZu YnNwO0lmJm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2Vt YWlsJm5ic3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZu YnNwO29yaWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5i c3A7dmlld3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5i c3A7YXJlJm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtz ZW5kZXIuDQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVk Jm5ic3A7Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pU RSZuYnNwO0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 004B102B482575FC_=-- From AUDET@nortel.com Thu Jul 23 09:09:32 2009 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 6216B3A6AC3 for ; Thu, 23 Jul 2009 09:09:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.295 X-Spam-Level: X-Spam-Status: No, score=-6.295 tagged_above=-999 required=5 tests=[AWL=0.303, 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 gBg93-sFiN-Y for ; Thu, 23 Jul 2009 09:09:31 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 309593A68B3 for ; Thu, 23 Jul 2009 09:09:30 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6NG72O03036; Thu, 23 Jul 2009 16:07:02 GMT X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01CA0BAF.DBFDFD68" Date: Thu, 23 Jul 2009 11:08:46 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F202311@zrc2hxm0.corp.nortel.com> In-Reply-To: <9ae56b1e0907230144q5abdafe8k7d21e944d6f68212@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summaryof where we are thread-index: AcoLccyYT32AahqERCqpc7SWP6lHlgAPgirg References: <0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3616@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F1A339E@zrc2hxm0.corp.nortel.com> <0D5F89FAC29E2C41B98A6A762007F5D0022A3667@GBNTHT12009MSX.gb002.siemens.net> <0D5F89FAC29E2C41B98A6A762007F5D0022A39CE@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F201CE4@zrc2hxm0.corp.nortel.com> <9ae56b1e0907230104u3957a145mcac1f1445b796d1b@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D0022E989D@GBNTHT12009MSX.gb002.siemens.net> <9ae56b1e0907230144q5abdafe8k7d21e944d6f68212@mail.gmail.com> From: "Francois Audet" To: "Hans Erik van Elburg" , "Elwell, John" Cc: SIPCORE Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summaryof where we are 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, 23 Jul 2009 16:09:32 -0000 This is a multi-part message in MIME format. ------_=_NextPart_001_01CA0BAF.DBFDFD68 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable To URI is almost always not reliable. ________________________________ From: Hans Erik van Elburg [mailto:ietf.hanserik@gmail.com]=20 Sent: Thursday, July 23, 2009 01:44 To: Elwell, John Cc: Audet, Francois (SC100:3055); SIPCORE Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: = Summaryof where we are =09 =09 inline as [HE]... /Hans Erik van Elburg =09 =09 On Thu, Jul 23, 2009 at 10:34 AM, Elwell, John = wrote: =09 > To retrieve the addressed target (freephone, etc) (Main thing > that target-uri draft was after.): > - traverse all H-I entries backward until an "mp" entry is > found, if found this is the addressed target > - if no "mp" found take the first H-I entry > - if no History-Info header take the Request-URI value =09 [JRE] Would it not be better to use the To URI in this case? The Request-URI is very unlikely to contain the addressed target. =09 [HE] Not sure To URI is also very unreliable. Maybe we should say in = that case that the addressed target could not be determined reliably. =20 > > To retrieve the last aor before it was overwritten by contact > address (similar as P-Called-Party-ID): > - traverse all H-I entries backward until an "aor" entry is > found, if found this is the last AOR used =09 [JRE] And if none found? [HE] Then the info is not available. =20 > Both values can be the same in a lot of situations. But they > will not always be. =09 [JRE] A common situation might be as follows. Caller dials freephone number (or group number, or whatever). Proxy resolves this to an AOR, and because that same proxy is responsible for that domain, it = resolves it further to a contact URI. If the proxy populates H-I with both the AOR and the contact URI, the algorithm above would work. However, I don't think there is anything in the document to mandate that, so a simple implementation would only insert the contact URI (assuming the freephone number is already there). I don't think either H-I entry = would be marked as either AOR or MP in this case, would they? =09 [HE] I think they would. I believe the 4244bis and also 4244 explicitly = require internal retargets to also be recorded. =20 =09 =09 > > On Thu, Jul 23, 2009 at 6:57 AM, Francois Audet > wrote: > > > target-URI algorithm for UAS: > > There were some questions on the list about > algorithms for picking > the "target URI parameter: is it the last > "mp"-marked tag or is it > the last "aor" tag. It seems that the answer to > this question may > be different based on what the assumptions > people have about what > is in fact a "target URI". It is not clear if we > need to describe > this in the draft, or even indeed if it actually makes = a > difference. > > > =09 ------_=_NextPart_001_01CA0BAF.DBFDFD68 Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable
To URI=20 is almost always not reliable.

From: Hans Erik van Elburg=20 [mailto:ietf.hanserik@gmail.com]
Sent: Thursday, July 23, = 2009=20 01:44
To: Elwell, John
Cc: Audet, Francois = (SC100:3055);=20 SIPCORE
Subject: Re: [sipcore] = draft-barnes-sipcore-rfc4244bis &=20 target-URI: Summaryof where we are

inline as [HE]...

/Hans Erik van = Elburg

On Thu, Jul 23, 2009 at 10:34 AM, Elwell, = John <john.elwell@siemens-en= terprise.com>=20 wrote:

> To retrieve the addressed target = (freephone, etc)=20 (Main thing
> that target-uri draft was after.):
> - = traverse all=20 H-I entries backward until an "mp" entry is
> found, if found = this is=20 the addressed target
> - if no "mp" found take the first H-I=20 entry
> - if no History-Info header take the Request-URI=20 value
[JRE] Would it not be better to use the To URI in = this case?=20 The
Request-URI is very unlikely to contain the addressed = target.
[HE] Not sure To URI is also very unreliable. Maybe we should say = in that=20 case that  the addressed target could not be determined = reliably.
 

>
> To retrieve the last aor before it = was=20 overwritten by contact
> address (similar as=20 P-Called-Party-ID):
> - traverse all H-I entries backward = until an=20 "aor" entry is
> found, if found this is the last AOR=20 used
[JRE] And if none found?
[HE] Then the info is not available.
 
> Both values can be the same in a lot of = situations. But=20 they
> will not always be.
[JRE] A common situation = might be=20 as follows. Caller dials freephone
number (or group number, or = whatever).=20 Proxy resolves this to an AOR,
and because that same proxy is = responsible=20 for that domain, it resolves
it further to a contact URI. If the = proxy=20 populates H-I with both the
AOR and the contact URI, the = algorithm above=20 would work. However, I
don't think there is anything in the = document to=20 mandate that, so a
simple implementation would only insert the = contact=20 URI (assuming the
freephone number is already there). I don't = think=20 either H-I entry would
be marked as either AOR or MP in this = case, would=20 they?
[HE] I think they would. I believe the 4244bis and also 4244 = explicitly=20 require internal retargets to also be recorded.
 

>
> On Thu, Jul 23, 2009 at 6:57 AM, = Francois=20 Audet
> <audet@nortel.com>=20 wrote:
>
>
>       target-URI = algorithm for=20 UAS:
>
>             =  There=20 were some questions on the list about
> algorithms for = picking
>=20              the "target URI = parameter:=20 is it the last
> "mp"-marked tag or is it
>   =    =20        the last "aor" tag. It seems that the = answer=20 to
> this question may
>         =  =20    be different based on what the assumptions
> = people have=20 about what
>             =  is in=20 fact a "target URI". It is not clear if we
> need to = describe
>=20              this in the draft, = or even=20 indeed if it actually makes a
>         =  =20  =20 =  difference.
>
>
>

------_=_NextPart_001_01CA0BAF.DBFDFD68-- From AUDET@nortel.com Thu Jul 23 09:34:58 2009 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 08DAD3A67A4 for ; Thu, 23 Jul 2009 09:34:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.314 X-Spam-Level: X-Spam-Status: No, score=-6.314 tagged_above=-999 required=5 tests=[AWL=0.285, 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 js5Vr0KJU480 for ; Thu, 23 Jul 2009 09:34:57 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id E3E063A6B38 for ; Thu, 23 Jul 2009 09:34:56 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6NGY4M19821; Thu, 23 Jul 2009 16:34:04 GMT 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, 23 Jul 2009 11:34:02 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F2023B9@zrc2hxm0.corp.nortel.com> In-Reply-To: A<0D5F89FAC29E2C41B98A6A762007F5D0022E981E@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summary ofwhere we are thread-index: AcoF6CVRUPlMKkb7SrWHqBtgx6wCgwAAvgVQABgn/cAAH/S/oADX36qgAATaVgAAAdl4gAATblIAABAxhiAAAXHJ8AAcxRAQAAXUPBAAE2znsA== References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com> <4A5E83CB.4090701@cisco.com> <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0022A3616@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F1A339E@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0022A3667@GBNTHT12009MSX.gb002.siemens.net> A <0D5F89FAC2! 9E2C41B98 A6A762007F5D 0022A39CE@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F201CE4@zrc2hxm0.corp.nortel.com> A<0D5F89FAC29E2C41B98A6A762007F5D0022E981E@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Elwell, John" , "SIPCORE" Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summary ofwhere we are 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, 23 Jul 2009 16:34:58 -0000 =20 > [JRE] It might also be worth mentioning that there was=20 > discussion about redirects. My understanding was that a=20 > redirecting entity could also mark a URI as an AOR. No. Those are orthogonal. The rule is clear: the entity that recognizes the entry as an AOR it is responsible for does the marking. So, if I redirect an incoming session from sip:audet@nortel.com to sip:john.elwell@siemens-enterprise.com, I will add an entry so it will look like this: History-Info: ;rt;aor;index=3D1=20 History-Info: ;mp;index=3D1.1 Then, when YOUR proxy receives the request, it will mark it as aor and then route it to you. It will look like this: History-Info: ;rt;aor;index=3D1 History-Info: = ;mp;aor;index=3D1.1=20 History-Info: ;rc;index=3D1.1.1 See the call flows in draft. From pkyzivat@cisco.com Thu Jul 23 09:36:44 2009 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 438E53A6AA3 for ; Thu, 23 Jul 2009 09:36:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 pA+IzdtndLc3 for ; Thu, 23 Jul 2009 09:36:43 -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 EB0FB3A6856 for ; Thu, 23 Jul 2009 09:36:42 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAE8uaEqrR7PD/2dsb2JhbAC5LoglkRQFhA0 X-IronPort-AV: E=Sophos;i="4.43,256,1246838400"; d="scan'208";a="352563366" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-6.cisco.com with ESMTP; 23 Jul 2009 16:36:23 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6NGaNM1021138; Thu, 23 Jul 2009 09:36:23 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6NGaLCQ016074; Thu, 23 Jul 2009 16:36:22 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 12:36:21 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 12:36:21 -0400 Message-ID: <4A689184.5050903@cisco.com> Date: Thu, 23 Jul 2009 12:36:20 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com> <4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com> <4A686715.3070909@ericsson.com> In-Reply-To: <4A686715.3070909@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2009 16:36:21.0273 (UTC) FILETIME=[B5ECD890:01CA0BB3] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9242; t=1248366983; x=1249230983; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20New=20revision=20of=20the=2 0re-INVITE=20handling=20draft |Sender:=20; bh=1aZBCuxBXzh9ztSv4U4miu2rFqmsIt8fqiJYrAYk0xc=; b=GClQ+RQHOgkho7VKHoL3HGLjMp3u/0nM7lbVADO5nUPIa8ocG89QVjAReQ q1qmasozmPEs8KoWDSWCKsCRiMtUuQhscWBoPfM51dfzPDi0pVoQfY9tQIDF h3aTxZJEzl; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 23 Jul 2009 16:36:44 -0000 I'm don't know if we are on quite the same page yet. Once accepted, I don't think a target refresh should be rolled back by anything. A key use case might be: I've started an reINVITE - one that might take awhile because it is trying to add media and the other end is alerting about that. While that is in progress I lose my IP address and need to target refresh. So what do I do? I think I send an UPDATE, which will be in the midst of the reINVITE transaction. I make it a simple one, in that it includes no o/a, its *just* a target refresh. Of course the Via for it has the new ip address. It *might* be rejected with 401. If so I may have to try again, but at least I have a chance of getting the response and trying again. Now the reINVITE itself is going to fail, because the responses will be going to a non-functional address based on the Via for the reINVITE. What we *don't* want is for the failure of the reINVITE to roll back the target refresh. The UAC can try sending a CANCEL following the UPDATE. It can have the new address as its Via. But still the resulting 487 for the reINVITE will go to the wrong address. Eventually the UAC can send another reINVITE with the new target. Or the UAS can send a new reINVITE to the new target address. Thanks, Paul Gonzalo Camarillo wrote: > Hi Paul, > > > This will encourage using a *simple* request to do an essential target > > refresh, rather than a complex one that has a chance of failing. > > Yes, I agree with you. I think we can get what you are looking for by > keeping the text that is currently in the draft (i.e., re-INVITEs remain > atomic and an error response rolls everything back, including the target > refresh), by adding a description of why piggybacking other changes in a > target refresh request is a bad idea (the new text would include a > discussion on the Via problem and on legacy UASs responding with an > error response even if changes have been executed), and by discouraging > the use of re-INVITEs that update the target and perform other changes > at the same time (we probably need to go as far as to say that one > SHOULD NOT do it). > > I agree with you that encouraging the use of "simple" requests will be > better than specifying complex behavior just to cover corner cases. > > Thanks, > > Gonzalo > > > > Paul Kyzivat wrote: >> Gonzalo, >> >> I agree with all you say below, except at the very end about target >> refresh. >> >> If target refreshes are to be accepted even if the request fails, then >> it is possible to hijack a session even if authentication is being >> used for signaling. >> >> IMO a target refresh must be ignored in at least *some* cases when the >> request is rejected. We could enumerate these cases individually, or >> simply state that it will only be accepted if the request is accepted. >> (In case of reINVITE, that would be if it was accepted sufficiently to >> return a 2xx or a 1xx.) >> >> This will encourage using a *simple* request to do an essential target >> refresh, rather than a complex one that has a chance of failing. >> Perhaps it won't work in all cases, but such is life. >> >> Thanks, >> Paul >> >> Gonzalo Camarillo wrote: >>> Hi Paul, >>> >>> thanks for your comments. Answers inline: >>> >>> Paul Kyzivat wrote: >>>> Gonzalo, >>>> >>>> Thanks for doing this work! I do have some comments: >>>> >>>> Section 3/Figure 1 >>>> >>>> The figure shows a 6xx response. >>>> The text says that the UAS wants to reject the new offer. >>>> >>>> A UAS would probably not use a 6xx response to reject media. >>>> (I guess it might use 606, but 488 would be more appropriate.) >>>> In fact, it probably would not reject the request at all, but rather >>>> would just refuse the added media stream. >>>> >>>> The point being made doesn't require that the response be 6xx or >>>> that it be with the purpose of refusing the media. So I think what >>>> is needed here is to find a plausible example to make the point. >>>> >>>> A good one for the purpose here might be a 488 to reject the media, >>>> or a 401 response as another sort of reason for rejecting the whole >>>> thing but wanting to preserve what there is. >>> >>> yes, I agree that a 488 response would be more appropriate. I will >>> change that in the draft. >>> >>>> >>>> Section 5: >>>> >>>>> A change to the session state is considered to have been executed >>>>> when the new media parameters are being used. Therefore, a >>>>> change to >>>>> a stream subject to preconditions [RFC4032] is considered to have >>>>> been executed when the new media parameters start being used; not >>>>> when the preconditions for the stream are met. Unsurprisingly, the >>>>> UAS considers the new parameters to be in use when it actually >>>>> starts >>>>> using them. >>>> >>>> I'm not entirely following this. I think there may be an assumption >>>> here that the UAC is the offerer and the UAS the answerer. I'm >>>> guessing you are saying that the answerer considers the new >>>> parameters to be in use when it actually starts using them. >>>> >>>> Since this section is about the UAS (for the reinvite), this point >>>> is probably that when the UAS is also the answerer it can decide >>>> when the new media is in use based on when it starts using them. >>>> >>>> But what happens when the UAS is the offerer? In that case I think >>>> it must assume the media is in use as soon as it is offered. But >>>> maybe that isn't always the case with preconditions. I don't think >>>> it can wait till it receives media, because media may be in flight >>>> when it makes its decision. >>> >>> yes, the draft assumes that the UAS is the answerer because that was >>> the use case being discussed originally. However, you are right that >>> we should also cover the case where the UAS is the offerer. I will >>> look into it and add text about it in the draft. >>> >>>> >>>>> As described in Section 8.3.1 of RFC 3264 [RFC3264], the >>>>> UAC considers the new parameters to be in use when media is >>>>> received >>>>> in the new port, which should be interpreted as follows: >>>>> >>>>> Received, in this case, means that the media is passed to a >>>>> media >>>>> sink. This means that if there is a playout buffer, the agent >>>>> would continue to listen on the old port until the media on the >>>>> new port reached the top of the playout buffer. At that >>>>> time, it >>>>> MAY cease listening for media on the old port. >>>> >>>> I don't know what the above has to do with the behavior of the UAS. >>> >>> The UAC needs to know when the new parameters are in use in order to >>> implement the normative behavior in Section 6: >>> >>> ... a UAC that receives an error response to a re-INVITE for which >>> changes have been already executed ... >>> >>> In any case, I will clarify all this when I write the text about the >>> UAS being the offerer because this type of behavior has to do with >>> being the offerer or the answerer, not the UAC or the UAS. >>> >>> >>>>> 9. Clarifications on Target Refresh Requests >>> >>> the current text is a straw man that puts target refreshes in the >>> same category as any other change. The other option we talked about >>> in the past was to special case them so that they are treated >>> differently. You seem to like the latter option better. What do you >>> think about the following text? >>> >>> >>>
>> anchor="sec-atom"> >>> >>> The remote target of a dialog is a special type of state information >>> because of its essential role in the exchange of SIP messages between >>> UAs in a dialog. A UA involved in a dialog receives the remote target >>> of the dialog from the remote UA. The UA uses the remote target to >>> send SIP requests to the remote UA. >>> >>> >>> The remote target is a piece of state information that is not meant to >>> be negotiated. When a UAC changes its address, the UAC simply >>> communicates its new address to the UAS in order to remain reachable >>> by the UAS. As described in , a UAS >>> starts using the new remote target as soon as the target refresh >>> request is received, regardless of the response the UAS generates to >>> that request. That is, even if the UAS generates an error response to >>> the target refresh request, the UAS needs to update the dialog's >>> remote target URI. >>> >>> >>> The fact that a target refresh request updates the remote target >>> regardless of the response it triggers implies that target refresh >>> requests are not atomic. That is, an error response to a target >>> refresh request will keep all changes associated to the request from >>> being performed except for the refresh of the remote target, which >>> will be performed anyway. >>> >>>
>>> >>> >>> Cheers, >>> >>> Gonzalo >>> > > From sanjsinh@cisco.com Thu Jul 23 09:52:31 2009 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 4DE9C3A6AD3 for ; Thu, 23 Jul 2009 09:52:31 -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=[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 irLamJUCcwjt for ; Thu, 23 Jul 2009 09:52:30 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 0A0CB3A67EF for ; Thu, 23 Jul 2009 09:52:30 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAEwyaEpAZnmf/2dsb2JhbAC5IYglkRgFhA2BSA X-IronPort-AV: E=Sophos;i="4.43,256,1246838400"; d="scan'208";a="218216649" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 23 Jul 2009 16:51:32 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6NGpWYH027688; Thu, 23 Jul 2009 12:51:32 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6NGpVxt008081; Thu, 23 Jul 2009 16:51:32 GMT Received: from xmb-rtp-201.amer.cisco.com ([64.102.31.13]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 12:51:31 -0400 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: Thu, 23 Jul 2009 12:51:27 -0400 Message-ID: In-Reply-To: <4A686715.3070909@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] New revision of the re-INVITE handling draft Thread-Index: AcoLmpC9hOqkFA9HQCm4vNfASD458QAGWGRg References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com><4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com> <4A686715.3070909@ericsson.com> From: "Sanjay Sinha (sanjsinh)" To: "Gonzalo Camarillo" , "Paul Kyzivat (pkyzivat)" X-OriginalArrivalTime: 23 Jul 2009 16:51:31.0575 (UTC) FILETIME=[D481E870:01CA0BB5] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=9311; t=1248367892; x=1249231892; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=sanjsinh@cisco.com; z=From:=20=22Sanjay=20Sinha=20(sanjsinh)=22=20 |Subject:=20RE=3A=20[sipcore]=20New=20revision=20of=20the=2 0re-INVITE=20handling=20draft |Sender:=20 |To:=20=22Gonzalo=20Camarillo=22=20,=0A=20=20=20=20=20=20=20=20=22Paul=20Kyzivat=20(pky zivat)=22=20; bh=Qku7qZvb0Vt/LEm6Cty/ITK2KKODG/WbdBz8ITLcrKM=; b=k9MpVFXkUdednFVTcNkCiu5jl63tq1qCLw1kJ+Dj5hddpoi/f429mgjQrx 9HVlk5JBdi11Tw/TIgxhQjNg5utaq5FM3w5nQypcguqNefDYpKpMgiUq3+zV AQdbcIp6wG; Authentication-Results: rtp-dkim-2; header.From=sanjsinh@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 23 Jul 2009 16:52:31 -0000 In theory it is okay to say that each request should be atomic, i.e. UAC should not request another operation on a request which is target refresh request. But in order to minimize signaling and deployment of legacy UA, it will continue to happen in practice. So having some kind of BCP text in the draft is a good idea. But I agree with Paul, that there should be a list of error codes for which the target refresh is not rolled back and others for which previous one remains in effect. We have seen the issue many times, does 488 response to a re-Invite causes target refresh to be applied or not. Having a list will go a long way in clarifying such cases. Thanks >-----Original Message----- >From: sipcore-bounces@ietf.org=20 >[mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >Sent: Thursday, July 23, 2009 7:05 PM >To: Paul Kyzivat (pkyzivat) >Cc: gao.yang2@zte.com.cn; SIPCORE >Subject: Re: [sipcore] New revision of the re-INVITE handling draft > >Hi Paul, > > > This will encourage using a *simple* request to do an=20 >essential target > refresh, rather than a complex one that=20 >has a chance of failing. > >Yes, I agree with you. I think we can get what you are looking=20 >for by keeping the text that is currently in the draft (i.e.,=20 >re-INVITEs remain atomic and an error response rolls=20 >everything back, including the target refresh), by adding a=20 >description of why piggybacking other changes in a target=20 >refresh request is a bad idea (the new text would include a=20 >discussion on the Via problem and on legacy UASs responding=20 >with an error response even if changes have been executed),=20 >and by discouraging the use of re-INVITEs that update the=20 >target and perform other changes at the same time (we probably=20 >need to go as far as to say that one SHOULD NOT do it). > >I agree with you that encouraging the use of "simple" requests=20 >will be better than specifying complex behavior just to cover=20 >corner cases. > >Thanks, > >Gonzalo > > > >Paul Kyzivat wrote: >> Gonzalo, >>=20 >> I agree with all you say below, except at the very end about target=20 >> refresh. >>=20 >> If target refreshes are to be accepted even if the request=20 >fails, then=20 >> it is possible to hijack a session even if authentication is being=20 >> used for signaling. >>=20 >> IMO a target refresh must be ignored in at least *some*=20 >cases when the=20 >> request is rejected. We could enumerate these cases individually, or=20 >> simply state that it will only be accepted if the request is=20 >accepted. >> (In case of reINVITE, that would be if it was accepted=20 >sufficiently to=20 >> return a 2xx or a 1xx.) >>=20 >> This will encourage using a *simple* request to do an=20 >essential target=20 >> refresh, rather than a complex one that has a chance of failing.=20 >> Perhaps it won't work in all cases, but such is life. >>=20 >> Thanks, >> Paul >>=20 >> Gonzalo Camarillo wrote: >>> Hi Paul, >>> >>> thanks for your comments. Answers inline: >>> >>> Paul Kyzivat wrote: >>>> Gonzalo, >>>> >>>> Thanks for doing this work! I do have some comments: >>>> >>>> Section 3/Figure 1 >>>> >>>> The figure shows a 6xx response. >>>> The text says that the UAS wants to reject the new offer. >>>> >>>> A UAS would probably not use a 6xx response to reject media. >>>> (I guess it might use 606, but 488 would be more appropriate.) In=20 >>>> fact, it probably would not reject the request at all, but rather=20 >>>> would just refuse the added media stream. >>>> >>>> The point being made doesn't require that the response be 6xx or=20 >>>> that it be with the purpose of refusing the media. So I think what=20 >>>> is needed here is to find a plausible example to make the point. >>>> >>>> A good one for the purpose here might be a 488 to reject=20 >the media,=20 >>>> or a 401 response as another sort of reason for rejecting=20 >the whole=20 >>>> thing but wanting to preserve what there is. >>> >>> yes, I agree that a 488 response would be more appropriate. I will=20 >>> change that in the draft. >>> >>>> >>>> Section 5: >>>> >>>>> A change to the session state is considered to have=20 >been executed >>>>> when the new media parameters are being used. Therefore, a=20 >>>>> change to >>>>> a stream subject to preconditions [RFC4032] is=20 >considered to have >>>>> been executed when the new media parameters start=20 >being used; not >>>>> when the preconditions for the stream are met. =20 >Unsurprisingly, the >>>>> UAS considers the new parameters to be in use when it actually=20 >>>>> starts >>>>> using them.=20 >>>> >>>> I'm not entirely following this. I think there may be an=20 >assumption=20 >>>> here that the UAC is the offerer and the UAS the answerer. I'm=20 >>>> guessing you are saying that the answerer considers the new=20 >>>> parameters to be in use when it actually starts using them. >>>> >>>> Since this section is about the UAS (for the reinvite), this point=20 >>>> is probably that when the UAS is also the answerer it can decide=20 >>>> when the new media is in use based on when it starts using them. >>>> >>>> But what happens when the UAS is the offerer? In that case I think=20 >>>> it must assume the media is in use as soon as it is offered. But=20 >>>> maybe that isn't always the case with preconditions. I don't think=20 >>>> it can wait till it receives media, because media may be in flight=20 >>>> when it makes its decision. >>> >>> yes, the draft assumes that the UAS is the answerer because=20 >that was=20 >>> the use case being discussed originally. However, you are=20 >right that=20 >>> we should also cover the case where the UAS is the offerer. I will=20 >>> look into it and add text about it in the draft. >>> >>>> >>>>> As described in Section 8.3.1 of RFC 3264 [RFC3264], the >>>>> UAC considers the new parameters to be in use when=20 >media is received >>>>> in the new port, which should be interpreted as follows: >>>>> >>>>> Received, in this case, means that the media is=20 >passed to a media >>>>> sink. This means that if there is a playout=20 >buffer, the agent >>>>> would continue to listen on the old port until the=20 >media on the >>>>> new port reached the top of the playout buffer. At=20 >that time, it >>>>> MAY cease listening for media on the old port. >>>> >>>> I don't know what the above has to do with the behavior of the UAS. >>> >>> The UAC needs to know when the new parameters are in use in=20 >order to=20 >>> implement the normative behavior in Section 6: >>> >>> ... a UAC that receives an error response to a re-INVITE=20 >for which >>> changes have been already executed ... >>> >>> In any case, I will clarify all this when I write the text=20 >about the=20 >>> UAS being the offerer because this type of behavior has to do with=20 >>> being the offerer or the answerer, not the UAC or the UAS. >>> >>> >>>>> 9. Clarifications on Target Refresh Requests >>> >>> the current text is a straw man that puts target refreshes in the=20 >>> same category as any other change. The other option we talked about=20 >>> in the past was to special case them so that they are=20 >treated differently. >>> You seem to like the latter option better. What do you think about=20 >>> the following text? >>> >>> >>>
>> Requests" >>> anchor=3D"sec-atom"> >>> >>> The remote target of a dialog is a special type of state=20 >information=20 >>> because of its essential role in the exchange of SIP=20 >messages between=20 >>> UAs in a dialog. A UA involved in a dialog receives the=20 >remote target=20 >>> of the dialog from the remote UA. The UA uses the remote target to=20 >>> send SIP requests to the remote UA. >>> >>> >>> The remote target is a piece of state information that is not meant=20 >>> to be negotiated. When a UAC changes its address, the UAC simply=20 >>> communicates its new address to the UAS in order to remain=20 >reachable=20 >>> by the UAS. As described in , a UAS=20 >>> starts using the new remote target as soon as the target refresh=20 >>> request is received, regardless of the response the UAS=20 >generates to=20 >>> that request. That is, even if the UAS generates an error=20 >response to=20 >>> the target refresh request, the UAS needs to update the dialog's=20 >>> remote target URI. >>> >>> >>> The fact that a target refresh request updates the remote target=20 >>> regardless of the response it triggers implies that target refresh=20 >>> requests are not atomic. That is, an error response to a target=20 >>> refresh request will keep all changes associated to the=20 >request from=20 >>> being performed except for the refresh of the remote target, which=20 >>> will be performed anyway. >>> >>>
>>> >>> >>> Cheers, >>> >>> Gonzalo >>> > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore > From john.elwell@siemens-enterprise.com Thu Jul 23 10:11:53 2009 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 3F1663A6AD3 for ; Thu, 23 Jul 2009 10:11:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.578 X-Spam-Level: X-Spam-Status: No, score=-2.578 tagged_above=-999 required=5 tests=[AWL=0.021, 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 HxbUcb1hYxR5 for ; Thu, 23 Jul 2009 10:11:52 -0700 (PDT) Received: from mailgate.siemenscomms.co.uk (mailgate.siemenscomms.co.uk [195.171.110.225]) by core3.amsl.com (Postfix) with ESMTP id D55D43A67EF for ; Thu, 23 Jul 2009 10:11:51 -0700 (PDT) Received: from GBNTHT12009MSX.gb002.siemens.net ([172.23.15.171]) by siemenscomms.co.uk (PMDF V6.3-x14 #31430) with ESMTP id <0KN800J24VOVGQ@siemenscomms.co.uk> for sipcore@ietf.org; Thu, 23 Jul 2009 18:10:07 +0100 (BST) Date: Thu, 23 Jul 2009 18:10:05 +0100 From: "Elwell, John" In-reply-to: <1ECE0EB50388174790F9694F77522CCF1F2023B9@zrc2hxm0.corp.nortel.com> To: Francois Audet , SIPCORE Message-id: <0D5F89FAC29E2C41B98A6A762007F5D0022E9D16@GBNTHT12009MSX.gb002.siemens.net> MIME-version: 1.0 X-MIMEOLE: Produced By Microsoft Exchange V6.5 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: quoted-printable Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summary ofwhere we are Thread-Index: AcoF6CVRUPlMKkb7SrWHqBtgx6wCgwAAvgVQABgn/cAAH/S/oADX36qgAATaVgAAAdl4gAATblIAABAxhiAAAXHJ8AAcxRAQAAXUPBAAE2znsAABfBIw Content-class: urn:content-classes:message X-MS-Has-Attach: X-MS-TNEF-Correlator: References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com> <4A5E83CB.4090701@cisco.com> <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0022A3616@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F1A339E@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0022A3667@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F201CE4@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0022E981E@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F2023B9@zrc2hxm0.corp.nortel.com> Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summary ofwhere we are 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, 23 Jul 2009 17:11:53 -0000 =20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com]=20 > Sent: 23 July 2009 17:34 > To: Elwell, John; SIPCORE > Subject: RE: [sipcore] draft-barnes-sipcore-rfc4244bis &=20 > target-URI: Summary ofwhere we are >=20 > =20 > > [JRE] It might also be worth mentioning that there was=20 > > discussion about redirects. My understanding was that a=20 > > redirecting entity could also mark a URI as an AOR. >=20 > No. Those are orthogonal. >=20 > The rule is clear: the entity that recognizes the entry as an > AOR it is responsible for does the marking. >=20 > So, if I redirect an incoming session from sip:audet@nortel.com > to sip:john.elwell@siemens-enterprise.com, I will add an entry so > it will look like this: >=20 > History-Info: ;rt;aor;index=3D1=20 [JRE] Exactly - as part of redirection you have marked your H-I entry as AOR. So I don't understand why you said "no" above. John > History-Info: ;mp;index=3D1.1 >=20 > Then, when YOUR proxy receives the request, it will mark it > as aor and then route it to you. It will look like this: >=20 > History-Info: ;rt;aor;index=3D1 > History-Info:=20 > ;mp;aor;index=3D1.1=20 > History-Info: ;rc;index=3D1.1.1 >=20 > See the call flows in draft. >=20 From AUDET@nortel.com Thu Jul 23 10:55:56 2009 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 63DA428C13B for ; Thu, 23 Jul 2009 10:55:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.331 X-Spam-Level: X-Spam-Status: No, score=-6.331 tagged_above=-999 required=5 tests=[AWL=0.268, 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 KvciwcXrDfDW for ; Thu, 23 Jul 2009 10:55:55 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id E80C53A6BD9 for ; Thu, 23 Jul 2009 10:54:16 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6NHS9M04138; Thu, 23 Jul 2009 17:28:09 GMT 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, 23 Jul 2009 12:27:56 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F2024E9@zrc2hxm0.corp.nortel.com> In-Reply-To: A<0D5F89FAC29E2C41B98A6A762007F5D0022E9D16@GBNTHT12009MSX.gb002.siemens.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summary ofwhere we are thread-index: AcoF6CVRUPlMKkb7SrWHqBtgx6wCgwAAvgVQABgn/cAAH/S/oADX36qgAATaVgAAAdl4gAATblIAABAxhiAAAXHJ8AAcxRAQAAXUPBAAE2znsAABfBIwAAAWVNA= References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com> <4A5E5D5F.80908@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com> <4A5E6558.8000108@cisco.com> <1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com> <4A5E83CB.4090701@cisco.com> <9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com> <0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0022A3616@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F1A339E@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0022A3667@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388! 174790F96 94F77522CCF1 F201CE4@zrc2hxm0.corp.nortel.com> A <0D5F89FAC29E2C41B98A6A762007F5D0022E981E@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F2023B9@zrc2hxm0.corp.nortel.com> A<0D5F89FAC29E2C41B98A6A762007F5D0022E9D16@GBNTHT12009MSX.gb002.siemens.net> From: "Francois Audet" To: "Elwell, John" , "SIPCORE" Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summary ofwhere we are 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, 23 Jul 2009 17:55:56 -0000 =20 > > So, if I redirect an incoming session from sip:audet@nortel.com to=20 > > sip:john.elwell@siemens-enterprise.com, I will add an entry=20 > so it will=20 > > look like this: > >=20 > > History-Info: ;rt;aor;index=3D1 > [JRE] Exactly - as part of redirection you have marked your=20 > H-I entry as AOR. So I don't understand why you said "no" above. Because I (i.e., my UAC) has NOT marked it. My proxy did. ^ If my UAC had included the entry (which is legal, but uncommon), there = would be no aor tag: History-Info: ;rt;index=3D1 Then, my proxy "recognizes it as an aor it owns" and adds the aor tag: History-Info: ;rt;aor;index=3D1 ^^^ Since in typical deployments, UACs don't include History-Info, the two = steps above are done by the proxy. This is why in the new procedures in the draft, the steps are clearly = defined in sequence, i.e.,=20 1 - Proxy adds previous entry on behalf of UAC if not present 2 - Proxy adds aor tag to previous entry if it recognizes URI a AOR it=20 is responsible for 3 - Proxy adds new entry for new target Makes sense? From dworley@nortel.com Thu Jul 23 12:24:01 2009 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 7FCF93A67E6 for ; Thu, 23 Jul 2009 12:24:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.477 X-Spam-Level: X-Spam-Status: No, score=-6.477 tagged_above=-999 required=5 tests=[AWL=0.122, 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 MBpGAjgh++94 for ; Thu, 23 Jul 2009 12:24:00 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 3FD563A6C47 for ; Thu, 23 Jul 2009 12:23:44 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (casmtp.ca.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6NJ30O27673; Thu, 23 Jul 2009 19:03:00 GMT Received: from [47.141.31.129] ([47.141.31.129]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 15:04:45 -0400 From: "Dale Worley" To: Hadriel Kaplan In-Reply-To: References: <1245876685.3748.61.camel@victoria-pingtel-com.us.nortel.com> <40FB0FFB97588246A1BEFB05759DC8A00330040F@S4DE9JSAANI.ost.t-com.de> <1247883283.4025.2.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Thu, 23 Jul 2009 15:04:44 -0400 Message-Id: <1248375884.4427.18.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2009 19:04:45.0674 (UTC) FILETIME=[715C9CA0:01CA0BC8] Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-kaplan-sip-session-id-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, 23 Jul 2009 19:24:01 -0000 On Sun, 2009-07-19 at 20:53 -0400, Hadriel Kaplan wrote: > A middlebox which replaces Call-ID's *does* know if it's a > secure-call-id. If it has no '@', and no IP Addr/hostname format in > it, it's sufficiently benign to not change. I see no reason to believe that -- sipXecs generates call-id's that have no @ and not addr/hostname, but they're by no means random. Moreover, the draft does not specify that call-ids with the specified format MAY NOT be changed by middleboxes, so once middlebox vendors realize my point in the previous paragraph, they'll start changing them. Dale From HKaplan@acmepacket.com Thu Jul 23 14:53:26 2009 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 464393A6C21 for ; Thu, 23 Jul 2009 14:53:26 -0700 (PDT) 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.000, 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 IcQXbB9rdJ48 for ; Thu, 23 Jul 2009 14:53:25 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 59B883A6B03 for ; Thu, 23 Jul 2009 14:53:25 -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.1.375.2; Thu, 23 Jul 2009 17:53:14 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Thu, 23 Jul 2009 17:53:14 -0400 From: Hadriel Kaplan To: Dale Worley Date: Thu, 23 Jul 2009 17:53:13 -0400 Thread-Topic: [sipcore] draft-kaplan-sip-session-id-02 Thread-Index: AcoLyQE4IgcsdZUySoa+3UPYqfTtVwAFU+mg Message-ID: References: <1245876685.3748.61.camel@victoria-pingtel-com.us.nortel.com> <40FB0FFB97588246A1BEFB05759DC8A00330040F@S4DE9JSAANI.ost.t-com.de> <1247883283.4025.2.camel@victoria-pingtel-com.us.nortel.com> <1248375884.4427.18.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1248375884.4427.18.camel@victoria-pingtel-com.us.nortel.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] draft-kaplan-sip-session-id-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, 23 Jul 2009 21:53:26 -0000 > -----Original Message----- > From: Dale Worley [mailto:dworley@nortel.com] > Sent: Thursday, July 23, 2009 3:05 PM >=20 > On Sun, 2009-07-19 at 20:53 -0400, Hadriel Kaplan wrote: > > A middlebox which replaces Call-ID's *does* know if it's a > > secure-call-id. If it has no '@', and no IP Addr/hostname format in > > it, it's sufficiently benign to not change. >=20 > I see no reason to believe that -- sipXecs generates call-id's that have > no @ and not addr/hostname, but they're by no means random. It's not the property of being random that's really important - it's the pr= operty of not revealing the generator's identity - by which I mean its IP A= ddress or hostname. I.e., by looking at a Call-ID value that sipXecs sends= me, can I discern its IP-addr/host? Note: There is an argument by some that if it even reveals the vendor/model= , then it's too sensitive, and obviously letting any word string be a Call-= ID lets that happen - I am consciously ignoring that concern in the current= draft's proposal, because I think the benefits outweigh the concern... but= I'm slightly on the fence about that particular topic. =20 > Moreover, the draft does not specify that call-ids with the specified > format MAY NOT be changed by middleboxes, so once middlebox vendors > realize my point in the previous paragraph, they'll start changing them. Even if we define a new format, if the contents reveal something a middle-b= ox doesn't want revealed (or really that their owner doesn't want revealed)= , there's nothing we can do to prevent it being changed. BUT, the middlebo= x vendors do have an incentive not to change it, as much as they can. -hadriel From dworley@nortel.com Thu Jul 23 17:43:15 2009 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 BC9D23A6C8F for ; Thu, 23 Jul 2009 17:43:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.497 X-Spam-Level: X-Spam-Status: No, score=-6.497 tagged_above=-999 required=5 tests=[AWL=0.102, 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 0FwJLoeNgoec for ; Thu, 23 Jul 2009 17:43:15 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id AA8D23A63D3 for ; Thu, 23 Jul 2009 17:43:14 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6O0fNe01949; Fri, 24 Jul 2009 00:41:23 GMT Received: from [47.141.31.129] ([47.141.31.129]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 23 Jul 2009 20:43:09 -0400 From: "Dale Worley" To: Hadriel Kaplan In-Reply-To: References: <1245876685.3748.61.camel@victoria-pingtel-com.us.nortel.com> <40FB0FFB97588246A1BEFB05759DC8A00330040F@S4DE9JSAANI.ost.t-com.de> <1247883283.4025.2.camel@victoria-pingtel-com.us.nortel.com> <1248375884.4427.18.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Thu, 23 Jul 2009 20:43:08 -0400 Message-Id: <1248396188.4427.24.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2009 00:43:09.0112 (UTC) FILETIME=[B7276380:01CA0BF7] Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-kaplan-sip-session-id-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: Fri, 24 Jul 2009 00:43:16 -0000 On Thu, 2009-07-23 at 17:53 -0400, Hadriel Kaplan wrote: > It's not the property of being random that's really important - it's > the property of not revealing the generator's identity - by which I > mean its IP Address or hostname. I.e., by looking at a Call-ID value > that sipXecs sends me, can I discern its IP-addr/host? > > > Note: There is an argument by some that if it even reveals the > vendor/model, then it's too sensitive, and obviously letting any word > string be a Call-ID lets that happen - I am consciously ignoring that > concern in the current draft's proposal, because I think the benefits > outweigh the concern... but I'm slightly on the fence about that > particular topic. > > > > Moreover, the draft does not specify that call-ids with the specified > > format MAY NOT be changed by middleboxes, so once middlebox vendors > > realize my point in the previous paragraph, they'll start changing them. > > Even if we define a new format, if the contents reveal something a > middle-box doesn't want revealed (or really that their owner doesn't > want revealed), there's nothing we can do to prevent it being changed. > BUT, the middlebox vendors do have an incentive not to change it, as > much as they can. In order to get value out of the proposed mechanism, we need to define how a UA can generate Call-Ids that middleboxes won't (in practice) feel the need to change. If the proposal requires that the Call-Ids be pseudo-random strings of a specified length and encoding, then middleboxes truly don't need to change them, as they don't reveal *anything*. But we still have to get the middleboxes to have a reasonably effective test for this situation, and then act on it. As I see it, all of these aspects of the situation need to be addressed in the draft, or otherwise it won't accomplish its purpose. Dale From christer.holmberg@ericsson.com Fri Jul 24 05:35:12 2009 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 50A9A28C15C for ; Fri, 24 Jul 2009 05:35:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.749 X-Spam-Level: X-Spam-Status: No, score=-3.749 tagged_above=-999 required=5 tests=[AWL=-1.500, BAYES_00=-2.599, HELO_EQ_SE=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 urjsrp1bBqeW for ; Fri, 24 Jul 2009 05:35:11 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 6462C3A6A0F for ; Fri, 24 Jul 2009 05:35:10 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-74-4a69aa7a865b Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 4D.C2.18827.A7AA96A4; Fri, 24 Jul 2009 14:35:07 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 14:33:39 +0200 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: Fri, 24 Jul 2009 14:33:37 +0200 Message-ID: In-Reply-To: <4A689184.5050903@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] New revision of the re-INVITE handling draft Thread-Index: AcoLs8ehleyjZr4iSoG9yc8aEELH6AApNi1w References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com><4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com><4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" , "Gonzalo Camarillo" X-OriginalArrivalTime: 24 Jul 2009 12:33:39.0035 (UTC) FILETIME=[F8916AB0:01CA0C5A] X-Brightmail-Tracker: AAAAAA== Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 24 Jul 2009 12:35:12 -0000 Hi, I am just re-booting after my summer vacation, and I have NOT been able to read all e-mails in this thread yet. So, I appologize if something has been discussed. Regarding the proposal to not be able to reject a target update. If you use Outbound, where you have created the NAT binding as part of the registration, a target refresh can not be performed, because the signalling wouldn't reach the client behind the NAT anymore. You would need to perform a re-registration. Now, we could of course say that a client using Outbound shall not perform a target refresh in the first place. BUT, the same issue also apply to other registration-based NAT traversal mechanisms - in some cases the client behind the NAT may not even be aware of those. So, if we want to say that one cannot reject a target refresh we need to make sure we don't create a new cannot-reject-offer-in-PRACK type of problem... >I'm don't know if we are on quite the same page yet. >Once accepted, I don't think a target refresh should be rolled back by anything. > >A key use case might be: > >I've started an reINVITE - one that might take awhile because it is trying to add media and the other end is alerting=20 >about that. > >While that is in progress I lose my IP address and need to target refresh. So what do I do? > >I think I send an UPDATE, which will be in the midst of the reINVITE transaction. I make it a simple one, in that it=20 >includes no o/a, its *just* a target refresh. In most cases, won't you use the same IP address for signalling and media? So, if you've lost it you would need to re-negotiate the media parameters also... I think it would be much better for the UAC to first cancel the re-INVITE, and then do the target refresh and re-start the o/a transaction. Performing target refreshes inside ongoing re-INVITEs are only going to cause problems - especially if you are not able to receive responses etc on the old address. Regards, Christer > Hi Paul, >=20 > > This will encourage using a *simple* request to do an essential=20 > target > refresh, rather than a complex one that has a chance of failing. >=20 > Yes, I agree with you. I think we can get what you are looking for by=20 > keeping the text that is currently in the draft (i.e., re-INVITEs=20 > remain atomic and an error response rolls everything back, including=20 > the target refresh), by adding a description of why piggybacking other > changes in a target refresh request is a bad idea (the new text would=20 > include a discussion on the Via problem and on legacy UASs responding=20 > with an error response even if changes have been executed), and by=20 > discouraging the use of re-INVITEs that update the target and perform=20 > other changes at the same time (we probably need to go as far as to=20 > say that one SHOULD NOT do it). >=20 > I agree with you that encouraging the use of "simple" requests will be > better than specifying complex behavior just to cover corner cases. >=20 > Thanks, >=20 > Gonzalo >=20 >=20 >=20 > Paul Kyzivat wrote: >> Gonzalo, >> >> I agree with all you say below, except at the very end about target=20 >> refresh. >> >> If target refreshes are to be accepted even if the request fails,=20 >> then it is possible to hijack a session even if authentication is=20 >> being used for signaling. >> >> IMO a target refresh must be ignored in at least *some* cases when=20 >> the request is rejected. We could enumerate these cases individually, >> or simply state that it will only be accepted if the request is accepted. >> (In case of reINVITE, that would be if it was accepted sufficiently=20 >> to return a 2xx or a 1xx.) >> >> This will encourage using a *simple* request to do an essential=20 >> target refresh, rather than a complex one that has a chance of failing. >> Perhaps it won't work in all cases, but such is life. >> >> Thanks, >> Paul >> >> Gonzalo Camarillo wrote: >>> Hi Paul, >>> >>> thanks for your comments. Answers inline: >>> >>> Paul Kyzivat wrote: >>>> Gonzalo, >>>> >>>> Thanks for doing this work! I do have some comments: >>>> >>>> Section 3/Figure 1 >>>> >>>> The figure shows a 6xx response. >>>> The text says that the UAS wants to reject the new offer. >>>> >>>> A UAS would probably not use a 6xx response to reject media. >>>> (I guess it might use 606, but 488 would be more appropriate.) In=20 >>>> fact, it probably would not reject the request at all, but rather=20 >>>> would just refuse the added media stream. >>>> >>>> The point being made doesn't require that the response be 6xx or=20 >>>> that it be with the purpose of refusing the media. So I think what=20 >>>> is needed here is to find a plausible example to make the point. >>>> >>>> A good one for the purpose here might be a 488 to reject the media, >>>> or a 401 response as another sort of reason for rejecting the=20 >>>> whole thing but wanting to preserve what there is. >>> >>> yes, I agree that a 488 response would be more appropriate. I will=20 >>> change that in the draft. >>> >>>> >>>> Section 5: >>>> >>>>> A change to the session state is considered to have been executed >>>>> when the new media parameters are being used. Therefore, a=20 >>>>> change to >>>>> a stream subject to preconditions [RFC4032] is considered to have >>>>> been executed when the new media parameters start being used; not >>>>> when the preconditions for the stream are met. Unsurprisingly, the >>>>> UAS considers the new parameters to be in use when it actually=20 >>>>> starts >>>>> using them.=20 >>>> >>>> I'm not entirely following this. I think there may be an assumption >>>> here that the UAC is the offerer and the UAS the answerer. I'm=20 >>>> guessing you are saying that the answerer considers the new=20 >>>> parameters to be in use when it actually starts using them. >>>> >>>> Since this section is about the UAS (for the reinvite), this point=20 >>>> is probably that when the UAS is also the answerer it can decide=20 >>>> when the new media is in use based on when it starts using them. >>>> >>>> But what happens when the UAS is the offerer? In that case I think=20 >>>> it must assume the media is in use as soon as it is offered. But=20 >>>> maybe that isn't always the case with preconditions. I don't think=20 >>>> it can wait till it receives media, because media may be in flight=20 >>>> when it makes its decision. >>> >>> yes, the draft assumes that the UAS is the answerer because that was >>> the use case being discussed originally. However, you are right that >>> we should also cover the case where the UAS is the offerer. I will=20 >>> look into it and add text about it in the draft. >>> >>>> >>>>> As described in Section 8.3.1 of RFC 3264 [RFC3264], the >>>>> UAC considers the new parameters to be in use when media is=20 >>>>> received >>>>> in the new port, which should be interpreted as follows: >>>>> >>>>> Received, in this case, means that the media is passed to a=20 >>>>> media >>>>> sink. This means that if there is a playout buffer, the agent >>>>> would continue to listen on the old port until the media on the >>>>> new port reached the top of the playout buffer. At that=20 >>>>> time, it >>>>> MAY cease listening for media on the old port. >>>> >>>> I don't know what the above has to do with the behavior of the UAS. >>> >>> The UAC needs to know when the new parameters are in use in order to >>> implement the normative behavior in Section 6: >>> >>> ... a UAC that receives an error response to a re-INVITE for which >>> changes have been already executed ... >>> >>> In any case, I will clarify all this when I write the text about the >>> UAS being the offerer because this type of behavior has to do with=20 >>> being the offerer or the answerer, not the UAC or the UAS. >>> >>> >>>>> 9. Clarifications on Target Refresh Requests >>> >>> the current text is a straw man that puts target refreshes in the=20 >>> same category as any other change. The other option we talked about=20 >>> in the past was to special case them so that they are treated=20 >>> differently. You seem to like the latter option better. What do you=20 >>> think about the following text? >>> >>> >>>
>> Requests" >>> anchor=3D"sec-atom"> >>> >>> The remote target of a dialog is a special type of state information >>> because of its essential role in the exchange of SIP messages=20 >>> between UAs in a dialog. A UA involved in a dialog receives the=20 >>> remote target of the dialog from the remote UA. The UA uses the=20 >>> remote target to send SIP requests to the remote UA. >>> >>> >>> The remote target is a piece of state information that is not meant=20 >>> to be negotiated. When a UAC changes its address, the UAC simply=20 >>> communicates its new address to the UAS in order to remain reachable >>> by the UAS. As described in , a UAS=20 >>> starts using the new remote target as soon as the target refresh=20 >>> request is received, regardless of the response the UAS generates to >>> that request. That is, even if the UAS generates an error response=20 >>> to the target refresh request, the UAS needs to update the dialog's=20 >>> remote target URI. >>> >>> >>> The fact that a target refresh request updates the remote target=20 >>> regardless of the response it triggers implies that target refresh=20 >>> requests are not atomic. That is, an error response to a target=20 >>> refresh request will keep all changes associated to the request from >>> being performed except for the refresh of the remote target, which=20 >>> will be performed anyway. >>> >>>
>>> >>> >>> Cheers, >>> >>> Gonzalo >>> >=20 >=20 _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Fri Jul 24 06:16:39 2009 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 E22923A6C49 for ; Fri, 24 Jul 2009 06:16:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.337 X-Spam-Level: X-Spam-Status: No, score=-6.337 tagged_above=-999 required=5 tests=[AWL=0.263, 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 ZEfYotu46vvE for ; Fri, 24 Jul 2009 06:16:38 -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 F0E1E3A67E3 for ; Fri, 24 Jul 2009 06:16:37 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEALJQaUpAZnmf/2dsb2JhbAC6SYglkGYFgj+BTg X-IronPort-AV: E=Sophos;i="4.43,264,1246838400"; d="scan'208";a="51654778" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by rtp-iport-2.cisco.com with ESMTP; 24 Jul 2009 13:13:48 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6ODDmle031574; Fri, 24 Jul 2009 09:13:48 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6ODDmGc028745; Fri, 24 Jul 2009 13:13:48 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 09:13:48 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 09:13:47 -0400 Message-ID: <4A69B38B.3040602@cisco.com> Date: Fri, 24 Jul 2009 09:13:47 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Christer Holmberg References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com><4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com><4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 24 Jul 2009 13:13:48.0013 (UTC) FILETIME=[946E49D0:01CA0C60] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11417; t=1248441228; x=1249305228; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20New=20revision=20of=20the=2 0re-INVITE=20handling=20draft |Sender:=20 |To:=20Christer=20Holmberg=20; bh=WPR7qAcI6h3LkhGcN+OeV4GtOc+7ky8PEPd2AYXbaso=; b=phKX0b1/Idmv5fMN1o9coYQLqSmKQhphuckcgz7gjwL+N5ysThE+M3o7Pl m4XKfEhPNBMm+iHiP3GChM20uGHY2tYeCqZnJ9Lg1UFpcn4gnIxmYMpVGqAw GVSwNXaJrz; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: gao.yang2@zte.com.cn, SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 24 Jul 2009 13:16:40 -0000 Christer Holmberg wrote: > Hi, > > I am just re-booting after my summer vacation, and I have NOT been able > to read all e-mails in this thread yet. So, I appologize if something > has been discussed. > > Regarding the proposal to not be able to reject a target update. If you > use Outbound, where you have created the NAT binding as part of the > registration, a target refresh can not be performed, because the > signalling wouldn't reach the client behind the NAT anymore. You would > need to perform a re-registration. > > Now, we could of course say that a client using Outbound shall not > perform a target refresh in the first place. BUT, the same issue also > apply to other registration-based NAT traversal mechanisms - in some > cases the client behind the NAT may not even be aware of those. > > So, if we want to say that one cannot reject a target refresh we need to > make sure we don't create a new cannot-reject-offer-in-PRACK type of > problem... First, I'm not saying you can't reject a target refresh. Recommending you shouldn't reject it if you have alternatives is not the same. For instance if you have an authorization failure then you should definitely reject it. >> I'm don't know if we are on quite the same page yet. >> Once accepted, I don't think a target refresh should be rolled back by > anything. >> A key use case might be: >> >> I've started an reINVITE - one that might take awhile because it is > trying to add media and the other end is alerting >> about that. >> >> While that is in progress I lose my IP address and need to target > refresh. So what do I do? >> I think I send an UPDATE, which will be in the midst of the reINVITE > transaction. I make it a simple one, in that it >> includes no o/a, its *just* a target refresh. > > In most cases, won't you use the same IP address for signalling and > media? So, if you've lost it you would need to re-negotiate the media > parameters also... Yes, you will probably need to renegotiate the media too. But that isn't quite as urgent. If need be it can wait until you have a working signaling path again. > I think it would be much better for the UAC to first cancel the > re-INVITE, and then do the target refresh and re-start the o/a > transaction. As I noted, if you have really lost your ip address, then while you can send the CANCEL, you won't get the final response to the reINVITE that was canceled. You can either send the CANCEL, wait the full timeout interval, then send a new target refresh, or you can send the target refresh first (so you know you have a working signaling path again), then send the CANCEL. OTOH, if there is overlap in address availability (e.g. your renew of the lease on your IP address was rejected but hasn't yet expired) then it indeed would be prudent to wait for a quiescent state and then send the refresh. Thanks, Paul > Performing target refreshes inside ongoing re-INVITEs are only going to > cause problems - especially if you are not able to receive responses etc > on the old address. > Regards, > > Christer > > > >> Hi Paul, >> >> > This will encourage using a *simple* request to do an essential >> target > refresh, rather than a complex one that has a chance of > failing. >> Yes, I agree with you. I think we can get what you are looking for by >> keeping the text that is currently in the draft (i.e., re-INVITEs >> remain atomic and an error response rolls everything back, including >> the target refresh), by adding a description of why piggybacking other > >> changes in a target refresh request is a bad idea (the new text would >> include a discussion on the Via problem and on legacy UASs responding >> with an error response even if changes have been executed), and by >> discouraging the use of re-INVITEs that update the target and perform >> other changes at the same time (we probably need to go as far as to >> say that one SHOULD NOT do it). >> >> I agree with you that encouraging the use of "simple" requests will be > >> better than specifying complex behavior just to cover corner cases. >> >> Thanks, >> >> Gonzalo >> >> >> >> Paul Kyzivat wrote: >>> Gonzalo, >>> >>> I agree with all you say below, except at the very end about target >>> refresh. >>> >>> If target refreshes are to be accepted even if the request fails, >>> then it is possible to hijack a session even if authentication is >>> being used for signaling. >>> >>> IMO a target refresh must be ignored in at least *some* cases when >>> the request is rejected. We could enumerate these cases individually, > >>> or simply state that it will only be accepted if the request is > accepted. >>> (In case of reINVITE, that would be if it was accepted sufficiently >>> to return a 2xx or a 1xx.) >>> >>> This will encourage using a *simple* request to do an essential >>> target refresh, rather than a complex one that has a chance of > failing. >>> Perhaps it won't work in all cases, but such is life. >>> >>> Thanks, >>> Paul >>> >>> Gonzalo Camarillo wrote: >>>> Hi Paul, >>>> >>>> thanks for your comments. Answers inline: >>>> >>>> Paul Kyzivat wrote: >>>>> Gonzalo, >>>>> >>>>> Thanks for doing this work! I do have some comments: >>>>> >>>>> Section 3/Figure 1 >>>>> >>>>> The figure shows a 6xx response. >>>>> The text says that the UAS wants to reject the new offer. >>>>> >>>>> A UAS would probably not use a 6xx response to reject media. >>>>> (I guess it might use 606, but 488 would be more appropriate.) In >>>>> fact, it probably would not reject the request at all, but rather >>>>> would just refuse the added media stream. >>>>> >>>>> The point being made doesn't require that the response be 6xx or >>>>> that it be with the purpose of refusing the media. So I think what >>>>> is needed here is to find a plausible example to make the point. >>>>> >>>>> A good one for the purpose here might be a 488 to reject the media, > >>>>> or a 401 response as another sort of reason for rejecting the >>>>> whole thing but wanting to preserve what there is. >>>> yes, I agree that a 488 response would be more appropriate. I will >>>> change that in the draft. >>>> >>>>> Section 5: >>>>> >>>>>> A change to the session state is considered to have been > executed >>>>>> when the new media parameters are being used. Therefore, a >>>>>> change to >>>>>> a stream subject to preconditions [RFC4032] is considered to > have >>>>>> been executed when the new media parameters start being used; > not >>>>>> when the preconditions for the stream are met. Unsurprisingly, > the >>>>>> UAS considers the new parameters to be in use when it actually >>>>>> starts >>>>>> using them. >>>>> I'm not entirely following this. I think there may be an assumption > >>>>> here that the UAC is the offerer and the UAS the answerer. I'm >>>>> guessing you are saying that the answerer considers the new >>>>> parameters to be in use when it actually starts using them. >>>>> >>>>> Since this section is about the UAS (for the reinvite), this point >>>>> is probably that when the UAS is also the answerer it can decide >>>>> when the new media is in use based on when it starts using them. >>>>> >>>>> But what happens when the UAS is the offerer? In that case I think >>>>> it must assume the media is in use as soon as it is offered. But >>>>> maybe that isn't always the case with preconditions. I don't think >>>>> it can wait till it receives media, because media may be in flight >>>>> when it makes its decision. >>>> yes, the draft assumes that the UAS is the answerer because that was > >>>> the use case being discussed originally. However, you are right that > >>>> we should also cover the case where the UAS is the offerer. I will >>>> look into it and add text about it in the draft. >>>> >>>>>> As described in Section 8.3.1 of RFC 3264 [RFC3264], the >>>>>> UAC considers the new parameters to be in use when media is >>>>>> received >>>>>> in the new port, which should be interpreted as follows: >>>>>> >>>>>> Received, in this case, means that the media is passed to a >>>>>> media >>>>>> sink. This means that if there is a playout buffer, the > agent >>>>>> would continue to listen on the old port until the media on > the >>>>>> new port reached the top of the playout buffer. At that >>>>>> time, it >>>>>> MAY cease listening for media on the old port. >>>>> I don't know what the above has to do with the behavior of the UAS. >>>> The UAC needs to know when the new parameters are in use in order to > >>>> implement the normative behavior in Section 6: >>>> >>>> ... a UAC that receives an error response to a re-INVITE for > which >>>> changes have been already executed ... >>>> >>>> In any case, I will clarify all this when I write the text about the > >>>> UAS being the offerer because this type of behavior has to do with >>>> being the offerer or the answerer, not the UAC or the UAS. >>>> >>>> >>>>>> 9. Clarifications on Target Refresh Requests >>>> the current text is a straw man that puts target refreshes in the >>>> same category as any other change. The other option we talked about >>>> in the past was to special case them so that they are treated >>>> differently. You seem to like the latter option better. What do you >>>> think about the following text? >>>> >>>> >>>>
>>> anchor="sec-atom"> >>>> >>>> The remote target of a dialog is a special type of state information > >>>> because of its essential role in the exchange of SIP messages >>>> between UAs in a dialog. A UA involved in a dialog receives the >>>> remote target of the dialog from the remote UA. The UA uses the >>>> remote target to send SIP requests to the remote UA. >>>> >>>> >>>> The remote target is a piece of state information that is not meant >>>> to be negotiated. When a UAC changes its address, the UAC simply >>>> communicates its new address to the UAS in order to remain reachable > >>>> by the UAS. As described in , a UAS >>>> starts using the new remote target as soon as the target refresh >>>> request is received, regardless of the response the UAS generates to > >>>> that request. That is, even if the UAS generates an error response >>>> to the target refresh request, the UAS needs to update the dialog's >>>> remote target URI. >>>> >>>> >>>> The fact that a target refresh request updates the remote target >>>> regardless of the response it triggers implies that target refresh >>>> requests are not atomic. That is, an error response to a target >>>> refresh request will keep all changes associated to the request from > >>>> being performed except for the refresh of the remote target, which >>>> will be performed anyway. >>>> >>>>
>>>> >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Fri Jul 24 06:47:18 2009 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 771193A6974 for ; Fri, 24 Jul 2009 06:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.449 X-Spam-Level: X-Spam-Status: No, score=-5.449 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 3aAQsOdba+T9 for ; Fri, 24 Jul 2009 06:47:17 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 5DBF73A677D for ; Fri, 24 Jul 2009 06:47:15 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-ca-4a69b759fe0e Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id FE.69.00514.957B96A4; Fri, 24 Jul 2009 15:30:01 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 15:30:00 +0200 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: Fri, 24 Jul 2009 15:30:00 +0200 Message-ID: In-Reply-To: <4A69B38B.3040602@cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] New revision of the re-INVITE handling draft Thread-Index: AcoMYJfueIX2c0PSS++zDPtibHoUbQAAJ1nw References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com><4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com><4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> <4A69B38B.3040602@cisco.com> From: "Christer Holmberg" To: "Paul Kyzivat" X-OriginalArrivalTime: 24 Jul 2009 13:30:00.0948 (UTC) FILETIME=[D8586340:01CA0C62] X-Brightmail-Tracker: AAAAAA== Cc: gao.yang2@zte.com.cn, SIPCORE , Gonzalo Camarillo Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 24 Jul 2009 13:47:18 -0000 Hi,=20 >> I am just re-booting after my summer vacation, and I have NOT been=20 >> able to read all e-mails in this thread yet. So, I appologize if=20 >> something has been discussed. >>=20 >> Regarding the proposal to not be able to reject a target update. If=20 >> you use Outbound, where you have created the NAT binding as part of=20 >> the registration, a target refresh can not be performed, because the=20 >> signalling wouldn't reach the client behind the NAT anymore. You would=20 >> need to perform a re-registration. >>=20 >> Now, we could of course say that a client using Outbound shall not=20 >> perform a target refresh in the first place. BUT, the same issue also >> apply to other registration-based NAT traversal mechanisms - in some=20 >> cases the client behind the NAT may not even be aware of those. >>=20 >> So, if we want to say that one cannot reject a target refresh we need >> to make sure we don't create a new cannot-reject-offer-in-PRACK type=20 >> of problem... > >First, I'm not saying you can't reject a target refresh. I wasn't directly arguing against you, just giving some general input :) >Recommending you shouldn't reject it if you have alternatives is not the same. For instance if you have an authorization >failure then you should definitely reject it. Yes. So, just for me to catch up: the current proposal is that a failed re-INVITE would not rollback a target refresh that has been sucessfully performed (e.g. using UPDATE)? >>> I'm don't know if we are on quite the same page yet. >>> Once accepted, I don't think a target refresh should be rolled back=20 >>> by anything. >>> A key use case might be: >>> >>> I've started an reINVITE - one that might take awhile because it is trying to add media and the other end is alerting >>> about that. >>> >>> While that is in progress I lose my IP address and need to target refresh. So what do I do? >>> I think I send an UPDATE, which will be in the midst of the reINVITE transaction. I make it a simple one, in that it >>> includes no o/a, its *just* a target refresh. >>=20 >>In most cases, won't you use the same IP address for signalling and media? So, if you've lost it you would need to re- >>negotiate the media parameters also... > >Yes, you will probably need to renegotiate the media too. But that isn't quite as urgent. If need be it can wait until=20 >you have a working signaling path again. True. But, if you are using ICE, or some other media plane procedures, those won't work anymore. >>I think it would be much better for the UAC to first cancel the re-INVITE, and then do the target refresh and re-start=20 >>the o/a transaction. > >As I noted, if you have really lost your ip address, then while you can send the CANCEL, you won't get the final response=20 >to the reINVITE that was canceled. You won't get 18x responses, and final responses, either.. And, if you are still performing re-transmission of something which was originally sent from the old address, can you switch those to the new address just like that? >OTOH, if there is overlap in address availability (e.g. your renew of the lease on your IP address was rejected but=20 >hasn't yet expired) then it indeed would be prudent to wait for a quiescent state and then send the refresh. If you can't use the old IP address anymore (e.g. because you lost it), aren't you going to have to first do a re-registration in any case? Trying to fix things with a target refresh - especially in the middle of anohter negotiation procedure - is not going to work, I am pretty sure of... Regards, Christer > Performing target refreshes inside ongoing re-INVITEs are only going=20 > to cause problems - especially if you are not able to receive=20 > responses etc on the old address. > Regards, >=20 > Christer >=20 >=20 >=20 >> Hi Paul, >> >> > This will encourage using a *simple* request to do an essential=20 >> target > refresh, rather than a complex one that has a chance of > failing. >> Yes, I agree with you. I think we can get what you are looking for by >> keeping the text that is currently in the draft (i.e., re-INVITEs=20 >> remain atomic and an error response rolls everything back, including=20 >> the target refresh), by adding a description of why piggybacking=20 >> other >=20 >> changes in a target refresh request is a bad idea (the new text would >> include a discussion on the Via problem and on legacy UASs responding >> with an error response even if changes have been executed), and by=20 >> discouraging the use of re-INVITEs that update the target and perform >> other changes at the same time (we probably need to go as far as to=20 >> say that one SHOULD NOT do it). >> >> I agree with you that encouraging the use of "simple" requests will=20 >> be >=20 >> better than specifying complex behavior just to cover corner cases. >> >> Thanks, >> >> Gonzalo >> >> >> >> Paul Kyzivat wrote: >>> Gonzalo, >>> >>> I agree with all you say below, except at the very end about target=20 >>> refresh. >>> >>> If target refreshes are to be accepted even if the request fails,=20 >>> then it is possible to hijack a session even if authentication is=20 >>> being used for signaling. >>> >>> IMO a target refresh must be ignored in at least *some* cases when=20 >>> the request is rejected. We could enumerate these cases=20 >>> individually, >=20 >>> or simply state that it will only be accepted if the request is > accepted. >>> (In case of reINVITE, that would be if it was accepted sufficiently=20 >>> to return a 2xx or a 1xx.) >>> >>> This will encourage using a *simple* request to do an essential=20 >>> target refresh, rather than a complex one that has a chance of > failing. >>> Perhaps it won't work in all cases, but such is life. >>> >>> Thanks, >>> Paul >>> >>> Gonzalo Camarillo wrote: >>>> Hi Paul, >>>> >>>> thanks for your comments. Answers inline: >>>> >>>> Paul Kyzivat wrote: >>>>> Gonzalo, >>>>> >>>>> Thanks for doing this work! I do have some comments: >>>>> >>>>> Section 3/Figure 1 >>>>> >>>>> The figure shows a 6xx response. >>>>> The text says that the UAS wants to reject the new offer. >>>>> >>>>> A UAS would probably not use a 6xx response to reject media. >>>>> (I guess it might use 606, but 488 would be more appropriate.) In=20 >>>>> fact, it probably would not reject the request at all, but rather=20 >>>>> would just refuse the added media stream. >>>>> >>>>> The point being made doesn't require that the response be 6xx or=20 >>>>> that it be with the purpose of refusing the media. So I think what >>>>> is needed here is to find a plausible example to make the point. >>>>> >>>>> A good one for the purpose here might be a 488 to reject the=20 >>>>> media, >=20 >>>>> or a 401 response as another sort of reason for rejecting the=20 >>>>> whole thing but wanting to preserve what there is. >>>> yes, I agree that a 488 response would be more appropriate. I will=20 >>>> change that in the draft. >>>> >>>>> Section 5: >>>>> >>>>>> A change to the session state is considered to have been > executed >>>>>> when the new media parameters are being used. Therefore, a=20 >>>>>> change to >>>>>> a stream subject to preconditions [RFC4032] is considered to > have >>>>>> been executed when the new media parameters start being used; > not >>>>>> when the preconditions for the stream are met. =20 >>>>>> Unsurprisingly, > the >>>>>> UAS considers the new parameters to be in use when it actually >>>>>> starts >>>>>> using them.=20 >>>>> I'm not entirely following this. I think there may be an=20 >>>>> assumption >=20 >>>>> here that the UAC is the offerer and the UAS the answerer. I'm=20 >>>>> guessing you are saying that the answerer considers the new=20 >>>>> parameters to be in use when it actually starts using them. >>>>> >>>>> Since this section is about the UAS (for the reinvite), this point >>>>> is probably that when the UAS is also the answerer it can decide=20 >>>>> when the new media is in use based on when it starts using them. >>>>> >>>>> But what happens when the UAS is the offerer? In that case I think >>>>> it must assume the media is in use as soon as it is offered. But=20 >>>>> maybe that isn't always the case with preconditions. I don't think >>>>> it can wait till it receives media, because media may be in flight >>>>> when it makes its decision. >>>> yes, the draft assumes that the UAS is the answerer because that=20 >>>> was >=20 >>>> the use case being discussed originally. However, you are right=20 >>>> that >=20 >>>> we should also cover the case where the UAS is the offerer. I will=20 >>>> look into it and add text about it in the draft. >>>> >>>>>> As described in Section 8.3.1 of RFC 3264 [RFC3264], the >>>>>> UAC considers the new parameters to be in use when media is=20 >>>>>> received >>>>>> in the new port, which should be interpreted as follows: >>>>>> >>>>>> Received, in this case, means that the media is passed to a >>>>>> media >>>>>> sink. This means that if there is a playout buffer, the > agent >>>>>> would continue to listen on the old port until the media on > the >>>>>> new port reached the top of the playout buffer. At that=20 >>>>>> time, it >>>>>> MAY cease listening for media on the old port. >>>>> I don't know what the above has to do with the behavior of the UAS. >>>> The UAC needs to know when the new parameters are in use in order=20 >>>> to >=20 >>>> implement the normative behavior in Section 6: >>>> >>>> ... a UAC that receives an error response to a re-INVITE for > which >>>> changes have been already executed ... >>>> >>>> In any case, I will clarify all this when I write the text about=20 >>>> the >=20 >>>> UAS being the offerer because this type of behavior has to do with=20 >>>> being the offerer or the answerer, not the UAC or the UAS. >>>> >>>> >>>>>> 9. Clarifications on Target Refresh Requests >>>> the current text is a straw man that puts target refreshes in the=20 >>>> same category as any other change. The other option we talked about >>>> in the past was to special case them so that they are treated=20 >>>> differently. You seem to like the latter option better. What do you >>>> think about the following text? >>>> >>>> >>>>
>>> Requests" >>>> anchor=3D"sec-atom"> >>>> >>>> The remote target of a dialog is a special type of state=20 >>>> information >=20 >>>> because of its essential role in the exchange of SIP messages=20 >>>> between UAs in a dialog. A UA involved in a dialog receives the=20 >>>> remote target of the dialog from the remote UA. The UA uses the=20 >>>> remote target to send SIP requests to the remote UA. >>>> >>>> >>>> The remote target is a piece of state information that is not meant >>>> to be negotiated. When a UAC changes its address, the UAC simply=20 >>>> communicates its new address to the UAS in order to remain=20 >>>> reachable >=20 >>>> by the UAS. As described in , a UAS = >>>> starts using the new remote target as soon as the target refresh=20 >>>> request is received, regardless of the response the UAS generates=20 >>>> to >=20 >>>> that request. That is, even if the UAS generates an error response=20 >>>> to the target refresh request, the UAS needs to update the dialog's >>>> remote target URI. >>>> >>>> >>>> The fact that a target refresh request updates the remote target=20 >>>> regardless of the response it triggers implies that target refresh=20 >>>> requests are not atomic. That is, an error response to a target=20 >>>> refresh request will keep all changes associated to the request=20 >>>> from >=20 >>>> being performed except for the refresh of the remote target, which=20 >>>> will be performed anyway. >>>> >>>>
>>>> >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >> > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From ian.elz@ericsson.com Fri Jul 24 07:19:02 2009 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 9821028C1CF for ; Fri, 24 Jul 2009 07:19:02 -0700 (PDT) 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_SE=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 CTaV9gMIFpnx for ; Fri, 24 Jul 2009 07:19:01 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 9DD453A6B7C for ; Fri, 24 Jul 2009 07:18:47 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-e4-4a69b5c999e5 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id A2.C5.18827.9C5B96A4; Fri, 24 Jul 2009 15:23:21 +0200 (CEST) Received: from esealmw118.eemea.ericsson.se ([153.88.200.77]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 24 Jul 2009 15:23:07 +0200 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: Fri, 24 Jul 2009 15:23:06 +0200 Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F201CE4@zrc2hxm0.corp.nortel.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summary ofwhere we are Thread-Index: AcoMYeFFaTkZsdMKT9KQVPplAf1/Lw== References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com><4A5E5D5F.80908@cisco.com><1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com><4A5E6558.8000108@cisco.com><1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com><4A5E83CB.4090701@cisco.com><9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com>A<0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com>A<0D5F89FAC29E2C41B98A6A762007F5D0022A3616@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1F1A339E@zrc2hxm0.corp.nortel.com>A<0D5F89FAC29E2C41B98A6A762007F5D0022A3667@GBNTHT12009MSX.gb002.siemens.net><"1ECE0EB5038! 8174790F9 69 4F775 22CCF1F1 A39AF"@zrc2h xm0.corp.nortel.com>A<0D5F89FAC29E2C41B98A6A762007F5D0022A39CE@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F201CE4@zrc2hxm0.corp.nortel.com> From: "Ian Elz" To: "Francois Audet" , "SIPCORE" X-OriginalArrivalTime: 24 Jul 2009 13:23:07.0503 (UTC) FILETIME=[E1E9AFF0:01CA0C61] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summary ofwhere we are 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, 24 Jul 2009 14:19:02 -0000 Francois, I don't get to attend the IETF but your input on the privacy appear to cover the current situation. The only issue for 4424bis is to ensure that no changes are made which would preclude any future changes for 3rd party privacy. I would hate to have to come back with another revision to change something that with care now we could avoid. I don't think that there is anything at present which falls into this scenario. Enjoy Stockholm, it is a great place to visit (in summer). Ian=20 -----Original Message----- From: Francois Audet [mailto:audet@nortel.com]=20 Sent: 23 July 2009 05:57 To: SIPCORE Subject: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summary ofwhere we are Hi all, In preparation for the meeting next week, I'm writting a Summary of where we are with draft-barnes-sipcore-rfc4244bis and target-URI with regards to mailing list discussions. target-URI draft: The authors have stopped updating the target-URI to focus their=20 energies on the 4244bis draft instead. The idea is that once we solve the issues remaining with 4244bis, targetURI will be realigned with 4244bis. This means that the nature of targetURI draft may change: it could become a "use case" illustating use cases and call flows for various target URI scenarios. So participants are invited to NOT to read the target-URI draft. aor tag:=20 It seems that after much discussion on mailing list, after much initial confusion, people came around and agree that the definition from the draft does make sense, and does represent an AOR, as per the meaning in RFC 3261. Specifically, a URI entry is marked as "aor" when a proxy responsible for the URI recognizes it as an AOR (i.e., it uses it for a location server dip). One question asked on the list is how to treat IP addresses as domains? Can entries using IP addresses be AORs? The answer to that question is that when a domain uses an IP address as a domain name instead of a proper DNS domain name, yes, it can be considered an AOR. This will need to be clarified in an upcoming version. We might want to confirm this in Stockholm. There appears to be no other open issues regarding the aor tag. =20 rc / cc / rt tags:=20 These where created to be "precise" in their definition (i.e., mechanical),=20 but it appears that they all represent "fluff". In other words, they are not=20 normally used by algorithms. One idea being considered is "grouping" them=20 together under a single "fluff" tag (proper name to be determined).=20 No strong opinion against the grouping idea.=20 Another approach suggested was to not mark them at all (i.e., no tag). The concern about this approach is that in the current model, all rfc4244bis proxies/redirect servers will mark ALL entries, while RFC 4244 (old) will not, thereby allowing for distinguishing the entries, and allowing backward compatibility. We would therefore need to define another mechanism in parallel for each entry (e.g., another tag?) for=20 backward compatibility. Yet another approach (suggested last meeting), was to not include the "fluff" items at all. Again, this suffers from backward compatibility issues. There wasn't much discussion of this particular approach on=20 the list. A resolution for this particular issue, i.e., "rc/cc/rt" vs "fluff" vs "no tag" vs "no entry" is required. Seems like a good topic for Stockholm. mp tag:=20 In the current draft, the "mp" tag represent the "mapped-TO" address,=20 not the mapped-FROM address. Unlike the "fluff" parameters, it means a=20 "user different from the previous one".=20 target-URI algorithm for UAS: There were some questions on the list about algorithms for picking the "target URI parameter: is it the last "mp"-marked tag or is it the last "aor" tag. It seems that the answer to this question may be different based on what the assumptions people have about what is in fact a "target URI". It is not clear if we need to describe this in the draft, or even indeed if it actually makes a difference. privacy:=20 RFC 3323 was written with a 2-party model. Some of the wording in=20 the documents was changed from 4244 to adapt to individual=20 H-I entries. It is not clear if further enhancements to RFC 3323 are required. We are inviting people to look at it. I believe this is it. Thanks. From AUDET@nortel.com Fri Jul 24 08:59:07 2009 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 1C5F03A69F1 for ; Fri, 24 Jul 2009 08:59:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.346 X-Spam-Level: X-Spam-Status: No, score=-6.346 tagged_above=-999 required=5 tests=[AWL=0.253, 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 1GGz4VLtlt1s for ; Fri, 24 Jul 2009 08:59:06 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id E4A783A6B53 for ; Fri, 24 Jul 2009 08:59:05 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6OFXjH02704; Fri, 24 Jul 2009 15:33:45 GMT 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, 24 Jul 2009 10:35:20 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F24F280@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summary ofwhere we are thread-index: AcoMYeFFaTkZsdMKT9KQVPplAf1/LwAEmkZg References: <1ECE0EB50388174790F9694F77522CCF1F04FAEF@zrc2hxm0.corp.nortel.com><4A5E5D5F.80908@cisco.com><1ECE0EB50388174790F9694F77522CCF1F04FC34@zrc2hxm0.corp.nortel.com><4A5E6558.8000108@cisco.com><1ECE0EB50388174790F9694F77522CCF1F04FC5E@zrc2hxm0.corp.nortel.com><4A5E83CB.4090701@cisco.com><9ae56b1e0907160033l593c8eei2e67f3b11bdd1f44@mail.gmail.com><0D5F89FAC29E2C41B98A6A762007F5D0022653E6@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1F050A35@zrc2hxm0.corp.nortel.com>A<0D5F89FAC29E2C41B98A6A762007F5D002265A6B@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1F155AFF@zrc2hxm0.corp.nortel.com>A<0D5F89FAC29E2C41B98A6A762007F5D0022A3616@GBNTHT12009MSX.gb002.siemens.net><1ECE0EB50388174790F9694F77522CCF1F1A339E@zrc2hxm0.corp.nortel.com>A<0D5F89FAC29E2C41B98A6A762007F5D0022A3667@GBNTHT12009MSX.gb002.siemens.net><"1ECE0EB5038! 8174790F9 69 4F77! ! 522CCF1 F1A39AF"@zrc 2hxm0.corp.nortel.com>A<0D5F89FAC29E2C41B98A6A762007F5D0022A39CE@GBNTHT12009MSX.gb002.siemens.net> <1ECE0EB50388174790F9694F77522CCF1F201CE4@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Ian Elz" , "SIPCORE" Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis & target-URI: Summary ofwhere we are 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, 24 Jul 2009 15:59:07 -0000 Ok, thanks. I'm glad you are ok with the Privacy material.=20 > -----Original Message----- > From: Ian Elz [mailto:ian.elz@ericsson.com]=20 > Sent: Friday, July 24, 2009 06:23 > To: Audet, Francois (SC100:3055); SIPCORE > Subject: RE: [sipcore] draft-barnes-sipcore-rfc4244bis &=20 > target-URI: Summary ofwhere we are >=20 > Francois, >=20 > I don't get to attend the IETF but your input on the privacy=20 > appear to cover the current situation. >=20 > The only issue for 4424bis is to ensure that no changes are=20 > made which would preclude any future changes for 3rd party=20 > privacy. I would hate to have to come back with another=20 > revision to change something that with care now we could=20 > avoid. I don't think that there is anything at present which=20 > falls into this scenario. >=20 > Enjoy Stockholm, it is a great place to visit (in summer). >=20 > Ian=20 >=20 > -----Original Message----- > From: Francois Audet [mailto:audet@nortel.com] > Sent: 23 July 2009 05:57 > To: SIPCORE > Subject: [sipcore] draft-barnes-sipcore-rfc4244bis &=20 > target-URI: Summary ofwhere we are >=20 > Hi all, >=20 > In preparation for the meeting next week, I'm writting a=20 > Summary of where we are with draft-barnes-sipcore-rfc4244bis=20 > and target-URI with regards to mailing list discussions. >=20 > target-URI draft: >=20 > The authors have stopped updating the target-URI to focus their=20 > energies on the 4244bis draft instead. >=20 > The idea is that once we solve the issues remaining=20 > with 4244bis, > targetURI will be realigned with 4244bis. This means that the > nature of targetURI draft may change: it could become a "use > case" illustating use cases and call flows for various target > URI scenarios. >=20 > So participants are invited to NOT to read the target-URI draft. >=20 >=20 > aor tag:=20 >=20 > It seems that after much discussion on mailing list,=20 > after much initial > confusion, people came around and agree that the=20 > definition from the draft does > make sense, and does represent an AOR, as per the=20 > meaning in RFC 3261. >=20 > Specifically, a URI entry is marked as "aor" when a=20 > proxy responsible for > the URI recognizes it as an AOR (i.e., it uses it for a=20 > location server dip). >=20 > One question asked on the list is how to treat IP=20 > addresses as domains? > Can entries using IP addresses be AORs? >=20 > The answer to that question is that when a domain uses=20 > an IP address > as a domain name instead of a proper DNS domain name,=20 > yes, it can > be considered an AOR. This will need to be clarified in=20 > an upcoming version. >=20 > We might want to confirm this in Stockholm. There=20 > appears to be no other > open issues regarding the aor tag. >=20 > =20 > rc / cc / rt tags:=20 >=20 > These where created to be "precise" in their definition=20 > (i.e., mechanical),=20 > but it appears that they all represent "fluff". In=20 > other words, they are not=20 > normally used by algorithms. One idea being considered=20 > is "grouping" them=20 > together under a single "fluff" tag (proper name to be=20 > determined).=20 > No strong opinion against the grouping idea.=20 >=20 > Another approach suggested was to not mark them at all=20 > (i.e., no tag). > The concern about this approach is that in the current=20 > model, all > rfc4244bis proxies/redirect servers will mark ALL entries, while > RFC 4244 (old) will not, thereby allowing for=20 > distinguishing the entries, > and allowing backward compatibility. We would therefore=20 > need to define > another mechanism in parallel for each entry (e.g., another > tag?) for=20 > backward compatibility. >=20 > Yet another approach (suggested last meeting), was to=20 > not include the > "fluff" items at all. Again, this suffers from backward=20 > compatibility > issues. There wasn't much discussion of this particular=20 > approach on=20 > the list. >=20 > A resolution for this particular issue, i.e.,=20 > "rc/cc/rt" vs "fluff" vs > "no tag" vs "no entry" is required. Seems like a good=20 > topic for Stockholm. >=20 >=20 > mp tag:=20 >=20 > In the current draft, the "mp" tag represent the "mapped-TO" > address,=20 > not the mapped-FROM address. Unlike the "fluff"=20 > parameters, it means a=20 > "user different from the previous one".=20 >=20 >=20 > target-URI algorithm for UAS: >=20 > There were some questions on the list about algorithms=20 > for picking > the "target URI parameter: is it the last "mp"-marked=20 > tag or is it > the last "aor" tag. It seems that the answer to this=20 > question may > be different based on what the assumptions people have=20 > about what > is in fact a "target URI". It is not clear if we need=20 > to describe > this in the draft, or even indeed if it actually makes a > difference. >=20 >=20 > privacy:=20 >=20 > RFC 3323 was written with a 2-party model. Some of the=20 > wording in=20 > the documents was changed from 4244 to adapt to individual=20 > H-I entries. >=20 > It is not clear if further enhancements to RFC 3323 are=20 > required. > We are inviting people to look at it. >=20 > I believe this is it. >=20 > Thanks. >=20 >=20 From gao.yang2@zte.com.cn Sat Jul 25 05:19:16 2009 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 A98F63A6811 for ; Sat, 25 Jul 2009 05:19:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.07 X-Spam-Level: X-Spam-Status: No, score=-94.07 tagged_above=-999 required=5 tests=[AWL=-1.280, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 9axX18n6HC9q for ; Sat, 25 Jul 2009 05:19:14 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 864383A682D for ; Sat, 25 Jul 2009 05:19:11 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 91101727820181; Sat, 25 Jul 2009 20:05:26 +0800 (CST) Received: from [10.30.3.18] by [10.30.17.100] with StormMail ESMTP id 12290.6396279943; Sat, 25 Jul 2009 20:11:36 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse1.zte.com.cn with ESMTP id n6PCJIAR013301; Sat, 25 Jul 2009 20:19:18 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4A69B38B.3040602@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Sat, 25 Jul 2009 20:18:45 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-25 20:19:03, Serialize complete at 2009-07-25 20:19:03 Content-Type: multipart/alternative; boundary="=_alternative 0043A8BC482575FE_=" X-MAIL: mse1.zte.com.cn n6PCJIAR013301 Cc: SIPCORE , Gonzalo Camarillo Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ICBOZXcgcmV2aXNpb24gb2YgdGhlIHJl?= =?gb2312?b?LUlOVklURSBoYW5kbGluZyBkcmFmdA==?= 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, 25 Jul 2009 12:19:16 -0000 This is a multipart message in MIME format. --=_alternative 0043A8BC482575FE_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGksDQoNCkkgYW0gYXQgU3RvY2tob2xtIG5vdy4NCg0KSSBvbmNlIGFza2VkIFBhdWwgYWJvdXQg dGhpcyBJRVRGIG1lZXRpbmcuIEhlIHNhaWQgdGhhdCBoZSB3b3VsZCBiZSB0b28gDQpidXN5IHRv IGF0dGVuZCB0aGlzIHRpbWUuIEl0IGlzIGEgcGl0eS4NCg0KQW5kIGFzIHdlIGtub3csIHRoZXJl IGlzIGEgbWlsZXN0b25lIGZvciBjb3JyZWN0aW9uIG9mIFJGQzMyNjEuIEFuZCBJIA0KdGhpbmsg c2Vzc2lvbiBzdGF0ZSBhbmQgZGlhbG9nIHN0YXRlIGNvcnJlY3Rpb24gYXJlIGltcG9ydGFudCBw YXJ0cyBvZiANCnRoaXMgY29ycmVjdGlvbi4NCg0KQW5kIGlmIHdlIGNhbiBub3RpZnkgdGhlIHRh bGsgaW4gdGhlIG1lZXRpbmcgaW4gdGhlIG1haWxsaXN0IGFuZCBjb2xsZWN0IA0Kdmlld3BvaW50 IGZyb20gdGhlIG1haWxsaXN0IG9uIHRpbWUsIHdlIGNhbiBoYXZlIGEgdGFsayBhcyBpZiBwZW9w bGUgDQpjb25jZXJuaW5nIHRoaXMgdG9waWMgYXJlIG9uIHRoZSBzY2VuZS4gQW5kIHRoaXMgY2Fu IG1ha2UgdGhlIHRhbGsgZmFzdCANCmFuZCBlZmZlY3RpdmUuDQoNCklmIEdvbnphbG8gaGFzIHRp bWUsIGhlIGNhbiBiZSB0aGUgcHJvcGVyIHBlcnNvbiB0byB0YWtlIGNoYXJnZSBvZiB0aGlzIA0K dGFsay4NCg0KVGhhbmtzLg0KDQpHYW8NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT0NCiBaaXAgICAgOiAyMTAwMTINCiBUZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4Nikt MDI1LTUyODc3MjExDQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg0KDQpQYXVsIEt5eml2YXQgPHBreXppdmF0QGNp c2NvLmNvbT4gDQq3orz+yMs6ICBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMDktMDctMjQg MjE6MTMNCg0KytW8/sjLDQpDaHJpc3RlciBIb2xtYmVyZyA8Y2hyaXN0ZXIuaG9sbWJlcmdAZXJp Y3Nzb24uY29tPg0Ks63LzQ0KZ2FvLnlhbmcyQHp0ZS5jb20uY24sIFNJUENPUkUgPHNpcGNvcmVA aWV0Zi5vcmc+LCBHb256YWxvIENhbWFyaWxsbyANCjxnb256YWxvLmNhbWFyaWxsb0Blcmljc3Nv bi5jb20+DQrW98ziDQpSZTogW3NpcGNvcmVdIE5ldyByZXZpc2lvbiBvZiB0aGUgcmUtSU5WSVRF IGhhbmRsaW5nIGRyYWZ0DQoNCg0KDQoNCg0KDQoNCg0KQ2hyaXN0ZXIgSG9sbWJlcmcgd3JvdGU6 DQo+IEhpLA0KPiANCj4gSSBhbSBqdXN0IHJlLWJvb3RpbmcgYWZ0ZXIgbXkgc3VtbWVyIHZhY2F0 aW9uLCBhbmQgSSBoYXZlIE5PVCBiZWVuIGFibGUNCj4gdG8gcmVhZCBhbGwgZS1tYWlscyBpbiB0 aGlzIHRocmVhZCB5ZXQuIFNvLCBJIGFwcG9sb2dpemUgaWYgc29tZXRoaW5nDQo+IGhhcyBiZWVu IGRpc2N1c3NlZC4NCj4gDQo+IFJlZ2FyZGluZyB0aGUgcHJvcG9zYWwgdG8gbm90IGJlIGFibGUg dG8gcmVqZWN0IGEgdGFyZ2V0IHVwZGF0ZS4gSWYgeW91DQo+IHVzZSBPdXRib3VuZCwgd2hlcmUg eW91IGhhdmUgY3JlYXRlZCB0aGUgTkFUIGJpbmRpbmcgYXMgcGFydCBvZiB0aGUNCj4gcmVnaXN0 cmF0aW9uLCBhIHRhcmdldCByZWZyZXNoIGNhbiBub3QgYmUgcGVyZm9ybWVkLCBiZWNhdXNlIHRo ZQ0KPiBzaWduYWxsaW5nIHdvdWxkbid0IHJlYWNoIHRoZSBjbGllbnQgYmVoaW5kIHRoZSBOQVQg YW55bW9yZS4gWW91IHdvdWxkDQo+IG5lZWQgdG8gcGVyZm9ybSBhIHJlLXJlZ2lzdHJhdGlvbi4N Cj4gDQo+IE5vdywgd2UgY291bGQgb2YgY291cnNlIHNheSB0aGF0IGEgY2xpZW50IHVzaW5nIE91 dGJvdW5kIHNoYWxsIG5vdA0KPiBwZXJmb3JtIGEgdGFyZ2V0IHJlZnJlc2ggaW4gdGhlIGZpcnN0 IHBsYWNlLiBCVVQsIHRoZSBzYW1lIGlzc3VlIGFsc28NCj4gYXBwbHkgdG8gb3RoZXIgcmVnaXN0 cmF0aW9uLWJhc2VkIE5BVCB0cmF2ZXJzYWwgbWVjaGFuaXNtcyAtIGluIHNvbWUNCj4gY2FzZXMg dGhlIGNsaWVudCBiZWhpbmQgdGhlIE5BVCBtYXkgbm90IGV2ZW4gYmUgYXdhcmUgb2YgdGhvc2Uu DQo+IA0KPiBTbywgaWYgd2Ugd2FudCB0byBzYXkgdGhhdCBvbmUgY2Fubm90IHJlamVjdCBhIHRh cmdldCByZWZyZXNoIHdlIG5lZWQgdG8NCj4gbWFrZSBzdXJlIHdlIGRvbid0IGNyZWF0ZSBhIG5l dyBjYW5ub3QtcmVqZWN0LW9mZmVyLWluLVBSQUNLIHR5cGUgb2YNCj4gcHJvYmxlbS4uLg0KDQpG aXJzdCwgSSdtIG5vdCBzYXlpbmcgeW91IGNhbid0IHJlamVjdCBhIHRhcmdldCByZWZyZXNoLg0K UmVjb21tZW5kaW5nIHlvdSBzaG91bGRuJ3QgcmVqZWN0IGl0IGlmIHlvdSBoYXZlIGFsdGVybmF0 aXZlcyBpcyBub3QgdGhlIA0Kc2FtZS4gRm9yIGluc3RhbmNlIGlmIHlvdSBoYXZlIGFuIGF1dGhv cml6YXRpb24gZmFpbHVyZSB0aGVuIHlvdSBzaG91bGQgDQpkZWZpbml0ZWx5IHJlamVjdCBpdC4N Cg0KPj4gSSdtIGRvbid0IGtub3cgaWYgd2UgYXJlIG9uIHF1aXRlIHRoZSBzYW1lIHBhZ2UgeWV0 Lg0KPj4gT25jZSBhY2NlcHRlZCwgSSBkb24ndCB0aGluayBhIHRhcmdldCByZWZyZXNoIHNob3Vs ZCBiZSByb2xsZWQgYmFjayBieQ0KPiBhbnl0aGluZy4NCj4+IEEga2V5IHVzZSBjYXNlIG1pZ2h0 IGJlOg0KPj4NCj4+IEkndmUgc3RhcnRlZCBhbiByZUlOVklURSAtIG9uZSB0aGF0IG1pZ2h0IHRh a2UgYXdoaWxlIGJlY2F1c2UgaXQgaXMNCj4gdHJ5aW5nIHRvIGFkZCBtZWRpYSBhbmQgdGhlIG90 aGVyIGVuZCBpcyBhbGVydGluZyANCj4+IGFib3V0IHRoYXQuDQo+Pg0KPj4gV2hpbGUgdGhhdCBp cyBpbiBwcm9ncmVzcyBJIGxvc2UgbXkgSVAgYWRkcmVzcyBhbmQgbmVlZCB0byB0YXJnZXQNCj4g cmVmcmVzaC4gU28gd2hhdCBkbyBJIGRvPw0KPj4gSSB0aGluayBJIHNlbmQgYW4gVVBEQVRFLCB3 aGljaCB3aWxsIGJlIGluIHRoZSBtaWRzdCBvZiB0aGUgcmVJTlZJVEUNCj4gdHJhbnNhY3Rpb24u IEkgbWFrZSBpdCBhIHNpbXBsZSBvbmUsIGluIHRoYXQgaXQgDQo+PiBpbmNsdWRlcyBubyBvL2Es IGl0cyAqanVzdCogYSB0YXJnZXQgcmVmcmVzaC4NCj4gDQo+IEluIG1vc3QgY2FzZXMsIHdvbid0 IHlvdSB1c2UgdGhlIHNhbWUgSVAgYWRkcmVzcyBmb3Igc2lnbmFsbGluZyBhbmQNCj4gbWVkaWE/ IFNvLCBpZiB5b3UndmUgbG9zdCBpdCB5b3Ugd291bGQgbmVlZCB0byByZS1uZWdvdGlhdGUgdGhl IG1lZGlhDQo+IHBhcmFtZXRlcnMgYWxzby4uLg0KDQpZZXMsIHlvdSB3aWxsIHByb2JhYmx5IG5l ZWQgdG8gcmVuZWdvdGlhdGUgdGhlIG1lZGlhIHRvby4gQnV0IHRoYXQgaXNuJ3QgDQpxdWl0ZSBh cyB1cmdlbnQuIElmIG5lZWQgYmUgaXQgY2FuIHdhaXQgdW50aWwgeW91IGhhdmUgYSB3b3JraW5n IA0Kc2lnbmFsaW5nIHBhdGggYWdhaW4uDQoNCj4gSSB0aGluayBpdCB3b3VsZCBiZSBtdWNoIGJl dHRlciBmb3IgdGhlIFVBQyB0byBmaXJzdCBjYW5jZWwgdGhlDQo+IHJlLUlOVklURSwgYW5kIHRo ZW4gZG8gdGhlIHRhcmdldCByZWZyZXNoIGFuZCByZS1zdGFydCB0aGUgby9hDQo+IHRyYW5zYWN0 aW9uLg0KDQpBcyBJIG5vdGVkLCBpZiB5b3UgaGF2ZSByZWFsbHkgbG9zdCB5b3VyIGlwIGFkZHJl c3MsIHRoZW4gd2hpbGUgeW91IGNhbiANCnNlbmQgdGhlIENBTkNFTCwgeW91IHdvbid0IGdldCB0 aGUgZmluYWwgcmVzcG9uc2UgdG8gdGhlIHJlSU5WSVRFIHRoYXQgDQp3YXMgY2FuY2VsZWQuIFlv dSBjYW4gZWl0aGVyIHNlbmQgdGhlIENBTkNFTCwgd2FpdCB0aGUgZnVsbCB0aW1lb3V0IA0KaW50 ZXJ2YWwsIHRoZW4gc2VuZCBhIG5ldyB0YXJnZXQgcmVmcmVzaCwgb3IgeW91IGNhbiBzZW5kIHRo ZSB0YXJnZXQgDQpyZWZyZXNoIGZpcnN0IChzbyB5b3Uga25vdyB5b3UgaGF2ZSBhIHdvcmtpbmcg c2lnbmFsaW5nIHBhdGggYWdhaW4pLCANCnRoZW4gc2VuZCB0aGUgQ0FOQ0VMLg0KDQpPVE9ILCBp ZiB0aGVyZSBpcyBvdmVybGFwIGluIGFkZHJlc3MgYXZhaWxhYmlsaXR5IChlLmcuIHlvdXIgcmVu ZXcgb2YgDQp0aGUgbGVhc2Ugb24geW91ciBJUCBhZGRyZXNzIHdhcyByZWplY3RlZCBidXQgaGFz bid0IHlldCBleHBpcmVkKSB0aGVuIA0KaXQgaW5kZWVkIHdvdWxkIGJlIHBydWRlbnQgdG8gd2Fp dCBmb3IgYSBxdWllc2NlbnQgc3RhdGUgYW5kIHRoZW4gc2VuZCANCnRoZSByZWZyZXNoLg0KDQog ICAgICAgICAgICAgICAgIFRoYW5rcywNCiAgICAgICAgICAgICAgICAgUGF1bA0KDQo+IFBlcmZv cm1pbmcgdGFyZ2V0IHJlZnJlc2hlcyBpbnNpZGUgb25nb2luZyByZS1JTlZJVEVzIGFyZSBvbmx5 IGdvaW5nIHRvDQo+IGNhdXNlIHByb2JsZW1zIC0gZXNwZWNpYWxseSBpZiB5b3UgYXJlIG5vdCBh YmxlIHRvIHJlY2VpdmUgcmVzcG9uc2VzIGV0Yw0KPiBvbiB0aGUgb2xkIGFkZHJlc3MuDQoNCg0K DQo+IFJlZ2FyZHMsDQo+IA0KPiBDaHJpc3Rlcg0KPiANCj4gDQo+IA0KPj4gSGkgUGF1bCwNCj4+ DQo+PiAgPiBUaGlzIHdpbGwgZW5jb3VyYWdlIHVzaW5nIGEgKnNpbXBsZSogcmVxdWVzdCB0byBk byBhbiBlc3NlbnRpYWwgDQo+PiB0YXJnZXQgID4gcmVmcmVzaCwgcmF0aGVyIHRoYW4gYSBjb21w bGV4IG9uZSB0aGF0IGhhcyBhIGNoYW5jZSBvZg0KPiBmYWlsaW5nLg0KPj4gWWVzLCBJIGFncmVl IHdpdGggeW91LiBJIHRoaW5rIHdlIGNhbiBnZXQgd2hhdCB5b3UgYXJlIGxvb2tpbmcgZm9yIGJ5 IA0KPj4ga2VlcGluZyB0aGUgdGV4dCB0aGF0IGlzIGN1cnJlbnRseSBpbiB0aGUgZHJhZnQgKGku ZS4sIHJlLUlOVklURXMgDQo+PiByZW1haW4gYXRvbWljIGFuZCBhbiBlcnJvciByZXNwb25zZSBy b2xscyBldmVyeXRoaW5nIGJhY2ssIGluY2x1ZGluZyANCj4+IHRoZSB0YXJnZXQgcmVmcmVzaCks IGJ5IGFkZGluZyBhIGRlc2NyaXB0aW9uIG9mIHdoeSBwaWdneWJhY2tpbmcgb3RoZXINCj4gDQo+ PiBjaGFuZ2VzIGluIGEgdGFyZ2V0IHJlZnJlc2ggcmVxdWVzdCBpcyBhIGJhZCBpZGVhICh0aGUg bmV3IHRleHQgd291bGQgDQo+PiBpbmNsdWRlIGEgZGlzY3Vzc2lvbiBvbiB0aGUgVmlhIHByb2Js ZW0gYW5kIG9uIGxlZ2FjeSBVQVNzIHJlc3BvbmRpbmcgDQo+PiB3aXRoIGFuIGVycm9yIHJlc3Bv bnNlIGV2ZW4gaWYgY2hhbmdlcyBoYXZlIGJlZW4gZXhlY3V0ZWQpLCBhbmQgYnkgDQo+PiBkaXNj b3VyYWdpbmcgdGhlIHVzZSBvZiByZS1JTlZJVEVzIHRoYXQgdXBkYXRlIHRoZSB0YXJnZXQgYW5k IHBlcmZvcm0gDQo+PiBvdGhlciBjaGFuZ2VzIGF0IHRoZSBzYW1lIHRpbWUgKHdlIHByb2JhYmx5 IG5lZWQgdG8gZ28gYXMgZmFyIGFzIHRvIA0KPj4gc2F5IHRoYXQgb25lIFNIT1VMRCBOT1QgZG8g aXQpLg0KPj4NCj4+IEkgYWdyZWUgd2l0aCB5b3UgdGhhdCBlbmNvdXJhZ2luZyB0aGUgdXNlIG9m ICJzaW1wbGUiIHJlcXVlc3RzIHdpbGwgYmUNCj4gDQo+PiBiZXR0ZXIgdGhhbiBzcGVjaWZ5aW5n IGNvbXBsZXggYmVoYXZpb3IganVzdCB0byBjb3ZlciBjb3JuZXIgY2FzZXMuDQo+Pg0KPj4gVGhh bmtzLA0KPj4NCj4+IEdvbnphbG8NCj4+DQo+Pg0KPj4NCj4+IFBhdWwgS3l6aXZhdCB3cm90ZToN Cj4+PiBHb256YWxvLA0KPj4+DQo+Pj4gSSBhZ3JlZSB3aXRoIGFsbCB5b3Ugc2F5IGJlbG93LCBl eGNlcHQgYXQgdGhlIHZlcnkgZW5kIGFib3V0IHRhcmdldCANCj4+PiByZWZyZXNoLg0KPj4+DQo+ Pj4gSWYgdGFyZ2V0IHJlZnJlc2hlcyBhcmUgdG8gYmUgYWNjZXB0ZWQgZXZlbiBpZiB0aGUgcmVx dWVzdCBmYWlscywgDQo+Pj4gdGhlbiBpdCBpcyBwb3NzaWJsZSB0byBoaWphY2sgYSBzZXNzaW9u IGV2ZW4gaWYgYXV0aGVudGljYXRpb24gaXMgDQo+Pj4gYmVpbmcgdXNlZCBmb3Igc2lnbmFsaW5n Lg0KPj4+DQo+Pj4gSU1PIGEgdGFyZ2V0IHJlZnJlc2ggbXVzdCBiZSBpZ25vcmVkIGluIGF0IGxl YXN0ICpzb21lKiBjYXNlcyB3aGVuIA0KPj4+IHRoZSByZXF1ZXN0IGlzIHJlamVjdGVkLiBXZSBj b3VsZCBlbnVtZXJhdGUgdGhlc2UgY2FzZXMgaW5kaXZpZHVhbGx5LA0KPiANCj4+PiBvciBzaW1w bHkgc3RhdGUgdGhhdCBpdCB3aWxsIG9ubHkgYmUgYWNjZXB0ZWQgaWYgdGhlIHJlcXVlc3QgaXMN Cj4gYWNjZXB0ZWQuDQo+Pj4gKEluIGNhc2Ugb2YgcmVJTlZJVEUsIHRoYXQgd291bGQgYmUgaWYg aXQgd2FzIGFjY2VwdGVkIHN1ZmZpY2llbnRseSANCj4+PiB0byByZXR1cm4gYSAyeHggb3IgYSAx eHguKQ0KPj4+DQo+Pj4gVGhpcyB3aWxsIGVuY291cmFnZSB1c2luZyBhICpzaW1wbGUqIHJlcXVl c3QgdG8gZG8gYW4gZXNzZW50aWFsIA0KPj4+IHRhcmdldCByZWZyZXNoLCByYXRoZXIgdGhhbiBh IGNvbXBsZXggb25lIHRoYXQgaGFzIGEgY2hhbmNlIG9mDQo+IGZhaWxpbmcuDQo+Pj4gUGVyaGFw cyBpdCB3b24ndCB3b3JrIGluIGFsbCBjYXNlcywgYnV0IHN1Y2ggaXMgbGlmZS4NCj4+Pg0KPj4+ ICAgICBUaGFua3MsDQo+Pj4gICAgIFBhdWwNCj4+Pg0KPj4+IEdvbnphbG8gQ2FtYXJpbGxvIHdy b3RlOg0KPj4+PiBIaSBQYXVsLA0KPj4+Pg0KPj4+PiB0aGFua3MgZm9yIHlvdXIgY29tbWVudHMu IEFuc3dlcnMgaW5saW5lOg0KPj4+Pg0KPj4+PiBQYXVsIEt5eml2YXQgd3JvdGU6DQo+Pj4+PiBH b256YWxvLA0KPj4+Pj4NCj4+Pj4+IFRoYW5rcyBmb3IgZG9pbmcgdGhpcyB3b3JrISBJIGRvIGhh dmUgc29tZSBjb21tZW50czoNCj4+Pj4+DQo+Pj4+PiBTZWN0aW9uIDMvRmlndXJlIDENCj4+Pj4+ DQo+Pj4+PiBUaGUgZmlndXJlIHNob3dzIGEgNnh4IHJlc3BvbnNlLg0KPj4+Pj4gVGhlIHRleHQg c2F5cyB0aGF0IHRoZSBVQVMgd2FudHMgdG8gcmVqZWN0IHRoZSBuZXcgb2ZmZXIuDQo+Pj4+Pg0K Pj4+Pj4gQSBVQVMgd291bGQgcHJvYmFibHkgbm90IHVzZSBhIDZ4eCByZXNwb25zZSB0byByZWpl Y3QgbWVkaWEuDQo+Pj4+PiAoSSBndWVzcyBpdCBtaWdodCB1c2UgNjA2LCBidXQgNDg4IHdvdWxk IGJlIG1vcmUgYXBwcm9wcmlhdGUuKSBJbiANCj4+Pj4+IGZhY3QsIGl0IHByb2JhYmx5IHdvdWxk IG5vdCByZWplY3QgdGhlIHJlcXVlc3QgYXQgYWxsLCBidXQgcmF0aGVyIA0KPj4+Pj4gd291bGQg anVzdCByZWZ1c2UgdGhlIGFkZGVkIG1lZGlhIHN0cmVhbS4NCj4+Pj4+DQo+Pj4+PiBUaGUgcG9p bnQgYmVpbmcgbWFkZSBkb2Vzbid0IHJlcXVpcmUgdGhhdCB0aGUgcmVzcG9uc2UgYmUgNnh4IG9y IA0KPj4+Pj4gdGhhdCBpdCBiZSB3aXRoIHRoZSBwdXJwb3NlIG9mIHJlZnVzaW5nIHRoZSBtZWRp YS4gU28gSSB0aGluayB3aGF0IA0KPj4+Pj4gaXMgbmVlZGVkIGhlcmUgaXMgdG8gZmluZCBhIHBs YXVzaWJsZSBleGFtcGxlIHRvIG1ha2UgdGhlIHBvaW50Lg0KPj4+Pj4NCj4+Pj4+IEEgZ29vZCBv bmUgZm9yIHRoZSBwdXJwb3NlIGhlcmUgbWlnaHQgYmUgYSA0ODggdG8gcmVqZWN0IHRoZSBtZWRp YSwNCj4gDQo+Pj4+PiBvciBhICA0MDEgcmVzcG9uc2UgYXMgYW5vdGhlciBzb3J0IG9mIHJlYXNv biBmb3IgcmVqZWN0aW5nIHRoZSANCj4+Pj4+IHdob2xlIHRoaW5nIGJ1dCB3YW50aW5nIHRvIHBy ZXNlcnZlIHdoYXQgdGhlcmUgaXMuDQo+Pj4+IHllcywgSSBhZ3JlZSB0aGF0IGEgNDg4IHJlc3Bv bnNlIHdvdWxkIGJlIG1vcmUgYXBwcm9wcmlhdGUuIEkgd2lsbCANCj4+Pj4gY2hhbmdlIHRoYXQg aW4gdGhlIGRyYWZ0Lg0KPj4+Pg0KPj4+Pj4gU2VjdGlvbiA1Og0KPj4+Pj4NCj4+Pj4+PiAgICBB IGNoYW5nZSB0byB0aGUgc2Vzc2lvbiBzdGF0ZSBpcyBjb25zaWRlcmVkIHRvIGhhdmUgYmVlbg0K PiBleGVjdXRlZA0KPj4+Pj4+ICAgIHdoZW4gdGhlIG5ldyBtZWRpYSBwYXJhbWV0ZXJzIGFyZSBi ZWluZyB1c2VkLiAgVGhlcmVmb3JlLCBhIA0KPj4+Pj4+IGNoYW5nZSB0bw0KPj4+Pj4+ICAgIGEg c3RyZWFtIHN1YmplY3QgdG8gcHJlY29uZGl0aW9ucyBbUkZDNDAzMl0gaXMgY29uc2lkZXJlZCB0 bw0KPiBoYXZlDQo+Pj4+Pj4gICAgYmVlbiBleGVjdXRlZCB3aGVuIHRoZSBuZXcgbWVkaWEgcGFy YW1ldGVycyBzdGFydCBiZWluZyB1c2VkOw0KPiBub3QNCj4+Pj4+PiAgICB3aGVuIHRoZSBwcmVj b25kaXRpb25zIGZvciB0aGUgc3RyZWFtIGFyZSBtZXQuICBVbnN1cnByaXNpbmdseSwNCj4gdGhl DQo+Pj4+Pj4gICAgVUFTIGNvbnNpZGVycyB0aGUgbmV3IHBhcmFtZXRlcnMgdG8gYmUgaW4gdXNl IHdoZW4gaXQgYWN0dWFsbHkgDQo+Pj4+Pj4gc3RhcnRzDQo+Pj4+Pj4gICAgdXNpbmcgdGhlbS4g DQo+Pj4+PiBJJ20gbm90IGVudGlyZWx5IGZvbGxvd2luZyB0aGlzLiBJIHRoaW5rIHRoZXJlIG1h eSBiZSBhbiBhc3N1bXB0aW9uDQo+IA0KPj4+Pj4gaGVyZSB0aGF0IHRoZSBVQUMgaXMgdGhlIG9m ZmVyZXIgYW5kIHRoZSBVQVMgdGhlIGFuc3dlcmVyLiBJJ20gDQo+Pj4+PiBndWVzc2luZyB5b3Ug YXJlIHNheWluZyB0aGF0IHRoZSBhbnN3ZXJlciBjb25zaWRlcnMgdGhlIG5ldyANCj4+Pj4+IHBh cmFtZXRlcnMgdG8gYmUgaW4gdXNlIHdoZW4gaXQgYWN0dWFsbHkgc3RhcnRzIHVzaW5nIHRoZW0u DQo+Pj4+Pg0KPj4+Pj4gU2luY2UgdGhpcyBzZWN0aW9uIGlzIGFib3V0IHRoZSBVQVMgKGZvciB0 aGUgcmVpbnZpdGUpLCB0aGlzIHBvaW50IA0KPj4+Pj4gaXMgcHJvYmFibHkgdGhhdCB3aGVuIHRo ZSBVQVMgaXMgYWxzbyB0aGUgYW5zd2VyZXIgaXQgY2FuIGRlY2lkZSANCj4+Pj4+IHdoZW4gdGhl IG5ldyBtZWRpYSBpcyBpbiB1c2UgYmFzZWQgb24gd2hlbiBpdCBzdGFydHMgdXNpbmcgdGhlbS4N Cj4+Pj4+DQo+Pj4+PiBCdXQgd2hhdCBoYXBwZW5zIHdoZW4gdGhlIFVBUyBpcyB0aGUgb2ZmZXJl cj8gSW4gdGhhdCBjYXNlIEkgdGhpbmsgDQo+Pj4+PiBpdCBtdXN0IGFzc3VtZSB0aGUgbWVkaWEg aXMgaW4gdXNlIGFzIHNvb24gYXMgaXQgaXMgb2ZmZXJlZC4gQnV0IA0KPj4+Pj4gbWF5YmUgdGhh dCBpc24ndCBhbHdheXMgdGhlIGNhc2Ugd2l0aCBwcmVjb25kaXRpb25zLiBJIGRvbid0IHRoaW5r IA0KPj4+Pj4gaXQgY2FuIHdhaXQgdGlsbCBpdCByZWNlaXZlcyBtZWRpYSwgYmVjYXVzZSBtZWRp YSBtYXkgYmUgaW4gZmxpZ2h0IA0KPj4+Pj4gd2hlbiBpdCBtYWtlcyBpdHMgZGVjaXNpb24uDQo+ Pj4+IHllcywgdGhlIGRyYWZ0IGFzc3VtZXMgdGhhdCB0aGUgVUFTIGlzIHRoZSBhbnN3ZXJlciBi ZWNhdXNlIHRoYXQgd2FzDQo+IA0KPj4+PiB0aGUgdXNlIGNhc2UgYmVpbmcgZGlzY3Vzc2VkIG9y aWdpbmFsbHkuIEhvd2V2ZXIsIHlvdSBhcmUgcmlnaHQgdGhhdA0KPiANCj4+Pj4gd2Ugc2hvdWxk IGFsc28gY292ZXIgdGhlIGNhc2Ugd2hlcmUgdGhlIFVBUyBpcyB0aGUgb2ZmZXJlci4gSSB3aWxs IA0KPj4+PiBsb29rIGludG8gaXQgYW5kIGFkZCB0ZXh0IGFib3V0IGl0IGluIHRoZSBkcmFmdC4N Cj4+Pj4NCj4+Pj4+PiAgICBBcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA4LjMuMSBvZiBSRkMgMzI2 NCBbUkZDMzI2NF0sIHRoZQ0KPj4+Pj4+ICAgIFVBQyBjb25zaWRlcnMgdGhlIG5ldyBwYXJhbWV0 ZXJzIHRvIGJlIGluIHVzZSB3aGVuIG1lZGlhIGlzIA0KPj4+Pj4+IHJlY2VpdmVkDQo+Pj4+Pj4g ICAgaW4gdGhlIG5ldyBwb3J0LCB3aGljaCBzaG91bGQgYmUgaW50ZXJwcmV0ZWQgYXMgZm9sbG93 czoNCj4+Pj4+Pg0KPj4+Pj4+ICAgICAgIFJlY2VpdmVkLCBpbiB0aGlzIGNhc2UsIG1lYW5zIHRo YXQgdGhlIG1lZGlhIGlzIHBhc3NlZCB0byBhIA0KPj4+Pj4+IG1lZGlhDQo+Pj4+Pj4gICAgICAg c2luay4gIFRoaXMgbWVhbnMgdGhhdCBpZiB0aGVyZSBpcyBhIHBsYXlvdXQgYnVmZmVyLCB0aGUN Cj4gYWdlbnQNCj4+Pj4+PiAgICAgICB3b3VsZCBjb250aW51ZSB0byBsaXN0ZW4gb24gdGhlIG9s ZCBwb3J0IHVudGlsIHRoZSBtZWRpYSBvbg0KPiB0aGUNCj4+Pj4+PiAgICAgICBuZXcgcG9ydCBy ZWFjaGVkIHRoZSB0b3Agb2YgdGhlIHBsYXlvdXQgYnVmZmVyLiAgQXQgdGhhdCANCj4+Pj4+PiB0 aW1lLCBpdA0KPj4+Pj4+ICAgICAgIE1BWSBjZWFzZSBsaXN0ZW5pbmcgZm9yIG1lZGlhIG9uIHRo ZSBvbGQgcG9ydC4NCj4+Pj4+IEkgZG9uJ3Qga25vdyB3aGF0IHRoZSBhYm92ZSBoYXMgdG8gZG8g d2l0aCB0aGUgYmVoYXZpb3Igb2YgdGhlIFVBUy4NCj4+Pj4gVGhlIFVBQyBuZWVkcyB0byBrbm93 IHdoZW4gdGhlIG5ldyBwYXJhbWV0ZXJzIGFyZSBpbiB1c2UgaW4gb3JkZXIgdG8NCj4gDQo+Pj4+ IGltcGxlbWVudCB0aGUgbm9ybWF0aXZlIGJlaGF2aW9yIGluIFNlY3Rpb24gNjoNCj4+Pj4NCj4+ Pj4gICAgLi4uIGEgVUFDIHRoYXQgcmVjZWl2ZXMgYW4gZXJyb3IgcmVzcG9uc2UgdG8gYSByZS1J TlZJVEUgZm9yDQo+IHdoaWNoDQo+Pj4+ICAgIGNoYW5nZXMgaGF2ZSBiZWVuIGFscmVhZHkgZXhl Y3V0ZWQgLi4uDQo+Pj4+DQo+Pj4+IEluIGFueSBjYXNlLCBJIHdpbGwgY2xhcmlmeSBhbGwgdGhp cyB3aGVuIEkgd3JpdGUgdGhlIHRleHQgYWJvdXQgdGhlDQo+IA0KPj4+PiBVQVMgYmVpbmcgdGhl IG9mZmVyZXIgYmVjYXVzZSB0aGlzIHR5cGUgb2YgYmVoYXZpb3IgaGFzIHRvIGRvIHdpdGggDQo+ Pj4+IGJlaW5nIHRoZSBvZmZlcmVyIG9yIHRoZSBhbnN3ZXJlciwgbm90IHRoZSBVQUMgb3IgdGhl IFVBUy4NCj4+Pj4NCj4+Pj4NCj4+Pj4+PiA5LiAgQ2xhcmlmaWNhdGlvbnMgb24gVGFyZ2V0IFJl ZnJlc2ggUmVxdWVzdHMNCj4+Pj4gdGhlIGN1cnJlbnQgdGV4dCBpcyBhIHN0cmF3IG1hbiB0aGF0 IHB1dHMgdGFyZ2V0IHJlZnJlc2hlcyBpbiB0aGUgDQo+Pj4+IHNhbWUgY2F0ZWdvcnkgYXMgYW55 IG90aGVyIGNoYW5nZS4gVGhlIG90aGVyIG9wdGlvbiB3ZSB0YWxrZWQgYWJvdXQgDQo+Pj4+IGlu IHRoZSBwYXN0IHdhcyB0byBzcGVjaWFsIGNhc2UgdGhlbSBzbyB0aGF0IHRoZXkgYXJlIHRyZWF0 ZWQgDQo+Pj4+IGRpZmZlcmVudGx5LiBZb3Ugc2VlbSB0byBsaWtlIHRoZSBsYXR0ZXIgb3B0aW9u IGJldHRlci4gV2hhdCBkbyB5b3UgDQo+Pj4+IHRoaW5rIGFib3V0IHRoZSBmb2xsb3dpbmcgdGV4 dD8NCj4+Pj4NCj4+Pj4NCj4+Pj4gPHNlY3Rpb24gdGl0bGU9IkNsYXJpZmljYXRpb24gb24gdGhl IEF0b21pY2l0eSBvZiBUYXJnZXQgUmVmcmVzaCANCj4+Pj4gUmVxdWVzdHMiDQo+Pj4+IGFuY2hv cj0ic2VjLWF0b20iPg0KPj4+PiA8dD4NCj4+Pj4gVGhlIHJlbW90ZSB0YXJnZXQgb2YgYSBkaWFs b2cgaXMgYSBzcGVjaWFsIHR5cGUgb2Ygc3RhdGUgaW5mb3JtYXRpb24NCj4gDQo+Pj4+IGJlY2F1 c2Ugb2YgaXRzIGVzc2VudGlhbCByb2xlIGluIHRoZSBleGNoYW5nZSBvZiBTSVAgbWVzc2FnZXMg DQo+Pj4+IGJldHdlZW4gVUFzIGluIGEgZGlhbG9nLiBBIFVBIGludm9sdmVkIGluIGEgZGlhbG9n IHJlY2VpdmVzIHRoZSANCj4+Pj4gcmVtb3RlIHRhcmdldCBvZiB0aGUgZGlhbG9nIGZyb20gdGhl IHJlbW90ZSBVQS4gVGhlIFVBIHVzZXMgdGhlIA0KPj4+PiByZW1vdGUgdGFyZ2V0IHRvIHNlbmQg U0lQIHJlcXVlc3RzIHRvIHRoZSByZW1vdGUgVUEuDQo+Pj4+IDwvdD4NCj4+Pj4gPHQ+DQo+Pj4+ IFRoZSByZW1vdGUgdGFyZ2V0IGlzIGEgcGllY2Ugb2Ygc3RhdGUgaW5mb3JtYXRpb24gdGhhdCBp cyBub3QgbWVhbnQgDQo+Pj4+IHRvIGJlIG5lZ290aWF0ZWQuIFdoZW4gYSBVQUMgY2hhbmdlcyBp dHMgYWRkcmVzcywgdGhlIFVBQyBzaW1wbHkgDQo+Pj4+IGNvbW11bmljYXRlcyBpdHMgbmV3IGFk ZHJlc3MgdG8gdGhlIFVBUyBpbiBvcmRlciB0byByZW1haW4gcmVhY2hhYmxlDQo+IA0KPj4+PiBi eSB0aGUgVUFTLiBBcyBkZXNjcmliZWQgaW4gPHhyZWYgdGFyZ2V0PSJzZWMtYmFjay1hdG9tIi8+ LCBhIFVBUyANCj4+Pj4gc3RhcnRzIHVzaW5nIHRoZSBuZXcgcmVtb3RlIHRhcmdldCBhcyBzb29u IGFzIHRoZSB0YXJnZXQgcmVmcmVzaCANCj4+Pj4gcmVxdWVzdCBpcyByZWNlaXZlZCwgcmVnYXJk bGVzcyBvZiB0aGUgcmVzcG9uc2UgdGhlIFVBUyBnZW5lcmF0ZXMgdG8NCj4gDQo+Pj4+IHRoYXQg cmVxdWVzdC4gVGhhdCBpcywgZXZlbiBpZiB0aGUgVUFTIGdlbmVyYXRlcyBhbiBlcnJvciByZXNw b25zZSANCj4+Pj4gdG8gdGhlIHRhcmdldCByZWZyZXNoIHJlcXVlc3QsIHRoZSBVQVMgbmVlZHMg dG8gdXBkYXRlIHRoZSBkaWFsb2cncyANCj4+Pj4gcmVtb3RlIHRhcmdldCBVUkkuDQo+Pj4+IDwv dD4NCj4+Pj4gPHQ+DQo+Pj4+IFRoZSBmYWN0IHRoYXQgYSB0YXJnZXQgcmVmcmVzaCByZXF1ZXN0 IHVwZGF0ZXMgdGhlIHJlbW90ZSB0YXJnZXQgDQo+Pj4+IHJlZ2FyZGxlc3Mgb2YgdGhlIHJlc3Bv bnNlIGl0IHRyaWdnZXJzIGltcGxpZXMgdGhhdCB0YXJnZXQgcmVmcmVzaCANCj4+Pj4gcmVxdWVz dHMgYXJlIG5vdCBhdG9taWMuIFRoYXQgaXMsIGFuIGVycm9yIHJlc3BvbnNlIHRvIGEgdGFyZ2V0 IA0KPj4+PiByZWZyZXNoIHJlcXVlc3Qgd2lsbCBrZWVwIGFsbCBjaGFuZ2VzIGFzc29jaWF0ZWQg dG8gdGhlIHJlcXVlc3QgZnJvbQ0KPiANCj4+Pj4gYmVpbmcgcGVyZm9ybWVkIGV4Y2VwdCBmb3Ig dGhlIHJlZnJlc2ggb2YgdGhlIHJlbW90ZSB0YXJnZXQsIHdoaWNoIA0KPj4+PiB3aWxsIGJlIHBl cmZvcm1lZCBhbnl3YXkuDQo+Pj4+IDwvdD4NCj4+Pj4gPC9zZWN0aW9uPg0KPj4+Pg0KPj4+Pg0K Pj4+PiBDaGVlcnMsDQo+Pj4+DQo+Pj4+IEdvbnphbG8NCj4+Pj4NCj4+DQo+IF9fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNpcGNvcmUgbWFpbGluZyBs aXN0DQo+IHNpcGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zaXBjb3JlDQo+IA0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnDQpodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg0KDQoNCg0KDQotLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRF IEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGluZm9ybWF0aW9uIGNvbnRhaW5lZCBp biB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBzZW5kZXIncyBvcmdhbml6YXRp b24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBu YW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kgYW5kIGFyZSBub3Qg cGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24g dG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQg YXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBp bmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlIGFkZHJlc3NlZC4gSWYgeW91IGhh dmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBwbGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5h dG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBh cmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVyLg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVu IHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 0043A8BC482575FE_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpLDwvZm9udD4NCjxicj4NCjxi cj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBhbSBhdCBTdG9ja2hvbG0gbm93Ljwv Zm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBvbmNlIGFz a2VkIFBhdWwgYWJvdXQgdGhpcyBJRVRGIG1lZXRpbmcuDQpIZSBzYWlkIHRoYXQgaGUgd291bGQg YmUgdG9vIGJ1c3kgdG8gYXR0ZW5kIHRoaXMgdGltZS4gSXQgaXMgYSBwaXR5LjwvZm9udD4NCjxi cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QW5kIGFzIHdlIGtub3csIHRo ZXJlIGlzIGEgbWlsZXN0b25lDQpmb3IgY29ycmVjdGlvbiBvZiBSRkMzMjYxLiBBbmQgSSB0aGlu ayBzZXNzaW9uIHN0YXRlIGFuZCBkaWFsb2cgc3RhdGUgY29ycmVjdGlvbg0KYXJlIGltcG9ydGFu dCBwYXJ0cyBvZiB0aGlzIGNvcnJlY3Rpb24uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJzYW5zLXNlcmlmIj5BbmQgaWYgd2UgY2FuIG5vdGlmeSB0aGUgdGFsayBpbiB0aGUN Cm1lZXRpbmcgaW4gdGhlIG1haWxsaXN0IGFuZCBjb2xsZWN0IHZpZXdwb2ludCBmcm9tIHRoZSBt YWlsbGlzdCBvbiB0aW1lLA0Kd2UgY2FuIGhhdmUgYSB0YWxrIGFzIGlmIHBlb3BsZSBjb25jZXJu aW5nIHRoaXMgdG9waWMgYXJlIG9uIHRoZSBzY2VuZS4NCkFuZCB0aGlzIGNhbiBtYWtlIHRoZSB0 YWxrIGZhc3QgYW5kIGVmZmVjdGl2ZS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZh Y2U9InNhbnMtc2VyaWYiPklmIEdvbnphbG8gaGFzIHRpbWUsIGhlIGNhbiBiZSB0aGUgcHJvcGVy DQpwZXJzb24gdG8gdGFrZSBjaGFyZ2Ugb2YgdGhpcyB0YWxrLjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzLjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+R2FvPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PTxicj4NCiBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0KIFRlbCAmbmJzcDsgJm5i c3A7OiA4NzIxMTxicj4NCiBUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3MjExPGJyPg0KIGVf bWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4N Cjx0ciB2YWxpZ249dG9wPg0KPHRkIHdpZHRoPTI2JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+PGI+UGF1bCBLeXppdmF0ICZsdDtwa3l6aXZhdEBjaXNjby5jb20mZ3Q7PC9iPg0KPC9m b250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO3Np cGNvcmUtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj4yMDA5LTA3LTI0IDIxOjEzPC9mb250Pg0KPHRkIHdpZHRoPTczJT4NCjx0YWJsZSB3 aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250 IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPkNocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5o b2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8 ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250 PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5nYW8ueWFuZzJAenRl LmNvbS5jbiwgU0lQQ09SRSAmbHQ7c2lwY29yZUBpZXRmLm9yZyZndDssDQpHb256YWxvIENhbWFy aWxsbyAmbHQ7Z29uemFsby5jYW1hcmlsbG9AZXJpY3Nzb24uY29tJmd0OzwvZm9udD4NCjx0ciB2 YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fu cy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+UmU6IFtzaXBjb3JlXSBOZXcgcmV2aXNpb24gb2YgdGhlIHJlLUlOVklURQ0KaGFuZGxp bmcgZHJhZnQ8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0K PHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48Zm9udCBz aXplPTI+PHR0Pjxicj4NCjxicj4NCkNocmlzdGVyIEhvbG1iZXJnIHdyb3RlOjxicj4NCiZndDsg SGksPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgYW0ganVzdCByZS1ib290aW5nIGFmdGVyIG15IHN1 bW1lciB2YWNhdGlvbiwgYW5kIEkgaGF2ZSBOT1QgYmVlbg0KYWJsZTxicj4NCiZndDsgdG8gcmVh ZCBhbGwgZS1tYWlscyBpbiB0aGlzIHRocmVhZCB5ZXQuIFNvLCBJIGFwcG9sb2dpemUgaWYgc29t ZXRoaW5nPGJyPg0KJmd0OyBoYXMgYmVlbiBkaXNjdXNzZWQuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IFJlZ2FyZGluZyB0aGUgcHJvcG9zYWwgdG8gbm90IGJlIGFibGUgdG8gcmVqZWN0IGEgdGFyZ2V0 IHVwZGF0ZS4gSWYNCnlvdTxicj4NCiZndDsgdXNlIE91dGJvdW5kLCB3aGVyZSB5b3UgaGF2ZSBj cmVhdGVkIHRoZSBOQVQgYmluZGluZyBhcyBwYXJ0IG9mIHRoZTxicj4NCiZndDsgcmVnaXN0cmF0 aW9uLCBhIHRhcmdldCByZWZyZXNoIGNhbiBub3QgYmUgcGVyZm9ybWVkLCBiZWNhdXNlIHRoZTxi cj4NCiZndDsgc2lnbmFsbGluZyB3b3VsZG4ndCByZWFjaCB0aGUgY2xpZW50IGJlaGluZCB0aGUg TkFUIGFueW1vcmUuIFlvdSB3b3VsZDxicj4NCiZndDsgbmVlZCB0byBwZXJmb3JtIGEgcmUtcmVn aXN0cmF0aW9uLjxicj4NCiZndDsgPGJyPg0KJmd0OyBOb3csIHdlIGNvdWxkIG9mIGNvdXJzZSBz YXkgdGhhdCBhIGNsaWVudCB1c2luZyBPdXRib3VuZCBzaGFsbCBub3Q8YnI+DQomZ3Q7IHBlcmZv cm0gYSB0YXJnZXQgcmVmcmVzaCBpbiB0aGUgZmlyc3QgcGxhY2UuIEJVVCwgdGhlIHNhbWUgaXNz dWUgYWxzbzxicj4NCiZndDsgYXBwbHkgdG8gb3RoZXIgcmVnaXN0cmF0aW9uLWJhc2VkIE5BVCB0 cmF2ZXJzYWwgbWVjaGFuaXNtcyAtIGluIHNvbWU8YnI+DQomZ3Q7IGNhc2VzIHRoZSBjbGllbnQg YmVoaW5kIHRoZSBOQVQgbWF5IG5vdCBldmVuIGJlIGF3YXJlIG9mIHRob3NlLjxicj4NCiZndDsg PGJyPg0KJmd0OyBTbywgaWYgd2Ugd2FudCB0byBzYXkgdGhhdCBvbmUgY2Fubm90IHJlamVjdCBh IHRhcmdldCByZWZyZXNoIHdlIG5lZWQNCnRvPGJyPg0KJmd0OyBtYWtlIHN1cmUgd2UgZG9uJ3Qg Y3JlYXRlIGEgbmV3IGNhbm5vdC1yZWplY3Qtb2ZmZXItaW4tUFJBQ0sgdHlwZQ0Kb2Y8YnI+DQom Z3Q7IHByb2JsZW0uLi48YnI+DQo8YnI+DQpGaXJzdCwgSSdtIG5vdCBzYXlpbmcgeW91IGNhbid0 IHJlamVjdCBhIHRhcmdldCByZWZyZXNoLjxicj4NClJlY29tbWVuZGluZyB5b3Ugc2hvdWxkbid0 IHJlamVjdCBpdCBpZiB5b3UgaGF2ZSBhbHRlcm5hdGl2ZXMgaXMgbm90IHRoZQ0KPGJyPg0Kc2Ft ZS4gRm9yIGluc3RhbmNlIGlmIHlvdSBoYXZlIGFuIGF1dGhvcml6YXRpb24gZmFpbHVyZSB0aGVu IHlvdSBzaG91bGQNCjxicj4NCmRlZmluaXRlbHkgcmVqZWN0IGl0Ljxicj4NCjxicj4NCiZndDsm Z3Q7IEknbSBkb24ndCBrbm93IGlmIHdlIGFyZSBvbiBxdWl0ZSB0aGUgc2FtZSBwYWdlIHlldC48 YnI+DQomZ3Q7Jmd0OyBPbmNlIGFjY2VwdGVkLCBJIGRvbid0IHRoaW5rIGEgdGFyZ2V0IHJlZnJl c2ggc2hvdWxkIGJlIHJvbGxlZA0KYmFjayBieTxicj4NCiZndDsgYW55dGhpbmcuPGJyPg0KJmd0 OyZndDsgQSBrZXkgdXNlIGNhc2UgbWlnaHQgYmU6PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyBJJ3ZlIHN0YXJ0ZWQgYW4gcmVJTlZJVEUgLSBvbmUgdGhhdCBtaWdodCB0YWtlIGF3aGlsZSBi ZWNhdXNlDQppdCBpczxicj4NCiZndDsgdHJ5aW5nIHRvIGFkZCBtZWRpYSBhbmQgdGhlIG90aGVy IGVuZCBpcyBhbGVydGluZyA8YnI+DQomZ3Q7Jmd0OyBhYm91dCB0aGF0Ljxicj4NCiZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsgV2hpbGUgdGhhdCBpcyBpbiBwcm9ncmVzcyBJIGxvc2UgbXkgSVAgYWRk cmVzcyBhbmQgbmVlZCB0byB0YXJnZXQ8YnI+DQomZ3Q7IHJlZnJlc2guIFNvIHdoYXQgZG8gSSBk bz88YnI+DQomZ3Q7Jmd0OyBJIHRoaW5rIEkgc2VuZCBhbiBVUERBVEUsIHdoaWNoIHdpbGwgYmUg aW4gdGhlIG1pZHN0IG9mIHRoZSByZUlOVklURTxicj4NCiZndDsgdHJhbnNhY3Rpb24uIEkgbWFr ZSBpdCBhIHNpbXBsZSBvbmUsIGluIHRoYXQgaXQgPGJyPg0KJmd0OyZndDsgaW5jbHVkZXMgbm8g by9hLCBpdHMgKmp1c3QqIGEgdGFyZ2V0IHJlZnJlc2guPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IElu IG1vc3QgY2FzZXMsIHdvbid0IHlvdSB1c2UgdGhlIHNhbWUgSVAgYWRkcmVzcyBmb3Igc2lnbmFs bGluZyBhbmQ8YnI+DQomZ3Q7IG1lZGlhPyBTbywgaWYgeW91J3ZlIGxvc3QgaXQgeW91IHdvdWxk IG5lZWQgdG8gcmUtbmVnb3RpYXRlIHRoZSBtZWRpYTxicj4NCiZndDsgcGFyYW1ldGVycyBhbHNv Li4uPGJyPg0KPGJyPg0KWWVzLCB5b3Ugd2lsbCBwcm9iYWJseSBuZWVkIHRvIHJlbmVnb3RpYXRl IHRoZSBtZWRpYSB0b28uIEJ1dCB0aGF0IGlzbid0DQo8YnI+DQpxdWl0ZSBhcyB1cmdlbnQuIElm IG5lZWQgYmUgaXQgY2FuIHdhaXQgdW50aWwgeW91IGhhdmUgYSB3b3JraW5nIDxicj4NCnNpZ25h bGluZyBwYXRoIGFnYWluLjxicj4NCjxicj4NCiZndDsgSSB0aGluayBpdCB3b3VsZCBiZSBtdWNo IGJldHRlciBmb3IgdGhlIFVBQyB0byBmaXJzdCBjYW5jZWwgdGhlPGJyPg0KJmd0OyByZS1JTlZJ VEUsIGFuZCB0aGVuIGRvIHRoZSB0YXJnZXQgcmVmcmVzaCBhbmQgcmUtc3RhcnQgdGhlIG8vYTxi cj4NCiZndDsgdHJhbnNhY3Rpb24uPGJyPg0KPGJyPg0KQXMgSSBub3RlZCwgaWYgeW91IGhhdmUg cmVhbGx5IGxvc3QgeW91ciBpcCBhZGRyZXNzLCB0aGVuIHdoaWxlIHlvdSBjYW4NCjxicj4NCnNl bmQgdGhlIENBTkNFTCwgeW91IHdvbid0IGdldCB0aGUgZmluYWwgcmVzcG9uc2UgdG8gdGhlIHJl SU5WSVRFIHRoYXQNCjxicj4NCndhcyBjYW5jZWxlZC4gWW91IGNhbiBlaXRoZXIgc2VuZCB0aGUg Q0FOQ0VMLCB3YWl0IHRoZSBmdWxsIHRpbWVvdXQgPGJyPg0KaW50ZXJ2YWwsIHRoZW4gc2VuZCBh IG5ldyB0YXJnZXQgcmVmcmVzaCwgb3IgeW91IGNhbiBzZW5kIHRoZSB0YXJnZXQgPGJyPg0KcmVm cmVzaCBmaXJzdCAoc28geW91IGtub3cgeW91IGhhdmUgYSB3b3JraW5nIHNpZ25hbGluZyBwYXRo IGFnYWluKSwgPGJyPg0KdGhlbiBzZW5kIHRoZSBDQU5DRUwuPGJyPg0KPGJyPg0KT1RPSCwgaWYg dGhlcmUgaXMgb3ZlcmxhcCBpbiBhZGRyZXNzIGF2YWlsYWJpbGl0eSAoZS5nLiB5b3VyIHJlbmV3 IG9mIDxicj4NCnRoZSBsZWFzZSBvbiB5b3VyIElQIGFkZHJlc3Mgd2FzIHJlamVjdGVkIGJ1dCBo YXNuJ3QgeWV0IGV4cGlyZWQpIHRoZW4NCjxicj4NCml0IGluZGVlZCB3b3VsZCBiZSBwcnVkZW50 IHRvIHdhaXQgZm9yIGEgcXVpZXNjZW50IHN0YXRlIGFuZCB0aGVuIHNlbmQNCjxicj4NCnRoZSBy ZWZyZXNoLjxicj4NCjxicj4NCiAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7DQpUaGFua3MsPGJyPg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsNClBhdWw8YnI+DQo8YnI+DQomZ3Q7IFBl cmZvcm1pbmcgdGFyZ2V0IHJlZnJlc2hlcyBpbnNpZGUgb25nb2luZyByZS1JTlZJVEVzIGFyZSBv bmx5IGdvaW5nDQp0bzxicj4NCiZndDsgY2F1c2UgcHJvYmxlbXMgLSBlc3BlY2lhbGx5IGlmIHlv dSBhcmUgbm90IGFibGUgdG8gcmVjZWl2ZSByZXNwb25zZXMNCmV0Yzxicj4NCiZndDsgb24gdGhl IG9sZCBhZGRyZXNzLjxicj4NCjxicj4NCjxicj4NCjxicj4NCiZndDsgUmVnYXJkcyw8YnI+DQom Z3Q7IDxicj4NCiZndDsgQ2hyaXN0ZXI8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7Jmd0OyBIaSBQYXVsLDxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgJm5ic3A7 Jmd0OyBUaGlzIHdpbGwgZW5jb3VyYWdlIHVzaW5nIGEgKnNpbXBsZSogcmVxdWVzdCB0byBkbw0K YW4gZXNzZW50aWFsIDxicj4NCiZndDsmZ3Q7IHRhcmdldCAmbmJzcDsmZ3Q7IHJlZnJlc2gsIHJh dGhlciB0aGFuIGEgY29tcGxleCBvbmUgdGhhdCBoYXMNCmEgY2hhbmNlIG9mPGJyPg0KJmd0OyBm YWlsaW5nLjxicj4NCiZndDsmZ3Q7IFllcywgSSBhZ3JlZSB3aXRoIHlvdS4gSSB0aGluayB3ZSBj YW4gZ2V0IHdoYXQgeW91IGFyZSBsb29raW5nDQpmb3IgYnkgPGJyPg0KJmd0OyZndDsga2VlcGlu ZyB0aGUgdGV4dCB0aGF0IGlzIGN1cnJlbnRseSBpbiB0aGUgZHJhZnQgKGkuZS4sIHJlLUlOVklU RXMNCjxicj4NCiZndDsmZ3Q7IHJlbWFpbiBhdG9taWMgYW5kIGFuIGVycm9yIHJlc3BvbnNlIHJv bGxzIGV2ZXJ5dGhpbmcgYmFjaywgaW5jbHVkaW5nDQo8YnI+DQomZ3Q7Jmd0OyB0aGUgdGFyZ2V0 IHJlZnJlc2gpLCBieSBhZGRpbmcgYSBkZXNjcmlwdGlvbiBvZiB3aHkgcGlnZ3liYWNraW5nDQpv dGhlcjxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsgY2hhbmdlcyBpbiBhIHRhcmdldCByZWZyZXNo IHJlcXVlc3QgaXMgYSBiYWQgaWRlYSAodGhlIG5ldyB0ZXh0DQp3b3VsZCA8YnI+DQomZ3Q7Jmd0 OyBpbmNsdWRlIGEgZGlzY3Vzc2lvbiBvbiB0aGUgVmlhIHByb2JsZW0gYW5kIG9uIGxlZ2FjeSBV QVNzIHJlc3BvbmRpbmcNCjxicj4NCiZndDsmZ3Q7IHdpdGggYW4gZXJyb3IgcmVzcG9uc2UgZXZl biBpZiBjaGFuZ2VzIGhhdmUgYmVlbiBleGVjdXRlZCksIGFuZA0KYnkgPGJyPg0KJmd0OyZndDsg ZGlzY291cmFnaW5nIHRoZSB1c2Ugb2YgcmUtSU5WSVRFcyB0aGF0IHVwZGF0ZSB0aGUgdGFyZ2V0 IGFuZA0KcGVyZm9ybSA8YnI+DQomZ3Q7Jmd0OyBvdGhlciBjaGFuZ2VzIGF0IHRoZSBzYW1lIHRp bWUgKHdlIHByb2JhYmx5IG5lZWQgdG8gZ28gYXMgZmFyDQphcyB0byA8YnI+DQomZ3Q7Jmd0OyBz YXkgdGhhdCBvbmUgU0hPVUxEIE5PVCBkbyBpdCkuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyBJIGFncmVlIHdpdGggeW91IHRoYXQgZW5jb3VyYWdpbmcgdGhlIHVzZSBvZiAmcXVvdDtzaW1w bGUmcXVvdDsNCnJlcXVlc3RzIHdpbGwgYmU8YnI+DQomZ3Q7IDxicj4NCiZndDsmZ3Q7IGJldHRl ciB0aGFuIHNwZWNpZnlpbmcgY29tcGxleCBiZWhhdmlvciBqdXN0IHRvIGNvdmVyIGNvcm5lciBj YXNlcy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7IEdvbnphbG88YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyBQYXVsIEt5eml2YXQgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7 IEdvbnphbG8sPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEkgYWdyZWUgd2l0 aCBhbGwgeW91IHNheSBiZWxvdywgZXhjZXB0IGF0IHRoZSB2ZXJ5IGVuZCBhYm91dA0KdGFyZ2V0 IDxicj4NCiZndDsmZ3Q7Jmd0OyByZWZyZXNoLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyBJZiB0YXJnZXQgcmVmcmVzaGVzIGFyZSB0byBiZSBhY2NlcHRlZCBldmVuIGlmIHRo ZSByZXF1ZXN0DQpmYWlscywgPGJyPg0KJmd0OyZndDsmZ3Q7IHRoZW4gaXQgaXMgcG9zc2libGUg dG8gaGlqYWNrIGEgc2Vzc2lvbiBldmVuIGlmIGF1dGhlbnRpY2F0aW9uDQppcyA8YnI+DQomZ3Q7 Jmd0OyZndDsgYmVpbmcgdXNlZCBmb3Igc2lnbmFsaW5nLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyBJTU8gYSB0YXJnZXQgcmVmcmVzaCBtdXN0IGJlIGlnbm9yZWQgaW4gYXQg bGVhc3QgKnNvbWUqIGNhc2VzDQp3aGVuIDxicj4NCiZndDsmZ3Q7Jmd0OyB0aGUgcmVxdWVzdCBp cyByZWplY3RlZC4gV2UgY291bGQgZW51bWVyYXRlIHRoZXNlIGNhc2VzIGluZGl2aWR1YWxseSw8 YnI+DQomZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyBvciBzaW1wbHkgc3RhdGUgdGhhdCBpdCB3aWxs IG9ubHkgYmUgYWNjZXB0ZWQgaWYgdGhlIHJlcXVlc3QNCmlzPGJyPg0KJmd0OyBhY2NlcHRlZC48 YnI+DQomZ3Q7Jmd0OyZndDsgKEluIGNhc2Ugb2YgcmVJTlZJVEUsIHRoYXQgd291bGQgYmUgaWYg aXQgd2FzIGFjY2VwdGVkIHN1ZmZpY2llbnRseQ0KPGJyPg0KJmd0OyZndDsmZ3Q7IHRvIHJldHVy biBhIDJ4eCBvciBhIDF4eC4pPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IFRo aXMgd2lsbCBlbmNvdXJhZ2UgdXNpbmcgYSAqc2ltcGxlKiByZXF1ZXN0IHRvIGRvIGFuIGVzc2Vu dGlhbA0KPGJyPg0KJmd0OyZndDsmZ3Q7IHRhcmdldCByZWZyZXNoLCByYXRoZXIgdGhhbiBhIGNv bXBsZXggb25lIHRoYXQgaGFzIGEgY2hhbmNlDQpvZjxicj4NCiZndDsgZmFpbGluZy48YnI+DQom Z3Q7Jmd0OyZndDsgUGVyaGFwcyBpdCB3b24ndCB3b3JrIGluIGFsbCBjYXNlcywgYnV0IHN1Y2gg aXMgbGlmZS48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNw OyBUaGFua3MsPGJyPg0KJmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgUGF1bDxicj4NCiZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBHb256YWxvIENhbWFyaWxsbyB3cm90ZTo8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7IEhpIFBhdWwsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDsgdGhhbmtzIGZvciB5b3VyIGNvbW1lbnRzLiBBbnN3ZXJzIGlubGluZTo8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBQYXVsIEt5eml2YXQgd3Jv dGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgR29uemFsbyw8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoYW5rcyBmb3IgZG9pbmcgdGhpcyB3 b3JrISBJIGRvIGhhdmUgc29tZSBjb21tZW50czo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFNlY3Rpb24gMy9GaWd1cmUgMTxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIGZpZ3VyZSBzaG93cyBh IDZ4eCByZXNwb25zZS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgdGV4dCBzYXlzIHRo YXQgdGhlIFVBUyB3YW50cyB0byByZWplY3QgdGhlIG5ldw0Kb2ZmZXIuPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBBIFVBUyB3b3VsZCBwcm9iYWJs eSBub3QgdXNlIGEgNnh4IHJlc3BvbnNlIHRvIHJlamVjdA0KbWVkaWEuPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsgKEkgZ3Vlc3MgaXQgbWlnaHQgdXNlIDYwNiwgYnV0IDQ4OCB3b3VsZCBiZSBt b3JlIGFwcHJvcHJpYXRlLikNCkluIDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGZhY3QsIGl0 IHByb2JhYmx5IHdvdWxkIG5vdCByZWplY3QgdGhlIHJlcXVlc3QgYXQNCmFsbCwgYnV0IHJhdGhl ciA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB3b3VsZCBqdXN0IHJlZnVzZSB0aGUgYWRkZWQg bWVkaWEgc3RyZWFtLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgVGhlIHBvaW50IGJlaW5nIG1hZGUgZG9lc24ndCByZXF1aXJlIHRoYXQgdGhlIHJl c3BvbnNlDQpiZSA2eHggb3IgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhhdCBpdCBiZSB3 aXRoIHRoZSBwdXJwb3NlIG9mIHJlZnVzaW5nIHRoZSBtZWRpYS4NClNvIEkgdGhpbmsgd2hhdCA8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpcyBuZWVkZWQgaGVyZSBpcyB0byBmaW5kIGEgcGxh dXNpYmxlIGV4YW1wbGUgdG8gbWFrZQ0KdGhlIHBvaW50Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgQSBnb29kIG9uZSBmb3IgdGhlIHB1cnBvc2Ug aGVyZSBtaWdodCBiZSBhIDQ4OCB0bw0KcmVqZWN0IHRoZSBtZWRpYSw8YnI+DQomZ3Q7IDxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG9yIGEgJm5ic3A7NDAxIHJlc3BvbnNlIGFzIGFub3RoZXIg c29ydCBvZiByZWFzb24NCmZvciByZWplY3RpbmcgdGhlIDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IHdob2xlIHRoaW5nIGJ1dCB3YW50aW5nIHRvIHByZXNlcnZlIHdoYXQgdGhlcmUgaXMuPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyB5ZXMsIEkgYWdyZWUgdGhhdCBhIDQ4OCByZXNwb25zZSB3b3Vs ZCBiZSBtb3JlIGFwcHJvcHJpYXRlLg0KSSB3aWxsIDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgY2hh bmdlIHRoYXQgaW4gdGhlIGRyYWZ0Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyBTZWN0aW9uIDU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwO0EgY2hhbmdlIHRvIHRoZSBzZXNz aW9uIHN0YXRlIGlzDQpjb25zaWRlcmVkIHRvIGhhdmUgYmVlbjxicj4NCiZndDsgZXhlY3V0ZWQ8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwO3doZW4gdGhlIG5ldyBt ZWRpYSBwYXJhbWV0ZXJzIGFyZQ0KYmVpbmcgdXNlZC4gJm5ic3A7VGhlcmVmb3JlLCBhIDxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBjaGFuZ2UgdG88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyZndDsgJm5ic3A7ICZuYnNwO2Egc3RyZWFtIHN1YmplY3QgdG8gcHJlY29uZGl0aW9ucw0K W1JGQzQwMzJdIGlzIGNvbnNpZGVyZWQgdG88YnI+DQomZ3Q7IGhhdmU8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwO2JlZW4gZXhlY3V0ZWQgd2hlbiB0aGUgbmV3IG1l ZGlhDQpwYXJhbWV0ZXJzIHN0YXJ0IGJlaW5nIHVzZWQ7PGJyPg0KJmd0OyBub3Q8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwO3doZW4gdGhlIHByZWNvbmRpdGlvbnMg Zm9yIHRoZSBzdHJlYW0NCmFyZSBtZXQuICZuYnNwO1Vuc3VycHJpc2luZ2x5LDxicj4NCiZndDsg dGhlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtVQVMgY29uc2lk ZXJzIHRoZSBuZXcgcGFyYW1ldGVycw0KdG8gYmUgaW4gdXNlIHdoZW4gaXQgYWN0dWFsbHkgPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHN0YXJ0czxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyAmbmJzcDsgJm5ic3A7dXNpbmcgdGhlbS4gPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgSSdtIG5vdCBlbnRpcmVseSBmb2xsb3dpbmcgdGhpcy4gSSB0aGluayB0aGVyZSBtYXkNCmJl IGFuIGFzc3VtcHRpb248YnI+DQomZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGhlcmUg dGhhdCB0aGUgVUFDIGlzIHRoZSBvZmZlcmVyIGFuZCB0aGUgVUFTIHRoZSBhbnN3ZXJlci4NCkkn bSA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBndWVzc2luZyB5b3UgYXJlIHNheWluZyB0aGF0 IHRoZSBhbnN3ZXJlciBjb25zaWRlcnMNCnRoZSBuZXcgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgcGFyYW1ldGVycyB0byBiZSBpbiB1c2Ugd2hlbiBpdCBhY3R1YWxseSBzdGFydHMgdXNpbmcN CnRoZW0uPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBTaW5jZSB0aGlzIHNlY3Rpb24gaXMgYWJvdXQgdGhlIFVBUyAoZm9yIHRoZSByZWludml0ZSks DQp0aGlzIHBvaW50IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGlzIHByb2JhYmx5IHRoYXQg d2hlbiB0aGUgVUFTIGlzIGFsc28gdGhlIGFuc3dlcmVyDQppdCBjYW4gZGVjaWRlIDxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdoZW4gdGhlIG5ldyBtZWRpYSBpcyBpbiB1c2UgYmFzZWQgb24g d2hlbiBpdCBzdGFydHMNCnVzaW5nIHRoZW0uPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBCdXQgd2hhdCBoYXBwZW5zIHdoZW4gdGhlIFVBUyBpcyB0 aGUgb2ZmZXJlcj8gSW4gdGhhdA0KY2FzZSBJIHRoaW5rIDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IGl0IG11c3QgYXNzdW1lIHRoZSBtZWRpYSBpcyBpbiB1c2UgYXMgc29vbiBhcyBpdCBpcw0K b2ZmZXJlZC4gQnV0IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1heWJlIHRoYXQgaXNuJ3Qg YWx3YXlzIHRoZSBjYXNlIHdpdGggcHJlY29uZGl0aW9ucy4NCkkgZG9uJ3QgdGhpbmsgPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXQgY2FuIHdhaXQgdGlsbCBpdCByZWNlaXZlcyBtZWRpYSwg YmVjYXVzZSBtZWRpYQ0KbWF5IGJlIGluIGZsaWdodCA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyB3aGVuIGl0IG1ha2VzIGl0cyBkZWNpc2lvbi48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHllcywg dGhlIGRyYWZ0IGFzc3VtZXMgdGhhdCB0aGUgVUFTIGlzIHRoZSBhbnN3ZXJlciBiZWNhdXNlDQp0 aGF0IHdhczxicj4NCiZndDsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyB0aGUgdXNlIGNhc2UgYmVp bmcgZGlzY3Vzc2VkIG9yaWdpbmFsbHkuIEhvd2V2ZXIsIHlvdQ0KYXJlIHJpZ2h0IHRoYXQ8YnI+ DQomZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgd2Ugc2hvdWxkIGFsc28gY292ZXIgdGhlIGNh c2Ugd2hlcmUgdGhlIFVBUyBpcyB0aGUgb2ZmZXJlci4NCkkgd2lsbCA8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7IGxvb2sgaW50byBpdCBhbmQgYWRkIHRleHQgYWJvdXQgaXQgaW4gdGhlIGRyYWZ0Ljxi cj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7 ICZuYnNwO0FzIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDguMy4xIG9mDQpSRkMgMzI2NCBbUkZDMzI2 NF0sIHRoZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7VUFDIGNv bnNpZGVycyB0aGUgbmV3IHBhcmFtZXRlcnMNCnRvIGJlIGluIHVzZSB3aGVuIG1lZGlhIGlzIDxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWNlaXZlZDxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7aW4gdGhlIG5ldyBwb3J0LCB3aGljaCBzaG91bGQgYmUN CmludGVycHJldGVkIGFzIGZvbGxvd3M6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFJlY2VpdmVk LCBpbiB0aGlzIGNhc2UsIG1lYW5zDQp0aGF0IHRoZSBtZWRpYSBpcyBwYXNzZWQgdG8gYSA8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbWVkaWE8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgc2luay4gJm5ic3A7VGhpcyBtZWFucyB0aGF0DQpp ZiB0aGVyZSBpcyBhIHBsYXlvdXQgYnVmZmVyLCB0aGU8YnI+DQomZ3Q7IGFnZW50PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHdvdWxkIGNvbnRpbnVl IHRvIGxpc3Rlbg0Kb24gdGhlIG9sZCBwb3J0IHVudGlsIHRoZSBtZWRpYSBvbjxicj4NCiZndDsg dGhlPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IG5l dyBwb3J0IHJlYWNoZWQgdGhlIHRvcA0Kb2YgdGhlIHBsYXlvdXQgYnVmZmVyLiAmbmJzcDtBdCB0 aGF0IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aW1lLCBpdDxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBNQVkgY2Vhc2UgbGlzdGVuaW5n IGZvciBtZWRpYQ0Kb24gdGhlIG9sZCBwb3J0Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEkg ZG9uJ3Qga25vdyB3aGF0IHRoZSBhYm92ZSBoYXMgdG8gZG8gd2l0aCB0aGUgYmVoYXZpb3INCm9m IHRoZSBVQVMuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBUaGUgVUFDIG5lZWRzIHRvIGtub3cgd2hl biB0aGUgbmV3IHBhcmFtZXRlcnMgYXJlIGluIHVzZQ0KaW4gb3JkZXIgdG88YnI+DQomZ3Q7IDxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsgaW1wbGVtZW50IHRoZSBub3JtYXRpdmUgYmVoYXZpb3IgaW4g U2VjdGlvbiA2Ojxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZu YnNwOyAmbmJzcDsuLi4gYSBVQUMgdGhhdCByZWNlaXZlcyBhbiBlcnJvciByZXNwb25zZQ0KdG8g YSByZS1JTlZJVEUgZm9yPGJyPg0KJmd0OyB3aGljaDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgJm5i c3A7ICZuYnNwO2NoYW5nZXMgaGF2ZSBiZWVuIGFscmVhZHkgZXhlY3V0ZWQgLi4uPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgSW4gYW55IGNhc2UsIEkgd2lsbCBj bGFyaWZ5IGFsbCB0aGlzIHdoZW4gSSB3cml0ZSB0aGUNCnRleHQgYWJvdXQgdGhlPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFVBUyBiZWluZyB0aGUgb2ZmZXJlciBiZWNhdXNlIHRo aXMgdHlwZSBvZiBiZWhhdmlvciBoYXMNCnRvIGRvIHdpdGggPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyBiZWluZyB0aGUgb2ZmZXJlciBvciB0aGUgYW5zd2VyZXIsIG5vdCB0aGUgVUFDIG9yIHRoZQ0K VUFTLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDkuICZuYnNwO0NsYXJpZmljYXRpb25zIG9uIFRhcmdldCBS ZWZyZXNoIFJlcXVlc3RzPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyB0aGUgY3VycmVudCB0ZXh0IGlz IGEgc3RyYXcgbWFuIHRoYXQgcHV0cyB0YXJnZXQgcmVmcmVzaGVzDQppbiB0aGUgPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyBzYW1lIGNhdGVnb3J5IGFzIGFueSBvdGhlciBjaGFuZ2UuIFRoZSBvdGhl ciBvcHRpb24gd2UNCnRhbGtlZCBhYm91dCA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGluIHRoZSBw YXN0IHdhcyB0byBzcGVjaWFsIGNhc2UgdGhlbSBzbyB0aGF0IHRoZXkgYXJlDQp0cmVhdGVkIDxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsgZGlmZmVyZW50bHkuIFlvdSBzZWVtIHRvIGxpa2UgdGhlIGxh dHRlciBvcHRpb24gYmV0dGVyLg0KV2hhdCBkbyB5b3UgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyB0 aGluayBhYm91dCB0aGUgZm9sbG93aW5nIHRleHQ/PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDtzZWN0aW9uIHRpdGxl PSZxdW90O0NsYXJpZmljYXRpb24gb24gdGhlIEF0b21pY2l0eQ0Kb2YgVGFyZ2V0IFJlZnJlc2gg PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBSZXF1ZXN0cyZxdW90Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsgYW5jaG9yPSZxdW90O3NlYy1hdG9tJnF1b3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsg Jmx0O3QmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBUaGUgcmVtb3RlIHRhcmdldCBvZiBhIGRp YWxvZyBpcyBhIHNwZWNpYWwgdHlwZSBvZiBzdGF0ZQ0KaW5mb3JtYXRpb248YnI+DQomZ3Q7IDxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsgYmVjYXVzZSBvZiBpdHMgZXNzZW50aWFsIHJvbGUgaW4gdGhl IGV4Y2hhbmdlIG9mIFNJUCBtZXNzYWdlcw0KPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBiZXR3ZWVu IFVBcyBpbiBhIGRpYWxvZy4gQSBVQSBpbnZvbHZlZCBpbiBhIGRpYWxvZyByZWNlaXZlcw0KdGhl IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgcmVtb3RlIHRhcmdldCBvZiB0aGUgZGlhbG9nIGZyb20g dGhlIHJlbW90ZSBVQS4gVGhlIFVBDQp1c2VzIHRoZSA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHJl bW90ZSB0YXJnZXQgdG8gc2VuZCBTSVAgcmVxdWVzdHMgdG8gdGhlIHJlbW90ZSBVQS48YnI+DQom Z3Q7Jmd0OyZndDsmZ3Q7ICZsdDsvdCZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDt0Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgVGhlIHJlbW90ZSB0YXJnZXQgaXMgYSBwaWVjZSBvZiBz dGF0ZSBpbmZvcm1hdGlvbiB0aGF0DQppcyBub3QgbWVhbnQgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0 OyB0byBiZSBuZWdvdGlhdGVkLiBXaGVuIGEgVUFDIGNoYW5nZXMgaXRzIGFkZHJlc3MsIHRoZQ0K VUFDIHNpbXBseSA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGNvbW11bmljYXRlcyBpdHMgbmV3IGFk ZHJlc3MgdG8gdGhlIFVBUyBpbiBvcmRlciB0byByZW1haW4NCnJlYWNoYWJsZTxicj4NCiZndDsg PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBieSB0aGUgVUFTLiBBcyBkZXNjcmliZWQgaW4gJmx0O3hy ZWYgdGFyZ2V0PSZxdW90O3NlYy1iYWNrLWF0b20mcXVvdDsvJmd0OywNCmEgVUFTIDxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgc3RhcnRzIHVzaW5nIHRoZSBuZXcgcmVtb3RlIHRhcmdldCBhcyBzb29u IGFzIHRoZSB0YXJnZXQNCnJlZnJlc2ggPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyByZXF1ZXN0IGlz IHJlY2VpdmVkLCByZWdhcmRsZXNzIG9mIHRoZSByZXNwb25zZSB0aGUgVUFTDQpnZW5lcmF0ZXMg dG88YnI+DQomZ3Q7IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgdGhhdCByZXF1ZXN0LiBUaGF0IGlz LCBldmVuIGlmIHRoZSBVQVMgZ2VuZXJhdGVzIGFuIGVycm9yDQpyZXNwb25zZSA8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7IHRvIHRoZSB0YXJnZXQgcmVmcmVzaCByZXF1ZXN0LCB0aGUgVUFTIG5lZWRz IHRvIHVwZGF0ZQ0KdGhlIGRpYWxvZydzIDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgcmVtb3RlIHRh cmdldCBVUkkuPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7L3QmZ3Q7PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyAmbHQ7dCZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBmYWN0IHRoYXQgYSB0 YXJnZXQgcmVmcmVzaCByZXF1ZXN0IHVwZGF0ZXMgdGhlIHJlbW90ZQ0KdGFyZ2V0IDxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgcmVnYXJkbGVzcyBvZiB0aGUgcmVzcG9uc2UgaXQgdHJpZ2dlcnMgaW1w bGllcyB0aGF0IHRhcmdldA0KcmVmcmVzaCA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHJlcXVlc3Rz IGFyZSBub3QgYXRvbWljLiBUaGF0IGlzLCBhbiBlcnJvciByZXNwb25zZSB0bw0KYSB0YXJnZXQg PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyByZWZyZXNoIHJlcXVlc3Qgd2lsbCBrZWVwIGFsbCBjaGFu Z2VzIGFzc29jaWF0ZWQgdG8gdGhlDQpyZXF1ZXN0IGZyb208YnI+DQomZ3Q7IDxicj4NCiZndDsm Z3Q7Jmd0OyZndDsgYmVpbmcgcGVyZm9ybWVkIGV4Y2VwdCBmb3IgdGhlIHJlZnJlc2ggb2YgdGhl IHJlbW90ZSB0YXJnZXQsDQp3aGljaCA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IHdpbGwgYmUgcGVy Zm9ybWVkIGFueXdheS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDsvdCZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7ICZsdDsvc2VjdGlvbiZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgQ2hlZXJzLDxicj4NCiZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IEdvbnphbG88YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7PGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7IF9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0OyBzaXBjb3JlIG1haWxpbmcgbGlzdDxicj4N CiZndDsgc2lwY29yZUBpZXRmLm9yZzxicj4NCiZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFp bG1hbi9saXN0aW5mby9zaXBjb3JlPGJyPg0KJmd0OyA8YnI+DQpfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNpcGNvcmUgbWFpbGluZyBsaXN0PGJy Pg0Kc2lwY29yZUBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2lwY29yZTxicj4NCjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxwcmU+DQot LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K WlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJzcDtUaGUm bmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21h aWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0aGUmbmJz cDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZuYnNwO2Nv bW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGllbnRzJm5i c3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3RvJm5ic3A7 bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5ic3A7cGVy bWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRzJm5ic3A7 b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJzLg0KVGhp cyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFuc21pdHRl ZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNwO2FuZCZu YnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNlJm5ic3A7 b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJzcDt0byZu YnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lmJm5ic3A7 eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5ic3A7aW4m bmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29yaWdpbmF0 b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmlld3MmbmJz cDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJlJm5ic3A7 dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIuDQpUaGlz Jm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7Zm9yJm5i c3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNwO0FudGkt U3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 0043A8BC482575FE_=-- From gonzalo.camarillo@ericsson.com Sun Jul 26 03:51:44 2009 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 4ED5F3A6ABE for ; Sun, 26 Jul 2009 03:51:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.725 X-Spam-Level: X-Spam-Status: No, score=-1.725 tagged_above=-999 required=5 tests=[AWL=-2.771, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HELO_EQ_SE=0.35, MIME_8BIT_HEADER=0.3, MIME_CHARSET_FARAWAY=2.45, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_GB2312=1.345] 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 2JrhvfVn1gs3 for ; Sun, 26 Jul 2009 03:51:42 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id CF9593A6903 for ; Sun, 26 Jul 2009 03:51:41 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-29-4a6c353d5d8c Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 6D.12.00514.D353C6A4; Sun, 26 Jul 2009 12:51:41 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 26 Jul 2009 12:51:41 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Sun, 26 Jul 2009 12:51:41 +0200 Received: from [131.160.126.137] (rvi2-126-137.lmf.ericsson.se [131.160.126.137]) by mail.lmf.ericsson.se (Postfix) with ESMTP id F0BE9245F; Sun, 26 Jul 2009 13:51:40 +0300 (EEST) Message-ID: <4A6C353C.1000002@ericsson.com> Date: Sun, 26 Jul 2009 13:51:40 +0300 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: gao.yang2@zte.com.cn References: In-Reply-To: Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 26 Jul 2009 10:51:41.0408 (UTC) FILETIME=[0F011E00:01CA0DDF] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] =?gb2312?b?tPC4tDogUmU6ICBOZXcgcmV2aXNpb24gb2YgdGhlIHJl?= =?gb2312?b?LUlOVklURSBoYW5kbGluZyBkcmFmdA==?= 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, 26 Jul 2009 10:51:44 -0000 Hi Gao, I do not see the need to have a face-to-face presentation on this topic at this point. We already have an agreed and documented-in-a-draft solution for the session state and will have a solution for the target refresh stuff very soon as well (the discussions are already converging). Let's finish this on the list. Cheers, Gonzalo gao.yang2@zte.com.cn wrote: > > Hi, > > I am at Stockholm now. > > I once asked Paul about this IETF meeting. He said that he would be too > busy to attend this time. It is a pity. > > And as we know, there is a milestone for correction of RFC3261. And I > think session state and dialog state correction are important parts of > this correction. > > And if we can notify the talk in the meeting in the maillist and collect > viewpoint from the maillist on time, we can have a talk as if people > concerning this topic are on the scene. And this can make the talk fast > and effective. > > If Gonzalo has time, he can be the proper person to take charge of this > talk. > > Thanks. > > Gao > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > > > *Paul Kyzivat * > ·¢¼þÈË: sipcore-bounces@ietf.org > > 2009-07-24 21:13 > > > ÊÕ¼þÈË > Christer Holmberg > ³­ËÍ > gao.yang2@zte.com.cn, SIPCORE , Gonzalo Camarillo > > Ö÷Ìâ > Re: [sipcore] New revision of the re-INVITE handling draft > > > > > > > > > > > Christer Holmberg wrote: > > Hi, > > > > I am just re-booting after my summer vacation, and I have NOT been able > > to read all e-mails in this thread yet. So, I appologize if something > > has been discussed. > > > > Regarding the proposal to not be able to reject a target update. If you > > use Outbound, where you have created the NAT binding as part of the > > registration, a target refresh can not be performed, because the > > signalling wouldn't reach the client behind the NAT anymore. You would > > need to perform a re-registration. > > > > Now, we could of course say that a client using Outbound shall not > > perform a target refresh in the first place. BUT, the same issue also > > apply to other registration-based NAT traversal mechanisms - in some > > cases the client behind the NAT may not even be aware of those. > > > > So, if we want to say that one cannot reject a target refresh we need to > > make sure we don't create a new cannot-reject-offer-in-PRACK type of > > problem... > > First, I'm not saying you can't reject a target refresh. > Recommending you shouldn't reject it if you have alternatives is not the > same. For instance if you have an authorization failure then you should > definitely reject it. > > >> I'm don't know if we are on quite the same page yet. > >> Once accepted, I don't think a target refresh should be rolled back by > > anything. > >> A key use case might be: > >> > >> I've started an reINVITE - one that might take awhile because it is > > trying to add media and the other end is alerting > >> about that. > >> > >> While that is in progress I lose my IP address and need to target > > refresh. So what do I do? > >> I think I send an UPDATE, which will be in the midst of the reINVITE > > transaction. I make it a simple one, in that it > >> includes no o/a, its *just* a target refresh. > > > > In most cases, won't you use the same IP address for signalling and > > media? So, if you've lost it you would need to re-negotiate the media > > parameters also... > > Yes, you will probably need to renegotiate the media too. But that isn't > quite as urgent. If need be it can wait until you have a working > signaling path again. > > > I think it would be much better for the UAC to first cancel the > > re-INVITE, and then do the target refresh and re-start the o/a > > transaction. > > As I noted, if you have really lost your ip address, then while you can > send the CANCEL, you won't get the final response to the reINVITE that > was canceled. You can either send the CANCEL, wait the full timeout > interval, then send a new target refresh, or you can send the target > refresh first (so you know you have a working signaling path again), > then send the CANCEL. > > OTOH, if there is overlap in address availability (e.g. your renew of > the lease on your IP address was rejected but hasn't yet expired) then > it indeed would be prudent to wait for a quiescent state and then send > the refresh. > > Thanks, > Paul > > > Performing target refreshes inside ongoing re-INVITEs are only going to > > cause problems - especially if you are not able to receive responses etc > > on the old address. > > > > > Regards, > > > > Christer > > > > > > > >> Hi Paul, > >> > >> > This will encourage using a *simple* request to do an essential > >> target > refresh, rather than a complex one that has a chance of > > failing. > >> Yes, I agree with you. I think we can get what you are looking for by > >> keeping the text that is currently in the draft (i.e., re-INVITEs > >> remain atomic and an error response rolls everything back, including > >> the target refresh), by adding a description of why piggybacking other > > > >> changes in a target refresh request is a bad idea (the new text would > >> include a discussion on the Via problem and on legacy UASs responding > >> with an error response even if changes have been executed), and by > >> discouraging the use of re-INVITEs that update the target and perform > >> other changes at the same time (we probably need to go as far as to > >> say that one SHOULD NOT do it). > >> > >> I agree with you that encouraging the use of "simple" requests will be > > > >> better than specifying complex behavior just to cover corner cases. > >> > >> Thanks, > >> > >> Gonzalo > >> > >> > >> > >> Paul Kyzivat wrote: > >>> Gonzalo, > >>> > >>> I agree with all you say below, except at the very end about target > >>> refresh. > >>> > >>> If target refreshes are to be accepted even if the request fails, > >>> then it is possible to hijack a session even if authentication is > >>> being used for signaling. > >>> > >>> IMO a target refresh must be ignored in at least *some* cases when > >>> the request is rejected. We could enumerate these cases individually, > > > >>> or simply state that it will only be accepted if the request is > > accepted. > >>> (In case of reINVITE, that would be if it was accepted sufficiently > >>> to return a 2xx or a 1xx.) > >>> > >>> This will encourage using a *simple* request to do an essential > >>> target refresh, rather than a complex one that has a chance of > > failing. > >>> Perhaps it won't work in all cases, but such is life. > >>> > >>> Thanks, > >>> Paul > >>> > >>> Gonzalo Camarillo wrote: > >>>> Hi Paul, > >>>> > >>>> thanks for your comments. Answers inline: > >>>> > >>>> Paul Kyzivat wrote: > >>>>> Gonzalo, > >>>>> > >>>>> Thanks for doing this work! I do have some comments: > >>>>> > >>>>> Section 3/Figure 1 > >>>>> > >>>>> The figure shows a 6xx response. > >>>>> The text says that the UAS wants to reject the new offer. > >>>>> > >>>>> A UAS would probably not use a 6xx response to reject media. > >>>>> (I guess it might use 606, but 488 would be more appropriate.) In > >>>>> fact, it probably would not reject the request at all, but rather > >>>>> would just refuse the added media stream. > >>>>> > >>>>> The point being made doesn't require that the response be 6xx or > >>>>> that it be with the purpose of refusing the media. So I think what > >>>>> is needed here is to find a plausible example to make the point. > >>>>> > >>>>> A good one for the purpose here might be a 488 to reject the media, > > > >>>>> or a 401 response as another sort of reason for rejecting the > >>>>> whole thing but wanting to preserve what there is. > >>>> yes, I agree that a 488 response would be more appropriate. I will > >>>> change that in the draft. > >>>> > >>>>> Section 5: > >>>>> > >>>>>> A change to the session state is considered to have been > > executed > >>>>>> when the new media parameters are being used. Therefore, a > >>>>>> change to > >>>>>> a stream subject to preconditions [RFC4032] is considered to > > have > >>>>>> been executed when the new media parameters start being used; > > not > >>>>>> when the preconditions for the stream are met. Unsurprisingly, > > the > >>>>>> UAS considers the new parameters to be in use when it actually > >>>>>> starts > >>>>>> using them. > >>>>> I'm not entirely following this. I think there may be an assumption > > > >>>>> here that the UAC is the offerer and the UAS the answerer. I'm > >>>>> guessing you are saying that the answerer considers the new > >>>>> parameters to be in use when it actually starts using them. > >>>>> > >>>>> Since this section is about the UAS (for the reinvite), this point > >>>>> is probably that when the UAS is also the answerer it can decide > >>>>> when the new media is in use based on when it starts using them. > >>>>> > >>>>> But what happens when the UAS is the offerer? In that case I think > >>>>> it must assume the media is in use as soon as it is offered. But > >>>>> maybe that isn't always the case with preconditions. I don't think > >>>>> it can wait till it receives media, because media may be in flight > >>>>> when it makes its decision. > >>>> yes, the draft assumes that the UAS is the answerer because that was > > > >>>> the use case being discussed originally. However, you are right that > > > >>>> we should also cover the case where the UAS is the offerer. I will > >>>> look into it and add text about it in the draft. > >>>> > >>>>>> As described in Section 8.3.1 of RFC 3264 [RFC3264], the > >>>>>> UAC considers the new parameters to be in use when media is > >>>>>> received > >>>>>> in the new port, which should be interpreted as follows: > >>>>>> > >>>>>> Received, in this case, means that the media is passed to a > >>>>>> media > >>>>>> sink. This means that if there is a playout buffer, the > > agent > >>>>>> would continue to listen on the old port until the media on > > the > >>>>>> new port reached the top of the playout buffer. At that > >>>>>> time, it > >>>>>> MAY cease listening for media on the old port. > >>>>> I don't know what the above has to do with the behavior of the UAS. > >>>> The UAC needs to know when the new parameters are in use in order to > > > >>>> implement the normative behavior in Section 6: > >>>> > >>>> ... a UAC that receives an error response to a re-INVITE for > > which > >>>> changes have been already executed ... > >>>> > >>>> In any case, I will clarify all this when I write the text about the > > > >>>> UAS being the offerer because this type of behavior has to do with > >>>> being the offerer or the answerer, not the UAC or the UAS. > >>>> > >>>> > >>>>>> 9. Clarifications on Target Refresh Requests > >>>> the current text is a straw man that puts target refreshes in the > >>>> same category as any other change. The other option we talked about > >>>> in the past was to special case them so that they are treated > >>>> differently. You seem to like the latter option better. What do you > >>>> think about the following text? > >>>> > >>>> > >>>>
>>>> anchor="sec-atom"> > >>>> > >>>> The remote target of a dialog is a special type of state information > > > >>>> because of its essential role in the exchange of SIP messages > >>>> between UAs in a dialog. A UA involved in a dialog receives the > >>>> remote target of the dialog from the remote UA. The UA uses the > >>>> remote target to send SIP requests to the remote UA. > >>>> > >>>> > >>>> The remote target is a piece of state information that is not meant > >>>> to be negotiated. When a UAC changes its address, the UAC simply > >>>> communicates its new address to the UAS in order to remain reachable > > > >>>> by the UAS. As described in , a UAS > >>>> starts using the new remote target as soon as the target refresh > >>>> request is received, regardless of the response the UAS generates to > > > >>>> that request. That is, even if the UAS generates an error response > >>>> to the target refresh request, the UAS needs to update the dialog's > >>>> remote target URI. > >>>> > >>>> > >>>> The fact that a target refresh request updates the remote target > >>>> regardless of the response it triggers implies that target refresh > >>>> requests are not atomic. That is, an error response to a target > >>>> refresh request will keep all changes associated to the request from > > > >>>> being performed except for the refresh of the remote target, which > >>>> will be performed anyway. > >>>> > >>>>
> >>>> > >>>> > >>>> Cheers, > >>>> > >>>> Gonzalo > >>>> > >> > > _______________________________________________ > > 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 > > > > -------------------------------------------------------- > ZTE Information Security Notice: The information contained in this mail is solely property of the sender's organization. This mail communication is confidential. Recipients named above are obligated to maintain secrecy and are not permitted to disclose the contents of this communication to others. > This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the originator of the message. Any views expressed in this message are those of the individual sender. > This message has been scanned for viruses and Spam by ZTE Anti-Spam system. From gao.yang2@zte.com.cn Sun Jul 26 04:35:06 2009 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 3A8A83A69BD for ; Sun, 26 Jul 2009 04:35:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.75 X-Spam-Level: X-Spam-Status: No, score=-93.75 tagged_above=-999 required=5 tests=[AWL=-0.960, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 bnR7OzjqhK6l for ; Sun, 26 Jul 2009 04:35:03 -0700 (PDT) Received: from mx6.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id CB4E73A69FF for ; Sun, 26 Jul 2009 04:35:02 -0700 (PDT) Received: from [10.30.17.100] by mx6.zte.com.cn with surfront esmtp id 91101727820181; Sun, 26 Jul 2009 19:21:15 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 12290.6396279943; Sun, 26 Jul 2009 19:27:26 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n6QBYdWd028882; Sun, 26 Jul 2009 19:34:44 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4A6C353C.1000002@ericsson.com> To: Gonzalo Camarillo MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Sun, 26 Jul 2009 19:34:09 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-26 19:34:27, Serialize complete at 2009-07-26 19:34:27 Content-Type: multipart/alternative; boundary="=_alternative 003F935E482575FF_=" X-MAIL: mse2.zte.com.cn n6QBYdWd028882 Cc: SIPCORE Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ILTwuLQ6IFJlOiAgTmV3IHJldmlzaW9u?= =?gb2312?b?IG9mIHRoZSByZS1JTlZJVEUgaGFuZGxpbmcgZHJhZnQ=?= 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, 26 Jul 2009 11:35:06 -0000 This is a multipart message in MIME format. --=_alternative 003F935E482575FF_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgR29uemFsbywNCg0KT0suDQoNClRoYW5rLg0KDQpHYW8NCg0KDQo9PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PQ0KIFppcCAgICA6IDIxMDAxMg0KIFRlbCAgICA6IDg3MjExDQog VGVsMiAgIDooKzg2KS0wMjUtNTI4NzcyMTENCiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5j bg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCg0KDQoNCkdvbnphbG8gQ2Ft YXJpbGxvIDxHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb20+IA0KMjAwOS0wNy0yNiAxODo1 MQ0KDQrK1bz+yMsNCmdhby55YW5nMkB6dGUuY29tLmNuDQqzrcvNDQpQYXVsIEt5eml2YXQgPHBr eXppdmF0QGNpc2NvLmNvbT4sIENocmlzdGVyIEhvbG1iZXJnIA0KPGNocmlzdGVyLmhvbG1iZXJn QGVyaWNzc29uLmNvbT4sIFNJUENPUkUgPHNpcGNvcmVAaWV0Zi5vcmc+DQrW98ziDQpSZTogtPC4 tDogUmU6IFtzaXBjb3JlXSBOZXcgcmV2aXNpb24gb2YgdGhlIHJlLUlOVklURSBoYW5kbGluZyBk cmFmdA0KDQoNCg0KDQoNCg0KSGkgR2FvLA0KDQpJIGRvIG5vdCBzZWUgdGhlIG5lZWQgdG8gaGF2 ZSBhIGZhY2UtdG8tZmFjZSBwcmVzZW50YXRpb24gb24gdGhpcyB0b3BpYw0KYXQgdGhpcyBwb2lu dC4gV2UgYWxyZWFkeSBoYXZlIGFuIGFncmVlZCBhbmQgZG9jdW1lbnRlZC1pbi1hLWRyYWZ0DQpz b2x1dGlvbiBmb3IgdGhlIHNlc3Npb24gc3RhdGUgYW5kIHdpbGwgaGF2ZSBhIHNvbHV0aW9uIGZv ciB0aGUgdGFyZ2V0DQpyZWZyZXNoIHN0dWZmIHZlcnkgc29vbiBhcyB3ZWxsICh0aGUgZGlzY3Vz c2lvbnMgYXJlIGFscmVhZHkNCmNvbnZlcmdpbmcpLiBMZXQncyBmaW5pc2ggdGhpcyBvbiB0aGUg bGlzdC4NCg0KQ2hlZXJzLA0KDQpHb256YWxvDQoNCg0KZ2FvLnlhbmcyQHp0ZS5jb20uY24gd3Jv dGU6DQo+IA0KPiBIaSwNCj4gDQo+IEkgYW0gYXQgU3RvY2tob2xtIG5vdy4NCj4gDQo+IEkgb25j ZSBhc2tlZCBQYXVsIGFib3V0IHRoaXMgSUVURiBtZWV0aW5nLiBIZSBzYWlkIHRoYXQgaGUgd291 bGQgYmUgdG9vIA0KPiBidXN5IHRvIGF0dGVuZCB0aGlzIHRpbWUuIEl0IGlzIGEgcGl0eS4NCj4g DQo+IEFuZCBhcyB3ZSBrbm93LCB0aGVyZSBpcyBhIG1pbGVzdG9uZSBmb3IgY29ycmVjdGlvbiBv ZiBSRkMzMjYxLiBBbmQgSSANCj4gdGhpbmsgc2Vzc2lvbiBzdGF0ZSBhbmQgZGlhbG9nIHN0YXRl IGNvcnJlY3Rpb24gYXJlIGltcG9ydGFudCBwYXJ0cyBvZiANCj4gdGhpcyBjb3JyZWN0aW9uLg0K PiANCj4gQW5kIGlmIHdlIGNhbiBub3RpZnkgdGhlIHRhbGsgaW4gdGhlIG1lZXRpbmcgaW4gdGhl IG1haWxsaXN0IGFuZCBjb2xsZWN0IA0KDQo+IHZpZXdwb2ludCBmcm9tIHRoZSBtYWlsbGlzdCBv biB0aW1lLCB3ZSBjYW4gaGF2ZSBhIHRhbGsgYXMgaWYgcGVvcGxlIA0KPiBjb25jZXJuaW5nIHRo aXMgdG9waWMgYXJlIG9uIHRoZSBzY2VuZS4gQW5kIHRoaXMgY2FuIG1ha2UgdGhlIHRhbGsgZmFz dCANCj4gYW5kIGVmZmVjdGl2ZS4NCj4gDQo+IElmIEdvbnphbG8gaGFzIHRpbWUsIGhlIGNhbiBi ZSB0aGUgcHJvcGVyIHBlcnNvbiB0byB0YWtlIGNoYXJnZSBvZiB0aGlzIA0KPiB0YWxrLg0KPiAN Cj4gVGhhbmtzLg0KPiANCj4gR2FvDQo+IA0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PQ0KPiBaaXAgICAgOiAyMTAwMTINCj4gVGVsICAgIDogODcyMTENCj4gVGVsMiAgIDoo Kzg2KS0wMjUtNTI4NzcyMTENCj4gZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj4gPT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCj4gDQo+IA0KPiAqUGF1bCBLeXppdmF0 IDxwa3l6aXZhdEBjaXNjby5jb20+Kg0KPiA3Ijx+SEs6ICBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5v cmcNCj4gDQo+IDIwMDktMDctMjQgMjE6MTMNCj4gDQo+IA0KPiBKVTx+SEsNCj4gICAgICAgICAg ICAgICAgQ2hyaXN0ZXIgSG9sbWJlcmcgPGNocmlzdGVyLmhvbG1iZXJnQGVyaWNzc29uLmNvbT4N Cj4gMy1LTQ0KPiAgICAgICAgICAgICAgICBnYW8ueWFuZzJAenRlLmNvbS5jbiwgU0lQQ09SRSA8 c2lwY29yZUBpZXRmLm9yZz4sIEdvbnphbG8gDQpDYW1hcmlsbG8gDQo+IDxnb256YWxvLmNhbWFy aWxsb0Blcmljc3Nvbi5jb20+DQo+IFZ3TGINCj4gICAgICAgICAgICAgICAgUmU6IFtzaXBjb3Jl XSBOZXcgcmV2aXNpb24gb2YgdGhlIHJlLUlOVklURSBoYW5kbGluZyANCmRyYWZ0DQo+IA0KPiAN Cj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiBDaHJpc3RlciBIb2xtYmVyZyB3cm90 ZToNCj4gID4gSGksDQo+ICA+DQo+ICA+IEkgYW0ganVzdCByZS1ib290aW5nIGFmdGVyIG15IHN1 bW1lciB2YWNhdGlvbiwgYW5kIEkgaGF2ZSBOT1QgYmVlbiANCmFibGUNCj4gID4gdG8gcmVhZCBh bGwgZS1tYWlscyBpbiB0aGlzIHRocmVhZCB5ZXQuIFNvLCBJIGFwcG9sb2dpemUgaWYgc29tZXRo aW5nDQo+ICA+IGhhcyBiZWVuIGRpc2N1c3NlZC4NCj4gID4NCj4gID4gUmVnYXJkaW5nIHRoZSBw cm9wb3NhbCB0byBub3QgYmUgYWJsZSB0byByZWplY3QgYSB0YXJnZXQgdXBkYXRlLiBJZiANCnlv dQ0KPiAgPiB1c2UgT3V0Ym91bmQsIHdoZXJlIHlvdSBoYXZlIGNyZWF0ZWQgdGhlIE5BVCBiaW5k aW5nIGFzIHBhcnQgb2YgdGhlDQo+ICA+IHJlZ2lzdHJhdGlvbiwgYSB0YXJnZXQgcmVmcmVzaCBj YW4gbm90IGJlIHBlcmZvcm1lZCwgYmVjYXVzZSB0aGUNCj4gID4gc2lnbmFsbGluZyB3b3VsZG4n dCByZWFjaCB0aGUgY2xpZW50IGJlaGluZCB0aGUgTkFUIGFueW1vcmUuIFlvdSANCndvdWxkDQo+ ICA+IG5lZWQgdG8gcGVyZm9ybSBhIHJlLXJlZ2lzdHJhdGlvbi4NCj4gID4NCj4gID4gTm93LCB3 ZSBjb3VsZCBvZiBjb3Vyc2Ugc2F5IHRoYXQgYSBjbGllbnQgdXNpbmcgT3V0Ym91bmQgc2hhbGwg bm90DQo+ICA+IHBlcmZvcm0gYSB0YXJnZXQgcmVmcmVzaCBpbiB0aGUgZmlyc3QgcGxhY2UuIEJV VCwgdGhlIHNhbWUgaXNzdWUgYWxzbw0KPiAgPiBhcHBseSB0byBvdGhlciByZWdpc3RyYXRpb24t YmFzZWQgTkFUIHRyYXZlcnNhbCBtZWNoYW5pc21zIC0gaW4gc29tZQ0KPiAgPiBjYXNlcyB0aGUg Y2xpZW50IGJlaGluZCB0aGUgTkFUIG1heSBub3QgZXZlbiBiZSBhd2FyZSBvZiB0aG9zZS4NCj4g ID4NCj4gID4gU28sIGlmIHdlIHdhbnQgdG8gc2F5IHRoYXQgb25lIGNhbm5vdCByZWplY3QgYSB0 YXJnZXQgcmVmcmVzaCB3ZSBuZWVkIA0KdG8NCj4gID4gbWFrZSBzdXJlIHdlIGRvbid0IGNyZWF0 ZSBhIG5ldyBjYW5ub3QtcmVqZWN0LW9mZmVyLWluLVBSQUNLIHR5cGUgb2YNCj4gID4gcHJvYmxl bS4uLg0KPiANCj4gRmlyc3QsIEknbSBub3Qgc2F5aW5nIHlvdSBjYW4ndCByZWplY3QgYSB0YXJn ZXQgcmVmcmVzaC4NCj4gUmVjb21tZW5kaW5nIHlvdSBzaG91bGRuJ3QgcmVqZWN0IGl0IGlmIHlv dSBoYXZlIGFsdGVybmF0aXZlcyBpcyBub3QgdGhlDQo+IHNhbWUuIEZvciBpbnN0YW5jZSBpZiB5 b3UgaGF2ZSBhbiBhdXRob3JpemF0aW9uIGZhaWx1cmUgdGhlbiB5b3Ugc2hvdWxkDQo+IGRlZmlu aXRlbHkgcmVqZWN0IGl0Lg0KPiANCj4gID4+IEknbSBkb24ndCBrbm93IGlmIHdlIGFyZSBvbiBx dWl0ZSB0aGUgc2FtZSBwYWdlIHlldC4NCj4gID4+IE9uY2UgYWNjZXB0ZWQsIEkgZG9uJ3QgdGhp bmsgYSB0YXJnZXQgcmVmcmVzaCBzaG91bGQgYmUgcm9sbGVkIGJhY2sgDQpieQ0KPiAgPiBhbnl0 aGluZy4NCj4gID4+IEEga2V5IHVzZSBjYXNlIG1pZ2h0IGJlOg0KPiAgPj4NCj4gID4+IEkndmUg c3RhcnRlZCBhbiByZUlOVklURSAtIG9uZSB0aGF0IG1pZ2h0IHRha2UgYXdoaWxlIGJlY2F1c2Ug aXQgaXMNCj4gID4gdHJ5aW5nIHRvIGFkZCBtZWRpYSBhbmQgdGhlIG90aGVyIGVuZCBpcyBhbGVy dGluZw0KPiAgPj4gYWJvdXQgdGhhdC4NCj4gID4+DQo+ICA+PiBXaGlsZSB0aGF0IGlzIGluIHBy b2dyZXNzIEkgbG9zZSBteSBJUCBhZGRyZXNzIGFuZCBuZWVkIHRvIHRhcmdldA0KPiAgPiByZWZy ZXNoLiBTbyB3aGF0IGRvIEkgZG8/DQo+ICA+PiBJIHRoaW5rIEkgc2VuZCBhbiBVUERBVEUsIHdo aWNoIHdpbGwgYmUgaW4gdGhlIG1pZHN0IG9mIHRoZSByZUlOVklURQ0KPiAgPiB0cmFuc2FjdGlv bi4gSSBtYWtlIGl0IGEgc2ltcGxlIG9uZSwgaW4gdGhhdCBpdA0KPiAgPj4gaW5jbHVkZXMgbm8g by9hLCBpdHMgKmp1c3QqIGEgdGFyZ2V0IHJlZnJlc2guDQo+ICA+DQo+ICA+IEluIG1vc3QgY2Fz ZXMsIHdvbid0IHlvdSB1c2UgdGhlIHNhbWUgSVAgYWRkcmVzcyBmb3Igc2lnbmFsbGluZyBhbmQN Cj4gID4gbWVkaWE/IFNvLCBpZiB5b3UndmUgbG9zdCBpdCB5b3Ugd291bGQgbmVlZCB0byByZS1u ZWdvdGlhdGUgdGhlIG1lZGlhDQo+ICA+IHBhcmFtZXRlcnMgYWxzby4uLg0KPiANCj4gWWVzLCB5 b3Ugd2lsbCBwcm9iYWJseSBuZWVkIHRvIHJlbmVnb3RpYXRlIHRoZSBtZWRpYSB0b28uIEJ1dCB0 aGF0IGlzbid0DQo+IHF1aXRlIGFzIHVyZ2VudC4gSWYgbmVlZCBiZSBpdCBjYW4gd2FpdCB1bnRp bCB5b3UgaGF2ZSBhIHdvcmtpbmcNCj4gc2lnbmFsaW5nIHBhdGggYWdhaW4uDQo+IA0KPiAgPiBJ IHRoaW5rIGl0IHdvdWxkIGJlIG11Y2ggYmV0dGVyIGZvciB0aGUgVUFDIHRvIGZpcnN0IGNhbmNl bCB0aGUNCj4gID4gcmUtSU5WSVRFLCBhbmQgdGhlbiBkbyB0aGUgdGFyZ2V0IHJlZnJlc2ggYW5k IHJlLXN0YXJ0IHRoZSBvL2ENCj4gID4gdHJhbnNhY3Rpb24uDQo+IA0KPiBBcyBJIG5vdGVkLCBp ZiB5b3UgaGF2ZSByZWFsbHkgbG9zdCB5b3VyIGlwIGFkZHJlc3MsIHRoZW4gd2hpbGUgeW91IGNh bg0KPiBzZW5kIHRoZSBDQU5DRUwsIHlvdSB3b24ndCBnZXQgdGhlIGZpbmFsIHJlc3BvbnNlIHRv IHRoZSByZUlOVklURSB0aGF0DQo+IHdhcyBjYW5jZWxlZC4gWW91IGNhbiBlaXRoZXIgc2VuZCB0 aGUgQ0FOQ0VMLCB3YWl0IHRoZSBmdWxsIHRpbWVvdXQNCj4gaW50ZXJ2YWwsIHRoZW4gc2VuZCBh IG5ldyB0YXJnZXQgcmVmcmVzaCwgb3IgeW91IGNhbiBzZW5kIHRoZSB0YXJnZXQNCj4gcmVmcmVz aCBmaXJzdCAoc28geW91IGtub3cgeW91IGhhdmUgYSB3b3JraW5nIHNpZ25hbGluZyBwYXRoIGFn YWluKSwNCj4gdGhlbiBzZW5kIHRoZSBDQU5DRUwuDQo+IA0KPiBPVE9ILCBpZiB0aGVyZSBpcyBv dmVybGFwIGluIGFkZHJlc3MgYXZhaWxhYmlsaXR5IChlLmcuIHlvdXIgcmVuZXcgb2YNCj4gdGhl IGxlYXNlIG9uIHlvdXIgSVAgYWRkcmVzcyB3YXMgcmVqZWN0ZWQgYnV0IGhhc24ndCB5ZXQgZXhw aXJlZCkgdGhlbg0KPiBpdCBpbmRlZWQgd291bGQgYmUgcHJ1ZGVudCB0byB3YWl0IGZvciBhIHF1 aWVzY2VudCBzdGF0ZSBhbmQgdGhlbiBzZW5kDQo+IHRoZSByZWZyZXNoLg0KPiANCj4gICAgICAg ICAgICAgICAgIFRoYW5rcywNCj4gICAgICAgICAgICAgICAgIFBhdWwNCj4gDQo+ICA+IFBlcmZv cm1pbmcgdGFyZ2V0IHJlZnJlc2hlcyBpbnNpZGUgb25nb2luZyByZS1JTlZJVEVzIGFyZSBvbmx5 IGdvaW5nIA0KdG8NCj4gID4gY2F1c2UgcHJvYmxlbXMgLSBlc3BlY2lhbGx5IGlmIHlvdSBhcmUg bm90IGFibGUgdG8gcmVjZWl2ZSByZXNwb25zZXMgDQpldGMNCj4gID4gb24gdGhlIG9sZCBhZGRy ZXNzLg0KPiANCj4gDQo+IA0KPiAgPiBSZWdhcmRzLA0KPiAgPg0KPiAgPiBDaHJpc3Rlcg0KPiAg Pg0KPiAgPg0KPiAgPg0KPiAgPj4gSGkgUGF1bCwNCj4gID4+DQo+ICA+PiAgPiBUaGlzIHdpbGwg ZW5jb3VyYWdlIHVzaW5nIGEgKnNpbXBsZSogcmVxdWVzdCB0byBkbyBhbiBlc3NlbnRpYWwNCj4g ID4+IHRhcmdldCAgPiByZWZyZXNoLCByYXRoZXIgdGhhbiBhIGNvbXBsZXggb25lIHRoYXQgaGFz IGEgY2hhbmNlIG9mDQo+ICA+IGZhaWxpbmcuDQo+ICA+PiBZZXMsIEkgYWdyZWUgd2l0aCB5b3Uu IEkgdGhpbmsgd2UgY2FuIGdldCB3aGF0IHlvdSBhcmUgbG9va2luZyBmb3IgDQpieQ0KPiAgPj4g a2VlcGluZyB0aGUgdGV4dCB0aGF0IGlzIGN1cnJlbnRseSBpbiB0aGUgZHJhZnQgKGkuZS4sIHJl LUlOVklURXMNCj4gID4+IHJlbWFpbiBhdG9taWMgYW5kIGFuIGVycm9yIHJlc3BvbnNlIHJvbGxz IGV2ZXJ5dGhpbmcgYmFjaywgaW5jbHVkaW5nDQo+ICA+PiB0aGUgdGFyZ2V0IHJlZnJlc2gpLCBi eSBhZGRpbmcgYSBkZXNjcmlwdGlvbiBvZiB3aHkgcGlnZ3liYWNraW5nIA0Kb3RoZXINCj4gID4N Cj4gID4+IGNoYW5nZXMgaW4gYSB0YXJnZXQgcmVmcmVzaCByZXF1ZXN0IGlzIGEgYmFkIGlkZWEg KHRoZSBuZXcgdGV4dCANCndvdWxkDQo+ICA+PiBpbmNsdWRlIGEgZGlzY3Vzc2lvbiBvbiB0aGUg VmlhIHByb2JsZW0gYW5kIG9uIGxlZ2FjeSBVQVNzIA0KcmVzcG9uZGluZw0KPiAgPj4gd2l0aCBh biBlcnJvciByZXNwb25zZSBldmVuIGlmIGNoYW5nZXMgaGF2ZSBiZWVuIGV4ZWN1dGVkKSwgYW5k IGJ5DQo+ICA+PiBkaXNjb3VyYWdpbmcgdGhlIHVzZSBvZiByZS1JTlZJVEVzIHRoYXQgdXBkYXRl IHRoZSB0YXJnZXQgYW5kIA0KcGVyZm9ybQ0KPiAgPj4gb3RoZXIgY2hhbmdlcyBhdCB0aGUgc2Ft ZSB0aW1lICh3ZSBwcm9iYWJseSBuZWVkIHRvIGdvIGFzIGZhciBhcyB0bw0KPiAgPj4gc2F5IHRo YXQgb25lIFNIT1VMRCBOT1QgZG8gaXQpLg0KPiAgPj4NCj4gID4+IEkgYWdyZWUgd2l0aCB5b3Ug dGhhdCBlbmNvdXJhZ2luZyB0aGUgdXNlIG9mICJzaW1wbGUiIHJlcXVlc3RzIHdpbGwgDQpiZQ0K PiAgPg0KPiAgPj4gYmV0dGVyIHRoYW4gc3BlY2lmeWluZyBjb21wbGV4IGJlaGF2aW9yIGp1c3Qg dG8gY292ZXIgY29ybmVyIGNhc2VzLg0KPiAgPj4NCj4gID4+IFRoYW5rcywNCj4gID4+DQo+ICA+ PiBHb256YWxvDQo+ICA+Pg0KPiAgPj4NCj4gID4+DQo+ICA+PiBQYXVsIEt5eml2YXQgd3JvdGU6 DQo+ICA+Pj4gR29uemFsbywNCj4gID4+Pg0KPiAgPj4+IEkgYWdyZWUgd2l0aCBhbGwgeW91IHNh eSBiZWxvdywgZXhjZXB0IGF0IHRoZSB2ZXJ5IGVuZCBhYm91dCB0YXJnZXQNCj4gID4+PiByZWZy ZXNoLg0KPiAgPj4+DQo+ICA+Pj4gSWYgdGFyZ2V0IHJlZnJlc2hlcyBhcmUgdG8gYmUgYWNjZXB0 ZWQgZXZlbiBpZiB0aGUgcmVxdWVzdCBmYWlscywNCj4gID4+PiB0aGVuIGl0IGlzIHBvc3NpYmxl IHRvIGhpamFjayBhIHNlc3Npb24gZXZlbiBpZiBhdXRoZW50aWNhdGlvbiBpcw0KPiAgPj4+IGJl aW5nIHVzZWQgZm9yIHNpZ25hbGluZy4NCj4gID4+Pg0KPiAgPj4+IElNTyBhIHRhcmdldCByZWZy ZXNoIG11c3QgYmUgaWdub3JlZCBpbiBhdCBsZWFzdCAqc29tZSogY2FzZXMgd2hlbg0KPiAgPj4+ IHRoZSByZXF1ZXN0IGlzIHJlamVjdGVkLiBXZSBjb3VsZCBlbnVtZXJhdGUgdGhlc2UgY2FzZXMg DQppbmRpdmlkdWFsbHksDQo+ICA+DQo+ICA+Pj4gb3Igc2ltcGx5IHN0YXRlIHRoYXQgaXQgd2ls bCBvbmx5IGJlIGFjY2VwdGVkIGlmIHRoZSByZXF1ZXN0IGlzDQo+ICA+IGFjY2VwdGVkLg0KPiAg Pj4+IChJbiBjYXNlIG9mIHJlSU5WSVRFLCB0aGF0IHdvdWxkIGJlIGlmIGl0IHdhcyBhY2NlcHRl ZCBzdWZmaWNpZW50bHkNCj4gID4+PiB0byByZXR1cm4gYSAyeHggb3IgYSAxeHguKQ0KPiAgPj4+ DQo+ICA+Pj4gVGhpcyB3aWxsIGVuY291cmFnZSB1c2luZyBhICpzaW1wbGUqIHJlcXVlc3QgdG8g ZG8gYW4gZXNzZW50aWFsDQo+ICA+Pj4gdGFyZ2V0IHJlZnJlc2gsIHJhdGhlciB0aGFuIGEgY29t cGxleCBvbmUgdGhhdCBoYXMgYSBjaGFuY2Ugb2YNCj4gID4gZmFpbGluZy4NCj4gID4+PiBQZXJo YXBzIGl0IHdvbid0IHdvcmsgaW4gYWxsIGNhc2VzLCBidXQgc3VjaCBpcyBsaWZlLg0KPiAgPj4+ DQo+ICA+Pj4gICAgIFRoYW5rcywNCj4gID4+PiAgICAgUGF1bA0KPiAgPj4+DQo+ICA+Pj4gR29u emFsbyBDYW1hcmlsbG8gd3JvdGU6DQo+ICA+Pj4+IEhpIFBhdWwsDQo+ICA+Pj4+DQo+ICA+Pj4+ IHRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gQW5zd2VycyBpbmxpbmU6DQo+ICA+Pj4+DQo+ICA+ Pj4+IFBhdWwgS3l6aXZhdCB3cm90ZToNCj4gID4+Pj4+IEdvbnphbG8sDQo+ICA+Pj4+Pg0KPiAg Pj4+Pj4gVGhhbmtzIGZvciBkb2luZyB0aGlzIHdvcmshIEkgZG8gaGF2ZSBzb21lIGNvbW1lbnRz Og0KPiAgPj4+Pj4NCj4gID4+Pj4+IFNlY3Rpb24gMy9GaWd1cmUgMQ0KPiAgPj4+Pj4NCj4gID4+ Pj4+IFRoZSBmaWd1cmUgc2hvd3MgYSA2eHggcmVzcG9uc2UuDQo+ICA+Pj4+PiBUaGUgdGV4dCBz YXlzIHRoYXQgdGhlIFVBUyB3YW50cyB0byByZWplY3QgdGhlIG5ldyBvZmZlci4NCj4gID4+Pj4+ DQo+ICA+Pj4+PiBBIFVBUyB3b3VsZCBwcm9iYWJseSBub3QgdXNlIGEgNnh4IHJlc3BvbnNlIHRv IHJlamVjdCBtZWRpYS4NCj4gID4+Pj4+IChJIGd1ZXNzIGl0IG1pZ2h0IHVzZSA2MDYsIGJ1dCA0 ODggd291bGQgYmUgbW9yZSBhcHByb3ByaWF0ZS4pIEluDQo+ICA+Pj4+PiBmYWN0LCBpdCBwcm9i YWJseSB3b3VsZCBub3QgcmVqZWN0IHRoZSByZXF1ZXN0IGF0IGFsbCwgYnV0IHJhdGhlcg0KPiAg Pj4+Pj4gd291bGQganVzdCByZWZ1c2UgdGhlIGFkZGVkIG1lZGlhIHN0cmVhbS4NCj4gID4+Pj4+ DQo+ICA+Pj4+PiBUaGUgcG9pbnQgYmVpbmcgbWFkZSBkb2Vzbid0IHJlcXVpcmUgdGhhdCB0aGUg cmVzcG9uc2UgYmUgNnh4IG9yDQo+ICA+Pj4+PiB0aGF0IGl0IGJlIHdpdGggdGhlIHB1cnBvc2Ug b2YgcmVmdXNpbmcgdGhlIG1lZGlhLiBTbyBJIHRoaW5rIA0Kd2hhdA0KPiAgPj4+Pj4gaXMgbmVl ZGVkIGhlcmUgaXMgdG8gZmluZCBhIHBsYXVzaWJsZSBleGFtcGxlIHRvIG1ha2UgdGhlIHBvaW50 Lg0KPiAgPj4+Pj4NCj4gID4+Pj4+IEEgZ29vZCBvbmUgZm9yIHRoZSBwdXJwb3NlIGhlcmUgbWln aHQgYmUgYSA0ODggdG8gcmVqZWN0IHRoZSANCm1lZGlhLA0KPiAgPg0KPiAgPj4+Pj4gb3IgYSAg NDAxIHJlc3BvbnNlIGFzIGFub3RoZXIgc29ydCBvZiByZWFzb24gZm9yIHJlamVjdGluZyB0aGUN Cj4gID4+Pj4+IHdob2xlIHRoaW5nIGJ1dCB3YW50aW5nIHRvIHByZXNlcnZlIHdoYXQgdGhlcmUg aXMuDQo+ICA+Pj4+IHllcywgSSBhZ3JlZSB0aGF0IGEgNDg4IHJlc3BvbnNlIHdvdWxkIGJlIG1v cmUgYXBwcm9wcmlhdGUuIEkgd2lsbA0KPiAgPj4+PiBjaGFuZ2UgdGhhdCBpbiB0aGUgZHJhZnQu DQo+ICA+Pj4+DQo+ICA+Pj4+PiBTZWN0aW9uIDU6DQo+ICA+Pj4+Pg0KPiAgPj4+Pj4+ICAgIEEg Y2hhbmdlIHRvIHRoZSBzZXNzaW9uIHN0YXRlIGlzIGNvbnNpZGVyZWQgdG8gaGF2ZSBiZWVuDQo+ ICA+IGV4ZWN1dGVkDQo+ICA+Pj4+Pj4gICAgd2hlbiB0aGUgbmV3IG1lZGlhIHBhcmFtZXRlcnMg YXJlIGJlaW5nIHVzZWQuICBUaGVyZWZvcmUsIGENCj4gID4+Pj4+PiBjaGFuZ2UgdG8NCj4gID4+ Pj4+PiAgICBhIHN0cmVhbSBzdWJqZWN0IHRvIHByZWNvbmRpdGlvbnMgW1JGQzQwMzJdIGlzIGNv bnNpZGVyZWQgdG8NCj4gID4gaGF2ZQ0KPiAgPj4+Pj4+ICAgIGJlZW4gZXhlY3V0ZWQgd2hlbiB0 aGUgbmV3IG1lZGlhIHBhcmFtZXRlcnMgc3RhcnQgYmVpbmcgdXNlZDsNCj4gID4gbm90DQo+ICA+ Pj4+Pj4gICAgd2hlbiB0aGUgcHJlY29uZGl0aW9ucyBmb3IgdGhlIHN0cmVhbSBhcmUgbWV0LiAN ClVuc3VycHJpc2luZ2x5LA0KPiAgPiB0aGUNCj4gID4+Pj4+PiAgICBVQVMgY29uc2lkZXJzIHRo ZSBuZXcgcGFyYW1ldGVycyB0byBiZSBpbiB1c2Ugd2hlbiBpdCANCmFjdHVhbGx5DQo+ICA+Pj4+ Pj4gc3RhcnRzDQo+ICA+Pj4+Pj4gICAgdXNpbmcgdGhlbS4NCj4gID4+Pj4+IEknbSBub3QgZW50 aXJlbHkgZm9sbG93aW5nIHRoaXMuIEkgdGhpbmsgdGhlcmUgbWF5IGJlIGFuIA0KYXNzdW1wdGlv bg0KPiAgPg0KPiAgPj4+Pj4gaGVyZSB0aGF0IHRoZSBVQUMgaXMgdGhlIG9mZmVyZXIgYW5kIHRo ZSBVQVMgdGhlIGFuc3dlcmVyLiBJJ20NCj4gID4+Pj4+IGd1ZXNzaW5nIHlvdSBhcmUgc2F5aW5n IHRoYXQgdGhlIGFuc3dlcmVyIGNvbnNpZGVycyB0aGUgbmV3DQo+ICA+Pj4+PiBwYXJhbWV0ZXJz IHRvIGJlIGluIHVzZSB3aGVuIGl0IGFjdHVhbGx5IHN0YXJ0cyB1c2luZyB0aGVtLg0KPiAgPj4+ Pj4NCj4gID4+Pj4+IFNpbmNlIHRoaXMgc2VjdGlvbiBpcyBhYm91dCB0aGUgVUFTIChmb3IgdGhl IHJlaW52aXRlKSwgdGhpcyANCnBvaW50DQo+ICA+Pj4+PiBpcyBwcm9iYWJseSB0aGF0IHdoZW4g dGhlIFVBUyBpcyBhbHNvIHRoZSBhbnN3ZXJlciBpdCBjYW4gZGVjaWRlDQo+ICA+Pj4+PiB3aGVu IHRoZSBuZXcgbWVkaWEgaXMgaW4gdXNlIGJhc2VkIG9uIHdoZW4gaXQgc3RhcnRzIHVzaW5nIHRo ZW0uDQo+ICA+Pj4+Pg0KPiAgPj4+Pj4gQnV0IHdoYXQgaGFwcGVucyB3aGVuIHRoZSBVQVMgaXMg dGhlIG9mZmVyZXI/IEluIHRoYXQgY2FzZSBJIA0KdGhpbmsNCj4gID4+Pj4+IGl0IG11c3QgYXNz dW1lIHRoZSBtZWRpYSBpcyBpbiB1c2UgYXMgc29vbiBhcyBpdCBpcyBvZmZlcmVkLiBCdXQNCj4g ID4+Pj4+IG1heWJlIHRoYXQgaXNuJ3QgYWx3YXlzIHRoZSBjYXNlIHdpdGggcHJlY29uZGl0aW9u cy4gSSBkb24ndCANCnRoaW5rDQo+ICA+Pj4+PiBpdCBjYW4gd2FpdCB0aWxsIGl0IHJlY2VpdmVz IG1lZGlhLCBiZWNhdXNlIG1lZGlhIG1heSBiZSBpbiANCmZsaWdodA0KPiAgPj4+Pj4gd2hlbiBp dCBtYWtlcyBpdHMgZGVjaXNpb24uDQo+ICA+Pj4+IHllcywgdGhlIGRyYWZ0IGFzc3VtZXMgdGhh dCB0aGUgVUFTIGlzIHRoZSBhbnN3ZXJlciBiZWNhdXNlIHRoYXQgDQp3YXMNCj4gID4NCj4gID4+ Pj4gdGhlIHVzZSBjYXNlIGJlaW5nIGRpc2N1c3NlZCBvcmlnaW5hbGx5LiBIb3dldmVyLCB5b3Ug YXJlIHJpZ2h0IA0KdGhhdA0KPiAgPg0KPiAgPj4+PiB3ZSBzaG91bGQgYWxzbyBjb3ZlciB0aGUg Y2FzZSB3aGVyZSB0aGUgVUFTIGlzIHRoZSBvZmZlcmVyLiBJIHdpbGwNCj4gID4+Pj4gbG9vayBp bnRvIGl0IGFuZCBhZGQgdGV4dCBhYm91dCBpdCBpbiB0aGUgZHJhZnQuDQo+ICA+Pj4+DQo+ICA+ Pj4+Pj4gICAgQXMgZGVzY3JpYmVkIGluIFNlY3Rpb24gOC4zLjEgb2YgUkZDIDMyNjQgW1JGQzMy NjRdLCB0aGUNCj4gID4+Pj4+PiAgICBVQUMgY29uc2lkZXJzIHRoZSBuZXcgcGFyYW1ldGVycyB0 byBiZSBpbiB1c2Ugd2hlbiBtZWRpYSBpcw0KPiAgPj4+Pj4+IHJlY2VpdmVkDQo+ICA+Pj4+Pj4g ICAgaW4gdGhlIG5ldyBwb3J0LCB3aGljaCBzaG91bGQgYmUgaW50ZXJwcmV0ZWQgYXMgZm9sbG93 czoNCj4gID4+Pj4+Pg0KPiAgPj4+Pj4+ICAgICAgIFJlY2VpdmVkLCBpbiB0aGlzIGNhc2UsIG1l YW5zIHRoYXQgdGhlIG1lZGlhIGlzIHBhc3NlZCB0byANCmENCj4gID4+Pj4+PiBtZWRpYQ0KPiAg Pj4+Pj4+ICAgICAgIHNpbmsuICBUaGlzIG1lYW5zIHRoYXQgaWYgdGhlcmUgaXMgYSBwbGF5b3V0 IGJ1ZmZlciwgdGhlDQo+ICA+IGFnZW50DQo+ICA+Pj4+Pj4gICAgICAgd291bGQgY29udGludWUg dG8gbGlzdGVuIG9uIHRoZSBvbGQgcG9ydCB1bnRpbCB0aGUgbWVkaWEgDQpvbg0KPiAgPiB0aGUN Cj4gID4+Pj4+PiAgICAgICBuZXcgcG9ydCByZWFjaGVkIHRoZSB0b3Agb2YgdGhlIHBsYXlvdXQg YnVmZmVyLiAgQXQgdGhhdA0KPiAgPj4+Pj4+IHRpbWUsIGl0DQo+ICA+Pj4+Pj4gICAgICAgTUFZ IGNlYXNlIGxpc3RlbmluZyBmb3IgbWVkaWEgb24gdGhlIG9sZCBwb3J0Lg0KPiAgPj4+Pj4gSSBk b24ndCBrbm93IHdoYXQgdGhlIGFib3ZlIGhhcyB0byBkbyB3aXRoIHRoZSBiZWhhdmlvciBvZiB0 aGUgDQpVQVMuDQo+ICA+Pj4+IFRoZSBVQUMgbmVlZHMgdG8ga25vdyB3aGVuIHRoZSBuZXcgcGFy YW1ldGVycyBhcmUgaW4gdXNlIGluIG9yZGVyIA0KdG8NCj4gID4NCj4gID4+Pj4gaW1wbGVtZW50 IHRoZSBub3JtYXRpdmUgYmVoYXZpb3IgaW4gU2VjdGlvbiA2Og0KPiAgPj4+Pg0KPiAgPj4+PiAg ICAuLi4gYSBVQUMgdGhhdCByZWNlaXZlcyBhbiBlcnJvciByZXNwb25zZSB0byBhIHJlLUlOVklU RSBmb3INCj4gID4gd2hpY2gNCj4gID4+Pj4gICAgY2hhbmdlcyBoYXZlIGJlZW4gYWxyZWFkeSBl eGVjdXRlZCAuLi4NCj4gID4+Pj4NCj4gID4+Pj4gSW4gYW55IGNhc2UsIEkgd2lsbCBjbGFyaWZ5 IGFsbCB0aGlzIHdoZW4gSSB3cml0ZSB0aGUgdGV4dCBhYm91dCANCnRoZQ0KPiAgPg0KPiAgPj4+ PiBVQVMgYmVpbmcgdGhlIG9mZmVyZXIgYmVjYXVzZSB0aGlzIHR5cGUgb2YgYmVoYXZpb3IgaGFz IHRvIGRvIHdpdGgNCj4gID4+Pj4gYmVpbmcgdGhlIG9mZmVyZXIgb3IgdGhlIGFuc3dlcmVyLCBu b3QgdGhlIFVBQyBvciB0aGUgVUFTLg0KPiAgPj4+Pg0KPiAgPj4+Pg0KPiAgPj4+Pj4+IDkuICBD bGFyaWZpY2F0aW9ucyBvbiBUYXJnZXQgUmVmcmVzaCBSZXF1ZXN0cw0KPiAgPj4+PiB0aGUgY3Vy cmVudCB0ZXh0IGlzIGEgc3RyYXcgbWFuIHRoYXQgcHV0cyB0YXJnZXQgcmVmcmVzaGVzIGluIHRo ZQ0KPiAgPj4+PiBzYW1lIGNhdGVnb3J5IGFzIGFueSBvdGhlciBjaGFuZ2UuIFRoZSBvdGhlciBv cHRpb24gd2UgdGFsa2VkIA0KYWJvdXQNCj4gID4+Pj4gaW4gdGhlIHBhc3Qgd2FzIHRvIHNwZWNp YWwgY2FzZSB0aGVtIHNvIHRoYXQgdGhleSBhcmUgdHJlYXRlZA0KPiAgPj4+PiBkaWZmZXJlbnRs eS4gWW91IHNlZW0gdG8gbGlrZSB0aGUgbGF0dGVyIG9wdGlvbiBiZXR0ZXIuIFdoYXQgZG8gDQp5 b3UNCj4gID4+Pj4gdGhpbmsgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0Pw0KPiAgPj4+Pg0KPiAg Pj4+Pg0KPiAgPj4+PiA8c2VjdGlvbiB0aXRsZT0iQ2xhcmlmaWNhdGlvbiBvbiB0aGUgQXRvbWlj aXR5IG9mIFRhcmdldCBSZWZyZXNoDQo+ICA+Pj4+IFJlcXVlc3RzIg0KPiAgPj4+PiBhbmNob3I9 InNlYy1hdG9tIj4NCj4gID4+Pj4gPHQ+DQo+ICA+Pj4+IFRoZSByZW1vdGUgdGFyZ2V0IG9mIGEg ZGlhbG9nIGlzIGEgc3BlY2lhbCB0eXBlIG9mIHN0YXRlIA0KaW5mb3JtYXRpb24NCj4gID4NCj4g ID4+Pj4gYmVjYXVzZSBvZiBpdHMgZXNzZW50aWFsIHJvbGUgaW4gdGhlIGV4Y2hhbmdlIG9mIFNJ UCBtZXNzYWdlcw0KPiAgPj4+PiBiZXR3ZWVuIFVBcyBpbiBhIGRpYWxvZy4gQSBVQSBpbnZvbHZl ZCBpbiBhIGRpYWxvZyByZWNlaXZlcyB0aGUNCj4gID4+Pj4gcmVtb3RlIHRhcmdldCBvZiB0aGUg ZGlhbG9nIGZyb20gdGhlIHJlbW90ZSBVQS4gVGhlIFVBIHVzZXMgdGhlDQo+ICA+Pj4+IHJlbW90 ZSB0YXJnZXQgdG8gc2VuZCBTSVAgcmVxdWVzdHMgdG8gdGhlIHJlbW90ZSBVQS4NCj4gID4+Pj4g PC90Pg0KPiAgPj4+PiA8dD4NCj4gID4+Pj4gVGhlIHJlbW90ZSB0YXJnZXQgaXMgYSBwaWVjZSBv ZiBzdGF0ZSBpbmZvcm1hdGlvbiB0aGF0IGlzIG5vdCANCm1lYW50DQo+ICA+Pj4+IHRvIGJlIG5l Z290aWF0ZWQuIFdoZW4gYSBVQUMgY2hhbmdlcyBpdHMgYWRkcmVzcywgdGhlIFVBQyBzaW1wbHkN Cj4gID4+Pj4gY29tbXVuaWNhdGVzIGl0cyBuZXcgYWRkcmVzcyB0byB0aGUgVUFTIGluIG9yZGVy IHRvIHJlbWFpbiANCnJlYWNoYWJsZQ0KPiAgPg0KPiAgPj4+PiBieSB0aGUgVUFTLiBBcyBkZXNj cmliZWQgaW4gPHhyZWYgdGFyZ2V0PSJzZWMtYmFjay1hdG9tIi8+LCBhIFVBUw0KPiAgPj4+PiBz dGFydHMgdXNpbmcgdGhlIG5ldyByZW1vdGUgdGFyZ2V0IGFzIHNvb24gYXMgdGhlIHRhcmdldCBy ZWZyZXNoDQo+ICA+Pj4+IHJlcXVlc3QgaXMgcmVjZWl2ZWQsIHJlZ2FyZGxlc3Mgb2YgdGhlIHJl c3BvbnNlIHRoZSBVQVMgZ2VuZXJhdGVzIA0KdG8NCj4gID4NCj4gID4+Pj4gdGhhdCByZXF1ZXN0 LiBUaGF0IGlzLCBldmVuIGlmIHRoZSBVQVMgZ2VuZXJhdGVzIGFuIGVycm9yIHJlc3BvbnNlDQo+ ICA+Pj4+IHRvIHRoZSB0YXJnZXQgcmVmcmVzaCByZXF1ZXN0LCB0aGUgVUFTIG5lZWRzIHRvIHVw ZGF0ZSB0aGUgDQpkaWFsb2cncw0KPiAgPj4+PiByZW1vdGUgdGFyZ2V0IFVSSS4NCj4gID4+Pj4g PC90Pg0KPiAgPj4+PiA8dD4NCj4gID4+Pj4gVGhlIGZhY3QgdGhhdCBhIHRhcmdldCByZWZyZXNo IHJlcXVlc3QgdXBkYXRlcyB0aGUgcmVtb3RlIHRhcmdldA0KPiAgPj4+PiByZWdhcmRsZXNzIG9m IHRoZSByZXNwb25zZSBpdCB0cmlnZ2VycyBpbXBsaWVzIHRoYXQgdGFyZ2V0IHJlZnJlc2gNCj4g ID4+Pj4gcmVxdWVzdHMgYXJlIG5vdCBhdG9taWMuIFRoYXQgaXMsIGFuIGVycm9yIHJlc3BvbnNl IHRvIGEgdGFyZ2V0DQo+ICA+Pj4+IHJlZnJlc2ggcmVxdWVzdCB3aWxsIGtlZXAgYWxsIGNoYW5n ZXMgYXNzb2NpYXRlZCB0byB0aGUgcmVxdWVzdCANCmZyb20NCj4gID4NCj4gID4+Pj4gYmVpbmcg cGVyZm9ybWVkIGV4Y2VwdCBmb3IgdGhlIHJlZnJlc2ggb2YgdGhlIHJlbW90ZSB0YXJnZXQsIHdo aWNoDQo+ICA+Pj4+IHdpbGwgYmUgcGVyZm9ybWVkIGFueXdheS4NCj4gID4+Pj4gPC90Pg0KPiAg Pj4+PiA8L3NlY3Rpb24+DQo+ICA+Pj4+DQo+ICA+Pj4+DQo+ICA+Pj4+IENoZWVycywNCj4gID4+ Pj4NCj4gID4+Pj4gR29uemFsbw0KPiAgPj4+Pg0KPiAgPj4NCj4gID4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gID4gc2lwY29yZSBtYWlsaW5nIGxp c3QNCj4gID4gc2lwY29yZUBpZXRmLm9yZw0KPiAgPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4gID4NCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBp ZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUN Cj4gDQo+IA0KPiANCj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCj4gWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhlIGlu Zm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgDQppcyBzb2xlbHkgcHJvcGVydHkgb2Yg dGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gDQppcyBj b25maWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWlu dGFpbiBzZWNyZWN5IA0KYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250 ZW50cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gDQpvdGhlcnMuDQo+IFRoaXMgZW1haWwgYW5k IGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIA0KaW50 ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3 aG9tIHRoZXkgYXJlIA0KYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWls IGluIGVycm9yIHBsZWFzZSBub3RpZnkgdGhlIA0Kb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4g QW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIA0Kb2YgdGhlIGlu ZGl2aWR1YWwgc2VuZGVyLg0KPiBUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3Igdmly dXNlcyBhbmQgU3BhbSBieSBaVEUgQW50aS1TcGFtIA0Kc3lzdGVtLg0KDQoNCg0KDQoNCg0KLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpU RSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQg aW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2VuZGVyJ3Mgb3JnYW5pemF0 aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRpYWwuIFJlY2lwaWVudHMg bmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNyZWN5IGFuZCBhcmUgbm90 IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9u IHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFuc21pdHRlZCB3aXRoIGl0 IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUg aW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRyZXNzZWQuIElmIHlvdSBo YXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2lu YXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBpbiB0aGlzIG1lc3NhZ2Ug YXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMgbWVzc2FnZSBoYXMgYmVl biBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 003F935E482575FF_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIDwvZm9udD48Zm9udCBzaXpl PTI+PHR0PkdvbnphbG88L3R0PjwvZm9udD48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+ LDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+T0suPC9m b250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGFuay48L2Zv bnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdhbzwvZm9udD4N Cjxicj4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQogWmlwICZuYnNwOyAmbmJzcDs6IDIxMDAx Mjxicj4NCiBUZWwgJm5ic3A7ICZuYnNwOzogODcyMTE8YnI+DQogVGVsMiAmbmJzcDsgOigrODYp LTAyNS01Mjg3NzIxMTxicj4NCiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbjxicj4NCj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJy Pg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0yNiU+PGZv bnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkdvbnphbG8gQ2FtYXJpbGxvICZsdDtHb256 YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb20mZ3Q7PC9iPg0KPC9mb250Pg0KPHA+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjIwMDktMDctMjYgMTg6NTE8L2ZvbnQ+DQo8dGQgd2lkdGg9 NzMlPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxp Z249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rp dj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+Z2FvLnlhbmcyQHp0ZS5jb20u Y248L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQg c2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6 ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlBhdWwgS3l6aXZhdCAmbHQ7cGt5eml2YXRAY2lzY28uY29t Jmd0OywNCkNocmlzdGVyIEhvbG1iZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5j b20mZ3Q7LCBTSVBDT1JFICZsdDtzaXBjb3JlQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxp Z249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1z ZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJp ZiI+UmU6ILTwuLQ6IFJlOiBbc2lwY29yZV0gTmV3IHJldmlzaW9uDQpvZiB0aGUgcmUtSU5WSVRF IGhhbmRsaW5nIGRyYWZ0PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWdu PXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yPjx0dD5IaSBHYW8sPGJyPg0KPGJyPg0KSSBkbyBub3Qgc2VlIHRoZSBuZWVk IHRvIGhhdmUgYSBmYWNlLXRvLWZhY2UgcHJlc2VudGF0aW9uIG9uIHRoaXMgdG9waWM8YnI+DQph dCB0aGlzIHBvaW50LiBXZSBhbHJlYWR5IGhhdmUgYW4gYWdyZWVkIGFuZCBkb2N1bWVudGVkLWlu LWEtZHJhZnQ8YnI+DQpzb2x1dGlvbiBmb3IgdGhlIHNlc3Npb24gc3RhdGUgYW5kIHdpbGwgaGF2 ZSBhIHNvbHV0aW9uIGZvciB0aGUgdGFyZ2V0PGJyPg0KcmVmcmVzaCBzdHVmZiB2ZXJ5IHNvb24g YXMgd2VsbCAodGhlIGRpc2N1c3Npb25zIGFyZSBhbHJlYWR5PGJyPg0KY29udmVyZ2luZykuIExl dCdzIGZpbmlzaCB0aGlzIG9uIHRoZSBsaXN0Ljxicj4NCjxicj4NCkNoZWVycyw8YnI+DQo8YnI+ DQpHb256YWxvPGJyPg0KPGJyPg0KPGJyPg0KZ2FvLnlhbmcyQHp0ZS5jb20uY24gd3JvdGU6PGJy Pg0KJmd0OyA8YnI+DQomZ3Q7IEhpLDxicj4NCiZndDsgPGJyPg0KJmd0OyBJIGFtIGF0IFN0b2Nr aG9sbSBub3cuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgb25jZSBhc2tlZCBQYXVsIGFib3V0IHRo aXMgSUVURiBtZWV0aW5nLiBIZSBzYWlkIHRoYXQgaGUgd291bGQgYmUNCnRvbyA8YnI+DQomZ3Q7 IGJ1c3kgdG8gYXR0ZW5kIHRoaXMgdGltZS4gSXQgaXMgYSBwaXR5Ljxicj4NCiZndDsgPGJyPg0K Jmd0OyBBbmQgYXMgd2Uga25vdywgdGhlcmUgaXMgYSBtaWxlc3RvbmUgZm9yIGNvcnJlY3Rpb24g b2YgUkZDMzI2MS4gQW5kDQpJIDxicj4NCiZndDsgdGhpbmsgc2Vzc2lvbiBzdGF0ZSBhbmQgZGlh bG9nIHN0YXRlIGNvcnJlY3Rpb24gYXJlIGltcG9ydGFudCBwYXJ0cw0Kb2YgPGJyPg0KJmd0OyB0 aGlzIGNvcnJlY3Rpb24uPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEFuZCBpZiB3ZSBjYW4gbm90aWZ5 IHRoZSB0YWxrIGluIHRoZSBtZWV0aW5nIGluIHRoZSBtYWlsbGlzdCBhbmQgY29sbGVjdA0KPGJy Pg0KJmd0OyB2aWV3cG9pbnQgZnJvbSB0aGUgbWFpbGxpc3Qgb24gdGltZSwgd2UgY2FuIGhhdmUg YSB0YWxrIGFzIGlmIHBlb3BsZQ0KPGJyPg0KJmd0OyBjb25jZXJuaW5nIHRoaXMgdG9waWMgYXJl IG9uIHRoZSBzY2VuZS4gQW5kIHRoaXMgY2FuIG1ha2UgdGhlIHRhbGsNCmZhc3QgPGJyPg0KJmd0 OyBhbmQgZWZmZWN0aXZlLjxicj4NCiZndDsgPGJyPg0KJmd0OyBJZiBHb256YWxvIGhhcyB0aW1l LCBoZSBjYW4gYmUgdGhlIHByb3BlciBwZXJzb24gdG8gdGFrZSBjaGFyZ2Ugb2YNCnRoaXMgPGJy Pg0KJmd0OyB0YWxrLjxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFua3MuPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IEdhbzxicj4NCiZndDsgPGJyPg0KJmd0OyA9PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PTxicj4NCiZndDsgWmlwICZuYnNwOyAmbmJzcDs6IDIxMDAxMjxicj4NCiZndDsg VGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KJmd0OyBUZWwyICZuYnNwOyA6KCs4NiktMDI1 LTUyODc3MjExPGJyPg0KJmd0OyBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbjxicj4NCiZn dDsgPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQomZ3Q7IDxicj4NCiZn dDsgPGJyPg0KJmd0OyAqUGF1bCBLeXppdmF0ICZsdDtwa3l6aXZhdEBjaXNjby5jb20mZ3Q7Kjxi cj4NCiZndDsgNyZxdW90OyZsdDt+SEs6ICZuYnNwO3NpcGNvcmUtYm91bmNlc0BpZXRmLm9yZzxi cj4NCiZndDsgPGJyPg0KJmd0OyAyMDA5LTA3LTI0IDIxOjEzPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7PGJyPg0KJmd0OyBKVSZsdDt+SEs8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Q2hyaXN0ZXINCkhvbG1i ZXJnICZsdDtjaHJpc3Rlci5ob2xtYmVyZ0Blcmljc3Nvbi5jb20mZ3Q7PGJyPg0KJmd0OyAzLUtN PGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwO2dhby55YW5nMkB6dGUuY29tLmNuLA0KU0lQQ09SRSAmbHQ7c2lwY29y ZUBpZXRmLm9yZyZndDssIEdvbnphbG8gQ2FtYXJpbGxvIDxicj4NCiZndDsgJmx0O2dvbnphbG8u Y2FtYXJpbGxvQGVyaWNzc29uLmNvbSZndDs8YnI+DQomZ3Q7IFZ3TGI8YnI+DQomZ3Q7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7 UmU6DQpbc2lwY29yZV0gTmV3IHJldmlzaW9uIG9mIHRoZSByZS1JTlZJVEUgaGFuZGxpbmcgZHJh ZnQ8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsgPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgPGJyPg0KJmd0OyBDaHJpc3RlciBIb2xtYmVyZyB3cm90ZTo8YnI+DQomZ3Q7ICZuYnNwOyZn dDsgSGksPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IEkgYW0ganVz dCByZS1ib290aW5nIGFmdGVyIG15IHN1bW1lciB2YWNhdGlvbiwgYW5kIEkgaGF2ZQ0KTk9UIGJl ZW4gYWJsZTxicj4NCiZndDsgJm5ic3A7Jmd0OyB0byByZWFkIGFsbCBlLW1haWxzIGluIHRoaXMg dGhyZWFkIHlldC4gU28sIEkgYXBwb2xvZ2l6ZQ0KaWYgc29tZXRoaW5nPGJyPg0KJmd0OyAmbmJz cDsmZ3Q7IGhhcyBiZWVuIGRpc2N1c3NlZC48YnI+DQomZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7 ICZuYnNwOyZndDsgUmVnYXJkaW5nIHRoZSBwcm9wb3NhbCB0byBub3QgYmUgYWJsZSB0byByZWpl Y3QgYSB0YXJnZXQNCnVwZGF0ZS4gSWYgeW91PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IHVzZSBPdXRi b3VuZCwgd2hlcmUgeW91IGhhdmUgY3JlYXRlZCB0aGUgTkFUIGJpbmRpbmcgYXMNCnBhcnQgb2Yg dGhlPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IHJlZ2lzdHJhdGlvbiwgYSB0YXJnZXQgcmVmcmVzaCBj YW4gbm90IGJlIHBlcmZvcm1lZCwgYmVjYXVzZQ0KdGhlPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IHNp Z25hbGxpbmcgd291bGRuJ3QgcmVhY2ggdGhlIGNsaWVudCBiZWhpbmQgdGhlIE5BVCBhbnltb3Jl Lg0KWW91IHdvdWxkPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IG5lZWQgdG8gcGVyZm9ybSBhIHJlLXJl Z2lzdHJhdGlvbi48YnI+DQomZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsgTm93 LCB3ZSBjb3VsZCBvZiBjb3Vyc2Ugc2F5IHRoYXQgYSBjbGllbnQgdXNpbmcgT3V0Ym91bmQNCnNo YWxsIG5vdDxicj4NCiZndDsgJm5ic3A7Jmd0OyBwZXJmb3JtIGEgdGFyZ2V0IHJlZnJlc2ggaW4g dGhlIGZpcnN0IHBsYWNlLiBCVVQsIHRoZSBzYW1lDQppc3N1ZSBhbHNvPGJyPg0KJmd0OyAmbmJz cDsmZ3Q7IGFwcGx5IHRvIG90aGVyIHJlZ2lzdHJhdGlvbi1iYXNlZCBOQVQgdHJhdmVyc2FsIG1l Y2hhbmlzbXMNCi0gaW4gc29tZTxicj4NCiZndDsgJm5ic3A7Jmd0OyBjYXNlcyB0aGUgY2xpZW50 IGJlaGluZCB0aGUgTkFUIG1heSBub3QgZXZlbiBiZSBhd2FyZSBvZg0KdGhvc2UuPGJyPg0KJmd0 OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IFNvLCBpZiB3ZSB3YW50IHRvIHNheSB0 aGF0IG9uZSBjYW5ub3QgcmVqZWN0IGEgdGFyZ2V0IHJlZnJlc2gNCndlIG5lZWQgdG88YnI+DQom Z3Q7ICZuYnNwOyZndDsgbWFrZSBzdXJlIHdlIGRvbid0IGNyZWF0ZSBhIG5ldyBjYW5ub3QtcmVq ZWN0LW9mZmVyLWluLVBSQUNLDQp0eXBlIG9mPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IHByb2JsZW0u Li48YnI+DQomZ3Q7IDxicj4NCiZndDsgRmlyc3QsIEknbSBub3Qgc2F5aW5nIHlvdSBjYW4ndCBy ZWplY3QgYSB0YXJnZXQgcmVmcmVzaC48YnI+DQomZ3Q7IFJlY29tbWVuZGluZyB5b3Ugc2hvdWxk bid0IHJlamVjdCBpdCBpZiB5b3UgaGF2ZSBhbHRlcm5hdGl2ZXMgaXMgbm90DQp0aGU8YnI+DQom Z3Q7IHNhbWUuIEZvciBpbnN0YW5jZSBpZiB5b3UgaGF2ZSBhbiBhdXRob3JpemF0aW9uIGZhaWx1 cmUgdGhlbiB5b3Ugc2hvdWxkPGJyPg0KJmd0OyBkZWZpbml0ZWx5IHJlamVjdCBpdC48YnI+DQom Z3Q7IDxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgSSdtIGRvbid0IGtub3cgaWYgd2UgYXJlIG9u IHF1aXRlIHRoZSBzYW1lIHBhZ2UgeWV0Ljxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgT25jZSBh Y2NlcHRlZCwgSSBkb24ndCB0aGluayBhIHRhcmdldCByZWZyZXNoIHNob3VsZA0KYmUgcm9sbGVk IGJhY2sgYnk8YnI+DQomZ3Q7ICZuYnNwOyZndDsgYW55dGhpbmcuPGJyPg0KJmd0OyAmbmJzcDsm Z3Q7Jmd0OyBBIGtleSB1c2UgY2FzZSBtaWdodCBiZTo8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7 PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyBJJ3ZlIHN0YXJ0ZWQgYW4gcmVJTlZJVEUgLSBvbmUg dGhhdCBtaWdodCB0YWtlIGF3aGlsZQ0KYmVjYXVzZSBpdCBpczxicj4NCiZndDsgJm5ic3A7Jmd0 OyB0cnlpbmcgdG8gYWRkIG1lZGlhIGFuZCB0aGUgb3RoZXIgZW5kIGlzIGFsZXJ0aW5nPGJyPg0K Jmd0OyAmbmJzcDsmZ3Q7Jmd0OyBhYm91dCB0aGF0Ljxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDs8 YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IFdoaWxlIHRoYXQgaXMgaW4gcHJvZ3Jlc3MgSSBsb3Nl IG15IElQIGFkZHJlc3MgYW5kDQpuZWVkIHRvIHRhcmdldDxicj4NCiZndDsgJm5ic3A7Jmd0OyBy ZWZyZXNoLiBTbyB3aGF0IGRvIEkgZG8/PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyBJIHRoaW5r IEkgc2VuZCBhbiBVUERBVEUsIHdoaWNoIHdpbGwgYmUgaW4gdGhlIG1pZHN0DQpvZiB0aGUgcmVJ TlZJVEU8YnI+DQomZ3Q7ICZuYnNwOyZndDsgdHJhbnNhY3Rpb24uIEkgbWFrZSBpdCBhIHNpbXBs ZSBvbmUsIGluIHRoYXQgaXQ8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IGluY2x1ZGVzIG5vIG8v YSwgaXRzICpqdXN0KiBhIHRhcmdldCByZWZyZXNoLjxicj4NCiZndDsgJm5ic3A7Jmd0Ozxicj4N CiZndDsgJm5ic3A7Jmd0OyBJbiBtb3N0IGNhc2VzLCB3b24ndCB5b3UgdXNlIHRoZSBzYW1lIElQ IGFkZHJlc3MgZm9yIHNpZ25hbGxpbmcNCmFuZDxicj4NCiZndDsgJm5ic3A7Jmd0OyBtZWRpYT8g U28sIGlmIHlvdSd2ZSBsb3N0IGl0IHlvdSB3b3VsZCBuZWVkIHRvIHJlLW5lZ290aWF0ZQ0KdGhl IG1lZGlhPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IHBhcmFtZXRlcnMgYWxzby4uLjxicj4NCiZndDsg PGJyPg0KJmd0OyBZZXMsIHlvdSB3aWxsIHByb2JhYmx5IG5lZWQgdG8gcmVuZWdvdGlhdGUgdGhl IG1lZGlhIHRvby4gQnV0IHRoYXQNCmlzbid0PGJyPg0KJmd0OyBxdWl0ZSBhcyB1cmdlbnQuIElm IG5lZWQgYmUgaXQgY2FuIHdhaXQgdW50aWwgeW91IGhhdmUgYSB3b3JraW5nPGJyPg0KJmd0OyBz aWduYWxpbmcgcGF0aCBhZ2Fpbi48YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7Jmd0OyBJIHRo aW5rIGl0IHdvdWxkIGJlIG11Y2ggYmV0dGVyIGZvciB0aGUgVUFDIHRvIGZpcnN0IGNhbmNlbA0K dGhlPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IHJlLUlOVklURSwgYW5kIHRoZW4gZG8gdGhlIHRhcmdl dCByZWZyZXNoIGFuZCByZS1zdGFydA0KdGhlIG8vYTxicj4NCiZndDsgJm5ic3A7Jmd0OyB0cmFu c2FjdGlvbi48YnI+DQomZ3Q7IDxicj4NCiZndDsgQXMgSSBub3RlZCwgaWYgeW91IGhhdmUgcmVh bGx5IGxvc3QgeW91ciBpcCBhZGRyZXNzLCB0aGVuIHdoaWxlIHlvdQ0KY2FuPGJyPg0KJmd0OyBz ZW5kIHRoZSBDQU5DRUwsIHlvdSB3b24ndCBnZXQgdGhlIGZpbmFsIHJlc3BvbnNlIHRvIHRoZSBy ZUlOVklURQ0KdGhhdDxicj4NCiZndDsgd2FzIGNhbmNlbGVkLiBZb3UgY2FuIGVpdGhlciBzZW5k IHRoZSBDQU5DRUwsIHdhaXQgdGhlIGZ1bGwgdGltZW91dDxicj4NCiZndDsgaW50ZXJ2YWwsIHRo ZW4gc2VuZCBhIG5ldyB0YXJnZXQgcmVmcmVzaCwgb3IgeW91IGNhbiBzZW5kIHRoZSB0YXJnZXQ8 YnI+DQomZ3Q7IHJlZnJlc2ggZmlyc3QgKHNvIHlvdSBrbm93IHlvdSBoYXZlIGEgd29ya2luZyBz aWduYWxpbmcgcGF0aCBhZ2FpbiksPGJyPg0KJmd0OyB0aGVuIHNlbmQgdGhlIENBTkNFTC48YnI+ DQomZ3Q7IDxicj4NCiZndDsgT1RPSCwgaWYgdGhlcmUgaXMgb3ZlcmxhcCBpbiBhZGRyZXNzIGF2 YWlsYWJpbGl0eSAoZS5nLiB5b3VyIHJlbmV3DQpvZjxicj4NCiZndDsgdGhlIGxlYXNlIG9uIHlv dXIgSVAgYWRkcmVzcyB3YXMgcmVqZWN0ZWQgYnV0IGhhc24ndCB5ZXQgZXhwaXJlZCkNCnRoZW48 YnI+DQomZ3Q7IGl0IGluZGVlZCB3b3VsZCBiZSBwcnVkZW50IHRvIHdhaXQgZm9yIGEgcXVpZXNj ZW50IHN0YXRlIGFuZCB0aGVuDQpzZW5kPGJyPg0KJmd0OyB0aGUgcmVmcmVzaC48YnI+DQomZ3Q7 IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyBUaGFua3MsPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFBhdWw8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5i c3A7Jmd0OyBQZXJmb3JtaW5nIHRhcmdldCByZWZyZXNoZXMgaW5zaWRlIG9uZ29pbmcgcmUtSU5W SVRFcyBhcmUNCm9ubHkgZ29pbmcgdG88YnI+DQomZ3Q7ICZuYnNwOyZndDsgY2F1c2UgcHJvYmxl bXMgLSBlc3BlY2lhbGx5IGlmIHlvdSBhcmUgbm90IGFibGUgdG8gcmVjZWl2ZQ0KcmVzcG9uc2Vz IGV0Yzxicj4NCiZndDsgJm5ic3A7Jmd0OyBvbiB0aGUgb2xkIGFkZHJlc3MuPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IFJlZ2FyZHMsPGJyPg0K Jmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IENocmlzdGVyPGJyPg0KJmd0OyAm bmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0K Jmd0OyAmbmJzcDsmZ3Q7Jmd0OyBIaSBQYXVsLDxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDs8YnI+ DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7ICZuYnNwOyZndDsgVGhpcyB3aWxsIGVuY291cmFnZSB1c2lu ZyBhICpzaW1wbGUqIHJlcXVlc3QNCnRvIGRvIGFuIGVzc2VudGlhbDxicj4NCiZndDsgJm5ic3A7 Jmd0OyZndDsgdGFyZ2V0ICZuYnNwOyZndDsgcmVmcmVzaCwgcmF0aGVyIHRoYW4gYSBjb21wbGV4 IG9uZQ0KdGhhdCBoYXMgYSBjaGFuY2Ugb2Y8YnI+DQomZ3Q7ICZuYnNwOyZndDsgZmFpbGluZy48 YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IFllcywgSSBhZ3JlZSB3aXRoIHlvdS4gSSB0aGluayB3 ZSBjYW4gZ2V0IHdoYXQgeW91DQphcmUgbG9va2luZyBmb3IgYnk8YnI+DQomZ3Q7ICZuYnNwOyZn dDsmZ3Q7IGtlZXBpbmcgdGhlIHRleHQgdGhhdCBpcyBjdXJyZW50bHkgaW4gdGhlIGRyYWZ0IChp LmUuLA0KcmUtSU5WSVRFczxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgcmVtYWluIGF0b21pYyBh bmQgYW4gZXJyb3IgcmVzcG9uc2Ugcm9sbHMgZXZlcnl0aGluZw0KYmFjaywgaW5jbHVkaW5nPGJy Pg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyB0aGUgdGFyZ2V0IHJlZnJlc2gpLCBieSBhZGRpbmcgYSBk ZXNjcmlwdGlvbiBvZiB3aHkNCnBpZ2d5YmFja2luZyBvdGhlcjxicj4NCiZndDsgJm5ic3A7Jmd0 Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgY2hhbmdlcyBpbiBhIHRhcmdldCByZWZyZXNoIHJl cXVlc3QgaXMgYSBiYWQgaWRlYSAodGhlDQpuZXcgdGV4dCB3b3VsZDxicj4NCiZndDsgJm5ic3A7 Jmd0OyZndDsgaW5jbHVkZSBhIGRpc2N1c3Npb24gb24gdGhlIFZpYSBwcm9ibGVtIGFuZCBvbiBs ZWdhY3kNClVBU3MgcmVzcG9uZGluZzxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgd2l0aCBhbiBl cnJvciByZXNwb25zZSBldmVuIGlmIGNoYW5nZXMgaGF2ZSBiZWVuIGV4ZWN1dGVkKSwNCmFuZCBi eTxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgZGlzY291cmFnaW5nIHRoZSB1c2Ugb2YgcmUtSU5W SVRFcyB0aGF0IHVwZGF0ZSB0aGUNCnRhcmdldCBhbmQgcGVyZm9ybTxicj4NCiZndDsgJm5ic3A7 Jmd0OyZndDsgb3RoZXIgY2hhbmdlcyBhdCB0aGUgc2FtZSB0aW1lICh3ZSBwcm9iYWJseSBuZWVk IHRvDQpnbyBhcyBmYXIgYXMgdG88YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IHNheSB0aGF0IG9u ZSBTSE9VTEQgTk9UIGRvIGl0KS48YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7PGJyPg0KJmd0OyAm bmJzcDsmZ3Q7Jmd0OyBJIGFncmVlIHdpdGggeW91IHRoYXQgZW5jb3VyYWdpbmcgdGhlIHVzZSBv ZiAmcXVvdDtzaW1wbGUmcXVvdDsNCnJlcXVlc3RzIHdpbGwgYmU8YnI+DQomZ3Q7ICZuYnNwOyZn dDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IGJldHRlciB0aGFuIHNwZWNpZnlpbmcgY29tcGxl eCBiZWhhdmlvciBqdXN0IHRvIGNvdmVyDQpjb3JuZXIgY2FzZXMuPGJyPg0KJmd0OyAmbmJzcDsm Z3Q7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsgVGhhbmtzLDxicj4NCiZndDsgJm5ic3A7 Jmd0OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IEdvbnphbG88YnI+DQomZ3Q7ICZuYnNw OyZndDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyZn dDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7IFBhdWwgS3l6aXZhdCB3cm90ZTo8YnI+DQomZ3Q7 ICZuYnNwOyZndDsmZ3Q7Jmd0OyBHb256YWxvLDxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsgSSBhZ3JlZSB3aXRoIGFsbCB5b3Ugc2F5IGJl bG93LCBleGNlcHQgYXQgdGhlIHZlcnkNCmVuZCBhYm91dCB0YXJnZXQ8YnI+DQomZ3Q7ICZuYnNw OyZndDsmZ3Q7Jmd0OyByZWZyZXNoLjxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsgSWYgdGFyZ2V0IHJlZnJlc2hlcyBhcmUgdG8gYmUgYWNj ZXB0ZWQgZXZlbiBpZg0KdGhlIHJlcXVlc3QgZmFpbHMsPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0 OyZndDsgdGhlbiBpdCBpcyBwb3NzaWJsZSB0byBoaWphY2sgYSBzZXNzaW9uIGV2ZW4gaWYNCmF1 dGhlbnRpY2F0aW9uIGlzPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsgYmVpbmcgdXNlZCBm b3Igc2lnbmFsaW5nLjxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmbmJz cDsmZ3Q7Jmd0OyZndDsgSU1PIGEgdGFyZ2V0IHJlZnJlc2ggbXVzdCBiZSBpZ25vcmVkIGluIGF0 IGxlYXN0DQoqc29tZSogY2FzZXMgd2hlbjxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7IHRo ZSByZXF1ZXN0IGlzIHJlamVjdGVkLiBXZSBjb3VsZCBlbnVtZXJhdGUgdGhlc2UNCmNhc2VzIGlu ZGl2aWR1YWxseSw8YnI+DQomZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7 Jmd0OyBvciBzaW1wbHkgc3RhdGUgdGhhdCBpdCB3aWxsIG9ubHkgYmUgYWNjZXB0ZWQgaWYNCnRo ZSByZXF1ZXN0IGlzPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IGFjY2VwdGVkLjxicj4NCiZndDsgJm5i c3A7Jmd0OyZndDsmZ3Q7IChJbiBjYXNlIG9mIHJlSU5WSVRFLCB0aGF0IHdvdWxkIGJlIGlmIGl0 IHdhcyBhY2NlcHRlZA0Kc3VmZmljaWVudGx5PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsg dG8gcmV0dXJuIGEgMnh4IG9yIGEgMXh4Lik8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7IFRoaXMgd2lsbCBlbmNvdXJhZ2UgdXNpbmcgYSAq c2ltcGxlKiByZXF1ZXN0IHRvDQpkbyBhbiBlc3NlbnRpYWw8YnI+DQomZ3Q7ICZuYnNwOyZndDsm Z3Q7Jmd0OyB0YXJnZXQgcmVmcmVzaCwgcmF0aGVyIHRoYW4gYSBjb21wbGV4IG9uZSB0aGF0DQpo YXMgYSBjaGFuY2Ugb2Y8YnI+DQomZ3Q7ICZuYnNwOyZndDsgZmFpbGluZy48YnI+DQomZ3Q7ICZu YnNwOyZndDsmZ3Q7Jmd0OyBQZXJoYXBzIGl0IHdvbid0IHdvcmsgaW4gYWxsIGNhc2VzLCBidXQg c3VjaCBpcw0KbGlmZS48YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJm5i c3A7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgVGhhbmtzLDxicj4NCiZndDsgJm5ic3A7Jmd0 OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgUGF1bDxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsgR29uemFsbyBDYW1hcmlsbG8gd3JvdGU6PGJy Pg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsmZ3Q7IEhpIFBhdWwsPGJyPg0KJmd0OyAmbmJzcDsm Z3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoYW5rcyBm b3IgeW91ciBjb21tZW50cy4gQW5zd2VycyBpbmxpbmU6PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsmZ3Q7IFBhdWwgS3l6aXZhdCB3 cm90ZTo8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEdvbnphbG8sPGJyPg0K Jmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgVGhhbmtzIGZvciBkb2luZyB0aGlzIHdvcmshIEkgZG8gaGF2ZSBzb21lDQpj b21tZW50czo8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAm bmJzcDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBTZWN0aW9uIDMvRmlndXJlIDE8YnI+DQomZ3Q7ICZu YnNwOyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBUaGUgZmlndXJlIHNob3dzIGEgNnh4IHJlc3BvbnNlLjxicj4NCiZndDsgJm5ic3A7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDsgVGhlIHRleHQgc2F5cyB0aGF0IHRoZSBVQVMgd2FudHMgdG8gcmVq ZWN0DQp0aGUgbmV3IG9mZmVyLjxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEEgVUFTIHdvdWxkIHByb2JhYmx5 IG5vdCB1c2UgYSA2eHggcmVzcG9uc2UNCnRvIHJlamVjdCBtZWRpYS48YnI+DQomZ3Q7ICZuYnNw OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IChJIGd1ZXNzIGl0IG1pZ2h0IHVzZSA2MDYsIGJ1dCA0ODgg d291bGQNCmJlIG1vcmUgYXBwcm9wcmlhdGUuKSBJbjxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgZmFjdCwgaXQgcHJvYmFibHkgd291bGQgbm90IHJlamVjdCB0aGUNCnJlcXVl c3QgYXQgYWxsLCBidXQgcmF0aGVyPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyB3b3VsZCBqdXN0IHJlZnVzZSB0aGUgYWRkZWQgbWVkaWEgc3RyZWFtLjxicj4NCiZndDsgJm5i c3A7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7IFRoZSBwb2ludCBiZWluZyBtYWRlIGRvZXNuJ3QgcmVxdWlyZSB0aGF0DQp0aGUgcmVzcG9u c2UgYmUgNnh4IG9yPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGF0IGl0 IGJlIHdpdGggdGhlIHB1cnBvc2Ugb2YgcmVmdXNpbmcNCnRoZSBtZWRpYS4gU28gSSB0aGluayB3 aGF0PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpcyBuZWVkZWQgaGVyZSBp cyB0byBmaW5kIGEgcGxhdXNpYmxlIGV4YW1wbGUNCnRvIG1ha2UgdGhlIHBvaW50Ljxicj4NCiZn dDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7IEEgZ29vZCBvbmUgZm9yIHRoZSBwdXJwb3NlIGhlcmUgbWlnaHQgYmUNCmEgNDg4 IHRvIHJlamVjdCB0aGUgbWVkaWEsPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJz cDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBvciBhICZuYnNwOzQwMSByZXNwb25zZSBhcyBhbm90aGVy IHNvcnQNCm9mIHJlYXNvbiBmb3IgcmVqZWN0aW5nIHRoZTxicj4NCiZndDsgJm5ic3A7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgd2hvbGUgdGhpbmcgYnV0IHdhbnRpbmcgdG8gcHJlc2VydmUgd2hhdA0K dGhlcmUgaXMuPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsmZ3Q7IHllcywgSSBhZ3JlZSB0 aGF0IGEgNDg4IHJlc3BvbnNlIHdvdWxkIGJlIG1vcmUNCmFwcHJvcHJpYXRlLiBJIHdpbGw8YnI+ DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsgY2hhbmdlIHRoYXQgaW4gdGhlIGRyYWZ0Ljxi cj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgU2VjdGlvbiA1Ojxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7 QSBjaGFuZ2UgdG8gdGhlIHNlc3Npb24NCnN0YXRlIGlzIGNvbnNpZGVyZWQgdG8gaGF2ZSBiZWVu PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IGV4ZWN1dGVkPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwO3doZW4gdGhlIG5ldyBtZWRpYSBwYXJhbWV0ZXJz DQphcmUgYmVpbmcgdXNlZC4gJm5ic3A7VGhlcmVmb3JlLCBhPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgY2hhbmdlIHRvPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwO2Egc3RyZWFtIHN1YmplY3QgdG8gcHJlY29uZGl0 aW9ucw0KW1JGQzQwMzJdIGlzIGNvbnNpZGVyZWQgdG88YnI+DQomZ3Q7ICZuYnNwOyZndDsgaGF2 ZTxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDti ZWVuIGV4ZWN1dGVkIHdoZW4gdGhlDQpuZXcgbWVkaWEgcGFyYW1ldGVycyBzdGFydCBiZWluZyB1 c2VkOzxicj4NCiZndDsgJm5ic3A7Jmd0OyBub3Q8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7d2hlbiB0aGUgcHJlY29uZGl0aW9ucw0KZm9yIHRo ZSBzdHJlYW0gYXJlIG1ldC4gJm5ic3A7VW5zdXJwcmlzaW5nbHksPGJyPg0KJmd0OyAmbmJzcDsm Z3Q7IHRoZTxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAm bmJzcDtVQVMgY29uc2lkZXJzIHRoZSBuZXcNCnBhcmFtZXRlcnMgdG8gYmUgaW4gdXNlIHdoZW4g aXQgYWN0dWFsbHk8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBzdGFy dHM8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7 dXNpbmcgdGhlbS48YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEknbSBub3Qg ZW50aXJlbHkgZm9sbG93aW5nIHRoaXMuIEkgdGhpbmsNCnRoZXJlIG1heSBiZSBhbiBhc3N1bXB0 aW9uPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyBoZXJlIHRoYXQgdGhlIFVBQyBpcyB0aGUgb2ZmZXJlciBhbmQgdGhlDQpVQVMgdGhlIGFu c3dlcmVyLiBJJ208YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGd1ZXNzaW5n IHlvdSBhcmUgc2F5aW5nIHRoYXQgdGhlIGFuc3dlcmVyDQpjb25zaWRlcnMgdGhlIG5ldzxicj4N CiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcGFyYW1ldGVycyB0byBiZSBpbiB1c2Ug d2hlbiBpdCBhY3R1YWxseQ0Kc3RhcnRzIHVzaW5nIHRoZW0uPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgU2lu Y2UgdGhpcyBzZWN0aW9uIGlzIGFib3V0IHRoZSBVQVMgKGZvcg0KdGhlIHJlaW52aXRlKSwgdGhp cyBwb2ludDxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXMgcHJvYmFibHkg dGhhdCB3aGVuIHRoZSBVQVMgaXMgYWxzbyB0aGUNCmFuc3dlcmVyIGl0IGNhbiBkZWNpZGU8YnI+ DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdoZW4gdGhlIG5ldyBtZWRpYSBpcyBp biB1c2UgYmFzZWQgb24gd2hlbg0KaXQgc3RhcnRzIHVzaW5nIHRoZW0uPGJyPg0KJmd0OyAmbmJz cDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgQnV0IHdoYXQgaGFwcGVucyB3aGVuIHRoZSBVQVMgaXMgdGhlIG9mZmVyZXI/DQpJbiB0aGF0 IGNhc2UgSSB0aGluazxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXQgbXVz dCBhc3N1bWUgdGhlIG1lZGlhIGlzIGluIHVzZSBhcyBzb29uDQphcyBpdCBpcyBvZmZlcmVkLiBC dXQ8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1heWJlIHRoYXQgaXNuJ3Qg YWx3YXlzIHRoZSBjYXNlIHdpdGggcHJlY29uZGl0aW9ucy4NCkkgZG9uJ3QgdGhpbms8YnI+DQom Z3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGl0IGNhbiB3YWl0IHRpbGwgaXQgcmVjZWl2 ZXMgbWVkaWEsIGJlY2F1c2UNCm1lZGlhIG1heSBiZSBpbiBmbGlnaHQ8YnI+DQomZ3Q7ICZuYnNw OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdoZW4gaXQgbWFrZXMgaXRzIGRlY2lzaW9uLjxicj4NCiZn dDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0OyB5ZXMsIHRoZSBkcmFmdCBhc3N1bWVzIHRoYXQgdGhl IFVBUyBpcyB0aGUNCmFuc3dlcmVyIGJlY2F1c2UgdGhhdCB3YXM8YnI+DQomZ3Q7ICZuYnNwOyZn dDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsgdGhlIHVzZSBjYXNlIGJlaW5nIGRp c2N1c3NlZCBvcmlnaW5hbGx5LiBIb3dldmVyLA0KeW91IGFyZSByaWdodCB0aGF0PGJyPg0KJmd0 OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdlIHNob3VsZCBh bHNvIGNvdmVyIHRoZSBjYXNlIHdoZXJlIHRoZSBVQVMNCmlzIHRoZSBvZmZlcmVyLiBJIHdpbGw8 YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsgbG9vayBpbnRvIGl0IGFuZCBhZGQgdGV4 dCBhYm91dCBpdCBpbiB0aGUgZHJhZnQuPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwO0Fz IGRlc2NyaWJlZCBpbiBTZWN0aW9uDQo4LjMuMSBvZiBSRkMgMzI2NCBbUkZDMzI2NF0sIHRoZTxi cj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtVQUMg Y29uc2lkZXJzIHRoZSBuZXcNCnBhcmFtZXRlcnMgdG8gYmUgaW4gdXNlIHdoZW4gbWVkaWEgaXM8 YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyByZWNlaXZlZDxicj4NCiZn dDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtpbiB0aGUgbmV3 IHBvcnQsIHdoaWNoDQpzaG91bGQgYmUgaW50ZXJwcmV0ZWQgYXMgZm9sbG93czo8YnI+DQomZ3Q7 ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IFJlY2VpdmVkLCBpbiB0aGlzDQpj YXNlLCBtZWFucyB0aGF0IHRoZSBtZWRpYSBpcyBwYXNzZWQgdG8gYTxicj4NCiZndDsgJm5ic3A7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IG1lZGlhPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgc2luay4gJm5ic3A7VGhpcw0KbWVh bnMgdGhhdCBpZiB0aGVyZSBpcyBhIHBsYXlvdXQgYnVmZmVyLCB0aGU8YnI+DQomZ3Q7ICZuYnNw OyZndDsgYWdlbnQ8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJz cDsgJm5ic3A7ICZuYnNwOyB3b3VsZCBjb250aW51ZQ0KdG8gbGlzdGVuIG9uIHRoZSBvbGQgcG9y dCB1bnRpbCB0aGUgbWVkaWEgb248YnI+DQomZ3Q7ICZuYnNwOyZndDsgdGhlPGJyPg0KJmd0OyAm bmJzcDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbmV3IHBv cnQgcmVhY2hlZA0KdGhlIHRvcCBvZiB0aGUgcGxheW91dCBidWZmZXIuICZuYnNwO0F0IHRoYXQ8 YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aW1lLCBpdDxicj4NCiZn dDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IE1B WSBjZWFzZSBsaXN0ZW5pbmcNCmZvciBtZWRpYSBvbiB0aGUgb2xkIHBvcnQuPGJyPg0KJmd0OyAm bmJzcDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBJIGRvbid0IGtub3cgd2hhdCB0aGUgYWJvdmUgaGFz IHRvIGRvIHdpdGgNCnRoZSBiZWhhdmlvciBvZiB0aGUgVUFTLjxicj4NCiZndDsgJm5ic3A7Jmd0 OyZndDsmZ3Q7Jmd0OyBUaGUgVUFDIG5lZWRzIHRvIGtub3cgd2hlbiB0aGUgbmV3IHBhcmFtZXRl cnMNCmFyZSBpbiB1c2UgaW4gb3JkZXIgdG88YnI+DQomZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7 ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsgaW1wbGVtZW50IHRoZSBub3JtYXRpdmUgYmVoYXZpb3Ig aW4gU2VjdGlvbg0KNjo8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwOy4uLiBhIFVBQyB0aGF0IHJlY2Vp dmVzIGFuIGVycm9yDQpyZXNwb25zZSB0byBhIHJlLUlOVklURSBmb3I8YnI+DQomZ3Q7ICZuYnNw OyZndDsgd2hpY2g8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNw O2NoYW5nZXMgaGF2ZSBiZWVuIGFscmVhZHkgZXhlY3V0ZWQNCi4uLjxicj4NCiZndDsgJm5ic3A7 Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0OyBJbiBhbnkg Y2FzZSwgSSB3aWxsIGNsYXJpZnkgYWxsIHRoaXMgd2hlbiBJDQp3cml0ZSB0aGUgdGV4dCBhYm91 dCB0aGU8YnI+DQomZ3Q7ICZuYnNwOyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZn dDsgVUFTIGJlaW5nIHRoZSBvZmZlcmVyIGJlY2F1c2UgdGhpcyB0eXBlIG9mDQpiZWhhdmlvciBo YXMgdG8gZG8gd2l0aDxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0OyBiZWluZyB0aGUg b2ZmZXJlciBvciB0aGUgYW5zd2VyZXIsIG5vdCB0aGUNClVBQyBvciB0aGUgVUFTLjxicj4NCiZn dDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IDkuICZuYnNwO0NsYXJp ZmljYXRpb25zIG9uIFRhcmdldCBSZWZyZXNoDQpSZXF1ZXN0czxicj4NCiZndDsgJm5ic3A7Jmd0 OyZndDsmZ3Q7Jmd0OyB0aGUgY3VycmVudCB0ZXh0IGlzIGEgc3RyYXcgbWFuIHRoYXQgcHV0cyB0 YXJnZXQNCnJlZnJlc2hlcyBpbiB0aGU8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsg c2FtZSBjYXRlZ29yeSBhcyBhbnkgb3RoZXIgY2hhbmdlLiBUaGUgb3RoZXINCm9wdGlvbiB3ZSB0 YWxrZWQgYWJvdXQ8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsgaW4gdGhlIHBhc3Qg d2FzIHRvIHNwZWNpYWwgY2FzZSB0aGVtIHNvIHRoYXQNCnRoZXkgYXJlIHRyZWF0ZWQ8YnI+DQom Z3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsgZGlmZmVyZW50bHkuIFlvdSBzZWVtIHRvIGxpa2Ug dGhlIGxhdHRlciBvcHRpb24NCmJldHRlci4gV2hhdCBkbyB5b3U8YnI+DQomZ3Q7ICZuYnNwOyZn dDsmZ3Q7Jmd0OyZndDsgdGhpbmsgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0Pzxicj4NCiZndDsg Jm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0Ozxi cj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7c2VjdGlvbiB0aXRsZT0mcXVvdDtD bGFyaWZpY2F0aW9uIG9uIHRoZQ0KQXRvbWljaXR5IG9mIFRhcmdldCBSZWZyZXNoPGJyPg0KJmd0 OyAmbmJzcDsmZ3Q7Jmd0OyZndDsmZ3Q7IFJlcXVlc3RzJnF1b3Q7PGJyPg0KJmd0OyAmbmJzcDsm Z3Q7Jmd0OyZndDsmZ3Q7IGFuY2hvcj0mcXVvdDtzZWMtYXRvbSZxdW90OyZndDs8YnI+DQomZ3Q7 ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsgJmx0O3QmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0 OyZndDsmZ3Q7IFRoZSByZW1vdGUgdGFyZ2V0IG9mIGEgZGlhbG9nIGlzIGEgc3BlY2lhbA0KdHlw ZSBvZiBzdGF0ZSBpbmZvcm1hdGlvbjxicj4NCiZndDsgJm5ic3A7Jmd0Ozxicj4NCiZndDsgJm5i c3A7Jmd0OyZndDsmZ3Q7Jmd0OyBiZWNhdXNlIG9mIGl0cyBlc3NlbnRpYWwgcm9sZSBpbiB0aGUg ZXhjaGFuZ2UNCm9mIFNJUCBtZXNzYWdlczxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0 OyBiZXR3ZWVuIFVBcyBpbiBhIGRpYWxvZy4gQSBVQSBpbnZvbHZlZCBpbiBhDQpkaWFsb2cgcmVj ZWl2ZXMgdGhlPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlbW90ZSB0YXJnZXQg b2YgdGhlIGRpYWxvZyBmcm9tIHRoZSByZW1vdGUNClVBLiBUaGUgVUEgdXNlcyB0aGU8YnI+DQom Z3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsgcmVtb3RlIHRhcmdldCB0byBzZW5kIFNJUCByZXF1 ZXN0cyB0byB0aGUgcmVtb3RlDQpVQS48YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsg Jmx0Oy90Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7dCZndDs8YnI+ DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsgVGhlIHJlbW90ZSB0YXJnZXQgaXMgYSBwaWVj ZSBvZiBzdGF0ZSBpbmZvcm1hdGlvbg0KdGhhdCBpcyBub3QgbWVhbnQ8YnI+DQomZ3Q7ICZuYnNw OyZndDsmZ3Q7Jmd0OyZndDsgdG8gYmUgbmVnb3RpYXRlZC4gV2hlbiBhIFVBQyBjaGFuZ2VzIGl0 cyBhZGRyZXNzLA0KdGhlIFVBQyBzaW1wbHk8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZn dDsgY29tbXVuaWNhdGVzIGl0cyBuZXcgYWRkcmVzcyB0byB0aGUgVUFTIGluDQpvcmRlciB0byBy ZW1haW4gcmVhY2hhYmxlPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7 Jmd0OyZndDsmZ3Q7IGJ5IHRoZSBVQVMuIEFzIGRlc2NyaWJlZCBpbiAmbHQ7eHJlZiB0YXJnZXQ9 JnF1b3Q7c2VjLWJhY2stYXRvbSZxdW90Oy8mZ3Q7LA0KYSBVQVM8YnI+DQomZ3Q7ICZuYnNwOyZn dDsmZ3Q7Jmd0OyZndDsgc3RhcnRzIHVzaW5nIHRoZSBuZXcgcmVtb3RlIHRhcmdldCBhcyBzb29u DQphcyB0aGUgdGFyZ2V0IHJlZnJlc2g8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsg cmVxdWVzdCBpcyByZWNlaXZlZCwgcmVnYXJkbGVzcyBvZiB0aGUgcmVzcG9uc2UNCnRoZSBVQVMg Z2VuZXJhdGVzIHRvPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0 OyZndDsmZ3Q7IHRoYXQgcmVxdWVzdC4gVGhhdCBpcywgZXZlbiBpZiB0aGUgVUFTIGdlbmVyYXRl cw0KYW4gZXJyb3IgcmVzcG9uc2U8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsgdG8g dGhlIHRhcmdldCByZWZyZXNoIHJlcXVlc3QsIHRoZSBVQVMgbmVlZHMNCnRvIHVwZGF0ZSB0aGUg ZGlhbG9nJ3M8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsgcmVtb3RlIHRhcmdldCBV UkkuPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDsvdCZndDs8YnI+DQomZ3Q7 ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsgJmx0O3QmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0 OyZndDsmZ3Q7IFRoZSBmYWN0IHRoYXQgYSB0YXJnZXQgcmVmcmVzaCByZXF1ZXN0IHVwZGF0ZXMN CnRoZSByZW1vdGUgdGFyZ2V0PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlZ2Fy ZGxlc3Mgb2YgdGhlIHJlc3BvbnNlIGl0IHRyaWdnZXJzIGltcGxpZXMNCnRoYXQgdGFyZ2V0IHJl ZnJlc2g8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsgcmVxdWVzdHMgYXJlIG5vdCBh dG9taWMuIFRoYXQgaXMsIGFuIGVycm9yDQpyZXNwb25zZSB0byBhIHRhcmdldDxicj4NCiZndDsg Jm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0OyByZWZyZXNoIHJlcXVlc3Qgd2lsbCBrZWVwIGFsbCBjaGFu Z2VzIGFzc29jaWF0ZWQNCnRvIHRoZSByZXF1ZXN0IGZyb208YnI+DQomZ3Q7ICZuYnNwOyZndDs8 YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7Jmd0OyZndDsgYmVpbmcgcGVyZm9ybWVkIGV4Y2VwdCBm b3IgdGhlIHJlZnJlc2ggb2YgdGhlDQpyZW1vdGUgdGFyZ2V0LCB3aGljaDxicj4NCiZndDsgJm5i c3A7Jmd0OyZndDsmZ3Q7Jmd0OyB3aWxsIGJlIHBlcmZvcm1lZCBhbnl3YXkuPGJyPg0KJmd0OyAm bmJzcDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDsvdCZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7 Jmd0OyZndDsgJmx0Oy9zZWN0aW9uJmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsgJm5ic3A7Jmd0OyZn dDsmZ3Q7Jmd0OyBDaGVlcnMsPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0K Jmd0OyAmbmJzcDsmZ3Q7Jmd0OyZndDsmZ3Q7IEdvbnphbG88YnI+DQomZ3Q7ICZuYnNwOyZndDsm Z3Q7Jmd0OyZndDs8YnI+DQomZ3Q7ICZuYnNwOyZndDsmZ3Q7PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7 IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0KJmd0 OyAmbmJzcDsmZ3Q7IHNpcGNvcmUgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyAmbmJzcDsmZ3Q7IHNp cGNvcmVAaWV0Zi5vcmc8YnI+DQomZ3Q7ICZuYnNwOyZndDsgaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9zaXBjb3JlPGJyPg0KJmd0OyAmbmJzcDsmZ3Q7PGJyPg0KJmd0OyBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsg c2lwY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQomZ3Q7IHNpcGNvcmVAaWV0Zi5vcmc8YnI+DQomZ3Q7 IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZTxicj4NCiZndDsg PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IFpURSBJbmZvcm1hdGlv biBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcw0KbWFp bCBpcyBzb2xlbHkgcHJvcGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBt YWlsIGNvbW11bmljYXRpb24NCmlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92 ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50YWluIHNlY3JlY3kNCmFuZCBhcmUgbm90IHBlcm1pdHRl ZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvDQpvdGhl cnMuPGJyPg0KJmd0OyBUaGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBp dCBhcmUgY29uZmlkZW50aWFsIGFuZA0KaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRo ZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkgYXJlDQphZGRyZXNzZWQuIElmIHlv dSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3Jp Z2luYXRvcg0Kb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNz YWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbA0Kc2VuZGVyLjxicj4NCiZndDsgVGhpcyBt ZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGkt U3BhbQ0Kc3lzdGVtLjxicj4NCjxicj4NCjxicj4NCjwvdHQ+PC9mb250Pg0KPGJyPg0KPGJyPjxw cmU+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KWlRFJm5ic3A7SW5mb3JtYXRpb24mbmJzcDtTZWN1cml0eSZuYnNwO05vdGljZTombmJz cDtUaGUmbmJzcDtpbmZvcm1hdGlvbiZuYnNwO2NvbnRhaW5lZCZuYnNwO2luJm5ic3A7dGhpcyZu YnNwO21haWwmbmJzcDtpcyZuYnNwO3NvbGVseSZuYnNwO3Byb3BlcnR5Jm5ic3A7b2YmbmJzcDt0 aGUmbmJzcDtzZW5kZXIncyZuYnNwO29yZ2FuaXphdGlvbi4mbmJzcDtUaGlzJm5ic3A7bWFpbCZu YnNwO2NvbW11bmljYXRpb24mbmJzcDtpcyZuYnNwO2NvbmZpZGVudGlhbC4mbmJzcDtSZWNpcGll bnRzJm5ic3A7bmFtZWQmbmJzcDthYm92ZSZuYnNwO2FyZSZuYnNwO29ibGlnYXRlZCZuYnNwO3Rv Jm5ic3A7bWFpbnRhaW4mbmJzcDtzZWNyZWN5Jm5ic3A7YW5kJm5ic3A7YXJlJm5ic3A7bm90Jm5i c3A7cGVybWl0dGVkJm5ic3A7dG8mbmJzcDtkaXNjbG9zZSZuYnNwO3RoZSZuYnNwO2NvbnRlbnRz Jm5ic3A7b2YmbmJzcDt0aGlzJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO3RvJm5ic3A7b3RoZXJz Lg0KVGhpcyZuYnNwO2VtYWlsJm5ic3A7YW5kJm5ic3A7YW55Jm5ic3A7ZmlsZXMmbmJzcDt0cmFu c21pdHRlZCZuYnNwO3dpdGgmbmJzcDtpdCZuYnNwO2FyZSZuYnNwO2NvbmZpZGVudGlhbCZuYnNw O2FuZCZuYnNwO2ludGVuZGVkJm5ic3A7c29sZWx5Jm5ic3A7Zm9yJm5ic3A7dGhlJm5ic3A7dXNl Jm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtpbmRpdmlkdWFsJm5ic3A7b3ImbmJzcDtlbnRpdHkmbmJz cDt0byZuYnNwO3dob20mbmJzcDt0aGV5Jm5ic3A7YXJlJm5ic3A7YWRkcmVzc2VkLiZuYnNwO0lm Jm5ic3A7eW91Jm5ic3A7aGF2ZSZuYnNwO3JlY2VpdmVkJm5ic3A7dGhpcyZuYnNwO2VtYWlsJm5i c3A7aW4mbmJzcDtlcnJvciZuYnNwO3BsZWFzZSZuYnNwO25vdGlmeSZuYnNwO3RoZSZuYnNwO29y aWdpbmF0b3ImbmJzcDtvZiZuYnNwO3RoZSZuYnNwO21lc3NhZ2UuJm5ic3A7QW55Jm5ic3A7dmll d3MmbmJzcDtleHByZXNzZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttZXNzYWdlJm5ic3A7YXJl Jm5ic3A7dGhvc2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtzZW5kZXIu DQpUaGlzJm5ic3A7bWVzc2FnZSZuYnNwO2hhcyZuYnNwO2JlZW4mbmJzcDtzY2FubmVkJm5ic3A7 Zm9yJm5ic3A7dmlydXNlcyZuYnNwO2FuZCZuYnNwO1NwYW0mbmJzcDtieSZuYnNwO1pURSZuYnNw O0FudGktU3BhbSZuYnNwO3N5c3RlbS4NCjwvcHJlPg== --=_alternative 003F935E482575FF_=-- From root@core3.amsl.com Mon Jul 27 00:45:01 2009 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id C254B28C1D6; Mon, 27 Jul 2009 00:45:01 -0700 (PDT) From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Content-Type: Multipart/Mixed; Boundary="NextPart" Mime-Version: 1.0 Message-Id: <20090727074501.C254B28C1D6@core3.amsl.com> Date: Mon, 27 Jul 2009 00:45:01 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-rfc3265bis-00.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, 27 Jul 2009 07:45:01 -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 : SIP-Specific Event Notification Author(s) : A. Roach Filename : draft-ietf-sipcore-rfc3265bis-00.txt Pages : 50 Date : 2009-07-27 This document describes an extension to the Session Initiation Protocol (SIP). The purpose of this extension is to provide an extensible framework by which SIP nodes can request notification from remote nodes indicating that certain events have occurred. Note that the event notification mechanisms defined herein are NOT intended to be a general-purpose infrastructure for all classes of event subscription and notification. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-rfc3265bis-00.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-rfc3265bis-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2009-07-27004035.I-D@ietf.org> --NextPart-- From gonzalo.camarillo@ericsson.com Mon Jul 27 05:12:07 2009 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 76F1928C17E for ; Mon, 27 Jul 2009 05:12:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.234 X-Spam-Level: X-Spam-Status: No, score=-5.234 tagged_above=-999 required=5 tests=[AWL=1.015, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 N0tFsnBe-S1s for ; Mon, 27 Jul 2009 05:12:06 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 4752528C150 for ; Mon, 27 Jul 2009 05:12:06 -0700 (PDT) X-AuditID: c1b4fb3e-b7bf5ae000000202-80-4a6d996a8b01 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id E1.2A.00514.A699D6A4; Mon, 27 Jul 2009 14:11:22 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 14:11:10 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 14:11:09 +0200 Received: from [131.160.126.137] (rvi2-126-137.lmf.ericsson.se [131.160.126.137]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 77BC9245F for ; Mon, 27 Jul 2009 15:11:09 +0300 (EEST) Message-ID: <4A6D995D.7040609@ericsson.com> Date: Mon, 27 Jul 2009 14:11:09 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: SIPCORE References: <4A3227D2.4020808@ericsson.com> <4A40853F.8010102@ericsson.com> In-Reply-To: <4A40853F.8010102@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2009 12:11:09.0752 (UTC) FILETIME=[53926B80:01CA0EB3] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] Milestone to revise RFC 3265: Conclusion 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, 27 Jul 2009 12:12:07 -0000 Folks, the WG item version of this draft has just been submitted. I would like to see discussions about the scope of this effort, per my previous email below. http://www.ietf.org/id/draft-ietf-sipcore-rfc3265bis-00.txt Thanks, Gonzalo SIPCORE co-chair Gonzalo Camarillo wrote: > Hi, > > based on all the responses received, there is agreement that the WG > should work on revising RFC 3265 and that this draft is a good starting > point for that. Therefore, I will ask our ADs to add a milestone to > revise RFC 3265 and the author of the draft to submit it as a SIPCORE WG > item. > > Keith brought up two good questions about the scope of this effort that > we need to resolve (while he agrees on a limited-scope update that would > preserve backwards compatibility, he would object to a wider scope). The > first discussions on this topic need to deal with those questions in > order to reach an agreement on the actual scope of this effort. > > Thanks, > > Gonzalo > SIPCORE cochair > > > Gonzalo Camarillo wrote: >> Folks, >> >> since the publication of RFC 3265, we have gotten significant >> experience deploying SIP-based notification systems. It has been >> proposed to revise RFC 3265 based on that experience. We have two >> questions for the WG: >> >> 1) should we add a milestone to our charter to revise RFC 3265? >> >> 2) if we add such a milestone, should we take the following draft as >> the initial WG item for the milestone? >> >> http://tools.ietf.org/html/draft-roach-sipcore-rfc3265bis-00 >> >> Thanks, >> >> Gonzalo >> SIPCORE co-chair >> _______________________________________________ >> 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 Mon Jul 27 05:50:00 2009 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 09AA53A6C5E for ; Mon, 27 Jul 2009 05:50:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.263 X-Spam-Level: X-Spam-Status: No, score=-5.263 tagged_above=-999 required=5 tests=[AWL=0.986, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 sKdG-9OtwtNJ for ; Mon, 27 Jul 2009 05:49:58 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id E174C3A69E8 for ; Mon, 27 Jul 2009 05:49:57 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9dae00000519d-77-4a6da2751e2a Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id E7.5C.20893.572AD6A4; Mon, 27 Jul 2009 14:49:57 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 14:49:57 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 14:49:57 +0200 Received: from [131.160.126.137] (rvi2-126-137.lmf.ericsson.se [131.160.126.137]) by mail.lmf.ericsson.se (Postfix) with ESMTP id F1F5F245F; Mon, 27 Jul 2009 15:49:51 +0300 (EEST) Message-ID: <4A6DA26F.7060205@ericsson.com> Date: Mon, 27 Jul 2009 14:49:51 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Paul Kyzivat References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com> <4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com> <4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> In-Reply-To: <4A689184.5050903@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2009 12:49:57.0253 (UTC) FILETIME=[BEDEE350:01CA0EB8] X-Brightmail-Tracker: AAAAAA== Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 27 Jul 2009 12:50:00 -0000 Hi, it seems we can cover most cases with the following rules: 1) a reliable provisional response or a 2xx response to a target refresh confirms that the UAS has refreshed the target. This refresh is not rolled back under any circumstance (i.e., even if the target refresh was a re-INVITE that eventually failed or the target refresh was an UPDATE within a re-INVITE that eventually failed). 2) if the target refresh is rejected without any previous reliable provisional response, the target is not refreshed (this allows UASs to authenticate target refresh requests). 3) a reliable provisional response or a 2xx response to a target refresh request can refresh the target. Such a refresh is never rolled back either. (The UAS for the re-INVITE could of course also choose to send an UPDATE instead of refreshing the target in a response to the re-INVITE.) We would also recommend UACs not to piggyback a target refresh with session changes in re-INVITEs that do not use 100rel because this would make it unnecessarily complicated for the UAS to accept the target refresh but to reject the session changes. With respect to a UAC for a re-INVITE losing its IP address, the right thing to do would be to send an UPDATE to refresh the target, cancel the re-INVITE because the UAC would not be able to receive responses for it any longer, and initiate a new re-INVITE or UPDATE in order to get the media session in sync again. Cheers, Gonzalo Paul Kyzivat wrote: > I'm don't know if we are on quite the same page yet. > Once accepted, I don't think a target refresh should be rolled back by > anything. > > A key use case might be: > > I've started an reINVITE - one that might take awhile because it is > trying to add media and the other end is alerting about that. > > While that is in progress I lose my IP address and need to target > refresh. So what do I do? > > I think I send an UPDATE, which will be in the midst of the reINVITE > transaction. I make it a simple one, in that it includes no o/a, its > *just* a target refresh. Of course the Via for it has the new ip > address. It *might* be rejected with 401. If so I may have to try again, > but at least I have a chance of getting the response and trying again. > > Now the reINVITE itself is going to fail, because the responses will be > going to a non-functional address based on the Via for the reINVITE. > What we *don't* want is for the failure of the reINVITE to roll back the > target refresh. The UAC can try sending a CANCEL following the UPDATE. > It can have the new address as its Via. But still the resulting 487 for > the reINVITE will go to the wrong address. Eventually the UAC can send > another reINVITE with the new target. Or the UAS can send a new reINVITE > to the new target address. > > Thanks, > Paul > > Gonzalo Camarillo wrote: >> Hi Paul, >> >> > This will encourage using a *simple* request to do an essential target >> > refresh, rather than a complex one that has a chance of failing. >> >> Yes, I agree with you. I think we can get what you are looking for by >> keeping the text that is currently in the draft (i.e., re-INVITEs >> remain atomic and an error response rolls everything back, including >> the target refresh), by adding a description of why piggybacking other >> changes in a target refresh request is a bad idea (the new text would >> include a discussion on the Via problem and on legacy UASs responding >> with an error response even if changes have been executed), and by >> discouraging the use of re-INVITEs that update the target and perform >> other changes at the same time (we probably need to go as far as to >> say that one SHOULD NOT do it). >> >> I agree with you that encouraging the use of "simple" requests will be >> better than specifying complex behavior just to cover corner cases. >> >> Thanks, >> >> Gonzalo >> >> >> >> Paul Kyzivat wrote: >>> Gonzalo, >>> >>> I agree with all you say below, except at the very end about target >>> refresh. >>> >>> If target refreshes are to be accepted even if the request fails, >>> then it is possible to hijack a session even if authentication is >>> being used for signaling. >>> >>> IMO a target refresh must be ignored in at least *some* cases when >>> the request is rejected. We could enumerate these cases individually, >>> or simply state that it will only be accepted if the request is >>> accepted. (In case of reINVITE, that would be if it was accepted >>> sufficiently to return a 2xx or a 1xx.) >>> >>> This will encourage using a *simple* request to do an essential >>> target refresh, rather than a complex one that has a chance of >>> failing. Perhaps it won't work in all cases, but such is life. >>> >>> Thanks, >>> Paul >>> >>> Gonzalo Camarillo wrote: >>>> Hi Paul, >>>> >>>> thanks for your comments. Answers inline: >>>> >>>> Paul Kyzivat wrote: >>>>> Gonzalo, >>>>> >>>>> Thanks for doing this work! I do have some comments: >>>>> >>>>> Section 3/Figure 1 >>>>> >>>>> The figure shows a 6xx response. >>>>> The text says that the UAS wants to reject the new offer. >>>>> >>>>> A UAS would probably not use a 6xx response to reject media. >>>>> (I guess it might use 606, but 488 would be more appropriate.) >>>>> In fact, it probably would not reject the request at all, but >>>>> rather would just refuse the added media stream. >>>>> >>>>> The point being made doesn't require that the response be 6xx or >>>>> that it be with the purpose of refusing the media. So I think what >>>>> is needed here is to find a plausible example to make the point. >>>>> >>>>> A good one for the purpose here might be a 488 to reject the media, >>>>> or a 401 response as another sort of reason for rejecting the >>>>> whole thing but wanting to preserve what there is. >>>> >>>> yes, I agree that a 488 response would be more appropriate. I will >>>> change that in the draft. >>>> >>>>> >>>>> Section 5: >>>>> >>>>>> A change to the session state is considered to have been executed >>>>>> when the new media parameters are being used. Therefore, a >>>>>> change to >>>>>> a stream subject to preconditions [RFC4032] is considered to have >>>>>> been executed when the new media parameters start being used; not >>>>>> when the preconditions for the stream are met. Unsurprisingly, >>>>>> the >>>>>> UAS considers the new parameters to be in use when it actually >>>>>> starts >>>>>> using them. >>>>> >>>>> I'm not entirely following this. I think there may be an assumption >>>>> here that the UAC is the offerer and the UAS the answerer. I'm >>>>> guessing you are saying that the answerer considers the new >>>>> parameters to be in use when it actually starts using them. >>>>> >>>>> Since this section is about the UAS (for the reinvite), this point >>>>> is probably that when the UAS is also the answerer it can decide >>>>> when the new media is in use based on when it starts using them. >>>>> >>>>> But what happens when the UAS is the offerer? In that case I think >>>>> it must assume the media is in use as soon as it is offered. But >>>>> maybe that isn't always the case with preconditions. I don't think >>>>> it can wait till it receives media, because media may be in flight >>>>> when it makes its decision. >>>> >>>> yes, the draft assumes that the UAS is the answerer because that was >>>> the use case being discussed originally. However, you are right that >>>> we should also cover the case where the UAS is the offerer. I will >>>> look into it and add text about it in the draft. >>>> >>>>> >>>>>> As described in Section 8.3.1 of RFC 3264 [RFC3264], the >>>>>> UAC considers the new parameters to be in use when media is >>>>>> received >>>>>> in the new port, which should be interpreted as follows: >>>>>> >>>>>> Received, in this case, means that the media is passed to a >>>>>> media >>>>>> sink. This means that if there is a playout buffer, the agent >>>>>> would continue to listen on the old port until the media on the >>>>>> new port reached the top of the playout buffer. At that >>>>>> time, it >>>>>> MAY cease listening for media on the old port. >>>>> >>>>> I don't know what the above has to do with the behavior of the UAS. >>>> >>>> The UAC needs to know when the new parameters are in use in order to >>>> implement the normative behavior in Section 6: >>>> >>>> ... a UAC that receives an error response to a re-INVITE for which >>>> changes have been already executed ... >>>> >>>> In any case, I will clarify all this when I write the text about the >>>> UAS being the offerer because this type of behavior has to do with >>>> being the offerer or the answerer, not the UAC or the UAS. >>>> >>>> >>>>>> 9. Clarifications on Target Refresh Requests >>>> >>>> the current text is a straw man that puts target refreshes in the >>>> same category as any other change. The other option we talked about >>>> in the past was to special case them so that they are treated >>>> differently. You seem to like the latter option better. What do you >>>> think about the following text? >>>> >>>> >>>>
>>> anchor="sec-atom"> >>>> >>>> The remote target of a dialog is a special type of state information >>>> because of its essential role in the exchange of SIP messages between >>>> UAs in a dialog. A UA involved in a dialog receives the remote target >>>> of the dialog from the remote UA. The UA uses the remote target to >>>> send SIP requests to the remote UA. >>>> >>>> >>>> The remote target is a piece of state information that is not meant to >>>> be negotiated. When a UAC changes its address, the UAC simply >>>> communicates its new address to the UAS in order to remain reachable >>>> by the UAS. As described in , a UAS >>>> starts using the new remote target as soon as the target refresh >>>> request is received, regardless of the response the UAS generates to >>>> that request. That is, even if the UAS generates an error response to >>>> the target refresh request, the UAS needs to update the dialog's >>>> remote target URI. >>>> >>>> >>>> The fact that a target refresh request updates the remote target >>>> regardless of the response it triggers implies that target refresh >>>> requests are not atomic. That is, an error response to a target >>>> refresh request will keep all changes associated to the request from >>>> being performed except for the refresh of the remote target, which >>>> will be performed anyway. >>>> >>>>
>>>> >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >> >> From pkyzivat@cisco.com Mon Jul 27 06:39:08 2009 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 839B028C1A1 for ; Mon, 27 Jul 2009 06:39:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.424 X-Spam-Level: X-Spam-Status: No, score=-6.424 tagged_above=-999 required=5 tests=[AWL=0.175, 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 A43OSAXJdhBY for ; Mon, 27 Jul 2009 06:39:06 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id EDC4628C25C for ; Mon, 27 Jul 2009 06:39:02 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANJKbUpAZnmf/2dsb2JhbAC6BIgojX0FhA0 X-IronPort-AV: E=Sophos;i="4.43,276,1246838400"; d="scan'208";a="219535484" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 27 Jul 2009 13:39:03 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6RDd3ui014927; Mon, 27 Jul 2009 09:39:03 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6RDd3qS001740; Mon, 27 Jul 2009 13:39:03 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 09:39:03 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 09:39:02 -0400 Message-ID: <4A6DADF6.7000106@cisco.com> Date: Mon, 27 Jul 2009 09:39:02 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com> <4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com> <4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> <4A6DA26F.7060205@ericsson.com> In-Reply-To: <4A6DA26F.7060205@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 27 Jul 2009 13:39:03.0030 (UTC) FILETIME=[9AB0C960:01CA0EBF] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=11493; t=1248701943; x=1249565943; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20New=20revision=20of=20the=2 0re-INVITE=20handling=20draft |Sender:=20 |To:=20Gonzalo=20Camarillo=20; bh=oqe9Md47n+qAG2iqma+e6MPGXdWBagBMJjlOVEB3XJM=; b=tSPbLj95qcR5XkxIKhH32Un/EU7hCgJF+YJ3aHPDKh6gjDVrvbiqxSSpQF MwMRSctDzxN9Er4XRsKyiAQtXzJ4p1/QGMaF+YnlYOa8180etP/tkCdJVMFK PRZM0mtq87; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 27 Jul 2009 13:39:08 -0000 Gonzalo Camarillo wrote: > Hi, > > it seems we can cover most cases with the following rules: > > 1) a reliable provisional response or a 2xx response to a target refresh > confirms that the UAS has refreshed the target. This refresh is not > rolled back under any circumstance (i.e., even if the target refresh was > a re-INVITE that eventually failed or the target refresh was an UPDATE > within a re-INVITE that eventually failed). > > 2) if the target refresh is rejected without any previous reliable > provisional response, the target is not refreshed (this allows UASs to > authenticate target refresh requests). > > 3) a reliable provisional response or a 2xx response to a target refresh > request can refresh the target. Such a refresh is never rolled back > either. (The UAS for the re-INVITE could of course also choose to send > an UPDATE instead of refreshing the target in a response to the re-INVITE.) > > We would also recommend UACs not to piggyback a target refresh with > session changes in re-INVITEs that do not use 100rel because this would > make it unnecessarily complicated for the UAS to accept the target > refresh but to reject the session changes. > > With respect to a UAC for a re-INVITE losing its IP address, the right > thing to do would be to send an UPDATE to refresh the target, cancel the > re-INVITE because the UAC would not be able to receive responses for it > any longer, and initiate a new re-INVITE or UPDATE in order to get the > media session in sync again. I'm fine with all of the above - its clear and precise. In the last paragraph, the order of events is important. Thanks, Paul > Cheers, > > Gonzalo > > > Paul Kyzivat wrote: >> I'm don't know if we are on quite the same page yet. >> Once accepted, I don't think a target refresh should be rolled back by >> anything. >> >> A key use case might be: >> >> I've started an reINVITE - one that might take awhile because it is >> trying to add media and the other end is alerting about that. >> >> While that is in progress I lose my IP address and need to target >> refresh. So what do I do? >> >> I think I send an UPDATE, which will be in the midst of the reINVITE >> transaction. I make it a simple one, in that it includes no o/a, its >> *just* a target refresh. Of course the Via for it has the new ip >> address. It *might* be rejected with 401. If so I may have to try >> again, but at least I have a chance of getting the response and trying >> again. >> >> Now the reINVITE itself is going to fail, because the responses will >> be going to a non-functional address based on the Via for the >> reINVITE. What we *don't* want is for the failure of the reINVITE to >> roll back the target refresh. The UAC can try sending a CANCEL >> following the UPDATE. It can have the new address as its Via. But >> still the resulting 487 for the reINVITE will go to the wrong address. >> Eventually the UAC can send another reINVITE with the new target. Or >> the UAS can send a new reINVITE to the new target address. >> >> Thanks, >> Paul >> >> Gonzalo Camarillo wrote: >>> Hi Paul, >>> >>> > This will encourage using a *simple* request to do an essential >>> target >>> > refresh, rather than a complex one that has a chance of failing. >>> >>> Yes, I agree with you. I think we can get what you are looking for by >>> keeping the text that is currently in the draft (i.e., re-INVITEs >>> remain atomic and an error response rolls everything back, including >>> the target refresh), by adding a description of why piggybacking >>> other changes in a target refresh request is a bad idea (the new text >>> would include a discussion on the Via problem and on legacy UASs >>> responding with an error response even if changes have been >>> executed), and by discouraging the use of re-INVITEs that update the >>> target and perform other changes at the same time (we probably need >>> to go as far as to say that one SHOULD NOT do it). >>> >>> I agree with you that encouraging the use of "simple" requests will >>> be better than specifying complex behavior just to cover corner cases. >>> >>> Thanks, >>> >>> Gonzalo >>> >>> >>> >>> Paul Kyzivat wrote: >>>> Gonzalo, >>>> >>>> I agree with all you say below, except at the very end about target >>>> refresh. >>>> >>>> If target refreshes are to be accepted even if the request fails, >>>> then it is possible to hijack a session even if authentication is >>>> being used for signaling. >>>> >>>> IMO a target refresh must be ignored in at least *some* cases when >>>> the request is rejected. We could enumerate these cases >>>> individually, or simply state that it will only be accepted if the >>>> request is accepted. (In case of reINVITE, that would be if it was >>>> accepted sufficiently to return a 2xx or a 1xx.) >>>> >>>> This will encourage using a *simple* request to do an essential >>>> target refresh, rather than a complex one that has a chance of >>>> failing. Perhaps it won't work in all cases, but such is life. >>>> >>>> Thanks, >>>> Paul >>>> >>>> Gonzalo Camarillo wrote: >>>>> Hi Paul, >>>>> >>>>> thanks for your comments. Answers inline: >>>>> >>>>> Paul Kyzivat wrote: >>>>>> Gonzalo, >>>>>> >>>>>> Thanks for doing this work! I do have some comments: >>>>>> >>>>>> Section 3/Figure 1 >>>>>> >>>>>> The figure shows a 6xx response. >>>>>> The text says that the UAS wants to reject the new offer. >>>>>> >>>>>> A UAS would probably not use a 6xx response to reject media. >>>>>> (I guess it might use 606, but 488 would be more appropriate.) >>>>>> In fact, it probably would not reject the request at all, but >>>>>> rather would just refuse the added media stream. >>>>>> >>>>>> The point being made doesn't require that the response be 6xx or >>>>>> that it be with the purpose of refusing the media. So I think what >>>>>> is needed here is to find a plausible example to make the point. >>>>>> >>>>>> A good one for the purpose here might be a 488 to reject the >>>>>> media, or a 401 response as another sort of reason for rejecting >>>>>> the whole thing but wanting to preserve what there is. >>>>> >>>>> yes, I agree that a 488 response would be more appropriate. I will >>>>> change that in the draft. >>>>> >>>>>> >>>>>> Section 5: >>>>>> >>>>>>> A change to the session state is considered to have been executed >>>>>>> when the new media parameters are being used. Therefore, a >>>>>>> change to >>>>>>> a stream subject to preconditions [RFC4032] is considered to have >>>>>>> been executed when the new media parameters start being used; not >>>>>>> when the preconditions for the stream are met. >>>>>>> Unsurprisingly, the >>>>>>> UAS considers the new parameters to be in use when it actually >>>>>>> starts >>>>>>> using them. >>>>>> >>>>>> I'm not entirely following this. I think there may be an >>>>>> assumption here that the UAC is the offerer and the UAS the >>>>>> answerer. I'm guessing you are saying that the answerer considers >>>>>> the new parameters to be in use when it actually starts using them. >>>>>> >>>>>> Since this section is about the UAS (for the reinvite), this point >>>>>> is probably that when the UAS is also the answerer it can decide >>>>>> when the new media is in use based on when it starts using them. >>>>>> >>>>>> But what happens when the UAS is the offerer? In that case I think >>>>>> it must assume the media is in use as soon as it is offered. But >>>>>> maybe that isn't always the case with preconditions. I don't think >>>>>> it can wait till it receives media, because media may be in flight >>>>>> when it makes its decision. >>>>> >>>>> yes, the draft assumes that the UAS is the answerer because that >>>>> was the use case being discussed originally. However, you are right >>>>> that we should also cover the case where the UAS is the offerer. I >>>>> will look into it and add text about it in the draft. >>>>> >>>>>> >>>>>>> As described in Section 8.3.1 of RFC 3264 [RFC3264], the >>>>>>> UAC considers the new parameters to be in use when media is >>>>>>> received >>>>>>> in the new port, which should be interpreted as follows: >>>>>>> >>>>>>> Received, in this case, means that the media is passed to a >>>>>>> media >>>>>>> sink. This means that if there is a playout buffer, the agent >>>>>>> would continue to listen on the old port until the media on >>>>>>> the >>>>>>> new port reached the top of the playout buffer. At that >>>>>>> time, it >>>>>>> MAY cease listening for media on the old port. >>>>>> >>>>>> I don't know what the above has to do with the behavior of the UAS. >>>>> >>>>> The UAC needs to know when the new parameters are in use in order >>>>> to implement the normative behavior in Section 6: >>>>> >>>>> ... a UAC that receives an error response to a re-INVITE for which >>>>> changes have been already executed ... >>>>> >>>>> In any case, I will clarify all this when I write the text about >>>>> the UAS being the offerer because this type of behavior has to do >>>>> with being the offerer or the answerer, not the UAC or the UAS. >>>>> >>>>> >>>>>>> 9. Clarifications on Target Refresh Requests >>>>> >>>>> the current text is a straw man that puts target refreshes in the >>>>> same category as any other change. The other option we talked about >>>>> in the past was to special case them so that they are treated >>>>> differently. You seem to like the latter option better. What do you >>>>> think about the following text? >>>>> >>>>> >>>>>
>>>> anchor="sec-atom"> >>>>> >>>>> The remote target of a dialog is a special type of state information >>>>> because of its essential role in the exchange of SIP messages between >>>>> UAs in a dialog. A UA involved in a dialog receives the remote target >>>>> of the dialog from the remote UA. The UA uses the remote target to >>>>> send SIP requests to the remote UA. >>>>> >>>>> >>>>> The remote target is a piece of state information that is not meant to >>>>> be negotiated. When a UAC changes its address, the UAC simply >>>>> communicates its new address to the UAS in order to remain reachable >>>>> by the UAS. As described in , a UAS >>>>> starts using the new remote target as soon as the target refresh >>>>> request is received, regardless of the response the UAS generates to >>>>> that request. That is, even if the UAS generates an error response to >>>>> the target refresh request, the UAS needs to update the dialog's >>>>> remote target URI. >>>>> >>>>> >>>>> The fact that a target refresh request updates the remote target >>>>> regardless of the response it triggers implies that target refresh >>>>> requests are not atomic. That is, an error response to a target >>>>> refresh request will keep all changes associated to the request from >>>>> being performed except for the refresh of the remote target, which >>>>> will be performed anyway. >>>>> >>>>>
>>>>> >>>>> >>>>> Cheers, >>>>> >>>>> Gonzalo >>>>> >>> >>> > > From christer.holmberg@ericsson.com Mon Jul 27 07:02:38 2009 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 15F0228C1B5 for ; Mon, 27 Jul 2009 07:02:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.668 X-Spam-Level: X-Spam-Status: No, score=-3.668 tagged_above=-999 required=5 tests=[AWL=-1.419, BAYES_00=-2.599, HELO_EQ_SE=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 inpY+qCE6GTc for ; Mon, 27 Jul 2009 07:02:36 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 11EAE28C1AF for ; Mon, 27 Jul 2009 07:02:35 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-f2-4a6db37bb4e1 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 05.28.18827.B73BD6A4; Mon, 27 Jul 2009 16:02:35 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 27 Jul 2009 16:01:36 +0200 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: Mon, 27 Jul 2009 16:01:34 +0200 Message-ID: In-Reply-To: <4A6DA26F.7060205@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] New revision of the re-INVITE handling draft Thread-Index: AcoOuMO36qoO+E/2T0eltXHLXyFY4QACBWzQ References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com><4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com><4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> <4A6DA26F.7060205@ericsson.com> From: "Christer Holmberg" To: "Gonzalo Camarillo" , "Paul Kyzivat" X-OriginalArrivalTime: 27 Jul 2009 14:01:36.0140 (UTC) FILETIME=[C134FCC0:01CA0EC2] X-Brightmail-Tracker: AAAAAA== Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 27 Jul 2009 14:02:38 -0000 Hi,=20 >it seems we can cover most cases with the following rules: > >1) a reliable provisional response or a 2xx response to a target refresh confirms that the UAS has refreshed the target.=20 >This refresh is not rolled back under any circumstance (i.e., even if the target refresh was a re-INVITE that eventually=20 >failed or the target refresh was an UPDATE within a re-INVITE that eventually failed). > >2) if the target refresh is rejected without any previous reliable provisional response, the target is not refreshed=20 >(this allows UASs to authenticate target refresh requests). > >3) a reliable provisional response or a 2xx response to a target refresh request can refresh the target. Such a refresh=20 >is never rolled back either. (The UAS for the re-INVITE could of course also choose to send an UPDATE instead of=20 >refreshing the target in a response to the re-INVITE.) > >We would also recommend UACs not to piggyback a target refresh with session changes in re-INVITEs that do not use 100rel=20 >because this would make it unnecessarily complicated for the UAS to accept the target refresh but to reject the session=20 >changes. In general I am ok with the rules, but we may need to think a little about UNreliable provisional responses.=20 For example, if a UAC sends an (re-)INVITE, and receives an UNreliable 18x, isn't there then an early dialog created in the UAC-to-UAS direction, and the UAC can start sending in-dialog messages towards the UAS at that point? So, the question is: does an unreliable response update the remote target, or where will the UAC send those in-dialog messages? >With respect to a UAC for a re-INVITE losing its IP address, the right thing to do would be to send an UPDATE to refresh >the target, cancel the re-INVITE because the UAC would not be able to receive responses for it any longer, and initiate a=20 >new re-INVITE or UPDATE in order to get the media session in sync again. I think we need to say something about that there may be cases where a re-registration is also needed. Regards, Christer Paul Kyzivat wrote: > I'm don't know if we are on quite the same page yet. > Once accepted, I don't think a target refresh should be rolled back by > anything. >=20 > A key use case might be: >=20 > I've started an reINVITE - one that might take awhile because it is=20 > trying to add media and the other end is alerting about that. >=20 > While that is in progress I lose my IP address and need to target=20 > refresh. So what do I do? >=20 > I think I send an UPDATE, which will be in the midst of the reINVITE=20 > transaction. I make it a simple one, in that it includes no o/a, its > *just* a target refresh. Of course the Via for it has the new ip=20 > address. It *might* be rejected with 401. If so I may have to try=20 > again, but at least I have a chance of getting the response and trying again. >=20 > Now the reINVITE itself is going to fail, because the responses will=20 > be going to a non-functional address based on the Via for the reINVITE. > What we *don't* want is for the failure of the reINVITE to roll back=20 > the target refresh. The UAC can try sending a CANCEL following the UPDATE. > It can have the new address as its Via. But still the resulting 487=20 > for the reINVITE will go to the wrong address. Eventually the UAC can=20 > send another reINVITE with the new target. Or the UAS can send a new=20 > reINVITE to the new target address. >=20 > Thanks, > Paul >=20 > Gonzalo Camarillo wrote: >> Hi Paul, >> >> > This will encourage using a *simple* request to do an essential=20 >> target > refresh, rather than a complex one that has a chance of failing. >> >> Yes, I agree with you. I think we can get what you are looking for by >> keeping the text that is currently in the draft (i.e., re-INVITEs=20 >> remain atomic and an error response rolls everything back, including=20 >> the target refresh), by adding a description of why piggybacking=20 >> other changes in a target refresh request is a bad idea (the new text >> would include a discussion on the Via problem and on legacy UASs=20 >> responding with an error response even if changes have been=20 >> executed), and by discouraging the use of re-INVITEs that update the=20 >> target and perform other changes at the same time (we probably need=20 >> to go as far as to say that one SHOULD NOT do it). >> >> I agree with you that encouraging the use of "simple" requests will=20 >> be better than specifying complex behavior just to cover corner cases. >> >> Thanks, >> >> Gonzalo >> >> >> >> Paul Kyzivat wrote: >>> Gonzalo, >>> >>> I agree with all you say below, except at the very end about target=20 >>> refresh. >>> >>> If target refreshes are to be accepted even if the request fails,=20 >>> then it is possible to hijack a session even if authentication is=20 >>> being used for signaling. >>> >>> IMO a target refresh must be ignored in at least *some* cases when=20 >>> the request is rejected. We could enumerate these cases=20 >>> individually, or simply state that it will only be accepted if the=20 >>> request is accepted. (In case of reINVITE, that would be if it was=20 >>> accepted sufficiently to return a 2xx or a 1xx.) >>> >>> This will encourage using a *simple* request to do an essential=20 >>> target refresh, rather than a complex one that has a chance of=20 >>> failing. Perhaps it won't work in all cases, but such is life. >>> >>> Thanks, >>> Paul >>> >>> Gonzalo Camarillo wrote: >>>> Hi Paul, >>>> >>>> thanks for your comments. Answers inline: >>>> >>>> Paul Kyzivat wrote: >>>>> Gonzalo, >>>>> >>>>> Thanks for doing this work! I do have some comments: >>>>> >>>>> Section 3/Figure 1 >>>>> >>>>> The figure shows a 6xx response. >>>>> The text says that the UAS wants to reject the new offer. >>>>> >>>>> A UAS would probably not use a 6xx response to reject media. >>>>> (I guess it might use 606, but 488 would be more appropriate.) In=20 >>>>> fact, it probably would not reject the request at all, but rather=20 >>>>> would just refuse the added media stream. >>>>> >>>>> The point being made doesn't require that the response be 6xx or=20 >>>>> that it be with the purpose of refusing the media. So I think what >>>>> is needed here is to find a plausible example to make the point. >>>>> >>>>> A good one for the purpose here might be a 488 to reject the=20 >>>>> media, or a 401 response as another sort of reason for rejecting=20 >>>>> the whole thing but wanting to preserve what there is. >>>> >>>> yes, I agree that a 488 response would be more appropriate. I will=20 >>>> change that in the draft. >>>> >>>>> >>>>> Section 5: >>>>> >>>>>> A change to the session state is considered to have been executed >>>>>> when the new media parameters are being used. Therefore, a=20 >>>>>> change to >>>>>> a stream subject to preconditions [RFC4032] is considered to have >>>>>> been executed when the new media parameters start being used; not >>>>>> when the preconditions for the stream are met. =20 >>>>>> Unsurprisingly, the >>>>>> UAS considers the new parameters to be in use when it actually >>>>>> starts >>>>>> using them.=20 >>>>> >>>>> I'm not entirely following this. I think there may be an=20 >>>>> assumption here that the UAC is the offerer and the UAS the=20 >>>>> answerer. I'm guessing you are saying that the answerer considers=20 >>>>> the new parameters to be in use when it actually starts using them. >>>>> >>>>> Since this section is about the UAS (for the reinvite), this point >>>>> is probably that when the UAS is also the answerer it can decide=20 >>>>> when the new media is in use based on when it starts using them. >>>>> >>>>> But what happens when the UAS is the offerer? In that case I think >>>>> it must assume the media is in use as soon as it is offered. But=20 >>>>> maybe that isn't always the case with preconditions. I don't think >>>>> it can wait till it receives media, because media may be in flight >>>>> when it makes its decision. >>>> >>>> yes, the draft assumes that the UAS is the answerer because that=20 >>>> was the use case being discussed originally. However, you are right >>>> that we should also cover the case where the UAS is the offerer. I=20 >>>> will look into it and add text about it in the draft. >>>> >>>>> >>>>>> As described in Section 8.3.1 of RFC 3264 [RFC3264], the >>>>>> UAC considers the new parameters to be in use when media is=20 >>>>>> received >>>>>> in the new port, which should be interpreted as follows: >>>>>> >>>>>> Received, in this case, means that the media is passed to a >>>>>> media >>>>>> sink. This means that if there is a playout buffer, the agent >>>>>> would continue to listen on the old port until the media on the >>>>>> new port reached the top of the playout buffer. At that=20 >>>>>> time, it >>>>>> MAY cease listening for media on the old port. >>>>> >>>>> I don't know what the above has to do with the behavior of the UAS. >>>> >>>> The UAC needs to know when the new parameters are in use in order=20 >>>> to implement the normative behavior in Section 6: >>>> >>>> ... a UAC that receives an error response to a re-INVITE for which >>>> changes have been already executed ... >>>> >>>> In any case, I will clarify all this when I write the text about=20 >>>> the UAS being the offerer because this type of behavior has to do=20 >>>> with being the offerer or the answerer, not the UAC or the UAS. >>>> >>>> >>>>>> 9. Clarifications on Target Refresh Requests >>>> >>>> the current text is a straw man that puts target refreshes in the=20 >>>> same category as any other change. The other option we talked about >>>> in the past was to special case them so that they are treated=20 >>>> differently. You seem to like the latter option better. What do you >>>> think about the following text? >>>> >>>> >>>>
>>> Requests" >>>> anchor=3D"sec-atom"> >>>> >>>> The remote target of a dialog is a special type of state=20 >>>> information because of its essential role in the exchange of SIP=20 >>>> messages between UAs in a dialog. A UA involved in a dialog=20 >>>> receives the remote target of the dialog from the remote UA. The UA >>>> uses the remote target to send SIP requests to the remote UA. >>>> >>>> >>>> The remote target is a piece of state information that is not meant >>>> to be negotiated. When a UAC changes its address, the UAC simply=20 >>>> communicates its new address to the UAS in order to remain=20 >>>> reachable by the UAS. As described in >>> target=3D"sec-back-atom"/>, a UAS starts using the new remote = target=20 >>>> as soon as the target refresh request is received, regardless of=20 >>>> the response the UAS generates to that request. That is, even if=20 >>>> the UAS generates an error response to the target refresh request,=20 >>>> the UAS needs to update the dialog's remote target URI. >>>> >>>> >>>> The fact that a target refresh request updates the remote target=20 >>>> regardless of the response it triggers implies that target refresh=20 >>>> requests are not atomic. That is, an error response to a target=20 >>>> refresh request will keep all changes associated to the request=20 >>>> from being performed except for the refresh of the remote target,=20 >>>> which will be performed anyway. >>>> >>>>
>>>> >>>> >>>> Cheers, >>>> >>>> Gonzalo >>>> >> >> _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From drage@alcatel-lucent.com Mon Jul 27 07:09:44 2009 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 474DC3A6ADE for ; Mon, 27 Jul 2009 07:09:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.458 X-Spam-Level: X-Spam-Status: No, score=-5.458 tagged_above=-999 required=5 tests=[AWL=0.791, BAYES_00=-2.599, HELO_EQ_FR=0.35, 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 M-G322XjCQS7 for ; Mon, 27 Jul 2009 07:09:43 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [62.23.212.56]) by core3.amsl.com (Postfix) with ESMTP id 0B5F83A695F for ; Mon, 27 Jul 2009 07:09:42 -0700 (PDT) Received: from FRMRSSXCHHUB02.dc-m.alcatel-lucent.com (FRMRSSXCHHUB02.dc-m.alcatel-lucent.com [135.120.45.62]) by smail3.alcatel.fr (8.13.8/8.13.8/ICT) with ESMTP id n6RE9f1q010056 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 27 Jul 2009 16:09:41 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.47]) by FRMRSSXCHHUB02.dc-m.alcatel-lucent.com ([135.120.45.62]) with mapi; Mon, 27 Jul 2009 16:09:40 +0200 From: "DRAGE, Keith (Keith)" To: Gonzalo Camarillo , SIPCORE Date: Mon, 27 Jul 2009 16:09:38 +0200 Thread-Topic: [sipcore] Milestone to revise RFC 3265: Conclusion Thread-Index: AcoOs3lBncOLHIywTdOwZW7nUOdCgwAAjPOA Message-ID: References: <4A3227D2.4020808@ericsson.com> <4A40853F.8010102@ericsson.com> <4A6D995D.7040609@ericsson.com> In-Reply-To: <4A6D995D.7040609@ericsson.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.57 on 155.132.188.83 Subject: Re: [sipcore] Milestone to revise RFC 3265: Conclusion 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, 27 Jul 2009 14:09:44 -0000 So I would like to see agreement that: 1) rfc3625bis implementations are expected to be both forward and backward = compatible with RFC 3265 implementations except where changes have been exp= licitly agreed to solve interoperability problems (i.e. of the order of RFC= 3265 was so unclear in what should happen that any judgement of compatibil= ity issues is impossible). This may be obvious to some people, but this is = the first bis document we have done for SIP (apart from RFC 3261) and we sh= ould definitely state this is the policy. 2) Adam tells me that he thinks the list of addressed issues in the Appendi= xes to this document (which I believe come from various issue trackers like= SIPIT) is pretty much complete. I would therefore suggest to take this as = the stated scope of the work, unless the WG now identifies other issues. Th= is is both the current Appendix B and Appendix C. Note that the scope of the work could always be extended by consensus call = later, but we do need to avoid open ended work items where we keep adding n= ew tasks as the work progresses. I would like to understand some of the clause numbering changes in the docu= ment, because some of the changes that have occurred are less than helpful = in identifying real differences between the two documents. Maybe Adam can t= alk me through this during IETF. Finally there is one requirement in RFC 5367 that updates RFC 3265. What ar= e we going to do with that requirement. regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo > Sent: Monday, July 27, 2009 1:11 PM > To: SIPCORE > Subject: Re: [sipcore] Milestone to revise RFC 3265: Conclusion >=20 > Folks, >=20 > the WG item version of this draft has just been submitted. I=20 > would like to see discussions about the scope of this effort,=20 > per my previous email below. >=20 > http://www.ietf.org/id/draft-ietf-sipcore-rfc3265bis-00.txt >=20 > Thanks, >=20 > Gonzalo > SIPCORE co-chair >=20 > Gonzalo Camarillo wrote: > > Hi, > >=20 > > based on all the responses received, there is agreement that the WG=20 > > should work on revising RFC 3265 and that this draft is a good=20 > > starting point for that. Therefore, I will ask our ADs to add a=20 > > milestone to revise RFC 3265 and the author of the draft to=20 > submit it=20 > > as a SIPCORE WG item. > >=20 > > Keith brought up two good questions about the scope of this effort=20 > > that we need to resolve (while he agrees on a limited-scope update=20 > > that would preserve backwards compatibility, he would object to a=20 > > wider scope). The first discussions on this topic need to deal with=20 > > those questions in order to reach an agreement on the=20 > actual scope of this effort. > >=20 > > Thanks, > >=20 > > Gonzalo > > SIPCORE cochair > >=20 > >=20 > > Gonzalo Camarillo wrote: > >> Folks, > >> > >> since the publication of RFC 3265, we have gotten significant=20 > >> experience deploying SIP-based notification systems. It has been=20 > >> proposed to revise RFC 3265 based on that experience. We have two=20 > >> questions for the WG: > >> > >> 1) should we add a milestone to our charter to revise RFC 3265? > >> > >> 2) if we add such a milestone, should we take the=20 > following draft as=20 > >> the initial WG item for the milestone? > >> > >> http://tools.ietf.org/html/draft-roach-sipcore-rfc3265bis-00 > >> > >> Thanks, > >> > >> Gonzalo > >> SIPCORE co-chair > >> _______________________________________________ > >> 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 >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From gao.yang2@zte.com.cn Mon Jul 27 09:59:49 2009 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 EC3083A682F for ; Mon, 27 Jul 2009 09:59:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -94.842 X-Spam-Level: X-Spam-Status: No, score=-94.842 tagged_above=-999 required=5 tests=[AWL=-2.052, BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, HTML_MESSAGE=0.001, MIME_8BIT_HEADER=0.3, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, RCVD_DOUBLE_IP_LOOSE=0.76, SARE_SUB_ENC_GB2312=1.345, 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 4YteLvS6eGkN for ; Mon, 27 Jul 2009 09:59:47 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id D945D3A6945 for ; Mon, 27 Jul 2009 09:59:46 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 111641727820181; Tue, 28 Jul 2009 00:41:24 +0800 (CST) Received: from [10.30.3.19] by [10.30.17.100] with StormMail ESMTP id 12290.4786316380; Tue, 28 Jul 2009 00:52:09 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id n6RGxhu2030761; Tue, 28 Jul 2009 00:59:43 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4A6DADF6.7000106@cisco.com> To: Paul Kyzivat MIME-Version: 1.0 X-Mailer: Lotus Notes Release 6.5.4 March 27, 2005 Message-ID: From: gao.yang2@zte.com.cn Date: Tue, 28 Jul 2009 00:59:19 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2009-07-28 00:59:19, Serialize complete at 2009-07-28 00:59:19 Content-Type: multipart/alternative; boundary="=_alternative 005D517748257600_=" X-MAIL: mse2.zte.com.cn n6RGxhu2030761 Cc: SIPCORE Subject: [sipcore] =?gb2312?b?tPC4tDogUmU6ICBOZXcgcmV2aXNpb24gb2YgdGhlIHJl?= =?gb2312?b?LUlOVklURSBoYW5kbGluZyBkcmFmdA==?= 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, 27 Jul 2009 16:59:50 -0000 This is a multipart message in MIME format. --=_alternative 005D517748257600_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SSBhbSBmaW5lIHdpdGggdGhlIHJ1bGVzIHRvby4NCg0KVGhhbmtzLg0KDQpHYW8NCg0KPT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAgOiAyMTAwMTINCiBUZWwgICAg OiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQogZV9tYWlsIDogZ2FvLnlhbmcy QHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQoNCg0KDQpQ YXVsIEt5eml2YXQgPHBreXppdmF0QGNpc2NvLmNvbT4gDQoyMDA5LTA3LTI3IDIxOjM5DQoNCsrV vP7Iyw0KR29uemFsbyBDYW1hcmlsbG8gPEdvbnphbG8uQ2FtYXJpbGxvQGVyaWNzc29uLmNvbT4N CrOty80NClNJUENPUkUgPHNpcGNvcmVAaWV0Zi5vcmc+LCBnYW8ueWFuZzJAenRlLmNvbS5jbg0K 1vfM4g0KUmU6IFtzaXBjb3JlXSBOZXcgcmV2aXNpb24gb2YgdGhlIHJlLUlOVklURSBoYW5kbGlu ZyBkcmFmdA0KDQoNCg0KDQoNCg0KDQoNCkdvbnphbG8gQ2FtYXJpbGxvIHdyb3RlOg0KPiBIaSwN Cj4gDQo+IGl0IHNlZW1zIHdlIGNhbiBjb3ZlciBtb3N0IGNhc2VzIHdpdGggdGhlIGZvbGxvd2lu ZyBydWxlczoNCj4gDQo+IDEpIGEgcmVsaWFibGUgcHJvdmlzaW9uYWwgcmVzcG9uc2Ugb3IgYSAy eHggcmVzcG9uc2UgdG8gYSB0YXJnZXQgcmVmcmVzaCANCg0KPiBjb25maXJtcyB0aGF0IHRoZSBV QVMgaGFzIHJlZnJlc2hlZCB0aGUgdGFyZ2V0LiBUaGlzIHJlZnJlc2ggaXMgbm90IA0KPiByb2xs ZWQgYmFjayB1bmRlciBhbnkgY2lyY3Vtc3RhbmNlIChpLmUuLCBldmVuIGlmIHRoZSB0YXJnZXQg cmVmcmVzaCB3YXMgDQoNCj4gYSByZS1JTlZJVEUgdGhhdCBldmVudHVhbGx5IGZhaWxlZCBvciB0 aGUgdGFyZ2V0IHJlZnJlc2ggd2FzIGFuIFVQREFURSANCj4gd2l0aGluIGEgcmUtSU5WSVRFIHRo YXQgZXZlbnR1YWxseSBmYWlsZWQpLg0KPiANCj4gMikgaWYgdGhlIHRhcmdldCByZWZyZXNoIGlz IHJlamVjdGVkIHdpdGhvdXQgYW55IHByZXZpb3VzIHJlbGlhYmxlIA0KPiBwcm92aXNpb25hbCBy ZXNwb25zZSwgdGhlIHRhcmdldCBpcyBub3QgcmVmcmVzaGVkICh0aGlzIGFsbG93cyBVQVNzIHRv IA0KPiBhdXRoZW50aWNhdGUgdGFyZ2V0IHJlZnJlc2ggcmVxdWVzdHMpLg0KPiANCj4gMykgYSBy ZWxpYWJsZSBwcm92aXNpb25hbCByZXNwb25zZSBvciBhIDJ4eCByZXNwb25zZSB0byBhIHRhcmdl dCByZWZyZXNoIA0KDQo+IHJlcXVlc3QgY2FuIHJlZnJlc2ggdGhlIHRhcmdldC4gU3VjaCBhIHJl ZnJlc2ggaXMgbmV2ZXIgcm9sbGVkIGJhY2sgDQo+IGVpdGhlci4gKFRoZSBVQVMgZm9yIHRoZSBy ZS1JTlZJVEUgY291bGQgb2YgY291cnNlIGFsc28gY2hvb3NlIHRvIHNlbmQgDQo+IGFuIFVQREFU RSBpbnN0ZWFkIG9mIHJlZnJlc2hpbmcgdGhlIHRhcmdldCBpbiBhIHJlc3BvbnNlIHRvIHRoZSAN CnJlLUlOVklURS4pDQo+IA0KPiBXZSB3b3VsZCBhbHNvIHJlY29tbWVuZCBVQUNzIG5vdCB0byBw aWdneWJhY2sgYSB0YXJnZXQgcmVmcmVzaCB3aXRoIA0KPiBzZXNzaW9uIGNoYW5nZXMgaW4gcmUt SU5WSVRFcyB0aGF0IGRvIG5vdCB1c2UgMTAwcmVsIGJlY2F1c2UgdGhpcyB3b3VsZCANCj4gbWFr ZSBpdCB1bm5lY2Vzc2FyaWx5IGNvbXBsaWNhdGVkIGZvciB0aGUgVUFTIHRvIGFjY2VwdCB0aGUg dGFyZ2V0IA0KPiByZWZyZXNoIGJ1dCB0byByZWplY3QgdGhlIHNlc3Npb24gY2hhbmdlcy4NCj4g DQo+IFdpdGggcmVzcGVjdCB0byBhIFVBQyBmb3IgYSByZS1JTlZJVEUgbG9zaW5nIGl0cyBJUCBh ZGRyZXNzLCB0aGUgcmlnaHQgDQo+IHRoaW5nIHRvIGRvIHdvdWxkIGJlIHRvIHNlbmQgYW4gVVBE QVRFIHRvIHJlZnJlc2ggdGhlIHRhcmdldCwgY2FuY2VsIHRoZSANCg0KPiByZS1JTlZJVEUgYmVj YXVzZSB0aGUgVUFDIHdvdWxkIG5vdCBiZSBhYmxlIHRvIHJlY2VpdmUgcmVzcG9uc2VzIGZvciBp dCANCj4gYW55IGxvbmdlciwgYW5kIGluaXRpYXRlIGEgbmV3IHJlLUlOVklURSBvciBVUERBVEUg aW4gb3JkZXIgdG8gZ2V0IHRoZSANCj4gbWVkaWEgc2Vzc2lvbiBpbiBzeW5jIGFnYWluLg0KDQpJ J20gZmluZSB3aXRoIGFsbCBvZiB0aGUgYWJvdmUgLSBpdHMgY2xlYXIgYW5kIHByZWNpc2UuIElu IHRoZSBsYXN0IA0KcGFyYWdyYXBoLCB0aGUgb3JkZXIgb2YgZXZlbnRzIGlzIGltcG9ydGFudC4N Cg0KICAgICAgICAgICAgICAgICBUaGFua3MsDQogICAgICAgICAgICAgICAgIFBhdWwNCg0KPiBD aGVlcnMsDQo+IA0KPiBHb256YWxvDQo+IA0KPiANCj4gUGF1bCBLeXppdmF0IHdyb3RlOg0KPj4g SSdtIGRvbid0IGtub3cgaWYgd2UgYXJlIG9uIHF1aXRlIHRoZSBzYW1lIHBhZ2UgeWV0Lg0KPj4g T25jZSBhY2NlcHRlZCwgSSBkb24ndCB0aGluayBhIHRhcmdldCByZWZyZXNoIHNob3VsZCBiZSBy b2xsZWQgYmFjayBieSANCj4+IGFueXRoaW5nLg0KPj4NCj4+IEEga2V5IHVzZSBjYXNlIG1pZ2h0 IGJlOg0KPj4NCj4+IEkndmUgc3RhcnRlZCBhbiByZUlOVklURSAtIG9uZSB0aGF0IG1pZ2h0IHRh a2UgYXdoaWxlIGJlY2F1c2UgaXQgaXMgDQo+PiB0cnlpbmcgdG8gYWRkIG1lZGlhIGFuZCB0aGUg b3RoZXIgZW5kIGlzIGFsZXJ0aW5nIGFib3V0IHRoYXQuDQo+Pg0KPj4gV2hpbGUgdGhhdCBpcyBp biBwcm9ncmVzcyBJIGxvc2UgbXkgSVAgYWRkcmVzcyBhbmQgbmVlZCB0byB0YXJnZXQgDQo+PiBy ZWZyZXNoLiBTbyB3aGF0IGRvIEkgZG8/DQo+Pg0KPj4gSSB0aGluayBJIHNlbmQgYW4gVVBEQVRF LCB3aGljaCB3aWxsIGJlIGluIHRoZSBtaWRzdCBvZiB0aGUgcmVJTlZJVEUgDQo+PiB0cmFuc2Fj dGlvbi4gSSBtYWtlIGl0IGEgc2ltcGxlIG9uZSwgaW4gdGhhdCBpdCBpbmNsdWRlcyBubyBvL2Es IGl0cyANCj4+ICpqdXN0KiBhIHRhcmdldCByZWZyZXNoLiBPZiBjb3Vyc2UgdGhlIFZpYSBmb3Ig aXQgaGFzIHRoZSBuZXcgaXAgDQo+PiBhZGRyZXNzLiBJdCAqbWlnaHQqIGJlIHJlamVjdGVkIHdp dGggNDAxLiBJZiBzbyBJIG1heSBoYXZlIHRvIHRyeSANCj4+IGFnYWluLCBidXQgYXQgbGVhc3Qg SSBoYXZlIGEgY2hhbmNlIG9mIGdldHRpbmcgdGhlIHJlc3BvbnNlIGFuZCB0cnlpbmcgDQo+PiBh Z2Fpbi4NCj4+DQo+PiBOb3cgdGhlIHJlSU5WSVRFIGl0c2VsZiBpcyBnb2luZyB0byBmYWlsLCBi ZWNhdXNlIHRoZSByZXNwb25zZXMgd2lsbCANCj4+IGJlIGdvaW5nIHRvIGEgbm9uLWZ1bmN0aW9u YWwgYWRkcmVzcyBiYXNlZCBvbiB0aGUgVmlhIGZvciB0aGUgDQo+PiByZUlOVklURS4gV2hhdCB3 ZSAqZG9uJ3QqIHdhbnQgaXMgZm9yIHRoZSBmYWlsdXJlIG9mIHRoZSByZUlOVklURSB0byANCj4+ IHJvbGwgYmFjayB0aGUgdGFyZ2V0IHJlZnJlc2guIFRoZSBVQUMgY2FuIHRyeSBzZW5kaW5nIGEg Q0FOQ0VMIA0KPj4gZm9sbG93aW5nIHRoZSBVUERBVEUuIEl0IGNhbiBoYXZlIHRoZSBuZXcgYWRk cmVzcyBhcyBpdHMgVmlhLiBCdXQgDQo+PiBzdGlsbCB0aGUgcmVzdWx0aW5nIDQ4NyBmb3IgdGhl IHJlSU5WSVRFIHdpbGwgZ28gdG8gdGhlIHdyb25nIGFkZHJlc3MuIA0KPj4gRXZlbnR1YWxseSB0 aGUgVUFDIGNhbiBzZW5kIGFub3RoZXIgcmVJTlZJVEUgd2l0aCB0aGUgbmV3IHRhcmdldC4gT3Ig DQo+PiB0aGUgVUFTIGNhbiBzZW5kIGEgbmV3IHJlSU5WSVRFIHRvIHRoZSBuZXcgdGFyZ2V0IGFk ZHJlc3MuDQo+Pg0KPj4gICAgIFRoYW5rcywNCj4+ICAgICBQYXVsDQo+Pg0KPj4gR29uemFsbyBD YW1hcmlsbG8gd3JvdGU6DQo+Pj4gSGkgUGF1bCwNCj4+Pg0KPj4+ICA+IFRoaXMgd2lsbCBlbmNv dXJhZ2UgdXNpbmcgYSAqc2ltcGxlKiByZXF1ZXN0IHRvIGRvIGFuIGVzc2VudGlhbCANCj4+PiB0 YXJnZXQNCj4+PiAgPiByZWZyZXNoLCByYXRoZXIgdGhhbiBhIGNvbXBsZXggb25lIHRoYXQgaGFz IGEgY2hhbmNlIG9mIGZhaWxpbmcuDQo+Pj4NCj4+PiBZZXMsIEkgYWdyZWUgd2l0aCB5b3UuIEkg dGhpbmsgd2UgY2FuIGdldCB3aGF0IHlvdSBhcmUgbG9va2luZyBmb3IgYnkgDQo+Pj4ga2VlcGlu ZyB0aGUgdGV4dCB0aGF0IGlzIGN1cnJlbnRseSBpbiB0aGUgZHJhZnQgKGkuZS4sIHJlLUlOVklU RXMgDQo+Pj4gcmVtYWluIGF0b21pYyBhbmQgYW4gZXJyb3IgcmVzcG9uc2Ugcm9sbHMgZXZlcnl0 aGluZyBiYWNrLCBpbmNsdWRpbmcgDQo+Pj4gdGhlIHRhcmdldCByZWZyZXNoKSwgYnkgYWRkaW5n IGEgZGVzY3JpcHRpb24gb2Ygd2h5IHBpZ2d5YmFja2luZyANCj4+PiBvdGhlciBjaGFuZ2VzIGlu IGEgdGFyZ2V0IHJlZnJlc2ggcmVxdWVzdCBpcyBhIGJhZCBpZGVhICh0aGUgbmV3IHRleHQgDQo+ Pj4gd291bGQgaW5jbHVkZSBhIGRpc2N1c3Npb24gb24gdGhlIFZpYSBwcm9ibGVtIGFuZCBvbiBs ZWdhY3kgVUFTcyANCj4+PiByZXNwb25kaW5nIHdpdGggYW4gZXJyb3IgcmVzcG9uc2UgZXZlbiBp ZiBjaGFuZ2VzIGhhdmUgYmVlbiANCj4+PiBleGVjdXRlZCksIGFuZCBieSBkaXNjb3VyYWdpbmcg dGhlIHVzZSBvZiByZS1JTlZJVEVzIHRoYXQgdXBkYXRlIHRoZSANCj4+PiB0YXJnZXQgYW5kIHBl cmZvcm0gb3RoZXIgY2hhbmdlcyBhdCB0aGUgc2FtZSB0aW1lICh3ZSBwcm9iYWJseSBuZWVkIA0K Pj4+IHRvIGdvIGFzIGZhciBhcyB0byBzYXkgdGhhdCBvbmUgU0hPVUxEIE5PVCBkbyBpdCkuDQo+ Pj4NCj4+PiBJIGFncmVlIHdpdGggeW91IHRoYXQgZW5jb3VyYWdpbmcgdGhlIHVzZSBvZiAic2lt cGxlIiByZXF1ZXN0cyB3aWxsIA0KPj4+IGJlIGJldHRlciB0aGFuIHNwZWNpZnlpbmcgY29tcGxl eCBiZWhhdmlvciBqdXN0IHRvIGNvdmVyIGNvcm5lciBjYXNlcy4NCj4+Pg0KPj4+IFRoYW5rcywN Cj4+Pg0KPj4+IEdvbnphbG8NCj4+Pg0KPj4+DQo+Pj4NCj4+PiBQYXVsIEt5eml2YXQgd3JvdGU6 DQo+Pj4+IEdvbnphbG8sDQo+Pj4+DQo+Pj4+IEkgYWdyZWUgd2l0aCBhbGwgeW91IHNheSBiZWxv dywgZXhjZXB0IGF0IHRoZSB2ZXJ5IGVuZCBhYm91dCB0YXJnZXQgDQo+Pj4+IHJlZnJlc2guDQo+ Pj4+DQo+Pj4+IElmIHRhcmdldCByZWZyZXNoZXMgYXJlIHRvIGJlIGFjY2VwdGVkIGV2ZW4gaWYg dGhlIHJlcXVlc3QgZmFpbHMsIA0KPj4+PiB0aGVuIGl0IGlzIHBvc3NpYmxlIHRvIGhpamFjayBh IHNlc3Npb24gZXZlbiBpZiBhdXRoZW50aWNhdGlvbiBpcyANCj4+Pj4gYmVpbmcgdXNlZCBmb3Ig c2lnbmFsaW5nLg0KPj4+Pg0KPj4+PiBJTU8gYSB0YXJnZXQgcmVmcmVzaCBtdXN0IGJlIGlnbm9y ZWQgaW4gYXQgbGVhc3QgKnNvbWUqIGNhc2VzIHdoZW4gDQo+Pj4+IHRoZSByZXF1ZXN0IGlzIHJl amVjdGVkLiBXZSBjb3VsZCBlbnVtZXJhdGUgdGhlc2UgY2FzZXMgDQo+Pj4+IGluZGl2aWR1YWxs eSwgb3Igc2ltcGx5IHN0YXRlIHRoYXQgaXQgd2lsbCBvbmx5IGJlIGFjY2VwdGVkIGlmIHRoZSAN Cj4+Pj4gcmVxdWVzdCBpcyBhY2NlcHRlZC4gKEluIGNhc2Ugb2YgcmVJTlZJVEUsIHRoYXQgd291 bGQgYmUgaWYgaXQgd2FzIA0KPj4+PiBhY2NlcHRlZCBzdWZmaWNpZW50bHkgdG8gcmV0dXJuIGEg Mnh4IG9yIGEgMXh4LikNCj4+Pj4NCj4+Pj4gVGhpcyB3aWxsIGVuY291cmFnZSB1c2luZyBhICpz aW1wbGUqIHJlcXVlc3QgdG8gZG8gYW4gZXNzZW50aWFsIA0KPj4+PiB0YXJnZXQgcmVmcmVzaCwg cmF0aGVyIHRoYW4gYSBjb21wbGV4IG9uZSB0aGF0IGhhcyBhIGNoYW5jZSBvZiANCj4+Pj4gZmFp bGluZy4gUGVyaGFwcyBpdCB3b24ndCB3b3JrIGluIGFsbCBjYXNlcywgYnV0IHN1Y2ggaXMgbGlm ZS4NCj4+Pj4NCj4+Pj4gICAgIFRoYW5rcywNCj4+Pj4gICAgIFBhdWwNCj4+Pj4NCj4+Pj4gR29u emFsbyBDYW1hcmlsbG8gd3JvdGU6DQo+Pj4+PiBIaSBQYXVsLA0KPj4+Pj4NCj4+Pj4+IHRoYW5r cyBmb3IgeW91ciBjb21tZW50cy4gQW5zd2VycyBpbmxpbmU6DQo+Pj4+Pg0KPj4+Pj4gUGF1bCBL eXppdmF0IHdyb3RlOg0KPj4+Pj4+IEdvbnphbG8sDQo+Pj4+Pj4NCj4+Pj4+PiBUaGFua3MgZm9y IGRvaW5nIHRoaXMgd29yayEgSSBkbyBoYXZlIHNvbWUgY29tbWVudHM6DQo+Pj4+Pj4NCj4+Pj4+ PiBTZWN0aW9uIDMvRmlndXJlIDENCj4+Pj4+Pg0KPj4+Pj4+IFRoZSBmaWd1cmUgc2hvd3MgYSA2 eHggcmVzcG9uc2UuDQo+Pj4+Pj4gVGhlIHRleHQgc2F5cyB0aGF0IHRoZSBVQVMgd2FudHMgdG8g cmVqZWN0IHRoZSBuZXcgb2ZmZXIuDQo+Pj4+Pj4NCj4+Pj4+PiBBIFVBUyB3b3VsZCBwcm9iYWJs eSBub3QgdXNlIGEgNnh4IHJlc3BvbnNlIHRvIHJlamVjdCBtZWRpYS4NCj4+Pj4+PiAoSSBndWVz cyBpdCBtaWdodCB1c2UgNjA2LCBidXQgNDg4IHdvdWxkIGJlIG1vcmUgYXBwcm9wcmlhdGUuKQ0K Pj4+Pj4+IEluIGZhY3QsIGl0IHByb2JhYmx5IHdvdWxkIG5vdCByZWplY3QgdGhlIHJlcXVlc3Qg YXQgYWxsLCBidXQgDQo+Pj4+Pj4gcmF0aGVyIHdvdWxkIGp1c3QgcmVmdXNlIHRoZSBhZGRlZCBt ZWRpYSBzdHJlYW0uDQo+Pj4+Pj4NCj4+Pj4+PiBUaGUgcG9pbnQgYmVpbmcgbWFkZSBkb2Vzbid0 IHJlcXVpcmUgdGhhdCB0aGUgcmVzcG9uc2UgYmUgNnh4IG9yIA0KPj4+Pj4+IHRoYXQgaXQgYmUg d2l0aCB0aGUgcHVycG9zZSBvZiByZWZ1c2luZyB0aGUgbWVkaWEuIFNvIEkgdGhpbmsgd2hhdCAN Cj4+Pj4+PiBpcyBuZWVkZWQgaGVyZSBpcyB0byBmaW5kIGEgcGxhdXNpYmxlIGV4YW1wbGUgdG8g bWFrZSB0aGUgcG9pbnQuDQo+Pj4+Pj4NCj4+Pj4+PiBBIGdvb2Qgb25lIGZvciB0aGUgcHVycG9z ZSBoZXJlIG1pZ2h0IGJlIGEgNDg4IHRvIHJlamVjdCB0aGUgDQo+Pj4+Pj4gbWVkaWEsIG9yIGEg IDQwMSByZXNwb25zZSBhcyBhbm90aGVyIHNvcnQgb2YgcmVhc29uIGZvciByZWplY3RpbmcgDQo+ Pj4+Pj4gdGhlIHdob2xlIHRoaW5nIGJ1dCB3YW50aW5nIHRvIHByZXNlcnZlIHdoYXQgdGhlcmUg aXMuDQo+Pj4+Pg0KPj4+Pj4geWVzLCBJIGFncmVlIHRoYXQgYSA0ODggcmVzcG9uc2Ugd291bGQg YmUgbW9yZSBhcHByb3ByaWF0ZS4gSSB3aWxsIA0KPj4+Pj4gY2hhbmdlIHRoYXQgaW4gdGhlIGRy YWZ0Lg0KPj4+Pj4NCj4+Pj4+Pg0KPj4+Pj4+IFNlY3Rpb24gNToNCj4+Pj4+Pg0KPj4+Pj4+PiAg ICBBIGNoYW5nZSB0byB0aGUgc2Vzc2lvbiBzdGF0ZSBpcyBjb25zaWRlcmVkIHRvIGhhdmUgYmVl biANCmV4ZWN1dGVkDQo+Pj4+Pj4+ICAgIHdoZW4gdGhlIG5ldyBtZWRpYSBwYXJhbWV0ZXJzIGFy ZSBiZWluZyB1c2VkLiAgVGhlcmVmb3JlLCBhIA0KPj4+Pj4+PiBjaGFuZ2UgdG8NCj4+Pj4+Pj4g ICAgYSBzdHJlYW0gc3ViamVjdCB0byBwcmVjb25kaXRpb25zIFtSRkM0MDMyXSBpcyBjb25zaWRl cmVkIHRvIA0KaGF2ZQ0KPj4+Pj4+PiAgICBiZWVuIGV4ZWN1dGVkIHdoZW4gdGhlIG5ldyBtZWRp YSBwYXJhbWV0ZXJzIHN0YXJ0IGJlaW5nIHVzZWQ7IA0Kbm90DQo+Pj4+Pj4+ICAgIHdoZW4gdGhl IHByZWNvbmRpdGlvbnMgZm9yIHRoZSBzdHJlYW0gYXJlIG1ldC4gDQo+Pj4+Pj4+IFVuc3VycHJp c2luZ2x5LCB0aGUNCj4+Pj4+Pj4gICAgVUFTIGNvbnNpZGVycyB0aGUgbmV3IHBhcmFtZXRlcnMg dG8gYmUgaW4gdXNlIHdoZW4gaXQgYWN0dWFsbHkgDQo+Pj4+Pj4+IHN0YXJ0cw0KPj4+Pj4+PiAg ICB1c2luZyB0aGVtLiANCj4+Pj4+Pg0KPj4+Pj4+IEknbSBub3QgZW50aXJlbHkgZm9sbG93aW5n IHRoaXMuIEkgdGhpbmsgdGhlcmUgbWF5IGJlIGFuIA0KPj4+Pj4+IGFzc3VtcHRpb24gaGVyZSB0 aGF0IHRoZSBVQUMgaXMgdGhlIG9mZmVyZXIgYW5kIHRoZSBVQVMgdGhlIA0KPj4+Pj4+IGFuc3dl cmVyLiBJJ20gZ3Vlc3NpbmcgeW91IGFyZSBzYXlpbmcgdGhhdCB0aGUgYW5zd2VyZXIgY29uc2lk ZXJzIA0KPj4+Pj4+IHRoZSBuZXcgcGFyYW1ldGVycyB0byBiZSBpbiB1c2Ugd2hlbiBpdCBhY3R1 YWxseSBzdGFydHMgdXNpbmcgdGhlbS4NCj4+Pj4+Pg0KPj4+Pj4+IFNpbmNlIHRoaXMgc2VjdGlv biBpcyBhYm91dCB0aGUgVUFTIChmb3IgdGhlIHJlaW52aXRlKSwgdGhpcyBwb2ludCANCj4+Pj4+ PiBpcyBwcm9iYWJseSB0aGF0IHdoZW4gdGhlIFVBUyBpcyBhbHNvIHRoZSBhbnN3ZXJlciBpdCBj YW4gZGVjaWRlIA0KPj4+Pj4+IHdoZW4gdGhlIG5ldyBtZWRpYSBpcyBpbiB1c2UgYmFzZWQgb24g d2hlbiBpdCBzdGFydHMgdXNpbmcgdGhlbS4NCj4+Pj4+Pg0KPj4+Pj4+IEJ1dCB3aGF0IGhhcHBl bnMgd2hlbiB0aGUgVUFTIGlzIHRoZSBvZmZlcmVyPyBJbiB0aGF0IGNhc2UgSSB0aGluayANCj4+ Pj4+PiBpdCBtdXN0IGFzc3VtZSB0aGUgbWVkaWEgaXMgaW4gdXNlIGFzIHNvb24gYXMgaXQgaXMg b2ZmZXJlZC4gQnV0IA0KPj4+Pj4+IG1heWJlIHRoYXQgaXNuJ3QgYWx3YXlzIHRoZSBjYXNlIHdp dGggcHJlY29uZGl0aW9ucy4gSSBkb24ndCB0aGluayANCj4+Pj4+PiBpdCBjYW4gd2FpdCB0aWxs IGl0IHJlY2VpdmVzIG1lZGlhLCBiZWNhdXNlIG1lZGlhIG1heSBiZSBpbiBmbGlnaHQgDQo+Pj4+ Pj4gd2hlbiBpdCBtYWtlcyBpdHMgZGVjaXNpb24uDQo+Pj4+Pg0KPj4+Pj4geWVzLCB0aGUgZHJh ZnQgYXNzdW1lcyB0aGF0IHRoZSBVQVMgaXMgdGhlIGFuc3dlcmVyIGJlY2F1c2UgdGhhdCANCj4+ Pj4+IHdhcyB0aGUgdXNlIGNhc2UgYmVpbmcgZGlzY3Vzc2VkIG9yaWdpbmFsbHkuIEhvd2V2ZXIs IHlvdSBhcmUgcmlnaHQgDQo+Pj4+PiB0aGF0IHdlIHNob3VsZCBhbHNvIGNvdmVyIHRoZSBjYXNl IHdoZXJlIHRoZSBVQVMgaXMgdGhlIG9mZmVyZXIuIEkgDQo+Pj4+PiB3aWxsIGxvb2sgaW50byBp dCBhbmQgYWRkIHRleHQgYWJvdXQgaXQgaW4gdGhlIGRyYWZ0Lg0KPj4+Pj4NCj4+Pj4+Pg0KPj4+ Pj4+PiAgICBBcyBkZXNjcmliZWQgaW4gU2VjdGlvbiA4LjMuMSBvZiBSRkMgMzI2NCBbUkZDMzI2 NF0sIHRoZQ0KPj4+Pj4+PiAgICBVQUMgY29uc2lkZXJzIHRoZSBuZXcgcGFyYW1ldGVycyB0byBi ZSBpbiB1c2Ugd2hlbiBtZWRpYSBpcyANCj4+Pj4+Pj4gcmVjZWl2ZWQNCj4+Pj4+Pj4gICAgaW4g dGhlIG5ldyBwb3J0LCB3aGljaCBzaG91bGQgYmUgaW50ZXJwcmV0ZWQgYXMgZm9sbG93czoNCj4+ Pj4+Pj4NCj4+Pj4+Pj4gICAgICAgUmVjZWl2ZWQsIGluIHRoaXMgY2FzZSwgbWVhbnMgdGhhdCB0 aGUgbWVkaWEgaXMgcGFzc2VkIHRvIGEgDQo+Pj4+Pj4+IG1lZGlhDQo+Pj4+Pj4+ICAgICAgIHNp bmsuICBUaGlzIG1lYW5zIHRoYXQgaWYgdGhlcmUgaXMgYSBwbGF5b3V0IGJ1ZmZlciwgdGhlIA0K YWdlbnQNCj4+Pj4+Pj4gICAgICAgd291bGQgY29udGludWUgdG8gbGlzdGVuIG9uIHRoZSBvbGQg cG9ydCB1bnRpbCB0aGUgbWVkaWEgb24gDQo+Pj4+Pj4+IHRoZQ0KPj4+Pj4+PiAgICAgICBuZXcg cG9ydCByZWFjaGVkIHRoZSB0b3Agb2YgdGhlIHBsYXlvdXQgYnVmZmVyLiAgQXQgdGhhdCANCj4+ Pj4+Pj4gdGltZSwgaXQNCj4+Pj4+Pj4gICAgICAgTUFZIGNlYXNlIGxpc3RlbmluZyBmb3IgbWVk aWEgb24gdGhlIG9sZCBwb3J0Lg0KPj4+Pj4+DQo+Pj4+Pj4gSSBkb24ndCBrbm93IHdoYXQgdGhl IGFib3ZlIGhhcyB0byBkbyB3aXRoIHRoZSBiZWhhdmlvciBvZiB0aGUgVUFTLg0KPj4+Pj4NCj4+ Pj4+IFRoZSBVQUMgbmVlZHMgdG8ga25vdyB3aGVuIHRoZSBuZXcgcGFyYW1ldGVycyBhcmUgaW4g dXNlIGluIG9yZGVyIA0KPj4+Pj4gdG8gaW1wbGVtZW50IHRoZSBub3JtYXRpdmUgYmVoYXZpb3Ig aW4gU2VjdGlvbiA2Og0KPj4+Pj4NCj4+Pj4+ICAgIC4uLiBhIFVBQyB0aGF0IHJlY2VpdmVzIGFu IGVycm9yIHJlc3BvbnNlIHRvIGEgcmUtSU5WSVRFIGZvciANCndoaWNoDQo+Pj4+PiAgICBjaGFu Z2VzIGhhdmUgYmVlbiBhbHJlYWR5IGV4ZWN1dGVkIC4uLg0KPj4+Pj4NCj4+Pj4+IEluIGFueSBj YXNlLCBJIHdpbGwgY2xhcmlmeSBhbGwgdGhpcyB3aGVuIEkgd3JpdGUgdGhlIHRleHQgYWJvdXQg DQo+Pj4+PiB0aGUgVUFTIGJlaW5nIHRoZSBvZmZlcmVyIGJlY2F1c2UgdGhpcyB0eXBlIG9mIGJl aGF2aW9yIGhhcyB0byBkbyANCj4+Pj4+IHdpdGggYmVpbmcgdGhlIG9mZmVyZXIgb3IgdGhlIGFu c3dlcmVyLCBub3QgdGhlIFVBQyBvciB0aGUgVUFTLg0KPj4+Pj4NCj4+Pj4+DQo+Pj4+Pj4+IDku ICBDbGFyaWZpY2F0aW9ucyBvbiBUYXJnZXQgUmVmcmVzaCBSZXF1ZXN0cw0KPj4+Pj4NCj4+Pj4+ IHRoZSBjdXJyZW50IHRleHQgaXMgYSBzdHJhdyBtYW4gdGhhdCBwdXRzIHRhcmdldCByZWZyZXNo ZXMgaW4gdGhlIA0KPj4+Pj4gc2FtZSBjYXRlZ29yeSBhcyBhbnkgb3RoZXIgY2hhbmdlLiBUaGUg b3RoZXIgb3B0aW9uIHdlIHRhbGtlZCBhYm91dCANCj4+Pj4+IGluIHRoZSBwYXN0IHdhcyB0byBz cGVjaWFsIGNhc2UgdGhlbSBzbyB0aGF0IHRoZXkgYXJlIHRyZWF0ZWQgDQo+Pj4+PiBkaWZmZXJl bnRseS4gWW91IHNlZW0gdG8gbGlrZSB0aGUgbGF0dGVyIG9wdGlvbiBiZXR0ZXIuIFdoYXQgZG8g eW91IA0KPj4+Pj4gdGhpbmsgYWJvdXQgdGhlIGZvbGxvd2luZyB0ZXh0Pw0KPj4+Pj4NCj4+Pj4+ DQo+Pj4+PiA8c2VjdGlvbiB0aXRsZT0iQ2xhcmlmaWNhdGlvbiBvbiB0aGUgQXRvbWljaXR5IG9m IFRhcmdldCBSZWZyZXNoIA0KPj4+Pj4gUmVxdWVzdHMiDQo+Pj4+PiBhbmNob3I9InNlYy1hdG9t Ij4NCj4+Pj4+IDx0Pg0KPj4+Pj4gVGhlIHJlbW90ZSB0YXJnZXQgb2YgYSBkaWFsb2cgaXMgYSBz cGVjaWFsIHR5cGUgb2Ygc3RhdGUgaW5mb3JtYXRpb24NCj4+Pj4+IGJlY2F1c2Ugb2YgaXRzIGVz c2VudGlhbCByb2xlIGluIHRoZSBleGNoYW5nZSBvZiBTSVAgbWVzc2FnZXMgDQpiZXR3ZWVuDQo+ Pj4+PiBVQXMgaW4gYSBkaWFsb2cuIEEgVUEgaW52b2x2ZWQgaW4gYSBkaWFsb2cgcmVjZWl2ZXMg dGhlIHJlbW90ZSANCnRhcmdldA0KPj4+Pj4gb2YgdGhlIGRpYWxvZyBmcm9tIHRoZSByZW1vdGUg VUEuIFRoZSBVQSB1c2VzIHRoZSByZW1vdGUgdGFyZ2V0IHRvDQo+Pj4+PiBzZW5kIFNJUCByZXF1 ZXN0cyB0byB0aGUgcmVtb3RlIFVBLg0KPj4+Pj4gPC90Pg0KPj4+Pj4gPHQ+DQo+Pj4+PiBUaGUg cmVtb3RlIHRhcmdldCBpcyBhIHBpZWNlIG9mIHN0YXRlIGluZm9ybWF0aW9uIHRoYXQgaXMgbm90 IG1lYW50IA0KdG8NCj4+Pj4+IGJlIG5lZ290aWF0ZWQuIFdoZW4gYSBVQUMgY2hhbmdlcyBpdHMg YWRkcmVzcywgdGhlIFVBQyBzaW1wbHkNCj4+Pj4+IGNvbW11bmljYXRlcyBpdHMgbmV3IGFkZHJl c3MgdG8gdGhlIFVBUyBpbiBvcmRlciB0byByZW1haW4gcmVhY2hhYmxlDQo+Pj4+PiBieSB0aGUg VUFTLiBBcyBkZXNjcmliZWQgaW4gPHhyZWYgdGFyZ2V0PSJzZWMtYmFjay1hdG9tIi8+LCBhIFVB Uw0KPj4+Pj4gc3RhcnRzIHVzaW5nIHRoZSBuZXcgcmVtb3RlIHRhcmdldCBhcyBzb29uIGFzIHRo ZSB0YXJnZXQgcmVmcmVzaA0KPj4+Pj4gcmVxdWVzdCBpcyByZWNlaXZlZCwgcmVnYXJkbGVzcyBv ZiB0aGUgcmVzcG9uc2UgdGhlIFVBUyBnZW5lcmF0ZXMgdG8NCj4+Pj4+IHRoYXQgcmVxdWVzdC4g VGhhdCBpcywgZXZlbiBpZiB0aGUgVUFTIGdlbmVyYXRlcyBhbiBlcnJvciByZXNwb25zZSANCnRv DQo+Pj4+PiB0aGUgdGFyZ2V0IHJlZnJlc2ggcmVxdWVzdCwgdGhlIFVBUyBuZWVkcyB0byB1cGRh dGUgdGhlIGRpYWxvZydzDQo+Pj4+PiByZW1vdGUgdGFyZ2V0IFVSSS4NCj4+Pj4+IDwvdD4NCj4+ Pj4+IDx0Pg0KPj4+Pj4gVGhlIGZhY3QgdGhhdCBhIHRhcmdldCByZWZyZXNoIHJlcXVlc3QgdXBk YXRlcyB0aGUgcmVtb3RlIHRhcmdldA0KPj4+Pj4gcmVnYXJkbGVzcyBvZiB0aGUgcmVzcG9uc2Ug aXQgdHJpZ2dlcnMgaW1wbGllcyB0aGF0IHRhcmdldCByZWZyZXNoDQo+Pj4+PiByZXF1ZXN0cyBh cmUgbm90IGF0b21pYy4gVGhhdCBpcywgYW4gZXJyb3IgcmVzcG9uc2UgdG8gYSB0YXJnZXQNCj4+ Pj4+IHJlZnJlc2ggcmVxdWVzdCB3aWxsIGtlZXAgYWxsIGNoYW5nZXMgYXNzb2NpYXRlZCB0byB0 aGUgcmVxdWVzdCBmcm9tDQo+Pj4+PiBiZWluZyBwZXJmb3JtZWQgZXhjZXB0IGZvciB0aGUgcmVm cmVzaCBvZiB0aGUgcmVtb3RlIHRhcmdldCwgd2hpY2gNCj4+Pj4+IHdpbGwgYmUgcGVyZm9ybWVk IGFueXdheS4NCj4+Pj4+IDwvdD4NCj4+Pj4+IDwvc2VjdGlvbj4NCj4+Pj4+DQo+Pj4+Pg0KPj4+ Pj4gQ2hlZXJzLA0KPj4+Pj4NCj4+Pj4+IEdvbnphbG8NCj4+Pj4+DQo+Pj4NCj4+Pg0KPiANCj4g DQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2Vu ZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRp YWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNy ZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhp cyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFu c21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRy ZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5v dGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBp biB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMg bWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRp LVNwYW0gc3lzdGVtLg0K --=_alternative 005D517748257600_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgYW0gZmluZSB3aXRoIHRoZSBy dWxlcyB0b28uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5UaGFua3MuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij5HYW88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPj09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsgJm5ic3A7 OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIgJm5ic3A7 IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248 YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj4NCjxi cj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lkdGg9 MjYlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5QYXVsIEt5eml2YXQgJmx0O3Br eXppdmF0QGNpc2NvLmNvbSZndDs8L2I+DQo8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0i c2Fucy1zZXJpZiI+MjAwOS0wNy0yNyAyMTozOTwvZm9udD4NCjx0ZCB3aWR0aD03MyU+DQo8dGFi bGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48 Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxm b250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5Hb256YWxvIENhbWFyaWxsbyAmbHQ7R29uemFs by5DYW1hcmlsbG9AZXJpY3Nzb24uY29tJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRk Pg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+s63LzTwv Zm9udD48L2Rpdj4NCjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+U0lQQ09SRSAm bHQ7c2lwY29yZUBpZXRmLm9yZyZndDssIGdhby55YW5nMkB6dGUuY29tLmNuPC9mb250Pg0KPHRy IHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJz YW5zLXNlcmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5z LXNlcmlmIj5SZTogW3NpcGNvcmVdIE5ldyByZXZpc2lvbiBvZiB0aGUgcmUtSU5WSVRFDQpoYW5k bGluZyBkcmFmdDwvZm9udD48L3RhYmxlPg0KPGJyPg0KPHRhYmxlPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8dGQ+PC90YWJsZT4NCjxicj48L3RhYmxlPg0KPGJyPg0KPGJyPg0KPGJyPjxmb250 IHNpemU9Mj48dHQ+PGJyPg0KPGJyPg0KR29uemFsbyBDYW1hcmlsbG8gd3JvdGU6PGJyPg0KJmd0 OyBIaSw8YnI+DQomZ3Q7IDxicj4NCiZndDsgaXQgc2VlbXMgd2UgY2FuIGNvdmVyIG1vc3QgY2Fz ZXMgd2l0aCB0aGUgZm9sbG93aW5nIHJ1bGVzOjxicj4NCiZndDsgPGJyPg0KJmd0OyAxKSBhIHJl bGlhYmxlIHByb3Zpc2lvbmFsIHJlc3BvbnNlIG9yIGEgMnh4IHJlc3BvbnNlIHRvIGEgdGFyZ2V0 IHJlZnJlc2gNCjxicj4NCiZndDsgY29uZmlybXMgdGhhdCB0aGUgVUFTIGhhcyByZWZyZXNoZWQg dGhlIHRhcmdldC4gVGhpcyByZWZyZXNoIGlzIG5vdA0KPGJyPg0KJmd0OyByb2xsZWQgYmFjayB1 bmRlciBhbnkgY2lyY3Vtc3RhbmNlIChpLmUuLCBldmVuIGlmIHRoZSB0YXJnZXQgcmVmcmVzaA0K d2FzIDxicj4NCiZndDsgYSByZS1JTlZJVEUgdGhhdCBldmVudHVhbGx5IGZhaWxlZCBvciB0aGUg dGFyZ2V0IHJlZnJlc2ggd2FzIGFuIFVQREFURQ0KPGJyPg0KJmd0OyB3aXRoaW4gYSByZS1JTlZJ VEUgdGhhdCBldmVudHVhbGx5IGZhaWxlZCkuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDIpIGlmIHRo ZSB0YXJnZXQgcmVmcmVzaCBpcyByZWplY3RlZCB3aXRob3V0IGFueSBwcmV2aW91cyByZWxpYWJs ZQ0KPGJyPg0KJmd0OyBwcm92aXNpb25hbCByZXNwb25zZSwgdGhlIHRhcmdldCBpcyBub3QgcmVm cmVzaGVkICh0aGlzIGFsbG93cyBVQVNzDQp0byA8YnI+DQomZ3Q7IGF1dGhlbnRpY2F0ZSB0YXJn ZXQgcmVmcmVzaCByZXF1ZXN0cykuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDMpIGEgcmVsaWFibGUg cHJvdmlzaW9uYWwgcmVzcG9uc2Ugb3IgYSAyeHggcmVzcG9uc2UgdG8gYSB0YXJnZXQgcmVmcmVz aA0KPGJyPg0KJmd0OyByZXF1ZXN0IGNhbiByZWZyZXNoIHRoZSB0YXJnZXQuIFN1Y2ggYSByZWZy ZXNoIGlzIG5ldmVyIHJvbGxlZCBiYWNrDQo8YnI+DQomZ3Q7IGVpdGhlci4gKFRoZSBVQVMgZm9y IHRoZSByZS1JTlZJVEUgY291bGQgb2YgY291cnNlIGFsc28gY2hvb3NlIHRvDQpzZW5kIDxicj4N CiZndDsgYW4gVVBEQVRFIGluc3RlYWQgb2YgcmVmcmVzaGluZyB0aGUgdGFyZ2V0IGluIGEgcmVz cG9uc2UgdG8gdGhlIHJlLUlOVklURS4pPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFdlIHdvdWxkIGFs c28gcmVjb21tZW5kIFVBQ3Mgbm90IHRvIHBpZ2d5YmFjayBhIHRhcmdldCByZWZyZXNoIHdpdGgN Cjxicj4NCiZndDsgc2Vzc2lvbiBjaGFuZ2VzIGluIHJlLUlOVklURXMgdGhhdCBkbyBub3QgdXNl IDEwMHJlbCBiZWNhdXNlIHRoaXMNCndvdWxkIDxicj4NCiZndDsgbWFrZSBpdCB1bm5lY2Vzc2Fy aWx5IGNvbXBsaWNhdGVkIGZvciB0aGUgVUFTIHRvIGFjY2VwdCB0aGUgdGFyZ2V0DQo8YnI+DQom Z3Q7IHJlZnJlc2ggYnV0IHRvIHJlamVjdCB0aGUgc2Vzc2lvbiBjaGFuZ2VzLjxicj4NCiZndDsg PGJyPg0KJmd0OyBXaXRoIHJlc3BlY3QgdG8gYSBVQUMgZm9yIGEgcmUtSU5WSVRFIGxvc2luZyBp dHMgSVAgYWRkcmVzcywgdGhlIHJpZ2h0DQo8YnI+DQomZ3Q7IHRoaW5nIHRvIGRvIHdvdWxkIGJl IHRvIHNlbmQgYW4gVVBEQVRFIHRvIHJlZnJlc2ggdGhlIHRhcmdldCwgY2FuY2VsDQp0aGUgPGJy Pg0KJmd0OyByZS1JTlZJVEUgYmVjYXVzZSB0aGUgVUFDIHdvdWxkIG5vdCBiZSBhYmxlIHRvIHJl Y2VpdmUgcmVzcG9uc2VzIGZvcg0KaXQgPGJyPg0KJmd0OyBhbnkgbG9uZ2VyLCBhbmQgaW5pdGlh dGUgYSBuZXcgcmUtSU5WSVRFIG9yIFVQREFURSBpbiBvcmRlciB0byBnZXQNCnRoZSA8YnI+DQom Z3Q7IG1lZGlhIHNlc3Npb24gaW4gc3luYyBhZ2Fpbi48YnI+DQo8YnI+DQpJJ20gZmluZSB3aXRo IGFsbCBvZiB0aGUgYWJvdmUgLSBpdHMgY2xlYXIgYW5kIHByZWNpc2UuIEluIHRoZSBsYXN0IDxi cj4NCnBhcmFncmFwaCwgdGhlIG9yZGVyIG9mIGV2ZW50cyBpcyBpbXBvcnRhbnQuPGJyPg0KPGJy Pg0KICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsNClRoYW5rcyw8YnI+DQogJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDsgJm5ic3A7ICZuYnNwOw0KUGF1bDxicj4NCjxicj4NCiZndDsgQ2hlZXJzLDxicj4NCiZndDsg PGJyPg0KJmd0OyBHb256YWxvPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgUGF1bCBL eXppdmF0IHdyb3RlOjxicj4NCiZndDsmZ3Q7IEknbSBkb24ndCBrbm93IGlmIHdlIGFyZSBvbiBx dWl0ZSB0aGUgc2FtZSBwYWdlIHlldC48YnI+DQomZ3Q7Jmd0OyBPbmNlIGFjY2VwdGVkLCBJIGRv bid0IHRoaW5rIGEgdGFyZ2V0IHJlZnJlc2ggc2hvdWxkIGJlIHJvbGxlZA0KYmFjayBieSA8YnI+ DQomZ3Q7Jmd0OyBhbnl0aGluZy48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEEga2V5IHVz ZSBjYXNlIG1pZ2h0IGJlOjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgSSd2ZSBzdGFydGVk IGFuIHJlSU5WSVRFIC0gb25lIHRoYXQgbWlnaHQgdGFrZSBhd2hpbGUgYmVjYXVzZQ0KaXQgaXMg PGJyPg0KJmd0OyZndDsgdHJ5aW5nIHRvIGFkZCBtZWRpYSBhbmQgdGhlIG90aGVyIGVuZCBpcyBh bGVydGluZyBhYm91dCB0aGF0Ljxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgV2hpbGUgdGhh dCBpcyBpbiBwcm9ncmVzcyBJIGxvc2UgbXkgSVAgYWRkcmVzcyBhbmQgbmVlZCB0byB0YXJnZXQN Cjxicj4NCiZndDsmZ3Q7IHJlZnJlc2guIFNvIHdoYXQgZG8gSSBkbz88YnI+DQomZ3Q7Jmd0Ozxi cj4NCiZndDsmZ3Q7IEkgdGhpbmsgSSBzZW5kIGFuIFVQREFURSwgd2hpY2ggd2lsbCBiZSBpbiB0 aGUgbWlkc3Qgb2YgdGhlIHJlSU5WSVRFDQo8YnI+DQomZ3Q7Jmd0OyB0cmFuc2FjdGlvbi4gSSBt YWtlIGl0IGEgc2ltcGxlIG9uZSwgaW4gdGhhdCBpdCBpbmNsdWRlcyBubyBvL2EsDQppdHMgPGJy Pg0KJmd0OyZndDsgKmp1c3QqIGEgdGFyZ2V0IHJlZnJlc2guIE9mIGNvdXJzZSB0aGUgVmlhIGZv ciBpdCBoYXMgdGhlIG5ldw0KaXAgPGJyPg0KJmd0OyZndDsgYWRkcmVzcy4gSXQgKm1pZ2h0KiBi ZSByZWplY3RlZCB3aXRoIDQwMS4gSWYgc28gSSBtYXkgaGF2ZSB0bw0KdHJ5IDxicj4NCiZndDsm Z3Q7IGFnYWluLCBidXQgYXQgbGVhc3QgSSBoYXZlIGEgY2hhbmNlIG9mIGdldHRpbmcgdGhlIHJl c3BvbnNlIGFuZA0KdHJ5aW5nIDxicj4NCiZndDsmZ3Q7IGFnYWluLjxicj4NCiZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsgTm93IHRoZSByZUlOVklURSBpdHNlbGYgaXMgZ29pbmcgdG8gZmFpbCwgYmVj YXVzZSB0aGUgcmVzcG9uc2VzDQp3aWxsIDxicj4NCiZndDsmZ3Q7IGJlIGdvaW5nIHRvIGEgbm9u LWZ1bmN0aW9uYWwgYWRkcmVzcyBiYXNlZCBvbiB0aGUgVmlhIGZvciB0aGUNCjxicj4NCiZndDsm Z3Q7IHJlSU5WSVRFLiBXaGF0IHdlICpkb24ndCogd2FudCBpcyBmb3IgdGhlIGZhaWx1cmUgb2Yg dGhlIHJlSU5WSVRFDQp0byA8YnI+DQomZ3Q7Jmd0OyByb2xsIGJhY2sgdGhlIHRhcmdldCByZWZy ZXNoLiBUaGUgVUFDIGNhbiB0cnkgc2VuZGluZyBhIENBTkNFTA0KPGJyPg0KJmd0OyZndDsgZm9s bG93aW5nIHRoZSBVUERBVEUuIEl0IGNhbiBoYXZlIHRoZSBuZXcgYWRkcmVzcyBhcyBpdHMgVmlh Lg0KQnV0IDxicj4NCiZndDsmZ3Q7IHN0aWxsIHRoZSByZXN1bHRpbmcgNDg3IGZvciB0aGUgcmVJ TlZJVEUgd2lsbCBnbyB0byB0aGUgd3JvbmcNCmFkZHJlc3MuIDxicj4NCiZndDsmZ3Q7IEV2ZW50 dWFsbHkgdGhlIFVBQyBjYW4gc2VuZCBhbm90aGVyIHJlSU5WSVRFIHdpdGggdGhlIG5ldyB0YXJn ZXQuDQpPciA8YnI+DQomZ3Q7Jmd0OyB0aGUgVUFTIGNhbiBzZW5kIGEgbmV3IHJlSU5WSVRFIHRv IHRoZSBuZXcgdGFyZ2V0IGFkZHJlc3MuPGJyPg0KJmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyAmbmJz cDsgJm5ic3A7IFRoYW5rcyw8YnI+DQomZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7IFBhdWw8YnI+DQom Z3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IEdvbnphbG8gQ2FtYXJpbGxvIHdyb3RlOjxicj4NCiZndDsm Z3Q7Jmd0OyBIaSBQYXVsLDxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyAmbmJz cDsmZ3Q7IFRoaXMgd2lsbCBlbmNvdXJhZ2UgdXNpbmcgYSAqc2ltcGxlKiByZXF1ZXN0IHRvDQpk byBhbiBlc3NlbnRpYWwgPGJyPg0KJmd0OyZndDsmZ3Q7IHRhcmdldDxicj4NCiZndDsmZ3Q7Jmd0 OyAmbmJzcDsmZ3Q7IHJlZnJlc2gsIHJhdGhlciB0aGFuIGEgY29tcGxleCBvbmUgdGhhdCBoYXMg YSBjaGFuY2UNCm9mIGZhaWxpbmcuPGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 IFllcywgSSBhZ3JlZSB3aXRoIHlvdS4gSSB0aGluayB3ZSBjYW4gZ2V0IHdoYXQgeW91IGFyZSBs b29raW5nDQpmb3IgYnkgPGJyPg0KJmd0OyZndDsmZ3Q7IGtlZXBpbmcgdGhlIHRleHQgdGhhdCBp cyBjdXJyZW50bHkgaW4gdGhlIGRyYWZ0IChpLmUuLCByZS1JTlZJVEVzDQo8YnI+DQomZ3Q7Jmd0 OyZndDsgcmVtYWluIGF0b21pYyBhbmQgYW4gZXJyb3IgcmVzcG9uc2Ugcm9sbHMgZXZlcnl0aGlu ZyBiYWNrLA0KaW5jbHVkaW5nIDxicj4NCiZndDsmZ3Q7Jmd0OyB0aGUgdGFyZ2V0IHJlZnJlc2gp LCBieSBhZGRpbmcgYSBkZXNjcmlwdGlvbiBvZiB3aHkgcGlnZ3liYWNraW5nDQo8YnI+DQomZ3Q7 Jmd0OyZndDsgb3RoZXIgY2hhbmdlcyBpbiBhIHRhcmdldCByZWZyZXNoIHJlcXVlc3QgaXMgYSBi YWQgaWRlYSAodGhlDQpuZXcgdGV4dCA8YnI+DQomZ3Q7Jmd0OyZndDsgd291bGQgaW5jbHVkZSBh IGRpc2N1c3Npb24gb24gdGhlIFZpYSBwcm9ibGVtIGFuZCBvbiBsZWdhY3kNClVBU3MgPGJyPg0K Jmd0OyZndDsmZ3Q7IHJlc3BvbmRpbmcgd2l0aCBhbiBlcnJvciByZXNwb25zZSBldmVuIGlmIGNo YW5nZXMgaGF2ZSBiZWVuDQo8YnI+DQomZ3Q7Jmd0OyZndDsgZXhlY3V0ZWQpLCBhbmQgYnkgZGlz Y291cmFnaW5nIHRoZSB1c2Ugb2YgcmUtSU5WSVRFcyB0aGF0DQp1cGRhdGUgdGhlIDxicj4NCiZn dDsmZ3Q7Jmd0OyB0YXJnZXQgYW5kIHBlcmZvcm0gb3RoZXIgY2hhbmdlcyBhdCB0aGUgc2FtZSB0 aW1lICh3ZSBwcm9iYWJseQ0KbmVlZCA8YnI+DQomZ3Q7Jmd0OyZndDsgdG8gZ28gYXMgZmFyIGFz IHRvIHNheSB0aGF0IG9uZSBTSE9VTEQgTk9UIGRvIGl0KS48YnI+DQomZ3Q7Jmd0OyZndDs8YnI+ DQomZ3Q7Jmd0OyZndDsgSSBhZ3JlZSB3aXRoIHlvdSB0aGF0IGVuY291cmFnaW5nIHRoZSB1c2Ug b2YgJnF1b3Q7c2ltcGxlJnF1b3Q7DQpyZXF1ZXN0cyB3aWxsIDxicj4NCiZndDsmZ3Q7Jmd0OyBi ZSBiZXR0ZXIgdGhhbiBzcGVjaWZ5aW5nIGNvbXBsZXggYmVoYXZpb3IganVzdCB0byBjb3ZlciBj b3JuZXINCmNhc2VzLjxicj4NCiZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyBUaGFua3Ms PGJyPg0KJmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7IEdvbnphbG88YnI+DQomZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsgUGF1bCBLeXppdmF0IHdyb3RlOjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgR29uemFsbyw8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyBJIGFncmVlIHdpdGggYWxs IHlvdSBzYXkgYmVsb3csIGV4Y2VwdCBhdCB0aGUgdmVyeSBlbmQNCmFib3V0IHRhcmdldCA8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7IHJlZnJlc2guPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsgSWYgdGFyZ2V0IHJlZnJlc2hlcyBhcmUgdG8gYmUgYWNjZXB0ZWQgZXZl biBpZiB0aGUgcmVxdWVzdA0KZmFpbHMsIDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgdGhlbiBpdCBp cyBwb3NzaWJsZSB0byBoaWphY2sgYSBzZXNzaW9uIGV2ZW4gaWYgYXV0aGVudGljYXRpb24NCmlz IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgYmVpbmcgdXNlZCBmb3Igc2lnbmFsaW5nLjxicj4NCiZn dDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IElNTyBhIHRhcmdldCByZWZyZXNo IG11c3QgYmUgaWdub3JlZCBpbiBhdCBsZWFzdCAqc29tZSoNCmNhc2VzIHdoZW4gPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyB0aGUgcmVxdWVzdCBpcyByZWplY3RlZC4gV2UgY291bGQgZW51bWVyYXRl IHRoZXNlIGNhc2VzDQo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGluZGl2aWR1YWxseSwgb3Igc2lt cGx5IHN0YXRlIHRoYXQgaXQgd2lsbCBvbmx5IGJlIGFjY2VwdGVkDQppZiB0aGUgPGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyByZXF1ZXN0IGlzIGFjY2VwdGVkLiAoSW4gY2FzZSBvZiByZUlOVklURSwg dGhhdCB3b3VsZA0KYmUgaWYgaXQgd2FzIDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgYWNjZXB0ZWQg c3VmZmljaWVudGx5IHRvIHJldHVybiBhIDJ4eCBvciBhIDF4eC4pPGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsgVGhpcyB3aWxsIGVuY291cmFnZSB1c2luZyBhICpz aW1wbGUqIHJlcXVlc3QgdG8gZG8gYW4NCmVzc2VudGlhbCA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 IHRhcmdldCByZWZyZXNoLCByYXRoZXIgdGhhbiBhIGNvbXBsZXggb25lIHRoYXQgaGFzIGEgY2hh bmNlDQpvZiA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7IGZhaWxpbmcuIFBlcmhhcHMgaXQgd29uJ3Qg d29yayBpbiBhbGwgY2FzZXMsIGJ1dCBzdWNoDQppcyBsaWZlLjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgVGhhbmtzLDxicj4NCiZndDsm Z3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyBQYXVsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyZndDsgR29uemFsbyBDYW1hcmlsbG8gd3JvdGU6PGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsgSGkgUGF1bCw8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IHRoYW5rcyBmb3IgeW91ciBjb21tZW50cy4gQW5zd2VycyBpbmxpbmU6 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBQYXVs IEt5eml2YXQgd3JvdGU6PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IEdvbnphbG8sPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IFRoYW5rcyBmb3IgZG9pbmcgdGhpcyB3b3JrISBJIGRvIGhhdmUgc29tZSBjb21tZW50czo8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsg U2VjdGlvbiAzL0ZpZ3VyZSAxPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0 OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBmaWd1cmUgc2hvd3MgYSA2eHggcmVzcG9uc2UuPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSB0ZXh0IHNheXMgdGhhdCB0aGUgVUFTIHdh bnRzIHRvIHJlamVjdCB0aGUNCm5ldyBvZmZlci48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQSBVQVMgd291bGQgcHJvYmFibHkgbm90 IHVzZSBhIDZ4eCByZXNwb25zZSB0bw0KcmVqZWN0IG1lZGlhLjxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyAoSSBndWVzcyBpdCBtaWdodCB1c2UgNjA2LCBidXQgNDg4IHdvdWxkIGJlIG1v cmUNCmFwcHJvcHJpYXRlLik8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSW4gZmFjdCwg aXQgcHJvYmFibHkgd291bGQgbm90IHJlamVjdCB0aGUgcmVxdWVzdA0KYXQgYWxsLCBidXQgPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJhdGhlciB3b3VsZCBqdXN0IHJlZnVzZSB0aGUg YWRkZWQgbWVkaWEgc3RyZWFtLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgcG9pbnQgYmVpbmcgbWFkZSBkb2Vzbid0IHJlcXVp cmUgdGhhdCB0aGUNCnJlc3BvbnNlIGJlIDZ4eCBvciA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgdGhhdCBpdCBiZSB3aXRoIHRoZSBwdXJwb3NlIG9mIHJlZnVzaW5nIHRoZSBtZWRpYS4N ClNvIEkgdGhpbmsgd2hhdCA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXMgbmVlZGVk IGhlcmUgaXMgdG8gZmluZCBhIHBsYXVzaWJsZSBleGFtcGxlDQp0byBtYWtlIHRoZSBwb2ludC48 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZn dDsgQSBnb29kIG9uZSBmb3IgdGhlIHB1cnBvc2UgaGVyZSBtaWdodCBiZSBhIDQ4OA0KdG8gcmVq ZWN0IHRoZSA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgbWVkaWEsIG9yIGEgJm5ic3A7 NDAxIHJlc3BvbnNlIGFzIGFub3RoZXIgc29ydA0Kb2YgcmVhc29uIGZvciByZWplY3RpbmcgPGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSB3aG9sZSB0aGluZyBidXQgd2FudGluZyB0 byBwcmVzZXJ2ZSB3aGF0IHRoZXJlDQppcy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHllcywgSSBhZ3JlZSB0aGF0IGEgNDg4IHJlc3BvbnNlIHdv dWxkIGJlIG1vcmUgYXBwcm9wcmlhdGUuDQpJIHdpbGwgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgY2hhbmdlIHRoYXQgaW4gdGhlIGRyYWZ0Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IFNlY3Rpb24gNTo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtBIGNoYW5nZSB0byB0aGUgc2Vzc2lvbiBz dGF0ZQ0KaXMgY29uc2lkZXJlZCB0byBoYXZlIGJlZW4gZXhlY3V0ZWQ8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDt3aGVuIHRoZSBuZXcgbWVkaWEgcGFyYW1l dGVycw0KYXJlIGJlaW5nIHVzZWQuICZuYnNwO1RoZXJlZm9yZSwgYSA8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNoYW5nZSB0bzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgJm5ic3A7ICZuYnNwO2Egc3RyZWFtIHN1YmplY3QgdG8gcHJlY29uZGl0aW9ucw0KW1JG QzQwMzJdIGlzIGNvbnNpZGVyZWQgdG8gaGF2ZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgJm5ic3A7ICZuYnNwO2JlZW4gZXhlY3V0ZWQgd2hlbiB0aGUgbmV3IG1lZGlhDQpwYXJh bWV0ZXJzIHN0YXJ0IGJlaW5nIHVzZWQ7IG5vdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgJm5ic3A7ICZuYnNwO3doZW4gdGhlIHByZWNvbmRpdGlvbnMgZm9yIHRoZQ0Kc3RyZWFt IGFyZSBtZXQuICZuYnNwOzxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgVW5zdXJw cmlzaW5nbHksIHRoZTxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZu YnNwO1VBUyBjb25zaWRlcnMgdGhlIG5ldyBwYXJhbWV0ZXJzDQp0byBiZSBpbiB1c2Ugd2hlbiBp dCBhY3R1YWxseSA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHN0YXJ0czxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwO3VzaW5nIHRoZW0uIDxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBJJ20gbm90IGVudGlyZWx5IGZvbGxvd2luZyB0aGlzLiBJIHRoaW5rIHRoZXJlDQptYXkgYmUg YW4gPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGFzc3VtcHRpb24gaGVyZSB0aGF0IHRo ZSBVQUMgaXMgdGhlIG9mZmVyZXIgYW5kDQp0aGUgVUFTIHRoZSA8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyZndDsgYW5zd2VyZXIuIEknbSBndWVzc2luZyB5b3UgYXJlIHNheWluZyB0aGF0IHRo ZQ0KYW5zd2VyZXIgY29uc2lkZXJzIDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aGUg bmV3IHBhcmFtZXRlcnMgdG8gYmUgaW4gdXNlIHdoZW4gaXQgYWN0dWFsbHkNCnN0YXJ0cyB1c2lu ZyB0aGVtLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBTaW5jZSB0aGlzIHNlY3Rpb24gaXMgYWJvdXQgdGhlIFVBUyAoZm9yIHRoZSBy ZWludml0ZSksDQp0aGlzIHBvaW50IDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpcyBw cm9iYWJseSB0aGF0IHdoZW4gdGhlIFVBUyBpcyBhbHNvIHRoZSBhbnN3ZXJlcg0KaXQgY2FuIGRl Y2lkZSA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgd2hlbiB0aGUgbmV3IG1lZGlhIGlz IGluIHVzZSBiYXNlZCBvbiB3aGVuIGl0DQpzdGFydHMgdXNpbmcgdGhlbS48YnI+DQomZ3Q7Jmd0 OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgQnV0IHdoYXQg aGFwcGVucyB3aGVuIHRoZSBVQVMgaXMgdGhlIG9mZmVyZXI/DQpJbiB0aGF0IGNhc2UgSSB0aGlu ayA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgaXQgbXVzdCBhc3N1bWUgdGhlIG1lZGlh IGlzIGluIHVzZSBhcyBzb29uIGFzDQppdCBpcyBvZmZlcmVkLiBCdXQgPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7IG1heWJlIHRoYXQgaXNuJ3QgYWx3YXlzIHRoZSBjYXNlIHdpdGggcHJl Y29uZGl0aW9ucy4NCkkgZG9uJ3QgdGhpbmsgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 IGl0IGNhbiB3YWl0IHRpbGwgaXQgcmVjZWl2ZXMgbWVkaWEsIGJlY2F1c2UgbWVkaWENCm1heSBi ZSBpbiBmbGlnaHQgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdoZW4gaXQgbWFrZXMg aXRzIGRlY2lzaW9uLjxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgeWVzLCB0aGUgZHJhZnQgYXNzdW1lcyB0aGF0IHRoZSBVQVMgaXMgdGhlIGFuc3dl cmVyDQpiZWNhdXNlIHRoYXQgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgd2FzIHRoZSB1c2Ug Y2FzZSBiZWluZyBkaXNjdXNzZWQgb3JpZ2luYWxseS4gSG93ZXZlciwNCnlvdSBhcmUgcmlnaHQg PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgdGhhdCB3ZSBzaG91bGQgYWxzbyBjb3ZlciB0aGUg Y2FzZSB3aGVyZSB0aGUgVUFTIGlzDQp0aGUgb2ZmZXJlci4gSSA8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyB3aWxsIGxvb2sgaW50byBpdCBhbmQgYWRkIHRleHQgYWJvdXQgaXQgaW4gdGhlIGRy YWZ0Ljxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7QXMgZGVz Y3JpYmVkIGluIFNlY3Rpb24gOC4zLjENCm9mIFJGQyAzMjY0IFtSRkMzMjY0XSwgdGhlPGJyPg0K Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7VUFDIGNvbnNpZGVycyB0 aGUgbmV3IHBhcmFtZXRlcnMNCnRvIGJlIGluIHVzZSB3aGVuIG1lZGlhIGlzIDxicj4NCiZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVjZWl2ZWQ8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDtpbiB0aGUgbmV3IHBvcnQsIHdoaWNoIHNob3VsZA0KYmUg aW50ZXJwcmV0ZWQgYXMgZm9sbG93czo8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyBS ZWNlaXZlZCwgaW4gdGhpcyBjYXNlLA0KbWVhbnMgdGhhdCB0aGUgbWVkaWEgaXMgcGFzc2VkIHRv IGEgPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBtZWRpYTxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgc2luay4gJm5ic3A7VGhp cyBtZWFucw0KdGhhdCBpZiB0aGVyZSBpcyBhIHBsYXlvdXQgYnVmZmVyLCB0aGUgYWdlbnQ8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IHdvdWxk IGNvbnRpbnVlIHRvIGxpc3Rlbg0Kb24gdGhlIG9sZCBwb3J0IHVudGlsIHRoZSBtZWRpYSBvbiA8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZTxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgbmV3IHBvcnQgcmVhY2hlZCB0aGUN CnRvcCBvZiB0aGUgcGxheW91dCBidWZmZXIuICZuYnNwO0F0IHRoYXQgPGJyPg0KJmd0OyZndDsm Z3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0aW1lLCBpdDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgTUFZIGNlYXNlIGxpc3RlbmluZyBmb3INCm1lZGlh IG9uIHRoZSBvbGQgcG9ydC48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyZndDsgSSBkb24ndCBrbm93IHdoYXQgdGhlIGFib3ZlIGhhcyB0byBk byB3aXRoIHRoZQ0KYmVoYXZpb3Igb2YgdGhlIFVBUy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFRoZSBVQUMgbmVlZHMgdG8ga25vdyB3aGVuIHRo ZSBuZXcgcGFyYW1ldGVycyBhcmUNCmluIHVzZSBpbiBvcmRlciA8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyB0byBpbXBsZW1lbnQgdGhlIG5vcm1hdGl2ZSBiZWhhdmlvciBpbiBTZWN0aW9uIDY6 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbmJz cDsgJm5ic3A7Li4uIGEgVUFDIHRoYXQgcmVjZWl2ZXMgYW4gZXJyb3IgcmVzcG9uc2UNCnRvIGEg cmUtSU5WSVRFIGZvciB3aGljaDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZuYnNwOyAmbmJz cDtjaGFuZ2VzIGhhdmUgYmVlbiBhbHJlYWR5IGV4ZWN1dGVkIC4uLjxicj4NCiZndDsmZ3Q7Jmd0 OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgSW4gYW55IGNhc2UsIEkgd2lsbCBj bGFyaWZ5IGFsbCB0aGlzIHdoZW4gSSB3cml0ZQ0KdGhlIHRleHQgYWJvdXQgPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgdGhlIFVBUyBiZWluZyB0aGUgb2ZmZXJlciBiZWNhdXNlIHRoaXMgdHlw ZSBvZiBiZWhhdmlvcg0KaGFzIHRvIGRvIDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdpdGgg YmVpbmcgdGhlIG9mZmVyZXIgb3IgdGhlIGFuc3dlcmVyLCBub3QgdGhlIFVBQw0Kb3IgdGhlIFVB Uy48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyA5LiAmbmJzcDtDbGFyaWZpY2F0aW9ucyBv biBUYXJnZXQgUmVmcmVzaA0KUmVxdWVzdHM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4N CiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoZSBjdXJyZW50IHRleHQgaXMgYSBzdHJhdyBtYW4gdGhh dCBwdXRzIHRhcmdldCByZWZyZXNoZXMNCmluIHRoZSA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBzYW1lIGNhdGVnb3J5IGFzIGFueSBvdGhlciBjaGFuZ2UuIFRoZSBvdGhlciBvcHRpb24NCndl IHRhbGtlZCBhYm91dCA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBpbiB0aGUgcGFzdCB3YXMg dG8gc3BlY2lhbCBjYXNlIHRoZW0gc28gdGhhdCB0aGV5DQphcmUgdHJlYXRlZCA8YnI+DQomZ3Q7 Jmd0OyZndDsmZ3Q7Jmd0OyBkaWZmZXJlbnRseS4gWW91IHNlZW0gdG8gbGlrZSB0aGUgbGF0dGVy IG9wdGlvbiBiZXR0ZXIuDQpXaGF0IGRvIHlvdSA8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyB0 aGluayBhYm91dCB0aGUgZm9sbG93aW5nIHRleHQ/PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8 YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDtz ZWN0aW9uIHRpdGxlPSZxdW90O0NsYXJpZmljYXRpb24gb24gdGhlIEF0b21pY2l0eQ0Kb2YgVGFy Z2V0IFJlZnJlc2ggPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgUmVxdWVzdHMmcXVvdDs8YnI+ DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBhbmNob3I9JnF1b3Q7c2VjLWF0b20mcXVvdDsmZ3Q7PGJy Pg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0O3QmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZn dDsgVGhlIHJlbW90ZSB0YXJnZXQgb2YgYSBkaWFsb2cgaXMgYSBzcGVjaWFsIHR5cGUgb2YNCnN0 YXRlIGluZm9ybWF0aW9uPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgYmVjYXVzZSBvZiBpdHMg ZXNzZW50aWFsIHJvbGUgaW4gdGhlIGV4Y2hhbmdlIG9mIFNJUA0KbWVzc2FnZXMgYmV0d2Vlbjxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IFVBcyBpbiBhIGRpYWxvZy4gQSBVQSBpbnZvbHZlZCBp biBhIGRpYWxvZyByZWNlaXZlcw0KdGhlIHJlbW90ZSB0YXJnZXQ8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBvZiB0aGUgZGlhbG9nIGZyb20gdGhlIHJlbW90ZSBVQS4gVGhlIFVBIHVzZXMgdGhl DQpyZW1vdGUgdGFyZ2V0IHRvPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgc2VuZCBTSVAgcmVx dWVzdHMgdG8gdGhlIHJlbW90ZSBVQS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7L3Qm Z3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0O3QmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7 Jmd0OyZndDsgVGhlIHJlbW90ZSB0YXJnZXQgaXMgYSBwaWVjZSBvZiBzdGF0ZSBpbmZvcm1hdGlv bg0KdGhhdCBpcyBub3QgbWVhbnQgdG88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBiZSBuZWdv dGlhdGVkLiBXaGVuIGEgVUFDIGNoYW5nZXMgaXRzIGFkZHJlc3MsIHRoZQ0KVUFDIHNpbXBseTxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IGNvbW11bmljYXRlcyBpdHMgbmV3IGFkZHJlc3MgdG8g dGhlIFVBUyBpbiBvcmRlciB0bw0KcmVtYWluIHJlYWNoYWJsZTxicj4NCiZndDsmZ3Q7Jmd0OyZn dDsmZ3Q7IGJ5IHRoZSBVQVMuIEFzIGRlc2NyaWJlZCBpbiAmbHQ7eHJlZiB0YXJnZXQ9JnF1b3Q7 c2VjLWJhY2stYXRvbSZxdW90Oy8mZ3Q7LA0KYSBVQVM8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyBzdGFydHMgdXNpbmcgdGhlIG5ldyByZW1vdGUgdGFyZ2V0IGFzIHNvb24gYXMgdGhlDQp0YXJn ZXQgcmVmcmVzaDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlcXVlc3QgaXMgcmVjZWl2ZWQs IHJlZ2FyZGxlc3Mgb2YgdGhlIHJlc3BvbnNlIHRoZQ0KVUFTIGdlbmVyYXRlcyB0bzxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHRoYXQgcmVxdWVzdC4gVGhhdCBpcywgZXZlbiBpZiB0aGUgVUFT IGdlbmVyYXRlcyBhbg0KZXJyb3IgcmVzcG9uc2UgdG88YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0 OyB0aGUgdGFyZ2V0IHJlZnJlc2ggcmVxdWVzdCwgdGhlIFVBUyBuZWVkcyB0byB1cGRhdGUNCnRo ZSBkaWFsb2cnczxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlbW90ZSB0YXJnZXQgVVJJLjxi cj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7ICZsdDsvdCZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7 Jmd0OyAmbHQ7dCZndDs8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBUaGUgZmFjdCB0aGF0IGEg dGFyZ2V0IHJlZnJlc2ggcmVxdWVzdCB1cGRhdGVzIHRoZQ0KcmVtb3RlIHRhcmdldDxicj4NCiZn dDsmZ3Q7Jmd0OyZndDsmZ3Q7IHJlZ2FyZGxlc3Mgb2YgdGhlIHJlc3BvbnNlIGl0IHRyaWdnZXJz IGltcGxpZXMgdGhhdA0KdGFyZ2V0IHJlZnJlc2g8YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyBy ZXF1ZXN0cyBhcmUgbm90IGF0b21pYy4gVGhhdCBpcywgYW4gZXJyb3IgcmVzcG9uc2UNCnRvIGEg dGFyZ2V0PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgcmVmcmVzaCByZXF1ZXN0IHdpbGwga2Vl cCBhbGwgY2hhbmdlcyBhc3NvY2lhdGVkIHRvDQp0aGUgcmVxdWVzdCBmcm9tPGJyPg0KJmd0OyZn dDsmZ3Q7Jmd0OyZndDsgYmVpbmcgcGVyZm9ybWVkIGV4Y2VwdCBmb3IgdGhlIHJlZnJlc2ggb2Yg dGhlIHJlbW90ZQ0KdGFyZ2V0LCB3aGljaDxicj4NCiZndDsmZ3Q7Jmd0OyZndDsmZ3Q7IHdpbGwg YmUgcGVyZm9ybWVkIGFueXdheS48YnI+DQomZ3Q7Jmd0OyZndDsmZ3Q7Jmd0OyAmbHQ7L3QmZ3Q7 PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDsgJmx0Oy9zZWN0aW9uJmd0Ozxicj4NCiZndDsmZ3Q7 Jmd0OyZndDsmZ3Q7PGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDsm Z3Q7Jmd0OyBDaGVlcnMsPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0OyZn dDsmZ3Q7Jmd0OyBHb256YWxvPGJyPg0KJmd0OyZndDsmZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7Jmd0 OyZndDs8YnI+DQomZ3Q7Jmd0OyZndDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KPGJyPg0K PC90dD48L2ZvbnQ+DQo8YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNw O1NlY3VyaXR5Jm5ic3A7Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29u dGFpbmVkJm5ic3A7aW4mbmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5i c3A7cHJvcGVydHkmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0 aW9uLiZuYnNwO1RoaXMmbmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7 Y29uZmlkZW50aWFsLiZuYnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7 YXJlJm5ic3A7b2JsaWdhdGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJz cDthbmQmbmJzcDthcmUmbmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Ns b3NlJm5ic3A7dGhlJm5ic3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5p Y2F0aW9uJm5ic3A7dG8mbmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJz cDthbnkmbmJzcDtmaWxlcyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7 YXJlJm5ic3A7Y29uZmlkZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkm bmJzcDtmb3ImbmJzcDt0aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1 YWwmbmJzcDtvciZuYnNwO2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDth cmUmbmJzcDthZGRyZXNzZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2 ZWQmbmJzcDt0aGlzJm5ic3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5i c3A7bm90aWZ5Jm5ic3A7dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7 bWVzc2FnZS4mbmJzcDtBbnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7 dGhpcyZuYnNwO21lc3NhZ2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5i c3A7aW5kaXZpZHVhbCZuYnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5i c3A7YmVlbiZuYnNwO3NjYW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7 U3BhbSZuYnNwO2J5Jm5ic3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 005D517748257600_=-- From adam@nostrum.com Tue Jul 28 00:45:22 2009 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 6D2E83A6B3A for ; Tue, 28 Jul 2009 00:45:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-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 ISLW8d9LhLpJ for ; Tue, 28 Jul 2009 00:45:21 -0700 (PDT) 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 5D68F3A6ABC for ; Tue, 28 Jul 2009 00:45:21 -0700 (PDT) Received: from dhcp-17f4.meeting.ietf.org (dhcp-17f4.meeting.ietf.org [130.129.23.244]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n6S7jHUi092506 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 02:45:19 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A6EAC8D.2080504@nostrum.com> Date: Tue, 28 Jul 2009 09:45:17 +0200 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Dean Willis References: <109101c9eae2$f8ef9890$eacec9b0$@net> <1EF42B19-CB00-48C3-9EF7-F15A36AE5CF7@estacado.net> <1244821160.3768.13.camel@victoria-pingtel-com.us.nortel.com> <85ED2F6F-EBAC-454D-858B-D3BFAF901CCA@estacado.net> <4A33F51F.7070405@softarmor.com> In-Reply-To: <4A33F51F.7070405@softarmor.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.23.244 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org, Byron Campen , Dale Worley Subject: Re: [sipcore] [Sipping] draft-niemi-sipcore-event-rate-control-00 and forcing notifications when state has not changed 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, 28 Jul 2009 07:45:22 -0000 Dean Willis wrote: > Byron Campen wrote: > > >> Indeed, this could be done with etag, and using etag is a far more >> efficient mechanism, because you are not gratuitously sending >> (potentially very large) documents. My main beef is that this shifts the >> job of maintaining soft-state to the server. As a general principle, >> this has been the client's job, and this is specifically how SIP events >> is supposed to work. Allowing the client to say, "Nah, you're going to >> handle recovery now." is a rather fundamental change to the protocol, >> that we should only make if there is a compelling reason. I see no such >> reason. >> >> > > I find this argument compelling. It might even be worth expounding on > this general concept in rfrc265bis. > I don't understand what you are proposing. Could you give an example of what such text would look like? /a From adam@nostrum.com Tue Jul 28 03:33:27 2009 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 02FF53A6DC4 for ; Tue, 28 Jul 2009 03:33:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-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 mPzsTyqR8Cjl for ; Tue, 28 Jul 2009 03:33:26 -0700 (PDT) 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 DD8183A6CDA for ; Tue, 28 Jul 2009 03:33:25 -0700 (PDT) Received: from dhcp-17f4.meeting.ietf.org (dhcp-17f4.meeting.ietf.org [130.129.23.244]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n6SAXLLo006951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 05:33:22 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A6ED3F1.4040104@nostrum.com> Date: Tue, 28 Jul 2009 12:33:21 +0200 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.23.244 is authenticated by a trusted mechanism) Subject: [sipcore] Call for Minute Takers 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, 28 Jul 2009 10:33:27 -0000 [as chair] To avoid my staring at you for several minutes at the beginning of the meeting, I'm soliciting two minute takers for the SIPCORE meeting this Friday. We only have three presentations, so it should be a fairly easy session to take notes for. If you're willing to help out, please send a note to me and Gonzalo. Thanks. /a From adam@nostrum.com Tue Jul 28 06:29:13 2009 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 AB5673A6BD1 for ; Tue, 28 Jul 2009 06:29:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-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 m+SJ9tl8g6dc for ; Tue, 28 Jul 2009 06:29:13 -0700 (PDT) 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 85EC43A6ADD for ; Tue, 28 Jul 2009 06:29:12 -0700 (PDT) Received: from dhcp-17f4.meeting.ietf.org (dhcp-17f4.meeting.ietf.org [130.129.23.244]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n6SDT8nN023795 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 28 Jul 2009 08:29:09 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A6EFD23.8090604@nostrum.com> Date: Tue, 28 Jul 2009 15:29:07 +0200 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: SIPCORE References: <4A6ED3F1.4040104@nostrum.com> In-Reply-To: <4A6ED3F1.4040104@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.23.244 is authenticated by a trusted mechanism) Subject: Re: [sipcore] Call for Minute Takers 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, 28 Jul 2009 13:29:13 -0000 A big thanks to Avshalom Houri and Eric Burger for signing up to be our victims^H^H^H^H^H^H^Hnote takers this time around. /a Adam Roach wrote: > [as chair] > > To avoid my staring at you for several minutes at the beginning of the > meeting, I'm soliciting two minute takers for the SIPCORE meeting this > Friday. We only have three presentations, so it should be a fairly > easy session to take notes for. > > If you're willing to help out, please send a note to me and Gonzalo. > Thanks. > > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From bcampen@estacado.net Tue Jul 28 06:53:01 2009 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 B60FE3A6D35 for ; Tue, 28 Jul 2009 06:53:01 -0700 (PDT) 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 MUjYFGLBE7hU for ; Tue, 28 Jul 2009 06:53:00 -0700 (PDT) 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 1C60F3A68DA for ; Tue, 28 Jul 2009 06:52:59 -0700 (PDT) Received: from dn3-233.estacado.net (dn3-233.estacado.net [172.16.3.233]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n6SDqw2b010983 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Jul 2009 08:52:58 -0500 (CDT) (envelope-from bcampen@estacado.net) Message-Id: <32A39E52-CD15-45AB-A3F4-15D7D654CFA2@estacado.net> From: Byron Campen To: Adam Roach In-Reply-To: <4A6EAC8D.2080504@nostrum.com> Content-Type: multipart/signed; boundary=Apple-Mail-2--100961679; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 28 Jul 2009 08:52:54 -0500 References: <109101c9eae2$f8ef9890$eacec9b0$@net> <1EF42B19-CB00-48C3-9EF7-F15A36AE5CF7@estacado.net> <1244821160.3768.13.camel@victoria-pingtel-com.us.nortel.com> <85ED2F6F-EBAC-454D-858B-D3BFAF901CCA@estacado.net> <4A33F51F.7070405@softarmor.com> <4A6EAC8D.2080504@nostrum.com> X-Mailer: Apple Mail (2.935.3) Cc: sipcore@ietf.org, Dale Worley Subject: Re: [sipcore] [Sipping] draft-niemi-sipcore-event-rate-control-00 and forcing notifications when state has not changed 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, 28 Jul 2009 13:53:01 -0000 --Apple-Mail-2--100961679 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit > Dean Willis wrote: >> Byron Campen wrote: >> >> >>> Indeed, this could be done with etag, and using etag is a far >>> more >>> efficient mechanism, because you are not gratuitously sending >>> (potentially very large) documents. My main beef is that this >>> shifts the >>> job of maintaining soft-state to the server. As a general principle, >>> this has been the client's job, and this is specifically how SIP >>> events >>> is supposed to work. Allowing the client to say, "Nah, you're >>> going to >>> handle recovery now." is a rather fundamental change to the >>> protocol, >>> that we should only make if there is a compelling reason. I see no >>> such >>> reason. >>> >>> >> >> I find this argument compelling. It might even be worth expounding on >> this general concept in rfrc265bis. >> > > I don't understand what you are proposing. Could you give an example > of what such text would look like? > > /a Basically, that the client should handle keepalives for soft state. Best regards, Byron Campen --Apple-Mail-2--100961679 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGZDCCAx0w ggKGoAMCAQICEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDkyMzA0MzgwNFoXDTA5MDkyMzA0Mzgw NFowazEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh bXBlbkBlc3RhY2Fkby5uZXQxIzAhBgkqhkiG9w0BCQEWFGRvY2ZhcmFkYXlAZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIGiyvzQgsqDjR3TiFTO4nkc/VRo/eX6xKu ky4CR2QtnIPEWhNLbU5UgXdGzU3YWx/cRj5alT0auKVQ/BnjCbf3bFSzP5mIfV6KlJV89dpxKQQA 3FaDYxE3whiRPIjQh3nmqxSacBTLohlt/g8MlFyiHoNs3XcH83M3QMjMxU8pD7SgXUDaXdtqC8vV +7g3rzPmlONdJ+4vac159wuZe37WVTsFI4sYL3p/KvqT1NZhmn1cmOVWKfCVAdGLk8VEUZtWuSeM NU5CLnFvenxaSPkDeVR5h0qDpw4DQyHfWXQuKvRs1WgVeHASz87EPgncyp90yiByetvE0WIBGKiz 0QIDAQABo0cwRTA1BgNVHREELjAsgRRiY2FtcGVuQGVzdGFjYWRvLm5ldIEUZG9jZmFyYWRheUBn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQANmDZo4t+1SrO9nb8KfjN4 QtlV1gzaAa2jEsAZ369PBXdsxVz32a1JIa1KudXFfMMxtF1NRDJ0Z3ib/qq+L8B28IpkYgRWtRr+ WWm6LzJ6rm1Q85cC0VSqoIRr+NoRZjaBdqWbJC4QsPnwVSXN9jLMLkFkjcxVDSxQtEx6v1PF9zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRp bmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUP SAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0Eu Y3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2f Ni/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH 1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQW7SrCyoCwnsms5MfcqmjmzAJBgUr DgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA3 MjgxMzUyNTRaMCMGCSqGSIb3DQEJBDEWBBRsvKPCWdC4eZhLtbjoo4BXP/xooDCBhQYJKwYBBAGC NxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsq AsJ7JrOTH3Kpo5swgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEBBQAEggEAQz8r 1zLaHgth1wmBZKeRYkIn6LehRxNSHfWTt7ZhTPEuJbUUCf7Tvh3EvvXKTa80daRVl2zbAKm8s2FC 2pzbzGleI2fBevYb59C79Y/kS11LksLG4BpYpFZLhEwQC4ptWDvjycCodu9ACnTVu4EKsuO47v6q vfB45UUPTVvPBqF784Yt985tmWF/Y1Mt7DJFtann6pEqOO4ptQckWxGq0DGEnCqFjjGomBw9jkIe GMCsyoNCvy7MjnFrJIOPxI9E7MdihAnDIt+7nLU6gFGGJbl9WCcqj9adQhflMlgkSq4KNMAi7SxL p29+ofXoJFz+CGHqMKfPa5yGHC3sEZzOsgAAAAAAAA== --Apple-Mail-2--100961679-- From gonzalo.camarillo@ericsson.com Tue Jul 28 06:57:12 2009 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 95A643A6C1A for ; Tue, 28 Jul 2009 06:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.262 X-Spam-Level: X-Spam-Status: No, score=-5.262 tagged_above=-999 required=5 tests=[AWL=0.987, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 zs3ovoP3mfYg for ; Tue, 28 Jul 2009 06:57:11 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 6426E3A68DA for ; Tue, 28 Jul 2009 06:57:11 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9dae00000519d-a8-4a6f03a17f93 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 86.55.20893.1A30F6A4; Tue, 28 Jul 2009 15:56:49 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 15:56:49 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 15:56:49 +0200 Received: from [131.160.126.137] (rvi2-126-137.lmf.ericsson.se [131.160.126.137]) by mail.lmf.ericsson.se (Postfix) with ESMTP id E68F92537; Tue, 28 Jul 2009 16:56:48 +0300 (EEST) Message-ID: <4A6F03A0.6000604@ericsson.com> Date: Tue, 28 Jul 2009 15:56:48 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Christer Holmberg References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com><4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com><4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> <4A6DA26F.7060205@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2009 13:56:49.0256 (UTC) FILETIME=[409FB680:01CA0F8B] X-Brightmail-Tracker: AAAAAA== Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 28 Jul 2009 13:57:12 -0000 Hi Christer, > In general I am ok with the rules, but we may need to think a little > about UNreliable provisional responses. > > For example, if a UAC sends an (re-)INVITE, and receives an UNreliable > 18x, isn't there then an early dialog created in the UAC-to-UAS > direction, and the UAC can start sending in-dialog messages towards the > UAS at that point? > > So, the question is: does an unreliable response update the remote > target, or where will the UAC send those in-dialog messages? In your example, the re-INVITE is a target refresh request. That means that the UAC can change its location. However, the UAC continues using the UAS's location to send requests... and the UAS's location cannot be changed with an unreliable response (only reliable responses can refresh the target; we may need to stress this point so that it is clear). Therefore, your example can be handled easily. A more interesting example would be one where the UAC sends a re-INVITE updating the target (i.e., the UAC's location) and the UAS (which does not support reliable provisional responses) sends a request to the UAC using the new target. I think we should add a rule that requests coming from the remote UA that use the new target confirm that the target has been refreshed. > I think we need to say something about that there may be cases where a > re-registration is also needed. sure, we can mention this, although it is not directly related to the target refresh procedure... but I agree it will be a good idea to mention it in the draft. Thanks for your comments, Gonzalo From christer.holmberg@ericsson.com Tue Jul 28 07:18:04 2009 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 35C333A6EF3 for ; Tue, 28 Jul 2009 07:18:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.493 X-Spam-Level: X-Spam-Status: No, score=-5.493 tagged_above=-999 required=5 tests=[AWL=0.756, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 6LCqG5tJkbnt for ; Tue, 28 Jul 2009 07:18:03 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 320ED3A6FB4 for ; Tue, 28 Jul 2009 07:18:03 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9dae00000519d-66-4a6f0890ecd0 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 80.67.20893.0980F6A4; Tue, 28 Jul 2009 16:17:52 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 16:17:52 +0200 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, 28 Jul 2009 16:17:51 +0200 Message-ID: In-Reply-To: <4A6F03A0.6000604@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] New revision of the re-INVITE handling draft Thread-Index: AcoPi0FA9k+uubXyRTK5HWn5LKjJNQAAlLeQ References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com><4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com><4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> <4A6DA26F.7060205@ericsson.com> <4A6F03A0.6000604@ericsson.com> From: "Christer Holmberg" To: "Gonzalo Camarillo" X-OriginalArrivalTime: 28 Jul 2009 14:17:52.0295 (UTC) FILETIME=[31742B70:01CA0F8E] X-Brightmail-Tracker: AAAAAA== Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 28 Jul 2009 14:18:04 -0000 Hi,=20 >>I think we need to say something about that there may be cases where a re-registration is also needed. > >sure, we can mention this, although it is not directly related to the target refresh procedure... but I agree it will be=20 >a good idea to mention it in the draft. In fact, I think the client will have to re-register very often. For example, if the client has registered its previous IP address it needs to re-register the new IP address. Otherwise it will not receive incoming calls, since the registrar will forward those towards the old address... I do agree it is not directly relatd to target refresh, but IF we want to have text about the case where the IP address is lost I think it is important to mention. Regards, Christer From gonzalo.camarillo@ericsson.com Tue Jul 28 07:29:07 2009 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 CFE0C3A6F8D for ; Tue, 28 Jul 2009 07:29:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.287 X-Spam-Level: X-Spam-Status: No, score=-3.287 tagged_above=-999 required=5 tests=[AWL=-1.038, BAYES_00=-2.599, HELO_EQ_SE=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 l43fL4U9-zGn for ; Tue, 28 Jul 2009 07:29:07 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id B60763A6E5E for ; Tue, 28 Jul 2009 07:29:06 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-70-4a6f0b32a583 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id B5.C8.18827.23B0F6A4; Tue, 28 Jul 2009 16:29:06 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 16:28:31 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 16:28:31 +0200 Received: from [131.160.126.137] (rvi2-126-137.lmf.ericsson.se [131.160.126.137]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B4EB72537; Tue, 28 Jul 2009 17:28:30 +0300 (EEST) Message-ID: <4A6F0B0E.4060703@ericsson.com> Date: Tue, 28 Jul 2009 16:28:30 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Christer Holmberg References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com><4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com><4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> <4A6DA26F.7060205@ericsson.com> <4A6F03A0.6000604@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2009 14:28:31.0396 (UTC) FILETIME=[AE633E40:01CA0F8F] X-Brightmail-Tracker: AAAAAA== Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 28 Jul 2009 14:29:07 -0000 Hi, OK, we seem to have reached agreement on how to proceed. I will revise the draft taking into account Paul's original comments and specifying the rules I proposed for target refresh together with the additions to address Christer's last comments. Cheers, Gonzalo Christer Holmberg wrote: > Hi, > >>> I think we need to say something about that there may be cases where a > re-registration is also needed. >> sure, we can mention this, although it is not directly related to the > target refresh procedure... but I agree it will be >> a good idea to mention it in the draft. > > In fact, I think the client will have to re-register very often. For > example, if the client has registered its previous IP address it needs > to re-register the new IP address. Otherwise it will not receive > incoming calls, since the registrar will forward those towards the old > address... > > I do agree it is not directly relatd to target refresh, but IF we want > to have text about the case where the IP address is lost I think it is > important to mention. > > Regards, > > Christer > > From adam@nostrum.com Tue Jul 28 07:35:28 2009 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 BFB553A6EF3 for ; Tue, 28 Jul 2009 07:35:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-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 1YtdKRgd14hg for ; Tue, 28 Jul 2009 07:35:28 -0700 (PDT) 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 962613A6FBE for ; Tue, 28 Jul 2009 07:35:27 -0700 (PDT) Received: from dhcp-17f4.meeting.ietf.org (dhcp-17f4.meeting.ietf.org [130.129.23.244]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n6SEZKe6029046 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 28 Jul 2009 09:35:22 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4A6F0CA8.4020307@nostrum.com> Date: Tue, 28 Jul 2009 16:35:20 +0200 From: Adam Roach User-Agent: Thunderbird 2.0.0.22 (Macintosh/20090605) MIME-Version: 1.0 To: Byron Campen References: <109101c9eae2$f8ef9890$eacec9b0$@net> <1EF42B19-CB00-48C3-9EF7-F15A36AE5CF7@estacado.net> <1244821160.3768.13.camel@victoria-pingtel-com.us.nortel.com> <85ED2F6F-EBAC-454D-858B-D3BFAF901CCA@estacado.net> <4A33F51F.7070405@softarmor.com> <4A6EAC8D.2080504@nostrum.com> <32A39E52-CD15-45AB-A3F4-15D7D654CFA2@estacado.net> In-Reply-To: <32A39E52-CD15-45AB-A3F4-15D7D654CFA2@estacado.net> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.23.244 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org, Dale Worley Subject: Re: [sipcore] [Sipping] draft-niemi-sipcore-event-rate-control-00 and forcing notifications when state has not changed 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, 28 Jul 2009 14:35:28 -0000 [as individual participant] Byron Campen wrote: >> Dean Willis wrote: >>> Byron Campen wrote: >>> >>> >>>> Indeed, this could be done with etag, and using etag is a far more >>>> efficient mechanism, because you are not gratuitously sending >>>> (potentially very large) documents. My main beef is that this >>>> shifts the >>>> job of maintaining soft-state to the server. As a general principle, >>>> this has been the client's job, and this is specifically how SIP >>>> events >>>> is supposed to work. Allowing the client to say, "Nah, you're going to >>>> handle recovery now." is a rather fundamental change to the protocol, >>>> that we should only make if there is a compelling reason. I see no >>>> such >>>> reason. >>>> >>>> >>> >>> I find this argument compelling. It might even be worth expounding on >>> this general concept in rfrc265bis. >>> >> >> I don't understand what you are proposing. Could you give an example >> of what such text would look like? >> >> /a > > Basically, that the client should handle keepalives for soft state. I get that, but I don't see where that indicates any changes to the document. I'll be more blunt: if you have an idea for something you'd like to see added to RFC3265bis, send the literal text you'd like to see included in the document, and an extremely precise pointer to where you'd like to see it inserted. I'll take xml2rfc format or plain text. /a From christer.holmberg@ericsson.com Tue Jul 28 07:35:58 2009 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 623563A7023 for ; Tue, 28 Jul 2009 07:35:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.547 X-Spam-Level: X-Spam-Status: No, score=-5.547 tagged_above=-999 required=5 tests=[AWL=0.702, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 bvDhw2zibx45 for ; Tue, 28 Jul 2009 07:35:57 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 298CD3A6EF3 for ; Tue, 28 Jul 2009 07:35:56 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9dae00000519d-3a-4a6f0ccd93c9 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 8B.29.20893.DCC0F6A4; Tue, 28 Jul 2009 16:35:57 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 16:35:52 +0200 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, 28 Jul 2009 16:35:50 +0200 Message-ID: In-Reply-To: <4A6F03A0.6000604@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] New revision of the re-INVITE handling draft Thread-Index: AcoPi0FA9k+uubXyRTK5HWn5LKjJNQAAxU0Q References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com><4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com><4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> <4A6DA26F.7060205@ericsson.com> <4A6F03A0.6000604@ericsson.com> From: "Christer Holmberg" To: "Gonzalo Camarillo" X-OriginalArrivalTime: 28 Jul 2009 14:35:52.0813 (UTC) FILETIME=[B57E21D0:01CA0F90] X-Brightmail-Tracker: AAAAAA== Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 28 Jul 2009 14:35:58 -0000 Hi, >>In general I am ok with the rules, but we may need to think a little=20 >>about UNreliable provisional responses. >>=20 >>For example, if a UAC sends an (re-)INVITE, and receives an UNreliable >>18x, isn't there then an early dialog created in the UAC-to-UAS=20 >>direction, and the UAC can start sending in-dialog messages towards=20 >>the UAS at that point? >>=20 >>So, the question is: does an unreliable response update the remote=20 >>target, or where will the UAC send those in-dialog messages? > >In your example, the re-INVITE is a target refresh request. That means that the UAC can change its location. However, the=20 >UAC continues using the UAS's location to send requests... and the UAS's location cannot be changed with an unreliable=20 >response (only reliable responses can refresh the target; we may need to stress this point so that it is clear).=20 I would be happy if that would be the case, but we need to discuss whether it really is the case. As I said, for an initial INVITE I believe an unreliable response can create an early dialog in the UAC-to-UAS direction, which means that if the unreliable response contains a remote target (Contact header) it will be used by the UAC for in-dialog messages. So, unless I am wrong we would say that it is possible to provide the remote target unreliably for an initial INVITE, but it is not possible to update it unreliably for a re-INVITE. >Therefore, your example can be handled easily. > >A more interesting example would be one where the UAC sends a re-INVITE updating the target (i.e., the UAC's location)=20 >and the UAS (which does not support reliable provisional responses) sends a request to the UAC using the new target. > >I think we should add a rule that requests coming from the remote UA that use the new target confirm that the target has >been refreshed. Yes. Regards, Christer From gonzalo.camarillo@ericsson.com Tue Jul 28 07:38:18 2009 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 E47B73A702D for ; Tue, 28 Jul 2009 07:38:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.261 X-Spam-Level: X-Spam-Status: No, score=-5.261 tagged_above=-999 required=5 tests=[AWL=0.988, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 4349cA15+bTd for ; Tue, 28 Jul 2009 07:38:18 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id DFEF93A6FD0 for ; Tue, 28 Jul 2009 07:38:17 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9dae00000519d-37-4a6f0d5985ac Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 00.89.20893.A5D0F6A4; Tue, 28 Jul 2009 16:38:18 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 16:38:17 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 16:38:17 +0200 Received: from [131.160.126.137] (rvi2-126-137.lmf.ericsson.se [131.160.126.137]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1628E2553; Tue, 28 Jul 2009 17:38:17 +0300 (EEST) Message-ID: <4A6F0D58.5090009@ericsson.com> Date: Tue, 28 Jul 2009 16:38:16 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Christer Holmberg References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com><4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com><4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> <4A6DA26F.7060205@ericsson.com> <4A6F03A0.6000604@ericsson.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2009 14:38:17.0412 (UTC) FILETIME=[0BAE3040:01CA0F91] X-Brightmail-Tracker: AAAAAA== Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 28 Jul 2009 14:38:19 -0000 Hi Christer, > So, unless I am wrong we would say that it is possible to provide the > remote target unreliably for an initial INVITE, but it is not possible > to update it unreliably for a re-INVITE. yes, that is what I said in my previous email. We are in agreement. An unreliable response cannot refresh a target. Thanks, Gonzalo From pkyzivat@cisco.com Tue Jul 28 07:54:59 2009 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 D7EC53A6CF4 for ; Tue, 28 Jul 2009 07:54:59 -0700 (PDT) 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 uBS3ECBFJQSn for ; Tue, 28 Jul 2009 07:54:58 -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 D77993A696E for ; Tue, 28 Jul 2009 07:54:58 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAJuubkqrR7PE/2dsb2JhbAC8W4gnj3MFhAw X-IronPort-AV: E=Sophos;i="4.43,283,1246838400"; d="scan'208";a="355552223" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 28 Jul 2009 14:54:57 +0000 Received: from sj-core-2.cisco.com (sj-core-2.cisco.com [171.71.177.254]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n6SEsvj0025185; Tue, 28 Jul 2009 07:54:57 -0700 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6SEshFQ011218; Tue, 28 Jul 2009 14:54:57 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 10:54:57 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 10:54:56 -0400 Message-ID: <4A6F1140.3010704@cisco.com> Date: Tue, 28 Jul 2009 10:54:56 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com><4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com><4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> <4A6DA26F.7060205@ericsson.com> <4A6F03A0.6000604@ericsson.com> In-Reply-To: <4A6F03A0.6000604@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2009 14:54:56.0847 (UTC) FILETIME=[5F63DDF0:01CA0F93] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2137; t=1248792897; x=1249656897; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20New=20revision=20of=20the=2 0re-INVITE=20handling=20draft |Sender:=20; bh=OfwuumRKsp5fjZqSpigHdaDPBxddjeqHJ0RSx9TZdjo=; b=URjj5xm5WKHQWhiI2vSN+un9gVskmUpLYQbVFSh/zngYD20pZiINQpDKl4 M/HNBIQE9ENC+8OIQvJwZ/NVdH7I60MsO8IQEuy5VosbJUzbHXpeNK6/xum7 PdBlNC8x+D; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 28 Jul 2009 14:54:59 -0000 Gonzalo Camarillo wrote: > Hi Christer, > >> In general I am ok with the rules, but we may need to think a little >> about UNreliable provisional responses. >> For example, if a UAC sends an (re-)INVITE, and receives an UNreliable >> 18x, isn't there then an early dialog created in the UAC-to-UAS >> direction, and the UAC can start sending in-dialog messages towards the >> UAS at that point? >> >> So, the question is: does an unreliable response update the remote >> target, or where will the UAC send those in-dialog messages? > > In your example, the re-INVITE is a target refresh request. That means > that the UAC can change its location. However, the UAC continues using > the UAS's location to send requests... and the UAS's location cannot be > changed with an unreliable response (only reliable responses can refresh > the target; we may need to stress this point so that it is clear). > Therefore, your example can be handled easily. Agree. > A more interesting example would be one where the UAC sends a re-INVITE > updating the target (i.e., the UAC's location) and the UAS (which does > not support reliable provisional responses) sends a request to the UAC > using the new target. > > I think we should add a rule that requests coming from the remote UA > that use the new target confirm that the target has been refreshed. Pragmatically this makes sense. Its a little like a NOTIFY establishing a new dialog. But it can only be a *successful* request. If the request is rejected (e.g. 401) then it is not a confirmation. >> I think we need to say something about that there may be cases where a >> re-registration is also needed. > > sure, we can mention this, although it is not directly related to the > target refresh procedure... but I agree it will be a good idea to > mention it in the draft. This is a sensitive area. IETF has never embraced the linkage of REGISTER to ongoing sessions. I don't think this is the time. That is really an IMS convention. I'd be inclined to leave it to them to address in their specs. Thanks, Paul From gonzalo.camarillo@ericsson.com Tue Jul 28 08:03:23 2009 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 C79FB3A6FFC for ; Tue, 28 Jul 2009 08:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.285 X-Spam-Level: X-Spam-Status: No, score=-3.285 tagged_above=-999 required=5 tests=[AWL=-1.036, BAYES_00=-2.599, HELO_EQ_SE=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 c5kJO2LkOXu7 for ; Tue, 28 Jul 2009 08:03:23 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id A66EE3A6FDB for ; Tue, 28 Jul 2009 08:03:22 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-be-4a6f133a7c86 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 5C.0C.18827.A331F6A4; Tue, 28 Jul 2009 17:03:22 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 17:02:00 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 17:01:59 +0200 Received: from [131.160.126.137] (rvi2-126-137.lmf.ericsson.se [131.160.126.137]) by mail.lmf.ericsson.se (Postfix) with ESMTP id B82112537; Tue, 28 Jul 2009 18:01:59 +0300 (EEST) Message-ID: <4A6F12E7.8000103@ericsson.com> Date: Tue, 28 Jul 2009 17:01:59 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Paul Kyzivat References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com><4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com><4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> <4A6DA26F.7060205@ericsson.com> <4A6F03A0.6000604@ericsson.com> <4A6F1140.3010704@cisco.com> In-Reply-To: <4A6F1140.3010704@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2009 15:02:00.0042 (UTC) FILETIME=[5BA24CA0:01CA0F94] X-Brightmail-Tracker: AAAAAA== Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 28 Jul 2009 15:03:23 -0000 Hi, > Pragmatically this makes sense. > Its a little like a NOTIFY establishing a new dialog. > > But it can only be a *successful* request. If the request is rejected > (e.g. 401) then it is not a confirmation. if the UAS wants to authenticate the re-INVITE, it would return a 401 right away. The UAS only refreshes the remote target and, thus, sends a request to the new location of the UAC, if it decides that the re-INVITE was authenticated. Of course, the re-INVITE could be rejected later because of a different reason (e.g., a 488). That would not rollback the target refresh, as we have agreed. > This is a sensitive area. IETF has never embraced the linkage of > REGISTER to ongoing sessions. I don't think this is the time. > > That is really an IMS convention. I'd be inclined to leave it to them to > address in their specs. That is why I said that it is not directly related to the target refresh issue. When talking about a user agent that loses its IP address, we can mention that it may want to re-register, but I intend to simply mention it very briefly without any normative behavior. I am happy either way (talking or not taking about it), but I fully agree that we do not want to specify anything new in this area. Thanks, Gonzalo From pkyzivat@cisco.com Tue Jul 28 08:22:56 2009 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 C80233A7067 for ; Tue, 28 Jul 2009 08:22:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.475 X-Spam-Level: X-Spam-Status: No, score=-6.475 tagged_above=-999 required=5 tests=[AWL=0.124, 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 Dqiz7FybxmW0 for ; Tue, 28 Jul 2009 08:22:55 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id AFE1A3A7063 for ; Tue, 28 Jul 2009 08:22:55 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAO+0bkpAZnmf/2dsb2JhbAC9H4gnj3gFhAw X-IronPort-AV: E=Sophos;i="4.43,283,1246838400"; d="scan'208";a="220176459" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 28 Jul 2009 15:22:56 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6SFMuNe014687; Tue, 28 Jul 2009 11:22:56 -0400 Received: from xbh-rtp-201.amer.cisco.com (xbh-rtp-201.cisco.com [64.102.31.12]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6SFMuqp011288; Tue, 28 Jul 2009 15:22:56 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 11:22:56 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 11:22:56 -0400 Message-ID: <4A6F17CF.1000505@cisco.com> Date: Tue, 28 Jul 2009 11:22:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com><4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com><4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> <4A6DA26F.7060205@ericsson.com> <4A6F03A0.6000604@ericsson.com> <4A6F0D58.5090009@ericsson.com> In-Reply-To: <4A6F0D58.5090009@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2009 15:22:56.0060 (UTC) FILETIME=[48476FC0:01CA0F97] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=826; t=1248794576; x=1249658576; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20New=20revision=20of=20the=2 0re-INVITE=20handling=20draft |Sender:=20 |To:=20Gonzalo=20Camarillo=20; bh=MdjGAZADn0jVnKiDckDfeDUtWrkDA3lYZRueee4dGRQ=; b=wC36diTFA3n/PWmdhGpvSyt7GwGEX3/ZzQiGxDupd8IloRpl7wjPxmzyNk zw04Ecuk76pRntqjqMjBt8HtyHsH0YsjXVVJpnIiraAJee7LDOVkGfZbAZPt Nc8dYlU7Cx; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 28 Jul 2009 15:22:56 -0000 Gonzalo Camarillo wrote: > Hi Christer, > >> So, unless I am wrong we would say that it is possible to provide the >> remote target unreliably for an initial INVITE, but it is not possible >> to update it unreliably for a re-INVITE. > > yes, that is what I said in my previous email. We are in agreement. An > unreliable response cannot refresh a target. Hmm... That means that the UAC of a reINVITE, when it receives an unreliable response with a new target, MUST NOT refresh the target at that time? That will certainly make the code inconsistent with what is implemented for the initial INVITE. And probably break a lot of implementations. I'm not certain one way or the other on this. My inclination is that it can refresh the target, but the UAS won't know if it has. Thanks, Paul From pkyzivat@cisco.com Tue Jul 28 08:25:05 2009 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 C6A003A706A for ; Tue, 28 Jul 2009 08:25:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.482 X-Spam-Level: X-Spam-Status: No, score=-6.482 tagged_above=-999 required=5 tests=[AWL=0.117, 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 JEItadPZwNeM for ; Tue, 28 Jul 2009 08:25:04 -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 757F23A706E for ; Tue, 28 Jul 2009 08:25:04 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEADW1bkqrR7PD/2dsb2JhbAC9IIgnj3gFhAw X-IronPort-AV: E=Sophos;i="4.43,283,1246838400"; d="scan'208";a="87844589" Received: from sj-dkim-3.cisco.com ([171.71.179.195]) by sj-iport-5.cisco.com with ESMTP; 28 Jul 2009 15:25:06 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-3.cisco.com (8.12.11/8.12.11) with ESMTP id n6SFP6tu032071; Tue, 28 Jul 2009 08:25:06 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6SFP1XS002881; Tue, 28 Jul 2009 15:25:05 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 11:25:02 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 11:25:02 -0400 Message-ID: <4A6F184D.9050106@cisco.com> Date: Tue, 28 Jul 2009 11:25:01 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com><4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com><4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> <4A6DA26F.7060205@ericsson.com> <4A6F03A0.6000604@ericsson.com> <4A6F1140.3010704@cisco.com> <4A6F12E7.8000103@ericsson.com> In-Reply-To: <4A6F12E7.8000103@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2009 15:25:02.0089 (UTC) FILETIME=[9365EF90:01CA0F97] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1538; t=1248794706; x=1249658706; c=relaxed/simple; s=sjdkim3002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20New=20revision=20of=20the=2 0re-INVITE=20handling=20draft |Sender:=20; bh=hylBs9ABLSfK9fDDX2Y1dnGUlSb+LgfNRYDW9e3zexU=; b=eEZwJBFWvA1kFJBH8VhSG8sPyesu9eVgOx1py5CUYkGXCS6Ns37mBeHt4Q 3JxH39U+xdWwg6LHz9Wup/XCJAfVpWoFkaEE8pgAEFN8Ft0JzHwAdPupzAck 1fUIgnGEyb; Authentication-Results: sj-dkim-3; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim3002 verified; ); Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 28 Jul 2009 15:25:05 -0000 Gonzalo Camarillo wrote: > Hi, > >> Pragmatically this makes sense. >> Its a little like a NOTIFY establishing a new dialog. >> >> But it can only be a *successful* request. If the request is rejected >> (e.g. 401) then it is not a confirmation. > > if the UAS wants to authenticate the re-INVITE, it would return a 401 > right away. The UAS only refreshes the remote target and, thus, sends a > request to the new location of the UAC, if it decides that the re-INVITE > was authenticated. > > Of course, the re-INVITE could be rejected later because of a different > reason (e.g., a 488). That would not rollback the target refresh, as we > have agreed. > >> This is a sensitive area. IETF has never embraced the linkage of >> REGISTER to ongoing sessions. I don't think this is the time. >> >> That is really an IMS convention. I'd be inclined to leave it to them >> to address in their specs. > > That is why I said that it is not directly related to the target refresh > issue. When talking about a user agent that loses its IP address, we can > mention that it may want to re-register, but I intend to simply mention > it very briefly without any normative behavior. OK. I'm fine with *that*. It may also want to refresh any other dialogs it has established, such as subscriptions. Thanks, Paul > I am happy either way (talking or not taking about it), but I fully > agree that we do not want to specify anything new in this area. > > Thanks, > > Gonzalo > > From christer.holmberg@ericsson.com Tue Jul 28 08:26:58 2009 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 583A13A707B for ; Tue, 28 Jul 2009 08:26:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.594 X-Spam-Level: X-Spam-Status: No, score=-3.594 tagged_above=-999 required=5 tests=[AWL=-1.345, BAYES_00=-2.599, HELO_EQ_SE=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 sZsPD2J9RvYO for ; Tue, 28 Jul 2009 08:26:57 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 5AD6B3A7066 for ; Tue, 28 Jul 2009 08:26:57 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-90-4a6f18c11bdd Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 87.5E.18827.1C81F6A4; Tue, 28 Jul 2009 17:26:57 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 17:25:47 +0200 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, 28 Jul 2009 17:25:46 +0200 Message-ID: In-Reply-To: <4A6F12E7.8000103@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] New revision of the re-INVITE handling draft Thread-Index: AcoPlFuWYwil1Kv1QPCbCibvLa8nSAAAmpUA References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com><4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com><4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> <4A6DA26F.7060205@ericsson.com> <4A6F03A0.6000604@ericsson.com> <4A6F1140.3010704@cisco.com> <4A6F12E7.8000103@ericsson.com> From: "Christer Holmberg" To: "Gonzalo Camarillo" , "Paul Kyzivat" X-OriginalArrivalTime: 28 Jul 2009 15:25:47.0671 (UTC) FILETIME=[AE913270:01CA0F97] X-Brightmail-Tracker: AAAAAA== Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 28 Jul 2009 15:26:58 -0000 Hi,=20 >>This is a sensitive area. IETF has never embraced the linkage of REGISTER to ongoing sessions. I don't think this is the >>time. >=20 >>That is really an IMS convention. I'd be inclined to leave it to them to address in their specs. If you loose your address, and you have registered your old address, you need to register your new address in order to receive incoming calls (and to make things like outbound to work). I see nothing IMS specific in that... But, I agree with you that we should not start specifying new procedures which are not directly related to target refresh. I only ask for a statement which indicates that a re-registration may be needed in the case of IP address loss.=20 Regards, Christer From gonzalo.camarillo@ericsson.com Tue Jul 28 08:27:31 2009 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 D9EEE3A7083 for ; Tue, 28 Jul 2009 08:27:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.261 X-Spam-Level: X-Spam-Status: No, score=-5.261 tagged_above=-999 required=5 tests=[AWL=0.988, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 uBrW9fmuBI+i for ; Tue, 28 Jul 2009 08:27:31 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id B11F43A707B for ; Tue, 28 Jul 2009 08:27:30 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9dae00000519d-24-4a6f18e2d713 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 8F.8E.20893.2E81F6A4; Tue, 28 Jul 2009 17:27:30 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 17:27:30 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 17:27:30 +0200 Received: from [131.160.126.137] (rvi2-126-137.lmf.ericsson.se [131.160.126.137]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 26CE32537; Tue, 28 Jul 2009 18:27:30 +0300 (EEST) Message-ID: <4A6F18E1.5070408@ericsson.com> Date: Tue, 28 Jul 2009 17:27:29 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Paul Kyzivat References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com><4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com><4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> <4A6DA26F.7060205@ericsson.com> <4A6F03A0.6000604@ericsson.com> <4A6F0D58.5090009@ericsson.com> <4A6F17CF.1000505@cisco.com> In-Reply-To: <4A6F17CF.1000505@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2009 15:27:30.0652 (UTC) FILETIME=[EBF2D9C0:01CA0F97] X-Brightmail-Tracker: AAAAAA== Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 28 Jul 2009 15:27:31 -0000 Hi, answers inline: Paul Kyzivat wrote: > > > Gonzalo Camarillo wrote: >> Hi Christer, >> >>> So, unless I am wrong we would say that it is possible to provide the >>> remote target unreliably for an initial INVITE, but it is not possible >>> to update it unreliably for a re-INVITE. >> >> yes, that is what I said in my previous email. We are in agreement. An >> unreliable response cannot refresh a target. > > Hmm... > > That means that the UAC of a reINVITE, when it receives an unreliable > response with a new target, MUST NOT refresh the target at that time? > > That will certainly make the code inconsistent with what is implemented > for the initial INVITE. And probably break a lot of implementations. > > I'm not certain one way or the other on this. My inclination is that it > can refresh the target, but the UAS won't know if it has. yes, that is the problem. If we let unreliable responses change things, the UAS is not aware if the UAC received them or not. So, if the UAS later sends a 4xx for the re-INVITE, it does not know if the UAC has refreshed the target (if the UAC received the response) or not (if the UAC did not receive it). We would be creating a mechanism that gets UAs out of sync. Cheers, Gonzalo From gonzalo.camarillo@ericsson.com Tue Jul 28 08:30:16 2009 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 C6E183A7058 for ; Tue, 28 Jul 2009 08:30:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.284 X-Spam-Level: X-Spam-Status: No, score=-3.284 tagged_above=-999 required=5 tests=[AWL=-1.035, BAYES_00=-2.599, HELO_EQ_SE=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 qGZQi+XgIapP for ; Tue, 28 Jul 2009 08:30:16 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id BBBD73A7052 for ; Tue, 28 Jul 2009 08:30:15 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-e1-4a6f1987be79 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 65.AE.18827.7891F6A4; Tue, 28 Jul 2009 17:30:15 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 17:29:20 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 17:29:19 +0200 Received: from [131.160.126.137] (rvi2-126-137.lmf.ericsson.se [131.160.126.137]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 11A8F2537; Tue, 28 Jul 2009 18:29:19 +0300 (EEST) Message-ID: <4A6F194E.4050105@ericsson.com> Date: Tue, 28 Jul 2009 17:29:18 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Paul Kyzivat References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com><4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com><4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> <4A6DA26F.7060205@ericsson.com> <4A6F03A0.6000604@ericsson.com> <4A6F1140.3010704@cisco.com> <4A6F12E7.8000103@ericsson.com> <4A6F184D.9050106@cisco.com> In-Reply-To: <4A6F184D.9050106@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2009 15:29:19.0365 (UTC) FILETIME=[2CBF2350:01CA0F98] X-Brightmail-Tracker: AAAAAA== Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 28 Jul 2009 15:30:16 -0000 Hi, > OK. I'm fine with *that*. It may also want to refresh any other dialogs > it has established, such as subscriptions. sure, I will mention that as well. Again, as a general consideration so that implementors understand the scenario. Thanks, Gonzalo From pkyzivat@cisco.com Tue Jul 28 08:39:11 2009 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 C6DFE3A7028 for ; Tue, 28 Jul 2009 08:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.488 X-Spam-Level: X-Spam-Status: No, score=-6.488 tagged_above=-999 required=5 tests=[AWL=0.111, 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 wI2+akVNdRsy for ; Tue, 28 Jul 2009 08:39:10 -0700 (PDT) Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id B704A3A707D for ; Tue, 28 Jul 2009 08:38:59 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHi4bkpAZnmf/2dsb2JhbAC9MYgnj3gFhAw X-IronPort-AV: E=Sophos;i="4.43,284,1246838400"; d="scan'208";a="220186345" Received: from rtp-dkim-2.cisco.com ([64.102.121.159]) by sj-iport-1.cisco.com with ESMTP; 28 Jul 2009 15:39:00 +0000 Received: from rtp-core-1.cisco.com (rtp-core-1.cisco.com [64.102.124.12]) by rtp-dkim-2.cisco.com (8.12.11/8.12.11) with ESMTP id n6SFd0f7023114; Tue, 28 Jul 2009 11:39:00 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6SFd0wj016589; Tue, 28 Jul 2009 15:39:00 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 11:38:59 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 11:38:59 -0400 Message-ID: <4A6F1B93.4010301@cisco.com> Date: Tue, 28 Jul 2009 11:38:59 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com><4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com><4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> <4A6DA26F.7060205@ericsson.com> <4A6F03A0.6000604@ericsson.com> <4A6F0D58.5090009@ericsson.com> <4A6F17CF.1000505@cisco.com> <4A6F18E1.5070408@ericsson.com> In-Reply-To: <4A6F18E1.5070408@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2009 15:38:59.0548 (UTC) FILETIME=[869009C0:01CA0F99] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=2134; t=1248795540; x=1249659540; c=relaxed/simple; s=rtpdkim2001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20New=20revision=20of=20the=2 0re-INVITE=20handling=20draft |Sender:=20 |To:=20Gonzalo=20Camarillo=20; bh=5GnYIkTPcykPAodXwcwGaU0D4QspJlPiocTfmEp16UM=; b=vPNnK2u+5LSfxP7zlYXeM3vcJXKAk1e1WiZQ9OE4524Rim9BWxRXrOQ/5y KsDk+wMYJXCe4l2AmLPt4q6g9BoXsJvPSXGFGtB/xarjQwc/0pn1THgF6t/O zAy+7QJUWi; Authentication-Results: rtp-dkim-2; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim2001 verified; ); Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 28 Jul 2009 15:39:11 -0000 Gonzalo Camarillo wrote: > Hi, > > answers inline: > > Paul Kyzivat wrote: >> >> >> Gonzalo Camarillo wrote: >>> Hi Christer, >>> >>>> So, unless I am wrong we would say that it is possible to provide the >>>> remote target unreliably for an initial INVITE, but it is not possible >>>> to update it unreliably for a re-INVITE. >>> >>> yes, that is what I said in my previous email. We are in agreement. >>> An unreliable response cannot refresh a target. >> >> Hmm... >> >> That means that the UAC of a reINVITE, when it receives an unreliable >> response with a new target, MUST NOT refresh the target at that time? >> >> That will certainly make the code inconsistent with what is >> implemented for the initial INVITE. And probably break a lot of >> implementations. >> >> I'm not certain one way or the other on this. My inclination is that >> it can refresh the target, but the UAS won't know if it has. > > yes, that is the problem. If we let unreliable responses change things, > the UAS is not aware if the UAC received them or not. So, if the UAS > later sends a 4xx for the re-INVITE, it does not know if the UAC has > refreshed the target (if the UAC received the response) or not (if the > UAC did not receive it). We would be creating a mechanism that gets UAs > out of sync. I agree. But I still see justification for allowing it: 1) its simpler for the UAC - common logic for initial- and re- invite. 2) its more likely to be consistent with current behavior 3) if the UAC and/or the UAS doesn't support reliable provisionals, and the UAC does need to change the target, it seems better to do it than not. but I still wouldn't *recommend* it. Certainly there are cases where this could lead to inconsistencies and thus a failed call. I think the preferred behavior in that situation would be: - send final response to reINVITE (e.g. 487.) - immediately send new reINVITE to refresh the target. (It can go before receiving the ACK. If it causes glare due to loss of the final response, then deal with it then.) Thanks, Paul From christer.holmberg@ericsson.com Tue Jul 28 08:40:58 2009 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 75D4A3A6FF6 for ; Tue, 28 Jul 2009 08:40:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.51 X-Spam-Level: X-Spam-Status: No, score=-5.51 tagged_above=-999 required=5 tests=[AWL=0.739, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 1UagFaoOjZHQ for ; Tue, 28 Jul 2009 08:40:57 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id 4136F3A6DA3 for ; Tue, 28 Jul 2009 08:40:57 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9dae00000519d-d3-4a6f1c048e89 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 0D.7F.20893.40C1F6A4; Tue, 28 Jul 2009 17:40:52 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 17:40:52 +0200 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, 28 Jul 2009 17:40:51 +0200 Message-ID: In-Reply-To: <4A6F18E1.5070408@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] New revision of the re-INVITE handling draft Thread-Index: AcoPl+vDVscIKiMVRjuBThPukrJcJAAAQscg References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com><4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com><4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> <4A6DA26F.7060205@ericsson.com> <4A6F03A0.6000604@ericsson.com> <4A6F0D58.5090009@ericsson.com> <4A6F17CF.1000505@cisco.com> <4A6F18E1.5070408@ericsson.com> From: "Christer Holmberg" To: "Gonzalo Camarillo" , "Paul Kyzivat" X-OriginalArrivalTime: 28 Jul 2009 15:40:52.0231 (UTC) FILETIME=[C9BA1970:01CA0F99] X-Brightmail-Tracker: AAAAAA== Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 28 Jul 2009 15:40:58 -0000 Hi,=20 >>>>So, unless I am wrong we would say that it is possible to provide=20 >>>>the remote target unreliably for an initial INVITE, but it is not=20 >>>>possible to update it unreliably for a re-INVITE. >>> >>>yes, that is what I said in my previous email. We are in agreement.=20 >>>An unreliable response cannot refresh a target. >>=20 >>Hmm... >>=20 >>That means that the UAC of a reINVITE, when it receives an unreliable=20 >>response with a new target, MUST NOT refresh the target at that time? >> >>That will certainly make the code inconsistent with what is=20 >>implemented for the initial INVITE. And probably break a lot of implementations. >>=20 >>I'm not certain one way or the other on this. My inclination is that=20 >>it can refresh the target, but the UAS won't know if it has. > >yes, that is the problem. If we let unreliable responses change things, the UAS is not aware if the UAC received them or=20 >not. So, if the UAS later sends a 4xx for the re-INVITE, it does not know if the UAC has refreshed the target (if the UAC=20 >received the response) or not (if the UAC did not receive it). We would be creating a mechanism that gets UAs out of=20 >sync. It was probably a misstake to allow the unreliable 18x to provide the target for the initial INVITE, but I guess it is too late to change that now... =20 I share Paul's issue with potential implementation impacts, but I guess this is something we just have to do - otherwise we will end up with the problem Gonzalo describes. This is probably one thing it would be good to get some feedback from SIPit, on how implementations behave. Regards, Christer From gonzalo.camarillo@ericsson.com Tue Jul 28 08:49:04 2009 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 000873A696A for ; Tue, 28 Jul 2009 08:49:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.26 X-Spam-Level: X-Spam-Status: No, score=-5.26 tagged_above=-999 required=5 tests=[AWL=0.989, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 QGYB5cf7eQlH for ; Tue, 28 Jul 2009 08:49:03 -0700 (PDT) Received: from mailgw3.ericsson.se (mailgw3.ericsson.se [193.180.251.60]) by core3.amsl.com (Postfix) with ESMTP id A7D223A6962 for ; Tue, 28 Jul 2009 08:48:38 -0700 (PDT) X-AuditID: c1b4fb3c-b7b9dae00000519d-98-4a6f1dd6e782 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw3.ericsson.se (Symantec Mail Security) with SMTP id 24.FF.20893.6DD1F6A4; Tue, 28 Jul 2009 17:48:38 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 17:48:18 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 17:48:17 +0200 Received: from [131.160.126.137] (rvi2-126-137.lmf.ericsson.se [131.160.126.137]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 34F6B2537; Tue, 28 Jul 2009 18:48:17 +0300 (EEST) Message-ID: <4A6F1DC1.2050307@ericsson.com> Date: Tue, 28 Jul 2009 17:48:17 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Paul Kyzivat References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com><4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com><4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> <4A6DA26F.7060205@ericsson.com> <4A6F03A0.6000604@ericsson.com> <4A6F0D58.5090009@ericsson.com> <4A6F17CF.1000505@cisco.com> <4A6F18E1.5070408@ericsson.com> <4A6F1B93.4010301@cisco.com> In-Reply-To: <4A6F1B93.4010301@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 28 Jul 2009 15:48:17.0956 (UTC) FILETIME=[D3665640:01CA0F9A] X-Brightmail-Tracker: AAAAAA== Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 28 Jul 2009 15:49:04 -0000 Hi, > I agree. But I still see justification for allowing it: > > 1) its simpler for the UAC - common logic for initial- and re- invite. > 2) its more likely to be consistent with current behavior how simpler and how consistent with current behavior it is would depend on each particular implementation. In any case, RFC3261 does not allow unreliable responses to refresh targets. RFC3261 only allows 2xx responses to do that. Therefore, we are consistent with what is currently specified. We are not specifying anything new here. > 3) if the UAC and/or the UAS doesn't support reliable provisionals, > and the UAC does need to change the target, it seems better > to do it than not. If the UAS wants to change its location, it can send an UPDATE instead of an unreliable response. That would work just fine. Cheers, Gonzalo From bcampen@estacado.net Tue Jul 28 08:52:28 2009 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 3728F3A6EB9 for ; Tue, 28 Jul 2009 08:52:28 -0700 (PDT) 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 YXLXln6JA1KZ for ; Tue, 28 Jul 2009 08:52:27 -0700 (PDT) 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 DED193A6DA3 for ; Tue, 28 Jul 2009 08:52:26 -0700 (PDT) Received: from dn3-233.estacado.net (dn3-233.estacado.net [172.16.3.233]) (authenticated bits=0) by estacado.net (8.14.2/8.14.2) with ESMTP id n6SFqPTC030177 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 28 Jul 2009 10:52:25 -0500 (CDT) (envelope-from bcampen@estacado.net) Message-Id: <11ACDD44-2A08-46E7-A156-DE117FD25BC2@estacado.net> From: Byron Campen To: Adam Roach In-Reply-To: <4A6F0CA8.4020307@nostrum.com> Content-Type: multipart/signed; boundary=Apple-Mail-3--93794018; micalg=sha1; protocol="application/pkcs7-signature" Mime-Version: 1.0 (Apple Message framework v935.3) Date: Tue, 28 Jul 2009 10:52:20 -0500 References: <109101c9eae2$f8ef9890$eacec9b0$@net> <1EF42B19-CB00-48C3-9EF7-F15A36AE5CF7@estacado.net> <1244821160.3768.13.camel@victoria-pingtel-com.us.nortel.com> <85ED2F6F-EBAC-454D-858B-D3BFAF901CCA@estacado.net> <4A33F51F.7070405@softarmor.com> <4A6EAC8D.2080504@nostrum.com> <32A39E52-CD15-45AB-A3F4-15D7D654CFA2@estacado.net> <4A6F0CA8.4020307@nostrum.com> X-Mailer: Apple Mail (2.935.3) Cc: sipcore@ietf.org, Dale Worley Subject: Re: [sipcore] [Sipping] draft-niemi-sipcore-event-rate-control-00 and forcing notifications when state has not changed 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, 28 Jul 2009 15:52:28 -0000 --Apple-Mail-3--93794018 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit > [as individual participant] > > Byron Campen wrote: >>> Dean Willis wrote: >>>> Byron Campen wrote: >>>> >>>> >>>>> Indeed, this could be done with etag, and using etag is a far >>>>> more >>>>> efficient mechanism, because you are not gratuitously sending >>>>> (potentially very large) documents. My main beef is that this >>>>> shifts the >>>>> job of maintaining soft-state to the server. As a general >>>>> principle, >>>>> this has been the client's job, and this is specifically how SIP >>>>> events >>>>> is supposed to work. Allowing the client to say, "Nah, you're >>>>> going to >>>>> handle recovery now." is a rather fundamental change to the >>>>> protocol, >>>>> that we should only make if there is a compelling reason. I see >>>>> no such >>>>> reason. >>>>> >>>>> >>>> >>>> I find this argument compelling. It might even be worth >>>> expounding on >>>> this general concept in rfrc265bis. >>>> >>> >>> I don't understand what you are proposing. Could you give an >>> example of what such text would look like? >>> >>> /a >> >> Basically, that the client should handle keepalives for soft >> state. > > I get that, but I don't see where that indicates any changes to the > document. > > I'll be more blunt: if you have an idea for something you'd like to > see added to RFC3265bis, send the literal text you'd like to see > included in the document, and an extremely precise pointer to where > you'd like to see it inserted. I'll take xml2rfc format or plain text. > > /a Personally, it seems like a design principle that is more general, so I dunno if it would go somewhere like 3265bis. Dean? Best regards, Byron Campen --Apple-Mail-3--93794018 Content-Disposition: attachment; filename=smime.p7s Content-Type: application/pkcs7-signature; name=smime.p7s Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIGZDCCAx0w ggKGoAMCAQICEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEFBQAwYjELMAkGA1UEBhMCWkEx JTAjBgNVBAoTHFRoYXd0ZSBDb25zdWx0aW5nIChQdHkpIEx0ZC4xLDAqBgNVBAMTI1RoYXd0ZSBQ ZXJzb25hbCBGcmVlbWFpbCBJc3N1aW5nIENBMB4XDTA4MDkyMzA0MzgwNFoXDTA5MDkyMzA0Mzgw NFowazEfMB0GA1UEAxMWVGhhd3RlIEZyZWVtYWlsIE1lbWJlcjEjMCEGCSqGSIb3DQEJARYUYmNh bXBlbkBlc3RhY2Fkby5uZXQxIzAhBgkqhkiG9w0BCQEWFGRvY2ZhcmFkYXlAZ21haWwuY29tMIIB IjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAnvIGiyvzQgsqDjR3TiFTO4nkc/VRo/eX6xKu ky4CR2QtnIPEWhNLbU5UgXdGzU3YWx/cRj5alT0auKVQ/BnjCbf3bFSzP5mIfV6KlJV89dpxKQQA 3FaDYxE3whiRPIjQh3nmqxSacBTLohlt/g8MlFyiHoNs3XcH83M3QMjMxU8pD7SgXUDaXdtqC8vV +7g3rzPmlONdJ+4vac159wuZe37WVTsFI4sYL3p/KvqT1NZhmn1cmOVWKfCVAdGLk8VEUZtWuSeM NU5CLnFvenxaSPkDeVR5h0qDpw4DQyHfWXQuKvRs1WgVeHASz87EPgncyp90yiByetvE0WIBGKiz 0QIDAQABo0cwRTA1BgNVHREELjAsgRRiY2FtcGVuQGVzdGFjYWRvLm5ldIEUZG9jZmFyYWRheUBn bWFpbC5jb20wDAYDVR0TAQH/BAIwADANBgkqhkiG9w0BAQUFAAOBgQANmDZo4t+1SrO9nb8KfjN4 QtlV1gzaAa2jEsAZ369PBXdsxVz32a1JIa1KudXFfMMxtF1NRDJ0Z3ib/qq+L8B28IpkYgRWtRr+ WWm6LzJ6rm1Q85cC0VSqoIRr+NoRZjaBdqWbJC4QsPnwVSXN9jLMLkFkjcxVDSxQtEx6v1PF9zCC Az8wggKooAMCAQICAQ0wDQYJKoZIhvcNAQEFBQAwgdExCzAJBgNVBAYTAlpBMRUwEwYDVQQIEwxX ZXN0ZXJuIENhcGUxEjAQBgNVBAcTCUNhcGUgVG93bjEaMBgGA1UEChMRVGhhd3RlIENvbnN1bHRp bmcxKDAmBgNVBAsTH0NlcnRpZmljYXRpb24gU2VydmljZXMgRGl2aXNpb24xJDAiBgNVBAMTG1Ro YXd0ZSBQZXJzb25hbCBGcmVlbWFpbCBDQTErMCkGCSqGSIb3DQEJARYccGVyc29uYWwtZnJlZW1h aWxAdGhhd3RlLmNvbTAeFw0wMzA3MTcwMDAwMDBaFw0xMzA3MTYyMzU5NTlaMGIxCzAJBgNVBAYT AlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNUaGF3 dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQTCBnzANBgkqhkiG9w0BAQEFAAOBjQAwgYkC gYEAxKY8VXNV+065yplaHmjAdQRwnd/p/6Me7L3N9VvyGna9fww6YfK/Uc4B1OVQCjDXAmNaLIkV cI7dyfArhVqqP3FWy688Cwfn8R+RNiQqE88r1fOCdz0Dviv+uxg+B79AgAJk16emu59l0cUqVIUP SAR/p7bRPGEEQB5kGXJgt/sCAwEAAaOBlDCBkTASBgNVHRMBAf8ECDAGAQH/AgEAMEMGA1UdHwQ8 MDowOKA2oDSGMmh0dHA6Ly9jcmwudGhhd3RlLmNvbS9UaGF3dGVQZXJzb25hbEZyZWVtYWlsQ0Eu Y3JsMAsGA1UdDwQEAwIBBjApBgNVHREEIjAgpB4wHDEaMBgGA1UEAxMRUHJpdmF0ZUxhYmVsMi0x MzgwDQYJKoZIhvcNAQEFBQADgYEASIzRUIPqCy7MDaNmrGcPf6+svsIXoUOWlJ1/TCG4+DYfqi2f Ni/A9BxQIJNwPP2t4WFiw9k6GX6EsZkbAMUaC4J0niVQlGLH2ydxVyWN3amcOY6MIE9lX5Xa9/eH 1sYITq726jTlEBpbNU1341YheILcIRk13iSx0x1G/11fZU8xggMQMIIDDAIBATB2MGIxCzAJBgNV BAYTAlpBMSUwIwYDVQQKExxUaGF3dGUgQ29uc3VsdGluZyAoUHR5KSBMdGQuMSwwKgYDVQQDEyNU aGF3dGUgUGVyc29uYWwgRnJlZW1haWwgSXNzdWluZyBDQQIQW7SrCyoCwnsms5MfcqmjmzAJBgUr DgMCGgUAoIIBbzAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0wOTA3 MjgxNTUyMjFaMCMGCSqGSIb3DQEJBDEWBBT/ypTrrxpG06E2KK2ZJEPUFMYCrTCBhQYJKwYBBAGC NxAEMXgwdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMcVGhhd3RlIENvbnN1bHRpbmcgKFB0eSkg THRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZyZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsq AsJ7JrOTH3Kpo5swgYcGCyqGSIb3DQEJEAILMXigdjBiMQswCQYDVQQGEwJaQTElMCMGA1UEChMc VGhhd3RlIENvbnN1bHRpbmcgKFB0eSkgTHRkLjEsMCoGA1UEAxMjVGhhd3RlIFBlcnNvbmFsIEZy ZWVtYWlsIElzc3VpbmcgQ0ECEFu0qwsqAsJ7JrOTH3Kpo5swDQYJKoZIhvcNAQEBBQAEggEABwzd pnTtpe4SCW+Ud2jW9zvYFlhuLPQGBrcuWN9u18HMzYPuzIrtO5SYEG2lphz08YtOOWHTQg1LeC7z Dqu6FY0RJ0lkxAiKze/vIqu3QZDpUaqV9BY+ivdtAIV3doL3+2T5J99wG2tUAJ0xRi2RJncP/T8D KL49PFmwy8Ui7Sk+pQqsSSjNgEDQoq1dZ6XpuJdSh8l/qm7jxCU6q1uUWXpYKq9bZWzVkBzs30MH 5AvK9j3apNYMlJKV9RpKtpihEn1x4a3O5D9Va1LzgJGaPnzTzEUiHAa7soTnC/qfSknOEcWP5JwS +NgcKseUfMlU68/cBME5or5JoJ5viagJ9AAAAAAAAA== --Apple-Mail-3--93794018-- From pkyzivat@cisco.com Tue Jul 28 18:19:05 2009 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 4628A3A6821 for ; Tue, 28 Jul 2009 18:19:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, 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 L9kYoqySOxhK for ; Tue, 28 Jul 2009 18:19:04 -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 C15103A696A for ; Tue, 28 Jul 2009 18:18:49 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEANtAb0pAZnme/2dsb2JhbAC8fognkCgFhBA X-IronPort-AV: E=Sophos;i="4.43,285,1246838400"; d="scan'208";a="52102418" Received: from rtp-dkim-1.cisco.com ([64.102.121.158]) by rtp-iport-2.cisco.com with ESMTP; 29 Jul 2009 01:18:50 +0000 Received: from rtp-core-2.cisco.com (rtp-core-2.cisco.com [64.102.124.13]) by rtp-dkim-1.cisco.com (8.12.11/8.12.11) with ESMTP id n6T1IopR016083; Tue, 28 Jul 2009 21:18:50 -0400 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id n6T1Io81017480; Wed, 29 Jul 2009 01:18:50 GMT Received: from xfe-rtp-201.amer.cisco.com ([64.102.31.38]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 21:18:50 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-201.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 28 Jul 2009 21:18:50 -0400 Message-ID: <4A6FA37A.1030009@cisco.com> Date: Tue, 28 Jul 2009 21:18:50 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com><4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com><4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> <4A6DA26F.7060205@ericsson.com> <4A6F03A0.6000604@ericsson.com> <4A6F0D58.5090009@ericsson.com> <4A6F17CF.1000505@cisco.com> <4A6F18E1.5070408@ericsson.com> <4A6F1B93.4010301@cisco.com> <4A6F1DC1.2050307@ericsson.com> In-Reply-To: <4A6F1DC1.2050307@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jul 2009 01:18:50.0164 (UTC) FILETIME=[8762BF40:01CA0FEA] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1023; t=1248830330; x=1249694330; c=relaxed/simple; s=rtpdkim1001; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20New=20revision=20of=20the=2 0re-INVITE=20handling=20draft |Sender:=20 |To:=20Gonzalo=20Camarillo=20; bh=r9mnl86ChV8lwt6XSjslkBFVU2Cr3Nc3E5Y+OdmxD/g=; b=BnzZuFVtMpqHAsqdXRbkTBpiMqwXbdMzmOhhxyVPgaMYXfq76HOcMWqU4l hO8YB22pY5rKUewjNuX0srhU58eTz2jwjuRvZRJckIYhMFnx9CIvTWuJEVo7 U5mHvfm036; Authentication-Results: rtp-dkim-1; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/rtpdkim1001 verified; ); Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 29 Jul 2009 01:19:05 -0000 Gonzalo Camarillo wrote: > Hi, > >> I agree. But I still see justification for allowing it: >> >> 1) its simpler for the UAC - common logic for initial- and re- invite. >> 2) its more likely to be consistent with current behavior > > how simpler and how consistent with current behavior it is would depend > on each particular implementation. In any case, RFC3261 does not allow > unreliable responses to refresh targets. RFC3261 only allows 2xx > responses to do that. Therefore, we are consistent with what is > currently specified. We are not specifying anything new here. OK, sorry about that. >> 3) if the UAC and/or the UAS doesn't support reliable provisionals, >> and the UAC does need to change the target, it seems better >> to do it than not. > > If the UAS wants to change its location, it can send an UPDATE instead > of an unreliable response. That would work just fine. If UPDATE is supported. But maybe we should stop worrying about things that don't. Paul From gonzalo.camarillo@ericsson.com Wed Jul 29 05:25:37 2009 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 DCE713A7023 for ; Wed, 29 Jul 2009 05:25:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.29 X-Spam-Level: X-Spam-Status: No, score=-3.29 tagged_above=-999 required=5 tests=[AWL=-1.041, BAYES_00=-2.599, HELO_EQ_SE=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 i9Tt7v8h8+o2 for ; Wed, 29 Jul 2009 05:25:37 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id EFE6E3A6ECB for ; Wed, 29 Jul 2009 05:25:36 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-98-4a703fc14a6e Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 5C.FC.18827.1CF307A4; Wed, 29 Jul 2009 14:25:37 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 14:25:37 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 14:25:37 +0200 Received: from [131.160.126.137] (rvi2-126-137.lmf.ericsson.se [131.160.126.137]) by mail.lmf.ericsson.se (Postfix) with ESMTP id D0C152530; Wed, 29 Jul 2009 15:25:36 +0300 (EEST) Message-ID: <4A703FC0.1080205@ericsson.com> Date: Wed, 29 Jul 2009 14:25:36 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Paul Kyzivat References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com><4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com><4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> <4A6DA26F.7060205@ericsson.com> <4A6F03A0.6000604@ericsson.com> <4A6F0D58.5090009@ericsson.com> <4A6F17CF.1000505@cisco.com> <4A6F18E1.5070408@ericsson.com> <4A6F1B93.4010301@cisco.com> <4A6F1DC1.2050307@ericsson.com> <4A6FA37A.1030009@cisco.com> In-Reply-To: <4A6FA37A.1030009@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jul 2009 12:25:37.0157 (UTC) FILETIME=[AD696B50:01CA1047] X-Brightmail-Tracker: AAAAAA== Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 29 Jul 2009 12:25:38 -0000 Hi, > If UPDATE is supported. > But maybe we should stop worrying about things that don't. I will make sure the draft covers the different possibilities (e.g., no support for 100rel or UPDATE). Thanks, Gonzalo From gonzalo.camarillo@ericsson.com Wed Jul 29 08:11:57 2009 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 283013A6E78 for ; Wed, 29 Jul 2009 08:11:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.268 X-Spam-Level: X-Spam-Status: No, score=-6.268 tagged_above=-999 required=5 tests=[AWL=1.981, BAYES_00=-2.599, GB_I_LETTER=-2, HELO_EQ_SE=0.35, 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 FK97DLuXH1oM for ; Wed, 29 Jul 2009 08:11:55 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 8D0323A6940 for ; Wed, 29 Jul 2009 08:11:55 -0700 (PDT) X-AuditID: c1b4fb3e-b7bb9ae000004f89-8e-4a7066bb3d9d Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id 44.B5.20361.BB6607A4; Wed, 29 Jul 2009 17:11:56 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.175]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 17:11:55 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 17:11:55 +0200 Received: from [131.160.126.137] (rvi2-126-137.lmf.ericsson.se [131.160.126.137]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 54E532530; Wed, 29 Jul 2009 18:11:55 +0300 (EEST) Message-ID: <4A7066BB.7000302@ericsson.com> Date: Wed, 29 Jul 2009 17:11:55 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Dale Worley References: <1245876685.3748.61.camel@victoria-pingtel-com.us.nortel.com> In-Reply-To: <1245876685.3748.61.camel@victoria-pingtel-com.us.nortel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 29 Jul 2009 15:11:55.0745 (UTC) FILETIME=[E91D1D10:01CA105E] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] draft-kaplan-sip-session-id-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, 29 Jul 2009 15:11:57 -0000 Hi, note that this draft proposes a new SIP header but it does not seem to update any of our core specs. Therefore, it would be better to discuss it on the DISPATCH WG's list. Cheers, Gonzalo SIPCORE co-chair Dale Worley wrote: > Looking at draft-kaplan-sip-session-id-02, the shorter the Session-Id > header is, the fewer complaints people will have about using it in > practice. A couple of things could be done to shorten it: > > - assign a single-letter abbreviation for the name > > - use base64 rather than hex encoding > > Base64 encoding reduces the header value to 22 characters from 32. > > Dale > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From Hannes.Tschofenig@gmx.net Wed Jul 29 11:27:47 2009 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 4C54F3A6A29 for ; Wed, 29 Jul 2009 11:27:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.169 X-Spam-Level: X-Spam-Status: No, score=-2.169 tagged_above=-999 required=5 tests=[AWL=-0.170, 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 9qDfGVSsdca6 for ; Wed, 29 Jul 2009 11:27:47 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 875613A6B7F for ; Wed, 29 Jul 2009 11:27:46 -0700 (PDT) Received: (qmail invoked by alias); 29 Jul 2009 18:21:05 -0000 Received: from a91-154-108-144.elisa-laajakaista.fi (EHLO 4FIL42860) [91.154.108.144] by mail.gmx.net (mp062) with SMTP; 29 Jul 2009 20:21:05 +0200 X-Authenticated: #29516787 X-Provags-ID: V01U2FsdGVkX1/pCz1u5J7pQ7jx/eoEUhr0qTjzlGCJPxBJ+DotyO aU9RqsVJxeWfPj From: "Hannes Tschofenig" To: "'Gonzalo Camarillo'" , "'SIPCORE'" References: <4A6423CE.7010601@ericsson.com> Date: Wed, 29 Jul 2009 21:23:33 +0300 Message-ID: <082501ca1079$af12c2d0$0301a8c0@nsnintra.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcoJEEVIR3zJuv0qTr2NFG3B6atwtwF2RqYA X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3350 In-Reply-To: <4A6423CE.7010601@ericsson.com> X-Y-GMX-Trusted: 0 X-FuHaFi: 0.52 Cc: geopriv@ietf.org Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-location-conveyance-01.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: Wed, 29 Jul 2009 18:27:47 -0000 Hi Gonzalo, Hi James, Hi Brian, I have done a review of the SIP Location Conveyance already earlier this year (in March 2009), see http://www.ietf.org/mail-archive/web/geopriv/current/msg06955.html. I re-did it for http://www.ietf.org/id/draft-ietf-sipcore-location-conveyance-01.txt. * I believe that the document should try to avoid the term "using protocol" at all costs. As we know, this term is very confusing and adds no particular value. Example: Other protocols used in the Location URI MUST be reviewed against the RFC 3693 criteria for a Using Protocol. In human readable language this means: "You have to consider security and privacy with new extensions." Wow. What a surprising statement! * Don't understand why this document does not allow a HELD URI to be conveyed. I commented this already several times. Even the IANA registry appears unnecessary for me. You have error messages defined for the cases where the URI isn't understood. There aren't too many new protocols to be expected. * Based on the other list discusssions around this draft I suspect that information about what the location refers to will be described in a future version of the document. * This document is about the transport of a PIDF-LO and not about describing what deployments should do. Example: " Adding a new locationValue to an in-transit request SHOULD NOT occur for at least two reasons, #1 - SIP Servers are not the best Sighters, as defined by [RFC3693], of geographically where a UAC can be; meaning the location information is not necessarily the greatest. There MAY be exceptions, but this SHOULD be the rule of thumb. #2 - without appropriate caution to the fact that Location Recipients might not understand how to process more than one location, given this document's limited guidance as to what a Location Recipient should do when receiving more than one location (i.e., currently no priority instructions are given for which locationValue to use if there are more than one). A Location Recipient can easily be confused by too much location information, producing undesirable results. The element in the PIDF-LO XML indicates whose location is contained in the PIDF-LO. " This example also shows inappropriate usage of RFC2119 language, which should be used for interoperability. We know who wants some of this functionality and what the exact use case it. Btw, the term "sighter" is not defined anyway (and not in RFC3693 either). Here is the relevant text part: This document gives no guidance how this is accomplished, given the number of ways a UAC can learn its location, or a SIP intermediary can **Sight** a UAC, as defined in [RFC3693]. * In my previous review I complained about the error codes and the thought that went into them. I was wondering whether someone (maybe the authors?) has implemented this specification in the meanwhile and has gained some experience with the error handling already. Are the error codes suffient? Well enough described? * I might be too tired today already but the example shown in Section 5.1 seems to be wrong. It says: " ... 33.001111 -96.68142 ... " It should say: " ... 33.001111 -96.68142 ... " * " Use of self-signed certificates is inappropriate for use in protecting a PIDF, as the sender does not have a secure identity of the recipient. " This sentence does not make a lot of sense to me. You can use self-signed certificates for protecting a PIDF before sending it to me. The important thing is to make your self-signed cert available to me. * This document does not need to repeat the text from other documents. Example: " When using LbyR, the location URI MUST NOT contain any user identifying information. For example, use something unidentifiable like " Already in the LbyR requirements document. Reference it -- no need to write new text. That's why we have written these other documents. * " If the Location Generator wishes to control whether any location included in the SIP request or added along the signaling path of this request can be viewed for routing decisions, the Location Generator adds a Geolocation header value including the "routing-allowed=no" parameter. " Replace "Location Generator" by "Rule Maker". * Remove useless statements. Example: " Unless stated otherwise by future standards-track publication(s), a LbyR URI only has meaning within the Geolocation header field and MUST NOT appear in any other SIP header field. " * Avoid author bias. Example: "Proxies inserting location for location-based routing are unable to meet this requirement, and such use is NOT RECOMMENDED." The document defines functionality to allow the proxy to add location and we know who is going to use this. The text further says: " Proxies conveying location using this extension MUST have the permission of the Target to do so. " Is a Service URN with a service:sos parameter good enough as a permission? Or what **permission** mechanism are you think about? * " Any idea of using SIP Identity is lost as soon as it is realized that the Geolocation header value can be added to by intermediaries in the signaling path. " That's not the problem. The problem is that the signature calculation of SIP Identity does not cover these new headers. * I like this acknowledgement "To Dave Oran for helping to shape this idea." The idea that location can be carried in SIP? * Geopriv Privacy Considerations This section is pretty useless but I wanted to ask one thing about the following text: " Quoting requirement #4 of [RFC3693]: "The Using Protocol has to obey the privacy and security instructions coded in the Location Object and in the corresponding Rules regarding the transmission and storage of the LO." This document requires that SIP entities sending or receiving location MUST obey such instructions. " What about a SIP node that does not understand SIP location conveyance? It sends and receives the messages related to location messages. * Avoid inappropriate treatment of subjects that are discussed somewhere else. You discuss topics that have been described elsewhere and are therefore clearly outside the scope of this document. " One facet within this extension is such that locations can be placed on a remote server, accessible with the possession of a URI. The concept of an LbyR URI has its own security considerations. It is tempting to assume that the dereference would have authentication, authorization and other security mechanisms that limit the access to information. Unfortunately, this might not be true. The access network the UAC is connected to can be the source of location reference, and it might not have any credentialing mechanism suitable for controlling access to location. Consider, specifically, a nomadic user connected to an access network in a hotel. The UAC has no way to provide a credential acceptable to the hotel Location Server (LS) to any of its intended Location Recipients. The recipient of a reference does not know if a reference has appropriate authorization policies or not. The LS should provide location to any requestor. " * I found this paragraph in the security consideration sections. It more or less argues that the authorization model based on access control does not work in a number of cases. This is sort of interesting, if one additional considers the other work that is being done in GEOPRIV with the DHCP-URI document where the argument goes into the opposite direction. " Because target locations can be placed on a remote server, called a Location Server accessible with the possession of a location URI, this URI has its own security considerations. It is tempting to assume that the dereference of this URI would have authentication, authorization and other security mechanisms that limit the access to information. Unfortunately, this might not be true. The access network the UAC is connected to can be the source of location reference, and it might not have any credentialing mechanism suitable for controlling access to a target's location. Consider, specifically, a nomadic user connected to an access network in a hotel. The UAC has no way to provide a credential acceptable of the hotel Location Server (LS) to any of its intended Location Recipients. The recipient of a reference does not know if a reference has appropriate authorization policies or not. " I am sure the security consideration section will get some more feedback as the document moves along. If you read through it essentially provides the following story: - Conveying location is privacy sensitive and hence the transport has to be protected. ==> Use S/MIME - Well, you cannot really use S/MIME since it isn't deployed. ==> Use TLS hop-by-hop. - TLS isn't good either since the SIP hops see the location and then there is also retargeting. The end host does not know the intermedia SIP proxies either so he might not trust them. ==> Use an unlinkable pseudonym by placing garbage in the entity attribute of the PIDF document. - Well. That does not work either. ==> Here is the solution: We just let the UA decide what todo. And there SHOULD be a way to ask for user consent. Users make good decisions! I would present the story differently: First, there are 2 important aspects to differentiate from a security point of view, namely: 1) Location Based Routing 2) Non-Location Based Routing With location based routing the idea is that intermedaries see the location since otherwise they cannot route according to it. So, hop-by-hop TLS is the best you can do. If you don't like the consequences of it then you really need to use something like LoST prior to the SIP exchange to discover the entity you need to route to. With non-location based routing you will have problems with retargeting and forking. The good thing is that nobody says that you have to send location with the first message. Most folks might use TLS for signaling (hopefully) and hence at least you can deal with entities that are eavesdropping (unless they are SIP signaling elements). If you are worried about these entities listening to the location flying by, then you will have to use S/MIME. To make it deployable you could use SIP CERT. What is probably more important from a threat point of view is the ability to observe someone's movements. This would be possible in a presence based environment (when you PUBLISH your location to a presence / location server). The draft does provide that functionality, if I correctly understand it, but does not discuss it. There, we have our policy work that deals with this problem, namely Common Policy and Geolocation Policy. Additionally, one might want to mention the attached policies that travel with location. You could also point to the loc-sec architecture document for this purpose (as an informative reference). If you mention these policies in the security consideration section then you could also delete the "Geopriv Privacy Considerations" section. Finally, you might want to say that the PIDF-LO is only bound to the SIP message if SIP Identity is used and the location is in the body of the message as the signature computation utilized by SIP Identity would not cover any of the header fields. Btw, I have provided text for the security consideration section in the past already. Luckily it was kindly ignored. So, don't expect me to write it again. Ciao Hannes >-----Original Message----- >From: sipcore-bounces@ietf.org >[mailto:sipcore-bounces@ietf.org] On Behalf Of Gonzalo Camarillo >Sent: 20 July, 2009 10:59 >To: SIPCORE >Subject: [sipcore] WGLC: draft-ietf-sipcore-location-conveyance-01.txt > >Folks, > >we would like to start the WGLC of the following draft: > >http://tools.ietf.org/html/draft-ietf-sipcore-location-conveyance-01 > >This WGLC will end on August 7th. > >Note that there are ongoing threads discussing this draft on the list. >The idea is to take those comments as WGLC comments. > >Also note that we have another WGLC in parallel at this point >(info events, whose WGLC ends on July 29th). We have chosen to >have this partial overlap between the two WGLCs in order to >take advantage of the extra cycles people put in on reviewing >drafts during the pre-IETF week. >Given that we have canceled the second SIPCORE session in >Stockholm, we believe this is a reasonable amount of work for >folks following this WG. > >Keith will be the PROTO shepherd for this draft. > >Thanks, > >Gonzalo >SIPCORE co-chair > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore > From christer.holmberg@ericsson.com Wed Jul 29 12:23:23 2009 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 6340B3A7055 for ; Wed, 29 Jul 2009 12:23:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.553 X-Spam-Level: X-Spam-Status: No, score=-5.553 tagged_above=-999 required=5 tests=[AWL=0.696, BAYES_00=-2.599, HELO_EQ_SE=0.35, 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 xFebGBTib6hh for ; Wed, 29 Jul 2009 12:23:22 -0700 (PDT) Received: from mailgw4.ericsson.se (mailgw4.ericsson.se [193.180.251.62]) by core3.amsl.com (Postfix) with ESMTP id 67CB53A6FFC for ; Wed, 29 Jul 2009 12:23:22 -0700 (PDT) X-AuditID: c1b4fb3e-b7bb9ae000004f89-1a-4a70a1aadb46 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw4.ericsson.se (Symantec Mail Security) with SMTP id EC.43.20361.AA1A07A4; Wed, 29 Jul 2009 21:23:22 +0200 (CEST) Received: from esealmw113.eemea.ericsson.se ([153.88.200.4]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Wed, 29 Jul 2009 21:22:11 +0200 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: Wed, 29 Jul 2009 21:22:10 +0200 Message-ID: In-Reply-To: <4A703FC0.1080205@ericsson.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] New revision of the re-INVITE handling draft Thread-Index: AcoQR64BWs7CysiBTbSy+gyoeSl3RQAOh5SA References: <4A52019B.4030600@ericsson.com> <4A528AB2.7020206@cisco.com><4A66E224.2010900@ericsson.com> <4A6861CC.5030300@cisco.com><4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> <4A6DA26F.7060205@ericsson.com> <4A6F03A0.6000604@ericsson.com> <4A6F0D58.5090009@ericsson.com> <4A6F17CF.1000505@cisco.com> <4A6F18E1.5070408@ericsson.com> <4A6F1B93.4010301@cisco.com> <4A6F1DC1.2050307@ericsson.com> <4A6FA37A.1030009@cisco.com> <4A703FC0.1080205@ericsson.com> From: "Christer Holmberg" To: "Gonzalo Camarillo" , "Paul Kyzivat" X-OriginalArrivalTime: 29 Jul 2009 19:22:11.0552 (UTC) FILETIME=[DF3B6E00:01CA1081] X-Brightmail-Tracker: AAAAAA== Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 29 Jul 2009 19:23:23 -0000 Hi, If you don't support UPDATE you can always send a re-INVITE, once the ongoing re-INVITE is done. Regards, Christer=20 -----Original Message----- From: Gonzalo Camarillo [mailto:Gonzalo.Camarillo@ericsson.com]=20 Sent: Wednesday, July 29, 2009 3:26 PM To: Paul Kyzivat Cc: Christer Holmberg; gao.yang2@zte.com.cn; SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft Hi, > If UPDATE is supported. > But maybe we should stop worrying about things that don't. I will make sure the draft covers the different possibilities (e.g., no support for 100rel or UPDATE). Thanks, Gonzalo From Martin.Thomson@andrew.com Thu Jul 30 01:29:36 2009 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 324073A7182; Thu, 30 Jul 2009 01:29:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.3 X-Spam-Level: X-Spam-Status: No, score=-2.3 tagged_above=-999 required=5 tests=[AWL=-0.301, 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 Fi3ftQE2i27N; Thu, 30 Jul 2009 01:29:34 -0700 (PDT) Received: from andrew.com (smtp3.andrew.com [198.135.207.235]) by core3.amsl.com (Postfix) with ESMTP id 0B3BC28C154; Thu, 30 Jul 2009 01:28:37 -0700 (PDT) X-SEF-Processed: 5_0_0_910__2009_07_30_03_51_11 X-SEF-16EBA1E9-99E8-4E1D-A1CA-4971F5510AF: 1 Received: from acdcexbh1.andrew.com [10.86.20.91] by smtp3.andrew.com - SurfControl E-mail Filter (5.2.1); Thu, 30 Jul 2009 03:51:05 -0500 Received: from AHQEX1.andrew.com ([10.86.20.21]) by acdcexbh1.andrew.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 03:28:29 -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: Thu, 30 Jul 2009 03:28:25 -0500 Message-ID: In-Reply-To: <082501ca1079$af12c2d0$0301a8c0@nsnintra.net> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Geopriv] [sipcore] WGLC:draft-ietf-sipcore-location-conveyance-01.txt Thread-Index: AcoJEEVIR3zJuv0qTr2NFG3B6atwtwF2RqYAAIFisSA= References: <4A6423CE.7010601@ericsson.com> <082501ca1079$af12c2d0$0301a8c0@nsnintra.net> From: "Thomson, Martin" To: "Hannes Tschofenig" , "Gonzalo Camarillo" , "SIPCORE" X-OriginalArrivalTime: 30 Jul 2009 08:28:29.0982 (UTC) FILETIME=[B7C48BE0:01CA10EF] Cc: geopriv@ietf.org Subject: Re: [sipcore] [Geopriv] WGLC:draft-ietf-sipcore-location-conveyance-01.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, 30 Jul 2009 08:29:36 -0000 SSB3YXMgZ29pbmcgdG8gd3JpdGUgYSBsb25nZXIgY29tbWVudCwgYnV0IEhhbm5lcyBoYXMgYWxy ZWFkeSBzYWlkIGFsbCB0aGF0IEkgd291bGQgaGF2ZSBhbnl3YXkuICBBbGwgb2YgaXQuDQoNCklu c3RlYWQsIEknbGwganVzdCBub3RlIHRoYXQgdGhlcmUgYXJlIGEgZmV3IHBsYWNlcyB3aGVyZSAy MTE5IHRleHQgaXMgdXNlZCB0byBtYW5kYXRlIGJlaGF2aW91ciB0aGF0IGlzIG91dHNpZGUgdGhl IHNjb3BlIG9mIHRoZSBkb2N1bWVudCBhbmQgY2VydGFpbmx5IG5vdCBuZWNlc3NhcnkgdG8gZW5z dXJlIGludGVyb3BlcmFiaWxpdHkuDQoNCkZvciBpbnN0YW5jZSwNCg0KICAgSW1wbGVtZW50YXRp b25zIE1BWSBjaG9vc2Ugd2hldGhlciBvciBub3QgdG8gaW5mb3JtIHRoZSB1c2VyIG9mIHRoaXMN CiAgIGVycm9yLiAgVGhlIHRleHQgc3RyaW5nIG9mICJSZXRyeSBMb2NhdGlvbiBMYXRlciB3aXRo IGRldmljZSB1cGRhdGVkDQogICBsb2NhdGlvbiIgaXMgUkVDT01NRU5ERUQsIGJ1dCBub3QgbWFu ZGF0b3J5IGZvciB1c2FnZSBpbiB0aGlzDQogICBlcnJvci4gIEltcGxlbWVudGF0aW9uIE1BWSB1 c2UgYW5vdGhlciB0ZXh0IHN0cmluZyB0byBpbmZvcm0gdGhlDQogICB1c2VyIHRoYXQgbG9jYXRp b24gd2FzIG5vdCByZWNlaXZlZCBieSB0aGUgVUFTIChpLmUuLCB0aGUgY2FsbGVkDQogICBwYXJ0 eSkuDQoNCi0tTWFydGluDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTog Z2VvcHJpdi1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86Z2VvcHJpdi1ib3VuY2VzQGlldGYub3Jn XSBPbg0KPiBCZWhhbGYgT2YgSGFubmVzIFRzY2hvZmVuaWcNCj4gU2VudDogV2VkbmVzZGF5LCAy OSBKdWx5IDIwMDkgODoyNCBQTQ0KPiBUbzogJ0dvbnphbG8gQ2FtYXJpbGxvJzsgJ1NJUENPUkUn DQo+IENjOiBnZW9wcml2QGlldGYub3JnDQo+IFN1YmplY3Q6IFJlOiBbR2VvcHJpdl0gW3NpcGNv cmVdIFdHTEM6ZHJhZnQtaWV0Zi1zaXBjb3JlLWxvY2F0aW9uLQ0KPiBjb252ZXlhbmNlLTAxLnR4 dA0KPiANCj4gSGkgR29uemFsbywNCj4gSGkgSmFtZXMsIEhpIEJyaWFuLA0KPiANCj4gSSBoYXZl IGRvbmUgYSByZXZpZXcgb2YgdGhlIFNJUCBMb2NhdGlvbiBDb252ZXlhbmNlIGFscmVhZHkgZWFy bGllcg0KPiB0aGlzDQo+IHllYXIgKGluIE1hcmNoIDIwMDkpLA0KPiBzZWUgaHR0cDovL3d3dy5p ZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL2dlb3ByaXYvY3VycmVudC9tc2cwNjk1NS5odG1sLg0K PiBJDQo+IHJlLWRpZCBpdA0KPiBmb3IgaHR0cDovL3d3dy5pZXRmLm9yZy9pZC9kcmFmdC1pZXRm LXNpcGNvcmUtbG9jYXRpb24tY29udmV5YW5jZS0NCj4gMDEudHh0Lg0KPiANCj4gKiBJIGJlbGll dmUgdGhhdCB0aGUgZG9jdW1lbnQgc2hvdWxkIHRyeSB0byBhdm9pZCB0aGUgdGVybSAidXNpbmcN Cj4gcHJvdG9jb2wiDQo+IGF0IGFsbCBjb3N0cy4NCj4gQXMgd2Uga25vdywgdGhpcyB0ZXJtIGlz IHZlcnkgY29uZnVzaW5nIGFuZCBhZGRzIG5vIHBhcnRpY3VsYXIgdmFsdWUuDQo+IA0KPiBFeGFt cGxlOiBPdGhlciBwcm90b2NvbHMgdXNlZCBpbiB0aGUgTG9jYXRpb24gVVJJIE1VU1QgYmUgcmV2 aWV3ZWQNCj4gYWdhaW5zdCB0aGUgUkZDIDM2OTMgY3JpdGVyaWEgZm9yIGEgVXNpbmcgUHJvdG9j b2wuDQo+IA0KPiBJbiBodW1hbiByZWFkYWJsZSBsYW5ndWFnZSB0aGlzIG1lYW5zOiAiWW91IGhh dmUgdG8gY29uc2lkZXIgc2VjdXJpdHkNCj4gYW5kDQo+IHByaXZhY3kgd2l0aCBuZXcgZXh0ZW5z aW9ucy4iIFdvdy4gV2hhdCBhIHN1cnByaXNpbmcgc3RhdGVtZW50IQ0KPiANCj4gKiBEb24ndCB1 bmRlcnN0YW5kIHdoeSB0aGlzIGRvY3VtZW50IGRvZXMgbm90IGFsbG93IGEgSEVMRCBVUkkgdG8g YmUNCj4gY29udmV5ZWQuIEkgY29tbWVudGVkIHRoaXMgYWxyZWFkeSBzZXZlcmFsIHRpbWVzLg0K PiANCj4gRXZlbiB0aGUgSUFOQSByZWdpc3RyeSBhcHBlYXJzIHVubmVjZXNzYXJ5IGZvciBtZS4g WW91IGhhdmUgZXJyb3INCj4gbWVzc2FnZXMNCj4gZGVmaW5lZA0KPiBmb3IgdGhlIGNhc2VzIHdo ZXJlIHRoZSBVUkkgaXNuJ3QgdW5kZXJzdG9vZC4NCj4gVGhlcmUgYXJlbid0IHRvbyBtYW55IG5l dyBwcm90b2NvbHMgdG8gYmUgZXhwZWN0ZWQuDQo+IA0KPiAqIEJhc2VkIG9uIHRoZSBvdGhlciBs aXN0IGRpc2N1c3NzaW9ucyBhcm91bmQgdGhpcyBkcmFmdCBJIHN1c3BlY3QgdGhhdA0KPiBpbmZv cm1hdGlvbg0KPiBhYm91dCB3aGF0IHRoZSBsb2NhdGlvbiByZWZlcnMgdG8gd2lsbCBiZSBkZXNj cmliZWQgaW4gYSBmdXR1cmUgdmVyc2lvbg0KPiBvZg0KPiB0aGUgZG9jdW1lbnQuDQo+IA0KPiAq IFRoaXMgZG9jdW1lbnQgaXMgYWJvdXQgdGhlIHRyYW5zcG9ydCBvZiBhIFBJREYtTE8gYW5kIG5v dCBhYm91dA0KPiBkZXNjcmliaW5nDQo+IA0KPiB3aGF0IGRlcGxveW1lbnRzIHNob3VsZCBkby4N Cj4gDQo+IEV4YW1wbGU6DQo+ICINCj4gICAgQWRkaW5nIGEgbmV3IGxvY2F0aW9uVmFsdWUgdG8g YW4gaW4tdHJhbnNpdCByZXF1ZXN0IFNIT1VMRCBOT1QNCj4gICAgb2NjdXIgZm9yIGF0IGxlYXN0 IHR3byByZWFzb25zLA0KPiANCj4gICAgIzEgLSBTSVAgU2VydmVycyBhcmUgbm90IHRoZSBiZXN0 IFNpZ2h0ZXJzLCBhcyBkZWZpbmVkIGJ5IFtSRkMzNjkzXSwNCj4gICAgICAgICBvZiBnZW9ncmFw aGljYWxseSB3aGVyZSBhIFVBQyBjYW4gYmU7IG1lYW5pbmcgdGhlIGxvY2F0aW9uDQo+ICAgICAg ICAgaW5mb3JtYXRpb24gaXMgbm90IG5lY2Vzc2FyaWx5IHRoZSBncmVhdGVzdC4gIFRoZXJlIE1B WSBiZQ0KPiAgICAgICAgIGV4Y2VwdGlvbnMsIGJ1dCB0aGlzIFNIT1VMRCBiZSB0aGUgcnVsZSBv ZiB0aHVtYi4NCj4gDQo+ICAgICMyIC0gd2l0aG91dCBhcHByb3ByaWF0ZSBjYXV0aW9uIHRvIHRo ZSBmYWN0IHRoYXQgTG9jYXRpb24NCj4gICAgICAgICBSZWNpcGllbnRzIG1pZ2h0IG5vdCB1bmRl cnN0YW5kIGhvdyB0byBwcm9jZXNzIG1vcmUgdGhhbiBvbmUNCj4gICAgICAgICBsb2NhdGlvbiwg Z2l2ZW4gdGhpcyBkb2N1bWVudCdzIGxpbWl0ZWQgZ3VpZGFuY2UgYXMgdG8gd2hhdCBhDQo+ICAg ICAgICAgTG9jYXRpb24gUmVjaXBpZW50IHNob3VsZCBkbyB3aGVuIHJlY2VpdmluZyBtb3JlIHRo YW4gb25lDQo+ICAgICAgICAgbG9jYXRpb24gIChpLmUuLCBjdXJyZW50bHkgbm8gcHJpb3JpdHkg aW5zdHJ1Y3Rpb25zIGFyZSBnaXZlbg0KPiAgICAgICAgIGZvciB3aGljaCBsb2NhdGlvblZhbHVl IHRvIHVzZSBpZiB0aGVyZSBhcmUgbW9yZSB0aGFuIG9uZSkuICBBDQo+ICAgICAgICAgTG9jYXRp b24gUmVjaXBpZW50IGNhbiBlYXNpbHkgYmUgY29uZnVzZWQgYnkgdG9vIG11Y2ggbG9jYXRpb24N Cj4gICAgICAgICBpbmZvcm1hdGlvbiwgcHJvZHVjaW5nIHVuZGVzaXJhYmxlIHJlc3VsdHMuICBU aGUgPHR1cGxlIGlkPg0KPiAgICAgICAgIGVsZW1lbnQgaW4gdGhlIFBJREYtTE8gWE1MIGluZGlj YXRlcyB3aG9zZSBsb2NhdGlvbiBpcw0KPiAgICAgICAgIGNvbnRhaW5lZCBpbiB0aGUgUElERi1M Ty4NCj4gIg0KPiANCj4gVGhpcyBleGFtcGxlIGFsc28gc2hvd3MgaW5hcHByb3ByaWF0ZSB1c2Fn ZSBvZiBSRkMyMTE5IGxhbmd1YWdlLCB3aGljaA0KPiBzaG91bGQNCj4gYmUgdXNlZCBmb3IgaW50 ZXJvcGVyYWJpbGl0eS4NCj4gDQo+IFdlIGtub3cgd2hvIHdhbnRzIHNvbWUgb2YgdGhpcyBmdW5j dGlvbmFsaXR5IGFuZCB3aGF0IHRoZSBleGFjdCB1c2UNCj4gY2FzZSBpdC4NCj4gDQo+IEJ0dywg dGhlIHRlcm0gInNpZ2h0ZXIiIGlzIG5vdCBkZWZpbmVkIGFueXdheSAoYW5kIG5vdCBpbiBSRkMz NjkzDQo+IGVpdGhlcikuDQo+IEhlcmUgaXMgdGhlIHJlbGV2YW50IHRleHQgcGFydDoNCj4gDQo+ ICAgIFRoaXMgZG9jdW1lbnQgZ2l2ZXMgbm8gZ3VpZGFuY2UgaG93IHRoaXMgaXMgYWNjb21wbGlz aGVkLCBnaXZlbiB0aGUNCj4gICAgbnVtYmVyIG9mIHdheXMgYSBVQUMgY2FuIGxlYXJuIGl0cyBs b2NhdGlvbiwgb3IgYSBTSVAgaW50ZXJtZWRpYXJ5DQo+ICAgIGNhbiAqKlNpZ2h0KiogYSBVQUMs IGFzIGRlZmluZWQgaW4gW1JGQzM2OTNdLg0KPiANCj4gKiBJbiBteSBwcmV2aW91cyByZXZpZXcg SSBjb21wbGFpbmVkIGFib3V0IHRoZSBlcnJvciBjb2RlcyBhbmQgdGhlDQo+IHRob3VnaHQNCj4g dGhhdCB3ZW50IGludG8gdGhlbS4NCj4gSSB3YXMgd29uZGVyaW5nIHdoZXRoZXIgc29tZW9uZSAo bWF5YmUgdGhlIGF1dGhvcnM/KSBoYXMgaW1wbGVtZW50ZWQNCj4gdGhpcw0KPiBzcGVjaWZpY2F0 aW9uIGluIHRoZSBtZWFud2hpbGUgYW5kIGhhcyBnYWluZWQgc29tZQ0KPiBleHBlcmllbmNlIHdp dGggdGhlIGVycm9yIGhhbmRsaW5nIGFscmVhZHkuIEFyZSB0aGUgZXJyb3IgY29kZXMNCj4gc3Vm ZmllbnQ/DQo+IFdlbGwgZW5vdWdoIGRlc2NyaWJlZD8NCj4gDQo+ICogSSBtaWdodCBiZSB0b28g dGlyZWQgdG9kYXkgYWxyZWFkeSBidXQgdGhlIGV4YW1wbGUgc2hvd24gaW4gU2VjdGlvbg0KPiA1 LjENCj4gc2VlbXMgdG8gYmUgd3JvbmcuDQo+IA0KPiBJdCBzYXlzOg0KPiANCj4gIg0KPiAuLi4N Cj4gPGdwOmxvY2F0aW9uLWluZm8+DQo+ICAgICAgICAgICAgICAgPGdtbDpsb2NhdGlvbj4NCj4g ICAgICAgICAgICAgICAgIDxnbWw6UG9pbnQgc3JzTmFtZT0idXJuOm9nYzpkZWY6Y3JzOkVQU0c6 OjQzMjYiPg0KPiAgICAgICAgICAgICAgICAgICA8Z21sOnBvcz4zMy4wMDExMTEgLTk2LjY4MTQy PC9nbWw6cG9zPg0KPiAgICAgICAgICAgICAgICAgPC9nbWw6UG9pbnQ+DQo+ICAgICAgICAgICAg ICAgIDwvZ21sOmxvY2F0aW9uPg0KPiAgICAgICAgICAgICA8L2dwOmxvY2F0aW9uLWluZm8+DQo+ IC4uLg0KPiAiDQo+IA0KPiBJdCBzaG91bGQgc2F5Og0KPiANCj4gIg0KPiAuLi4NCj4gPGdwOmxv Y2F0aW9uLWluZm8+DQo+ICAgICAgICAgICAgICAgICA8Z21sOlBvaW50IHNyc05hbWU9InVybjpv Z2M6ZGVmOmNyczpFUFNHOjo0MzI2Ij4NCj4gICAgICAgICAgICAgICAgICAgPGdtbDpwb3M+MzMu MDAxMTExIC05Ni42ODE0MjwvZ21sOnBvcz4NCj4gICAgICAgICAgICAgICAgIDwvZ21sOlBvaW50 Pg0KPiAgICAgICAgICAgICA8L2dwOmxvY2F0aW9uLWluZm8+DQo+IC4uLg0KPiAiDQo+IA0KPiAN Cj4gKg0KPiAiDQo+ICAgIFVzZSBvZiBzZWxmLXNpZ25lZCBjZXJ0aWZpY2F0ZXMgaXMgaW5hcHBy b3ByaWF0ZSBmb3IgdXNlIGluDQo+ICAgIHByb3RlY3RpbmcgYSBQSURGLCBhcyB0aGUgc2VuZGVy IGRvZXMgbm90IGhhdmUgYSBzZWN1cmUgaWRlbnRpdHkgb2YNCj4gICAgdGhlIHJlY2lwaWVudC4N Cj4gIg0KPiANCj4gIFRoaXMgc2VudGVuY2UgZG9lcyBub3QgbWFrZSBhIGxvdCBvZiBzZW5zZSB0 byBtZS4gWW91IGNhbiB1c2Ugc2VsZi0NCj4gc2lnbmVkDQo+ICBjZXJ0aWZpY2F0ZXMgZm9yIHBy b3RlY3RpbmcgYSBQSURGIGJlZm9yZSBzZW5kaW5nIGl0IHRvIG1lLg0KPiAgVGhlIGltcG9ydGFu dCB0aGluZyBpcyB0byBtYWtlIHlvdXIgc2VsZi1zaWduZWQgY2VydCBhdmFpbGFibGUgdG8gbWUu DQo+IA0KPiAqIFRoaXMgZG9jdW1lbnQgZG9lcyBub3QgbmVlZCB0byByZXBlYXQgdGhlIHRleHQg ZnJvbSBvdGhlciBkb2N1bWVudHMuDQo+IEV4YW1wbGU6DQo+ICAgICINCj4gICAgV2hlbiB1c2lu ZyBMYnlSLCB0aGUgbG9jYXRpb24gVVJJIE1VU1QgTk9UIGNvbnRhaW4gYW55IHVzZXINCj4gICAg aWRlbnRpZnlpbmcgaW5mb3JtYXRpb24uIEZvciBleGFtcGxlLCB1c2Ugc29tZXRoaW5nIHVuaWRl bnRpZmlhYmxlDQo+ICAgIGxpa2UNCj4gICAgIg0KPiANCj4gICBBbHJlYWR5IGluIHRoZSBMYnlS IHJlcXVpcmVtZW50cyBkb2N1bWVudC4gUmVmZXJlbmNlIGl0IC0tIG5vIG5lZWQgdG8NCj4gd3Jp dGUgbmV3IHRleHQuIFRoYXQncyB3aHkgd2UgaGF2ZSB3cml0dGVuIHRoZXNlIG90aGVyIGRvY3Vt ZW50cy4NCj4gDQo+IA0KPiAqICINCj4gSWYgdGhlIExvY2F0aW9uIEdlbmVyYXRvciB3aXNoZXMg dG8gY29udHJvbCB3aGV0aGVyIGFueSBsb2NhdGlvbg0KPiAgICBpbmNsdWRlZCBpbiB0aGUgU0lQ IHJlcXVlc3Qgb3IgYWRkZWQgYWxvbmcgdGhlIHNpZ25hbGluZyBwYXRoIG9mDQo+ICAgIHRoaXMg cmVxdWVzdCBjYW4gYmUgdmlld2VkIGZvciByb3V0aW5nIGRlY2lzaW9ucywgdGhlIExvY2F0aW9u DQo+ICAgIEdlbmVyYXRvciBhZGRzIGEgR2VvbG9jYXRpb24gaGVhZGVyIHZhbHVlIGluY2x1ZGlu ZyB0aGUNCj4gICAgInJvdXRpbmctYWxsb3dlZD1ubyIgcGFyYW1ldGVyLg0KPiAiDQo+IA0KPiBS ZXBsYWNlICJMb2NhdGlvbiBHZW5lcmF0b3IiIGJ5ICJSdWxlIE1ha2VyIi4NCj4gDQo+ICogUmVt b3ZlIHVzZWxlc3Mgc3RhdGVtZW50cy4gRXhhbXBsZToNCj4gICAiDQo+ICAgIFVubGVzcyBzdGF0 ZWQgb3RoZXJ3aXNlIGJ5IGZ1dHVyZSBzdGFuZGFyZHMtdHJhY2sgcHVibGljYXRpb24ocyksIGEN Cj4gICAgTGJ5UiBVUkkgb25seSBoYXMgbWVhbmluZyB3aXRoaW4gdGhlIEdlb2xvY2F0aW9uIGhl YWRlciBmaWVsZCBhbmQNCj4gICAgTVVTVCBOT1QgYXBwZWFyIGluIGFueSBvdGhlciBTSVAgaGVh ZGVyIGZpZWxkLg0KPiAgICINCj4gDQo+ICogQXZvaWQgYXV0aG9yIGJpYXMuIEV4YW1wbGU6DQo+ IA0KPiAiUHJveGllcyBpbnNlcnRpbmcgbG9jYXRpb24gZm9yIGxvY2F0aW9uLWJhc2VkIHJvdXRp bmcgYXJlDQo+ICAgIHVuYWJsZSB0byBtZWV0IHRoaXMgcmVxdWlyZW1lbnQsIGFuZCBzdWNoIHVz ZSBpcyBOT1QgUkVDT01NRU5ERUQuIg0KPiANCj4gVGhlIGRvY3VtZW50IGRlZmluZXMgZnVuY3Rp b25hbGl0eSB0byBhbGxvdyB0aGUgcHJveHkgdG8gYWRkIGxvY2F0aW9uDQo+IGFuZCB3ZQ0KPiBr bm93IHdobyBpcyBnb2luZyB0byB1c2UgdGhpcy4NCj4gDQo+IFRoZSB0ZXh0IGZ1cnRoZXIgc2F5 czoNCj4gICAgIg0KPiAgICBQcm94aWVzDQo+ICAgIGNvbnZleWluZyBsb2NhdGlvbiB1c2luZyB0 aGlzIGV4dGVuc2lvbiBNVVNUIGhhdmUgdGhlIHBlcm1pc3Npb24gb2YNCj4gICAgdGhlIFRhcmdl dCB0byBkbyBzby4NCj4gICAgIg0KPiBJcyBhIFNlcnZpY2UgVVJOIHdpdGggYSBzZXJ2aWNlOnNv cyBwYXJhbWV0ZXIgZ29vZCBlbm91Z2ggYXMgYQ0KPiBwZXJtaXNzaW9uPw0KPiBPciB3aGF0ICoq cGVybWlzc2lvbioqIG1lY2hhbmlzbSBhcmUgeW91IHRoaW5rIGFib3V0Pw0KPiANCj4gKg0KPiAi DQo+IEFueSBpZGVhIG9mIHVzaW5nIFNJUCBJZGVudGl0eSBpcyBsb3N0IGFzIHNvb24gYXMgaXQg aXMNCj4gICAgcmVhbGl6ZWQgdGhhdCB0aGUgR2VvbG9jYXRpb24gaGVhZGVyIHZhbHVlIGNhbiBi ZSBhZGRlZCB0byBieQ0KPiAgICBpbnRlcm1lZGlhcmllcyBpbiB0aGUgc2lnbmFsaW5nIHBhdGgu DQo+ICINCj4gDQo+IFRoYXQncyBub3QgdGhlIHByb2JsZW0uIFRoZSBwcm9ibGVtIGlzIHRoYXQg dGhlIHNpZ25hdHVyZSBjYWxjdWxhdGlvbg0KPiBvZiBTSVANCj4gSWRlbnRpdHkNCj4gZG9lcyBu b3QgY292ZXIgdGhlc2UgbmV3IGhlYWRlcnMuDQo+IA0KPiAqIEkgbGlrZSB0aGlzIGFja25vd2xl ZGdlbWVudCAiVG8gRGF2ZSBPcmFuIGZvciBoZWxwaW5nIHRvIHNoYXBlIHRoaXMNCj4gaWRlYS4i DQo+IA0KPiBUaGUgaWRlYSB0aGF0IGxvY2F0aW9uIGNhbiBiZSBjYXJyaWVkIGluIFNJUD8NCj4g DQo+ICogR2VvcHJpdiBQcml2YWN5IENvbnNpZGVyYXRpb25zDQo+IA0KPiBUaGlzIHNlY3Rpb24g aXMgcHJldHR5IHVzZWxlc3MgYnV0IEkgd2FudGVkIHRvIGFzayBvbmUgdGhpbmcgYWJvdXQgdGhl DQo+IGZvbGxvd2luZyB0ZXh0Og0KPiANCj4gIg0KPiAgICBRdW90aW5nIHJlcXVpcmVtZW50ICM0 IG9mIFtSRkMzNjkzXToNCj4gDQo+ICAgICJUaGUgVXNpbmcgUHJvdG9jb2wgaGFzIHRvIG9iZXkg dGhlIHByaXZhY3kgYW5kIHNlY3VyaXR5DQo+ICAgICBpbnN0cnVjdGlvbnMgY29kZWQgaW4gdGhl IExvY2F0aW9uIE9iamVjdCBhbmQgaW4gdGhlDQo+ICAgICBjb3JyZXNwb25kaW5nIFJ1bGVzIHJl Z2FyZGluZyB0aGUgdHJhbnNtaXNzaW9uIGFuZCBzdG9yYWdlDQo+ICAgICBvZiB0aGUgTE8uIg0K PiANCj4gICAgVGhpcyBkb2N1bWVudCByZXF1aXJlcyB0aGF0IFNJUCBlbnRpdGllcyBzZW5kaW5n IG9yIHJlY2VpdmluZw0KPiAgICBsb2NhdGlvbiBNVVNUIG9iZXkgc3VjaCBpbnN0cnVjdGlvbnMu DQo+ICINCj4gDQo+IFdoYXQgYWJvdXQgYSBTSVAgbm9kZSB0aGF0IGRvZXMgbm90IHVuZGVyc3Rh bmQgU0lQIGxvY2F0aW9uIGNvbnZleWFuY2U/DQo+IEl0IHNlbmRzIGFuZCByZWNlaXZlcyB0aGUg bWVzc2FnZXMgcmVsYXRlZCB0byBsb2NhdGlvbiBtZXNzYWdlcy4NCj4gDQo+IA0KPiAqIEF2b2lk IGluYXBwcm9wcmlhdGUgdHJlYXRtZW50IG9mIHN1YmplY3RzIHRoYXQgYXJlIGRpc2N1c3NlZA0K PiBzb21ld2hlcmUNCj4gZWxzZS4gWW91IGRpc2N1c3MgdG9waWNzIHRoYXQgaGF2ZSBiZWVuIGRl c2NyaWJlZCBlbHNld2hlcmUgYW5kIGFyZQ0KPiB0aGVyZWZvcmUNCj4gY2xlYXJseSBvdXRzaWRl IHRoZSBzY29wZSBvZiB0aGlzIGRvY3VtZW50Lg0KPiANCj4gIg0KPiAgICBPbmUgZmFjZXQgd2l0 aGluIHRoaXMgZXh0ZW5zaW9uIGlzIHN1Y2ggdGhhdCBsb2NhdGlvbnMgY2FuIGJlIHBsYWNlZA0K PiAgICBvbiBhIHJlbW90ZSBzZXJ2ZXIsIGFjY2Vzc2libGUgd2l0aCB0aGUgcG9zc2Vzc2lvbiBv ZiBhIFVSSS4gIFRoZQ0KPiAgICBjb25jZXB0IG9mIGFuIExieVIgVVJJIGhhcyBpdHMgb3duIHNl Y3VyaXR5IGNvbnNpZGVyYXRpb25zLiAgSXQgaXMNCj4gICAgdGVtcHRpbmcgdG8gYXNzdW1lIHRo YXQgdGhlIGRlcmVmZXJlbmNlIHdvdWxkIGhhdmUgYXV0aGVudGljYXRpb24sDQo+ICAgIGF1dGhv cml6YXRpb24gYW5kIG90aGVyIHNlY3VyaXR5IG1lY2hhbmlzbXMgdGhhdCBsaW1pdCB0aGUgYWNj ZXNzIHRvDQo+ICAgIGluZm9ybWF0aW9uLiAgVW5mb3J0dW5hdGVseSwgdGhpcyBtaWdodCBub3Qg YmUgdHJ1ZS4gIFRoZSBhY2Nlc3MNCj4gICAgbmV0d29yayB0aGUgVUFDIGlzIGNvbm5lY3RlZCB0 byBjYW4gYmUgdGhlIHNvdXJjZSBvZiBsb2NhdGlvbg0KPiAgICByZWZlcmVuY2UsIGFuZCBpdCBt aWdodCBub3QgaGF2ZSBhbnkgY3JlZGVudGlhbGluZyBtZWNoYW5pc20NCj4gICAgc3VpdGFibGUg Zm9yIGNvbnRyb2xsaW5nIGFjY2VzcyB0byBsb2NhdGlvbi4gIENvbnNpZGVyLA0KPiAgICBzcGVj aWZpY2FsbHksIGEgbm9tYWRpYyB1c2VyIGNvbm5lY3RlZCB0byBhbiBhY2Nlc3MgbmV0d29yayBp biBhDQo+ICAgIGhvdGVsLiAgVGhlIFVBQyBoYXMgbm8gd2F5IHRvIHByb3ZpZGUgYSBjcmVkZW50 aWFsIGFjY2VwdGFibGUgdG8NCj4gICAgdGhlIGhvdGVsIExvY2F0aW9uIFNlcnZlciAoTFMpIHRv IGFueSBvZiBpdHMgaW50ZW5kZWQgTG9jYXRpb24NCj4gICAgUmVjaXBpZW50cy4gIFRoZSByZWNp cGllbnQgb2YgYSByZWZlcmVuY2UgZG9lcyBub3Qga25vdyBpZiBhDQo+ICAgIHJlZmVyZW5jZSBo YXMgYXBwcm9wcmlhdGUgYXV0aG9yaXphdGlvbiBwb2xpY2llcyBvciBub3QuICBUaGUgTFMNCj4g ICAgc2hvdWxkIHByb3ZpZGUgbG9jYXRpb24gdG8gYW55IHJlcXVlc3Rvci4NCj4gIg0KPiANCj4g KiBJIGZvdW5kIHRoaXMgcGFyYWdyYXBoIGluIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uIHNl Y3Rpb25zLiBJdA0KPiBtb3JlDQo+IG9yIGxlc3MgYXJndWVzIHRoYXQgdGhlIGF1dGhvcml6YXRp b24gbW9kZWwgYmFzZWQgb24gYWNjZXNzIGNvbnRyb2wNCj4gZG9lcw0KPiBub3Qgd29yayBpbiBh IG51bWJlciBvZiBjYXNlcy4gVGhpcyBpcyBzb3J0IG9mIGludGVyZXN0aW5nLCBpZiBvbmUNCj4g YWRkaXRpb25hbCBjb25zaWRlcnMgdGhlIG90aGVyIHdvcmsgdGhhdCBpcyBiZWluZyBkb25lIGlu IEdFT1BSSVYgd2l0aA0KPiB0aGUNCj4gREhDUC1VUkkgZG9jdW1lbnQgd2hlcmUgdGhlIGFyZ3Vt ZW50IGdvZXMgaW50byB0aGUgb3Bwb3NpdGUgZGlyZWN0aW9uLg0KPiANCj4gIg0KPiAgICBCZWNh dXNlIHRhcmdldCBsb2NhdGlvbnMgY2FuIGJlIHBsYWNlZCBvbiBhIHJlbW90ZSBzZXJ2ZXIsIGNh bGxlZCBhDQo+ICAgIExvY2F0aW9uIFNlcnZlciBhY2Nlc3NpYmxlIHdpdGggdGhlIHBvc3Nlc3Np b24gb2YgYSBsb2NhdGlvbiBVUkksDQo+ICAgIHRoaXMgVVJJIGhhcyBpdHMgb3duIHNlY3VyaXR5 IGNvbnNpZGVyYXRpb25zLiAgSXQgaXMgdGVtcHRpbmcgdG8NCj4gICAgYXNzdW1lIHRoYXQgdGhl IGRlcmVmZXJlbmNlIG9mIHRoaXMgVVJJIHdvdWxkIGhhdmUgYXV0aGVudGljYXRpb24sDQo+ICAg IGF1dGhvcml6YXRpb24gYW5kIG90aGVyIHNlY3VyaXR5IG1lY2hhbmlzbXMgdGhhdCBsaW1pdCB0 aGUgYWNjZXNzIHRvDQo+ICAgIGluZm9ybWF0aW9uLiAgVW5mb3J0dW5hdGVseSwgdGhpcyBtaWdo dCBub3QgYmUgdHJ1ZS4gIFRoZSBhY2Nlc3MNCj4gICAgbmV0d29yayB0aGUgVUFDIGlzIGNvbm5l Y3RlZCB0byBjYW4gYmUgdGhlIHNvdXJjZSBvZiBsb2NhdGlvbg0KPiAgICByZWZlcmVuY2UsIGFu ZCBpdCBtaWdodCBub3QgaGF2ZSBhbnkgY3JlZGVudGlhbGluZyBtZWNoYW5pc20NCj4gICAgc3Vp dGFibGUgZm9yIGNvbnRyb2xsaW5nIGFjY2VzcyB0byBhIHRhcmdldCdzIGxvY2F0aW9uLiAgQ29u c2lkZXIsDQo+ICAgIHNwZWNpZmljYWxseSwgYSBub21hZGljIHVzZXIgY29ubmVjdGVkIHRvIGFu IGFjY2VzcyBuZXR3b3JrIGluIGENCj4gICAgaG90ZWwuICBUaGUgVUFDIGhhcyBubyB3YXkgdG8g cHJvdmlkZSBhIGNyZWRlbnRpYWwgYWNjZXB0YWJsZSBvZiB0aGUNCj4gICAgaG90ZWwgTG9jYXRp b24gU2VydmVyIChMUykgdG8gYW55IG9mIGl0cyBpbnRlbmRlZCBMb2NhdGlvbg0KPiAgICBSZWNp cGllbnRzLiAgVGhlIHJlY2lwaWVudCBvZiBhIHJlZmVyZW5jZSBkb2VzIG5vdCBrbm93IGlmIGEN Cj4gICAgcmVmZXJlbmNlIGhhcyBhcHByb3ByaWF0ZSBhdXRob3JpemF0aW9uIHBvbGljaWVzIG9y IG5vdC4NCj4gIg0KPiANCj4gSSBhbSBzdXJlIHRoZSBzZWN1cml0eSBjb25zaWRlcmF0aW9uIHNl Y3Rpb24gd2lsbCBnZXQgc29tZSBtb3JlDQo+IGZlZWRiYWNrDQo+IGFzIHRoZSBkb2N1bWVudCBt b3ZlcyBhbG9uZy4gSWYgeW91IHJlYWQgdGhyb3VnaCBpdCBlc3NlbnRpYWxseQ0KPiBwcm92aWRl cw0KPiB0aGUgZm9sbG93aW5nIHN0b3J5Og0KPiANCj4gICAgLSBDb252ZXlpbmcgbG9jYXRpb24g aXMgcHJpdmFjeSBzZW5zaXRpdmUgYW5kIGhlbmNlIHRoZSB0cmFuc3BvcnQNCj4gICAgICBoYXMg dG8gYmUgcHJvdGVjdGVkLg0KPiAJID09PiBVc2UgUy9NSU1FDQo+ICAgIC0gV2VsbCwgeW91IGNh bm5vdCByZWFsbHkgdXNlIFMvTUlNRSBzaW5jZSBpdCBpc24ndCBkZXBsb3llZC4NCj4gICAgICA9 PT4gVXNlIFRMUyBob3AtYnktaG9wLg0KPiAgICAtIFRMUyBpc24ndCBnb29kIGVpdGhlciBzaW5j ZSB0aGUgU0lQIGhvcHMgc2VlIHRoZSBsb2NhdGlvbiBhbmQNCj4gICAgICB0aGVuIHRoZXJlIGlz IGFsc28gcmV0YXJnZXRpbmcuIFRoZSBlbmQgaG9zdCBkb2VzIG5vdCBrbm93DQo+IAkgdGhlIGlu dGVybWVkaWEgU0lQIHByb3hpZXMgZWl0aGVyIHNvIGhlIG1pZ2h0IG5vdCB0cnVzdCB0aGVtLg0K PiAgICAgID09PiBVc2UgYW4gdW5saW5rYWJsZSBwc2V1ZG9ueW0gYnkgcGxhY2luZyBnYXJiYWdl IGluIHRoZQ0KPiAJIGVudGl0eSBhdHRyaWJ1dGUgb2YgdGhlIFBJREYgZG9jdW1lbnQuDQo+ICAg IC0gV2VsbC4gVGhhdCBkb2VzIG5vdCB3b3JrIGVpdGhlci4NCj4gICAgICA9PT4gSGVyZSBpcyB0 aGUgc29sdXRpb246IFdlIGp1c3QgbGV0IHRoZSBVQSBkZWNpZGUgd2hhdCB0b2RvLiBBbmQNCj4g ICAgICB0aGVyZSBTSE9VTEQgYmUgYSB3YXkgdG8gYXNrIGZvciB1c2VyIGNvbnNlbnQuIFVzZXJz IG1ha2UgZ29vZA0KPiAJIGRlY2lzaW9ucyENCj4gDQo+IEkgd291bGQgcHJlc2VudCB0aGUgc3Rv cnkgZGlmZmVyZW50bHk6DQo+IA0KPiBGaXJzdCwgdGhlcmUgYXJlIDIgaW1wb3J0YW50IGFzcGVj dHMgdG8gZGlmZmVyZW50aWF0ZSBmcm9tIGEgc2VjdXJpdHkNCj4gcG9pbnQNCj4gb2Ygdmlldywg bmFtZWx5Og0KPiAxKSBMb2NhdGlvbiBCYXNlZCBSb3V0aW5nDQo+IDIpIE5vbi1Mb2NhdGlvbiBC YXNlZCBSb3V0aW5nDQo+IA0KPiBXaXRoIGxvY2F0aW9uIGJhc2VkIHJvdXRpbmcgdGhlIGlkZWEg aXMgdGhhdCBpbnRlcm1lZGFyaWVzIHNlZSB0aGUNCj4gbG9jYXRpb24NCj4gc2luY2Ugb3RoZXJ3 aXNlDQo+IHRoZXkgY2Fubm90IHJvdXRlIGFjY29yZGluZyB0byBpdC4gU28sIGhvcC1ieS1ob3Ag VExTIGlzIHRoZSBiZXN0IHlvdQ0KPiBjYW4NCj4gZG8uIElmIHlvdSBkb24ndA0KPiBsaWtlIHRo ZSBjb25zZXF1ZW5jZXMgb2YgaXQgdGhlbiB5b3UgcmVhbGx5IG5lZWQgdG8gdXNlIHNvbWV0aGlu ZyBsaWtlDQo+IExvU1QNCj4gcHJpb3IgdG8gdGhlDQo+IFNJUCBleGNoYW5nZSB0byBkaXNjb3Zl ciB0aGUgZW50aXR5IHlvdSBuZWVkIHRvIHJvdXRlIHRvLg0KPiANCj4gV2l0aCBub24tbG9jYXRp b24gYmFzZWQgcm91dGluZyB5b3Ugd2lsbCBoYXZlIHByb2JsZW1zIHdpdGggcmV0YXJnZXRpbmcN Cj4gYW5kDQo+IGZvcmtpbmcuDQo+IFRoZSBnb29kIHRoaW5nIGlzIHRoYXQgbm9ib2R5IHNheXMg dGhhdCB5b3UgaGF2ZSB0byBzZW5kIGxvY2F0aW9uIHdpdGgNCj4gdGhlDQo+IGZpcnN0DQo+IG1l c3NhZ2UuIE1vc3QgZm9sa3MgbWlnaHQgdXNlIFRMUyBmb3Igc2lnbmFsaW5nIChob3BlZnVsbHkp IGFuZCBoZW5jZQ0KPiBhdA0KPiBsZWFzdCB5b3UgY2FuIGRlYWwgd2l0aA0KPiBlbnRpdGllcyB0 aGF0IGFyZSBlYXZlc2Ryb3BwaW5nICh1bmxlc3MgdGhleSBhcmUgU0lQIHNpZ25hbGluZw0KPiBl bGVtZW50cykuIElmDQo+IHlvdSBhcmUgd29ycmllZCBhYm91dA0KPiB0aGVzZSBlbnRpdGllcyBs aXN0ZW5pbmcgdG8gdGhlIGxvY2F0aW9uIGZseWluZyBieSwgdGhlbiB5b3Ugd2lsbCBoYXZlDQo+ IHRvDQo+IHVzZSBTL01JTUUuIFRvIG1ha2UgaXQNCj4gZGVwbG95YWJsZSB5b3UgY291bGQgdXNl IFNJUCBDRVJULg0KPiANCj4gV2hhdCBpcyBwcm9iYWJseSBtb3JlIGltcG9ydGFudCBmcm9tIGEg dGhyZWF0IHBvaW50IG9mIHZpZXcgaXMgdGhlDQo+IGFiaWxpdHkNCj4gdG8gb2JzZXJ2ZSBzb21l b25lJ3MNCj4gbW92ZW1lbnRzLiBUaGlzIHdvdWxkIGJlIHBvc3NpYmxlIGluIGEgcHJlc2VuY2Ug YmFzZWQgZW52aXJvbm1lbnQgKHdoZW4NCj4geW91DQo+IFBVQkxJU0ggeW91ciBsb2NhdGlvbg0K PiB0byBhIHByZXNlbmNlIC8gbG9jYXRpb24gc2VydmVyKS4gVGhlIGRyYWZ0IGRvZXMgcHJvdmlk ZSB0aGF0DQo+IGZ1bmN0aW9uYWxpdHksDQo+IGlmIEkgY29ycmVjdGx5DQo+IHVuZGVyc3RhbmQg aXQsIGJ1dCBkb2VzIG5vdCBkaXNjdXNzIGl0LiBUaGVyZSwgd2UgaGF2ZSBvdXIgcG9saWN5IHdv cmsNCj4gdGhhdA0KPiBkZWFscyB3aXRoIHRoaXMgcHJvYmxlbSwNCj4gbmFtZWx5IENvbW1vbiBQ b2xpY3kgYW5kIEdlb2xvY2F0aW9uIFBvbGljeS4NCj4gDQo+IEFkZGl0aW9uYWxseSwgb25lIG1p Z2h0IHdhbnQgdG8gbWVudGlvbiB0aGUgYXR0YWNoZWQgcG9saWNpZXMgdGhhdA0KPiB0cmF2ZWwN Cj4gd2l0aCBsb2NhdGlvbi4gWW91IGNvdWxkDQo+IGFsc28gcG9pbnQgdG8gdGhlIGxvYy1zZWMg YXJjaGl0ZWN0dXJlIGRvY3VtZW50IGZvciB0aGlzIHB1cnBvc2UgKGFzIGFuDQo+IGluZm9ybWF0 aXZlIHJlZmVyZW5jZSkuDQo+IElmIHlvdSBtZW50aW9uIHRoZXNlIHBvbGljaWVzIGluIHRoZSBz ZWN1cml0eSBjb25zaWRlcmF0aW9uIHNlY3Rpb24NCj4gdGhlbiB5b3UNCj4gY291bGQgYWxzbyBk ZWxldGUgdGhlDQo+ICJHZW9wcml2IFByaXZhY3kgQ29uc2lkZXJhdGlvbnMiIHNlY3Rpb24uDQo+ IA0KPiBGaW5hbGx5LCB5b3UgbWlnaHQgd2FudCB0byBzYXkgdGhhdCB0aGUgUElERi1MTyBpcyBv bmx5IGJvdW5kIHRvIHRoZQ0KPiBTSVANCj4gbWVzc2FnZSBpZiBTSVAgSWRlbnRpdHkgaXMNCj4g dXNlZCBhbmQgdGhlIGxvY2F0aW9uIGlzIGluIHRoZSBib2R5IG9mIHRoZSBtZXNzYWdlIGFzIHRo ZSBzaWduYXR1cmUNCj4gY29tcHV0YXRpb24gdXRpbGl6ZWQgYnkgU0lQDQo+IElkZW50aXR5IHdv dWxkIG5vdCBjb3ZlciBhbnkgb2YgdGhlIGhlYWRlciBmaWVsZHMuDQo+IA0KPiBCdHcsIEkgaGF2 ZSBwcm92aWRlZCB0ZXh0IGZvciB0aGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbiBzZWN0aW9uIGlu IHRoZQ0KPiBwYXN0DQo+IGFscmVhZHkuIEx1Y2tpbHkgaXQgd2FzDQo+IGtpbmRseSBpZ25vcmVk LiBTbywgZG9uJ3QgZXhwZWN0IG1lIHRvIHdyaXRlIGl0IGFnYWluLg0KPiANCj4gDQo+IENpYW8N Cj4gSGFubmVzDQo+IA0KPiA+LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPkZyb206IHNp cGNvcmUtYm91bmNlc0BpZXRmLm9yZw0KPiA+W21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5v cmddIE9uIEJlaGFsZiBPZiBHb256YWxvIENhbWFyaWxsbw0KPiA+U2VudDogMjAgSnVseSwgMjAw OSAxMDo1OQ0KPiA+VG86IFNJUENPUkUNCj4gPlN1YmplY3Q6IFtzaXBjb3JlXSBXR0xDOiBkcmFm dC1pZXRmLXNpcGNvcmUtbG9jYXRpb24tY29udmV5YW5jZS0wMS50eHQNCj4gPg0KPiA+Rm9sa3Ms DQo+ID4NCj4gPndlIHdvdWxkIGxpa2UgdG8gc3RhcnQgdGhlIFdHTEMgb2YgdGhlIGZvbGxvd2lu ZyBkcmFmdDoNCj4gPg0KPiA+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1z aXBjb3JlLWxvY2F0aW9uLWNvbnZleWFuY2UtMDENCj4gPg0KPiA+VGhpcyBXR0xDIHdpbGwgZW5k IG9uIEF1Z3VzdCA3dGguDQo+ID4NCj4gPk5vdGUgdGhhdCB0aGVyZSBhcmUgb25nb2luZyB0aHJl YWRzIGRpc2N1c3NpbmcgdGhpcyBkcmFmdCBvbiB0aGUgbGlzdC4NCj4gPlRoZSBpZGVhIGlzIHRv IHRha2UgdGhvc2UgY29tbWVudHMgYXMgV0dMQyBjb21tZW50cy4NCj4gPg0KPiA+QWxzbyBub3Rl IHRoYXQgd2UgaGF2ZSBhbm90aGVyIFdHTEMgaW4gcGFyYWxsZWwgYXQgdGhpcyBwb2ludA0KPiA+ KGluZm8gZXZlbnRzLCB3aG9zZSBXR0xDIGVuZHMgb24gSnVseSAyOXRoKS4gV2UgaGF2ZSBjaG9z ZW4gdG8NCj4gPmhhdmUgdGhpcyBwYXJ0aWFsIG92ZXJsYXAgYmV0d2VlbiB0aGUgdHdvIFdHTENz IGluIG9yZGVyIHRvDQo+ID50YWtlIGFkdmFudGFnZSBvZiB0aGUgZXh0cmEgY3ljbGVzIHBlb3Bs ZSBwdXQgaW4gb24gcmV2aWV3aW5nDQo+ID5kcmFmdHMgZHVyaW5nIHRoZSBwcmUtSUVURiB3ZWVr Lg0KPiA+R2l2ZW4gdGhhdCB3ZSBoYXZlIGNhbmNlbGVkIHRoZSBzZWNvbmQgU0lQQ09SRSBzZXNz aW9uIGluDQo+ID5TdG9ja2hvbG0sIHdlIGJlbGlldmUgdGhpcyBpcyBhIHJlYXNvbmFibGUgYW1v dW50IG9mIHdvcmsgZm9yDQo+ID5mb2xrcyBmb2xsb3dpbmcgdGhpcyBXRy4NCj4gPg0KPiA+S2Vp dGggd2lsbCBiZSB0aGUgUFJPVE8gc2hlcGhlcmQgZm9yIHRoaXMgZHJhZnQuDQo+ID4NCj4gPlRo YW5rcywNCj4gPg0KPiA+R29uemFsbw0KPiA+U0lQQ09SRSBjby1jaGFpcg0KPiA+DQo+ID5fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+c2lwY29yZSBt YWlsaW5nIGxpc3QNCj4gPnNpcGNvcmVAaWV0Zi5vcmcNCj4gPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPiA+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBHZW9wcml2IG1haWxpbmcgbGlzdA0KPiBH ZW9wcml2QGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v Z2VvcHJpdg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRoaXMg bWVzc2FnZSBpcyBmb3IgdGhlIGRlc2lnbmF0ZWQgcmVjaXBpZW50IG9ubHkgYW5kIG1heQ0KY29u dGFpbiBwcml2aWxlZ2VkLCBwcm9wcmlldGFyeSwgb3Igb3RoZXJ3aXNlIHByaXZhdGUgaW5mb3Jt YXRpb24uICANCklmIHlvdSBoYXZlIHJlY2VpdmVkIGl0IGluIGVycm9yLCBwbGVhc2Ugbm90aWZ5 IHRoZSBzZW5kZXINCmltbWVkaWF0ZWx5IGFuZCBkZWxldGUgdGhlIG9yaWdpbmFsLiAgQW55IHVu YXV0aG9yaXplZCB1c2Ugb2YNCnRoaXMgZW1haWwgaXMgcHJvaGliaXRlZC4NCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KW21mMl0NCg== From shin@softfront.co.jp Thu Jul 30 02:17:48 2009 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 CA0D328C284 for ; Thu, 30 Jul 2009 02:17:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 4.085 X-Spam-Level: **** X-Spam-Status: No, score=4.085 tagged_above=-999 required=5 tests=[AWL=1.952, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, UNPARSEABLE_RELAY=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 GlZHgvx8D4Lw for ; Thu, 30 Jul 2009 02:17:48 -0700 (PDT) Received: from mail2.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with SMTP id B34A328C28C for ; Thu, 30 Jul 2009 02:17:47 -0700 (PDT) Received: from softfront.co.jp by mail2.softfront.co.jp id AA03720 ; 30 Jul 2009 18:16:43 +0900 From: OKUMURA Shinji To: Gonzalo Camarillo Date: Thu, 30 Jul 2009 18:17:44 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.19 (WinNT,501) In-Reply-To: <4A6DA26F.7060205@ericsson.com> References: <4A6861CC.5030300@cisco.com> <4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> <4A6DA26F.7060205@ericsson.com> Message-Id: <50CA10F698AAD6shin@softfront.co.jp> Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 30 Jul 2009 09:17:48 -0000 Hi, I want to confirm one basic points, Gonzalo Camarillo >Hi, > >it seems we can cover most cases with the following rules: > >1) a reliable provisional response or a 2xx response to a target refresh >confirms that the UAS has refreshed the target. This refresh is not >rolled back under any circumstance (i.e., even if the target refresh was >a re-INVITE that eventually failed or the target refresh was an UPDATE >within a re-INVITE that eventually failed). I don't dislike this rule. But AFAIK RFC3261 and 3262 don't allow (even if reliable) provisional responses to refresh targets. Therefore I think this is a normative change. Regards, Shinji From gonzalo.camarillo@ericsson.com Thu Jul 30 05:41:35 2009 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 5E24A28C287 for ; Thu, 30 Jul 2009 05:41:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.309 X-Spam-Level: X-Spam-Status: No, score=-3.309 tagged_above=-999 required=5 tests=[AWL=-1.060, BAYES_00=-2.599, HELO_EQ_SE=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 rMljPqxxIjti for ; Thu, 30 Jul 2009 05:41:34 -0700 (PDT) Received: from mailgw5.ericsson.se (mailgw5.ericsson.se [193.180.251.36]) by core3.amsl.com (Postfix) with ESMTP id 7869F28C286 for ; Thu, 30 Jul 2009 05:41:31 -0700 (PDT) X-AuditID: c1b4fb24-b7c01ae00000498b-43-4a7194fb15de Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw5.ericsson.se (Symantec Brightmail Gateway) with SMTP id 54.85.18827.BF4917A4; Thu, 30 Jul 2009 14:41:31 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.172]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 14:41:31 +0200 Received: from mail.lmf.ericsson.se ([131.160.11.50]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 14:41:29 +0200 Received: from [131.160.126.137] (rvi2-126-137.lmf.ericsson.se [131.160.126.137]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 1704F24D8; Thu, 30 Jul 2009 15:41:29 +0300 (EEST) Message-ID: <4A7194F8.2090801@ericsson.com> Date: Thu, 30 Jul 2009 14:41:28 +0200 From: Gonzalo Camarillo User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: OKUMURA Shinji References: <4A6861CC.5030300@cisco.com> <4A686715.3070909@ericsson.com> <4A689184.5050903@cisco.com> <4A6DA26F.7060205@ericsson.com> <50CA10F698AAD6shin@softfront.co.jp> In-Reply-To: <50CA10F698AAD6shin@softfront.co.jp> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2009 12:41:29.0867 (UTC) FILETIME=[0FAF2DB0:01CA1113] X-Brightmail-Tracker: AAAAAA== Cc: gao.yang2@zte.com.cn, SIPCORE Subject: Re: [sipcore] New revision of the re-INVITE handling draft 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, 30 Jul 2009 12:41:36 -0000 Hi, please, read Section 8 of the draft. It points to the relevant paragraphs of RFC 3261. Cheers, Gonzalo OKUMURA Shinji wrote: > Hi, > > I want to confirm one basic points, > > Gonzalo Camarillo >> Hi, >> >> it seems we can cover most cases with the following rules: >> >> 1) a reliable provisional response or a 2xx response to a target refresh >> confirms that the UAS has refreshed the target. This refresh is not >> rolled back under any circumstance (i.e., even if the target refresh was >> a re-INVITE that eventually failed or the target refresh was an UPDATE >> within a re-INVITE that eventually failed). > > I don't dislike this rule. But AFAIK RFC3261 and 3262 don't allow > (even if reliable) provisional responses to refresh targets. > Therefore I think this is a normative change. > > Regards, > > Shinji From xavier.marjou@gmail.com Thu Jul 30 09:00:15 2009 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 BC77D28C309 for ; Thu, 30 Jul 2009 09:00:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.977 X-Spam-Level: X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622] 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 GIodRINrjdWd for ; Thu, 30 Jul 2009 09:00:15 -0700 (PDT) Received: from mail-ew0-f214.google.com (mail-ew0-f214.google.com [209.85.219.214]) by core3.amsl.com (Postfix) with ESMTP id A8BFA3A6C43 for ; Thu, 30 Jul 2009 08:59:42 -0700 (PDT) Received: by ewy10 with SMTP id 10so860064ewy.37 for ; Thu, 30 Jul 2009 08:59:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type:content-transfer-encoding; bh=QA+tCiXH+9mPcbJMSAwxfh2f5yYc3rLLweDV1MkTHSw=; b=BsNYRLVyyhPyfZ0HcmJcqeRfqFjnj8abWMk9H7QkOWnWeRv/B+tmYhveo/SW3N+Y17 35DF7kStxmjvnBgD1dkYrUJo8fErikboVCXdE2qEw/k4m5a8y277BDWJPrfAY+2LkZeS +E56Nav9PuOzQMc4RT88Hut8Rb/l2BPim+T7A= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=Ktjh0ZTbUKi/SPuv5Z4iTuHUTH+Q7MVFcD5hQyswB4tkHSFrJdgiTfcerkkbxCwWMd wxZ6Sl5TduMdMlrLnBQ1mcBqeOuJnt1uwnKcNPX7hMuwHUIBSaIflh+2kSz15ibZXyV4 YVKH+6o7mt/uRX4IZ0P35PQGgTdcVV1qDNT/U= MIME-Version: 1.0 Sender: xavier.marjou@gmail.com Received: by 10.216.85.21 with SMTP id t21mr267648wee.87.1248969581965; Thu, 30 Jul 2009 08:59:41 -0700 (PDT) In-Reply-To: <44F700B5-1F7F-4732-86A0-76D7E7083AE6@standardstrack.com> References: <44F700B5-1F7F-4732-86A0-76D7E7083AE6@standardstrack.com> Date: Thu, 30 Jul 2009 17:59:41 +0200 X-Google-Sender-Auth: 0e0d58e864ca100f Message-ID: <458913680907300859y7bfef974w7b2137cea5041683@mail.gmail.com> From: Xavier Marjou To: Eric Burger Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] INFO draft 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, 30 Jul 2009 16:00:15 -0000 Sorry for this late answer: +1 2 additional minor comments: 1/ Replace "A UAC conforming to this document can always send or receive legacy INFO usages without packages." By "A UA conforming to this document can always send or receive legacy INFO usages without packages." Indeed, RFC3261 indicates that the UAC is the entity that sends SIP requests, the UAS the one that receive SIP responses. An UA can do both. 2/ Similarly it also written some lines later that: "A UAC MAY send a legacy INFO [RFC2976] method at any time." I would suggest to replace it by "A UA MAY send or receive a legacy INFO [RFC2976] method at any time". (I have not understood your explanation in your previous response in another mail indicating why such replacement was not possible). Cheers, Xavier On Fri, Jul 17, 2009 at 1:08 AM, Eric Burger wrote: > The silence is deafening. Please +1 or -1, as the WGLC is underway. If > you're too tired of the topic, just +1 to prove you read the email. > > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-info-events-00.txt > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > From mdolly@att.com Thu Jul 30 09:01:57 2009 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 4BF203A6C72 for ; Thu, 30 Jul 2009 09:01:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.257 X-Spam-Level: X-Spam-Status: No, score=-106.257 tagged_above=-999 required=5 tests=[AWL=0.342, 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 S+f08vZX1GA7 for ; Thu, 30 Jul 2009 09:01:56 -0700 (PDT) Received: from mail146.messagelabs.com (mail146.messagelabs.com [216.82.241.147]) by core3.amsl.com (Postfix) with ESMTP id 544603A6C30 for ; Thu, 30 Jul 2009 09:01:56 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: mdolly@att.com X-Msg-Ref: server-10.tower-146.messagelabs.com!1248969717!4447206!1 X-StarScan-Version: 6.0.0; banners=-,-,- X-Originating-IP: [144.160.20.54] Received: (qmail 2543 invoked from network); 30 Jul 2009 16:01:57 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpi135.enaf.sfdc.sbc.com) (144.160.20.54) by server-10.tower-146.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 30 Jul 2009 16:01:57 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n6UG1u21019533 for ; Thu, 30 Jul 2009 12:01:56 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpi135.enaf.sfdc.sbc.com (8.14.3/8.14.3) with ESMTP id n6UG1klV019419 for ; Thu, 30 Jul 2009 12:01:52 -0400 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: Thu, 30 Jul 2009 12:01:49 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA03DC90E7@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <458913680907300859y7bfef974w7b2137cea5041683@mail.gmail.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] INFO draft Thread-Index: AcoRLuR8NoIdLJt8TFqXaOGBII5QYQAAB57w References: <44F700B5-1F7F-4732-86A0-76D7E7083AE6@standardstrack.com> <458913680907300859y7bfef974w7b2137cea5041683@mail.gmail.com> From: "DOLLY, MARTIN C, ATTLABS" To: "Xavier Marjou" , "Eric Burger" Cc: SIPCORE Subject: Re: [sipcore] INFO draft 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, 30 Jul 2009 16:01:57 -0000 +1 -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Xavier Marjou Sent: Thursday, July 30, 2009 12:00 PM To: Eric Burger Cc: SIPCORE Subject: Re: [sipcore] INFO draft Sorry for this late answer: +1 2 additional minor comments: 1/ Replace "A UAC conforming to this document can always send or receive legacy INFO usages without packages." By "A UA conforming to this document can always send or receive legacy INFO usages without packages." Indeed, RFC3261 indicates that the UAC is the entity that sends SIP requests, the UAS the one that receive SIP responses. An UA can do both. 2/ Similarly it also written some lines later that: "A UAC MAY send a legacy INFO [RFC2976] method at any time." I would suggest to replace it by "A UA MAY send or receive a legacy INFO [RFC2976] method at any time". (I have not understood your explanation in your previous response in another mail indicating why such replacement was not possible). Cheers, Xavier On Fri, Jul 17, 2009 at 1:08 AM, Eric Burger wrote: > The silence is deafening. Please +1 or -1, as the WGLC is underway. If > you're too tired of the topic, just +1 to prove you read the email. > > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-info-events-00.tx t > _______________________________________________ > 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@nortel.com Thu Jul 30 13:52:34 2009 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 AD0FB3A71C2 for ; Thu, 30 Jul 2009 13:52:34 -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=[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 Kvcq8q8ygV9I for ; Thu, 30 Jul 2009 13:52:33 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 8FCDA3A6A02 for ; Thu, 30 Jul 2009 13:52:33 -0700 (PDT) Received: from zrtphxs1.corp.nortel.com (zrtphxs1.corp.nortel.com [47.140.202.46]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6UKqPh12939 for ; Thu, 30 Jul 2009 20:52:25 GMT Received: from [47.16.90.165] ([47.16.90.165]) by zrtphxs1.corp.nortel.com with Microsoft SMTPSVC(6.0.3790.3959); Thu, 30 Jul 2009 16:52:20 -0400 From: "Dale Worley" To: "Francois Audet" In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1EEDEAB8@zrc2hxm0.corp.nortel.com> References: <1246996560.5962.37.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EDE5C07@zrc2hxm0.corp.nortel.com> <1247077928.3712.26.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EE8A67C@zrc2hxm0.corp.nortel.com> <1247257464.3757.67.camel@victoria-pingtel-com.us.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EEDE853@zrc2hxm0.corp.nortel.com> <1ECE0EB50388174790F9694F77522CCF1EEDEAB8@zrc2hxm0.corp.nortel.com> Content-Type: text/plain Organization: Nortel Networks Date: Thu, 30 Jul 2009 16:52:20 -0400 Message-Id: <1248987140.3740.43.camel@victoria-pingtel-com.us.nortel.com> Mime-Version: 1.0 X-Mailer: Evolution 2.12.3 (2.12.3-5.fc8) Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 30 Jul 2009 20:52:20.0758 (UTC) FILETIME=[A1C88360:01CA1157] Cc: SIPCORE Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis - privacy syntax 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, 30 Jul 2009 20:52:34 -0000 On Fri, 2009-07-10 at 20:36 -0400, Audet, Francois (SC100:3055) wrote: > While it's debatable if it was the right choice back in 2002, it > seems a bit late to change it now. Especially since it will not > be backwards compatible. I think I've already mentioned that I don't see us changing that feature. But I wanted to review it to understand why it was done that way. Dale From rjsparks@nostrum.com Thu Jul 30 15:50:22 2009 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 5E49C3A6A35 for ; Thu, 30 Jul 2009 15:50:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, SPF_PASS=-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 QADtdnmh7aHE for ; Thu, 30 Jul 2009 15:50:21 -0700 (PDT) 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 68F723A6A30 for ; Thu, 30 Jul 2009 15:50:20 -0700 (PDT) Received: from [10.43.1.229] ([212.112.167.85]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id n6UMoBIV001644 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Thu, 30 Jul 2009 17:50:13 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Message-Id: From: Robert Sparks To: sipcore@ietf.org Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v935.3) Date: Fri, 31 Jul 2009 00:50:06 +0200 X-Mailer: Apple Mail (2.935.3) Received-SPF: pass (nostrum.com: 212.112.167.85 is authenticated by a trusted mechanism) Cc: draft-ietf-sipcore-info-events@tools.ietf.org Subject: [sipcore] info-events WGLC comments 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, 30 Jul 2009 22:50:22 -0000 (as an individual) I found having this WGLC right before and over IETF hindered my ability for a thorough review from scratch style review. I suspect others are in the same boat. To show that at least a few people have read this, here are the comments I have so far. This is more hastily written than I'd like, so apologies for using document rather than priority order and apologies if any of this isn't clear. In case it's not clear from reading the below, I do not believe this document is quite ready to leave the working group. 1) Paragraph 1 of Section 1: "Note the INFO method does not change the SIP session state" - I think you mean "INVITE usage state" or "session usage state". Otherwise, this continues to introduce confusion about whether it changes dialog state (which it does). 2) The document needs a thorough scrubbing for "header field" vs "header". Paragraph 6 of section 1 is a first example, speaking of the Recv-Info header instead of the Recv- Info header field. Similar care needs to be taken when writing about header field _values_. 3) Nit - last paragraph before section 3 - spurious comma in last sentence 4) I find the structure of section 3 confusing in the extreme. The section might be better titled "Event package negotiation" and the attempt to use UAC and UAS vs Initiating and target to distinguish the actors in using the package and negotiating the package is not working well. I strongly suggest rewriting this section from scratch and finding a way to identify the actors that doesn't conflate so many things. As written, I find it very likely that implementers will give up and write code that guesses at the attempt. To hopefully inform that rewrite (rather than informing just minor edits), here are some smaller things I noted in the section 4-a) 2nd sentence, 3rd paragaph of 3.1: "This UA" is ambiguous. If the sentence as a whole is really important, the point needs to be expanded. 4-b) 5th sentence, 4th paragraph of 3.1 (starting "That is,") : This is an incomplete sentence. 4-c) 2nd sentence, 5th paragraph of 31 (starting "This enables") : I could not make sense out of this sentence during my first read. Only on writing these comments did I untangle it. Suggest adding "INFO requests using this package mechanism" after the words "receive any". (The confusion comes from grouping the words "any from a legacy UAS"). It would be even better to reword the sentence to avoid this issue. 4-d) Paragraph one of 3.2 : This paragraph is particularly hard to follow. Suggest just writing the extra words to call out sending an INVITE-usage creating/ updating response or receiving one. (Taking this response focus can remove some of the confusion that "request or response" is creating now). 4-e) 3rd sentence, 7th paragraph of 3.2: "either of these headers" doesn't make sense since you've talked about 3 of these header fields explicitly and readers will probably think of the implicit 4th. 4-f) Last sentence of 3.2 : (This one is fairly major) - This sentence can be read to say a UAC following this spec MAY send a legacy INFO method outside of a usage created by an INVITE request. This document OBSOLETES 2976. The behavior of an element implementing _this_ specification really can't refer to that document for behavior and it _especially_ can't ask the reader to infer behavior from that document. More words are needed here (and probably elsewhere in the document) to avoid the very strange situation of really needing a normative reference to the draft this one is obsoleting. 4-g) Last sentence of 3.3: This paragraph does not say quite what you mean. You are trying to say an element can't assume it knows what "foo2" means only because it knows what "foo1" means, or vice-versa. You are also trying to say package designers must not attempt to encode this kind of extensibility into their package names I think. 4-h) Section 3.4 (and a few other places): What does it mean to "receive from" an Info Package? Instances of this language, like "receive from Info Packages P and R" should be changed to something like "receive Info requests indicating packages P and R" 5) Section 4.1, 3rd paragraph, 2nd sentence: This sentence starts "In general". When is the rest of the sentence not the case (what is the exception to that "general")? 6) Section 4.1, 5th paragraph, last sentence: Nit (but an important one) This should say once the UAC has received the field value, not once the UAS has sent it. 7) Section 4.1, 6th paragraph: This paragraph should note that an INFO might beat a dialog-establishing provisional (or even final) response back (because of reordering, or more likely because of Route/Record-Route mechanics that gave it a shorter path than the response to the INVITE has to follow). 8) Section 4.2, 1st paragraph: It's really not clear this paragraph still reflects the architectural consensus of the community given some other recent conversations. I think we should explicitly reconfirm it's what we mean to say. 9) Section 4.2, 2nd paragraph: As written, this paragraph can be read to say that if a package allows requests to have a payload then all requests MUST have a payload. Did you intend to preclude packages where the payload is optional? 10) Section 4.2, 7th paragraph (MAY omit Content-Disposition): Would adding "for this part" to the end of this sentence be wrong? I think it would avoid a problem otherwise. 11) Section 4.2 - the two NOTEs. These are written to argue a point in the discussion of the draft. They need to be rewritten as conclusions 12) 4.3 paragraph 1. where you say "on an existing session." I suggest using "on an existing session dialog usage" or "on an existing session usage". 13) 4.3 paragraph 2: This paragraph precludes package specific error codes to the INFO request itself, which I think was the architectural intent, but it should be explicitly called out here. 14) 4.3 paragraph 5, last sentence. This sentence implies that strict compliance with this framework does not allow the use of legacy INFO at all. Is that what the group meant? Should the document say instead "If the UAS wishes to disallow use of legacy INFO requests, ..." 15) 4.3 paragraph 6: s/session/session usage/ 16) 4.4 Paragraph one: Please point out an otherwise or remove the "Unless stated otherwise" at the start of this paragraph. If the intent was to leave room for describing how you add bodies, then call that out separately from the other basic dialog/routing mechanics. 17) Why is section 4.5 here. The document doesn't discuss the semantics of an endpoint putting this header in a REGISTER request and this is a gross under-specification of what a proxy/registrar might do with the data. I will accep leaving it open to the future for this header to appear in a REGISTER request, but we either need to say what it means or say explicitly that it has no defined semantic. 18) Section 4.7 Paragraph 1: This paragraph is confused. It _is_ possible to determine order of the INFOs from the CSeq sequence (in case packets got reordered). What is not possible is objecting to a gap. If something is willing to wait for the NIT timeout, its possible to know that a gap won't be filled, so it is possible (with that timing constraint) to _detect_ gaps. You just can't build something that would consider that an error because some non-dialog- destroying error might be generated at an intervening proxy. 19) Section 4.7 last paragraph, last sentence : What does it mean to violate a package? 20) I did not review the tables. Who has? 21) I did review one bit of text below the tables. The * explanation is wrong I think. Info-Package is not OPTIONAL for legacy messages, it is forbidden there. To prevent someone from thinking this OPTIONAL means it's OK to put Info-Package in a legacy request, I suggest changing this o* to an m* and noting that the header field is mandatory in package using requests and forbidden in legacy requests. 22) Section 6 Paragraph 2: Why is this MAY? What else is a server going to interpret such an INFO as? If this really is a MAY, please justify in the text why it is not MUST. 23) Section 7.7: Why is this MAY not MUST? If this really is a MAY, the document needs to explain why it isn't MUST. Any package will at a minimum say what parts of the INFO to pass to an application for further processing or something of that nature. 23) Section 7.7: "Since INFO does not change SIP state" is incorrect. It changes dialog state. You meant the state of the invite session usage I think. 24) Section 7.7 Paragraph 2 points out that INFO can be used as the transport for other transaction-based protocols. This needs a reference to the section on when to use something other than INFO and it should probably repeat the statements on the MTU induced limitations. 25) Section 7.11 Paragraph 1: "Complete messages" are overkill and introduce an opportunity for error in the specification that is much larger than the usual gain of explanatory power. I suggest changing the sentence to focus on "all relative parts" rather than "complete". 26) Section 9.5: "Please add the following registration" doesn't seem to have a following registration. 27) I strongly suggest moving Appendix A into the main body. If we don't have it already, I suggest requiring new packages to discuss their consideration of this advice. 28) A.4 "your only option" feels too strong here. Better scoping of the sentence, or softening the only would help. 29) A.5.4 Second paragraph : Um, isn't this document creating an INFO framework? Maybe its just too late as I'm writing this, but I think this is legacy text and it doesn't match the rest of the document. Similarly (and backing up a little), the first paragraph reads very strangely for the current document. 30) Nit: Acknowlegments: "My, we have been working on this for a long time" will not age well after this is published. RjS From dean.willis@softarmor.com Fri Jul 31 02:09:35 2009 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 AE3DC28C224 for ; Fri, 31 Jul 2009 02:09:35 -0700 (PDT) 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 Zq9IY2AqNjTP for ; Fri, 31 Jul 2009 02:09:35 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id BA7CC3A68B4 for ; Fri, 31 Jul 2009 02:08:39 -0700 (PDT) Received: from [130.129.21.224] (dhcp-15e0.meeting.ietf.org [130.129.21.224]) (authenticated bits=0) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6V98ckp003582 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Fri, 31 Jul 2009 04:08:40 -0500 Message-ID: <4A72B495.80407@softarmor.com> Date: Fri, 31 Jul 2009 04:08:37 -0500 From: Dean Willis User-Agent: Thunderbird 2.0.0.22 (X11/20090608) MIME-Version: 1.0 To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery 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, 31 Jul 2009 09:09:35 -0000 I propose that since we're claiming that RFC 4244bis meets our charter deliverable goal of delivery of parameters from UAC to UAS that the use cases document for RFC 4244bis should document this use case. Further, if we find out that History-Info does NOT effectively meet the requirements of the use case, then we should find some other mechanism by which to meet that charter deliverable. -- Dean From HKaplan@acmepacket.com Fri Jul 31 02:15:35 2009 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 4CC633A6DB3 for ; Fri, 31 Jul 2009 02:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.56 X-Spam-Level: X-Spam-Status: No, score=-2.56 tagged_above=-999 required=5 tests=[AWL=0.039, 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 0+oitRUkQ2y0 for ; Fri, 31 Jul 2009 02:15:34 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 5A1633A6D5B for ; Fri, 31 Jul 2009 02:15:34 -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.1.375.2; Fri, 31 Jul 2009 05:15:35 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 31 Jul 2009 05:15:35 -0400 From: Hadriel Kaplan To: "sipcore@ietf.org" Date: Fri, 31 Jul 2009 05:15:33 -0400 Thread-Topic: Mixing old and new H-I Thread-Index: AcoRv3Us9se50y13SZ+McVW1Ysx44A== 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] Mixing old and new H-I 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, 31 Jul 2009 09:15:35 -0000 Howdy, Someone got up at the mic during the WG meeting and said "mixing old and ne= w H-I will be really confusing and cause problems". That person (me) wasn'= t too smart. It occurred to me as I sat down that this is really just equi= valent to if proxies/middleboxes didn't support 4244 or 4244bis period. =20 In other words, even if we said "start from scratch" and do a new header-na= me, the fact is that any middlebox not supporting that new header-name woul= d cause the same type of issues as middleboxes supporting legacy 4244 but n= ot 4244bis. It's unavoidable. Mea culpa. -hadriel From AUDET@nortel.com Fri Jul 31 02:22:20 2009 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 1D3413A6C11 for ; Fri, 31 Jul 2009 02:22:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.392 X-Spam-Level: X-Spam-Status: No, score=-6.392 tagged_above=-999 required=5 tests=[AWL=0.207, 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 bEzoISdeCI7w for ; Fri, 31 Jul 2009 02:22:19 -0700 (PDT) Received: from zrtps0kp.nortel.com (zrtps0kp.nortel.com [47.140.192.56]) by core3.amsl.com (Postfix) with ESMTP id 309AF3A6A02 for ; Fri, 31 Jul 2009 02:22:18 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zrtps0kp.nortel.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id n6V9MHV16843; Fri, 31 Jul 2009 09:22:17 GMT 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, 31 Jul 2009 04:21:59 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F410024@zrc2hxm0.corp.nortel.com> In-Reply-To: <4A72B495.80407@softarmor.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery thread-index: AcoRvrdk7ysXEO/eSv2Z9AkWh7BAhAAARvXg References: <4A72B495.80407@softarmor.com> From: "Francois Audet" To: "Dean Willis" , "SIPCORE" Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery 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, 31 Jul 2009 09:22:20 -0000 Dean, Our chartered delivereable is to deliver the whole URI (including the parameters): Verbatim: Delivering request-URI and parameters to UAS via proxy to IESG (PS)=20 And yes, that is one of the 2 main use cases for rfc4244bis. (the other one being fixing broken things in RFC 4244). > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Dean Willis > Sent: Friday, July 31, 2009 02:09 > To: SIPCORE > Subject: [sipcore] RFC 4244 bis use cases and UAC->UAS=20 > parameter delivery >=20 >=20 > I propose that since we're claiming that RFC 4244bis meets=20 > our charter deliverable goal of delivery of parameters from=20 > UAC to UAS that the use cases document for RFC 4244bis should=20 > document this use case. >=20 > Further, if we find out that History-Info does NOT=20 > effectively meet the requirements of the use case, then we=20 > should find some other mechanism by which to meet that=20 > charter deliverable. >=20 > -- > Dean >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From HKaplan@acmepacket.com Fri Jul 31 02:23:28 2009 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 2316B28C255 for ; Fri, 31 Jul 2009 02:23:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.561 X-Spam-Level: X-Spam-Status: No, score=-2.561 tagged_above=-999 required=5 tests=[AWL=0.038, 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 tyjUk4zLfmv7 for ; Fri, 31 Jul 2009 02:23:27 -0700 (PDT) Received: from etmail.acmepacket.com (etmail.acmepacket.com [216.41.24.6]) by core3.amsl.com (Postfix) with ESMTP id 4482A28C1E6 for ; Fri, 31 Jul 2009 02:23:27 -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.1.375.2; Fri, 31 Jul 2009 05:23:28 -0400 Received: from mail.acmepacket.com ([127.0.0.1]) by mail ([127.0.0.1]) with mapi; Fri, 31 Jul 2009 05:23:28 -0400 From: Hadriel Kaplan To: Dean Willis , SIPCORE Date: Fri, 31 Jul 2009 05:23:27 -0400 Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery Thread-Index: AcoRvrc3p6WkD7i9RiGryO3h4cdcUQAAPDBg Message-ID: References: <4A72B495.80407@softarmor.com> In-Reply-To: <4A72B495.80407@softarmor.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] RFC 4244 bis use cases and UAC->UAS parameter delivery 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, 31 Jul 2009 09:23:28 -0000 I believe the exact charter says "Delivering request-URI and parameters to = UAS via proxy to IESG". 4244bis does that. It's just delivering ALL reque= st-uri's, so we're just arguing over how to figure out which one was the "r= ight" one. With regard to UUI, Francois' point was "H-I delivers Req-URI and its param= s, but there is no consensus UUI should be a Req-URI param". -hadriel > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f > Of Dean Willis > Sent: Friday, July 31, 2009 5:09 AM > To: SIPCORE > Subject: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery >=20 >=20 > I propose that since we're claiming that RFC 4244bis meets our charter > deliverable goal of delivery of parameters from UAC to UAS that the use > cases document for RFC 4244bis should document this use case. >=20 > Further, if we find out that History-Info does NOT effectively meet the > requirements of the use case, then we should find some other mechanism > by which to meet that charter deliverable. >=20 > -- > Dean >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From dean.willis@softarmor.com Fri Jul 31 03:44:36 2009 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 402613A68E8 for ; Fri, 31 Jul 2009 03:44:36 -0700 (PDT) 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 spTOUfVbtmps for ; Fri, 31 Jul 2009 03:44:35 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 9882F3A6AB0 for ; Fri, 31 Jul 2009 03:44:08 -0700 (PDT) Received: from www.softarmor.com (www-data@localhost [127.0.0.1]) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6VAi7XM005301; Fri, 31 Jul 2009 05:44:07 -0500 Received: from 130.129.21.224 (SquirrelMail authenticated user sipdean) by www.softarmor.com with HTTP; Fri, 31 Jul 2009 05:44:07 -0500 (CDT) Message-ID: In-Reply-To: <1ECE0EB50388174790F9694F77522CCF1F410024@zrc2hxm0.corp.nortel.com> References: <4A72B495.80407@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1F410024@zrc2hxm0.corp.nortel.com> Date: Fri, 31 Jul 2009 05:44:07 -0500 (CDT) From: "Dean Willis" To: "Francois Audet" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: SIPCORE Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery 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, 31 Jul 2009 10:44:36 -0000 On Fri, July 31, 2009 9:21 am, Francois Audet wrote: > Dean, > > Our chartered delivereable is to deliver the whole > URI (including the parameters): > > Verbatim: > Delivering request-URI and parameters to UAS via proxy to IESG (PS) > > And yes, that is one of the 2 main use cases for rfc4244bis. > (the other one being fixing broken things in RFC 4244). Just handing the raw data in an obfuscated way to the UAS is not enough. We need to deliver the URI and parameters to the UAS in such a fashion that the application running on the UAS can actually use them. You keep saying "History-Info does this", but when we TRY to use History-Info in this manner, people say "Well, these parameters don't feel like History, they feel like something else, so I need to use some easier-to-parse mechanism". They're not using History-Info for parameter delivery. Show a successful use case for parameter delivery using History-Info, or stop claiming it solves the problem. ing with respect to the request URI. -- Dean From dean.willis@softarmor.com Fri Jul 31 03:45:53 2009 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 356B23A6BE9 for ; Fri, 31 Jul 2009 03:45:53 -0700 (PDT) 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 T1wtKJlG+01g for ; Fri, 31 Jul 2009 03:45:52 -0700 (PDT) Received: from nylon.softarmor.com (nylon.softarmor.com [66.135.38.164]) by core3.amsl.com (Postfix) with ESMTP id 790C23A6AB0 for ; Fri, 31 Jul 2009 03:45:52 -0700 (PDT) Received: from www.softarmor.com (www-data@localhost [127.0.0.1]) by nylon.softarmor.com (8.14.3/8.14.3/Debian-5) with ESMTP id n6VAjnOx005349; Fri, 31 Jul 2009 05:45:49 -0500 Received: from 130.129.21.224 (SquirrelMail authenticated user sipdean) by www.softarmor.com with HTTP; Fri, 31 Jul 2009 10:45:50 -0000 (UTC) Message-ID: In-Reply-To: References: <4A72B495.80407@softarmor.com> Date: Fri, 31 Jul 2009 10:45:50 -0000 (UTC) From: "Dean Willis" To: "Hadriel Kaplan" User-Agent: SquirrelMail/1.4.15 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal Cc: SIPCORE Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery 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, 31 Jul 2009 10:45:53 -0000 On Fri, July 31, 2009 9:23 am, Hadriel Kaplan wrote: > > I believe the exact charter says "Delivering request-URI and parameters to > UAS via proxy to IESG". 4244bis does that. It's just delivering ALL > request-uri's, so we're just arguing over how to figure out which one was > the "right" one. and which parameters are the right ones? They're not necessarily the ones on the first request-URI, either! -- Dean From AUDET@nortel.com Fri Jul 31 03:59:53 2009 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 A95733A686D for ; Fri, 31 Jul 2009 03:59:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.401 X-Spam-Level: X-Spam-Status: No, score=-6.401 tagged_above=-999 required=5 tests=[AWL=0.198, 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 2KhAZXw8aLRe for ; Fri, 31 Jul 2009 03:59:52 -0700 (PDT) Received: from zcars04e.nortel.com (zcars04e.nortel.com [47.129.242.56]) by core3.amsl.com (Postfix) with ESMTP id 987C93A6825 for ; Fri, 31 Jul 2009 03:59:52 -0700 (PDT) Received: from zrc2hxm0.corp.nortel.com (zrc2hxm0.corp.nortel.com [47.103.123.71]) by zcars04e.nortel.com (Switch-2.2.0/Switch-2.2.0) with ESMTP id n6VAw0214552; Fri, 31 Jul 2009 10:58:00 GMT 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, 31 Jul 2009 05:59:44 -0500 Message-ID: <1ECE0EB50388174790F9694F77522CCF1F41002F@zrc2hxm0.corp.nortel.com> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery thread-index: AcoRy9gFFFvVd8hGSG2QOX/h2/n3PQAAW5Bw References: <4A72B495.80407@softarmor.com> <1ECE0EB50388174790F9694F77522CCF1F410024@zrc2hxm0.corp.nortel.com> From: "Francois Audet" To: "Dean Willis" Cc: SIPCORE Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery 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, 31 Jul 2009 10:59:53 -0000 Parameters without the URI itself are completely useless. I know you would like to change that so that parameters=20 stand on their own outside of the URI, but that's not how SIP works, and we can't change it. It's engrained in SIP. So basically, you need to know WHICH URI you are looking for. Depending on which Target-URI problem you are trying to solve, it could be typically either the first or the last retarget. In our current draft, that would mean either the first=20 entry with aor flag, or the last one. So it does work. I don't know why you claim it's difficult. If we remove the aor flag, then the logic will have to be=20 different. Probably something like "first or last entry without a fluff flag". > -----Original Message----- > From: Dean Willis [mailto:dean.willis@softarmor.com]=20 > Sent: Friday, July 31, 2009 03:44 > To: Audet, Francois (SC100:3055) > Cc: Dean Willis; SIPCORE > Subject: RE: [sipcore] RFC 4244 bis use cases and UAC->UAS=20 > parameter delivery >=20 > On Fri, July 31, 2009 9:21 am, Francois Audet wrote: > > Dean, > > > > Our chartered delivereable is to deliver the whole URI=20 > (including the=20 > > parameters): > > > > Verbatim: > > Delivering request-URI and parameters to UAS via proxy to IESG (PS) > > > > And yes, that is one of the 2 main use cases for rfc4244bis. > > (the other one being fixing broken things in RFC 4244). >=20 > Just handing the raw data in an obfuscated way to the UAS is=20 > not enough. >=20 > We need to deliver the URI and parameters to the UAS in such=20 > a fashion that the application running on the UAS can=20 > actually use them. >=20 > You keep saying "History-Info does this", but when we TRY to=20 > use History-Info in this manner, people say "Well, these=20 > parameters don't feel like History, they feel like something=20 > else, so I need to use some easier-to-parse mechanism".=20 > They're not using History-Info for parameter delivery. >=20 > Show a successful use case for parameter delivery using=20 > History-Info, or stop claiming it solves the problem. > ing with respect to the request URI. >=20 > -- > Dean >=20 >=20 >=20 From pkyzivat@cisco.com Fri Jul 31 05:42:53 2009 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 5C0D83A6E5D for ; Fri, 31 Jul 2009 05:42:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.504 X-Spam-Level: X-Spam-Status: No, score=-6.504 tagged_above=-999 required=5 tests=[AWL=0.095, 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 2KWskSM+q7ga for ; Fri, 31 Jul 2009 05:42:49 -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 07CCB3A68EA for ; Fri, 31 Jul 2009 05:42:44 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApoEAHeDckqrR7PE/2dsb2JhbAC5F4gnkDgFhBc X-IronPort-AV: E=Sophos;i="4.43,302,1246838400"; d="scan'208";a="357787979" Received: from sj-dkim-4.cisco.com ([171.71.179.196]) by sj-iport-6.cisco.com with ESMTP; 31 Jul 2009 12:42:46 +0000 Received: from sj-core-1.cisco.com (sj-core-1.cisco.com [171.71.177.237]) by sj-dkim-4.cisco.com (8.12.11/8.12.11) with ESMTP id n6VCgkFF016157; Fri, 31 Jul 2009 05:42:46 -0700 Received: from xbh-rtp-211.amer.cisco.com (xbh-rtp-211.cisco.com [64.102.31.102]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id n6VCgWYx021882; Fri, 31 Jul 2009 12:42:45 GMT Received: from xfe-rtp-202.amer.cisco.com ([64.102.31.21]) by xbh-rtp-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 08:42:45 -0400 Received: from [161.44.174.156] ([161.44.174.156]) by xfe-rtp-202.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Fri, 31 Jul 2009 08:42:45 -0400 Message-ID: <4A72E6C5.5070905@cisco.com> Date: Fri, 31 Jul 2009 08:42:45 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.22 (Windows/20090605) MIME-Version: 1.0 To: Hadriel Kaplan References: <4A72B495.80407@softarmor.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 31 Jul 2009 12:42:45.0216 (UTC) FILETIME=[67024600:01CA11DC] DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; l=1757; t=1249044166; x=1249908166; c=relaxed/simple; s=sjdkim4002; h=Content-Type:From:Subject:Content-Transfer-Encoding:MIME-Version; d=cisco.com; i=pkyzivat@cisco.com; z=From:=20Paul=20Kyzivat=20 |Subject:=20Re=3A=20[sipcore]=20RFC=204244=20bis=20use=20ca ses=20and=20UAC->UAS=20parameter=20delivery |Sender:=20; bh=5vSNEDW11+2o+8Xp3+Y0wjlFs5cYRStJDEtr3fJ/g6U=; b=YFv0nkYVNyXliNMzqS+cZpDYDXGpSVtYwe8WjyQv7ZErA54eADG0YqOxKX 6IXp80u5iN1OvavGFACEZFhVCm24joLlZ4lIov6RB2VTHtiv1jIHU8vdIVaO y/eKQNFF8M; Authentication-Results: sj-dkim-4; header.From=pkyzivat@cisco.com; dkim=pass ( sig from cisco.com/sjdkim4002 verified; ); Cc: SIPCORE Subject: Re: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery 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, 31 Jul 2009 12:42:53 -0000 Hadriel Kaplan wrote: > I believe the exact charter says "Delivering request-URI and parameters to UAS via proxy to IESG". 4244bis does that. It's just delivering ALL request-uri's, so we're just arguing over how to figure out which one was the "right" one. > > With regard to UUI, Francois' point was "H-I delivers Req-URI and its params, but there is no consensus UUI should be a Req-URI param". Right. But it does raise the bar for UUI. IIRC, one of the arguments against using R-URI params for UUI was the problem of them getting lost along the way - not reaching the destination. If that problem is removed by H-I, is there another compelling argument for introducing a new header? Thanks, Paul > -hadriel > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf >> Of Dean Willis >> Sent: Friday, July 31, 2009 5:09 AM >> To: SIPCORE >> Subject: [sipcore] RFC 4244 bis use cases and UAC->UAS parameter delivery >> >> >> I propose that since we're claiming that RFC 4244bis meets our charter >> deliverable goal of delivery of parameters from UAC to UAS that the use >> cases document for RFC 4244bis should document this use case. >> >> Further, if we find out that History-Info does NOT effectively meet the >> requirements of the use case, then we should find some other mechanism >> by which to meet that charter deliverable. >> >> -- >> Dean >> >> _______________________________________________ >> 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 >