From gonzalo.camarillo@ericsson.com Thu Jul 1 00:08:54 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5C1323A6802 for ; Thu, 1 Jul 2010 00:08:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.235 X-Spam-Level: X-Spam-Status: No, score=-103.235 tagged_above=-999 required=5 tests=[AWL=-0.636, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGmWDnUTCIEs for ; Thu, 1 Jul 2010 00:08:53 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 567EA3A67C3 for ; Thu, 1 Jul 2010 00:08:53 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae000004c90-e4-4c2c3f0f6ffa Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DF.ED.19600.F0F3C2C4; Thu, 1 Jul 2010 09:09:03 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Jul 2010 09:09:03 +0200 Received: from [131.160.126.184] ([131.160.126.184]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Jul 2010 09:09:02 +0200 Message-ID: <4C2C3F0D.4040701@ericsson.com> Date: Thu, 01 Jul 2010 10:09:01 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Brett Tate References: <4C230507.10105@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCD53715@EXMBXCLUS01.citservers.local> <4C2AF2BA.1070602@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCE7EC16@EXMBXCLUS01.citservers.local> <4C2B3864.4050708@ericsson.com> <4C2B4CF9.9000103@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCE7EC7A@EXMBXCLUS01.citservers.local> In-Reply-To: <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCE7EC7A@EXMBXCLUS01.citservers.local> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jul 2010 07:09:03.0010 (UTC) FILETIME=[493A5820:01CB18EC] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 01 Jul 2010 07:08:54 -0000 Hi Brett, > If adjustments are added to the other sections to clearly discuss non > reliable provisional responses, the proposal appears to adequately > clarify RFC 3261. sure, I am going to work on that. > My understanding of the new section is that an INVITE 2xx response's > updated Contact can trigger the UAC to update the remote-target. The > clarification is not because of the last sentence, it is because of > the first sentence. If this is not true, please explain. Yes, your understanding is correct. Cheers, Gonzalo From gonzalo.camarillo@ericsson.com Thu Jul 1 00:38:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B39043A6847 for ; Thu, 1 Jul 2010 00:38:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.229 X-Spam-Level: X-Spam-Status: No, score=-105.229 tagged_above=-999 required=5 tests=[AWL=1.370, 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 S2Y4oN-aZrLU for ; Thu, 1 Jul 2010 00:38:50 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 0CE313A6828 for ; Thu, 1 Jul 2010 00:38:49 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-06-4c2c4614fa74 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 84.7E.10125.4164C2C4; Thu, 1 Jul 2010 09:39:00 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Jul 2010 09:38:14 +0200 Received: from [131.160.126.184] ([131.160.126.184]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 1 Jul 2010 09:38:14 +0200 Message-ID: <4C2C45E4.50200@ericsson.com> Date: Thu, 01 Jul 2010 10:38:12 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Paul Kyzivat References: <4C230507.10105@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCD53715@EXMBXCLUS01.citservers.local> <4C2AF2BA.1070602@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCE7EC16@EXMBXCLUS01.citservers.local> <4C2B3864.4050708@ericsson.com> <4C2B4A09.3090006@cisco.com> <4C2B4F99.9020707@cisco.com> In-Reply-To: <4C2B4F99.9020707@cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Jul 2010 07:38:14.0220 (UTC) FILETIME=[5D07C8C0:01CB18F0] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 01 Jul 2010 07:38:51 -0000 Hi Paul, what I had in mind is exactly what you proposed below. It's good to see we are on the same page! I have added a second paragraph to Section 4.6 to address this issue. The whole section looks as follows now: 4.6. Early Dialogs The rules given in this section about which messages can refresh the target of a dialog also apply to early dialogs created by an initial INVITE transaction. Additionally, as specified in Section 13.2.2.4 of RFC 3261 [RFC3261], on receiving a 2xx response to the initial INVITE, the UAC recomputes the whole route set of the dialog, which transitions from the "early" state to the "confirmed" state. Section 12.1 of RFC 3261 allows unreliable provisional responses to create early dialogs. However, per the rules given in this section, unreliable provisional responses cannot refresh the target of a dialog. Therefore, the UAC of an initial INVITE transaction will not perform any target refresh as a result of the reception of an unreliable provisional response with an updated Contact value on an (already-established) early dialog. Note also that a given UAS can establish additional early dialogs, which can have different targets, by returning additional unreliable provisional responses with different To tags. Cheers, Gonzalo On 30/06/2010 5:07 PM, Paul Kyzivat wrote: > Replying to myself, > > Perhaps the answer here is that a non-reliable response to an initial > INVITE can indeed establish an early dialog. But then the contact > address in all subsequent non-reliable responses must remain identical > to that in the first non-reliable response. And Contacts received in > non-reliable responses, except the first one received, must be ignored. > > That would allow use of INFO and UPDATE in an early dialog without > 100rel, and even a remote target change via the UPDATE in that case. > > Thanks, > Paul > > Paul Kyzivat wrote: >> >> >> Gonzalo Camarillo wrote: >> >>>> The following rule only discusses reliable provisional responses. >>>> What are rules for non reliable provisional responses? >>> >>> non-reliable responses do not refresh the target because SIP does not >>> provide any type of ordering for them. I can clarify that if you think >>> it is unclear. >> >> Hmm. I think that is debatable. >> >> That logic would suggest that non-reliable provisionals also could not >> establish an early dialog in the first place, since there might have >> been more than one with different targets that got reordered. >> >> My reading of 3261 and 3311 leaves me with the conclusion that I could >> receive a non-reliable provisional, consider that to establish an early >> dialog, and then send an UPDATE, without ever using 100rel. >> >> OTOH, there is logic to your argument. So maybe what you propose is the >> "right" solution even if it is to some extent incompatible with things >> as they stand. If so, then there should be an additional explicit >> statement that non-reliable provisionals never establish an early dialog. >> >> That would also mean that INFO could not be used before 2xx unless >> 100rel was used to establish the early dialog. >> >> Thanks, >> Paul >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> From gao.yang2@zte.com.cn Thu Jul 1 02:38:16 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D11E03A6835 for ; Thu, 1 Jul 2010 02:38:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.47 X-Spam-Level: X-Spam-Status: No, score=-99.47 tagged_above=-999 required=5 tests=[AWL=2.368, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 UIzdEpLIuLUW for ; Thu, 1 Jul 2010 02:38:12 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id ED53D3A67D7 for ; Thu, 1 Jul 2010 02:38:11 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 383431727820181; Thu, 1 Jul 2010 17:37:50 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 2748.2980680612; Thu, 1 Jul 2010 17:38:17 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o619c5xG013359; Thu, 1 Jul 2010 17:38:05 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4C2B4D8D.70906@ericsson.com> To: Gonzalo Camarillo MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 1 Jul 2010 17:34:42 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-01 17:37:51, Serialize complete at 2010-07-01 17:37:51 Content-Type: multipart/alternative; boundary="=_alternative 0034D76A48257753_=" X-MAIL: mse2.zte.com.cn o619c5xG013359 Cc: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 01 Jul 2010 09:38:16 -0000 This is a multipart message in MIME format. --=_alternative 0034D76A48257753_= Content-Type: text/plain; charset="US-ASCII" Hi Gonzalo, > > I am OK with adding text about Ini-INVITE. > > And I think that, it might better to add some kind of remark for the > > Ini-INVITE topics in the text, in the Abstract or Introduction sections, > > as the name of the text is for Re-INVITE :) > > All that text already talks about target refreshes (in addition to > re-INVITEs). So, it already covers what we are talking about here. OK. Cheers, 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. --=_alternative 0034D76A48257753_= Content-Type: text/html; charset="US-ASCII"
Hi Gonzalo,

> > I am OK with adding text about Ini-INVITE.
> > And I think that, it might better to add some kind of remark for the
> > Ini-INVITE topics in the text, in the Abstract or Introduction sections,
> > as the name of the text is for Re-INVITE :)
>
> All that text already talks about target refreshes (in addition to
> re-INVITEs). So, it already covers what we are talking about here.
OK.

Cheers,

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.
--=_alternative 0034D76A48257753_=-- From xavier.marjou@gmail.com Thu Jul 1 02:52:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E09883A6842 for ; Thu, 1 Jul 2010 02:52:14 -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 MIrkVhEl9ymN for ; Thu, 1 Jul 2010 02:52:14 -0700 (PDT) Received: from mail-fx0-f44.google.com (mail-fx0-f44.google.com [209.85.161.44]) by core3.amsl.com (Postfix) with ESMTP id E22503A6848 for ; Thu, 1 Jul 2010 02:52:13 -0700 (PDT) Received: by fxm1 with SMTP id 1so1156116fxm.31 for ; Thu, 01 Jul 2010 02:52:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type; bh=h2nY6wbfqB5XJAmH++PJONimh1z9UC5FxYeSqqRb/5M=; b=jJfdT/kE47Jipymez+fk6Y5zkC3cODuN7XciZo1FAXhjjd3ablXH4AuVwptqbvbsj1 99FIKK2iPt/+SfCcHDnKxcu4hAL1kNVazzGMuLEKtbS3ar32/BPB/yqr7eYrA3rm6GPs IHjaMbxsKQRu5hpZ931AO+1Y5JsXl5HDpnmYM= 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; b=RSQNge/YgRWKP7FsLSIZQqQ2BRy90UN0/n/FA8vSsM/pezhXgf0jzGr3J/vNVdDNgu 9c8eLqkE5o4YYMdoyYsis7T7jkMy0oVdvshADoS5f9QUT3Y78AOphn4KZ094lQxmMmUy cKkJFlmLigabpdiA/TjriiJDcXnEVo2v2ixw8= MIME-Version: 1.0 Received: by 10.239.182.7 with SMTP id o7mr651721hbg.79.1277977474836; Thu, 01 Jul 2010 02:44:34 -0700 (PDT) Sender: xavier.marjou@gmail.com Received: by 10.239.183.143 with HTTP; Thu, 1 Jul 2010 02:44:34 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Jul 2010 11:44:34 +0200 X-Google-Sender-Auth: 0dRozJE9w5MGBcu88SvyEusOB24 Message-ID: From: Xavier Marjou To: Christer Holmberg Content-Type: text/plain; charset=ISO-8859-1 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Draft new version: draft-ietf-sipcore-keep-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 09:52:15 -0000 Hi, I support Christer's view on this draft. Cheers, Xavier On Mon, May 31, 2010 at 12:06 PM, Christer Holmberg wrote: > > Hi, > > Based on the discussions and comments, I have submitted a new version of the > keep draft now. > > There are currently no open issues, and in my opinion the draft is ready for > WGLC. > > Regards, > > Christer > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > > From pkyzivat@cisco.com Thu Jul 1 07:41:48 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 89A173A6811 for ; Thu, 1 Jul 2010 07:41:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.267 X-Spam-Level: X-Spam-Status: No, score=-10.267 tagged_above=-999 required=5 tests=[AWL=0.332, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DQkYOgGJtkHM for ; Thu, 1 Jul 2010 07:41:45 -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 725003A6802 for ; Thu, 1 Jul 2010 07:41:44 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACFGLExAZnwM/2dsb2JhbACfaHGkQ5o6hSUEiC0 X-IronPort-AV: E=Sophos;i="4.53,520,1272844800"; d="scan'208";a="127749273" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 01 Jul 2010 14:41:55 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o61Eftar010613; Thu, 1 Jul 2010 14:41:55 GMT Message-ID: <4C2CA93D.5050806@cisco.com> Date: Thu, 01 Jul 2010 10:42:05 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Paul E. Jones" References: <037201cb18d9$05dab420$11901c60$@packetizer.com> In-Reply-To: <037201cb18d9$05dab420$11901c60$@packetizer.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Revised draft-jones-sip-options-ping-02.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, 01 Jul 2010 14:41:48 -0000 [as co-chair] Paul J, What are your intentions/expectations with respect to this draft? While it is written using normative language, I find nothing in it that is enhanced by being normative. So I would imagine if this is to go anywhere, it would be as a Informational document. At the moment I don't envision this rising to the level of becoming a milestone for this group. I have no problem with using this list for a modest amount of discussion about this draft - especially about its eventual outcome. Thanks, Paul Paul E. Jones wrote: > Folks, > > I just wanted to bring to your attention the fact that we've submitted a new > revised version of the OPTIONS "ping" draft. This document contains input > from a number of folks who provided comments to me on various aspects of the > draft. > > We had some discussion of moving this work to the SIP Overload Control (SOC) > WG. Given my current understanding of the scope of the SOC WG, I do not > think that OPTIONS falls within the scope of their charter. Further, this > document was never produced for the purpose of providing an overload > mechanism, either. > > I would like to have some further dialog on this document. I've received > some positive feedback from several people, as this has been seen as a > useful first step in trying to define use of OPTIONS as a "ping" mechanism > that is interoperable. As I had mentioned before, there are several > different variants of the same procedure in production networks and I think > it's useful that we reach some agreement on how OPTIONS should be used as an > application-level "ping", as RFC 3261 is a bit light on detail in this area. > > I know I might not have captured every comment, but that's because the > discussions went in a variety of directions last time. :-) So, my edits > were primarily editorial or to add clarity to what was already written. > > Comments are most certainly welcome. > > Paul > >> -----Original Message----- >> From: i-d-announce-bounces@ietf.org [mailto:i-d-announce-bounces@ietf.org] >> On Behalf Of Internet-Drafts@ietf.org >> Sent: Thursday, July 01, 2010 12:30 AM >> To: i-d-announce@ietf.org >> Subject: I-D Action:draft-jones-sip-options-ping-02.txt >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> >> Title : Using OPTIONS to Query for Operational Status in >> the Session Initiation Protocol (SIP) >> Author(s) : V. Bhargava, et al. >> Filename : draft-jones-sip-options-ping-02.txt >> Pages : 8 >> Date : 2010-06-30 >> >> This document describes a procedure for using the Session Initiation >> Protocol (SIP) OPTIONS method in order to allow one SIP entity to query >> the operational status of another SIP entity. Through discovery of the >> status of a SIP entity, it is possible to expedite session establishment >> or provide diagnostic information to network administrators. >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-jones-sip-options-ping-02.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 > From pkyzivat@cisco.com Thu Jul 1 08:49:23 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 667B23A681F for ; Thu, 1 Jul 2010 08:49:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.279 X-Spam-Level: X-Spam-Status: No, score=-10.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U+n+MehiS0P6 for ; Thu, 1 Jul 2010 08:49: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 C5BF13A6807 for ; Thu, 1 Jul 2010 08:49:21 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEABBWLExAZnwM/2dsb2JhbACfa3GlCpo0hSUEiC0 X-IronPort-AV: E=Sophos;i="4.53,520,1272844800"; d="scan'208";a="127632169" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 01 Jul 2010 15:49:33 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o61FnWkw007856; Thu, 1 Jul 2010 15:49:33 GMT Message-ID: <4C2CB90C.7060608@cisco.com> Date: Thu, 01 Jul 2010 11:49:32 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4C230507.10105@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCD53715@EXMBXCLUS01.citservers.local> <4C2AF2BA.1070602@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCE7EC16@EXMBXCLUS01.citservers.local> <4C2B3864.4050708@ericsson.com> <4C2B4A09.3090006@cisco.com> <4C2B4F99.9020707@cisco.com> <4C2C45E4.50200@ericsson.com> In-Reply-To: <4C2C45E4.50200@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 01 Jul 2010 15:49:23 -0000 Gonzalo, I like the new paragraph. But I think the procedures in the rest of the section are still incomplete. Section 4.3 is limited to cases when the UAC is attempting to change *its* address and 4.4 is limited to cases when the UAS as received a request from a UAC that is attempting to change its address. The case where the UAS wants (needs) to change its address is largely unmentioned. This is of course a strange situation, which would require some freak timing, but it is possible. (To be fair, 4.3 does touch on the case where the UAS receives a response with a changed address. But since the whole section is restricted to a UAC changing its own address, it doesn't cover the case where only the UAS is changing its address.) If the UAS just *wants* to make the change, then it would be best for it to wait until it can send a request of its own. If it *needs* to make a change, then it must do what it must do. But then there are limits such as you have already identified. Specifically, if the UAS received an initial or re-INVITE, and send a reliable provisional response with one address, then it would be permitted to send another reliable response with a different address. But if it send an unreliable provisional with one address, then there are problems with sending another unreliable provisional with a different address. Specifically the problems are with which one the UAC believes when some may be lost or reordered. For an initial invite you already point out one solution in 4.6: change the to-tag and thus establish a new early dialog. That is a great solution for the UAS in this case. There is another solution for the UAS in a reINVITE: send an out of dialog INVITE/Replaces, transferring the call to the new address. Perhaps it is sufficient to offer those solutions to the UAS while keeping the rules you have spelled out for the UAC to ignore changes to the remote address in unreliable responses. Thanks, Paul Gonzalo Camarillo wrote: > Hi Paul, > > what I had in mind is exactly what you proposed below. It's good to see > we are on the same page! > > I have added a second paragraph to Section 4.6 to address this issue. > The whole section looks as follows now: > > > 4.6. Early Dialogs > > The rules given in this section about which messages can refresh the > target of a dialog also apply to early dialogs created by an initial > INVITE transaction. Additionally, as specified in Section 13.2.2.4 > of RFC 3261 [RFC3261], on receiving a 2xx response to the initial > INVITE, the UAC recomputes the whole route set of the dialog, which > transitions from the "early" state to the "confirmed" state. > > Section 12.1 of RFC 3261 allows unreliable provisional responses to > create early dialogs. However, per the rules given in this section, > unreliable provisional responses cannot refresh the target of a > dialog. Therefore, the UAC of an initial INVITE transaction will not > perform any target refresh as a result of the reception of an > unreliable provisional response with an updated Contact value on an > (already-established) early dialog. Note also that a given UAS can > establish additional early dialogs, which can have different targets, > by returning additional unreliable provisional responses with > different To tags. > > Cheers, > > Gonzalo > > On 30/06/2010 5:07 PM, Paul Kyzivat wrote: >> Replying to myself, >> >> Perhaps the answer here is that a non-reliable response to an initial >> INVITE can indeed establish an early dialog. But then the contact >> address in all subsequent non-reliable responses must remain identical >> to that in the first non-reliable response. And Contacts received in >> non-reliable responses, except the first one received, must be ignored. >> >> That would allow use of INFO and UPDATE in an early dialog without >> 100rel, and even a remote target change via the UPDATE in that case. >> >> Thanks, >> Paul >> >> Paul Kyzivat wrote: >>> >>> Gonzalo Camarillo wrote: >>> >>>>> The following rule only discusses reliable provisional responses. >>>>> What are rules for non reliable provisional responses? >>>> non-reliable responses do not refresh the target because SIP does not >>>> provide any type of ordering for them. I can clarify that if you think >>>> it is unclear. >>> Hmm. I think that is debatable. >>> >>> That logic would suggest that non-reliable provisionals also could not >>> establish an early dialog in the first place, since there might have >>> been more than one with different targets that got reordered. >>> >>> My reading of 3261 and 3311 leaves me with the conclusion that I could >>> receive a non-reliable provisional, consider that to establish an early >>> dialog, and then send an UPDATE, without ever using 100rel. >>> >>> OTOH, there is logic to your argument. So maybe what you propose is the >>> "right" solution even if it is to some extent incompatible with things >>> as they stand. If so, then there should be an additional explicit >>> statement that non-reliable provisionals never establish an early dialog. >>> >>> That would also mean that INFO could not be used before 2xx unless >>> 100rel was used to establish the early dialog. >>> >>> Thanks, >>> Paul >>> _______________________________________________ >>> sipcore mailing list >>> sipcore@ietf.org >>> https://www.ietf.org/mailman/listinfo/sipcore >>> > > From adam@nostrum.com Thu Jul 1 12:22:15 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E0CA83A69B1 for ; Thu, 1 Jul 2010 12:22:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.51 X-Spam-Level: X-Spam-Status: No, score=-2.51 tagged_above=-999 required=5 tests=[AWL=0.090, 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 Bl-tBSumxAkd for ; Thu, 1 Jul 2010 12:22:15 -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 B291E3A68F6 for ; Thu, 1 Jul 2010 12:22:14 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o61JMPsg025713 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 1 Jul 2010 14:22:25 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C2CEAF1.5060902@nostrum.com> Date: Thu, 01 Jul 2010 14:22:25 -0500 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: "SIPCORE (Session Initiation Protocol Core) WG" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Subject: [sipcore] SIPCORE Agenda Requests, call for NOMCOM volunteers X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Jul 2010 19:22:16 -0000 [as chair] If you wish to request time to discuss a draft at the upcoming face-to-face meeting in Maastricht, please send an email to to the SIPCORE chairs . The deadline for requesting SIPCORE meeting time is Monday, July 12th. Note that the chairs may decline requests for time if there is no evidence of mailing list traffic on the associated draft. Also, please note that the cutoff date for new (-00) documents is this upcoming Monday, and the cutoff date for all other documents is Monday, July 12th. Finally, please consider volunteering for NOMCOM. You are eligible if you have attended 3 of the past 5 IETF meetings. The deadline for volunteering is 17:00 PDT (24:00 UTC) July 8, 2010. If you are willing to help select the IETF leadership team for the next two years, please send an email to , with your full name, primary affiliation, email address(es) used to register for any of the past 5 meetings, and a telephone number. Thanks! /a From mary.ietf.barnes@gmail.com Thu Jul 1 12:30:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 70F643A67F5 for ; Thu, 1 Jul 2010 12:30:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.349 X-Spam-Level: X-Spam-Status: No, score=-2.349 tagged_above=-999 required=5 tests=[AWL=0.250, 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 i042VL9mENo8 for ; Thu, 1 Jul 2010 12:30:30 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 425E03A6868 for ; Thu, 1 Jul 2010 12:30:26 -0700 (PDT) Received: by iwn40 with SMTP id 40so2493351iwn.31 for ; Thu, 01 Jul 2010 12:30:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=ycbLaqQHQDYdtzCN617wTuHyA/QtUQMdej6WoN1G8qs=; b=x1dtyvcAv8UBKNUMfU6l2o9hiJOs99vkiIFdwZk5kJZgzPvwh6ENAwt3gVGFHAdUzq jRZk5QVEPFZA+xh0V4Ywtui9OpG7fe8qlI3mHf/ZP4+NSLUMFQ0mcaaKH7h/jM0R8gEk Gx4WnfwybqqRYLeVTavc3HmH3G/O3Y+pCd3GU= 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 :content-type:content-transfer-encoding; b=RLoMv21XbfCYvAqD+CLLsPeN+GZqog+Ej824XErhNDIg6f7d1tzoSjumRMktPwASqy iaSbu2PRLjuX5tLx5YqK7T7QWdeiL+kPHlktpPVr4XIunf66WmiQ0nMsc+T1JDl9YlrO Gn3vl5fbzxQ4pks1VT948Axiw6niptkllXl8A= MIME-Version: 1.0 Received: by 10.231.155.18 with SMTP id q18mr11018671ibw.44.1278012635742; Thu, 01 Jul 2010 12:30:35 -0700 (PDT) Received: by 10.231.146.206 with HTTP; Thu, 1 Jul 2010 12:30:35 -0700 (PDT) In-Reply-To: References: Date: Thu, 1 Jul 2010 14:30:35 -0500 Message-ID: From: Mary Barnes To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] Updated 4244bis and new call flow document X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 01 Jul 2010 19:30:31 -0000 Hi folks, I have not seen any responses to this email. So, either folks don't see any issues with the documents and 4244bis is ready for WGLC or folks have not reviewed the documents. I'm happy to assume the former, however, it would be good for folks that have read the docs to post a note on the mailing list as to whether they think 4244bis is ready for WGLC. And, if not, please detail your concerns, so that we can determine whether they warrant discussion in Maastricht. Also, opinions on how/where to progress the call flow document would be welcome. I personally do not think it's worthwhile to pursue this in DISPATCH, but it's not clear to me whether informational docs like this are under the purview of the SIPCORE charter. Since BLISS is trying to close down, it is also not appropriate to pursue the work there. Thanks, Mary. On Thu, Jun 24, 2010 at 3:11 PM, Mary Barnes w= rote: > Hi folks, > > The 4244bis draft has been updated and a separate call flow document > created per the earlier summary of proposed changes: > http://www.ietf.org/mail-archive/web/sipcore/current/msg02647.html > > http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-01.txt > http://www.ietf.org/id/draft-barnes-sipcore-rfc4244bis-callflows-00.txt > > There are =A0two voicemail examples in the new call flow document. =A0The > 4244bis has 3 call flows - the basic sequential forking and two > privacy examples. All the rest are now in the call flow document. > > The other changes we made were updates to the UAC, UAS and application > considerations section - adding additional text as to how the UAC and > UAS process hi-entries (including related to responses). =A0The > application considerations section now describes how the tags can be > used to derive specific information and the past guidelines were > removed since 4244bis has much definitive guidance on the normative > aspects of the header (i.e., SHOULDs replaced with MUSTs, privacy via > anonymization rather than removing entries, etc.) as summarized in > Section 11. > > Please review and provide any additional comments. We believe that > 4244bis is pretty much ready to go. We can fine tune the details in > the call flows and should be able to get that ready very soon, as > well. =A0Let us know if you see additional use cases you would like to > add. > > Thanks, > Mary et al > From shinji.okumura@softfront.jp Thu Jul 1 18:54:25 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 246233A686B for ; Thu, 1 Jul 2010 18:54:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.858 X-Spam-Level: X-Spam-Status: No, score=-96.858 tagged_above=-999 required=5 tests=[AWL=1.010, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, 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 jCav2uOmzG9w for ; Thu, 1 Jul 2010 18:54:24 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 5F0FB3A685C for ; Thu, 1 Jul 2010 18:54:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id E2B9A42800F; Fri, 2 Jul 2010 10:54:32 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ratCs6VdF1Zr; Fri, 2 Jul 2010 10:54:27 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id DDF8F42800C; Fri, 2 Jul 2010 10:54:26 +0900 (JST) From: OKUMURA Shinji To: SIPCORE Date: Fri, 02 Jul 2010 10:54:20 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: <4C2B328F.8050601@ericsson.com> References: <4C2AF154.9040905@ericsson.com> <53CB1844EA4162shinji.okumura@softfront.jp> <4C2B328F.8050601@ericsson.com> Message-Id: <5ECB19897C8959shinji.okumura@softfront.jp> Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 02 Jul 2010 01:54:25 -0000 Hi Gonzalo, I arrange my comments to clarify the issues. First, as a precondition for new rules, this text updates RFC3261. And so it is necessary to minimize the change in consideration of backward compatibility. I think this principle should be given priority to over the KISS principle. Therefore we should clarify not a sufficient condition but a necessary and sufficient condition. Second, you describe the rules about O/A and target-refresh at once. But I prefer to describe the two issues separately in order to clarify the reason why the rule is necessary. As we discuss the rules, it is acceptable result that the rules are unified accordingly. But it is premature at this moment in time. >>>>> The rules in RFC 3261 [RFC3261] do not cover collisions between an >>>>> UPDATE request and a reliable response to a re-INVITE (non-2xx final >>>>> responses to the re-INVITE are also considered reliable responses). >>>>> Since both the UPDATE request and the reliable response could be >>>>> requesting changes to the dialog or session state, it would not be >>>>> clear which changes would need to be executed first. >>>>> >>>>> If the UAS of a re-INVITE transaction receives and UPDATE request >>>>> after having sent a reliable response to the re-INVITE but before >>>>> having received the corresponding ACK or PRACK request, the UA SHOULD >>>>> return a 491 (Request Pending) response to the UPDATE request. >>>> >>>> I think this rule is more restrictive. >>>> IMO; >>>> In case that the reliable response is 18x, the UA SHOULD return a "500" response. >>>> In case that the reliable response is 2xx; >>>> If the 2xx carries an offer, the UA SHOULD return a "500" response. >>>> Otherwise, the UA MAY return a 2xx response. >>>> In case that the reliable response is 4xx, the UA MAY return a 2xx response. >>> >>> No, these rules would not address the glare situation. >From an offer-answer perspective, you should agree that there is no problem. >> I am very interested in this topic. Laying aside the >> response code, I don't understand the reason why these rules >> would not address the glare situation. >> Please explain the reason. >> >> In below cases, if a UAS returns a 2xx to the UPDATE, IMO >> no ploblem would be occured. > > as we discussed in the past, the collision of two given messages may or > may not be a problem. For example, two UPDATEs colliding each of them > updating a different parameter would not be a problem... but if they > update the same parameter the collision would get both UAs out of synch. > For the sake of simplicity, instead of having UAs implement complex > rules to figure out if a particular collision would cause problems, we > specify general rules that are (relatively) easy to implement by user > agents. > > So, let's take your example below > >> A B >> | | >> s0|re-INVITE (offer1) |s0 >> |------------------------------>| >> | 18x-rel(answer1)| >> |<------------------------------| >> s1|PRACK |s1 >> |------------------------------>| >> | 2xx-PRA| >> |<------------------------------|<-+ >> | 2xx| | >> | /--------------| | >> |UPDATE(offer2) / | | >> |==============/===============>| | accept PDATE >> | / 2xx-UPD(answer2)| | >> |<===========/==================| | >> s2| / |s2| >> |<---------/ | | >> |ACK | | >> |------------------------------>| | >> | | v > > > both the 2xx to the INVITE and the 2xx to the UPDATE can update the > dialog's target. As you see, the UAC receives them in a different order > than they were sent. So, for the UAC the latest target refresh was the > 2xx to the INVITE but for the UAS the latest target refresh was the 2xx > to the UPDATE. Your rules force a UAS to return a 491 response to the UPDATE. But if I understand a current RFCs correctly, a UAS may accept the UPDATE. Certainly, your rules are new normative definitions. I understand it. However if the 2xx to an UPDATE and the 2xx to a re-INVITE have the same Contact, there is no problem. And it is unnecessary to make an O/A exchange fail. In any cases, we can not deny the possibility that a legacy UAS returns a 2xx to the UPDATE with a different Contact. Therefore a UAC MUST be prepared to receive the 2xx. In this case, IMO UAC behavior are; 1. A UAC must treat the Contact in 2xx to an UPDATE as current remote target. 2. In below cases, a UAC should send new target refresh request. a. it has sent UPDATE, received 2xx to UPDATE, and then received 2xx to re-INVITE with a different Contact. b. it has received UPDATE, sent 2xx to UPDATE, and then received 2xx to re-INVITE with a different Contact. c. it has sent UPDATE, received 2xx to re-INVITE, and then received 2xx to UPDATE with a different Contact. Regards, Shinji Gonzalo Camarillo Wed, 30 Jun 2010 15:03:27 +0300 >Hi Shinji, > >thanks for your comments. I already responded to your first example in >my previous email. In your second example, the ACK (which does not carry >an answer) is not a problem because it is not a target refresh request. > >Thanks, > >Gonzalo From shinji.okumura@softfront.jp Thu Jul 1 23:12:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BE393A683E for ; Thu, 1 Jul 2010 23:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.003 X-Spam-Level: X-Spam-Status: No, score=-97.003 tagged_above=-999 required=5 tests=[AWL=0.865, BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, 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 Rc0d+BYrpzXB for ; Thu, 1 Jul 2010 23:12:26 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 65FDF3A67FE for ; Thu, 1 Jul 2010 23:12:26 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 1F88642800F; Fri, 2 Jul 2010 15:12:37 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id drdxFHzfGYWj; Fri, 2 Jul 2010 15:12:32 +0900 (JST) Received: from softfront.jp (p5042-ipngnfx01sapodori.hokkaido.ocn.ne.jp [114.160.211.106]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 07E4E42800C; Fri, 2 Jul 2010 15:12:30 +0900 (JST) From: OKUMURA Shinji To: SIPCORE Date: Fri, 02 Jul 2010 15:12:23 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.36 (WinNT,501) In-Reply-To: <4C29E540.4050402@ericsson.com> References: <4C230507.10105@ericsson.com> <4C29E540.4050402@ericsson.com> Message-Id: Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 02 Jul 2010 06:12:27 -0000 Hi Gonzalo, I'm studying the UAC behavior when it receives a reliable response to the re-INVITE. Gonzalo Camarillo Tue, 29 Jun 2010 15:21:20 +0300 (snip) >>> If >>> the UAC of a re-INVITE transaction sends an UPDATE request, receives >>> a reliable response to the re-INVITE, and then a 2xx response to the >>> UPDATE request, the UA 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, as described in Section 3.4. >> >> In case that the reliable response is 4xx, this rule is necessary >> from an offer-answer perspective. > >Exactly. > >> In case that the reliable response is 2xx or 18x, this rule seems >> to be also necessary from a remote-target perspective. > >Exactly. > >> But I'm not sure at present. > >Your understanding is correct. If the reliable response is 18x-rel, IMO signaling sequences are shown as below. A B | | s0|re-INVITE (offer1) |s0 |------------------------------>| | 18x-rel(answer1)| |<------------------------------| s1|PRACK |s1 |------------------------------>| | 2xx-PRA| |<------------------------------|<-+ |UPDATE | | |==============================>| | | 2xx-UPD(m:c1)| | | /================| | | / 18x-rel(m:c2)| | |<-----------/------------------| | | / | | |<=========/ | | |PRACK | | |------------------------------>| | accept UPDATE | 2xx-PRA| | |<------------------------------| | |UPDATE | | |==============================>| | | 2xx-UPD(m:c2)| | |<==============================| | | | | | | v There is no problem for an offer-answer interworking of an UPDATE and a 18x to a re-INVITE. Because the 2nd and subsequent 18x doesn't contain an offer. According to current text, the 18x-rel doesn't refresh a remote-target. But this draft changes the rules. That is, new definitions for a target-refresh cause this issue. And in another cases, A B | | s0|re-INVITE (offer1) |s0 |------------------------------>| | 18x-rel(answer1)| |<------------------------------| s1|PRACK |s1 |------------------------------>| | 2xx-PRA| |<------------------------------|<-+ | | | | UPDATE(m:c1)| | |<-------------\ /=============| | | \/ | | | /\ 18x-rel(m:c2)| | |<=============/ \-------------| | | | | accept UPDATE | | | | | v A B | | s0|re-INVITE (offer1) |s0 |------------------------------>| | 18x-rel(answer1)| |<------------------------------| s1|PRACK |s1 |------------------------------>| | 2xx-PRA| |<------------------------------|<-+ | | | | 18x-rel(m:c1)| | |<-------------\ /=============| | | \/ | | | /\ UPDATE(m:c2)| | |<=============/ \-------------| | | | | accept UPDATE | | | | | v After all, I think UAC should send an UPDATE every time it receives a 18x-rel with a different Contact. Regards, Shinji From gonzalo.camarillo@ericsson.com Fri Jul 2 06:01:29 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BCF203A68B1 for ; Fri, 2 Jul 2010 06:01:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.236 X-Spam-Level: X-Spam-Status: No, score=-105.236 tagged_above=-999 required=5 tests=[AWL=1.363, 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 dEOA6RV4FJP2 for ; Fri, 2 Jul 2010 06:01:28 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 9C4283A68D5 for ; Fri, 2 Jul 2010 06:00:59 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-a2-4c2de317bcb0 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 05.01.10125.713ED2C4; Fri, 2 Jul 2010 15:01:11 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Jul 2010 15:01:10 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Jul 2010 15:01:10 +0200 Message-ID: <4C2DE315.40304@ericsson.com> Date: Fri, 02 Jul 2010 16:01:09 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Paul Kyzivat References: <4C230507.10105@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCD53715@EXMBXCLUS01.citservers.local> <4C2AF2BA.1070602@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCE7EC16@EXMBXCLUS01.citservers.local> <4C2B3864.4050708@ericsson.com> <4C2B4A09.3090006@cisco.com> <4C2B4F99.9020707@cisco.com> <4C2C45E4.50200@ericsson.com> <4C2CB90C.7060608@cisco.com> In-Reply-To: <4C2CB90C.7060608@cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2010 13:01:10.0229 (UTC) FILETIME=[A471E050:01CB19E6] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 02 Jul 2010 13:01:29 -0000 Hi Paul, good point. I have re-structured the text so that the four different scenarios are covered and, additionally, are more clearly described. Please, review Sections 4.1 through 4.7: http://users.piuha.net/gonzalo/temp/draft-ietf-sipcore-reinvite-pre05-00.txt Thanks, Gonzalo On 01/07/2010 6:49 PM, Paul Kyzivat wrote: > Gonzalo, > > I like the new paragraph. > > But I think the procedures in the rest of the section are still incomplete. > > Section 4.3 is limited to cases when the UAC is attempting to change > *its* address and 4.4 is limited to cases when the UAS as received a > request from a UAC that is attempting to change its address. > > The case where the UAS wants (needs) to change its address is largely > unmentioned. This is of course a strange situation, which would require > some freak timing, but it is possible. (To be fair, 4.3 does touch on > the case where the UAS receives a response with a changed address. But > since the whole section is restricted to a UAC changing its own address, > it doesn't cover the case where only the UAS is changing its address.) > > If the UAS just *wants* to make the change, then it would be best for it > to wait until it can send a request of its own. If it *needs* to make a > change, then it must do what it must do. But then there are limits such > as you have already identified. > > Specifically, if the UAS received an initial or re-INVITE, and send a > reliable provisional response with one address, then it would be > permitted to send another reliable response with a different address. > But if it send an unreliable provisional with one address, then there > are problems with sending another unreliable provisional with a > different address. Specifically the problems are with which one the UAC > believes when some may be lost or reordered. > > For an initial invite you already point out one solution in 4.6: change > the to-tag and thus establish a new early dialog. That is a great > solution for the UAS in this case. > > There is another solution for the UAS in a reINVITE: send an out of > dialog INVITE/Replaces, transferring the call to the new address. > > Perhaps it is sufficient to offer those solutions to the UAS while > keeping the rules you have spelled out for the UAC to ignore changes to > the remote address in unreliable responses. > > Thanks, > Paul > > Gonzalo Camarillo wrote: >> Hi Paul, >> >> what I had in mind is exactly what you proposed below. It's good to see >> we are on the same page! >> >> I have added a second paragraph to Section 4.6 to address this issue. >> The whole section looks as follows now: >> >> >> 4.6. Early Dialogs >> >> The rules given in this section about which messages can refresh the >> target of a dialog also apply to early dialogs created by an initial >> INVITE transaction. Additionally, as specified in Section 13.2.2.4 >> of RFC 3261 [RFC3261], on receiving a 2xx response to the initial >> INVITE, the UAC recomputes the whole route set of the dialog, which >> transitions from the "early" state to the "confirmed" state. >> >> Section 12.1 of RFC 3261 allows unreliable provisional responses to >> create early dialogs. However, per the rules given in this section, >> unreliable provisional responses cannot refresh the target of a >> dialog. Therefore, the UAC of an initial INVITE transaction will not >> perform any target refresh as a result of the reception of an >> unreliable provisional response with an updated Contact value on an >> (already-established) early dialog. Note also that a given UAS can >> establish additional early dialogs, which can have different targets, >> by returning additional unreliable provisional responses with >> different To tags. >> >> Cheers, >> >> Gonzalo >> >> On 30/06/2010 5:07 PM, Paul Kyzivat wrote: >>> Replying to myself, >>> >>> Perhaps the answer here is that a non-reliable response to an initial >>> INVITE can indeed establish an early dialog. But then the contact >>> address in all subsequent non-reliable responses must remain identical >>> to that in the first non-reliable response. And Contacts received in >>> non-reliable responses, except the first one received, must be ignored. >>> >>> That would allow use of INFO and UPDATE in an early dialog without >>> 100rel, and even a remote target change via the UPDATE in that case. >>> >>> Thanks, >>> Paul >>> >>> Paul Kyzivat wrote: >>>> >>>> Gonzalo Camarillo wrote: >>>> >>>>>> The following rule only discusses reliable provisional responses. >>>>>> What are rules for non reliable provisional responses? >>>>> non-reliable responses do not refresh the target because SIP does not >>>>> provide any type of ordering for them. I can clarify that if you think >>>>> it is unclear. >>>> Hmm. I think that is debatable. >>>> >>>> That logic would suggest that non-reliable provisionals also could not >>>> establish an early dialog in the first place, since there might have >>>> been more than one with different targets that got reordered. >>>> >>>> My reading of 3261 and 3311 leaves me with the conclusion that I could >>>> receive a non-reliable provisional, consider that to establish an early >>>> dialog, and then send an UPDATE, without ever using 100rel. >>>> >>>> OTOH, there is logic to your argument. So maybe what you propose is the >>>> "right" solution even if it is to some extent incompatible with things >>>> as they stand. If so, then there should be an additional explicit >>>> statement that non-reliable provisionals never establish an early dialog. >>>> >>>> That would also mean that INFO could not be used before 2xx unless >>>> 100rel was used to establish the early dialog. >>>> >>>> Thanks, >>>> Paul >>>> _______________________________________________ >>>> sipcore mailing list >>>> sipcore@ietf.org >>>> https://www.ietf.org/mailman/listinfo/sipcore >>>> >> >> From gonzalo.camarillo@ericsson.com Fri Jul 2 06:05:48 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7882F3A67DA for ; Fri, 2 Jul 2010 06:05:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.25 X-Spam-Level: X-Spam-Status: No, score=-103.25 tagged_above=-999 required=5 tests=[AWL=-0.651, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5GSmbqtAeXBb for ; Fri, 2 Jul 2010 06:05:46 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id ACADF3A67D9 for ; Fri, 2 Jul 2010 06:05:45 -0700 (PDT) X-AuditID: c1b4fb39-b7ceaae000004c90-aa-4c2de4349c65 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id DD.36.19600.434ED2C4; Fri, 2 Jul 2010 15:05: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); Fri, 2 Jul 2010 15:05:56 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 2 Jul 2010 15:05:56 +0200 Message-ID: <4C2DE433.5000208@ericsson.com> Date: Fri, 02 Jul 2010 16:05:55 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: OKUMURA Shinji References: <4C230507.10105@ericsson.com> <4C29E540.4050402@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Jul 2010 13:05:56.0120 (UTC) FILETIME=[4ED96180:01CB19E7] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 02 Jul 2010 13:05:48 -0000 Hi Shinji, > After all, I think UAC should send an UPDATE every time it > receives a 18x-rel with a different Contact. In SIP, a UA can reject a request, but not a response. That is why the UAS does not need a confirmation from the UAC (e.g., the UPDATE request you propose) of the fact that the UAC accepted the response. The UAC did not have a choice; it had to accept the response. Thanks, Gonzalo From shinji.okumura@softfront.jp Fri Jul 2 08:42:25 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C7543A67F0 for ; Fri, 2 Jul 2010 08:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.868 X-Spam-Level: X-Spam-Status: No, score=-97.868 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, 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 C1ZFbEOPZjmr for ; Fri, 2 Jul 2010 08:42:24 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id 56E6C3A67B8 for ; Fri, 2 Jul 2010 08:42:23 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id DE79142800F; Sat, 3 Jul 2010 00:42:34 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFqsNugAt9uA; Sat, 3 Jul 2010 00:42:29 +0900 (JST) Received: from softfront.jp (112.136.80.28.er.eaccess.ne.jp [112.136.80.28]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 6495642800C; Sat, 3 Jul 2010 00:42:28 +0900 (JST) From: OKUMURA Shinji To: SIPCORE Date: Sat, 03 Jul 2010 00:42:27 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.33 (WinNT,501) In-Reply-To: <4C2DE433.5000208@ericsson.com> References: <4C29E540.4050402@ericsson.com> <4C2DE433.5000208@ericsson.com> Message-Id: <43CB19FD2C4635shinji.okumura@softfront.jp> Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 02 Jul 2010 15:42:25 -0000 Hi Gonzalo, >Hi Shinji, > >> After all, I think UAC should send an UPDATE every time it >> receives a 18x-rel with a different Contact. > >In SIP, a UA can reject a request, but not a response. That is why the >UAS does not need a confirmation from the UAC (e.g., the UPDATE request >you propose) of the fact that the UAC accepted the response. The UAC did >not have a choice; it had to accept the response. I don't understand what point you are making. The UPDATE request I propose make sure which is a current remort target, c1 or c2. And a UAC needs the confirmation. You seem to misunderstand my figures. Regards, Shinji From pkyzivat@cisco.com Fri Jul 2 09:17:01 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9424B3A68EE for ; Fri, 2 Jul 2010 09:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.279 X-Spam-Level: X-Spam-Status: No, score=-10.279 tagged_above=-999 required=5 tests=[AWL=0.320, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CsiUnMKS8gI6 for ; Fri, 2 Jul 2010 09:16:58 -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 82EFB3A68E3 for ; Fri, 2 Jul 2010 09:16:58 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGOtLUxAZnwM/2dsb2JhbACfYnGkTZpNhSQEiDU X-IronPort-AV: E=Sophos;i="4.53,527,1272844800"; d="scan'208";a="128055799" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 02 Jul 2010 16:17:09 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o62GH9Ml015124; Fri, 2 Jul 2010 16:17:09 GMT Message-ID: <4C2E1106.2060706@cisco.com> Date: Fri, 02 Jul 2010 12:17:10 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4C230507.10105@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCD53715@EXMBXCLUS01.citservers.local> <4C2AF2BA.1070602@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCE7EC16@EXMBXCLUS01.citservers.local> <4C2B3864.4050708@ericsson.com> <4C2B4A09.3090006@cisco.com> <4C2B4F99.9020707@cisco.com> <4C2C45E4.50200@ericsson.com> <4C2CB90C.7060608@cisco.com> <4C2DE315.40304@ericsson.com> In-Reply-To: <4C2DE315.40304@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 02 Jul 2010 16:17:01 -0000 Gonzalo, Gonzalo Camarillo wrote: > Hi Paul, > > good point. I have re-structured the text so that the four different > scenarios are covered and, additionally, are more clearly described. > Please, review Sections 4.1 through 4.7: > > http://users.piuha.net/gonzalo/temp/draft-ietf-sipcore-reinvite-pre05-00.txt Those changes do help. The introduction of "local target" makes things clearer to talk about. A couple more things: 4.6: "... the UA SHOULD send a request to the remote UA ..." I presume this should say "... the UA SHOULD send an in-dialog request to the remote UA ...". If you didn't mean that, then we need to talk further. 4.7: I think this should also say: "If a UA receives an unreliable provisional response to a target-refresh request, the UA MUST NOT replace the dialog's remote target URI." You alude to this in 4.9, but I don't find it stated anywhere. Thanks, Paul > On 01/07/2010 6:49 PM, Paul Kyzivat wrote: >> Gonzalo, >> >> I like the new paragraph. >> >> But I think the procedures in the rest of the section are still incomplete. >> >> Section 4.3 is limited to cases when the UAC is attempting to change >> *its* address and 4.4 is limited to cases when the UAS as received a >> request from a UAC that is attempting to change its address. >> >> The case where the UAS wants (needs) to change its address is largely >> unmentioned. This is of course a strange situation, which would require >> some freak timing, but it is possible. (To be fair, 4.3 does touch on >> the case where the UAS receives a response with a changed address. But >> since the whole section is restricted to a UAC changing its own address, >> it doesn't cover the case where only the UAS is changing its address.) >> >> If the UAS just *wants* to make the change, then it would be best for it >> to wait until it can send a request of its own. If it *needs* to make a >> change, then it must do what it must do. But then there are limits such >> as you have already identified. >> >> Specifically, if the UAS received an initial or re-INVITE, and send a >> reliable provisional response with one address, then it would be >> permitted to send another reliable response with a different address. >> But if it send an unreliable provisional with one address, then there >> are problems with sending another unreliable provisional with a >> different address. Specifically the problems are with which one the UAC >> believes when some may be lost or reordered. >> >> For an initial invite you already point out one solution in 4.6: change >> the to-tag and thus establish a new early dialog. That is a great >> solution for the UAS in this case. >> >> There is another solution for the UAS in a reINVITE: send an out of >> dialog INVITE/Replaces, transferring the call to the new address. >> >> Perhaps it is sufficient to offer those solutions to the UAS while >> keeping the rules you have spelled out for the UAC to ignore changes to >> the remote address in unreliable responses. >> >> Thanks, >> Paul >> >> Gonzalo Camarillo wrote: >>> Hi Paul, >>> >>> what I had in mind is exactly what you proposed below. It's good to see >>> we are on the same page! >>> >>> I have added a second paragraph to Section 4.6 to address this issue. >>> The whole section looks as follows now: >>> >>> >>> 4.6. Early Dialogs >>> >>> The rules given in this section about which messages can refresh the >>> target of a dialog also apply to early dialogs created by an initial >>> INVITE transaction. Additionally, as specified in Section 13.2.2.4 >>> of RFC 3261 [RFC3261], on receiving a 2xx response to the initial >>> INVITE, the UAC recomputes the whole route set of the dialog, which >>> transitions from the "early" state to the "confirmed" state. >>> >>> Section 12.1 of RFC 3261 allows unreliable provisional responses to >>> create early dialogs. However, per the rules given in this section, >>> unreliable provisional responses cannot refresh the target of a >>> dialog. Therefore, the UAC of an initial INVITE transaction will not >>> perform any target refresh as a result of the reception of an >>> unreliable provisional response with an updated Contact value on an >>> (already-established) early dialog. Note also that a given UAS can >>> establish additional early dialogs, which can have different targets, >>> by returning additional unreliable provisional responses with >>> different To tags. >>> >>> Cheers, >>> >>> Gonzalo >>> >>> On 30/06/2010 5:07 PM, Paul Kyzivat wrote: >>>> Replying to myself, >>>> >>>> Perhaps the answer here is that a non-reliable response to an initial >>>> INVITE can indeed establish an early dialog. But then the contact >>>> address in all subsequent non-reliable responses must remain identical >>>> to that in the first non-reliable response. And Contacts received in >>>> non-reliable responses, except the first one received, must be ignored. >>>> >>>> That would allow use of INFO and UPDATE in an early dialog without >>>> 100rel, and even a remote target change via the UPDATE in that case. >>>> >>>> Thanks, >>>> Paul >>>> >>>> Paul Kyzivat wrote: >>>>> Gonzalo Camarillo wrote: >>>>> >>>>>>> The following rule only discusses reliable provisional responses. >>>>>>> What are rules for non reliable provisional responses? >>>>>> non-reliable responses do not refresh the target because SIP does not >>>>>> provide any type of ordering for them. I can clarify that if you think >>>>>> it is unclear. >>>>> Hmm. I think that is debatable. >>>>> >>>>> That logic would suggest that non-reliable provisionals also could not >>>>> establish an early dialog in the first place, since there might have >>>>> been more than one with different targets that got reordered. >>>>> >>>>> My reading of 3261 and 3311 leaves me with the conclusion that I could >>>>> receive a non-reliable provisional, consider that to establish an early >>>>> dialog, and then send an UPDATE, without ever using 100rel. >>>>> >>>>> OTOH, there is logic to your argument. So maybe what you propose is the >>>>> "right" solution even if it is to some extent incompatible with things >>>>> as they stand. If so, then there should be an additional explicit >>>>> statement that non-reliable provisionals never establish an early dialog. >>>>> >>>>> That would also mean that INFO could not be used before 2xx unless >>>>> 100rel was used to establish the early dialog. >>>>> >>>>> Thanks, >>>>> Paul >>>>> _______________________________________________ >>>>> sipcore mailing list >>>>> sipcore@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/sipcore >>>>> >>> > > From gonzalo.camarillo@ericsson.com Sun Jul 4 23:20:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6BEE3A68BB for ; Sun, 4 Jul 2010 23:20:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.185 X-Spam-Level: X-Spam-Status: No, score=-100.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, 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 NlDTxrYoKwq6 for ; Sun, 4 Jul 2010 23:20:20 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 79BA63A68E7 for ; Sun, 4 Jul 2010 23:20:20 -0700 (PDT) X-AuditID: c1b4fb39-b7bc4ae000006582-49-4c3179a49b2b Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 47.E9.25986.4A9713C4; Mon, 5 Jul 2010 08:20:20 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Jul 2010 08:20:20 +0200 Received: from [131.160.126.198] ([131.160.126.198]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Jul 2010 08:20:20 +0200 Message-ID: <4C3179A1.9060800@ericsson.com> Date: Mon, 05 Jul 2010 09:20:17 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Paul Kyzivat References: <4C230507.10105@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCD53715@EXMBXCLUS01.citservers.local> <4C2AF2BA.1070602@ericsson.com> <7FF1E5E16911C54BB2D57D4C4A2ED35A01DCE7EC16@EXMBXCLUS01.citservers.local> <4C2B3864.4050708@ericsson.com> <4C2B4A09.3090006@cisco.com> <4C2B4F99.9020707@cisco.com> <4C2C45E4.50200@ericsson.com> <4C2CB90C.7060608@cisco.com> <4C2DE315.40304@ericsson.com> <4C2E1106.2060706@cisco.com> In-Reply-To: <4C2E1106.2060706@cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2010 06:20:20.0166 (UTC) FILETIME=[24BABE60:01CB1C0A] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Glare conditions in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 05 Jul 2010 06:20:21 -0000 Hi Paul, thanks for your comments. Answers inline: > 4.6: "... the UA SHOULD send a request to the remote UA ..." > > I presume this should say "... the UA SHOULD send an in-dialog request > to the remote UA ...". If you didn't mean that, then we need to talk > further. Fixed. > 4.7: I think this should also say: "If a UA receives an unreliable > provisional response to a target-refresh request, the UA MUST NOT > replace the dialog's remote target URI." You alude to this in 4.9, but I > don't find it stated anywhere. I did not originally added such a sentence because the draft already says that only reliable responses can do that. However, I agree with you that adding the sentence you propose here make things more explicit and clearer. So, I have added the sentence per your suggestion. Thanks, Gonzalo From gonzalo.camarillo@ericsson.com Sun Jul 4 23:34:49 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 59D023A68CF for ; Sun, 4 Jul 2010 23:34:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -100.462 X-Spam-Level: X-Spam-Status: No, score=-100.462 tagged_above=-999 required=5 tests=[AWL=0.277, BAYES_20=-0.74, 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 ipABtUAbOqT0 for ; Sun, 4 Jul 2010 23:34:46 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 142E23A68FB for ; Sun, 4 Jul 2010 23:34:42 -0700 (PDT) X-AuditID: c1b4fb39-b7bc4ae000006582-a6-4c317d031676 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id AC.9B.25986.30D713C4; Mon, 5 Jul 2010 08:34:43 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Jul 2010 08:34:43 +0200 Received: from [131.160.126.198] ([131.160.126.198]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 5 Jul 2010 08:34:43 +0200 Message-ID: <4C317D02.2030307@ericsson.com> Date: Mon, 05 Jul 2010 09:34:42 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: SIPCORE X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Jul 2010 06:34:43.0124 (UTC) FILETIME=[2717AF40:01CB1C0C] X-Brightmail-Tracker: AAAAAA== Subject: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 05 Jul 2010 06:34:49 -0000 Hi, the re-INVITE draft talks about modifications in the session state, dialog state, and the dialog's remote target. While it is relatively well understood what we mean by session state and the dialog's remote target, we do not really have a good definition for dialog state. We have discussed it in the past and what people had in mind were things such as called party identity. However, the draft is too vague at this point; it should be more precise regarding which piece of "dialog state" the rules in the draft apply to. My suggestion would be to have the draft talk only about session state and the dialog's remote target, and forget about any other dialog state. New extensions whose parameters can be modified by re-INVITEs can specify their own rules, possibly referring to this draft and using the rules defined in it by reference. In this way, the applicability of this draft would be much clearer. Comments? Thanks, Gonzalo From gao.yang2@zte.com.cn Mon Jul 5 02:19:17 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3CC1B3A6864 for ; Mon, 5 Jul 2010 02:19:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -93.835 X-Spam-Level: X-Spam-Status: No, score=-93.835 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, J_CHICKENPOX_63=0.6, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 KYz4wcjRkpQa for ; Mon, 5 Jul 2010 02:19:16 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 8CE023A6812 for ; Mon, 5 Jul 2010 02:19:15 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 552341727820181; Mon, 5 Jul 2010 17:18:39 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 34935.2980680612; Mon, 5 Jul 2010 17:11:58 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o659FaCp041635; Mon, 5 Jul 2010 17:15:36 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4C317D02.2030307@ericsson.com> To: Gonzalo Camarillo MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 5 Jul 2010 17:11:57 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-05 17:15:26, Serialize complete at 2010-07-05 17:15:26 Content-Type: multipart/alternative; boundary="=_alternative 0032C73848257757_=" X-MAIL: mse2.zte.com.cn o659FaCp041635 Cc: SIPCORE Subject: Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 05 Jul 2010 09:19:17 -0000 This is a multipart message in MIME format. --=_alternative 0032C73848257757_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgR29uemFsbywNCg0KRmlzcnQsIEkgYW0gZ2xhZCB0byBoZWFyIGFib3V0IHRoaXMgc3VnZ2Vz dGlvbi4gQW5kIEkgb25jZSBwcm9wb3NlZCB0aGUgDQpzaW1pbGFyIGlkZWEsIGFzIHB1dHRpbmcg dGhpbmdzIHdoaWNoIGhhcyBiZWVuIGNsZWFyZWQgZm9yd2FyZCwgYW5kIG1ha2UgDQp0aGUgYmFz aWMgcnVsZXMoc3VjaCBhcyAqaW4gdXNlKiB3YXkgZm9yIE8vQSB1c2FnZSwgYW5kIG5vdGlmeSB3 YXkgZm9yIA0KcmVtb3RlIHRhcmdldCkgYXMgcmVmZXJlbmNlIGZvciBvdGhlciAqZGlhbG9nIHN0 YXRlKiB1c2FnZXMsIGluIHNlcGFyYXRlIA0KZHJhZnRzLg0KDQpTZWNvbmQsIEkgb25jZSBkbyBv bmUgcHJvcG9zYWwgZm9yIHRoZSBvdGhlciAqZGlhbG9nIHN0YXRlKiB1c2FnZXMgaW4gb25lIA0K cHJldmlvdXMgbWFpbDoNCmh0dHA6Ly93d3cuaWV0Zi5vcmcvbWFpbC1hcmNoaXZlL3dlYi9zaXBj b3JlL2N1cnJlbnQvbXNnMDI4NTAuaHRtbA0KSSB0aGluayB3ZSBtaWdodCBuZWVkIHNldmVyYWwg bW9udGhzJ3MgZGlzY3Vzc2lvbiBmb3Igc3VjaCB0b3BpY3MuDQoNClRoaXJkLCBJIHN1Z2dlc3Qg b25lIGV4cGVydChHb256YWxvLCBQYXVsLCBvciBSb2JlcnQ/KSB0byBkcmFmdCBvdXQgb25lIA0K ZHJhZnQsIHRvIGNvbGxlY3QgcmVxdWlybWVudHMgZm9yIHRoZSByZW1haW5pbmcgdG9waWNzKHRo ZSBvdGhlciAqZGlhbG9nIA0Kc3RhdGUqIHVzYWdlcydzKSB3aGljaCBzdGlsbCBuZWVkIG5vcm1h dGl2ZSBkZWZpbml0aW9uL2NsYXJpZmljYXRpb24uIFRoaXMgDQptZW1vIHdvdWxkIGhhdmUgdGhl IGZvbGxvd2luZyBtZWFuaW5nczoNCjEuIFRvIGZpZ3VyZSBvdXQgY3VycmVudCBzdGF0dXMgb2Yg YWxsIFNJUCBDb3JlIHN0YW5kYXJkOw0KMi4gQXMgbWVtbyBvZiBjb25jbHVzaW9ucyBmb3IgcG9p bnRzLg0KMy4gSWYgc29tZWRheSwgd2UgbmVlZCAzMjYxYmlzLCB0aGlzIG1pZ2h0IGJlIGEgbm90 IGJhZCBzdGFydC4gDQoNClRoYW5rcywNCg0KR2FvDQoNCj09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09DQogWmlwICAgIDogMjEwMDEyDQogVGVsICAgIDogODcyMTENCiBUZWwyICAg OigrODYpLTAyNS01Mjg3NzIxMQ0KIGVfbWFpbCA6IGdhby55YW5nMkB6dGUuY29tLmNuDQo9PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KDQoNCg0KR29uemFsbyBDYW1hcmlsbG8g PEdvbnphbG8uQ2FtYXJpbGxvQGVyaWNzc29uLmNvbT4gDQq3orz+yMs6ICBzaXBjb3JlLWJvdW5j ZXNAaWV0Zi5vcmcNCjIwMTAtMDctMDUgMTQ6MzQNCg0KytW8/sjLDQpTSVBDT1JFIDxzaXBjb3Jl QGlldGYub3JnPg0Ks63LzQ0KDQrW98ziDQpbc2lwY29yZV0gRGlhbG9nIHN0YXRlIC0gU2NvcGUg aW4gZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlDQoNCg0KDQoNCg0KDQpIaSwNCg0KdGhlIHJl LUlOVklURSBkcmFmdCB0YWxrcyBhYm91dCBtb2RpZmljYXRpb25zIGluIHRoZSBzZXNzaW9uIHN0 YXRlLA0KZGlhbG9nIHN0YXRlLCBhbmQgdGhlIGRpYWxvZydzIHJlbW90ZSB0YXJnZXQuIFdoaWxl IGl0IGlzIHJlbGF0aXZlbHkNCndlbGwgdW5kZXJzdG9vZCB3aGF0IHdlIG1lYW4gYnkgc2Vzc2lv biBzdGF0ZSBhbmQgdGhlIGRpYWxvZydzIHJlbW90ZQ0KdGFyZ2V0LCB3ZSBkbyBub3QgcmVhbGx5 IGhhdmUgYSBnb29kIGRlZmluaXRpb24gZm9yIGRpYWxvZyBzdGF0ZS4NCg0KV2UgaGF2ZSBkaXNj dXNzZWQgaXQgaW4gdGhlIHBhc3QgYW5kIHdoYXQgcGVvcGxlIGhhZCBpbiBtaW5kIHdlcmUgdGhp bmdzDQpzdWNoIGFzIGNhbGxlZCBwYXJ0eSBpZGVudGl0eS4gSG93ZXZlciwgdGhlIGRyYWZ0IGlz IHRvbyB2YWd1ZSBhdCB0aGlzDQpwb2ludDsgaXQgc2hvdWxkIGJlIG1vcmUgcHJlY2lzZSByZWdh cmRpbmcgd2hpY2ggcGllY2Ugb2YgImRpYWxvZyBzdGF0ZSINCnRoZSBydWxlcyBpbiB0aGUgZHJh ZnQgYXBwbHkgdG8uDQoNCk15IHN1Z2dlc3Rpb24gd291bGQgYmUgdG8gaGF2ZSB0aGUgZHJhZnQg dGFsayBvbmx5IGFib3V0IHNlc3Npb24gc3RhdGUNCmFuZCB0aGUgZGlhbG9nJ3MgcmVtb3RlIHRh cmdldCwgYW5kIGZvcmdldCBhYm91dCBhbnkgb3RoZXIgZGlhbG9nIHN0YXRlLg0KTmV3IGV4dGVu c2lvbnMgd2hvc2UgcGFyYW1ldGVycyBjYW4gYmUgbW9kaWZpZWQgYnkgcmUtSU5WSVRFcyBjYW4N CnNwZWNpZnkgdGhlaXIgb3duIHJ1bGVzLCBwb3NzaWJseSByZWZlcnJpbmcgdG8gdGhpcyBkcmFm dCBhbmQgdXNpbmcgdGhlDQpydWxlcyBkZWZpbmVkIGluIGl0IGJ5IHJlZmVyZW5jZS4gSW4gdGhp cyB3YXksIHRoZSBhcHBsaWNhYmlsaXR5IG9mIHRoaXMNCmRyYWZ0IHdvdWxkIGJlIG11Y2ggY2xl YXJlci4NCg0KQ29tbWVudHM/DQoNClRoYW5rcywNCg0KR29uemFsbw0KDQpfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxpc3QN CnNpcGNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2lwY29yZQ0KDQoNCg0KDQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tDQpaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUg aW5mb3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2Yg dGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24gaXMgY29u ZmlkZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRh aW4gc2VjcmVjeSBhbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRlbnRz IG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byBvdGhlcnMuDQpUaGlzIGVtYWlsIGFuZCBhbnkgZmls ZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBzb2xl bHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdob20gdGhleSBh cmUgYWRkcmVzc2VkLiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIGVtYWlsIGluIGVycm9yIHBs ZWFzZSBub3RpZnkgdGhlIG9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2aWV3cyBleHBy ZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5kaXZpZHVhbCBzZW5kZXIu DQpUaGlzIG1lc3NhZ2UgaGFzIGJlZW4gc2Nhbm5lZCBmb3IgdmlydXNlcyBhbmQgU3BhbSBieSBa VEUgQW50aS1TcGFtIHN5c3RlbS4NCg== --=_alternative 0032C73848257757_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEdvbnphbG8sPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5GaXNydCwgSSBhbSBnbGFk IHRvIGhlYXIgYWJvdXQgdGhpcw0Kc3VnZ2VzdGlvbi4gQW5kIEkgb25jZSBwcm9wb3NlZCB0aGUg c2ltaWxhciBpZGVhLCBhcyBwdXR0aW5nIHRoaW5ncyB3aGljaA0KaGFzIGJlZW4gY2xlYXJlZCBm b3J3YXJkLCBhbmQgbWFrZSB0aGUgYmFzaWMgcnVsZXMoc3VjaCBhcyAqaW4gdXNlKiB3YXkNCmZv ciBPL0EgdXNhZ2UsIGFuZCBub3RpZnkgd2F5IDwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPmZvciBy ZW1vdGUgdGFyZ2V0PC9mb250PjwvdHQ+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPikN CmFzIDwvZm9udD48dHQ+PGZvbnQgc2l6ZT0yPnJlZmVyZW5jZTwvZm9udD48L3R0Pjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj4NCmZvciBvdGhlciAqZGlhbG9nIHN0YXRlKiB1c2FnZXMs IGluIHNlcGFyYXRlIGRyYWZ0cy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9 InNhbnMtc2VyaWYiPlNlY29uZCwgSSBvbmNlIGRvIG9uZSBwcm9wb3NhbCBmb3IgdGhlDQpvdGhl ciAqZGlhbG9nIHN0YXRlKiB1c2FnZXMgaW4gb25lIHByZXZpb3VzIG1haWw6PC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5odHRwOi8vd3d3LmlldGYub3JnL21haWwt YXJjaGl2ZS93ZWIvc2lwY29yZS9jdXJyZW50L21zZzAyODUwLmh0bWw8L2ZvbnQ+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkkgdGhpbmsgd2UgbWlnaHQgbmVlZCBzZXZlcmFs IG1vbnRocydzDQpkaXNjdXNzaW9uIGZvciBzdWNoIHRvcGljcy48L2ZvbnQ+DQo8YnI+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoaXJkLCBJIHN1Z2dlc3Qgb25lIGV4cGVy dChHb256YWxvLA0KUGF1bCwgb3IgUm9iZXJ0PykgdG8gZHJhZnQgb3V0IG9uZSBkcmFmdCwgdG8g Y29sbGVjdCByZXF1aXJtZW50cyBmb3IgdGhlDQpyZW1haW5pbmcgdG9waWNzKHRoZSBvdGhlciAq ZGlhbG9nIHN0YXRlKiB1c2FnZXMncykgd2hpY2ggc3RpbGwgbmVlZCBub3JtYXRpdmUNCmRlZmlu aXRpb24vY2xhcmlmaWNhdGlvbi4gVGhpcyBtZW1vIHdvdWxkIGhhdmUgdGhlIGZvbGxvd2luZyBt ZWFuaW5nczo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjEuIFRv IGZpZ3VyZSBvdXQgY3VycmVudCBzdGF0dXMgb2YgYWxsDQpTSVAgQ29yZSBzdGFuZGFyZDs8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjIuIEFzIG1lbW8gb2YgY29u Y2x1c2lvbnMgZm9yIHBvaW50cy48L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPjMuIElmIHNvbWVkYXksIHdlIG5lZWQgMzI2MWJpcywgdGhpcw0KbWlnaHQgYmUgYSBu b3QgYmFkIHN0YXJ0LiA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPlRoYW5rcyw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMt c2VyaWYiPkdhbzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJp ZiI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT08YnI+DQogWmlwICZuYnNwOyAm bmJzcDs6IDIxMDAxMjxicj4NCiBUZWwgJm5ic3A7ICZuYnNwOzogODcyMTE8YnI+DQogVGVsMiAm bmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiBlX21haWwgOiBnYW8ueWFuZzJAenRlLmNv bS5jbjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PC9mb250Pg0KPGJy Pg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZCB3 aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPjxiPkdvbnphbG8gQ2FtYXJp bGxvICZsdDtHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb20mZ3Q7PC9iPg0KPC9mb250Pg0K PGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63orz+yMs6ICZuYnNwO3NpcGNvcmUt Ym91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij4yMDEwLTA3LTA1IDE0OjM0PC9mb250Pg0KPHRkIHdpZHRoPTY0JT4NCjx0YWJsZSB3aWR0aD0x MDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9 MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0x IGZhY2U9InNhbnMtc2VyaWYiPlNJUENPUkUgJmx0O3NpcGNvcmVAaWV0Zi5vcmcmZ3Q7PC9mb250 Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250PjwvZGl2Pg0KPHRkPg0KPHRyIHZhbGlnbj10b3A+ DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W 98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5bc2lw Y29yZV0gRGlhbG9nIHN0YXRlIC0gU2NvcGUgaW4gZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRl PC9mb250PjwvdGFibGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0 ZD48L3RhYmxlPg0KPGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj5IaSw8YnI+DQo8YnI+DQp0aGUgcmUtSU5WSVRFIGRyYWZ0IHRhbGtzIGFib3V0IG1vZGlmaWNh dGlvbnMgaW4gdGhlIHNlc3Npb24gc3RhdGUsPGJyPg0KZGlhbG9nIHN0YXRlLCBhbmQgdGhlIGRp YWxvZydzIHJlbW90ZSB0YXJnZXQuIFdoaWxlIGl0IGlzIHJlbGF0aXZlbHk8YnI+DQp3ZWxsIHVu ZGVyc3Rvb2Qgd2hhdCB3ZSBtZWFuIGJ5IHNlc3Npb24gc3RhdGUgYW5kIHRoZSBkaWFsb2cncyBy ZW1vdGU8YnI+DQp0YXJnZXQsIHdlIGRvIG5vdCByZWFsbHkgaGF2ZSBhIGdvb2QgZGVmaW5pdGlv biBmb3IgZGlhbG9nIHN0YXRlLjxicj4NCjxicj4NCldlIGhhdmUgZGlzY3Vzc2VkIGl0IGluIHRo ZSBwYXN0IGFuZCB3aGF0IHBlb3BsZSBoYWQgaW4gbWluZCB3ZXJlIHRoaW5nczxicj4NCnN1Y2gg YXMgY2FsbGVkIHBhcnR5IGlkZW50aXR5LiBIb3dldmVyLCB0aGUgZHJhZnQgaXMgdG9vIHZhZ3Vl IGF0IHRoaXM8YnI+DQpwb2ludDsgaXQgc2hvdWxkIGJlIG1vcmUgcHJlY2lzZSByZWdhcmRpbmcg d2hpY2ggcGllY2Ugb2YgJnF1b3Q7ZGlhbG9nDQpzdGF0ZSZxdW90Ozxicj4NCnRoZSBydWxlcyBp biB0aGUgZHJhZnQgYXBwbHkgdG8uPGJyPg0KPGJyPg0KTXkgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0 byBoYXZlIHRoZSBkcmFmdCB0YWxrIG9ubHkgYWJvdXQgc2Vzc2lvbiBzdGF0ZTxicj4NCmFuZCB0 aGUgZGlhbG9nJ3MgcmVtb3RlIHRhcmdldCwgYW5kIGZvcmdldCBhYm91dCBhbnkgb3RoZXIgZGlh bG9nIHN0YXRlLjxicj4NCk5ldyBleHRlbnNpb25zIHdob3NlIHBhcmFtZXRlcnMgY2FuIGJlIG1v ZGlmaWVkIGJ5IHJlLUlOVklURXMgY2FuPGJyPg0Kc3BlY2lmeSB0aGVpciBvd24gcnVsZXMsIHBv c3NpYmx5IHJlZmVycmluZyB0byB0aGlzIGRyYWZ0IGFuZCB1c2luZyB0aGU8YnI+DQpydWxlcyBk ZWZpbmVkIGluIGl0IGJ5IHJlZmVyZW5jZS4gSW4gdGhpcyB3YXksIHRoZSBhcHBsaWNhYmlsaXR5 IG9mIHRoaXM8YnI+DQpkcmFmdCB3b3VsZCBiZSBtdWNoIGNsZWFyZXIuPGJyPg0KPGJyPg0KQ29t bWVudHM/PGJyPg0KPGJyPg0KVGhhbmtzLDxicj4NCjxicj4NCkdvbnphbG88YnI+DQo8YnI+DQpf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNpcGNv cmUgbWFpbGluZyBsaXN0PGJyPg0Kc2lwY29yZUBpZXRmLm9yZzxicj4NCmh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZTxicj4NCjxicj4NCjwvZm9udD48L3R0Pg0K 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 0032C73848257757_=-- From wwwrun@core3.amsl.com Tue Jul 6 12:35:55 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 30) id 47B8E3A69DE; Tue, 6 Jul 2010 12:35:55 -0700 (PDT) X-idtracker: yes From: The IESG To: IETF-Announce Message-Id: <20100706193555.47B8E3A69DE@core3.amsl.com> Date: Tue, 6 Jul 2010 12:35:55 -0700 (PDT) Cc: sipcore chair , Internet Architecture Board , sipcore mailing list , RFC Editor Subject: [sipcore] Protocol Action: 'Correct transaction handling for 2xx responses to Session Initiation Protocol (SIP) INVITE requests' to Proposed Standard X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 06 Jul 2010 19:35:55 -0000 The IESG has approved the following document: - 'Correct transaction handling for 2xx responses to Session Initiation Protocol (SIP) INVITE requests ' as a Proposed Standard This document is the product of the Session Initiation Protocol Core Working Group. The IESG contact persons are Gonzalo Camarillo and Robert Sparks. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-invfix-01.txt Technical Summary This document normatively updates RFC 3261, the Session Initiation Protocol (SIP), to address an error in the specified handling of certain types of transactions. It also modifies response processing under certain circumstances to address an identified security risk. Working Group Summary The mechanism in this document has good support from those working group members who participated in its discussion. Document Quality The document received significant review and comment in 2007 and 2008, when it was part of the SIP working group. By May of 2009, almost a quarter of the SIP implementations at the SIPit 24 interoperability testing event had incorporated the changes documented by this draft. The issue fixed by this document was first reported by Pekka Pessi. Early in the development of the correction documented in this work, Brett Tate identified an important and necessary modification to the proposed correction, which had significant impact on the resulting state maching. Personnel The document shepherd is Adam Roach. The responsible AD is Gonzalo Camarillo. RFC Editor Note: Section 3 paragraph 2: OLD: This requirement applies to both proxies and user agents (proxies forward the response upstream, the transaction layer at user agents forward the response to its "UA (User-Agent) core"). NEW: This requirement applies to both UAs (User Agents) and proxies (proxies forward the response upstream, the transaction layer at user agents forward the response to its "UA core"). In the IANA Considerations section add: IANA is requested to update the SIP Parameters: Method and Response Codes registry as follows: OLD: Methods Reference ------- --------- INVITE [RFC3261] NEW: Methods Reference ------- --------- INVITE [RFC3261][RFC-ietf-sipcore-invfix-01] In the Security Considerations section: OLD: However, this additional state is necessary to achieve correct operation. NEW: However, this additional state is necessary to achieve correct operation. There is some discussion of avoiding state exhaustion and other Denial-of-Service attacks in RFC 3261 section 26.3.2.4. Last paragraph of section 10 first sentence: s/possible/possibly/ Please replace "invfix" in header on pages 2 and forward with "Correct Handling for SIP 2xx responses" From adam@nostrum.com Fri Jul 9 13:51:15 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6A7F83A68CD for ; Fri, 9 Jul 2010 13:51:14 -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 qnhZVFqs0eKw for ; Fri, 9 Jul 2010 13:51:07 -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 E92333A67EE for ; Fri, 9 Jul 2010 13:51:06 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o69Kp22C036152 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 9 Jul 2010 15:51:03 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C378BB7.9090106@nostrum.com> Date: Fri, 09 Jul 2010 15:51:03 -0500 From: Adam Roach - SIPCORE Chair User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: SIPCORE Chairs References: <4C2CEAF1.5060902@nostrum.com> In-Reply-To: <4C2CEAF1.5060902@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: Jon Peterson , draft-ietf-sipcore-sec-flows@tools.ietf.org, "SIPCORE \(Session Initiation Protocol Core\) WG" , draft-ietf-sipcore-location-conveyance@tools.ietf.org, draft-barnes-sipcore-rfc4244bis@tools.ietf.org, draft-roach-sipcore-rfc3265bis@tools.ietf.org, draft-ietf-sipcore-keep@tools.ietf.org Subject: [sipcore] Canceling SIPCORE @ Maastricht? (was Re: SIPCORE Agenda Requests, call for NOMCOM volunteers) X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: SIPCORE Chairs List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Jul 2010 20:51:15 -0000 [as chair] Scheduling of working groups in Maastricht has been unusually problematic this time around, with several working groups receiving significantly less time than requested. As of today (July 9th) at 20:45 UTC, the SIPCORE chairs have received exactly zero requests for agenda time at the upcoming SIPCORE meeting. If no requests have been received *BEFORE* July 13th, we will be canceling our request for a room in Maastricht, to allow other working groups to use the room that has been allocated to us. /a On 7/1/10 2:22 PM, Adam Roach - SIPCORE Chair wrote: > [as chair] > > If you wish to request time to discuss a draft at the upcoming > face-to-face meeting in Maastricht, please send an email to to the > SIPCORE chairs . The deadline for > requesting SIPCORE meeting time is Monday, July 12th. > > Note that the chairs may decline requests for time if there is no > evidence of mailing list traffic on the associated draft. > > Also, please note that the cutoff date for new (-00) documents is this > upcoming Monday, and the cutoff date for all other documents is > Monday, July 12th. > > Finally, please consider volunteering for NOMCOM. You are eligible if > you have attended 3 of the past 5 IETF meetings. The deadline for > volunteering is 17:00 PDT (24:00 UTC) July 8, 2010. If you are willing > to help select the IETF leadership team for the next two years, please > send an email to , with your full name, primary > affiliation, email address(es) used to register for any of the past 5 > meetings, and a telephone number. > > Thanks! > > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From gao.yang2@zte.com.cn Mon Jul 12 02:35:01 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 98D513A6914 for ; Mon, 12 Jul 2010 02:35:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.206 X-Spam-Level: X-Spam-Status: No, score=-98.206 tagged_above=-999 required=5 tests=[AWL=0.573, BAYES_20=-0.74, HTML_MESSAGE=0.001, J_CHICKENPOX_54=0.6, J_CHICKENPOX_63=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 3XVU2+ZgFs86 for ; Mon, 12 Jul 2010 02:35:00 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 070E53A68CB for ; Mon, 12 Jul 2010 02:34:58 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 383431727820181; Mon, 12 Jul 2010 17:34:08 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 95274.2980680612; Mon, 12 Jul 2010 17:27:30 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o6C98IuB003958; Mon, 12 Jul 2010 17:08:18 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) To: sipcore@ietf.org MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 12 Jul 2010 17:04:12 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-12 17:08:08, Serialize complete at 2010-07-12 17:08:08 Content-Type: multipart/alternative; boundary="=_alternative 00321A984825775E_=" X-MAIL: mse2.zte.com.cn o6C98IuB003958 Subject: Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite //Request for other people's following up. X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 12 Jul 2010 09:35:01 -0000 This is a multipart message in MIME format. --=_alternative 00321A984825775E_= Content-Type: text/plain; charset="US-ASCII" Maybe my last week's comments was a little too expanding. So, I request other people to focus on Gonzalo's original suggestion and following up with comments. I think we can make things which has been clear to go on in the standard process. Thanks, Gao From: gao.yang2 at zte.com.cn To: Gonzalo Camarillo Cc: SIPCORE Date: Mon, 5 Jul 2010 17:11:57 +0800 In-reply-to: <4C317D02.2030307 at ericsson.com> Hi Gonzalo, Fisrt, I am glad to hear about this suggestion. And I once proposed the similar idea, as putting things which has been cleared forward, and make the basic rules(such as *in use* way for O/A usage, and notify way for remote target) as reference for other *dialog state* usages, in separate drafts. Second, I once do one proposal for the other *dialog state* usages in one previous mail: http://www.ietf.org/mail-archive/web/sipcore/current/msg02850.html I think we might need several months's discussion for such topics. Third, I suggest one expert(Gonzalo, Paul, or Robert?) to draft out one draft, to collect requirments for the remaining topics(the other *dialog state* usages's) which still need normative definition/clarification. This memo would have the following meanings: 1. To figure out current status of all SIP Core standard; 2. As memo of conclusions for points. 3. If someday, we need 3261bis, this might be a not bad start. Thanks, Gao =================================== 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 00321A984825775E_= Content-Type: text/html; charset="US-ASCII"
Maybe my last week's comments was a little too expanding. So, I request other people to focus on Gonzalo's original suggestion and following up with comments. I think we can make things which has been clear to go on in the standard process.

Thanks,

Gao


Hi Gonzalo,

Fisrt, I am glad to hear about this suggestion. And I once proposed the similar idea, as putting things which has been cleared forward, and make the basic rules(such as *in use* way for O/A usage, and notify way for remote target) as reference for other *dialog state* usages, in separate drafts.

Second, I once do one proposal for the other *dialog state* usages in one previous mail:
http://www.ietf.org/mail-archive/web/sipcore/current/msg02850.html
I think we might need several months's discussion for such topics.

Third, I suggest one expert(Gonzalo, Paul, or Robert?) to draft out one draft, to collect requirments for the remaining topics(the other *dialog state* usages's) which still need normative definition/clarification. This memo would have the following meanings:
1. To figure out current status of all SIP Core standard;
2. As memo of conclusions for points.
3. If someday, we need 3261bis, this might be a not bad start.

Thanks,

Gao


===================================
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 00321A984825775E_=-- From root@core3.amsl.com Mon Jul 12 15:15:02 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 78E733A6B4B; Mon, 12 Jul 2010 15:15:02 -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: <20100712221502.78E733A6B4B@core3.amsl.com> Date: Mon, 12 Jul 2010 15:15:02 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-location-conveyance-03.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, 12 Jul 2010 22:15:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Location Conveyance for the Session Initiation Protocol Author(s) : J. Polk, et al. Filename : draft-ietf-sipcore-location-conveyance-03.txt Pages : 25 Date : 2010-07-12 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 intermediaries make routing decisions based upon 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-03.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-03.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-12150210.I-D@ietf.org> --NextPart-- From jmpolk@cisco.com Mon Jul 12 16:54:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B4B693A67AC for ; Mon, 12 Jul 2010 16:54:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.999 X-Spam-Level: X-Spam-Status: No, score=-8.999 tagged_above=-999 required=5 tests=[AWL=1.600, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jfW3cJKzaMMf for ; Mon, 12 Jul 2010 16:54: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 DDA463A6805 for ; Mon, 12 Jul 2010 16:54:58 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ArsFAAFIO0yrRN+J/2dsb2JhbACTd4xCcaQwmwqCXoJJBIN7 X-IronPort-AV: E=Sophos;i="4.55,191,1278288000"; d="scan'208";a="157487239" Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-4.cisco.com with ESMTP; 12 Jul 2010 23:55:07 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6CNt6us024310 for ; Mon, 12 Jul 2010 23:55:07 GMT Message-Id: <201007122355.o6CNt6us024310@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 12 Jul 2010 18:55:06 -0500 To: sipcore@ietf.org From: "James M. Polk" Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: [sipcore] location-conveyance-03 just 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: Mon, 12 Jul 2010 23:54:59 -0000 SIPCORE http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location-conveyance-03.txt This version is a fairly radical departure from previous versions of the (long standing) effort. This time the doc didn't grow... We added Jon Peterson as a co-author, and he helped in Anaheim propose a significantly less complex way of specifying location conveyance for SIP. More than 95% of the doc has been rewritten by Jon and I, with a net result of 27 less pages of text (52 to 25 now). We took out the terms and concepts of following parameters: - inserter - inserted-by - used-for-routing - host-id - node-id as well as limiting the number of locationValues to *ONE*, in a SIP request. We removed the ability for SIP intermediaries to add location along the way unbeknownst to the UAC (with one infrequently used exception). In this way, location errors are only end-to-end, so there is no need to identify which entity added location to make sure the right entity reacted the right way when an error was caused by the location they inserted, and not that of another entity's inserted location (which is all very confusing). We added the ability for a SIP intermediary to augment a location with what the UAC should send in a subsequent request, and the ability to verify this augmentation is present before successfully processing that request. This is in line with both RFCs 4479 and 5491. Comments are appreciated James From root@core3.amsl.com Mon Jul 12 17:00:04 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 2890C3A697A; Mon, 12 Jul 2010 17:00:04 -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: <20100713000004.2890C3A697A@core3.amsl.com> Date: Mon, 12 Jul 2010 17:00:04 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-event-rate-control-04.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 00:00:04 -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) Event Notification Extension for Notification Rate Control Author(s) : A. Niemi, et al. Filename : draft-ietf-sipcore-event-rate-control-04.txt Pages : 24 Date : 2010-07-12 This document specifies mechanisms for adjusting the rate of Session Initiation Protocol (SIP) event notifications. These mechanisms can be applied in subscriptions to all SIP event packages. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-event-rate-control-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-event-rate-control-04.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-12165555.I-D@ietf.org> --NextPart-- From krisztian.kiss@nokia.com Mon Jul 12 17:13:58 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DBC503A6953 for ; Mon, 12 Jul 2010 17:13: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 ECfUqdrsHUsE for ; Mon, 12 Jul 2010 17:13:57 -0700 (PDT) Received: from mgw-mx09.nokia.com (smtp.nokia.com [192.100.105.134]) by core3.amsl.com (Postfix) with ESMTP id 6A9D23A68B0 for ; Mon, 12 Jul 2010 17:13:57 -0700 (PDT) Received: from esebh105.NOE.Nokia.com (esebh105.ntc.nokia.com [172.21.138.211]) by mgw-mx09.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o6D0DYpD019768; Mon, 12 Jul 2010 19:14:04 -0500 Received: from vaebh102.NOE.Nokia.com ([10.160.244.23]) by esebh105.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 03:13:59 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.5]) by vaebh102.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 03:13:55 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-01.mgdnok.nokia.com ([65.54.30.5]) with mapi; Tue, 13 Jul 2010 02:13:55 +0200 From: To: Date: Tue, 13 Jul 2010 02:13:41 +0200 Thread-Topic: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-03 Thread-Index: AcsI2ZDV1t/KeLdKSTWmuE3R6MtFGgF1JhiA Message-ID: References: <99619466-573D-4CEA-ACCD-3A3D262EB2B0@nostrum.com> In-Reply-To: <99619466-573D-4CEA-ACCD-3A3D262EB2B0@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 13 Jul 2010 00:13:55.0134 (UTC) FILETIME=[47EF15E0:01CB2220] X-Nokia-AV: Clean Cc: sipcore@ietf.org Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-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, 13 Jul 2010 00:13:59 -0000 Hi Robert, I submitted the -04 version today addressing your comments: http://www.ietf= .org/id/draft-ietf-sipcore-event-rate-control-04.txt=20 Please find my answers in-line with [KK]: -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of ext Robert Sparks Sent: 2010. j=FAnius 10. 13:14 To: SIPCORE Subject: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-03 Summary: This draft has a few adjustments that are needed before moving it = into IETF Last Call. Major question: Why isn't this an Update to 3265?=20 [KK] It's an extension to 3265. Implementations of 3265 not interested in r= ate control don't need to implement it. If people think it's an essential p= art of event-notifications, we could make it as an update of 3265. Any reco= mmendations? Is there text here that prevents a subscriber from generating Event headers in 200 OKs to NOTIFYs mid-subscription (when = he didn't probe for support using the SUBSCRIBE?) How would they know the requ= est got honored? The possibility of running into implementations that break sh= ould be called out. =20 [KK] I added text in -04 to address this:=20 Section 4.1: "If the Event header field of the SUBSCRIBE request did not in= clude the "min-interval" parameter, the subscriber MUST NOT include an init= ial value of the "min-interval" Event header field parameter in a 200-class= response to the NOTIFY request."=20 Section 4.2: "If the Event header field of the SUBSCRIBE request did not in= clude the "min-interval" parameter, the notifier MUST ignore an initial val= ue of the "min-interval" Event header field parameter in a 200-class respon= se to the NOTIFY request, if present." ...and similar text covering max-interval and average-interval mechanisms. 4.2 indicates the subscriber only gets a "hint" about support for rate-control in the notifier - is the condition it describes really onl= y a hint? [KK] Replaced "serves as a hint" with "indicates". In several places, the notifier is given permission to adjust an interval b= ased on local policy. The document should be explicit about allowing the adjust= ment in any direction (increasing or decreasing) since there are so many other u= ses of intervals in SIP and SIP Events that allow adjustment only in one direct= ion. A few places I noted when reading the document were the Note in REQ7, 4.3 4= th paragraph, 5.2 paragraph 3, 6.2 paragraph 3. [KK] I spelled out the possibility of increasing and decreasing at all of t= hese sections you referenced. The last paragraph of section 3.6 claims "exactly the same properties" exce= pt for being generated constrained to a schedule. Can you clarify which proper= ties you mean? Many properties of the notifications beside their timing are clea= rly different (for instance, you may miss state transitions). [KK] I just deleted that sentence, there was no real added value in it. The security considerations section deserves more text:=20 * What is the forward reference from section 3.4 supposed to be pointing to= ? [KK] Deleted. * Call out the implications on a Notifier having to store/aggregate partial= state [KK] I added a reference to the security considerations listed in RFC 5263 = (partial notifications). * Note that the Event header (particularly in 200 OKs) is not integrity pro= tected.=20 This would allow anything that could modify the message in flight (or an= =20 eavesdropper that could race a 200 OK in) to suppress (or flood) notifica= tions=20 without the subscriber seeing what caused it. [KK] I added a new paragraph on this: "RFC 3265 [RFC3265] recommends the integrity protection of the Event header= field of SUBSCRIBE requests. Implementations of this extension SHOULD also= provide integrity protection for the Event header field included in the 20= 0-class response to the NOTIFY request." =09 The assertion that applying rate limiting and compression together results = in savings as good as the sum of applying them independently should be support= ed or adjusted. I think it's sufficient to say they can be applied together. [KK] OK, so no changes needed, right? Below are several suggestions for text tweaks. The first few (staring with = *) are the most important.=20 * Section 3.2 paragraph 4: suggest replacing "does not typically" with "may= not" [KK] Fixed. * Section 3.2 last paragraph: The sentence 'The "max-interval" parameter=20 indicates ... complete state information' is difficult to parse. Coul= d it be simplified? [KK] Done. * Section 4.3 first paragraph, last sentence: "For such cases" is ambiguous= . Suggest "If the min-interval value is greater than the subscription expir= y". [KK]. Done. Re-wrote as: "If the subscription expiry is shortened during an= active subscription,..." * Section 6.2 last paragraph: This currently says the timeout mechanism doe= s not affect when 3261 transaction retransmissions are generated. It should also explicitly note that retransmissions do not affect the calculation o= f the next timeout. [KK]. Fixed by extending the definition of "count": =20 "count: The number of notifications that have been sent during the last "pe= riod" of seconds ***not including any retransmissions of requests***." New = text is between *** marks. Introduction, paragraph 2: suggest replacing "congestion" with "load" [KK] Fixed. Section 3.1 paragraph 3: suggest replacing "amount of traffic" with=20 "number of notifications" [KK] Fixed. Section 3.5 paragraph 1: Suggest a reference for RLS after "list subscripti= on". [KK] Fixed. The sentence "Moreover, the list event notifier..." should be more explicit about using the rate mechanism for any back-end subscriptions it might have= . [KK] Fixed. Suggest referencing 3261 in the last paragraph of 4.2 [KK] Fixed. Same applies to section 6.2. Section 4.3, 3rd paragraph last sentence. The only way the subscriber _can_ resume notifications is to renew the subscription with a resubscribe reques= t. Would this text work? "This results in receiving no further notifications u= ntil the subscription expires or the subscriber sends a SUBSCRIBE request refres= hing the subscription (perhaps resuming notifications)". [KK] Fixed as "or the subscriber sends a SUBSCRIBE request resuming notific= ations." The text needs to be adjusted to reflect subnot-etags being issued as an RF= C [KK] Fixed throughout the document. Adam suggested some RFC-Editor notes in the proto writeup (which may addres= s some of the above comments). Please be sure to incorporate those when revis= ing the draft. [KK] Done. Fixed the text for subnot-etags references throughout the docume= nt. One last question: If the combination of min-interval, max-interval, and average-interval make little sense, why does the document allow them to be combined? I think what= the group was trying to say is that we currently don't forsee a use for combini= ng those options, but do not wish to forbid their combination. [KK] Fixed as "this combination makes little sense to be used although not = forbidden". Recommendations added on choosing the right values similarly to= previous options for combinations. Thanks, Krisztian _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From krisztian.kiss@nokia.com Mon Jul 12 18:12:33 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 23AD63A68B5 for ; Mon, 12 Jul 2010 18:12:33 -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 HQucjnAO1yDX for ; Mon, 12 Jul 2010 18:12:30 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 902343A6995 for ; Mon, 12 Jul 2010 18:12:29 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o6D1COEv026106; Tue, 13 Jul 2010 04:12:31 +0300 Received: from vaebh104.NOE.Nokia.com ([10.160.244.30]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 04:12:21 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by vaebh104.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 04:12:16 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.7]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Tue, 13 Jul 2010 04:12:11 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-03.mgdnok.nokia.com ([65.54.30.7]) with mapi; Tue, 13 Jul 2010 03:12:11 +0200 From: To: Date: Tue, 13 Jul 2010 03:12:14 +0200 Thread-Topic: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-03 Thread-Index: AcsZaXeq+zMfHIyhROG6L1NpBKFFmgGV2suA Message-ID: References: <99619466-573D-4CEA-ACCD-3A3D262EB2B0@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginalArrivalTime: 13 Jul 2010 01:12:11.0440 (UTC) FILETIME=[6BE50B00:01CB2228] X-Nokia-AV: Clean Cc: sipcore@ietf.org Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-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, 13 Jul 2010 01:12:33 -0000 SGkgSmFuZXQsDQoNClRoYW5rcyBmb3IgeW91ciBjb21tZW50cywgcGxlYXNlIGZpbmQgbXkgYW5z d2VycyBpbi1saW5lIG1hcmtlZCB3aXRoIFtLS106DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLQ0KRnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86c2lwY29y ZS1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYgT2YgSmFuZXQgUCBHdW5uDQpTZW50OiAyMDEw LiBqw7puaXVzIDExLiAwODo0Mw0KVG86IFJvYmVydCBTcGFya3MNCkNjOiBTSVBDT1JFOyBzaXBj b3JlLWJvdW5jZXNAaWV0Zi5vcmcNClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gQUQgcmV2aWV3OiBk cmFmdC1pZXRmLXNpcGNvcmUtZXZlbnQtcmF0ZS1jb250cm9sLTAzDQoNCg0KSSBoYXZlIHNvbWUg ZnVydGhlciBjb21tZW50cywgbW9zdGx5IGFib3V0IHRoZSAiYXZlcmFnZSIgbWVjaGFuaXNtLiAN Cg0KV2hpbGUg4oCcbWF4LWludGVydmFs4oCdIGlzIHN5bm9ueW1vdXMgd2l0aCDigJxtaW5pbXVt IHJhdGXigJ0sIGFuZCDigJxtaW4taW50ZXJ2YWzigJ0gaXMgc3lub255bW91cyB3aXRoIOKAnG1h eGltdW0gcmF0ZeKAnSwgdGhlIGNvbnN0YW50IHN3aXRjaGluZyBiYWNrIGFuZCBmb3J0aCBiZXR3 ZWVuIHRoZSB0d28gc2V0cyBvZiB0ZXJtaW5vbG9neSBtYWtlcyBpdCB2ZXJ5IGRpZmZpY3VsdCB0 byBmb2xsb3cuIA0KDQpQaWNrIG9uZSBzZXQsIGFuZCB1c2UgdGhhdCBhcyB0aGUgZG9taW5hbnQg dGVybS4gwqBBdCBhIG1pbmltdW0sIHRoZSBzZWN0aW9uIGhlYWRpbmcgc2hvdWxkIGJlIGNvbnNp c3RlbnQuIA0KDQpbS0tdIFRoZSBkb21pbmFudCB0ZXJtcyBhcmUg4oCcbWluaW11bSByYXRl4oCd IGFuZCDigJxtYXhpbXVtIHJhdGXigJ0uIEkgYmVsaWV2ZSB0aGF04oCZcyBjb25zaXN0ZW50IHRo cm91Z2hvdXQgdGhlIGRvY3VtZW50IGluY2x1ZGluZyBzZWN0aW9uIGhlYWRpbmdzLiBJbiB0aGUg dGV4dCB3ZSBhbHdheXMgcmVmZXIgdG8gdGhlIG1lY2hhbmlzbXMgYXMg4oCcbWF4aW11bSByYXRl IG1lY2hhbmlzbeKAnSBhbmQg4oCcbWluaW11bSByYXRlIG1lY2hhbmlzbeKAnSB3aGlsZSB3ZSB1 c2Ug4oCcbWluLWludGVydmFs4oCdIGFuZCDigJxtYXgtaW50ZXJ2YWzigJ0gd2hlbiBkZWZpbmlu ZyB0aGUgYWN0dWFsIEV2ZW50IGhlYWRlciBmaWVsZCBwYXJhbWV0ZXJzLg0KSSB3aXNoIEkgY291 bGQgb25seSB1c2UgdGhlIHRlcm1zIOKAnG1heGltdW0gcmF0ZSBtZWNoYW5pc23igJ0gYW5kIOKA nG1pbmltdW0gcmF0ZSBtZWNoYW5pc23igJ0gaW4gdGhlIHdob2xlIGRvY3VtZW50IGluY2x1ZGlu ZyB0aGUgcGFyYW1ldGVyIG5hbWVzIGJ1dCBJIGFtIGFmcmFpZCBvZiBtYWtpbmcgc3VjaCBhIG5v bi1iYWNrd2FyZCBjb21wYXRpYmxlIGNoYW5nZSBhdCB0aGlzIHZlcnkgbGF0ZSBwaGFzZS4gDQpU aGUgb3RoZXIgb3B0aW9uIGNvdWxkIGJlIHRvIHVzZSBvbmx5IHRoZSB0ZXJtcyDigJxtaW4taW50 ZXJ2YWzigJ0gYW5kIOKAnG1heC1pbnRlcnZhbOKAnSBpbiB0aGUgZG9jdW1lbnQgYnV0IOKAnG1p bi1pbnRlcnZhbCBtZWNoYW5pc23igJ0gc291bmRzIG11Y2ggbW9yZSBjb25mdXNpbmcgdG8gbWUg dGhhbiDigJxtYXhpbXVtIHJhdGUgbWVjaGFuaXNt4oCdLCB0aGF04oCZcyB3aHkgd2UgaGF2ZSB0 aGlzIOKAnG1pc21hdGNo4oCdLiBJIGhvcGUgdGhpcyBkb2VzIG5vdCBjYXVzZSBhIG1ham9yIGNv bmZ1c2lvbiAobWlub3Igb25lIGlzIGFjY2VwdGFibGUgOikgYW5kIHRoZSBkb2N1bWVudCByZW1h aW5zIHJlYWRhYmxlLg0KwqANClRoZSBkZXNjcmlwdGlvbiBvZiB0aGUgaW50ZW5kZWQgZWZmZWN0 IG9mIHRoZSDigJxhdmVyYWdlLWludGVydmFs4oCdIGlzIHVuY2xlYXIgYW5kIGluY29uc2lzdGVu dC4gDQoNCkluIHRoZSBpbnRyb2R1Y3Rpb24sIGl0IHNheXMgDQrigJwgwqAgYXZlcmFnZS1pbnRl cnZhbDogwqBzcGVjaWZpZXMgYW4gYXZlcmFnZSBjYWRlbmNlIGF0IHdoaWNoIG5vdGlmaWNhdGlv bnMgYXJlIGRlc2lyZWQsIGluIHNlY29uZHMu4oCdIA0KDQpUaGlzIGltcGxpZXMgdGhhdCBpdCB3 aWxsIHNwZWVkIHVwIHRoZSByYXRlIG9mIG5vdGlmaWNhdGlvbnMgd2hlbiB0aGV5IHdvdWxkIG90 aGVyd2lzZSBiZSB0b28gc2xvdywgYW5kIHNsb3cgdGhlbSBkb3duIHdoZW4gdGhleSB3b3VsZCBv dGhlcndpc2UgYmUgdG9vIHF1aWNrLiANCg0KW0tLXSBUaGUgYXZlcmFnZSByYXRlIG1lY2hhbmlz bSBpcyBhICJzcGVjaWFsIiB0eXBlIG9mIHRoZSBtaW5pbXVtIHJhdGUgbWVjaGFuaXNtLCB3aGlj aCBzaW1wbHkgdGFrZXMgaW50byBhY2NvdW50IGhvdyBtYW55IG5vdGlmaWNhdGlvbnMgaGF2ZSBi ZWVuIHNlbnQgcmVjZW50bHkuIE9idmlvdXNseSBib3RoIHRoZSBtaW5pbXVtIHJhdGUgbWVjaGFu aXNtIGFuZCB0aGUgYXZlcmFnZSByYXRlIG1lY2hhbmlzbSByZXN1bHQgaW4gbW9yZSBub3RpZmlj YXRpb25zIHRoYW4gIm5vcm1hbCIgbm90aWZpY2F0aW9ucyB3aXRob3V0IHRoZXNlIHJhdGUgY29u dHJvbCBtZWNoYW5pc21zIGJlY2F1c2UgdGhlIGdlbmVyYXRpb24gb2Ygbm90aWZpY2F0aW9ucyBp cyBub3Qgb25seSB0cmlnZ2VyZWQgYnkgZXZlbnQgc3RhdGUgY2hhbmdlcyBidXQgYWxzbyB0aW1l cnMgKG1heC1pbnRlcnZhbCBpbiBtaW5pbXVtIHJhdGUgbWVjaGFuaXNtLCBhbmQgdGltZW91dCBp biBhdmVyYWdlIHJhdGUgbWVjaGFuaXNtKS4NCg0KTGF0ZXIgaW4gdGhlIGludHJvIGl0IHNheXMg DQrigJxBbGwgdGhvc2UgbWVjaGFuaXNtcyBhcmUgc2ltcGx5IHRpbWVyIHZhbHVlcyB0aGF0IGlu ZGljYXRlcyAoc2ljKSB0aGUgbWluaW11bSwgbWF4aW11bSBhbmQgYXZlcmFnZSB0aW1lIHBlcmlv ZCBhbGxvd2VkIGJldHdlZW4gdHdvIG5vdGlmaWNhdGlvbnMuIEFzIGEgcmVzdWx0IG9mIHRob3Nl IG1lY2hhbmlzbSwgYSBjb21wbGlhbnQgbm90aWZpZXIgd2lsbCBhZGp1c3QgdGhlIHJhdGUgYXQg d2hpY2ggaXQgZ2VuZXJhdGVzIG5vdGlmaWNhdGlvbnMu4oCdIA0KDQpUaGlzIGFsc28gaW1wbGll cyB0aGF0IHRoZSDigJxhdmVyYWdlLWludGVydmFs4oCdIG1lY2hhbmlzbSB3aWxsIGJvdGggc3Bl ZWQgdXAgYW5kIHNsb3cgZG93biB0aGUgcmF0ZSwgYXMgYXBwcm9wcmlhdGUuIA0KDQpJbiBzZWN0 aW9uIDMuMywgVXNlIENhc2UgZm9yIHNwZWNpZnlpbmcgdGhlIGF2ZXJhZ2UgcmF0ZSBvZiBub3Rp ZmljYXRpb25zLCBpdCBpcyBjb250cmFkaWN0b3J5LiDCoEZpcnN0IGl0IHNheXMgDQrigJxkeW5h bWljYWxseSBpbmNyZWFzZXMgdGhlIGludGVydmFsIGJldHdlZW4gbm90aWZpY2F0aW9ucyBpZiB0 aGUgdGFyZ2V0IGhhcyBzZW50IG91dCBzZXZlcmFsIG5vdGlmaWNhdGlvbnMgcmVjZW50bHku4oCd IMKgVGhpcyBpcyBhbiBJTkNSRUFTRSBpbiB0aGUgaW50ZXJ2YWwgDQoNCltLS10gVGhpcyBpcyBq dXN0IGFuIGV4YW1wbGUgdXNlIGNhc2UgZXhwbGFpbmluZyBob3cgdG8g4oCcZGVjcmVhc2UgdGhl IHByb2Nlc3NpbmcgYW5kIG5ldHdvcmsgbG9hZOKAnSB3aGljaCBpcyBzdGF0ZWQgaW4gdGhlIGZp cnN0IHBhcnQgb2YgdGhlIHNlbnRlbmNlLg0KDQpCdXQgdGhlbiBpdCBzYXlzIA0K4oCcVGhlICJh dmVyYWdlLWludGVydmFsIiBwYXJhbWV0ZXIgdmFsdWUgaXMgdXNlZCBieSB0aGUgbm90aWZpZXIg dG8gZHluYW1pY2FsbHkgY2FsY3VsYXRlIHRoZSBtYXhpbXVtIHRpbWUgYWxsb3dlZCBiZXR3ZWVu IHR3byBzdWJzY3JpcHRpb25zIChzaWMpLuKAnSANCkZpcnN0LCBJIGFzc3VtZSB5b3UgbWVhbiDi gJxiZXR3ZWVuIHR3byBub3RpZmljYXRpb25z4oCdLiBOb3Qg4oCcYmV0d2VlbiB0d28gc3Vic2Ny aXB0aW9uc+KAnS4gwqANCg0KW0tLXS4gUmlnaHQsIGZpeGVkIGluIC0wNCB2ZXJzaW9uLg0KDQpC dXQgbW9yZSBpbXBvcnRhbnRseSwgZHluYW1pY2FsbHkgY2FsY3VsYXRpbmcg4oCcdGhlIG1heGlt dW0gdGltZSBhbGxvd2VkIGJldHdlZW4gbm90aWZpY2F0aW9uc+KAnSBtZWFucyB0aGF0IHlvdSB3 aWxsIERFQ1JFQVNFIHRoZSBpbnRlcnZhbCBiZXR3ZWVuIG5vdGlmaWNhdGlvbnMsIGlmIHRoZSB0 YXJnZXQgaGFzIG5vdCBzZW50IG91dCBhbnkgbm90aWZpY2F0aW9ucyByZWNlbnRseS4gDQoNCltL S10g4oCcRHluYW1pY2FsbHkgY2FsY3VsYXRpbmcgdGhlIG1heGltdW0gdGltZSBhbGxvd2VkIGJl dHdlZW4gbm90aWZpY2F0aW9uc+KAnSBtZWFucyBkZWNyZWFzaW5nIG9yIGluY3JlYXNpbmcgdGhl IGludGVydmFsIGJldHdlZW4gdHdvIG5vdGlmaWNhdGlvbnMgKHdoaWNoZXZlciBpcyBuZWNlc3Nh cnkpIGNvbXBhcmVkIHRvIHRoZSBpbnRlcnZhbCBlbGFwc2VkIGJldHdlZW4gdGhlIHR3byBub3Rp ZmljYXRpb25zIHNlbnQgcHJldmlvdXNseS4NCg0KQW5kIGZ1cnRoZXIgDQrigJxUaGlzIHR5cGUg b2YgcmF0ZSBjb250cm9sIGFsbG93cyB0aGUgbm90aWZpZXIgdG8gZHluYW1pY2FsbHkgaW5jcmVh c2Ugb3IgZGVjcmVhc2UgdGhlIE5vdGlmaWNhdGlvbiBmcmVxdWVuY3ku4oCdIA0KDQpXaGVuIHdl IGdldCB0byBzZWN0aW9uIDYgKE9wZXJhdGlvbiBvZiB0aGUgYXZlcmFnZSByYXRlIG1lY2hhbmlz bSksIGl0IHN0YXJ0cyBvZmYgYnkgc2F5aW5nIA0K4oCcVGhlIG1haW4gY29uc2VxdWVuY2UgZm9y IHRoZSBzdWJzY3JpYmVyIHdoZW4gYXBwbHlpbmcgdGhlIGF2ZXJhZ2UgcmF0ZSBtZWNoYW5pc20g aXMgdGhhdCBpdCBjYW4gcmVjZWl2ZSBhIG5vdGlmaWNhdGlvbiBldmVuIGlmIG5vdGhpbmcgaGFz IGNoYW5nZWQgaW4gdGhlIGN1cnJlbnQgc3RhdGUgb2YgdGhlIG5vdGlmaWVyLuKAnSANClRoaXMg aW52b2x2ZXMgwqBhIERFQ1JFQVNFIGluIHRoZSBpbnRlcnZhbC4gDQoNCltLS10gWW91IG1lYW4g ImRlY3JlYXNlIGNvbXBhcmVkIHRvIG5vdGlmaWNhdGlvbnMgd2l0aG91dCB0aGlzIHJhdGUgY29u dHJvbCBtZWNoYW5pc20iLCByaWdodD8gSSB0aGluayB3ZSBoYXZlIGEgZGlmZmVyZW50IHVuZGVy c3RhbmRpbmcgb2YgdGhpcyAiaW5jcmVhc2UgYW5kIGRlY3JlYXNlIGluIHRoZSBpbnRlcnZhbCIg cHJvYmxlbSwgbGV0IG1lIHRyeSB0byBleHBsYWluLiBXaGVuIHdlIGRlc2NyaWJlIHRoYXQgdGhl IG5vdGlmaWVyIGNhbiBkeW5hbWljYWxseSBpbmNyZWFzZSBvciBkZWNyZWFzZSB0aGUgbm90aWZp Y2F0aW9uIGZyZXF1ZW5jeSwgd2UgZG9uJ3QgY29tcGFyZSB0aGUgYXZlcmFnZSByYXRlIGNvbnRy b2xsZWQgbm90aWZpY2F0aW9ucyB3aXRoICJub3JtYWwiIG5vdGlmaWNhdGlvbnMgd2l0aG91dCBy YXRlIGNvbnRyb2wsIGluc3RlYWQsIHdlIGNvbXBhcmUgdGhlIGF2ZXJhZ2UgcmF0ZSBtZWNoYW5p c20gd2l0aCB0aGUgbWluaW11bSByYXRlIG1lY2hhbmlzbS4gVGhlIG1pbmltdW0gcmF0ZSBtZWNo YW5pc20gZG9lcyBub3QgaGF2ZSB0aGUgZnVuY3Rpb25hbGl0eSB0byBpbmNyZWFzZSBvciBkZWNy ZWFzZSB0aGUgbm90aWZpY2F0aW9uIGZyZXF1ZW5jeSwgaXQganVzdCBpc3N1ZXMgbm90aWZpY2F0 aW9ucyBhdCBldmVyeSBtaW4taW50ZXJ2YWwgc2Vjb25kcy4gSW4gYXZlcmFnZSByYXRlIG1lY2hh bmlzbSwgdGhlIG5vdGlmaWVyIGNhbiBpbmNyZWFzZSBvciBkZWNyZWFzZSB0aGUgbm90aWZpY2F0 aW9uIGZyZXF1ZW5jeSBiYXNlZCBvbiByZWNlbnQgbnVtYmVyIG9mIG5vdGlmaWNhdGlvbnMgc2Vu dCBvdXQgaW4gdGhlIGxhc3QgInBlcmlvZCIgb2Ygc2Vjb25kcy4gVGhlIHNlbnRlbmNlIGFib3Zl IHNpbXBseSBzdGF0ZXMgdGhhdCBhIHN1YnNjcmliZXIgbWF5IHJlY2VpdmUgdW5uZWNlc3Nhcnkg bm90aWZpY2F0aW9ucyAocmVjZWl2ZXMgdGhlIHNhbWUgc3RhdGUgaXQgYWxyZWFkeSBoYXMpIGR1 ZSB0byB0aGUgYXZlcmFnZSByYXRlIG1lY2hhbmlzbSAoc2FtZSBpcyBvZiBjb3Vyc2UgdHJ1ZSBm b3IgdGhlIG1pbmltdW0gcmF0ZSBtZWNoYW5pc20pLg0KDQpJIGZvdW5kIHRoZSB1c2Ugb2YgdGhl IHRlcm0g4oCcdGltZW91dOKAnSBjb25mdXNpbmcgYXMgaXQgaW1wbGllcyAoYXQgbGVhc3QgdG8g bWUpIOKAnGEgdGltZSBpbiB3aGljaCB5b3UgbXVzdCBub3Qgc2VuZCBhbnl0aGluZ+KAnSByYXRo ZXIgdGhhbiDigJxhIHRpbWUgYWZ0ZXIgd2hpY2ggeW91IG11c3Qgc2VuZCBzb21ldGhpbmfigJ0t IGJ1dCBtYXliZSB0aGF0IGlzIGp1c3QgbWUuDQoNCltLS10g4oCcdGltZW91dOKAnSBpcyBhIOKA nHRpbWUgYWZ0ZXIgd2hpY2ggeW91IG11c3Qgc2VuZCBzb21ldGhpbmfigJ0uIFNlY3Rpb24gNi4y IHN0YXRlczog4oCcQSBjb21wbGlhbnQgbm90aWZpZXIgU0hPVUxEIGdlbmVyYXRlIG5vdGlmaWNh dGlvbnMgd2hlbmV2ZXIgdGhlIHRpbWUgc2luY2UgdGhlIG1vc3QgcmVjZW50IG5vdGlmaWNhdGlv biBleGNlZWRzIHRoZSB2YWx1ZSBjYWxjdWxhdGVkIHVzaW5nIHRoZSBmb3JtdWxhIGRlZmluZWQg aW4gU2VjdGlvbiA2LjPigJ0uIEl0IGZ1cnRoZXIgc3RhdGVzOiDigJxJZiB0aGUgdGltZW91dCBw ZXJpb2QgcGFzc2VzIHdpdGhvdXQgYSBOT1RJRlkgcmVxdWVzdCBiZWluZyBzZW50IGluIHRoZSBz dWJzY3JpcHRpb24sIHRoZW4gdGhlIGN1cnJlbnQgcmVzb3VyY2Ugc3RhdGUgaXMgc2VudCAoc3Vi amVjdCB0byBhbnkgZmlsdGVyaW5nIGFzc29jaWF0ZWQgd2l0aCB0aGUgc3Vic2NyaXB0aW9uKS7i gJ0gdGh1cyB0aGUgbm90aWZpZXIgZG9lcyBub3QgaGF2ZSB0byB3YWl0IGZvciB0aGUgInRpbWVv dXQiIHRvIHBhc3MgdG8gc2VuZCBhIG5ldyBOT1RJRlkgcmVxdWVzdC4gSWYgdGhlIGV2ZW50IHN0 YXRlIGNoYW5nZXMsIG9uZSAob3IgZXZlbiBtb3JlKSBOT1RJRlkgcmVxdWVzdChzKSBjYW4gYmUg c2VudCBvdXQgd2l0aG91dCB3YWl0aW5nIGZvciAidGltZW91dCIuIElmIHNldmVyYWwgTk9USUZZ IHJlcXVlc3RzIGhhdmUgYmVlbiBzZW50IHJlY2VudGx5IChkdWUgdG8gZXZlbnQgc3RhdGUgY2hh bmdlcykgYW5kIHRoZSBldmVudCBzdGF0ZSBkb2VzIG5vdCBjaGFuZ2UgZnVydGhlciwgdGhlIGlu dGVydmFsIGZvciB0aGUgbmV4dCBOT1RJRlkgcmVxdWVzdCAoZHVlIHRvICJ0aW1lb3V0IikgaW5j cmVhc2VzLg0KDQpXaGVuIHdlIGdldCB0byB0aGUgZm9ybXVsYWUgYW5kIHRoZSBkZXRhaWxlZCBt ZWNoYW5pY3MsIGl0IGlzIGNsZWFyIHRoYXQgdGhpcyBhcHByb2FjaCB3aWxsIG9ubHkgZXZlciBE RUNSRUFTRSB0aGUgaW50ZXJ2YWwgYmV0d2VlbiBub3RpZmljYXRpb25zIMKgKGZyb20gd2hhdCBp dCB3b3VsZCBiZSB3aXRob3V0IEV2ZW50IFJhdGUgQ29udHJvbCksIGl0IHdpbGwgbmV2ZXIgSU5D UkVBU0UgdGhlIGludGVydmFsIGJldHdlZW4gbm90aWZpY2F0aW9ucyDCoChmcm9tIHdoYXQgaXQg d291bGQgYmUgd2l0aG91dCBFdmVudCBSYXRlIENvbnRyb2wpLiANCg0KW0tLXSBZZXMsIHlvdSdy ZSByaWdodC4gTGV0IG1lIHRyeSB0byBpbGx1c3RyYXRlIHdoYXQgd2UgbWVhbiBieSAiaW5jcmVh c2UgdGhlIGludGVydmFsIGJldHdlZW4gbm90aWZpY2F0aW9ucyI6DQp0aW1lb3V0ID0gKGF2ZXJh Z2UtaW50ZXJ2YWwgXiAyKSAqIGNvdW50IC8gcGVyaW9kIA0KTGV04oCZcyBhc3N1bWUgYXZlcmFn ZS1pbnRlcnZhbD0zMCwgcGVyaW9kPTYwIGFuZCB0aGVyZSBoYXZlIGJlZW4gNCBub3RpZmljYXRp b25zIGR1cmluZyB0aGUgbGFzdCA2MCBzZWMsIG9uZSBhdCBldmVyeSAxNXRoIHNlYyAoY291bnQ9 NCkuIFRoZW4sIGNhbGN1bGF0aW5nIHRoZSB0aW1lb3V0IHZhbHVlIGl0IHR1cm5zIG91dCB0aGF0 IHRoZSBuZXh0IHRpbWVvdXQgaXMgNjAgc2VjIGZyb20gdGhlIGxhc3Qgbm90aWZpY2F0aW9uIGFz c3VtaW5nIG5vIHN0YXRlIGNoYW5nZXMgcmVxdWlyaW5nIGEgbm90aWZpY2F0aW9uIG90aGVyd2lz ZS4gVGh1cywgdGhlIGludGVydmFsIGJldHdlZW4gbm90aWZpY2F0aW9ucyBpbmNyZWFzZWQgZnJv bSAxNSBzZWMgdG8gNjAgc2VjLg0KDQpTbyB5b3UgbmVlZCBtYWtlIHRoZSBkb2N1bWVudCBjb25z aXN0ZW50LiDCoEVpdGhlciByZW1vdmUgdGhlIHRleHQgdGhhdCBzYXlzIChvciBpbXBsaWVzKSDC oHRoZSDigJxhdmVyYWdlLWludGVydmFs4oCdIMKgbWVjaGFuaXNtIHdpbGwgaW5jcmVhc2UsIGFz IHdlbGwgYXMgZGVjcmVhc2UsIHRoZSBpbnRlcnZhbCwgb3IgbW9kaWZ5IHRoZSBtZWNoYW5pc20g c28gaXQgRE9FUyDigJxkeW5hbWljYWxseSBpbmNyZWFzZSBvciBkZWNyZWFzZSB0aGUgTm90aWZp Y2F0aW9uIGZyZXF1ZW5jeeKAnS4gKHRoZSBsYXR0ZXIgd291bGQgYmUsIEkgdGhpbmssIHByZWZl cnJlZCkuIA0KDQpGdXJ0aGVybW9yZSwgaW4gdGhlIGRlc2NyaXB0aW9uIG9mIHRoZSDigJxhdmVy YWdlLWludGVydmFs4oCdIG1lY2hhbmlzbSwgdGhlcmUgbmVlZHMgdG8gYmUgZWl0aGVyIGEg4oCc TVVTVOKAnSBvciBhIOKAnFNIT1VMROKAnSB0byBlbnN1cmUgdGhhdCDigJxwZXJpb2TigJ0gaXMg R1JFQVRFUiBUSEFOIHRoZSDigJxhdmVyYWdlLWludGVydmFs4oCdLiDCoE90aGVyd2lzZSB0aGUg ZGVzY3JpYmVkIG1lY2hhbmlzbSB3aWxsIHNlbmQgb3V0IGEgbm90aWZpY2F0aW9uIGV2ZXJ5IOKA nHBlcmlvZOKAnSBzZWNvbmRzLCByZWdhcmRsZXNzIG9mIHRoZSB2YWx1ZSBvZiDigJxhdmVyYWdl LWludGVydmFs4oCdLg0KDQpbS0tdLiBUaGlzIGlzIGEgdmFsaWQgcG9pbnQuIEkgYWRkZWQgdGhl IGZvbGxvd2luZyB0ZXh0IHRvIHRoZSDigJxwZXJpb2TigJ0gZGVmaW5pdGlvbiBpbiB0aGUgLTA0 IHZlcnNpb246IOKAnFRoZSB2YWx1ZSBvZiB0aGUgInBlcmlvZCIgcGFyYW1ldGVyIE1VU1QgYmUg Z3JlYXRlciB0aGFuIHRoZSB2YWx1ZSBvZiB0aGUgImF2ZXJhZ2UtaW50ZXJ2YWwiIHBhcmFtZXRl ci7igJ0NCsKgDQpUaGFua3MsDQpLcmlzenRpYW4NCg0KSmFuZXQNCg0KVGhpcyBpcyBhIFBSSVZB VEUgbWVzc2FnZS4gSWYgeW91IGFyZSBub3QgdGhlIGludGVuZGVkIHJlY2lwaWVudCwgcGxlYXNl IGRlbGV0ZSB3aXRob3V0IGNvcHlpbmcgYW5kIGtpbmRseSBhZHZpc2UgdXMgYnkgZS1tYWlsIG9m IHRoZSBtaXN0YWtlIGluIGRlbGl2ZXJ5LiANCk5PVEU6IFJlZ2FyZGxlc3Mgb2YgY29udGVudCwg dGhpcyBlLW1haWwgc2hhbGwgbm90IG9wZXJhdGUgdG8gYmluZCBDU0MgdG8gYW55IG9yZGVyIG9y IG90aGVyIGNvbnRyYWN0IHVubGVzcyBwdXJzdWFudCB0byBleHBsaWNpdCB3cml0dGVuIGFncmVl bWVudCBvciBnb3Zlcm5tZW50IGluaXRpYXRpdmUgZXhwcmVzc2x5IHBlcm1pdHRpbmcgdGhlIHVz ZSBvZiBlLW1haWwgZm9yIHN1Y2ggcHVycG9zZS4gDQoNCnNpcGNvcmUtYm91bmNlc0BpZXRmLm9y ZyB3cm90ZSBvbiAwNi8xMC8yMDEwIDA0OjE0OjI5IFBNOg0KDQo+IFtpbWFnZSByZW1vdmVkXSAN Cj4gDQo+IFtzaXBjb3JlXSBBRCByZXZpZXc6IGRyYWZ0LWlldGYtc2lwY29yZS1ldmVudC1yYXRl LWNvbnRyb2wtMDMgDQo+IA0KPiBSb2JlcnQgU3BhcmtzIA0KPiANCj4gdG86IA0KPiANCj4gU0lQ Q09SRSANCj4gDQo+IDA2LzEwLzIwMTAgMDQ6MTQgUE0gDQo+IA0KPiBTZW50IGJ5OiANCj4gDQo+ IHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyANCj4gDQo+IFN1bW1hcnk6IFRoaXMgZHJhZnQgaGFz IGEgZmV3IGFkanVzdG1lbnRzIHRoYXQgYXJlIG5lZWRlZCBiZWZvcmUgDQo+IG1vdmluZyBpdCBp bnRvIElFVEYgTGFzdCBDYWxsLg0KPiANCj4gTWFqb3IgcXVlc3Rpb246DQo+IA0KPiBXaHkgaXNu J3QgdGhpcyBhbiBVcGRhdGUgdG8gMzI2NT8gSXMgdGhlcmUgdGV4dCBoZXJlIHRoYXQgcHJldmVu dHMgYXN1YnNjcmliZXINCj4gZnJvbSBnZW5lcmF0aW5nIEV2ZW50IGhlYWRlcnMgaW4gMjAwIE9L cyB0byBOT1RJRllzIG1pZC1zdWJzY3JpcHRpb24gKHdoZW4gaGUNCj4gZGlkbid0IHByb2JlIGZv ciBzdXBwb3J0IHVzaW5nIHRoZSBTVUJTQ1JJQkU/KSBIb3cgd291bGQgdGhleSBrbm93IHRoZSBy ZXF1ZXN0DQo+IGdvdCBob25vcmVkPyDCoFRoZSBwb3NzaWJpbGl0eSBvZiBydW5uaW5nIGludG8g aW1wbGVtZW50YXRpb25zIHRoYXQgDQo+IGJyZWFrIHNob3VsZA0KPiBiZSBjYWxsZWQgb3V0LiDC oDQuMiBpbmRpY2F0ZXMgdGhlIHN1YnNjcmliZXIgb25seSBnZXRzIGEgImhpbnQiIGFib3V0IHN1 cHBvcnQNCj4gZm9yIHJhdGUtY29udHJvbCBpbiB0aGUgbm90aWZpZXIgLSBpcyB0aGUgY29uZGl0 aW9uIGl0IGRlc2NyaWJlcyByZWFsbHkgb25seSBhDQo+IGhpbnQ/DQo+IA0KPiBJbiBzZXZlcmFs IHBsYWNlcywgdGhlIG5vdGlmaWVyIGlzIGdpdmVuIHBlcm1pc3Npb24gdG8gYWRqdXN0IGFuIA0K PiBpbnRlcnZhbCBiYXNlZA0KPiBvbiBsb2NhbCBwb2xpY3kuIMKgVGhlIGRvY3VtZW50IHNob3Vs ZCBiZSBleHBsaWNpdCBhYm91dCBhbGxvd2luZyB0aGVhZGp1c3RtZW50DQo+IGluIGFueSBkaXJl Y3Rpb24gKGluY3JlYXNpbmcgb3IgZGVjcmVhc2luZykgc2luY2UgdGhlcmUgYXJlIHNvIG1hbnkg b3RoZXIgdXNlcw0KPiBvZiBpbnRlcnZhbHMgaW4gU0lQIGFuZCBTSVAgRXZlbnRzIHRoYXQgYWxs b3cgYWRqdXN0bWVudCBvbmx5IGluIG9uZWRpcmVjdGlvbi4NCj4gQSBmZXcgcGxhY2VzIEkgbm90 ZWQgd2hlbiByZWFkaW5nIHRoZSBkb2N1bWVudCB3ZXJlIHRoZSBOb3RlIGluIFJFUTcsIDQuMyA0 dGgNCj4gcGFyYWdyYXBoLCA1LjIgcGFyYWdyYXBoIDMsIDYuMiBwYXJhZ3JhcGggMy4NCj4gDQo+ IFRoZSBsYXN0IHBhcmFncmFwaCBvZiBzZWN0aW9uIDMuNiBjbGFpbXMgImV4YWN0bHkgdGhlIHNh bWUgcHJvcGVydGllcyIgZXhjZXB0DQo+IGZvciBiZWluZyBnZW5lcmF0ZWQgY29uc3RyYWluZWQg dG8gYSBzY2hlZHVsZS4gQ2FuIHlvdSBjbGFyaWZ5IHdoaWNocHJvcGVydGllcw0KPiB5b3UgbWVh bj8gTWFueSBwcm9wZXJ0aWVzIG9mIHRoZSBub3RpZmljYXRpb25zIGJlc2lkZSB0aGVpciB0aW1p bmcgYXJlIGNsZWFybHkNCj4gZGlmZmVyZW50IChmb3IgaW5zdGFuY2UsIHlvdSBtYXkgbWlzcyBz dGF0ZSB0cmFuc2l0aW9ucykuDQo+IA0KPiBUaGUgc2VjdXJpdHkgY29uc2lkZXJhdGlvbnMgc2Vj dGlvbiBkZXNlcnZlcyBtb3JlIHRleHQ6IA0KPiAqIFdoYXQgaXMgdGhlIGZvcndhcmQgcmVmZXJl bmNlIGZyb20gc2VjdGlvbiAzLjQgc3VwcG9zZWQgdG8gYmUgcG9pbnRpbmcgdG8/DQo+ICogQ2Fs bCBvdXQgdGhlIGltcGxpY2F0aW9ucyBvbiBhIE5vdGlmaWVyIGhhdmluZyB0byBzdG9yZS9hZ2dy ZWdhdGUgDQo+IHBhcnRpYWwgc3RhdGUNCj4gKiBOb3RlIHRoYXQgdGhlIEV2ZW50IGhlYWRlciAo cGFydGljdWxhcmx5IGluIDIwMCBPS3MpIGlzIG5vdCANCj4gaW50ZWdyaXR5IHByb3RlY3RlZC4g DQo+IMKgIFRoaXMgd291bGQgYWxsb3cgYW55dGhpbmcgdGhhdCBjb3VsZCBtb2RpZnkgdGhlIG1l c3NhZ2UgaW4gZmxpZ2h0IChvciBhbiANCj4gwqAgZWF2ZXNkcm9wcGVyIHRoYXQgY291bGQgcmFj ZSBhIDIwMCBPSyBpbikgdG8gc3VwcHJlc3MgKG9yIGZsb29kKSANCj4gbm90aWZpY2F0aW9ucyAN Cj4gwqAgd2l0aG91dCB0aGUgc3Vic2NyaWJlciBzZWVpbmcgd2hhdCBjYXVzZWQgaXQuDQo+IA0K PiBUaGUgYXNzZXJ0aW9uIHRoYXQgYXBwbHlpbmcgcmF0ZSBsaW1pdGluZyBhbmQgY29tcHJlc3Np b24gdG9nZXRoZXIgcmVzdWx0cyBpbg0KPiBzYXZpbmdzIGFzIGdvb2QgYXMgdGhlIHN1bSBvZiBh cHBseWluZyB0aGVtIGluZGVwZW5kZW50bHkgc2hvdWxkIGJlIHN1cHBvcnRlZA0KPiBvciBhZGp1 c3RlZC4gSSB0aGluayBpdCdzIHN1ZmZpY2llbnQgdG8gc2F5IHRoZXkgY2FuIGJlIGFwcGxpZWQg dG9nZXRoZXIuDQo+IA0KPiBCZWxvdyBhcmUgc2V2ZXJhbCBzdWdnZXN0aW9ucyBmb3IgdGV4dCB0 d2Vha3MuIFRoZSBmaXJzdCBmZXcgKHN0YXJpbmcgd2l0aCAqKQ0KPiBhcmUgdGhlIG1vc3QgaW1w b3J0YW50LiANCj4gDQo+ICogU2VjdGlvbiAzLjIgcGFyYWdyYXBoIDQ6IHN1Z2dlc3QgcmVwbGFj aW5nICJkb2VzIG5vdCB0eXBpY2FsbHkiIA0KPiB3aXRoICJtYXkgbm90Ig0KPiANCj4gKiBTZWN0 aW9uIDMuMiBsYXN0IHBhcmFncmFwaDogVGhlIHNlbnRlbmNlICdUaGUgIm1heC1pbnRlcnZhbCIg cGFyYW1ldGVyIA0KPiDCoCDCoCDCoCBpbmRpY2F0ZXMgLi4uIGNvbXBsZXRlIHN0YXRlIGluZm9y bWF0aW9uJyBpcyBkaWZmaWN1bHQgdG8gDQo+IHBhcnNlLiBDb3VsZCBpdA0KPiDCoCDCoCDCoCBi ZSBzaW1wbGlmaWVkPw0KPiANCj4gKiBTZWN0aW9uIDQuMyBmaXJzdCBwYXJhZ3JhcGgsIGxhc3Qg c2VudGVuY2U6ICJGb3Igc3VjaCBjYXNlcyIgaXMgYW1iaWd1b3VzLg0KPiDCoCBTdWdnZXN0ICJJ ZiB0aGUgbWluLWludGVydmFsIHZhbHVlIGlzIGdyZWF0ZXIgdGhhbiB0aGUgc3Vic2NyaXB0aW9u IGV4cGlyeSIuDQo+IA0KPiAqIFNlY3Rpb24gNi4yIGxhc3QgcGFyYWdyYXBoOiBUaGlzIGN1cnJl bnRseSBzYXlzIHRoZSB0aW1lb3V0IG1lY2hhbmlzbSBkb2VzDQo+IMKgIG5vdCBhZmZlY3Qgd2hl biAzMjYxIHRyYW5zYWN0aW9uIHJldHJhbnNtaXNzaW9ucyBhcmUgZ2VuZXJhdGVkLiBJdCBzaG91 bGQNCj4gwqAgYWxzbyBleHBsaWNpdGx5IG5vdGUgdGhhdCByZXRyYW5zbWlzc2lvbnMgZG8gbm90 IGFmZmVjdCB0aGUgY2FsY3VsYXRpb24gb2YNCj4gwqAgdGhlIG5leHQgdGltZW91dC4NCj4gDQo+ IEludHJvZHVjdGlvbiwgcGFyYWdyYXBoIDI6IHN1Z2dlc3QgcmVwbGFjaW5nICJjb25nZXN0aW9u IiB3aXRoICJsb2FkIg0KPiANCj4gU2VjdGlvbiAzLjEgwqBwYXJhZ3JhcGggMzogc3VnZ2VzdCBy ZXBsYWNpbmcgImFtb3VudCBvZiB0cmFmZmljIiB3aXRoIA0KPiAibnVtYmVyIG9mIG5vdGlmaWNh dGlvbnMiDQo+IA0KPiBTZWN0aW9uIDMuNSBwYXJhZ3JhcGggMTogU3VnZ2VzdCBhIHJlZmVyZW5j ZSBmb3IgUkxTIGFmdGVyICJsaXN0IA0KPiBzdWJzY3JpcHRpb24iLg0KPiBUaGUgc2VudGVuY2Ug Ik1vcmVvdmVyLCB0aGUgbGlzdCBldmVudCBub3RpZmllci4uLiIgc2hvdWxkIGJlIG1vcmUgZXhw bGljaXQNCj4gYWJvdXQgdXNpbmcgdGhlIHJhdGUgbWVjaGFuaXNtIGZvciBhbnkgYmFjay1lbmQg c3Vic2NyaXB0aW9ucyBpdCBtaWdodCBoYXZlLg0KPiANCj4gU3VnZ2VzdCByZWZlcmVuY2luZyAz MjYxIGluIHRoZSBsYXN0IHBhcmFncmFwaCBvZiA0LjINCj4gDQo+IFNlY3Rpb24gNC4zLCAzcmQg cGFyYWdyYXBoIGxhc3Qgc2VudGVuY2UuIFRoZSBvbmx5IHdheSB0aGUgc3Vic2NyaWJlciBfY2Fu Xw0KPiByZXN1bWUgbm90aWZpY2F0aW9ucyBpcyB0byByZW5ldyB0aGUgc3Vic2NyaXB0aW9uIHdp dGggYSByZXN1YnNjcmliZSByZXF1ZXN0Lg0KPiBXb3VsZCB0aGlzIHRleHQgd29yaz8gIlRoaXMg cmVzdWx0cyBpbiByZWNlaXZpbmcgbm8gZnVydGhlciANCj4gbm90aWZpY2F0aW9ucyB1bnRpbA0K PiB0aGUgc3Vic2NyaXB0aW9uIGV4cGlyZXMgb3IgdGhlIHN1YnNjcmliZXIgc2VuZHMgYSBTVUJT Q1JJQkUgcmVxdWVzdHJlZnJlc2hpbmcNCj4gdGhlIHN1YnNjcmlwdGlvbiAocGVyaGFwcyByZXN1 bWluZyBub3RpZmljYXRpb25zKSIuDQo+IA0KPiBUaGUgdGV4dCBuZWVkcyB0byBiZSBhZGp1c3Rl ZCB0byByZWZsZWN0IHN1Ym5vdC1ldGFncyBiZWluZyBpc3N1ZWQgYXMgYW4gUkZDDQo+IA0KPiBB ZGFtIHN1Z2dlc3RlZCBzb21lIFJGQy1FZGl0b3Igbm90ZXMgaW4gdGhlIHByb3RvIHdyaXRldXAg KHdoaWNoIG1heSBhZGRyZXNzDQo+IHNvbWUgb2YgdGhlIGFib3ZlIGNvbW1lbnRzKS4gUGxlYXNl IGJlIHN1cmUgdG8gaW5jb3Jwb3JhdGUgdGhvc2Ugd2hlbiByZXZpc2luZw0KPiB0aGUgZHJhZnQu DQo+IA0KPiBPbmUgbGFzdCBxdWVzdGlvbjoNCj4gDQo+IElmIHRoZSBjb21iaW5hdGlvbiBvZiBt aW4taW50ZXJ2YWwsIG1heC1pbnRlcnZhbCwgYW5kIGF2ZXJhZ2UtaW50ZXJ2YWwgbWFrZQ0KPiBs aXR0bGUgc2Vuc2UsIHdoeSBkb2VzIHRoZSBkb2N1bWVudCBhbGxvdyB0aGVtIHRvIGJlIGNvbWJp bmVkPyBJIA0KPiB0aGluayB3aGF0IHRoZQ0KPiBncm91cCB3YXMgdHJ5aW5nIHRvIHNheSBpcyB0 aGF0IHdlIGN1cnJlbnRseSBkb24ndCBmb3JzZWUgYSB1c2UgZm9yIGNvbWJpbmluZw0KPiB0aG9z ZSBvcHRpb25zLCBidXQgZG8gbm90IHdpc2ggdG8gZm9yYmlkIHRoZWlyIGNvbWJpbmF0aW9uLg0K PiANCj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4g c2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg== From adam@nostrum.com Mon Jul 12 19:27:02 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 83D3D3A6844 for ; Mon, 12 Jul 2010 19:27:02 -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, 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 f5YblnqMamrL for ; Mon, 12 Jul 2010 19:27:01 -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 67EE73A67AE for ; Mon, 12 Jul 2010 19:27:01 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-149-233.dsl.rcsntx.swbell.net [70.249.149.233]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6D2R7VD024979 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 12 Jul 2010 21:27:08 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C3BCEFB.5010201@nostrum.com> Date: Mon, 12 Jul 2010 21:27:07 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: krisztian.kiss@nokia.com References: <99619466-573D-4CEA-ACCD-3A3D262EB2B0@nostrum.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.149.233 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-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, 13 Jul 2010 02:27:02 -0000 [as participant and RFC3265 expert] On 7/12/10 19:13, Jul 12, krisztian.kiss@nokia.com wrote: > Major question: > > Why isn't this an Update to 3265? > > [KK] It's an extension to 3265. Implementations of 3265 not interested in rate control don't need to implement it. If people think it's an essential part of event-notifications, we could make it as an update of 3265. Any recommendations? To be clear, these kinds of extensions haven't historically been considered "updates" to 3265 -- at least, in terms of the RFC "updates" terminology. Probably the closest parallel is RFC 4662 (another cross-package extension), which was not considered to be an update to 3265. So I think it's appropriate to consider this an extension (which we have not traditionally considered an "update"), rather than a formal update. /a From Martin.Thomson@andrew.com Mon Jul 12 22:53:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2E4C03A6875 for ; Mon, 12 Jul 2010 22:53:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.719 X-Spam-Level: X-Spam-Status: No, score=-2.719 tagged_above=-999 required=5 tests=[AWL=-0.120, 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 Wm7Fp7sRVh+I for ; Mon, 12 Jul 2010 22:53:45 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 263EC3A67C0 for ; Mon, 12 Jul 2010 22:53:39 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:30134 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S337104Ab0GMFxr (ORCPT ); Tue, 13 Jul 2010 00:53:47 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 13 Jul 2010 00:53:47 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 13 Jul 2010 13:53:45 +0800 From: "Thomson, Martin" To: "James M. Polk" , "sipcore@ietf.org" Date: Tue, 13 Jul 2010 13:55:51 +0800 Thread-Topic: [sipcore] location-conveyance-03 just submitted Thread-Index: AcsiHaubmUNEswfFSNG6YyIwHpshjQABipyw Message-ID: <8B0A9FCBB9832F43971E38010638454F03E9DCCFFC@SISPE7MB1.commscope.com> References: <201007122355.o6CNt6us024310@sj-core-3.cisco.com> In-Reply-To: <201007122355.o6CNt6us024310@sj-core-3.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] location-conveyance-03 just 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: Tue, 13 Jul 2010 05:53:52 -0000 Rmlyc3RseSwgdGhlIGdvb2Q6DQoNClRoZSBzaW1wbGlmaWNhdGlvbnMgYXJlIGEgZ3JlYXQgaW1w cm92ZW1lbnQuICBUaGUgZG9jdW1lbnQgaXMgbW9yZSBhY2Nlc3NpYmxlIGFuZCByZWFkYWJsZSBh cyBhIHJlc3VsdC4gIFRoZSBtZWNoYW5pc20gaXMgZnVuZGFtZW50YWxseSBzaW1wbGVyLg0KDQpD b250ZW50IGluZGlyZWN0aW9uIGhhcyBzb21lIGludGVyZXN0aW5nIGJlbmVmaXRzLiAgSXQncyBh IGdvb2QgaWRlYS4NCg0KSSBoYXZlIHNvbWUgY29tbWVudHMgdGhhdCBpbmNsdWRlcyBvbmUgbWFq b3IgaXNzdWUuDQoNClRoZSBtYWpvciBpc3N1ZToNCg0KVGhlIGxpbWl0YXRpb24gdG8gX29uZV8g bG9jYXRpb24gdmFsdWUgaGFzIHVuZGVuaWFibGUgYmVuZWZpdHMuICBJdCBhbHNvIHByZXZlbnRz IHRoZSBjb252ZXlhbmNlIG9mIGxvY2F0aW9uIHZhbHVlIGFuZCByZWZlcmVuY2UgdG9nZXRoZXIu DQoNCmRyYWZ0LWlldGYtZWNyaXQtcm91Z2gtbG9jIGRlc2NyaWJlcyBvbmUgdXNlIGNhc2UgdGhh dCB0aGlzIGFmZmVjdHMuICBCcmlhbiAoeW91ciBvdGhlciBjby1hdXRob3IpIHNob3VsZCBiZSBh YmxlIHRvIGFwcHJpc2UgeW91IG9mIHRoZSBjb25zZXF1ZW5jZXMgdGhpcyBoYXMgdG8gdGhlIE5F TkEgdXNlIGNhc2VzLg0KDQpKb24ncyBvcmlnaW5hbCByZXNwb25zZSB0byB0aGlzIHdhcyB0byBw dXNoIHRoZSBjb21wb3NpdGlvbiBwcm9ibGVtIHRvIHRoZSBQSURGLUxPLiAgVGhhdCBjb3VsZCBi ZSBkb25lLCBidXQgaXQgbmVlZHMgbW9yZSBzcGVjaWZpY2F0aW9uLg0KDQpSZWFjaGluZyBzb21l IHNvcnQgb2YgY29uc2Vuc3VzIG9uIHRoZSBzb2x1dGlvbiB0byB0aGlzIHByb2JsZW0gYmVmb3Jl IHRoaXMgd29yayBpcyBmaW5pc2hlZCBpcyBpbXBvcnRhbnQuDQoNCk1pbm9yIGlzc3VlczoNCg0K VGhlIHN0cnVjdHVyZSBvZiB0aGUgR2VvbG9jYXRpb24tRXJyb3IgaGVhZGVyIGRlc2NyaXB0aW9u IGlzIGEgbGl0dGxlIG9kZC4gIEl0IHNlZW1zIHRoYXQgeW91IGFyZSB0cnlpbmcgdG8gZGVzY3Jp YmUgKmNsYXNzZXMqIG9mIGVycm9yIGFuZCBzcGVjaWZpYyBlcnJvcnMgYXQgdGhlIHNhbWUgdGlt ZS4gIFNlcGFyYXRpbmcgdGhlc2UgY29uY2VybnMgbWlnaHQgbWFrZSB0aGlzIGVhc2llciB0byBl eHBsYWluIGFuZCB1bmRlcnN0YW5kLg0KDQpUaGUgZHJhZnQgZG9lc27igJl0IHJlYWxseSBqdXN0 aWZ5IHRoZSBleGlzdGVuY2Ugb2YgdGhlICJnZW9sb2NhdGlvbiIgb3B0aW9uIHRhZy4NCg0KU2Vj dGlvbiA0LjYgc2hvdWxkIHJlZmVyZW5jZSBkcmFmdC1pZXRmLWdlb3ByaXYtZGVyZWYtcHJvdG9j b2wuDQoNClNlY3Rpb24gNSBzaG91bGQgc2hvdyBhbiBleGFtcGxlIHVzZSBvZiBjb250ZW50IGlu ZGlyZWN0aW9uIGZvciBhIGxvY2F0aW9uIFVSSS4NCg0KSnVzdCBhIGZldyBuaXRzOg0KDQpPdmVy YWxsLCB0aGUgc3RydWN0dXJlIGlzIGdyZWF0bHkgaW1wcm92ZWQsIGJ1dCB3aGVuIHlvdSBzZWUg cmVmZXJlbmNlcyBpbiB0aGUgZm9ybSAiaW4gc2VjdGlvbiAzIChiZWxvdyBGaWd1cmUgNCkiLCB5 b3UgaGF2ZSBhIG5lZWQgZm9yIG1vcmUgc3ViLXNlY3Rpb25zLg0KDQpUaGUgZXhhbXBsZXMgaW4g U2VjdGlvbiA1IGFyZSBub3Qgc2NoZW1hLXZhbGlkIC0gYy5mLiBSRkMgNDExOSBlcnJhdGEgIzE3 NzENCiAgPGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhX3NlYXJjaC5waHA/cmZjPTQx MTk+DQoNClRoaXMsIGluIHRoZSBpbnRyb2R1Y3Rpb24sIGRvZXNuJ3QgcmVhZCB3ZWxsOg0KDQog IGEgbm9uLUlQIGRldmljZSAoYSBwZXJzb24gb3IgYSBibGFjayBwaG9uZSkNCg0KImJsYWNrIHBo b25lIiBpcyBhIGxpdHRsZSBqYXJnb24teS4gIE1vcmUgYW11c2luZyB3YXMgdGhlIGlkZWEgdGhh dCB5b3VyIGNoYXJhY3RlcmlzYXRpb24gb2YgYSBwZXJzb24gd2FzIGFzIGEgIm5vbi1JUCBkZXZp Y2UiLg0KDQotLU1hcnRpbg0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206 IHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOnNpcGNvcmUtYm91bmNlc0BpZXRmLm9y Z10gT24NCj4gQmVoYWxmIE9mIEphbWVzIE0uIFBvbGsNCj4gU2VudDogVHVlc2RheSwgMTMgSnVs eSAyMDEwIDk6NTUgQU0NCj4gVG86IHNpcGNvcmVAaWV0Zi5vcmcNCj4gU3ViamVjdDogW3NpcGNv cmVdIGxvY2F0aW9uLWNvbnZleWFuY2UtMDMganVzdCBzdWJtaXR0ZWQNCj4gDQo+IFNJUENPUkUN Cj4gDQo+IGh0dHA6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWlldGYtc2lw Y29yZS1sb2NhdGlvbi0NCj4gY29udmV5YW5jZS0wMy50eHQNCj4gDQo+IFRoaXMgdmVyc2lvbiBp cyBhIGZhaXJseSByYWRpY2FsIGRlcGFydHVyZSBmcm9tIHByZXZpb3VzIHZlcnNpb25zIG9mDQo+ IHRoZSAobG9uZyBzdGFuZGluZykgZWZmb3J0LiAgVGhpcyB0aW1lIHRoZSBkb2MgZGlkbid0IGdy b3cuLi4NCj4gDQo+IFdlIGFkZGVkIEpvbiBQZXRlcnNvbiBhcyBhIGNvLWF1dGhvciwgYW5kIGhl IGhlbHBlZCBpbiBBbmFoZWltDQo+IHByb3Bvc2UgYSBzaWduaWZpY2FudGx5IGxlc3MgY29tcGxl eCB3YXkgb2Ygc3BlY2lmeWluZyBsb2NhdGlvbg0KPiBjb252ZXlhbmNlIGZvciBTSVAuIE1vcmUg dGhhbiA5NSUgb2YgdGhlIGRvYyBoYXMgYmVlbiByZXdyaXR0ZW4gYnkNCj4gSm9uIGFuZCBJLCB3 aXRoIGEgbmV0IHJlc3VsdCBvZiAyNyBsZXNzIHBhZ2VzIG9mIHRleHQgKDUyIHRvIDI1IG5vdyku DQo+IA0KPiBXZSB0b29rIG91dCB0aGUgdGVybXMgYW5kIGNvbmNlcHRzIG9mIGZvbGxvd2luZyBw YXJhbWV0ZXJzOg0KPiANCj4gLSBpbnNlcnRlcg0KPiAtIGluc2VydGVkLWJ5DQo+IC0gdXNlZC1m b3Itcm91dGluZw0KPiAtIGhvc3QtaWQNCj4gLSBub2RlLWlkDQo+IA0KPiBhcyB3ZWxsIGFzIGxp bWl0aW5nIHRoZSBudW1iZXIgb2YgbG9jYXRpb25WYWx1ZXMgdG8gKk9ORSosIGluIGEgU0lQDQo+ IHJlcXVlc3QuDQo+IA0KPiBXZSByZW1vdmVkIHRoZSBhYmlsaXR5IGZvciBTSVAgaW50ZXJtZWRp YXJpZXMgdG8gYWRkIGxvY2F0aW9uIGFsb25nDQo+IHRoZSB3YXkgdW5iZWtub3duc3QgdG8gdGhl IFVBQyAod2l0aCBvbmUgaW5mcmVxdWVudGx5IHVzZWQNCj4gZXhjZXB0aW9uKS4gSW4gdGhpcyB3 YXksIGxvY2F0aW9uIGVycm9ycyBhcmUgb25seSBlbmQtdG8tZW5kLCBzbw0KPiB0aGVyZSBpcyBu byBuZWVkIHRvIGlkZW50aWZ5IHdoaWNoIGVudGl0eSBhZGRlZCBsb2NhdGlvbiB0byBtYWtlIHN1 cmUNCj4gdGhlIHJpZ2h0IGVudGl0eSByZWFjdGVkIHRoZSByaWdodCB3YXkgd2hlbiBhbiBlcnJv ciB3YXMgY2F1c2VkIGJ5DQo+IHRoZSBsb2NhdGlvbiB0aGV5IGluc2VydGVkLCBhbmQgbm90IHRo YXQgb2YgYW5vdGhlciBlbnRpdHkncyBpbnNlcnRlZA0KPiBsb2NhdGlvbiAod2hpY2ggaXMgYWxs IHZlcnkgY29uZnVzaW5nKS4NCj4gDQo+IFdlIGFkZGVkIHRoZSBhYmlsaXR5IGZvciBhIFNJUCBp bnRlcm1lZGlhcnkgdG8gYXVnbWVudCBhIGxvY2F0aW9uDQo+IHdpdGggd2hhdCB0aGUgVUFDIHNo b3VsZCBzZW5kIGluIGEgc3Vic2VxdWVudCByZXF1ZXN0LCBhbmQgdGhlDQo+IGFiaWxpdHkgdG8g dmVyaWZ5IHRoaXMgYXVnbWVudGF0aW9uIGlzIHByZXNlbnQgYmVmb3JlIHN1Y2Nlc3NmdWxseQ0K PiBwcm9jZXNzaW5nIHRoYXQgcmVxdWVzdC4gVGhpcyBpcyBpbiBsaW5lIHdpdGggYm90aCBSRkNz IDQ0NzkgYW5kIDU0OTEuDQo+IA0KPiBDb21tZW50cyBhcmUgYXBwcmVjaWF0ZWQNCj4gDQo+IEph bWVzDQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f Xw0KPiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiBzaXBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8v d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0K From jmpolk@cisco.com Mon Jul 12 23:29:40 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 034353A68CC for ; Mon, 12 Jul 2010 23:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9qnZggFKQp4 for ; Mon, 12 Jul 2010 23:29:38 -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 755FE3A68B2 for ; Mon, 12 Jul 2010 23:29:38 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,192,1278288000"; d="scan'208";a="157608979" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 13 Jul 2010 06:29:47 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6D6Tk7F028645; Tue, 13 Jul 2010 06:29:46 GMT Message-Id: <201007130629.o6D6Tk7F028645@sj-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 13 Jul 2010 01:29:45 -0500 To: "Thomson, Martin" , "James M. Polk" , "sipcore@ietf.org" From: "James M. Polk" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E9DCCFFC@SISPE7MB1.comms cope.com> References: <201007122355.o6CNt6us024310@sj-core-3.cisco.com> <8B0A9FCBB9832F43971E38010638454F03E9DCCFFC@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] location-conveyance-03 just 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: Tue, 13 Jul 2010 06:29:40 -0000 Martin in-line At 12:55 AM 7/13/2010, Thomson, Martin wrote: >Firstly, the good: > >The simplifications are a great=20 >improvement. The document is more accessible=20 >and readable as a result. The mechanism is fundamentally simpler. glad you agree >Content indirection has some interesting benefits. It's a good idea. it has always been in Conveyance, but might have been lost in the clutter. >I have some comments that includes one major issue. > >The major issue: > >The limitation to _one_ location value has=20 >undeniable benefits. It also prevents the=20 >conveyance of location value and reference together. I believe we can have a location URI in the=20 presence document. But you're right, we don't=20 want one locationValue identifying a PIDF-LO and=20 another locationValue indicating a location URI. >draft-ietf-ecrit-rough-loc describes one use=20 >case that this affects. Brian (your other=20 >co-author) should be able to apprise you of the=20 >consequences this has to the NENA use cases. ok... >Jon's original response to this was to push the=20 >composition problem to the PIDF-LO. That could be done, that is what's done, there is no 'could'. The=20 text surrounding Figure 4 states this, and the=20 example in 5.2 explains this is the example=20 albeit showing two composed values from different sources. >but it needs more specification. > >Reaching some sort of consensus on the solution=20 >to this problem before this work is finished is important. agreed >Minor issues: > >The structure of the Geolocation-Error header=20 >description is a little odd. It seems that you=20 >are trying to describe *classes* of error and=20 >specific errors at the same time. Separating=20 >these concerns might make this easier to explain and understand. the errors are in categories, of which, only one=20 category has more than one error code(the 3XX category about permissions). >The draft doesn=E2=80=99t really justify the existence=20 >of the "geolocation" option tag. what would justify it? the purpose of an option-tag is the ability to=20 indicate support for an extension (whether=20 optional or required), and to respond with=20 whether or not an extension is supported or=20 unsupported. This indication can be quite=20 important for communicating SIP elements to=20 understand support for (or not). I'm confused... >Section 4.6 should reference draft-ietf-geopriv-deref-protocol. how so? It is already covered by the geopriv-filters=20 reference. I do not believe anything more is necessary. >Section 5 should show an example use of content=20 >indirection for a location URI. I'll talk to my co-authors about this, as they=20 are the ones limiting the number of examples ;-) >Just a few nits: > >Overall, the structure is greatly improved, but=20 >when you see references in the form "in section=20 >3 (below Figure 4)", you have a need for more sub-sections. this might be a good point. I'll talk to my=20 co-authors about breaking up section 3 into sub-sections (1 per Figure). >The examples in Section 5 are not schema-valid - c.f. RFC 4119 errata #1771 > this is quite possible. This was a bit cobbled together. >This, in the introduction, doesn't read well: > > a non-IP device (a person or a black phone) > >"black phone" is a little jargon-y. it's certainly known inside the voice/telephony world. >More amusing was the idea that your=20 >characterisation of a person was as a "non-IP device". many readers misunderstand when talking about=20 Alice, it's one of her electronic devices that=20 SIP communicates with, not her directly. Thanks for reading this so quickly and providing comments (seriously) James >--Martin > > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > > Behalf Of James M. Polk > > Sent: Tuesday, 13 July 2010 9:55 AM > > To: sipcore@ietf.org > > Subject: [sipcore] location-conveyance-03 just submitted > > > > SIPCORE > > > > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-location- > > conveyance-03.txt > > > > This version is a fairly radical departure from previous versions of > > the (long standing) effort. This time the doc didn't grow... > > > > We added Jon Peterson as a co-author, and he helped in Anaheim > > propose a significantly less complex way of specifying location > > conveyance for SIP. More than 95% of the doc has been rewritten by > > Jon and I, with a net result of 27 less pages of text (52 to 25 now). > > > > We took out the terms and concepts of following parameters: > > > > - inserter > > - inserted-by > > - used-for-routing > > - host-id > > - node-id > > > > as well as limiting the number of locationValues to *ONE*, in a SIP > > request. > > > > We removed the ability for SIP intermediaries to add location along > > the way unbeknownst to the UAC (with one infrequently used > > exception). In this way, location errors are only end-to-end, so > > there is no need to identify which entity added location to make sure > > the right entity reacted the right way when an error was caused by > > the location they inserted, and not that of another entity's inserted > > location (which is all very confusing). > > > > We added the ability for a SIP intermediary to augment a location > > with what the UAC should send in a subsequent request, and the > > ability to verify this augmentation is present before successfully > > processing that request. This is in line with both RFCs 4479 and 5491. > > > > Comments are appreciated > > > > James > > > > _______________________________________________ > > sipcore mailing list > > sipcore@ietf.org > > https://www.ietf.org/mailman/listinfo/sipcore From James.Winterbottom@andrew.com Mon Jul 12 23:51:12 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 780293A690E for ; Mon, 12 Jul 2010 23:51:12 -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 xNvM7WxIb1RK for ; Mon, 12 Jul 2010 23:51:11 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id A1E353A6851 for ; Mon, 12 Jul 2010 23:51:11 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:58073 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S331734Ab0GMGvU convert rfc822-to-8bit (ORCPT ); Tue, 13 Jul 2010 01:51:20 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 13 Jul 2010 01:51:20 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 13 Jul 2010 14:51:18 +0800 From: "Winterbottom, James" To: "James M. Polk" , "Thomson, Martin" , "sipcore@ietf.org" Date: Tue, 13 Jul 2010 14:51:16 +0800 Thread-Topic: [sipcore] location-conveyance-03 just submitted Thread-Index: AcsiVM7hB/XehKtcRIGsLtrH5/QNRQAAb/hQ Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120E7BC023C@SISPE7MB1.commscope.com> References: <201007122355.o6CNt6us024310@sj-core-3.cisco.com> <8B0A9FCBB9832F43971E38010638454F03E9DCCFFC@SISPE7MB1.commscope.com> <201007130629.o6D6Tk7F028645@sj-core-2.cisco.com> In-Reply-To: <201007130629.o6D6Tk7F028645@sj-core-2.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: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [sipcore] location-conveyance-03 just 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: Tue, 13 Jul 2010 06:51:12 -0000 Hi James, I have similar sentiments to Martin, this is a greatly improved document. > >Section 4.6 should reference draft-ietf-geopriv-deref-protocol. > > how so? > > It is already covered by the geopriv-filters > reference. I do not believe anything more is necessary. > I don't think that your response here answers the question. Section 4.6 as is written now is saying that only a SIP, SIPS or PRES URI scheme can be carried in the Sip header. " If a location URI is included in a SIP request, it MUST be a SIP-, SIPS- or PRES-URI. When PRES: is used, as defined in [RFC3856], if the resulting resolution resolves to a SIP: or SIPS: URI, this section applies. These schemes MUST be implemented according to this document. absoluteURI is not mandatory-to-implement, but allowed. See [ID-GEO-FILTERS] for more details on dereferencing location." LOC Filters is all about subscribing for location information using SIP, and makes no reference to the HELD deref draft that Martin has requested reference to. Since we now have a working group item in Geopriv describing how an HTTP URI can be used as a location URI, it is being requested that the SIP conveyance document allow this in its prose, rather than excluding everything but a SIP-related method. I think that this is a reasonable request. Cheers James From pkyzivat@cisco.com Tue Jul 13 07:35:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 79CA23A6890 for ; Tue, 13 Jul 2010 07:35:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.402 X-Spam-Level: X-Spam-Status: No, score=-10.402 tagged_above=-999 required=5 tests=[AWL=0.197, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OpLbGzo6UG3l for ; Tue, 13 Jul 2010 07:35:11 -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 064653A686D for ; Tue, 13 Jul 2010 07:35:09 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAK8WPExAZnwM/2dsb2JhbACfZXGkRJpqgl+CSASITQ X-IronPort-AV: E=Sophos;i="4.55,195,1278288000"; d="scan'208";a="131831457" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 13 Jul 2010 14:35:18 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6DEZIro020669; Tue, 13 Jul 2010 14:35:18 GMT Message-ID: <4C3C79AC.4050502@cisco.com> Date: Tue, 13 Jul 2010 10:35:24 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4C317D02.2030307@ericsson.com> In-Reply-To: <4C317D02.2030307@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 13 Jul 2010 14:35:14 -0000 Gonzalo, Gonzalo Camarillo wrote: > Hi, > > the re-INVITE draft talks about modifications in the session state, > dialog state, and the dialog's remote target. While it is relatively > well understood what we mean by session state and the dialog's remote > target, we do not really have a good definition for dialog state. > > We have discussed it in the past and what people had in mind were things > such as called party identity. However, the draft is too vague at this > point; it should be more precise regarding which piece of "dialog state" > the rules in the draft apply to. > > My suggestion would be to have the draft talk only about session state > and the dialog's remote target, and forget about any other dialog state. > New extensions whose parameters can be modified by re-INVITEs can > specify their own rules, possibly referring to this draft and using the > rules defined in it by reference. In this way, the applicability of this > draft would be much clearer. This is one of those areas that has bugged me for a long time. 3261 defines dialog state, but the definitions are spread through the text, and subject to interpretation. Things identifiable in 3261: - remote URI - local URI - dialog id * local tag * remote tag * call-id - local sequence number - remote sequence number - route set - secure flag - early / final - local SDP - remote SDP (I just coined terms local/remote SDP. AFAIK its never mentioned as state, but clearly it is.) Of course there is no distinction between dialog state and dialog usage state - that distinction was made later. But based on subsequent refinements we now know that most of the above is generic dialog state, *except* for the local/remote SDP and the early/final attribute. (Early dialogs can only arise with INVITE.) Clearly *reinvite* cannot really affect non-invite usages. So I think attributes of non-invite usages are out of scope for this draft. I don't know of an exhaustive list of dialog state or invite-usage state that has been introduced in other documents. And in fact its not especially clear which things should be considered dialog/dialog-usage state, vs. just being transient/transaction state. I do think it would be a good thing if an exhaustive list of dialog and dialog-usage state was documented, and possibly made an IANA registry. But the information certainly doesn't change much, or often, so maybe we can get by without that. Its interesting that the "rollback" we have been so concerned with regarding reinvite in fact does not impact *any* of the *dialog* state - only some of the invite-usage state, and not all of that. So the rollback is really very limited, and should probably be described in terms of what it *does* affect rather than what it does not affect. The modifications to the remote target discussed in this draft are indeed about *dialog* state, which affects other usages. But the *issues* about the remote target change are only applicable to INVITE, because only it can use provisional responses. The update of remote and local targets in other (i.e. subscribe) usages is straightforward. You mention p-called-party, to which one might add p-asserted-id, p-preferred-id, etc. Its not at all clear to me whether those are even intended to be stateful. If they are, then they are dialog state, not invite-usage state. Thanks, Paul From adam@nostrum.com Tue Jul 13 12:22:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A694F3A6826 for ; Tue, 13 Jul 2010 12:22:14 -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=[AWL=0.000, 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 bbt8upRJnYhw for ; Tue, 13 Jul 2010 12:22:14 -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 9D7113A68DF for ; Tue, 13 Jul 2010 12:22:13 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-149-233.dsl.rcsntx.swbell.net [70.249.149.233]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6DJLo51000238 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jul 2010 14:21:51 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C3CBCCE.7010502@nostrum.com> Date: Tue, 13 Jul 2010 14:21:50 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 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: 70.249.149.233 is authenticated by a trusted mechanism) Cc: "sipcore-chairs@tools.ietf.org" , Robert Sparks Subject: [sipcore] SIPCORE Preliminary Agenda X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list Reply-To: "sipcore-chairs@tools.ietf.org" List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2010 19:22:14 -0000 [as chair] We have posted a preliminary agenda for the upcoming face-to-face SIPCORE meeting in Maastrict: http://www.ietf.org/proceedings/78/agenda/sipcore.html Please provide any comments or feedback on the proposed agenda by Friday. Thanks. /a From rjsparks@nostrum.com Tue Jul 13 14:23:09 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86F0F3A6800 for ; Tue, 13 Jul 2010 14:23:09 -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 UnPRQ3mP25o7 for ; Tue, 13 Jul 2010 14:23:08 -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 B43EF3A6833 for ; Tue, 13 Jul 2010 14:23:07 -0700 (PDT) Received: from [172.16.3.177] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6DLNBju024419 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Jul 2010 16:23:12 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: <4C3BCEFB.5010201@nostrum.com> Date: Tue, 13 Jul 2010 16:23:11 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <739E9B6D-24B5-4A45-9BC7-0387BFB5CF32@nostrum.com> References: <99619466-573D-4CEA-ACCD-3A3D262EB2B0@nostrum.com> <4C3BCEFB.5010201@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1081) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-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, 13 Jul 2010 21:23:09 -0000 I don't think it's as clear-cut as that. 4662 used the extension points 3265 expected to be used. Someone that = had written a network monitor, for example, just using 3265 for reference could have produced code that made sense out of a = stream of messages emitted by implementations of 4662. That same code would probably not do the right thing with a stream of = messages from this spec - at the very least, it wouldn't know to be looking for Event headers in 200 responses - that's what makes = this new, and potentially a change to the base specification. What does 3265bis say about Event headers in responses to NOTIFYs at the = moment? RjS On Jul 12, 2010, at 9:27 PM, Adam Roach wrote: > [as participant and RFC3265 expert] >=20 > On 7/12/10 19:13, Jul 12, krisztian.kiss@nokia.com wrote: >> Major question: >>=20 >> Why isn't this an Update to 3265? >>=20 >> [KK] It's an extension to 3265. Implementations of 3265 not = interested in rate control don't need to implement it. If people think = it's an essential part of event-notifications, we could make it as an = update of 3265. Any recommendations? >=20 > To be clear, these kinds of extensions haven't historically been = considered "updates" to 3265 -- at least, in terms of the RFC "updates" = terminology. Probably the closest parallel is RFC 4662 (another = cross-package extension), which was not considered to be an update to = 3265. >=20 > So I think it's appropriate to consider this an extension (which we = have not traditionally considered an "update"), rather than a formal = update. >=20 > /a From rjsparks@nostrum.com Tue Jul 13 14:33:29 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BAAAB3A6814 for ; Tue, 13 Jul 2010 14:33:29 -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 jzq-NCQODJG8 for ; Tue, 13 Jul 2010 14: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 EB90D3A69FF for ; Tue, 13 Jul 2010 14:33:19 -0700 (PDT) Received: from [172.16.3.177] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6DLXRMd070376 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Jul 2010 16:33:28 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Robert Sparks In-Reply-To: Date: Tue, 13 Jul 2010 16:33:27 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <99619466-573D-4CEA-ACCD-3A3D262EB2B0@nostrum.com> To: krisztian.kiss@nokia.com X-Mailer: Apple Mail (2.1081) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-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, 13 Jul 2010 21:33:30 -0000 inline: On Jul 12, 2010, at 7:13 PM, krisztian.kiss@nokia.com wrote: > Hi Robert, >=20 > I submitted the -04 version today addressing your comments: = http://www.ietf.org/id/draft-ietf-sipcore-event-rate-control-04.txt=20 >=20 > Please find my answers in-line with [KK]: >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On = Behalf Of ext Robert Sparks > Sent: 2010. j=FAnius 10. 13:14 > To: SIPCORE > Subject: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-03 >=20 > Summary: This draft has a few adjustments that are needed before = moving it into IETF Last Call. >=20 > Major question: >=20 > Why isn't this an Update to 3265?=20 >=20 > [KK] It's an extension to 3265. Implementations of 3265 not interested = in rate control don't need to implement it. If people think it's an = essential part of event-notifications, we could make it as an update of = 3265. Any recommendations? We have a separate thread going for this one. >=20 > Is there text here that prevents a subscriber > from generating Event headers in 200 OKs to NOTIFYs mid-subscription = (when he > didn't probe for support using the SUBSCRIBE?) How would they know the = request > got honored? The possibility of running into implementations that = break should > be called out. =20 >=20 > [KK] I added text in -04 to address this:=20 > Section 4.1: "If the Event header field of the SUBSCRIBE request did = not include the "min-interval" parameter, the subscriber MUST NOT = include an initial value of the "min-interval" Event header field = parameter in a 200-class response to the NOTIFY request."=20 > Section 4.2: "If the Event header field of the SUBSCRIBE request did = not include the "min-interval" parameter, the notifier MUST ignore an = initial value of the "min-interval" Event header field parameter in a = 200-class response to the NOTIFY request, if present." > ...and similar text covering max-interval and average-interval = mechanisms. So, which SUBSCRIBE? I think you mean the most recent SUBSCRIBE request = received on this dialog (and not just the initial SUBSCRIBE)? >=20 > 4.2 indicates the subscriber only gets a "hint" about support > for rate-control in the notifier - is the condition it describes = really only a > hint? >=20 > [KK] Replaced "serves as a hint" with "indicates". >=20 > In several places, the notifier is given permission to adjust an = interval based > on local policy. The document should be explicit about allowing the = adjustment > in any direction (increasing or decreasing) since there are so many = other uses > of intervals in SIP and SIP Events that allow adjustment only in one = direction. > A few places I noted when reading the document were the Note in REQ7, = 4.3 4th > paragraph, 5.2 paragraph 3, 6.2 paragraph 3. >=20 > [KK] I spelled out the possibility of increasing and decreasing at all = of these sections you referenced. >=20 > The last paragraph of section 3.6 claims "exactly the same properties" = except > for being generated constrained to a schedule. Can you clarify which = properties > you mean? Many properties of the notifications beside their timing are = clearly > different (for instance, you may miss state transitions). >=20 > [KK] I just deleted that sentence, there was no real added value in = it. >=20 > The security considerations section deserves more text:=20 > * What is the forward reference from section 3.4 supposed to be = pointing to? >=20 > [KK] Deleted. >=20 > * Call out the implications on a Notifier having to store/aggregate = partial state >=20 > [KK] I added a reference to the security considerations listed in RFC = 5263 (partial notifications). >=20 > * Note that the Event header (particularly in 200 OKs) is not = integrity protected.=20 > This would allow anything that could modify the message in flight (or = an=20 > eavesdropper that could race a 200 OK in) to suppress (or flood) = notifications=20 > without the subscriber seeing what caused it. >=20 > [KK] I added a new paragraph on this: > "RFC 3265 [RFC3265] recommends the integrity protection of the Event = header field of SUBSCRIBE requests. Implementations of this extension = SHOULD also provide integrity protection for the Event header field = included in the 200-class response to the NOTIFY request." I would still call out the attacks that are possible when it isn't = integrity protected. > =09 > The assertion that applying rate limiting and compression together = results in > savings as good as the sum of applying them independently should be = supported > or adjusted. I think it's sufficient to say they can be applied = together. >=20 > [KK] OK, so no changes needed, right? No, not OK. I think you misunderstood my comment. You should either add text justifying the claim, or change the text. I = propose above to change the text to simply say they can be applied together and not make an unsupported = claim about the savings being as good as the sum of applying them together. >=20 > Below are several suggestions for text tweaks. The first few (staring = with *) > are the most important.=20 >=20 > * Section 3.2 paragraph 4: suggest replacing "does not typically" with = "may not" >=20 > [KK] Fixed. >=20 > * Section 3.2 last paragraph: The sentence 'The "max-interval" = parameter=20 > indicates ... complete state information' is difficult to parse. = Could it > be simplified? >=20 > [KK] Done. >=20 > * Section 4.3 first paragraph, last sentence: "For such cases" is = ambiguous. > Suggest "If the min-interval value is greater than the subscription = expiry". >=20 > [KK]. Done. Re-wrote as: "If the subscription expiry is shortened = during an active subscription,..." >=20 > * Section 6.2 last paragraph: This currently says the timeout = mechanism does > not affect when 3261 transaction retransmissions are generated. It = should > also explicitly note that retransmissions do not affect the = calculation of > the next timeout. >=20 > [KK]. Fixed by extending the definition of "count": =20 > "count: The number of notifications that have been sent during the = last "period" of seconds ***not including any retransmissions of = requests***." New text is between *** marks. >=20 > Introduction, paragraph 2: suggest replacing "congestion" with "load" >=20 > [KK] Fixed. >=20 > Section 3.1 paragraph 3: suggest replacing "amount of traffic" with=20= > "number of notifications" >=20 > [KK] Fixed. >=20 > Section 3.5 paragraph 1: Suggest a reference for RLS after "list = subscription". >=20 > [KK] Fixed. >=20 > The sentence "Moreover, the list event notifier..." should be more = explicit > about using the rate mechanism for any back-end subscriptions it might = have. >=20 > [KK] Fixed. >=20 > Suggest referencing 3261 in the last paragraph of 4.2 >=20 > [KK] Fixed. Same applies to section 6.2. >=20 > Section 4.3, 3rd paragraph last sentence. The only way the subscriber = _can_ > resume notifications is to renew the subscription with a resubscribe = request. > Would this text work? "This results in receiving no further = notifications until > the subscription expires or the subscriber sends a SUBSCRIBE request = refreshing > the subscription (perhaps resuming notifications)". >=20 > [KK] Fixed as "or the subscriber sends a SUBSCRIBE request resuming = notifications." >=20 > The text needs to be adjusted to reflect subnot-etags being issued as = an RFC >=20 > [KK] Fixed throughout the document. >=20 > Adam suggested some RFC-Editor notes in the proto writeup (which may = address > some of the above comments). Please be sure to incorporate those when = revising > the draft. >=20 > [KK] Done. Fixed the text for subnot-etags references throughout the = document. >=20 > One last question: >=20 > If the combination of min-interval, max-interval, and average-interval = make > little sense, why does the document allow them to be combined? I think = what the > group was trying to say is that we currently don't forsee a use for = combining > those options, but do not wish to forbid their combination. >=20 > [KK] Fixed as "this combination makes little sense to be used although = not forbidden". Recommendations added on choosing the right values = similarly to previous options for combinations. >=20 >=20 > Thanks, > Krisztian >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From adam@nostrum.com Tue Jul 13 15:18:43 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B93AF3A69F1 for ; Tue, 13 Jul 2010 15:18:43 -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=[AWL=0.000, 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 dlKiLdJHu0oD for ; Tue, 13 Jul 2010 15:18:43 -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 A25493A69E5 for ; Tue, 13 Jul 2010 15:18:42 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-149-233.dsl.rcsntx.swbell.net [70.249.149.233]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6DMInrR093518 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 13 Jul 2010 17:18:50 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C3CE649.1060309@nostrum.com> Date: Tue, 13 Jul 2010 17:18:49 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Robert Sparks References: <99619466-573D-4CEA-ACCD-3A3D262EB2B0@nostrum.com> <4C3BCEFB.5010201@nostrum.com> <739E9B6D-24B5-4A45-9BC7-0387BFB5CF32@nostrum.com> In-Reply-To: <739E9B6D-24B5-4A45-9BC7-0387BFB5CF32@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.149.233 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-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, 13 Jul 2010 22:18:43 -0000 On 7/13/10 16:23, Jul 13, Robert Sparks wrote: > I don't think it's as clear-cut as that. > > 4662 used the extension points 3265 expected to be used. Not any more than anything else. The extension points that 3265 defines are new event packages. 4662 uses feature tags to negotiate usage -- a basic SIP extension mechanism. Event-rate-control uses new header field parameters -- another basic SIP extension mechanism. > Someone that had written a network monitor, for example, just using > 3265 for reference could have produced code that made sense out of a stream of messages emitted by implementations of 4662. > > That same code would probably not do the right thing with a stream of messages from this spec I can't imagine why not. It will look like a stream of state information sent in NOTIFY messages. I also don't have a lot of sympathy for the "network monitor" use case as a motivator unless we're going to explicitly deprecate TLS and S/MIME. > - at the very least, it wouldn't know to be looking for Event headers in 200 responses No, and it won't know to care about them either. Which is exactly the right thing to do reaction. The event header fields in responses are there as a syntactic concession -- we needed somewhere to hang the parameters. The actual event name itself can't change. It can be safely ignored by network monitors, and they'll do the right thing. > What does 3265bis say about Event headers in responses to NOTIFYs at the moment? Nothing yet. I have a note to add text addressing this case (as well as the suppressed NOTIFY situation that arises from subnot-etags). /a From rjsparks@nostrum.com Tue Jul 13 15:22:46 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 372F73A67E5 for ; Tue, 13 Jul 2010 15:22:46 -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 JCXpgAnEwzlP for ; Tue, 13 Jul 2010 15:22:45 -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 EB42F3A67D1 for ; Tue, 13 Jul 2010 15:22:44 -0700 (PDT) Received: from [172.16.3.177] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6DMMrR2093872 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 13 Jul 2010 17:22:53 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: Date: Tue, 13 Jul 2010 17:22:52 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: References: <99619466-573D-4CEA-ACCD-3A3D262EB2B0@nostrum.com> To: krisztian.kiss@nokia.com X-Mailer: Apple Mail (2.1081) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-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, 13 Jul 2010 22:22:46 -0000 A couple more observations inline (and I'm trimming away things I'm not = replying to here): On Jul 12, 2010, at 7:13 PM, krisztian.kiss@nokia.com wrote: > Hi Robert, >=20 > I submitted the -04 version today addressing your comments: = http://www.ietf.org/id/draft-ietf-sipcore-event-rate-control-04.txt=20 >=20 > Please find my answers in-line with [KK]: >=20 > Is there text here that prevents a subscriber > from generating Event headers in 200 OKs to NOTIFYs mid-subscription = (when he > didn't probe for support using the SUBSCRIBE?) How would they know the = request > got honored? The possibility of running into implementations that = break should > be called out. =20 >=20 > [KK] I added text in -04 to address this:=20 > Section 4.1: "If the Event header field of the SUBSCRIBE request did = not include the "min-interval" parameter, the subscriber MUST NOT = include an initial value of the "min-interval" Event header field = parameter in a 200-class response to the NOTIFY request."=20 > Section 4.2: "If the Event header field of the SUBSCRIBE request did = not include the "min-interval" parameter, the notifier MUST ignore an = initial value of the "min-interval" Event header field parameter in a = 200-class response to the NOTIFY request, if present." > ...and similar text covering max-interval and average-interval = mechanisms. These changes (and the associated changes in 5.1, 5.2, 6.1, and 6.2) are = too granular and introduce the possibility of edge cases I don't think = we should introduce. It would be much simpler to say: =20 If the subscriber did not include at least one of the "min-interval, = "max-interval", or "average-interval" header field parameters in the = most recent SUBSCRIBE request in a given dialog, it MUST NOT include an = Event header field with any of those parameters in a 200 OK to a NOTIFY = in that dialog. >=20 > * Section 3.2 last paragraph: The sentence 'The "max-interval" = parameter=20 > indicates ... complete state information' is difficult to parse. = Could it > be simplified? The new sentence you propose is even harder for me to read. Here's some suggested text: The "max-interval" parameter indicates to the notifier the maximum = amount of time that should be allowed to elapse between NOTIFY requests = containing complete state information. RjS From Martin.Thomson@andrew.com Tue Jul 13 17:07:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8CC533A68D4 for ; Tue, 13 Jul 2010 17:07:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.469 X-Spam-Level: X-Spam-Status: No, score=-1.469 tagged_above=-999 required=5 tests=[AWL=-1.329, BAYES_20=-0.74, J_CHICKENPOX_43=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 l1YXQcCdRDx5 for ; Tue, 13 Jul 2010 17:07:29 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 2AE093A6896 for ; Tue, 13 Jul 2010 17:07:29 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:36779 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S27563160Ab0GNAHi (ORCPT ); Tue, 13 Jul 2010 19:07:38 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 13 Jul 2010 19:07:37 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Wed, 14 Jul 2010 08:07:33 +0800 From: "Thomson, Martin" To: "James M. Polk" , "sipcore@ietf.org" Date: Wed, 14 Jul 2010 08:09:39 +0800 Thread-Topic: [sipcore] location-conveyance-03 just submitted Thread-Index: AcsiVMw6WuAjuKc6RYuOSENQnOL1nQAjOQUw Message-ID: <8B0A9FCBB9832F43971E38010638454F03E9DCD0D7@SISPE7MB1.commscope.com> References: <201007122355.o6CNt6us024310@sj-core-3.cisco.com> <8B0A9FCBB9832F43971E38010638454F03E9DCCFFC@SISPE7MB1.commscope.com> <201007130629.o6D6Tk7F028645@sj-core-2.cisco.com> In-Reply-To: <201007130629.o6D6Tk7F028645@sj-core-2.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] location-conveyance-03 just 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: Wed, 14 Jul 2010 00:07:30 -0000 SGkgSmFtZXMsDQoNCkxvb2tzIGxpa2Ugd2UndmUgZ290IG1vc3Qgb2YgdGhlIGJpZyBzdHVmZiBv dXQgb2YgdGhlIHdheS4NCg0KPiA+Q29udGVudCBpbmRpcmVjdGlvbiBoYXMgc29tZSBpbnRlcmVz dGluZyBiZW5lZml0cy4gIEl0J3MgYSBnb29kIGlkZWEuDQo+IA0KPiBpdCBoYXMgYWx3YXlzIGJl ZW4gaW4gQ29udmV5YW5jZSwgYnV0IG1pZ2h0IGhhdmUgYmVlbiBsb3N0IGluIHRoZQ0KPiBjbHV0 dGVyLg0KDQpUaGUgNDQ4MyByZWZlcmVuY2Ugd2FzIGxlc3MgZXhwbGljaXQgdGhhbiB5b3VyIG5l dyBTZWN0aW9uIDQuNS4NCg0KSmFtZXMgKFcpIGFuZCBJIGhhdmUgYmVlbiBkaXNjdXNzaW5nIHRo ZSBpbXBsaWNhdGlvbnMgb2YgdGhpcywgYW5kIHRoZXJlIGlzIG9uZSBub3RlIHRoYXQgbWlnaHQg bmVlZCByZXZpc2l0aW5nIGluIGxpZ2h0IG9mIHRoaXMuDQoNClRoZSBtZWNoYW5pc20gZm9yIGxv Y2F0aW9uIGJ5IHJlZmVyZW5jZSByZXF1aXJlcyBhY2Nlc3MgdG8gcmVxdWVzdCBib2RpZXMuICBG b3IgaW50ZXJtZWRpYXJpZXMsIHRoaXMgaXMgT0ssIGJlY2F1c2Ugb2YgdGhlIG5ldyBtZWNoYW5p c20gdGhhdCB5b3UgaGF2ZSBkZXZlbG9wZWQuICBIb3dldmVyLCB0aGUgZm9sbG93aW5nIHRleHQg aW4gU2VjdGlvbiA0LjEgaXMgcHJvYmFibHkgbm93IG91dCBvZiBkYXRlOg0KDQogICBBIFNJUCBp bnRlcm1lZGlhcnkgTUFZIGFkZCBhIEdlb2xvY2F0aW9uIGhlYWRlciBmaWVsZCBpZiBvbmUgaXMg bm90DQogICBwcmVzZW50IC0gZm9yIGV4YW1wbGUsIHdoZW4gYSB1c2VyIGFnZW50IGRvZXMgbm90 IHN1cHBvcnQgdGhlDQogICBHZW9sb2NhdGlvbiBtZWNoYW5pc20gYnV0IHRoZWlyIG91dGJvdW5k IHByb3h5IGRvZXMgYW5kIGtub3dzIHRoZWlyDQogICBMb2NhdGlvbi4uLg0KIA0KPiA+SSBoYXZl IHNvbWUgY29tbWVudHMgdGhhdCBpbmNsdWRlcyBvbmUgbWFqb3IgaXNzdWUuDQo+ID4NCj4gPlRo ZSBtYWpvciBpc3N1ZToNCj4gPg0KPiA+VGhlIGxpbWl0YXRpb24gdG8gX29uZV8gbG9jYXRpb24g dmFsdWUgaGFzDQo+ID51bmRlbmlhYmxlIGJlbmVmaXRzLiAgSXQgYWxzbyBwcmV2ZW50cyB0aGUN Cj4gPmNvbnZleWFuY2Ugb2YgbG9jYXRpb24gdmFsdWUgYW5kIHJlZmVyZW5jZSB0b2dldGhlci4N Ci4uLg0KPiA+Sm9uJ3Mgb3JpZ2luYWwgcmVzcG9uc2UgdG8gdGhpcyB3YXMgdG8gcHVzaCB0aGUN Cj4gPmNvbXBvc2l0aW9uIHByb2JsZW0gdG8gdGhlIFBJREYtTE8uICBUaGF0IGNvdWxkIGJlIGRv bmUsDQo+IA0KPiB0aGF0IGlzIHdoYXQncyBkb25lLCB0aGVyZSBpcyBubyAnY291bGQnLiBUaGUN Cj4gdGV4dCBzdXJyb3VuZGluZyBGaWd1cmUgNCBzdGF0ZXMgdGhpcywgYW5kIHRoZQ0KPiBleGFt cGxlIGluIDUuMiBleHBsYWlucyB0aGlzIGlzIHRoZSBleGFtcGxlDQo+IGFsYmVpdCBzaG93aW5n IHR3byBjb21wb3NlZCB2YWx1ZXMgZnJvbSBkaWZmZXJlbnQgc291cmNlcy4NCg0KVGhlIGNvbXBv c2l0aW9uIHNjZW5hcmlvIGlzIGEgdmFsaWQgb25lLCBidXQgaXQgc3RpbGwgaGFzIHRoZSBpbmhl cmVudCBsaW1pdGF0aW9ucyBvZiBsb2NhdGlvbiBieSB2YWx1ZSAtIHlvdSBjYW4ndCBnZXQgdXBk YXRlcy4NCg0KVGhlIHVzZSBjYXNlIGlzIGJhc2ljYWxseTogcm91dGUgYmFzZWQgb24gdGhlIHZh bHVlLCBidXQgcHJvdmlkZSBhIHJlZmVyZW5jZSBzbyB0aGF0IGEgUFNBUCBjYW4gZ2V0IGJldHRl ciBsb2NhdGlvbiBpbmZvcm1hdGlvbiBsYXRlcjsgdGhhdCBpcywgdXBkYXRlZCBvciBtb3JlIGFj Y3VyYXRlIGxvY2F0aW9uLiAgVGhhdCdzIG5vdCBwb3NzaWJsZSBpZiB0aGUgVUFDIGRvZXMgdGhl IGRlcmVmZXJlbmNlOiB0aGUgbG9jYXRpb24gaW5mb3JtYXRpb24gYmVjb21lcyBmaXhlZC4NCg0K VGhlcmUgYXJlIG11bHRpcGxlIHdheXMgdG8gYWRkcmVzcyB0aGlzIHByb2JsZW0uICBPbmUgaWRl YSAtIHRoYXQgbWF5IGJlIGEgYmFkIG9uZSwgSSBkb24ndCBrbm93IHlldCAtIGlzIHRvIGFkZCBh IHJlZmVyZW5jZSB0byBhIENvbnRlbnQtTG9jYXRpb24gaGVhZGVyIGluIGNvbWJpbmF0aW9uIHdp dGggdGhlIFBJREYtTE8gdmFsdWUuICBUaGUgb3RoZXIgd2FzIHRvIGFkZCBQSURGIGV4dGVuc2lv bnMgZm9yIGluZGlyZWN0aW9uLg0KDQo+ID5UaGUgc3RydWN0dXJlIG9mIHRoZSBHZW9sb2NhdGlv bi1FcnJvciBoZWFkZXINCj4gPmRlc2NyaXB0aW9uIGlzIGEgbGl0dGxlIG9kZC4gIEl0IHNlZW1z IHRoYXQgeW91DQo+ID5hcmUgdHJ5aW5nIHRvIGRlc2NyaWJlICpjbGFzc2VzKiBvZiBlcnJvciBh bmQNCj4gPnNwZWNpZmljIGVycm9ycyBhdCB0aGUgc2FtZSB0aW1lLiAgU2VwYXJhdGluZw0KPiA+ dGhlc2UgY29uY2VybnMgbWlnaHQgbWFrZSB0aGlzIGVhc2llciB0byBleHBsYWluIGFuZCB1bmRl cnN0YW5kLg0KPiANCj4gdGhlIGVycm9ycyBhcmUgaW4gY2F0ZWdvcmllcywgb2Ygd2hpY2gsIG9u bHkgb25lDQo+IGNhdGVnb3J5IGhhcyBtb3JlIHRoYW4gb25lIGVycm9yIGNvZGUodGhlIDNYWCBj YXRlZ29yeSBhYm91dA0KPiBwZXJtaXNzaW9ucykuDQoNCkkgdW5kZXJzdGFuZCwgbXkgY29uY2Vy biB3YXMgdGhhdCB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIGNsYXNzZXMgZGlkbid0IG1ha2UgaXQg c3VmZmljaWVudGx5IGNsZWFyIHRoYXQgZWFjaCBvZiB0aGUgMXh4LCAyeHggYW5kIDR4eCBjbGFz c2VzIGhhZCBhIHNpbmdsZSBlcnJvciBjb2RlIGluIHRoZW0uICBCeSBjb21iaW5pbmcgdGhlIGRl ZmluaXRpb24gb2YgdGhhdCBzaW5nbGUgZXJyb3IgY29kZSB3aXRoIHRoZSBkZWZpbml0aW9uIG9m IHRoZSBjbGFzcyB0aGF0IGNvbnRhaW5lZCB0aGVtLCBpdCBtYWtlcyBpdCBoYXJkIHRvIGRpc3Rp bmd1aXNoIHdoYXQgZGVzY3JpcHRpb24gYXBwbGllcyB0byBqdXN0IHRoZSBjb2RlLCBhbmQgd2hh dCBhcHBsaWVzIHRvIHRoZSBjbGFzcyBhcyBhIHdob2xlLg0KDQo+ID5UaGUgZHJhZnQgZG9lc27D ouKCrOKEonQgcmVhbGx5IGp1c3RpZnkgdGhlIGV4aXN0ZW5jZQ0KPiA+b2YgdGhlICJnZW9sb2Nh dGlvbiIgb3B0aW9uIHRhZy4NCj4gDQo+IHdoYXQgd291bGQganVzdGlmeSBpdD8NCj4gDQo+IHRo ZSBwdXJwb3NlIG9mIGFuIG9wdGlvbi10YWcgaXMgdGhlIGFiaWxpdHkgdG8NCj4gaW5kaWNhdGUg c3VwcG9ydCBmb3IgYW4gZXh0ZW5zaW9uICh3aGV0aGVyDQo+IG9wdGlvbmFsIG9yIHJlcXVpcmVk KSwgYW5kIHRvIHJlc3BvbmQgd2l0aA0KPiB3aGV0aGVyIG9yIG5vdCBhbiBleHRlbnNpb24gaXMg c3VwcG9ydGVkIG9yDQo+IHVuc3VwcG9ydGVkLiBUaGlzIGluZGljYXRpb24gY2FuIGJlIHF1aXRl DQo+IGltcG9ydGFudCBmb3IgY29tbXVuaWNhdGluZyBTSVAgZWxlbWVudHMgdG8NCj4gdW5kZXJz dGFuZCBzdXBwb3J0IGZvciAob3Igbm90KS4gSSdtIGNvbmZ1c2VkLi4uDQoNCldoeSBpcyBpbmRp Y2F0aW5nIHN1cHBvcnQgZm9yIChvciByZXF1aXJlbWVudCBvZikgdGhpcyBwYXJ0aWN1bGFyIGZl YXR1cmUgaW1wb3J0YW50PyAgSWYgYSBVQUMgaW5jbHVkZXMgdGhlIGhlYWRlciwgaXMgdGhhdCBu b3Qgc3VmZmljaWVudCBpbmRpY2F0aW9uIG9mIHN1cHBvcnQ/ICBXaGF0IHJlYXNvbiBtaWdodCBh IFVBQyBoYXZlIGZvciByZXF1aXJpbmcgdGhhdCB0aGUgVUFTIHN1cHBvcnRzIHRoZSBmZWF0dXJl PyANCg0KT25lIGp1c3RpZmljYXRpb24gZm9yIFN1cHBvcnRlZCBtaWdodCBiZSB0aGF0IGl0IGlz IG5vdCBwb3NzaWJsZSB0byBzZW5kIDQyNCB3aXRob3V0IHNvbWUgcHJpb3IgYWNrbm93bGVkZ2Vt ZW50IHRoYXQgdGhlIGNvZGUgaXMgdW5kZXJzdG9vZCBieSB0aGUgVUFDLiAgVGhhdCBtaWdodCBi ZSBzdWZmaWNpZW50Lg0KDQo+ID5TZWN0aW9uIDUgc2hvdWxkIHNob3cgYW4gZXhhbXBsZSB1c2Ug b2YgY29udGVudA0KPiA+aW5kaXJlY3Rpb24gZm9yIGEgbG9jYXRpb24gVVJJLg0KPiANCj4gSSds bCB0YWxrIHRvIG15IGNvLWF1dGhvcnMgYWJvdXQgdGhpcywgYXMgdGhleQ0KPiBhcmUgdGhlIG9u ZXMgbGltaXRpbmcgdGhlIG51bWJlciBvZiBleGFtcGxlcyAgOy0pDQoNCkp1c3QgYSByZXF1ZXN0 IC0gdGhvdWdoIGl0IHNlZW1lZCBsaWtlIGEgZmFpcmx5IG1ham9yIG9taXNzaW9uLiAgSW4gY29t cGFyaXNvbiAoYW5kIHRoaXMgbWlnaHQganVzdCBiZSBteSBwZXJzcGVjdGl2ZSkgdGhlIGNvbXBv c2l0aW9uIGV4YW1wbGUgc2VlbXMgbGVzcyBzaWduaWZpY2FudC4NCiANCj4gdGhpcyBtaWdodCBi ZSBhIGdvb2QgcG9pbnQuIEknbGwgdGFsayB0byBteQ0KPiBjby1hdXRob3JzIGFib3V0IGJyZWFr aW5nIHVwIHNlY3Rpb24gMyBpbnRvIHN1Yi1zZWN0aW9ucyAoMSBwZXINCj4gRmlndXJlKS4NCg0K VGhhdCB3b3VsZCBoZWxwIGEgbG90LCBJIHRoaW5rLiAgVGhhbmtzLg0KDQo+ID5UaGUgZXhhbXBs ZXMgaW4gU2VjdGlvbiA1IGFyZSBub3Qgc2NoZW1hLXZhbGlkDQo+IA0KPiB0aGlzIGlzIHF1aXRl IHBvc3NpYmxlLiBUaGlzIHdhcyBhIGJpdCBjb2JibGVkIHRvZ2V0aGVyLg0KDQpUaGV5IHdlcmUg YWxtb3N0IHBlcmZlY3QuICBJJ3ZlIGNvcnJlY3RlZCB0aGUgdHdvIGV4YW1wbGVzIGFuZCBhZGRl ZCB0aGVtIHRvIHRoZSBib3R0b20gb2YgdGhpcyBlbWFpbC4gIEkndmUgdmFsaWRhdGVkIHRoZXNl IGFuZCBtYWRlIHN1cmUgdGhhdCB0aGV5IGRvbid0IGhhdmUgZXhjZXNzaXZlbHkgbG9uZyBsaW5l cyA6KQ0KDQo+ID4iYmxhY2sgcGhvbmUiIGlzIGEgbGl0dGxlIGphcmdvbi15Lg0KPiANCj4gaXQn cyBjZXJ0YWlubHkga25vd24gaW5zaWRlIHRoZSB2b2ljZS90ZWxlcGhvbnkgd29ybGQuDQoNClN1 cmUuICBUaGF0IGRvZXNuJ3QgbWFrZSBpdCBhbnkgbGVzcyBqYXJnb24teSB0aG91Z2guDQoNCj4g Pk1vcmUgYW11c2luZyB3YXMgdGhlIGlkZWEgdGhhdCB5b3VyDQo+ID5jaGFyYWN0ZXJpc2F0aW9u IG9mIGEgcGVyc29uIHdhcyBhcyBhICJub24tSVAgZGV2aWNlIi4NCj4gDQo+IG1hbnkgcmVhZGVy cyBtaXN1bmRlcnN0YW5kIHdoZW4gdGFsa2luZyBhYm91dA0KPiBBbGljZSwgaXQncyBvbmUgb2Yg aGVyIGVsZWN0cm9uaWMgZGV2aWNlcyB0aGF0DQo+IFNJUCBjb21tdW5pY2F0ZXMgd2l0aCwgbm90 IGhlciBkaXJlY3RseS4NCg0KVGhhdCdzIGFuIGltcG9ydGFudCBkaXN0aW5jdGlvbiwgYnV0IG5v dCBvbmUgdGhhdCBJIHdvdWxkIGhhdmUgaW5mZXJyZWQgZnJvbSB0aGUgdGV4dC4gIFBlcmhhcHMg eW91IG1lYW50IHRvIHNheTogIm5vbi1JUCBkZXZpY2UgKGEgcGVyc29uYWwgZGV2aWNlIHN1Y2gg YXMgYSBibGFjayBwaG9uZSkiLg0KDQo+IFRoYW5rcyBmb3IgcmVhZGluZyB0aGlzIHNvIHF1aWNr bHkgYW5kIHByb3ZpZGluZyBjb21tZW50cyAoc2VyaW91c2x5KQ0KDQpUaGFua3MgZm9yIGJlaW5n IHJlc3BvbnNpdmUgaW4gcmV0dXJuIDopDQoNCiANCj4gSmFtZXMNCj4gDQo+IA0KPiA+LS1NYXJ0 aW4NCg0KRXhhbXBsZSBmcm9tIDUuMToNCg0KICA8cHJlc2VuY2UNCiAgICAgIHhtbG5zPSJ1cm46 aWV0ZjpwYXJhbXM6eG1sOm5zOnBpZGYiDQogICAgICB4bWxuczpncD0idXJuOmlldGY6cGFyYW1z OnhtbDpuczpwaWRmOmdlb3ByaXYxMCINCiAgICAgIHhtbG5zOmdicD0idXJuOmlldGY6cGFyYW1z OnhtbDpuczpwaWRmOmdlb3ByaXYxMDpiYXNpY1BvbGljeSINCiAgICAgIHhtbG5zOmNsPSJ1cm46 aWV0ZjpwYXJhbXM6eG1sOm5zOnBpZGY6Z2VvcHJpdjEwOmNpdmljQWRkciINCiAgICAgIHhtbG5z OmdtbD0iaHR0cDovL3d3dy5vcGVuZ2lzLm5ldC9nbWwiDQogICAgICB4bWxuczpkbT0idXJuOmll dGY6cGFyYW1zOnhtbDpuczpwaWRmOmRhdGEtbW9kZWwiDQogICAgICBlbnRpdHk9InByZXM6YWxp Y2VAYXRsYW50YS5leGFtcGxlLmNvbSI+DQogICAgPGRtOmRldmljZSBpZD0idGFyZ2V0MTIzLTEi Pg0KICAgICAgPGdwOmdlb3ByaXY+DQogICAgICAgIDxncDpsb2NhdGlvbi1pbmZvPg0KICAgICAg ICAgIDxnbWw6bG9jYXRpb24+DQogICAgICAgICAgICA8Z21sOlBvaW50IHNyc05hbWU9InVybjpv Z2M6ZGVmOmNyczpFUFNHOjo0MzI2Ij4NCiAgICAgICAgICAgICAgPGdtbDpwb3M+MzIuODY3MjYg LTk3LjE2MDU0PC9nbWw6cG9zPg0KICAgICAgICAgICAgPC9nbWw6UG9pbnQ+DQogICAgICAgICAg PC9nbWw6bG9jYXRpb24+DQogICAgICAgIDwvZ3A6bG9jYXRpb24taW5mbz4NCiAgICAgICAgPGdw OnVzYWdlLXJ1bGVzPg0KICAgICAgICAgIDxnYnA6cmV0cmFuc21pc3Npb24tYWxsb3dlZD5mYWxz ZQ0KICAgICAgICAgIDwvZ2JwOnJldHJhbnNtaXNzaW9uLWFsbG93ZWQ+DQogICAgICAgICAgPGdi cDpyZXRlbnRpb24tZXhwaXJ5PjIwMTAtMDctMzBUMjA6MDA6MDBaDQogICAgICAgICAgPC9nYnA6 cmV0ZW50aW9uLWV4cGlyeT4NCiAgICAgICAgPC9ncDp1c2FnZS1ydWxlcz4NCiAgICAgICAgPGdw Om1ldGhvZD44MDIuMTE8L2dwOm1ldGhvZD4NCiAgICAgIDwvZ3A6Z2VvcHJpdj4NCiAgICAgIDxk bTpkZXZpY2VJRD5tYWM6MTIzNDU2Nzg5MGFiPC9kbTpkZXZpY2VJRD4NCiAgICAgIDxkbTp0aW1l c3RhbXA+MjAxMC0wNy0yOFQyMDo1NzoyOVo8L2RtOnRpbWVzdGFtcD4NCiAgICA8L2RtOmRldmlj ZT4NCiAgPC9wcmVzZW5jZT4NCg0KRXhhbXBsZSA1LjI6DQoNCiAgPHByZXNlbmNlDQogICAgICB4 bWxucz0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpwaWRmIg0KICAgICAgeG1sbnM6Z3A9InVybjpp ZXRmOnBhcmFtczp4bWw6bnM6cGlkZjpnZW9wcml2MTAiDQogICAgICB4bWxuczpnYnA9InVybjpp ZXRmOnBhcmFtczp4bWw6bnM6cGlkZjpnZW9wcml2MTA6YmFzaWNQb2xpY3kiDQogICAgICB4bWxu czpkbT0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpwaWRmOmRhdGEtbW9kZWwiDQogICAgICB4bWxu czpjbD0idXJuOmlldGY6cGFyYW1zOnhtbDpuczpwaWRmOmdlb3ByaXYxMDpjaXZpY0FkZHIiDQog ICAgICB4bWxuczpnbWw9Imh0dHA6Ly93d3cub3Blbmdpcy5uZXQvZ21sIg0KICAgICAgZW50aXR5 PSJwcmVzOmFsaWNlQGF0bGFudGEuZXhhbXBsZS5jb20iPg0KICAgIDxkbTpkZXZpY2UgaWQ9InRh cmdldDEyMy0xIj4NCiAgICAgIDxncDpnZW9wcml2Pg0KICAgICAgICA8Z3A6bG9jYXRpb24taW5m bz4NCiAgICAgICAgICA8Z21sOmxvY2F0aW9uPg0KICAgICAgICAgICAgPGdtbDpQb2ludCBzcnNO YW1lPSJ1cm46b2djOmRlZjpjcnM6RVBTRzo6NDMyNiI+DQogICAgICAgICAgICAgIDxnbWw6cG9z PjMyLjg2NzI2IC05Ny4xNjA1NDwvZ21sOnBvcz4NCiAgICAgICAgICAgIDwvZ21sOlBvaW50Pg0K ICAgICAgICAgIDwvZ21sOmxvY2F0aW9uPg0KICAgICAgICA8L2dwOmxvY2F0aW9uLWluZm8+DQog ICAgICAgIDxncDp1c2FnZS1ydWxlcz4NCiAgICAgICAgICA8Z2JwOnJldHJhbnNtaXNzaW9uLWFs bG93ZWQ+ZmFsc2UNCiAgICAgICAgICA8L2dicDpyZXRyYW5zbWlzc2lvbi1hbGxvd2VkPg0KICAg ICAgICAgIDxnYnA6cmV0ZW50aW9uLWV4cGlyeT4yMDEwLTA3LTMwVDIwOjAwOjAwWg0KICAgICAg ICAgIDwvZ2JwOnJldGVudGlvbi1leHBpcnk+DQogICAgICAgIDwvZ3A6dXNhZ2UtcnVsZXM+DQog ICAgICAgIDxncDptZXRob2Q+ODAyLjExPC9ncDptZXRob2Q+DQogICAgICA8L2dwOmdlb3ByaXY+ DQogICAgICA8ZG06ZGV2aWNlSUQ+bWFjOjEyMzQ1Njc4OTBhYjwvZG06ZGV2aWNlSUQ+DQogICAg ICA8ZG06dGltZXN0YW1wPjIwMTAtMDctMjhUMjA6NTc6MjlaPC9kbTp0aW1lc3RhbXA+DQogICAg PC9kbTpkZXZpY2U+DQogICAgPGRtOnBlcnNvbiBpZD0idGFyZ2V0MTIzIj4NCiAgICAgIDxncDpn ZW9wcml2Pg0KICAgICAgICA8Z3A6bG9jYXRpb24taW5mbz4NCiAgICAgICAgICA8Y2w6Y2l2aWNB ZGRyZXNzPg0KICAgICAgICAgICAgPGNsOmNvdW50cnk+VVM8L2NsOmNvdW50cnk+DQogICAgICAg ICAgICA8Y2w6QTE+VGV4YXM8L2NsOkExPg0KICAgICAgICAgICAgPGNsOkEzPkNvbGxleXZpbGxl PC9jbDpBMz4NCiAgICAgICAgICAgIDxjbDpSRD5UcmVlbW9udDwvY2w6UkQ+DQogICAgICAgICAg ICA8Y2w6U1RTPkNpcmNsZTwvY2w6U1RTPg0KICAgICAgICAgICAgPGNsOkhOTz4zOTEzPC9jbDpI Tk8+DQogICAgICAgICAgICA8Y2w6RkxSPjE8L2NsOkZMUj4NCiAgICAgICAgICAgIDxjbDpOQU0+ SGFsZXkncyBQbGFjZTwvY2w6TkFNPg0KICAgICAgICAgICAgPGNsOlBDPjc2MDM0PC9jbDpQQz4N CiAgICAgICAgICA8L2NsOmNpdmljQWRkcmVzcz4NCiAgICAgICAgPC9ncDpsb2NhdGlvbi1pbmZv Pg0KICAgICAgICA8Z3A6dXNhZ2UtcnVsZXM+DQogICAgICAgICAgPGdicDpyZXRyYW5zbWlzc2lv bi1hbGxvd2VkPmZhbHNlDQogICAgICAgICAgPC9nYnA6cmV0cmFuc21pc3Npb24tYWxsb3dlZD4N CiAgICAgICAgICA8Z2JwOnJldGVudGlvbi1leHBpcnk+MjAxMC0wNy0zMFQyMDowMDowMFoNCiAg ICAgICAgICA8L2dicDpyZXRlbnRpb24tZXhwaXJ5Pg0KICAgICAgICA8L2dwOnVzYWdlLXJ1bGVz Pg0KICAgICAgICA8Z3A6bWV0aG9kPnRyaWFuZ3VsYXRpb248L2dwOm1ldGhvZD4NCiAgICAgIDwv Z3A6Z2VvcHJpdj4NCiAgICAgIDxkbTp0aW1lc3RhbXA+MjAxMC0wNy0yOFQxMjoyODowNFo8L2Rt OnRpbWVzdGFtcD4NCiAgICA8L2RtOnBlcnNvbj4NCiAgPC9wcmVzZW5jZT4NCg== From jmpolk@cisco.com Tue Jul 13 19:00:57 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1F5E03A68AE for ; Tue, 13 Jul 2010 19:00:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.327 X-Spam-Level: X-Spam-Status: No, score=-9.327 tagged_above=-999 required=5 tests=[AWL=-1.187, BAYES_20=-0.74, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EHi2-Gldp-0S for ; Tue, 13 Jul 2010 19:00:55 -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 210283A6872 for ; Tue, 13 Jul 2010 19:00:55 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,199,1278288000"; d="scan'208";a="158020884" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 14 Jul 2010 02:01:04 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6E2138L023850; Wed, 14 Jul 2010 02:01:04 GMT Message-Id: <201007140201.o6E2138L023850@sj-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 13 Jul 2010 21:01:03 -0500 To: "Thomson, Martin" , "James M. Polk" , "sipcore@ietf.org" From: "James M. Polk" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E9DCD0D7@SISPE7MB1.comms cope.com> References: <201007122355.o6CNt6us024310@sj-core-3.cisco.com> <8B0A9FCBB9832F43971E38010638454F03E9DCCFFC@SISPE7MB1.commscope.com> <201007130629.o6D6Tk7F028645@sj-core-2.cisco.com> <8B0A9FCBB9832F43971E38010638454F03E9DCD0D7@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] location-conveyance-03 just 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: Wed, 14 Jul 2010 02:00:57 -0000 At 07:09 PM 7/13/2010, Thomson, Martin wrote: >Hi James, > >Looks like we've got most of the big stuff out of the way. very cool to hear (err, read)! > > >Content indirection has some interesting benefits. It's a good idea. > > > > it has always been in Conveyance, but might have been lost in the > > clutter. > >The 4483 reference was less explicit than your new Section 4.5. fair point >James (W) and I have been discussing the=20 >implications of this, and there is one note that=20 >might need revisiting in light of this. > >The mechanism for location by reference requires=20 >access to request bodies. For intermediaries,=20 >this is OK, because of the new mechanism that=20 >you have developed. However, the following text=20 >in Section 4.1 is probably now out of date: > > A SIP intermediary MAY add a Geolocation header field if one is not > present - for example, when a user agent does not support the > Geolocation mechanism but their outbound proxy does and knows their > Location... This text is actually new, though the meaning was=20 present in previous versions. What this means is=20 that if a SIP request does not have a Geolocation=20 header value, one *MAY* (i.e., more like _can_,=20 but not all the way) be added by a SIP=20 intermediary (i.e., proxy, b2bua, sbc,=20 etc). This last description is important -- as=20 proxies cannot legally (per any RFC)=20 add/modify/delete a MIME part (part), a b2bua or=20 sbc can. Many enterprise SIP systems are built=20 around b2buas as their call servers - expressly=20 for this capability (and for many other reasons=20 too). This document isn't advocating or=20 recommending intermediaries insert a Geolocation=20 header value when one is not present in a=20 received SIP request, but this doc makes it possible, that's all. > > > >I have some comments that includes one major issue. > > > > > >The major issue: > > > > > >The limitation to _one_ location value has > > >undeniable benefits. It also prevents the > > >conveyance of location value and reference together. >... > > >Jon's original response to this was to push the > > >composition problem to the PIDF-LO. That could be done, > > > > that is what's done, there is no 'could'. The > > text surrounding Figure 4 states this, and the > > example in 5.2 explains this is the example > > albeit showing two composed values from different sources. > >The composition scenario is a valid one, but it=20 >still has the inherent limitations of location=20 >by value - you can't get updates. correct, not without possessing a location URI of=20 the Target. But, that's what the geopriv-filters=20 ID is for, defining how to subscribe to a Target=20 (or its compositor server) to ask for current location of the Target. >The use case is basically: route based on the=20 >value, but provide a reference so that a PSAP=20 >can get better location information later; that=20 >is, updated or more accurate location. That's=20 >not possible if the UAC does the dereference:=20 >the location information becomes fixed. "...UAC does the dereference"? Do you mean to=20 understand that the UAC inserts location towards=20 an intermediary, gets a rejection 424, with the=20 intermediary's version of where the UAC is -=20 possibly as a location URI, and has to=20 dereference that URI to compose the now dual location MIME body? This is not how we mean for you to have read the section. We mean to have the intermediary do the=20 dereference (if one is needed) and compose in the=20 SIP 424 response a MIME body with both the=20 server's version or both locations of the Target,=20 and for that dual location single presence=20 document to be copied into the next SIP request=20 from that UAC (towards that same intermediary). Also, we do a little dance around idea - in text=20 - the concept of us not expecting the=20 intermediary receiving a 911 or 112 style=20 emergency call from ever returning a 424=20 rejection. We say we expect, but can't say this=20 normatively, that the intermediary will become a=20 b2bua for that call setup and compose (or=20 overwrite) the location in the SIP request and=20 forward that towards a PSAP/emergency call center. I think this is inconsistent with the phonebcp, which will need to be fixed. Does this make sense? >There are multiple ways to address this=20 >problem. One idea - that may be a bad one, I=20 >don't know yet - is to add a reference to a=20 >Content-Location header in combination with the=20 >PIDF-LO value. The other was to add PIDF extensions for indirection. I don't know what a "Content-Location" header is,=20 but given that Jon created the PIDF-LO, and was=20 instrumental in this Conveyance rewrite, he's=20 proposing the above be the solution. > > >The structure of the Geolocation-Error header > > >description is a little odd. It seems that you > > >are trying to describe *classes* of error and > > >specific errors at the same time. Separating > > >these concerns might make this easier to explain and understand. > > > > the errors are in categories, of which, only one > > category has more than one error code(the 3XX category about > > permissions). > >I understand, my concern was that the=20 >description of the classes didn't make it=20 >sufficiently clear that each of the 1xx, 2xx and=20 >4xx classes had a single error code in them. oh... yeah, I think I agree (even without looking=20 back at it). That's been at the back of my mind=20 since Jon whacked another section that I wrote in=20 an early version of this -03. I was meaning to=20 get back to that. I'll make it clear that each=20 are classes, where each x00 error code has a text=20 string that's clearly understood (similar to=20 what's there in the IANA section now). I'll make=20 it clearer that how more error codes can be added to each category too. >By combining the definition of that single error=20 >code with the definition of the class that=20 >contained them, it makes it hard to distinguish=20 >what description applies to just the code, and=20 >what applies to the class as a whole. > > > >The draft doesn=C3=A2=80=99t really justify the existence > > >of the "geolocaocation" option tag. > > > > what would justify it? > > > > the purpose of an option-tag is the ability to > > indicate support for an extension (whether > > optional or required), and to respond with > > whether or not an extension is supported or > > unsupported. This indication can be quite > > important for communicating SIP elements to > > understand support for (or not). I'm confused... > >Why is indicating support for (or requirement=20 >of) this particular feature important? If a UAC=20 >includes the header, is that not sufficient=20 >indication of support? What reason might a UAC=20 >have for requiring that the UAS supports the feature? any other SIP request where understanding that=20 the location of the UAC is vitally important to=20 properly process the request is another. for example, 911 is one I believe. But calling Pizza Hut's national URI, I might=20 require that UAS to understand where I am in=20 order to take my order, or reject my request. A=20 more likely scenario is for a roadside towing=20 service that I don't have a prior relationship=20 with. I would want to not call again to those=20 that don't understand 'location', and only call those that do in the future. >One justification for Supported might be that it=20 >is not possible to send 424 without some prior=20 >acknowledgement that the code is understood by=20 >the UAC. That might be sufficient. hmm... sounds good to me. I'll add it. Thanks! > > >Section 5 should show an example use of content > > >indirection for a location URI. > > > > I'll talk to my co-authors about this, as they > > are the ones limiting the number of examples ;-) > >Just a request - though it seemed like a fairly=20 >major omission. In comparison (and this might=20 >just be my perspective) the composition example seems less significant. less significant... I'm not sure how to take that=20 (as there is more than one way it might go). Two of us felt it important that there be an=20 example of a composed single MIME body for some=20 readers. Are you suggesting, that you feel the=20 composed dual value body is of less value than one value and one reference? > > > this might be a good point. I'll talk to my > > co-authors about breaking up section 3 into sub-sections (1 per > > Figure). > >That would help a lot, I think. Thanks. > > > >The examples in Section 5 are not schema-valid > > > > this is quite possible. This was a bit cobbled together. > >They were almost perfect. I've corrected the=20 >two examples and added them to the bottom of=20 >this email. I've validated these and made sure=20 >that they don't have excessively long lines :) a BIG thank you for this!! > > >"black phone" is a little jargon-y. > > > > it's certainly known inside the voice/telephony world. > >Sure. That doesn't make it any less jargon-y though. I guess it's also pre-Blackberry, and we don't=20 want anyone getting mad... I'll work on it. > > >More amusing was the idea that your > > >characterisation of a person was as a "non-IP device". > > > > many readers misunderstand when talking about > > Alice, it's one of her electronic devices that > > SIP communicates with, not her directly. > >That's an important distinction, but not one=20 >that I would have inferred from the=20 >text. Perhaps you meant to say: "non-IP device=20 >(a personal device such as a black phone)". that would work. I'll make the change > > Thanks for reading this so quickly and providing comments (seriously) > >Thanks for being responsive in return :) Thanks again James > > > James > > > > > > >--Martin > >Example from 5.1: > > xmlns=3D"urn:ietf:params:xml:ns:pidf" > xmlns:gp=3D"urn:ietf:params:xml:ns:pidf:geopriv10" > xmlns:gbp=3D"urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" > xmlns:cl=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" > xmlns:gml=3D"http://www.opengis.net/gml" > xmlns:dm=3D"urn:ietf:params:xml:ns:pidf:data-model" > entity=3D"pres:alice@atlanta.example.com"> > > > > > > 32.86726 -97.16054 > > > > > false > > 2010-07-30T20:00:00Z > > > 802.11 > > mac:1234567890ab > 2010-07-28T20:57:29Z > > > >Example 5.2: > > xmlns=3D"urn:ietf:params:xml:ns:pidf" > xmlns:gp=3D"urn:ietf:params:xml:ns:pidf:geopriv10" > xmlns:gbp=3D"urn:ietf:params:xml:ns:pidf:geopriv10:basicPolicy" > xmlns:dm=3D"urn:ietf:params:xml:ns:pidf:data-model" > xmlns:cl=3D"urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" > xmlns:gml=3D"http://www.opengis.net/gml" > entity=3D"pres:alice@atlanta.example.com"> > > > > > > 32.86726 -97.16054 > > > > > false > > 2010-07-30T20:00:00Z > > > 802.11 > > mac:1234567890ab > 2010-07-28T20:57:29Z > > > > > > US > Texas > Colleyville > Treemont > Circle > 3913 > 1 > Haley's Place > 76034 > > > > false > > 2010-07-30T20:00:00Z > > > triangulation > > 2010-07-28T12:28:04Z > > From krisztian.kiss@nokia.com Tue Jul 13 20:50:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B24313A69EE for ; Tue, 13 Jul 2010 20:50:30 -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 jYn8oEUYgG8b for ; Tue, 13 Jul 2010 20:50:29 -0700 (PDT) Received: from mgw-mx03.nokia.com (smtp.nokia.com [192.100.122.230]) by core3.amsl.com (Postfix) with ESMTP id 47B163A69CC for ; Tue, 13 Jul 2010 20:50:29 -0700 (PDT) Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-mx03.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o6E3oYgd006054; Wed, 14 Jul 2010 06:50:36 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 06:50:33 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 06:50:33 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 06:50:28 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 14 Jul 2010 05:50:24 +0200 From: To: Date: Wed, 14 Jul 2010 05:50:24 +0200 Thread-Topic: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-03 Thread-Index: Acsi2fNHxSxJ7oxfRaSgoZkp2aTRhwALGVWg Message-ID: References: <99619466-573D-4CEA-ACCD-3A3D262EB2B0@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Jul 2010 03:50:28.0551 (UTC) FILETIME=[B306ED70:01CB2307] X-Nokia-AV: Clean Cc: sipcore@ietf.org Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-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: Wed, 14 Jul 2010 03:50:30 -0000 Hi, Both suggestions sound good to me. Once the I-D submission tool reopens, we= can incorporate these changes in -05. Thanks, Krisztian -----Original Message----- From: ext Robert Sparks [mailto:rjsparks@nostrum.com]=20 Sent: 2010. j=FAlius 13. 15:23 To: Kiss Krisztian (Nokia-CD/MtView) Cc: sipcore@ietf.org Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-03 A couple more observations inline (and I'm trimming away things I'm not rep= lying to here): On Jul 12, 2010, at 7:13 PM, krisztian.kiss@nokia.com wrote: > Hi Robert, >=20 > I submitted the -04 version today addressing your comments: http://www.ie= tf.org/id/draft-ietf-sipcore-event-rate-control-04.txt=20 >=20 > Please find my answers in-line with [KK]: >=20 > Is there text here that prevents a subscriber > from generating Event headers in 200 OKs to NOTIFYs mid-subscription (whe= n he > didn't probe for support using the SUBSCRIBE?) How would they know the re= quest > got honored? The possibility of running into implementations that break = should > be called out. =20 >=20 > [KK] I added text in -04 to address this:=20 > Section 4.1: "If the Event header field of the SUBSCRIBE request did not = include the "min-interval" parameter, the subscriber MUST NOT include an in= itial value of the "min-interval" Event header field parameter in a 200-cla= ss response to the NOTIFY request."=20 > Section 4.2: "If the Event header field of the SUBSCRIBE request did not = include the "min-interval" parameter, the notifier MUST ignore an initial v= alue of the "min-interval" Event header field parameter in a 200-class resp= onse to the NOTIFY request, if present." > ...and similar text covering max-interval and average-interval mechanisms= . These changes (and the associated changes in 5.1, 5.2, 6.1, and 6.2) are to= o granular and introduce the possibility of edge cases I don't think we sho= uld introduce. It would be much simpler to say: =20 If the subscriber did not include at least one of the "min-interval, "max-i= nterval", or "average-interval" header field parameters in the most recent = SUBSCRIBE request in a given dialog, it MUST NOT include an Event header fi= eld with any of those parameters in a 200 OK to a NOTIFY in that dialog. >=20 > * Section 3.2 last paragraph: The sentence 'The "max-interval" parameter= =20 > indicates ... complete state information' is difficult to parse. Cou= ld it > be simplified? The new sentence you propose is even harder for me to read. Here's some suggested text: The "max-interval" parameter indicates to the notifier the maximum amount o= f time that should be allowed to elapse between NOTIFY requests containing = complete state information. RjS From krisztian.kiss@nokia.com Tue Jul 13 20:51:04 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4D11F3A6A0B for ; Tue, 13 Jul 2010 20:51:04 -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 sy54JdPZonBg for ; Tue, 13 Jul 2010 20:51:03 -0700 (PDT) Received: from mgw-mx06.nokia.com (smtp.nokia.com [192.100.122.233]) by core3.amsl.com (Postfix) with ESMTP id C0D503A69DC for ; Tue, 13 Jul 2010 20:51:02 -0700 (PDT) Received: from vaebh106.NOE.Nokia.com (vaebh106.europe.nokia.com [10.160.244.32]) by mgw-mx06.nokia.com (Switch-3.3.3/Switch-3.3.3) with ESMTP id o6E3oiaq008087; Wed, 14 Jul 2010 06:51:08 +0300 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by vaebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 06:50:00 +0300 Received: from vaebh101.NOE.Nokia.com ([10.160.244.22]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 06:50:00 +0300 Received: from smtp.mgd.nokia.com ([65.54.30.6]) by vaebh101.NOE.Nokia.com over TLS secured channel with Microsoft SMTPSVC(6.0.3790.4675); Wed, 14 Jul 2010 06:49:54 +0300 Received: from NOK-EUMSG-01.mgdnok.nokia.com ([65.54.30.86]) by nok-am1mhub-02.mgdnok.nokia.com ([65.54.30.6]) with mapi; Wed, 14 Jul 2010 05:49:54 +0200 From: To: Date: Wed, 14 Jul 2010 05:49:51 +0200 Thread-Topic: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-03 Thread-Index: Acsi0wwXC2fWU5rvRDuPCWTCQVMHJAAKIEpQ Message-ID: References: <99619466-573D-4CEA-ACCD-3A3D262EB2B0@nostrum.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 14 Jul 2010 03:49:54.0974 (UTC) FILETIME=[9F037BE0:01CB2307] X-Nokia-AV: Clean Cc: sipcore@ietf.org Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-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: Wed, 14 Jul 2010 03:51:04 -0000 Hi, Inline: -----Original Message----- From: ext Robert Sparks [mailto:rjsparks@nostrum.com]=20 Sent: 2010. j=FAlius 13. 14:33 To: Kiss Krisztian (Nokia-CD/MtView) Cc: sipcore@ietf.org Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-03 inline: On Jul 12, 2010, at 7:13 PM, krisztian.kiss@nokia.com wrote: > Hi Robert, >=20 > I submitted the -04 version today addressing your comments: http://www.ie= tf.org/id/draft-ietf-sipcore-event-rate-control-04.txt=20 >=20 > Please find my answers in-line with [KK]: >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behal= f Of ext Robert Sparks > Sent: 2010. j=FAnius 10. 13:14 > To: SIPCORE > Subject: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-03 >=20 > Summary: This draft has a few adjustments that are needed before moving i= t into IETF Last Call. >=20 > Major question: >=20 > Why isn't this an Update to 3265?=20 >=20 > [KK] It's an extension to 3265. Implementations of 3265 not interested in= rate control don't need to implement it. If people think it's an essential= part of event-notifications, we could make it as an update of 3265. Any re= commendations? We have a separate thread going for this one. >=20 > Is there text here that prevents a subscriber > from generating Event headers in 200 OKs to NOTIFYs mid-subscription (whe= n he > didn't probe for support using the SUBSCRIBE?) How would they know the re= quest > got honored? The possibility of running into implementations that break = should > be called out. =20 >=20 > [KK] I added text in -04 to address this:=20 > Section 4.1: "If the Event header field of the SUBSCRIBE request did not = include the "min-interval" parameter, the subscriber MUST NOT include an in= itial value of the "min-interval" Event header field parameter in a 200-cla= ss response to the NOTIFY request."=20 > Section 4.2: "If the Event header field of the SUBSCRIBE request did not = include the "min-interval" parameter, the notifier MUST ignore an initial v= alue of the "min-interval" Event header field parameter in a 200-class resp= onse to the NOTIFY request, if present." > ...and similar text covering max-interval and average-interval mechanisms= . So, which SUBSCRIBE? I think you mean the most recent SUBSCRIBE request rec= eived on this dialog (and not just the initial SUBSCRIBE)? [KK2] Yes, I mean the most recent SUBSCRIBE.=20 >=20 > 4.2 indicates the subscriber only gets a "hint" about support > for rate-control in the notifier - is the condition it describes really o= nly a > hint? >=20 > [KK] Replaced "serves as a hint" with "indicates". >=20 > In several places, the notifier is given permission to adjust an interval= based > on local policy. The document should be explicit about allowing the adju= stment > in any direction (increasing or decreasing) since there are so many other= uses > of intervals in SIP and SIP Events that allow adjustment only in one dire= ction. > A few places I noted when reading the document were the Note in REQ7, 4.3= 4th > paragraph, 5.2 paragraph 3, 6.2 paragraph 3. >=20 > [KK] I spelled out the possibility of increasing and decreasing at all of= these sections you referenced. >=20 > The last paragraph of section 3.6 claims "exactly the same properties" ex= cept > for being generated constrained to a schedule. Can you clarify which prop= erties > you mean? Many properties of the notifications beside their timing are cl= early > different (for instance, you may miss state transitions). >=20 > [KK] I just deleted that sentence, there was no real added value in it. >=20 > The security considerations section deserves more text:=20 > * What is the forward reference from section 3.4 supposed to be pointing = to? >=20 > [KK] Deleted. >=20 > * Call out the implications on a Notifier having to store/aggregate parti= al state >=20 > [KK] I added a reference to the security considerations listed in RFC 526= 3 (partial notifications). >=20 > * Note that the Event header (particularly in 200 OKs) is not integrity p= rotected.=20 > This would allow anything that could modify the message in flight (or an= =20 > eavesdropper that could race a 200 OK in) to suppress (or flood) notific= ations=20 > without the subscriber seeing what caused it. >=20 > [KK] I added a new paragraph on this: > "RFC 3265 [RFC3265] recommends the integrity protection of the Event head= er field of SUBSCRIBE requests. Implementations of this extension SHOULD al= so provide integrity protection for the Event header field included in the = 200-class response to the NOTIFY request." I would still call out the attacks that are possible when it isn't integrit= y protected. [KK2] OK, will add text in -05 version. > The assertion that applying rate limiting and compression together result= s in > savings as good as the sum of applying them independently should be suppo= rted > or adjusted. I think it's sufficient to say they can be applied together. >=20 > [KK] OK, so no changes needed, right? No, not OK. I think you misunderstood my comment. You should either add text justifying the claim, or change the text. I prop= ose above to change the text to simply say they can be applied together and not make an unsupported clai= m about the savings being as good as the sum of applying them together. [KK2] I see what you mean now. I will remove the "compound savings are as g= ood as the sum of applying each one alone" part of the sentence. Cheers, Krisztian From Martin.Thomson@andrew.com Wed Jul 14 00:06:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D844C3A6A04 for ; Wed, 14 Jul 2010 00:06:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.446 X-Spam-Level: X-Spam-Status: No, score=-2.446 tagged_above=-999 required=5 tests=[AWL=0.153, 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 e7ULm7mmBIS2 for ; Wed, 14 Jul 2010 00:06:12 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 92D613A694C for ; Wed, 14 Jul 2010 00:06:12 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:48336 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S338012Ab0GNHGW (ORCPT ); Wed, 14 Jul 2010 02:06:22 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Wed, 14 Jul 2010 02:06:21 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 14 Jul 2010 15:06:17 +0800 From: "Thomson, Martin" To: "James M. Polk" , "sipcore@ietf.org" Date: Wed, 14 Jul 2010 15:08:24 +0800 Thread-Topic: [sipcore] location-conveyance-03 just submitted Thread-Index: Acsi+NJTa+ULYvovSE2TL/bYrSlncwAKAPJQ Message-ID: <8B0A9FCBB9832F43971E38010638454F03E9DCD1AE@SISPE7MB1.commscope.com> References: <201007122355.o6CNt6us024310@sj-core-3.cisco.com> <8B0A9FCBB9832F43971E38010638454F03E9DCCFFC@SISPE7MB1.commscope.com> <201007130629.o6D6Tk7F028645@sj-core-2.cisco.com> <8B0A9FCBB9832F43971E38010638454F03E9DCD0D7@SISPE7MB1.commscope.com> <201007140201.o6E2138L023850@sj-core-1.cisco.com> In-Reply-To: <201007140201.o6E2138L023850@sj-core-1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] location-conveyance-03 just 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: Wed, 14 Jul 2010 07:06:14 -0000 U25pcHBpbmcgc3R1ZmYgdGhhdCBJIHRoaW5rIHdlJ3ZlIHJlc29sdmVkLg0KDQo+ID4gICAgQSBT SVAgaW50ZXJtZWRpYXJ5IE1BWSBhZGQgYSBHZW9sb2NhdGlvbiBoZWFkZXIgZmllbGQgaWYgb25l IGlzDQo+IG5vdA0KPiA+ICAgIHByZXNlbnQgLSBmb3IgZXhhbXBsZSwgd2hlbiBhIHVzZXIgYWdl bnQgZG9lcyBub3Qgc3VwcG9ydCB0aGUNCj4gPiAgICBHZW9sb2NhdGlvbiBtZWNoYW5pc20gYnV0 IHRoZWlyIG91dGJvdW5kIHByb3h5IGRvZXMgYW5kIGtub3dzDQo+IHRoZWlyDQo+ID4gICAgTG9j YXRpb24uLi4NCj4gDQo+IFRoaXMgdGV4dCBpcyBhY3R1YWxseSBuZXcsIHRob3VnaCB0aGUgbWVh bmluZyB3YXMNCj4gcHJlc2VudCBpbiBwcmV2aW91cyB2ZXJzaW9ucy4gV2hhdCB0aGlzIG1lYW5z IGlzDQo+IHRoYXQgaWYgYSBTSVAgcmVxdWVzdCBkb2VzIG5vdCBoYXZlIGEgR2VvbG9jYXRpb24N Cj4gaGVhZGVyIHZhbHVlLCBvbmUgKk1BWSogKGkuZS4sIG1vcmUgbGlrZSBfY2FuXywNCj4gYnV0 IG5vdCBhbGwgdGhlIHdheSkgYmUgYWRkZWQgYnkgYSBTSVANCj4gaW50ZXJtZWRpYXJ5IChpLmUu LCBwcm94eSwgYjJidWEsIHNiYywNCj4gZXRjKS4gIFRoaXMgbGFzdCBkZXNjcmlwdGlvbiBpcyBp bXBvcnRhbnQgLS0gYXMNCj4gcHJveGllcyBjYW5ub3QgbGVnYWxseSAocGVyIGFueSBSRkMpDQo+ IGFkZC9tb2RpZnkvZGVsZXRlIGEgTUlNRSBwYXJ0IChwYXJ0KSwgYSBiMmJ1YSBvcg0KPiBzYmMg Y2FuLiAgTWFueSBlbnRlcnByaXNlIFNJUCBzeXN0ZW1zIGFyZSBidWlsdA0KPiBhcm91bmQgYjJi dWFzIGFzIHRoZWlyIGNhbGwgc2VydmVycyAtIGV4cHJlc3NseQ0KPiBmb3IgdGhpcyBjYXBhYmls aXR5IChhbmQgZm9yIG1hbnkgb3RoZXIgcmVhc29ucw0KPiB0b28pLiBUaGlzIGRvY3VtZW50IGlz bid0IGFkdm9jYXRpbmcgb3INCj4gcmVjb21tZW5kaW5nIGludGVybWVkaWFyaWVzIGluc2VydCBh IEdlb2xvY2F0aW9uDQo+IGhlYWRlciB2YWx1ZSB3aGVuIG9uZSBpcyBub3QgcHJlc2VudCBpbiBh DQo+IHJlY2VpdmVkIFNJUCByZXF1ZXN0LCBidXQgdGhpcyBkb2MgbWFrZXMgaXQgcG9zc2libGUs IHRoYXQncyBhbGwuDQoNClRoYXQncyBhIGdvb2QgZXhwbGFuYXRpb24sIGJ1dCBJIGRpZG4ndCBn ZXQgdGhpcyBmcm9tIHRoZSB0ZXh0LiAgSSB0aGluayB0aGF0IHBlcmhhcHMgYWxsIHRoaXMgbmVl ZHMgaXMgYSBsaXR0bGUgY2xhcmlmaWNhdGlvbjogIkEgU0lQIGludGVybWVkaWFyeSAqdGhhdCBh Y3RzIGFzIGEgQjJCVUEqIE1BWSBhZGQgYS4uLiIuICBJIHRoaW5rIHRoYXQgaW4gdGhpcyBjYXNl LCB5b3Ugd291bGQgaGF2ZSB0byBleHBsaWNpdGx5IGV4Y2x1ZGUgInByb3h5IiBmcm9tIHRoZSBk ZWZpbml0aW9uLg0KDQo+ID5UaGUgY29tcG9zaXRpb24gc2NlbmFyaW8gaXMgYSB2YWxpZCBvbmUs IGJ1dCBpdA0KPiA+c3RpbGwgaGFzIHRoZSBpbmhlcmVudCBsaW1pdGF0aW9ucyBvZiBsb2NhdGlv bg0KPiA+YnkgdmFsdWUgLSB5b3UgY2FuJ3QgZ2V0IHVwZGF0ZXMuDQo+IA0KPiBjb3JyZWN0LCBu b3Qgd2l0aG91dCBwb3NzZXNzaW5nIGEgbG9jYXRpb24gVVJJIG9mDQo+IHRoZSBUYXJnZXQuIEJ1 dCwgdGhhdCdzIHdoYXQgdGhlIGdlb3ByaXYtZmlsdGVycw0KPiBJRCBpcyBmb3IsIGRlZmluaW5n IGhvdyB0byBzdWJzY3JpYmUgdG8gYSBUYXJnZXQNCj4gKG9yIGl0cyBjb21wb3NpdG9yIHNlcnZl cikgdG8gYXNrIGZvciBjdXJyZW50IGxvY2F0aW9uIG9mIHRoZSBUYXJnZXQuDQoNCkZpbHRlcnMg aXNuJ3QgcmVhbGx5IHRoZSBkZWZpbml0aXZlIHJlZmVyZW5jZSBmb3IgdGhhdC4gIFlvdSBtaWdo dCBhY3R1YWxseSBjb25zaWRlciBSRkMgMzg1NiB0byBiZSB0aGUgZGVmaW5pdGl2ZSByZWZlcmVu Y2UgKG1heWJlIHJlZmVyZW5jaW5nIFJGQyA0MDc5KS4NCiANCj4gPlRoZSB1c2UgY2FzZSBpcyBi YXNpY2FsbHk6IHJvdXRlIGJhc2VkIG9uIHRoZQ0KPiA+dmFsdWUsIGJ1dCBwcm92aWRlIGEgcmVm ZXJlbmNlIHNvIHRoYXQgYSBQU0FQDQo+ID5jYW4gZ2V0IGJldHRlciBsb2NhdGlvbiBpbmZvcm1h dGlvbiBsYXRlcjsgdGhhdA0KPiA+aXMsIHVwZGF0ZWQgb3IgbW9yZSBhY2N1cmF0ZSBsb2NhdGlv bi4gIFRoYXQncw0KPiA+bm90IHBvc3NpYmxlIGlmIHRoZSBVQUMgZG9lcyB0aGUgZGVyZWZlcmVu Y2U6DQo+ID50aGUgbG9jYXRpb24gaW5mb3JtYXRpb24gYmVjb21lcyBmaXhlZC4NCj4gDQo+ICIu Li5VQUMgZG9lcyB0aGUgZGVyZWZlcmVuY2UiPyBEbyB5b3UgbWVhbiB0bw0KPiB1bmRlcnN0YW5k IHRoYXQgdGhlIFVBQyBpbnNlcnRzIGxvY2F0aW9uIHRvd2FyZHMNCj4gYW4gaW50ZXJtZWRpYXJ5 LCBnZXRzIGEgcmVqZWN0aW9uIDQyNCwgd2l0aCB0aGUNCj4gaW50ZXJtZWRpYXJ5J3MgdmVyc2lv biBvZiB3aGVyZSB0aGUgVUFDIGlzIC0NCj4gcG9zc2libHkgYXMgYSBsb2NhdGlvbiBVUkksIGFu ZCBoYXMgdG8NCj4gZGVyZWZlcmVuY2UgdGhhdCBVUkkgdG8gY29tcG9zZSB0aGUgbm93IGR1YWwg bG9jYXRpb24gTUlNRSBib2R5Pw0KDQpObyAtIEknbSBzYXlpbmcgdGhhdCBteSBtYWpvciBpc3N1 ZSBpcyBkcml2ZW4gYnkgdGhhdCB1c2UgY2FzZS4gIFRoZXJlIGlzIChjdXJyZW50bHkpIG5vIHdh eSBmb3IgYW55IGVudGl0eSAoVUFDIG9yIGludGVybWVkaWFyeSkgdG8gaW5zZXJ0IGJvdGggbG9j YXRpb24gYnkgdmFsdWUgYW5kIGxvY2F0aW9uIGJ5IHJlZmVyZW5jZS4gIFRoZXJlIGlzIGEgbmVl ZCBmb3IgdGhhdCBjYXBhYmlsaXR5Lg0KDQo+IFdlIG1lYW4gdG8gaGF2ZSB0aGUgaW50ZXJtZWRp YXJ5IGRvIHRoZQ0KPiBkZXJlZmVyZW5jZSAoaWYgb25lIGlzIG5lZWRlZCkgYW5kIGNvbXBvc2Ug aW4gdGhlDQo+IFNJUCA0MjQgcmVzcG9uc2UgYSBNSU1FIGJvZHkgd2l0aCBib3RoIHRoZQ0KPiBz ZXJ2ZXIncyB2ZXJzaW9uIG9yIGJvdGggbG9jYXRpb25zIG9mIHRoZSBUYXJnZXQsDQo+IGFuZCBm b3IgdGhhdCBkdWFsIGxvY2F0aW9uIHNpbmdsZSBwcmVzZW5jZQ0KPiBkb2N1bWVudCB0byBiZSBj b3BpZWQgaW50byB0aGUgbmV4dCBTSVAgcmVxdWVzdA0KPiBmcm9tIHRoYXQgVUFDICh0b3dhcmRz IHRoYXQgc2FtZSBpbnRlcm1lZGlhcnkpLg0KDQpFbGVnYW50IGFzIGl0IGlzLCB0aGlzIGp1c3Qg ZG9lc24ndCB3b3JrLiAgVGhlIFVBUyAoUFNBUCwgTFIsIGV0Yy4uLikgbmVlZHMgdG8gYmUgdGhl IGVudGl0eSB0aGF0IGRvZXMgdGhlIGRlcmVmZXJlbmNlLiAgVGhleSBuZWVkIHRvIGRvIHRoaXMg YmVjYXVzZSB0aGV5IGtub3cgaG93IChhbmQgd2hlbikgdG8gbWFrZSB0aGlzIHJlcXVlc3Qgc28g dGhhdCB0aGV5IGdldCB0aGUgaW5mb3JtYXRpb24gdGhleSBuZWVkLiAgSWYgdGhlIGludGVybWVk aWFyeSBkb2VzIHRoZSBkZXJlZmVyZW5jZSwgdGhlbiBsb2NhdGlvbiBpbmZvcm1hdGlvbiBpcyBz ZXQgaW4gc3RvbmUgZnJvbSB0aGF0IHBvaW50IG9ud2FyZC4NCiANCj4gQWxzbywgd2UgZG8gYSBs aXR0bGUgZGFuY2UgYXJvdW5kIGlkZWEgLSBpbiB0ZXh0DQo+IC0gdGhlIGNvbmNlcHQgb2YgdXMg bm90IGV4cGVjdGluZyB0aGUNCj4gaW50ZXJtZWRpYXJ5IHJlY2VpdmluZyBhIDkxMSBvciAxMTIg c3R5bGUNCj4gZW1lcmdlbmN5IGNhbGwgZnJvbSBldmVyIHJldHVybmluZyBhIDQyNA0KPiByZWpl Y3Rpb24uIFdlIHNheSB3ZSBleHBlY3QsIGJ1dCBjYW4ndCBzYXkgdGhpcw0KPiBub3JtYXRpdmVs eSwgdGhhdCB0aGUgaW50ZXJtZWRpYXJ5IHdpbGwgYmVjb21lIGENCj4gYjJidWEgZm9yIHRoYXQg Y2FsbCBzZXR1cCBhbmQgY29tcG9zZSAob3INCj4gb3ZlcndyaXRlKSB0aGUgbG9jYXRpb24gaW4g dGhlIFNJUCByZXF1ZXN0IGFuZA0KPiBmb3J3YXJkIHRoYXQgdG93YXJkcyBhIFBTQVAvZW1lcmdl bmN5IGNhbGwgY2VudGVyLg0KDQpCVFcsIEkgbGlrZWQgdGhhdCBkYW5jZS4gIEl0J3MgYW5vdGhl ciB3aW4gZm9yIHByYWdtYXRpc20gb3ZlciBkb2dtYXRpc20uDQoNCj4gSSB0aGluayB0aGlzIGlz IGluY29uc2lzdGVudCB3aXRoIHRoZSBwaG9uZWJjcCwgd2hpY2ggd2lsbCBuZWVkIHRvIGJlDQo+ IGZpeGVkLg0KDQpJJ20gc3RpbGwgcmVhZGluZyBwaG9uZS1iY3AgYWdhaW5zdCBwcmV2aW91cyB2 ZXJzaW9ucy4gIEknbGwgYXdhaXQgYSBwaG9uZS1iY3AgdXBkYXRlIGFuZCB3ZSBjYW4gZGlzY3Vz cyBob3cgdGhlIHR3byBpbnRlcmFjdCB0aGVuLg0KDQo+ID5UaGVyZSBhcmUgbXVsdGlwbGUgd2F5 cyB0byBhZGRyZXNzIHRoaXMNCj4gPnByb2JsZW0uICBPbmUgaWRlYSAtIHRoYXQgbWF5IGJlIGEg YmFkIG9uZSwgSQ0KPiA+ZG9uJ3Qga25vdyB5ZXQgLSBpcyB0byBhZGQgYSByZWZlcmVuY2UgdG8g YQ0KPiA+Q29udGVudC1Mb2NhdGlvbiBoZWFkZXIgaW4gY29tYmluYXRpb24gd2l0aCB0aGUNCj4g PlBJREYtTE8gdmFsdWUuICBUaGUgb3RoZXIgd2FzIHRvIGFkZCBQSURGIGV4dGVuc2lvbnMgZm9y IGluZGlyZWN0aW9uLg0KPiANCj4gSSBkb24ndCBrbm93IHdoYXQgYSAiQ29udGVudC1Mb2NhdGlv biIgaGVhZGVyIGlzLA0KPiBidXQgZ2l2ZW4gdGhhdCBKb24gY3JlYXRlZCB0aGUgUElERi1MTywg YW5kIHdhcw0KPiBpbnN0cnVtZW50YWwgaW4gdGhpcyBDb252ZXlhbmNlIHJld3JpdGUsIGhlJ3MN Cj4gcHJvcG9zaW5nIHRoZSBhYm92ZSBiZSB0aGUgc29sdXRpb24uDQoNCkFzIEkgc3RhdGVkLCBJ IGRvbid0IHNlZSB0aGF0IHRoZXJlIGlzIGEgc29sdXRpb24geWV0Lg0KDQo+ID5JIHVuZGVyc3Rh bmQsIG15IGNvbmNlcm4gd2FzIHRoYXQgdGhlDQo+ID5kZXNjcmlwdGlvbiBvZiB0aGUgY2xhc3Nl cyBkaWRuJ3QgbWFrZSBpdA0KPiA+c3VmZmljaWVudGx5IGNsZWFyIHRoYXQgZWFjaCBvZiB0aGUg MXh4LCAyeHggYW5kDQo+ID40eHggY2xhc3NlcyBoYWQgYSBzaW5nbGUgZXJyb3IgY29kZSBpbiB0 aGVtLg0KPiANCj4gb2guLi4geWVhaCwgSSB0aGluayBJIGFncmVlIChldmVuIHdpdGhvdXQgbG9v a2luZw0KPiBiYWNrIGF0IGl0KS4gVGhhdCdzIGJlZW4gYXQgdGhlIGJhY2sgb2YgbXkgbWluZA0K PiBzaW5jZSBKb24gd2hhY2tlZCBhbm90aGVyIHNlY3Rpb24gdGhhdCBJIHdyb3RlIGluDQo+IGFu IGVhcmx5IHZlcnNpb24gb2YgdGhpcyAtMDMuIEkgd2FzIG1lYW5pbmcgdG8NCj4gZ2V0IGJhY2sg dG8gdGhhdC4gIEknbGwgbWFrZSBpdCBjbGVhciB0aGF0IGVhY2gNCj4gYXJlIGNsYXNzZXMsIHdo ZXJlIGVhY2ggeDAwIGVycm9yIGNvZGUgaGFzIGEgdGV4dA0KPiBzdHJpbmcgdGhhdCdzIGNsZWFy bHkgdW5kZXJzdG9vZCAoc2ltaWxhciB0bw0KPiB3aGF0J3MgdGhlcmUgaW4gdGhlIElBTkEgc2Vj dGlvbiBub3cpLiBJJ2xsIG1ha2UNCj4gaXQgY2xlYXJlciB0aGF0IGhvdyBtb3JlIGVycm9yIGNv ZGVzIGNhbiBiZSBhZGRlZCB0byBlYWNoIGNhdGVnb3J5IHRvby4NCg0KR3JlYXQuICBCdXQgcGxl YXNlIHRlbGwgbWUgdGhhdCB5b3UgYXJlbid0IGZpeGluZyB0aGUgZXJyb3IgdGV4dCB0byB0aGUg ZXJyb3IgY29kZS4NCiANCg0KPiBUd28gb2YgdXMgZmVsdCBpdCBpbXBvcnRhbnQgdGhhdCB0aGVy ZSBiZSBhbg0KPiBleGFtcGxlIG9mIGEgY29tcG9zZWQgc2luZ2xlIE1JTUUgYm9keSBmb3Igc29t ZQ0KPiByZWFkZXJzLiAgQXJlIHlvdSBzdWdnZXN0aW5nLCB0aGF0IHlvdSBmZWVsIHRoZQ0KPiBj b21wb3NlZCBkdWFsIHZhbHVlIGJvZHkgaXMgb2YgbGVzcyB2YWx1ZSB0aGFuIG9uZSB2YWx1ZSBh bmQgb25lDQo+IHJlZmVyZW5jZT8NCg0KVGhhdCdzIGJhc2VkIG9uIHdoYXQgSSBrbm93IHdlIG5l ZWQgLSBJIGRvbid0IGhhdmUgYSBzdHJvbmcgbmVlZCBmb3IgY29tcG9zaXRpb24gcmlnaHQgbm93 LiAgT2YgY291cnNlLCBldmVyeW9uZSBpcyBhbGxvd2VkIHRvIGhhdmUgdGhlaXIgb3duIHBlcnNw ZWN0aXZlIG9uIHRoaXMgc29ydCBvZiB0aGluZy4NCg0KQ2hlZXJzLA0KTWFydGluDQo= From adam@nostrum.com Wed Jul 14 07:02:10 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC7753A680C for ; Wed, 14 Jul 2010 07:02:10 -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=[AWL=0.000, 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 VHHOGWG-6c28 for ; Wed, 14 Jul 2010 07:02:10 -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 473763A67DA for ; Wed, 14 Jul 2010 07:02:05 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-149-233.dsl.rcsntx.swbell.net [70.249.149.233]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6EE2D5v077661 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 14 Jul 2010 09:02:14 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C3DC365.1060508@nostrum.com> Date: Wed, 14 Jul 2010 09:02:13 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 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: 70.249.149.233 is authenticated by a trusted mechanism) Cc: draft-ietf-sipcore-keep@tools.ietf.org, "sipcore-chairs@tools.ietf.org" Subject: [sipcore] WGLC: draft-ietf-sipcore-keep X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 14 Jul 2010 14:02:11 -0000 [as chair] The author of draft-ietf-sipcore-keep believes that the document has no remaining open issues, and is ready to be evaluated by the IESG for publication. Today, we begin a three-week Working Group Last Call period, which ends on Wednesday, August 4th. (This WGLC is three weeks instead of the more traditional two to account for the upcoming IETF meeting). The latest version of the document can be retrieved here: http://tools.ietf.org/html/draft-ietf-sipcore-keep Any comments on the document should be sent to the SIPCORE mailing list. As a note to document reviewers: the document's author is on holiday through August 2nd, and will respond to any direct queries after returning. /a From jon.peterson@neustar.biz Wed Jul 14 10:08:40 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B0B223A6B95 for ; Wed, 14 Jul 2010 10:08:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.598 X-Spam-Level: X-Spam-Status: No, score=-102.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kGjHUkzHpXem for ; Wed, 14 Jul 2010 10:08:34 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id CB7B33A6B67 for ; Wed, 14 Jul 2010 10:08:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1279127315; x=1594397711; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=nzDnwyjnw9LJvZS2wpzlEt94yeaAan4WQyvG8rcBFHA=; b=Kev7eL9fV6H5WcO8Ql+FrbYjG0ikiV1Hys53lAek3VYSsyS4l1+OKI2EwMW11o HeU/fSFVkdpxXdVINBamDAbA== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id G6K7MJ1.11391791; Wed, 14 Jul 2010 13:08:34 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Wed, 14 Jul 2010 13:08:34 -0400 From: "Peterson, Jon" To: "Thomson, Martin" , "James M. Polk" , "sipcore@ietf.org" Date: Wed, 14 Jul 2010 13:08:32 -0400 Thread-Topic: [sipcore] location-conveyance-03 just submitted Thread-Index: Acsi+NJTa+ULYvovSE2TL/bYrSlncwAKAPJQABWWaxY= Message-ID: In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E9DCD1AE@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: vTSEB5ZFBF8DzTa3mqpaiw== Content-Type: multipart/alternative; boundary="_000_C8633D2041A01jonpetersonneustarbiz_" MIME-Version: 1.0 Subject: Re: [sipcore] location-conveyance-03 just 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: Wed, 14 Jul 2010 17:08:40 -0000 --_000_C8633D2041A01jonpetersonneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable [snip] > We mean to have the intermediary do the > dereference (if one is needed) and compose in the > SIP 424 response a MIME body with both the > server's version or both locations of the Target, > and for that dual location single presence > document to be copied into the next SIP request > from that UAC (towards that same intermediary). Elegant as it is, this just doesn't work. The UAS (PSAP, LR, etc...) needs= to be the entity that does the dereference. They need to do this because = they know how (and when) to make this request so that they get the informat= ion they need. If the intermediary does the dereference, then location inf= ormation is set in stone from that point onward. I see your point, but I think the difficulty is deeper still than thi= s. The whole use case for an intermediary providing different (or supplemen= tary) location information above and beyond the location provided by the UA= C is based on the intermediary inspecting, and disliking, the location pres= ent in the request. If that location is constantly changing, what would it = mean for the intermediary to dislike it? Maybe it likes it one minute and n= ot the next? Would it -ever- be safe for a picky intermediary to allow a re= ference to pass it, given that it couldn't control what location the LR wou= ld ultimately get from it? Moreover, what if the creator of the reference a= uthorizes the end recipient (the PSAP) but not the intermediary that wants = to judge location information? I think we'd need to look further into the m= otivations here to understand the underlying requirement. Practically speaking, however, there are a number of potential work-arounds= to enable this semantic - I don't necessarily think that once the intermed= iary performs the dereference, then the location information must be set in= stone. If you seriously want to retain the dynamism of location informatio= n, it could become the responsibility of the compositor to deliver a simila= rly dynamic reference, and every time someone dereferences the composed obj= ect, the compositor creates a new PIDF-LO document based on freshly derefer= encing any dynamic components of the location information. Another possibil= ity would be to specify external references in PIDF, so we could compose lo= cation information from dynamic sources by reference in the PIDF object, ra= ther than by value. One composed object could even have a mix of by-value a= nd by-reference location information in that case. The important thing is t= hat we solve this down in the PIDF level, within the parameters of RFC4479,= rather than trying to cobble together some relationship between devices, s= ervices and users in the Geolocation header. Anyway, none of this is to suggest that this is adequately specified in the= current draft, or something. We'd need to have a more lengthy discussion a= bout some of the issues above before figuring out what we'd add, though. Jon Peterson NeuStar, Inc. --_000_C8633D2041A01jonpetersonneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [sipcore] location-conveyance-03 just submitted

[snip]
> We mean to have the intermediary do the
> dereference (if one is needed) and compose in the
> SIP 424 response a MIME body with both the
> server's version or both locations of the Target,
> and for that dual location single presence
> document to be copied into the next SIP request
> from that UAC (towards that same intermediary).

Elegant as it is, this just doesn't work.  The UAS (PSAP, LR, etc...) = needs to be the entity that does the dereference.  They need to do thi= s because they know how (and when) to make this request so that they get th= e information they need.  If the intermediary does the dereference, th= en location information is set in stone from that point onward.

<JFP> I see your point, but I think the difficulty is deeper still th= an this. The whole use case for an intermediary providing different (or sup= plementary) location information above and beyond the location provided by = the UAC is based on the intermediary inspecting, and disliking, the locatio= n present in the request. If that location is constantly changing, what wou= ld it mean for the intermediary to dislike it? Maybe it likes it one minute= and not the next? Would it –ever- be safe for a picky intermediary t= o allow a reference to pass it, given that it couldn’t control what l= ocation the LR would ultimately get from it? Moreover, what if the creator = of the reference authorizes the end recipient (the PSAP) but not the interm= ediary that wants to judge location information? I think we’d need to= look further into the motivations here to understand the underlying requir= ement.

Practically speaking, however, there are a number of potential work-arounds= to enable this semantic – I don’t necessarily think that once = the intermediary performs the dereference, then the location information mu= st be set in stone. If you seriously want to retain the dynamism of locatio= n information, it could become the responsibility of the compositor to deli= ver a similarly dynamic reference, and every time someone dereferences the = composed object, the compositor creates a new PIDF-LO document based on fre= shly dereferencing any dynamic components of the location information. Anot= her possibility would be to specify external references in PIDF, so we coul= d compose location information from dynamic sources by reference in the PID= F object, rather than by value. One composed object could even have a mix o= f by-value and by-reference location information in that case. The importan= t thing is that we solve this down in the PIDF level, within the parameters= of RFC4479, rather than trying to cobble together some relationship betwee= n devices, services and users in the Geolocation header.

Anyway, none of this is to suggest that this is adequately specified in the= current draft, or something. We’d need to have a more lengthy discus= sion about some of the issues above before figuring out what we’d add= , though.

Jon Peterson
NeuStar, Inc.
--_000_C8633D2041A01jonpetersonneustarbiz_-- From Martin.Thomson@andrew.com Wed Jul 14 18:31:24 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 99D5E3A68CD for ; Wed, 14 Jul 2010 18:31:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.46 X-Spam-Level: X-Spam-Status: No, score=-2.46 tagged_above=-999 required=5 tests=[AWL=0.139, 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 EmHREFeZtbQ4 for ; Wed, 14 Jul 2010 18:31:21 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id C54A33A68B9 for ; Wed, 14 Jul 2010 18:31:20 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:38191 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S27718742Ab0GOBba (ORCPT ); Wed, 14 Jul 2010 20:31:30 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Wed, 14 Jul 2010 20:31:30 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Thu, 15 Jul 2010 09:31:26 +0800 From: "Thomson, Martin" To: "Peterson, Jon" , "James M. Polk" , "sipcore@ietf.org" Date: Thu, 15 Jul 2010 09:33:32 +0800 Thread-Topic: [sipcore] location-conveyance-03 just submitted Thread-Index: Acsi+NJTa+ULYvovSE2TL/bYrSlncwAKAPJQABWWaxYADURloA== Message-ID: <8B0A9FCBB9832F43971E38010638454F03E9DCD24A@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03E9DCD1AE@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] location-conveyance-03 just 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, 15 Jul 2010 01:31:24 -0000 SGkgSm9uLA0KDQpUaGVyZeKAmXMgYSBudW1iZXIgb2YgaXNzdWVzIGhlcmUuICBJIHRoaW5rIHRo YXQgd2UgbmVlZCB0byBkaXNlbnRhbmdsZSB0aGVtLiAgVGhlIHJvbGUgb2YgdGhlIGludGVybWVk aWFyeSBpbiB0aGlzIGRlYWxpbmcgd2l0aCB0aGlzIHByb2JsZW0gaXMgYSBzZWNvbmRhcnkgY29u Y2Vybi4NCg0KVGhlcmUgYXJlIHR3byBwcmltYXJ5IHJlYXNvbnMgZm9yIGhhdmluZyBib3RoIHZh bHVlIGFuZCByZWZlcmVuY2U6IGF1dGhvcml6YXRpb24gYW5kIGR5bmFtaXNtLg0KDQpEeW5hbWlz bSBpcyB0aGUgZWFzaWVzdCBvbmUgdG8gcGluIGRvd24uICBJdCdzIG9idmlvdXNseSB2ZXJ5IGlt cG9ydGFudCB0byB0aGUgZW1lcmdlbmN5IHNjZW5hcmlvIC0gdGhlIGFiaWxpdHkgb2YgYSBQU0FQ IHRvIGFjcXVpcmUgdXBkYXRlZCBsb2NhdGlvbiBpbmZvcm1hdGlvbiBpbiBhIHRpbWVseSBmYXNo aW9uIGlzIGNlbnRyYWwgdG8gbWFueSBvZiB0aGVpciB1c2UgY2FzZXMuDQoNCmRyYWZ0LWVjcml0 LXJvdWdoLWxvYyBkZXNjcmliZXMgYSBzY2VuYXJpbyB3aGVyZSB0aGUgVUFDIGlzIGxlc3MgYXV0 aG9yaXplZCB0aGFuIHRoZSBVQVM7IGludGVybWVkaWFyaWVzIGFyZSBhdXRob3JpemVkIGRpZmZl cmVudGx5LiAgSW4gdGhlIGNhbm9uaWNhbCBleGFtcGxlLCB0aGUgVUFTIGdldHMgYSBydWJiaXNo IGxvY2F0aW9uIHZhbHVlIGFuZCBhIGxvY2F0aW9uIHJlZmVyZW5jZSB0aGF0IHRoZXkgY2FuJ3Qg dXNlLiAgVGhlIHJ1YmJpc2ggbG9jYXRpb24gaXMgZW5vdWdoIHRvIGdldCB0aGVtIHRvIGEgUFNB UC4gIFRoZSBQU0FQIHVzZXMgdGhlIHJlZmVyZW5jZSBiZWNhdXNlIHRoZXkgYXJlIGF1dGhvcml6 ZWQuDQoNCkluIGVpdGhlciBjYXNlLCBpdCdzIHBvc3NpYmxlIHRvIGxlYXZlIHRoZSBpbnRlcm1l ZGlhcnkgb3V0IG9mIGNvbnNpZGVyYXRpb24gYW5kIGNvbmNlbnRyYXRlIG9uIHRoZSBpbmZvcm1h dGlvbiB0aGF0IHRoZSBVQUMgcHJvdmlkZXMuICBUaGUgZ3JlYXQgdGhpbmcgd2l0aCB0aGUgc29s dXRpb24gdGhhdCB5b3UndmUgcHJvcG9zZWQgaXMgdGhhdCB0aGlzIGlzIHVsdGltYXRlbHkgd2hh dCBoYXBwZW5zIGluIGFueSBjYXNlLiAgTGVhdmluZyB0aGUgYjJidWEgY2FzZSBhc2lkZSwgdGhl IFVBQyBpcyB1bHRpbWF0ZWx5IHJlc3BvbnNpYmxlIGZvciB3aGF0IEdlb2xvY2F0aW9uIGlzIHBs YWNlZCBpbiB0aGUgcmVxdWVzdC4NCg0KVGhlIGludGVyYWN0aW9ucyB3aXRoIHRoZSBpbnRlcm1l ZGlhcnkgYWRkIGNvbXBsZXhpdHkgdG8gdGhlIHNjZW5hcmlvLCBpbmNsdWRpbmcgc29tZSBwcml2 YWN5IG1vZGVsIHByb2JsZW1zLCBwcmltYXJpbHkgd2l0aCByZXRyYW5zbWlzc2lvbi4gIEknZCBs aWtlIHRvIHNvbHZlIHRoZSBlYXNpZXIgcHJvYmxlbSBmaXJzdC4NCg0KLS1NYXJ0aW4NCg0KDQpG cm9tOiBQZXRlcnNvbiwgSm9uIFttYWlsdG86am9uLnBldGVyc29uQG5ldXN0YXIuYml6XSANClNl bnQ6IFRodXJzZGF5LCAxNSBKdWx5IDIwMTAgMzowOSBBTQ0KVG86IFRob21zb24sIE1hcnRpbjsg SmFtZXMgTS4gUG9sazsgc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBs b2NhdGlvbi1jb252ZXlhbmNlLTAzIGp1c3Qgc3VibWl0dGVkDQoNCg0KW3NuaXBdDQo+IFdlIG1l YW4gdG8gaGF2ZSB0aGUgaW50ZXJtZWRpYXJ5IGRvIHRoZQ0KPiBkZXJlZmVyZW5jZSAoaWYgb25l IGlzIG5lZWRlZCkgYW5kIGNvbXBvc2UgaW4gdGhlDQo+IFNJUCA0MjQgcmVzcG9uc2UgYSBNSU1F IGJvZHkgd2l0aCBib3RoIHRoZQ0KPiBzZXJ2ZXIncyB2ZXJzaW9uIG9yIGJvdGggbG9jYXRpb25z IG9mIHRoZSBUYXJnZXQsDQo+IGFuZCBmb3IgdGhhdCBkdWFsIGxvY2F0aW9uIHNpbmdsZSBwcmVz ZW5jZQ0KPiBkb2N1bWVudCB0byBiZSBjb3BpZWQgaW50byB0aGUgbmV4dCBTSVAgcmVxdWVzdA0K PiBmcm9tIHRoYXQgVUFDICh0b3dhcmRzIHRoYXQgc2FtZSBpbnRlcm1lZGlhcnkpLg0KDQpFbGVn YW50IGFzIGl0IGlzLCB0aGlzIGp1c3QgZG9lc24ndCB3b3JrLiDCoFRoZSBVQVMgKFBTQVAsIExS LCBldGMuLi4pIG5lZWRzIHRvIGJlIHRoZSBlbnRpdHkgdGhhdCBkb2VzIHRoZSBkZXJlZmVyZW5j ZS4gwqBUaGV5IG5lZWQgdG8gZG8gdGhpcyBiZWNhdXNlIHRoZXkga25vdyBob3cgKGFuZCB3aGVu KSB0byBtYWtlIHRoaXMgcmVxdWVzdCBzbyB0aGF0IHRoZXkgZ2V0IHRoZSBpbmZvcm1hdGlvbiB0 aGV5IG5lZWQuIMKgSWYgdGhlIGludGVybWVkaWFyeSBkb2VzIHRoZSBkZXJlZmVyZW5jZSwgdGhl biBsb2NhdGlvbiBpbmZvcm1hdGlvbiBpcyBzZXQgaW4gc3RvbmUgZnJvbSB0aGF0IHBvaW50IG9u d2FyZC4NCg0KPEpGUD4gSSBzZWUgeW91ciBwb2ludCwgYnV0IEkgdGhpbmsgdGhlIGRpZmZpY3Vs dHkgaXMgZGVlcGVyIHN0aWxsIHRoYW4gdGhpcy4gVGhlIHdob2xlIHVzZSBjYXNlIGZvciBhbiBp bnRlcm1lZGlhcnkgcHJvdmlkaW5nIGRpZmZlcmVudCAob3Igc3VwcGxlbWVudGFyeSkgbG9jYXRp b24gaW5mb3JtYXRpb24gYWJvdmUgYW5kIGJleW9uZCB0aGUgbG9jYXRpb24gcHJvdmlkZWQgYnkg dGhlIFVBQyBpcyBiYXNlZCBvbiB0aGUgaW50ZXJtZWRpYXJ5IGluc3BlY3RpbmcsIGFuZCBkaXNs aWtpbmcsIHRoZSBsb2NhdGlvbiBwcmVzZW50IGluIHRoZSByZXF1ZXN0LiBJZiB0aGF0IGxvY2F0 aW9uIGlzIGNvbnN0YW50bHkgY2hhbmdpbmcsIHdoYXQgd291bGQgaXQgbWVhbiBmb3IgdGhlIGlu dGVybWVkaWFyeSB0byBkaXNsaWtlIGl0PyBNYXliZSBpdCBsaWtlcyBpdCBvbmUgbWludXRlIGFu ZCBub3QgdGhlIG5leHQ/IFdvdWxkIGl0IOKAk2V2ZXItIGJlIHNhZmUgZm9yIGEgcGlja3kgaW50 ZXJtZWRpYXJ5IHRvIGFsbG93IGEgcmVmZXJlbmNlIHRvIHBhc3MgaXQsIGdpdmVuIHRoYXQgaXQg Y291bGRu4oCZdCBjb250cm9sIHdoYXQgbG9jYXRpb24gdGhlIExSIHdvdWxkIHVsdGltYXRlbHkg Z2V0IGZyb20gaXQ/IE1vcmVvdmVyLCB3aGF0IGlmIHRoZSBjcmVhdG9yIG9mIHRoZSByZWZlcmVu Y2UgYXV0aG9yaXplcyB0aGUgZW5kIHJlY2lwaWVudCAodGhlIFBTQVApIGJ1dCBub3QgdGhlIGlu dGVybWVkaWFyeSB0aGF0IHdhbnRzIHRvIGp1ZGdlIGxvY2F0aW9uIGluZm9ybWF0aW9uPyBJIHRo aW5rIHdl4oCZZCBuZWVkIHRvIGxvb2sgZnVydGhlciBpbnRvIHRoZSBtb3RpdmF0aW9ucyBoZXJl IHRvIHVuZGVyc3RhbmQgdGhlIHVuZGVybHlpbmcgcmVxdWlyZW1lbnQuDQoNClByYWN0aWNhbGx5 IHNwZWFraW5nLCBob3dldmVyLCB0aGVyZSBhcmUgYSBudW1iZXIgb2YgcG90ZW50aWFsIHdvcmst YXJvdW5kcyB0byBlbmFibGUgdGhpcyBzZW1hbnRpYyDigJMgSSBkb27igJl0IG5lY2Vzc2FyaWx5 IHRoaW5rIHRoYXQgb25jZSB0aGUgaW50ZXJtZWRpYXJ5IHBlcmZvcm1zIHRoZSBkZXJlZmVyZW5j ZSwgdGhlbiB0aGUgbG9jYXRpb24gaW5mb3JtYXRpb24gbXVzdCBiZSBzZXQgaW4gc3RvbmUuIElm IHlvdSBzZXJpb3VzbHkgd2FudCB0byByZXRhaW4gdGhlIGR5bmFtaXNtIG9mIGxvY2F0aW9uIGlu Zm9ybWF0aW9uLCBpdCBjb3VsZCBiZWNvbWUgdGhlIHJlc3BvbnNpYmlsaXR5IG9mIHRoZSBjb21w b3NpdG9yIHRvIGRlbGl2ZXIgYSBzaW1pbGFybHkgZHluYW1pYyByZWZlcmVuY2UsIGFuZCBldmVy eSB0aW1lIHNvbWVvbmUgZGVyZWZlcmVuY2VzIHRoZSBjb21wb3NlZCBvYmplY3QsIHRoZSBjb21w b3NpdG9yIGNyZWF0ZXMgYSBuZXcgUElERi1MTyBkb2N1bWVudCBiYXNlZCBvbiBmcmVzaGx5IGRl cmVmZXJlbmNpbmcgYW55IGR5bmFtaWMgY29tcG9uZW50cyBvZiB0aGUgbG9jYXRpb24gaW5mb3Jt YXRpb24uIEFub3RoZXIgcG9zc2liaWxpdHkgd291bGQgYmUgdG8gc3BlY2lmeSBleHRlcm5hbCBy ZWZlcmVuY2VzIGluIFBJREYsIHNvIHdlIGNvdWxkIGNvbXBvc2UgbG9jYXRpb24gaW5mb3JtYXRp b24gZnJvbSBkeW5hbWljIHNvdXJjZXMgYnkgcmVmZXJlbmNlIGluIHRoZSBQSURGIG9iamVjdCwg cmF0aGVyIHRoYW4gYnkgdmFsdWUuIE9uZSBjb21wb3NlZCBvYmplY3QgY291bGQgZXZlbiBoYXZl IGEgbWl4IG9mIGJ5LXZhbHVlIGFuZCBieS1yZWZlcmVuY2UgbG9jYXRpb24gaW5mb3JtYXRpb24g aW4gdGhhdCBjYXNlLiBUaGUgaW1wb3J0YW50IHRoaW5nIGlzIHRoYXQgd2Ugc29sdmUgdGhpcyBk b3duIGluIHRoZSBQSURGIGxldmVsLCB3aXRoaW4gdGhlIHBhcmFtZXRlcnMgb2YgUkZDNDQ3OSwg cmF0aGVyIHRoYW4gdHJ5aW5nIHRvIGNvYmJsZSB0b2dldGhlciBzb21lIHJlbGF0aW9uc2hpcCBi ZXR3ZWVuIGRldmljZXMsIHNlcnZpY2VzIGFuZCB1c2VycyBpbiB0aGUgR2VvbG9jYXRpb24gaGVh ZGVyLg0KDQpBbnl3YXksIG5vbmUgb2YgdGhpcyBpcyB0byBzdWdnZXN0IHRoYXQgdGhpcyBpcyBh ZGVxdWF0ZWx5IHNwZWNpZmllZCBpbiB0aGUgY3VycmVudCBkcmFmdCwgb3Igc29tZXRoaW5nLiBX ZeKAmWQgbmVlZCB0byBoYXZlIGEgbW9yZSBsZW5ndGh5IGRpc2N1c3Npb24gYWJvdXQgc29tZSBv ZiB0aGUgaXNzdWVzIGFib3ZlIGJlZm9yZSBmaWd1cmluZyBvdXQgd2hhdCB3ZeKAmWQgYWRkLCB0 aG91Z2guDQoNCkpvbiBQZXRlcnNvbg0KTmV1U3RhciwgSW5jLg0K From fmenard@xittel.net Wed Jul 14 18:47:58 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C5A813A6830 for ; Wed, 14 Jul 2010 18:47:58 -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 wo3AxWZ+4m0B for ; Wed, 14 Jul 2010 18:47:57 -0700 (PDT) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 944DA3A67B3 for ; Wed, 14 Jul 2010 18:47:57 -0700 (PDT) Received: from relay.infoteck.qc.ca ([205.151.16.15]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1OZDYR-0005nC-Td; Wed, 14 Jul 2010 21:48:04 -0400 Received: from [207.96.236.60] (helo=[192.168.3.252]) by relay.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1OZDYR-0005yN-A5; Wed, 14 Jul 2010 21:48:03 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Francois Menard In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E9DCD24A@SISPE7MB1.commscope.com> Date: Wed, 14 Jul 2010 21:47:59 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B0A9FCBB9832F43971E38010638454F03E9DCD1AE@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F03E9DCD24A@SISPE7MB1.commscope.com> To: "Thomson, Martin" X-Mailer: Apple Mail (2.1081) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] location-conveyance-03 just 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, 15 Jul 2010 01:47:58 -0000 I've challenged the Canadian PSAPs to put their NG-911 use cases in = writing. This is being met with fierce resistance at this time. Has anyone made an IETF draft of NG-9-1-1 PSAP use cases ? I'm thinking of adding digitally-signed-by-the-PSAP ALI data in ENUM and = allowing PSAP access to Carrier ENUM. Why allowing PSAPs to fetch MSAG-dispatcheable from Carrier ENUM records = be a good idea ? Regards, F. On 2010-07-14, at 9:33 PM, Thomson, Martin wrote: > Hi Jon, >=20 > There=92s a number of issues here. I think that we need to = disentangle them. The role of the intermediary in this dealing with = this problem is a secondary concern. >=20 > There are two primary reasons for having both value and reference: = authorization and dynamism. >=20 > Dynamism is the easiest one to pin down. It's obviously very = important to the emergency scenario - the ability of a PSAP to acquire = updated location information in a timely fashion is central to many of = their use cases. >=20 > draft-ecrit-rough-loc describes a scenario where the UAC is less = authorized than the UAS; intermediaries are authorized differently. In = the canonical example, the UAS gets a rubbish location value and a = location reference that they can't use. The rubbish location is enough = to get them to a PSAP. The PSAP uses the reference because they are = authorized. >=20 > In either case, it's possible to leave the intermediary out of = consideration and concentrate on the information that the UAC provides. = The great thing with the solution that you've proposed is that this is = ultimately what happens in any case. Leaving the b2bua case aside, the = UAC is ultimately responsible for what Geolocation is placed in the = request. >=20 > The interactions with the intermediary add complexity to the scenario, = including some privacy model problems, primarily with retransmission. = I'd like to solve the easier problem first. >=20 > --Martin >=20 >=20 > From: Peterson, Jon [mailto:jon.peterson@neustar.biz]=20 > Sent: Thursday, 15 July 2010 3:09 AM > To: Thomson, Martin; James M. Polk; sipcore@ietf.org > Subject: Re: [sipcore] location-conveyance-03 just submitted >=20 >=20 > [snip] >> We mean to have the intermediary do the >> dereference (if one is needed) and compose in the >> SIP 424 response a MIME body with both the >> server's version or both locations of the Target, >> and for that dual location single presence >> document to be copied into the next SIP request >> from that UAC (towards that same intermediary). >=20 > Elegant as it is, this just doesn't work. The UAS (PSAP, LR, etc...) = needs to be the entity that does the dereference. They need to do this = because they know how (and when) to make this request so that they get = the information they need. If the intermediary does the dereference, = then location information is set in stone from that point onward. >=20 > I see your point, but I think the difficulty is deeper still = than this. The whole use case for an intermediary providing different = (or supplementary) location information above and beyond the location = provided by the UAC is based on the intermediary inspecting, and = disliking, the location present in the request. If that location is = constantly changing, what would it mean for the intermediary to dislike = it? Maybe it likes it one minute and not the next? Would it =96ever- be = safe for a picky intermediary to allow a reference to pass it, given = that it couldn=92t control what location the LR would ultimately get = from it? Moreover, what if the creator of the reference authorizes the = end recipient (the PSAP) but not the intermediary that wants to judge = location information? I think we=92d need to look further into the = motivations here to understand the underlying requirement. >=20 > Practically speaking, however, there are a number of potential = work-arounds to enable this semantic =96 I don=92t necessarily think = that once the intermediary performs the dereference, then the location = information must be set in stone. If you seriously want to retain the = dynamism of location information, it could become the responsibility of = the compositor to deliver a similarly dynamic reference, and every time = someone dereferences the composed object, the compositor creates a new = PIDF-LO document based on freshly dereferencing any dynamic components = of the location information. Another possibility would be to specify = external references in PIDF, so we could compose location information = from dynamic sources by reference in the PIDF object, rather than by = value. One composed object could even have a mix of by-value and = by-reference location information in that case. The important thing is = that we solve this down in the PIDF level, within the parameters of = RFC4479, rather than trying to cobble together some relationship between = devices, services and users in the Geolocation header. >=20 > Anyway, none of this is to suggest that this is adequately specified = in the current draft, or something. We=92d need to have a more lengthy = discussion about some of the issues above before figuring out what we=92d = add, though. >=20 > Jon Peterson > NeuStar, Inc. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From gonzalo.camarillo@ericsson.com Thu Jul 15 03:26:05 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3A1E43A698D for ; Thu, 15 Jul 2010 03:26:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.887 X-Spam-Level: X-Spam-Status: No, score=-103.887 tagged_above=-999 required=5 tests=[AWL=-1.288, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZLRNhDIh-aBP for ; Thu, 15 Jul 2010 03:26:03 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 95E0D3A68C7 for ; Thu, 15 Jul 2010 03:26:03 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-3c-4c3ee245cbd1 Received: from esealmw127.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 04.04.06895.542EE3C4; Thu, 15 Jul 2010 12:26:13 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jul 2010 12:26:13 +0200 Received: from [131.160.126.225] ([131.160.126.225]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 15 Jul 2010 12:26:12 +0200 Message-ID: <4C3EE244.8040909@ericsson.com> Date: Thu, 15 Jul 2010 13:26:12 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: Gonzalo Camarillo References: <4C317D02.2030307@ericsson.com> In-Reply-To: <4C317D02.2030307@ericsson.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 15 Jul 2010 10:26:12.0666 (UTC) FILETIME=[260919A0:01CB2408] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 15 Jul 2010 10:26:05 -0000 Hi, thanks for the feedback I have received on and off list. We seem to have consensus on reducing the scope of the draft to session state and target refreshes. That is great because it allows us to hugely simplify the rules to avoid glare conditions (this is something a few of you have requested on the list in the past). I have put together a new revision of the draft, which you can fetch from: http://users.piuha.net/gonzalo/temp/draft-ietf-sipcore-reinvite-pre05-01.txt In addition to adjusting the scope of the draft and simplifying the glare-related rules, I have also added a few clarifications to Section 5 in response to Robert's AD review. Let me know if you have any comments. Thanks, Gonzalo On 05/07/2010 9:34 AM, Gonzalo Camarillo wrote: > Hi, > > the re-INVITE draft talks about modifications in the session state, > dialog state, and the dialog's remote target. While it is relatively > well understood what we mean by session state and the dialog's remote > target, we do not really have a good definition for dialog state. > > We have discussed it in the past and what people had in mind were things > such as called party identity. However, the draft is too vague at this > point; it should be more precise regarding which piece of "dialog state" > the rules in the draft apply to. > > My suggestion would be to have the draft talk only about session state > and the dialog's remote target, and forget about any other dialog state. > New extensions whose parameters can be modified by re-INVITEs can > specify their own rules, possibly referring to this draft and using the > rules defined in it by reference. In this way, the applicability of this > draft would be much clearer. > > Comments? > > Thanks, > > Gonzalo > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From fluffy@cisco.com Thu Jul 15 05:29:23 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1456A3A6976 for ; Thu, 15 Jul 2010 05:29:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -109.906 X-Spam-Level: X-Spam-Status: No, score=-109.906 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, DATE_IN_PAST_06_12=1.069, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7LmOx71RzaLU for ; Thu, 15 Jul 2010 05:29:22 -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 EC7313A685F for ; Thu, 15 Jul 2010 05:29:21 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlUFACecPkyrR7Hu/2dsb2JhbAAwnzdxowWafoJWAYJNBIN+hFI X-IronPort-AV: E=Sophos;i="4.55,208,1278288000"; d="scan'208";a="158927871" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 15 Jul 2010 12:29:32 +0000 Received: from [192.168.4.2] (rcdn-fluffy-8711.cisco.com [10.99.9.18]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6FCTP9V018255; Thu, 15 Jul 2010 12:29:32 GMT Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Cullen Jennings In-Reply-To: <8EA04371-7637-49D3-BB6B-0676F642638B@ntt-at.com> Date: Wed, 14 Jul 2010 18:48:15 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8EA04371-7637-49D3-BB6B-0676F642638B@ntt-at.com> To: Shida Schubert X-Mailer: Apple Mail (2.1081) Cc: SIPCORE Subject: Re: [sipcore] ECO(energy-saving) device and response code X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 15 Jul 2010 12:29:23 -0000 How about a new code 101 "Device is making coffee to wake up" On serious note, my gut feeling is we should consider a new 1xx response = code that includes a header that provides expected amount of time before = the real response will be sent. On Jun 21, 2010, at 23:10 , Shida Schubert wrote: >=20 > We have a device from several vendors on our test bed (and=20 > will be deployed in near future) that goes into sleep mode=20 > (energy saving mode) when standing by.=20 >=20 > It takes about 10 seconds for these devices to wake up and=20 > although it can't process the SDP and other parameters in=20 > INVITE while resuming, it can be configured to send a=20 > response.=20 >=20 > Question is what response should be sent to=20 > indicate to the caller the following semantics. >=20 > "device on the callee side is waking up to decide=20 > whether it can handle the call or if it's interested in=20 > picking up the call at all".=20 >=20 > The response code that kind of match the semantic=20 > is the 182 "Queued", based on the definition in RFC3261=20 > or 183 "Session Progress" but we can't seem to come to=20 > agreement internally, so I was hoping to get some opinions=20 > on this..=20 >=20 > ** >=20 > 21.1.4 182 Queued >=20 > The called party is temporarily unavailable, but the server has > decided to queue the call rather than reject it. When the callee > becomes available, it will return the appropriate final status > response. The reason phrase MAY give further details about the > status of the call, for example, "5 calls queued; expected waiting > time is 15 minutes". The server MAY issue several 182 (Queued) > responses to update the caller about the status of the queued call. =20= >=20 > ** >=20 > If none of the currently defined response code is=20 > suitable semantically, would it be viable to define a new=20 > response code for this, I personally don't think so but=20 > as we may see more and more of devices like this in the=20 > future, may be? >=20 > Another option is I guess is to use current 18x + Alert-Info URN to=20 > indicate what's happening on the callee side. >=20 > Regards > Shida >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore Cullen Jennings For corporate legal information go to: http://www.cisco.com/web/about/doing_business/legal/cri/index.html From RMarshall@telecomsys.com Thu Jul 15 15:56:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F2A33A679F for ; Thu, 15 Jul 2010 15:56:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_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 QM0lnFksg6SO for ; Thu, 15 Jul 2010 15:56:28 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [199.165.246.12]) by core3.amsl.com (Postfix) with ESMTP id B6D223A69D3 for ; Thu, 15 Jul 2010 15:56:28 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Thu, 15 Jul 2010 15:56:22 -0700 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, 15 Jul 2010 15:56:20 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A6575135CDD92@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E9DCD24A@SISPE7MB1.commscope.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] location-conveyance-03 just submitted Thread-Index: Acsi+NJTa+ULYvovSE2TL/bYrSlncwAKAPJQABWWaxYADURloAAvdkeA References: <8B0A9FCBB9832F43971E38010638454F03E9DCD1AE@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F03E9DCD24A@SISPE7MB1.commscope.com> From: "Roger Marshall" To: "Thomson, Martin" , "Peterson, Jon" , "James M. Polk" , Subject: Re: [sipcore] location-conveyance-03 just 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, 15 Jul 2010 22:56:31 -0000 QWxsOg0KTXkgdW5kZXJzdGFuZGluZyBvZiB3aGF0IHRoaXMgY29udmV5YW5jZS0wMyBkcmFmdCBu b3cgYWxsb3dzIGZvciBpcyBzdXBwb3J0IG9mIGxvY2F0aW9uIGluIHRlcm1zIG9mOg0KDQpMYnlW IGlmIHRoZSBnZW9sb2NhdGlvbiBoZWFkZXIgY29udGFpbnMgYSBjaWQgVVJJIHdoaWNoIHBvaW50 cyB0byBhIFBJREYtTE8gaW4gdGhlIGJvZHkNCk9yDQpMYnlSIGlmIHRoZSBnZW9sb2NhdGlvbiBo ZWFkZXIgY29udGFpbnMgYSBsb2NhdGlvbiBVUkkgDQpPciANCkJvdGggTGJ5ViAmIExieVIgX29u bHlfIGlmIHRoZSBQSURGLUxPIHRoYXQgdGhlIGNpZCBVUkkgcG9pbnRzIHRvIGFsc28gaW5jbHVk ZXMgYW4gImFzc29jaWF0ZWQiIExvY2F0aW9uIFVSSSB3aXRoaW4uICBUaGlzIGlzIHdoYXQgSSBh c3N1bWUgaXMgdGhlIGNvbXBvc2l0ZSBjYXNlLg0KDQpJZiB0aGlzIGlzIGhvdyBpdCdzIGludGVu ZGVkIHRvIHdvcmssIGhvdyB0aGVuIHdvdWxkIHJvdXRpbmcgYmUgYWNjb21wbGlzaGVkIGlmIHRo ZSBpbnRlbnRpb24gd2FzIHRvIHJvdXRlIG9uIGxvY2F0aW9uIFVSSSwgbm90IExieVY/DQoNClRo ZSBnZW9sb2NhdGlvbiBoZWFkZXIgcGFyYW1ldGVyIHZhbHVlIG9mICJyb3V0aW5nLWFsbG93ZWQi IGNhbiBvbmx5IGJlIHllcyBvciBubyBwb2ludGluZyB0byB0aGUgd2hvbGUgUElERi1MTzoNCg0K W2Zyb20gLTAzXQ0KICAgVGhlIHByYWN0aWNhbCBpbXBsaWNhdGlvbiBpcyB0aGF0IHdoZW4gdGhl ICJyb3V0aW5nLWFsbG93ZWQiDQogICBwYXJhbWV0ZXIgaXMgc2V0IHRvICJubyIsIGlmIGEgY2lk OnVybCBpcyBwcmVzZW50IGluIHRoZSBTSVANCiAgIHJlcXVlc3QsIGludGVybWVkaWFyaWVzIE1V U1QgTk9UIHZpZXcgdGhlIGxvY2F0aW9uIChiZWNhdXNlIGl0IGlzDQogICBub3QgZm9yIGludGVy bWVkaWFyaWVzIHRvIHZpZXcpLCBhbmQgaWYgYSBsb2NhdGlvbiBVUkkgaXMgcHJlc2VudCwNCiAg IGludGVybWVkaWFyaWVzIE1VU1QgTk9UIGRlcmVmZXJlbmNlIGl0LiAgVUFzIGFyZSBhbGxvd2Vk IHRvIHZpZXcNCiAgIGxvY2F0aW9uIGluIHRoZSBTSVAgcmVxdWVzdCBldmVuIHdoZW4gdGhlICJy b3V0aW5nLWFsbG93ZWQiDQogICBwYXJhbWV0ZXIgaXMgc2V0IHRvICJubyIuICBBbiBMUiBNVVNU IGJ5IGRlZmF1bHQgY29uc2lkZXIgdGhlDQogICAicm91dGluZy1hbGxvd2VkIiBoZWFkZXIgcGFy YW1ldGVyIGFzIHNldCB0byAibm8iLCB3aXRoIG5vDQogICBleGNlcHRpb25zLCB1bmxlc3MgdGhl IGhlYWRlciBmaWVsZCB2YWx1ZSBpcyBzZXQgdG8gInllcyIuDQoNCkl0IHNlZW1zIHRvIG1lIHRo YXQgYSBiZXR0ZXIgd2F5IGlzIHRvIGFsbG93IGdlb2xvY2F0aW9uIFVSSXMgaW4gbnVtYmVycyBv ZiAwLCAxLCBvciAyLCBzbyB0aGF0IHlvdSBjb3VsZCBlbGV2YXRlIHRoZSBMb2NhdGlvbiBVUkkg dXAgdG8gdGhlIGdlb2xvY2F0aW9uIGhlYWRlciBhbmQgYXZvaWQgYWxsIHRoZSBkaWZmaWN1bHRp ZXMgb2Ygbm90IGtub3dpbmcgd2hhdCBsb2NhdGlvbiBmb3JtIHdhcyByb3V0YWJsZSwgcGx1cyBl c2NhcGUgdGhlIG92ZXJoZWFkIG9mIGVtYmVkZGluZyBpdCBpbnRvIGFuIG90aGVyd2lzZSBlbXB0 eSBQSURGLUxPIHdoZW4gdXNpbmcgTGJ5UiBleGNsdXNpdmVseS4NCg0KUmVnYXJkcywNCg0KLXJv Z2VyIG1hcnNoYWxsLg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBzaXBj b3JlLWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9u IEJlaGFsZiBPZiBUaG9tc29uLCBNYXJ0aW4NClNlbnQ6IFdlZG5lc2RheSwgSnVseSAxNCwgMjAx MCA2OjM0IFBNDQpUbzogUGV0ZXJzb24sIEpvbjsgSmFtZXMgTS4gUG9sazsgc2lwY29yZUBpZXRm Lm9yZw0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBsb2NhdGlvbi1jb252ZXlhbmNlLTAzIGp1c3Qg c3VibWl0dGVkDQoNCkhpIEpvbiwNCg0KVGhlcmXigJlzIGEgbnVtYmVyIG9mIGlzc3VlcyBoZXJl LiAgSSB0aGluayB0aGF0IHdlIG5lZWQgdG8gZGlzZW50YW5nbGUgdGhlbS4gIFRoZSByb2xlIG9m IHRoZSBpbnRlcm1lZGlhcnkgaW4gdGhpcyBkZWFsaW5nIHdpdGggdGhpcyBwcm9ibGVtIGlzIGEg c2Vjb25kYXJ5IGNvbmNlcm4uDQoNClRoZXJlIGFyZSB0d28gcHJpbWFyeSByZWFzb25zIGZvciBo YXZpbmcgYm90aCB2YWx1ZSBhbmQgcmVmZXJlbmNlOiBhdXRob3JpemF0aW9uIGFuZCBkeW5hbWlz bS4NCg0KRHluYW1pc20gaXMgdGhlIGVhc2llc3Qgb25lIHRvIHBpbiBkb3duLiAgSXQncyBvYnZp b3VzbHkgdmVyeSBpbXBvcnRhbnQgdG8gdGhlIGVtZXJnZW5jeSBzY2VuYXJpbyAtIHRoZSBhYmls aXR5IG9mIGEgUFNBUCB0byBhY3F1aXJlIHVwZGF0ZWQgbG9jYXRpb24gaW5mb3JtYXRpb24gaW4g YSB0aW1lbHkgZmFzaGlvbiBpcyBjZW50cmFsIHRvIG1hbnkgb2YgdGhlaXIgdXNlIGNhc2VzLg0K DQpkcmFmdC1lY3JpdC1yb3VnaC1sb2MgZGVzY3JpYmVzIGEgc2NlbmFyaW8gd2hlcmUgdGhlIFVB QyBpcyBsZXNzIGF1dGhvcml6ZWQgdGhhbiB0aGUgVUFTOyBpbnRlcm1lZGlhcmllcyBhcmUgYXV0 aG9yaXplZCBkaWZmZXJlbnRseS4gIEluIHRoZSBjYW5vbmljYWwgZXhhbXBsZSwgdGhlIFVBUyBn ZXRzIGEgcnViYmlzaCBsb2NhdGlvbiB2YWx1ZSBhbmQgYSBsb2NhdGlvbiByZWZlcmVuY2UgdGhh dCB0aGV5IGNhbid0IHVzZS4gIFRoZSBydWJiaXNoIGxvY2F0aW9uIGlzIGVub3VnaCB0byBnZXQg dGhlbSB0byBhIFBTQVAuICBUaGUgUFNBUCB1c2VzIHRoZSByZWZlcmVuY2UgYmVjYXVzZSB0aGV5 IGFyZSBhdXRob3JpemVkLg0KDQpJbiBlaXRoZXIgY2FzZSwgaXQncyBwb3NzaWJsZSB0byBsZWF2 ZSB0aGUgaW50ZXJtZWRpYXJ5IG91dCBvZiBjb25zaWRlcmF0aW9uIGFuZCBjb25jZW50cmF0ZSBv biB0aGUgaW5mb3JtYXRpb24gdGhhdCB0aGUgVUFDIHByb3ZpZGVzLiAgVGhlIGdyZWF0IHRoaW5n IHdpdGggdGhlIHNvbHV0aW9uIHRoYXQgeW91J3ZlIHByb3Bvc2VkIGlzIHRoYXQgdGhpcyBpcyB1 bHRpbWF0ZWx5IHdoYXQgaGFwcGVucyBpbiBhbnkgY2FzZS4gIExlYXZpbmcgdGhlIGIyYnVhIGNh c2UgYXNpZGUsIHRoZSBVQUMgaXMgdWx0aW1hdGVseSByZXNwb25zaWJsZSBmb3Igd2hhdCBHZW9s b2NhdGlvbiBpcyBwbGFjZWQgaW4gdGhlIHJlcXVlc3QuDQoNClRoZSBpbnRlcmFjdGlvbnMgd2l0 aCB0aGUgaW50ZXJtZWRpYXJ5IGFkZCBjb21wbGV4aXR5IHRvIHRoZSBzY2VuYXJpbywgaW5jbHVk aW5nIHNvbWUgcHJpdmFjeSBtb2RlbCBwcm9ibGVtcywgcHJpbWFyaWx5IHdpdGggcmV0cmFuc21p c3Npb24uICBJJ2QgbGlrZSB0byBzb2x2ZSB0aGUgZWFzaWVyIHByb2JsZW0gZmlyc3QuDQoNCi0t TWFydGluDQoNCg0KRnJvbTogUGV0ZXJzb24sIEpvbiBbbWFpbHRvOmpvbi5wZXRlcnNvbkBuZXVz dGFyLmJpel0gDQpTZW50OiBUaHVyc2RheSwgMTUgSnVseSAyMDEwIDM6MDkgQU0NClRvOiBUaG9t c29uLCBNYXJ0aW47IEphbWVzIE0uIFBvbGs7IHNpcGNvcmVAaWV0Zi5vcmcNClN1YmplY3Q6IFJl OiBbc2lwY29yZV0gbG9jYXRpb24tY29udmV5YW5jZS0wMyBqdXN0IHN1Ym1pdHRlZA0KDQoNCltz bmlwXQ0KPiBXZSBtZWFuIHRvIGhhdmUgdGhlIGludGVybWVkaWFyeSBkbyB0aGUNCj4gZGVyZWZl cmVuY2UgKGlmIG9uZSBpcyBuZWVkZWQpIGFuZCBjb21wb3NlIGluIHRoZQ0KPiBTSVAgNDI0IHJl c3BvbnNlIGEgTUlNRSBib2R5IHdpdGggYm90aCB0aGUNCj4gc2VydmVyJ3MgdmVyc2lvbiBvciBi b3RoIGxvY2F0aW9ucyBvZiB0aGUgVGFyZ2V0LA0KPiBhbmQgZm9yIHRoYXQgZHVhbCBsb2NhdGlv biBzaW5nbGUgcHJlc2VuY2UNCj4gZG9jdW1lbnQgdG8gYmUgY29waWVkIGludG8gdGhlIG5leHQg U0lQIHJlcXVlc3QNCj4gZnJvbSB0aGF0IFVBQyAodG93YXJkcyB0aGF0IHNhbWUgaW50ZXJtZWRp YXJ5KS4NCg0KRWxlZ2FudCBhcyBpdCBpcywgdGhpcyBqdXN0IGRvZXNuJ3Qgd29yay4gwqBUaGUg VUFTIChQU0FQLCBMUiwgZXRjLi4uKSBuZWVkcyB0byBiZSB0aGUgZW50aXR5IHRoYXQgZG9lcyB0 aGUgZGVyZWZlcmVuY2UuIMKgVGhleSBuZWVkIHRvIGRvIHRoaXMgYmVjYXVzZSB0aGV5IGtub3cg aG93IChhbmQgd2hlbikgdG8gbWFrZSB0aGlzIHJlcXVlc3Qgc28gdGhhdCB0aGV5IGdldCB0aGUg aW5mb3JtYXRpb24gdGhleSBuZWVkLiDCoElmIHRoZSBpbnRlcm1lZGlhcnkgZG9lcyB0aGUgZGVy ZWZlcmVuY2UsIHRoZW4gbG9jYXRpb24gaW5mb3JtYXRpb24gaXMgc2V0IGluIHN0b25lIGZyb20g dGhhdCBwb2ludCBvbndhcmQuDQoNCjxKRlA+IEkgc2VlIHlvdXIgcG9pbnQsIGJ1dCBJIHRoaW5r IHRoZSBkaWZmaWN1bHR5IGlzIGRlZXBlciBzdGlsbCB0aGFuIHRoaXMuIFRoZSB3aG9sZSB1c2Ug Y2FzZSBmb3IgYW4gaW50ZXJtZWRpYXJ5IHByb3ZpZGluZyBkaWZmZXJlbnQgKG9yIHN1cHBsZW1l bnRhcnkpIGxvY2F0aW9uIGluZm9ybWF0aW9uIGFib3ZlIGFuZCBiZXlvbmQgdGhlIGxvY2F0aW9u IHByb3ZpZGVkIGJ5IHRoZSBVQUMgaXMgYmFzZWQgb24gdGhlIGludGVybWVkaWFyeSBpbnNwZWN0 aW5nLCBhbmQgZGlzbGlraW5nLCB0aGUgbG9jYXRpb24gcHJlc2VudCBpbiB0aGUgcmVxdWVzdC4g SWYgdGhhdCBsb2NhdGlvbiBpcyBjb25zdGFudGx5IGNoYW5naW5nLCB3aGF0IHdvdWxkIGl0IG1l YW4gZm9yIHRoZSBpbnRlcm1lZGlhcnkgdG8gZGlzbGlrZSBpdD8gTWF5YmUgaXQgbGlrZXMgaXQg b25lIG1pbnV0ZSBhbmQgbm90IHRoZSBuZXh0PyBXb3VsZCBpdCDigJNldmVyLSBiZSBzYWZlIGZv ciBhIHBpY2t5IGludGVybWVkaWFyeSB0byBhbGxvdyBhIHJlZmVyZW5jZSB0byBwYXNzIGl0LCBn aXZlbiB0aGF0IGl0IGNvdWxkbuKAmXQgY29udHJvbCB3aGF0IGxvY2F0aW9uIHRoZSBMUiB3b3Vs ZCB1bHRpbWF0ZWx5IGdldCBmcm9tIGl0PyBNb3Jlb3Zlciwgd2hhdCBpZiB0aGUgY3JlYXRvciBv ZiB0aGUgcmVmZXJlbmNlIGF1dGhvcml6ZXMgdGhlIGVuZCByZWNpcGllbnQgKHRoZSBQU0FQKSBi dXQgbm90IHRoZSBpbnRlcm1lZGlhcnkgdGhhdCB3YW50cyB0byBqdWRnZSBsb2NhdGlvbiBpbmZv cm1hdGlvbj8gSSB0aGluayB3ZeKAmWQgbmVlZCB0byBsb29rIGZ1cnRoZXIgaW50byB0aGUgbW90 aXZhdGlvbnMgaGVyZSB0byB1bmRlcnN0YW5kIHRoZSB1bmRlcmx5aW5nIHJlcXVpcmVtZW50Lg0K DQpQcmFjdGljYWxseSBzcGVha2luZywgaG93ZXZlciwgdGhlcmUgYXJlIGEgbnVtYmVyIG9mIHBv dGVudGlhbCB3b3JrLWFyb3VuZHMgdG8gZW5hYmxlIHRoaXMgc2VtYW50aWMg4oCTIEkgZG9u4oCZ dCBuZWNlc3NhcmlseSB0aGluayB0aGF0IG9uY2UgdGhlIGludGVybWVkaWFyeSBwZXJmb3JtcyB0 aGUgZGVyZWZlcmVuY2UsIHRoZW4gdGhlIGxvY2F0aW9uIGluZm9ybWF0aW9uIG11c3QgYmUgc2V0 IGluIHN0b25lLiBJZiB5b3Ugc2VyaW91c2x5IHdhbnQgdG8gcmV0YWluIHRoZSBkeW5hbWlzbSBv ZiBsb2NhdGlvbiBpbmZvcm1hdGlvbiwgaXQgY291bGQgYmVjb21lIHRoZSByZXNwb25zaWJpbGl0 eSBvZiB0aGUgY29tcG9zaXRvciB0byBkZWxpdmVyIGEgc2ltaWxhcmx5IGR5bmFtaWMgcmVmZXJl bmNlLCBhbmQgZXZlcnkgdGltZSBzb21lb25lIGRlcmVmZXJlbmNlcyB0aGUgY29tcG9zZWQgb2Jq ZWN0LCB0aGUgY29tcG9zaXRvciBjcmVhdGVzIGEgbmV3IFBJREYtTE8gZG9jdW1lbnQgYmFzZWQg b24gZnJlc2hseSBkZXJlZmVyZW5jaW5nIGFueSBkeW5hbWljIGNvbXBvbmVudHMgb2YgdGhlIGxv Y2F0aW9uIGluZm9ybWF0aW9uLiBBbm90aGVyIHBvc3NpYmlsaXR5IHdvdWxkIGJlIHRvIHNwZWNp ZnkgZXh0ZXJuYWwgcmVmZXJlbmNlcyBpbiBQSURGLCBzbyB3ZSBjb3VsZCBjb21wb3NlIGxvY2F0 aW9uIGluZm9ybWF0aW9uIGZyb20gZHluYW1pYyBzb3VyY2VzIGJ5IHJlZmVyZW5jZSBpbiB0aGUg UElERiBvYmplY3QsIHJhdGhlciB0aGFuIGJ5IHZhbHVlLiBPbmUgY29tcG9zZWQgb2JqZWN0IGNv dWxkIGV2ZW4gaGF2ZSBhIG1peCBvZiBieS12YWx1ZSBhbmQgYnktcmVmZXJlbmNlIGxvY2F0aW9u IGluZm9ybWF0aW9uIGluIHRoYXQgY2FzZS4gVGhlIGltcG9ydGFudCB0aGluZyBpcyB0aGF0IHdl IHNvbHZlIHRoaXMgZG93biBpbiB0aGUgUElERiBsZXZlbCwgd2l0aGluIHRoZSBwYXJhbWV0ZXJz IG9mIFJGQzQ0NzksIHJhdGhlciB0aGFuIHRyeWluZyB0byBjb2JibGUgdG9nZXRoZXIgc29tZSBy ZWxhdGlvbnNoaXAgYmV0d2VlbiBkZXZpY2VzLCBzZXJ2aWNlcyBhbmQgdXNlcnMgaW4gdGhlIEdl b2xvY2F0aW9uIGhlYWRlci4NCg0KQW55d2F5LCBub25lIG9mIHRoaXMgaXMgdG8gc3VnZ2VzdCB0 aGF0IHRoaXMgaXMgYWRlcXVhdGVseSBzcGVjaWZpZWQgaW4gdGhlIGN1cnJlbnQgZHJhZnQsIG9y IHNvbWV0aGluZy4gV2XigJlkIG5lZWQgdG8gaGF2ZSBhIG1vcmUgbGVuZ3RoeSBkaXNjdXNzaW9u IGFib3V0IHNvbWUgb2YgdGhlIGlzc3VlcyBhYm92ZSBiZWZvcmUgZmlndXJpbmcgb3V0IHdoYXQg d2XigJlkIGFkZCwgdGhvdWdoLg0KDQpKb24gUGV0ZXJzb24NCk5ldVN0YXIsIEluYy4NCl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxp bmcgbGlzdA0Kc2lwY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9s aXN0aW5mby9zaXBjb3JlDQoNCkNPTkZJREVOVElBTElUWSBOT1RJQ0U6IFRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIG1heSBiZSBwcml2aWxlZ2VkIGFuZC9vciBjb25m aWRlbnRpYWwuIElmIHlvdSBhcmUgbm90IHRoZSBpbnRlbmRlZCByZWNpcGllbnQsIG9yIHJlc3Bv bnNpYmxlIGZvciBkZWxpdmVyaW5nIHRoaXMgbWVzc2FnZSB0byB0aGUgaW50ZW5kZWQgcmVjaXBp ZW50LCBhbnkgcmV2aWV3LCBmb3J3YXJkaW5nLCBkaXNzZW1pbmF0aW9uLCBkaXN0cmlidXRpb24g b3IgY29weWluZyBvZiB0aGlzIGNvbW11bmljYXRpb24gb3IgYW55IGF0dGFjaG1lbnQocykgaXMg c3RyaWN0bHkgcHJvaGliaXRlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBtZXNzYWdlIGlu IGVycm9yLCBwbGVhc2Ugbm90aWZ5IHRoZSBzZW5kZXIgaW1tZWRpYXRlbHksIGFuZCBkZWxldGUg aXQgYW5kIGFsbCBhdHRhY2htZW50cyBmcm9tIHlvdXIgY29tcHV0ZXIgYW5kIG5ldHdvcmsuDQo= From James.Winterbottom@andrew.com Thu Jul 15 16:39:16 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 960473A6982 for ; Thu, 15 Jul 2010 16:39:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 RYAROqAkjrgd for ; Thu, 15 Jul 2010 16:39:15 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 0FEBB3A67E5 for ; Thu, 15 Jul 2010 16:39:15 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:928 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S337050Ab0GOXjZ convert rfc822-to-8bit (ORCPT ); Thu, 15 Jul 2010 18:39:25 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 15 Jul 2010 18:39:25 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 16 Jul 2010 07:39:22 +0800 From: "Winterbottom, James" To: Roger Marshall , "Thomson, Martin" , "Peterson, Jon" , "James M. Polk" , "sipcore@ietf.org" Date: Fri, 16 Jul 2010 07:39:21 +0800 Thread-Topic: [sipcore] location-conveyance-03 just submitted Thread-Index: Acsi+NJTa+ULYvovSE2TL/bYrSlncwAKAPJQABWWaxYADURloAAvdkeAAAMwlBA= Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120E7BC053C@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03E9DCD1AE@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F03E9DCD24A@SISPE7MB1.commscope.com> <8C837214C95C864C9F34F3635C2A6575135CDD92@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <8C837214C95C864C9F34F3635C2A6575135CDD92@SEA-EXCHVS-2.telecomsys.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: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [sipcore] location-conveyance-03 just 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, 15 Jul 2010 23:39:16 -0000 I support Roger's proposal. > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf > Of Roger Marshall > Sent: Friday, 16 July 2010 8:56 AM > To: Thomson, Martin; Peterson, Jon; James M. Polk; sipcore@ietf.org > Subject: Re: [sipcore] location-conveyance-03 just submitted > > All: > My understanding of what this conveyance-03 draft now allows for is > support of location in terms of: > > LbyV if the geolocation header contains a cid URI which points to a PIDF- > LO in the body > Or > LbyR if the geolocation header contains a location URI > Or > Both LbyV & LbyR _only_ if the PIDF-LO that the cid URI points to also > includes an "associated" Location URI within. This is what I assume is > the composite case. > > If this is how it's intended to work, how then would routing be > accomplished if the intention was to route on location URI, not LbyV? > > The geolocation header parameter value of "routing-allowed" can only be > yes or no pointing to the whole PIDF-LO: > > [from -03] > The practical implication is that when the "routing-allowed" > parameter is set to "no", if a cid:url is present in the SIP > request, intermediaries MUST NOT view the location (because it is > not for intermediaries to view), and if a location URI is present, > intermediaries MUST NOT dereference it. UAs are allowed to view > location in the SIP request even when the "routing-allowed" > parameter is set to "no". An LR MUST by default consider the > "routing-allowed" header parameter as set to "no", with no > exceptions, unless the header field value is set to "yes". > > It seems to me that a better way is to allow geolocation URIs in numbers > of 0, 1, or 2, so that you could elevate the Location URI up to the > geolocation header and avoid all the difficulties of not knowing what > location form was routable, plus escape the overhead of embedding it into > an otherwise empty PIDF-LO when using LbyR exclusively. > > Regards, > > -roger marshall. > From Martin.Thomson@andrew.com Thu Jul 15 23:02:33 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3EA03A689D for ; Thu, 15 Jul 2010 23:02:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 ax+6d134UTre for ; Thu, 15 Jul 2010 23:02:31 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 1ACC33A67A4 for ; Thu, 15 Jul 2010 23:02:30 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:57050 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S27861662Ab0GPGCl (ORCPT ); Fri, 16 Jul 2010 01:02:41 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Fri, 16 Jul 2010 01:02:41 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 16 Jul 2010 14:02:37 +0800 From: "Thomson, Martin" To: "sipcore@ietf.org" Date: Fri, 16 Jul 2010 14:04:42 +0800 Thread-Topic: location conveyance ABNF Thread-Index: AcskrMgeF2JN1WX8SFeYF8iLZSaiGA== Message-ID: <8B0A9FCBB9832F43971E38010638454F03E9DCD3DD@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {8DE34B42-A8FE-451F-991C-4D2E6717D737} x-cr-hashedpuzzle: Bg5G BwsR C0mx DmYE Eiwc EyVA FDxa FExl H/ym ItAr JBDe JB32 J+sq Kj9c K1G9 K+2z; 1; cwBpAHAAYwBvAHIAZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {8DE34B42-A8FE-451F-991C-4D2E6717D737}; bQBhAHIAdABpAG4ALgB0AGgAbwBtAHMAbwBuAEAAYQBuAGQAcgBlAHcALgBjAG8AbQA=; Fri, 16 Jul 2010 06:04:42 GMT;bABvAGMAYQB0AGkAbwBuACAAYwBvAG4AdgBlAHkAYQBuAGMAZQAgAEEAQgBOAEYA acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: [sipcore] location conveyance ABNF X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 16 Jul 2010 06:02:33 -0000 SSd2ZSBiZWVuIGxvb2tpbmcgYXQgdGhlIEFCTkYgaW4gZHJhZnQtaWV0Zi1zaXBjb3JlLWxvY2F0 aW9uLWNvbnZleWFuY2UtMDMgYW5kIGl0IGxvb2tzIGxpa2UgaXQgY291bGQgdXNlIGEgbGl0dGxl IGNsZWFuaW5nIHVwLg0KDQpJZiB0aGUgaW50ZW50IGlzIHRvIGhhdmUgYSBsb2NhdGlvblZhbHVl LCBhIHJvdXRpbmctcGFyYW0sIG9yIGJvdGgsIHRoZW4gdGhpcyBpcyB0aGUgY29ycmVjdCBmb3Jt Og0KDQogICBHZW9sb2NhdGlvbi1oZWFkZXIgPSAiR2VvbG9jYXRpb24iIEhDT0xPTiBHZW9sb2Nh dGlvbi12YWx1ZQ0KICAgR2VvbG9jYXRpb24tdmFsdWUgID0gKCBsb2NhdGlvblZhbHVlIFsgQ09N TUEgcm91dGluZy1wYXJhbSBdICkNCiAgICAgICAgICAgICAgICAgICAgICAgIC8gcm91dGluZy1w YXJhbQ0KDQpJZiB0aGUgaW50ZW50IGlzIHRvIHJlcXVpcmUgdXNlIG9mIGNvbnRlbnQgaW5kaXJl Y3Rpb24gKFJGQyA0NDgzKSwgdGhlbiB0aGVyZSBpcyBubyBuZWVkIHRvIHN1cHBvcnQgZGlmZmVy ZW50IFVSSSBzY2hlbWVzIGhlcmUuDQoNCiAgIGxvY2F0aW9uVmFsdWUgICAgICA9ICBMQVFVT1Qg Y2lkLXVybCBSQVFVT1QgKihTRU1JIGdlb2xvYy1wYXJhbSkNCiAgICAgICAgICAgICAgICAgICAg ICAgICA7IGNpZC11cmwgZnJvbSBSRkMgMjM5Mg0KDQpIb3dldmVyLCBpdCBtaWdodCBiZSBiZXR0 ZXIgdG8gYWxsb3cgZm9yIGEgbGl0dGxlIG1vcmUgZmxleGliaWxpdHkuDQoNCiAgIGxvY2F0aW9u VmFsdWUgICAgICA9ICBMQVFVT1QgbG9jYXRpb25VUkkgUkFRVU9UICooU0VNSSBnZW9sb2MtcGFy YW0pDQogICBsb2NhdGlvblVSSSAgICAgICAgPSAgY2lkLXVybCAvIGFic29sdXRlVVJJDQogICAg ICAgICAgICAgICAgICAgICAgICAgOyBjaWQtdXJsIGZyb20gUkZDIDIzOTIsIGFic29sdXRlVVJJ IGZyb20gUkZDIDM5ODYNCg0KSSBkb24ndCBrbm93IHdoYXQgdGhlIGltcGxpY2F0aW9ucyBvZiBy ZWZlcmVuY2luZyBSRkMgMzk4NiBpcywgYnV0IGl0IHNlZW1zIG1vcmUgYXBwcm9wcmlhdGUgdGhh biB0aGUgZGVmaW5pdGlvbiBpbiBSRkMgMzI2MSwgd2hpY2ggc2VlbXMgdG8gY29weSBmcm9tIFJG QyAxNzM4Lg0KDQpHZW9sb2NhdGlvbi1FcnJvciBpcyBPSywgYnV0IGl0IG1pZ2h0IGJlIHNob3J0 ZXIgLSB0aGUgbG9jYXRpb25FcnJvclZhbHVlIHJ1bGUgYWRkcyBubyB2YWx1ZS4gIEknZCBhbHNv IHVzZSB0ZXh0IHRvIG5vdGUgdGhhdCB0aGlzIGJ1aWxkcyBvbiB0aGUgc3ludGF4IGRlZmluZWQg aW4gUkZDIDMyNjEsIHJhdGhlciB0aGFuIGlkZW50aWZ5aW5nIGVhY2ggcnVsZSBmcm9tIHRoZSAz MjYxIEFCTkYgaW5kaXZpZHVhbGx5Lg0KDQogICBHZW9sb2NhdGlvbi1FcnJvciAgICAgICAgPSAi R2VvbG9jYXRpb24tRXJyb3IiIEhDT0xPTiBsb2NhdGlvbi1lcnJvci1hcmcNCiAgIGxvY2F0aW9u LWVycm9yLWFyZyAgICAgICA9IGxvY2F0aW9uLWVycm9yLWNvZGUNCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAqKFNFTUkgbG9jYXRpb24tZXJyb3ItcGFyYW1zKQ0KICAgbG9jYXRpb24t ZXJyb3ItY29kZSAgICAgID0gMSozRElHSVQNCiAgIGxvY2F0aW9uLWVycm9yLXBhcmFtcyAgICA9 IGxvY2F0aW9uLWVycm9yLWNvZGUtdGV4dCAvIGdlbmVyaWMtcGFyYW0NCiAgIGxvY2F0aW9uLWVy cm9yLWNvZGUtdGV4dCA9ICJjb2RlIiBFUVVBTCBxdW90ZWQtc3RyaW5nDQoNCg== From Martin.Thomson@andrew.com Thu Jul 15 23:19:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7192F3A689D for ; Thu, 15 Jul 2010 23:19:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.591 X-Spam-Level: X-Spam-Status: No, score=-2.591 tagged_above=-999 required=5 tests=[AWL=0.008, 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 qxhOr+nZznQD for ; Thu, 15 Jul 2010 23:19:54 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 879D43A67A4 for ; Thu, 15 Jul 2010 23:19:54 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:27657 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S334666Ab0GPGUF (ORCPT ); Fri, 16 Jul 2010 01:20:05 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Fri, 16 Jul 2010 01:20:05 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 16 Jul 2010 14:20:03 +0800 From: "Thomson, Martin" To: "sipcore@ietf.org" Date: Fri, 16 Jul 2010 14:22:09 +0800 Thread-Topic: location conveyance and error "code" parameter Thread-Index: AcskrziNSpxIhLlDR4WoiYs47ll9sw== Message-ID: <8B0A9FCBB9832F43971E38010638454F03E9DCD3E4@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: [sipcore] location conveyance and error "code" parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 16 Jul 2010 06:19:55 -0000 VHdvIHJlbGF0ZWQgbm9uLUFCTkYgcXVlc3Rpb25zIGFib3V0IHRoZSAiY29kZSIgcGFyYW1ldGVy IGluIHRoZSBHZW9sb2NhdGlvbi1FcnJvciBoZWFkZXIgdGhhdCBJIHRob3VnaHQgd291bGQgYmUg YmV0dGVyIHNlcGFyYXRlZDoNCg0KMS4gV2h5IGlzIGNhbGxlZCAiY29kZSIgaWYgaXQgY29udGFp bnMgdGV4dD8gIFRoZSBhY3R1YWwgY29kZSAobG9jYXRpb24tZXJyb3ItY29kZSkgaXMgdGhlIDMg ZGlnaXQgdmFsdWUuICBJdCBtaWdodCBiZSBjb25mdXNpbmcgdGFsa2luZyBhYm91dCB0aGUgImdl b2xvY2F0aW9uIGVycm9yIGNvZGUiLiAgV291bGQgaXQgYmUgYmV0dGVyIG5hbWVkIHRvICJtZXNz YWdlIj8NCg0KMi4gSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwgdGhlICJjb2RlIiBwYXJhbWV0 ZXIgaGFzIGEgdmFsdWUgdGhhdCBpcyBmaXhlZCBiYXNlZCBvbiB0aGUgMyBkaWdpdCBjb2RlLiAg QSBmaXhlZCBtZXNzYWdlIGRvZXNuJ3QgYWRkIGFueSB2YWx1ZSBbMV0uICBJZiBhIGh1bWFuIHJl YWRhYmxlIG1lc3NhZ2UgaXMgcmVxdWlyZWQsIHRoZW4gYWxsb3dpbmcgZm9yIGFyYml0cmFyeSBj b250ZW50IHdvdWxkIGJlIG1vcmUgbGlrZWx5IHRvIGJlIHVzZWZ1bC4NClRoZSBleGlzdGluZyBz dHJpbmdzIGFyZSB1c2VmdWwgYXMgdGl0bGVzIGZvciB0aGUgY29kZXMsIGJ1dCB0aGF0J3MgYWxs Lg0KDQotLU1hcnRpbg0KDQpbMV0gU2VlIGRpc2N1c3Npb24gaW4gYSByZWNlbnQgbWVldGluZyBv biB0aGlzIHN1YmplY3QuDQoNCg0K From jon.peterson@neustar.biz Thu Jul 15 23:54:46 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 265DE3A6872 for ; Thu, 15 Jul 2010 23:54:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.277 X-Spam-Level: X-Spam-Status: No, score=-101.277 tagged_above=-999 required=5 tests=[AWL=-1.321, BAYES_05=-1.11, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, J_CHICKENPOX_33=0.6, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lgfNcLWuWy7r for ; Thu, 15 Jul 2010 23:54:32 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 1BE463A67AE for ; Thu, 15 Jul 2010 23:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1279263274; x=1594611293; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=sp6DbBqPJ5wxX01PVFFK0neitpzFk9WeLxEUk23hbVo=; b=JeqWI1uKxBoR7qZ5+3SCQR+yCLdE05AWf0NVUXlwdA+5hSKgPPBIGWSCmgCTh9 5rw9Kt2OtXgddWJy7d2REg4A== Received: from ([10.31.13.242]) by stihiron2.va.neustar.com with ESMTP with TLS id 5202732.34706162; Fri, 16 Jul 2010 02:54:32 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Fri, 16 Jul 2010 02:54:32 -0400 From: "Peterson, Jon" To: Roger Marshall , "Thomson, Martin" , "James M. Polk" , "sipcore@ietf.org" Date: Fri, 16 Jul 2010 02:54:26 -0400 Thread-Topic: [sipcore] location-conveyance-03 just submitted Thread-Index: Acsi+NJTa+ULYvovSE2TL/bYrSlncwAKAPJQABWWaxYADURloAAvdkeAABJoDoQ= Message-ID: In-Reply-To: <8C837214C95C864C9F34F3635C2A6575135CDD92@SEA-EXCHVS-2.telecomsys.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: WGUSaPd/ccE4+4OdO1k1cQ== Content-Type: multipart/alternative; boundary="_000_C865503241B60jonpetersonneustarbiz_" MIME-Version: 1.0 Subject: Re: [sipcore] location-conveyance-03 just 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, 16 Jul 2010 06:54:46 -0000 --_000_C865503241B60jonpetersonneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable In the corner case (and I do think it is a corner case) where multiple enti= ties are contributing different location information to a single SIP reques= t, I think we face a fundamental architecture choice in this mechanism: eit= her it is SIP's job to sort out how we understand those different locations= , or it is PIDF's job. Traditionally, PIDF's understanding of different so= urces of presence that provide potentially contradictory information relies= on the presence data model (RFC4479), which is designed to reconcile condi= tions like the one where my mobile phone thinks I am available but my deskt= op thinks I'm offline. The presence data model moreover differentiates betw= een users, services and devices in a way that is useful and apparently appl= icable to location information. I am not eager to try to replicate this in = SIP headers, including by inserting multiple such headers, putting in marku= p that tries to explain the "source" of location information in SIP headers= , and so on. SIP's job should be to convey the location object - fundamenta= lly, the further we diverge from "conveyance" and enter into the realm of "= integration," the less comfortable I get. I understand that the subsequent use case where there are different sources= of location information, some of which are LbrV and some of which are LbyR= , looks like a hairy one. This is, however, a corner case of a corner case= . I really do not feel comfortable justifying the allowance of multiple loc= ation headers in SIP pointing to different presence objects (as opposed to = following the presence data model) to carry the 0, 1 or 2 different locatio= ns due to a corner case of a corner case. As I said in my previous mail to = Martin, I'm not really sure I even understand the requirements for an inter= mediary to evaluate and reject LbyR, nor what the best way is for presence = from these dynamic sources to be composed. If we were to investigate the ri= ght way for presence from those source to be composed, it might very well b= e that it is the responsibility of the compositor to insert an LbyR into th= e SIP request (into the Geolocation header), and to poll and compose a cohe= rent PIDF document from its dynamic and static sources - that is probably t= he approach that most closely parallels the traditional approaches to prese= nce. But we haven't even begun to explore this yet. No one insisting that t= here will be "empty" PIDF documents just containing references to external = PIDF documents or something. Something along those lines is one approach of= many that we would consider if we tried to figure out how to address this = in PIDF. The question we need to decide, as I said above, is the architectu= re one - is SIP's job to convey PIDF documents, or to compose them? Jon Peterson NeuStar, Inc. On 7/15/10 3:56 PM, "Roger Marshall" wrote: All: My understanding of what this conveyance-03 draft now allows for is support= of location in terms of: LbyV if the geolocation header contains a cid URI which points to a PIDF-LO= in the body Or LbyR if the geolocation header contains a location URI Or Both LbyV & LbyR _only_ if the PIDF-LO that the cid URI points to also incl= udes an "associated" Location URI within. This is what I assume is the com= posite case. If this is how it's intended to work, how then would routing be accomplishe= d if the intention was to route on location URI, not LbyV? The geolocation header parameter value of "routing-allowed" can only be yes= or no pointing to the whole PIDF-LO: [from -03] The practical implication is that when the "routing-allowed" parameter is set to "no", if a cid:url is present in the SIP request, intermediaries MUST NOT view the location (because it is not for intermediaries to view), and if a location URI is present, intermediaries MUST NOT dereference it. UAs are allowed to view location in the SIP request even when the "routing-allowed" parameter is set to "no". An LR MUST by default consider the "routing-allowed" header parameter as set to "no", with no exceptions, unless the header field value is set to "yes". It seems to me that a better way is to allow geolocation URIs in numbers of= 0, 1, or 2, so that you could elevate the Location URI up to the geolocati= on header and avoid all the difficulties of not knowing what location form = was routable, plus escape the overhead of embedding it into an otherwise em= pty PIDF-LO when using LbyR exclusively. Regards, -roger marshall. -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf = Of Thomson, Martin Sent: Wednesday, July 14, 2010 6:34 PM To: Peterson, Jon; James M. Polk; sipcore@ietf.org Subject: Re: [sipcore] location-conveyance-03 just submitted Hi Jon, There's a number of issues here. I think that we need to disentangle them.= The role of the intermediary in this dealing with this problem is a secon= dary concern. There are two primary reasons for having both value and reference: authoriz= ation and dynamism. Dynamism is the easiest one to pin down. It's obviously very important to = the emergency scenario - the ability of a PSAP to acquire updated location = information in a timely fashion is central to many of their use cases. draft-ecrit-rough-loc describes a scenario where the UAC is less authorized= than the UAS; intermediaries are authorized differently. In the canonical= example, the UAS gets a rubbish location value and a location reference th= at they can't use. The rubbish location is enough to get them to a PSAP. = The PSAP uses the reference because they are authorized. In either case, it's possible to leave the intermediary out of consideratio= n and concentrate on the information that the UAC provides. The great thin= g with the solution that you've proposed is that this is ultimately what ha= ppens in any case. Leaving the b2bua case aside, the UAC is ultimately res= ponsible for what Geolocation is placed in the request. The interactions with the intermediary add complexity to the scenario, incl= uding some privacy model problems, primarily with retransmission. I'd like= to solve the easier problem first. --Martin From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Thursday, 15 July 2010 3:09 AM To: Thomson, Martin; James M. Polk; sipcore@ietf.org Subject: Re: [sipcore] location-conveyance-03 just submitted [snip] > We mean to have the intermediary do the > dereference (if one is needed) and compose in the > SIP 424 response a MIME body with both the > server's version or both locations of the Target, > and for that dual location single presence > document to be copied into the next SIP request > from that UAC (towards that same intermediary). Elegant as it is, this just doesn't work. The UAS (PSAP, LR, etc...) needs= to be the entity that does the dereference. They need to do this because = they know how (and when) to make this request so that they get the informat= ion they need. If the intermediary does the dereference, then location inf= ormation is set in stone from that point onward. I see your point, but I think the difficulty is deeper still than thi= s. The whole use case for an intermediary providing different (or supplemen= tary) location information above and beyond the location provided by the UA= C is based on the intermediary inspecting, and disliking, the location pres= ent in the request. If that location is constantly changing, what would it = mean for the intermediary to dislike it? Maybe it likes it one minute and n= ot the next? Would it -ever- be safe for a picky intermediary to allow a re= ference to pass it, given that it couldn't control what location the LR wou= ld ultimately get from it? Moreover, what if the creator of the reference a= uthorizes the end recipient (the PSAP) but not the intermediary that wants = to judge location information? I think we'd need to look further into the m= otivations here to understand the underlying requirement. Practically speaking, however, there are a number of potential work-arounds= to enable this semantic - I don't necessarily think that once the intermed= iary performs the dereference, then the location information must be set in= stone. If you seriously want to retain the dynamism of location informatio= n, it could become the responsibility of the compositor to deliver a simila= rly dynamic reference, and every time someone dereferences the composed obj= ect, the compositor creates a new PIDF-LO document based on freshly derefer= encing any dynamic components of the location information. Another possibil= ity would be to specify external references in PIDF, so we could compose lo= cation information from dynamic sources by reference in the PIDF object, ra= ther than by value. One composed object could even have a mix of by-value a= nd by-reference location information in that case. The important thing is t= hat we solve this down in the PIDF level, within the parameters of RFC4479,= rather than trying to cobble together some relationship between devices, s= ervices and users in the Geolocation header. Anyway, none of this is to suggest that this is adequately specified in the= current draft, or something. We'd need to have a more lengthy discussion a= bout some of the issues above before figuring out what we'd add, though. Jon Peterson NeuStar, Inc. _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network. --_000_C865503241B60jonpetersonneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [sipcore] location-conveyance-03 just submitted
In the corner case (and I do think it is a corner case) where multiple enti= ties are contributing different location information to a single SIP reques= t, I think we face a fundamental architecture choice in this mechanism: eit= her it is SIP’s job to sort out how we understand those different loc= ations, or it is PIDF’s job.  Traditionally, PIDF’s unders= tanding of different sources of presence that provide potentially contradic= tory information relies on the presence data model (RFC4479), which is desi= gned to reconcile conditions like the one where my mobile phone thinks I am= available but my desktop thinks I’m offline. The presence data model= moreover differentiates between users, services and devices in a way that = is useful and apparently applicable to location information. I am not eager= to try to replicate this in SIP headers, including by inserting multiple s= uch headers, putting in markup that tries to explain the “source̶= 1; of location information in SIP headers, and so on. SIP’s job shoul= d be to convey the location object – fundamentally, the further we di= verge from “conveyance” and enter into the realm of “inte= gration,” the less comfortable I get.

I understand that the subsequent use case where there are different sources= of location information, some of which are LbrV and some of which are LbyR= , looks like a  hairy one. This is, however, a corner case of a corner= case. I really do not feel comfortable justifying the allowance of multipl= e location headers in SIP pointing to different presence objects (as oppose= d to following the presence data model) to carry the 0, 1 or 2 different lo= cations due to a corner case of a corner case. As I said in my previous mai= l to Martin, I’m not really sure I even understand the requirements f= or an intermediary to evaluate and reject LbyR, nor what the best way is fo= r presence from these dynamic sources to be composed. If we were to investi= gate the right way for presence from those source to be composed, it might = very well be that it is the responsibility of the compositor to insert an L= byR into the SIP request (into the Geolocation header), and to poll and com= pose a coherent PIDF document from its dynamic and static sources – t= hat is probably the approach that most closely parallels the traditional ap= proaches to presence. But we haven’t even begun to explore this yet. = No one insisting that there will be “empty” PIDF documents just= containing references to external PIDF documents or something. Something a= long those lines is one approach of many that we would consider if we tried= to figure out how to address this in PIDF. The question we need to decide,= as I said above, is the architecture one – is SIP’s job to con= vey PIDF documents, or to compose them?

Jon Peterson
NeuStar, Inc.

On 7/15/10 3:56 PM, "Roger Marshall" <RMarshall@telecomsys.com> wrote:

All:
My understanding of what this conveyance-03 draft now allows for is support= of location in terms of:

LbyV if the geolocation header contains a cid URI which points to a PIDF-LO= in the body
Or
LbyR if the geolocation header contains a location URI
Or
Both LbyV & LbyR _only_ if the PIDF-LO that the cid URI points to also = includes an "associated" Location URI within.  This is what = I assume is the composite case.

If this is how it's intended to work, how then would routing be accomplishe= d if the intention was to route on location URI, not LbyV?

The geolocation header parameter value of "routing-allowed" can o= nly be yes or no pointing to the whole PIDF-LO:

[from -03]
   The practical implication is that when the "routing-= allowed"
   parameter is set to "no", if a cid:url is prese= nt in the SIP
   request, intermediaries MUST NOT view the location (becau= se it is
   not for intermediaries to view), and if a location URI is= present,
   intermediaries MUST NOT dereference it.  UAs are all= owed to view
   location in the SIP request even when the "routing-a= llowed"
   parameter is set to "no".  An LR MUST by d= efault consider the
   "routing-allowed" header parameter as set to &q= uot;no", with no
   exceptions, unless the header field value is set to "= ;yes".

It seems to me that a better way is to allow geolocation URIs in numbers of= 0, 1, or 2, so that you could elevate the Location URI up to the geolocati= on header and avoid all the difficulties of not knowing what location form = was routable, plus escape the overhead of embedding it into an otherwise em= pty PIDF-LO when using LbyR exclusively.

Regards,

-roger marshall.


-----Original Message-----
From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of Thomson, Martin
Sent: Wednesday, July 14, 2010 6:34 PM
To: Peterson, Jon; James M. Polk; sipcore@ietf= .org
Subject: Re: [sipcore] location-conveyance-03 just submitted

Hi Jon,

There’s a number of issues here.  I think that we need to disent= angle them.  The role of the intermediary in this dealing with this pr= oblem is a secondary concern.

There are two primary reasons for having both value and reference: authoriz= ation and dynamism.

Dynamism is the easiest one to pin down.  It's obviously very importan= t to the emergency scenario - the ability of a PSAP to acquire updated loca= tion information in a timely fashion is central to many of their use cases.=

draft-ecrit-rough-loc describes a scenario where the UAC is less authorized= than the UAS; intermediaries are authorized differently.  In the cano= nical example, the UAS gets a rubbish location value and a location referen= ce that they can't use.  The rubbish location is enough to get them to= a PSAP.  The PSAP uses the reference because they are authorized.

In either case, it's possible to leave the intermediary out of consideratio= n and concentrate on the information that the UAC provides.  The great= thing with the solution that you've proposed is that this is ultimately wh= at happens in any case.  Leaving the b2bua case aside, the UAC is ulti= mately responsible for what Geolocation is placed in the request.

The interactions with the intermediary add complexity to the scenario, incl= uding some privacy model problems, primarily with retransmission.  I'd= like to solve the easier problem first.

--Martin


From: Peterson, Jon [mailto:jon= .peterson@neustar.biz]
Sent: Thursday, 15 July 2010 3:09 AM
To: Thomson, Martin; James M. Polk; sipcore@ie= tf.org
Subject: Re: [sipcore] location-conveyance-03 just submitted


[snip]
> We mean to have the intermediary do the
> dereference (if one is needed) and compose in the
> SIP 424 response a MIME body with both the
> server's version or both locations of the Target,
> and for that dual location single presence
> document to be copied into the next SIP request
> from that UAC (towards that same intermediary).

Elegant as it is, this just doesn't work. =A0The UAS (PSAP, LR, etc...) nee= ds to be the entity that does the dereference. =A0They need to do this beca= use they know how (and when) to make this request so that they get the info= rmation they need. =A0If the intermediary does the dereference, then locati= on information is set in stone from that point onward.

<JFP> I see your point, but I think the difficulty is deeper still th= an this. The whole use case for an intermediary providing different (or sup= plementary) location information above and beyond the location provided by = the UAC is based on the intermediary inspecting, and disliking, the locatio= n present in the request. If that location is constantly changing, what wou= ld it mean for the intermediary to dislike it? Maybe it likes it one minute= and not the next? Would it –ever- be safe for a picky intermediary t= o allow a reference to pass it, given that it couldn’t control what l= ocation the LR would ultimately get from it? Moreover, what if the creator = of the reference authorizes the end recipient (the PSAP) but not the interm= ediary that wants to judge location information? I think we’d need to= look further into the motivations here to understand the underlying requir= ement.

Practically speaking, however, there are a number of potential work-arounds= to enable this semantic – I don’t necessarily think that once = the intermediary performs the dereference, then the location information mu= st be set in stone. If you seriously want to retain the dynamism of locatio= n information, it could become the responsibility of the compositor to deli= ver a similarly dynamic reference, and every time someone dereferences the = composed object, the compositor creates a new PIDF-LO document based on fre= shly dereferencing any dynamic components of the location information. Anot= her possibility would be to specify external references in PIDF, so we coul= d compose location information from dynamic sources by reference in the PID= F object, rather than by value. One composed object could even have a mix o= f by-value and by-reference location information in that case. The importan= t thing is that we solve this down in the PIDF level, within the parameters= of RFC4479, rather than trying to cobble together some relationship betwee= n devices, services and users in the Geolocation header.

Anyway, none of this is to suggest that this is adequately specified in the= current draft, or something. We’d need to have a more lengthy discus= sion about some of the issues above before figuring out what we’d add= , though.

Jon Peterson
NeuStar, Inc.
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore

CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network.

--_000_C865503241B60jonpetersonneustarbiz_-- From jmpolk@cisco.com Fri Jul 16 00:03:03 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CFC013A6843 for ; Fri, 16 Jul 2010 00:03:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.352 X-Spam-Level: X-Spam-Status: No, score=-10.352 tagged_above=-999 required=5 tests=[AWL=0.247, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bTtfmAmEvkqo for ; Fri, 16 Jul 2010 00:03:02 -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 E06043A680A for ; Fri, 16 Jul 2010 00:03:02 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAAShP0yrR7Hu/2dsb2JhbACfaXGjdJpThSQEg34 X-IronPort-AV: E=Sophos;i="4.55,213,1278288000"; d="scan'208";a="559922591" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 16 Jul 2010 07:03:13 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6G73CcX006182; Fri, 16 Jul 2010 07:03:13 GMT Message-Id: <201007160703.o6G73CcX006182@sj-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Fri, 16 Jul 2010 02:03:12 -0500 To: "Thomson, Martin" , "sipcore@ietf.org" From: "James M. Polk" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E9DCD3E4@SISPE7MB1.comms cope.com> References: <8B0A9FCBB9832F43971E38010638454F03E9DCD3E4@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] location conveyance and error "code" parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 16 Jul 2010 07:03:03 -0000 Martin in-line At 01:22 AM 7/16/2010, Thomson, Martin wrote: >Two related non-ABNF questions about the "code" parameter in the >Geolocation-Error header that I thought would be better separated: > >1. Why is called "code" if it contains text? The actual code >(location-error-code) is the 3 digit value. It might be confusing >talking about the "geolocation error code". Would it be better >named to "message"? I think "message" would be confusing as it would be different than the SIP response it was carried in (a 424 (Bad Location Information) or something else). If code is completely appalling to folks, then I think "value" could be used instead, but not "message". >2. If I understand correctly, the "code" parameter has a value that >is fixed based on the 3 digit code. A fixed message doesn't add any >value [1]. If a human readable message is required, then allowing >for arbitrary content would be more likely to be useful. >The existing strings are useful as titles for the codes, but that's all. I'm not sure I agree on this one. Most everyone knows what a 404 "Not Found" means; as a computer (rather than human) is returning your request because of what the string says. i.e., "Not Found". This make the meaning more final to humans much of the time. Anyone who's browsed has received a 404 (with the text too) and understands it. thus, if I understand what you are suggesting (and I may not) - I think both the 3 digit value and the string should be present as much as possible. That said, the string is optional, the 3 digit value, or code, is not - for a GeolocationError at least. Please let me know if I've misunderstood your point #2. James >--Martin > >[1] See discussion in a recent meeting on this subject. > > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From fmenard@xittel.net Fri Jul 16 05:43:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1CD913A69DC for ; Fri, 16 Jul 2010 05:43:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=-0.300, 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 MSAF5KseLnt0 for ; Fri, 16 Jul 2010 05:43:49 -0700 (PDT) Received: from smtp3.infoteck.qc.ca (smtp3.infoteck.qc.ca [205.151.16.19]) by core3.amsl.com (Postfix) with ESMTP id 5E52B3A6985 for ; Fri, 16 Jul 2010 05:43:49 -0700 (PDT) Received: from relay.infoteck.qc.ca ([205.151.16.15]) by smtp3.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1OZkGi-0005xN-BU; Fri, 16 Jul 2010 08:43:56 -0400 Received: from [207.96.236.60] (helo=[192.168.3.252]) by relay.infoteck.qc.ca with esmtp (Exim 4.69) (envelope-from ) id 1OZkGh-0000zo-Fm; Fri, 16 Jul 2010 08:43:56 -0400 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Francois Menard In-Reply-To: Date: Fri, 16 Jul 2010 08:43:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <994F9DFA-A692-4C08-A415-0A0B9F273FB9@xittel.net> References: To: "Peterson, Jon" X-Mailer: Apple Mail (2.1081) Cc: Roger Marshall , "sipcore@ietf.org" , "Thomson, Martin" Subject: Re: [sipcore] location-conveyance-03 just 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, 16 Jul 2010 12:43:51 -0000 I've been monitoring this thread and I think too much effort is being = made to consider 'location negotiation' inside SIP. Heck we're not even there with SDP for codec negotiation after 15 years = of having VoIP in production. With SDP, the end-point chooses ultimately what to send over RTP. It = receives advice at the SIP level, but insofar as possibly being rogue, = an end-point being told to send-in G.729, will possibly send-out G.711 = without saying so. Now, to build on this analogy, if an end-point chooses to package into = its SIP invite, several LbyV and an LbyR to accomodate the requirement = that the SIP B2BUA behind the proxy of a PSAP gets an LbyR, to perform = verification that the LbyV is really what its supposed to be, then such = interpretation of the LbyR is done by the far-end B2BUA at the PSAP. I = am not convinced that the job of the proxy at the PSAP will be to = replace an LbyR by a LbyV and that the B2BUA at the PSAP will blindly = trust what's coming from its first hop proxy over what's coming from the = far-end SIP UA at the customer premise. The requirements for this chain of trust, i.e. 1) end-user SIP UA trusting acquisition of location by say DHCPLOC 2) first hop VoIP service provider trusting PROXY that the SIP UA is = conveying the proper location (if its LbyR, then it can't authenticate), = is proper 3) last hop B2BUA at the PSAP, if it sees an LbyV added by its first hop = proxy, did this LbyV replaced the far-end LbyV learned by the end-user = SIP UA from DHCPLOC ? This does not appear to be super well documented at this time. This is why I am asking that PSAPs get together in Canada and start = ironing out their NG-911 requirements. And so far, its being met with some resistance. But we're getting going, making tis new CRTC CISC working group Task on = NG-911 PSAP requirements. Has anyone else documented what we'd like to see done or are we trying = to accommodate all possible requirements ? F. On 2010-07-16, at 2:54 AM, Peterson, Jon wrote: >=20 > In the corner case (and I do think it is a corner case) where multiple = entities are contributing different location information to a single SIP = request, I think we face a fundamental architecture choice in this = mechanism: either it is SIP=92s job to sort out how we understand those = different locations, or it is PIDF=92s job. Traditionally, PIDF=92s = understanding of different sources of presence that provide potentially = contradictory information relies on the presence data model (RFC4479), = which is designed to reconcile conditions like the one where my mobile = phone thinks I am available but my desktop thinks I=92m offline. The = presence data model moreover differentiates between users, services and = devices in a way that is useful and apparently applicable to location = information. I am not eager to try to replicate this in SIP headers, = including by inserting multiple such headers, putting in markup that = tries to explain the =93source=94 of location information in SIP = headers, and so on. SIP=92s job should be to convey the location object = =96 fundamentally, the further we diverge from =93conveyance=94 and = enter into the realm of =93integration,=94 the less comfortable I get. >=20 > I understand that the subsequent use case where there are different = sources of location information, some of which are LbrV and some of = which are LbyR, looks like a hairy one. This is, however, a corner case = of a corner case. I really do not feel comfortable justifying the = allowance of multiple location headers in SIP pointing to different = presence objects (as opposed to following the presence data model) to = carry the 0, 1 or 2 different locations due to a corner case of a corner = case. As I said in my previous mail to Martin, I=92m not really sure I = even understand the requirements for an intermediary to evaluate and = reject LbyR, nor what the best way is for presence from these dynamic = sources to be composed. If we were to investigate the right way for = presence from those source to be composed, it might very well be that it = is the responsibility of the compositor to insert an LbyR into the SIP = request (into the Geolocation header), and to poll and compose a = coherent PIDF document from its dynamic and static sources =96 that is = probably the approach that most closely parallels the traditional = approaches to presence. But we haven=92t even begun to explore this yet. = No one insisting that there will be =93empty=94 PIDF documents just = containing references to external PIDF documents or something. Something = along those lines is one approach of many that we would consider if we = tried to figure out how to address this in PIDF. The question we need to = decide, as I said above, is the architecture one =96 is SIP=92s job to = convey PIDF documents, or to compose them? >=20 > Jon Peterson > NeuStar, Inc. >=20 > On 7/15/10 3:56 PM, "Roger Marshall" wrote: >=20 > All: > My understanding of what this conveyance-03 draft now allows for is = support of location in terms of: >=20 > LbyV if the geolocation header contains a cid URI which points to a = PIDF-LO in the body > Or > LbyR if the geolocation header contains a location URI > Or > Both LbyV & LbyR _only_ if the PIDF-LO that the cid URI points to also = includes an "associated" Location URI within. This is what I assume is = the composite case. >=20 > If this is how it's intended to work, how then would routing be = accomplished if the intention was to route on location URI, not LbyV? >=20 > The geolocation header parameter value of "routing-allowed" can only = be yes or no pointing to the whole PIDF-LO: >=20 > [from -03] > The practical implication is that when the "routing-allowed" > parameter is set to "no", if a cid:url is present in the SIP > request, intermediaries MUST NOT view the location (because it is > not for intermediaries to view), and if a location URI is present, > intermediaries MUST NOT dereference it. UAs are allowed to view > location in the SIP request even when the "routing-allowed" > parameter is set to "no". An LR MUST by default consider the > "routing-allowed" header parameter as set to "no", with no > exceptions, unless the header field value is set to "yes". >=20 > It seems to me that a better way is to allow geolocation URIs in = numbers of 0, 1, or 2, so that you could elevate the Location URI up to = the geolocation header and avoid all the difficulties of not knowing = what location form was routable, plus escape the overhead of embedding = it into an otherwise empty PIDF-LO when using LbyR exclusively. >=20 > Regards, >=20 > -roger marshall. >=20 >=20 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On = Behalf Of Thomson, Martin > Sent: Wednesday, July 14, 2010 6:34 PM > To: Peterson, Jon; James M. Polk; sipcore@ietf.org > Subject: Re: [sipcore] location-conveyance-03 just submitted >=20 > Hi Jon, >=20 > There=92s a number of issues here. I think that we need to = disentangle them. The role of the intermediary in this dealing with = this problem is a secondary concern. >=20 > There are two primary reasons for having both value and reference: = authorization and dynamism. >=20 > Dynamism is the easiest one to pin down. It's obviously very = important to the emergency scenario - the ability of a PSAP to acquire = updated location information in a timely fashion is central to many of = their use cases. >=20 > draft-ecrit-rough-loc describes a scenario where the UAC is less = authorized than the UAS; intermediaries are authorized differently. In = the canonical example, the UAS gets a rubbish location value and a = location reference that they can't use. The rubbish location is enough = to get them to a PSAP. The PSAP uses the reference because they are = authorized. >=20 > In either case, it's possible to leave the intermediary out of = consideration and concentrate on the information that the UAC provides. = The great thing with the solution that you've proposed is that this is = ultimately what happens in any case. Leaving the b2bua case aside, the = UAC is ultimately responsible for what Geolocation is placed in the = request. >=20 > The interactions with the intermediary add complexity to the scenario, = including some privacy model problems, primarily with retransmission. = I'd like to solve the easier problem first. >=20 > --Martin >=20 >=20 > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Thursday, 15 July 2010 3:09 AM > To: Thomson, Martin; James M. Polk; sipcore@ietf.org > Subject: Re: [sipcore] location-conveyance-03 just submitted >=20 >=20 > [snip] > > We mean to have the intermediary do the > > dereference (if one is needed) and compose in the > > SIP 424 response a MIME body with both the > > server's version or both locations of the Target, > > and for that dual location single presence > > document to be copied into the next SIP request > > from that UAC (towards that same intermediary). >=20 > Elegant as it is, this just doesn't work. The UAS (PSAP, LR, etc...) = needs to be the entity that does the dereference. They need to do this = because they know how (and when) to make this request so that they get = the information they need. If the intermediary does the dereference, = then location information is set in stone from that point onward. >=20 > I see your point, but I think the difficulty is deeper still = than this. The whole use case for an intermediary providing different = (or supplementary) location information above and beyond the location = provided by the UAC is based on the intermediary inspecting, and = disliking, the location present in the request. If that location is = constantly changing, what would it mean for the intermediary to dislike = it? Maybe it likes it one minute and not the next? Would it =96ever- be = safe for a picky intermediary to allow a reference to pass it, given = that it couldn=92t control what location the LR would ultimately get = from it? Moreover, what if the creator of the reference authorizes the = end recipient (the PSAP) but not the intermediary that wants to judge = location information? I think we=92d need to look further into the = motivations here to understand the underlying requirement. >=20 > Practically speaking, however, there are a number of potential = work-arounds to enable this semantic =96 I don=92t necessarily think = that once the intermediary performs the dereference, then the location = information must be set in stone. If you seriously want to retain the = dynamism of location information, it could become the responsibility of = the compositor to deliver a similarly dynamic reference, and every time = someone dereferences the composed object, the compositor creates a new = PIDF-LO document based on freshly dereferencing any dynamic components = of the location information. Another possibility would be to specify = external references in PIDF, so we could compose location information = from dynamic sources by reference in the PIDF object, rather than by = value. One composed object could even have a mix of by-value and = by-reference location information in that case. The important thing is = that we solve this down in the PIDF level, within the parameters of = RFC4479, rather than trying to cobble together some relationship between = devices, services and users in the Geolocation header. >=20 > Anyway, none of this is to suggest that this is adequately specified = in the current draft, or something. We=92d need to have a more lengthy = discussion about some of the issues above before figuring out what we=92d = add, though. >=20 > Jon Peterson > NeuStar, Inc. > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 > CONFIDENTIALITY NOTICE: The information contained in this message may = be privileged and/or confidential. If you are not the intended = recipient, or responsible for delivering this message to the intended = recipient, any review, forwarding, dissemination, distribution or = copying of this communication or any attachment(s) is strictly = prohibited. If you have received this message in error, please notify = the sender immediately, and delete it and all attachments from your = computer and network. >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From rbarnes@bbn.com Fri Jul 16 06:09:16 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4BBAE3A69FF for ; Fri, 16 Jul 2010 06:09:16 -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 RvMXJpp2W5ks for ; Fri, 16 Jul 2010 06:09:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 840013A69F9 for ; Fri, 16 Jul 2010 06:09:15 -0700 (PDT) Received: from [192.1.255.159] (port=60114 helo=col-dhcp-192-1-255-159.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OZkfO-000K8X-K3; Fri, 16 Jul 2010 09:09:26 -0400 Message-Id: From: "Richard L. Barnes" To: "Thomson, Martin" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E9DCD3DD@SISPE7MB1.commscope.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 16 Jul 2010 09:09:26 -0400 References: <8B0A9FCBB9832F43971E38010638454F03E9DCD3DD@SISPE7MB1.commscope.com> X-Mailer: Apple Mail (2.936) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] location conveyance ABNF X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 16 Jul 2010 13:09:16 -0000 > However, it might be better to allow for a little more flexibility. > > locationValue = LAQUOT locationURI RAQUOT *(SEMI geoloc-param) > locationURI = cid-url / absoluteURI > ; cid-url from RFC 2392, absoluteURI from > RFC 3986 I would really like it if we could preserve this flexibility. --Richard From adam@nostrum.com Fri Jul 16 08:55:39 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 552FA3A686C for ; Fri, 16 Jul 2010 08:55:39 -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 0xrW9nQD3iHf for ; Fri, 16 Jul 2010 08:55:38 -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 1EEF93A67C2 for ; Fri, 16 Jul 2010 08:55:37 -0700 (PDT) Received: from dn3-228.estacado.net (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6GFtkZW032885 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 16 Jul 2010 10:55:48 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C408102.6010005@nostrum.com> Date: Fri, 16 Jul 2010 10:55:46 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: SIPCORE References: <4C3DC365.1060508@nostrum.com> In-Reply-To: <4C3DC365.1060508@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: draft-ietf-sipcore-keep@tools.ietf.org, "sipcore-chairs@tools.ietf.org" Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-keep X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 16 Jul 2010 15:55:39 -0000 As an addendum: if you have read the document and think it is ready for publication, please send an email to the list indicating this fact. We can't request publication if the WG hasn't taken a good look at the document. /a On 7/14/10 9:02 AM, Adam Roach wrote: > [as chair] > > The author of draft-ietf-sipcore-keep believes that the document has > no remaining open issues, and is ready to be evaluated by the IESG for > publication. Today, we begin a three-week Working Group Last Call > period, which ends on Wednesday, August 4th. (This WGLC is three weeks > instead of the more traditional two to account for the upcoming IETF > meeting). > > The latest version of the document can be retrieved here: > > http://tools.ietf.org/html/draft-ietf-sipcore-keep > > Any comments on the document should be sent to the SIPCORE mailing list. > > As a note to document reviewers: the document's author is on holiday > through August 2nd, and will respond to any direct queries after > returning. > > /a From Martin.Thomson@andrew.com Sun Jul 18 17:08:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CD6153A69B6 for ; Sun, 18 Jul 2010 17:08:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.847 X-Spam-Level: X-Spam-Status: No, score=-1.847 tagged_above=-999 required=5 tests=[AWL=-0.737, BAYES_05=-1.11] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id o-CiBm5Zyoqo for ; Sun, 18 Jul 2010 17:08:54 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id BCCC23A69B0 for ; Sun, 18 Jul 2010 17:08:54 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:48932 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S28063326Ab0GSAJI (ORCPT ); Sun, 18 Jul 2010 19:09:08 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Sun, 18 Jul 2010 19:09:08 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 19 Jul 2010 08:09:04 +0800 From: "Thomson, Martin" To: "Richard L. Barnes" Date: Mon, 19 Jul 2010 08:11:12 +0800 Thread-Topic: [sipcore] location conveyance ABNF Thread-Index: Acsk6B84L2xvL8zJRrmb/iCZb2hLWgB7mlvQ Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB772E70@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03E9DCD3DD@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "sipcore@ietf.org" Subject: Re: [sipcore] location conveyance ABNF X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 19 Jul 2010 00:08:55 -0000 PiBGcm9tOiBSaWNoYXJkIEwuIEJhcm5lcyBbbWFpbHRvOnJiYXJuZXNAYmJuLmNvbV0NCj4gDQo+ ID4gSG93ZXZlciwgaXQgbWlnaHQgYmUgYmV0dGVyIHRvIGFsbG93IGZvciBhIGxpdHRsZSBtb3Jl IGZsZXhpYmlsaXR5Lg0KPiA+DQo+ID4gICBsb2NhdGlvblZhbHVlICAgICAgPSAgTEFRVU9UIGxv Y2F0aW9uVVJJIFJBUVVPVCAqKFNFTUkgZ2VvbG9jLQ0KPiBwYXJhbSkNCj4gPiAgIGxvY2F0aW9u VVJJICAgICAgICA9ICBjaWQtdXJsIC8gYWJzb2x1dGVVUkkNCj4gPiAgICAgICAgICAgICAgICAg ICAgICAgICA7IGNpZC11cmwgZnJvbSBSRkMgMjM5MiwgYWJzb2x1dGVVUkkgZnJvbQ0KPiA+IFJG QyAzOTg2DQo+IA0KPiBJIHdvdWxkIHJlYWxseSBsaWtlIGl0IGlmIHdlIGNvdWxkIHByZXNlcnZl IHRoaXMgZmxleGliaWxpdHkuDQoNCkFncmVlZC4gIE5vIG5lZWQgdG8gY3V0IG9mZiBmbGV4aWJp bGl0eSB3aGVuIGl0IGNvc3RzIHNvIGxpdHRsZS4NCg0KPiANCj4gLS1SaWNoYXJkDQo= From Martin.Thomson@andrew.com Sun Jul 18 17:32:48 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 86CEC3A69C0 for ; Sun, 18 Jul 2010 17:32:48 -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 k0RUDLmYIsy0 for ; Sun, 18 Jul 2010 17:32:47 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 4D6C83A69BC for ; Sun, 18 Jul 2010 17:32:43 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:60093 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S335167Ab0GSAbw (ORCPT ); Sun, 18 Jul 2010 19:31:52 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Sun, 18 Jul 2010 19:31:52 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 19 Jul 2010 08:31:50 +0800 From: "Thomson, Martin" To: "James M. Polk" , "sipcore@ietf.org" Date: Mon, 19 Jul 2010 08:33:58 +0800 Thread-Topic: [sipcore] location conveyance and error "code" parameter Thread-Index: AcsktPdhuC20Uc3oQrCheuVCY56GoQCIw/Zg Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB772E77@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03E9DCD3E4@SISPE7MB1.commscope.com> <201007160703.o6G73CcX006182@sj-core-5.cisco.com> In-Reply-To: <201007160703.o6G73CcX006182@sj-core-5.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] location conveyance and error "code" parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 19 Jul 2010 00:32:49 -0000 SGkgSmFtZXMsDQoNCg0KPiBJIHRoaW5rICJtZXNzYWdlIiB3b3VsZCBiZSBjb25mdXNpbmcgYXMg aXQgd291bGQgYmUgZGlmZmVyZW50IHRoYW4NCj4gdGhlIFNJUCByZXNwb25zZSBpdCB3YXMgY2Fy cmllZCBpbiAoYSA0MjQgKEJhZCBMb2NhdGlvbiBJbmZvcm1hdGlvbikNCj4gb3Igc29tZXRoaW5n IGVsc2UpLiBJZiBjb2RlIGlzIGNvbXBsZXRlbHkgYXBwYWxsaW5nIHRvIGZvbGtzLCB0aGVuIEkN Cj4gdGhpbmsgInZhbHVlIiBjb3VsZCBiZSB1c2VkIGluc3RlYWQsIGJ1dCBub3QgIm1lc3NhZ2Ui Lg0KDQpJIGRvbid0IG1pbmQgd2hhdCB0aGUgcGFyYW1ldGVyIGlzIGNhbGxlZC4gICJjb2RlIiBp cyBjb25mdXNpbmcsIHRoYXQncyBhbGwuICAidGV4dCIgaXMgYW5vdGhlciBhbHRlcm5hdGl2ZSB0 byBjb25zaWRlci4gICJ2YWx1ZSIgaW1wbGllcyB0aGF0IHRoZSBjb250ZW50IG9mIHRoZSBwYXJh bWV0ZXIgaXMgdmFsdWFibGUgaW4gc29tZSBtYW5uZXIsIGl0IHNlZW1zIGEgbGl0dGxlIGRpc2lu Z2VudW91cyAoc2VlIGJlbG93KS4NCg0KPiA+Mi4gSWYgSSB1bmRlcnN0YW5kIGNvcnJlY3RseSwg dGhlICJjb2RlIiBwYXJhbWV0ZXIgaGFzIGEgdmFsdWUgdGhhdA0KPiA+aXMgZml4ZWQgYmFzZWQg b24gdGhlIDMgZGlnaXQgY29kZS4gIEEgZml4ZWQgbWVzc2FnZSBkb2Vzbid0IGFkZCBhbnkNCj4g PnZhbHVlIFsxXS4gIElmIGEgaHVtYW4gcmVhZGFibGUgbWVzc2FnZSBpcyByZXF1aXJlZCwgdGhl biBhbGxvd2luZw0KPiA+Zm9yIGFyYml0cmFyeSBjb250ZW50IHdvdWxkIGJlIG1vcmUgbGlrZWx5 IHRvIGJlIHVzZWZ1bC4NCj4gPlRoZSBleGlzdGluZyBzdHJpbmdzIGFyZSB1c2VmdWwgYXMgdGl0 bGVzIGZvciB0aGUgY29kZXMsIGJ1dCB0aGF0J3MNCj4gYWxsLg0KPiANCj4gSSdtIG5vdCBzdXJl IEkgYWdyZWUgb24gdGhpcyBvbmUuIE1vc3QgZXZlcnlvbmUga25vd3Mgd2hhdCBhIDQwNCAiTm90 DQo+IEZvdW5kIiBtZWFuczsgYXMgYSBjb21wdXRlciAocmF0aGVyIHRoYW4gaHVtYW4pIGlzIHJl dHVybmluZyB5b3VyDQo+IHJlcXVlc3QgYmVjYXVzZSBvZiB3aGF0IHRoZSBzdHJpbmcgc2F5cy4g aS5lLiwgIk5vdCBGb3VuZCIuICBUaGlzDQo+IG1ha2UgdGhlIG1lYW5pbmcgbW9yZSBmaW5hbCB0 byBodW1hbnMgbXVjaCBvZiB0aGUgdGltZS4gQW55b25lIHdobydzDQo+IGJyb3dzZWQgaGFzIHJl Y2VpdmVkIGEgNDA0ICh3aXRoIHRoZSB0ZXh0IHRvbykgYW5kIHVuZGVyc3RhbmRzIGl0Lg0KDQpU aGUgaHVtYW4gdmFsdWUgb2YgdGhlIHN0cmluZyAiTm90IGZvdW5kIiBpcyBkZWJhdGFibGUuICBJ ZiB5b3UgZG9uJ3Qgc3BlYWsgRW5nbGlzaCwgdGhlbiBpdCBpcyBldmVuIGxlc3Mgc28uICBBZnRl ciBhbGwsIGEgYnJvd3NlciBpcyBjYXBhYmxlIG9mIGdlbmVyYXRpbmcgbW9yZSBhcHByb3ByaWF0 ZSBtZXNzYWdlIHRleHQuDQoNClRoZSBjb2RlICg0MDQpIGNvbnRhaW5zIGFsbCB0aGUgcmVxdWly ZWQgaW5mb3JtYXRpb24uICBGcm9tIHRoaXMsIGEgdXNlciBhZ2VudCAob3Igc2VydmVyKSBjYW4g Z2VuZXJhdGUgYSBtZXNzYWdlIHRoYXQgaXMgYmV0dGVyIHN1aXRlZCB0byB0aGVpciBhdWRpZW5j ZS4gIEZvciBpbnN0YW5jZToNCg0KICAiVGhlIHJlcXVlc3RlZCBVUkwgPHVybD4gd2FzIG5vdCBm b3VuZCBvbiB0aGlzIHNlcnZlci4iDQoNCkZpeGVkIHRleHQgKE5vdCBmb3VuZCkgaXMgcmVkdW5k YW50LiAgVmFyaWFibGUgdGV4dCBjYW4gYmUgdXNlZnVsIGluIHByb3ZpZGluZyBkaWFnbm9zdGlj IGluZm9ybWF0aW9uLiANCg0KPiBQbGVhc2UgbGV0IG1lIGtub3cgaWYgSSd2ZSBtaXN1bmRlcnN0 b29kIHlvdXIgcG9pbnQgIzIuDQoNCklmIHRoZSBmb2xsb3dpbmcgaXMgcG9zc2libGUsIHRoZW4g d2UgaGF2ZSBubyBwcm9ibGVtOg0KDQogIDIwMCBPSw0KICAuLi4NCiAgR2VvbG9jYXRpb24tRXJy b3I6IDMwMTtjb2RlPSJQbGVhc2UgYWxsb3cgbWUgdG8gcmVkaXN0cmlidXRlIHlvdXIgbG9jYXRp b24uIg0KDQo+IA0KPiBKYW1lcw0KPiANCi0tTWFydGluDQo= From Martin.Thomson@andrew.com Sun Jul 18 19:23:24 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5DFB53A69CB for ; Sun, 18 Jul 2010 19:23:24 -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 Pdt+KLykrUlG for ; Sun, 18 Jul 2010 19:23:23 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 0C7B33A699F for ; Sun, 18 Jul 2010 19:23:22 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:59344 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S28065163Ab0GSCXe (ORCPT ); Sun, 18 Jul 2010 21:23:34 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Sun, 18 Jul 2010 21:23:34 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 19 Jul 2010 10:23:27 +0800 From: "Thomson, Martin" To: "Peterson, Jon" , Roger Marshall , "James M. Polk" , "sipcore@ietf.org" Date: Mon, 19 Jul 2010 10:25:37 +0800 Thread-Topic: composition or just indirection (was: location-conveyance-03 just submitted) Thread-Index: Acsi+NJTa+ULYvovSE2TL/bYrSlncwAKAPJQABWWaxYADURloAAvdkeAABJoDoQAjAHMIA== Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB772EBB@SISPE7MB1.commscope.com> References: <8C837214C95C864C9F34F3635C2A6575135CDD92@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: [sipcore] composition or just indirection (was: location-conveyance-03 just 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: Mon, 19 Jul 2010 02:23:24 -0000 SGkgSm9uLA0KDQpJIGFkbWl0IGEgZmFpciBkZWdyZWUgb2Ygc3ltcGF0aHkgZm9yIFJvZ2Vy4oCZ cyBzdWdnZXN0aW9uLiAgQWZ0ZXIgYWxsLCB0aGUgYWJpbGl0eSB0byBpbmNsdWRlIG11bHRpcGxl IGxvY2F0aW9uIOKAnHZhbHVlc+KAnSBpbiB0aGUgc2FtZSBTSVAgcmVxdWVzdCBpcyBhIGZlYXR1 cmUgdGhhdCBoYXMgZXhpc3RlZCBmb3IgbWFueSB5ZWFycy4gIEEgbnVtYmVyIG9mIGltcGxlbWVu dGF0aW9ucyBoYXZlIGNvbWUgdG8gcmVseSBvbiB0aGlzIG1lY2hhbmlzbTsgcGVvcGxlIGFyZSBi dWlsZGluZyBhbmQgaGF2ZSBidWlsdCBzb2x1dGlvbnMgYmFzZWQgb24gZWFybGllciBkcmFmdCwg ZnVsbHkgYXdhcmUgb2YgdGhlIHJpc2tzIGluIGltcGxlbWVudGluZyBhbiBpbnRlcm5ldCBkcmFm dC4NCg0KQXQgc29tZSBwb2ludCwgaXQgbWlnaHQgYmUgbmVjZXNzYXJ5IHRvIHN3YWxsb3cgYW55 IGRpc2NvbWZvcnQgYW5kIHJlY29nbml6ZSB0aGF0IHRoZSBjb25zZXF1ZW5jZXMgb2YgYW4gaW1w ZXJmZWN0IHNvbHV0aW9uIGFyZSBsZXNzIHRoYW4gdGhlIGNvbnNlcXVlbmNlcyBvZiBhIGNoYW5n ZSBvZiB0aGUgbmF0dXJlIHlvdSBzdWdnZXN0Lg0KDQpBbHRlcmluZyBwZXJzcGVjdGl2ZSBtaWdo dCBvZmZlciBhIHNvbHV0aW9uLg0KDQpUaGUgaWRlYSB0aGF0IHRoZXJlIGFyZSBtdWx0aXBsZSBp dGVtcyB0aGF0IGFyZSBjb21wb3NpdGVkIG1pZ2h0IGJlIGNvdW50ZXJwcm9kdWN0aXZlLiAgSW4g dGhpcyB3b3JsZC12aWV3LCB5b3UgaGF2ZSB0byByZWNvbmNpbGUgYSBudW1iZXIgb2YgcGVyc3Bl Y3RpdmVzLiAgSW4gdGhpcywgeW91IGFyZSBhYnNvbHV0ZWx5IGNvcnJlY3Q6IGRvaW5nIHRoYXQg YXQgdHdvIGxheWVycyBpcyBiYWQuICBDb21wb3NpdGlvbiBpcyBhIGhhcmQgcHJvYmxlbSBhbHJl YWR5LiAgTW92aW5nIGl0IGludG8gU0lQIG9ubHkgY29tcGxpY2F0ZXMgaXQgZnVydGhlci4NCg0K VGhlIGFsdGVybmF0aXZlIGlzIHRvIGltYWdpbmUgYSBzaW5nbGUgbG9naWNhbCByZXNvdXJjZSB0 aGF0IHJlcHJlc2VudHMgdGhlIGxvY2F0aW9uIG9mIHRoZSBUYXJnZXQuICBBIGxvY2F0aW9uIGJ5 IHZhbHVlIGlzIGEgcmVwcmVzZW50YXRpb24gb2YgdGhpcyByZXNvdXJjZTogYSBzbmFwc2hvdC4g IExvY2F0aW9uIGJ5IHJlZmVyZW5jZSBvZmZlcnMgYSBtZWFucyBmb3IgYW55IGVudGl0eSB0byBp ZGVudGlmeSBhbmQgYWNxdWlyZSBhIHZpZXcgb2YgdGhlIHJlc291cmNlLCBpbmRlcGVuZGVudCBv ZiB0aGF0IHNuYXBzaG90LiAgVGhlIGF1dGhvcml0eSBmb3IgdGhlIHJlc291cmNlIG1pZ2h0IG9m ZmVyIHRoZSBzYW1lIHJlcHJlc2VudGF0aW9uLCBvciBpdCBjb3VsZCBvZmZlciBvbmUgYmV0dGVy IHN1aXRlZCB0byB0aGUgcmVjaXBpZW50LiAgVGhlIHJlcHJlc2VudGF0aW9uIG1pZ2h0IGJlIHVw ZGF0ZWQsIGl0IG1pZ2h0IGJlIGFsdGVyZWQgYmFzZWQgb24gYW4gYXV0aG9yaXphdGlvbiBwb2xp Y3ksIG9yIHNvbWV0aGluZyBlbHNlIChsYW5ndWFnZSBwcmVmZXJlbmNlcykuICBSZWdhcmRsZXNz IG9mIGhvdyBpdCBpcyByZXByZXNlbnRlZCwgaXQgaXMgc3RpbGwgdGhlIHNhbWUgcmVzb3VyY2Uu DQoNCkluIHNpbXBsZSB0ZXJtcywgeW91IHN0YXRlIHRoYXQgdGhlIHJlcXVlc3QgY2FuIG9ubHkg aW5jbHVkZSBhIHNpbmdsZSBfbG9jYXRpb25fLiAgV2hlbiBhIGxvY2F0aW9uIHZhbHVlIGFuZCBy ZWZlcmVuY2UgYXJlIGJvdGggaW5jbHVkZWQsIHRoZXkgcmVwcmVzZW50IHRoZSBfc2FtZV8gbG9j YXRpb24uDQoNClRoaXMgaXMgd2h5IEkgc3VnZ2VzdGVkIHRoYXQgQ29udGVudC1Mb2NhdGlvbiBi ZSBib3Jyb3dlZC4gIEluIEhUVFAsIENvbnRlbnQtTG9jYXRpb24gc2F5cyAtIGlmIHlvdSB3YW50 IHRvIGtub3cgd2hlcmUgdGhpcyByZXNvdXJjZSByZWFsbHkgbGl2ZXMsIGhlcmUgaXMgd2hlcmUg eW91IGNhbiBmaW5kIGl0Lg0KDQpOb3cgdGhpcyBtaWdodCBiZSBzaGVlciBzb3BoaXN0cnksIGJ1 dCBpdCBtaWdodCBvZmZlciBhIHdheSBvdXQuICBUaGUgY29tcG9zaXRpb24gcHJvYmxlbXMgYXJl IGxlZnQgb3V0IG9mIFNJUC4NCg0KSSBjYW4gd3JpdGUgdXAgYSBtb3JlIGRldGFpbGVkIHN0cmF3 bWFuLCBidXQgZm9yIG5vdywgSSdsbCBqdXN0IGluY2x1ZGUgYW4gZXhhbXBsZToNCg0KICAgSU5W SVRFIHNpcHM6Ym9iQGJpbG94aS5leGFtcGxlLmNvbSBTSVAvMi4wDQogICBWaWE6IFNJUFMvMi4w L1RMUyBwYzMzLmF0bGFudGEuZXhhbXBsZS5jb207YnJhbmNoPXo5aEc0Yks3NGJmOQ0KICAgTWF4 LUZvcndhcmRzOiA3MA0KICAgVG86IEJvYiA8c2lwczpib2JAYmlsb3hpLmV4YW1wbGUuY29tPg0K ICAgRnJvbTogQWxpY2UgPHNpcHM6YWxpY2VAYXRsYW50YS5leGFtcGxlLmNvbT47dGFnPTlmeGNl ZDc2c2wNCiAgIENhbGwtSUQ6IDM4NDgyNzYyOTgyMjAxODg1MTFAYXRsYW50YS5leGFtcGxlLmNv bQ0KICAgR2VvbG9jYXRpb246IDxjaWQ6dGFyZ2V0MTIzQGF0bGFudGEuZXhhbXBsZS5jb20+DQog ICAgIDtyb3V0aW5nLWFsbG93ZWQ9bm8NCiAgIFN1cHBvcnRlZDogZ2VvbG9jYXRpb24NCiAgIEFj Y2VwdDogYXBwbGljYXRpb24vc2RwLCBhcHBsaWNhdGlvbi9waWRmK3htbA0KICAgQ1NlcTogMzE4 NjIgSU5WSVRFDQogICBDb250YWN0OiA8c2lwczphbGljZUBhdGxhbnRhLmV4YW1wbGUuY29tPg0K ICAgQ29udGVudC1UeXBlOiBtdWx0aXBhcnQvbWl4ZWQ7IGJvdW5kYXJ5PWJvdW5kYXJ5MQ0KICAg Q29udGVudC1MZW5ndGg6IC4uLg0KDQogICAtLWJvdW5kYXJ5MQ0KICAgQ29udGVudC1UeXBlOiBh cHBsaWNhdGlvbi9zZHANCg0KICAgLi4uU0RQIGdvZXMgaGVyZQ0KDQogICAtLWJvdW5kYXJ5MQ0K ICAgQ29udGVudC1UeXBlOiBhcHBsaWNhdGlvbi9waWRmK3htbA0KICAgQ29udGVudC1JRDogPHRh cmdldDEyM0BhdGxhbnRhLmV4YW1wbGUuY29tPg0KICAgQ29udGVudC1Mb2NhdGlvbjogcHJlczph bGljZUBleGFtcGxlLmNvbT9sb2NhdGlvbi9YSmhiWE02ZUcxc09tNXpPbkJwWg0KDQogICA8P3ht bCB2ZXJzaW9uPSIxLjAiPz4NCiAgIC4uLlBJREYtTE8gZG9jdW1lbnQNCiAgIC0tYm91bmRhcnkx LS0NCg0KDQotLU1hcnRpbg0KDQotLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLQ0KRnJvbTogUGV0 ZXJzb24sIEpvbiBbbWFpbHRvOmpvbi5wZXRlcnNvbkBuZXVzdGFyLmJpel0gDQpTZW50OiBGcmlk YXksIDE2IEp1bHkgMjAxMCA0OjU0IFBNDQpUbzogUm9nZXIgTWFyc2hhbGw7IFRob21zb24sIE1h cnRpbjsgSmFtZXMgTS4gUG9sazsgc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzaXBj b3JlXSBsb2NhdGlvbi1jb252ZXlhbmNlLTAzIGp1c3Qgc3VibWl0dGVkDQoNCg0KSW4gdGhlIGNv cm5lciBjYXNlIChhbmQgSSBkbyB0aGluayBpdCBpcyBhIGNvcm5lciBjYXNlKSB3aGVyZSBtdWx0 aXBsZSBlbnRpdGllcyBhcmUgY29udHJpYnV0aW5nIGRpZmZlcmVudCBsb2NhdGlvbiBpbmZvcm1h dGlvbiB0byBhIHNpbmdsZSBTSVAgcmVxdWVzdCwgSSB0aGluayB3ZSBmYWNlIGEgZnVuZGFtZW50 YWwgYXJjaGl0ZWN0dXJlIGNob2ljZSBpbiB0aGlzIG1lY2hhbmlzbTogZWl0aGVyIGl0IGlzIFNJ UOKAmXMgam9iIHRvIHNvcnQgb3V0IGhvdyB3ZSB1bmRlcnN0YW5kIHRob3NlIGRpZmZlcmVudCBs b2NhdGlvbnMsIG9yIGl0IGlzIFBJREbigJlzIGpvYi4gwqBUcmFkaXRpb25hbGx5LCBQSURG4oCZ cyB1bmRlcnN0YW5kaW5nIG9mIGRpZmZlcmVudCBzb3VyY2VzIG9mIHByZXNlbmNlIHRoYXQgcHJv dmlkZSBwb3RlbnRpYWxseSBjb250cmFkaWN0b3J5IGluZm9ybWF0aW9uIHJlbGllcyBvbiB0aGUg cHJlc2VuY2UgZGF0YSBtb2RlbCAoUkZDNDQ3OSksIHdoaWNoIGlzIGRlc2lnbmVkIHRvIHJlY29u Y2lsZSBjb25kaXRpb25zIGxpa2UgdGhlIG9uZSB3aGVyZSBteSBtb2JpbGUgcGhvbmUgdGhpbmtz IEkgYW0gYXZhaWxhYmxlIGJ1dCBteSBkZXNrdG9wIHRoaW5rcyBJ4oCZbSBvZmZsaW5lLiBUaGUg cHJlc2VuY2UgZGF0YSBtb2RlbCBtb3Jlb3ZlciBkaWZmZXJlbnRpYXRlcyBiZXR3ZWVuIHVzZXJz LCBzZXJ2aWNlcyBhbmQgZGV2aWNlcyBpbiBhIHdheSB0aGF0IGlzIHVzZWZ1bCBhbmQgYXBwYXJl bnRseSBhcHBsaWNhYmxlIHRvIGxvY2F0aW9uIGluZm9ybWF0aW9uLiBJIGFtIG5vdCBlYWdlciB0 byB0cnkgdG8gcmVwbGljYXRlIHRoaXMgaW4gU0lQIGhlYWRlcnMsIGluY2x1ZGluZyBieSBpbnNl cnRpbmcgbXVsdGlwbGUgc3VjaCBoZWFkZXJzLCBwdXR0aW5nIGluIG1hcmt1cCB0aGF0IHRyaWVz IHRvIGV4cGxhaW4gdGhlIOKAnHNvdXJjZeKAnSBvZiBsb2NhdGlvbiBpbmZvcm1hdGlvbiBpbiBT SVAgaGVhZGVycywgYW5kIHNvIG9uLiBTSVDigJlzIGpvYiBzaG91bGQgYmUgdG8gY29udmV5IHRo ZSBsb2NhdGlvbiBvYmplY3Qg4oCTIGZ1bmRhbWVudGFsbHksIHRoZSBmdXJ0aGVyIHdlIGRpdmVy Z2UgZnJvbSDigJxjb252ZXlhbmNl4oCdIGFuZCBlbnRlciBpbnRvIHRoZSByZWFsbSBvZiDigJxp bnRlZ3JhdGlvbizigJ0gdGhlIGxlc3MgY29tZm9ydGFibGUgSSBnZXQuDQoNCkkgdW5kZXJzdGFu ZCB0aGF0IHRoZSBzdWJzZXF1ZW50IHVzZSBjYXNlIHdoZXJlIHRoZXJlIGFyZSBkaWZmZXJlbnQg c291cmNlcyBvZiBsb2NhdGlvbiBpbmZvcm1hdGlvbiwgc29tZSBvZiB3aGljaCBhcmUgTGJyViBh bmQgc29tZSBvZiB3aGljaCBhcmUgTGJ5UiwgbG9va3MgbGlrZSBhIMKgaGFpcnkgb25lLiBUaGlz IGlzLCBob3dldmVyLCBhIGNvcm5lciBjYXNlIG9mIGEgY29ybmVyIGNhc2UuIEkgcmVhbGx5IGRv IG5vdCBmZWVsIGNvbWZvcnRhYmxlIGp1c3RpZnlpbmcgdGhlIGFsbG93YW5jZSBvZiBtdWx0aXBs ZSBsb2NhdGlvbiBoZWFkZXJzIGluIFNJUCBwb2ludGluZyB0byBkaWZmZXJlbnQgcHJlc2VuY2Ug b2JqZWN0cyAoYXMgb3Bwb3NlZCB0byBmb2xsb3dpbmcgdGhlIHByZXNlbmNlIGRhdGEgbW9kZWwp IHRvIGNhcnJ5IHRoZSAwLCAxIG9yIDIgZGlmZmVyZW50IGxvY2F0aW9ucyBkdWUgdG8gYSBjb3Ju ZXIgY2FzZSBvZiBhIGNvcm5lciBjYXNlLiBBcyBJIHNhaWQgaW4gbXkgcHJldmlvdXMgbWFpbCB0 byBNYXJ0aW4sIEnigJltIG5vdCByZWFsbHkgc3VyZSBJIGV2ZW4gdW5kZXJzdGFuZCB0aGUgcmVx dWlyZW1lbnRzIGZvciBhbiBpbnRlcm1lZGlhcnkgdG8gZXZhbHVhdGUgYW5kIHJlamVjdCBMYnlS LCBub3Igd2hhdCB0aGUgYmVzdCB3YXkgaXMgZm9yIHByZXNlbmNlIGZyb20gdGhlc2UgZHluYW1p YyBzb3VyY2VzIHRvIGJlIGNvbXBvc2VkLiBJZiB3ZSB3ZXJlIHRvIGludmVzdGlnYXRlIHRoZSBy aWdodCB3YXkgZm9yIHByZXNlbmNlIGZyb20gdGhvc2Ugc291cmNlIHRvIGJlIGNvbXBvc2VkLCBp dCBtaWdodCB2ZXJ5IHdlbGwgYmUgdGhhdCBpdCBpcyB0aGUgcmVzcG9uc2liaWxpdHkgb2YgdGhl IGNvbXBvc2l0b3IgdG8gaW5zZXJ0IGFuIExieVIgaW50byB0aGUgU0lQIHJlcXVlc3QgKGludG8g dGhlIEdlb2xvY2F0aW9uIGhlYWRlciksIGFuZCB0byBwb2xsIGFuZCBjb21wb3NlIGEgY29oZXJl bnQgUElERiBkb2N1bWVudCBmcm9tIGl0cyBkeW5hbWljIGFuZCBzdGF0aWMgc291cmNlcyDigJMg dGhhdCBpcyBwcm9iYWJseSB0aGUgYXBwcm9hY2ggdGhhdCBtb3N0IGNsb3NlbHkgcGFyYWxsZWxz IHRoZSB0cmFkaXRpb25hbCBhcHByb2FjaGVzIHRvIHByZXNlbmNlLiBCdXQgd2UgaGF2ZW7igJl0 IGV2ZW4gYmVndW4gdG8gZXhwbG9yZSB0aGlzIHlldC4gTm8gb25lIGluc2lzdGluZyB0aGF0IHRo ZXJlIHdpbGwgYmUg4oCcZW1wdHnigJ0gUElERiBkb2N1bWVudHMganVzdCBjb250YWluaW5nIHJl ZmVyZW5jZXMgdG8gZXh0ZXJuYWwgUElERiBkb2N1bWVudHMgb3Igc29tZXRoaW5nLiBTb21ldGhp bmcgYWxvbmcgdGhvc2UgbGluZXMgaXMgb25lIGFwcHJvYWNoIG9mIG1hbnkgdGhhdCB3ZSB3b3Vs ZCBjb25zaWRlciBpZiB3ZSB0cmllZCB0byBmaWd1cmUgb3V0IGhvdyB0byBhZGRyZXNzIHRoaXMg aW4gUElERi4gVGhlIHF1ZXN0aW9uIHdlIG5lZWQgdG8gZGVjaWRlLCBhcyBJIHNhaWQgYWJvdmUs IGlzIHRoZSBhcmNoaXRlY3R1cmUgb25lIOKAkyBpcyBTSVDigJlzIGpvYiB0byBjb252ZXkgUElE RiBkb2N1bWVudHMsIG9yIHRvIGNvbXBvc2UgdGhlbT8NCg0KSm9uIFBldGVyc29uDQpOZXVTdGFy LCBJbmMuDQoNCuKApg0K From gao.yang2@zte.com.cn Sun Jul 18 20:43:58 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F05F93A69CC for ; Sun, 18 Jul 2010 20:43:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -96.373 X-Spam-Level: X-Spam-Status: No, score=-96.373 tagged_above=-999 required=5 tests=[AWL=-0.597, BAYES_20=-0.74, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 KVucKoCQOTH9 for ; Sun, 18 Jul 2010 20:43:55 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 610533A67D1 for ; Sun, 18 Jul 2010 20:43:53 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 205951727820181; Mon, 19 Jul 2010 11:43:13 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 38391.2980680612; Mon, 19 Jul 2010 11:36:09 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o6J3h1FU044247; Mon, 19 Jul 2010 11:43:36 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4C3EE244.8040909@ericsson.com> To: Gonzalo Camarillo MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 19 Jul 2010 11:40:14 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-19 11:43:31, Serialize complete at 2010-07-19 11:43:31 Content-Type: multipart/alternative; boundary="=_alternative 001462C248257765_=" X-MAIL: mse2.zte.com.cn o6J3h1FU044247 Cc: SIPCORE Subject: Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 19 Jul 2010 03:43:58 -0000 This is a multipart message in MIME format. --=_alternative 001462C248257765_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgR29uemFsbywNCg0KSSBmb3VuZCB0aW1lIHRvIHJlYWQgdGhpcyB2ZXJzaW9uIG9uIHdlZWtl bmQuIEFuZCB0aGVyZSBhcmUgdGhyZWUgbWFpbiANCnBvaW50czoNCg0KMS4gR2xhcmUgU2l0dWF0 aW9ucyhzZWN0aW9uIDMuNSkNCkFzIHRoZSBuZXcgd2F5LCB0aGlzIHBhcnQgaXMgcmVsYXRpdmVs eSBzaW1wbGUgbm93LiBBbmQgdGhlIG5ldyB3YXkgaXMgDQpzZW5kaW5nIGEgbmV3IHJlZnJlc2gg dXNhZ2UgUmUtSU5WSVRFIHRvIHN5bmNocm9uaXplIHN0YXRlIGZvciBhbnkgZ2xhcmUgDQpzaXR1 YXRpb25zLg0KVGhpcyBpcyBzaW1wbGUsIGFuZCBlZmZlY3RpdmUuIFNvLCBJIGFtIE9LIGF0IHRo aXMgcG9pbnQuDQoNCjIuIFJhY2UgQ29uZGl0aW9ucyBhbmQgVGFyZ2V0IFJlZnJlc2hlcyhzZWN0 aW9uIDQuOCkNClRvIGRpc2FsbG93IHRhcmdldCByZWZyZXNoZXMgaW4gdW5yZWxpYWJsZSByZXNw b25zZSBjYW4gc29sdmUgdGhpcyANCnByb2JsZW0uIEFuZCBpbiBmYWN0LCBJIHRoaW5rIGl0IGlz IGEgbmljZSB3YXksIGFzIGRvICJUYXJnZXQgUmVmcmVzaGVzIiANCmluIHVucmVsaWFibGUgcmVz cG9uc2UgaXMgdW5yZWxpYWJsZS4gU28sIEknbSBPSyB3aXRoIGl0Lg0KQXMgdGhpcyBydWxlJ3Mg bWVhbmluZyBpcyBtb3JlIHRoYW4gZ2xhcmUgaXNzdWUsIHNvIHdlIG1heSBwdXQgdGhpcyBydWxl IA0KaW4gYSBuZXcgc2VjdGlvbiwgYW5kIG9ubHkgbWVudGlvbiBpbiBzZWN0aW9uIDQuOCB0aGF0 IGdhbHJlIHByb2JsZW0gaGVyZSANCmNhbiBiZSBzb2x2ZWQgYnkgdGhpcyBydWxlLg0KDQozLiBT ZWN0aW9uIDUNCkkgYW0gT0sgd2l0aCB0aGlzIHNlY3Rpb24ncyByZXZpc2lvbi4NCg0KVGhhbmtz LA0KDQpHYW8NCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBaaXAgICAg OiAyMTAwMTINCiBUZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3MjExDQog ZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09DQoNCg0KDQpHb256YWxvIENhbWFyaWxsbyA8R29uemFsby5DYW1hcmlsbG9AZXJp Y3Nzb24uY29tPiANCreivP7IyzogIHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZw0KMjAxMC0wNy0x NSAxODoyNg0KDQrK1bz+yMsNCkdvbnphbG8gQ2FtYXJpbGxvIDxHb256YWxvLkNhbWFyaWxsb0Bl cmljc3Nvbi5jb20+DQqzrcvNDQpTSVBDT1JFIDxzaXBjb3JlQGlldGYub3JnPg0K1vfM4g0KUmU6 IFtzaXBjb3JlXSBEaWFsb2cgc3RhdGUgLSBTY29wZSBpbiBkcmFmdC1pZXRmLXNpcGNvcmUtcmVp bnZpdGUNCg0KDQoNCg0KDQoNCkhpLA0KDQp0aGFua3MgZm9yIHRoZSBmZWVkYmFjayBJIGhhdmUg cmVjZWl2ZWQgb24gYW5kIG9mZiBsaXN0LiBXZSBzZWVtIHRvIGhhdmUNCmNvbnNlbnN1cyBvbiBy ZWR1Y2luZyB0aGUgc2NvcGUgb2YgdGhlIGRyYWZ0IHRvIHNlc3Npb24gc3RhdGUgYW5kIHRhcmdl dA0KcmVmcmVzaGVzLiBUaGF0IGlzIGdyZWF0IGJlY2F1c2UgaXQgYWxsb3dzIHVzIHRvIGh1Z2Vs eSBzaW1wbGlmeSB0aGUNCnJ1bGVzIHRvIGF2b2lkIGdsYXJlIGNvbmRpdGlvbnMgKHRoaXMgaXMg c29tZXRoaW5nIGEgZmV3IG9mIHlvdSBoYXZlDQpyZXF1ZXN0ZWQgb24gdGhlIGxpc3QgaW4gdGhl IHBhc3QpLiBJIGhhdmUgcHV0IHRvZ2V0aGVyIGEgbmV3IHJldmlzaW9uDQpvZiB0aGUgZHJhZnQs IHdoaWNoIHlvdSBjYW4gZmV0Y2ggZnJvbToNCg0KaHR0cDovL3VzZXJzLnBpdWhhLm5ldC9nb256 YWxvL3RlbXAvZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlLXByZTA1LTAxLnR4dA0KDQoNCklu IGFkZGl0aW9uIHRvIGFkanVzdGluZyB0aGUgc2NvcGUgb2YgdGhlIGRyYWZ0IGFuZCBzaW1wbGlm eWluZyB0aGUNCmdsYXJlLXJlbGF0ZWQgcnVsZXMsIEkgaGF2ZSBhbHNvIGFkZGVkIGEgZmV3IGNs YXJpZmljYXRpb25zIHRvIFNlY3Rpb24gNQ0KaW4gcmVzcG9uc2UgdG8gUm9iZXJ0J3MgQUQgcmV2 aWV3Lg0KDQpMZXQgbWUga25vdyBpZiB5b3UgaGF2ZSBhbnkgY29tbWVudHMuDQoNClRoYW5rcywN Cg0KR29uemFsbw0KDQoNCk9uIDA1LzA3LzIwMTAgOTozNCBBTSwgR29uemFsbyBDYW1hcmlsbG8g d3JvdGU6DQo+IEhpLA0KPiANCj4gdGhlIHJlLUlOVklURSBkcmFmdCB0YWxrcyBhYm91dCBtb2Rp ZmljYXRpb25zIGluIHRoZSBzZXNzaW9uIHN0YXRlLA0KPiBkaWFsb2cgc3RhdGUsIGFuZCB0aGUg ZGlhbG9nJ3MgcmVtb3RlIHRhcmdldC4gV2hpbGUgaXQgaXMgcmVsYXRpdmVseQ0KPiB3ZWxsIHVu ZGVyc3Rvb2Qgd2hhdCB3ZSBtZWFuIGJ5IHNlc3Npb24gc3RhdGUgYW5kIHRoZSBkaWFsb2cncyBy ZW1vdGUNCj4gdGFyZ2V0LCB3ZSBkbyBub3QgcmVhbGx5IGhhdmUgYSBnb29kIGRlZmluaXRpb24g Zm9yIGRpYWxvZyBzdGF0ZS4NCj4gDQo+IFdlIGhhdmUgZGlzY3Vzc2VkIGl0IGluIHRoZSBwYXN0 IGFuZCB3aGF0IHBlb3BsZSBoYWQgaW4gbWluZCB3ZXJlIHRoaW5ncw0KPiBzdWNoIGFzIGNhbGxl ZCBwYXJ0eSBpZGVudGl0eS4gSG93ZXZlciwgdGhlIGRyYWZ0IGlzIHRvbyB2YWd1ZSBhdCB0aGlz DQo+IHBvaW50OyBpdCBzaG91bGQgYmUgbW9yZSBwcmVjaXNlIHJlZ2FyZGluZyB3aGljaCBwaWVj ZSBvZiAiZGlhbG9nIHN0YXRlIg0KPiB0aGUgcnVsZXMgaW4gdGhlIGRyYWZ0IGFwcGx5IHRvLg0K PiANCj4gTXkgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0byBoYXZlIHRoZSBkcmFmdCB0YWxrIG9ubHkg YWJvdXQgc2Vzc2lvbiBzdGF0ZQ0KPiBhbmQgdGhlIGRpYWxvZydzIHJlbW90ZSB0YXJnZXQsIGFu ZCBmb3JnZXQgYWJvdXQgYW55IG90aGVyIGRpYWxvZyBzdGF0ZS4NCj4gTmV3IGV4dGVuc2lvbnMg d2hvc2UgcGFyYW1ldGVycyBjYW4gYmUgbW9kaWZpZWQgYnkgcmUtSU5WSVRFcyBjYW4NCj4gc3Bl Y2lmeSB0aGVpciBvd24gcnVsZXMsIHBvc3NpYmx5IHJlZmVycmluZyB0byB0aGlzIGRyYWZ0IGFu ZCB1c2luZyB0aGUNCj4gcnVsZXMgZGVmaW5lZCBpbiBpdCBieSByZWZlcmVuY2UuIEluIHRoaXMg d2F5LCB0aGUgYXBwbGljYWJpbGl0eSBvZiB0aGlzDQo+IGRyYWZ0IHdvdWxkIGJlIG11Y2ggY2xl YXJlci4NCj4gDQo+IENvbW1lbnRzPw0KPiANCj4gVGhhbmtzLA0KPiANCj4gR29uemFsbw0KPiAN Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2lw Y29yZSBtYWlsaW5nIGxpc3QNCj4gc2lwY29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCj4gDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lwY29y ZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3Jl DQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0aGUgc2Vu ZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25maWRlbnRp YWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFpbiBzZWNy ZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMgb2YgdGhp cyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxlcyB0cmFu c21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVseSBmb3Ig dGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFyZSBhZGRy ZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5v dGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJlc3NlZCBp biB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4NClRoaXMg bWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRp LVNwYW0gc3lzdGVtLg0K --=_alternative 001462C248257765_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEdvbnphbG8sPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIGZvdW5kIHRpbWUgdG8g cmVhZCB0aGlzIHZlcnNpb24gb24NCndlZWtlbmQuIEFuZCB0aGVyZSBhcmUgdGhyZWUgbWFpbiBw b2ludHM6PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj4x LiBHbGFyZSBTaXR1YXRpb25zKHNlY3Rpb24gMy41KTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0ic2Fucy1zZXJpZiI+QXMgdGhlIG5ldyB3YXksIHRoaXMgcGFydCBpcyByZWxhdGl2ZWx5 DQpzaW1wbGUgbm93LiBBbmQgdGhlIG5ldyB3YXkgaXMgc2VuZGluZyBhIG5ldyByZWZyZXNoIHVz YWdlIFJlLUlOVklURSB0bw0Kc3luY2hyb25pemUgc3RhdGUgZm9yIGFueSBnbGFyZSBzaXR1YXRp b25zLjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhpcyBpcyBz aW1wbGUsIGFuZCBlZmZlY3RpdmUuIFNvLCBJDQphbSBPSyBhdCB0aGlzIHBvaW50LjwvZm9udD4N Cjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+Mi4gUmFjZSBDb25kaXRp b25zIGFuZCBUYXJnZXQgUmVmcmVzaGVzKHNlY3Rpb24NCjQuOCk8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRvIGRpc2FsbG93IHRhcmdldCByZWZyZXNoZXMgaW4g dW5yZWxpYWJsZQ0KcmVzcG9uc2UgY2FuIHNvbHZlIHRoaXMgcHJvYmxlbS4gQW5kIGluIGZhY3Qs IEkgdGhpbmsgaXQgaXMgYSBuaWNlIHdheSwNCmFzIGRvICZxdW90O1RhcmdldCBSZWZyZXNoZXMm cXVvdDsgaW4gdW5yZWxpYWJsZSByZXNwb25zZSBpcyB1bnJlbGlhYmxlLg0KU28sIEknbSBPSyB3 aXRoIGl0LjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+QXMgdGhp cyBydWxlJ3MgbWVhbmluZyBpcyBtb3JlIHRoYW4NCmdsYXJlIGlzc3VlLCBzbyB3ZSBtYXkgcHV0 IHRoaXMgcnVsZSBpbiBhIG5ldyBzZWN0aW9uLCBhbmQgb25seSBtZW50aW9uDQppbiBzZWN0aW9u IDQuOCB0aGF0IGdhbHJlIHByb2JsZW0gaGVyZSBjYW4gYmUgc29sdmVkIGJ5IHRoaXMgcnVsZS48 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPjMuIFNlY3Rp b24gNTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+SSBhbSBPSyB3 aXRoIHRoaXMgc2VjdGlvbidzIHJldmlzaW9uLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+VGhhbmtzLDwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0ic2Fucy1zZXJpZiI+R2FvPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBm YWNlPSJzYW5zLXNlcmlmIj49PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTxicj4N CiBaaXAgJm5ic3A7ICZuYnNwOzogMjEwMDEyPGJyPg0KIFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIx MTxicj4NCiBUZWwyICZuYnNwOyA6KCs4NiktMDI1LTUyODc3MjExPGJyPg0KIGVfbWFpbCA6IGdh by55YW5nMkB6dGUuY29tLmNuPGJyPg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+DQo8dGFibGUgd2lkdGg9MTAwJT4NCjx0ciB2YWxp Z249dG9wPg0KPHRkIHdpZHRoPTM1JT48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+PGI+ R29uemFsbyBDYW1hcmlsbG8gJmx0O0dvbnphbG8uQ2FtYXJpbGxvQGVyaWNzc29uLmNvbSZndDs8 L2I+DQo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPreivP7Iyzog Jm5ic3A7c2lwY29yZS1ib3VuY2VzQGlldGYub3JnPC9mb250Pg0KPHA+PGZvbnQgc2l6ZT0xIGZh Y2U9InNhbnMtc2VyaWYiPjIwMTAtMDctMTUgMTg6MjY8L2ZvbnQ+DQo8dGQgd2lkdGg9NjQlPg0K PHRhYmxlIHdpZHRoPTEwMCU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmln aHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPsrVvP7IyzwvZm9udD48L2Rpdj4NCjx0 ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+R29uemFsbyBDYW1hcmlsbG8gJmx0O0dv bnphbG8uQ2FtYXJpbGxvQGVyaWNzc29uLmNvbSZndDs8L2ZvbnQ+DQo8dHIgdmFsaWduPXRvcD4N Cjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPrOt y808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPlNJUENP UkUgJmx0O3NpcGNvcmVAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+ DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7W98ziPC9m b250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5SZTogW3NpcGNv cmVdIERpYWxvZyBzdGF0ZSAtIFNjb3BlIGluDQpkcmFmdC1pZXRmLXNpcGNvcmUtcmVpbnZpdGU8 L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPHRk PjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PkhpLDxicj4NCjxicj4NCnRoYW5rcyBmb3IgdGhlIGZlZWRiYWNrIEkgaGF2ZSByZWNlaXZlZCBv biBhbmQgb2ZmIGxpc3QuIFdlIHNlZW0gdG8gaGF2ZTxicj4NCmNvbnNlbnN1cyBvbiByZWR1Y2lu ZyB0aGUgc2NvcGUgb2YgdGhlIGRyYWZ0IHRvIHNlc3Npb24gc3RhdGUgYW5kIHRhcmdldDxicj4N CnJlZnJlc2hlcy4gVGhhdCBpcyBncmVhdCBiZWNhdXNlIGl0IGFsbG93cyB1cyB0byBodWdlbHkg c2ltcGxpZnkgdGhlPGJyPg0KcnVsZXMgdG8gYXZvaWQgZ2xhcmUgY29uZGl0aW9ucyAodGhpcyBp cyBzb21ldGhpbmcgYSBmZXcgb2YgeW91IGhhdmU8YnI+DQpyZXF1ZXN0ZWQgb24gdGhlIGxpc3Qg aW4gdGhlIHBhc3QpLiBJIGhhdmUgcHV0IHRvZ2V0aGVyIGEgbmV3IHJldmlzaW9uPGJyPg0Kb2Yg dGhlIGRyYWZ0LCB3aGljaCB5b3UgY2FuIGZldGNoIGZyb206PGJyPg0KPGJyPg0KaHR0cDovL3Vz ZXJzLnBpdWhhLm5ldC9nb256YWxvL3RlbXAvZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlLXBy ZTA1LTAxLnR4dDxicj4NCjxicj4NCkluIGFkZGl0aW9uIHRvIGFkanVzdGluZyB0aGUgc2NvcGUg b2YgdGhlIGRyYWZ0IGFuZCBzaW1wbGlmeWluZyB0aGU8YnI+DQpnbGFyZS1yZWxhdGVkIHJ1bGVz LCBJIGhhdmUgYWxzbyBhZGRlZCBhIGZldyBjbGFyaWZpY2F0aW9ucyB0byBTZWN0aW9uDQo1PGJy Pg0KaW4gcmVzcG9uc2UgdG8gUm9iZXJ0J3MgQUQgcmV2aWV3Ljxicj4NCjxicj4NCkxldCBtZSBr bm93IGlmIHlvdSBoYXZlIGFueSBjb21tZW50cy48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KPGJy Pg0KR29uemFsbzxicj4NCjxicj4NCjxicj4NCk9uIDA1LzA3LzIwMTAgOTozNCBBTSwgR29uemFs byBDYW1hcmlsbG8gd3JvdGU6PGJyPg0KJmd0OyBIaSw8YnI+DQomZ3Q7IDxicj4NCiZndDsgdGhl IHJlLUlOVklURSBkcmFmdCB0YWxrcyBhYm91dCBtb2RpZmljYXRpb25zIGluIHRoZSBzZXNzaW9u IHN0YXRlLDxicj4NCiZndDsgZGlhbG9nIHN0YXRlLCBhbmQgdGhlIGRpYWxvZydzIHJlbW90ZSB0 YXJnZXQuIFdoaWxlIGl0IGlzIHJlbGF0aXZlbHk8YnI+DQomZ3Q7IHdlbGwgdW5kZXJzdG9vZCB3 aGF0IHdlIG1lYW4gYnkgc2Vzc2lvbiBzdGF0ZSBhbmQgdGhlIGRpYWxvZydzIHJlbW90ZTxicj4N CiZndDsgdGFyZ2V0LCB3ZSBkbyBub3QgcmVhbGx5IGhhdmUgYSBnb29kIGRlZmluaXRpb24gZm9y IGRpYWxvZyBzdGF0ZS48YnI+DQomZ3Q7IDxicj4NCiZndDsgV2UgaGF2ZSBkaXNjdXNzZWQgaXQg aW4gdGhlIHBhc3QgYW5kIHdoYXQgcGVvcGxlIGhhZCBpbiBtaW5kIHdlcmUNCnRoaW5nczxicj4N CiZndDsgc3VjaCBhcyBjYWxsZWQgcGFydHkgaWRlbnRpdHkuIEhvd2V2ZXIsIHRoZSBkcmFmdCBp cyB0b28gdmFndWUgYXQNCnRoaXM8YnI+DQomZ3Q7IHBvaW50OyBpdCBzaG91bGQgYmUgbW9yZSBw cmVjaXNlIHJlZ2FyZGluZyB3aGljaCBwaWVjZSBvZiAmcXVvdDtkaWFsb2cNCnN0YXRlJnF1b3Q7 PGJyPg0KJmd0OyB0aGUgcnVsZXMgaW4gdGhlIGRyYWZ0IGFwcGx5IHRvLjxicj4NCiZndDsgPGJy Pg0KJmd0OyBNeSBzdWdnZXN0aW9uIHdvdWxkIGJlIHRvIGhhdmUgdGhlIGRyYWZ0IHRhbGsgb25s eSBhYm91dCBzZXNzaW9uIHN0YXRlPGJyPg0KJmd0OyBhbmQgdGhlIGRpYWxvZydzIHJlbW90ZSB0 YXJnZXQsIGFuZCBmb3JnZXQgYWJvdXQgYW55IG90aGVyIGRpYWxvZw0Kc3RhdGUuPGJyPg0KJmd0 OyBOZXcgZXh0ZW5zaW9ucyB3aG9zZSBwYXJhbWV0ZXJzIGNhbiBiZSBtb2RpZmllZCBieSByZS1J TlZJVEVzIGNhbjxicj4NCiZndDsgc3BlY2lmeSB0aGVpciBvd24gcnVsZXMsIHBvc3NpYmx5IHJl ZmVycmluZyB0byB0aGlzIGRyYWZ0IGFuZCB1c2luZw0KdGhlPGJyPg0KJmd0OyBydWxlcyBkZWZp bmVkIGluIGl0IGJ5IHJlZmVyZW5jZS4gSW4gdGhpcyB3YXksIHRoZSBhcHBsaWNhYmlsaXR5IG9m DQp0aGlzPGJyPg0KJmd0OyBkcmFmdCB3b3VsZCBiZSBtdWNoIGNsZWFyZXIuPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IENvbW1lbnRzPzxicj4NCiZndDsgPGJyPg0KJmd0OyBUaGFua3MsPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IEdvbnphbG88YnI+DQomZ3Q7IDxicj4NCiZndDsgX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IHNpcGNvcmUgbWFpbGlu ZyBsaXN0PGJyPg0KJmd0OyBzaXBjb3JlQGlldGYub3JnPGJyPg0KJmd0OyBodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8YnI+DQomZ3Q7IDxicj4NCjxicj4NCl9f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPGJyPg0Kc2lwY29y ZSBtYWlsaW5nIGxpc3Q8YnI+DQpzaXBjb3JlQGlldGYub3JnPGJyPg0KaHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlPGJyPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8 YnI+DQo8YnI+PHByZT4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tDQpaVEUmbmJzcDtJbmZvcm1hdGlvbiZuYnNwO1NlY3VyaXR5Jm5ic3A7 Tm90aWNlOiZuYnNwO1RoZSZuYnNwO2luZm9ybWF0aW9uJm5ic3A7Y29udGFpbmVkJm5ic3A7aW4m bmJzcDt0aGlzJm5ic3A7bWFpbCZuYnNwO2lzJm5ic3A7c29sZWx5Jm5ic3A7cHJvcGVydHkmbmJz cDtvZiZuYnNwO3RoZSZuYnNwO3NlbmRlcidzJm5ic3A7b3JnYW5pemF0aW9uLiZuYnNwO1RoaXMm bmJzcDttYWlsJm5ic3A7Y29tbXVuaWNhdGlvbiZuYnNwO2lzJm5ic3A7Y29uZmlkZW50aWFsLiZu YnNwO1JlY2lwaWVudHMmbmJzcDtuYW1lZCZuYnNwO2Fib3ZlJm5ic3A7YXJlJm5ic3A7b2JsaWdh dGVkJm5ic3A7dG8mbmJzcDttYWludGFpbiZuYnNwO3NlY3JlY3kmbmJzcDthbmQmbmJzcDthcmUm bmJzcDtub3QmbmJzcDtwZXJtaXR0ZWQmbmJzcDt0byZuYnNwO2Rpc2Nsb3NlJm5ic3A7dGhlJm5i c3A7Y29udGVudHMmbmJzcDtvZiZuYnNwO3RoaXMmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7dG8m bmJzcDtvdGhlcnMuDQpUaGlzJm5ic3A7ZW1haWwmbmJzcDthbmQmbmJzcDthbnkmbmJzcDtmaWxl cyZuYnNwO3RyYW5zbWl0dGVkJm5ic3A7d2l0aCZuYnNwO2l0Jm5ic3A7YXJlJm5ic3A7Y29uZmlk ZW50aWFsJm5ic3A7YW5kJm5ic3A7aW50ZW5kZWQmbmJzcDtzb2xlbHkmbmJzcDtmb3ImbmJzcDt0 aGUmbmJzcDt1c2UmbmJzcDtvZiZuYnNwO3RoZSZuYnNwO2luZGl2aWR1YWwmbmJzcDtvciZuYnNw O2VudGl0eSZuYnNwO3RvJm5ic3A7d2hvbSZuYnNwO3RoZXkmbmJzcDthcmUmbmJzcDthZGRyZXNz ZWQuJm5ic3A7SWYmbmJzcDt5b3UmbmJzcDtoYXZlJm5ic3A7cmVjZWl2ZWQmbmJzcDt0aGlzJm5i c3A7ZW1haWwmbmJzcDtpbiZuYnNwO2Vycm9yJm5ic3A7cGxlYXNlJm5ic3A7bm90aWZ5Jm5ic3A7 dGhlJm5ic3A7b3JpZ2luYXRvciZuYnNwO29mJm5ic3A7dGhlJm5ic3A7bWVzc2FnZS4mbmJzcDtB bnkmbmJzcDt2aWV3cyZuYnNwO2V4cHJlc3NlZCZuYnNwO2luJm5ic3A7dGhpcyZuYnNwO21lc3Nh Z2UmbmJzcDthcmUmbmJzcDt0aG9zZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVhbCZu YnNwO3NlbmRlci4NClRoaXMmbmJzcDttZXNzYWdlJm5ic3A7aGFzJm5ic3A7YmVlbiZuYnNwO3Nj YW5uZWQmbmJzcDtmb3ImbmJzcDt2aXJ1c2VzJm5ic3A7YW5kJm5ic3A7U3BhbSZuYnNwO2J5Jm5i c3A7WlRFJm5ic3A7QW50aS1TcGFtJm5ic3A7c3lzdGVtLg0KPC9wcmU+ --=_alternative 001462C248257765_=-- From gonzalo.camarillo@ericsson.com Sun Jul 18 23:35:48 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D23D3A69F5 for ; Sun, 18 Jul 2010 23:35:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.51 X-Spam-Level: X-Spam-Status: No, score=-104.51 tagged_above=-999 required=5 tests=[AWL=-0.361, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, 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 XLkx3TN8cbrT for ; Sun, 18 Jul 2010 23:35:46 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id EDC563A69F1 for ; Sun, 18 Jul 2010 23:35:45 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-fe-4c43f24e3b61 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 0E.3C.10125.E42F34C4; Mon, 19 Jul 2010 08:35:59 +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, 19 Jul 2010 08:35:58 +0200 Received: from [131.160.126.163] ([131.160.126.163]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 08:35:58 +0200 Message-ID: <4C43F24E.7070901@ericsson.com> Date: Mon, 19 Jul 2010 09:35:58 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.10) Gecko/20100512 Thunderbird/3.0.5 MIME-Version: 1.0 To: "gao.yang2@zte.com.cn" References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 19 Jul 2010 06:35:58.0477 (UTC) FILETIME=[A5CA23D0:01CB270C] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 19 Jul 2010 06:35:48 -0000 Hi Gao, thanks for your answers. Regarding Section 4.8, I agree with you it is not about glare. That is why the title of the section does not mention glare. It mentions race conditions. I think we are OK. Thanks for your comments, Gonzalo On 19/07/2010 6:40 AM, gao.yang2@zte.com.cn wrote: > > Hi Gonzalo, > > I found time to read this version on weekend. And there are three main > points: > > 1. Glare Situations(section 3.5) > As the new way, this part is relatively simple now. And the new way is > sending a new refresh usage Re-INVITE to synchronize state for any glare > situations. > This is simple, and effective. So, I am OK at this point. > > 2. Race Conditions and Target Refreshes(section 4.8) > To disallow target refreshes in unreliable response can solve this > problem. And in fact, I think it is a nice way, as do "Target Refreshes" > in unreliable response is unreliable. So, I'm OK with it. > As this rule's meaning is more than glare issue, so we may put this rule > in a new section, and only mention in section 4.8 that galre problem > here can be solved by this rule. > > 3. Section 5 > I am OK with this section's revision. > > Thanks, > > Gao > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > > > *Gonzalo Camarillo * > ·¢¼þÈË: sipcore-bounces@ietf.org > > 2010-07-15 18:26 > > > ÊÕ¼þÈË > Gonzalo Camarillo > ³­ËÍ > SIPCORE > Ö÷Ìâ > Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite > > > > > > > > > Hi, > > thanks for the feedback I have received on and off list. We seem to have > consensus on reducing the scope of the draft to session state and target > refreshes. That is great because it allows us to hugely simplify the > rules to avoid glare conditions (this is something a few of you have > requested on the list in the past). I have put together a new revision > of the draft, which you can fetch from: > > http://users.piuha.net/gonzalo/temp/draft-ietf-sipcore-reinvite-pre05-01.txt > > In addition to adjusting the scope of the draft and simplifying the > glare-related rules, I have also added a few clarifications to Section 5 > in response to Robert's AD review. > > Let me know if you have any comments. > > Thanks, > > Gonzalo > > > On 05/07/2010 9:34 AM, Gonzalo Camarillo wrote: >> Hi, >> >> the re-INVITE draft talks about modifications in the session state, >> dialog state, and the dialog's remote target. While it is relatively >> well understood what we mean by session state and the dialog's remote >> target, we do not really have a good definition for dialog state. >> >> We have discussed it in the past and what people had in mind were things >> such as called party identity. However, the draft is too vague at this >> point; it should be more precise regarding which piece of "dialog state" >> the rules in the draft apply to. >> >> My suggestion would be to have the draft talk only about session state >> and the dialog's remote target, and forget about any other dialog state. >> New extensions whose parameters can be modified by re-INVITEs can >> specify their own rules, possibly referring to this draft and using the >> rules defined in it by reference. In this way, the applicability of this >> draft would be much clearer. >> >> Comments? >> >> Thanks, >> >> 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 18 23:53:08 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8555A3A69EF for ; Sun, 18 Jul 2010 23:53:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.582 X-Spam-Level: X-Spam-Status: No, score=-97.582 tagged_above=-999 required=5 tests=[AWL=0.053, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 7+PpHFeK8RMU for ; Sun, 18 Jul 2010 23:53:07 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 004643A699C for ; Sun, 18 Jul 2010 23:53:04 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 35101727820181; Mon, 19 Jul 2010 14:52:28 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 83990.2980680612; Mon, 19 Jul 2010 14:51:31 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o6J6XcSq095260; Mon, 19 Jul 2010 14:50:14 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4C43F24E.7070901@ericsson.com> To: Gonzalo Camarillo MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Mon, 19 Jul 2010 14:46:00 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-19 14:50:06, Serialize complete at 2010-07-19 14:50:06 Content-Type: multipart/alternative; boundary="=_alternative 002564C148257765_=" X-MAIL: mse2.zte.com.cn o6J6XcSq095260 Cc: SIPCORE Subject: Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 19 Jul 2010 06:53:08 -0000 This is a multipart message in MIME format. --=_alternative 002564C148257765_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgR29uemFsbywNCg0KWW91ciBleHBsYW5hdGlvbiB3b3JrcyBmb3IgbWUgYXQgdGhpcyBzbWFs bCBwb2ludC4NCg0KVGhlbiwgSSBhbSBPSyB3aXRoIGFsbCB0aGUgdGhyZWUgcG9pbnRzLg0KDQpD aGVlcnMsDQoNCkdhbyANCg0KPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0NCiBa aXAgICAgOiAyMTAwMTINCiBUZWwgICAgOiA4NzIxMQ0KIFRlbDIgICA6KCs4NiktMDI1LTUyODc3 MjExDQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY24NCj09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09DQoNCg0KDQpHb256YWxvIENhbWFyaWxsbyA8R29uemFsby5DYW1hcmls bG9AZXJpY3Nzb24uY29tPiANCreivP7IyzogIHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZw0KMjAx MC0wNy0xOSAxNDozNQ0KDQrK1bz+yMsNCiJnYW8ueWFuZzJAenRlLmNvbS5jbiIgPGdhby55YW5n MkB6dGUuY29tLmNuPg0Ks63LzQ0KU0lQQ09SRSA8c2lwY29yZUBpZXRmLm9yZz4NCtb3zOINClJl OiBbc2lwY29yZV0gRGlhbG9nIHN0YXRlIC0gU2NvcGUgaW4gZHJhZnQtaWV0Zi1zaXBjb3JlLXJl aW52aXRlDQoNCg0KDQoNCg0KDQpIaSBHYW8sDQoNCnRoYW5rcyBmb3IgeW91ciBhbnN3ZXJzLiBS ZWdhcmRpbmcgU2VjdGlvbiA0LjgsIEkgYWdyZWUgd2l0aCB5b3UgaXQgaXMNCm5vdCBhYm91dCBn bGFyZS4gVGhhdCBpcyB3aHkgdGhlIHRpdGxlIG9mIHRoZSBzZWN0aW9uIGRvZXMgbm90IG1lbnRp b24NCmdsYXJlLiBJdCBtZW50aW9ucyByYWNlIGNvbmRpdGlvbnMuIEkgdGhpbmsgd2UgYXJlIE9L Lg0KDQpUaGFua3MgZm9yIHlvdXIgY29tbWVudHMsDQoNCkdvbnphbG8NCg0KT24gMTkvMDcvMjAx MCA2OjQwIEFNLCBnYW8ueWFuZzJAenRlLmNvbS5jbiB3cm90ZToNCj4gDQo+IEhpIEdvbnphbG8s DQo+IA0KPiBJIGZvdW5kIHRpbWUgdG8gcmVhZCB0aGlzIHZlcnNpb24gb24gd2Vla2VuZC4gQW5k IHRoZXJlIGFyZSB0aHJlZSBtYWluDQo+IHBvaW50czoNCj4gDQo+IDEuIEdsYXJlIFNpdHVhdGlv bnMoc2VjdGlvbiAzLjUpDQo+IEFzIHRoZSBuZXcgd2F5LCB0aGlzIHBhcnQgaXMgcmVsYXRpdmVs eSBzaW1wbGUgbm93LiBBbmQgdGhlIG5ldyB3YXkgaXMNCj4gc2VuZGluZyBhIG5ldyByZWZyZXNo IHVzYWdlIFJlLUlOVklURSB0byBzeW5jaHJvbml6ZSBzdGF0ZSBmb3IgYW55IGdsYXJlDQo+IHNp dHVhdGlvbnMuDQo+IFRoaXMgaXMgc2ltcGxlLCBhbmQgZWZmZWN0aXZlLiBTbywgSSBhbSBPSyBh dCB0aGlzIHBvaW50Lg0KPiANCj4gMi4gUmFjZSBDb25kaXRpb25zIGFuZCBUYXJnZXQgUmVmcmVz aGVzKHNlY3Rpb24gNC44KQ0KPiBUbyBkaXNhbGxvdyB0YXJnZXQgcmVmcmVzaGVzIGluIHVucmVs aWFibGUgcmVzcG9uc2UgY2FuIHNvbHZlIHRoaXMNCj4gcHJvYmxlbS4gQW5kIGluIGZhY3QsIEkg dGhpbmsgaXQgaXMgYSBuaWNlIHdheSwgYXMgZG8gIlRhcmdldCBSZWZyZXNoZXMiDQo+IGluIHVu cmVsaWFibGUgcmVzcG9uc2UgaXMgdW5yZWxpYWJsZS4gU28sIEknbSBPSyB3aXRoIGl0Lg0KPiBB cyB0aGlzIHJ1bGUncyBtZWFuaW5nIGlzIG1vcmUgdGhhbiBnbGFyZSBpc3N1ZSwgc28gd2UgbWF5 IHB1dCB0aGlzIHJ1bGUNCj4gaW4gYSBuZXcgc2VjdGlvbiwgYW5kIG9ubHkgbWVudGlvbiBpbiBz ZWN0aW9uIDQuOCB0aGF0IGdhbHJlIHByb2JsZW0NCj4gaGVyZSBjYW4gYmUgc29sdmVkIGJ5IHRo aXMgcnVsZS4NCj4gDQo+IDMuIFNlY3Rpb24gNQ0KPiBJIGFtIE9LIHdpdGggdGhpcyBzZWN0aW9u J3MgcmV2aXNpb24uDQo+IA0KPiBUaGFua3MsDQo+IA0KPiBHYW8NCj4gDQo+ID09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09DQo+IFppcCAgICA6IDIxMDAxMg0KPiBUZWwgICAgOiA4 NzIxMQ0KPiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KPiBlX21haWwgOiBnYW8ueWFuZzJA enRlLmNvbS5jbg0KPiA9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQ0KPiANCj4g DQo+ICpHb256YWxvIENhbWFyaWxsbyA8R29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24uY29tPioN Cj4gt6K8/sjLOiAgc2lwY29yZS1ib3VuY2VzQGlldGYub3JnDQo+IA0KPiAyMDEwLTA3LTE1IDE4 OjI2DQo+IA0KPiANCj4gytW8/sjLDQo+ICAgICAgICAgICAgICAgIEdvbnphbG8gQ2FtYXJpbGxv IDxHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5jb20+DQo+ILOty80NCj4gICAgICAgICAgICAg ICAgU0lQQ09SRSA8c2lwY29yZUBpZXRmLm9yZz4NCj4g1vfM4g0KPiAgICAgICAgICAgICAgICBS ZTogW3NpcGNvcmVdIERpYWxvZyBzdGF0ZSAtIFNjb3BlIGluIA0KZHJhZnQtaWV0Zi1zaXBjb3Jl LXJlaW52aXRlDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gDQo+IA0KPiANCj4gSGksDQo+IA0KPiB0 aGFua3MgZm9yIHRoZSBmZWVkYmFjayBJIGhhdmUgcmVjZWl2ZWQgb24gYW5kIG9mZiBsaXN0LiBX ZSBzZWVtIHRvIGhhdmUNCj4gY29uc2Vuc3VzIG9uIHJlZHVjaW5nIHRoZSBzY29wZSBvZiB0aGUg ZHJhZnQgdG8gc2Vzc2lvbiBzdGF0ZSBhbmQgdGFyZ2V0DQo+IHJlZnJlc2hlcy4gVGhhdCBpcyBn cmVhdCBiZWNhdXNlIGl0IGFsbG93cyB1cyB0byBodWdlbHkgc2ltcGxpZnkgdGhlDQo+IHJ1bGVz IHRvIGF2b2lkIGdsYXJlIGNvbmRpdGlvbnMgKHRoaXMgaXMgc29tZXRoaW5nIGEgZmV3IG9mIHlv dSBoYXZlDQo+IHJlcXVlc3RlZCBvbiB0aGUgbGlzdCBpbiB0aGUgcGFzdCkuIEkgaGF2ZSBwdXQg dG9nZXRoZXIgYSBuZXcgcmV2aXNpb24NCj4gb2YgdGhlIGRyYWZ0LCB3aGljaCB5b3UgY2FuIGZl dGNoIGZyb206DQo+IA0KPiANCmh0dHA6Ly91c2Vycy5waXVoYS5uZXQvZ29uemFsby90ZW1wL2Ry YWZ0LWlldGYtc2lwY29yZS1yZWludml0ZS1wcmUwNS0wMS50eHQNCg0KPiANCj4gSW4gYWRkaXRp b24gdG8gYWRqdXN0aW5nIHRoZSBzY29wZSBvZiB0aGUgZHJhZnQgYW5kIHNpbXBsaWZ5aW5nIHRo ZQ0KPiBnbGFyZS1yZWxhdGVkIHJ1bGVzLCBJIGhhdmUgYWxzbyBhZGRlZCBhIGZldyBjbGFyaWZp Y2F0aW9ucyB0byBTZWN0aW9uIDUNCj4gaW4gcmVzcG9uc2UgdG8gUm9iZXJ0J3MgQUQgcmV2aWV3 Lg0KPiANCj4gTGV0IG1lIGtub3cgaWYgeW91IGhhdmUgYW55IGNvbW1lbnRzLg0KPiANCj4gVGhh bmtzLA0KPiANCj4gR29uemFsbw0KPiANCj4gDQo+IE9uIDA1LzA3LzIwMTAgOTozNCBBTSwgR29u emFsbyBDYW1hcmlsbG8gd3JvdGU6DQo+PiBIaSwNCj4+DQo+PiB0aGUgcmUtSU5WSVRFIGRyYWZ0 IHRhbGtzIGFib3V0IG1vZGlmaWNhdGlvbnMgaW4gdGhlIHNlc3Npb24gc3RhdGUsDQo+PiBkaWFs b2cgc3RhdGUsIGFuZCB0aGUgZGlhbG9nJ3MgcmVtb3RlIHRhcmdldC4gV2hpbGUgaXQgaXMgcmVs YXRpdmVseQ0KPj4gd2VsbCB1bmRlcnN0b29kIHdoYXQgd2UgbWVhbiBieSBzZXNzaW9uIHN0YXRl IGFuZCB0aGUgZGlhbG9nJ3MgcmVtb3RlDQo+PiB0YXJnZXQsIHdlIGRvIG5vdCByZWFsbHkgaGF2 ZSBhIGdvb2QgZGVmaW5pdGlvbiBmb3IgZGlhbG9nIHN0YXRlLg0KPj4NCj4+IFdlIGhhdmUgZGlz Y3Vzc2VkIGl0IGluIHRoZSBwYXN0IGFuZCB3aGF0IHBlb3BsZSBoYWQgaW4gbWluZCB3ZXJlIA0K dGhpbmdzDQo+PiBzdWNoIGFzIGNhbGxlZCBwYXJ0eSBpZGVudGl0eS4gSG93ZXZlciwgdGhlIGRy YWZ0IGlzIHRvbyB2YWd1ZSBhdCB0aGlzDQo+PiBwb2ludDsgaXQgc2hvdWxkIGJlIG1vcmUgcHJl Y2lzZSByZWdhcmRpbmcgd2hpY2ggcGllY2Ugb2YgImRpYWxvZyANCnN0YXRlIg0KPj4gdGhlIHJ1 bGVzIGluIHRoZSBkcmFmdCBhcHBseSB0by4NCj4+DQo+PiBNeSBzdWdnZXN0aW9uIHdvdWxkIGJl IHRvIGhhdmUgdGhlIGRyYWZ0IHRhbGsgb25seSBhYm91dCBzZXNzaW9uIHN0YXRlDQo+PiBhbmQg dGhlIGRpYWxvZydzIHJlbW90ZSB0YXJnZXQsIGFuZCBmb3JnZXQgYWJvdXQgYW55IG90aGVyIGRp YWxvZyANCnN0YXRlLg0KPj4gTmV3IGV4dGVuc2lvbnMgd2hvc2UgcGFyYW1ldGVycyBjYW4gYmUg bW9kaWZpZWQgYnkgcmUtSU5WSVRFcyBjYW4NCj4+IHNwZWNpZnkgdGhlaXIgb3duIHJ1bGVzLCBw b3NzaWJseSByZWZlcnJpbmcgdG8gdGhpcyBkcmFmdCBhbmQgdXNpbmcgdGhlDQo+PiBydWxlcyBk ZWZpbmVkIGluIGl0IGJ5IHJlZmVyZW5jZS4gSW4gdGhpcyB3YXksIHRoZSBhcHBsaWNhYmlsaXR5 IG9mIA0KdGhpcw0KPj4gZHJhZnQgd291bGQgYmUgbXVjaCBjbGVhcmVyLg0KPj4NCj4+IENvbW1l bnRzPw0KPj4NCj4+IFRoYW5rcywNCj4+DQo+PiBHb256YWxvDQo+Pg0KPj4gX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+IHNpcGNvcmUgbWFpbGluZyBs aXN0DQo+PiBzaXBjb3JlQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu L2xpc3RpbmZvL3NpcGNvcmUNCj4+DQo+IA0KPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fXw0KPiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiBzaXBjb3JlQGll dGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0K PiANCj4gDQo+IA0KPiAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KPiBaVEUgSW5mb3JtYXRpb24gU2VjdXJpdHkgTm90aWNlOiBUaGUgaW5m b3JtYXRpb24gY29udGFpbmVkIGluIHRoaXMgbWFpbCANCmlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0 aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiANCmlzIGNv bmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50 YWluIHNlY3JlY3kgDQphbmQgYXJlIG5vdCBwZXJtaXR0ZWQgdG8gZGlzY2xvc2UgdGhlIGNvbnRl bnRzIG9mIHRoaXMgY29tbXVuaWNhdGlvbiB0byANCm90aGVycy4NCj4gVGhpcyBlbWFpbCBhbmQg YW55IGZpbGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgDQppbnRl bmRlZCBzb2xlbHkgZm9yIHRoZSB1c2Ugb2YgdGhlIGluZGl2aWR1YWwgb3IgZW50aXR5IHRvIHdo b20gdGhleSBhcmUgDQphZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwg aW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgDQpvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBB bnkgdmlld3MgZXhwcmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2UgDQpvZiB0aGUgaW5k aXZpZHVhbCBzZW5kZXIuDQo+IFRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1 c2VzIGFuZCBTcGFtIGJ5IFpURSBBbnRpLVNwYW0gDQpzeXN0ZW0uDQo+IA0KDQpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0Kc2lwY29yZSBtYWlsaW5nIGxp c3QNCnNpcGNvcmVAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu Zm8vc2lwY29yZQ0KDQoNCg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLQ0KWlRFIEluZm9ybWF0aW9uIFNlY3VyaXR5IE5vdGljZTogVGhl IGluZm9ybWF0aW9uIGNvbnRhaW5lZCBpbiB0aGlzIG1haWwgaXMgc29sZWx5IHByb3BlcnR5IG9m IHRoZSBzZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIGlzIGNv bmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50 YWluIHNlY3JlY3kgYW5kIGFyZSBub3QgcGVybWl0dGVkIHRvIGRpc2Nsb3NlIHRoZSBjb250ZW50 cyBvZiB0aGlzIGNvbW11bmljYXRpb24gdG8gb3RoZXJzLg0KVGhpcyBlbWFpbCBhbmQgYW55IGZp bGVzIHRyYW5zbWl0dGVkIHdpdGggaXQgYXJlIGNvbmZpZGVudGlhbCBhbmQgaW50ZW5kZWQgc29s ZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0byB3aG9tIHRoZXkg YXJlIGFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBlcnJvciBw bGVhc2Ugbm90aWZ5IHRoZSBvcmlnaW5hdG9yIG9mIHRoZSBtZXNzYWdlLiBBbnkgdmlld3MgZXhw cmVzc2VkIGluIHRoaXMgbWVzc2FnZSBhcmUgdGhvc2Ugb2YgdGhlIGluZGl2aWR1YWwgc2VuZGVy Lg0KVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkg WlRFIEFudGktU3BhbSBzeXN0ZW0uDQo= --=_alternative 002564C148257765_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEdvbnphbG8sPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5Zb3VyIGV4cGxhbmF0aW9u IHdvcmtzIGZvciBtZSBhdCB0aGlzDQpzbWFsbCBwb2ludC48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoZW4sIEkgYW0gT0sgd2l0aCBhbGwgdGhlIHRo cmVlIHBvaW50cy48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPkNoZWVycyw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2Vy aWYiPkdhbyA8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYi Pj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KIFppcCAmbmJzcDsgJm5i c3A7OiAyMTAwMTI8YnI+DQogVGVsICZuYnNwOyAmbmJzcDs6IDg3MjExPGJyPg0KIFRlbDIgJm5i c3A7IDooKzg2KS0wMjUtNTI4NzcyMTE8YnI+DQogZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20u Y248YnI+DQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PTwvZm9udD4NCjxicj4N Cjxicj4NCjxicj4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQgd2lk dGg9MzUlPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj48Yj5Hb256YWxvIENhbWFyaWxs byAmbHQ7R29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24uY29tJmd0OzwvYj4NCjwvZm9udD4NCjxi cj48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+t6K8/sjLOiAmbmJzcDtzaXBjb3JlLWJv dW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+DQo8cD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+ MjAxMC0wNy0xOSAxNDozNTwvZm9udD4NCjx0ZCB3aWR0aD02NCU+DQo8dGFibGUgd2lkdGg9MTAw JT4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGlnbj1yaWdodD48Zm9udCBzaXplPTEg ZmFjZT0ic2Fucy1zZXJpZiI+ytW8/sjLPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBm YWNlPSJzYW5zLXNlcmlmIj4mcXVvdDtnYW8ueWFuZzJAenRlLmNvbS5jbiZxdW90OyAmbHQ7Z2Fv LnlhbmcyQHp0ZS5jb20uY24mZ3Q7PC9mb250Pg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2 IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj6zrcvNPC9mb250Pjwv ZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj5TSVBDT1JFICZsdDtzaXBj b3JlQGlldGYub3JnJmd0OzwvZm9udD4NCjx0ciB2YWxpZ249dG9wPg0KPHRkPg0KPGRpdiBhbGln bj1yaWdodD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+1vfM4jwvZm9udD48L2Rpdj4N Cjx0ZD48Zm9udCBzaXplPTEgZmFjZT0ic2Fucy1zZXJpZiI+UmU6IFtzaXBjb3JlXSBEaWFsb2cg c3RhdGUgLSBTY29wZSBpbg0KZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlPC9mb250PjwvdGFi bGU+DQo8YnI+DQo8dGFibGU+DQo8dHIgdmFsaWduPXRvcD4NCjx0ZD4NCjx0ZD48L3RhYmxlPg0K PGJyPjwvdGFibGU+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5IaSBHYW8sPGJy Pg0KPGJyPg0KdGhhbmtzIGZvciB5b3VyIGFuc3dlcnMuIFJlZ2FyZGluZyBTZWN0aW9uIDQuOCwg SSBhZ3JlZSB3aXRoIHlvdSBpdCBpczxicj4NCm5vdCBhYm91dCBnbGFyZS4gVGhhdCBpcyB3aHkg dGhlIHRpdGxlIG9mIHRoZSBzZWN0aW9uIGRvZXMgbm90IG1lbnRpb248YnI+DQpnbGFyZS4gSXQg bWVudGlvbnMgcmFjZSBjb25kaXRpb25zLiBJIHRoaW5rIHdlIGFyZSBPSy48YnI+DQo8YnI+DQpU aGFua3MgZm9yIHlvdXIgY29tbWVudHMsPGJyPg0KPGJyPg0KR29uemFsbzxicj4NCjxicj4NCk9u IDE5LzA3LzIwMTAgNjo0MCBBTSwgZ2FvLnlhbmcyQHp0ZS5jb20uY24gd3JvdGU6PGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IEhpIEdvbnphbG8sPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IEkgZm91bmQgdGlt ZSB0byByZWFkIHRoaXMgdmVyc2lvbiBvbiB3ZWVrZW5kLiBBbmQgdGhlcmUgYXJlIHRocmVlDQpt YWluPGJyPg0KJmd0OyBwb2ludHM6PGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDEuIEdsYXJlIFNpdHVh dGlvbnMoc2VjdGlvbiAzLjUpPGJyPg0KJmd0OyBBcyB0aGUgbmV3IHdheSwgdGhpcyBwYXJ0IGlz IHJlbGF0aXZlbHkgc2ltcGxlIG5vdy4gQW5kIHRoZSBuZXcgd2F5DQppczxicj4NCiZndDsgc2Vu ZGluZyBhIG5ldyByZWZyZXNoIHVzYWdlIFJlLUlOVklURSB0byBzeW5jaHJvbml6ZSBzdGF0ZSBm b3IgYW55DQpnbGFyZTxicj4NCiZndDsgc2l0dWF0aW9ucy48YnI+DQomZ3Q7IFRoaXMgaXMgc2lt cGxlLCBhbmQgZWZmZWN0aXZlLiBTbywgSSBhbSBPSyBhdCB0aGlzIHBvaW50Ljxicj4NCiZndDsg PGJyPg0KJmd0OyAyLiBSYWNlIENvbmRpdGlvbnMgYW5kIFRhcmdldCBSZWZyZXNoZXMoc2VjdGlv biA0LjgpPGJyPg0KJmd0OyBUbyBkaXNhbGxvdyB0YXJnZXQgcmVmcmVzaGVzIGluIHVucmVsaWFi bGUgcmVzcG9uc2UgY2FuIHNvbHZlIHRoaXM8YnI+DQomZ3Q7IHByb2JsZW0uIEFuZCBpbiBmYWN0 LCBJIHRoaW5rIGl0IGlzIGEgbmljZSB3YXksIGFzIGRvICZxdW90O1RhcmdldA0KUmVmcmVzaGVz JnF1b3Q7PGJyPg0KJmd0OyBpbiB1bnJlbGlhYmxlIHJlc3BvbnNlIGlzIHVucmVsaWFibGUuIFNv LCBJJ20gT0sgd2l0aCBpdC48YnI+DQomZ3Q7IEFzIHRoaXMgcnVsZSdzIG1lYW5pbmcgaXMgbW9y ZSB0aGFuIGdsYXJlIGlzc3VlLCBzbyB3ZSBtYXkgcHV0IHRoaXMNCnJ1bGU8YnI+DQomZ3Q7IGlu IGEgbmV3IHNlY3Rpb24sIGFuZCBvbmx5IG1lbnRpb24gaW4gc2VjdGlvbiA0LjggdGhhdCBnYWxy ZSBwcm9ibGVtPGJyPg0KJmd0OyBoZXJlIGNhbiBiZSBzb2x2ZWQgYnkgdGhpcyBydWxlLjxicj4N CiZndDsgPGJyPg0KJmd0OyAzLiBTZWN0aW9uIDU8YnI+DQomZ3Q7IEkgYW0gT0sgd2l0aCB0aGlz IHNlY3Rpb24ncyByZXZpc2lvbi48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzLDxicj4NCiZn dDsgPGJyPg0KJmd0OyBHYW88YnI+DQomZ3Q7IDxicj4NCiZndDsgPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT08YnI+DQomZ3Q7IFppcCAmbmJzcDsgJm5ic3A7OiAyMTAwMTI8YnI+ DQomZ3Q7IFRlbCAmbmJzcDsgJm5ic3A7OiA4NzIxMTxicj4NCiZndDsgVGVsMiAmbmJzcDsgOigr ODYpLTAyNS01Mjg3NzIxMTxicj4NCiZndDsgZV9tYWlsIDogZ2FvLnlhbmcyQHp0ZS5jb20uY248 YnI+DQomZ3Q7ID09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IDxicj4NCiZndDsgKkdvbnphbG8gQ2FtYXJpbGxvICZsdDtHb256YWxvLkNhbWFy aWxsb0Blcmljc3Nvbi5jb20mZ3Q7Kjxicj4NCiZndDsgt6K8/sjLOiAmbmJzcDtzaXBjb3JlLWJv dW5jZXNAaWV0Zi5vcmc8YnI+DQomZ3Q7IDxicj4NCiZndDsgMjAxMC0wNy0xNSAxODoyNjxicj4N CiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOzxicj4NCiZndDsgytW8/sjLPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0dv bnphbG8NCkNhbWFyaWxsbyAmbHQ7R29uemFsby5DYW1hcmlsbG9AZXJpY3Nzb24uY29tJmd0Ozxi cj4NCiZndDsgs63LzTxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtTSVBDT1JFDQombHQ7c2lwY29yZUBpZXRmLm9y ZyZndDs8YnI+DQomZ3Q7INb3zOI8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7UmU6DQpbc2lwY29yZV0gRGlhbG9n IHN0YXRlIC0gU2NvcGUgaW4gZHJhZnQtaWV0Zi1zaXBjb3JlLXJlaW52aXRlPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDs8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0 OyA8YnI+DQomZ3Q7IDxicj4NCiZndDsgPGJyPg0KJmd0OyBIaSw8YnI+DQomZ3Q7IDxicj4NCiZn dDsgdGhhbmtzIGZvciB0aGUgZmVlZGJhY2sgSSBoYXZlIHJlY2VpdmVkIG9uIGFuZCBvZmYgbGlz dC4gV2Ugc2VlbSB0bw0KaGF2ZTxicj4NCiZndDsgY29uc2Vuc3VzIG9uIHJlZHVjaW5nIHRoZSBz Y29wZSBvZiB0aGUgZHJhZnQgdG8gc2Vzc2lvbiBzdGF0ZSBhbmQNCnRhcmdldDxicj4NCiZndDsg cmVmcmVzaGVzLiBUaGF0IGlzIGdyZWF0IGJlY2F1c2UgaXQgYWxsb3dzIHVzIHRvIGh1Z2VseSBz aW1wbGlmeSB0aGU8YnI+DQomZ3Q7IHJ1bGVzIHRvIGF2b2lkIGdsYXJlIGNvbmRpdGlvbnMgKHRo aXMgaXMgc29tZXRoaW5nIGEgZmV3IG9mIHlvdSBoYXZlPGJyPg0KJmd0OyByZXF1ZXN0ZWQgb24g dGhlIGxpc3QgaW4gdGhlIHBhc3QpLiBJIGhhdmUgcHV0IHRvZ2V0aGVyIGEgbmV3IHJldmlzaW9u PGJyPg0KJmd0OyBvZiB0aGUgZHJhZnQsIHdoaWNoIHlvdSBjYW4gZmV0Y2ggZnJvbTo8YnI+DQom Z3Q7IDxicj4NCiZndDsgaHR0cDovL3VzZXJzLnBpdWhhLm5ldC9nb256YWxvL3RlbXAvZHJhZnQt aWV0Zi1zaXBjb3JlLXJlaW52aXRlLXByZTA1LTAxLnR4dDxicj4NCiZndDsgPGJyPg0KJmd0OyBJ biBhZGRpdGlvbiB0byBhZGp1c3RpbmcgdGhlIHNjb3BlIG9mIHRoZSBkcmFmdCBhbmQgc2ltcGxp ZnlpbmcgdGhlPGJyPg0KJmd0OyBnbGFyZS1yZWxhdGVkIHJ1bGVzLCBJIGhhdmUgYWxzbyBhZGRl ZCBhIGZldyBjbGFyaWZpY2F0aW9ucyB0byBTZWN0aW9uDQo1PGJyPg0KJmd0OyBpbiByZXNwb25z ZSB0byBSb2JlcnQncyBBRCByZXZpZXcuPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IExldCBtZSBrbm93 IGlmIHlvdSBoYXZlIGFueSBjb21tZW50cy48YnI+DQomZ3Q7IDxicj4NCiZndDsgVGhhbmtzLDxi cj4NCiZndDsgPGJyPg0KJmd0OyBHb256YWxvPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxicj4NCiZn dDsgT24gMDUvMDcvMjAxMCA5OjM0IEFNLCBHb256YWxvIENhbWFyaWxsbyB3cm90ZTo8YnI+DQom Z3Q7Jmd0OyBIaSw8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsmZ3Q7IHRoZSByZS1JTlZJVEUgZHJh ZnQgdGFsa3MgYWJvdXQgbW9kaWZpY2F0aW9ucyBpbiB0aGUgc2Vzc2lvbiBzdGF0ZSw8YnI+DQom Z3Q7Jmd0OyBkaWFsb2cgc3RhdGUsIGFuZCB0aGUgZGlhbG9nJ3MgcmVtb3RlIHRhcmdldC4gV2hp bGUgaXQgaXMgcmVsYXRpdmVseTxicj4NCiZndDsmZ3Q7IHdlbGwgdW5kZXJzdG9vZCB3aGF0IHdl IG1lYW4gYnkgc2Vzc2lvbiBzdGF0ZSBhbmQgdGhlIGRpYWxvZydzDQpyZW1vdGU8YnI+DQomZ3Q7 Jmd0OyB0YXJnZXQsIHdlIGRvIG5vdCByZWFsbHkgaGF2ZSBhIGdvb2QgZGVmaW5pdGlvbiBmb3Ig ZGlhbG9nIHN0YXRlLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgV2UgaGF2ZSBkaXNjdXNz ZWQgaXQgaW4gdGhlIHBhc3QgYW5kIHdoYXQgcGVvcGxlIGhhZCBpbiBtaW5kIHdlcmUNCnRoaW5n czxicj4NCiZndDsmZ3Q7IHN1Y2ggYXMgY2FsbGVkIHBhcnR5IGlkZW50aXR5LiBIb3dldmVyLCB0 aGUgZHJhZnQgaXMgdG9vIHZhZ3VlDQphdCB0aGlzPGJyPg0KJmd0OyZndDsgcG9pbnQ7IGl0IHNo b3VsZCBiZSBtb3JlIHByZWNpc2UgcmVnYXJkaW5nIHdoaWNoIHBpZWNlIG9mICZxdW90O2RpYWxv Zw0Kc3RhdGUmcXVvdDs8YnI+DQomZ3Q7Jmd0OyB0aGUgcnVsZXMgaW4gdGhlIGRyYWZ0IGFwcGx5 IHRvLjxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgTXkgc3VnZ2VzdGlvbiB3b3VsZCBiZSB0 byBoYXZlIHRoZSBkcmFmdCB0YWxrIG9ubHkgYWJvdXQgc2Vzc2lvbg0Kc3RhdGU8YnI+DQomZ3Q7 Jmd0OyBhbmQgdGhlIGRpYWxvZydzIHJlbW90ZSB0YXJnZXQsIGFuZCBmb3JnZXQgYWJvdXQgYW55 IG90aGVyIGRpYWxvZw0Kc3RhdGUuPGJyPg0KJmd0OyZndDsgTmV3IGV4dGVuc2lvbnMgd2hvc2Ug cGFyYW1ldGVycyBjYW4gYmUgbW9kaWZpZWQgYnkgcmUtSU5WSVRFcw0KY2FuPGJyPg0KJmd0OyZn dDsgc3BlY2lmeSB0aGVpciBvd24gcnVsZXMsIHBvc3NpYmx5IHJlZmVycmluZyB0byB0aGlzIGRy YWZ0IGFuZA0KdXNpbmcgdGhlPGJyPg0KJmd0OyZndDsgcnVsZXMgZGVmaW5lZCBpbiBpdCBieSBy ZWZlcmVuY2UuIEluIHRoaXMgd2F5LCB0aGUgYXBwbGljYWJpbGl0eQ0Kb2YgdGhpczxicj4NCiZn dDsmZ3Q7IGRyYWZ0IHdvdWxkIGJlIG11Y2ggY2xlYXJlci48YnI+DQomZ3Q7Jmd0Ozxicj4NCiZn dDsmZ3Q7IENvbW1lbnRzPzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgVGhhbmtzLDxicj4N CiZndDsmZ3Q7PGJyPg0KJmd0OyZndDsgR29uemFsbzxicj4NCiZndDsmZ3Q7PGJyPg0KJmd0OyZn dDsgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQom Z3Q7Jmd0OyBzaXBjb3JlIG1haWxpbmcgbGlzdDxicj4NCiZndDsmZ3Q7IHNpcGNvcmVAaWV0Zi5v cmc8YnI+DQomZ3Q7Jmd0OyBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Np cGNvcmU8YnI+DQomZ3Q7Jmd0Ozxicj4NCiZndDsgPGJyPg0KJmd0OyBfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCiZndDsgc2lwY29yZSBtYWlsaW5n IGxpc3Q8YnI+DQomZ3Q7IHNpcGNvcmVAaWV0Zi5vcmc8YnI+DQomZ3Q7IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZTxicj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+ DQomZ3Q7IDxicj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS08YnI+DQomZ3Q7IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3Rp Y2U6IFRoZSBpbmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcw0KbWFpbCBpcyBzb2xlbHkgcHJv cGVydHkgb2YgdGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRp b24NCmlzIGNvbmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVk IHRvIG1haW50YWluIHNlY3JlY3kNCmFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0 aGUgY29udGVudHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvDQpvdGhlcnMuPGJyPg0KJmd0OyBU aGlzIGVtYWlsIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50 aWFsIGFuZA0KaW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9y IGVudGl0eSB0byB3aG9tIHRoZXkgYXJlDQphZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVk IHRoaXMgZW1haWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvcg0Kb2YgdGhl IG1lc3NhZ2UuIEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBv ZiB0aGUgaW5kaXZpZHVhbA0Kc2VuZGVyLjxicj4NCiZndDsgVGhpcyBtZXNzYWdlIGhhcyBiZWVu IHNjYW5uZWQgZm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbQ0Kc3lzdGVtLjxi cj4NCiZndDsgPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX188YnI+DQpzaXBjb3JlIG1haWxpbmcgbGlzdDxicj4NCnNpcGNvcmVAaWV0Zi5v cmc8YnI+DQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8YnI+ DQo8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5i c3A7U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtj b250YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkm bmJzcDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6 YXRpb24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJz cDtjb25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJz cDthcmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZu YnNwO2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlz Y2xvc2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11 bmljYXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZu YnNwO2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJz cDthcmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVs eSZuYnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZp ZHVhbCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNw O2FyZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNl aXZlZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2Um bmJzcDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJz cDttZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJz cDt0aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUm bmJzcDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMm bmJzcDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJz cDtTcGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3By ZT4= --=_alternative 002564C148257765_=-- From Hannes.Tschofenig@gmx.net Mon Jul 19 01:14:03 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1EE6C3A68C7 for ; Mon, 19 Jul 2010 01:14:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.337 X-Spam-Level: X-Spam-Status: No, score=0.337 tagged_above=-999 required=5 tests=[AWL=-0.283, BAYES_50=0.001, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x3KCrfgqzsAC for ; Mon, 19 Jul 2010 01:14:02 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 84D8D3A68C1 for ; Mon, 19 Jul 2010 01:14:01 -0700 (PDT) Received: (qmail 16939 invoked by uid 0); 19 Jul 2010 08:14:14 -0000 Received: from 213.162.68.175 by www048.gmx.net with HTTP; Mon, 19 Jul 2010 10:14:12 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Date: Mon, 19 Jul 2010 10:14:12 +0200 From: "Hannes Tschofenig" Message-ID: <20100719081412.77060@gmx.net> MIME-Version: 1.0 To: sipcore@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1/8I3JsQ3D8F0Al+BFCi6/3jd3jfRN5kOM8X7BN42 NzJpCB+CedYy16nVgHVBcZ7Ivm7yX5lYDLRg== Content-Transfer-Encoding: 8bit X-GMX-UID: A00OC1J5a2AoT5dV9XUyUHk6OWhhascw X-FuHaFi: 0.73999999999999999 Subject: [sipcore] Location Conveyance Open Issue: Privacy Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 19 Jul 2010 08:14:03 -0000 Hi, quite contrary to what one would assume for such a specification the discussion about privacy is extremely weak. It gets even more fuzzy by referencing arbitrary requirements from RFC 3693, which do not make a sense for a large number of people. I believe we can do better. Ciao Hannes From Hannes.Tschofenig@gmx.net Mon Jul 19 01:14:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D12163A6817 for ; Mon, 19 Jul 2010 01:14:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.197 X-Spam-Level: X-Spam-Status: No, score=-0.197 tagged_above=-999 required=5 tests=[AWL=0.294, BAYES_05=-1.11, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zgwoe7Qg8WLw for ; Mon, 19 Jul 2010 01:14:47 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 936903A6452 for ; Mon, 19 Jul 2010 01:14:46 -0700 (PDT) Received: (qmail 9775 invoked by uid 0); 19 Jul 2010 08:14:59 -0000 Received: from 213.162.68.175 by www048.gmx.net with HTTP; Mon, 19 Jul 2010 10:14:58 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Date: Mon, 19 Jul 2010 10:14:58 +0200 From: "Hannes Tschofenig" Message-ID: <20100719081458.77080@gmx.net> MIME-Version: 1.0 To: sipcore@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1+UApcGyViULu5Kn6v06P5l3jnYWKHIJ/8OrMWal6 MRgb1xG0L8Yczbv6qO6f2nGbxBxa9Nvi9Tmg== Content-Transfer-Encoding: 8bit X-GMX-UID: tDx2dCstPjl+HMZX9DQ2qHw7MTE2NcmD X-FuHaFi: 0.70999999999999996 Subject: [sipcore] Location Conveyance Question: Multiple Location X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 19 Jul 2010 08:14:47 -0000 Hi, The document states that attaching multiple Geolocation headers is not allowed. How would I attach a location by reference and a location by value in the same SIP message? I believe this is a quite common use case given that the LbyR will be used by the PSAP to obtain fine grain location information and the ESRP will use rough location for routing purposes. A discussion about this use case would be useful in the document, if you believe it should be dealt with in two independent SIP exchanges. Did I misunderstood the text in the draft? Ciao Hannes From Hannes.Tschofenig@gmx.net Mon Jul 19 01:17:04 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 16C703A6817 for ; Mon, 19 Jul 2010 01:17:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.244 X-Spam-Level: X-Spam-Status: No, score=0.244 tagged_above=-999 required=5 tests=[AWL=-0.190, BAYES_40=-0.185, RCVD_IN_SORBS_WEB=0.619] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ncacDy1vkY67 for ; Mon, 19 Jul 2010 01:17:03 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id C4FD13A6452 for ; Mon, 19 Jul 2010 01:17:02 -0700 (PDT) Received: (qmail 30426 invoked by uid 0); 19 Jul 2010 08:17:15 -0000 Received: from 213.162.68.175 by www052.gmx.net with HTTP; Mon, 19 Jul 2010 10:17:13 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Date: Mon, 19 Jul 2010 10:17:13 +0200 From: "Hannes Tschofenig" Message-ID: <20100719081713.77060@gmx.net> MIME-Version: 1.0 To: sipcore@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX1/i/NV/PNzi8B5FjupdXA85fZPpyZShMLNB1G60TG TMNIQBPGzgNcw2n9wAYSljZupz+WfzrAKdaA== Content-Transfer-Encoding: 8bit X-GMX-UID: aGYvJFNLTlI8RJsGtWlrfRtOU2poZZm1 X-FuHaFi: 0.69999999999999996 Subject: [sipcore] Location Conveyance Flaw: HTTP/HTTPS Location URI Scheme X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 19 Jul 2010 08:17:04 -0000 Hi, The authors (or one of them in particular) have not managed to include support for the HTTP/HTTPS URI scheme in the draft despite the fact that the GEOPRIV working group has provided support for HTTP/HTTPS location URIs for dereferencing in HELD (and now works on the HTTP/HTTPS dereference protocol). Ciao Hannes From john.elwell@siemens-enterprise.com Mon Jul 19 06:56:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4E9883A6B10 for ; Mon, 19 Jul 2010 06:56:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.411 X-Spam-Level: X-Spam-Status: No, score=-2.411 tagged_above=-999 required=5 tests=[AWL=0.188, 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 Sua-daLPrQ9z for ; Mon, 19 Jul 2010 06:56:50 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 846A63A6880 for ; Mon, 19 Jul 2010 06:56:49 -0700 (PDT) Received: from senmx12-mx ([62.134.46.10] [62.134.46.10]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-894667; Mon, 19 Jul 2010 15:57:02 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx12-mx (Server) with ESMTP id 6B1AE23F0294; Mon, 19 Jul 2010 15:57:02 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 19 Jul 2010 15:57:02 +0200 From: "Elwell, John" To: Adam Roach , SIPCORE Date: Mon, 19 Jul 2010 15:57:01 +0200 Thread-Topic: [sipcore] WGLC: draft-ietf-sipcore-keep Thread-Index: AcsjXS8VQrlKdK6dS8KXKyc3qtelJAD0Z7Vw Message-ID: References: <4C3DC365.1060508@nostrum.com> In-Reply-To: <4C3DC365.1060508@nostrum.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "draft-ietf-sipcore-keep@tools.ietf.org" , "sipcore-chairs@tools.ietf.org" Subject: Re: [sipcore] WGLC: draft-ietf-sipcore-keep X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 19 Jul 2010 13:56:51 -0000 This has some minor issues that need fixing before it is ready to go. 1. In 4.2.2: ". Once negotiated, keep- alives are sent until the registration is terminated, or until a subsequent registration refresh request is sent or forwarded. When a subsequent registration refresh request is sent or forwarded, if a SIP entity is willing to continue sending keep-alives associated with the registration, usage of keep-alives MUST be re-negotiated. If usage is not successfully re-negotiated, the SIP entity MUST cease sending of keep-alives associated with the registration." Yet in 4.2.3: "Once negotiated, keep-alives MUST be sent for the lifetime of the dialog, until the dialog is terminated. Once usage of keep-alives associated with a dialog has been negotiated, it is not possible to re-negotiate the usage associated with the dialog." There seems to be inconsistency between registrations and dialogs. For a re= gistration, keep-alive can be terminated when the registration is refreshed= , whereas for a dialog there is no way to terminate keep-alives (without te= rminating the dialog). Would it not be better to align the two? The use cas= e for being able to negotiate no keep-alives during a registration that is = already using keep-alives is not clear. It might be simpler to say that, on= ce keep-alive has been negotiated, it remains in place for the duration of = the registration or dialog. 2. "When the SIP entity receives the associated response, if the "keep" parameter in its Via header field of the response contains a parameter value, it MUST start to send keep-alives towards the same destination where it would send a subsequent request (e.g. REGISTER requests and initial requests for dialog) associated with the registration (if the keep-alive negotiation is for a registration), or where it would send subsequent mid-dialog requests (if the keep- alive negotiation is for a dialog)." This sentence is rather long. But my main concern is with the dialog-initia= ting case. Whilst "where it would send subsequent mid-dialog requests" is c= orrect, that is not necessarily where the Via header field entry with 'keep= ' has come from. Or putting it another way, if a non-record-routing proxy w= ere to include 'keep', sending keep-alives towards that proxy would be poin= tless. Of course, a non-record-routing proxy should not include 'keep'. In = this case the first mid-dialog request should contain 'keep' again, and if = the response to that also contains 'keep' (with a value) then keep-alives c= an start. So although the 'keep' in Via in principle works for both registrations and= dialogues, there are subtle differences. The present wording doesn't seem = to be wrong, but it certainly doesn't convey the real situation very satisf= actorily, IMO. It might be useful to have separate statements for registrat= ions and dialogs. It might also be useful to state that a non-record-routin= g proxy MUST NOT insert 'keep' (probably more appropriate in 4.4). 3. "Once a SIP entity has negotiated sending of keep-alives associated with a dialog towards its adjacent upstream SIP entity, it MUST NOT insert a "keep" parameter in any subsequent SIP requests associated with the dialog." This doesn't seem to be quite correct. A sends 'keep' to B on a dialog-form= ing request. B does not record route. A sends mid-dialog request to C. Sure= ly in this case, A needs to be able to include 'keep'? But this text seems = to forbid it. A note further down seems to cover the points I made in 2 and 3 above, but = I don't think that is satisfactory. In particular, using a note to contradi= ct a MUST NOT is incorrect. 4. "NOTE: If a SIP entity inserts a "keep" parameter in its Via header field of an INVITE request, and it receives multiple responses (provisional or final) associated with the request, as long as at least one of the responses, per dialog, contains a "keep" parameter with a parameter value it is seen as an indication that the adjacent upstream SIP entity is willing to receive keep-alives associated with the dialog." This isn't incorrect, but it is hard to work out what it means. If there is= a dialog-forming response, and then further responses on that same dialog,= then 'keep' in any one of these should be sufficient. But if there are mul= tiple dialog-forming responses, then 'keep' on any one of these will (I ass= ume) apply only to that dialog, and not other dialogs formed by other respo= nses. I think there is room for stating this more clearly. 5. In 4.3: "The SIP entity must support the amount of STUN which is required to apply the STUN keep-alive mechanism defined in [RFC5626], and it must support the CRLF keep-alive mechanism defined in [RFC5626]." I assume the use of lower case "must" (two instances) is motivated by the b= elief that we are repeating what is in RFC 5626. However, I don't think tha= t is correct - we are stating new normative requirements (i.e., to apply th= e mechanisms in RFC 5626 to the cases covered by this I-D). Therefore I thi= nk we should use "MUST" in each case. Similarly in 4.4. 6. The Security Considerations section merely states: "This specification d= oes not introduce security considerations in addition to those specified in [RFC5626]." Considering the I-D addresses dialogs, not just registrations, it sounds li= ke this statement might not be sufficient. For example, if a dialog hop cro= sses a firewall, use of keep-alive is likely to keep the firewall pin-hole = open for an extended period. I leave it to the security experts to determin= e whether this is an issue. 7. In section 3: ""keep" parameter: A SIP Via header field parameter that a= SIP entity can insert in its Via header field of a request to explicitly indicate willingness to send keep-alives towards it adjacent upstream SIP entity. If a SIP entity is willing to receive keep-alives from its adjacent downstream SIP entity, and the Via header field associated with the adjacent downstream SIP entity contains a "keep" parameter, the SIP entity willing to receive keep-alives can add an integer parameter value to that "keep" parameter. The integer parameter value can be used to indicate a recommended keep-alive frequency. A zero value indicates that the SIP entity is willing to receive keep-alives, but that a recommended keep-alive frequency is not provided." This seems top be far too much for a definition. Some of the material shoul= d instead be covered later in the document (and I suspect it already is). Nits: N1. Change "Eventhough" to "Even though". N2. "since usage of keep-alives in most cases are implicitly negotiated" Change "are" to "is". N3. "usage of keep-alives are not implicitly negotiated" Change "are" to "is". N4. "usage keep-alives". Change to "usage of keep-alives". N5: "why usage needs to be explicitly negotiated." The word "why" seems to be wrong. Should it be "where"? N6: "towards it adjacent upstream SIP entity" Change "it" to "its". N7: "the amount of STUN which is required" (two instances) In each case, change to "those aspects of STUN that are required". John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Adam Roach > Sent: 14 July 2010 15:02 > To: SIPCORE > Cc: draft-ietf-sipcore-keep@tools.ietf.org;=20 > sipcore-chairs@tools.ietf.org > Subject: [sipcore] WGLC: draft-ietf-sipcore-keep >=20 > [as chair] >=20 > The author of draft-ietf-sipcore-keep believes that the=20 > document has no=20 > remaining open issues, and is ready to be evaluated by the IESG for=20 > publication. Today, we begin a three-week Working Group Last Call=20 > period, which ends on Wednesday, August 4th. (This WGLC is=20 > three weeks=20 > instead of the more traditional two to account for the upcoming IETF=20 > meeting). >=20 > The latest version of the document can be retrieved here: >=20 > http://tools.ietf.org/html/draft-ietf-sipcore-keep >=20 > Any comments on the document should be sent to the SIPCORE=20 > mailing list. >=20 > As a note to document reviewers: the document's author is on holiday=20 > through August 2nd, and will respond to any direct queries=20 > after returning. >=20 > /a > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From jon.peterson@neustar.biz Mon Jul 19 11:37:08 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08EAD3A6768 for ; Mon, 19 Jul 2010 11:37:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.661 X-Spam-Level: X-Spam-Status: No, score=-101.661 tagged_above=-999 required=5 tests=[AWL=0.384, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xe-086odnLyw for ; Mon, 19 Jul 2010 11:37:05 -0700 (PDT) Received: from neustar.com (keys.neustar.biz [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 38AE43A693F for ; Mon, 19 Jul 2010 11:37:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1279564632; x=1594488827; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=OZfJI2dAAKlYvZKNFmlaBEnuypEck6QGBqIXlBlH1W8=; b=pPiaF9r4Dnn4nyIjfIYG+2TRvj+v5/Ylq14CsIMe5Z/tse2pFU1vHe3xya55Zf +2huHgos7xpkqYW1bOJ1hzGQ== Received: from ([10.31.13.242]) by stihiron1.va.neustar.com with ESMTP with TLS id G6K7MJ1.11621963; Mon, 19 Jul 2010 14:37:11 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT03.cis.neustar.com ([::1]) with mapi; Mon, 19 Jul 2010 14:37:55 -0400 From: "Peterson, Jon" To: Hannes Tschofenig , "sipcore@ietf.org" Date: Mon, 19 Jul 2010 14:37:08 -0400 Thread-Topic: [sipcore] Location Conveyance Flaw: HTTP/HTTPS Location URI Scheme Thread-Index: AcsnGs3YSaLujuN+TZ2YuJCtBtfshQAVpaUq Message-ID: In-Reply-To: <20100719081713.77060@gmx.net> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: h9+74fdWF7XdoRId5yS8Rg== Content-Type: multipart/alternative; boundary="_000_C869E96441D27jonpetersonneustarbiz_" MIME-Version: 1.0 Subject: Re: [sipcore] Location Conveyance Flaw: HTTP/HTTPS Location URI Scheme X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 19 Jul 2010 18:37:08 -0000 --_000_C869E96441D27jonpetersonneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Yes, this needs to be fixed. Jon Peterson NeuStar, Inc. On 7/19/10 1:17 AM, "Hannes Tschofenig" wrote: Hi, The authors (or one of them in particular) have not managed to include supp= ort for the HTTP/HTTPS URI scheme in the draft despite the fact that the GE= OPRIV working group has provided support for HTTP/HTTPS location URIs for d= ereferencing in HELD (and now works on the HTTP/HTTPS dereference protocol)= . Ciao Hannes _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_C869E96441D27jonpetersonneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [sipcore] Location Conveyance Flaw: HTTP/HTTPS Location URI Sche= me
Yes, this needs to be fixed.

Jon Peterson
NeuStar, Inc.


On 7/19/10 1:17 AM, "Hannes Tschofenig" <Hannes.Tschofenig@gmx.net> wrote:

Hi,

The authors (or one of them in particular) have not managed to include supp= ort for the HTTP/HTTPS URI scheme in the draft despite the fact that the GE= OPRIV working group has provided support for HTTP/HTTPS location URIs for d= ereferencing in HELD (and now works on the HTTP/HTTPS dereference protocol)= .

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

--_000_C869E96441D27jonpetersonneustarbiz_-- From jmpolk@cisco.com Mon Jul 19 11:43:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4B2F73A68D5 for ; Mon, 19 Jul 2010 11:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.34 X-Spam-Level: X-Spam-Status: No, score=-10.34 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGhu2wsbfr-j for ; Mon, 19 Jul 2010 11:43:44 -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 6C90F3A68A2 for ; Mon, 19 Jul 2010 11:43:44 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEc6REyrR7Hu/2dsb2JhbACfa3GrSJsEhSIEg38 X-IronPort-AV: E=Sophos;i="4.55,228,1278288000"; d="scan'208";a="160725412" Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 19 Jul 2010 18:43:52 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6JIhpLv029037; Mon, 19 Jul 2010 18:43:52 GMT Message-Id: <201007191843.o6JIhpLv029037@sj-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Jul 2010 13:43:51 -0500 To: "Hannes Tschofenig" , sipcore@ietf.org From: "James M. Polk" In-Reply-To: <20100719081713.77060@gmx.net> References: <20100719081713.77060@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] Location Conveyance Flaw: HTTP/HTTPS Location URI Scheme X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 19 Jul 2010 18:43:45 -0000 At 03:17 AM 7/19/2010, Hannes Tschofenig wrote: >Hi, > >The authors (or one of them in particular) on the IAB and you can't stop attacking publicly? hmmmm... >have not managed to include support for the HTTP/HTTPS URI scheme in >the draft despite the fact that the GEOPRIV working group has provided Which RFC is that defined in? James >support for HTTP/HTTPS location URIs for dereferencing in HELD (and >now works on the HTTP/HTTPS dereference protocol). > >Ciao >Hannes >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From rbarnes@bbn.com Mon Jul 19 11:51:35 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 60A193A67A1 for ; Mon, 19 Jul 2010 11:51: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 nwbdMKuxwia2 for ; Mon, 19 Jul 2010 11:51:34 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 88E453A6768 for ; Mon, 19 Jul 2010 11:51:34 -0700 (PDT) Received: from [192.1.255.159] (port=52983 helo=col-dhcp-192-1-255-159.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OavRM-000PeO-OY; Mon, 19 Jul 2010 14:51:48 -0400 Message-Id: <38FFD510-FF04-417C-9B25-4F41B2A3E1CB@bbn.com> From: "Richard L. Barnes" To: "James M. Polk" In-Reply-To: <201007191843.o6JIhpLv029037@sj-core-5.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 19 Jul 2010 14:51:45 -0400 References: <20100719081713.77060@gmx.net> <201007191843.o6JIhpLv029037@sj-core-5.cisco.com> X-Mailer: Apple Mail (2.936) Cc: Hannes Tschofenig , sipcore@ietf.org Subject: Re: [sipcore] Location Conveyance Flaw: HTTP/HTTPS Location URI Scheme X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 19 Jul 2010 18:51:35 -0000 >> have not managed to include support for the HTTP/HTTPS URI scheme >> in the draft despite the fact that the GEOPRIV working group has >> provided > > Which RFC is that defined in? See: http://tools.ietf.org/html/rfc2616 http://tools.ietf.org/html/rfc2818 http://tools.ietf.org/html/draft-ietf-geopriv-deref-protocol-00 From jmpolk@cisco.com Mon Jul 19 11:56:53 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BDD23A68D5 for ; Mon, 19 Jul 2010 11:56:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.362 X-Spam-Level: X-Spam-Status: No, score=-10.362 tagged_above=-999 required=5 tests=[AWL=0.237, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G9CMThvAlLXT for ; Mon, 19 Jul 2010 11:56:52 -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 ABB373A685F for ; Mon, 19 Jul 2010 11:56:52 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ88REyrR7Ht/2dsb2JhbACfa3GrRpsHglqCSASDfw X-IronPort-AV: E=Sophos;i="4.55,228,1278288000"; d="scan'208";a="160733919" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 19 Jul 2010 18:57:07 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6JIv7in014515; Mon, 19 Jul 2010 18:57:07 GMT Message-Id: <201007191857.o6JIv7in014515@sj-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Jul 2010 13:57:06 -0500 To: "Hannes Tschofenig" , sipcore@ietf.org From: "James M. Polk" In-Reply-To: <20100719081458.77080@gmx.net> References: <20100719081458.77080@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] Location Conveyance Question: Multiple Location X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 19 Jul 2010 18:56:53 -0000 At 03:14 AM 7/19/2010, Hannes Tschofenig wrote: >Hi, > >The document states that attaching multiple Geolocation headers is >not allowed. How would I attach a location by reference and a >location by value in the same SIP message? I believe this is a quite >common use case given that the LbyR will be used by the PSAP PSAP? that's a corner case that is talked about in the draft -03. >to obtain fine grain location information and the ESRP will use >rough location for routing purposes. A discussion about this use >case would be useful in the document, again - that's a corner case, as are many others that are not mentioned. >if you believe it should be dealt with in two independent SIP exchanges. > >Did I misunderstood the text in the draft? yes - the purpose of -03 was to reduce the complexity of the whole proposal, and your suggestion would increase the complexity back to where it was, which everyone else seems to be opposed to. SIP is an end-to-end protocol - which anyone who knows SIP knows this. If there are multiple inserters of location, these inserters need to be identified if an LR determines any one of the locations is insufficient (in some way) and said LR needs to reject the message (or just reject the location). Given multiple locations in a single SIP request, each inserter needs to be able to identify which location they inserted (because the actual location and/or location URI are not in the SIP response) to know that they inserted 'bad' location - in the hopes that they would correct the location information. If this is a rejection by the LR, then the Target needs to send new - better - location in the subsequent SIP request. It can only do that if it knows what to correct, meaning it has to have been able to be told what was wrong with its location in the first place, *and* to explicitly ignore location errors NOT meant for that SIP entity. This lead to the complexity of previous versions of the ID and what many opposed. You seem to want to go back to that complexity for your one use-case; many do not. James >Ciao >Hannes >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From jmpolk@cisco.com Mon Jul 19 12:06:25 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7361F3A6951 for ; Mon, 19 Jul 2010 12:06:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.38 X-Spam-Level: X-Spam-Status: No, score=-10.38 tagged_above=-999 required=5 tests=[AWL=0.219, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id io0Zso0AfOZ0 for ; Mon, 19 Jul 2010 12:06:24 -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 7B9103A6908 for ; Mon, 19 Jul 2010 12:06:24 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALo+REyrR7H+/2dsb2JhbACfa3GrVZsJgluCRwSDfw X-IronPort-AV: E=Sophos;i="4.55,228,1278288000"; d="scan'208";a="345176125" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 19 Jul 2010 19:06:39 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6JJ6ceZ028407; Mon, 19 Jul 2010 19:06:39 GMT Message-Id: <201007191906.o6JJ6ceZ028407@sj-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Jul 2010 14:06:37 -0500 To: "Hannes Tschofenig" , sipcore@ietf.org From: "James M. Polk" In-Reply-To: <20100719081412.77060@gmx.net> References: <20100719081412.77060@gmx.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] Location Conveyance Open Issue: Privacy Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 19 Jul 2010 19:06:25 -0000 At 03:14 AM 7/19/2010, Hannes Tschofenig wrote: >Hi, > >quite contrary to what one would assume for such a specification the >discussion about privacy is extremely weak. apparently you haven't read many SIP specifications then. When securing header values, we recommend TLS per hop. When securing identity information, we recommend hashing many header values and include the hash with a url to where to check the hash. When securing message bodies, encrypt it with S/MIME. >It gets even more fuzzy by referencing arbitrary requirements from >RFC 3693, which do not make a sense for a large number of people. private addressing doesn't make sense until one reads RFC 1918. I could go on and on by listing more than a thousand RFCs whose topics don't make sense until one reads the RFCs. Specifically wrt RFC 3693 - you need to be reminded that the old SIPPING document on the requirements for carrying location in SIP (circa 2003) are in the (only) appendix of this ID (and have been since the first SIP ID on the topic), which require adherence to RFC 3693, along with RFCs 3261 and 4119 (which also probably doesn't make sense until one reads it). > > >I believe we can do better. I believe we need to do a better case of reading next time... but maybe that's just my opinion James >Ciao >Hannes > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From rbarnes@bbn.com Mon Jul 19 12:12:54 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8C6B83A6940 for ; Mon, 19 Jul 2010 12:12: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 2jT5eB6Wu2XG for ; Mon, 19 Jul 2010 12:12:48 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id E90EA3A68A4 for ; Mon, 19 Jul 2010 12:12:44 -0700 (PDT) Received: from [192.1.255.159] (port=53180 helo=col-dhcp-192-1-255-159.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Oavlq-000PyA-Me; Mon, 19 Jul 2010 15:12:59 -0400 Message-Id: <2936AA57-EEDC-4B43-BE88-E5BDB5D44C8C@bbn.com> From: "Richard L. Barnes" To: "James M. Polk" In-Reply-To: <201007191857.o6JIv7in014515@sj-core-1.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 19 Jul 2010 15:12:57 -0400 References: <20100719081458.77080@gmx.net> <201007191857.o6JIv7in014515@sj-core-1.cisco.com> X-Mailer: Apple Mail (2.936) Cc: Hannes Tschofenig , sipcore@ietf.org Subject: Re: [sipcore] Location Conveyance Question: Multiple Location X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 19 Jul 2010 19:12:55 -0000 I might be mistaken, but it looks to me as if the header ABNF would allow the following: Geolocation: , So what's the problem? Is there language that says proxies can't modify a Geolocation header (or delete/add)? --Richard On Jul 19, 2010, at 2:57 PM, James M. Polk wrote: > At 03:14 AM 7/19/2010, Hannes Tschofenig wrote: >> Hi, >> >> The document states that attaching multiple Geolocation headers is >> not allowed. How would I attach a location by reference and a >> location by value in the same SIP message? I believe this is a >> quite common use case given that the LbyR will be used by the PSAP > > PSAP? that's a corner case that is talked about in the draft -03. > >> to obtain fine grain location information and the ESRP will use >> rough location for routing purposes. A discussion about this use >> case would be useful in the document, > > again - that's a corner case, as are many others that are not > mentioned. > >> if you believe it should be dealt with in two independent SIP >> exchanges. >> >> Did I misunderstood the text in the draft? > > yes - the purpose of -03 was to reduce the complexity of the whole > proposal, and your suggestion would increase the complexity back to > where it was, which everyone else seems to be opposed to. > > SIP is an end-to-end protocol - which anyone who knows SIP knows > this. If there are multiple inserters of location, these inserters > need to be identified if an LR determines any one of the locations > is insufficient (in some way) and said LR needs to reject the > message (or just reject the location). Given multiple locations in > a single SIP request, each inserter needs to be able to identify > which location they inserted (because the actual location and/or > location URI are not in the SIP response) to know that they inserted > 'bad' location - in the hopes that they would correct the location > information. If this is a rejection by the LR, then the Target needs > to send new - better - location in the subsequent SIP request. It > can only do that if it knows what to correct, meaning it has to have > been able to be told what was wrong with its location in the first > place, *and* to explicitly ignore location errors NOT meant for that > SIP entity. > > This lead to the complexity of previous versions of the ID and what > many opposed. > > You seem to want to go back to that complexity for your one use- > case; many do not. > > James > > >> Ciao >> Hannes >> _______________________________________________ >> 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 rjsparks@nostrum.com Mon Jul 19 12:24:12 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E96E43A69B2 for ; Mon, 19 Jul 2010 12:24:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.484 X-Spam-Level: X-Spam-Status: No, score=-2.484 tagged_above=-999 required=5 tests=[AWL=0.116, 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 bDYIDmarLZSN for ; Mon, 19 Jul 2010 12:24:11 -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 402993A6940 for ; Mon, 19 Jul 2010 12:24:10 -0700 (PDT) Received: from [172.16.3.177] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6JJOOHJ004812 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Jul 2010 14:24:24 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: <4C3CE649.1060309@nostrum.com> Date: Mon, 19 Jul 2010 14:24:24 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <743561D3-35E1-47A6-B6DD-1FD73A0CB274@nostrum.com> References: <99619466-573D-4CEA-ACCD-3A3D262EB2B0@nostrum.com> <4C3BCEFB.5010201@nostrum.com> <739E9B6D-24B5-4A45-9BC7-0387BFB5CF32@nostrum.com> <4C3CE649.1060309@nostrum.com> To: Adam Roach X-Mailer: Apple Mail (2.1081) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-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: Mon, 19 Jul 2010 19:24:13 -0000 This reply clarified my discomfort - thanks. Your point of syntactic concession was essential - it made sense to add = parameters to the Event header in requests, so as a matter of convenience, the draft is reusing the Event header and = the new parameters for the special case=20 where you are wanting to convey information in a response. The group = could well have chosen a new header with=20 the same contents for inclusion in responses (I don't think folks = explicitly considered this?), but this thing that looked like the Event header was around, so it was easier to use that. This is = only an issue in that if we ever wanted to more=20 generally take advantage of the Event header in responses, whatever we = did would be constrained by this document=20 and the semantics for an Event header showing up in a 200 to a NOTIFY = that it defines. As it stands, this document needs to do a few things it doesn't yet: 1) Explicitly call out that the use of the Event header field in = responses other than 200 OKs to NOTIFYs is (still) undefined. =20 2) Explicitly note than any of the other parameters currently defined = for the Event header do have meaning if copied from the NOTIFY into it's 200 OK (so that we don't have people being = surprised when they return a 200 OK with an expires=3D with some shorter value and it doesn't shorten their = subscription). 3) State that the event-type can't be changed between the NOTIFY and = it's 200 OK (yes, that seems obvious, but..,) 4) So that someone stumbling across an Event header field in a 200 OK to = a NOTIFY can look up what it means,=20 this document should update the IANA registry at = as follows: OLD: Event o [RFC3265] NEW: Event o = [RFC3265][RFC-ietf-sipcore-event-rate-control] (btw - I assume it is intended to be ok to use the short-form ("o" ) in = responses?) Personally, because of thought's like what I have in 2) above, I feel = there's a good chance we're making another=20 ACK-200/ACK-non200 mistake that we could be avoiding. RjS On Jul 13, 2010, at 5:18 PM, Adam Roach wrote: > On 7/13/10 16:23, Jul 13, Robert Sparks wrote: >> I don't think it's as clear-cut as that. >>=20 >> 4662 used the extension points 3265 expected to be used. >=20 > Not any more than anything else. The extension points that 3265 = defines are new event packages. 4662 uses feature tags to negotiate = usage -- a basic SIP extension mechanism. >=20 > Event-rate-control uses new header field parameters -- another basic = SIP extension mechanism. >=20 >> Someone that had written a network monitor, for example, just using >> 3265 for reference could have produced code that made sense out of a = stream of messages emitted by implementations of 4662. >>=20 >> That same code would probably not do the right thing with a stream of = messages from this spec >=20 > I can't imagine why not. It will look like a stream of state = information sent in NOTIFY messages. >=20 > I also don't have a lot of sympathy for the "network monitor" use case = as a motivator unless we're going to explicitly deprecate TLS and = S/MIME. >=20 >=20 >> - at the very least, it wouldn't know to be looking for Event headers = in 200 responses >=20 > No, and it won't know to care about them either. Which is exactly the = right thing to do reaction. >=20 > The event header fields in responses are there as a syntactic = concession -- we needed somewhere to hang the parameters. The actual = event name itself can't change. It can be safely ignored by network = monitors, and they'll do the right thing. >=20 >> What does 3265bis say about Event headers in responses to NOTIFYs at = the moment? >=20 > Nothing yet. I have a note to add text addressing this case (as well = as the suppressed NOTIFY situation that arises from subnot-etags). >=20 > /a From jmpolk@cisco.com Mon Jul 19 12:37:04 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CBA0A3A6B58 for ; Mon, 19 Jul 2010 12:36:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.409 X-Spam-Level: X-Spam-Status: No, score=-10.409 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ixyBvmxeNPiP for ; Mon, 19 Jul 2010 12:36:37 -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 144EB3A6A5C for ; Mon, 19 Jul 2010 12:33:41 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,228,1278288000"; d="scan'208";a="160747637" Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 19 Jul 2010 19:32:41 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6JJWeqN016724; Mon, 19 Jul 2010 19:32:41 GMT Message-Id: <201007191932.o6JJWeqN016724@sj-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Jul 2010 14:32:40 -0500 To: "Richard L. Barnes" , "James M. Polk" From: "James M. Polk" In-Reply-To: <38FFD510-FF04-417C-9B25-4F41B2A3E1CB@bbn.com> References: <20100719081713.77060@gmx.net> <201007191843.o6JIhpLv029037@sj-core-5.cisco.com> <38FFD510-FF04-417C-9B25-4F41B2A3E1CB@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Hannes Tschofenig , sipcore@ietf.org Subject: Re: [sipcore] Location Conveyance Flaw: HTTP/HTTPS Location URI Scheme X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 19 Jul 2010 19:37:04 -0000 At 01:51 PM 7/19/2010, Richard L. Barnes wrote: >>>have not managed to include support for the HTTP/HTTPS URI scheme >>>in the draft despite the fact that the GEOPRIV working group has >>>provided >> >>Which RFC is that defined in? > >See: >http://tools.ietf.org/html/rfc2616 >http://tools.ietf.org/html/rfc2818 >http://tools.ietf.org/html/draft-ietf-geopriv-deref-protocol-00 at least you read the draft... From rjsparks@nostrum.com Mon Jul 19 12:37:08 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5962E3A6B3F for ; Mon, 19 Jul 2010 12:37:08 -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.122, 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 b69Ov-q4LoYG for ; Mon, 19 Jul 2010 12:37:07 -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 307583A6B43 for ; Mon, 19 Jul 2010 12:36:17 -0700 (PDT) Received: from [172.16.3.177] (vicuna-alt.estacado.net [75.53.54.121]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6JJa0mj005840 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 19 Jul 2010 14:36:01 -0500 (CDT) (envelope-from rjsparks@nostrum.com) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Robert Sparks In-Reply-To: <743561D3-35E1-47A6-B6DD-1FD73A0CB274@nostrum.com> Date: Mon, 19 Jul 2010 14:36:00 -0500 Content-Transfer-Encoding: quoted-printable Message-Id: <2BC6096B-AEC4-432A-BB10-0C84DAAB4DAF@nostrum.com> References: <99619466-573D-4CEA-ACCD-3A3D262EB2B0@nostrum.com> <4C3BCEFB.5010201@nostrum.com> <739E9B6D-24B5-4A45-9BC7-0387BFB5CF32@nostrum.com> <4C3CE649.1060309@nostrum.com> <743561D3-35E1-47A6-B6DD-1FD73A0CB274@nostrum.com> To: Robert Sparks X-Mailer: Apple Mail (2.1081) Received-SPF: pass (nostrum.com: 75.53.54.121 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-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: Mon, 19 Jul 2010 19:37:08 -0000 sigh - critical typo correction below: On Jul 19, 2010, at 2:24 PM, Robert Sparks wrote: > This reply clarified my discomfort - thanks. >=20 > Your point of syntactic concession was essential - it made sense to = add parameters to the Event header in requests, > so as a matter of convenience, the draft is reusing the Event header = and the new parameters for the special case=20 > where you are wanting to convey information in a response. The group = could well have chosen a new header with=20 > the same contents for inclusion in responses (I don't think folks = explicitly considered this?), but this thing that looked > like the Event header was around, so it was easier to use that. This = is only an issue in that if we ever wanted to more=20 > generally take advantage of the Event header in responses, whatever we = did would be constrained by this document=20 > and the semantics for an Event header showing up in a 200 to a NOTIFY = that it defines. >=20 > As it stands, this document needs to do a few things it doesn't yet: >=20 > 1) Explicitly call out that the use of the Event header field in = responses other than 200 OKs to NOTIFYs is (still) undefined. >=20 > 2) Explicitly note than any of the other parameters currently defined = for the Event header do ->NOT<- > have meaning if copied from > the NOTIFY into it's 200 OK (so that we don't have people being = surprised when they return a 200 OK with an > expires=3D with some shorter value and it doesn't shorten their = subscription). >=20 > 3) State that the event-type can't be changed between the NOTIFY and = it's 200 OK (yes, that seems obvious, but..,) >=20 > 4) So that someone stumbling across an Event header field in a 200 OK = to a NOTIFY can look up what it means,=20 > this document should update the IANA registry at = as follows: >=20 > OLD: > Event o [RFC3265] > NEW: > Event o = [RFC3265][RFC-ietf-sipcore-event-rate-control] >=20 > (btw - I assume it is intended to be ok to use the short-form ("o" ) = in responses?) >=20 > Personally, because of thought's like what I have in 2) above, I feel = there's a good chance we're making another=20 > ACK-200/ACK-non200 mistake that we could be avoiding. >=20 > RjS >=20 >=20 >=20 > On Jul 13, 2010, at 5:18 PM, Adam Roach wrote: >=20 >> On 7/13/10 16:23, Jul 13, Robert Sparks wrote: >>> I don't think it's as clear-cut as that. >>>=20 >>> 4662 used the extension points 3265 expected to be used. >>=20 >> Not any more than anything else. The extension points that 3265 = defines are new event packages. 4662 uses feature tags to negotiate = usage -- a basic SIP extension mechanism. >>=20 >> Event-rate-control uses new header field parameters -- another basic = SIP extension mechanism. >>=20 >>> Someone that had written a network monitor, for example, just using >>> 3265 for reference could have produced code that made sense out of a = stream of messages emitted by implementations of 4662. >>>=20 >>> That same code would probably not do the right thing with a stream = of messages from this spec >>=20 >> I can't imagine why not. It will look like a stream of state = information sent in NOTIFY messages. >>=20 >> I also don't have a lot of sympathy for the "network monitor" use = case as a motivator unless we're going to explicitly deprecate TLS and = S/MIME. >>=20 >>=20 >>> - at the very least, it wouldn't know to be looking for Event = headers in 200 responses >>=20 >> No, and it won't know to care about them either. Which is exactly the = right thing to do reaction. >>=20 >> The event header fields in responses are there as a syntactic = concession -- we needed somewhere to hang the parameters. The actual = event name itself can't change. It can be safely ignored by network = monitors, and they'll do the right thing. >>=20 >>> What does 3265bis say about Event headers in responses to NOTIFYs at = the moment? >>=20 >> Nothing yet. I have a note to add text addressing this case (as well = as the suppressed NOTIFY situation that arises from subnot-etags). >>=20 >> /a >=20 From jgunn6@csc.com Mon Jul 19 12:39:44 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 06BD53A680D; Mon, 19 Jul 2010 12:39:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.258 X-Spam-Level: X-Spam-Status: No, score=-5.258 tagged_above=-999 required=5 tests=[AWL=-1.074, BAYES_40=-0.185, 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 pfm9Ww037Wr1; Mon, 19 Jul 2010 12:39:42 -0700 (PDT) Received: from mail85.messagelabs.com (mail85.messagelabs.com [216.82.241.211]) by core3.amsl.com (Postfix) with ESMTP id 9BE393A685C; Mon, 19 Jul 2010 12:39:41 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-13.tower-85.messagelabs.com!1279568394!9854962!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 7008 invoked from network); 19 Jul 2010 19:39:55 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-13.tower-85.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Jul 2010 19:39:55 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id o6JJdsA9027334; Mon, 19 Jul 2010 15:39:54 -0400 In-Reply-To: References: <99619466-573D-4CEA-ACCD-3A3D262EB2B0@nostrum.com> To: MIME-Version: 1.0 X-KeepSent: AA614B95:28939D2C-85257762:006BA0F9; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009 From: Janet P Gunn Message-ID: Date: Mon, 19 Jul 2010 15:39:55 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.1FP1 HF440|June 18, 2010) at 07/19/2010 03:40:23 PM, Serialize complete at 07/19/2010 03:40:23 PM Content-Type: multipart/alternative; boundary="=_alternative 006C06B685257765_=" Cc: sipcore-bounces@ietf.org, sipcore@ietf.org Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Jul 2010 19:39:44 -0000 This is a multipart message in MIME format. --=_alternative 006C06B685257765_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 PiANCj4gSSBzdWJtaXR0ZWQgdGhlIC0wNCB2ZXJzaW9uIHRvZGF5IGFkZHJlc3NpbmcgeW91ciBj b21tZW50czogaHR0cDovLw0KPiB3d3cuaWV0Zi5vcmcvaWQvZHJhZnQtaWV0Zi1zaXBjb3JlLWV2 ZW50LXJhdGUtY29udHJvbC0wNC50eHQgDQoNClRoYW5rIHlvdSBmb3IgaW5jbHVkaW5nIG1lIGlu IHRoZSBhY2tub3dsZWRnZW1lbnRzLg0KDQpJIGZpbmQgdGhhdCBzb21lLCBidXQgbm90IGFsbCwg b2YgbXkgY29tbWVudHMgaGF2ZSBiZWVuIGFkZHJlc3NlZC4gIEkgYW0gDQpyZXBlYXRpbmcgdGhl IG9uZXMgd2hpY2ggc3RpbGwgY2F1c2UgY29uZnVzaW9uLg0KDQpGaXJzdCBsZXQgbWUgc2F5IHRo YXQgSSB0aGluayB0aGlzIGlzIGEgdmVyeSB1c2VmdWwgbWVjaGFuaXNtLiAgTXkgDQpjb25jZXJu cyBhcmUgcHJpbWFyaWx5IGluIHRoZSB3YXkgdGhlIG1lY2hhbmlzbSBpcyBkZXNjcmliZWQuDQoN Cg0KPldoaWxlIOKAnG1heC1pbnRlcnZhbOKAnSBpcyBzeW5vbnltb3VzIHdpdGgg4oCcbWluaW11 bSByYXRl4oCdLCBhbmQgDQrigJxtaW4taW50ZXJ2YWzigJ0gaXMgc3lub255bW91cyB3aXRoIOKA nG1heGltdW0gcmF0ZeKAnSwgdGhlIGNvbnN0YW50IHN3aXRjaGluZyANCmJhY2sgYW5kIGZvcnRo IGJldHdlZW4gdGhlIHR3byBzZXRzIG9mIHRlcm1pbm9sb2d5IG1ha2VzIGl0IHZlcnkgZGlmZmlj dWx0IA0KdG8gZm9sbG93Lg0KDQpbSlBHXSB0aGlzIGlzIHN0aWxsIGFuIGlzc3VlLiAgU2VjdGlv bnMgNCwgNSwgYW5kIDYgYXJlIHRpdGxlZCAiLi4uLXJhdGUgDQpiZWhhdmlvciIsIGJ1dCBzZWN0 aW9uIDcgaXMgdGl0bGVkIC4uLi1pbnRlcnZhbC4NCg0KW0pQR10gSWYgeW91IGp1c3QgY2hhbmdl IHRoZSB0aXRsZSBvZiBzZWN0aW9uIDcgdG8gDQpVc2FnZSBvZiAibWF4aW11bSByYXRlIiwgIm1p bmltdW0gcmF0ZSIgYW5kICJhdmVyYWdlIHJhdGUiIGluIGEgDQpjb21iaW5hdGlvbg0KaXQgd291 bGQgYmUgTVVDSCBjbGVhcmVyLg0KDQoNCj5UaGUgZGVzY3JpcHRpb24gb2YgdGhlIGludGVuZGVk IGVmZmVjdCBvZiB0aGUg4oCcYXZlcmFnZS1pbnRlcnZhbOKAnSBpcyANCnVuY2xlYXIgYW5kIGlu Y29uc2lzdGVudC4NCg0KPkluIHRoZSBpbnRyb2R1Y3Rpb24sIGl0IHNheXMgDQrigJwgICBhdmVy YWdlLWludGVydmFsOiAgc3BlY2lmaWVzIGFuIGF2ZXJhZ2UgY2FkZW5jZSBhdCB3aGljaCBub3Rp ZmljYXRpb25zIA0KYXJlIGRlc2lyZWQsIGluIHNlY29uZHMu4oCdDQoNCltKUEddIFRoZSBJbnRy b2R1Y3Rpb24gU1RJTEwgU0FZUyB0aGlzLiBCdXQgdGhhdCBpcyBub3Qgd2hhdCB0aGF0IA0KbWVj aGFuaXNtIGRvZXMuIA0KIA0KW0pQR10gSWYgdGhlIHN1YnNjcmliZXIncyBkZXNpcmVkICJhdmVy YWdlIiBpcyAib25lIG5vdGlmaWNhdGlvbiBldmVyeSA1IA0Kc2Vjb25kcyIsIGFuZCB0aGUgIG5v dGlmaWVyIGhhcyBhIG5vdGlmaWNhdGlvbiByZWFkeSB0byBzZW5kIGV2ZXJ5IHNlY29uZCwgDQpp dCBpcyBnb2luZyB0byBzZW5kIHRoZSBub3RpZmljYXRpb24gb3V0IG9uY2UgYSBzZWNvbmQuICBV bmRlciB0aGUgDQpkZXNjcmliZWQgYWxnb3JpdGhtLCB0aGUgbm90aWZpZXIgd2lsbCBOT1QgZGVs YXksIG5vciBidWZmZXIsIA0Kbm90aWZpY2F0aW9ucyB0byBhcHByb2FjaCB0aGUgZGVzaXJlZC9z cGVjaWZpZWQgImF2ZXJhZ2UiDQoNCltKUEddIEluIGZhY3QsIHRoZSBtZWNoYW5pc20gZGVzY3Jp YmVkIGluIHNlY3Rpb24gNiBpcyBhbiBBREFQVElWRSB2YXJpYW50IA0Kb2YgdGhlIG1pbmltdW0t cmF0ZSAobWF4aW11bS1pbnRlcnZhbCkgbWVjaGFuaXNtLg0KDQpbSlBHXSBQZXJzb25hbGx5LCBJ IHdvdWxkIHByZWZlciB0byBzZWUgdGhlIG5hbWUgb2YgdGhlIG1lY2hhbmlzbSBjaGFuZ2VkIA0K dG8gImFkYXB0aXZlLW1pbmltdW0tcmF0ZSIgaW5zdGVhZCBvZiAiYXZlcmFnZS1yYXRlIi4gIEJ1 dCBldmVuIGlmIHlvdSANCmRvbid0IGRvIHRoYXQsIHlvdSBuZWVkIHRvIGNoYW5nZSB0aGUgdGV4 dCBzbyB0aGF0IHlvdSBhcmUgbm8gbG9uZ2VyIA0KbWlzcmVwcmVzZW50aW5nIHRoZSBhbGdvcml0 aG0uDQogDQoNCj5JbiBzZWN0aW9uIDMuMywgVXNlIENhc2UgZm9yIHNwZWNpZnlpbmcgdGhlIGF2 ZXJhZ2UgcmF0ZSBvZiANCm5vdGlmaWNhdGlvbnMsIGl0IGlzIGNvbnRyYWRpY3RvcnkuICBGaXJz dCBpdCBzYXlzDQo+4oCcZHluYW1pY2FsbHkgaW5jcmVhc2VzIHRoZSBpbnRlcnZhbCBiZXR3ZWVu IG5vdGlmaWNhdGlvbnMgaWYgdGhlIHRhcmdldCANCmhhcyBzZW50IG91dCBzZXZlcmFsIG5vdGlm aWNhdGlvbnMgPnJlY2VudGx5LuKAnSAgVGhpcyBpcyBhbiBJTkNSRUFTRSBpbiB0aGUgDQppbnRl cnZhbC4NCg0KW0pQR10gVGhpcyB0ZXh0IGFib3V0IHRoaXMgdXNlIGNhc2UgIEFMU08gc2F5cyAi SW4gb3JkZXIgdG8gZGVjcmVhc2UgdGhlIA0KcHJvY2Vzc2luZyBhbmQgbmV0d29yayBsb2FkIg0K DQpbSlBHXSAgVGhlIHRleHQgc3RpbGwgc2F5cyB0aGlzLiAgQnV0IHRoZSBtZWNoYW5pc20gYW5k IGZvcm11bGEgeW91IA0KZGVzY3JpYmUgaW4gc2VjdGlvbiA2IFdJTEwgTk9UICJpbmNyZWFzZSB0 aGUgaW50ZXJ2YWwgYmV0d2VlbiANCm5vdGlmaWNhdGlvbnMgaWYgdGhlIHRhcmdldCBoYXMgc2Vu dCBvdXQgc2V2ZXJhbCBub3RpZmljYXRpb25zIHJlY2VudGx5LiIgDQpJdCBvbmx5IERFQ1JFQVNF UyB0aGUgaW50ZXJ2YWwgYmV0d2VlbiBub3RpZmljYXRpb25zLiANCg0KW0pQR10gSXQgaXMgdHJ1 ZSB0aGF0IGl0IHdpbGwgREVDUkVBU0UgdGhlIGludGVydmFsICBMRVNTIGlmIHRoZXJlIGhhdmUg DQpiZWVuIHNldmVyYWwgcmVjZW50IG5vdGlmaWNhdGlvbnMuICBCdXQgdGhhdCBpcyBxdWl0ZSBk aWZmZXJlbnQgZnJvbSANCklOQ1JFQVNJTkcgdGhlIGludGVydmFsLg0KDQpbSlBHXSBUaGlzIHRl eHQgYWJvdXQgdGhpcyB1c2UgY2FzZSBBTFNPIHNheXMgIkluIG9yZGVyIHRvIGRlY3JlYXNlIHRo ZSANCnByb2Nlc3NpbmcgYW5kIG5ldHdvcmsgbG9hZCIuICBUaGUgYWxnb3JpdGhtIGluIHNlY3Rp b24gNiB3aWxsIE5PVCANCiJkZWNyZWFzZSBwcm9jZXNzaW5nIGFuZCBuZXR3b3JrIGxvYWQuICBJ dCB3aWxsIElOQ1JFQVNFIHByb2Nlc3NpbmcgYW5kIA0KbmV0d29yayBsb2FkLg0KDQpbSlBHXSBI ZXJlIGlzIG15IHN1Z2dlc3RlZCByZXdyaXRlIG9mIHRoZSB1c2UgY2FzZSBmb3IgMy4zLCBiYXNl ZCBvbiB0aGUgDQp1c2UgY2FzZSBpbiAzLjIsIHNvIGl0IGNvcnJlc3BvbmRzIHRvIHRoZSBhbGdv cml0aG0gaW4gc2VjdGlvbiA2IChhZGRlZCANCnRleHQgaW4gQUxMIENBUFMpLg0KICAiQSB0cmFj a2luZyBhcHBsaWNhdGlvbiBpcyBtb25pdG9yaW5nIHRoZSBtb3ZlbWVudCBvZiBhIHRhcmdldC4N Cg0KICAgSW4gb3JkZXIgdG8gZGVjcmVhc2UgdGhlIHByb2Nlc3NpbmcgYW5kIG5ldHdvcmsgbG9h ZCwgdGhlIHRyYWNraW5nDQogICBhcHBsaWNhdGlvbiBoYXMgbWFkZSBhIHN1YnNjcmlwdGlvbiB3 aXRoIGEgc2V0IG9mIGxvY2F0aW9uIGZpbHRlcnMNCiAgIHRoYXQgc3BlY2lmeSB0cmlnZ2VyIGNy aXRlcmlhLCBmb3INCiAgIGV4YW1wbGUsIHRvIHNlbmQgYW4gdXBkYXRlIG9ubHkgd2hlbiB0aGUg dGFyZ2V0IGhhcyBtb3ZlZCBhdCBsZWFzdCBuDQogICBtZXRlcnMuICBIb3dldmVyLCB0aGUgYXBw bGljYXRpb24gaXMgYWxzbyBpbnRlcmVzdGVkIGluIHJlY2VpdmluZyB0aGUNCiAgIGN1cnJlbnQg c3RhdGUgcGVyaW9kaWNhbGx5IGV2ZW4gaWYgdGhlIHN0YXRlIG9mIHRoZSB0YXJnZXQgaGFzIG5v dA0KICAgY2hhbmdlZCBlbm91Z2ggdG8gc2F0aXNmeSBhbnkgb2YgdGhlIHRyaWdnZXIgY3JpdGVy aWEsIGUuZy4sIGhhcyBub3QNCiAgIG1vdmVkIGF0IGxlYXN0IG4gbWV0ZXJzIHdpdGhpbiB0aGUg cGVyaW9kLiANCiANCiAgIEhPV0VWRVIsIElGIFRIRVJFIEhBVkUgQkVFTiBGRVcgUkVDRU5UIFVQ REFURVMsIFRIRSBTVUJTQ1JJQkVSIA0KICAgV09VTEQgTElLRSBOT01JTkFMIFVQREFURVMgTU9S RSBGUkVRVUVOVExZIFRIQU4gV0hFTiBUSEVSRSBIQVZFIEJFRU4NCiAgIE1BTlkgUkVDRU5UIFVQ REFURVMuDQoNCiAgIEluIG9yZGVyIHRvIGNvbnRyb2wgdGhlIGFjdHVhbCBzdGF0ZSwgdGhlIGxv Y2F0aW9uIGFwcGxpY2F0aW9uIHNldHMgDQogICBhTiBBREFQVElWRSBtaW5pbXVtIHJhdGUgKEEg IlRJTUUtT1VUIiBwYXJhbWV0ZXIpLCBpLmUuIGEgbWF4aW11bSB0aW1lDQogICBpbnRlcnZhbCBi ZXR3ZWVuIHR3byBub3RpZmljYXRpb25zLCBXSElDSCBBREFQVFMsIEJBU0VEIE9OIFRIRSBSRUNF TlQgDQogICBISVNUT1JZIE9GIFVQREFURVMuIA0KDQogICBXSEVOIFRIRVJFIEhBVkUgQkVFTiBB IExPVCBPRiBSRUNFTlQgVVBEQVRFUywgVEhFDQogICBBTEdPUklUSE0gSU5DUkVBU0VTIFRIRSAi VElNRS1PVVQiIElOVEVSVkFMLCBTTyBUSEUgQ09NQklOQVRJT04gT0YgDQogICAiUkVBTCIgKFRS SUdHRVJFRCBCWSBVUERBVEVEIElORk9STUFUSU9OKSBBTkQgIk5PTUlOQUwiIChUUklHR0VSRUQg QlkgDQogICBUSEUgVElNRS1PVVQpIFVQREFURVMgQ09OVkVSR0UgVE8gVEhFICBTUEVDSUZJRUQg QVZFUkFHRSBSQVRFLiANCiANCiAgIEJVVCBXSEVOIFRIRVJFIEFSRSBGUkVRVUVOVCAiUkVBTCIg VVBEQVRFUywgVEhFIEFMR09SSVRITSBET0VTIE5PVCANCiAgIERFTEFZIE9SIEJVRkZFUiBUSEVT RSBOT1RJRklDQVRJT05TLiAgSU4gVEhJUyBDQVNFLCBUSEUgUkFURSBPRiBVUERBVEVTIA0KDQog ICBXSUxMIE5PVCBDT05WRVJHRSBUTyBUSEUgU1BFQ0lGSUVEIEFWRVJBR0UgUkFURS4NCg0KW0pQ R10gYW5kIGZyb20gdGhlIG9yaWdpbmFsIDMuMw0KICAgVGhpcyB0eXBlIG9mIHJhdGUgY29udHJv bCBhbGxvd3MgdGhlIG5vdGlmaWVyIHRvIGR5bmFtaWNhbGx5IGluY3JlYXNlDQogICB0aGUgTm90 aWZpY2F0aW9uIGZyZXF1ZW5jeS4gKFJFTU9WRUQgIm9yIGRlY3JlYXNlIikNCg0KICAgVGhlIHRy YWNraW5nIGFwcGxpY2F0aW9uIGNhbiBhbHNvIG1vZGlmeSB0aGUgImF2ZXJhZ2UtaW50ZXJ2YWwi DQogICBwYXJhbWV0ZXIgZHVyaW5nIHRoZSBsaWZldGltZSBvZiB0aGUgc3Vic2NyaXB0aW9uLg0K DQoNCltKUEddIElmIHlvdSBtYWtlIHRoZXNlIGNoYW5nZXMgdG8gdGhlIHVzZS1jYXNlLCB0aGVu IHRoZSB1c2UgY2FzZSB3aWxsIGJlIA0KY29uc2lzdGVudCB3aXRoIG1vc3Qgb2YgdGhlIHRleHQg aW4gc2VjdGlvbiA2Lg0KDQo+V2hlbiB3ZSBnZXQgdG8gdGhlIGZvcm11bGFlIGFuZCB0aGUgZGV0 YWlsZWQgbWVjaGFuaWNzLCBpdCBpcyBjbGVhciB0aGF0IA0KdGhpcyBhcHByb2FjaCB3aWxsIG9u bHkgZXZlciBERUNSRUFTRSB0aGUgaW50ZXJ2YWwgYmV0d2VlbiBub3RpZmljYXRpb25zIA0KKGZy b20gd2hhdCBpdCB3b3VsZCBiZSB3aXRob3V0IEV2ZW50IFJhdGUgQ29udHJvbCksIGl0IHdpbGwg bmV2ZXIgSU5DUkVBU0UgDQp0aGUgaW50ZXJ2YWwgYmV0d2VlbiBub3RpZmljYXRpb25zICAoZnJv bSB3aGF0IGl0IHdvdWxkIGJlIHdpdGhvdXQgRXZlbnQgDQpSYXRlIENvbnRyb2wpLg0KDQpbSlBH XSBUaGlzIGNvbW1lbnQgd2lsbCBiZSByZXNvbHZlZCBpZiB5b3UgY2hhbmdlIHRoZSB0ZXh0IGlu IHRoZSBVc2UgDQpDYXNlLg0KDQo+RnVydGhlcm1vcmUsIGluIHRoZSBkZXNjcmlwdGlvbiBvZiB0 aGUg4oCcYXZlcmFnZS1pbnRlcnZhbOKAnSBtZWNoYW5pc20sIA0KdGhlcmUgbmVlZHMgdG8gYmUg ZWl0aGVyIGEg4oCcTVVTVOKAnSBvciBhIOKAnFNIT1VMROKAnSB0byBlbnN1cmUgdGhhdCDigJxw ZXJpb2TigJ0gaXMgDQpHUkVBVEVSIFRIQU4gdGhlIOKAnGF2ZXJhZ2UtaW50ZXJ2YWzigJ0uICBP dGhlcndpc2UgdGhlIGRlc2NyaWJlZCBtZWNoYW5pc20gDQp3aWxsIHNlbmQgb3V0IGEgbm90aWZp Y2F0aW9uIGV2ZXJ5IOKAnHBlcmlvZOKAnSBzZWNvbmRzLCByZWdhcmRsZXNzIG9mIHRoZSANCnZh bHVlIG9mIOKAnGF2ZXJhZ2UtaW50ZXJ2YWzigJ0uDQoNCltKUEddIFlvdSBhZGRyZXNzZWQgdGhp cywgd2l0aCB0aGUgdGV4dCANCiAgICAgICJUaGUgdmFsdWUgb2YgdGhlDQogICAgICAicGVyaW9k IiBwYXJhbWV0ZXIgTVVTVCBiZSBncmVhdGVyIHRoYW4gdGhlIHZhbHVlIG9mIHRoZSAiYXZlcmFn ZS0NCiAgICAgIGludGVydmFsIiBwYXJhbWV0ZXIuIg0KSG93ZXZlciwgc2luY2Ugb25seSB0aGUg ImF2ZXJhZ2UtaW50ZXJ2YWwiIHBhcmFtZXRlciBpcyB1bmRlciB0aGUgY29udHJvbCANCm9mIHRo ZSBzdWJzY3JpYmVyLCBpdCB3b3VsZCBtYWtlIG1vcmUgc2Vuc2UgdG8gcHV0IGl0IGluIHRoZSAN CiJhdmVyYWdlLWludGVydmFsIiBkZWZpbml0aW9uLCBhbmQgc2F5DQogICAgICAiVGhlIHZhbHVl IG9mIHRoZSAiYXZlcmFnZS1pbnRlcnZhbCIgcGFyYW1ldGVyIE1VU1QgYmUgbGVzcyB0aGFuIHRo ZSANCnZhbHVlIG9mIHRoZQ0KICAgICAgInBlcmlvZCIgcGFyYW1ldGVyLiINCmFuZCB0YWtlIHRo ZSBjb3JyZXNwb25kaW5nICB0ZXh0IG91dCBvZiB0aGUgInBlcmlvZCIgc3BlY2lmaWNhdGlvbi4N Cg0KSSB3aWxsIGFsc28gYmUgc2VuZGluZyBhbm90aGVyIGVtYWlsIHdpdGggc29tZSBuZXcgY29t bWVudHMvcXVlc3Rpb25zLCBhbmQgDQphbm90aGVyIG9uZSB3aXRoIGEgYnVuY2ggb2Ygbml0cy4N Cg0KVGhhbmtzLg0KDQpBbmQgYWdhaW4sIEkgcmVhbGx5IGRvIHRoaW5rIHRoaXMgaXMgYSB1c2Vm dWwgbWVjaGFuaXNtLCB3ZSBqdXN0IG5lZWQgdG8gDQptYWtlIHRoZSB0ZXh0IGNvbnNpc3RlbnQu DQoNCkphbmV0DQo= --=_alternative 006C06B685257765_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PHR0Pjxmb250IHNpemU9Mj48YnI+DQomZ3Q7IDxicj4NCiZndDsgSSBzdWJtaXR0ZWQg dGhlIC0wNCB2ZXJzaW9uIHRvZGF5IGFkZHJlc3NpbmcgeW91ciBjb21tZW50czogaHR0cDovLzxi cj4NCiZndDsgPC9mb250PjwvdHQ+PGEgaHJlZj0id3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYt c2lwY29yZS1ldmVudC1yYXRlLWNvbnRyb2wtMDQudHh0Ij48dHQ+PGZvbnQgc2l6ZT0yPnd3dy5p ZXRmLm9yZy9pZC9kcmFmdC1pZXRmLXNpcGNvcmUtZXZlbnQtcmF0ZS1jb250cm9sLTA0LnR4dDwv Zm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPg0KPGJyPg0KPC9mb250PjwvdHQ+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj5UaGFuayB5b3UgZm9yIGluY2x1ZGluZyBtZSBpbiB0aGUgYWNrbm93 bGVkZ2VtZW50cy48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkkgZmlu ZCB0aGF0IHNvbWUsIGJ1dCBub3QgYWxsLCBvZiBteSBjb21tZW50cyBoYXZlDQpiZWVuIGFkZHJl c3NlZC4gJm5ic3A7SSBhbSByZXBlYXRpbmcgdGhlIG9uZXMgd2hpY2ggc3RpbGwgY2F1c2UgY29u ZnVzaW9uLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Rmlyc3QgbGV0 IG1lIHNheSB0aGF0IEkgdGhpbmsgdGhpcyBpcyBhIHZlcnkgdXNlZnVsDQptZWNoYW5pc20uICZu YnNwO015IGNvbmNlcm5zIGFyZSBwcmltYXJpbHkgaW4gdGhlIHdheSB0aGUgbWVjaGFuaXNtIGlz DQpkZXNjcmliZWQuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mZ3Q7V2hpbGUg4oCcbWF4LWludGVydmFs4oCdIGlzIHN5bm9ueW1vdXMgd2l0aCDigJxtaW5p bXVtDQpyYXRl4oCdLCBhbmQg4oCcbWluLWludGVydmFs4oCdIGlzIHN5bm9ueW1vdXMgd2l0aCDi gJxtYXhpbXVtIHJhdGXigJ0sIHRoZSBjb25zdGFudA0Kc3dpdGNoaW5nIGJhY2sgYW5kIGZvcnRo IGJldHdlZW4gdGhlIHR3byBzZXRzIG9mIHRlcm1pbm9sb2d5IG1ha2VzIGl0IHZlcnkNCmRpZmZp Y3VsdCB0byBmb2xsb3cuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5b SlBHXSB0aGlzIGlzIHN0aWxsIGFuIGlzc3VlLiAmbmJzcDtTZWN0aW9ucyA0LCA1LA0KYW5kIDYg YXJlIHRpdGxlZCAmcXVvdDsuLi4tcmF0ZSBiZWhhdmlvciZxdW90OywgYnV0IHNlY3Rpb24gNyBp cyB0aXRsZWQNCi4uLi1pbnRlcnZhbC48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPltKUEddIElmIHlvdSBqdXN0IGNoYW5nZSB0aGUgdGl0bGUgb2Ygc2VjdGlvbiA3IHRv DQo8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlVzYWdlIG9mICZxdW90O21heGlt dW0gcmF0ZSZxdW90OywgJnF1b3Q7bWluaW11bSByYXRlJnF1b3Q7DQphbmQgJnF1b3Q7YXZlcmFn ZSByYXRlJnF1b3Q7IGluIGEgY29tYmluYXRpb248L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQg c2l6ZT0yPml0IHdvdWxkIGJlIE1VQ0ggY2xlYXJlci48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZndDtUaGUgZGVzY3JpcHRpb24gb2YgdGhlIGludGVuZGVk IGVmZmVjdCBvZiB0aGUNCuKAnGF2ZXJhZ2UtaW50ZXJ2YWzigJ0gaXMgdW5jbGVhciBhbmQgaW5j b25zaXN0ZW50LjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0O0lu IHRoZSBpbnRyb2R1Y3Rpb24sIGl0IHNheXMgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj7igJwgJm5ic3A7IGF2ZXJhZ2UtaW50ZXJ2YWw6ICZuYnNwO3NwZWNpZmllcyBhbiBhdmVy YWdlDQpjYWRlbmNlIGF0IHdoaWNoIG5vdGlmaWNhdGlvbnMgYXJlIGRlc2lyZWQsIGluIHNlY29u ZHMu4oCdPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5bSlBHXSBUaGUg SW50cm9kdWN0aW9uIFNUSUxMIFNBWVMgdGhpcy4gQnV0IHRoYXQgaXMNCm5vdCB3aGF0IHRoYXQg bWVjaGFuaXNtIGRvZXMuICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5bSlBHXSBJZiB0aGUgc3Vi c2NyaWJlcidzIGRlc2lyZWQgJnF1b3Q7YXZlcmFnZSZxdW90Ow0KaXMgJnF1b3Q7b25lIG5vdGlm aWNhdGlvbiBldmVyeSA1IHNlY29uZHMmcXVvdDssIGFuZCB0aGUgJm5ic3A7bm90aWZpZXINCmhh cyBhIG5vdGlmaWNhdGlvbiByZWFkeSB0byBzZW5kIGV2ZXJ5IHNlY29uZCwgaXQgaXMgZ29pbmcg dG8gc2VuZCB0aGUNCm5vdGlmaWNhdGlvbiBvdXQgb25jZSBhIHNlY29uZC4gJm5ic3A7VW5kZXIg dGhlIGRlc2NyaWJlZCBhbGdvcml0aG0sIHRoZQ0Kbm90aWZpZXIgd2lsbCBOT1QgZGVsYXksIG5v ciBidWZmZXIsIG5vdGlmaWNhdGlvbnMgdG8gYXBwcm9hY2ggdGhlIGRlc2lyZWQvc3BlY2lmaWVk DQomcXVvdDthdmVyYWdlJnF1b3Q7PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNp emU9Mj5bSlBHXSBJbiBmYWN0LCB0aGUgbWVjaGFuaXNtIGRlc2NyaWJlZCBpbiBzZWN0aW9uDQo2 IGlzIGFuIEFEQVBUSVZFIHZhcmlhbnQgb2YgdGhlIG1pbmltdW0tcmF0ZSAobWF4aW11bS1pbnRl cnZhbCkgbWVjaGFuaXNtLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ W0pQR10gUGVyc29uYWxseSwgSSB3b3VsZCBwcmVmZXIgdG8gc2VlIHRoZSBuYW1lIG9mDQp0aGUg bWVjaGFuaXNtIGNoYW5nZWQgdG8gJnF1b3Q7YWRhcHRpdmUtbWluaW11bS1yYXRlJnF1b3Q7IGlu c3RlYWQgb2YgJnF1b3Q7YXZlcmFnZS1yYXRlJnF1b3Q7Lg0KJm5ic3A7QnV0IGV2ZW4gaWYgeW91 IGRvbid0IGRvIHRoYXQsIHlvdSBuZWVkIHRvIGNoYW5nZSB0aGUgdGV4dCBzbyB0aGF0DQp5b3Ug YXJlIG5vIGxvbmdlciBtaXNyZXByZXNlbnRpbmcgdGhlIGFsZ29yaXRobS48L2ZvbnQ+PC90dD4N Cjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNwOyA8L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPiZndDtJbiBzZWN0aW9uIDMuMywgVXNlIENhc2UgZm9yIHNwZWNpZnlpbmcg dGhlIGF2ZXJhZ2UNCnJhdGUgb2Ygbm90aWZpY2F0aW9ucywgaXQgaXMgY29udHJhZGljdG9yeS4g Jm5ic3A7Rmlyc3QgaXQgc2F5czwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0 O+KAnGR5bmFtaWNhbGx5IGluY3JlYXNlcyB0aGUgaW50ZXJ2YWwgYmV0d2VlbiBub3RpZmljYXRp b25zDQppZiB0aGUgdGFyZ2V0IGhhcyBzZW50IG91dCBzZXZlcmFsIG5vdGlmaWNhdGlvbnMgJmd0 O3JlY2VudGx5LuKAnSAmbmJzcDtUaGlzDQppcyBhbiBJTkNSRUFTRSBpbiB0aGUgaW50ZXJ2YWwu PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5bSlBHXSBUaGlzIHRleHQg YWJvdXQgdGhpcyB1c2UgY2FzZSAmbmJzcDtBTFNPIHNheXMNCiZxdW90O0luIG9yZGVyIHRvIGRl Y3JlYXNlIHRoZSBwcm9jZXNzaW5nIGFuZCBuZXR3b3JrIGxvYWQmcXVvdDs8L2ZvbnQ+PC90dD4N Cjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPltKUEddICZuYnNwO1RoZSB0ZXh0IHN0aWxsIHNh eXMgdGhpcy4gJm5ic3A7QnV0IHRoZQ0KbWVjaGFuaXNtIGFuZCBmb3JtdWxhIHlvdSBkZXNjcmli ZSBpbiBzZWN0aW9uIDYgV0lMTCBOT1QgJnF1b3Q7aW5jcmVhc2UNCnRoZSBpbnRlcnZhbCBiZXR3 ZWVuIG5vdGlmaWNhdGlvbnMgaWYgdGhlIHRhcmdldCBoYXMgc2VudCBvdXQgc2V2ZXJhbCBub3Rp ZmljYXRpb25zDQpyZWNlbnRseS4mcXVvdDsgJm5ic3A7SXQgb25seSBERUNSRUFTRVMgdGhlIGlu dGVydmFsIGJldHdlZW4gbm90aWZpY2F0aW9ucy4NCiZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPg0K PGJyPjx0dD48Zm9udCBzaXplPTI+W0pQR10gSXQgaXMgdHJ1ZSB0aGF0IGl0IHdpbGwgREVDUkVB U0UgdGhlIGludGVydmFsDQombmJzcDtMRVNTIGlmIHRoZXJlIGhhdmUgYmVlbiBzZXZlcmFsIHJl Y2VudCBub3RpZmljYXRpb25zLiAmbmJzcDtCdXQgdGhhdA0KaXMgcXVpdGUgZGlmZmVyZW50IGZy b20gSU5DUkVBU0lORyB0aGUgaW50ZXJ2YWwuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj5bSlBHXSBUaGlzIHRleHQgYWJvdXQgdGhpcyB1c2UgY2FzZSBBTFNPIHNheXMg JnF1b3Q7SW4NCm9yZGVyIHRvIGRlY3JlYXNlIHRoZSBwcm9jZXNzaW5nIGFuZCBuZXR3b3JrIGxv YWQmcXVvdDsuICZuYnNwO1RoZSBhbGdvcml0aG0NCmluIHNlY3Rpb24gNiB3aWxsIE5PVCAmcXVv dDtkZWNyZWFzZSBwcm9jZXNzaW5nIGFuZCBuZXR3b3JrIGxvYWQuICZuYnNwO0l0DQp3aWxsIElO Q1JFQVNFIHByb2Nlc3NpbmcgYW5kIG5ldHdvcmsgbG9hZC48L2ZvbnQ+PC90dD4NCjxicj4NCjxi cj48dHQ+PGZvbnQgc2l6ZT0yPltKUEddIEhlcmUgaXMgbXkgc3VnZ2VzdGVkIHJld3JpdGUgb2Yg dGhlIHVzZSBjYXNlDQpmb3IgMy4zLCBiYXNlZCBvbiB0aGUgdXNlIGNhc2UgaW4gMy4yLCBzbyBp dCBjb3JyZXNwb25kcyB0byB0aGUgYWxnb3JpdGhtDQppbiBzZWN0aW9uIDYgKGFkZGVkIHRleHQg aW4gQUxMIENBUFMpLjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7ICZx dW90O0EgdHJhY2tpbmcgYXBwbGljYXRpb24gaXMgbW9uaXRvcmluZw0KdGhlIG1vdmVtZW50IG9m IGEgdGFyZ2V0LjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7 ICZuYnNwO0luIG9yZGVyIHRvIGRlY3JlYXNlIHRoZSBwcm9jZXNzaW5nIGFuZA0KbmV0d29yayBs b2FkLCB0aGUgdHJhY2tpbmc8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNw OyAmbmJzcDthcHBsaWNhdGlvbiBoYXMgbWFkZSBhIHN1YnNjcmlwdGlvbiB3aXRoDQphIHNldCBv ZiBsb2NhdGlvbiBmaWx0ZXJzPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJz cDsgJm5ic3A7dGhhdCBzcGVjaWZ5IHRyaWdnZXIgY3JpdGVyaWEsIGZvcjwvZm9udD48L3R0Pg0K PGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7ICZuYnNwO2V4YW1wbGUsIHRvIHNlbmQgYW4gdXBk YXRlIG9ubHkgd2hlbg0KdGhlIHRhcmdldCBoYXMgbW92ZWQgYXQgbGVhc3QgbjwvZm9udD48L3R0 Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7ICZuYnNwO21ldGVycy4gJm5ic3A7SG93ZXZl ciwgdGhlIGFwcGxpY2F0aW9uDQppcyBhbHNvIGludGVyZXN0ZWQgaW4gcmVjZWl2aW5nIHRoZTwv Zm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7ICZuYnNwO2N1cnJlbnQgc3Rh dGUgcGVyaW9kaWNhbGx5IGV2ZW4gaWYgdGhlDQpzdGF0ZSBvZiB0aGUgdGFyZ2V0IGhhcyBub3Q8 L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNwOyAmbmJzcDtjaGFuZ2VkIGVu b3VnaCB0byBzYXRpc2Z5IGFueSBvZiB0aGUNCnRyaWdnZXIgY3JpdGVyaWEsIGUuZy4sIGhhcyBu b3Q8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNwOyAmbmJzcDttb3ZlZCBh dCBsZWFzdCBuIG1ldGVycyB3aXRoaW4gdGhlIHBlcmlvZC4NCjwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4m bmJzcDsgJm5ic3A7SE9XRVZFUiwgSUYgVEhFUkUgSEFWRSBCRUVOIEZFVyBSRUNFTlQNClVQREFU RVMsIFRIRSBTVUJTQ1JJQkVSIDwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5i c3A7ICZuYnNwO1dPVUxEIExJS0UgTk9NSU5BTCBVUERBVEVTIE1PUkUgRlJFUVVFTlRMWQ0KVEhB TiBXSEVOIFRIRVJFIEhBVkUgQkVFTjwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+ Jm5ic3A7ICZuYnNwO01BTlkgUkVDRU5UIFVQREFURVMuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+ PHR0Pjxmb250IHNpemU9Mj4mbmJzcDsgJm5ic3A7SW4gb3JkZXIgdG8gY29udHJvbCB0aGUgYWN0 dWFsIHN0YXRlLA0KdGhlIGxvY2F0aW9uIGFwcGxpY2F0aW9uIHNldHMgPC9mb250PjwvdHQ+DQo8 YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDsgJm5ic3A7YU4gQURBUFRJVkUgbWluaW11bSByYXRl IChBICZxdW90O1RJTUUtT1VUJnF1b3Q7DQpwYXJhbWV0ZXIpLCBpLmUuIGEgbWF4aW11bSB0aW1l PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDsgJm5ic3A7aW50ZXJ2YWwg YmV0d2VlbiB0d28gbm90aWZpY2F0aW9ucywgV0hJQ0gNCkFEQVBUUywgQkFTRUQgT04gVEhFIFJF Q0VOVCA8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNwOyAmbmJzcDtISVNU T1JZIE9GIFVQREFURVMuICZuYnNwOzwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBz aXplPTI+Jm5ic3A7ICZuYnNwO1dIRU4gVEhFUkUgSEFWRSBCRUVOIEEgTE9UIE9GIFJFQ0VOVA0K VVBEQVRFUywgVEhFPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDsgJm5i c3A7QUxHT1JJVEhNIElOQ1JFQVNFUyBUSEUgJnF1b3Q7VElNRS1PVVQmcXVvdDsNCklOVEVSVkFM LCBTTyBUSEUgQ09NQklOQVRJT04gT0YgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9 Mj4mbmJzcDsgJm5ic3A7JnF1b3Q7UkVBTCZxdW90OyAoVFJJR0dFUkVEIEJZIFVQREFURUQNCklO Rk9STUFUSU9OKSBBTkQgJnF1b3Q7Tk9NSU5BTCZxdW90OyAoVFJJR0dFUkVEIEJZIDwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7ICZuYnNwO1RIRSBUSU1FLU9VVCkgVVBE QVRFUyBDT05WRVJHRSBUTyBUSEUNCiZuYnNwO1NQRUNJRklFRCBBVkVSQUdFIFJBVEUuIDwvZm9u dD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7PC9mb250PjwvdHQ+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj4mbmJzcDsgJm5ic3A7QlVUIFdIRU4gVEhFUkUgQVJFIEZSRVFVRU5UICZx dW90O1JFQUwmcXVvdDsNClVQREFURVMsIFRIRSBBTEdPUklUSE0gRE9FUyBOT1QgPC9mb250Pjwv dHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDsgJm5ic3A7REVMQVkgT1IgQlVGRkVSIFRI RVNFIE5PVElGSUNBVElPTlMuDQombmJzcDtJTiBUSElTIENBU0UsIFRIRSBSQVRFIE9GIFVQREFU RVMgPC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDsgJm5ic3A7V0lMTCBO T1QgQ09OVkVSR0UgVE8gVEhFIFNQRUNJRklFRCBBVkVSQUdFDQpSQVRFLjwvZm9udD48L3R0Pg0K PGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+W0pQR10gYW5kIGZyb20gdGhlIG9yaWdpbmFsIDMu MzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7ICZuYnNwO1RoaXMgdHlw ZSBvZiByYXRlIGNvbnRyb2wgYWxsb3dzIHRoZQ0Kbm90aWZpZXIgdG8gZHluYW1pY2FsbHkgaW5j cmVhc2U8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPiZuYnNwOyAmbmJzcDt0aGUg Tm90aWZpY2F0aW9uIGZyZXF1ZW5jeS4gKFJFTU9WRUQNCiZxdW90O29yIGRlY3JlYXNlJnF1b3Q7 KTwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7ICZuYnNwO1Ro ZSB0cmFja2luZyBhcHBsaWNhdGlvbiBjYW4gYWxzbyBtb2RpZnkNCnRoZSAmcXVvdDthdmVyYWdl LWludGVydmFsJnF1b3Q7PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDsg Jm5ic3A7cGFyYW1ldGVyIGR1cmluZyB0aGUgbGlmZXRpbWUgb2YgdGhlDQpzdWJzY3JpcHRpb24u PC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj5bSlBHXSBJZiB5 b3UgbWFrZSB0aGVzZSBjaGFuZ2VzIHRvIHRoZSB1c2UtY2FzZSwgdGhlbg0KdGhlIHVzZSBjYXNl IHdpbGwgYmUgY29uc2lzdGVudCB3aXRoIG1vc3Qgb2YgdGhlIHRleHQgaW4gc2VjdGlvbiA2Ljwv Zm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jmd0O1doZW4gd2UgZ2V0IHRv IHRoZSBmb3JtdWxhZSBhbmQgdGhlIGRldGFpbGVkIG1lY2hhbmljcywNCml0IGlzIGNsZWFyIHRo YXQgdGhpcyBhcHByb2FjaCB3aWxsIG9ubHkgZXZlciBERUNSRUFTRSB0aGUgaW50ZXJ2YWwgYmV0 d2Vlbg0Kbm90aWZpY2F0aW9ucyAmbmJzcDsoZnJvbSB3aGF0IGl0IHdvdWxkIGJlIHdpdGhvdXQg RXZlbnQgUmF0ZSBDb250cm9sKSwNCml0IHdpbGwgbmV2ZXIgSU5DUkVBU0UgdGhlIGludGVydmFs IGJldHdlZW4gbm90aWZpY2F0aW9ucyAmbmJzcDsoZnJvbSB3aGF0DQppdCB3b3VsZCBiZSB3aXRo b3V0IEV2ZW50IFJhdGUgQ29udHJvbCkuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxmb250 IHNpemU9Mj5bSlBHXSBUaGlzIGNvbW1lbnQgd2lsbCBiZSByZXNvbHZlZCBpZiB5b3UgY2hhbmdl DQp0aGUgdGV4dCBpbiB0aGUgVXNlIENhc2UuPC9mb250PjwvdHQ+DQo8YnI+DQo8YnI+PHR0Pjxm b250IHNpemU9Mj4mZ3Q7RnVydGhlcm1vcmUsIGluIHRoZSBkZXNjcmlwdGlvbiBvZiB0aGUg4oCc YXZlcmFnZS1pbnRlcnZhbOKAnQ0KbWVjaGFuaXNtLCB0aGVyZSBuZWVkcyB0byBiZSBlaXRoZXIg YSDigJxNVVNU4oCdIG9yIGEg4oCcU0hPVUxE4oCdIHRvIGVuc3VyZQ0KdGhhdCDigJxwZXJpb2Ti gJ0gaXMgR1JFQVRFUiBUSEFOIHRoZSDigJxhdmVyYWdlLWludGVydmFs4oCdLiAmbmJzcDtPdGhl cndpc2UNCnRoZSBkZXNjcmliZWQgbWVjaGFuaXNtIHdpbGwgc2VuZCBvdXQgYSBub3RpZmljYXRp b24gZXZlcnkg4oCccGVyaW9k4oCdIHNlY29uZHMsDQpyZWdhcmRsZXNzIG9mIHRoZSB2YWx1ZSBv ZiDigJxhdmVyYWdlLWludGVydmFs4oCdLjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48Zm9u dCBzaXplPTI+W0pQR10gWW91IGFkZHJlc3NlZCB0aGlzLCB3aXRoIHRoZSB0ZXh0IDwvZm9udD48 L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJnF1b3Q7VGhl IHZhbHVlIG9mIHRoZTwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+Jm5ic3A7ICZu YnNwOyAmbmJzcDsgJnF1b3Q7cGVyaW9kJnF1b3Q7IHBhcmFtZXRlcg0KTVVTVCBiZSBncmVhdGVy IHRoYW4gdGhlIHZhbHVlIG9mIHRoZSAmcXVvdDthdmVyYWdlLTwvZm9udD48L3R0Pg0KPGJyPjx0 dD48Zm9udCBzaXplPTI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgaW50ZXJ2YWwmcXVvdDsgcGFyYW1l dGVyLiZxdW90OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBzaXplPTI+SG93ZXZlciwgc2lu Y2Ugb25seSB0aGUgJnF1b3Q7YXZlcmFnZS1pbnRlcnZhbCZxdW90Ow0KcGFyYW1ldGVyIGlzIHVu ZGVyIHRoZSBjb250cm9sIG9mIHRoZSBzdWJzY3JpYmVyLCBpdCB3b3VsZCBtYWtlIG1vcmUgc2Vu c2UNCnRvIHB1dCBpdCBpbiB0aGUgJnF1b3Q7YXZlcmFnZS1pbnRlcnZhbCZxdW90OyBkZWZpbml0 aW9uLCBhbmQgc2F5PC9mb250PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDsgJm5i c3A7ICZuYnNwOyAmcXVvdDtUaGUgdmFsdWUgb2YgdGhlICZxdW90O2F2ZXJhZ2UtaW50ZXJ2YWwm cXVvdDsNCnBhcmFtZXRlciBNVVNUIGJlIGxlc3MgdGhhbiB0aGUgdmFsdWUgb2YgdGhlPC9mb250 PjwvdHQ+DQo8YnI+PHR0Pjxmb250IHNpemU9Mj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtw ZXJpb2QmcXVvdDsgcGFyYW1ldGVyLiZxdW90OzwvZm9udD48L3R0Pg0KPGJyPjx0dD48Zm9udCBz aXplPTI+YW5kIHRha2UgdGhlIGNvcnJlc3BvbmRpbmcgJm5ic3A7dGV4dCBvdXQgb2YgdGhlICZx dW90O3BlcmlvZCZxdW90Ow0Kc3BlY2lmaWNhdGlvbi48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48 dHQ+PGZvbnQgc2l6ZT0yPkkgd2lsbCBhbHNvIGJlIHNlbmRpbmcgYW5vdGhlciBlbWFpbCB3aXRo IHNvbWUgbmV3DQpjb21tZW50cy9xdWVzdGlvbnMsIGFuZCBhbm90aGVyIG9uZSB3aXRoIGEgYnVu Y2ggb2Ygbml0cy48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPlRoYW5r cy48L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48dHQ+PGZvbnQgc2l6ZT0yPkFuZCBhZ2FpbiwgSSBy ZWFsbHkgZG8gdGhpbmsgdGhpcyBpcyBhIHVzZWZ1bCBtZWNoYW5pc20sDQp3ZSBqdXN0IG5lZWQg dG8gbWFrZSB0aGUgdGV4dCBjb25zaXN0ZW50LjwvZm9udD48L3R0Pg0KPGJyPg0KPGJyPjx0dD48 Zm9udCBzaXplPTI+SmFuZXQ8L2ZvbnQ+PC90dD4NCg== --=_alternative 006C06B685257765_=-- From jmpolk@cisco.com Mon Jul 19 12:43:05 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 498E53A67BD for ; Mon, 19 Jul 2010 12:43:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.421 X-Spam-Level: X-Spam-Status: No, score=-10.421 tagged_above=-999 required=5 tests=[AWL=0.178, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fQLGlKLI0SeY for ; Mon, 19 Jul 2010 12:43:04 -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 3A9AD3A63EC for ; Mon, 19 Jul 2010 12:43:04 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,228,1278288000"; d="scan'208";a="268246402" Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 19 Jul 2010 19:43:19 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6JJhIrX004288; Mon, 19 Jul 2010 19:43:18 GMT Message-Id: <201007191943.o6JJhIrX004288@sj-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Jul 2010 14:43:17 -0500 To: "Richard L. Barnes" , "James M. Polk" From: "James M. Polk" In-Reply-To: <2936AA57-EEDC-4B43-BE88-E5BDB5D44C8C@bbn.com> References: <20100719081458.77080@gmx.net> <201007191857.o6JIv7in014515@sj-core-1.cisco.com> <2936AA57-EEDC-4B43-BE88-E5BDB5D44C8C@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Hannes Tschofenig , sipcore@ietf.org Subject: Re: [sipcore] Location Conveyance Question: Multiple Location X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 19 Jul 2010 19:43:05 -0000 At 02:12 PM 7/19/2010, Richard L. Barnes wrote: >I might be mistaken, but it looks to me as if the header ABNF would >allow the following: > >Geolocation: , > >So what's the problem? are you asking me or Hannes? >Is there language that says proxies can't modify a Geolocation >header (or delete/add)? Table 1 indicates proxies cannot delete this header, but the text doesn't clarify that point. The text explicitly says proxies can add one locationValue, but does limit it to a maximum of one locationValue in the Geolocation header. See Jon's recent note for the argument why this is. This ID specifies no limit on the number of message bodies in a SIP message, and a location URI can be added by a SIP intermediary along the signaling path. James >--Richard > > > > > > >On Jul 19, 2010, at 2:57 PM, James M. Polk wrote: > >>At 03:14 AM 7/19/2010, Hannes Tschofenig wrote: >>>Hi, >>> >>>The document states that attaching multiple Geolocation headers is >>>not allowed. How would I attach a location by reference and a >>>location by value in the same SIP message? I believe this is a >>>quite common use case given that the LbyR will be used by the PSAP >> >>PSAP? that's a corner case that is talked about in the draft -03. >> >>>to obtain fine grain location information and the ESRP will use >>>rough location for routing purposes. A discussion about this use >>>case would be useful in the document, >> >>again - that's a corner case, as are many others that are not >>mentioned. >> >>>if you believe it should be dealt with in two independent SIP >>>exchanges. >>> >>>Did I misunderstood the text in the draft? >> >>yes - the purpose of -03 was to reduce the complexity of the whole >>proposal, and your suggestion would increase the complexity back to >>where it was, which everyone else seems to be opposed to. >> >>SIP is an end-to-end protocol - which anyone who knows SIP knows >>this. If there are multiple inserters of location, these inserters >>need to be identified if an LR determines any one of the locations >>is insufficient (in some way) and said LR needs to reject the >>message (or just reject the location). Given multiple locations in >>a single SIP request, each inserter needs to be able to identify >>which location they inserted (because the actual location and/or >>location URI are not in the SIP response) to know that they inserted >>'bad' location - in the hopes that they would correct the location >>information. If this is a rejection by the LR, then the Target needs >>to send new - better - location in the subsequent SIP request. It >>can only do that if it knows what to correct, meaning it has to have >>been able to be told what was wrong with its location in the first >>place, *and* to explicitly ignore location errors NOT meant for that >>SIP entity. >> >>This lead to the complexity of previous versions of the ID and what >>many opposed. >> >>You seem to want to go back to that complexity for your one use- >>case; many do not. >> >>James >> >> >>>Ciao >>>Hannes >>>_______________________________________________ >>>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 jon.peterson@neustar.biz Mon Jul 19 14:29:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4F4B3A68A4 for ; Mon, 19 Jul 2010 14:29:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.066 X-Spam-Level: X-Spam-Status: No, score=-102.066 tagged_above=-999 required=5 tests=[AWL=0.532, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ikoaNMnvzBGU for ; Mon, 19 Jul 2010 14:29:17 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id 616403A684F for ; Mon, 19 Jul 2010 14:29:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1279574963; x=1594488827; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=hZfXQtNC4jq/Fr+lIcfU8zbt88LboQEhsyZYlQ3bvWg=; b=f/+OcWWWdKGizZ3pJ65S/foiYUcNlG6Oc+DHV+GCQ9F2AXVvcJD8HjTPJEQKKQ UXBGFm+eu/rtRVisnZgYrlKA== Received: from ([10.31.13.229]) by stihiron1.va.neustar.com with ESMTP with TLS id G6K7MJ1.11628225; Mon, 19 Jul 2010 17:29:22 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Mon, 19 Jul 2010 17:29:22 -0400 From: "Peterson, Jon" To: "Thomson, Martin" , Roger Marshall , "James M. Polk" , "sipcore@ietf.org" Date: Mon, 19 Jul 2010 17:29:19 -0400 Thread-Topic: composition or just indirection (was: location-conveyance-03 just submitted) Thread-Index: Acsi+NJTa+ULYvovSE2TL/bYrSlncwAKAPJQABWWaxYADURloAAvdkeAABJoDoQAjAHMIAApbBSC Message-ID: In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03EB772EBB@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: zH9Hi+gDlMdenhxI4uNFDg== Content-Type: multipart/alternative; boundary="_000_C86A11BF41D5Djonpetersonneustarbiz_" MIME-Version: 1.0 Subject: Re: [sipcore] composition or just indirection (was: location-conveyance-03 just 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: Mon, 19 Jul 2010 21:29:31 -0000 --_000_C86A11BF41D5Djonpetersonneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable I'm sure we're all going to have to discuss this a bit in Maastricht, but t= here are a couple basic points here I think we need to tee up. I certainly = didn't mean to suggest that a request can only include a single location (i= .e., that any contributing piece of location information designates the sam= e place, just with varying degrees of accuracy or timeliness or something).= Rather, I believe a presence document describes a single entity - multiple= locations come about because various devices and services associated with = that single entity may attribute various locations to the entity. Getting back to fundamentals, we don't need a Geolocation header in order t= o carry location in SIP. There are MIME bodies for that (including Content-= Indirection bodies for LbyR, or perhaps Content-Location as you suggest), a= nd we can include seventeen different location objects if we want to, regar= dless of whether there are zero or one or fifteen Geolocation headers. We d= on't need a location conveyance specification or a Geolocation header to en= able that, SIP has always been able to do it, and you'll still be able to a= dd random MIME bodies that contain location information even if there is a = Geolocation header which does not point to them. So what does the Geolocati= on header and location conveyance specification buy us? I've always naively thought that the Geolocation header provides a coupling= between this particular SIP session and an entity whose location is design= ated by a PIDF document. The entity is the geopriv Target, and is probably = (though not necessarily) related to the party identified by the classic Fro= m header field of the SIP request. The Geolocation header tells us that for= the purposes of the SIP session being negotiated, the location of this Tar= get is somehow relevant... the boldest interpretation would be that this Ta= rget's location should be considered the source of the request. Just attach= ing location-aware MIME bodies without the Geolocation header to SIP reques= ts doesn't convey the same semantics - those bodies could mean anything, an= d presumably the receiving application would sort through them at its discr= etion. Where I get confused is when I start trying to understand what it would mea= n semantically for a SIP session to be coupled with more than one Target. A= gain, I can imagine hypothetically a SIP request containing unsorted MIME b= odies that talk about different Targets to assist some specific application= that knows how to reconcile them, but here I mean using the Geolocation he= ader to couple a SIP request with location information about different Targ= ets. Is there actually a use case/requirement for that? If not, and we only= want to couple a SIP request with one Target, then I fail to see why compo= sing location information about the same Target into a single PIDF body wou= ld be a problem. Having location information about the same entity fail to = be organized in one body through RFC4479 wouldn't make sense, anyway. I think if we understand the semantics by which the Geolocation header "cou= ples" PIDF with a SIP session, then we'll better understand all of this. If= the Geolocation header only exists to notify lazy intermediaries that ther= e are location-sensitive bodies in the request or somewhere out on the net,= without implying anything about the Target or the relationship of those lo= cations to the SIP request, then this whole specification is probably more = trouble than it's worth - it really wouldn't provide much incremental value= above the basic ability of SIP to carry all sorts of bodies, including loc= ation bodies. If there are, however, more binding semantics here, then we p= robably won't be able to agree on the need for solitary or multiple Geoloca= tion headers until we agree on what those semantics are. Jon Peterson NeuStar, Inc. On 7/18/10 7:25 PM, "Thomson, Martin" wrote: Hi Jon, I admit a fair degree of sympathy for Roger's suggestion. After all, the a= bility to include multiple location "values" in the same SIP request is a f= eature that has existed for many years. A number of implementations have c= ome to rely on this mechanism; people are building and have built solutions= based on earlier draft, fully aware of the risks in implementing an intern= et draft. At some point, it might be necessary to swallow any discomfort and recogniz= e that the consequences of an imperfect solution are less than the conseque= nces of a change of the nature you suggest. Altering perspective might offer a solution. The idea that there are multiple items that are composited might be counter= productive. In this world-view, you have to reconcile a number of perspect= ives. In this, you are absolutely correct: doing that at two layers is bad= . Composition is a hard problem already. Moving it into SIP only complica= tes it further. The alternative is to imagine a single logical resource that represents the= location of the Target. A location by value is a representation of this r= esource: a snapshot. Location by reference offers a means for any entity t= o identify and acquire a view of the resource, independent of that snapshot= . The authority for the resource might offer the same representation, or i= t could offer one better suited to the recipient. The representation might= be updated, it might be altered based on an authorization policy, or somet= hing else (language preferences). Regardless of how it is represented, it = is still the same resource. In simple terms, you state that the request can only include a single _loca= tion_. When a location value and reference are both included, they represe= nt the _same_ location. This is why I suggested that Content-Location be borrowed. In HTTP, Conten= t-Location says - if you want to know where this resource really lives, her= e is where you can find it. Now this might be sheer sophistry, but it might offer a way out. The compo= sition problems are left out of SIP. I can write up a more detailed strawman, but for now, I'll just include an = example: INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4bK74bf9 Max-Forwards: 70 To: Bob From: Alice ;tag=3D9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Geolocation: ;routing-allowed=3Dno Supported: geolocation Accept: application/sdp, application/pidf+xml CSeq: 31862 INVITE Contact: Content-Type: multipart/mixed; boundary=3Dboundary1 Content-Length: ... --boundary1 Content-Type: application/sdp ...SDP goes here --boundary1 Content-Type: application/pidf+xml Content-ID: Content-Location: pres:alice@example.com?location/XJhbXM6eG1sOm5zOnBpZ ...PIDF-LO document --boundary1-- --Martin ---- Original Message ---- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Friday, 16 July 2010 4:54 PM To: Roger Marshall; Thomson, Martin; James M. Polk; sipcore@ietf.org Subject: Re: [sipcore] location-conveyance-03 just submitted In the corner case (and I do think it is a corner case) where multiple enti= ties are contributing different location information to a single SIP reques= t, I think we face a fundamental architecture choice in this mechanism: eit= her it is SIP's job to sort out how we understand those different locations= , or it is PIDF's job. Traditionally, PIDF's understanding of different so= urces of presence that provide potentially contradictory information relies= on the presence data model (RFC4479), which is designed to reconcile condi= tions like the one where my mobile phone thinks I am available but my deskt= op thinks I'm offline. The presence data model moreover differentiates betw= een users, services and devices in a way that is useful and apparently appl= icable to location information. I am not eager to try to replicate this in = SIP headers, including by inserting multiple such headers, putting in marku= p that tries to explain the "source" of location information in SIP headers= , and so on. SIP's job should be to convey the location object - fundamenta= lly, the further we diverge from "conveyance" and enter into the realm of "= integration," the less comfortable I get. I understand that the subsequent use case where there are different sources= of location information, some of which are LbrV and some of which are LbyR= , looks like a hairy one. This is, however, a corner case of a corner case= . I really do not feel comfortable justifying the allowance of multiple loc= ation headers in SIP pointing to different presence objects (as opposed to = following the presence data model) to carry the 0, 1 or 2 different locatio= ns due to a corner case of a corner case. As I said in my previous mail to = Martin, I'm not really sure I even understand the requirements for an inter= mediary to evaluate and reject LbyR, nor what the best way is for presence = from these dynamic sources to be composed. If we were to investigate the ri= ght way for presence from those source to be composed, it might very well b= e that it is the responsibility of the compositor to insert an LbyR into th= e SIP request (into the Geolocation header), and to poll and compose a cohe= rent PIDF document from its dynamic and static sources - that is probably t= he approach that most closely parallels the traditional approaches to prese= nce. But we haven't even begun to explore this yet. No one insisting that t= here will be "empty" PIDF documents just containing references to external = PIDF documents or something. Something along those lines is one approach of= many that we would consider if we tried to figure out how to address this = in PIDF. The question we need to decide, as I said above, is the architectu= re one - is SIP's job to convey PIDF documents, or to compose them? Jon Peterson NeuStar, Inc. ... --_000_C86A11BF41D5Djonpetersonneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: composition or just indirection (was: location-conveyance-03 jus= t submitted)
I’m sure we’re all going to have to discuss this a bit in Maast= richt, but there are a couple basic points here I think we need to tee up. = I certainly didn’t mean to suggest that a request can only include a = single location (i.e., that any contributing piece of location information = designates the same place, just with varying degrees of accuracy or timelin= ess or something). Rather, I believe a presence document describes a single= entity – multiple locations come about because various devices and s= ervices associated with that single entity may attribute various locations = to the entity.

Getting back to fundamentals, we don’t need a Geolocation header in o= rder to carry location in SIP. There are MIME bodies for that (including Co= ntent-Indirection bodies for LbyR, or perhaps Content-Location as you sugge= st), and we can include seventeen different location objects if we want to,= regardless of whether there are zero or one or fifteen Geolocation headers= . We don’t need a location conveyance specification or a Geolocation = header to enable that, SIP has always been able to do it, and you’ll = still be able to add random MIME bodies that contain location information e= ven if there is a Geolocation header which does not point to them. So what = does the Geolocation header and location conveyance specification buy us? <= BR>
I’ve always naively thought that the Geolocation header provides a co= upling between this particular SIP session and an entity whose location is = designated by a PIDF document. The entity is the geopriv Target, and is pro= bably (though not necessarily) related to the party identified by the class= ic From header field of the SIP request. The Geolocation header tells us th= at for the purposes of the SIP session being negotiated, the location of th= is Target is somehow relevant... the boldest interpretation would be that t= his Target’s location should be considered the source of the request.= Just attaching location-aware MIME bodies without the Geolocation header t= o SIP requests doesn’t convey the same semantics – those bodies= could mean anything, and presumably the receiving application would sort t= hrough them at its discretion.

Where I get confused is when I start trying to understand what it would mea= n semantically for a SIP session to be coupled with more than one Target. A= gain, I can imagine hypothetically a SIP request containing unsorted MIME b= odies that talk about different Targets to assist some specific application= that knows how to reconcile them, but here I mean using the Geolocation he= ader to couple a SIP request with location information about different Targ= ets. Is there actually a use case/requirement for that? If not, and we only= want to couple a SIP request with one Target, then I fail to see why compo= sing location information about the same Target into a single PIDF body wou= ld be a problem. Having location information about the same entity fail to = be organized in one body through RFC4479 wouldn’t make sense, anyway.=

I think if we understand the semantics by which the Geolocation header R= 20;couples” PIDF with a SIP session, then we’ll better understa= nd all of this. If the Geolocation header only exists to notify lazy interm= ediaries that there are location-sensitive bodies in the request or somewhe= re out on the net, without implying anything about the Target or the relati= onship of those locations to the SIP request, then this whole specification= is probably more trouble than it’s worth – it really wouldn= 217;t provide much incremental value above the basic ability of SIP to carr= y all sorts of bodies, including location bodies. If there are, however, mo= re binding semantics here, then we probably won’t be able to agree on= the need for solitary or multiple Geolocation headers until we agree on wh= at those semantics are.

Jon Peterson
NeuStar, Inc.


On 7/18/10 7:25 PM, "Thomson, Martin" <Martin.Thomson@andrew.com> wrote:

Hi Jon,

I admit a fair degree of sympathy for Roger’s suggestion.  After= all, the ability to include multiple location “values” in the = same SIP request is a feature that has existed for many years.  A numb= er of implementations have come to rely on this mechanism; people are build= ing and have built solutions based on earlier draft, fully aware of the ris= ks in implementing an internet draft.

At some point, it might be necessary to swallow any discomfort and recogniz= e that the consequences of an imperfect solution are less than the conseque= nces of a change of the nature you suggest.

Altering perspective might offer a solution.

The idea that there are multiple items that are composited might be counter= productive.  In this world-view, you have to reconcile a number of per= spectives.  In this, you are absolutely correct: doing that at two lay= ers is bad.  Composition is a hard problem already.  Moving it in= to SIP only complicates it further.

The alternative is to imagine a single logical resource that represents the= location of the Target.  A location by value is a representation of t= his resource: a snapshot.  Location by reference offers a means for an= y entity to identify and acquire a view of the resource, independent of tha= t snapshot.  The authority for the resource might offer the same repre= sentation, or it could offer one better suited to the recipient.  The = representation might be updated, it might be altered based on an authorizat= ion policy, or something else (language preferences).  Regardless of h= ow it is represented, it is still the same resource.

In simple terms, you state that the request can only include a single _loca= tion_.  When a location value and reference are both included, they re= present the _same_ location.

This is why I suggested that Content-Location be borrowed.  In HTTP, C= ontent-Location says - if you want to know where this resource really lives= , here is where you can find it.

Now this might be sheer sophistry, but it might offer a way out.  The = composition problems are left out of SIP.

I can write up a more detailed strawman, but for now, I'll just include an = example:

   INVITE sips:bob@biloxi= .example.com SIP/2.0
   Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4= bK74bf9
   Max-Forwards: 70
   To: Bob <sips:bob@b= iloxi.example.com>
   From: Alice <sips:alice@atlanta.example.com>;tag=3D9fxced76sl
   Call-ID: 3848276298220188511@atlanta.example.com
   Geolocation: <cid:target123@atlanta.example.com>
     ;routing-allowed=3Dno
   Supported: geolocation
   Accept: application/sdp, application/pidf+xml
   CSeq: 31862 INVITE
   Contact: <sips:a= lice@atlanta.example.com>
   Content-Type: multipart/mixed; boundary=3Dboundary1
   Content-Length: ...

   --boundary1
   Content-Type: application/sdp

   ...SDP goes here

   --boundary1
   Content-Type: application/pidf+xml
   Content-ID: <target123@atlanta.example.com>
   Content-Location: pres:alice@example.com?location/XJhbXM6eG1sOm5zOnBpZ

   <?xml version=3D"1.0"?>
   ...PIDF-LO document
   --boundary1--


--Martin

---- Original Message ----
From: Peterson, Jon [mailto:jon= .peterson@neustar.biz]
Sent: Friday, 16 July 2010 4:54 PM
To: Roger Marshall; Thomson, Martin; James M. Polk; sipcore@ietf.org
Subject: Re: [sipcore] location-conveyance-03 just submitted


In the corner case (and I do think it is a corner case) where multiple enti= ties are contributing different location information to a single SIP reques= t, I think we face a fundamental architecture choice in this mechanism: eit= her it is SIP’s job to sort out how we understand those different loc= ations, or it is PIDF’s job. =A0Traditionally, PIDF’s understan= ding of different sources of presence that provide potentially contradictor= y information relies on the presence data model (RFC4479), which is designe= d to reconcile conditions like the one where my mobile phone thinks I am av= ailable but my desktop thinks I’m offline. The presence data model mo= reover differentiates between users, services and devices in a way that is = useful and apparently applicable to location information. I am not eager to= try to replicate this in SIP headers, including by inserting multiple such= headers, putting in markup that tries to explain the “source” = of location information in SIP headers, and so on. SIP’s job should b= e to convey the location object – fundamentally, the further we diver= ge from “conveyance” and enter into the realm of “integra= tion,” the less comfortable I get.

I understand that the subsequent use case where there are different sources= of location information, some of which are LbrV and some of which are LbyR= , looks like a =A0hairy one. This is, however, a corner case of a corner ca= se. I really do not feel comfortable justifying the allowance of multiple l= ocation headers in SIP pointing to different presence objects (as opposed t= o following the presence data model) to carry the 0, 1 or 2 different locat= ions due to a corner case of a corner case. As I said in my previous mail t= o Martin, I’m not really sure I even understand the requirements for = an intermediary to evaluate and reject LbyR, nor what the best way is for p= resence from these dynamic sources to be composed. If we were to investigat= e the right way for presence from those source to be composed, it might ver= y well be that it is the responsibility of the compositor to insert an LbyR= into the SIP request (into the Geolocation header), and to poll and compos= e a coherent PIDF document from its dynamic and static sources – that= is probably the approach that most closely parallels the traditional appro= aches to presence. But we haven’t even begun to explore this yet. No = one insisting that there will be “empty” PIDF documents just co= ntaining references to external PIDF documents or something. Something alon= g those lines is one approach of many that we would consider if we tried to= figure out how to address this in PIDF. The question we need to decide, as= I said above, is the architecture one – is SIP’s job to convey= PIDF documents, or to compose them?

Jon Peterson
NeuStar, Inc.

…

--_000_C86A11BF41D5Djonpetersonneustarbiz_-- From rbarnes@bbn.com Mon Jul 19 14:43:58 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 522E73A697D for ; Mon, 19 Jul 2010 14:43:58 -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, 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 1Pz76LwOnz+D for ; Mon, 19 Jul 2010 14:43:55 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 9BE283A6B7C for ; Mon, 19 Jul 2010 14:43:55 -0700 (PDT) Received: from [192.1.255.159] (port=54805 helo=col-dhcp-192-1-255-159.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Oay87-0001z7-JE; Mon, 19 Jul 2010 17:44:07 -0400 Message-Id: <605CEAA0-91F5-4860-A2B6-7E1BAFD3D847@bbn.com> From: "Richard L. Barnes" To: "Peterson, Jon" In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-15-620935621 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 19 Jul 2010 17:44:06 -0400 References: X-Mailer: Apple Mail (2.936) Cc: Roger Marshall , "sipcore@ietf.org" , "Thomson, Martin" Subject: Re: [sipcore] composition or just indirection (was: location-conveyance-03 just 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: Mon, 19 Jul 2010 21:43:58 -0000 --Apple-Mail-15-620935621 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable While it's correct to say that one presence document describes a =20 single entity, it's not necessarily true that multiple presence =20 documents describe multiple entities. Regardless of how we define the =20= entity in the session that is the target (IIRC, earlier versions said =20= something like "the UAC that initiated the dialogue"), it seems =20 plausible that different entities processing a SIP message might have =20= different ideas as to the location of the target. In this case, it =20 would seem plausible to have multiple location objects in a single =20 message, all of which have the semantic that they're describing the =20 location of the target (however the target is coupled to the session). Speaking more practically, if we accept the assertion that multiple =20 location values will be necessary (whether in a single document or =20 not), then it seems much cleaner to have them in separate presence =20 documents, with separate CID URIs. I don't really see any reason for =20= any of this to call for more than one Geolocation header, since you =20 can just add more URIs. On Jul 19, 2010, at 5:29 PM, Peterson, Jon wrote: > > I=92m sure we=92re all going to have to discuss this a bit in =20 > Maastricht, but there are a couple basic points here I think we need =20= > to tee up. I certainly didn=92t mean to suggest that a request can =20 > only include a single location (i.e., that any contributing piece of =20= > location information designates the same place, just with varying =20 > degrees of accuracy or timeliness or something). Rather, I believe a =20= > presence document describes a single entity =96 multiple locations =20 > come about because various devices and services associated with that =20= > single entity may attribute various locations to the entity. > > Getting back to fundamentals, we don=92t need a Geolocation header in =20= > order to carry location in SIP. There are MIME bodies for that =20 > (including Content-Indirection bodies for LbyR, or perhaps Content-=20 > Location as you suggest), and we can include seventeen different =20 > location objects if we want to, regardless of whether there are zero =20= > or one or fifteen Geolocation headers. We don=92t need a location =20 > conveyance specification or a Geolocation header to enable that, SIP =20= > has always been able to do it, and you=92ll still be able to add =20 > random MIME bodies that contain location information even if there =20 > is a Geolocation header which does not point to them. So what does =20 > the Geolocation header and location conveyance specification buy us? > > I=92ve always naively thought that the Geolocation header provides a =20= > coupling between this particular SIP session and an entity whose =20 > location is designated by a PIDF document. The entity is the geopriv =20= > Target, and is probably (though not necessarily) related to the =20 > party identified by the classic =46rom header field of the SIP =20 > request. The Geolocation header tells us that for the purposes of =20 > the SIP session being negotiated, the location of this Target is =20 > somehow relevant... the boldest interpretation would be that this =20 > Target=92s location should be considered the source of the request. =20= > Just attaching location-aware MIME bodies without the Geolocation =20 > header to SIP requests doesn=92t convey the same semantics =96 those =20= > bodies could mean anything, and presumably the receiving application =20= > would sort through them at its discretion. > > Where I get confused is when I start trying to understand what it =20 > would mean semantically for a SIP session to be coupled with more =20 > than one Target. Again, I can imagine hypothetically a SIP request =20 > containing unsorted MIME bodies that talk about different Targets to =20= > assist some specific application that knows how to reconcile them, =20 > but here I mean using the Geolocation header to couple a SIP request =20= > with location information about different Targets. Is there actually =20= > a use case/requirement for that? If not, and we only want to couple =20= > a SIP request with one Target, then I fail to see why composing =20 > location information about the same Target into a single PIDF body =20 > would be a problem. Having location information about the same =20 > entity fail to be organized in one body through RFC4479 wouldn=92t =20 > make sense, anyway. > > I think if we understand the semantics by which the Geolocation =20 > header =93couples=94 PIDF with a SIP session, then we=92ll better =20 > understand all of this. If the Geolocation header only exists to =20 > notify lazy intermediaries that there are location-sensitive bodies =20= > in the request or somewhere out on the net, without implying =20 > anything about the Target or the relationship of those locations to =20= > the SIP request, then this whole specification is probably more =20 > trouble than it=92s worth =96 it really wouldn=92t provide much =20 > incremental value above the basic ability of SIP to carry all sorts =20= > of bodies, including location bodies. If there are, however, more =20 > binding semantics here, then we probably won=92t be able to agree on =20= > the need for solitary or multiple Geolocation headers until we agree =20= > on what those semantics are. > > Jon Peterson > NeuStar, Inc. > > > On 7/18/10 7:25 PM, "Thomson, Martin" =20 > wrote: > > Hi Jon, > > I admit a fair degree of sympathy for Roger=92s suggestion. After =20 > all, the ability to include multiple location =93values=94 in the same = =20 > SIP request is a feature that has existed for many years. A number =20= > of implementations have come to rely on this mechanism; people are =20 > building and have built solutions based on earlier draft, fully =20 > aware of the risks in implementing an internet draft. > > At some point, it might be necessary to swallow any discomfort and =20 > recognize that the consequences of an imperfect solution are less =20 > than the consequences of a change of the nature you suggest. > > Altering perspective might offer a solution. > > The idea that there are multiple items that are composited might be =20= > counterproductive. In this world-view, you have to reconcile a =20 > number of perspectives. In this, you are absolutely correct: doing =20= > that at two layers is bad. Composition is a hard problem already. =20= > Moving it into SIP only complicates it further. > > The alternative is to imagine a single logical resource that =20 > represents the location of the Target. A location by value is a =20 > representation of this resource: a snapshot. Location by reference =20= > offers a means for any entity to identify and acquire a view of the =20= > resource, independent of that snapshot. The authority for the =20 > resource might offer the same representation, or it could offer one =20= > better suited to the recipient. The representation might be =20 > updated, it might be altered based on an authorization policy, or =20 > something else (language preferences). Regardless of how it is =20 > represented, it is still the same resource. > > In simple terms, you state that the request can only include a =20 > single _location_. When a location value and reference are both =20 > included, they represent the _same_ location. > > This is why I suggested that Content-Location be borrowed. In HTTP, =20= > Content-Location says - if you want to know where this resource =20 > really lives, here is where you can find it. > > Now this might be sheer sophistry, but it might offer a way out. =20 > The composition problems are left out of SIP. > > I can write up a more detailed strawman, but for now, I'll just =20 > include an example: > > INVITE sips:bob@biloxi.example.com SIP/2.0 > Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4bK74bf9 > Max-Forwards: 70 > To: Bob > From: Alice ;tag=3D9fxced76sl > Call-ID: 3848276298220188511@atlanta.example.com > Geolocation: > ;routing-allowed=3Dno > Supported: geolocation > Accept: application/sdp, application/pidf+xml > CSeq: 31862 INVITE > Contact: > Content-Type: multipart/mixed; boundary=3Dboundary1 > Content-Length: ... > > --boundary1 > Content-Type: application/sdp > > ...SDP goes here > > --boundary1 > Content-Type: application/pidf+xml > Content-ID: > Content-Location: = pres:alice@example.com?location/XJhbXM6eG1sOm5zOnBpZ > > > ...PIDF-LO document > --boundary1-- > > > --Martin > > ---- Original Message ---- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Friday, 16 July 2010 4:54 PM > To: Roger Marshall; Thomson, Martin; James M. Polk; sipcore@ietf.org > Subject: Re: [sipcore] location-conveyance-03 just submitted > > > In the corner case (and I do think it is a corner case) where =20 > multiple entities are contributing different location information to =20= > a single SIP request, I think we face a fundamental architecture =20 > choice in this mechanism: either it is SIP=92s job to sort out how we =20= > understand those different locations, or it is PIDF=92s job. =20 > Traditionally, PIDF=92s understanding of different sources of presence = =20 > that provide potentially contradictory information relies on the =20 > presence data model (RFC4479), which is designed to reconcile =20 > conditions like the one where my mobile phone thinks I am available =20= > but my desktop thinks I=92m offline. The presence data model moreover =20= > differentiates between users, services and devices in a way that is =20= > useful and apparently applicable to location information. I am not =20 > eager to try to replicate this in SIP headers, including by =20 > inserting multiple such headers, putting in markup that tries to =20 > explain the =93source=94 of location information in SIP headers, and = so =20 > on. SIP=92s job should be to convey the location object =96 =20 > fundamentally, the further we diverge from =93conveyance=94 and enter =20= > into the realm of =93integration,=94 the less comfortable I get. > > I understand that the subsequent use case where there are different =20= > sources of location information, some of which are LbrV and some of =20= > which are LbyR, looks like a hairy one. This is, however, a corner =20= > case of a corner case. I really do not feel comfortable justifying =20 > the allowance of multiple location headers in SIP pointing to =20 > different presence objects (as opposed to following the presence =20 > data model) to carry the 0, 1 or 2 different locations due to a =20 > corner case of a corner case. As I said in my previous mail to =20 > Martin, I=92m not really sure I even understand the requirements for =20= > an intermediary to evaluate and reject LbyR, nor what the best way =20 > is for presence from these dynamic sources to be composed. If we =20 > were to investigate the right way for presence from those source to =20= > be composed, it might very well be that it is the responsibility of =20= > the compositor to insert an LbyR into the SIP request (into the =20 > Geolocation header), and to poll and compose a coherent PIDF =20 > document from its dynamic and static sources =96 that is probably the =20= > approach that most closely parallels the traditional approaches to =20 > presence. But we haven=92t even begun to explore this yet. No one =20 > insisting that there will be =93empty=94 PIDF documents just = containing =20 > references to external PIDF documents or something. Something along =20= > those lines is one approach of many that we would consider if we =20 > tried to figure out how to address this in PIDF. The question we =20 > need to decide, as I said above, is the architecture one =96 is SIP=92s = =20 > job to convey PIDF documents, or to compose them? > > Jon Peterson > NeuStar, Inc. > > =85 > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail-15-620935621 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable
While it's correct to say = that one presence document describes a single entity, it's not = necessarily true that multiple presence documents describe multiple = entities.  Regardless of how we define the entity in the session = that is the target (IIRC, earlier versions said something like "the UAC = that initiated the dialogue"), it seems plausible that different = entities processing a SIP message might have different ideas as to the = location of the target.  In this case, it would seem plausible to = have multiple location objects in a single message, all of which have = the semantic that they're describing the location of the target (however = the target is coupled to the session).

Speaking = more practically, if we accept the assertion that multiple location = values will be necessary (whether in a single document or not), then it = seems much cleaner to have them in separate presence documents, with = separate CID URIs.  I don't really see any reason for any of this = to call for more than one Geolocation header, since you can just add = more URIs.



On Jul 19, = 2010, at 5:29 PM, Peterson, Jon wrote:

=
I=92m sure we=92re all going to have to = discuss this a bit in Maastricht, but there are a couple basic points = here I think we need to tee up. I certainly didn=92t mean to suggest = that a request can only include a single location (i.e., that any = contributing piece of location information designates the same place, = just with varying degrees of accuracy or timeliness or something). = Rather, I believe a presence document describes a single entity =96 = multiple locations come about because various devices and services = associated with that single entity may attribute various locations to = the entity.

Getting back to fundamentals, we don=92t need a = Geolocation header in order to carry location in SIP. There are MIME = bodies for that (including Content-Indirection bodies for LbyR, or = perhaps Content-Location as you suggest), and we can include seventeen = different location objects if we want to, regardless of whether there = are zero or one or fifteen Geolocation headers. We don=92t need a = location conveyance specification or a Geolocation header to enable = that, SIP has always been able to do it, and you=92ll still be able to = add random MIME bodies that contain location information even if there = is a Geolocation header which does not point to them. So what does the = Geolocation header and location conveyance specification buy us?
=
I=92ve always naively thought that the Geolocation header provides = a coupling between this particular SIP session and an entity whose = location is designated by a PIDF document. The entity is the geopriv = Target, and is probably (though not necessarily) related to the party = identified by the classic =46rom header field of the SIP request. The = Geolocation header tells us that for the purposes of the SIP session = being negotiated, the location of this Target is somehow relevant... the = boldest interpretation would be that this Target=92s location should be = considered the source of the request. Just attaching location-aware MIME = bodies without the Geolocation header to SIP requests doesn=92t convey = the same semantics =96 those bodies could mean anything, and presumably = the receiving application would sort through them at its discretion.
=
Where I get confused is when I start trying to understand what it = would mean semantically for a SIP session to be coupled with more than = one Target. Again, I can imagine hypothetically a SIP request containing = unsorted MIME bodies that talk about different Targets to assist some = specific application that knows how to reconcile them, but here I mean = using the Geolocation header to couple a SIP request with location = information about different Targets. Is there actually a use = case/requirement for that? If not, and we only want to couple a SIP = request with one Target, then I fail to see why composing location = information about the same Target into a single PIDF body would be a = problem. Having location information about the same entity fail to be = organized in one body through RFC4479 wouldn=92t make sense, anyway.
=
I think if we understand the semantics by which the Geolocation = header =93couples=94 PIDF with a SIP session, then we=92ll better = understand all of this. If the Geolocation header only exists to notify = lazy intermediaries that there are location-sensitive bodies in the = request or somewhere out on the net, without implying anything about the = Target or the relationship of those locations to the SIP request, then = this whole specification is probably more trouble than it=92s worth =96 = it really wouldn=92t provide much incremental value above the basic = ability of SIP to carry all sorts of bodies, including location bodies. = If there are, however, more binding semantics here, then we probably = won=92t be able to agree on the need for solitary or multiple = Geolocation headers until we agree on what those semantics are.

= Jon Peterson
NeuStar, Inc.


On 7/18/10 7:25 PM, = "Thomson, Martin" <Martin.Thomson@andrew.com> = wrote:

Hi Jon,
=
I admit a fair degree of sympathy for Roger=92s suggestion. =  After all, the ability to include multiple location =93values=94 = in the same SIP request is a feature that has existed for many years. =  A number of implementations have come to rely on this mechanism; = people are building and have built solutions based on earlier draft, = fully aware of the risks in implementing an internet draft.

At = some point, it might be necessary to swallow any discomfort and = recognize that the consequences of an imperfect solution are less than = the consequences of a change of the nature you suggest.

= Altering perspective might offer a solution.

The idea that = there are multiple items that are composited might be counterproductive. =  In this world-view, you have to reconcile a number of = perspectives.  In this, you are absolutely correct: doing that at = two layers is bad.  Composition is a hard problem already. =  Moving it into SIP only complicates it further.

The = alternative is to imagine a single logical resource that represents the = location of the Target.  A location by value is a representation of = this resource: a snapshot.  Location by reference offers a means = for any entity to identify and acquire a view of the resource, = independent of that snapshot.  The authority for the resource might = offer the same representation, or it could offer one better suited to = the recipient.  The representation might be updated, it might be = altered based on an authorization policy, or something else (language = preferences).  Regardless of how it is represented, it is still the = same resource.

In simple terms, you state that the request can = only include a single _location_.  When a location value and = reference are both included, they represent the _same_ location.
=
This is why I suggested that Content-Location be borrowed.  In = HTTP, Content-Location says - if you want to know where this resource = really lives, here is where you can find it.

Now this might be = sheer sophistry, but it might offer a way out.  The composition = problems are left out of SIP.

I can write up a more detailed = strawman, but for now, I'll just include an example:

=    INVITE sips:bob@biloxi.example.com SIP/2.0
=    Via: SIPS/2.0/TLS = pc33.atlanta.example.com;branch=3Dz9hG4bK74bf9
=    Max-Forwards: 70
   To: Bob = <sips:bob@biloxi.example.com>
=    From: Alice <sips:alice@atlanta.example.com>;tag=3D= 9fxced76sl
   Call-ID: 3848276298220188511@atlan= ta.example.com
   Geolocation: <cid:target123@atlanta.example.com&g= t;
     ;routing-allowed=3Dno
=    Supported: geolocation
   Accept: = application/sdp, application/pidf+xml
   CSeq: 31862 = INVITE
   Contact: <sips:alice@atlanta.example.com>
=    Content-Type: multipart/mixed; boundary=3Dboundary1
=    Content-Length: ...

=    --boundary1
   Content-Type: = application/sdp

   ...SDP goes here

=    --boundary1
   Content-Type: = application/pidf+xml
   Content-ID: <target123@atlanta.example.com&g= t;
   Content-Location: pres:alice@example.com= ?location/XJhbXM6eG1sOm5zOnBpZ

   <?xml = version=3D"1.0"?>
   ...PIDF-LO document
=    --boundary1--


--Martin

---- = Original Message ----
From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
Sent: Friday, 16 July 2010 4:54 PM
To: Roger Marshall; = Thomson, Martin; James M. Polk; sipcore@ietf.org
Subject: Re: = [sipcore] location-conveyance-03 just submitted


In the = corner case (and I do think it is a corner case) where multiple entities = are contributing different location information to a single SIP request, = I think we face a fundamental architecture choice in this mechanism: = either it is SIP=92s job to sort out how we understand those different = locations, or it is PIDF=92s job.  Traditionally, PIDF=92s = understanding of different sources of presence that provide potentially = contradictory information relies on the presence data model (RFC4479), = which is designed to reconcile conditions like the one where my mobile = phone thinks I am available but my desktop thinks I=92m offline. The = presence data model moreover differentiates between users, services and = devices in a way that is useful and apparently applicable to location = information. I am not eager to try to replicate this in SIP headers, = including by inserting multiple such headers, putting in markup that = tries to explain the =93source=94 of location information in SIP = headers, and so on. SIP=92s job should be to convey the location object = =96 fundamentally, the further we diverge from =93conveyance=94 and = enter into the realm of =93integration,=94 the less comfortable I = get.

I understand that the subsequent use case where there are = different sources of location information, some of which are LbrV and = some of which are LbyR, looks like a  hairy one. This is, however, = a corner case of a corner case. I really do not feel comfortable = justifying the allowance of multiple location headers in SIP pointing to = different presence objects (as opposed to following the presence data = model) to carry the 0, 1 or 2 different locations due to a corner case = of a corner case. As I said in my previous mail to Martin, I=92m not = really sure I even understand the requirements for an intermediary to = evaluate and reject LbyR, nor what the best way is for presence from = these dynamic sources to be composed. If we were to investigate the = right way for presence from those source to be composed, it might very = well be that it is the responsibility of the compositor to insert an = LbyR into the SIP request (into the Geolocation header), and to poll and = compose a coherent PIDF document from its dynamic and static sources =96 = that is probably the approach that most closely parallels the = traditional approaches to presence. But we haven=92t even begun to = explore this yet. No one insisting that there will be =93empty=94 PIDF = documents just containing references to external PIDF documents or = something. Something along those lines is one approach of many that we = would consider if we tried to figure out how to address this in PIDF. = The question we need to decide, as I said above, is the architecture one = =96 is SIP=92s job to convey PIDF documents, or to compose them?
=
Jon Peterson
NeuStar, Inc.

=85

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

= --Apple-Mail-15-620935621-- From rbarnes@bbn.com Mon Jul 19 14:46:25 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B3853A6B7B for ; Mon, 19 Jul 2010 14:46:25 -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 BMvor44zzzAG for ; Mon, 19 Jul 2010 14:46:24 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 263CC3A695B for ; Mon, 19 Jul 2010 14:46:24 -0700 (PDT) Received: from [192.1.255.159] (port=54817 helo=col-dhcp-192-1-255-159.bbn.com) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OayAY-00021q-T3 for sipcore@ietf.org; Mon, 19 Jul 2010 17:46:38 -0400 Message-Id: From: "Richard L. Barnes" 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 v936) Date: Mon, 19 Jul 2010 17:46:38 -0400 X-Mailer: Apple Mail (2.936) Subject: [sipcore] Geo URI in location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 19 Jul 2010 21:46:25 -0000 What do people think about having support for GEO URIs [1] in a Geolocation header field? Seems like it would be kind of handy... [1] From pkyzivat@cisco.com Mon Jul 19 15:40:07 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 441DE3A698F for ; Mon, 19 Jul 2010 15:40:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.489 X-Spam-Level: X-Spam-Status: No, score=-10.489 tagged_above=-999 required=5 tests=[AWL=0.110, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y43jlRHoRJHe for ; Mon, 19 Jul 2010 15:40: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 B2DDB3A6995 for ; Mon, 19 Jul 2010 15:40:02 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,228,1278288000"; d="scan'208";a="134385834" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 19 Jul 2010 22:34:16 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6JMYGPJ003134; Mon, 19 Jul 2010 22:34:16 GMT Message-ID: <4C44D2E8.8020904@cisco.com> Date: Mon, 19 Jul 2010 18:34:16 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "James M. Polk" References: <20100719081458.77080@gmx.net> <201007191857.o6JIv7in014515@sj-core-1.cisco.com> <2936AA57-EEDC-4B43-BE88-E5BDB5D44C8C@bbn.com> <201007191943.o6JJhIrX004288@sj-core-2.cisco.com> In-Reply-To: <201007191943.o6JJhIrX004288@sj-core-2.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Richard L. Barnes" , Hannes Tschofenig , sipcore@ietf.org Subject: Re: [sipcore] Location Conveyance Question: Multiple Location X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 19 Jul 2010 22:40:07 -0000 James M. Polk wrote: > At 02:12 PM 7/19/2010, Richard L. Barnes wrote: >> I might be mistaken, but it looks to me as if the header ABNF would >> allow the following: >> >> Geolocation: ,> foobar> The ABNF permits that (by virtue of allowing absoluteURI, http: is permitted), but the text does not: The Geolocation header field has zero or one locationValue, but MUST NOT contain more than one locationValue. >> So what's the problem? > > are you asking me or Hannes? > >> Is there language that says proxies can't modify a Geolocation header >> (or delete/add)? > > Table 1 indicates proxies cannot delete this header, but the text > doesn't clarify that point. > > The text explicitly says proxies can add one locationValue, but does > limit it to a maximum of one locationValue in the Geolocation header. Text I quoted above limits it. Thanks, Paul > See Jon's recent note for the argument why this is. > > This ID specifies no limit on the number of message bodies in a SIP > message, and a location URI can be added by a SIP intermediary along the > signaling path. > > James > > >> --Richard >> >> >> >> >> >> >> On Jul 19, 2010, at 2:57 PM, James M. Polk wrote: >> >>> At 03:14 AM 7/19/2010, Hannes Tschofenig wrote: >>>> Hi, >>>> >>>> The document states that attaching multiple Geolocation headers is >>>> not allowed. How would I attach a location by reference and a >>>> location by value in the same SIP message? I believe this is a >>>> quite common use case given that the LbyR will be used by the PSAP >>> >>> PSAP? that's a corner case that is talked about in the draft -03. >>> >>>> to obtain fine grain location information and the ESRP will use >>>> rough location for routing purposes. A discussion about this use >>>> case would be useful in the document, >>> >>> again - that's a corner case, as are many others that are not >>> mentioned. >>> >>>> if you believe it should be dealt with in two independent SIP >>>> exchanges. >>>> >>>> Did I misunderstood the text in the draft? >>> >>> yes - the purpose of -03 was to reduce the complexity of the whole >>> proposal, and your suggestion would increase the complexity back to >>> where it was, which everyone else seems to be opposed to. >>> >>> SIP is an end-to-end protocol - which anyone who knows SIP knows >>> this. If there are multiple inserters of location, these inserters >>> need to be identified if an LR determines any one of the locations >>> is insufficient (in some way) and said LR needs to reject the >>> message (or just reject the location). Given multiple locations in >>> a single SIP request, each inserter needs to be able to identify >>> which location they inserted (because the actual location and/or >>> location URI are not in the SIP response) to know that they inserted >>> 'bad' location - in the hopes that they would correct the location >>> information. If this is a rejection by the LR, then the Target needs >>> to send new - better - location in the subsequent SIP request. It >>> can only do that if it knows what to correct, meaning it has to have >>> been able to be told what was wrong with its location in the first >>> place, *and* to explicitly ignore location errors NOT meant for that >>> SIP entity. >>> >>> This lead to the complexity of previous versions of the ID and what >>> many opposed. >>> >>> You seem to want to go back to that complexity for your one use- >>> case; many do not. >>> >>> James >>> >>> >>>> Ciao >>>> Hannes >>>> _______________________________________________ >>>> 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 James.Winterbottom@andrew.com Mon Jul 19 16:04:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E850D3A6B4B for ; Mon, 19 Jul 2010 16:04:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 VrBTpi5rJ04J for ; Mon, 19 Jul 2010 16:04:52 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id EDF483A6840 for ; Mon, 19 Jul 2010 16:04:51 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:47723 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S28152639Ab0GSXFG convert rfc822-to-8bit (ORCPT ); Mon, 19 Jul 2010 18:05:06 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 19 Jul 2010 18:05:06 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 20 Jul 2010 07:05:04 +0800 From: "Winterbottom, James" To: "Richard L. Barnes" , "sipcore@ietf.org" Date: Tue, 20 Jul 2010 07:05:03 +0800 Thread-Topic: [sipcore] Geo URI in location-conveyance Thread-Index: Acsni+GtwaEmlFjSRr6UcsTN6GAKxAACsa2A Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120E9829412@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Subject: Re: [sipcore] Geo URI in location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 19 Jul 2010 23:04:53 -0000 I want this, and I want to be able to support a CID in the same header. If we can do that in the same header, then I a more than happy to restrict the number of geolocation headers to 1. Cheers James > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf > Of Richard L. Barnes > Sent: Tuesday, 20 July 2010 7:47 AM > To: sipcore@ietf.org > Subject: [sipcore] Geo URI in location-conveyance > > What do people think about having support for GEO URIs [1] in a > Geolocation header field? Seems like it would be kind of handy... > > [1] > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From James.Winterbottom@andrew.com Mon Jul 19 16:18:53 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 43E523A6BA3 for ; Mon, 19 Jul 2010 16:18:53 -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 lxK+qU6iN9fV for ; Mon, 19 Jul 2010 16:18:52 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 19F763A6B4B for ; Mon, 19 Jul 2010 16:18:52 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:37276 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S340034Ab0GSXTG convert rfc822-to-8bit (ORCPT ); Mon, 19 Jul 2010 18:19:06 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 19 Jul 2010 18:19:06 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 20 Jul 2010 07:19:02 +0800 From: "Winterbottom, James" To: Paul Kyzivat , "James M. Polk" Date: Tue, 20 Jul 2010 07:19:01 +0800 Thread-Topic: [sipcore] Location Conveyance Question: Multiple Location Thread-Index: Acsnk2LzZA8kNRvgT365cgrBgthM/QABMQOw Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120E9829415@SISPE7MB1.commscope.com> References: <20100719081458.77080@gmx.net> <201007191857.o6JIv7in014515@sj-core-1.cisco.com> <2936AA57-EEDC-4B43-BE88-E5BDB5D44C8C@bbn.com> <201007191943.o6JJhIrX004288@sj-core-2.cisco.com> <4C44D2E8.8020904@cisco.com> In-Reply-To: <4C44D2E8.8020904@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: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: "Richard L. Barnes" , Hannes Tschofenig , "sipcore@ietf.org" Subject: Re: [sipcore] Location Conveyance Question: Multiple Location X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 19 Jul 2010 23:18:53 -0000 By the same token absoluteURI also permits pres:, sip: and sips: URI schemes, yet these are explicitly called out, presumably because there is specification work that says how to use them for acquiring location information. Hannes's comment, and indeed my comment made nearly a week ago, are simply calling for the inclusion of the http: and http2: URI schemes to also be included because similar specification work on how to use these schemes to acquire location information exists. If the argument is that this is covered by the absoluteURI component, then presumably that is all the ABNF requires, and the sips: sips: and pres: URI schemes can also be removed. Cheers James > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf > Of Paul Kyzivat > Sent: Tuesday, 20 July 2010 8:34 AM > To: James M. Polk > Cc: Richard L. Barnes; Hannes Tschofenig; sipcore@ietf.org > Subject: Re: [sipcore] Location Conveyance Question: Multiple Location > > > > James M. Polk wrote: > > At 02:12 PM 7/19/2010, Richard L. Barnes wrote: > >> I might be mistaken, but it looks to me as if the header ABNF would > >> allow the following: > >> > >> Geolocation: , >> foobar> > > The ABNF permits that (by virtue of allowing absoluteURI, http: is > permitted), but the text does not: > > The Geolocation header field has zero or one locationValue, but > MUST NOT contain more than one locationValue. > > sipcore From jon.peterson@neustar.biz Mon Jul 19 16:21:15 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 202253A6BA5 for ; Mon, 19 Jul 2010 16:21:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.199 X-Spam-Level: X-Spam-Status: No, score=-102.199 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Az4GsQxGUX6X for ; Mon, 19 Jul 2010 16:20:57 -0700 (PDT) Received: from neustar.com (mx1.neustar.com [156.154.16.88]) by core3.amsl.com (Postfix) with ESMTP id B579E3A693F for ; Mon, 19 Jul 2010 16:20:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1279581594; x=1594488827; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=UXiTG3co9cWKfyAl97wxH24W9CZHkFXIFBbA0IDp11c=; b=oQm1ssAWVCUU+n3xjmajJFmKs5ujDrCpIkrX8KdGEhUD7IL0Sywa9c/Uiqpj9i 6/nrX6sCAyun5IMnsfavZUIw== Received: from ([10.31.13.228]) by stihiron1.va.neustar.com with ESMTP with TLS id G6K7MJ1.11631319; Mon, 19 Jul 2010 19:19:53 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT01.cis.neustar.com ([::1]) with mapi; Mon, 19 Jul 2010 19:19:47 -0400 From: "Peterson, Jon" To: "Richard L. Barnes" Date: Mon, 19 Jul 2010 19:19:47 -0400 Thread-Topic: [sipcore] composition or just indirection (was: location-conveyance-03 just submitted) Thread-Index: Acsni6descmN989+Q0SvWFiF0KxPhgADTlot Message-ID: In-Reply-To: <605CEAA0-91F5-4860-A2B6-7E1BAFD3D847@bbn.com> Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: 1UPF+ummvnFCo5bMGcqfkA== Content-Type: multipart/alternative; boundary="_000_C86A2BA341D74jonpetersonneustarbiz_" MIME-Version: 1.0 Cc: Roger Marshall , "sipcore@ietf.org" , "Thomson, Martin" Subject: Re: [sipcore] composition or just indirection (was: location-conveyance-03 just 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: Mon, 19 Jul 2010 23:21:15 -0000 --_000_C86A2BA341D74jonpetersonneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable It sounds like you agree that there is one Target, at least. I'm not disagr= eeing that different entities might have different ideas about the location= of the target; I just don't see why that entails anything whether they sho= uld be in different presence documents or the same one. Again, this is just= a question of whether a bald list in a header field value has enough synta= ctic richness to describe the relationship between those presence documents= , or whether we should let RFC4479 do that job. All of those crufty paramet= ers that had crept into the Geolocation header were symptoms of the lack of= syntactic richness in that neck of the woods, as was the bloat in error co= des related to their upkeep. As to composition, any presence architecture that has multiple sources of p= resence has to provide composition somewhere. If (as the previous location-= conveyance document tacitly assumed) we deliver a bunch of separate presenc= e documents from different sources all talking about the same presentity/Ta= rget to a watcher (an LR, in geopriv parlance), then the responsibility dev= olves to the LR/watcher to effectively perform composition - to try to unde= rstand the documents and how they relate to one another in order to derive = a useful picture of the presentity's presence. The problem is, the watcher = is the least likely entity in the architecture to understand how all these = bits of information fit together. Jon Peterson NeuStar, Inc. On 7/19/10 2:44 PM, "Richard L. Barnes" wrote: While it's correct to say that one presence document describes a single ent= ity, it's not necessarily true that multiple presence documents describe mu= ltiple entities. Regardless of how we define the entity in the session tha= t is the target (IIRC, earlier versions said something like "the UAC that i= nitiated the dialogue"), it seems plausible that different entities process= ing a SIP message might have different ideas as to the location of the targ= et. In this case, it would seem plausible to have multiple location object= s in a single message, all of which have the semantic that they're describi= ng the location of the target (however the target is coupled to the session= ). Speaking more practically, if we accept the assertion that multiple locatio= n values will be necessary (whether in a single document or not), then it s= eems much cleaner to have them in separate presence documents, with separat= e CID URIs. I don't really see any reason for any of this to call for more= than one Geolocation header, since you can just add more URIs. On Jul 19, 2010, at 5:29 PM, Peterson, Jon wrote: I'm sure we're all going to have to discuss this a bit in Maastricht, but = there are a couple basic points here I think we need to tee up. I certainly= didn't mean to suggest that a request can only include a single location (= i.e., that any contributing piece of location information designates the sa= me place, just with varying degrees of accuracy or timeliness or something)= . Rather, I believe a presence document describes a single entity - multipl= e locations come about because various devices and services associated with= that single entity may attribute various locations to the entity. Getting back to fundamentals, we don't need a Geolocation header in order = to carry location in SIP. There are MIME bodies for that (including Content= -Indirection bodies for LbyR, or perhaps Content-Location as you suggest), = and we can include seventeen different location objects if we want to, rega= rdless of whether there are zero or one or fifteen Geolocation headers. We = don't need a location conveyance specification or a Geolocation header to e= nable that, SIP has always been able to do it, and you'll still be able to = add random MIME bodies that contain location information even if there is a= Geolocation header which does not point to them. So what does the Geolocat= ion header and location conveyance specification buy us? I've always naively thought that the Geolocation header provides a couplin= g between this particular SIP session and an entity whose location is desig= nated by a PIDF document. The entity is the geopriv Target, and is probably= (though not necessarily) related to the party identified by the classic Fr= om header field of the SIP request. The Geolocation header tells us that fo= r the purposes of the SIP session being negotiated, the location of this Ta= rget is somehow relevant... the boldest interpretation would be that this T= arget's location should be considered the source of the request. Just attac= hing location-aware MIME bodies without the Geolocation header to SIP reque= sts doesn't convey the same semantics - those bodies could mean anything, a= nd presumably the receiving application would sort through them at its disc= retion. Where I get confused is when I start trying to understand what it would me= an semantically for a SIP session to be coupled with more than one Target. = Again, I can imagine hypothetically a SIP request containing unsorted MIME = bodies that talk about different Targets to assist some specific applicatio= n that knows how to reconcile them, but here I mean using the Geolocation h= eader to couple a SIP request with location information about different Tar= gets. Is there actually a use case/requirement for that? If not, and we onl= y want to couple a SIP request with one Target, then I fail to see why comp= osing location information about the same Target into a single PIDF body wo= uld be a problem. Having location information about the same entity fail to= be organized in one body through RFC4479 wouldn't make sense, anyway. I think if we understand the semantics by which the Geolocation header "co= uples" PIDF with a SIP session, then we'll better understand all of this. I= f the Geolocation header only exists to notify lazy intermediaries that the= re are location-sensitive bodies in the request or somewhere out on the net= , without implying anything about the Target or the relationship of those l= ocations to the SIP request, then this whole specification is probably more= trouble than it's worth - it really wouldn't provide much incremental valu= e above the basic ability of SIP to carry all sorts of bodies, including lo= cation bodies. If there are, however, more binding semantics here, then we = probably won't be able to agree on the need for solitary or multiple Geoloc= ation headers until we agree on what those semantics are. Jon Peterson NeuStar, Inc. On 7/18/10 7:25 PM, "Thomson, Martin" wrote: Hi Jon, I admit a fair degree of sympathy for Roger's suggestion. After all, the = ability to include multiple location "values" in the same SIP request is a = feature that has existed for many years. A number of implementations have = come to rely on this mechanism; people are building and have built solution= s based on earlier draft, fully aware of the risks in implementing an inter= net draft. At some point, it might be necessary to swallow any discomfort and recogni= ze that the consequences of an imperfect solution are less than the consequ= ences of a change of the nature you suggest. Altering perspective might offer a solution. The idea that there are multiple items that are composited might be counte= rproductive. In this world-view, you have to reconcile a number of perspec= tives. In this, you are absolutely correct: doing that at two layers is ba= d. Composition is a hard problem already. Moving it into SIP only complic= ates it further. The alternative is to imagine a single logical resource that represents th= e location of the Target. A location by value is a representation of this = resource: a snapshot. Location by reference offers a means for any entity = to identify and acquire a view of the resource, independent of that snapsho= t. The authority for the resource might offer the same representation, or = it could offer one better suited to the recipient. The representation migh= t be updated, it might be altered based on an authorization policy, or some= thing else (language preferences). Regardless of how it is represented, it= is still the same resource. In simple terms, you state that the request can only include a single _loc= ation_. When a location value and reference are both included, they repres= ent the _same_ location. This is why I suggested that Content-Location be borrowed. In HTTP, Conte= nt-Location says - if you want to know where this resource really lives, he= re is where you can find it. Now this might be sheer sophistry, but it might offer a way out. The comp= osition problems are left out of SIP. I can write up a more detailed strawman, but for now, I'll just include an= example: INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4bK74bf9 Max-Forwards: 70 To: Bob From: Alice ;tag=3D9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Geolocation: ;routing-allowed=3Dno Supported: geolocation Accept: application/sdp, application/pidf+xml CSeq: 31862 INVITE Contact: Content-Type: multipart/mixed; boundary=3Dboundary1 Content-Length: ... --boundary1 Content-Type: application/sdp ...SDP goes here --boundary1 Content-Type: application/pidf+xml Content-ID: Content-Location: pres:alice@example.com?location/XJhbXM6eG1sOm5zOnBpZ ...PIDF-LO document --boundary1-- --Martin ---- Original Message ---- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Friday, 16 July 2010 4:54 PM To: Roger Marshall; Thomson, Martin; James M. Polk; sipcore@ietf.org Subject: Re: [sipcore] location-conveyance-03 just submitted In the corner case (and I do think it is a corner case) where multiple ent= ities are contributing different location information to a single SIP reque= st, I think we face a fundamental architecture choice in this mechanism: ei= ther it is SIP's job to sort out how we understand those different location= s, or it is PIDF's job. Traditionally, PIDF's understanding of different s= ources of presence that provide potentially contradictory information relie= s on the presence data model (RFC4479), which is designed to reconcile cond= itions like the one where my mobile phone thinks I am available but my desk= top thinks I'm offline. The presence data model moreover differentiates bet= ween users, services and devices in a way that is useful and apparently app= licable to location information. I am not eager to try to replicate this in= SIP headers, including by inserting multiple such headers, putting in mark= up that tries to explain the "source" of location information in SIP header= s, and so on. SIP's job should be to convey the location object - fundament= ally, the further we diverge from "conveyance" and enter into the realm of = "integration," the less comfortable I get. I understand that the subsequent use case where there are different source= s of location information, some of which are LbrV and some of which are Lby= R, looks like a hairy one. This is, however, a corner case of a corner cas= e. I really do not feel comfortable justifying the allowance of multiple lo= cation headers in SIP pointing to different presence objects (as opposed to= following the presence data model) to carry the 0, 1 or 2 different locati= ons due to a corner case of a corner case. As I said in my previous mail to= Martin, I'm not really sure I even understand the requirements for an inte= rmediary to evaluate and reject LbyR, nor what the best way is for presence= from these dynamic sources to be composed. If we were to investigate the r= ight way for presence from those source to be composed, it might very well = be that it is the responsibility of the compositor to insert an LbyR into t= he SIP request (into the Geolocation header), and to poll and compose a coh= erent PIDF document from its dynamic and static sources - that is probably = the approach that most closely parallels the traditional approaches to pres= ence. But we haven't even begun to explore this yet. No one insisting that = there will be "empty" PIDF documents just containing references to external= PIDF documents or something. Something along those lines is one approach o= f many that we would consider if we tried to figure out how to address this= in PIDF. The question we need to decide, as I said above, is the architect= ure one - is SIP's job to convey PIDF documents, or to compose them? Jon Peterson NeuStar, Inc. ... _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore --_000_C86A2BA341D74jonpetersonneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [sipcore] composition or just indirection (was: location-conveya= nce-03 just submitted)
It sounds like you agree that there is one Target, at least. I’m not = disagreeing that different entities might have different ideas about the lo= cation of the target; I just don’t see why that entails anything whet= her they should be in different presence documents or the same one. Again, = this is just a question of whether a bald list in a header field value has = enough syntactic richness to describe the relationship between those presen= ce documents, or whether we should let RFC4479 do that job. All of those cr= ufty parameters that had crept into the Geolocation header were symptoms of= the lack of syntactic richness in that neck of the woods, as was the bloat= in error codes related to their upkeep.

As to composition, any presence architecture that has multiple sources of p= resence has to provide composition somewhere. If (as the previous location-= conveyance document tacitly assumed) we deliver a bunch of separate presenc= e documents from different sources all talking about the same presentity/Ta= rget to a watcher (an LR, in geopriv parlance), then the responsibility dev= olves to the LR/watcher to effectively perform composition – to try t= o understand the documents and how they relate to one another in order to d= erive a useful picture of the presentity’s presence. The problem is, = the watcher is the least likely entity in the architecture to understand ho= w all these bits of information fit together.

Jon Peterson
NeuStar, Inc.


On 7/19/10 2:44 PM, "Richard L. Barnes" <rbarnes@bbn.com> wrote:

While it's correct to say that one presence= document describes a single entity, it's not necessarily true that multipl= e presence documents describe multiple entities.  Regardless of how we= define the entity in the session that is the target (IIRC, earlier version= s said something like "the UAC that initiated the dialogue"), it = seems plausible that different entities processing a SIP message might have= different ideas as to the location of the target.  In this case, it w= ould seem plausible to have multiple location objects in a single message, = all of which have the semantic that they're describing the location of the = target (however the target is coupled to the session).

Speaking more practically, if we accept the assertion that multiple locatio= n values will be necessary (whether in a single document or not), then it s= eems much cleaner to have them in separate presence documents, with separat= e CID URIs.  I don't really see any reason for any of this to call for= more than one Geolocation header, since you can just add more URIs.



On Jul 19, 2010, at 5:29 PM, Peterson, Jon wrote:


 I’m sure we’re all going to have to discuss this a bit in= Maastricht, but there are a couple basic points here I think we need to te= e up. I certainly didn’t mean to suggest that a request can only incl= ude a single location (i.e., that any contributing piece of location inform= ation designates the same place, just with varying degrees of accuracy or t= imeliness or something). Rather, I believe a presence document describes a = single entity – multiple locations come about because various devices= and services associated with that single entity may attribute various loca= tions to the entity.
 
 Getting back to fundamentals, we don’t need a Geolocation heade= r in order to carry location in SIP. There are MIME bodies for that (includ= ing Content-Indirection bodies for LbyR, or perhaps Content-Location as you= suggest), and we can include seventeen different location objects if we wa= nt to, regardless of whether there are zero or one or fifteen Geolocation h= eaders. We don’t need a location conveyance specification or a Geoloc= ation header to enable that, SIP has always been able to do it, and youR= 17;ll still be able to add random MIME bodies that contain location informa= tion even if there is a Geolocation header which does not point to them. So= what does the Geolocation header and location conveyance specification buy= us?
 
 I’ve always naively thought that the Geolocation header provide= s a coupling between this particular SIP session and an entity whose locati= on is designated by a PIDF document. The entity is the geopriv Target, and = is probably (though not necessarily) related to the party identified by the= classic From header field of the SIP request. The Geolocation header tells= us that for the purposes of the SIP session being negotiated, the location= of this Target is somehow relevant... the boldest interpretation would be = that this Target’s location should be considered the source of the re= quest. Just attaching location-aware MIME bodies without the Geolocation he= ader to SIP requests doesn’t convey the same semantics – those = bodies could mean anything, and presumably the receiving application would = sort through them at its discretion.
 
 Where I get confused is when I start trying to understand what it wou= ld mean semantically for a SIP session to be coupled with more than one Tar= get. Again, I can imagine hypothetically a SIP request containing unsorted = MIME bodies that talk about different Targets to assist some specific appli= cation that knows how to reconcile them, but here I mean using the Geolocat= ion header to couple a SIP request with location information about differen= t Targets. Is there actually a use case/requirement for that? If not, and w= e only want to couple a SIP request with one Target, then I fail to see why= composing location information about the same Target into a single PIDF bo= dy would be a problem. Having location information about the same entity fa= il to be organized in one body through RFC4479 wouldn’t make sense, a= nyway.
 
 I think if we understand the semantics by which the Geolocation heade= r “couples” PIDF with a SIP session, then we’ll better un= derstand all of this. If the Geolocation header only exists to notify lazy = intermediaries that there are location-sensitive bodies in the request or s= omewhere out on the net, without implying anything about the Target or the = relationship of those locations to the SIP request, then this whole specifi= cation is probably more trouble than it’s worth – it really wou= ldn’t provide much incremental value above the basic ability of SIP t= o carry all sorts of bodies, including location bodies. If there are, howev= er, more binding semantics here, then we probably won’t be able to ag= ree on the need for solitary or multiple Geolocation headers until we agree= on what those semantics are.
 
 Jon Peterson
 NeuStar, Inc.
 
 
 On 7/18/10 7:25 PM, "Thomson, Martin" <Martin.Thomson@andrew.com> wrote:
 
 
Hi Jon,
 
 I admit a fair degree of sympathy for Roger’s suggestion.  = ;After all, the ability to include multiple location “values” i= n the same SIP request is a feature that has existed for many years.  = A number of implementations have come to rely on this mechanism; people are= building and have built solutions based on earlier draft, fully aware of t= he risks in implementing an internet draft.
 
 At some point, it might be necessary to swallow any discomfort and re= cognize that the consequences of an imperfect solution are less than the co= nsequences of a change of the nature you suggest.
 
 Altering perspective might offer a solution.
 
 The idea that there are multiple items that are composited might be c= ounterproductive.  In this world-view, you have to reconcile a number = of perspectives.  In this, you are absolutely correct: doing that at t= wo layers is bad.  Composition is a hard problem already.  Moving= it into SIP only complicates it further.
 
 The alternative is to imagine a single logical resource that represen= ts the location of the Target.  A location by value is a representatio= n of this resource: a snapshot.  Location by reference offers a means = for any entity to identify and acquire a view of the resource, independent = of that snapshot.  The authority for the resource might offer the same= representation, or it could offer one better suited to the recipient. &nbs= p;The representation might be updated, it might be altered based on an auth= orization policy, or something else (language preferences).  Regardles= s of how it is represented, it is still the same resource.
 
 In simple terms, you state that the request can only include a single= _location_.  When a location value and reference are both included, t= hey represent the _same_ location.
 
 This is why I suggested that Content-Location be borrowed.  In H= TTP, Content-Location says - if you want to know where this resource really= lives, here is where you can find it.
 
 Now this might be sheer sophistry, but it might offer a way out. &nbs= p;The composition problems are left out of SIP.
 
 I can write up a more detailed strawman, but for now, I'll just inclu= de an example:
 
    INVITE sips:bob@= biloxi.example.com SIP/2.0
    Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch= =3Dz9hG4bK74bf9
    Max-Forwards: 70
    To: Bob <sips:bob@biloxi.example.com>
    From: Alice <sips:alice@atlanta.example.com>;tag=3D9fxced76sl
    Call-ID: 3848276298220188511@atlanta.example.com
    Geolocation: <cid:target123@atlanta.example.com>
      ;routing-allowed=3Dno
    Supported: geolocation
    Accept: application/sdp, application/pidf+xml
    CSeq: 31862 INVITE
    Contact: <sips:alice@atlanta.example.com>
    Content-Type: multipart/mixed; boundary=3Dboundary1=
    Content-Length: ...
 
    --boundary1
    Content-Type: application/sdp
 
    ...SDP goes here
 
    --boundary1
    Content-Type: application/pidf+xml
    Content-ID: <target123@atlanta.example.com>
    Content-Location: pres:alice@example.com?location/XJhbXM6eG1sOm5zO= nBpZ
 
    <?xml version=3D"1.0"?>
    ...PIDF-LO document
    --boundary1--
 
 
 --Martin
 
 ---- Original Message ----
 From: Peterson, Jon [mail= to:jon.peterson@neustar.biz]
 Sent: Friday, 16 July 2010 4:54 PM
 To: Roger Marshall; Thomson, Martin; James M. Polk; sipcore@ietf.org
 Subject: Re: [sipcore] location-conveyance-03 just submitted
 
 
 In the corner case (and I do think it is a corner case) where multipl= e entities are contributing different location information to a single SIP = request, I think we face a fundamental architecture choice in this mechanis= m: either it is SIP’s job to sort out how we understand those differe= nt locations, or it is PIDF’s job.  Traditionally, PIDF’s = understanding of different sources of presence that provide potentially con= tradictory information relies on the presence data model (RFC4479), which i= s designed to reconcile conditions like the one where my mobile phone think= s I am available but my desktop thinks I’m offline. The presence data= model moreover differentiates between users, services and devices in a way= that is useful and apparently applicable to location information. I am not= eager to try to replicate this in SIP headers, including by inserting mult= iple such headers, putting in markup that tries to explain the “sourc= e” of location information in SIP headers, and so on. SIP’s job= should be to convey the location object – fundamentally, the further= we diverge from “conveyance” and enter into the realm of ̶= 0;integration,” the less comfortable I get.
 
 I understand that the subsequent use case where there are different s= ources of location information, some of which are LbrV and some of which ar= e LbyR, looks like a  hairy one. This is, however, a corner case of a = corner case. I really do not feel comfortable justifying the allowance of m= ultiple location headers in SIP pointing to different presence objects (as = opposed to following the presence data model) to carry the 0, 1 or 2 differ= ent locations due to a corner case of a corner case. As I said in my previo= us mail to Martin, I’m not really sure I even understand the requirem= ents for an intermediary to evaluate and reject LbyR, nor what the best way= is for presence from these dynamic sources to be composed. If we were to i= nvestigate the right way for presence from those source to be composed, it = might very well be that it is the responsibility of the compositor to inser= t an LbyR into the SIP request (into the Geolocation header), and to poll a= nd compose a coherent PIDF document from its dynamic and static sources = 211; that is probably the approach that most closely parallels the traditio= nal approaches to presence. But we haven’t even begun to explore this= yet. No one insisting that there will be “empty” PIDF document= s just containing references to external PIDF documents or something. Somet= hing along those lines is one approach of many that we would consider if we= tried to figure out how to address this in PIDF. The question we need to d= ecide, as I said above, is the architecture one – is SIP’s job = to convey PIDF documents, or to compose them?
 
 Jon Peterson
 NeuStar, Inc.
 
 …
 
 
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore
To: "Peterson, Jon" In-Reply-To: Content-Type: multipart/alternative; boundary=Apple-Mail-19-629344957 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 19 Jul 2010 20:04:15 -0400 References: X-Mailer: Apple Mail (2.936) Cc: Roger Marshall , "sipcore@ietf.org" , "Thomson, Martin" Subject: Re: [sipcore] composition or just indirection (was: location-conveyance-03 just 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: Tue, 20 Jul 2010 00:04:07 -0000 --Apple-Mail-19-629344957 Content-Type: text/plain; charset=WINDOWS-1252; format=flowed; delsp=yes Content-Transfer-Encoding: quoted-printable Certainly agree that there is one Target, so the question is simply =20 how to represent multiple estimates of that target's location. Your analysis is correct that carrying separate location objects =20 effectively gives the LR the responsibility for compositing, but I'm =20 not sure that's a bad thing. The LR has an idea of what application =20 it's using the location information for -- something an intermediary =20 probably lacks -- which can inform how it chooses or combines location =20= values. The question then becomes how to provide the LR with sufficient =20 information to make these decisions. Beyond information in the =20 location object itself (e.g., accuracy or privacy settings), it seems =20= like the main data of interest would be: -- How the location information was determined, and possibly -- Who inserted the location object Along these dimensions, there's really no difference between the one-=20 object and multiple-object cases. In both cases, the determination =20 method will be in a tag inside the element. =20 Neither option provides much good information about who inserts a =20 location object -- the primary mechanism in RFC 4479 is the =20 element (which isn't really all that helpful), leaving you basically =20 with preference-ordering in either case (see RFC 5491). There are probably also scenarios where the intermediary knows best, =20 but allowing for multiple location values would seem to allow for =20 either possibility: If an intermediary wants to composite, it can, or =20= it can just tack on what it has. So I think the question comes down to two things: 1. Whether you want to allow entities *not* to composite 2. Where you want your preference ordering (URI list or XML) 3. How easy you want it to be to add objects Especially given the tidiness of the layering in the multi-object =20 model (w.r.t. 3), it seems like allowing multiple objects wins on =20 counts 1 and 3. And on balance, probably point 2 as well, since you =20 can read the ordering without parsing any XML first. --Richard On Jul 19, 2010, at 7:19 PM, Peterson, Jon wrote: > > It sounds like you agree that there is one Target, at least. I=92m not = =20 > disagreeing that different entities might have different ideas about =20= > the location of the target; I just don=92t see why that entails =20 > anything whether they should be in different presence documents or =20 > the same one. Again, this is just a question of whether a bald list =20= > in a header field value has enough syntactic richness to describe =20 > the relationship between those presence documents, or whether we =20 > should let RFC4479 do that job. All of those crufty parameters that =20= > had crept into the Geolocation header were symptoms of the lack of =20 > syntactic richness in that neck of the woods, as was the bloat in =20 > error codes related to their upkeep. > > As to composition, any presence architecture that has multiple =20 > sources of presence has to provide composition somewhere. If (as the =20= > previous location-conveyance document tacitly assumed) we deliver a =20= > bunch of separate presence documents from different sources all =20 > talking about the same presentity/Target to a watcher (an LR, in =20 > geopriv parlance), then the responsibility devolves to the LR/=20 > watcher to effectively perform composition =96 to try to understand =20= > the documents and how they relate to one another in order to derive =20= > a useful picture of the presentity=92s presence. The problem is, the =20= > watcher is the least likely entity in the architecture to understand =20= > how all these bits of information fit together. > > Jon Peterson > NeuStar, Inc. > > > On 7/19/10 2:44 PM, "Richard L. Barnes" wrote: > > While it's correct to say that one presence document describes a =20 > single entity, it's not necessarily true that multiple presence =20 > documents describe multiple entities. Regardless of how we define =20 > the entity in the session that is the target (IIRC, earlier versions =20= > said something like "the UAC that initiated the dialogue"), it seems =20= > plausible that different entities processing a SIP message might =20 > have different ideas as to the location of the target. In this =20 > case, it would seem plausible to have multiple location objects in a =20= > single message, all of which have the semantic that they're =20 > describing the location of the target (however the target is coupled =20= > to the session). > > Speaking more practically, if we accept the assertion that multiple =20= > location values will be necessary (whether in a single document or =20 > not), then it seems much cleaner to have them in separate presence =20 > documents, with separate CID URIs. I don't really see any reason =20 > for any of this to call for more than one Geolocation header, since =20= > you can just add more URIs. > > > > On Jul 19, 2010, at 5:29 PM, Peterson, Jon wrote: > > > I=92m sure we=92re all going to have to discuss this a bit in =20 > Maastricht, but there are a couple basic points here I think we need =20= > to tee up. I certainly didn=92t mean to suggest that a request can =20 > only include a single location (i.e., that any contributing piece of =20= > location information designates the same place, just with varying =20 > degrees of accuracy or timeliness or something). Rather, I believe a =20= > presence document describes a single entity =96 multiple locations =20 > come about because various devices and services associated with that =20= > single entity may attribute various locations to the entity. > > Getting back to fundamentals, we don=92t need a Geolocation header in = =20 > order to carry location in SIP. There are MIME bodies for that =20 > (including Content-Indirection bodies for LbyR, or perhaps Content-=20 > Location as you suggest), and we can include seventeen different =20 > location objects if we want to, regardless of whether there are zero =20= > or one or fifteen Geolocation headers. We don=92t need a location =20 > conveyance specification or a Geolocation header to enable that, SIP =20= > has always been able to do it, and you=92ll still be able to add =20 > random MIME bodies that contain location information even if there =20 > is a Geolocation header which does not point to them. So what does =20 > the Geolocation header and location conveyance specification buy us? > > I=92ve always naively thought that the Geolocation header provides a =20= > coupling between this particular SIP session and an entity whose =20 > location is designated by a PIDF document. The entity is the geopriv =20= > Target, and is probably (though not necessarily) related to the =20 > party identified by the classic =46rom header field of the SIP =20 > request. The Geolocation header tells us that for the purposes of =20 > the SIP session being negotiated, the location of this Target is =20 > somehow relevant... the boldest interpretation would be that this =20 > Target=92s location should be considered the source of the request. =20= > Just attaching location-aware MIME bodies without the Geolocation =20 > header to SIP requests doesn=92t convey the same semantics =96 those =20= > bodies could mean anything, and presumably the receiving application =20= > would sort through them at its discretion. > > Where I get confused is when I start trying to understand what it =20 > would mean semantically for a SIP session to be coupled with more =20 > than one Target. Again, I can imagine hypothetically a SIP request =20 > containing unsorted MIME bodies that talk about different Targets to =20= > assist some specific application that knows how to reconcile them, =20 > but here I mean using the Geolocation header to couple a SIP request =20= > with location information about different Targets. Is there actually =20= > a use case/requirement for that? If not, and we only want to couple =20= > a SIP request with one Target, then I fail to see why composing =20 > location information about the same Target into a single PIDF body =20 > would be a problem. Having location information about the same =20 > entity fail to be organized in one body through RFC4479 wouldn=92t =20 > make sense, anyway. > > I think if we understand the semantics by which the Geolocation =20 > header =93couples=94 PIDF with a SIP session, then we=92ll better =20 > understand all of this. If the Geolocation header only exists to =20 > notify lazy intermediaries that there are location-sensitive bodies =20= > in the request or somewhere out on the net, without implying =20 > anything about the Target or the relationship of those locations to =20= > the SIP request, then this whole specification is probably more =20 > trouble than it=92s worth =96 it really wouldn=92t provide much =20 > incremental value above the basic ability of SIP to carry all sorts =20= > of bodies, including location bodies. If there are, however, more =20 > binding semantics here, then we probably won=92t be able to agree on =20= > the need for solitary or multiple Geolocation headers until we agree =20= > on what those semantics are. > > Jon Peterson > NeuStar, Inc. > > > On 7/18/10 7:25 PM, "Thomson, Martin" =20 > wrote: > > > Hi Jon, > > I admit a fair degree of sympathy for Roger=92s suggestion. After =20= > all, the ability to include multiple location =93values=94 in the same = =20 > SIP request is a feature that has existed for many years. A number =20= > of implementations have come to rely on this mechanism; people are =20 > building and have built solutions based on earlier draft, fully =20 > aware of the risks in implementing an internet draft. > > At some point, it might be necessary to swallow any discomfort and =20= > recognize that the consequences of an imperfect solution are less =20 > than the consequences of a change of the nature you suggest. > > Altering perspective might offer a solution. > > The idea that there are multiple items that are composited might be =20= > counterproductive. In this world-view, you have to reconcile a =20 > number of perspectives. In this, you are absolutely correct: doing =20= > that at two layers is bad. Composition is a hard problem already. =20= > Moving it into SIP only complicates it further. > > The alternative is to imagine a single logical resource that =20 > represents the location of the Target. A location by value is a =20 > representation of this resource: a snapshot. Location by reference =20= > offers a means for any entity to identify and acquire a view of the =20= > resource, independent of that snapshot. The authority for the =20 > resource might offer the same representation, or it could offer one =20= > better suited to the recipient. The representation might be =20 > updated, it might be altered based on an authorization policy, or =20 > something else (language preferences). Regardless of how it is =20 > represented, it is still the same resource. > > In simple terms, you state that the request can only include a =20 > single _location_. When a location value and reference are both =20 > included, they represent the _same_ location. > > This is why I suggested that Content-Location be borrowed. In =20 > HTTP, Content-Location says - if you want to know where this =20 > resource really lives, here is where you can find it. > > Now this might be sheer sophistry, but it might offer a way out. =20 > The composition problems are left out of SIP. > > I can write up a more detailed strawman, but for now, I'll just =20 > include an example: > > INVITE sips:bob@biloxi.example.com SIP/2.0 > Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4bK74bf9 > Max-Forwards: 70 > To: Bob > From: Alice ;tag=3D9fxced76sl > Call-ID: 3848276298220188511@atlanta.example.com > Geolocation: > ;routing-allowed=3Dno > Supported: geolocation > Accept: application/sdp, application/pidf+xml > CSeq: 31862 INVITE > Contact: > Content-Type: multipart/mixed; boundary=3Dboundary1 > Content-Length: ... > > --boundary1 > Content-Type: application/sdp > > ...SDP goes here > > --boundary1 > Content-Type: application/pidf+xml > Content-ID: > Content-Location: = pres:alice@example.com?location/XJhbXM6eG1sOm5zOnBpZ > > > ...PIDF-LO document > --boundary1-- > > > --Martin > > ---- Original Message ---- > From: Peterson, Jon [mailto:jon.peterson@neustar.biz] > Sent: Friday, 16 July 2010 4:54 PM > To: Roger Marshall; Thomson, Martin; James M. Polk; sipcore@ietf.org > Subject: Re: [sipcore] location-conveyance-03 just submitted > > > In the corner case (and I do think it is a corner case) where =20 > multiple entities are contributing different location information to =20= > a single SIP request, I think we face a fundamental architecture =20 > choice in this mechanism: either it is SIP=92s job to sort out how we =20= > understand those different locations, or it is PIDF=92s job. =20 > Traditionally, PIDF=92s understanding of different sources of presence = =20 > that provide potentially contradictory information relies on the =20 > presence data model (RFC4479), which is designed to reconcile =20 > conditions like the one where my mobile phone thinks I am available =20= > but my desktop thinks I=92m offline. The presence data model moreover =20= > differentiates between users, services and devices in a way that is =20= > useful and apparently applicable to location information. I am not =20 > eager to try to replicate this in SIP headers, including by =20 > inserting multiple such headers, putting in markup that tries to =20 > explain the =93source=94 of location information in SIP headers, and = so =20 > on. SIP=92s job should be to convey the location object =96 =20 > fundamentally, the further we diverge from =93conveyance=94 and enter =20= > into the realm of =93integration,=94 the less comfortable I get. > > I understand that the subsequent use case where there are different =20= > sources of location information, some of which are LbrV and some of =20= > which are LbyR, looks like a hairy one. This is, however, a corner =20= > case of a corner case. I really do not feel comfortable justifying =20 > the allowance of multiple location headers in SIP pointing to =20 > different presence objects (as opposed to following the presence =20 > data model) to carry the 0, 1 or 2 different locations due to a =20 > corner case of a corner case. As I said in my previous mail to =20 > Martin, I=92m not really sure I even understand the requirements for =20= > an intermediary to evaluate and reject LbyR, nor what the best way =20 > is for presence from these dynamic sources to be composed. If we =20 > were to investigate the right way for presence from those source to =20= > be composed, it might very well be that it is the responsibility of =20= > the compositor to insert an LbyR into the SIP request (into the =20 > Geolocation header), and to poll and compose a coherent PIDF =20 > document from its dynamic and static sources =96 that is probably the =20= > approach that most closely parallels the traditional approaches to =20 > presence. But we haven=92t even begun to explore this yet. No one =20 > insisting that there will be =93empty=94 PIDF documents just = containing =20 > references to external PIDF documents or something. Something along =20= > those lines is one approach of many that we would consider if we =20 > tried to figure out how to address this in PIDF. The question we =20 > need to decide, as I said above, is the architecture one =96 is SIP=92s = =20 > job to convey PIDF documents, or to compose them? > > Jon Peterson > NeuStar, Inc. > > =85 > > > > _______________________________________________ > 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 --Apple-Mail-19-629344957 Content-Type: text/html; charset=WINDOWS-1252 Content-Transfer-Encoding: quoted-printable Certainly agree that there is = one Target, so the question is simply how to represent multiple = estimates of that target's location.

Your analysis is = correct that carrying separate location objects effectively gives the LR = the responsibility for compositing, but I'm not sure that's a bad thing. =  The LR has an idea of what application it's using the location = information for -- something an intermediary probably lacks -- which can = inform how it chooses or combines location values. =  

The question then becomes how to provide = the LR with sufficient information to make these decisions.  Beyond = information in the location object itself (e.g., accuracy or privacy = settings), it seems like the main data of interest would = be:
-- How the location information was determined, and = possibly
-- Who inserted the location object
Along = these dimensions, there's really no difference between the one-object = and multiple-object cases.  In both cases, the determination method = will be in a <method> tag inside the  <geopriv> = element.  Neither option provides much good information about who = inserts a location object -- the primary mechanism in RFC 4479 is the = <device> element (which isn't really all that helpful), leaving = you basically with preference-ordering in either case (see RFC 5491). =  

There are probably also scenarios where = the intermediary knows best, but allowing for multiple location values = would seem to allow for either possibility: If an intermediary wants to = composite, it can, or it can just tack on what it = has.

So I think the question comes down to = two things:
1. Whether you want to allow entities *not* to = composite
2. Where you want your preference ordering (URI list = or XML)
3. How easy you want it to be to add = objects

Especially given the tidiness of the = layering in the multi-object model (w.r.t. 3), it seems like allowing = multiple objects wins on counts 1 and 3.  And on balance, probably = point 2 as well, since you can read the ordering without parsing any XML = first.

--Richard




On Jul 19, 2010, at 7:19 PM, = Peterson, Jon wrote:

=
It sounds like you agree that there is one = Target, at least. I=92m not disagreeing that different entities might = have different ideas about the location of the target; I just don=92t = see why that entails anything whether they should be in different = presence documents or the same one. Again, this is just a question of = whether a bald list in a header field value has enough syntactic = richness to describe the relationship between those presence documents, = or whether we should let RFC4479 do that job. All of those crufty = parameters that had crept into the Geolocation header were symptoms of = the lack of syntactic richness in that neck of the woods, as was the = bloat in error codes related to their upkeep.

As to = composition, any presence architecture that has multiple sources of = presence has to provide composition somewhere. If (as the previous = location-conveyance document tacitly assumed) we deliver a bunch of = separate presence documents from different sources all talking about the = same presentity/Target to a watcher (an LR, in geopriv parlance), then = the responsibility devolves to the LR/watcher to effectively perform = composition =96 to try to understand the documents and how they relate = to one another in order to derive a useful picture of the presentity=92s = presence. The problem is, the watcher is the least likely entity in the = architecture to understand how all these bits of information fit = together.

Jon Peterson
NeuStar, Inc.


On = 7/19/10 2:44 PM, "Richard L. Barnes" <rbarnes@bbn.com> wrote:

=
While it's correct to say that one = presence document describes a single entity, it's not necessarily true = that multiple presence documents describe multiple entities. =  Regardless of how we define the entity in the session that is the = target (IIRC, earlier versions said something like "the UAC that = initiated the dialogue"), it seems plausible that different entities = processing a SIP message might have different ideas as to the location = of the target.  In this case, it would seem plausible to have = multiple location objects in a single message, all of which have the = semantic that they're describing the location of the target (however the = target is coupled to the session).

Speaking more practically, = if we accept the assertion that multiple location values will be = necessary (whether in a single document or not), then it seems much = cleaner to have them in separate presence documents, with separate CID = URIs.  I don't really see any reason for any of this to call for = more than one Geolocation header, since you can just add more URIs.
=


On Jul 19, 2010, at 5:29 PM, Peterson, Jon wrote:
=

 I=92m sure = we=92re all going to have to discuss this a bit in Maastricht, but there = are a couple basic points here I think we need to tee up. I certainly = didn=92t mean to suggest that a request can only include a single = location (i.e., that any contributing piece of location information = designates the same place, just with varying degrees of accuracy or = timeliness or something). Rather, I believe a presence document = describes a single entity =96 multiple locations come about because = various devices and services associated with that single entity may = attribute various locations to the entity.
 
 Getting = back to fundamentals, we don=92t need a Geolocation header in order to = carry location in SIP. There are MIME bodies for that (including = Content-Indirection bodies for LbyR, or perhaps Content-Location as you = suggest), and we can include seventeen different location objects if we = want to, regardless of whether there are zero or one or fifteen = Geolocation headers. We don=92t need a location conveyance specification = or a Geolocation header to enable that, SIP has always been able to do = it, and you=92ll still be able to add random MIME bodies that contain = location information even if there is a Geolocation header which does = not point to them. So what does the Geolocation header and location = conveyance specification buy us?
 
 I=92ve always = naively thought that the Geolocation header provides a coupling between = this particular SIP session and an entity whose location is designated = by a PIDF document. The entity is the geopriv Target, and is probably = (though not necessarily) related to the party identified by the classic = =46rom header field of the SIP request. The Geolocation header tells us = that for the purposes of the SIP session being negotiated, the location = of this Target is somehow relevant... the boldest interpretation would = be that this Target=92s location should be considered the source of the = request. Just attaching location-aware MIME bodies without the = Geolocation header to SIP requests doesn=92t convey the same semantics =96= those bodies could mean anything, and presumably the receiving = application would sort through them at its discretion.
 
=  Where I get confused is when I start trying to understand what it = would mean semantically for a SIP session to be coupled with more than = one Target. Again, I can imagine hypothetically a SIP request containing = unsorted MIME bodies that talk about different Targets to assist some = specific application that knows how to reconcile them, but here I mean = using the Geolocation header to couple a SIP request with location = information about different Targets. Is there actually a use = case/requirement for that? If not, and we only want to couple a SIP = request with one Target, then I fail to see why composing location = information about the same Target into a single PIDF body would be a = problem. Having location information about the same entity fail to be = organized in one body through RFC4479 wouldn=92t make sense, anyway.
=  
 I think if we understand the semantics by which the = Geolocation header =93couples=94 PIDF with a SIP session, then we=92ll = better understand all of this. If the Geolocation header only exists to = notify lazy intermediaries that there are location-sensitive bodies in = the request or somewhere out on the net, without implying anything about = the Target or the relationship of those locations to the SIP request, = then this whole specification is probably more trouble than it=92s worth = =96 it really wouldn=92t provide much incremental value above the basic = ability of SIP to carry all sorts of bodies, including location bodies. = If there are, however, more binding semantics here, then we probably = won=92t be able to agree on the need for solitary or multiple = Geolocation headers until we agree on what those semantics are.
=  
 Jon Peterson
 NeuStar, Inc.
 
=  
 On 7/18/10 7:25 PM, "Thomson, Martin" <Martin.Thomson@andrew.com> = wrote:
 
 
Hi Jon,
 
 I admit a fair = degree of sympathy for Roger=92s suggestion.  After all, the = ability to include multiple location =93values=94 in the same SIP = request is a feature that has existed for many years.  A number of = implementations have come to rely on this mechanism; people are building = and have built solutions based on earlier draft, fully aware of the = risks in implementing an internet draft.
 
 At some = point, it might be necessary to swallow any discomfort and recognize = that the consequences of an imperfect solution are less than the = consequences of a change of the nature you suggest.
 
=  Altering perspective might offer a solution.
 
=  The idea that there are multiple items that are composited might = be counterproductive.  In this world-view, you have to reconcile a = number of perspectives.  In this, you are absolutely correct: doing = that at two layers is bad.  Composition is a hard problem already. =  Moving it into SIP only complicates it further.
 
=  The alternative is to imagine a single logical resource that = represents the location of the Target.  A location by value is a = representation of this resource: a snapshot.  Location by reference = offers a means for any entity to identify and acquire a view of the = resource, independent of that snapshot.  The authority for the = resource might offer the same representation, or it could offer one = better suited to the recipient.  The representation might be = updated, it might be altered based on an authorization policy, or = something else (language preferences).  Regardless of how it is = represented, it is still the same resource.
 
 In = simple terms, you state that the request can only include a single = _location_.  When a location value and reference are both included, = they represent the _same_ location.
 
 This is why I = suggested that Content-Location be borrowed.  In HTTP, = Content-Location says - if you want to know where this resource really = lives, here is where you can find it.
 
 Now this = might be sheer sophistry, but it might offer a way out.  The = composition problems are left out of SIP.
 
 I can = write up a more detailed strawman, but for now, I'll just include an = example:
 
    INVITE sips:bob@biloxi.example.com SIP/2.0
=     Via: SIPS/2.0/TLS = pc33.atlanta.example.com;branch=3Dz9hG4bK74bf9
=     Max-Forwards: 70
    To: = Bob <sips:bob@biloxi.example.com>
=     From: Alice <sips:alice@atlanta.example.com>;tag=3D= 9fxced76sl
    Call-ID: 3848276298220188511@atlan= ta.example.com
    Geolocation: <cid:target123@atlanta.example.com&g= t;
      ;routing-allowed=3Dno
=     Supported: geolocation
=     Accept: application/sdp, = application/pidf+xml
    CSeq: 31862 INVITE
=     Contact: <sips:alice@atlanta.example.com>
=     Content-Type: multipart/mixed; = boundary=3Dboundary1
    Content-Length: ...
=  
    --boundary1
=     Content-Type: application/sdp
 
=     ...SDP goes here
 
=     --boundary1
=     Content-Type: application/pidf+xml
=     Content-ID: <target123@atlanta.example.com&g= t;
    Content-Location: pres:alice@example.com= ?location/XJhbXM6eG1sOm5zOnBpZ
 
=     <?xml version=3D"1.0"?>
=     ...PIDF-LO document
=     --boundary1--
 
 
=  --Martin
 
 ---- Original Message ----
=  From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
 Sent: Friday, 16 July 2010 4:54 PM
 To: Roger = Marshall; Thomson, Martin; James M. Polk; sipcore@ietf.org
 Subject: Re: = [sipcore] location-conveyance-03 just submitted
 
=  
 In the corner case (and I do think it is a corner case) = where multiple entities are contributing different location information = to a single SIP request, I think we face a fundamental architecture = choice in this mechanism: either it is SIP=92s job to sort out how we = understand those different locations, or it is PIDF=92s job. =  Traditionally, PIDF=92s understanding of different sources of = presence that provide potentially contradictory information relies on = the presence data model (RFC4479), which is designed to reconcile = conditions like the one where my mobile phone thinks I am available but = my desktop thinks I=92m offline. The presence data model moreover = differentiates between users, services and devices in a way that is = useful and apparently applicable to location information. I am not eager = to try to replicate this in SIP headers, including by inserting multiple = such headers, putting in markup that tries to explain the =93source=94 = of location information in SIP headers, and so on. SIP=92s job should be = to convey the location object =96 fundamentally, the further we diverge = from =93conveyance=94 and enter into the realm of =93integration,=94 the = less comfortable I get.
 
 I understand that the = subsequent use case where there are different sources of location = information, some of which are LbrV and some of which are LbyR, looks = like a  hairy one. This is, however, a corner case of a corner = case. I really do not feel comfortable justifying the allowance of = multiple location headers in SIP pointing to different presence objects = (as opposed to following the presence data model) to carry the 0, 1 or 2 = different locations due to a corner case of a corner case. As I said in = my previous mail to Martin, I=92m not really sure I even understand the = requirements for an intermediary to evaluate and reject LbyR, nor what = the best way is for presence from these dynamic sources to be composed. = If we were to investigate the right way for presence from those source = to be composed, it might very well be that it is the responsibility of = the compositor to insert an LbyR into the SIP request (into the = Geolocation header), and to poll and compose a coherent PIDF document = from its dynamic and static sources =96 that is probably the approach = that most closely parallels the traditional approaches to presence. But = we haven=92t even begun to explore this yet. No one insisting that there = will be =93empty=94 PIDF documents just containing references to = external PIDF documents or something. Something along those lines is one = approach of many that we would consider if we tried to figure out how to = address this in PIDF. The question we need to decide, as I said above, = is the architecture one =96 is SIP=92s job to convey PIDF documents, or = to compose them?
 
 Jon Peterson
 NeuStar, = Inc.
 
 =85
 
 
=

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


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

= --Apple-Mail-19-629344957-- From pkyzivat@cisco.com Mon Jul 19 17:06:38 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1B6193A6BC4 for ; Mon, 19 Jul 2010 17:06:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.493 X-Spam-Level: X-Spam-Status: No, score=-10.493 tagged_above=-999 required=5 tests=[AWL=0.106, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZncuIhN1NcTR for ; Mon, 19 Jul 2010 17:06:35 -0700 (PDT) Received: from rtp-iport-2.cisco.com (rtp-iport-2.cisco.com [64.102.122.149]) by core3.amsl.com (Postfix) with ESMTP id 5561F3A6BA5 for ; Mon, 19 Jul 2010 17:06:34 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,229,1278288000"; d="scan'208";a="134408643" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 20 Jul 2010 00:06:49 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6K06mhS027492; Tue, 20 Jul 2010 00:06:48 GMT Message-ID: <4C44E898.6040304@cisco.com> Date: Mon, 19 Jul 2010 20:06:48 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Winterbottom, James" References: <20100719081458.77080@gmx.net> <201007191857.o6JIv7in014515@sj-core-1.cisco.com> <2936AA57-EEDC-4B43-BE88-E5BDB5D44C8C@bbn.com> <201007191943.o6JJhIrX004288@sj-core-2.cisco.com> <4C44D2E8.8020904@cisco.com> <5A55A45AE77F5941B18E5457ECAC81880120E9829415@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880120E9829415@SISPE7MB1.commscope.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "Richard L. Barnes" , Hannes Tschofenig , "sipcore@ietf.org" Subject: Re: [sipcore] Location Conveyance Question: Multiple Location X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Jul 2010 00:06:38 -0000 Fair enough. I guess that must be what the following words from the draft are about: Other URI schemas used in the location URI MUST be reviewed against the RFC 3693 [RFC3693] criteria for a Using Protocol. I guess I don't understand the details of that MUST. Who/what must do that? Thanks, Paul Winterbottom, James wrote: > By the same token absoluteURI also permits pres:, sip: and sips: URI schemes, yet these are explicitly called out, presumably because there is specification work that says how to use them for acquiring location information. Hannes's comment, and indeed my comment made nearly a week ago, are simply calling for the inclusion of the http: and http2: URI schemes to also be included because similar specification work on how to use these schemes to acquire location information exists. > > If the argument is that this is covered by the absoluteURI component, then presumably that is all the ABNF requires, and the sips: sips: and pres: URI schemes can also be removed. > > Cheers > James > > > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf >> Of Paul Kyzivat >> Sent: Tuesday, 20 July 2010 8:34 AM >> To: James M. Polk >> Cc: Richard L. Barnes; Hannes Tschofenig; sipcore@ietf.org >> Subject: Re: [sipcore] Location Conveyance Question: Multiple Location >> >> >> >> James M. Polk wrote: >>> At 02:12 PM 7/19/2010, Richard L. Barnes wrote: >>>> I might be mistaken, but it looks to me as if the header ABNF would >>>> allow the following: >>>> >>>> Geolocation: ,>>> foobar> >> The ABNF permits that (by virtue of allowing absoluteURI, http: is >> permitted), but the text does not: >> >> The Geolocation header field has zero or one locationValue, but >> MUST NOT contain more than one locationValue. >> >> > sipcore > From jmpolk@cisco.com Mon Jul 19 18:56:03 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9360D3A6BD9 for ; Mon, 19 Jul 2010 18:56:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.634 X-Spam-Level: X-Spam-Status: No, score=-9.634 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id io7sk3ZHwAOr for ; Mon, 19 Jul 2010 18:56:01 -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 9423C3A6BD3 for ; Mon, 19 Jul 2010 18:56:01 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 20 Jul 2010 01:23:09 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6K1N8PU005489; Tue, 20 Jul 2010 01:23:08 GMT Message-Id: <201007200123.o6K1N8PU005489@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Jul 2010 20:23:07 -0500 To: "Richard L. Barnes" , "Peterson, Jon" From: "James M. Polk" In-Reply-To: <605CEAA0-91F5-4860-A2B6-7E1BAFD3D847@bbn.com> References: <605CEAA0-91F5-4860-A2B6-7E1BAFD3D847@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Roger Marshall , "sipcore@ietf.org" , "Thomson, Martin" Subject: Re: [sipcore] composition or just indirection (was: location-conveyance-03 just 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: Tue, 20 Jul 2010 01:56:03 -0000 Richard Let's not forget the cost of having more than one=20 document in terms of additive bytes in the=20 request. Adding another or =20 element is not that much more data, whereas=20 adding a second or third PIDF would be a lot more. James At 04:44 PM 7/19/2010, Richard L. Barnes wrote: >While it's correct to say that one presence=20 >document describes a single entity, it's not=20 >necessarily true that multiple presence=20 >documents describe multiple=20 >entities. Regardless of how we define the=20 >entity in the session that is the target (IIRC,=20 >earlier versions said something like "the UAC=20 >that initiated the dialogue"), it seems=20 >plausible that different entities processing a=20 >SIP message might have different ideas as to the=20 >location of the target. In this case, it would=20 >seem plausible to have multiple location objects=20 >in a single message, all of which have the=20 >semantic that they're describing the location of=20 >the target (however the target is coupled to the session). > >Speaking more practically, if we accept the=20 >assertion that multiple location values will be=20 >necessary (whether in a single document or not),=20 >then it seems much cleaner to have them in=20 >separate presence documents, with separate CID=20 >URIs. I don't really see any reason for any of=20 >this to call for more than one Geolocation=20 >header, since you can just add more URIs. > > > >On Jul 19, 2010, at 5:29 PM, Peterson, Jon wrote: > >> >>I=92m sure we=92re all going to have to discuss=20 >>this a bit in Maastricht, but there are a=20 >>couple basic points here I think we need to tee=20 >>up. I certainly didn=92t mean to suggest that a=20 >>request can only include a single location=20 >>(i.e., that any contributing piece of location=20 >>information designates the same place, just=20 >>with varying degrees of accuracy or timeliness=20 >>or something). Rather, I believe a presence=20 >>document describes a single entity =96 multiple=20 >>locations come about because various devices=20 >>and services associated with that single entity=20 >>may attribute various locations to the entity. >> >>Getting back to fundamentals, we don=92t need a=20 >>Geolocation header in order to carry location=20 >>in SIP. There are MIME bodies for that=20 >>(including Content-Indirection bodies for LbyR,=20 >>or perhaps Content-Location as you suggest),=20 >>and we can include seventeen different location=20 >>objects if we want to, regardless of whether=20 >>there are zero or one or fifteen Geolocation=20 >>headers. We don=92t need a location conveyance=20 >>specification or a Geolocation header to enable=20 >>that, SIP has always been able to do it, and=20 >>you=92ll still be able to add random MIME bodies=20 >>that contain location information even if there=20 >>is a Geolocation header which does not point to=20 >>them. So what does the Geolocation header and=20 >>location conveyance specification buy us? >> >>I=92ve always naively thought that the=20 >>Geolocation header provides a coupling between=20 >>this particular SIP session and an entity whose=20 >>location is designated by a PIDF document. The=20 >>entity is the geopriv Target, and is probably=20 >>(though not necessarily) related to the party=20 >>identified by the classic From header field of=20 >>the SIP request. The Geolocation header tells=20 >>us that for the purposes of the SIP session=20 >>being negotiated, the location of this Target=20 >>is somehow relevant... the boldest=20 >>interpretation would be that this Target=92s=20 >>location should be considered the source of the=20 >>request. Just attaching location-aware MIME=20 >>bodies without the Geolocation header to SIP=20 >>requests doesn=92t convey the same semantics =96=20 >>those bodies could mean anything, and=20 >>presumably the receiving application would sort through them at its= discretion. >> >>Where I get confused is when I start trying to=20 >>understand what it would mean semantically for=20 >>a SIP session to be coupled with more than one=20 >>Target. Again, I can imagine hypothetically a=20 >>SIP request containing unsorted MIME bodies=20 >>that talk about different Targets to assist=20 >>some specific application that knows how to=20 >>reconcile them, but here I mean using the=20 >>Geolocation header to couple a SIP request with=20 >>location information about different Targets.=20 >>Is there actually a use case/requirement for=20 >>that? If not, and we only want to couple a SIP=20 >>request with one Target, then I fail to see why=20 >>composing location information about the same=20 >>Target into a single PIDF body would be a=20 >>problem. Having location information about the=20 >>same entity fail to be organized in one body=20 >>through RFC4479 wouldn=92t make sense, anyway. >> >>I think if we understand the semantics by which=20 >>the Geolocation header =93couples=94 PIDF with a=20 >>SIP session, then we=92ll better understand all=20 >>of this. If the Geolocation header only exists=20 >>to notify lazy intermediaries that there are=20 >>location-sensitive bodies in the request or=20 >>somewhere out on the net, without implying=20 >>anything about the Target or the relationship=20 >>of those locations to the SIP request, then=20 >>this whole specification is probably more=20 >>trouble than it=92s worth =96 it really wouldn=92t=20 >>provide much incremental value above the basic=20 >>ability of SIP to carry all sorts of bodies,=20 >>including location bodies. If there are,=20 >>however, more binding semantics here, then we=20 >>probably won=92t be able to agree on the need for=20 >>solitary or multiple Geolocation headers until=20 >>we agree on what those semantics are. >> >>Jon Peterson >>NeuStar, Inc. >> >> >>On 7/18/10 7:25 PM, "Thomson, Martin"=20 >><Martin.Thomson@andrew.com> wrote: >> >>Hi Jon, >> >>I admit a fair degree of sympathy for Roger=92s=20 >>suggestion. After all, the ability to include=20 >>multiple location =93values=94 in the same SIP=20 >>request is a feature that has existed for many=20 >>years. A number of implementations have come=20 >>to rely on this mechanism; people are building=20 >>and have built solutions based on earlier=20 >>draft, fully aware of the risks in implementing an internet draft. >> >>At some point, it might be necessary to swallow=20 >>any discomfort and recognize that the=20 >>consequences of an imperfect solution are less=20 >>than the consequences of a change of the nature you suggest. >> >>Altering perspective might offer a solution. >> >>The idea that there are multiple items that are=20 >>composited might be counterproductive. In this=20 >>world-view, you have to reconcile a number of=20 >>perspectives. In this, you are absolutely=20 >>correct: doing that at two layers is=20 >>bad. Composition is a hard problem=20 >>already. Moving it into SIP only complicates it further. >> >>The alternative is to imagine a single logical=20 >>resource that represents the location of the=20 >>Target. A location by value is a=20 >>representation of this resource: a=20 >>snapshot. Location by reference offers a means=20 >>for any entity to identify and acquire a view=20 >>of the resource, independent of that=20 >>snapshot. The authority for the resource might=20 >>offer the same representation, or it could=20 >>offer one better suited to the recipient. The=20 >>representation might be updated, it might be=20 >>altered based on an authorization policy, or=20 >>something else (language=20 >>preferences). Regardless of how it is=20 >>represented, it is still the same resource. >> >>In simple terms, you state that the request can=20 >>only include a single _location_. When a=20 >>location value and reference are both included,=20 >>they represent the _same_ location. >> >>This is why I suggested that Content-Location=20 >>be borrowed. In HTTP, Content-Location says -=20 >>if you want to know where this resource really=20 >>lives, here is where you can find it. >> >>Now this might be sheer sophistry, but it might=20 >>offer a way out. The composition problems are left out of SIP. >> >>I can write up a more detailed strawman, but=20 >>for now, I'll just include an example: >> >> INVITE sips:bob@biloxi.example.com SIP/2.0 >> Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4bK74bf9 >> Max-Forwards: 70 >> To: Bob bob@biloxi.example.com> >> From: Alice=20 >>= alice@atlanta.example.com>;tag=3D9fxced76s= l >> Call-ID:=20 >>= <3848276298220188511@atlanta.example.htm>3848276298220188511@atlanta.exampl= e.com >> Geolocation:=20 >> target123@atlanta.example.com> >> ;routing-allowed=3Dno >> Supported: geolocation >> Accept: application/sdp, application/pidf+xml >> CSeq: 31862 INVITE >> Contact: alice@atlanta.example.com> >> Content-Type: multipart/mixed; boundary=3Dboundary1 >> Content-Length: ... >> >> --boundary1 >> Content-Type: application/sdp >> >> ...SDP goes here >> >> --boundary1 >> Content-Type: application/pidf+xml >> Content-ID:=20 >> <target123@atlanta.example.com> >> Content-Location:=20 >> pres:alice@example.com?location/XJhbXM6eG1sOm5zOnBpZ >> >> >> ...PIDF-LO document >> --boundary1-- >> >> >>--Martin >> >>---- Original Message ---- >>From: Peterson, Jon=20 >>[mailto:jon.peterson@neustar.biz] >>Sent: Friday, 16 July 2010 4:54 PM >>To: Roger Marshall; Thomson, Martin; James M.=20 >>Polk; sipcore@ietf.org >>Subject: Re: [sipcore] location-conveyance-03 just submitted >> >> >>In the corner case (and I do think it is a=20 >>corner case) where multiple entities are=20 >>contributing different location information to=20 >>a single SIP request, I think we face a=20 >>fundamental architecture choice in this=20 >>mechanism: either it is SIP=92s job to sort out=20 >>how we understand those different locations, or=20 >>it is PIDF=92s job. Traditionally, PIDF=92s=20 >>understanding of different sources of presence=20 >>that provide potentially contradictory=20 >>information relies on the presence data model=20 >>(RFC4479), which is designed to reconcile=20 >>conditions like the one where my mobile phone=20 >>thinks I am available but my desktop thinks I=92m=20 >>offline. The presence data model moreover=20 >>differentiates between users, services and=20 >>devices in a way that is useful and apparently=20 >>applicable to location information. I am not=20 >>eager to try to replicate this in SIP headers,=20 >>including by inserting multiple such headers,=20 >>putting in markup that tries to explain the=20 >>=93source=94 of location information in SIP=20 >>headers, and so on. SIP=92s job should be to=20 >>convey the location object =96 fundamentally, the=20 >>further we diverge from =93conveyance=94 and enter=20 >>into the realm of =93integration,=94 the less comfortable I get. >> >>I understand that the subsequent use case where=20 >>there are different sources of location=20 >>information, some of which are LbrV and some of=20 >>which are LbyR, looks like a hairy one. This=20 >>is, however, a corner case of a corner case. I=20 >>really do not feel comfortable justifying the=20 >>allowance of multiple location headers in SIP=20 >>pointing to different presence objects (as=20 >>opposed to following the presence data model)=20 >>to carry the 0, 1 or 2 different locations due=20 >>to a corner case of a corner case. As I said in=20 >>my previous mail to Martin, I=92m not really sure=20 >>I even understand the requirements for an=20 >>intermediary to evaluate and reject LbyR, nor=20 >>what the best way is for presence from these=20 >>dynamic sources to be composed. If we were to=20 >>investigate the right way for presence from=20 >>those source to be composed, it might very well=20 >>be that it is the responsibility of the=20 >>compositor to insert an LbyR into the SIP=20 >>request (into the Geolocation header), and to=20 >>poll and compose a coherent PIDF document from=20 >>its dynamic and static sources =96 that is=20 >>probably the approach that most closely=20 >>parallels the traditional approaches to=20 >>presence. But we haven=92t even begun to explore=20 >>this yet. No one insisting that there will be=20 >>=93empty=94 PIDF documents just containing=20 >>references to external PIDF documents or=20 >>something. Something along those lines is one=20 >>approach of many that we would consider if we=20 >>tried to figure out how to address this in=20 >>PIDF. The question we need to decide, as I said=20 >>above, is the architecture one =96 is SIP=92s job=20 >>to convey PIDF documents, or to compose them? >> >>Jon Peterson >>NeuStar, Inc. >> >>=85 >> >>_______________________________________________ >>sipcore mailing list >>sipcore@ietf.org >>https://www.ietf.org/mailman/listinfo/sipcore From jmpolk@cisco.com Mon Jul 19 18:56:06 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFF1A3A6BE3 for ; Mon, 19 Jul 2010 18:56:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.431 X-Spam-Level: X-Spam-Status: No, score=-10.431 tagged_above=-999 required=5 tests=[AWL=0.168, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id J5C0drbuXoVy for ; Mon, 19 Jul 2010 18:56:05 -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 566A43A6BE2 for ; Mon, 19 Jul 2010 18:56:05 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANOeREyrR7H+/2dsb2JhbACfbnGoUJsxhSIEg38 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-1.cisco.com with ESMTP; 20 Jul 2010 01:25:08 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6K1P7sF001390; Tue, 20 Jul 2010 01:25:07 GMT Message-Id: <201007200125.o6K1P7sF001390@sj-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Jul 2010 20:25:06 -0500 To: "Winterbottom, James" , "Richard L. Barnes" , "sipcore@ietf.org" From: "James M. Polk" In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880120E9829412@SISPE7MB1.com mscope.com> References: <5A55A45AE77F5941B18E5457ECAC81880120E9829412@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] Geo URI in location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Jul 2010 01:56:06 -0000 As of now, this would be the first time I've heard that request (for a GEO URI), and there are currently no provisions for this (unless absoluteURI covers it). James At 06:05 PM 7/19/2010, Winterbottom, James wrote: >I want this, and I want to be able to support a CID in the same header. >If we can do that in the same header, then I a more than happy to >restrict the number of geolocation headers to 1. > >Cheers >James > > > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf > > Of Richard L. Barnes > > Sent: Tuesday, 20 July 2010 7:47 AM > > To: sipcore@ietf.org > > Subject: [sipcore] Geo URI in location-conveyance > > > > What do people think about having support for GEO URIs [1] in a > > Geolocation header field? Seems like it would be kind of handy... > > > > [1] > > _______________________________________________ > > 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 jmpolk@cisco.com Mon Jul 19 18:56:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5F4F33A6BE1 for ; Mon, 19 Jul 2010 18:56:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.634 X-Spam-Level: X-Spam-Status: No, score=-9.634 tagged_above=-999 required=5 tests=[AWL=-0.431, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dQW0DL7IxdcI for ; Mon, 19 Jul 2010 18:56: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 029513A6BE8 for ; Mon, 19 Jul 2010 18:56:13 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 20 Jul 2010 01:24:39 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6K1N8PU005489; Tue, 20 Jul 2010 01:23:08 GMT Message-Id: <201007200123.o6K1N8PU005489@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Jul 2010 20:23:07 -0500 To: "Richard L. Barnes" , "Peterson, Jon" From: "James M. Polk" In-Reply-To: <605CEAA0-91F5-4860-A2B6-7E1BAFD3D847@bbn.com> References: <605CEAA0-91F5-4860-A2B6-7E1BAFD3D847@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Roger Marshall , "sipcore@ietf.org" , "Thomson, Martin" Subject: Re: [sipcore] composition or just indirection (was: location-conveyance-03 just 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: Tue, 20 Jul 2010 01:56:13 -0000 Richard Let's not forget the cost of having more than one=20 document in terms of additive bytes in the=20 request. Adding another or =20 element is not that much more data, whereas=20 adding a second or third PIDF would be a lot more. James At 04:44 PM 7/19/2010, Richard L. Barnes wrote: >While it's correct to say that one presence=20 >document describes a single entity, it's not=20 >necessarily true that multiple presence=20 >documents describe multiple=20 >entities. Regardless of how we define the=20 >entity in the session that is the target (IIRC,=20 >earlier versions said something like "the UAC=20 >that initiated the dialogue"), it seems=20 >plausible that different entities processing a=20 >SIP message might have different ideas as to the=20 >location of the target. In this case, it would=20 >seem plausible to have multiple location objects=20 >in a single message, all of which have the=20 >semantic that they're describing the location of=20 >the target (however the target is coupled to the session). > >Speaking more practically, if we accept the=20 >assertion that multiple location values will be=20 >necessary (whether in a single document or not),=20 >then it seems much cleaner to have them in=20 >separate presence documents, with separate CID=20 >URIs. I don't really see any reason for any of=20 >this to call for more than one Geolocation=20 >header, since you can just add more URIs. > > > >On Jul 19, 2010, at 5:29 PM, Peterson, Jon wrote: > >> >>I=92m sure we=92re all going to have to discuss=20 >>this a bit in Maastricht, but there are a=20 >>couple basic points here I think we need to tee=20 >>up. I certainly didn=92t mean to suggest that a=20 >>request can only include a single location=20 >>(i.e., that any contributing piece of location=20 >>information designates the same place, just=20 >>with varying degrees of accuracy or timeliness=20 >>or something). Rather, I believe a presence=20 >>document describes a single entity =96 multiple=20 >>locations come about because various devices=20 >>and services associated with that single entity=20 >>may attribute various locations to the entity. >> >>Getting back to fundamentals, we don=92t need a=20 >>Geolocation header in order to carry location=20 >>in SIP. There are MIME bodies for that=20 >>(including Content-Indirection bodies for LbyR,=20 >>or perhaps Content-Location as you suggest),=20 >>and we can include seventeen different location=20 >>objects if we want to, regardless of whether=20 >>there are zero or one or fifteen Geolocation=20 >>headers. We don=92t need a location conveyance=20 >>specification or a Geolocation header to enable=20 >>that, SIP has always been able to do it, and=20 >>you=92ll still be able to add random MIME bodies=20 >>that contain location information even if there=20 >>is a Geolocation header which does not point to=20 >>them. So what does the Geolocation header and=20 >>location conveyance specification buy us? >> >>I=92ve always naively thought that the=20 >>Geolocation header provides a coupling between=20 >>this particular SIP session and an entity whose=20 >>location is designated by a PIDF document. The=20 >>entity is the geopriv Target, and is probably=20 >>(though not necessarily) related to the party=20 >>identified by the classic From header field of=20 >>the SIP request. The Geolocation header tells=20 >>us that for the purposes of the SIP session=20 >>being negotiated, the location of this Target=20 >>is somehow relevant... the boldest=20 >>interpretation would be that this Target=92s=20 >>location should be considered the source of the=20 >>request. Just attaching location-aware MIME=20 >>bodies without the Geolocation header to SIP=20 >>requests doesn=92t convey the same semantics =96=20 >>those bodies could mean anything, and=20 >>presumably the receiving application would sort through them at its= discretion. >> >>Where I get confused is when I start trying to=20 >>understand what it would mean semantically for=20 >>a SIP session to be coupled with more than one=20 >>Target. Again, I can imagine hypothetically a=20 >>SIP request containing unsorted MIME bodies=20 >>that talk about different Targets to assist=20 >>some specific application that knows how to=20 >>reconcile them, but here I mean using the=20 >>Geolocation header to couple a SIP request with=20 >>location information about different Targets.=20 >>Is there actually a use case/requirement for=20 >>that? If not, and we only want to couple a SIP=20 >>request with one Target, then I fail to see why=20 >>composing location information about the same=20 >>Target into a single PIDF body would be a=20 >>problem. Having location information about the=20 >>same entity fail to be organized in one body=20 >>through RFC4479 wouldn=92t make sense, anyway. >> >>I think if we understand the semantics by which=20 >>the Geolocation header =93couples=94 PIDF with a=20 >>SIP session, then we=92ll better understand all=20 >>of this. If the Geolocation header only exists=20 >>to notify lazy intermediaries that there are=20 >>location-sensitive bodies in the request or=20 >>somewhere out on the net, without implying=20 >>anything about the Target or the relationship=20 >>of those locations to the SIP request, then=20 >>this whole specification is probably more=20 >>trouble than it=92s worth =96 it really wouldn=92t=20 >>provide much incremental value above the basic=20 >>ability of SIP to carry all sorts of bodies,=20 >>including location bodies. If there are,=20 >>however, more binding semantics here, then we=20 >>probably won=92t be able to agree on the need for=20 >>solitary or multiple Geolocation headers until=20 >>we agree on what those semantics are. >> >>Jon Peterson >>NeuStar, Inc. >> >> >>On 7/18/10 7:25 PM, "Thomson, Martin"=20 >><Martin.Thomson@andrew.com> wrote: >> >>Hi Jon, >> >>I admit a fair degree of sympathy for Roger=92s=20 >>suggestion. After all, the ability to include=20 >>multiple location =93values=94 in the same SIP=20 >>request is a feature that has existed for many=20 >>years. A number of implementations have come=20 >>to rely on this mechanism; people are building=20 >>and have built solutions based on earlier=20 >>draft, fully aware of the risks in implementing an internet draft. >> >>At some point, it might be necessary to swallow=20 >>any discomfort and recognize that the=20 >>consequences of an imperfect solution are less=20 >>than the consequences of a change of the nature you suggest. >> >>Altering perspective might offer a solution. >> >>The idea that there are multiple items that are=20 >>composited might be counterproductive. In this=20 >>world-view, you have to reconcile a number of=20 >>perspectives. In this, you are absolutely=20 >>correct: doing that at two layers is=20 >>bad. Composition is a hard problem=20 >>already. Moving it into SIP only complicates it further. >> >>The alternative is to imagine a single logical=20 >>resource that represents the location of the=20 >>Target. A location by value is a=20 >>representation of this resource: a=20 >>snapshot. Location by reference offers a means=20 >>for any entity to identify and acquire a view=20 >>of the resource, independent of that=20 >>snapshot. The authority for the resource might=20 >>offer the same representation, or it could=20 >>offer one better suited to the recipient. The=20 >>representation might be updated, it might be=20 >>altered based on an authorization policy, or=20 >>something else (language=20 >>preferences). Regardless of how it is=20 >>represented, it is still the same resource. >> >>In simple terms, you state that the request can=20 >>only include a single _location_. When a=20 >>location value and reference are both included,=20 >>they represent the _same_ location. >> >>This is why I suggested that Content-Location=20 >>be borrowed. In HTTP, Content-Location says -=20 >>if you want to know where this resource really=20 >>lives, here is where you can find it. >> >>Now this might be sheer sophistry, but it might=20 >>offer a way out. The composition problems are left out of SIP. >> >>I can write up a more detailed strawman, but=20 >>for now, I'll just include an example: >> >> INVITE sips:bob@biloxi.example.com SIP/2.0 >> Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4bK74bf9 >> Max-Forwards: 70 >> To: Bob bob@biloxi.example.com> >> From: Alice=20 >>= alice@atlanta.example.com>;tag=3D9fxced76s= l >> Call-ID:=20 >>= <3848276298220188511@atlanta.example.htm>3848276298220188511@atlanta.exampl= e.com >> Geolocation:=20 >> target123@atlanta.example.com> >> ;routing-allowed=3Dno >> Supported: geolocation >> Accept: application/sdp, application/pidf+xml >> CSeq: 31862 INVITE >> Contact: alice@atlanta.example.com> >> Content-Type: multipart/mixed; boundary=3Dboundary1 >> Content-Length: ... >> >> --boundary1 >> Content-Type: application/sdp >> >> ...SDP goes here >> >> --boundary1 >> Content-Type: application/pidf+xml >> Content-ID:=20 >> <target123@atlanta.example.com> >> Content-Location:=20 >> pres:alice@example.com?location/XJhbXM6eG1sOm5zOnBpZ >> >> >> ...PIDF-LO document >> --boundary1-- >> >> >>--Martin >> >>---- Original Message ---- >>From: Peterson, Jon=20 >>[mailto:jon.peterson@neustar.biz] >>Sent: Friday, 16 July 2010 4:54 PM >>To: Roger Marshall; Thomson, Martin; James M.=20 >>Polk; sipcore@ietf.org >>Subject: Re: [sipcore] location-conveyance-03 just submitted >> >> >>In the corner case (and I do think it is a=20 >>corner case) where multiple entities are=20 >>contributing different location information to=20 >>a single SIP request, I think we face a=20 >>fundamental architecture choice in this=20 >>mechanism: either it is SIP=92s job to sort out=20 >>how we understand those different locations, or=20 >>it is PIDF=92s job. Traditionally, PIDF=92s=20 >>understanding of different sources of presence=20 >>that provide potentially contradictory=20 >>information relies on the presence data model=20 >>(RFC4479), which is designed to reconcile=20 >>conditions like the one where my mobile phone=20 >>thinks I am available but my desktop thinks I=92m=20 >>offline. The presence data model moreover=20 >>differentiates between users, services and=20 >>devices in a way that is useful and apparently=20 >>applicable to location information. I am not=20 >>eager to try to replicate this in SIP headers,=20 >>including by inserting multiple such headers,=20 >>putting in markup that tries to explain the=20 >>=93source=94 of location information in SIP=20 >>headers, and so on. SIP=92s job should be to=20 >>convey the location object =96 fundamentally, the=20 >>further we diverge from =93conveyance=94 and enter=20 >>into the realm of =93integration,=94 the less comfortable I get. >> >>I understand that the subsequent use case where=20 >>there are different sources of location=20 >>information, some of which are LbrV and some of=20 >>which are LbyR, looks like a hairy one. This=20 >>is, however, a corner case of a corner case. I=20 >>really do not feel comfortable justifying the=20 >>allowance of multiple location headers in SIP=20 >>pointing to different presence objects (as=20 >>opposed to following the presence data model)=20 >>to carry the 0, 1 or 2 different locations due=20 >>to a corner case of a corner case. As I said in=20 >>my previous mail to Martin, I=92m not really sure=20 >>I even understand the requirements for an=20 >>intermediary to evaluate and reject LbyR, nor=20 >>what the best way is for presence from these=20 >>dynamic sources to be composed. If we were to=20 >>investigate the right way for presence from=20 >>those source to be composed, it might very well=20 >>be that it is the responsibility of the=20 >>compositor to insert an LbyR into the SIP=20 >>request (into the Geolocation header), and to=20 >>poll and compose a coherent PIDF document from=20 >>its dynamic and static sources =96 that is=20 >>probably the approach that most closely=20 >>parallels the traditional approaches to=20 >>presence. But we haven=92t even begun to explore=20 >>this yet. No one insisting that there will be=20 >>=93empty=94 PIDF documents just containing=20 >>references to external PIDF documents or=20 >>something. Something along those lines is one=20 >>approach of many that we would consider if we=20 >>tried to figure out how to address this in=20 >>PIDF. The question we need to decide, as I said=20 >>above, is the architecture one =96 is SIP=92s job=20 >>to convey PIDF documents, or to compose them? >> >>Jon Peterson >>NeuStar, Inc. >> >>=85 >> >>_______________________________________________ >>sipcore mailing list >>sipcore@ietf.org >>https://www.ietf.org/mailman/listinfo/sipcore From jmpolk@cisco.com Mon Jul 19 18:56:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F41953A6BED for ; Mon, 19 Jul 2010 18:56:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.441 X-Spam-Level: X-Spam-Status: No, score=-10.441 tagged_above=-999 required=5 tests=[AWL=0.158, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1PZt1ARhBK8 for ; Mon, 19 Jul 2010 18:56:20 -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 C9D593A6BE8 for ; Mon, 19 Jul 2010 18:56:19 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 20 Jul 2010 01:26:51 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6K1Qo3n026484; Tue, 20 Jul 2010 01:26:51 GMT Message-Id: <201007200126.o6K1Qo3n026484@sj-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Jul 2010 20:26:49 -0500 To: "Winterbottom, James" , Paul Kyzivat , "James M. Polk" From: "James M. Polk" In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880120E9829415@SISPE7MB1.com mscope.com> References: <20100719081458.77080@gmx.net> <201007191857.o6JIv7in014515@sj-core-1.cisco.com> <2936AA57-EEDC-4B43-BE88-E5BDB5D44C8C@bbn.com> <201007191943.o6JJhIrX004288@sj-core-2.cisco.com> <4C44D2E8.8020904@cisco.com> <5A55A45AE77F5941B18E5457ECAC81880120E9829415@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: "Richard L. Barnes" , Hannes Tschofenig , "sipcore@ietf.org" Subject: Re: [sipcore] Location Conveyance Question: Multiple Location X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Jul 2010 01:56:21 -0000 James I logged your comment from a week ago on this, and Jon also agreed to it. -04 will have this explicitly allowed. James At 06:19 PM 7/19/2010, Winterbottom, James wrote: >By the same token absoluteURI also permits pres:, sip: and sips: URI >schemes, yet these are explicitly called out, presumably because >there is specification work that says how to use them for acquiring >location information. Hannes's comment, and indeed my comment made >nearly a week ago, are simply calling for the inclusion of the http: >and http2: URI schemes to also be included because similar >specification work on how to use these schemes to acquire location >information exists. > >If the argument is that this is covered by the absoluteURI >component, then presumably that is all the ABNF requires, and the >sips: sips: and pres: URI schemes can also be removed. > >Cheers >James > > > > > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf > > Of Paul Kyzivat > > Sent: Tuesday, 20 July 2010 8:34 AM > > To: James M. Polk > > Cc: Richard L. Barnes; Hannes Tschofenig; sipcore@ietf.org > > Subject: Re: [sipcore] Location Conveyance Question: Multiple Location > > > > > > > > James M. Polk wrote: > > > At 02:12 PM 7/19/2010, Richard L. Barnes wrote: > > >> I might be mistaken, but it looks to me as if the header ABNF would > > >> allow the following: > > >> > > >> Geolocation: > , >> foobar> > > > > The ABNF permits that (by virtue of allowing absoluteURI, http: is > > permitted), but the text does not: > > > > The Geolocation header field has zero or one locationValue, but > > MUST NOT contain more than one locationValue. > > > > >sipcore From jmpolk@cisco.com Mon Jul 19 18:57:33 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E42F83A69BE for ; Mon, 19 Jul 2010 18:57:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.751 X-Spam-Level: X-Spam-Status: No, score=-9.751 tagged_above=-999 required=5 tests=[AWL=-0.548, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4VrgBKZ-O36e for ; Mon, 19 Jul 2010 18:57:31 -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 771DF3A69A8 for ; Mon, 19 Jul 2010 18:57:29 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AosFAIefREyrR7Ht/2dsb2JhbACfFlhxqE+bNIJagkgEg38 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 20 Jul 2010 01:32:11 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6K1WAN6029814; Tue, 20 Jul 2010 01:32:10 GMT Message-Id: <201007200132.o6K1WAN6029814@sj-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Jul 2010 20:32:09 -0500 To: "Richard L. Barnes" , "Peterson, Jon" From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Roger Marshall , "sipcore@ietf.org" , "Thomson, Martin" Subject: Re: [sipcore] composition or just indirection (was: location-conveyance-03 just 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: Tue, 20 Jul 2010 01:57:34 -0000 All If we go back to identifying who inserted a=20 location, we have to go back to the "inserter=3D"=20 and "inserted-by=3D" parameters, which bring back=20 the "node-id", "host-id" and probably the=20 "used-for-routing" paramters... this certainly=20 makes things easier for phonebcp, but no one=20 else ;-) because it'll probably increase the=20 page count of this ID by ~10 pages. Why are we suggesting not having the UAC send the=20 composed location information? That's just increasing complexity several fold. James At 07:04 PM 7/19/2010, Richard L. Barnes wrote: >Certainly agree that there is one Target, so the=20 >question is simply how to represent multiple=20 >estimates of that target's location. > >Your analysis is correct that carrying separate=20 >location objects effectively gives the LR the=20 >responsibility for compositing, but I'm not sure=20 >that's a bad thing. The LR has an idea of what=20 >application it's using the location information=20 >for -- something an intermediary probably lacks=20 >-- which can inform how it chooses or combines location values. > >The question then becomes how to provide the LR=20 >with sufficient information to make these=20 >decisions. Beyond information in the location=20 >object itself (e.g., accuracy or privacy=20 >settings), it seems like the main data of interest would be: >-- How the location information was determined, and possibly >-- Who inserted the location object >Along these dimensions, there's really no=20 >difference between the one-object and=20 >multiple-object cases. In both cases, the=20 >determination method will be in a tag=20 >inside the element. Neither option=20 >provides much good information about who inserts=20 >a location object -- the primary mechanism in=20 >RFC 4479 is the element (which isn't=20 >really all that helpful), leaving you basically=20 >with preference-ordering in either case (see RFC 5491). > >There are probably also scenarios where the=20 >intermediary knows best, but allowing for=20 >multiple location values would seem to allow for=20 >either possibility: If an intermediary wants to=20 >composite, it can, or it can just tack on what it has. > >So I think the question comes down to two things: >1. Whether you want to allow entities *not* to composite >2. Where you want your preference ordering (URI list or XML) >3. How easy you want it to be to add objects > >Especially given the tidiness of the layering in=20 >the multi-object model (w.r.t. 3), it seems like=20 >allowing multiple objects wins on counts 1 and=20 >3. And on balance, probably point 2 as well,=20 >since you can read the ordering without parsing any XML first. > >--Richard > > > > >On Jul 19, 2010, at 7:19 PM, Peterson, Jon wrote: > >> >>It sounds like you agree that there is one=20 >>Target, at least. I=92m not disagreeing that=20 >>different entities might have different ideas=20 >>about the location of the target; I just don=92t=20 >>see why that entails anything whether they=20 >>should be in different presence documents or=20 >>the same one. Again, this is just a question of=20 >>whether a bald list in a header field value has=20 >>enough syntactic richness to describe the=20 >>relationship between those presence documents,=20 >>or whether we should let RFC4479 do that job.=20 >>All of those crufty parameters that had crept=20 >>into the Geolocation header were symptoms of=20 >>the lack of syntactic richness in that neck of=20 >>the woods, as was the bloat in error codes related to their upkeep. >> >>As to composition, any presence architecture=20 >>that has multiple sources of presence has to=20 >>provide composition somewhere. If (as the=20 >>previous location-conveyance document tacitly=20 >>assumed) we deliver a bunch of separate=20 >>presence documents from different sources all=20 >>talking about the same presentity/Target to a=20 >>watcher (an LR, in geopriv parlance), then the=20 >>responsibility devolves to the LR/watcher to=20 >>effectively perform composition =96 to try to=20 >>understand the documents and how they relate to=20 >>one another in order to derive a useful picture=20 >>of the presentity=92s presence. The problem is,=20 >>the watcher is the least likely entity in the=20 >>architecture to understand how all these bits of information fit together. >> >>Jon Peterson >>NeuStar, Inc. >> >> >>On 7/19/10 2:44 PM, "Richard L. Barnes"=20 >><rbarnes@bbn.com> wrote: >> >>While it's correct to say that one presence=20 >>document describes a single entity, it's not=20 >>necessarily true that multiple presence=20 >>documents describe multiple=20 >>entities. Regardless of how we define the=20 >>entity in the session that is the target (IIRC,=20 >>earlier versions said something like "the UAC=20 >>that initiated the dialogue"), it seems=20 >>plausible that different entities processing a=20 >>SIP message might have different ideas as to=20 >>the location of the target. In this case, it=20 >>would seem plausible to have multiple location=20 >>objects in a single message, all of which have=20 >>the semantic that they're describing the=20 >>location of the target (however the target is coupled to the session). >> >>Speaking more practically, if we accept the=20 >>assertion that multiple location values will be=20 >>necessary (whether in a single document or=20 >>not), then it seems much cleaner to have them=20 >>in separate presence documents, with separate=20 >>CID URIs. I don't really see any reason for=20 >>any of this to call for more than one=20 >>Geolocation header, since you can just add more URIs. >> >> >> >>On Jul 19, 2010, at 5:29 PM, Peterson, Jon wrote: >> >> >> I=92m sure we=92re all going to have to discuss=20 >> this a bit in Maastricht, but there are a=20 >> couple basic points here I think we need to=20 >> tee up. I certainly didn=92t mean to suggest=20 >> that a request can only include a single=20 >> location (i.e., that any contributing piece of=20 >> location information designates the same=20 >> place, just with varying degrees of accuracy=20 >> or timeliness or something). Rather, I believe=20 >> a presence document describes a single entity=20 >> =96 multiple locations come about because=20 >> various devices and services associated with=20 >> that single entity may attribute various locations to the entity. >> >> Getting back to fundamentals, we don=92t need a=20 >> Geolocation header in order to carry location=20 >> in SIP. There are MIME bodies for that=20 >> (including Content-Indirection bodies for=20 >> LbyR, or perhaps Content-Location as you=20 >> suggest), and we can include seventeen=20 >> different location objects if we want to,=20 >> regardless of whether there are zero or one or=20 >> fifteen Geolocation headers. We don=92t need a=20 >> location conveyance specification or a=20 >> Geolocation header to enable that, SIP has=20 >> always been able to do it, and you=92ll still be=20 >> able to add random MIME bodies that contain=20 >> location information even if there is a=20 >> Geolocation header which does not point to=20 >> them. So what does the Geolocation header and=20 >> location conveyance specification buy us? >> >> I=92ve always naively thought that the=20 >> Geolocation header provides a coupling between=20 >> this particular SIP session and an entity=20 >> whose location is designated by a PIDF=20 >> document. The entity is the geopriv Target,=20 >> and is probably (though not necessarily)=20 >> related to the party identified by the classic=20 >> From header field of the SIP request. The=20 >> Geolocation header tells us that for the=20 >> purposes of the SIP session being negotiated,=20 >> the location of this Target is somehow=20 >> relevant... the boldest interpretation would=20 >> be that this Target=92s location should be=20 >> considered the source of the request. Just=20 >> attaching location-aware MIME bodies without=20 >> the Geolocation header to SIP requests doesn=92t=20 >> convey the same semantics =96 those bodies could=20 >> mean anything, and presumably the receiving=20 >> application would sort through them at its discretion. >> >> Where I get confused is when I start trying=20 >> to understand what it would mean semantically=20 >> for a SIP session to be coupled with more than=20 >> one Target. Again, I can imagine=20 >> hypothetically a SIP request containing=20 >> unsorted MIME bodies that talk about different=20 >> Targets to assist some specific application=20 >> that knows how to reconcile them, but here I=20 >> mean using the Geolocation header to couple a=20 >> SIP request with location information about=20 >> different Targets. Is there actually a use=20 >> case/requirement for that? If not, and we only=20 >> want to couple a SIP request with one Target,=20 >> then I fail to see why composing location=20 >> information about the same Target into a=20 >> single PIDF body would be a problem. Having=20 >> location information about the same entity=20 >> fail to be organized in one body through RFC4479 wouldn=92t make sense,= anyway. >> >> I think if we understand the semantics by=20 >> which the Geolocation header =93couples=94 PIDF=20 >> with a SIP session, then we=92ll better=20 >> understand all of this. If the Geolocation=20 >> header only exists to notify lazy=20 >> intermediaries that there are=20 >> location-sensitive bodies in the request or=20 >> somewhere out on the net, without implying=20 >> anything about the Target or the relationship=20 >> of those locations to the SIP request, then=20 >> this whole specification is probably more=20 >> trouble than it=92s worth =96 it really wouldn=92t=20 >> provide much incremental value above the basic=20 >> ability of SIP to carry all sorts of bodies,=20 >> including location bodies. If there are,=20 >> however, more binding semantics here, then we=20 >> probably won=92t be able to agree on the need=20 >> for solitary or multiple Geolocation headers=20 >> until we agree on what those semantics are. >> >> Jon Peterson >> NeuStar, Inc. >> >> >> On 7/18/10 7:25 PM, "Thomson, Martin"=20 >> <Martin.Thomson@andrew.com> wrote: >> >> >>Hi Jon, >> >> I admit a fair degree of sympathy for Roger=92s=20 >> suggestion. After all, the ability to include=20 >> multiple location =93values=94 in the same SIP=20 >> request is a feature that has existed for many=20 >> years. A number of implementations have come=20 >> to rely on this mechanism; people are building=20 >> and have built solutions based on earlier=20 >> draft, fully aware of the risks in implementing an internet draft. >> >> At some point, it might be necessary to=20 >> swallow any discomfort and recognize that the=20 >> consequences of an imperfect solution are less=20 >> than the consequences of a change of the nature you suggest. >> >> Altering perspective might offer a solution. >> >> The idea that there are multiple items that=20 >> are composited might be counterproductive. In=20 >> this world-view, you have to reconcile a=20 >> number of perspectives. In this, you are=20 >> absolutely correct: doing that at two layers=20 >> is bad. Composition is a hard problem=20 >> already. Moving it into SIP only complicates it further. >> >> The alternative is to imagine a single=20 >> logical resource that represents the location=20 >> of the Target. A location by value is a=20 >> representation of this resource: a=20 >> snapshot. Location by reference offers a=20 >> means for any entity to identify and acquire a=20 >> view of the resource, independent of that=20 >> snapshot. The authority for the resource=20 >> might offer the same representation, or it=20 >> could offer one better suited to the=20 >> recipient. The representation might be=20 >> updated, it might be altered based on an=20 >> authorization policy, or something else=20 >> (language preferences). Regardless of how it=20 >> is represented, it is still the same resource. >> >> In simple terms, you state that the request=20 >> can only include a single _location_. When a=20 >> location value and reference are both=20 >> included, they represent the _same_ location. >> >> This is why I suggested that Content-Location=20 >> be borrowed. In HTTP, Content-Location says -=20 >> if you want to know where this resource really=20 >> lives, here is where you can find it. >> >> Now this might be sheer sophistry, but it=20 >> might offer a way out. The composition problems are left out of SIP. >> >> I can write up a more detailed strawman, but=20 >> for now, I'll just include an example: >> >> INVITE sips:bob@biloxi.example.com SIP/2.0 >> Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4bK74bf9 >> Max-Forwards: 70 >> To: Bob bob@biloxi.example.com> >> From: Alice=20 >>= alice@atlanta.example.com>;tag=3D9fxced76s= l >> Call-ID:=20 >>= <3848276298220188511@atlanta.example.htm>3848276298220188511@atlanta.exampl= e.com >> Geolocation:=20 >> target123@atlanta.example.com> >> ;routing-allowed=3Dno >> Supported: geolocation >> Accept: application/sdp, application/pidf+xml >> CSeq: 31862 INVITE >> Contact: alice@atlanta.example.com> >> Content-Type: multipart/mixed; boundary=3Dboundary1 >> Content-Length: ... >> >> --boundary1 >> Content-Type: application/sdp >> >> ...SDP goes here >> >> --boundary1 >> Content-Type: application/pidf+xml >> Content-ID:=20 >> <target123@atlanta.example.com> >> Content-Location:=20 >> pres:alice@example.com?location/XJhbXM6eG1sOm5zOnBpZ >> >> >> ...PIDF-LO document >> --boundary1-- >> >> >> --Martin >> >> ---- Original Message ---- >> From: Peterson, Jon=20 >> [mailto:jon.peterson@neustar.biz] >> Sent: Friday, 16 July 2010 4:54 PM >> To: Roger Marshall; Thomson, Martin; James M.=20 >> Polk; sipcore@ietf.org >> Subject: Re: [sipcore] location-conveyance-03 just submitted >> >> >> In the corner case (and I do think it is a=20 >> corner case) where multiple entities are=20 >> contributing different location information to=20 >> a single SIP request, I think we face a=20 >> fundamental architecture choice in this=20 >> mechanism: either it is SIP=92s job to sort out=20 >> how we understand those different locations,=20 >> or it is PIDF=92s job. Traditionally, PIDF=92s=20 >> understanding of different sources of presence=20 >> that provide potentially contradictory=20 >> information relies on the presence data model=20 >> (RFC4479), which is designed to reconcile=20 >> conditions like the one where my mobile phone=20 >> thinks I am available but my desktop thinks=20 >> I=92m offline. The presence data model moreover=20 >> differentiates between users, services and=20 >> devices in a way that is useful and apparently=20 >> applicable to location information. I am not=20 >> eager to try to replicate this in SIP headers,=20 >> including by inserting multiple such headers,=20 >> putting in markup that tries to explain the=20 >> =93source=94 of location information in SIP=20 >> headers, and so on. SIP=92s job should be to=20 >> convey the location object =96 fundamentally,=20 >> the further we diverge from =93conveyance=94 and=20 >> enter into the realm of =93integration,=94 the less comfortable I get. >> >> I understand that the subsequent use case=20 >> where there are different sources of location=20 >> information, some of which are LbrV and some=20 >> of which are LbyR, looks like a hairy one.=20 >> This is, however, a corner case of a corner=20 >> case. I really do not feel comfortable=20 >> justifying the allowance of multiple location=20 >> headers in SIP pointing to different presence=20 >> objects (as opposed to following the presence=20 >> data model) to carry the 0, 1 or 2 different=20 >> locations due to a corner case of a corner=20 >> case. As I said in my previous mail to Martin,=20 >> I=92m not really sure I even understand the=20 >> requirements for an intermediary to evaluate=20 >> and reject LbyR, nor what the best way is for=20 >> presence from these dynamic sources to be=20 >> composed. If we were to investigate the right=20 >> way for presence from those source to be=20 >> composed, it might very well be that it is the=20 >> responsibility of the compositor to insert an=20 >> LbyR into the SIP request (into the=20 >> Geolocation header), and to poll and compose a=20 >> coherent PIDF document from its dynamic and=20 >> static sources =96 that is probably the approach=20 >> that most closely parallels the traditional=20 >> approaches to presence. But we haven=92t even=20 >> begun to explore this yet. No one insisting=20 >> that there will be =93empty=94 PIDF documents just=20 >> containing references to external PIDF=20 >> documents or something. Something along those=20 >> lines is one approach of many that we would=20 >> consider if we tried to figure out how to=20 >> address this in PIDF. The question we need to=20 >> decide, as I said above, is the architecture=20 >> one =96 is SIP=92s job to convey PIDF documents, or to compose them? >> >> Jon Peterson >> NeuStar, Inc. >> >> =85 >> >> >> >> >> _______________________________________________ >>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 jon.peterson@neustar.biz Mon Jul 19 19:01:16 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A29443A69BE for ; Mon, 19 Jul 2010 19:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.214 X-Spam-Level: X-Spam-Status: No, score=-102.214 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, HTML_MESSAGE=0.001, SARE_RMML_Stock10=0.13, 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 KeF468pCn8Ih for ; Mon, 19 Jul 2010 19:00:56 -0700 (PDT) Received: from neustar.com (ns7.neustar.com [156.154.24.88]) by core3.amsl.com (Postfix) with ESMTP id 794043A69A8 for ; Mon, 19 Jul 2010 19:00:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=neustar.biz; s=neustarbiz; t=1279591197; x=1594920306; q=dns/txt; h=From:Date:Subject:Message-ID:Content-Language: Content-Type; bh=guQK8cGLp9MhWLU6r5FYl81DQdlCBbsm3AfROrs+9vk=; b=nzIhK0UP51xllwY6x3fNJcbsdi0GYgt+jcGYmbnLNioSkiaZBQIAsK2ja0kCZT P71vfurbfV8y/ZxN1QT0gx1Q== Received: from ([10.31.13.229]) by chihiron2.nc.neustar.com with ESMTP with TLS id 5202415.27439899; Mon, 19 Jul 2010 21:59:55 -0400 Received: from STNTEXCH01.cis.neustar.com ([fe80::31b6:4d09:2ada:e6c0]) by STNTEXCHHT02.cis.neustar.com ([::1]) with mapi; Mon, 19 Jul 2010 21:59:54 -0400 From: "Peterson, Jon" To: "Richard L. Barnes" Date: Mon, 19 Jul 2010 21:59:51 -0400 Thread-Topic: [sipcore] composition or just indirection (was: location-conveyance-03 just submitted) Thread-Index: Acsnnz1rOt6SZnZ6Rry1n95UKcMMsgAD//Mj Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US x-ems-proccessed: R64IxjzeHPwwd+efoj3ZcA== x-ems-stamp: ZTAXcHmQh8MBkd1nOtTnnA== Content-Type: multipart/alternative; boundary="_000_C86A512741D91jonpetersonneustarbiz_" MIME-Version: 1.0 Cc: Roger Marshall , "sipcore@ietf.org" , "Thomson, Martin" Subject: Re: [sipcore] composition or just indirection (was: location-conveyance-03 just 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: Tue, 20 Jul 2010 02:01:17 -0000 --_000_C86A512741D91jonpetersonneustarbiz_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable If the answer is "you know what, just throw all these unconnected bodies ov= er the wall at the LR, it will understand what to do," then can you explain= to me what this Geolocation header does for us again? We can already do th= at without any new headers. As I've been reading through this thread, I've been mentally substituting "= SDP" for "location information," and indeed, while we could just say "throw= three SDP bodies - two of which were added by intermediaries - in the sam= e request at the UAS, and it'll have some application-specific way of under= standing how to reconcile them," I think that's a bad plan for a number of = reasons. Intermediaries who refuse to allow the MIME portion of a SIP reque= st created by the UAC to pass without modification should have the responsi= bility to make the request comprehensible to the UAS (and they should have = to get the buy-in of the UAC in some fashion as well). Fortunately, I at least believe that intermediaries who want to add LI to r= equests that already contain previously added LI will be far more rare than= intermediaries who want to tinker with SDP in transit. In most normal arch= itecture, I imagine that either the UAC will supply location or an intermed= iary will - the case where both happens means, necessarily, that an interme= diary doesn't like what the UAC has put in, but the intermediary doesn't di= slike it enough to enforce its removal from the request. Honestly, how can = that be a common case? Why would an intermediary even want to impose that c= omplexity of interpretation on the UAS? Jon Peterson NeuStar, Inc. On 7/19/10 5:04 PM, "Richard L. Barnes" wrote: Certainly agree that there is one Target, so the question is simply how to = represent multiple estimates of that target's location. Your analysis is correct that carrying separate location objects effectivel= y gives the LR the responsibility for compositing, but I'm not sure that's = a bad thing. The LR has an idea of what application it's using the locatio= n information for -- something an intermediary probably lacks -- which can = inform how it chooses or combines location values. The question then becomes how to provide the LR with sufficient information= to make these decisions. Beyond information in the location object itself= (e.g., accuracy or privacy settings), it seems like the main data of inter= est would be: -- How the location information was determined, and possibly -- Who inserted the location object Along these dimensions, there's really no difference between the one-object= and multiple-object cases. In both cases, the determination method will b= e in a tag inside the element. Neither option provides= much good information about who inserts a location object -- the primary m= echanism in RFC 4479 is the element (which isn't really all that h= elpful), leaving you basically with preference-ordering in either case (see= RFC 5491). There are probably also scenarios where the intermediary knows best, but al= lowing for multiple location values would seem to allow for either possibil= ity: If an intermediary wants to composite, it can, or it can just tack on = what it has. So I think the question comes down to two things: 1. Whether you want to allow entities *not* to composite 2. Where you want your preference ordering (URI list or XML) 3. How easy you want it to be to add objects Especially given the tidiness of the layering in the multi-object model (w.= r.t. 3), it seems like allowing multiple objects wins on counts 1 and 3. A= nd on balance, probably point 2 as well, since you can read the ordering wi= thout parsing any XML first. --Richard On Jul 19, 2010, at 7:19 PM, Peterson, Jon wrote: It sounds like you agree that there is one Target, at least. I'm not disag= reeing that different entities might have different ideas about the locatio= n of the target; I just don't see why that entails anything whether they sh= ould be in different presence documents or the same one. Again, this is jus= t a question of whether a bald list in a header field value has enough synt= actic richness to describe the relationship between those presence document= s, or whether we should let RFC4479 do that job. All of those crufty parame= ters that had crept into the Geolocation header were symptoms of the lack o= f syntactic richness in that neck of the woods, as was the bloat in error c= odes related to their upkeep. As to composition, any presence architecture that has multiple sources of = presence has to provide composition somewhere. If (as the previous location= -conveyance document tacitly assumed) we deliver a bunch of separate presen= ce documents from different sources all talking about the same presentity/T= arget to a watcher (an LR, in geopriv parlance), then the responsibility de= volves to the LR/watcher to effectively perform composition - to try to und= erstand the documents and how they relate to one another in order to derive= a useful picture of the presentity's presence. The problem is, the watcher= is the least likely entity in the architecture to understand how all these= bits of information fit together. Jon Peterson NeuStar, Inc. On 7/19/10 2:44 PM, "Richard L. Barnes" wrote: While it's correct to say that one presence document describes a single ent= ity, it's not necessarily true that multiple presence documents describe mu= ltiple entities. Regardless of how we define the entity in the session tha= t is the target (IIRC, earlier versions said something like "the UAC that i= nitiated the dialogue"), it seems plausible that different entities process= ing a SIP message might have different ideas as to the location of the targ= et. In this case, it would seem plausible to have multiple location object= s in a single message, all of which have the semantic that they're describi= ng the location of the target (however the target is coupled to the session= ). Speaking more practically, if we accept the assertion that multiple locati= on values will be necessary (whether in a single document or not), then it = seems much cleaner to have them in separate presence documents, with separa= te CID URIs. I don't really see any reason for any of this to call for mor= e than one Geolocation header, since you can just add more URIs. On Jul 19, 2010, at 5:29 PM, Peterson, Jon wrote: I'm sure we're all going to have to discuss this a bit in Maastricht, but= there are a couple basic points here I think we need to tee up. I certainl= y didn't mean to suggest that a request can only include a single location = (i.e., that any contributing piece of location information designates the s= ame place, just with varying degrees of accuracy or timeliness or something= ). Rather, I believe a presence document describes a single entity - multip= le locations come about because various devices and services associated wit= h that single entity may attribute various locations to the entity. Getting back to fundamentals, we don't need a Geolocation header in order= to carry location in SIP. There are MIME bodies for that (including Conten= t-Indirection bodies for LbyR, or perhaps Content-Location as you suggest),= and we can include seventeen different location objects if we want to, reg= ardless of whether there are zero or one or fifteen Geolocation headers. We= don't need a location conveyance specification or a Geolocation header to = enable that, SIP has always been able to do it, and you'll still be able to= add random MIME bodies that contain location information even if there is = a Geolocation header which does not point to them. So what does the Geoloca= tion header and location conveyance specification buy us? I've always naively thought that the Geolocation header provides a coupli= ng between this particular SIP session and an entity whose location is desi= gnated by a PIDF document. The entity is the geopriv Target, and is probabl= y (though not necessarily) related to the party identified by the classic F= rom header field of the SIP request. The Geolocation header tells us that f= or the purposes of the SIP session being negotiated, the location of this T= arget is somehow relevant... the boldest interpretation would be that this = Target's location should be considered the source of the request. Just atta= ching location-aware MIME bodies without the Geolocation header to SIP requ= ests doesn't convey the same semantics - those bodies could mean anything, = and presumably the receiving application would sort through them at its dis= cretion. Where I get confused is when I start trying to understand what it would m= ean semantically for a SIP session to be coupled with more than one Target.= Again, I can imagine hypothetically a SIP request containing unsorted MIME= bodies that talk about different Targets to assist some specific applicati= on that knows how to reconcile them, but here I mean using the Geolocation = header to couple a SIP request with location information about different Ta= rgets. Is there actually a use case/requirement for that? If not, and we on= ly want to couple a SIP request with one Target, then I fail to see why com= posing location information about the same Target into a single PIDF body w= ould be a problem. Having location information about the same entity fail t= o be organized in one body through RFC4479 wouldn't make sense, anyway. I think if we understand the semantics by which the Geolocation header "c= ouples" PIDF with a SIP session, then we'll better understand all of this. = If the Geolocation header only exists to notify lazy intermediaries that th= ere are location-sensitive bodies in the request or somewhere out on the ne= t, without implying anything about the Target or the relationship of those = locations to the SIP request, then this whole specification is probably mor= e trouble than it's worth - it really wouldn't provide much incremental val= ue above the basic ability of SIP to carry all sorts of bodies, including l= ocation bodies. If there are, however, more binding semantics here, then we= probably won't be able to agree on the need for solitary or multiple Geolo= cation headers until we agree on what those semantics are. Jon Peterson NeuStar, Inc. On 7/18/10 7:25 PM, "Thomson, Martin" wrote: Hi Jon, I admit a fair degree of sympathy for Roger's suggestion. After all, the= ability to include multiple location "values" in the same SIP request is a= feature that has existed for many years. A number of implementations have= come to rely on this mechanism; people are building and have built solutio= ns based on earlier draft, fully aware of the risks in implementing an inte= rnet draft. At some point, it might be necessary to swallow any discomfort and recogn= ize that the consequences of an imperfect solution are less than the conseq= uences of a change of the nature you suggest. Altering perspective might offer a solution. The idea that there are multiple items that are composited might be count= erproductive. In this world-view, you have to reconcile a number of perspe= ctives. In this, you are absolutely correct: doing that at two layers is b= ad. Composition is a hard problem already. Moving it into SIP only compli= cates it further. The alternative is to imagine a single logical resource that represents t= he location of the Target. A location by value is a representation of this= resource: a snapshot. Location by reference offers a means for any entity= to identify and acquire a view of the resource, independent of that snapsh= ot. The authority for the resource might offer the same representation, or= it could offer one better suited to the recipient. The representation mig= ht be updated, it might be altered based on an authorization policy, or som= ething else (language preferences). Regardless of how it is represented, i= t is still the same resource. In simple terms, you state that the request can only include a single _lo= cation_. When a location value and reference are both included, they repre= sent the _same_ location. This is why I suggested that Content-Location be borrowed. In HTTP, Cont= ent-Location says - if you want to know where this resource really lives, h= ere is where you can find it. Now this might be sheer sophistry, but it might offer a way out. The com= position problems are left out of SIP. I can write up a more detailed strawman, but for now, I'll just include a= n example: INVITE sips:bob@biloxi.example.com SIP/2.0 Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4bK74bf9 Max-Forwards: 70 To: Bob From: Alice ;tag=3D9fxced76sl Call-ID: 3848276298220188511@atlanta.example.com Geolocation: ;routing-allowed=3Dno Supported: geolocation Accept: application/sdp, application/pidf+xml CSeq: 31862 INVITE Contact: Content-Type: multipart/mixed; boundary=3Dboundary1 Content-Length: ... --boundary1 Content-Type: application/sdp ...SDP goes here --boundary1 Content-Type: application/pidf+xml Content-ID: Content-Location: pres:alice@example.com?location/XJhbXM6eG1sOm5zOnBpZ ...PIDF-LO document --boundary1-- --Martin ---- Original Message ---- From: Peterson, Jon [mailto:jon.peterson@neustar.biz] Sent: Friday, 16 July 2010 4:54 PM To: Roger Marshall; Thomson, Martin; James M. Polk; sipcore@ietf.org Subject: Re: [sipcore] location-conveyance-03 just submitted In the corner case (and I do think it is a corner case) where multiple en= tities are contributing different location information to a single SIP requ= est, I think we face a fundamental architecture choice in this mechanism: e= ither it is SIP's job to sort out how we understand those different locatio= ns, or it is PIDF's job. Traditionally, PIDF's understanding of different = sources of presence that provide potentially contradictory information reli= es on the presence data model (RFC4479), which is designed to reconcile con= ditions like the one where my mobile phone thinks I am available but my des= ktop thinks I'm offline. The presence data model moreover differentiates be= tween users, services and devices in a way that is useful and apparently ap= plicable to location information. I am not eager to try to replicate this i= n SIP headers, including by inserting multiple such headers, putting in mar= kup that tries to explain the "source" of location information in SIP heade= rs, and so on. SIP's job should be to convey the location object - fundamen= tally, the further we diverge from "conveyance" and enter into the realm of= "integration," the less comfortable I get. I understand that the subsequent use case where there are different sourc= es of location information, some of which are LbrV and some of which are Lb= yR, looks like a hairy one. This is, however, a corner case of a corner ca= se. I really do not feel comfortable justifying the allowance of multiple l= ocation headers in SIP pointing to different presence objects (as opposed t= o following the presence data model) to carry the 0, 1 or 2 different locat= ions due to a corner case of a corner case. As I said in my previous mail t= o Martin, I'm not really sure I even understand the requirements for an int= ermediary to evaluate and reject LbyR, nor what the best way is for presenc= e from these dynamic sources to be composed. If we were to investigate the = right way for presence from those source to be composed, it might very well= be that it is the responsibility of the compositor to insert an LbyR into = the SIP request (into the Geolocation header), and to poll and compose a co= herent PIDF document from its dynamic and static sources - that is probably= the approach that most closely parallels the traditional approaches to pre= sence. But we haven't even begun to explore this yet. No one insisting that= there will be "empty" PIDF documents just containing references to externa= l PIDF documents or something. Something along those lines is one approach = of many that we would consider if we tried to figure out how to address thi= s in PIDF. The question we need to decide, as I said above, is the architec= ture one - is SIP's job to convey PIDF documents, or to compose them? Jon Peterson NeuStar, Inc. ... _______________________________________________ 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 --_000_C86A512741D91jonpetersonneustarbiz_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Re: [sipcore] composition or just indirection (was: location-conveya= nce-03 just submitted)
If the answer is “you know what, just throw all these unconnected bod= ies over the wall at the LR, it will understand what to do,” then can= you explain to me what this Geolocation header does for us again? We can a= lready do that without any new headers.

As I’ve been reading through this thread, I’ve been mentally su= bstituting “SDP” for “location information,” and in= deed, while we could just say “throw three SDP bodies  - two of = which were added by intermediaries – in the same request at the UAS, = and it’ll have some application-specific way of understanding how to = reconcile them,” I think that’s a bad plan for a number of reas= ons. Intermediaries who refuse to allow the MIME portion of a SIP request c= reated by the UAC to pass without modification should have the responsibili= ty to make the request comprehensible to the UAS (and they should have to g= et the buy-in of the UAC in some fashion as well).

Fortunately, I at least believe that intermediaries who want to add LI to r= equests that already contain previously added LI will be far more rare than= intermediaries who want to tinker with SDP in transit. In most normal arch= itecture, I imagine that either the UAC will supply location or an intermed= iary will – the case where both happens means, necessarily, that an i= ntermediary doesn’t like what the UAC has put in, but the intermediar= y doesn’t dislike it enough to enforce its removal from the request. = Honestly, how can that be a common case? Why would an intermediary even wan= t to impose that complexity of interpretation on the UAS?

Jon Peterson
NeuStar, Inc.

On 7/19/10 5:04 PM, "Richard L. Barnes" <rbarnes@bbn.com> wrote:

Certainly agree that there is one Target, s= o the question is simply how to represent multiple estimates of that target= 's location.

Your analysis is correct that carrying separate location objects effectivel= y gives the LR the responsibility for compositing, but I'm not sure that's = a bad thing.  The LR has an idea of what application it's using the lo= cation information for -- something an intermediary probably lacks -- which= can inform how it chooses or combines location values.  

The question then becomes how to provide the LR with sufficient information= to make these decisions.  Beyond information in the location object i= tself (e.g., accuracy or privacy settings), it seems like the main data of = interest would be:
-- How the location information was determined, and possibly
-- Who inserted the location object
Along these dimensions, there's really no difference between the one-object= and multiple-object cases.  In both cases, the determination method w= ill be in a <method> tag inside the  <geopriv> element. &n= bsp;Neither option provides much good information about who inserts a locat= ion object -- the primary mechanism in RFC 4479 is the <device> eleme= nt (which isn't really all that helpful), leaving you basically with prefer= ence-ordering in either case (see RFC 5491).  

There are probably also scenarios where the intermediary knows best, but al= lowing for multiple location values would seem to allow for either possibil= ity: If an intermediary wants to composite, it can, or it can just tack on = what it has.

So I think the question comes down to two things:
1. Whether you want to allow entities *not* to composite
2. Where you want your preference ordering (URI list or XML)
3. How easy you want it to be to add objects

Especially given the tidiness of the layering in the multi-object model (w.= r.t. 3), it seems like allowing multiple objects wins on counts 1 and 3. &n= bsp;And on balance, probably point 2 as well, since you can read the orderi= ng without parsing any XML first.

--Richard




On Jul 19, 2010, at 7:19 PM, Peterson, Jon wrote:


 It sounds like you agree that there is one Target, at least. I’= m not disagreeing that different entities might have different ideas about = the location of the target; I just don’t see why that entails anythin= g whether they should be in different presence documents or the same one. A= gain, this is just a question of whether a bald list in a header field valu= e has enough syntactic richness to describe the relationship between those = presence documents, or whether we should let RFC4479 do that job. All of th= ose crufty parameters that had crept into the Geolocation header were sympt= oms of the lack of syntactic richness in that neck of the woods, as was the= bloat in error codes related to their upkeep.
 
 As to composition, any presence architecture that has multiple source= s of presence has to provide composition somewhere. If (as the previous loc= ation-conveyance document tacitly assumed) we deliver a bunch of separate p= resence documents from different sources all talking about the same present= ity/Target to a watcher (an LR, in geopriv parlance), then the responsibili= ty devolves to the LR/watcher to effectively perform composition – to= try to understand the documents and how they relate to one another in orde= r to derive a useful picture of the presentity’s presence. The proble= m is, the watcher is the least likely entity in the architecture to underst= and how all these bits of information fit together.
 
 Jon Peterson
 NeuStar, Inc.
 
 
 On 7/19/10 2:44 PM, "Richard L. Barnes" <rbarnes@bbn.com> wrote:
 
 
While it's correct to say that one presence= document describes a single entity, it's not necessarily true that multipl= e presence documents describe multiple entities.  Regardless of how we= define the entity in the session that is the target (IIRC, earlier version= s said something like "the UAC that initiated the dialogue"), it = seems plausible that different entities processing a SIP message might have= different ideas as to the location of the target.  In this case, it w= ould seem plausible to have multiple location objects in a single message, = all of which have the semantic that they're describing the location of the = target (however the target is coupled to the session).
 
 Speaking more practically, if we accept the assertion that multiple l= ocation values will be necessary (whether in a single document or not), the= n it seems much cleaner to have them in separate presence documents, with s= eparate CID URIs.  I don't really see any reason for any of this to ca= ll for more than one Geolocation header, since you can just add more URIs.<= BR>  
 
 
 On Jul 19, 2010, at 5:29 PM, Peterson, Jon wrote:
 
 

  I’m sure we’re all going to have to discuss this a = bit in Maastricht, but there are a couple basic points here I think we need= to tee up. I certainly didn’t mean to suggest that a request can onl= y include a single location (i.e., that any contributing piece of location = information designates the same place, just with varying degrees of accurac= y or timeliness or something). Rather, I believe a presence document descri= bes a single entity – multiple locations come about because various d= evices and services associated with that single entity may attribute variou= s locations to the entity.
  
  Getting back to fundamentals, we don’t need a Geolocation= header in order to carry location in SIP. There are MIME bodies for that (= including Content-Indirection bodies for LbyR, or perhaps Content-Location = as you suggest), and we can include seventeen different location objects if= we want to, regardless of whether there are zero or one or fifteen Geoloca= tion headers. We don’t need a location conveyance specification or a = Geolocation header to enable that, SIP has always been able to do it, and y= ou’ll still be able to add random MIME bodies that contain location i= nformation even if there is a Geolocation header which does not point to th= em. So what does the Geolocation header and location conveyance specificati= on buy us?
  
  I’ve always naively thought that the Geolocation header p= rovides a coupling between this particular SIP session and an entity whose = location is designated by a PIDF document. The entity is the geopriv Target= , and is probably (though not necessarily) related to the party identified = by the classic From header field of the SIP request. The Geolocation header= tells us that for the purposes of the SIP session being negotiated, the lo= cation of this Target is somehow relevant... the boldest interpretation wou= ld be that this Target’s location should be considered the source of = the request. Just attaching location-aware MIME bodies without the Geolocat= ion header to SIP requests doesn’t convey the same semantics – = those bodies could mean anything, and presumably the receiving application = would sort through them at its discretion.
  
  Where I get confused is when I start trying to understand what = it would mean semantically for a SIP session to be coupled with more than o= ne Target. Again, I can imagine hypothetically a SIP request containing uns= orted MIME bodies that talk about different Targets to assist some specific= application that knows how to reconcile them, but here I mean using the Ge= olocation header to couple a SIP request with location information about di= fferent Targets. Is there actually a use case/requirement for that? If not,= and we only want to couple a SIP request with one Target, then I fail to s= ee why composing location information about the same Target into a single P= IDF body would be a problem. Having location information about the same ent= ity fail to be organized in one body through RFC4479 wouldn’t make se= nse, anyway.
  
  I think if we understand the semantics by which the Geolocation= header “couples” PIDF with a SIP session, then we’ll bet= ter understand all of this. If the Geolocation header only exists to notify= lazy intermediaries that there are location-sensitive bodies in the reques= t or somewhere out on the net, without implying anything about the Target o= r the relationship of those locations to the SIP request, then this whole s= pecification is probably more trouble than it’s worth – it real= ly wouldn’t provide much incremental value above the basic ability of= SIP to carry all sorts of bodies, including location bodies. If there are,= however, more binding semantics here, then we probably won’t be able= to agree on the need for solitary or multiple Geolocation headers until we= agree on what those semantics are.
  
  Jon Peterson
  NeuStar, Inc.
  
  
  On 7/18/10 7:25 PM, "Thomson, Martin" <Martin.Thomson@andrew.com> wrote:
  
  
 
Hi Jon,
  
  I admit a fair degree of sympathy for Roger’s suggestion.=  After all, the ability to include multiple location “values= 221; in the same SIP request is a feature that has existed for many years. =  A number of implementations have come to rely on this mechanism; peop= le are building and have built solutions based on earlier draft, fully awar= e of the risks in implementing an internet draft.
  
  At some point, it might be necessary to swallow any discomfort = and recognize that the consequences of an imperfect solution are less than = the consequences of a change of the nature you suggest.
  
  Altering perspective might offer a solution.
  
  The idea that there are multiple items that are composited migh= t be counterproductive.  In this world-view, you have to reconcile a n= umber of perspectives.  In this, you are absolutely correct: doing tha= t at two layers is bad.  Composition is a hard problem already.  = Moving it into SIP only complicates it further.
  
  The alternative is to imagine a single logical resource that re= presents the location of the Target.  A location by value is a represe= ntation of this resource: a snapshot.  Location by reference offers a = means for any entity to identify and acquire a view of the resource, indepe= ndent of that snapshot.  The authority for the resource might offer th= e same representation, or it could offer one better suited to the recipient= .  The representation might be updated, it might be altered based on a= n authorization policy, or something else (language preferences).  Reg= ardless of how it is represented, it is still the same resource.
  
  In simple terms, you state that the request can only include a = single _location_.  When a location value and reference are both inclu= ded, they represent the _same_ location.
  
  This is why I suggested that Content-Location be borrowed. &nbs= p;In HTTP, Content-Location says - if you want to know where this resource = really lives, here is where you can find it.
  
  Now this might be sheer sophistry, but it might offer a way out= .  The composition problems are left out of SIP.
  
  I can write up a more detailed strawman, but for now, I'll just= include an example:
  
     INVITE sips:bob@biloxi.example.com SIP/2.0
     Via: SIPS/2.0/TLS pc33.atlanta.example.com;br= anch=3Dz9hG4bK74bf9
     Max-Forwards: 70
     To: Bob <sips:bob@biloxi.example.com>
     From: Alice <sips:alice@atlanta.example.com>;tag=3D9fxced76sl
     Call-ID: 3848276298220188511@atlanta.example.com
     Geolocation: <cid:target123@atlanta.example.com>
       ;routing-allowed=3Dno
     Supported: geolocation
     Accept: application/sdp, application/pidf+xml=
     CSeq: 31862 INVITE
     Contact: <sips:alice@atlanta.example.com>
     Content-Type: multipart/mixed; boundary=3Dbou= ndary1
     Content-Length: ...
  
     --boundary1
     Content-Type: application/sdp
  
     ...SDP goes here
  
     --boundary1
     Content-Type: application/pidf+xml
     Content-ID: <target123@atlanta.example.com>
     Content-Location: pres:alice@example.com?location/XJhbXM6eG1= sOm5zOnBpZ
  
     <?xml version=3D"1.0"?>
     ...PIDF-LO document
     --boundary1--
  
  
  --Martin
  
  ---- Original Message ----
  From: Peterson, Jon [mailto:jon.peterson@neustar.biz]
  Sent: Friday, 16 July 2010 4:54 PM
  To: Roger Marshall; Thomson, Martin; James M. Polk; sipcore@ietf.org
  Subject: Re: [sipcore] location-conveyance-03 just submitted   
  
  In the corner case (and I do think it is a corner case) where m= ultiple entities are contributing different location information to a singl= e SIP request, I think we face a fundamental architecture choice in this me= chanism: either it is SIP’s job to sort out how we understand those d= ifferent locations, or it is PIDF’s job.  Traditionally, PIDF= 217;s understanding of different sources of presence that provide potential= ly contradictory information relies on the presence data model (RFC4479), w= hich is designed to reconcile conditions like the one where my mobile phone= thinks I am available but my desktop thinks I’m offline. The presenc= e data model moreover differentiates between users, services and devices in= a way that is useful and apparently applicable to location information. I = am not eager to try to replicate this in SIP headers, including by insertin= g multiple such headers, putting in markup that tries to explain the “= ;source” of location information in SIP headers, and so on. SIP’= ;s job should be to convey the location object – fundamentally, the f= urther we diverge from “conveyance” and enter into the realm of= “integration,” the less comfortable I get.
  
  I understand that the subsequent use case where there are diffe= rent sources of location information, some of which are LbrV and some of wh= ich are LbyR, looks like a  hairy one. This is, however, a corner case= of a corner case. I really do not feel comfortable justifying the allowanc= e of multiple location headers in SIP pointing to different presence object= s (as opposed to following the presence data model) to carry the 0, 1 or 2 = different locations due to a corner case of a corner case. As I said in my = previous mail to Martin, I’m not really sure I even understand the re= quirements for an intermediary to evaluate and reject LbyR, nor what the be= st way is for presence from these dynamic sources to be composed. If we wer= e to investigate the right way for presence from those source to be compose= d, it might very well be that it is the responsibility of the compositor to= insert an LbyR into the SIP request (into the Geolocation header), and to = poll and compose a coherent PIDF document from its dynamic and static sourc= es – that is probably the approach that most closely parallels the tr= aditional approaches to presence. But we haven’t even begun to explor= e this yet. No one insisting that there will be “empty” PIDF do= cuments just containing references to external PIDF documents or something.= Something along those lines is one approach of many that we would consider= if we tried to figure out how to address this in PIDF. The question we nee= d to decide, as I said above, is the architecture one – is SIP’= s job to convey PIDF documents, or to compose them?
  
  Jon Peterson
  NeuStar, Inc.
  
  …
  
  
 
sipcore@ietf.org
 https://www= .ietf.org/mailman/listinfo/sipcore
 
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore
); Mon, 19 Jul 2010 21:18:02 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 19 Jul 2010 21:18:01 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 20 Jul 2010 10:17:59 +0800 From: "Winterbottom, James" To: "James M. Polk" , Paul Kyzivat Date: Tue, 20 Jul 2010 10:17:57 +0800 Thread-Topic: [sipcore] Location Conveyance Question: Multiple Location Thread-Index: Acsnrsw9C9jFzJlQRGeDMgnnMfK4QAAAvWBQ Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120E982945C@SISPE7MB1.commscope.com> References: <20100719081458.77080@gmx.net> <201007191857.o6JIv7in014515@sj-core-1.cisco.com> <2936AA57-EEDC-4B43-BE88-E5BDB5D44C8C@bbn.com> <201007191943.o6JJhIrX004288@sj-core-2.cisco.com> <4C44D2E8.8020904@cisco.com> <5A55A45AE77F5941B18E5457ECAC81880120E9829415@SISPE7MB1.commscope.com> <201007200126.o6K1Qo3n026484@sj-core-1.cisco.com> In-Reply-To: <201007200126.o6K1Qo3n026484@sj-core-1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: "Richard L. Barnes" , Hannes Tschofenig , "sipcore@ietf.org" Subject: Re: [sipcore] Location Conveyance Question: Multiple Location X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Jul 2010 02:17:48 -0000 Thanks James James Winterbottom Global Product Manager Andrew GeoLENs IP Location Product Portfolio Email: james.winterbottom@andrew.com Phone: +61-2-42-212938 Mobile: +61-447-773-560 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf > Of James M. Polk > Sent: Tuesday, 20 July 2010 11:27 AM > To: Winterbottom, James; Paul Kyzivat; James M. Polk > Cc: Richard L. Barnes; Hannes Tschofenig; sipcore@ietf.org > Subject: Re: [sipcore] Location Conveyance Question: Multiple Location > > James > > I logged your comment from a week ago on this, and Jon also agreed to it. > > -04 will have this explicitly allowed. > > James > > At 06:19 PM 7/19/2010, Winterbottom, James wrote: > >By the same token absoluteURI also permits pres:, sip: and sips: URI > >schemes, yet these are explicitly called out, presumably because > >there is specification work that says how to use them for acquiring > >location information. Hannes's comment, and indeed my comment made > >nearly a week ago, are simply calling for the inclusion of the http: > >and http2: URI schemes to also be included because similar > >specification work on how to use these schemes to acquire location > >information exists. > > > >If the argument is that this is covered by the absoluteURI > >component, then presumably that is all the ABNF requires, and the > >sips: sips: and pres: URI schemes can also be removed. > > > >Cheers > >James > > > > > > > > > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf > > > Of Paul Kyzivat > > > Sent: Tuesday, 20 July 2010 8:34 AM > > > To: James M. Polk > > > Cc: Richard L. Barnes; Hannes Tschofenig; sipcore@ietf.org > > > Subject: Re: [sipcore] Location Conveyance Question: Multiple Location > > > > > > > > > > > > James M. Polk wrote: > > > > At 02:12 PM 7/19/2010, Richard L. Barnes wrote: > > > >> I might be mistaken, but it looks to me as if the header ABNF would > > > >> allow the following: > > > >> > > > >> Geolocation: > > , >> foobar> > > > > > > The ABNF permits that (by virtue of allowing absoluteURI, http: is > > > permitted), but the text does not: > > > > > > The Geolocation header field has zero or one locationValue, but > > > MUST NOT contain more than one locationValue. > > > > > > > >sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From Martin.Thomson@andrew.com Mon Jul 19 19:17:50 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A9A883A6937 for ; Mon, 19 Jul 2010 19:17:50 -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 k6812zPjzwsA for ; Mon, 19 Jul 2010 19:17:49 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id BD5F93A68F8 for ; Mon, 19 Jul 2010 19:17:49 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:7483 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S28159653Ab0GTCSC (ORCPT ); Mon, 19 Jul 2010 21:18:02 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 19 Jul 2010 21:18:02 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 20 Jul 2010 10:18:01 +0800 From: "Thomson, Martin" To: "James M. Polk" , "Winterbottom, James" , "Richard L. Barnes" , "sipcore@ietf.org" Date: Tue, 20 Jul 2010 10:20:08 +0800 Thread-Topic: [sipcore] Geo URI in location-conveyance Thread-Index: AcsnrsKDxaye5wvaTBCmk0kUJVkv+AAA0O8g Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB773041@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC81880120E9829412@SISPE7MB1.commscope.com> <201007200125.o6K1P7sF001390@sj-core-2.cisco.com> In-Reply-To: <201007200125.o6K1P7sF001390@sj-core-2.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] Geo URI in location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Jul 2010 02:17:50 -0000 SXQncyBub3QgdGhlIGZpcnN0IHRpbWUsIGJ1dCBubyBtYXR0ZXI6IGFic29sdXRlVVJJIGNvdmVy cyBpdC4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzaXBjb3JlLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJl aGFsZiBPZiBKYW1lcyBNLiBQb2xrDQo+IFNlbnQ6IFR1ZXNkYXksIDIwIEp1bHkgMjAxMCAxMToy NSBBTQ0KPiBUbzogV2ludGVyYm90dG9tLCBKYW1lczsgUmljaGFyZCBMLiBCYXJuZXM7IHNpcGNv cmVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzaXBjb3JlXSBHZW8gVVJJIGluIGxvY2F0aW9u LWNvbnZleWFuY2UNCj4gDQo+IEFzIG9mIG5vdywgdGhpcyB3b3VsZCBiZSB0aGUgZmlyc3QgdGlt ZSBJJ3ZlIGhlYXJkIHRoYXQgcmVxdWVzdCAoZm9yDQo+IGEgR0VPIFVSSSksIGFuZCB0aGVyZSBh cmUgY3VycmVudGx5IG5vIHByb3Zpc2lvbnMgZm9yIHRoaXMgKHVubGVzcw0KPiBhYnNvbHV0ZVVS SSBjb3ZlcnMgaXQpLg0KPiANCj4gSmFtZXMNCj4gDQo+IEF0IDA2OjA1IFBNIDcvMTkvMjAxMCwg V2ludGVyYm90dG9tLCBKYW1lcyB3cm90ZToNCj4gPkkgd2FudCB0aGlzLCBhbmQgSSB3YW50IHRv IGJlIGFibGUgdG8gc3VwcG9ydCBhIENJRCBpbiB0aGUgc2FtZQ0KPiBoZWFkZXIuDQo+ID5JZiB3 ZSBjYW4gZG8gdGhhdCBpbiB0aGUgc2FtZSBoZWFkZXIsIHRoZW4gSSBhIG1vcmUgdGhhbiBoYXBw eSB0bw0KPiA+cmVzdHJpY3QgdGhlIG51bWJlciBvZiBnZW9sb2NhdGlvbiBoZWFkZXJzIHRvIDEu DQo+ID4NCj4gPkNoZWVycw0KPiA+SmFtZXMNCj4gPg0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWls dG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYNCj4gPiA+IE9mIFJpY2hh cmQgTC4gQmFybmVzDQo+ID4gPiBTZW50OiBUdWVzZGF5LCAyMCBKdWx5IDIwMTAgNzo0NyBBTQ0K PiA+ID4gVG86IHNpcGNvcmVAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFtzaXBjb3JlXSBHZW8g VVJJIGluIGxvY2F0aW9uLWNvbnZleWFuY2UNCj4gPiA+DQo+ID4gPiBXaGF0IGRvIHBlb3BsZSB0 aGluayBhYm91dCBoYXZpbmcgc3VwcG9ydCBmb3IgR0VPIFVSSXMgWzFdIGluIGENCj4gPiA+IEdl b2xvY2F0aW9uIGhlYWRlciBmaWVsZD8gIFNlZW1zIGxpa2UgaXQgd291bGQgYmUga2luZCBvZiBo YW5keS4uLg0KPiA+ID4NCj4gPiA+IFsxXSA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NTg3MD4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gPiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiA+ID4gc2lwY29yZUBpZXRmLm9yZw0K PiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+ID5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+c2lwY29y ZSBtYWlsaW5nIGxpc3QNCj4gPnNpcGNvcmVAaWV0Zi5vcmcNCj4gPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lw Y29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Np cGNvcmUNCg== From Martin.Thomson@andrew.com Mon Jul 19 20:22:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0A2CE3A6A0A for ; Mon, 19 Jul 2010 20:22:00 -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.039, 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 yW-yRI+u18yO for ; Mon, 19 Jul 2010 20:21:55 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 199FA3A69F8 for ; Mon, 19 Jul 2010 20:21:54 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:18810 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S28161586Ab0GTDWJ (ORCPT ); Mon, 19 Jul 2010 22:22:09 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 19 Jul 2010 22:22:08 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Tue, 20 Jul 2010 11:22:05 +0800 From: "Thomson, Martin" To: "Richard L. Barnes" , "Peterson, Jon" Date: Tue, 20 Jul 2010 11:24:13 +0800 Thread-Topic: [sipcore] composition or just indirection (was: location-conveyance-03 just submitted) Thread-Index: AcsnnxwX5B3PELj6RxC2ZmJyrA0GtQAG3iGA Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB77305F@SISPE7MB1.commscope.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8B0A9FCBB9832F43971E38010638454F03EB77305FSISPE7MB1comm_" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: Roger Marshall , "sipcore@ietf.org" Subject: Re: [sipcore] composition or just indirection (was: location-conveyance-03 just 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: Tue, 20 Jul 2010 03:22:00 -0000 --_000_8B0A9FCBB9832F43971E38010638454F03EB77305FSISPE7MB1comm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB0ZW5kIHRvIGFncmVlIHdpdGggSmFtZXMgKFApIGFib3V0IHRoaXMgLSB5b3Ugc2VlbSB0byBi ZSBhZHZvY2F0aW5nIGFuIGluY3JlYXNlIGluIHRoZSBudW1iZXIgb2Yg4oCccG9pbnRzIG9mIGFy dGljdWxhdGlvbuKAnS4NCg0KV2hhdCBJIHRoaW5rIEpvbiBpcyBwdXJzdWluZyBpcyBmZXdlciBz dWNoIGNvbXBsaWNhdGlvbnPigKZ3aXRob3V0IHByZXZlbnRpbmcgYW55IG5lY2Vzc2FyeSBmbGV4 aWJpbGl0eS4gIFRoaXMgY2FuIGJlIHRha2VuIHRvbyBmYXIgaW4gZWl0aGVyIGRpcmVjdGlvbi4N Cg0KLS1NYXJ0aW4NCg0KRnJvbTogUmljaGFyZCBMLiBCYXJuZXMgW21haWx0bzpyYmFybmVzQGJi bi5jb21dDQpTZW50OiBUdWVzZGF5LCAyMCBKdWx5IDIwMTAgMTA6MDQgQU0NClRvOiBQZXRlcnNv biwgSm9uDQpDYzogUm9nZXIgTWFyc2hhbGw7IHNpcGNvcmVAaWV0Zi5vcmc7IFRob21zb24sIE1h cnRpbg0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBjb21wb3NpdGlvbiBvciBqdXN0IGluZGlyZWN0 aW9uICh3YXM6IGxvY2F0aW9uLWNvbnZleWFuY2UtMDMganVzdCBzdWJtaXR0ZWQpDQoNCkNlcnRh aW5seSBhZ3JlZSB0aGF0IHRoZXJlIGlzIG9uZSBUYXJnZXQsIHNvIHRoZSBxdWVzdGlvbiBpcyBz aW1wbHkgaG93IHRvIHJlcHJlc2VudCBtdWx0aXBsZSBlc3RpbWF0ZXMgb2YgdGhhdCB0YXJnZXQn cyBsb2NhdGlvbi4NCg0KWW91ciBhbmFseXNpcyBpcyBjb3JyZWN0IHRoYXQgY2Fycnlpbmcgc2Vw YXJhdGUgbG9jYXRpb24gb2JqZWN0cyBlZmZlY3RpdmVseSBnaXZlcyB0aGUgTFIgdGhlIHJlc3Bv bnNpYmlsaXR5IGZvciBjb21wb3NpdGluZywgYnV0IEknbSBub3Qgc3VyZSB0aGF0J3MgYSBiYWQg dGhpbmcuICBUaGUgTFIgaGFzIGFuIGlkZWEgb2Ygd2hhdCBhcHBsaWNhdGlvbiBpdCdzIHVzaW5n IHRoZSBsb2NhdGlvbiBpbmZvcm1hdGlvbiBmb3IgLS0gc29tZXRoaW5nIGFuIGludGVybWVkaWFy eSBwcm9iYWJseSBsYWNrcyAtLSB3aGljaCBjYW4gaW5mb3JtIGhvdyBpdCBjaG9vc2VzIG9yIGNv bWJpbmVzIGxvY2F0aW9uIHZhbHVlcy4NCg0KVGhlIHF1ZXN0aW9uIHRoZW4gYmVjb21lcyBob3cg dG8gcHJvdmlkZSB0aGUgTFIgd2l0aCBzdWZmaWNpZW50IGluZm9ybWF0aW9uIHRvIG1ha2UgdGhl c2UgZGVjaXNpb25zLiAgQmV5b25kIGluZm9ybWF0aW9uIGluIHRoZSBsb2NhdGlvbiBvYmplY3Qg aXRzZWxmIChlLmcuLCBhY2N1cmFjeSBvciBwcml2YWN5IHNldHRpbmdzKSwgaXQgc2VlbXMgbGlr ZSB0aGUgbWFpbiBkYXRhIG9mIGludGVyZXN0IHdvdWxkIGJlOg0KLS0gSG93IHRoZSBsb2NhdGlv biBpbmZvcm1hdGlvbiB3YXMgZGV0ZXJtaW5lZCwgYW5kIHBvc3NpYmx5DQotLSBXaG8gaW5zZXJ0 ZWQgdGhlIGxvY2F0aW9uIG9iamVjdA0KQWxvbmcgdGhlc2UgZGltZW5zaW9ucywgdGhlcmUncyBy ZWFsbHkgbm8gZGlmZmVyZW5jZSBiZXR3ZWVuIHRoZSBvbmUtb2JqZWN0IGFuZCBtdWx0aXBsZS1v YmplY3QgY2FzZXMuICBJbiBib3RoIGNhc2VzLCB0aGUgZGV0ZXJtaW5hdGlvbiBtZXRob2Qgd2ls bCBiZSBpbiBhIDxtZXRob2Q+IHRhZyBpbnNpZGUgdGhlICA8Z2VvcHJpdj4gZWxlbWVudC4gIE5l aXRoZXIgb3B0aW9uIHByb3ZpZGVzIG11Y2ggZ29vZCBpbmZvcm1hdGlvbiBhYm91dCB3aG8gaW5z ZXJ0cyBhIGxvY2F0aW9uIG9iamVjdCAtLSB0aGUgcHJpbWFyeSBtZWNoYW5pc20gaW4gUkZDIDQ0 NzkgaXMgdGhlIDxkZXZpY2U+IGVsZW1lbnQgKHdoaWNoIGlzbid0IHJlYWxseSBhbGwgdGhhdCBo ZWxwZnVsKSwgbGVhdmluZyB5b3UgYmFzaWNhbGx5IHdpdGggcHJlZmVyZW5jZS1vcmRlcmluZyBp biBlaXRoZXIgY2FzZSAoc2VlIFJGQyA1NDkxKS4NCg0KVGhlcmUgYXJlIHByb2JhYmx5IGFsc28g c2NlbmFyaW9zIHdoZXJlIHRoZSBpbnRlcm1lZGlhcnkga25vd3MgYmVzdCwgYnV0IGFsbG93aW5n IGZvciBtdWx0aXBsZSBsb2NhdGlvbiB2YWx1ZXMgd291bGQgc2VlbSB0byBhbGxvdyBmb3IgZWl0 aGVyIHBvc3NpYmlsaXR5OiBJZiBhbiBpbnRlcm1lZGlhcnkgd2FudHMgdG8gY29tcG9zaXRlLCBp dCBjYW4sIG9yIGl0IGNhbiBqdXN0IHRhY2sgb24gd2hhdCBpdCBoYXMuDQoNClNvIEkgdGhpbmsg dGhlIHF1ZXN0aW9uIGNvbWVzIGRvd24gdG8gdHdvIHRoaW5nczoNCjEuIFdoZXRoZXIgeW91IHdh bnQgdG8gYWxsb3cgZW50aXRpZXMgKm5vdCogdG8gY29tcG9zaXRlDQoyLiBXaGVyZSB5b3Ugd2Fu dCB5b3VyIHByZWZlcmVuY2Ugb3JkZXJpbmcgKFVSSSBsaXN0IG9yIFhNTCkNCjMuIEhvdyBlYXN5 IHlvdSB3YW50IGl0IHRvIGJlIHRvIGFkZCBvYmplY3RzDQoNCkVzcGVjaWFsbHkgZ2l2ZW4gdGhl IHRpZGluZXNzIG9mIHRoZSBsYXllcmluZyBpbiB0aGUgbXVsdGktb2JqZWN0IG1vZGVsICh3LnIu dC4gMyksIGl0IHNlZW1zIGxpa2UgYWxsb3dpbmcgbXVsdGlwbGUgb2JqZWN0cyB3aW5zIG9uIGNv dW50cyAxIGFuZCAzLiAgQW5kIG9uIGJhbGFuY2UsIHByb2JhYmx5IHBvaW50IDIgYXMgd2VsbCwg c2luY2UgeW91IGNhbiByZWFkIHRoZSBvcmRlcmluZyB3aXRob3V0IHBhcnNpbmcgYW55IFhNTCBm aXJzdC4NCg0KLS1SaWNoYXJkDQoNCg0KDQoNCk9uIEp1bCAxOSwgMjAxMCwgYXQgNzoxOSBQTSwg UGV0ZXJzb24sIEpvbiB3cm90ZToNCg0KDQoNCkl0IHNvdW5kcyBsaWtlIHlvdSBhZ3JlZSB0aGF0 IHRoZXJlIGlzIG9uZSBUYXJnZXQsIGF0IGxlYXN0LiBJ4oCZbSBub3QgZGlzYWdyZWVpbmcgdGhh dCBkaWZmZXJlbnQgZW50aXRpZXMgbWlnaHQgaGF2ZSBkaWZmZXJlbnQgaWRlYXMgYWJvdXQgdGhl IGxvY2F0aW9uIG9mIHRoZSB0YXJnZXQ7IEkganVzdCBkb27igJl0IHNlZSB3aHkgdGhhdCBlbnRh aWxzIGFueXRoaW5nIHdoZXRoZXIgdGhleSBzaG91bGQgYmUgaW4gZGlmZmVyZW50IHByZXNlbmNl IGRvY3VtZW50cyBvciB0aGUgc2FtZSBvbmUuIEFnYWluLCB0aGlzIGlzIGp1c3QgYSBxdWVzdGlv biBvZiB3aGV0aGVyIGEgYmFsZCBsaXN0IGluIGEgaGVhZGVyIGZpZWxkIHZhbHVlIGhhcyBlbm91 Z2ggc3ludGFjdGljIHJpY2huZXNzIHRvIGRlc2NyaWJlIHRoZSByZWxhdGlvbnNoaXAgYmV0d2Vl biB0aG9zZSBwcmVzZW5jZSBkb2N1bWVudHMsIG9yIHdoZXRoZXIgd2Ugc2hvdWxkIGxldCBSRkM0 NDc5IGRvIHRoYXQgam9iLiBBbGwgb2YgdGhvc2UgY3J1ZnR5IHBhcmFtZXRlcnMgdGhhdCBoYWQg Y3JlcHQgaW50byB0aGUgR2VvbG9jYXRpb24gaGVhZGVyIHdlcmUgc3ltcHRvbXMgb2YgdGhlIGxh Y2sgb2Ygc3ludGFjdGljIHJpY2huZXNzIGluIHRoYXQgbmVjayBvZiB0aGUgd29vZHMsIGFzIHdh cyB0aGUgYmxvYXQgaW4gZXJyb3IgY29kZXMgcmVsYXRlZCB0byB0aGVpciB1cGtlZXAuDQoNCkFz IHRvIGNvbXBvc2l0aW9uLCBhbnkgcHJlc2VuY2UgYXJjaGl0ZWN0dXJlIHRoYXQgaGFzIG11bHRp cGxlIHNvdXJjZXMgb2YgcHJlc2VuY2UgaGFzIHRvIHByb3ZpZGUgY29tcG9zaXRpb24gc29tZXdo ZXJlLiBJZiAoYXMgdGhlIHByZXZpb3VzIGxvY2F0aW9uLWNvbnZleWFuY2UgZG9jdW1lbnQgdGFj aXRseSBhc3N1bWVkKSB3ZSBkZWxpdmVyIGEgYnVuY2ggb2Ygc2VwYXJhdGUgcHJlc2VuY2UgZG9j dW1lbnRzIGZyb20gZGlmZmVyZW50IHNvdXJjZXMgYWxsIHRhbGtpbmcgYWJvdXQgdGhlIHNhbWUg cHJlc2VudGl0eS9UYXJnZXQgdG8gYSB3YXRjaGVyIChhbiBMUiwgaW4gZ2VvcHJpdiBwYXJsYW5j ZSksIHRoZW4gdGhlIHJlc3BvbnNpYmlsaXR5IGRldm9sdmVzIHRvIHRoZSBMUi93YXRjaGVyIHRv IGVmZmVjdGl2ZWx5IHBlcmZvcm0gY29tcG9zaXRpb24g4oCTIHRvIHRyeSB0byB1bmRlcnN0YW5k IHRoZSBkb2N1bWVudHMgYW5kIGhvdyB0aGV5IHJlbGF0ZSB0byBvbmUgYW5vdGhlciBpbiBvcmRl ciB0byBkZXJpdmUgYSB1c2VmdWwgcGljdHVyZSBvZiB0aGUgcHJlc2VudGl0eeKAmXMgcHJlc2Vu Y2UuIFRoZSBwcm9ibGVtIGlzLCB0aGUgd2F0Y2hlciBpcyB0aGUgbGVhc3QgbGlrZWx5IGVudGl0 eSBpbiB0aGUgYXJjaGl0ZWN0dXJlIHRvIHVuZGVyc3RhbmQgaG93IGFsbCB0aGVzZSBiaXRzIG9m IGluZm9ybWF0aW9uIGZpdCB0b2dldGhlci4NCg0KSm9uIFBldGVyc29uDQpOZXVTdGFyLCBJbmMu DQoNCg0KT24gNy8xOS8xMCAyOjQ0IFBNLCAiUmljaGFyZCBMLiBCYXJuZXMiIDxyYmFybmVzQGJi bi5jb20+IHdyb3RlOg0KV2hpbGUgaXQncyBjb3JyZWN0IHRvIHNheSB0aGF0IG9uZSBwcmVzZW5j ZSBkb2N1bWVudCBkZXNjcmliZXMgYSBzaW5nbGUgZW50aXR5LCBpdCdzIG5vdCBuZWNlc3Nhcmls eSB0cnVlIHRoYXQgbXVsdGlwbGUgcHJlc2VuY2UgZG9jdW1lbnRzIGRlc2NyaWJlIG11bHRpcGxl IGVudGl0aWVzLiAgUmVnYXJkbGVzcyBvZiBob3cgd2UgZGVmaW5lIHRoZSBlbnRpdHkgaW4gdGhl IHNlc3Npb24gdGhhdCBpcyB0aGUgdGFyZ2V0IChJSVJDLCBlYXJsaWVyIHZlcnNpb25zIHNhaWQg c29tZXRoaW5nIGxpa2UgInRoZSBVQUMgdGhhdCBpbml0aWF0ZWQgdGhlIGRpYWxvZ3VlIiksIGl0 IHNlZW1zIHBsYXVzaWJsZSB0aGF0IGRpZmZlcmVudCBlbnRpdGllcyBwcm9jZXNzaW5nIGEgU0lQ IG1lc3NhZ2UgbWlnaHQgaGF2ZSBkaWZmZXJlbnQgaWRlYXMgYXMgdG8gdGhlIGxvY2F0aW9uIG9m IHRoZSB0YXJnZXQuICBJbiB0aGlzIGNhc2UsIGl0IHdvdWxkIHNlZW0gcGxhdXNpYmxlIHRvIGhh dmUgbXVsdGlwbGUgbG9jYXRpb24gb2JqZWN0cyBpbiBhIHNpbmdsZSBtZXNzYWdlLCBhbGwgb2Yg d2hpY2ggaGF2ZSB0aGUgc2VtYW50aWMgdGhhdCB0aGV5J3JlIGRlc2NyaWJpbmcgdGhlIGxvY2F0 aW9uIG9mIHRoZSB0YXJnZXQgKGhvd2V2ZXIgdGhlIHRhcmdldCBpcyBjb3VwbGVkIHRvIHRoZSBz ZXNzaW9uKS4NCg0KU3BlYWtpbmcgbW9yZSBwcmFjdGljYWxseSwgaWYgd2UgYWNjZXB0IHRoZSBh c3NlcnRpb24gdGhhdCBtdWx0aXBsZSBsb2NhdGlvbiB2YWx1ZXMgd2lsbCBiZSBuZWNlc3Nhcnkg KHdoZXRoZXIgaW4gYSBzaW5nbGUgZG9jdW1lbnQgb3Igbm90KSwgdGhlbiBpdCBzZWVtcyBtdWNo IGNsZWFuZXIgdG8gaGF2ZSB0aGVtIGluIHNlcGFyYXRlIHByZXNlbmNlIGRvY3VtZW50cywgd2l0 aCBzZXBhcmF0ZSBDSUQgVVJJcy4gIEkgZG9uJ3QgcmVhbGx5IHNlZSBhbnkgcmVhc29uIGZvciBh bnkgb2YgdGhpcyB0byBjYWxsIGZvciBtb3JlIHRoYW4gb25lIEdlb2xvY2F0aW9uIGhlYWRlciwg c2luY2UgeW91IGNhbiBqdXN0IGFkZCBtb3JlIFVSSXMuDQoNCg0KDQpPbiBKdWwgMTksIDIwMTAs IGF0IDU6MjkgUE0sIFBldGVyc29uLCBKb24gd3JvdGU6DQoNCiBJ4oCZbSBzdXJlIHdl4oCZcmUg YWxsIGdvaW5nIHRvIGhhdmUgdG8gZGlzY3VzcyB0aGlzIGEgYml0IGluIE1hYXN0cmljaHQsIGJ1 dCB0aGVyZSBhcmUgYSBjb3VwbGUgYmFzaWMgcG9pbnRzIGhlcmUgSSB0aGluayB3ZSBuZWVkIHRv IHRlZSB1cC4gSSBjZXJ0YWlubHkgZGlkbuKAmXQgbWVhbiB0byBzdWdnZXN0IHRoYXQgYSByZXF1 ZXN0IGNhbiBvbmx5IGluY2x1ZGUgYSBzaW5nbGUgbG9jYXRpb24gKGkuZS4sIHRoYXQgYW55IGNv bnRyaWJ1dGluZyBwaWVjZSBvZiBsb2NhdGlvbiBpbmZvcm1hdGlvbiBkZXNpZ25hdGVzIHRoZSBz YW1lIHBsYWNlLCBqdXN0IHdpdGggdmFyeWluZyBkZWdyZWVzIG9mIGFjY3VyYWN5IG9yIHRpbWVs aW5lc3Mgb3Igc29tZXRoaW5nKS4gUmF0aGVyLCBJIGJlbGlldmUgYSBwcmVzZW5jZSBkb2N1bWVu dCBkZXNjcmliZXMgYSBzaW5nbGUgZW50aXR5IOKAkyBtdWx0aXBsZSBsb2NhdGlvbnMgY29tZSBh Ym91dCBiZWNhdXNlIHZhcmlvdXMgZGV2aWNlcyBhbmQgc2VydmljZXMgYXNzb2NpYXRlZCB3aXRo IHRoYXQgc2luZ2xlIGVudGl0eSBtYXkgYXR0cmlidXRlIHZhcmlvdXMgbG9jYXRpb25zIHRvIHRo ZSBlbnRpdHkuDQoNCiBHZXR0aW5nIGJhY2sgdG8gZnVuZGFtZW50YWxzLCB3ZSBkb27igJl0IG5l ZWQgYSBHZW9sb2NhdGlvbiBoZWFkZXIgaW4gb3JkZXIgdG8gY2FycnkgbG9jYXRpb24gaW4gU0lQ LiBUaGVyZSBhcmUgTUlNRSBib2RpZXMgZm9yIHRoYXQgKGluY2x1ZGluZyBDb250ZW50LUluZGly ZWN0aW9uIGJvZGllcyBmb3IgTGJ5Uiwgb3IgcGVyaGFwcyBDb250ZW50LUxvY2F0aW9uIGFzIHlv dSBzdWdnZXN0KSwgYW5kIHdlIGNhbiBpbmNsdWRlIHNldmVudGVlbiBkaWZmZXJlbnQgbG9jYXRp b24gb2JqZWN0cyBpZiB3ZSB3YW50IHRvLCByZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhlcmUgYXJl IHplcm8gb3Igb25lIG9yIGZpZnRlZW4gR2VvbG9jYXRpb24gaGVhZGVycy4gV2UgZG9u4oCZdCBu ZWVkIGEgbG9jYXRpb24gY29udmV5YW5jZSBzcGVjaWZpY2F0aW9uIG9yIGEgR2VvbG9jYXRpb24g aGVhZGVyIHRvIGVuYWJsZSB0aGF0LCBTSVAgaGFzIGFsd2F5cyBiZWVuIGFibGUgdG8gZG8gaXQs IGFuZCB5b3XigJlsbCBzdGlsbCBiZSBhYmxlIHRvIGFkZCByYW5kb20gTUlNRSBib2RpZXMgdGhh dCBjb250YWluIGxvY2F0aW9uIGluZm9ybWF0aW9uIGV2ZW4gaWYgdGhlcmUgaXMgYSBHZW9sb2Nh dGlvbiBoZWFkZXIgd2hpY2ggZG9lcyBub3QgcG9pbnQgdG8gdGhlbS4gU28gd2hhdCBkb2VzIHRo ZSBHZW9sb2NhdGlvbiBoZWFkZXIgYW5kIGxvY2F0aW9uIGNvbnZleWFuY2Ugc3BlY2lmaWNhdGlv biBidXkgdXM/DQoNCiBJ4oCZdmUgYWx3YXlzIG5haXZlbHkgdGhvdWdodCB0aGF0IHRoZSBHZW9s b2NhdGlvbiBoZWFkZXIgcHJvdmlkZXMgYSBjb3VwbGluZyBiZXR3ZWVuIHRoaXMgcGFydGljdWxh ciBTSVAgc2Vzc2lvbiBhbmQgYW4gZW50aXR5IHdob3NlIGxvY2F0aW9uIGlzIGRlc2lnbmF0ZWQg YnkgYSBQSURGIGRvY3VtZW50LiBUaGUgZW50aXR5IGlzIHRoZSBnZW9wcml2IFRhcmdldCwgYW5k IGlzIHByb2JhYmx5ICh0aG91Z2ggbm90IG5lY2Vzc2FyaWx5KSByZWxhdGVkIHRvIHRoZSBwYXJ0 eSBpZGVudGlmaWVkIGJ5IHRoZSBjbGFzc2ljIEZyb20gaGVhZGVyIGZpZWxkIG9mIHRoZSBTSVAg cmVxdWVzdC4gVGhlIEdlb2xvY2F0aW9uIGhlYWRlciB0ZWxscyB1cyB0aGF0IGZvciB0aGUgcHVy cG9zZXMgb2YgdGhlIFNJUCBzZXNzaW9uIGJlaW5nIG5lZ290aWF0ZWQsIHRoZSBsb2NhdGlvbiBv ZiB0aGlzIFRhcmdldCBpcyBzb21laG93IHJlbGV2YW50Li4uIHRoZSBib2xkZXN0IGludGVycHJl dGF0aW9uIHdvdWxkIGJlIHRoYXQgdGhpcyBUYXJnZXTigJlzIGxvY2F0aW9uIHNob3VsZCBiZSBj b25zaWRlcmVkIHRoZSBzb3VyY2Ugb2YgdGhlIHJlcXVlc3QuIEp1c3QgYXR0YWNoaW5nIGxvY2F0 aW9uLWF3YXJlIE1JTUUgYm9kaWVzIHdpdGhvdXQgdGhlIEdlb2xvY2F0aW9uIGhlYWRlciB0byBT SVAgcmVxdWVzdHMgZG9lc27igJl0IGNvbnZleSB0aGUgc2FtZSBzZW1hbnRpY3Mg4oCTIHRob3Nl IGJvZGllcyBjb3VsZCBtZWFuIGFueXRoaW5nLCBhbmQgcHJlc3VtYWJseSB0aGUgcmVjZWl2aW5n IGFwcGxpY2F0aW9uIHdvdWxkIHNvcnQgdGhyb3VnaCB0aGVtIGF0IGl0cyBkaXNjcmV0aW9uLg0K DQogV2hlcmUgSSBnZXQgY29uZnVzZWQgaXMgd2hlbiBJIHN0YXJ0IHRyeWluZyB0byB1bmRlcnN0 YW5kIHdoYXQgaXQgd291bGQgbWVhbiBzZW1hbnRpY2FsbHkgZm9yIGEgU0lQIHNlc3Npb24gdG8g YmUgY291cGxlZCB3aXRoIG1vcmUgdGhhbiBvbmUgVGFyZ2V0LiBBZ2FpbiwgSSBjYW4gaW1hZ2lu ZSBoeXBvdGhldGljYWxseSBhIFNJUCByZXF1ZXN0IGNvbnRhaW5pbmcgdW5zb3J0ZWQgTUlNRSBi b2RpZXMgdGhhdCB0YWxrIGFib3V0IGRpZmZlcmVudCBUYXJnZXRzIHRvIGFzc2lzdCBzb21lIHNw ZWNpZmljIGFwcGxpY2F0aW9uIHRoYXQga25vd3MgaG93IHRvIHJlY29uY2lsZSB0aGVtLCBidXQg aGVyZSBJIG1lYW4gdXNpbmcgdGhlIEdlb2xvY2F0aW9uIGhlYWRlciB0byBjb3VwbGUgYSBTSVAg cmVxdWVzdCB3aXRoIGxvY2F0aW9uIGluZm9ybWF0aW9uIGFib3V0IGRpZmZlcmVudCBUYXJnZXRz LiBJcyB0aGVyZSBhY3R1YWxseSBhIHVzZSBjYXNlL3JlcXVpcmVtZW50IGZvciB0aGF0PyBJZiBu b3QsIGFuZCB3ZSBvbmx5IHdhbnQgdG8gY291cGxlIGEgU0lQIHJlcXVlc3Qgd2l0aCBvbmUgVGFy Z2V0LCB0aGVuIEkgZmFpbCB0byBzZWUgd2h5IGNvbXBvc2luZyBsb2NhdGlvbiBpbmZvcm1hdGlv biBhYm91dCB0aGUgc2FtZSBUYXJnZXQgaW50byBhIHNpbmdsZSBQSURGIGJvZHkgd291bGQgYmUg YSBwcm9ibGVtLiBIYXZpbmcgbG9jYXRpb24gaW5mb3JtYXRpb24gYWJvdXQgdGhlIHNhbWUgZW50 aXR5IGZhaWwgdG8gYmUgb3JnYW5pemVkIGluIG9uZSBib2R5IHRocm91Z2ggUkZDNDQ3OSB3b3Vs ZG7igJl0IG1ha2Ugc2Vuc2UsIGFueXdheS4NCg0KIEkgdGhpbmsgaWYgd2UgdW5kZXJzdGFuZCB0 aGUgc2VtYW50aWNzIGJ5IHdoaWNoIHRoZSBHZW9sb2NhdGlvbiBoZWFkZXIg4oCcY291cGxlc+KA nSBQSURGIHdpdGggYSBTSVAgc2Vzc2lvbiwgdGhlbiB3ZeKAmWxsIGJldHRlciB1bmRlcnN0YW5k IGFsbCBvZiB0aGlzLiBJZiB0aGUgR2VvbG9jYXRpb24gaGVhZGVyIG9ubHkgZXhpc3RzIHRvIG5v dGlmeSBsYXp5IGludGVybWVkaWFyaWVzIHRoYXQgdGhlcmUgYXJlIGxvY2F0aW9uLXNlbnNpdGl2 ZSBib2RpZXMgaW4gdGhlIHJlcXVlc3Qgb3Igc29tZXdoZXJlIG91dCBvbiB0aGUgbmV0LCB3aXRo b3V0IGltcGx5aW5nIGFueXRoaW5nIGFib3V0IHRoZSBUYXJnZXQgb3IgdGhlIHJlbGF0aW9uc2hp cCBvZiB0aG9zZSBsb2NhdGlvbnMgdG8gdGhlIFNJUCByZXF1ZXN0LCB0aGVuIHRoaXMgd2hvbGUg c3BlY2lmaWNhdGlvbiBpcyBwcm9iYWJseSBtb3JlIHRyb3VibGUgdGhhbiBpdOKAmXMgd29ydGgg 4oCTIGl0IHJlYWxseSB3b3VsZG7igJl0IHByb3ZpZGUgbXVjaCBpbmNyZW1lbnRhbCB2YWx1ZSBh Ym92ZSB0aGUgYmFzaWMgYWJpbGl0eSBvZiBTSVAgdG8gY2FycnkgYWxsIHNvcnRzIG9mIGJvZGll cywgaW5jbHVkaW5nIGxvY2F0aW9uIGJvZGllcy4gSWYgdGhlcmUgYXJlLCBob3dldmVyLCBtb3Jl IGJpbmRpbmcgc2VtYW50aWNzIGhlcmUsIHRoZW4gd2UgcHJvYmFibHkgd29u4oCZdCBiZSBhYmxl IHRvIGFncmVlIG9uIHRoZSBuZWVkIGZvciBzb2xpdGFyeSBvciBtdWx0aXBsZSBHZW9sb2NhdGlv biBoZWFkZXJzIHVudGlsIHdlIGFncmVlIG9uIHdoYXQgdGhvc2Ugc2VtYW50aWNzIGFyZS4NCg0K IEpvbiBQZXRlcnNvbg0KIE5ldVN0YXIsIEluYy4NCg0KDQogT24gNy8xOC8xMCA3OjI1IFBNLCAi VGhvbXNvbiwgTWFydGluIiA8TWFydGluLlRob21zb25AYW5kcmV3LmNvbT4gd3JvdGU6DQoNCg0K SGkgSm9uLA0KDQogSSBhZG1pdCBhIGZhaXIgZGVncmVlIG9mIHN5bXBhdGh5IGZvciBSb2dlcuKA mXMgc3VnZ2VzdGlvbi4gIEFmdGVyIGFsbCwgdGhlIGFiaWxpdHkgdG8gaW5jbHVkZSBtdWx0aXBs ZSBsb2NhdGlvbiDigJx2YWx1ZXPigJ0gaW4gdGhlIHNhbWUgU0lQIHJlcXVlc3QgaXMgYSBmZWF0 dXJlIHRoYXQgaGFzIGV4aXN0ZWQgZm9yIG1hbnkgeWVhcnMuICBBIG51bWJlciBvZiBpbXBsZW1l bnRhdGlvbnMgaGF2ZSBjb21lIHRvIHJlbHkgb24gdGhpcyBtZWNoYW5pc207IHBlb3BsZSBhcmUg YnVpbGRpbmcgYW5kIGhhdmUgYnVpbHQgc29sdXRpb25zIGJhc2VkIG9uIGVhcmxpZXIgZHJhZnQs IGZ1bGx5IGF3YXJlIG9mIHRoZSByaXNrcyBpbiBpbXBsZW1lbnRpbmcgYW4gaW50ZXJuZXQgZHJh ZnQuDQoNCiBBdCBzb21lIHBvaW50LCBpdCBtaWdodCBiZSBuZWNlc3NhcnkgdG8gc3dhbGxvdyBh bnkgZGlzY29tZm9ydCBhbmQgcmVjb2duaXplIHRoYXQgdGhlIGNvbnNlcXVlbmNlcyBvZiBhbiBp bXBlcmZlY3Qgc29sdXRpb24gYXJlIGxlc3MgdGhhbiB0aGUgY29uc2VxdWVuY2VzIG9mIGEgY2hh bmdlIG9mIHRoZSBuYXR1cmUgeW91IHN1Z2dlc3QuDQoNCiBBbHRlcmluZyBwZXJzcGVjdGl2ZSBt aWdodCBvZmZlciBhIHNvbHV0aW9uLg0KDQogVGhlIGlkZWEgdGhhdCB0aGVyZSBhcmUgbXVsdGlw bGUgaXRlbXMgdGhhdCBhcmUgY29tcG9zaXRlZCBtaWdodCBiZSBjb3VudGVycHJvZHVjdGl2ZS4g IEluIHRoaXMgd29ybGQtdmlldywgeW91IGhhdmUgdG8gcmVjb25jaWxlIGEgbnVtYmVyIG9mIHBl cnNwZWN0aXZlcy4gIEluIHRoaXMsIHlvdSBhcmUgYWJzb2x1dGVseSBjb3JyZWN0OiBkb2luZyB0 aGF0IGF0IHR3byBsYXllcnMgaXMgYmFkLiAgQ29tcG9zaXRpb24gaXMgYSBoYXJkIHByb2JsZW0g YWxyZWFkeS4gIE1vdmluZyBpdCBpbnRvIFNJUCBvbmx5IGNvbXBsaWNhdGVzIGl0IGZ1cnRoZXIu DQoNCiBUaGUgYWx0ZXJuYXRpdmUgaXMgdG8gaW1hZ2luZSBhIHNpbmdsZSBsb2dpY2FsIHJlc291 cmNlIHRoYXQgcmVwcmVzZW50cyB0aGUgbG9jYXRpb24gb2YgdGhlIFRhcmdldC4gIEEgbG9jYXRp b24gYnkgdmFsdWUgaXMgYSByZXByZXNlbnRhdGlvbiBvZiB0aGlzIHJlc291cmNlOiBhIHNuYXBz aG90LiAgTG9jYXRpb24gYnkgcmVmZXJlbmNlIG9mZmVycyBhIG1lYW5zIGZvciBhbnkgZW50aXR5 IHRvIGlkZW50aWZ5IGFuZCBhY3F1aXJlIGEgdmlldyBvZiB0aGUgcmVzb3VyY2UsIGluZGVwZW5k ZW50IG9mIHRoYXQgc25hcHNob3QuICBUaGUgYXV0aG9yaXR5IGZvciB0aGUgcmVzb3VyY2UgbWln aHQgb2ZmZXIgdGhlIHNhbWUgcmVwcmVzZW50YXRpb24sIG9yIGl0IGNvdWxkIG9mZmVyIG9uZSBi ZXR0ZXIgc3VpdGVkIHRvIHRoZSByZWNpcGllbnQuICBUaGUgcmVwcmVzZW50YXRpb24gbWlnaHQg YmUgdXBkYXRlZCwgaXQgbWlnaHQgYmUgYWx0ZXJlZCBiYXNlZCBvbiBhbiBhdXRob3JpemF0aW9u IHBvbGljeSwgb3Igc29tZXRoaW5nIGVsc2UgKGxhbmd1YWdlIHByZWZlcmVuY2VzKS4gIFJlZ2Fy ZGxlc3Mgb2YgaG93IGl0IGlzIHJlcHJlc2VudGVkLCBpdCBpcyBzdGlsbCB0aGUgc2FtZSByZXNv dXJjZS4NCg0KIEluIHNpbXBsZSB0ZXJtcywgeW91IHN0YXRlIHRoYXQgdGhlIHJlcXVlc3QgY2Fu IG9ubHkgaW5jbHVkZSBhIHNpbmdsZSBfbG9jYXRpb25fLiAgV2hlbiBhIGxvY2F0aW9uIHZhbHVl IGFuZCByZWZlcmVuY2UgYXJlIGJvdGggaW5jbHVkZWQsIHRoZXkgcmVwcmVzZW50IHRoZSBfc2Ft ZV8gbG9jYXRpb24uDQoNCiBUaGlzIGlzIHdoeSBJIHN1Z2dlc3RlZCB0aGF0IENvbnRlbnQtTG9j YXRpb24gYmUgYm9ycm93ZWQuICBJbiBIVFRQLCBDb250ZW50LUxvY2F0aW9uIHNheXMgLSBpZiB5 b3Ugd2FudCB0byBrbm93IHdoZXJlIHRoaXMgcmVzb3VyY2UgcmVhbGx5IGxpdmVzLCBoZXJlIGlz IHdoZXJlIHlvdSBjYW4gZmluZCBpdC4NCg0KIE5vdyB0aGlzIG1pZ2h0IGJlIHNoZWVyIHNvcGhp c3RyeSwgYnV0IGl0IG1pZ2h0IG9mZmVyIGEgd2F5IG91dC4gIFRoZSBjb21wb3NpdGlvbiBwcm9i bGVtcyBhcmUgbGVmdCBvdXQgb2YgU0lQLg0KDQogSSBjYW4gd3JpdGUgdXAgYSBtb3JlIGRldGFp bGVkIHN0cmF3bWFuLCBidXQgZm9yIG5vdywgSSdsbCBqdXN0IGluY2x1ZGUgYW4gZXhhbXBsZToN Cg0KICAgIElOVklURSBzaXBzOmJvYkBiaWxveGkuZXhhbXBsZS5jb20gU0lQLzIuMA0KICAgIFZp YTogU0lQUy8yLjAvVExTIHBjMzMuYXRsYW50YS5leGFtcGxlLmNvbTticmFuY2g9ejloRzRiSzc0 YmY5DQogICAgTWF4LUZvcndhcmRzOiA3MA0KICAgIFRvOiBCb2IgPHNpcHM6Ym9iQGJpbG94aS5l eGFtcGxlLmNvbT4NCiAgICBGcm9tOiBBbGljZSA8c2lwczphbGljZUBhdGxhbnRhLmV4YW1wbGUu Y29tPjt0YWc9OWZ4Y2VkNzZzbA0KICAgIENhbGwtSUQ6IDM4NDgyNzYyOTgyMjAxODg1MTFAYXRs YW50YS5leGFtcGxlLmNvbQ0KICAgIEdlb2xvY2F0aW9uOiA8Y2lkOnRhcmdldDEyM0BhdGxhbnRh LmV4YW1wbGUuY29tPg0KICAgICAgO3JvdXRpbmctYWxsb3dlZD1ubw0KICAgIFN1cHBvcnRlZDog Z2VvbG9jYXRpb24NCiAgICBBY2NlcHQ6IGFwcGxpY2F0aW9uL3NkcCwgYXBwbGljYXRpb24vcGlk Zit4bWwNCiAgICBDU2VxOiAzMTg2MiBJTlZJVEUNCiAgICBDb250YWN0OiA8c2lwczphbGljZUBh dGxhbnRhLmV4YW1wbGUuY29tPg0KICAgIENvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L21peGVkOyBi b3VuZGFyeT1ib3VuZGFyeTENCiAgICBDb250ZW50LUxlbmd0aDogLi4uDQoNCiAgICAtLWJvdW5k YXJ5MQ0KICAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vc2RwDQoNCiAgICAuLi5TRFAgZ29l cyBoZXJlDQoNCiAgICAtLWJvdW5kYXJ5MQ0KICAgIENvbnRlbnQtVHlwZTogYXBwbGljYXRpb24v cGlkZit4bWwNCiAgICBDb250ZW50LUlEOiA8dGFyZ2V0MTIzQGF0bGFudGEuZXhhbXBsZS5jb20+ DQogICAgQ29udGVudC1Mb2NhdGlvbjogcHJlczphbGljZUBleGFtcGxlLmNvbT9sb2NhdGlvbi9Y SmhiWE02ZUcxc09tNXpPbkJwWg0KDQogICAgPD94bWwgdmVyc2lvbj0iMS4wIj8+DQogICAgLi4u UElERi1MTyBkb2N1bWVudA0KICAgIC0tYm91bmRhcnkxLS0NCg0KDQogLS1NYXJ0aW4NCg0KIC0t LS0gT3JpZ2luYWwgTWVzc2FnZSAtLS0tDQogRnJvbTogUGV0ZXJzb24sIEpvbiBbbWFpbHRvOmpv bi5wZXRlcnNvbkBuZXVzdGFyLmJpel0NCiBTZW50OiBGcmlkYXksIDE2IEp1bHkgMjAxMCA0OjU0 IFBNDQogVG86IFJvZ2VyIE1hcnNoYWxsOyBUaG9tc29uLCBNYXJ0aW47IEphbWVzIE0uIFBvbGs7 IHNpcGNvcmVAaWV0Zi5vcmcNCiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIGxvY2F0aW9uLWNvbnZl eWFuY2UtMDMganVzdCBzdWJtaXR0ZWQNCg0KDQogSW4gdGhlIGNvcm5lciBjYXNlIChhbmQgSSBk byB0aGluayBpdCBpcyBhIGNvcm5lciBjYXNlKSB3aGVyZSBtdWx0aXBsZSBlbnRpdGllcyBhcmUg Y29udHJpYnV0aW5nIGRpZmZlcmVudCBsb2NhdGlvbiBpbmZvcm1hdGlvbiB0byBhIHNpbmdsZSBT SVAgcmVxdWVzdCwgSSB0aGluayB3ZSBmYWNlIGEgZnVuZGFtZW50YWwgYXJjaGl0ZWN0dXJlIGNo b2ljZSBpbiB0aGlzIG1lY2hhbmlzbTogZWl0aGVyIGl0IGlzIFNJUOKAmXMgam9iIHRvIHNvcnQg b3V0IGhvdyB3ZSB1bmRlcnN0YW5kIHRob3NlIGRpZmZlcmVudCBsb2NhdGlvbnMsIG9yIGl0IGlz IFBJREbigJlzIGpvYi4gIFRyYWRpdGlvbmFsbHksIFBJREbigJlzIHVuZGVyc3RhbmRpbmcgb2Yg ZGlmZmVyZW50IHNvdXJjZXMgb2YgcHJlc2VuY2UgdGhhdCBwcm92aWRlIHBvdGVudGlhbGx5IGNv bnRyYWRpY3RvcnkgaW5mb3JtYXRpb24gcmVsaWVzIG9uIHRoZSBwcmVzZW5jZSBkYXRhIG1vZGVs IChSRkM0NDc5KSwgd2hpY2ggaXMgZGVzaWduZWQgdG8gcmVjb25jaWxlIGNvbmRpdGlvbnMgbGlr ZSB0aGUgb25lIHdoZXJlIG15IG1vYmlsZSBwaG9uZSB0aGlua3MgSSBhbSBhdmFpbGFibGUgYnV0 IG15IGRlc2t0b3AgdGhpbmtzIEnigJltIG9mZmxpbmUuIFRoZSBwcmVzZW5jZSBkYXRhIG1vZGVs IG1vcmVvdmVyIGRpZmZlcmVudGlhdGVzIGJldHdlZW4gdXNlcnMsIHNlcnZpY2VzIGFuZCBkZXZp Y2VzIGluIGEgd2F5IHRoYXQgaXMgdXNlZnVsIGFuZCBhcHBhcmVudGx5IGFwcGxpY2FibGUgdG8g bG9jYXRpb24gaW5mb3JtYXRpb24uIEkgYW0gbm90IGVhZ2VyIHRvIHRyeSB0byByZXBsaWNhdGUg dGhpcyBpbiBTSVAgaGVhZGVycywgaW5jbHVkaW5nIGJ5IGluc2VydGluZyBtdWx0aXBsZSBzdWNo IGhlYWRlcnMsIHB1dHRpbmcgaW4gbWFya3VwIHRoYXQgdHJpZXMgdG8gZXhwbGFpbiB0aGUg4oCc c291cmNl4oCdIG9mIGxvY2F0aW9uIGluZm9ybWF0aW9uIGluIFNJUCBoZWFkZXJzLCBhbmQgc28g b24uIFNJUOKAmXMgam9iIHNob3VsZCBiZSB0byBjb252ZXkgdGhlIGxvY2F0aW9uIG9iamVjdCDi gJMgZnVuZGFtZW50YWxseSwgdGhlIGZ1cnRoZXIgd2UgZGl2ZXJnZSBmcm9tIOKAnGNvbnZleWFu Y2XigJ0gYW5kIGVudGVyIGludG8gdGhlIHJlYWxtIG9mIOKAnGludGVncmF0aW9uLOKAnSB0aGUg bGVzcyBjb21mb3J0YWJsZSBJIGdldC4NCg0KIEkgdW5kZXJzdGFuZCB0aGF0IHRoZSBzdWJzZXF1 ZW50IHVzZSBjYXNlIHdoZXJlIHRoZXJlIGFyZSBkaWZmZXJlbnQgc291cmNlcyBvZiBsb2NhdGlv biBpbmZvcm1hdGlvbiwgc29tZSBvZiB3aGljaCBhcmUgTGJyViBhbmQgc29tZSBvZiB3aGljaCBh cmUgTGJ5UiwgbG9va3MgbGlrZSBhICBoYWlyeSBvbmUuIFRoaXMgaXMsIGhvd2V2ZXIsIGEgY29y bmVyIGNhc2Ugb2YgYSBjb3JuZXIgY2FzZS4gSSByZWFsbHkgZG8gbm90IGZlZWwgY29tZm9ydGFi bGUganVzdGlmeWluZyB0aGUgYWxsb3dhbmNlIG9mIG11bHRpcGxlIGxvY2F0aW9uIGhlYWRlcnMg aW4gU0lQIHBvaW50aW5nIHRvIGRpZmZlcmVudCBwcmVzZW5jZSBvYmplY3RzIChhcyBvcHBvc2Vk IHRvIGZvbGxvd2luZyB0aGUgcHJlc2VuY2UgZGF0YSBtb2RlbCkgdG8gY2FycnkgdGhlIDAsIDEg b3IgMiBkaWZmZXJlbnQgbG9jYXRpb25zIGR1ZSB0byBhIGNvcm5lciBjYXNlIG9mIGEgY29ybmVy IGNhc2UuIEFzIEkgc2FpZCBpbiBteSBwcmV2aW91cyBtYWlsIHRvIE1hcnRpbiwgSeKAmW0gbm90 IHJlYWxseSBzdXJlIEkgZXZlbiB1bmRlcnN0YW5kIHRoZSByZXF1aXJlbWVudHMgZm9yIGFuIGlu dGVybWVkaWFyeSB0byBldmFsdWF0ZSBhbmQgcmVqZWN0IExieVIsIG5vciB3aGF0IHRoZSBiZXN0 IHdheSBpcyBmb3IgcHJlc2VuY2UgZnJvbSB0aGVzZSBkeW5hbWljIHNvdXJjZXMgdG8gYmUgY29t cG9zZWQuIElmIHdlIHdlcmUgdG8gaW52ZXN0aWdhdGUgdGhlIHJpZ2h0IHdheSBmb3IgcHJlc2Vu Y2UgZnJvbSB0aG9zZSBzb3VyY2UgdG8gYmUgY29tcG9zZWQsIGl0IG1pZ2h0IHZlcnkgd2VsbCBi ZSB0aGF0IGl0IGlzIHRoZSByZXNwb25zaWJpbGl0eSBvZiB0aGUgY29tcG9zaXRvciB0byBpbnNl cnQgYW4gTGJ5UiBpbnRvIHRoZSBTSVAgcmVxdWVzdCAoaW50byB0aGUgR2VvbG9jYXRpb24gaGVh ZGVyKSwgYW5kIHRvIHBvbGwgYW5kIGNvbXBvc2UgYSBjb2hlcmVudCBQSURGIGRvY3VtZW50IGZy b20gaXRzIGR5bmFtaWMgYW5kIHN0YXRpYyBzb3VyY2VzIOKAkyB0aGF0IGlzIHByb2JhYmx5IHRo ZSBhcHByb2FjaCB0aGF0IG1vc3QgY2xvc2VseSBwYXJhbGxlbHMgdGhlIHRyYWRpdGlvbmFsIGFw cHJvYWNoZXMgdG8gcHJlc2VuY2UuIEJ1dCB3ZSBoYXZlbuKAmXQgZXZlbiBiZWd1biB0byBleHBs b3JlIHRoaXMgeWV0LiBObyBvbmUgaW5zaXN0aW5nIHRoYXQgdGhlcmUgd2lsbCBiZSDigJxlbXB0 eeKAnSBQSURGIGRvY3VtZW50cyBqdXN0IGNvbnRhaW5pbmcgcmVmZXJlbmNlcyB0byBleHRlcm5h bCBQSURGIGRvY3VtZW50cyBvciBzb21ldGhpbmcuIFNvbWV0aGluZyBhbG9uZyB0aG9zZSBsaW5l cyBpcyBvbmUgYXBwcm9hY2ggb2YgbWFueSB0aGF0IHdlIHdvdWxkIGNvbnNpZGVyIGlmIHdlIHRy aWVkIHRvIGZpZ3VyZSBvdXQgaG93IHRvIGFkZHJlc3MgdGhpcyBpbiBQSURGLiBUaGUgcXVlc3Rp b24gd2UgbmVlZCB0byBkZWNpZGUsIGFzIEkgc2FpZCBhYm92ZSwgaXMgdGhlIGFyY2hpdGVjdHVy ZSBvbmUg4oCTIGlzIFNJUOKAmXMgam9iIHRvIGNvbnZleSBQSURGIGRvY3VtZW50cywgb3IgdG8g Y29tcG9zZSB0aGVtPw0KDQogSm9uIFBldGVyc29uDQogTmV1U3RhciwgSW5jLg0KDQog4oCmDQoN Cg0KDQogIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpz aXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRm Lm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vc2lwY29yZQ0KDQo= --_000_8B0A9FCBB9832F43971E38010638454F03EB77305FSISPE7MB1comm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9VVRGLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDov L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KDQo8bWV0YSBuYW1lPUdlbmVy YXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5 bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6 MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MG1tOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJ Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMjQ0MDYxO30NCi5N c29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZTox MC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1h cmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtw YWdlOldvcmRTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHht bD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94 bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQg djpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286 c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4t QVUgbGluaz1ibHVlIHZsaW5rPXB1cnBsZSBzdHlsZT0nd29yZC13cmFwOiBicmVhay13b3JkOw0K LXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOy13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hpdGUt c3BhY2UnPg0KDQo8ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fu cy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYxJz5JIHRlbmQgdG8gYWdyZWUgd2l0aCBKYW1lcyAoUCkg YWJvdXQgdGhpcyAtIHlvdSBzZWVtIHRvIGJlDQphZHZvY2F0aW5nIGFuIGluY3JlYXNlIGluIHRo ZSBudW1iZXIgb2Yg4oCccG9pbnRzIG9mIGFydGljdWxhdGlvbuKAnS7CoCA8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjEx LjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+ PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4g c3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlm IjsNCmNvbG9yOiMyNDQwNjEnPldoYXQgSSB0aGluayBKb24gaXMgcHVyc3VpbmcgaXMgZmV3ZXIg c3VjaCBjb21wbGljYXRpb25z4oCmd2l0aG91dA0KcHJldmVudGluZyBhbnkgbmVjZXNzYXJ5IGZs ZXhpYmlsaXR5LsKgIFRoaXMgY2FuIGJlIHRha2VuIHRvbyBmYXIgaW4gZWl0aGVyDQpkaXJlY3Rp b24uPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsN CmNvbG9yOiMyNDQwNjEnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxp YnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYxJz4tLU1hcnRpbjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEu MHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYxJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2Jv cmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41cHQ7cGFkZGluZzowbW0gMG1tIDBtbSA0LjBwdCc+DQoN CjxkaXY+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRE RiAxLjBwdDtwYWRkaW5nOjMuMHB0IDBtbSAwbW0gMG1tJz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxiPjxzcGFuIGxhbmc9RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6 DQoiVGFob21hIiwic2Fucy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVT IHN0eWxlPSdmb250LXNpemU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiJz4gUmljaGFyZCBMLiBCYXJuZXMgW21haWx0bzpyYmFybmVzQGJibi5jb21dIDxicj4NCjxi PlNlbnQ6PC9iPiBUdWVzZGF5LCAyMCBKdWx5IDIwMTAgMTA6MDQgQU08YnI+DQo8Yj5Ubzo8L2I+ IFBldGVyc29uLCBKb248YnI+DQo8Yj5DYzo8L2I+IFJvZ2VyIE1hcnNoYWxsOyBzaXBjb3JlQGll dGYub3JnOyBUaG9tc29uLCBNYXJ0aW48YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFtzaXBjb3Jl XSBjb21wb3NpdGlvbiBvciBqdXN0IGluZGlyZWN0aW9uICh3YXM6DQpsb2NhdGlvbi1jb252ZXlh bmNlLTAzIGp1c3Qgc3VibWl0dGVkKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoN CjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD5DZXJ0YWlubHkgYWdyZWUgdGhhdCB0aGVyZSBpcyBvbmUgVGFyZ2V0 LCBzbyB0aGUgcXVlc3Rpb24gaXMNCnNpbXBseSBob3cgdG8gcmVwcmVzZW50IG11bHRpcGxlIGVz dGltYXRlcyBvZiB0aGF0IHRhcmdldCdzIGxvY2F0aW9uLjxvOnA+PC9vOnA+PC9wPg0KDQo8ZGl2 Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjwvZGl2Pg0K DQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+WW91ciBhbmFseXNpcyBpcyBjb3JyZWN0IHRo YXQgY2Fycnlpbmcgc2VwYXJhdGUgbG9jYXRpb24NCm9iamVjdHMgZWZmZWN0aXZlbHkgZ2l2ZXMg dGhlIExSIHRoZSByZXNwb25zaWJpbGl0eSBmb3IgY29tcG9zaXRpbmcsIGJ1dCBJJ20NCm5vdCBz dXJlIHRoYXQncyBhIGJhZCB0aGluZy4gJm5ic3A7VGhlIExSIGhhcyBhbiBpZGVhIG9mIHdoYXQg YXBwbGljYXRpb24gaXQncw0KdXNpbmcgdGhlIGxvY2F0aW9uIGluZm9ybWF0aW9uIGZvciAtLSBz b21ldGhpbmcgYW4gaW50ZXJtZWRpYXJ5IHByb2JhYmx5IGxhY2tzDQotLSB3aGljaCBjYW4gaW5m b3JtIGhvdyBpdCBjaG9vc2VzIG9yIGNvbWJpbmVzIGxvY2F0aW9uIHZhbHVlcy4gJm5ic3A7PG86 cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+VGhlIHF1ZXN0aW9uIHRoZW4gYmVjb21lcyBob3cgdG8gcHJvdmlkZSB0aGUgTFIgd2l0aA0K c3VmZmljaWVudCBpbmZvcm1hdGlvbiB0byBtYWtlIHRoZXNlIGRlY2lzaW9ucy4gJm5ic3A7QmV5 b25kIGluZm9ybWF0aW9uIGluIHRoZQ0KbG9jYXRpb24gb2JqZWN0IGl0c2VsZiAoZS5nLiwgYWNj dXJhY3kgb3IgcHJpdmFjeSBzZXR0aW5ncyksIGl0IHNlZW1zIGxpa2UgdGhlDQptYWluIGRhdGEg b2YgaW50ZXJlc3Qgd291bGQgYmU6PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+LS0gSG93IHRoZSBsb2NhdGlvbiBpbmZvcm1hdGlvbiB3YXMg ZGV0ZXJtaW5lZCwgYW5kIHBvc3NpYmx5PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2 Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+LS0gV2hvIGluc2VydGVkIHRoZSBsb2NhdGlvbiBvYmpl Y3Q8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD5BbG9uZyB0aGVzZSBkaW1lbnNpb25zLCB0aGVyZSdzIHJlYWxseSBubyBkaWZmZXJlbmNlIGJl dHdlZW4NCnRoZSBvbmUtb2JqZWN0IGFuZCBtdWx0aXBsZS1vYmplY3QgY2FzZXMuICZuYnNwO0lu IGJvdGggY2FzZXMsIHRoZQ0KZGV0ZXJtaW5hdGlvbiBtZXRob2Qgd2lsbCBiZSBpbiBhICZsdDtt ZXRob2QmZ3Q7IHRhZyBpbnNpZGUgdGhlDQombmJzcDsmbHQ7Z2VvcHJpdiZndDsgZWxlbWVudC4g Jm5ic3A7TmVpdGhlciBvcHRpb24gcHJvdmlkZXMgbXVjaCBnb29kDQppbmZvcm1hdGlvbiBhYm91 dCB3aG8gaW5zZXJ0cyBhIGxvY2F0aW9uIG9iamVjdCAtLSB0aGUgcHJpbWFyeSBtZWNoYW5pc20g aW4gUkZDDQo0NDc5IGlzIHRoZSAmbHQ7ZGV2aWNlJmd0OyBlbGVtZW50ICh3aGljaCBpc24ndCBy ZWFsbHkgYWxsIHRoYXQgaGVscGZ1bCksDQpsZWF2aW5nIHlvdSBiYXNpY2FsbHkgd2l0aCBwcmVm ZXJlbmNlLW9yZGVyaW5nIGluIGVpdGhlciBjYXNlIChzZWUgUkZDIDU0OTEpLg0KJm5ic3A7PG86 cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86 cD4mbmJzcDs8L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+VGhlcmUgYXJlIHByb2JhYmx5IGFsc28gc2NlbmFyaW9zIHdoZXJlIHRoZSBpbnRlcm1lZGlh cnkNCmtub3dzIGJlc3QsIGJ1dCBhbGxvd2luZyBmb3IgbXVsdGlwbGUgbG9jYXRpb24gdmFsdWVz IHdvdWxkIHNlZW0gdG8gYWxsb3cgZm9yDQplaXRoZXIgcG9zc2liaWxpdHk6IElmIGFuIGludGVy bWVkaWFyeSB3YW50cyB0byBjb21wb3NpdGUsIGl0IGNhbiwgb3IgaXQgY2FuDQpqdXN0IHRhY2sg b24gd2hhdCBpdCBoYXMuPG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8ZGl2 Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjwvZGl2Pg0K DQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+U28gSSB0aGluayB0aGUgcXVlc3Rpb24gY29t ZXMgZG93biB0byB0d28gdGhpbmdzOjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4N Cg0KPHAgY2xhc3M9TXNvTm9ybWFsPjEuIFdoZXRoZXIgeW91IHdhbnQgdG8gYWxsb3cgZW50aXRp ZXMgKm5vdCogdG8gY29tcG9zaXRlPG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0K DQo8cCBjbGFzcz1Nc29Ob3JtYWw+Mi4gV2hlcmUgeW91IHdhbnQgeW91ciBwcmVmZXJlbmNlIG9y ZGVyaW5nIChVUkkgbGlzdCBvciBYTUwpPG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2 Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+My4gSG93IGVhc3kgeW91IHdhbnQgaXQgdG8gYmUgdG8g YWRkIG9iamVjdHM8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxw IGNsYXNzPU1zb05vcm1hbD5Fc3BlY2lhbGx5IGdpdmVuIHRoZSB0aWRpbmVzcyBvZiB0aGUgbGF5 ZXJpbmcgaW4gdGhlDQptdWx0aS1vYmplY3QgbW9kZWwgKHcuci50LiAzKSwgaXQgc2VlbXMgbGlr ZSBhbGxvd2luZyBtdWx0aXBsZSBvYmplY3RzIHdpbnMgb24NCmNvdW50cyAxIGFuZCAzLiAmbmJz cDtBbmQgb24gYmFsYW5jZSwgcHJvYmFibHkgcG9pbnQgMiBhcyB3ZWxsLCBzaW5jZSB5b3UgY2Fu DQpyZWFkIHRoZSBvcmRlcmluZyB3aXRob3V0IHBhcnNpbmcgYW55IFhNTCBmaXJzdC48bzpwPjwv bzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4t LVJpY2hhcmQ8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxk aXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPGRpdj4N Cg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPk9uIEp1bCAxOSwgMjAxMCwgYXQgNzoxOSBQ TSwgUGV0ZXJzb24sIEpvbiB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCg0KPGRpdj4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5bGU9 J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48 YnI+DQpJdCBzb3VuZHMgbGlrZSB5b3UgYWdyZWUgdGhhdCB0aGVyZSBpcyBvbmUgVGFyZ2V0LCBh dCBsZWFzdC4gSeKAmW0gbm90DQpkaXNhZ3JlZWluZyB0aGF0IGRpZmZlcmVudCBlbnRpdGllcyBt aWdodCBoYXZlIGRpZmZlcmVudCBpZGVhcyBhYm91dCB0aGUNCmxvY2F0aW9uIG9mIHRoZSB0YXJn ZXQ7IEkganVzdCBkb27igJl0IHNlZSB3aHkgdGhhdCBlbnRhaWxzIGFueXRoaW5nIHdoZXRoZXIg dGhleQ0Kc2hvdWxkIGJlIGluIGRpZmZlcmVudCBwcmVzZW5jZSBkb2N1bWVudHMgb3IgdGhlIHNh bWUgb25lLiBBZ2FpbiwgdGhpcyBpcyBqdXN0DQphIHF1ZXN0aW9uIG9mIHdoZXRoZXIgYSBiYWxk IGxpc3QgaW4gYSBoZWFkZXIgZmllbGQgdmFsdWUgaGFzIGVub3VnaCBzeW50YWN0aWMNCnJpY2hu ZXNzIHRvIGRlc2NyaWJlIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiB0aG9zZSBwcmVzZW5jZSBk b2N1bWVudHMsIG9yDQp3aGV0aGVyIHdlIHNob3VsZCBsZXQgUkZDNDQ3OSBkbyB0aGF0IGpvYi4g QWxsIG9mIHRob3NlIGNydWZ0eSBwYXJhbWV0ZXJzIHRoYXQNCmhhZCBjcmVwdCBpbnRvIHRoZSBH ZW9sb2NhdGlvbiBoZWFkZXIgd2VyZSBzeW1wdG9tcyBvZiB0aGUgbGFjayBvZiBzeW50YWN0aWMN CnJpY2huZXNzIGluIHRoYXQgbmVjayBvZiB0aGUgd29vZHMsIGFzIHdhcyB0aGUgYmxvYXQgaW4g ZXJyb3IgY29kZXMgcmVsYXRlZCB0bw0KdGhlaXIgdXBrZWVwLjxicj4NCjxicj4NCkFzIHRvIGNv bXBvc2l0aW9uLCBhbnkgcHJlc2VuY2UgYXJjaGl0ZWN0dXJlIHRoYXQgaGFzIG11bHRpcGxlIHNv dXJjZXMgb2YNCnByZXNlbmNlIGhhcyB0byBwcm92aWRlIGNvbXBvc2l0aW9uIHNvbWV3aGVyZS4g SWYgKGFzIHRoZSBwcmV2aW91cw0KbG9jYXRpb24tY29udmV5YW5jZSBkb2N1bWVudCB0YWNpdGx5 IGFzc3VtZWQpIHdlIGRlbGl2ZXIgYSBidW5jaCBvZiBzZXBhcmF0ZQ0KcHJlc2VuY2UgZG9jdW1l bnRzIGZyb20gZGlmZmVyZW50IHNvdXJjZXMgYWxsIHRhbGtpbmcgYWJvdXQgdGhlIHNhbWUNCnBy ZXNlbnRpdHkvVGFyZ2V0IHRvIGEgd2F0Y2hlciAoYW4gTFIsIGluIGdlb3ByaXYgcGFybGFuY2Up LCB0aGVuIHRoZQ0KcmVzcG9uc2liaWxpdHkgZGV2b2x2ZXMgdG8gdGhlIExSL3dhdGNoZXIgdG8g ZWZmZWN0aXZlbHkgcGVyZm9ybSBjb21wb3NpdGlvbiDigJMNCnRvIHRyeSB0byB1bmRlcnN0YW5k IHRoZSBkb2N1bWVudHMgYW5kIGhvdyB0aGV5IHJlbGF0ZSB0byBvbmUgYW5vdGhlciBpbiBvcmRl cg0KdG8gZGVyaXZlIGEgdXNlZnVsIHBpY3R1cmUgb2YgdGhlIHByZXNlbnRpdHnigJlzIHByZXNl bmNlLiBUaGUgcHJvYmxlbSBpcywgdGhlDQp3YXRjaGVyIGlzIHRoZSBsZWFzdCBsaWtlbHkgZW50 aXR5IGluIHRoZSBhcmNoaXRlY3R1cmUgdG8gdW5kZXJzdGFuZCBob3cgYWxsDQp0aGVzZSBiaXRz IG9mIGluZm9ybWF0aW9uIGZpdCB0b2dldGhlci4gPGJyPg0KPGJyPg0KSm9uIFBldGVyc29uPGJy Pg0KTmV1U3RhciwgSW5jLjxicj4NCjxicj4NCjxicj4NCk9uIDcvMTkvMTAgMjo0NCBQTSwgJnF1 b3Q7UmljaGFyZCBMLiBCYXJuZXMmcXVvdDsgJmx0OzxhIGhyZWY9InJiYXJuZXNAYmJuLmNvbSI+ cmJhcm5lc0BiYm4uY29tPC9hPiZndDsNCndyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsIHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7DQpmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYi Jz5XaGlsZSBpdCdzIGNvcnJlY3QgdG8gc2F5IHRoYXQgb25lIHByZXNlbmNlDQpkb2N1bWVudCBk ZXNjcmliZXMgYSBzaW5nbGUgZW50aXR5LCBpdCdzIG5vdCBuZWNlc3NhcmlseSB0cnVlIHRoYXQg bXVsdGlwbGUNCnByZXNlbmNlIGRvY3VtZW50cyBkZXNjcmliZSBtdWx0aXBsZSBlbnRpdGllcy4g Jm5ic3A7UmVnYXJkbGVzcyBvZiBob3cgd2UNCmRlZmluZSB0aGUgZW50aXR5IGluIHRoZSBzZXNz aW9uIHRoYXQgaXMgdGhlIHRhcmdldCAoSUlSQywgZWFybGllciB2ZXJzaW9ucw0Kc2FpZCBzb21l dGhpbmcgbGlrZSAmcXVvdDt0aGUgVUFDIHRoYXQgaW5pdGlhdGVkIHRoZSBkaWFsb2d1ZSZxdW90 OyksIGl0IHNlZW1zDQpwbGF1c2libGUgdGhhdCBkaWZmZXJlbnQgZW50aXRpZXMgcHJvY2Vzc2lu ZyBhIFNJUCBtZXNzYWdlIG1pZ2h0IGhhdmUgZGlmZmVyZW50DQppZGVhcyBhcyB0byB0aGUgbG9j YXRpb24gb2YgdGhlIHRhcmdldC4gJm5ic3A7SW4gdGhpcyBjYXNlLCBpdCB3b3VsZCBzZWVtDQpw bGF1c2libGUgdG8gaGF2ZSBtdWx0aXBsZSBsb2NhdGlvbiBvYmplY3RzIGluIGEgc2luZ2xlIG1l c3NhZ2UsIGFsbCBvZiB3aGljaA0KaGF2ZSB0aGUgc2VtYW50aWMgdGhhdCB0aGV5J3JlIGRlc2Ny aWJpbmcgdGhlIGxvY2F0aW9uIG9mIHRoZSB0YXJnZXQgKGhvd2V2ZXINCnRoZSB0YXJnZXQgaXMg Y291cGxlZCB0byB0aGUgc2Vzc2lvbikuPGJyPg0KPGJyPg0KU3BlYWtpbmcgbW9yZSBwcmFjdGlj YWxseSwgaWYgd2UgYWNjZXB0IHRoZSBhc3NlcnRpb24gdGhhdCBtdWx0aXBsZSBsb2NhdGlvbg0K dmFsdWVzIHdpbGwgYmUgbmVjZXNzYXJ5ICh3aGV0aGVyIGluIGEgc2luZ2xlIGRvY3VtZW50IG9y IG5vdCksIHRoZW4gaXQgc2VlbXMNCm11Y2ggY2xlYW5lciB0byBoYXZlIHRoZW0gaW4gc2VwYXJh dGUgcHJlc2VuY2UgZG9jdW1lbnRzLCB3aXRoIHNlcGFyYXRlIENJRA0KVVJJcy4gJm5ic3A7SSBk b24ndCByZWFsbHkgc2VlIGFueSByZWFzb24gZm9yIGFueSBvZiB0aGlzIHRvIGNhbGwgZm9yIG1v cmUgdGhhbg0Kb25lIEdlb2xvY2F0aW9uIGhlYWRlciwgc2luY2UgeW91IGNhbiBqdXN0IGFkZCBt b3JlIFVSSXMuPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KT24gSnVsIDE5LCAyMDEwLCBhdCA1OjI5 IFBNLCBQZXRlcnNvbiwgSm9uIHdyb3RlOjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJD YWxpYnJpIiwic2Fucy1zZXJpZiInPjxicj4NCiZuYnNwO0nigJltIHN1cmUgd2XigJlyZSBhbGwg Z29pbmcgdG8gaGF2ZSB0byBkaXNjdXNzIHRoaXMgYSBiaXQgaW4gTWFhc3RyaWNodCwgYnV0DQp0 aGVyZSBhcmUgYSBjb3VwbGUgYmFzaWMgcG9pbnRzIGhlcmUgSSB0aGluayB3ZSBuZWVkIHRvIHRl ZSB1cC4gSSBjZXJ0YWlubHkNCmRpZG7igJl0IG1lYW4gdG8gc3VnZ2VzdCB0aGF0IGEgcmVxdWVz dCBjYW4gb25seSBpbmNsdWRlIGEgc2luZ2xlIGxvY2F0aW9uIChpLmUuLA0KdGhhdCBhbnkgY29u dHJpYnV0aW5nIHBpZWNlIG9mIGxvY2F0aW9uIGluZm9ybWF0aW9uIGRlc2lnbmF0ZXMgdGhlIHNh bWUgcGxhY2UsDQpqdXN0IHdpdGggdmFyeWluZyBkZWdyZWVzIG9mIGFjY3VyYWN5IG9yIHRpbWVs aW5lc3Mgb3Igc29tZXRoaW5nKS4gUmF0aGVyLCBJDQpiZWxpZXZlIGEgcHJlc2VuY2UgZG9jdW1l bnQgZGVzY3JpYmVzIGEgc2luZ2xlIGVudGl0eSDigJMgbXVsdGlwbGUgbG9jYXRpb25zIGNvbWUN CmFib3V0IGJlY2F1c2UgdmFyaW91cyBkZXZpY2VzIGFuZCBzZXJ2aWNlcyBhc3NvY2lhdGVkIHdp dGggdGhhdCBzaW5nbGUgZW50aXR5DQptYXkgYXR0cmlidXRlIHZhcmlvdXMgbG9jYXRpb25zIHRv IHRoZSBlbnRpdHkuPGJyPg0KJm5ic3A7PGJyPg0KJm5ic3A7R2V0dGluZyBiYWNrIHRvIGZ1bmRh bWVudGFscywgd2UgZG9u4oCZdCBuZWVkIGEgR2VvbG9jYXRpb24gaGVhZGVyIGluIG9yZGVyDQp0 byBjYXJyeSBsb2NhdGlvbiBpbiBTSVAuIFRoZXJlIGFyZSBNSU1FIGJvZGllcyBmb3IgdGhhdCAo aW5jbHVkaW5nDQpDb250ZW50LUluZGlyZWN0aW9uIGJvZGllcyBmb3IgTGJ5Uiwgb3IgcGVyaGFw cyBDb250ZW50LUxvY2F0aW9uIGFzIHlvdQ0Kc3VnZ2VzdCksIGFuZCB3ZSBjYW4gaW5jbHVkZSBz ZXZlbnRlZW4gZGlmZmVyZW50IGxvY2F0aW9uIG9iamVjdHMgaWYgd2Ugd2FudA0KdG8sIHJlZ2Fy ZGxlc3Mgb2Ygd2hldGhlciB0aGVyZSBhcmUgemVybyBvciBvbmUgb3IgZmlmdGVlbiBHZW9sb2Nh dGlvbiBoZWFkZXJzLg0KV2UgZG9u4oCZdCBuZWVkIGEgbG9jYXRpb24gY29udmV5YW5jZSBzcGVj aWZpY2F0aW9uIG9yIGEgR2VvbG9jYXRpb24gaGVhZGVyIHRvDQplbmFibGUgdGhhdCwgU0lQIGhh cyBhbHdheXMgYmVlbiBhYmxlIHRvIGRvIGl0LCBhbmQgeW914oCZbGwgc3RpbGwgYmUgYWJsZSB0 byBhZGQNCnJhbmRvbSBNSU1FIGJvZGllcyB0aGF0IGNvbnRhaW4gbG9jYXRpb24gaW5mb3JtYXRp b24gZXZlbiBpZiB0aGVyZSBpcyBhDQpHZW9sb2NhdGlvbiBoZWFkZXIgd2hpY2ggZG9lcyBub3Qg cG9pbnQgdG8gdGhlbS4gU28gd2hhdCBkb2VzIHRoZSBHZW9sb2NhdGlvbg0KaGVhZGVyIGFuZCBs b2NhdGlvbiBjb252ZXlhbmNlIHNwZWNpZmljYXRpb24gYnV5IHVzPyA8YnI+DQombmJzcDs8YnI+ DQombmJzcDtJ4oCZdmUgYWx3YXlzIG5haXZlbHkgdGhvdWdodCB0aGF0IHRoZSBHZW9sb2NhdGlv biBoZWFkZXIgcHJvdmlkZXMgYQ0KY291cGxpbmcgYmV0d2VlbiB0aGlzIHBhcnRpY3VsYXIgU0lQ IHNlc3Npb24gYW5kIGFuIGVudGl0eSB3aG9zZSBsb2NhdGlvbiBpcw0KZGVzaWduYXRlZCBieSBh IFBJREYgZG9jdW1lbnQuIFRoZSBlbnRpdHkgaXMgdGhlIGdlb3ByaXYgVGFyZ2V0LCBhbmQgaXMN CnByb2JhYmx5ICh0aG91Z2ggbm90IG5lY2Vzc2FyaWx5KSByZWxhdGVkIHRvIHRoZSBwYXJ0eSBp ZGVudGlmaWVkIGJ5IHRoZQ0KY2xhc3NpYyBGcm9tIGhlYWRlciBmaWVsZCBvZiB0aGUgU0lQIHJl cXVlc3QuIFRoZSBHZW9sb2NhdGlvbiBoZWFkZXIgdGVsbHMgdXMNCnRoYXQgZm9yIHRoZSBwdXJw b3NlcyBvZiB0aGUgU0lQIHNlc3Npb24gYmVpbmcgbmVnb3RpYXRlZCwgdGhlIGxvY2F0aW9uIG9m IHRoaXMNClRhcmdldCBpcyBzb21laG93IHJlbGV2YW50Li4uIHRoZSBib2xkZXN0IGludGVycHJl dGF0aW9uIHdvdWxkIGJlIHRoYXQgdGhpcw0KVGFyZ2V04oCZcyBsb2NhdGlvbiBzaG91bGQgYmUg Y29uc2lkZXJlZCB0aGUgc291cmNlIG9mIHRoZSByZXF1ZXN0LiBKdXN0DQphdHRhY2hpbmcgbG9j YXRpb24tYXdhcmUgTUlNRSBib2RpZXMgd2l0aG91dCB0aGUgR2VvbG9jYXRpb24gaGVhZGVyIHRv IFNJUA0KcmVxdWVzdHMgZG9lc27igJl0IGNvbnZleSB0aGUgc2FtZSBzZW1hbnRpY3Mg4oCTIHRo b3NlIGJvZGllcyBjb3VsZCBtZWFuIGFueXRoaW5nLA0KYW5kIHByZXN1bWFibHkgdGhlIHJlY2Vp dmluZyBhcHBsaWNhdGlvbiB3b3VsZCBzb3J0IHRocm91Z2ggdGhlbSBhdCBpdHMNCmRpc2NyZXRp b24uPGJyPg0KJm5ic3A7PGJyPg0KJm5ic3A7V2hlcmUgSSBnZXQgY29uZnVzZWQgaXMgd2hlbiBJ IHN0YXJ0IHRyeWluZyB0byB1bmRlcnN0YW5kIHdoYXQgaXQgd291bGQNCm1lYW4gc2VtYW50aWNh bGx5IGZvciBhIFNJUCBzZXNzaW9uIHRvIGJlIGNvdXBsZWQgd2l0aCBtb3JlIHRoYW4gb25lIFRh cmdldC4NCkFnYWluLCBJIGNhbiBpbWFnaW5lIGh5cG90aGV0aWNhbGx5IGEgU0lQIHJlcXVlc3Qg Y29udGFpbmluZyB1bnNvcnRlZCBNSU1FDQpib2RpZXMgdGhhdCB0YWxrIGFib3V0IGRpZmZlcmVu dCBUYXJnZXRzIHRvIGFzc2lzdCBzb21lIHNwZWNpZmljIGFwcGxpY2F0aW9uDQp0aGF0IGtub3dz IGhvdyB0byByZWNvbmNpbGUgdGhlbSwgYnV0IGhlcmUgSSBtZWFuIHVzaW5nIHRoZSBHZW9sb2Nh dGlvbiBoZWFkZXINCnRvIGNvdXBsZSBhIFNJUCByZXF1ZXN0IHdpdGggbG9jYXRpb24gaW5mb3Jt YXRpb24gYWJvdXQgZGlmZmVyZW50IFRhcmdldHMuIElzDQp0aGVyZSBhY3R1YWxseSBhIHVzZSBj YXNlL3JlcXVpcmVtZW50IGZvciB0aGF0PyBJZiBub3QsIGFuZCB3ZSBvbmx5IHdhbnQgdG8NCmNv dXBsZSBhIFNJUCByZXF1ZXN0IHdpdGggb25lIFRhcmdldCwgdGhlbiBJIGZhaWwgdG8gc2VlIHdo eSBjb21wb3NpbmcgbG9jYXRpb24NCmluZm9ybWF0aW9uIGFib3V0IHRoZSBzYW1lIFRhcmdldCBp bnRvIGEgc2luZ2xlIFBJREYgYm9keSB3b3VsZCBiZSBhIHByb2JsZW0uDQpIYXZpbmcgbG9jYXRp b24gaW5mb3JtYXRpb24gYWJvdXQgdGhlIHNhbWUgZW50aXR5IGZhaWwgdG8gYmUgb3JnYW5pemVk IGluIG9uZQ0KYm9keSB0aHJvdWdoIFJGQzQ0Nzkgd291bGRu4oCZdCBtYWtlIHNlbnNlLCBhbnl3 YXkuPGJyPg0KJm5ic3A7PGJyPg0KJm5ic3A7SSB0aGluayBpZiB3ZSB1bmRlcnN0YW5kIHRoZSBz ZW1hbnRpY3MgYnkgd2hpY2ggdGhlIEdlb2xvY2F0aW9uIGhlYWRlcg0K4oCcY291cGxlc+KAnSBQ SURGIHdpdGggYSBTSVAgc2Vzc2lvbiwgdGhlbiB3ZeKAmWxsIGJldHRlciB1bmRlcnN0YW5kIGFs bCBvZiB0aGlzLiBJZg0KdGhlIEdlb2xvY2F0aW9uIGhlYWRlciBvbmx5IGV4aXN0cyB0byBub3Rp ZnkgbGF6eSBpbnRlcm1lZGlhcmllcyB0aGF0IHRoZXJlIGFyZQ0KbG9jYXRpb24tc2Vuc2l0aXZl IGJvZGllcyBpbiB0aGUgcmVxdWVzdCBvciBzb21ld2hlcmUgb3V0IG9uIHRoZSBuZXQsIHdpdGhv dXQNCmltcGx5aW5nIGFueXRoaW5nIGFib3V0IHRoZSBUYXJnZXQgb3IgdGhlIHJlbGF0aW9uc2hp cCBvZiB0aG9zZSBsb2NhdGlvbnMgdG8NCnRoZSBTSVAgcmVxdWVzdCwgdGhlbiB0aGlzIHdob2xl IHNwZWNpZmljYXRpb24gaXMgcHJvYmFibHkgbW9yZSB0cm91YmxlIHRoYW4NCml04oCZcyB3b3J0 aCDigJMgaXQgcmVhbGx5IHdvdWxkbuKAmXQgcHJvdmlkZSBtdWNoIGluY3JlbWVudGFsIHZhbHVl IGFib3ZlIHRoZSBiYXNpYw0KYWJpbGl0eSBvZiBTSVAgdG8gY2FycnkgYWxsIHNvcnRzIG9mIGJv ZGllcywgaW5jbHVkaW5nIGxvY2F0aW9uIGJvZGllcy4gSWYNCnRoZXJlIGFyZSwgaG93ZXZlciwg bW9yZSBiaW5kaW5nIHNlbWFudGljcyBoZXJlLCB0aGVuIHdlIHByb2JhYmx5IHdvbuKAmXQgYmUg YWJsZQ0KdG8gYWdyZWUgb24gdGhlIG5lZWQgZm9yIHNvbGl0YXJ5IG9yIG11bHRpcGxlIEdlb2xv Y2F0aW9uIGhlYWRlcnMgdW50aWwgd2UgYWdyZWUNCm9uIHdoYXQgdGhvc2Ugc2VtYW50aWNzIGFy ZS48YnI+DQombmJzcDs8YnI+DQombmJzcDtKb24gUGV0ZXJzb248YnI+DQombmJzcDtOZXVTdGFy LCBJbmMuPGJyPg0KJm5ic3A7PGJyPg0KJm5ic3A7PGJyPg0KJm5ic3A7T24gNy8xOC8xMCA3OjI1 IFBNLCAmcXVvdDtUaG9tc29uLCBNYXJ0aW4mcXVvdDsgJmx0OzxhDQpocmVmPSJNYXJ0aW4uVGhv bXNvbkBhbmRyZXcuY29tIj5NYXJ0aW4uVGhvbXNvbkBhbmRyZXcuY29tPC9hPiZndDsgd3JvdGU6 PGJyPg0KJm5ic3A7PGJyPg0KJm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNh bGlicmkiLCJzYW5zLXNlcmlmIic+SGkNCkpvbiw8YnI+DQombmJzcDs8YnI+DQombmJzcDtJIGFk bWl0IGEgZmFpciBkZWdyZWUgb2Ygc3ltcGF0aHkgZm9yIFJvZ2Vy4oCZcyBzdWdnZXN0aW9uLiAm bmJzcDtBZnRlcg0KYWxsLCB0aGUgYWJpbGl0eSB0byBpbmNsdWRlIG11bHRpcGxlIGxvY2F0aW9u IOKAnHZhbHVlc+KAnSBpbiB0aGUgc2FtZSBTSVAgcmVxdWVzdA0KaXMgYSBmZWF0dXJlIHRoYXQg aGFzIGV4aXN0ZWQgZm9yIG1hbnkgeWVhcnMuICZuYnNwO0EgbnVtYmVyIG9mIGltcGxlbWVudGF0 aW9ucw0KaGF2ZSBjb21lIHRvIHJlbHkgb24gdGhpcyBtZWNoYW5pc207IHBlb3BsZSBhcmUgYnVp bGRpbmcgYW5kIGhhdmUgYnVpbHQNCnNvbHV0aW9ucyBiYXNlZCBvbiBlYXJsaWVyIGRyYWZ0LCBm dWxseSBhd2FyZSBvZiB0aGUgcmlza3MgaW4gaW1wbGVtZW50aW5nIGFuDQppbnRlcm5ldCBkcmFm dC48YnI+DQombmJzcDs8YnI+DQombmJzcDtBdCBzb21lIHBvaW50LCBpdCBtaWdodCBiZSBuZWNl c3NhcnkgdG8gc3dhbGxvdyBhbnkgZGlzY29tZm9ydCBhbmQNCnJlY29nbml6ZSB0aGF0IHRoZSBj b25zZXF1ZW5jZXMgb2YgYW4gaW1wZXJmZWN0IHNvbHV0aW9uIGFyZSBsZXNzIHRoYW4gdGhlDQpj b25zZXF1ZW5jZXMgb2YgYSBjaGFuZ2Ugb2YgdGhlIG5hdHVyZSB5b3Ugc3VnZ2VzdC48YnI+DQom bmJzcDs8YnI+DQombmJzcDtBbHRlcmluZyBwZXJzcGVjdGl2ZSBtaWdodCBvZmZlciBhIHNvbHV0 aW9uLjxicj4NCiZuYnNwOzxicj4NCiZuYnNwO1RoZSBpZGVhIHRoYXQgdGhlcmUgYXJlIG11bHRp cGxlIGl0ZW1zIHRoYXQgYXJlIGNvbXBvc2l0ZWQgbWlnaHQgYmUNCmNvdW50ZXJwcm9kdWN0aXZl LiAmbmJzcDtJbiB0aGlzIHdvcmxkLXZpZXcsIHlvdSBoYXZlIHRvIHJlY29uY2lsZSBhIG51bWJl ciBvZg0KcGVyc3BlY3RpdmVzLiAmbmJzcDtJbiB0aGlzLCB5b3UgYXJlIGFic29sdXRlbHkgY29y cmVjdDogZG9pbmcgdGhhdCBhdCB0d28NCmxheWVycyBpcyBiYWQuICZuYnNwO0NvbXBvc2l0aW9u IGlzIGEgaGFyZCBwcm9ibGVtIGFscmVhZHkuICZuYnNwO01vdmluZyBpdA0KaW50byBTSVAgb25s eSBjb21wbGljYXRlcyBpdCBmdXJ0aGVyLjxicj4NCiZuYnNwOzxicj4NCiZuYnNwO1RoZSBhbHRl cm5hdGl2ZSBpcyB0byBpbWFnaW5lIGEgc2luZ2xlIGxvZ2ljYWwgcmVzb3VyY2UgdGhhdCByZXBy ZXNlbnRzDQp0aGUgbG9jYXRpb24gb2YgdGhlIFRhcmdldC4gJm5ic3A7QSBsb2NhdGlvbiBieSB2 YWx1ZSBpcyBhIHJlcHJlc2VudGF0aW9uIG9mDQp0aGlzIHJlc291cmNlOiBhIHNuYXBzaG90LiAm bmJzcDtMb2NhdGlvbiBieSByZWZlcmVuY2Ugb2ZmZXJzIGEgbWVhbnMgZm9yIGFueQ0KZW50aXR5 IHRvIGlkZW50aWZ5IGFuZCBhY3F1aXJlIGEgdmlldyBvZiB0aGUgcmVzb3VyY2UsIGluZGVwZW5k ZW50IG9mIHRoYXQNCnNuYXBzaG90LiAmbmJzcDtUaGUgYXV0aG9yaXR5IGZvciB0aGUgcmVzb3Vy Y2UgbWlnaHQgb2ZmZXIgdGhlIHNhbWUNCnJlcHJlc2VudGF0aW9uLCBvciBpdCBjb3VsZCBvZmZl ciBvbmUgYmV0dGVyIHN1aXRlZCB0byB0aGUgcmVjaXBpZW50LiAmbmJzcDtUaGUNCnJlcHJlc2Vu dGF0aW9uIG1pZ2h0IGJlIHVwZGF0ZWQsIGl0IG1pZ2h0IGJlIGFsdGVyZWQgYmFzZWQgb24gYW4g YXV0aG9yaXphdGlvbg0KcG9saWN5LCBvciBzb21ldGhpbmcgZWxzZSAobGFuZ3VhZ2UgcHJlZmVy ZW5jZXMpLiAmbmJzcDtSZWdhcmRsZXNzIG9mIGhvdyBpdCBpcw0KcmVwcmVzZW50ZWQsIGl0IGlz IHN0aWxsIHRoZSBzYW1lIHJlc291cmNlLjxicj4NCiZuYnNwOzxicj4NCiZuYnNwO0luIHNpbXBs ZSB0ZXJtcywgeW91IHN0YXRlIHRoYXQgdGhlIHJlcXVlc3QgY2FuIG9ubHkgaW5jbHVkZSBhIHNp bmdsZQ0KX2xvY2F0aW9uXy4gJm5ic3A7V2hlbiBhIGxvY2F0aW9uIHZhbHVlIGFuZCByZWZlcmVu Y2UgYXJlIGJvdGggaW5jbHVkZWQsIHRoZXkNCnJlcHJlc2VudCB0aGUgX3NhbWVfIGxvY2F0aW9u Ljxicj4NCiZuYnNwOzxicj4NCiZuYnNwO1RoaXMgaXMgd2h5IEkgc3VnZ2VzdGVkIHRoYXQgQ29u dGVudC1Mb2NhdGlvbiBiZSBib3Jyb3dlZC4gJm5ic3A7SW4gSFRUUCwNCkNvbnRlbnQtTG9jYXRp b24gc2F5cyAtIGlmIHlvdSB3YW50IHRvIGtub3cgd2hlcmUgdGhpcyByZXNvdXJjZSByZWFsbHkg bGl2ZXMsDQpoZXJlIGlzIHdoZXJlIHlvdSBjYW4gZmluZCBpdC48YnI+DQombmJzcDs8YnI+DQom bmJzcDtOb3cgdGhpcyBtaWdodCBiZSBzaGVlciBzb3BoaXN0cnksIGJ1dCBpdCBtaWdodCBvZmZl ciBhIHdheSBvdXQuDQombmJzcDtUaGUgY29tcG9zaXRpb24gcHJvYmxlbXMgYXJlIGxlZnQgb3V0 IG9mIFNJUC48YnI+DQombmJzcDs8YnI+DQombmJzcDtJIGNhbiB3cml0ZSB1cCBhIG1vcmUgZGV0 YWlsZWQgc3RyYXdtYW4sIGJ1dCBmb3Igbm93LCBJJ2xsIGp1c3QgaW5jbHVkZQ0KYW4gZXhhbXBs ZTo8YnI+DQombmJzcDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtJTlZJVEUgc2lwczo8 YSBocmVmPSJib2JAYmlsb3hpLmV4YW1wbGUuY29tIj5ib2JAYmlsb3hpLmV4YW1wbGUuY29tPC9h Pg0KU0lQLzIuMDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1ZpYTogU0lQUy8yLjAvVExT DQpwYzMzLmF0bGFudGEuZXhhbXBsZS5jb207YnJhbmNoPXo5aEc0Yks3NGJmOTxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO01heC1Gb3J3YXJkczogNzA8YnI+DQombmJzcDsmbmJzcDsmbmJz cDsmbmJzcDtUbzogQm9iICZsdDtzaXBzOjxhIGhyZWY9ImJvYkBiaWxveGkuZXhhbXBsZS5jb20i PmJvYkBiaWxveGkuZXhhbXBsZS5jb208L2E+Jmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwO0Zyb206IEFsaWNlICZsdDtzaXBzOjxhIGhyZWY9ImFsaWNlQGF0bGFudGEuZXhhbXBsZS5j b20iPmFsaWNlQGF0bGFudGEuZXhhbXBsZS5jb208L2E+Jmd0Ozt0YWc9OWZ4Y2VkNzZzbDxicj4N CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO0NhbGwtSUQ6IDxhDQpocmVmPSIzODQ4Mjc2Mjk4MjIw MTg4NTExQGF0bGFudGEuZXhhbXBsZS5jb20iPjM4NDgyNzYyOTgyMjAxODg1MTFAYXRsYW50YS5l eGFtcGxlLmNvbTwvYT48YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtHZW9sb2NhdGlvbjog Jmx0O2NpZDo8YQ0KaHJlZj0idGFyZ2V0MTIzQGF0bGFudGEuZXhhbXBsZS5jb20iPnRhcmdldDEy M0BhdGxhbnRhLmV4YW1wbGUuY29tPC9hPiZndDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs7cm91dGluZy1hbGxvd2VkPW5vPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7U3VwcG9ydGVkOiBnZW9sb2NhdGlvbjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw O0FjY2VwdDogYXBwbGljYXRpb24vc2RwLCBhcHBsaWNhdGlvbi9waWRmK3htbDxicj4NCiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwO0NTZXE6IDMxODYyIElOVklURTxicj4NCiZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwO0NvbnRhY3Q6ICZsdDtzaXBzOjxhIGhyZWY9ImFsaWNlQGF0bGFudGEuZXhhbXBs ZS5jb20iPmFsaWNlQGF0bGFudGEuZXhhbXBsZS5jb208L2E+Jmd0Ozxicj4NCiZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwO0NvbnRlbnQtVHlwZTogbXVsdGlwYXJ0L21peGVkOyBib3VuZGFyeT1ib3Vu ZGFyeTE8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtDb250ZW50LUxlbmd0aDogLi4uPGJy Pg0KJm5ic3A7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7LS1ib3VuZGFyeTE8YnI+DQom bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtDb250ZW50LVR5cGU6IGFwcGxpY2F0aW9uL3NkcDxicj4N CiZuYnNwOzxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy4uLlNEUCBnb2VzIGhlcmU8YnI+ DQombmJzcDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstLWJvdW5kYXJ5MTxicj4NCiZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwO0NvbnRlbnQtVHlwZTogYXBwbGljYXRpb24vcGlkZit4bWw8 YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtDb250ZW50LUlEOiAmbHQ7PGEgaHJlZj0idGFy Z2V0MTIzQGF0bGFudGEuZXhhbXBsZS5jb20iPnRhcmdldDEyM0BhdGxhbnRhLmV4YW1wbGUuY29t PC9hPiZndDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtDb250ZW50LUxvY2F0aW9uOiBw cmVzOjxhDQpocmVmPSJhbGljZUBleGFtcGxlLmNvbT9sb2NhdGlvbi9YSmhiWE02ZUcxc09tNXpP bkJwWiI+YWxpY2VAZXhhbXBsZS5jb20/bG9jYXRpb24vWEpoYlhNNmVHMXNPbTV6T25CcFo8L2E+ PGJyPg0KJm5ic3A7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0Oz94bWwgdmVyc2lv bj0mcXVvdDsxLjAmcXVvdDs/Jmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOy4uLlBJ REYtTE8gZG9jdW1lbnQ8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDstLWJvdW5kYXJ5MS0t PGJyPg0KJm5ic3A7PGJyPg0KJm5ic3A7PGJyPg0KJm5ic3A7LS1NYXJ0aW48YnI+DQombmJzcDs8 YnI+DQombmJzcDstLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLTxicj4NCiZuYnNwO0Zyb206IFBl dGVyc29uLCBKb24gWzxhIGhyZWY9Im1haWx0bzpqb24ucGV0ZXJzb25AbmV1c3Rhci5iaXoiPm1h aWx0bzpqb24ucGV0ZXJzb25AbmV1c3Rhci5iaXo8L2E+XTxicj4NCiZuYnNwO1NlbnQ6IEZyaWRh eSwgMTYgSnVseSAyMDEwIDQ6NTQgUE08YnI+DQombmJzcDtUbzogUm9nZXIgTWFyc2hhbGw7IFRo b21zb24sIE1hcnRpbjsgSmFtZXMgTS4gUG9sazsgPGENCmhyZWY9InNpcGNvcmVAaWV0Zi5vcmci PnNpcGNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KJm5ic3A7U3ViamVjdDogUmU6IFtzaXBjb3JlXSBs b2NhdGlvbi1jb252ZXlhbmNlLTAzIGp1c3Qgc3VibWl0dGVkPGJyPg0KJm5ic3A7PGJyPg0KJm5i c3A7PGJyPg0KJm5ic3A7SW4gdGhlIGNvcm5lciBjYXNlIChhbmQgSSBkbyB0aGluayBpdCBpcyBh IGNvcm5lciBjYXNlKSB3aGVyZSBtdWx0aXBsZQ0KZW50aXRpZXMgYXJlIGNvbnRyaWJ1dGluZyBk aWZmZXJlbnQgbG9jYXRpb24gaW5mb3JtYXRpb24gdG8gYSBzaW5nbGUgU0lQDQpyZXF1ZXN0LCBJ IHRoaW5rIHdlIGZhY2UgYSBmdW5kYW1lbnRhbCBhcmNoaXRlY3R1cmUgY2hvaWNlIGluIHRoaXMg bWVjaGFuaXNtOg0KZWl0aGVyIGl0IGlzIFNJUOKAmXMgam9iIHRvIHNvcnQgb3V0IGhvdyB3ZSB1 bmRlcnN0YW5kIHRob3NlIGRpZmZlcmVudCBsb2NhdGlvbnMsDQpvciBpdCBpcyBQSURG4oCZcyBq b2IuICZuYnNwO1RyYWRpdGlvbmFsbHksIFBJREbigJlzIHVuZGVyc3RhbmRpbmcgb2YgZGlmZmVy ZW50DQpzb3VyY2VzIG9mIHByZXNlbmNlIHRoYXQgcHJvdmlkZSBwb3RlbnRpYWxseSBjb250cmFk aWN0b3J5IGluZm9ybWF0aW9uIHJlbGllcw0Kb24gdGhlIHByZXNlbmNlIGRhdGEgbW9kZWwgKFJG QzQ0NzkpLCB3aGljaCBpcyBkZXNpZ25lZCB0byByZWNvbmNpbGUgY29uZGl0aW9ucw0KbGlrZSB0 aGUgb25lIHdoZXJlIG15IG1vYmlsZSBwaG9uZSB0aGlua3MgSSBhbSBhdmFpbGFibGUgYnV0IG15 IGRlc2t0b3AgdGhpbmtzDQpJ4oCZbSBvZmZsaW5lLiBUaGUgcHJlc2VuY2UgZGF0YSBtb2RlbCBt b3Jlb3ZlciBkaWZmZXJlbnRpYXRlcyBiZXR3ZWVuIHVzZXJzLA0Kc2VydmljZXMgYW5kIGRldmlj ZXMgaW4gYSB3YXkgdGhhdCBpcyB1c2VmdWwgYW5kIGFwcGFyZW50bHkgYXBwbGljYWJsZSB0bw0K bG9jYXRpb24gaW5mb3JtYXRpb24uIEkgYW0gbm90IGVhZ2VyIHRvIHRyeSB0byByZXBsaWNhdGUg dGhpcyBpbiBTSVAgaGVhZGVycywNCmluY2x1ZGluZyBieSBpbnNlcnRpbmcgbXVsdGlwbGUgc3Vj aCBoZWFkZXJzLCBwdXR0aW5nIGluIG1hcmt1cCB0aGF0IHRyaWVzIHRvDQpleHBsYWluIHRoZSDi gJxzb3VyY2XigJ0gb2YgbG9jYXRpb24gaW5mb3JtYXRpb24gaW4gU0lQIGhlYWRlcnMsIGFuZCBz byBvbi4gU0lQ4oCZcw0Kam9iIHNob3VsZCBiZSB0byBjb252ZXkgdGhlIGxvY2F0aW9uIG9iamVj dCDigJMgZnVuZGFtZW50YWxseSwgdGhlIGZ1cnRoZXIgd2UNCmRpdmVyZ2UgZnJvbSDigJxjb252 ZXlhbmNl4oCdIGFuZCBlbnRlciBpbnRvIHRoZSByZWFsbSBvZiDigJxpbnRlZ3JhdGlvbizigJ0g dGhlIGxlc3MNCmNvbWZvcnRhYmxlIEkgZ2V0Ljxicj4NCiZuYnNwOzxicj4NCiZuYnNwO0kgdW5k ZXJzdGFuZCB0aGF0IHRoZSBzdWJzZXF1ZW50IHVzZSBjYXNlIHdoZXJlIHRoZXJlIGFyZSBkaWZm ZXJlbnQNCnNvdXJjZXMgb2YgbG9jYXRpb24gaW5mb3JtYXRpb24sIHNvbWUgb2Ygd2hpY2ggYXJl IExiclYgYW5kIHNvbWUgb2Ygd2hpY2ggYXJlDQpMYnlSLCBsb29rcyBsaWtlIGEgJm5ic3A7aGFp cnkgb25lLiBUaGlzIGlzLCBob3dldmVyLCBhIGNvcm5lciBjYXNlIG9mIGEgY29ybmVyDQpjYXNl LiBJIHJlYWxseSBkbyBub3QgZmVlbCBjb21mb3J0YWJsZSBqdXN0aWZ5aW5nIHRoZSBhbGxvd2Fu Y2Ugb2YgbXVsdGlwbGUNCmxvY2F0aW9uIGhlYWRlcnMgaW4gU0lQIHBvaW50aW5nIHRvIGRpZmZl cmVudCBwcmVzZW5jZSBvYmplY3RzIChhcyBvcHBvc2VkIHRvDQpmb2xsb3dpbmcgdGhlIHByZXNl bmNlIGRhdGEgbW9kZWwpIHRvIGNhcnJ5IHRoZSAwLCAxIG9yIDIgZGlmZmVyZW50IGxvY2F0aW9u cw0KZHVlIHRvIGEgY29ybmVyIGNhc2Ugb2YgYSBjb3JuZXIgY2FzZS4gQXMgSSBzYWlkIGluIG15 IHByZXZpb3VzIG1haWwgdG8gTWFydGluLA0KSeKAmW0gbm90IHJlYWxseSBzdXJlIEkgZXZlbiB1 bmRlcnN0YW5kIHRoZSByZXF1aXJlbWVudHMgZm9yIGFuIGludGVybWVkaWFyeSB0bw0KZXZhbHVh dGUgYW5kIHJlamVjdCBMYnlSLCBub3Igd2hhdCB0aGUgYmVzdCB3YXkgaXMgZm9yIHByZXNlbmNl IGZyb20gdGhlc2UNCmR5bmFtaWMgc291cmNlcyB0byBiZSBjb21wb3NlZC4gSWYgd2Ugd2VyZSB0 byBpbnZlc3RpZ2F0ZSB0aGUgcmlnaHQgd2F5IGZvcg0KcHJlc2VuY2UgZnJvbSB0aG9zZSBzb3Vy Y2UgdG8gYmUgY29tcG9zZWQsIGl0IG1pZ2h0IHZlcnkgd2VsbCBiZSB0aGF0IGl0IGlzIHRoZQ0K cmVzcG9uc2liaWxpdHkgb2YgdGhlIGNvbXBvc2l0b3IgdG8gaW5zZXJ0IGFuIExieVIgaW50byB0 aGUgU0lQIHJlcXVlc3QgKGludG8NCnRoZSBHZW9sb2NhdGlvbiBoZWFkZXIpLCBhbmQgdG8gcG9s bCBhbmQgY29tcG9zZSBhIGNvaGVyZW50IFBJREYgZG9jdW1lbnQgZnJvbQ0KaXRzIGR5bmFtaWMg YW5kIHN0YXRpYyBzb3VyY2VzIOKAkyB0aGF0IGlzIHByb2JhYmx5IHRoZSBhcHByb2FjaCB0aGF0 IG1vc3QNCmNsb3NlbHkgcGFyYWxsZWxzIHRoZSB0cmFkaXRpb25hbCBhcHByb2FjaGVzIHRvIHBy ZXNlbmNlLiBCdXQgd2UgaGF2ZW7igJl0IGV2ZW4NCmJlZ3VuIHRvIGV4cGxvcmUgdGhpcyB5ZXQu IE5vIG9uZSBpbnNpc3RpbmcgdGhhdCB0aGVyZSB3aWxsIGJlIOKAnGVtcHR54oCdIFBJREYNCmRv Y3VtZW50cyBqdXN0IGNvbnRhaW5pbmcgcmVmZXJlbmNlcyB0byBleHRlcm5hbCBQSURGIGRvY3Vt ZW50cyBvciBzb21ldGhpbmcuDQpTb21ldGhpbmcgYWxvbmcgdGhvc2UgbGluZXMgaXMgb25lIGFw cHJvYWNoIG9mIG1hbnkgdGhhdCB3ZSB3b3VsZCBjb25zaWRlciBpZg0Kd2UgdHJpZWQgdG8gZmln dXJlIG91dCBob3cgdG8gYWRkcmVzcyB0aGlzIGluIFBJREYuIFRoZSBxdWVzdGlvbiB3ZSBuZWVk IHRvDQpkZWNpZGUsIGFzIEkgc2FpZCBhYm92ZSwgaXMgdGhlIGFyY2hpdGVjdHVyZSBvbmUg4oCT IGlzIFNJUOKAmXMgam9iIHRvIGNvbnZleSBQSURGDQpkb2N1bWVudHMsIG9yIHRvIGNvbXBvc2Ug dGhlbT88YnI+DQombmJzcDs8YnI+DQombmJzcDtKb24gUGV0ZXJzb248YnI+DQombmJzcDtOZXVT dGFyLCBJbmMuPGJyPg0KJm5ic3A7PGJyPg0KJm5ic3A74oCmPGJyPg0KJm5ic3A7PGJyPg0KJm5i c3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5 bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIic+ PGJyPg0KJm5ic3A7Jm5ic3A7X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpzaXBjb3JlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9InNpcGNvcmVA aWV0Zi5vcmciPnNpcGNvcmVAaWV0Zi5vcmc8L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlIj5odHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8L2E+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KDQo8cCBj bGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0Jz48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNpcGNvcmUgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciPnNpcGNvcmVAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z aXBjb3JlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8L2E+ PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJz cDs8L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8 L2JvZHk+DQoNCjwvaHRtbD4NCg== --_000_8B0A9FCBB9832F43971E38010638454F03EB77305FSISPE7MB1comm_-- From Martin.Thomson@andrew.com Mon Jul 19 23:37:09 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B70633A694C for ; Mon, 19 Jul 2010 23:37:06 -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.038, 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 O0hNOyTRQsLg for ; Mon, 19 Jul 2010 23:37:00 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 1BC993A6BE9 for ; Mon, 19 Jul 2010 23:36:55 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:64317 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S340156Ab0GTGhK (ORCPT ); Tue, 20 Jul 2010 01:37:10 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 20 Jul 2010 01:37:10 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 20 Jul 2010 14:37:02 +0800 From: "Thomson, Martin" To: "Peterson, Jon" , Roger Marshall , "James M. Polk" , "sipcore@ietf.org" Date: Tue, 20 Jul 2010 14:39:11 +0800 Thread-Topic: composition or just indirection (was: location-conveyance-03 just submitted) Thread-Index: Acsi+NJTa+ULYvovSE2TL/bYrSlncwAKAPJQABWWaxYADURloAAvdkeAABJoDoQAjAHMIAApbBSCABIVO7A= Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB7730BA@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03EB772EBB@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8B0A9FCBB9832F43971E38010638454F03EB7730BASISPE7MB1comm_" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] composition or just indirection (was: location-conveyance-03 just 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: Tue, 20 Jul 2010 06:37:51 -0000 --_000_8B0A9FCBB9832F43971E38010638454F03EB7730BASISPE7MB1comm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVzb2x2aW5nIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIGhlYWRlciBpcyB0aGUgYmlnZ2VzdCBwcm9i bGVtLg0KDQpNeSBvcmlnaW5hbCB2aWV3IHdhcyB0aGF0IHRoZSBpbnRlbnQgd2FzIHRvIGNvbnZl eSB0aGUgbWVzc2FnZSB0aGF0IHRoZSByZWZlcmVuY2VkIGxvY2F0aW9uIGluZm9ybWF0aW9uIGlz IGZvciB0aGUgZW50aXR5IGlkZW50aWZpZWQgaW4gdGhlIEZyb20gaGVhZGVyLiAgVGhlIGlkZWEg d2FzIHRoZSBTSVAgcmVxdWVzdCBmb3JnZWQgYSBsaW5rIGJldHdlZW4gdGhlIGlkZW50aXR5IGFu ZCB0aGUgbG9jYXRpb24gaW4gdGhlIFBJREYtTE8gZG9jdW1lbnQuDQoNCkkgd2FzIGxhdGVyIGNv bnZpbmNlZCB0aGF0IHRoaXMgc29ydCBvZiBzdHJvbmcgc2VtYW50aWMgd2FzIHVubmVjZXNzYXJ5 LiAgVGhlIGlkZWEgb2Yg4oCccmVsZXZhbmNl4oCdIGlzIGEgYmV0dGVyIHdheSBvZiBhcHByb2Fj aGluZyB0aGUgcHJvYmxlbS4NCg0KTG9jYXRpb24gY2FuIGJlIGNvbnZleWVkIGluIFNJUCBhbHJl YWR5LCBzbyBpZiB0aGUgaGVhZGVyIGlzIHRvIGhhdmUgYW55IHZhbHVlLCBpdCBuZWVkcyBhIGNs ZWFybHkgZGVmaW5lZCBzZW1hbnRpYy4gIEhvdyBhYm91dDoNCg0KVGhlIEdlb2xvY2F0aW9uIGhl YWRlciBpZGVudGlmaWVzIGEgUElERiBkb2N1bWVudCBieSB2YWx1ZSBvciByZWZlcmVuY2UuICBB IEdlb2xvY2F0aW9uIGhlYWRlciBpbmRpY2F0ZXMgdGhhdCBhKSB0aGlzIHBhcnRpY3VsYXIgUElE RiBkb2N1bWVudCBjb250YWlucyBsb2NhdGlvbiBpbmZvcm1hdGlvbiBhbmQgYikgdGhhdCB0aGlz IGxvY2F0aW9uIGluZm9ybWF0aW9uIGluIHBhcnRpY3VsYXIgbWF5IGJlIHJlbGV2YW50IHRvIHRo ZSBwcm9jZXNzaW5nIG9mIHRoZSBTSVAgcmVxdWVzdC4NCg0KVGhpcyBpcyBpbnRlbnRpb25hbGx5 IHNvZnQsIGJ1dCAoSSBiZWxpZXZlKSBub3QgdG9vIHZhZ3VlLiAgWWVzLCB5b3UgY2FuIG1ha2Ug dGhlIGxlYXAgZnJvbSB0aGlzIHRvIGNvbmNsdWRlIHRoYXQgdGhlIFRhcmdldCBhbmQgdGhlIHJl cXVlc3Qgb3JpZ2luYXRvciBhcmUgb25lIGFuZCB0aGUgc2FtZS4gIEEgc2hvcnRlciBqdW1wIHdv dWxkIGJlIHRvIHNheSB0aGF0IHRoZXNlIGVudGl0aWVzIGFyZSBhdCB0aGUgc2FtZSBsb2NhdGlv bi4gIFRoZXNlIHN0cm9uZ2VyIHNlbWFudGljcyBhcmUgdW5uZWNlc3NhcnnigKYgb3IgYXQgbGVh c3QgaGFyZCB0byBwcm92ZS4NCg0KLS0NCg0KVGhlIHJlYXNvbiB0aGF0IEkgcHJvcG9zZWQgQ29u dGVudC1Mb2NhdGlvbiBpcyBiZWNhdXNlIGl0IGRvZXMgYXdheSB3aXRoIHRoZSBpZGVhIHRoYXQg dGhlcmUgYXJlIG11bHRpcGxlIHNvdXJjZXMuICBJbnN0ZWFkLCBpdCBpZGVudGlmaWVzIGEgc2lu Z2xlIGF1dGhvcml0eSBhbmQgcmVzb3VyY2UuICBUaGF0IGF1dGhvcml0eSBtaWdodCBjb21wb3Nl IG11bHRpcGxlIHNvdXJjZXMsIGJ1dCB0aGF0IGJlY29tZXMgb3BhcXVlLiAgSWYgSSB0aGluayBv ZiBhIHNpbmdsZSBIVFRQIHJlc291cmNlLCB0aGUgaWRlYSB0aGF0IHRoZSByZXNvdXJjZSBtaWdo dCBoYXZlIGRpZmZlcmVudCByZXByZXNlbnRhdGlvbnMgZG9lc27igJl0IGNhdXNlIChtdWNoKSBj b25zdGVybmF0aW9uLg0KDQpUaGUgYmlnZ2VyIHByb2JsZW0gYXJpc2VzIHdoZW4geW91IGFsbG93 IGZyZWUgcmVpZ24gdG8gZGlmZmVyZW50IGF1dGhvcml0aWVzIHdoaWNoIGVhY2ggaGF2ZSB0aGVp ciBkaWZmZXJlbnQgdmlld3MuICBBbGxvdyB0aGUgaW5jbHVzaW9uIG9mIHN0YXRpYyBhbmQgZHlu YW1pYywgYnV0IG1ha2UgaXQgY2xlYXIgdGhhdCBib3RoIHN0YXRpYyBhbmQgZHluYW1pYyBoYXZl IHRvIGJlIHRoZSBzYW1lIHRoaW5nL3Jlc291cmNlLg0KDQpPbmNlIGEgc2luZ2xlIGF1dGhvcml0 eSBpcyBpc29sYXRlZCwgdGhlbiBhbGwgeW91IGhhdmUgdG8gd29ycnkgYWJvdXQgaXMgdGhlIGNv bnRlbnRzIG9mIHRoZSBQSURGLiAgV2UgaGF2ZSB0aGUgbWVhbnMgdG8gZGVhbCB3aXRoIHRoYXQg d2l0aCA0NDc5IChpbiBnZW5lcmFsKSBhbmQgNTQ5MSAoZm9yIGxvY2F0aW9uIHNwZWNpZmljYWxs eSkuDQoNCkFuZCB0aGUgVUFDIG1ha2VzIHRoZSBkZWNpc2lvbiBhYm91dCB3aGljaCBhdXRob3Jp dHkgdG8gbm9taW5hdGUuDQoNCi0tTWFydGluDQoNCnAucy4gTm90ZSB0aGF0IHRoZSBkZWZpbml0 aW9uIHdvcmRpbmcgYWJvdmUgd291bGQgcHJlY2x1ZGUgdGhlIHVzZSBvZiBhIGdlbzogVVJJLiAg SeKAmW0gb3BlbiB0byBtYWtpbmcgdGhlIHN0YXRlbWVudCBmdXp6aWVyLCBpZiB0aGVyZSBpcyBj b25zZW5zdXMgdGhhdCBvdGhlciBsb2NhdGlvbiBmb3JtYXRzIGFyZSBhY2NlcHRhYmxlIG9yIGRl c2lyYWJsZS4NCg0KRnJvbTogUGV0ZXJzb24sIEpvbiBbbWFpbHRvOmpvbi5wZXRlcnNvbkBuZXVz dGFyLmJpel0NClNlbnQ6IFR1ZXNkYXksIDIwIEp1bHkgMjAxMCA3OjI5IEFNDQpUbzogVGhvbXNv biwgTWFydGluOyBSb2dlciBNYXJzaGFsbDsgSmFtZXMgTS4gUG9sazsgc2lwY29yZUBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IGNvbXBvc2l0aW9uIG9yIGp1c3QgaW5kaXJlY3Rpb24gKHdhczogbG9j YXRpb24tY29udmV5YW5jZS0wMyBqdXN0IHN1Ym1pdHRlZCkNCg0KDQpJ4oCZbSBzdXJlIHdl4oCZ cmUgYWxsIGdvaW5nIHRvIGhhdmUgdG8gZGlzY3VzcyB0aGlzIGEgYml0IGluIE1hYXN0cmljaHQs IGJ1dCB0aGVyZSBhcmUgYSBjb3VwbGUgYmFzaWMgcG9pbnRzIGhlcmUgSSB0aGluayB3ZSBuZWVk IHRvIHRlZSB1cC4gSSBjZXJ0YWlubHkgZGlkbuKAmXQgbWVhbiB0byBzdWdnZXN0IHRoYXQgYSBy ZXF1ZXN0IGNhbiBvbmx5IGluY2x1ZGUgYSBzaW5nbGUgbG9jYXRpb24gKGkuZS4sIHRoYXQgYW55 IGNvbnRyaWJ1dGluZyBwaWVjZSBvZiBsb2NhdGlvbiBpbmZvcm1hdGlvbiBkZXNpZ25hdGVzIHRo ZSBzYW1lIHBsYWNlLCBqdXN0IHdpdGggdmFyeWluZyBkZWdyZWVzIG9mIGFjY3VyYWN5IG9yIHRp bWVsaW5lc3Mgb3Igc29tZXRoaW5nKS4gUmF0aGVyLCBJIGJlbGlldmUgYSBwcmVzZW5jZSBkb2N1 bWVudCBkZXNjcmliZXMgYSBzaW5nbGUgZW50aXR5IOKAkyBtdWx0aXBsZSBsb2NhdGlvbnMgY29t ZSBhYm91dCBiZWNhdXNlIHZhcmlvdXMgZGV2aWNlcyBhbmQgc2VydmljZXMgYXNzb2NpYXRlZCB3 aXRoIHRoYXQgc2luZ2xlIGVudGl0eSBtYXkgYXR0cmlidXRlIHZhcmlvdXMgbG9jYXRpb25zIHRv IHRoZSBlbnRpdHkuDQoNCkdldHRpbmcgYmFjayB0byBmdW5kYW1lbnRhbHMsIHdlIGRvbuKAmXQg bmVlZCBhIEdlb2xvY2F0aW9uIGhlYWRlciBpbiBvcmRlciB0byBjYXJyeSBsb2NhdGlvbiBpbiBT SVAuIFRoZXJlIGFyZSBNSU1FIGJvZGllcyBmb3IgdGhhdCAoaW5jbHVkaW5nIENvbnRlbnQtSW5k aXJlY3Rpb24gYm9kaWVzIGZvciBMYnlSLCBvciBwZXJoYXBzIENvbnRlbnQtTG9jYXRpb24gYXMg eW91IHN1Z2dlc3QpLCBhbmQgd2UgY2FuIGluY2x1ZGUgc2V2ZW50ZWVuIGRpZmZlcmVudCBsb2Nh dGlvbiBvYmplY3RzIGlmIHdlIHdhbnQgdG8sIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB0aGVyZSBh cmUgemVybyBvciBvbmUgb3IgZmlmdGVlbiBHZW9sb2NhdGlvbiBoZWFkZXJzLiBXZSBkb27igJl0 IG5lZWQgYSBsb2NhdGlvbiBjb252ZXlhbmNlIHNwZWNpZmljYXRpb24gb3IgYSBHZW9sb2NhdGlv biBoZWFkZXIgdG8gZW5hYmxlIHRoYXQsIFNJUCBoYXMgYWx3YXlzIGJlZW4gYWJsZSB0byBkbyBp dCwgYW5kIHlvdeKAmWxsIHN0aWxsIGJlIGFibGUgdG8gYWRkIHJhbmRvbSBNSU1FIGJvZGllcyB0 aGF0IGNvbnRhaW4gbG9jYXRpb24gaW5mb3JtYXRpb24gZXZlbiBpZiB0aGVyZSBpcyBhIEdlb2xv Y2F0aW9uIGhlYWRlciB3aGljaCBkb2VzIG5vdCBwb2ludCB0byB0aGVtLiBTbyB3aGF0IGRvZXMg dGhlIEdlb2xvY2F0aW9uIGhlYWRlciBhbmQgbG9jYXRpb24gY29udmV5YW5jZSBzcGVjaWZpY2F0 aW9uIGJ1eSB1cz8NCg0KSeKAmXZlIGFsd2F5cyBuYWl2ZWx5IHRob3VnaHQgdGhhdCB0aGUgR2Vv bG9jYXRpb24gaGVhZGVyIHByb3ZpZGVzIGEgY291cGxpbmcgYmV0d2VlbiB0aGlzIHBhcnRpY3Vs YXIgU0lQIHNlc3Npb24gYW5kIGFuIGVudGl0eSB3aG9zZSBsb2NhdGlvbiBpcyBkZXNpZ25hdGVk IGJ5IGEgUElERiBkb2N1bWVudC4gVGhlIGVudGl0eSBpcyB0aGUgZ2VvcHJpdiBUYXJnZXQsIGFu ZCBpcyBwcm9iYWJseSAodGhvdWdoIG5vdCBuZWNlc3NhcmlseSkgcmVsYXRlZCB0byB0aGUgcGFy dHkgaWRlbnRpZmllZCBieSB0aGUgY2xhc3NpYyBGcm9tIGhlYWRlciBmaWVsZCBvZiB0aGUgU0lQ IHJlcXVlc3QuIFRoZSBHZW9sb2NhdGlvbiBoZWFkZXIgdGVsbHMgdXMgdGhhdCBmb3IgdGhlIHB1 cnBvc2VzIG9mIHRoZSBTSVAgc2Vzc2lvbiBiZWluZyBuZWdvdGlhdGVkLCB0aGUgbG9jYXRpb24g b2YgdGhpcyBUYXJnZXQgaXMgc29tZWhvdyByZWxldmFudC4uLiB0aGUgYm9sZGVzdCBpbnRlcnBy ZXRhdGlvbiB3b3VsZCBiZSB0aGF0IHRoaXMgVGFyZ2V04oCZcyBsb2NhdGlvbiBzaG91bGQgYmUg Y29uc2lkZXJlZCB0aGUgc291cmNlIG9mIHRoZSByZXF1ZXN0LiBKdXN0IGF0dGFjaGluZyBsb2Nh dGlvbi1hd2FyZSBNSU1FIGJvZGllcyB3aXRob3V0IHRoZSBHZW9sb2NhdGlvbiBoZWFkZXIgdG8g U0lQIHJlcXVlc3RzIGRvZXNu4oCZdCBjb252ZXkgdGhlIHNhbWUgc2VtYW50aWNzIOKAkyB0aG9z ZSBib2RpZXMgY291bGQgbWVhbiBhbnl0aGluZywgYW5kIHByZXN1bWFibHkgdGhlIHJlY2Vpdmlu ZyBhcHBsaWNhdGlvbiB3b3VsZCBzb3J0IHRocm91Z2ggdGhlbSBhdCBpdHMgZGlzY3JldGlvbi4N Cg0KV2hlcmUgSSBnZXQgY29uZnVzZWQgaXMgd2hlbiBJIHN0YXJ0IHRyeWluZyB0byB1bmRlcnN0 YW5kIHdoYXQgaXQgd291bGQgbWVhbiBzZW1hbnRpY2FsbHkgZm9yIGEgU0lQIHNlc3Npb24gdG8g YmUgY291cGxlZCB3aXRoIG1vcmUgdGhhbiBvbmUgVGFyZ2V0LiBBZ2FpbiwgSSBjYW4gaW1hZ2lu ZSBoeXBvdGhldGljYWxseSBhIFNJUCByZXF1ZXN0IGNvbnRhaW5pbmcgdW5zb3J0ZWQgTUlNRSBi b2RpZXMgdGhhdCB0YWxrIGFib3V0IGRpZmZlcmVudCBUYXJnZXRzIHRvIGFzc2lzdCBzb21lIHNw ZWNpZmljIGFwcGxpY2F0aW9uIHRoYXQga25vd3MgaG93IHRvIHJlY29uY2lsZSB0aGVtLCBidXQg aGVyZSBJIG1lYW4gdXNpbmcgdGhlIEdlb2xvY2F0aW9uIGhlYWRlciB0byBjb3VwbGUgYSBTSVAg cmVxdWVzdCB3aXRoIGxvY2F0aW9uIGluZm9ybWF0aW9uIGFib3V0IGRpZmZlcmVudCBUYXJnZXRz LiBJcyB0aGVyZSBhY3R1YWxseSBhIHVzZSBjYXNlL3JlcXVpcmVtZW50IGZvciB0aGF0PyBJZiBu b3QsIGFuZCB3ZSBvbmx5IHdhbnQgdG8gY291cGxlIGEgU0lQIHJlcXVlc3Qgd2l0aCBvbmUgVGFy Z2V0LCB0aGVuIEkgZmFpbCB0byBzZWUgd2h5IGNvbXBvc2luZyBsb2NhdGlvbiBpbmZvcm1hdGlv biBhYm91dCB0aGUgc2FtZSBUYXJnZXQgaW50byBhIHNpbmdsZSBQSURGIGJvZHkgd291bGQgYmUg YSBwcm9ibGVtLiBIYXZpbmcgbG9jYXRpb24gaW5mb3JtYXRpb24gYWJvdXQgdGhlIHNhbWUgZW50 aXR5IGZhaWwgdG8gYmUgb3JnYW5pemVkIGluIG9uZSBib2R5IHRocm91Z2ggUkZDNDQ3OSB3b3Vs ZG7igJl0IG1ha2Ugc2Vuc2UsIGFueXdheS4NCg0KSSB0aGluayBpZiB3ZSB1bmRlcnN0YW5kIHRo ZSBzZW1hbnRpY3MgYnkgd2hpY2ggdGhlIEdlb2xvY2F0aW9uIGhlYWRlciDigJxjb3VwbGVz4oCd IFBJREYgd2l0aCBhIFNJUCBzZXNzaW9uLCB0aGVuIHdl4oCZbGwgYmV0dGVyIHVuZGVyc3RhbmQg YWxsIG9mIHRoaXMuIElmIHRoZSBHZW9sb2NhdGlvbiBoZWFkZXIgb25seSBleGlzdHMgdG8gbm90 aWZ5IGxhenkgaW50ZXJtZWRpYXJpZXMgdGhhdCB0aGVyZSBhcmUgbG9jYXRpb24tc2Vuc2l0aXZl IGJvZGllcyBpbiB0aGUgcmVxdWVzdCBvciBzb21ld2hlcmUgb3V0IG9uIHRoZSBuZXQsIHdpdGhv dXQgaW1wbHlpbmcgYW55dGhpbmcgYWJvdXQgdGhlIFRhcmdldCBvciB0aGUgcmVsYXRpb25zaGlw IG9mIHRob3NlIGxvY2F0aW9ucyB0byB0aGUgU0lQIHJlcXVlc3QsIHRoZW4gdGhpcyB3aG9sZSBz cGVjaWZpY2F0aW9uIGlzIHByb2JhYmx5IG1vcmUgdHJvdWJsZSB0aGFuIGl04oCZcyB3b3J0aCDi gJMgaXQgcmVhbGx5IHdvdWxkbuKAmXQgcHJvdmlkZSBtdWNoIGluY3JlbWVudGFsIHZhbHVlIGFi b3ZlIHRoZSBiYXNpYyBhYmlsaXR5IG9mIFNJUCB0byBjYXJyeSBhbGwgc29ydHMgb2YgYm9kaWVz LCBpbmNsdWRpbmcgbG9jYXRpb24gYm9kaWVzLiBJZiB0aGVyZSBhcmUsIGhvd2V2ZXIsIG1vcmUg YmluZGluZyBzZW1hbnRpY3MgaGVyZSwgdGhlbiB3ZSBwcm9iYWJseSB3b27igJl0IGJlIGFibGUg dG8gYWdyZWUgb24gdGhlIG5lZWQgZm9yIHNvbGl0YXJ5IG9yIG11bHRpcGxlIEdlb2xvY2F0aW9u IGhlYWRlcnMgdW50aWwgd2UgYWdyZWUgb24gd2hhdCB0aG9zZSBzZW1hbnRpY3MgYXJlLg0KDQpK b24gUGV0ZXJzb24NCk5ldVN0YXIsIEluYy4NCg0KDQpPbiA3LzE4LzEwIDc6MjUgUE0sICJUaG9t c29uLCBNYXJ0aW4iIDxNYXJ0aW4uVGhvbXNvbkBhbmRyZXcuY29tPiB3cm90ZToNCkhpIEpvbiwN Cg0KSSBhZG1pdCBhIGZhaXIgZGVncmVlIG9mIHN5bXBhdGh5IGZvciBSb2dlcuKAmXMgc3VnZ2Vz dGlvbi4gIEFmdGVyIGFsbCwgdGhlIGFiaWxpdHkgdG8gaW5jbHVkZSBtdWx0aXBsZSBsb2NhdGlv biDigJx2YWx1ZXPigJ0gaW4gdGhlIHNhbWUgU0lQIHJlcXVlc3QgaXMgYSBmZWF0dXJlIHRoYXQg aGFzIGV4aXN0ZWQgZm9yIG1hbnkgeWVhcnMuICBBIG51bWJlciBvZiBpbXBsZW1lbnRhdGlvbnMg aGF2ZSBjb21lIHRvIHJlbHkgb24gdGhpcyBtZWNoYW5pc207IHBlb3BsZSBhcmUgYnVpbGRpbmcg YW5kIGhhdmUgYnVpbHQgc29sdXRpb25zIGJhc2VkIG9uIGVhcmxpZXIgZHJhZnQsIGZ1bGx5IGF3 YXJlIG9mIHRoZSByaXNrcyBpbiBpbXBsZW1lbnRpbmcgYW4gaW50ZXJuZXQgZHJhZnQuDQoNCkF0 IHNvbWUgcG9pbnQsIGl0IG1pZ2h0IGJlIG5lY2Vzc2FyeSB0byBzd2FsbG93IGFueSBkaXNjb21m b3J0IGFuZCByZWNvZ25pemUgdGhhdCB0aGUgY29uc2VxdWVuY2VzIG9mIGFuIGltcGVyZmVjdCBz b2x1dGlvbiBhcmUgbGVzcyB0aGFuIHRoZSBjb25zZXF1ZW5jZXMgb2YgYSBjaGFuZ2Ugb2YgdGhl IG5hdHVyZSB5b3Ugc3VnZ2VzdC4NCg0KQWx0ZXJpbmcgcGVyc3BlY3RpdmUgbWlnaHQgb2ZmZXIg YSBzb2x1dGlvbi4NCg0KVGhlIGlkZWEgdGhhdCB0aGVyZSBhcmUgbXVsdGlwbGUgaXRlbXMgdGhh dCBhcmUgY29tcG9zaXRlZCBtaWdodCBiZSBjb3VudGVycHJvZHVjdGl2ZS4gIEluIHRoaXMgd29y bGQtdmlldywgeW91IGhhdmUgdG8gcmVjb25jaWxlIGEgbnVtYmVyIG9mIHBlcnNwZWN0aXZlcy4g IEluIHRoaXMsIHlvdSBhcmUgYWJzb2x1dGVseSBjb3JyZWN0OiBkb2luZyB0aGF0IGF0IHR3byBs YXllcnMgaXMgYmFkLiAgQ29tcG9zaXRpb24gaXMgYSBoYXJkIHByb2JsZW0gYWxyZWFkeS4gIE1v dmluZyBpdCBpbnRvIFNJUCBvbmx5IGNvbXBsaWNhdGVzIGl0IGZ1cnRoZXIuDQoNClRoZSBhbHRl cm5hdGl2ZSBpcyB0byBpbWFnaW5lIGEgc2luZ2xlIGxvZ2ljYWwgcmVzb3VyY2UgdGhhdCByZXBy ZXNlbnRzIHRoZSBsb2NhdGlvbiBvZiB0aGUgVGFyZ2V0LiAgQSBsb2NhdGlvbiBieSB2YWx1ZSBp cyBhIHJlcHJlc2VudGF0aW9uIG9mIHRoaXMgcmVzb3VyY2U6IGEgc25hcHNob3QuICBMb2NhdGlv biBieSByZWZlcmVuY2Ugb2ZmZXJzIGEgbWVhbnMgZm9yIGFueSBlbnRpdHkgdG8gaWRlbnRpZnkg YW5kIGFjcXVpcmUgYSB2aWV3IG9mIHRoZSByZXNvdXJjZSwgaW5kZXBlbmRlbnQgb2YgdGhhdCBz bmFwc2hvdC4gIFRoZSBhdXRob3JpdHkgZm9yIHRoZSByZXNvdXJjZSBtaWdodCBvZmZlciB0aGUg c2FtZSByZXByZXNlbnRhdGlvbiwgb3IgaXQgY291bGQgb2ZmZXIgb25lIGJldHRlciBzdWl0ZWQg dG8gdGhlIHJlY2lwaWVudC4gIFRoZSByZXByZXNlbnRhdGlvbiBtaWdodCBiZSB1cGRhdGVkLCBp dCBtaWdodCBiZSBhbHRlcmVkIGJhc2VkIG9uIGFuIGF1dGhvcml6YXRpb24gcG9saWN5LCBvciBz b21ldGhpbmcgZWxzZSAobGFuZ3VhZ2UgcHJlZmVyZW5jZXMpLiAgUmVnYXJkbGVzcyBvZiBob3cg aXQgaXMgcmVwcmVzZW50ZWQsIGl0IGlzIHN0aWxsIHRoZSBzYW1lIHJlc291cmNlLg0KDQpJbiBz aW1wbGUgdGVybXMsIHlvdSBzdGF0ZSB0aGF0IHRoZSByZXF1ZXN0IGNhbiBvbmx5IGluY2x1ZGUg YSBzaW5nbGUgX2xvY2F0aW9uXy4gIFdoZW4gYSBsb2NhdGlvbiB2YWx1ZSBhbmQgcmVmZXJlbmNl IGFyZSBib3RoIGluY2x1ZGVkLCB0aGV5IHJlcHJlc2VudCB0aGUgX3NhbWVfIGxvY2F0aW9uLg0K DQpUaGlzIGlzIHdoeSBJIHN1Z2dlc3RlZCB0aGF0IENvbnRlbnQtTG9jYXRpb24gYmUgYm9ycm93 ZWQuICBJbiBIVFRQLCBDb250ZW50LUxvY2F0aW9uIHNheXMgLSBpZiB5b3Ugd2FudCB0byBrbm93 IHdoZXJlIHRoaXMgcmVzb3VyY2UgcmVhbGx5IGxpdmVzLCBoZXJlIGlzIHdoZXJlIHlvdSBjYW4g ZmluZCBpdC4NCg0KTm93IHRoaXMgbWlnaHQgYmUgc2hlZXIgc29waGlzdHJ5LCBidXQgaXQgbWln aHQgb2ZmZXIgYSB3YXkgb3V0LiAgVGhlIGNvbXBvc2l0aW9uIHByb2JsZW1zIGFyZSBsZWZ0IG91 dCBvZiBTSVAuDQoNCuKApg0K --_000_8B0A9FCBB9832F43971E38010638454F03EB7730BASISPE7MB1comm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRl bnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1H ZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0K PHRpdGxlPlJlOiBjb21wb3NpdGlvbiBvciBqdXN0IGluZGlyZWN0aW9uICh3YXM6IGxvY2F0aW9u LWNvbnZleWFuY2UtMDMganVzdA0Kc3VibWl0dGVkKTwvdGl0bGU+DQo8c3R5bGU+DQo8IS0tDQog LyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJy aWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1 IDQgNCAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MG1tOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMjQ0MDYxO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQg NzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT4NCjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tQVUgbGluaz1ibHVl IHZsaW5rPXB1cnBsZT4NCg0KPGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+UmVzb2x2aW5nIHRoZSBzZW1hbnRpY3Mg b2YgdGhlIGhlYWRlciBpcyB0aGUgYmlnZ2VzdCBwcm9ibGVtLsKgIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYxJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K Y29sb3I6IzI0NDA2MSc+TXkgb3JpZ2luYWwgdmlldyB3YXMgdGhhdCB0aGUgaW50ZW50IHdhcyB0 byBjb252ZXkgdGhlIG1lc3NhZ2UNCnRoYXQgdGhlIHJlZmVyZW5jZWQgbG9jYXRpb24gaW5mb3Jt YXRpb24gaXMgZm9yIHRoZSBlbnRpdHkgaWRlbnRpZmllZCBpbiB0aGUNCkZyb20gaGVhZGVyLiDC oFRoZSBpZGVhIHdhcyB0aGUgU0lQIHJlcXVlc3QgZm9yZ2VkIGEgbGluayBiZXR3ZWVuIHRoZSBp ZGVudGl0eQ0KYW5kIHRoZSBsb2NhdGlvbiBpbiB0aGUgUElERi1MTyBkb2N1bWVudC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0 NDA2MSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCmNvbG9yOiMyNDQwNjEnPkkgd2FzIGxhdGVyIGNvbnZpbmNlZCB0aGF0IHRoaXMg c29ydCBvZiBzdHJvbmcgc2VtYW50aWMgd2FzDQp1bm5lY2Vzc2FyeS7CoCBUaGUgaWRlYSBvZiDi gJxyZWxldmFuY2XigJ0gaXMgYSBiZXR0ZXIgd2F5IG9mIGFwcHJvYWNoaW5nIHRoZQ0KcHJvYmxl bS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K Y29sb3I6IzI0NDA2MSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMyNDQwNjEnPkxvY2F0aW9uIGNhbiBiZSBjb252ZXll ZCBpbiBTSVAgYWxyZWFkeSwgc28gaWYgdGhlIGhlYWRlciBpcyB0bw0KaGF2ZSBhbnkgdmFsdWUs IGl0IG5lZWRzIGEgY2xlYXJseSBkZWZpbmVkIHNlbWFudGljLsKgIEhvdyBhYm91dDo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0 NDA2MSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 DQpmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMyNDQwNjEnPlRoZSBH ZW9sb2NhdGlvbiBoZWFkZXIgaWRlbnRpZmllcw0KYSBQSURGIGRvY3VtZW50IGJ5IHZhbHVlIG9y IHJlZmVyZW5jZS7CoCBBIEdlb2xvY2F0aW9uIGhlYWRlciBpbmRpY2F0ZXMgdGhhdCBhKSB0aGlz DQpwYXJ0aWN1bGFyIFBJREYgZG9jdW1lbnQgY29udGFpbnMgbG9jYXRpb24gaW5mb3JtYXRpb24g YW5kIGIpIHRoYXQgdGhpcyBsb2NhdGlvbg0KaW5mb3JtYXRpb24gaW4gcGFydGljdWxhciBtYXkg YmUgcmVsZXZhbnQgdG8gdGhlIHByb2Nlc3Npbmcgb2YgdGhlIFNJUCByZXF1ZXN0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0 MDYxJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+VGhpcyBpcyBpbnRlbnRpb25hbGx5IHNvZnQsIGJ1dCAo SSBiZWxpZXZlKSBub3QgdG9vIHZhZ3VlLiDCoFllcywNCnlvdSBjYW4gbWFrZSB0aGUgbGVhcCBm cm9tIHRoaXMgdG8gY29uY2x1ZGUgdGhhdCB0aGUgVGFyZ2V0IGFuZCB0aGUgcmVxdWVzdA0Kb3Jp Z2luYXRvciBhcmUgb25lIGFuZCB0aGUgc2FtZS7CoCBBIHNob3J0ZXIganVtcCB3b3VsZCBiZSB0 byBzYXkgdGhhdCB0aGVzZQ0KZW50aXRpZXMgYXJlIGF0IHRoZSBzYW1lIGxvY2F0aW9uLiDCoFRo ZXNlIHN0cm9uZ2VyIHNlbWFudGljcyBhcmUgdW5uZWNlc3NhcnnigKYNCm9yIGF0IGxlYXN0IGhh cmQgdG8gcHJvdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCmNvbG9yOiMyNDQwNjEnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYxJz4tLTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYx Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KY29sb3I6IzI0NDA2MSc+VGhlIHJlYXNvbiB0aGF0IEkgcHJvcG9zZWQgQ29udGVudC1M b2NhdGlvbiBpcyBiZWNhdXNlIGl0IGRvZXMNCmF3YXkgd2l0aCB0aGUgaWRlYSB0aGF0IHRoZXJl IGFyZSBtdWx0aXBsZSBzb3VyY2VzLsKgIEluc3RlYWQsIGl0IGlkZW50aWZpZXMgYQ0Kc2luZ2xl IGF1dGhvcml0eSBhbmQgcmVzb3VyY2UuwqAgVGhhdCBhdXRob3JpdHkgbWlnaHQgY29tcG9zZSBt dWx0aXBsZSBzb3VyY2VzLA0KYnV0IHRoYXQgYmVjb21lcyBvcGFxdWUuwqAgSWYgSSB0aGluayBv ZiBhIHNpbmdsZSBIVFRQIHJlc291cmNlLCB0aGUgaWRlYSB0aGF0DQp0aGUgcmVzb3VyY2UgbWln aHQgaGF2ZSBkaWZmZXJlbnQgcmVwcmVzZW50YXRpb25zIGRvZXNu4oCZdCBjYXVzZSAobXVjaCkg Y29uc3Rlcm5hdGlvbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYxJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+VGhlIGJpZ2dl ciBwcm9ibGVtIGFyaXNlcyB3aGVuIHlvdSBhbGxvdyBmcmVlIHJlaWduIHRvIGRpZmZlcmVudA0K YXV0aG9yaXRpZXMgd2hpY2ggZWFjaCBoYXZlIHRoZWlyIGRpZmZlcmVudCB2aWV3cy7CoCBBbGxv dyB0aGUgaW5jbHVzaW9uIG9mIHN0YXRpYw0KYW5kIGR5bmFtaWMsIGJ1dCBtYWtlIGl0IGNsZWFy IHRoYXQgYm90aCBzdGF0aWMgYW5kIGR5bmFtaWMgaGF2ZSB0byBiZSB0aGUgc2FtZQ0KdGhpbmcv cmVzb3VyY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCmNvbG9yOiMyNDQwNjEnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYxJz5PbmNlIGEgc2luZ2xlIGF1 dGhvcml0eSBpcyBpc29sYXRlZCwgdGhlbiBhbGwgeW91IGhhdmUgdG8gd29ycnkNCmFib3V0IGlz IHRoZSBjb250ZW50cyBvZiB0aGUgUElERi7CoCBXZSBoYXZlIHRoZSBtZWFucyB0byBkZWFsIHdp dGggdGhhdCB3aXRoIDQ0NzkNCihpbiBnZW5lcmFsKSBhbmQgNTQ5MSAoZm9yIGxvY2F0aW9uIHNw ZWNpZmljYWxseSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCmNvbG9yOiMyNDQwNjEnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYxJz5BbmQgdGhlIFVBQyBt YWtlcyB0aGUgZGVjaXNpb24gYWJvdXQgd2hpY2ggYXV0aG9yaXR5IHRvIG5vbWluYXRlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjoj MjQ0MDYxJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+LS1NYXJ0aW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9y OiMyNDQwNjEnPnAucy4gTm90ZSB0aGF0IHRoZSBkZWZpbml0aW9uIHdvcmRpbmcgYWJvdmUgd291 bGQgcHJlY2x1ZGUgdGhlDQp1c2Ugb2YgYSBnZW86IFVSSS4gwqBJ4oCZbSBvcGVuIHRvIG1ha2lu ZyB0aGUgc3RhdGVtZW50IGZ1enppZXIsIGlmIHRoZXJlIGlzDQpjb25zZW5zdXMgdGhhdCBvdGhl ciBsb2NhdGlvbiBmb3JtYXRzIGFyZSBhY2NlcHRhYmxlIG9yIGRlc2lyYWJsZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2 MSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MG1tIDBtbSAwbW0gNC4wcHQn Pg0KDQo8ZGl2Pg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwbW0gMG1tIDBtbSc+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5Og0KIlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIic+IFBldGVyc29uLCBKb24NClttYWlsdG86am9uLnBldGVyc29uQG5ldXN0YXIuYml6 XSA8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgMjAgSnVseSAyMDEwIDc6MjkgQU08YnI+DQo8 Yj5Ubzo8L2I+IFRob21zb24sIE1hcnRpbjsgUm9nZXIgTWFyc2hhbGw7IEphbWVzIE0uIFBvbGs7 IHNpcGNvcmVAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IGNvbXBvc2l0aW9uIG9y IGp1c3QgaW5kaXJlY3Rpb24gKHdhczoNCmxvY2F0aW9uLWNvbnZleWFuY2UtMDMganVzdCBzdWJt aXR0ZWQpPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7DQpmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48YnI+DQpJ4oCZbSBzdXJl IHdl4oCZcmUgYWxsIGdvaW5nIHRvIGhhdmUgdG8gZGlzY3VzcyB0aGlzIGEgYml0IGluIE1hYXN0 cmljaHQsIGJ1dCB0aGVyZQ0KYXJlIGEgY291cGxlIGJhc2ljIHBvaW50cyBoZXJlIEkgdGhpbmsg d2UgbmVlZCB0byB0ZWUgdXAuIEkgY2VydGFpbmx5IGRpZG7igJl0DQptZWFuIHRvIHN1Z2dlc3Qg dGhhdCBhIHJlcXVlc3QgY2FuIG9ubHkgaW5jbHVkZSBhIHNpbmdsZSBsb2NhdGlvbiAoaS5lLiwg dGhhdA0KYW55IGNvbnRyaWJ1dGluZyBwaWVjZSBvZiBsb2NhdGlvbiBpbmZvcm1hdGlvbiBkZXNp Z25hdGVzIHRoZSBzYW1lIHBsYWNlLCBqdXN0DQp3aXRoIHZhcnlpbmcgZGVncmVlcyBvZiBhY2N1 cmFjeSBvciB0aW1lbGluZXNzIG9yIHNvbWV0aGluZykuIFJhdGhlciwgSSBiZWxpZXZlDQphIHBy ZXNlbmNlIGRvY3VtZW50IGRlc2NyaWJlcyBhIHNpbmdsZSBlbnRpdHkg4oCTIG11bHRpcGxlIGxv Y2F0aW9ucyBjb21lIGFib3V0DQpiZWNhdXNlIHZhcmlvdXMgZGV2aWNlcyBhbmQgc2VydmljZXMg YXNzb2NpYXRlZCB3aXRoIHRoYXQgc2luZ2xlIGVudGl0eSBtYXkNCmF0dHJpYnV0ZSB2YXJpb3Vz IGxvY2F0aW9ucyB0byB0aGUgZW50aXR5Ljxicj4NCjxicj4NCkdldHRpbmcgYmFjayB0byBmdW5k YW1lbnRhbHMsIHdlIGRvbuKAmXQgbmVlZCBhIEdlb2xvY2F0aW9uIGhlYWRlciBpbiBvcmRlciB0 bw0KY2FycnkgbG9jYXRpb24gaW4gU0lQLiBUaGVyZSBhcmUgTUlNRSBib2RpZXMgZm9yIHRoYXQg KGluY2x1ZGluZw0KQ29udGVudC1JbmRpcmVjdGlvbiBib2RpZXMgZm9yIExieVIsIG9yIHBlcmhh cHMgQ29udGVudC1Mb2NhdGlvbiBhcyB5b3UNCnN1Z2dlc3QpLCBhbmQgd2UgY2FuIGluY2x1ZGUg c2V2ZW50ZWVuIGRpZmZlcmVudCBsb2NhdGlvbiBvYmplY3RzIGlmIHdlIHdhbnQNCnRvLCByZWdh cmRsZXNzIG9mIHdoZXRoZXIgdGhlcmUgYXJlIHplcm8gb3Igb25lIG9yIGZpZnRlZW4gR2VvbG9j YXRpb24gaGVhZGVycy4NCldlIGRvbuKAmXQgbmVlZCBhIGxvY2F0aW9uIGNvbnZleWFuY2Ugc3Bl Y2lmaWNhdGlvbiBvciBhIEdlb2xvY2F0aW9uIGhlYWRlciB0bw0KZW5hYmxlIHRoYXQsIFNJUCBo YXMgYWx3YXlzIGJlZW4gYWJsZSB0byBkbyBpdCwgYW5kIHlvdeKAmWxsIHN0aWxsIGJlIGFibGUg dG8gYWRkDQpyYW5kb20gTUlNRSBib2RpZXMgdGhhdCBjb250YWluIGxvY2F0aW9uIGluZm9ybWF0 aW9uIGV2ZW4gaWYgdGhlcmUgaXMgYQ0KR2VvbG9jYXRpb24gaGVhZGVyIHdoaWNoIGRvZXMgbm90 IHBvaW50IHRvIHRoZW0uIFNvIHdoYXQgZG9lcyB0aGUgR2VvbG9jYXRpb24NCmhlYWRlciBhbmQg bG9jYXRpb24gY29udmV5YW5jZSBzcGVjaWZpY2F0aW9uIGJ1eSB1cz8gPGJyPg0KPGJyPg0KSeKA mXZlIGFsd2F5cyBuYWl2ZWx5IHRob3VnaHQgdGhhdCB0aGUgR2VvbG9jYXRpb24gaGVhZGVyIHBy b3ZpZGVzIGEgY291cGxpbmcNCmJldHdlZW4gdGhpcyBwYXJ0aWN1bGFyIFNJUCBzZXNzaW9uIGFu ZCBhbiBlbnRpdHkgd2hvc2UgbG9jYXRpb24gaXMgZGVzaWduYXRlZA0KYnkgYSBQSURGIGRvY3Vt ZW50LiBUaGUgZW50aXR5IGlzIHRoZSBnZW9wcml2IFRhcmdldCwgYW5kIGlzIHByb2JhYmx5ICh0 aG91Z2gNCm5vdCBuZWNlc3NhcmlseSkgcmVsYXRlZCB0byB0aGUgcGFydHkgaWRlbnRpZmllZCBi eSB0aGUgY2xhc3NpYyBGcm9tIGhlYWRlcg0KZmllbGQgb2YgdGhlIFNJUCByZXF1ZXN0LiBUaGUg R2VvbG9jYXRpb24gaGVhZGVyIHRlbGxzIHVzIHRoYXQgZm9yIHRoZSBwdXJwb3Nlcw0Kb2YgdGhl IFNJUCBzZXNzaW9uIGJlaW5nIG5lZ290aWF0ZWQsIHRoZSBsb2NhdGlvbiBvZiB0aGlzIFRhcmdl dCBpcyBzb21laG93DQpyZWxldmFudC4uLiB0aGUgYm9sZGVzdCBpbnRlcnByZXRhdGlvbiB3b3Vs ZCBiZSB0aGF0IHRoaXMgVGFyZ2V04oCZcyBsb2NhdGlvbg0Kc2hvdWxkIGJlIGNvbnNpZGVyZWQg dGhlIHNvdXJjZSBvZiB0aGUgcmVxdWVzdC4gSnVzdCBhdHRhY2hpbmcgbG9jYXRpb24tYXdhcmUN Ck1JTUUgYm9kaWVzIHdpdGhvdXQgdGhlIEdlb2xvY2F0aW9uIGhlYWRlciB0byBTSVAgcmVxdWVz dHMgZG9lc27igJl0IGNvbnZleSB0aGUNCnNhbWUgc2VtYW50aWNzIOKAkyB0aG9zZSBib2RpZXMg Y291bGQgbWVhbiBhbnl0aGluZywgYW5kIHByZXN1bWFibHkgdGhlIHJlY2VpdmluZw0KYXBwbGlj YXRpb24gd291bGQgc29ydCB0aHJvdWdoIHRoZW0gYXQgaXRzIGRpc2NyZXRpb24uPGJyPg0KPGJy Pg0KV2hlcmUgSSBnZXQgY29uZnVzZWQgaXMgd2hlbiBJIHN0YXJ0IHRyeWluZyB0byB1bmRlcnN0 YW5kIHdoYXQgaXQgd291bGQgbWVhbg0Kc2VtYW50aWNhbGx5IGZvciBhIFNJUCBzZXNzaW9uIHRv IGJlIGNvdXBsZWQgd2l0aCBtb3JlIHRoYW4gb25lIFRhcmdldC4gQWdhaW4sDQpJIGNhbiBpbWFn aW5lIGh5cG90aGV0aWNhbGx5IGEgU0lQIHJlcXVlc3QgY29udGFpbmluZyB1bnNvcnRlZCBNSU1F IGJvZGllcyB0aGF0DQp0YWxrIGFib3V0IGRpZmZlcmVudCBUYXJnZXRzIHRvIGFzc2lzdCBzb21l IHNwZWNpZmljIGFwcGxpY2F0aW9uIHRoYXQga25vd3MgaG93DQp0byByZWNvbmNpbGUgdGhlbSwg YnV0IGhlcmUgSSBtZWFuIHVzaW5nIHRoZSBHZW9sb2NhdGlvbiBoZWFkZXIgdG8gY291cGxlIGEg U0lQDQpyZXF1ZXN0IHdpdGggbG9jYXRpb24gaW5mb3JtYXRpb24gYWJvdXQgZGlmZmVyZW50IFRh cmdldHMuIElzIHRoZXJlIGFjdHVhbGx5IGENCnVzZSBjYXNlL3JlcXVpcmVtZW50IGZvciB0aGF0 PyBJZiBub3QsIGFuZCB3ZSBvbmx5IHdhbnQgdG8gY291cGxlIGEgU0lQIHJlcXVlc3QNCndpdGgg b25lIFRhcmdldCwgdGhlbiBJIGZhaWwgdG8gc2VlIHdoeSBjb21wb3NpbmcgbG9jYXRpb24gaW5m b3JtYXRpb24gYWJvdXQNCnRoZSBzYW1lIFRhcmdldCBpbnRvIGEgc2luZ2xlIFBJREYgYm9keSB3 b3VsZCBiZSBhIHByb2JsZW0uIEhhdmluZyBsb2NhdGlvbg0KaW5mb3JtYXRpb24gYWJvdXQgdGhl IHNhbWUgZW50aXR5IGZhaWwgdG8gYmUgb3JnYW5pemVkIGluIG9uZSBib2R5IHRocm91Z2gNClJG QzQ0Nzkgd291bGRu4oCZdCBtYWtlIHNlbnNlLCBhbnl3YXkuPGJyPg0KPGJyPg0KSSB0aGluayBp ZiB3ZSB1bmRlcnN0YW5kIHRoZSBzZW1hbnRpY3MgYnkgd2hpY2ggdGhlIEdlb2xvY2F0aW9uIGhl YWRlcg0K4oCcY291cGxlc+KAnSBQSURGIHdpdGggYSBTSVAgc2Vzc2lvbiwgdGhlbiB3ZeKAmWxs IGJldHRlciB1bmRlcnN0YW5kIGFsbCBvZiB0aGlzLiBJZg0KdGhlIEdlb2xvY2F0aW9uIGhlYWRl ciBvbmx5IGV4aXN0cyB0byBub3RpZnkgbGF6eSBpbnRlcm1lZGlhcmllcyB0aGF0IHRoZXJlIGFy ZQ0KbG9jYXRpb24tc2Vuc2l0aXZlIGJvZGllcyBpbiB0aGUgcmVxdWVzdCBvciBzb21ld2hlcmUg b3V0IG9uIHRoZSBuZXQsIHdpdGhvdXQNCmltcGx5aW5nIGFueXRoaW5nIGFib3V0IHRoZSBUYXJn ZXQgb3IgdGhlIHJlbGF0aW9uc2hpcCBvZiB0aG9zZSBsb2NhdGlvbnMgdG8NCnRoZSBTSVAgcmVx dWVzdCwgdGhlbiB0aGlzIHdob2xlIHNwZWNpZmljYXRpb24gaXMgcHJvYmFibHkgbW9yZSB0cm91 YmxlIHRoYW4NCml04oCZcyB3b3J0aCDigJMgaXQgcmVhbGx5IHdvdWxkbuKAmXQgcHJvdmlkZSBt dWNoIGluY3JlbWVudGFsIHZhbHVlIGFib3ZlIHRoZSBiYXNpYw0KYWJpbGl0eSBvZiBTSVAgdG8g Y2FycnkgYWxsIHNvcnRzIG9mIGJvZGllcywgaW5jbHVkaW5nIGxvY2F0aW9uIGJvZGllcy4gSWYN CnRoZXJlIGFyZSwgaG93ZXZlciwgbW9yZSBiaW5kaW5nIHNlbWFudGljcyBoZXJlLCB0aGVuIHdl IHByb2JhYmx5IHdvbuKAmXQgYmUgYWJsZQ0KdG8gYWdyZWUgb24gdGhlIG5lZWQgZm9yIHNvbGl0 YXJ5IG9yIG11bHRpcGxlIEdlb2xvY2F0aW9uIGhlYWRlcnMgdW50aWwgd2UNCmFncmVlIG9uIHdo YXQgdGhvc2Ugc2VtYW50aWNzIGFyZS48YnI+DQo8YnI+DQpKb24gUGV0ZXJzb248YnI+DQpOZXVT dGFyLCBJbmMuPGJyPg0KPGJyPg0KPGJyPg0KT24gNy8xOC8xMCA3OjI1IFBNLCAmcXVvdDtUaG9t c29uLCBNYXJ0aW4mcXVvdDsgJmx0OzxhDQpocmVmPSJNYXJ0aW4uVGhvbXNvbkBhbmRyZXcuY29t Ij5NYXJ0aW4uVGhvbXNvbkBhbmRyZXcuY29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0 Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiInPkhpIEpvbiw8YnI+DQo8YnI+DQpJIGFkbWl0IGEgZmFpciBkZWdyZWUgb2Yg c3ltcGF0aHkgZm9yIFJvZ2Vy4oCZcyBzdWdnZXN0aW9uLiAmbmJzcDtBZnRlciBhbGwsIHRoZQ0K YWJpbGl0eSB0byBpbmNsdWRlIG11bHRpcGxlIGxvY2F0aW9uIOKAnHZhbHVlc+KAnSBpbiB0aGUg c2FtZSBTSVAgcmVxdWVzdCBpcyBhDQpmZWF0dXJlIHRoYXQgaGFzIGV4aXN0ZWQgZm9yIG1hbnkg eWVhcnMuICZuYnNwO0EgbnVtYmVyIG9mIGltcGxlbWVudGF0aW9ucyBoYXZlDQpjb21lIHRvIHJl bHkgb24gdGhpcyBtZWNoYW5pc207IHBlb3BsZSBhcmUgYnVpbGRpbmcgYW5kIGhhdmUgYnVpbHQg c29sdXRpb25zDQpiYXNlZCBvbiBlYXJsaWVyIGRyYWZ0LCBmdWxseSBhd2FyZSBvZiB0aGUgcmlz a3MgaW4gaW1wbGVtZW50aW5nIGFuIGludGVybmV0DQpkcmFmdC48YnI+DQo8YnI+DQpBdCBzb21l IHBvaW50LCBpdCBtaWdodCBiZSBuZWNlc3NhcnkgdG8gc3dhbGxvdyBhbnkgZGlzY29tZm9ydCBh bmQgcmVjb2duaXplDQp0aGF0IHRoZSBjb25zZXF1ZW5jZXMgb2YgYW4gaW1wZXJmZWN0IHNvbHV0 aW9uIGFyZSBsZXNzIHRoYW4gdGhlIGNvbnNlcXVlbmNlcw0Kb2YgYSBjaGFuZ2Ugb2YgdGhlIG5h dHVyZSB5b3Ugc3VnZ2VzdC48YnI+DQo8YnI+DQpBbHRlcmluZyBwZXJzcGVjdGl2ZSBtaWdodCBv ZmZlciBhIHNvbHV0aW9uLjxicj4NCjxicj4NClRoZSBpZGVhIHRoYXQgdGhlcmUgYXJlIG11bHRp cGxlIGl0ZW1zIHRoYXQgYXJlIGNvbXBvc2l0ZWQgbWlnaHQgYmUNCmNvdW50ZXJwcm9kdWN0aXZl LiAmbmJzcDtJbiB0aGlzIHdvcmxkLXZpZXcsIHlvdSBoYXZlIHRvIHJlY29uY2lsZSBhIG51bWJl ciBvZg0KcGVyc3BlY3RpdmVzLiAmbmJzcDtJbiB0aGlzLCB5b3UgYXJlIGFic29sdXRlbHkgY29y cmVjdDogZG9pbmcgdGhhdCBhdCB0d28NCmxheWVycyBpcyBiYWQuICZuYnNwO0NvbXBvc2l0aW9u IGlzIGEgaGFyZCBwcm9ibGVtIGFscmVhZHkuICZuYnNwO01vdmluZyBpdA0KaW50byBTSVAgb25s eSBjb21wbGljYXRlcyBpdCBmdXJ0aGVyLjxicj4NCjxicj4NClRoZSBhbHRlcm5hdGl2ZSBpcyB0 byBpbWFnaW5lIGEgc2luZ2xlIGxvZ2ljYWwgcmVzb3VyY2UgdGhhdCByZXByZXNlbnRzIHRoZQ0K bG9jYXRpb24gb2YgdGhlIFRhcmdldC4gJm5ic3A7QSBsb2NhdGlvbiBieSB2YWx1ZSBpcyBhIHJl cHJlc2VudGF0aW9uIG9mIHRoaXMNCnJlc291cmNlOiBhIHNuYXBzaG90LiAmbmJzcDtMb2NhdGlv biBieSByZWZlcmVuY2Ugb2ZmZXJzIGEgbWVhbnMgZm9yIGFueSBlbnRpdHkNCnRvIGlkZW50aWZ5 IGFuZCBhY3F1aXJlIGEgdmlldyBvZiB0aGUgcmVzb3VyY2UsIGluZGVwZW5kZW50IG9mIHRoYXQg c25hcHNob3QuDQombmJzcDtUaGUgYXV0aG9yaXR5IGZvciB0aGUgcmVzb3VyY2UgbWlnaHQgb2Zm ZXIgdGhlIHNhbWUgcmVwcmVzZW50YXRpb24sIG9yIGl0DQpjb3VsZCBvZmZlciBvbmUgYmV0dGVy IHN1aXRlZCB0byB0aGUgcmVjaXBpZW50LiAmbmJzcDtUaGUgcmVwcmVzZW50YXRpb24gbWlnaHQN CmJlIHVwZGF0ZWQsIGl0IG1pZ2h0IGJlIGFsdGVyZWQgYmFzZWQgb24gYW4gYXV0aG9yaXphdGlv biBwb2xpY3ksIG9yIHNvbWV0aGluZw0KZWxzZSAobGFuZ3VhZ2UgcHJlZmVyZW5jZXMpLiAmbmJz cDtSZWdhcmRsZXNzIG9mIGhvdyBpdCBpcyByZXByZXNlbnRlZCwgaXQgaXMNCnN0aWxsIHRoZSBz YW1lIHJlc291cmNlLjxicj4NCjxicj4NCkluIHNpbXBsZSB0ZXJtcywgeW91IHN0YXRlIHRoYXQg dGhlIHJlcXVlc3QgY2FuIG9ubHkgaW5jbHVkZSBhIHNpbmdsZQ0KX2xvY2F0aW9uXy4gJm5ic3A7 V2hlbiBhIGxvY2F0aW9uIHZhbHVlIGFuZCByZWZlcmVuY2UgYXJlIGJvdGggaW5jbHVkZWQsIHRo ZXkNCnJlcHJlc2VudCB0aGUgX3NhbWVfIGxvY2F0aW9uLjxicj4NCjxicj4NClRoaXMgaXMgd2h5 IEkgc3VnZ2VzdGVkIHRoYXQgQ29udGVudC1Mb2NhdGlvbiBiZSBib3Jyb3dlZC4gJm5ic3A7SW4g SFRUUCwNCkNvbnRlbnQtTG9jYXRpb24gc2F5cyAtIGlmIHlvdSB3YW50IHRvIGtub3cgd2hlcmUg dGhpcyByZXNvdXJjZSByZWFsbHkgbGl2ZXMsDQpoZXJlIGlzIHdoZXJlIHlvdSBjYW4gZmluZCBp dC48YnI+DQo8YnI+DQpOb3cgdGhpcyBtaWdodCBiZSBzaGVlciBzb3BoaXN0cnksIGJ1dCBpdCBt aWdodCBvZmZlciBhIHdheSBvdXQuICZuYnNwO1RoZQ0KY29tcG9zaXRpb24gcHJvYmxlbXMgYXJl IGxlZnQgb3V0IG9mIFNJUC48YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0nY29sb3I6IzI0NDA2MSc+ 4oCmPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8 L2JvZHk+DQoNCjwvaHRtbD4NCg== --_000_8B0A9FCBB9832F43971E38010638454F03EB7730BASISPE7MB1comm_-- From hgs@cs.columbia.edu Tue Jul 20 00:16:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B3FEE3A6A01 for ; Tue, 20 Jul 2010 00:16:45 -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 cLrVVbwaeXhR for ; Tue, 20 Jul 2010 00:16:44 -0700 (PDT) Received: from serrano.cc.columbia.edu (serrano.cc.columbia.edu [128.59.29.6]) by core3.amsl.com (Postfix) with ESMTP id A52243A69F7 for ; Tue, 20 Jul 2010 00:16:44 -0700 (PDT) Received: from dyn0807.panoulu.local (gw1.panoulu.net [212.50.147.101]) (user=hgs10 mech=PLAIN bits=0) by serrano.cc.columbia.edu (8.14.4/8.14.3) with ESMTP id o6K7GsDo023886 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 20 Jul 2010 03:16:57 -0400 (EDT) Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Henning Schulzrinne In-Reply-To: Date: Tue, 20 Jul 2010 03:16:54 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: <8E99120B-5177-4DCE-9687-AE239DBB40A8@cs.columbia.edu> References: To: "Richard L. Barnes" X-Mailer: Apple Mail (2.1081) X-No-Spam-Score: Local X-Scanned-By: MIMEDefang 2.68 on 128.59.29.6 Cc: sipcore@ietf.org Subject: Re: [sipcore] Geo URI in location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Jul 2010 07:16:45 -0000 Good idea; the notion of not having by-value locations in the header was = always artificial and had more to do with = how-do-you-stuff-XML-in-a-header than with architectural principles. Henning On Jul 19, 2010, at 5:46 PM, Richard L. Barnes wrote: > What do people think about having support for GEO URIs [1] in a = Geolocation header field? Seems like it would be kind of handy... >=20 > [1] > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 From Hannes.Tschofenig@gmx.net Tue Jul 20 03:23:22 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 654D33A69DF for ; Tue, 20 Jul 2010 03:23:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.26 X-Spam-Level: X-Spam-Status: No, score=-1.26 tagged_above=-999 required=5 tests=[AWL=1.340, 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 vFn12+p6GPSN for ; Tue, 20 Jul 2010 03:23:21 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 2017F3A694C for ; Tue, 20 Jul 2010 03:23:20 -0700 (PDT) Received: (qmail 12690 invoked by uid 0); 20 Jul 2010 10:23:34 -0000 Received: from 213.162.68.136 by www041.gmx.net with HTTP; Tue, 20 Jul 2010 12:23:33 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Date: Tue, 20 Jul 2010 12:23:33 +0200 From: "Hannes Tschofenig" In-Reply-To: Message-ID: <20100720102333.24820@gmx.net> MIME-Version: 1.0 References: To: "Peterson, Jon" , rbarnes@bbn.com X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX18qlMpBCPsqQMqyl2YNNO7aUU5YxCR8x9uApm8wsY qD7YwckQW36yx9eU3uI812k+JdwmXejR6aDg== Content-Transfer-Encoding: 8bit X-GMX-UID: RBUuJPtcTlI8f5sGtWlrrxFOU2poZVkn X-FuHaFi: 0.58999999999999997 Cc: sipcore@ietf.org, Martin.Thomson@andrew.com, RMarshall@telecomsys.com Subject: Re: [sipcore] composition or just indirection (was: location-conveyance-03 just 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: Tue, 20 Jul 2010 10:23:22 -0000 Still trying to catch up with the mail thread but a few basic observations: 1) There is the 'entity' attribute in the element that points to the Target. 2) There is RFC 5491 http://datatracker.ietf.org/doc/rfc5491/ that describes how different location chunks (including "compound location") are interpreted. It also describes the meaning of different location objects in a PIDF-LO. 3) We know that we want to transmit multiple location chunks, and multiple location objects of the same Target. We do not seem to have use cases for transmitting location of >>different<< Targets in the same SIP message. So, this should allow us to carry one of multiple MIME bodies with PIDF-LOs in a SIP message (referring to the same Target) in a single SIP message. The following items are left for discussions, I believe: - How to encode the LbyR (in addition to the LbyV) - Procedures for how an intermediary attaches a reference to a PIDF-LO - Whether there needs to be a relationship between the 'entity' attribute in the element and the From header of a SIP message. I am less interested in the used-for-routing optimizations etc. Did I correctly capture the challenge? Ciao Hannes From Hannes.Tschofenig@gmx.net Tue Jul 20 03:38:20 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B245E3A68A0 for ; Tue, 20 Jul 2010 03:38:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.343 X-Spam-Level: X-Spam-Status: No, score=-1.343 tagged_above=-999 required=5 tests=[AWL=1.256, 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 Uwpnon-+eSmU for ; Tue, 20 Jul 2010 03:38:18 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 3233D3A6A06 for ; Tue, 20 Jul 2010 03:38:09 -0700 (PDT) Received: (qmail 9563 invoked by uid 0); 20 Jul 2010 10:37:51 -0000 Received: from 213.162.68.136 by www160.gmx.net with HTTP; Tue, 20 Jul 2010 12:37:50 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Date: Tue, 20 Jul 2010 12:37:50 +0200 From: "Hannes Tschofenig" In-Reply-To: <201007191843.o6JIhpLv029037@sj-core-5.cisco.com> Message-ID: <20100720103750.197770@gmx.net> MIME-Version: 1.0 References: <20100719081713.77060@gmx.net> <201007191843.o6JIhpLv029037@sj-core-5.cisco.com> To: "James M. Polk" , sipcore@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX18X7YNP9bQXZfQg7NxM5ymnOoXiaSzQgWYGeqMwhA u6vHypPov1JML9BaKvA9y7por1p4v5QA+CQg== Content-Transfer-Encoding: 8bit X-GMX-UID: GhUgDS85fW47Yck5tWRo/yRudmllcsXq X-FuHaFi: 0.69999999999999996 Subject: Re: [sipcore] Location Conveyance Flaw: HTTP/HTTPS Location URI Scheme X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Jul 2010 10:38:20 -0000 > At 03:17 AM 7/19/2010, Hannes Tschofenig wrote: > >Hi, > > > >The authors (or one of them in particular) > > on the IAB and you can't stop attacking publicly? > > hmmmm... > This has nothing to do with the IAB. I am also still a regular IETF participant who may feel unhappy. From Hannes.Tschofenig@gmx.net Tue Jul 20 03:46:18 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 602253A68A0 for ; Tue, 20 Jul 2010 03:46:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.417 X-Spam-Level: X-Spam-Status: No, score=-1.417 tagged_above=-999 required=5 tests=[AWL=1.182, 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 UJB4Gq6hetIs for ; Tue, 20 Jul 2010 03:46:14 -0700 (PDT) Received: from mail.gmx.net (mail.gmx.net [213.165.64.20]) by core3.amsl.com (Postfix) with SMTP id 548F33A683F for ; Tue, 20 Jul 2010 03:46:13 -0700 (PDT) Received: (qmail 4127 invoked by uid 0); 20 Jul 2010 10:46:28 -0000 Received: from 213.162.68.136 by www052.gmx.net with HTTP; Tue, 20 Jul 2010 12:46:25 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Date: Tue, 20 Jul 2010 12:46:25 +0200 From: "Hannes Tschofenig" In-Reply-To: <201007191906.o6JJ6ceZ028407@sj-core-2.cisco.com> Message-ID: <20100720104625.172310@gmx.net> MIME-Version: 1.0 References: <20100719081412.77060@gmx.net> <201007191906.o6JJ6ceZ028407@sj-core-2.cisco.com> To: "James M. Polk" , sipcore@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX18KYohuFFUK4kELUcqvZb/Hq6/4yGy+v58kxILVI/ kLKlXeItPIxpA+r1U3bPhi/x0s/B+cDKrxUg== Content-Transfer-Encoding: 8bit X-GMX-UID: tkZzfX1wYmYBUsVUp3Y3+WtCWkZTQRS/ X-FuHaFi: 0.5 Subject: Re: [sipcore] Location Conveyance Open Issue: Privacy Considerations X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Jul 2010 10:46:18 -0000 Hi James, I was referring to Section 6 in the draft (copied into this mail to make it easier). I would suggest to replace the entire section with a reference to http://datatracker.ietf.org/doc/draft-ietf-geopriv-arch/. Maybe a reference to http://datatracker.ietf.org/doc/rfc5606/ would be useful as well. Hope that makes more sense. Ciao Hannes ----------- 6. Geopriv Privacy Considerations Location information is considered by most to be highly sensitive information, requiring protection from eavesdropping, and altering in transit. [RFC3693] articulates rules to be followed by any protocol wishing to be considered a "Using Protocol", specifying how a transport protocol meets those rules. This section describes how SIP as a Using Protocol meets those requirements. 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. Quoting requirement #5 of [RFC3693]: "The Using Protocol will typically facilitate that the keys associated with the credentials are transported to the respective parties, that is, key establishment is the responsibility of the Using Protocol." [RFC3261] and the documents it references define the key establishment mechanisms. Quoting requirement #6 of [RFC3693]: "(Single Message Transfer) In particular, for tracking of small Target devices, the design should allow a single message/packet transmission of location as a complete transaction." When used for tracking, a simple NOTIFY or UPDATE normally is relatively small, although the PIDF itself can be large. Normal RFC 3261 procedures of reverting to TCP when the MTU size is exceeded would be invoked. ------- Ciao Hannes ---Nachricht -------- > Datum: Mon, 19 Jul 2010 14:06:37 -0500 > Von: "James M. Polk" > An: "Hannes Tschofenig" , sipcore@ietf.org > Betreff: Re: [sipcore] Location Conveyance Open Issue: Privacy Considerations > At 03:14 AM 7/19/2010, Hannes Tschofenig wrote: > >Hi, > > > >quite contrary to what one would assume for such a specification the > >discussion about privacy is extremely weak. > > apparently you haven't read many SIP specifications then. When > securing header values, we recommend TLS per hop. When securing > identity information, we recommend hashing many header values and > include the hash with a url to where to check the hash. When securing > message bodies, encrypt it with S/MIME. > > >It gets even more fuzzy by referencing arbitrary requirements from > >RFC 3693, which do not make a sense for a large number of people. > > private addressing doesn't make sense until one reads RFC 1918. I > could go on and on by listing more than a thousand RFCs whose topics > don't make sense until one reads the RFCs. > > Specifically wrt RFC 3693 - you need to be reminded that the old > SIPPING document on the requirements for carrying location in SIP > (circa 2003) are in the (only) appendix of this ID (and have been > since the first SIP ID on the topic), which require adherence to RFC > 3693, along with RFCs 3261 and 4119 (which also probably doesn't make > sense until one reads it). > > > > > > >I believe we can do better. > > I believe we need to do a better case of reading next time... > > but maybe that's just my opinion > > James > > > >Ciao > >Hannes > > > >_______________________________________________ > >sipcore mailing list > >sipcore@ietf.org > >https://www.ietf.org/mailman/listinfo/sipcore From john.elwell@siemens-enterprise.com Tue Jul 20 03:59:57 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B041B3A6407 for ; Tue, 20 Jul 2010 03:59:57 -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.161, 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 MkJaa9KG2Bmu for ; Tue, 20 Jul 2010 03:59:56 -0700 (PDT) Received: from ms01.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 7A09D3A67EA for ; Tue, 20 Jul 2010 03:59:56 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-907710; Tue, 20 Jul 2010 13:00:09 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id B4A0D1EB82AB; Tue, 20 Jul 2010 13:00:09 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 20 Jul 2010 13:00:09 +0200 From: "Elwell, John" To: "James M. Polk" , "sipcore@ietf.org" Date: Tue, 20 Jul 2010 13:00:08 +0200 Thread-Topic: [sipcore] location-conveyance-03 just submitted Thread-Index: AcsiHatHUUgsdDW9RKGALMHNFk4DHwF2Vfow Message-ID: References: <201007122355.o6CNt6us024310@sj-core-3.cisco.com> In-Reply-To: <201007122355.o6CNt6us024310@sj-core-3.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] location-conveyance-03 just 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: Tue, 20 Jul 2010 10:59:57 -0000 James, These are questions for clarification at this stage, rather than comments. The ABNF for the Geolocation header field allows multiple locationValues an= d multiple routing-params, in any order. The text below seems to limit it t= o 0 or 1 locationValue and 0 or 1 routing-param, and furthermore it limits = it so that the routing-param must be last. It seems this could be expressed= much more precisely, and still quite easily, in the ABNF. Of have I misund= erstood something? Although the text "The Geolocation header field has zero or one locationVal= ue, but=20 MUST NOT contain more than one locationValue." limits the header field to having a maximum of one locationValue, text furt= her down "another=20 instance of the Geolocation header" suggests that there can be multiple instances of the header field and hence= multiple locationValues. So a request can contain multiple locationValues,= but not in the same header field instance. Is this really what is intended= ? Unrelated to the above, concerning the text: "Other URI schemas used in the location URI MUST be reviewed against=20 the RFC 3693 [RFC3693] criteria for a Using Protocol" Who must review? The protocol implementer? How is this testable? John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of James M. Polk > Sent: 13 July 2010 00:55 > To: sipcore@ietf.org > Subject: [sipcore] location-conveyance-03 just submitted >=20 > SIPCORE >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio > n-conveyance-03.txt >=20 > This version is a fairly radical departure from previous versions of=20 > the (long standing) effort. This time the doc didn't grow... >=20 > We added Jon Peterson as a co-author, and he helped in Anaheim=20 > propose a significantly less complex way of specifying location=20 > conveyance for SIP. More than 95% of the doc has been rewritten by=20 > Jon and I, with a net result of 27 less pages of text (52 to 25 now). >=20 > We took out the terms and concepts of following parameters: >=20 > - inserter > - inserted-by > - used-for-routing > - host-id > - node-id >=20 > as well as limiting the number of locationValues to *ONE*, in=20 > a SIP request. >=20 > We removed the ability for SIP intermediaries to add location along=20 > the way unbeknownst to the UAC (with one infrequently used=20 > exception). In this way, location errors are only end-to-end, so=20 > there is no need to identify which entity added location to make sure=20 > the right entity reacted the right way when an error was caused by=20 > the location they inserted, and not that of another entity's inserted=20 > location (which is all very confusing). >=20 > We added the ability for a SIP intermediary to augment a location=20 > with what the UAC should send in a subsequent request, and the=20 > ability to verify this augmentation is present before successfully=20 > processing that request. This is in line with both RFCs 4479 and 5491. >=20 > Comments are appreciated >=20 > James >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From pkyzivat@cisco.com Tue Jul 20 05:51:22 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5FB4A3A6847 for ; Tue, 20 Jul 2010 05:51:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.495 X-Spam-Level: X-Spam-Status: No, score=-10.495 tagged_above=-999 required=5 tests=[AWL=0.104, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZCDXNPdrXbqv for ; Tue, 20 Jul 2010 05:51:21 -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 35EC23A6784 for ; Tue, 20 Jul 2010 05:51:21 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 20 Jul 2010 12:51:36 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6KCpais023325; Tue, 20 Jul 2010 12:51:36 GMT Message-ID: <4C459BD7.9050007@cisco.com> Date: Tue, 20 Jul 2010 08:51:35 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Thomson, Martin" References: <8B0A9FCBB9832F43971E38010638454F03EB772EBB@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F03EB7730BA@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03EB7730BA@SISPE7MB1.commscope.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: Roger Marshall , "sipcore@ietf.org" Subject: Re: [sipcore] composition or just indirection X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Jul 2010 12:51:22 -0000 Thomson, Martin wrote: > How about: > > The Geolocation header identifies a PIDF document by value or > reference. A Geolocation header indicates that a) this particular PIDF > document contains location information and b) that this location > information in particular may be relevant to the processing of the SIP > request. > > This is intentionally soft, but (I believe) not too vague. IMO this is *too* vague. For instance, I might want request that a call be routed *to* the phone closest to some geolocation. That location is also relevant to the processing of the request, but in an entirely different way. Thanks, Paul From adam@nostrum.com Tue Jul 20 09:06:51 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B69E3A6B2C for ; Tue, 20 Jul 2010 09:06:51 -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=[AWL=0.000, 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 ftNrGdWm2lgu for ; Tue, 20 Jul 2010 09:06:46 -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 D4AC03A6B29 for ; Tue, 20 Jul 2010 09:06:41 -0700 (PDT) Received: from hydra-3.local (ppp-70-249-149-233.dsl.rcsntx.swbell.net [70.249.149.233]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6KG6uGO011477 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 20 Jul 2010 11:06:56 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C45C9A0.7030503@nostrum.com> Date: Tue, 20 Jul 2010 11:06:56 -0500 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.4) Gecko/20100608 Thunderbird/3.1 MIME-Version: 1.0 To: Robert Sparks References: <99619466-573D-4CEA-ACCD-3A3D262EB2B0@nostrum.com> <4C3BCEFB.5010201@nostrum.com> <739E9B6D-24B5-4A45-9BC7-0387BFB5CF32@nostrum.com> <4C3CE649.1060309@nostrum.com> <743561D3-35E1-47A6-B6DD-1FD73A0CB274@nostrum.com> <2BC6096B-AEC4-432A-BB10-0C84DAAB4DAF@nostrum.com> In-Reply-To: <2BC6096B-AEC4-432A-BB10-0C84DAAB4DAF@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 70.249.149.233 is authenticated by a trusted mechanism) Cc: sipcore@ietf.org Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-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, 20 Jul 2010 16:06:51 -0000 [as participant] After thinking over Robert's arguments, I believe he is correct -- the change to include "Event" in NOTIFY responses does require this to be an update to 3265. We also need to tighten up the semantics around what it means when an "Event" header field appears in a response, and I think Robert's suggestions are both correct and complete. /a On 7/19/10 14:36, Jul 19, Robert Sparks wrote: > sigh - critical typo correction below: > > On Jul 19, 2010, at 2:24 PM, Robert Sparks wrote: > >> This reply clarified my discomfort - thanks. >> >> Your point of syntactic concession was essential - it made sense to add parameters to the Event header in requests, >> so as a matter of convenience, the draft is reusing the Event header and the new parameters for the special case >> where you are wanting to convey information in a response. The group could well have chosen a new header with >> the same contents for inclusion in responses (I don't think folks explicitly considered this?), but this thing that looked >> like the Event header was around, so it was easier to use that. This is only an issue in that if we ever wanted to more >> generally take advantage of the Event header in responses, whatever we did would be constrained by this document >> and the semantics for an Event header showing up in a 200 to a NOTIFY that it defines. >> >> As it stands, this document needs to do a few things it doesn't yet: >> >> 1) Explicitly call out that the use of the Event header field in responses other than 200 OKs to NOTIFYs is (still) undefined. >> >> 2) Explicitly note than any of the other parameters currently defined for the Event header do > ->NOT<- >> have meaning if copied from >> the NOTIFY into it's 200 OK (so that we don't have people being surprised when they return a 200 OK with an >> expires= with some shorter value and it doesn't shorten their subscription). >> >> 3) State that the event-type can't be changed between the NOTIFY and it's 200 OK (yes, that seems obvious, but..,) >> >> 4) So that someone stumbling across an Event header field in a 200 OK to a NOTIFY can look up what it means, >> this document should update the IANA registry at as follows: >> >> OLD: >> Event o [RFC3265] >> NEW: >> Event o [RFC3265][RFC-ietf-sipcore-event-rate-control] >> >> (btw - I assume it is intended to be ok to use the short-form ("o" ) in responses?) >> >> Personally, because of thought's like what I have in 2) above, I feel there's a good chance we're making another >> ACK-200/ACK-non200 mistake that we could be avoiding. >> >> RjS >> >> >> >> On Jul 13, 2010, at 5:18 PM, Adam Roach wrote: >> >>> On 7/13/10 16:23, Jul 13, Robert Sparks wrote: >>>> I don't think it's as clear-cut as that. >>>> >>>> 4662 used the extension points 3265 expected to be used. >>> Not any more than anything else. The extension points that 3265 defines are new event packages. 4662 uses feature tags to negotiate usage -- a basic SIP extension mechanism. >>> >>> Event-rate-control uses new header field parameters -- another basic SIP extension mechanism. >>> >>>> Someone that had written a network monitor, for example, just using >>>> 3265 for reference could have produced code that made sense out of a stream of messages emitted by implementations of 4662. >>>> >>>> That same code would probably not do the right thing with a stream of messages from this spec >>> I can't imagine why not. It will look like a stream of state information sent in NOTIFY messages. >>> >>> I also don't have a lot of sympathy for the "network monitor" use case as a motivator unless we're going to explicitly deprecate TLS and S/MIME. >>> >>> >>>> - at the very least, it wouldn't know to be looking for Event headers in 200 responses >>> No, and it won't know to care about them either. Which is exactly the right thing to do reaction. >>> >>> The event header fields in responses are there as a syntactic concession -- we needed somewhere to hang the parameters. The actual event name itself can't change. It can be safely ignored by network monitors, and they'll do the right thing. >>> >>>> What does 3265bis say about Event headers in responses to NOTIFYs at the moment? >>> Nothing yet. I have a note to add text addressing this case (as well as the suppressed NOTIFY situation that arises from subnot-etags). >>> >>> /a From jmpolk@cisco.com Tue Jul 20 11:22:43 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3E09E3A67A7 for ; Tue, 20 Jul 2010 11:22:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.422 X-Spam-Level: X-Spam-Status: No, score=-10.422 tagged_above=-999 required=5 tests=[AWL=0.177, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id baJ9-kKATe5N for ; Tue, 20 Jul 2010 11:22:42 -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 4351B3A6C1C for ; Tue, 20 Jul 2010 11:22:42 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAGOGRUyrR7H+/2dsb2JhbACfcnGlXZsxhTIEhACHDg Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-2.cisco.com with ESMTP; 20 Jul 2010 18:22:57 +0000 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 o6KIMtmI011673; Tue, 20 Jul 2010 18:22:57 GMT Received: from mail pickup service by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 11:21:01 -0700 Received: from xbh-rcd-301.cisco.com ([72.163.63.8]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 18:58:52 -0700 Received: from sj-iport-1.cisco.com ([171.71.176.70]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 20:58:48 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 20 Jul 2010 01:26:51 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6K1Qo3n026484; Tue, 20 Jul 2010 01:26:51 GMT Message-Id: <201007200126.o6K1Qo3n026484@sj-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Jul 2010 20:26:49 -0500 To: "Winterbottom, James" , Paul Kyzivat , "James M. Polk" From: "James M. Polk" In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880120E9829415@SISPE7MB1.com mscope.com> References: <20100719081458.77080@gmx.net> <201007191857.o6JIv7in014515@sj-core-1.cisco.com> <2936AA57-EEDC-4B43-BE88-E5BDB5D44C8C@bbn.com> <201007191943.o6JJhIrX004288@sj-core-2.cisco.com> <4C44D2E8.8020904@cisco.com> <5A55A45AE77F5941B18E5457ECAC81880120E9829415@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Jul 2010 01:58:48.0424 (UTC) FILETIME=[17EB2E80:01CB27AF] Cc: "Richard L. Barnes" , Hannes Tschofenig , "sipcore@ietf.org" Subject: Re: [sipcore] Location Conveyance Question: Multiple Location X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Jul 2010 18:22:43 -0000 James I logged your comment from a week ago on this, and Jon also agreed to it. -04 will have this explicitly allowed. James At 06:19 PM 7/19/2010, Winterbottom, James wrote: >By the same token absoluteURI also permits pres:, sip: and sips: URI >schemes, yet these are explicitly called out, presumably because >there is specification work that says how to use them for acquiring >location information. Hannes's comment, and indeed my comment made >nearly a week ago, are simply calling for the inclusion of the http: >and http2: URI schemes to also be included because similar >specification work on how to use these schemes to acquire location >information exists. > >If the argument is that this is covered by the absoluteURI >component, then presumably that is all the ABNF requires, and the >sips: sips: and pres: URI schemes can also be removed. > >Cheers >James > > > > > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf > > Of Paul Kyzivat > > Sent: Tuesday, 20 July 2010 8:34 AM > > To: James M. Polk > > Cc: Richard L. Barnes; Hannes Tschofenig; sipcore@ietf.org > > Subject: Re: [sipcore] Location Conveyance Question: Multiple Location > > > > > > > > James M. Polk wrote: > > > At 02:12 PM 7/19/2010, Richard L. Barnes wrote: > > >> I might be mistaken, but it looks to me as if the header ABNF would > > >> allow the following: > > >> > > >> Geolocation: > , >> foobar> > > > > The ABNF permits that (by virtue of allowing absoluteURI, http: is > > permitted), but the text does not: > > > > The Geolocation header field has zero or one locationValue, but > > MUST NOT contain more than one locationValue. > > > > >sipcore From jmpolk@cisco.com Tue Jul 20 11:25:00 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DFADD3A6BFB for ; Tue, 20 Jul 2010 11:24:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.573 X-Spam-Level: X-Spam-Status: No, score=-9.573 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTcZA3kxRokt for ; Tue, 20 Jul 2010 11:24:57 -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 DECAB3A6B47 for ; Tue, 20 Jul 2010 11:24:56 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiQFABaHRUyrR7Hu/2dsb2JhbACfGVlxpWSbL4JqgkgEhACHDg Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 18:25:11 +0000 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 o6KIP7Ot014104; Tue, 20 Jul 2010 18:25:11 GMT Received: from mail pickup service by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 11:21:58 -0700 Received: from xbh-rcd-102.cisco.com ([72.163.62.139]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 18:58:56 -0700 Received: from sj-iport-2.cisco.com ([171.71.176.71]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 20:58:27 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 20 Jul 2010 01:24:39 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6K1N8PU005489; Tue, 20 Jul 2010 01:23:08 GMT Message-Id: <201007200123.o6K1N8PU005489@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Jul 2010 20:23:07 -0500 To: "Richard L. Barnes" , "Peterson, Jon" From: "James M. Polk" In-Reply-To: <605CEAA0-91F5-4860-A2B6-7E1BAFD3D847@bbn.com> References: <605CEAA0-91F5-4860-A2B6-7E1BAFD3D847@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 20 Jul 2010 01:58:28.0428 (UTC) FILETIME=[0C0008C0:01CB27AF] Cc: Roger Marshall , "sipcore@ietf.org" , "Thomson, Martin" Subject: Re: [sipcore] composition or just indirection (was: location-conveyance-03 just 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: Tue, 20 Jul 2010 18:25:00 -0000 Richard Let's not forget the cost of having more than one=20 document in terms of additive bytes in the=20 request. Adding another or =20 element is not that much more data, whereas=20 adding a second or third PIDF would be a lot more. James At 04:44 PM 7/19/2010, Richard L. Barnes wrote: >While it's correct to say that one presence=20 >document describes a single entity, it's not=20 >necessarily true that multiple presence=20 >documents describe multiple=20 >entities. Regardless of how we define the=20 >entity in the session that is the target (IIRC,=20 >earlier versions said something like "the UAC=20 >that initiated the dialogue"), it seems=20 >plausible that different entities processing a=20 >SIP message might have different ideas as to the=20 >location of the target. In this case, it would=20 >seem plausible to have multiple location objects=20 >in a single message, all of which have the=20 >semantic that they're describing the location of=20 >the target (however the target is coupled to the session). > >Speaking more practically, if we accept the=20 >assertion that multiple location values will be=20 >necessary (whether in a single document or not),=20 >then it seems much cleaner to have them in=20 >separate presence documents, with separate CID=20 >URIs. I don't really see any reason for any of=20 >this to call for more than one Geolocation=20 >header, since you can just add more URIs. > > > >On Jul 19, 2010, at 5:29 PM, Peterson, Jon wrote: > >> >>I=92m sure we=92re all going to have to discuss=20 >>this a bit in Maastricht, but there are a=20 >>couple basic points here I think we need to tee=20 >>up. I certainly didn=92t mean to suggest that a=20 >>request can only include a single location=20 >>(i.e., that any contributing piece of location=20 >>information designates the same place, just=20 >>with varying degrees of accuracy or timeliness=20 >>or something). Rather, I believe a presence=20 >>document describes a single entity =96 multiple=20 >>locations come about because various devices=20 >>and services associated with that single entity=20 >>may attribute various locations to the entity. >> >>Getting back to fundamentals, we don=92t need a=20 >>Geolocation header in order to carry location=20 >>in SIP. There are MIME bodies for that=20 >>(including Content-Indirection bodies for LbyR,=20 >>or perhaps Content-Location as you suggest),=20 >>and we can include seventeen different location=20 >>objects if we want to, regardless of whether=20 >>there are zero or one or fifteen Geolocation=20 >>headers. We don=92t need a location conveyance=20 >>specification or a Geolocation header to enable=20 >>that, SIP has always been able to do it, and=20 >>you=92ll still be able to add random MIME bodies=20 >>that contain location information even if there=20 >>is a Geolocation header which does not point to=20 >>them. So what does the Geolocation header and=20 >>location conveyance specification buy us? >> >>I=92ve always naively thought that the=20 >>Geolocation header provides a coupling between=20 >>this particular SIP session and an entity whose=20 >>location is designated by a PIDF document. The=20 >>entity is the geopriv Target, and is probably=20 >>(though not necessarily) related to the party=20 >>identified by the classic From header field of=20 >>the SIP request. The Geolocation header tells=20 >>us that for the purposes of the SIP session=20 >>being negotiated, the location of this Target=20 >>is somehow relevant... the boldest=20 >>interpretation would be that this Target=92s=20 >>location should be considered the source of the=20 >>request. Just attaching location-aware MIME=20 >>bodies without the Geolocation header to SIP=20 >>requests doesn=92t convey the same semantics =96=20 >>those bodies could mean anything, and=20 >>presumably the receiving application would sort through them at its= discretion. >> >>Where I get confused is when I start trying to=20 >>understand what it would mean semantically for=20 >>a SIP session to be coupled with more than one=20 >>Target. Again, I can imagine hypothetically a=20 >>SIP request containing unsorted MIME bodies=20 >>that talk about different Targets to assist=20 >>some specific application that knows how to=20 >>reconcile them, but here I mean using the=20 >>Geolocation header to couple a SIP request with=20 >>location information about different Targets.=20 >>Is there actually a use case/requirement for=20 >>that? If not, and we only want to couple a SIP=20 >>request with one Target, then I fail to see why=20 >>composing location information about the same=20 >>Target into a single PIDF body would be a=20 >>problem. Having location information about the=20 >>same entity fail to be organized in one body=20 >>through RFC4479 wouldn=92t make sense, anyway. >> >>I think if we understand the semantics by which=20 >>the Geolocation header =93couples=94 PIDF with a=20 >>SIP session, then we=92ll better understand all=20 >>of this. If the Geolocation header only exists=20 >>to notify lazy intermediaries that there are=20 >>location-sensitive bodies in the request or=20 >>somewhere out on the net, without implying=20 >>anything about the Target or the relationship=20 >>of those locations to the SIP request, then=20 >>this whole specification is probably more=20 >>trouble than it=92s worth =96 it really wouldn=92t=20 >>provide much incremental value above the basic=20 >>ability of SIP to carry all sorts of bodies,=20 >>including location bodies. If there are,=20 >>however, more binding semantics here, then we=20 >>probably won=92t be able to agree on the need for=20 >>solitary or multiple Geolocation headers until=20 >>we agree on what those semantics are. >> >>Jon Peterson >>NeuStar, Inc. >> >> >>On 7/18/10 7:25 PM, "Thomson, Martin"=20 >><Martin.Thomson@andrew.com> wrote: >> >>Hi Jon, >> >>I admit a fair degree of sympathy for Roger=92s=20 >>suggestion. After all, the ability to include=20 >>multiple location =93values=94 in the same SIP=20 >>request is a feature that has existed for many=20 >>years. A number of implementations have come=20 >>to rely on this mechanism; people are building=20 >>and have built solutions based on earlier=20 >>draft, fully aware of the risks in implementing an internet draft. >> >>At some point, it might be necessary to swallow=20 >>any discomfort and recognize that the=20 >>consequences of an imperfect solution are less=20 >>than the consequences of a change of the nature you suggest. >> >>Altering perspective might offer a solution. >> >>The idea that there are multiple items that are=20 >>composited might be counterproductive. In this=20 >>world-view, you have to reconcile a number of=20 >>perspectives. In this, you are absolutely=20 >>correct: doing that at two layers is=20 >>bad. Composition is a hard problem=20 >>already. Moving it into SIP only complicates it further. >> >>The alternative is to imagine a single logical=20 >>resource that represents the location of the=20 >>Target. A location by value is a=20 >>representation of this resource: a=20 >>snapshot. Location by reference offers a means=20 >>for any entity to identify and acquire a view=20 >>of the resource, independent of that=20 >>snapshot. The authority for the resource might=20 >>offer the same representation, or it could=20 >>offer one better suited to the recipient. The=20 >>representation might be updated, it might be=20 >>altered based on an authorization policy, or=20 >>something else (language=20 >>preferences). Regardless of how it is=20 >>represented, it is still the same resource. >> >>In simple terms, you state that the request can=20 >>only include a single _location_. When a=20 >>location value and reference are both included,=20 >>they represent the _same_ location. >> >>This is why I suggested that Content-Location=20 >>be borrowed. In HTTP, Content-Location says -=20 >>if you want to know where this resource really=20 >>lives, here is where you can find it. >> >>Now this might be sheer sophistry, but it might=20 >>offer a way out. The composition problems are left out of SIP. >> >>I can write up a more detailed strawman, but=20 >>for now, I'll just include an example: >> >> INVITE sips:bob@biloxi.example.com SIP/2.0 >> Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4bK74bf9 >> Max-Forwards: 70 >> To: Bob bob@biloxi.example.com> >> From: Alice=20 >>= alice@atlanta.example.com>;tag=3D9fxced76s= l >> Call-ID:=20 >>= <3848276298220188511@atlanta.example.htm>3848276298220188511@atlanta.exampl= e.com >> Geolocation:=20 >> target123@atlanta.example.com> >> ;routing-allowed=3Dno >> Supported: geolocation >> Accept: application/sdp, application/pidf+xml >> CSeq: 31862 INVITE >> Contact: alice@atlanta.example.com> >> Content-Type: multipart/mixed; boundary=3Dboundary1 >> Content-Length: ... >> >> --boundary1 >> Content-Type: application/sdp >> >> ...SDP goes here >> >> --boundary1 >> Content-Type: application/pidf+xml >> Content-ID:=20 >> <target123@atlanta.example.com> >> Content-Location:=20 >> pres:alice@example.com?location/XJhbXM6eG1sOm5zOnBpZ >> >> >> ...PIDF-LO document >> --boundary1-- >> >> >>--Martin >> >>---- Original Message ---- >>From: Peterson, Jon=20 >>[mailto:jon.peterson@neustar.biz] >>Sent: Friday, 16 July 2010 4:54 PM >>To: Roger Marshall; Thomson, Martin; James M.=20 >>Polk; sipcore@ietf.org >>Subject: Re: [sipcore] location-conveyance-03 just submitted >> >> >>In the corner case (and I do think it is a=20 >>corner case) where multiple entities are=20 >>contributing different location information to=20 >>a single SIP request, I think we face a=20 >>fundamental architecture choice in this=20 >>mechanism: either it is SIP=92s job to sort out=20 >>how we understand those different locations, or=20 >>it is PIDF=92s job. Traditionally, PIDF=92s=20 >>understanding of different sources of presence=20 >>that provide potentially contradictory=20 >>information relies on the presence data model=20 >>(RFC4479), which is designed to reconcile=20 >>conditions like the one where my mobile phone=20 >>thinks I am available but my desktop thinks I=92m=20 >>offline. The presence data model moreover=20 >>differentiates between users, services and=20 >>devices in a way that is useful and apparently=20 >>applicable to location information. I am not=20 >>eager to try to replicate this in SIP headers,=20 >>including by inserting multiple such headers,=20 >>putting in markup that tries to explain the=20 >>=93source=94 of location information in SIP=20 >>headers, and so on. SIP=92s job should be to=20 >>convey the location object =96 fundamentally, the=20 >>further we diverge from =93conveyance=94 and enter=20 >>into the realm of =93integration,=94 the less comfortable I get. >> >>I understand that the subsequent use case where=20 >>there are different sources of location=20 >>information, some of which are LbrV and some of=20 >>which are LbyR, looks like a hairy one. This=20 >>is, however, a corner case of a corner case. I=20 >>really do not feel comfortable justifying the=20 >>allowance of multiple location headers in SIP=20 >>pointing to different presence objects (as=20 >>opposed to following the presence data model)=20 >>to carry the 0, 1 or 2 different locations due=20 >>to a corner case of a corner case. As I said in=20 >>my previous mail to Martin, I=92m not really sure=20 >>I even understand the requirements for an=20 >>intermediary to evaluate and reject LbyR, nor=20 >>what the best way is for presence from these=20 >>dynamic sources to be composed. If we were to=20 >>investigate the right way for presence from=20 >>those source to be composed, it might very well=20 >>be that it is the responsibility of the=20 >>compositor to insert an LbyR into the SIP=20 >>request (into the Geolocation header), and to=20 >>poll and compose a coherent PIDF document from=20 >>its dynamic and static sources =96 that is=20 >>probably the approach that most closely=20 >>parallels the traditional approaches to=20 >>presence. But we haven=92t even begun to explore=20 >>this yet. No one insisting that there will be=20 >>=93empty=94 PIDF documents just containing=20 >>references to external PIDF documents or=20 >>something. Something along those lines is one=20 >>approach of many that we would consider if we=20 >>tried to figure out how to address this in=20 >>PIDF. The question we need to decide, as I said=20 >>above, is the architecture one =96 is SIP=92s job=20 >>to convey PIDF documents, or to compose them? >> >>Jon Peterson >>NeuStar, Inc. >> >>=85 >> >>_______________________________________________ >>sipcore mailing list >>sipcore@ietf.org >>https://www.ietf.org/mailman/listinfo/sipcore From Hannes.Tschofenig@gmx.net Tue Jul 20 13:30:36 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3D8D3A691D for ; Tue, 20 Jul 2010 13:30:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.145 X-Spam-Level: X-Spam-Status: No, score=-6.145 tagged_above=-999 required=5 tests=[AWL=4.454, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BE1g4jlAxUub for ; Tue, 20 Jul 2010 13:30:36 -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 E9F513A65A5 for ; Tue, 20 Jul 2010 13:30:34 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-2.cisco.com with ESMTP; 20 Jul 2010 20:30:50 +0000 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 o6KKUnJm024517 for ; Tue, 20 Jul 2010 20:30:50 GMT Received: from mail pickup service by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 13:14:44 -0700 Received: from xbh-rcd-102.cisco.com ([72.163.62.139]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 04:17:10 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 05:37:57 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 10:37:53 +0000 Received: from sj-inbound-f.cisco.com (sj-inbound-f.cisco.com [128.107.234.207]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6KAbroT009279 for ; Tue, 20 Jul 2010 10:37:53 GMT X-from-outside-Cisco: 213.165.64.20 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsBACsZRUzVpUAUi2dsb2JhbACDH5EIi10BAQEKCwoHDwUfpQOJNJF2gSaDGXME X-IronPort-AV: E=Sophos;i="4.55,231,1278288000"; d="scan'208";a="205324629" Received: from mail.gmx.net ([213.165.64.20]) by sj-inbound-f.cisco.com with SMTP; 20 Jul 2010 10:37:52 +0000 Received: (qmail 9563 invoked by uid 0); 20 Jul 2010 10:37:51 -0000 Received: from 213.162.68.136 by www160.gmx.net with HTTP; Tue, 20 Jul 2010 12:37:50 +0200 (CEST) Content-Type: text/plain; charset="utf-8" Date: Tue, 20 Jul 2010 12:37:50 +0200 From: "Hannes Tschofenig" In-Reply-To: <201007191843.o6JIhpLv029037@sj-core-5.cisco.com> Message-ID: <20100720103750.197770@gmx.net> MIME-Version: 1.0 References: <20100719081713.77060@gmx.net> <201007191843.o6JIhpLv029037@sj-core-5.cisco.com> To: "James M. Polk" , sipcore@ietf.org X-Authenticated: #29516787 X-Flags: 0001 X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-Priority: 3 X-Provags-ID: V01U2FsdGVkX18X7YNP9bQXZfQg7NxM5ymnOoXiaSzQgWYGeqMwhA u6vHypPov1JML9BaKvA9y7por1p4v5QA+CQg== Content-Transfer-Encoding: 8bit X-GMX-UID: GhUgDS85fW47Yck5tWRo/yRudmllcsXq X-FuHaFi: 0.69999999999999996 X-OriginalArrivalTime: 20 Jul 2010 10:37:57.0328 (UTC) FILETIME=[9E1CBD00:01CB27F7] Subject: Re: [sipcore] Location Conveyance Flaw: HTTP/HTTPS Location URI Scheme X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Jul 2010 20:30:36 -0000 > At 03:17 AM 7/19/2010, Hannes Tschofenig wrote: > >Hi, > > > >The authors (or one of them in particular) > > on the IAB and you can't stop attacking publicly? > > hmmmm... > This has nothing to do with the IAB. I am also still a regular IETF participant who may feel unhappy. From Martin.Thomson@andrew.com Tue Jul 20 15:01:46 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D1C53A6892 for ; Tue, 20 Jul 2010 15:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.562 X-Spam-Level: X-Spam-Status: No, score=-6.562 tagged_above=-999 required=5 tests=[AWL=4.037, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qdkfwBgjOTlO for ; Tue, 20 Jul 2010 15:01:45 -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 441233A67E7 for ; Tue, 20 Jul 2010 15:01:45 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 22:02:01 +0000 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 o6KM1tA9011845; Tue, 20 Jul 2010 22:02:01 GMT Received: from mail pickup service by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 14:18:02 -0700 Received: from xbh-rcd-202.cisco.com ([72.163.62.201]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 19:18:07 -0700 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 21:18:07 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2010 02:18:05 +0000 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6K2I54B028523 for ; Tue, 20 Jul 2010 02:18:05 GMT X-from-outside-Cisco: 198.135.207.244 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMEAHOkREzGh8/0Z2dsb2JhbACDIJttYRUNCgsYIqgziTSSAIEmgwlzBIN9hw0 X-IronPort-AV: E=Sophos;i="4.55,230,1278288000"; d="scan'208";a="165610486" Received: from csmailgw1.commscope.com ([198.135.207.244]) by sj-inbound-e.cisco.com with ESMTP; 20 Jul 2010 02:18:05 +0000 Received: from [10.86.20.102] ([10.86.20.102]:7483 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S28159653Ab0GTCSC (ORCPT ); Mon, 19 Jul 2010 21:18:02 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 19 Jul 2010 21:18:02 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 20 Jul 2010 10:18:01 +0800 From: "Thomson, Martin" To: "James M. Polk" , "Winterbottom, James" , "Richard L. Barnes" , "sipcore@ietf.org" Date: Tue, 20 Jul 2010 10:20:08 +0800 Thread-Topic: [sipcore] Geo URI in location-conveyance Thread-Index: AcsnrsKDxaye5wvaTBCmk0kUJVkv+AAA0O8g Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB773041@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC81880120E9829412@SISPE7MB1.commscope.com> <201007200125.o6K1P7sF001390@sj-core-2.cisco.com> In-Reply-To: <201007200125.o6K1P7sF001390@sj-core-2.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com X-OriginalArrivalTime: 20 Jul 2010 02:18:07.0346 (UTC) FILETIME=[CAB0A520:01CB27B1] Subject: Re: [sipcore] Geo URI in location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Jul 2010 22:01:46 -0000 SXQncyBub3QgdGhlIGZpcnN0IHRpbWUsIGJ1dCBubyBtYXR0ZXI6IGFic29sdXRlVVJJIGNvdmVy cyBpdC4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzaXBjb3JlLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJl aGFsZiBPZiBKYW1lcyBNLiBQb2xrDQo+IFNlbnQ6IFR1ZXNkYXksIDIwIEp1bHkgMjAxMCAxMToy NSBBTQ0KPiBUbzogV2ludGVyYm90dG9tLCBKYW1lczsgUmljaGFyZCBMLiBCYXJuZXM7IHNpcGNv cmVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzaXBjb3JlXSBHZW8gVVJJIGluIGxvY2F0aW9u LWNvbnZleWFuY2UNCj4gDQo+IEFzIG9mIG5vdywgdGhpcyB3b3VsZCBiZSB0aGUgZmlyc3QgdGlt ZSBJJ3ZlIGhlYXJkIHRoYXQgcmVxdWVzdCAoZm9yDQo+IGEgR0VPIFVSSSksIGFuZCB0aGVyZSBh cmUgY3VycmVudGx5IG5vIHByb3Zpc2lvbnMgZm9yIHRoaXMgKHVubGVzcw0KPiBhYnNvbHV0ZVVS SSBjb3ZlcnMgaXQpLg0KPiANCj4gSmFtZXMNCj4gDQo+IEF0IDA2OjA1IFBNIDcvMTkvMjAxMCwg V2ludGVyYm90dG9tLCBKYW1lcyB3cm90ZToNCj4gPkkgd2FudCB0aGlzLCBhbmQgSSB3YW50IHRv IGJlIGFibGUgdG8gc3VwcG9ydCBhIENJRCBpbiB0aGUgc2FtZQ0KPiBoZWFkZXIuDQo+ID5JZiB3 ZSBjYW4gZG8gdGhhdCBpbiB0aGUgc2FtZSBoZWFkZXIsIHRoZW4gSSBhIG1vcmUgdGhhbiBoYXBw eSB0bw0KPiA+cmVzdHJpY3QgdGhlIG51bWJlciBvZiBnZW9sb2NhdGlvbiBoZWFkZXJzIHRvIDEu DQo+ID4NCj4gPkNoZWVycw0KPiA+SmFtZXMNCj4gPg0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWls dG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYNCj4gPiA+IE9mIFJpY2hh cmQgTC4gQmFybmVzDQo+ID4gPiBTZW50OiBUdWVzZGF5LCAyMCBKdWx5IDIwMTAgNzo0NyBBTQ0K PiA+ID4gVG86IHNpcGNvcmVAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFtzaXBjb3JlXSBHZW8g VVJJIGluIGxvY2F0aW9uLWNvbnZleWFuY2UNCj4gPiA+DQo+ID4gPiBXaGF0IGRvIHBlb3BsZSB0 aGluayBhYm91dCBoYXZpbmcgc3VwcG9ydCBmb3IgR0VPIFVSSXMgWzFdIGluIGENCj4gPiA+IEdl b2xvY2F0aW9uIGhlYWRlciBmaWVsZD8gIFNlZW1zIGxpa2UgaXQgd291bGQgYmUga2luZCBvZiBo YW5keS4uLg0KPiA+ID4NCj4gPiA+IFsxXSA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NTg3MD4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gPiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiA+ID4gc2lwY29yZUBpZXRmLm9yZw0K PiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+ID5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+c2lwY29y ZSBtYWlsaW5nIGxpc3QNCj4gPnNpcGNvcmVAaWV0Zi5vcmcNCj4gPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lw Y29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Np cGNvcmUNCg== From john.elwell@siemens-enterprise.com Tue Jul 20 15:21:29 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31EED3A6818 for ; Tue, 20 Jul 2010 15:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.574 X-Spam-Level: X-Spam-Status: No, score=-6.574 tagged_above=-999 required=5 tests=[AWL=4.025, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lYBd7K9AlxH3 for ; Tue, 20 Jul 2010 15:21:28 -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 156D73A65A5 for ; Tue, 20 Jul 2010 15:21:28 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 20 Jul 2010 22:21:43 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6KMLdEQ001367 for ; Tue, 20 Jul 2010 22:21:44 GMT Received: from mail pickup service by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 14:59:26 -0700 Received: from xbh-rcd-102.cisco.com ([72.163.62.139]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 04:30:22 -0700 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 06:00:14 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 11:00:12 +0000 Received: from sj-inbound-f.cisco.com (sj-inbound-f.cisco.com [128.107.234.207]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KB0CZq005717 for ; Tue, 20 Jul 2010 11:00:12 GMT X-from-outside-Cisco: 62.180.227.30 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At0BABEfRUw+tOMemWdsb2JhbACgBAEBAQEBCAsKBxEipG6bL4JqgkgEixo X-IronPort-AV: E=Sophos;i="4.55,231,1278288000"; d="scan'208";a="205327952" Received: from m0019.fra.mmp.de.bt.com (HELO ms01.m0019.fra.mmp.de.bt.com) ([62.180.227.30]) by sj-inbound-f.cisco.com with ESMTP; 20 Jul 2010 11:00:11 +0000 Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-907710; Tue, 20 Jul 2010 13:00:09 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id B4A0D1EB82AB; Tue, 20 Jul 2010 13:00:09 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 20 Jul 2010 13:00:09 +0200 From: "Elwell, John" To: "James M. Polk" , "sipcore@ietf.org" Date: Tue, 20 Jul 2010 13:00:08 +0200 Thread-Topic: [sipcore] location-conveyance-03 just submitted Thread-Index: AcsiHatHUUgsdDW9RKGALMHNFk4DHwF2Vfow Message-ID: References: <201007122355.o6CNt6us024310@sj-core-3.cisco.com> In-Reply-To: <201007122355.o6CNt6us024310@sj-core-3.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginalArrivalTime: 20 Jul 2010 11:00:14.0769 (UTC) FILETIME=[BB4A0A10:01CB27FA] Subject: Re: [sipcore] location-conveyance-03 just 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: Tue, 20 Jul 2010 22:21:29 -0000 James, These are questions for clarification at this stage, rather than comments. The ABNF for the Geolocation header field allows multiple locationValues an= d multiple routing-params, in any order. The text below seems to limit it t= o 0 or 1 locationValue and 0 or 1 routing-param, and furthermore it limits = it so that the routing-param must be last. It seems this could be expressed= much more precisely, and still quite easily, in the ABNF. Of have I misund= erstood something? Although the text "The Geolocation header field has zero or one locationVal= ue, but=20 MUST NOT contain more than one locationValue." limits the header field to having a maximum of one locationValue, text furt= her down "another=20 instance of the Geolocation header" suggests that there can be multiple instances of the header field and hence= multiple locationValues. So a request can contain multiple locationValues,= but not in the same header field instance. Is this really what is intended= ? Unrelated to the above, concerning the text: "Other URI schemas used in the location URI MUST be reviewed against=20 the RFC 3693 [RFC3693] criteria for a Using Protocol" Who must review? The protocol implementer? How is this testable? John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of James M. Polk > Sent: 13 July 2010 00:55 > To: sipcore@ietf.org > Subject: [sipcore] location-conveyance-03 just submitted >=20 > SIPCORE >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio > n-conveyance-03.txt >=20 > This version is a fairly radical departure from previous versions of=20 > the (long standing) effort. This time the doc didn't grow... >=20 > We added Jon Peterson as a co-author, and he helped in Anaheim=20 > propose a significantly less complex way of specifying location=20 > conveyance for SIP. More than 95% of the doc has been rewritten by=20 > Jon and I, with a net result of 27 less pages of text (52 to 25 now). >=20 > We took out the terms and concepts of following parameters: >=20 > - inserter > - inserted-by > - used-for-routing > - host-id > - node-id >=20 > as well as limiting the number of locationValues to *ONE*, in=20 > a SIP request. >=20 > We removed the ability for SIP intermediaries to add location along=20 > the way unbeknownst to the UAC (with one infrequently used=20 > exception). In this way, location errors are only end-to-end, so=20 > there is no need to identify which entity added location to make sure=20 > the right entity reacted the right way when an error was caused by=20 > the location they inserted, and not that of another entity's inserted=20 > location (which is all very confusing). >=20 > We added the ability for a SIP intermediary to augment a location=20 > with what the UAC should send in a subsequent request, and the=20 > ability to verify this augmentation is present before successfully=20 > processing that request. This is in line with both RFCs 4479 and 5491. >=20 > Comments are appreciated >=20 > James >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From Martin.Thomson@andrew.com Tue Jul 20 16:21:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C4C4C3A68DB for ; Tue, 20 Jul 2010 16:21:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.71 X-Spam-Level: X-Spam-Status: No, score=-6.71 tagged_above=-999 required=5 tests=[AWL=3.889, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id goCKRC6o99ua for ; Tue, 20 Jul 2010 16:21: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 A19D13A65A5 for ; Tue, 20 Jul 2010 16:21:36 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-1.cisco.com with ESMTP; 20 Jul 2010 23:21:52 +0000 Received: from xbh-sjc-231.amer.cisco.com (xbh-sjc-231.cisco.com [128.107.191.100]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6KNKGEg018850; Tue, 20 Jul 2010 23:21:48 GMT Received: from mail pickup service by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 14:18:42 -0700 Received: from xbh-rcd-202.cisco.com ([72.163.62.201]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 19:18:08 -0700 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 21:18:07 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2010 02:18:05 +0000 Received: from sj-inbound-e.cisco.com (sj-inbound-e.cisco.com [128.107.243.14]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6K2I54B028523 for ; Tue, 20 Jul 2010 02:18:05 GMT X-from-outside-Cisco: 198.135.207.244 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMEAHOkREzGh8/0Z2dsb2JhbACDIJttYRUNCgsYIqgziTSSAIEmgwlzBIN9hw0 X-IronPort-AV: E=Sophos;i="4.55,230,1278288000"; d="scan'208";a="165610486" Received: from csmailgw1.commscope.com ([198.135.207.244]) by sj-inbound-e.cisco.com with ESMTP; 20 Jul 2010 02:18:05 +0000 Received: from [10.86.20.102] ([10.86.20.102]:7483 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S28159653Ab0GTCSC (ORCPT ); Mon, 19 Jul 2010 21:18:02 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 19 Jul 2010 21:18:02 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 20 Jul 2010 10:18:01 +0800 From: "Thomson, Martin" To: "James M. Polk" , "Winterbottom, James" , "Richard L. Barnes" , "sipcore@ietf.org" Date: Tue, 20 Jul 2010 10:20:08 +0800 Thread-Topic: [sipcore] Geo URI in location-conveyance Thread-Index: AcsnrsKDxaye5wvaTBCmk0kUJVkv+AAA0O8g Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB773041@SISPE7MB1.commscope.com> References: <5A55A45AE77F5941B18E5457ECAC81880120E9829412@SISPE7MB1.commscope.com> <201007200125.o6K1P7sF001390@sj-core-2.cisco.com> In-Reply-To: <201007200125.o6K1P7sF001390@sj-core-2.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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com X-OriginalArrivalTime: 20 Jul 2010 02:18:07.0346 (UTC) FILETIME=[CAB0A520:01CB27B1] Subject: Re: [sipcore] Geo URI in location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Jul 2010 23:21:45 -0000 SXQncyBub3QgdGhlIGZpcnN0IHRpbWUsIGJ1dCBubyBtYXR0ZXI6IGFic29sdXRlVVJJIGNvdmVy cyBpdC4NCg0KPiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiBGcm9tOiBzaXBjb3JlLWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddIE9uDQo+IEJl aGFsZiBPZiBKYW1lcyBNLiBQb2xrDQo+IFNlbnQ6IFR1ZXNkYXksIDIwIEp1bHkgMjAxMCAxMToy NSBBTQ0KPiBUbzogV2ludGVyYm90dG9tLCBKYW1lczsgUmljaGFyZCBMLiBCYXJuZXM7IHNpcGNv cmVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUmU6IFtzaXBjb3JlXSBHZW8gVVJJIGluIGxvY2F0aW9u LWNvbnZleWFuY2UNCj4gDQo+IEFzIG9mIG5vdywgdGhpcyB3b3VsZCBiZSB0aGUgZmlyc3QgdGlt ZSBJJ3ZlIGhlYXJkIHRoYXQgcmVxdWVzdCAoZm9yDQo+IGEgR0VPIFVSSSksIGFuZCB0aGVyZSBh cmUgY3VycmVudGx5IG5vIHByb3Zpc2lvbnMgZm9yIHRoaXMgKHVubGVzcw0KPiBhYnNvbHV0ZVVS SSBjb3ZlcnMgaXQpLg0KPiANCj4gSmFtZXMNCj4gDQo+IEF0IDA2OjA1IFBNIDcvMTkvMjAxMCwg V2ludGVyYm90dG9tLCBKYW1lcyB3cm90ZToNCj4gPkkgd2FudCB0aGlzLCBhbmQgSSB3YW50IHRv IGJlIGFibGUgdG8gc3VwcG9ydCBhIENJRCBpbiB0aGUgc2FtZQ0KPiBoZWFkZXIuDQo+ID5JZiB3 ZSBjYW4gZG8gdGhhdCBpbiB0aGUgc2FtZSBoZWFkZXIsIHRoZW4gSSBhIG1vcmUgdGhhbiBoYXBw eSB0bw0KPiA+cmVzdHJpY3QgdGhlIG51bWJlciBvZiBnZW9sb2NhdGlvbiBoZWFkZXJzIHRvIDEu DQo+ID4NCj4gPkNoZWVycw0KPiA+SmFtZXMNCj4gPg0KPiA+DQo+ID4gPiAtLS0tLU9yaWdpbmFs IE1lc3NhZ2UtLS0tLQ0KPiA+ID4gRnJvbTogc2lwY29yZS1ib3VuY2VzQGlldGYub3JnIFttYWls dG86c2lwY29yZS1ib3VuY2VzQGlldGYub3JnXSBPbg0KPiBCZWhhbGYNCj4gPiA+IE9mIFJpY2hh cmQgTC4gQmFybmVzDQo+ID4gPiBTZW50OiBUdWVzZGF5LCAyMCBKdWx5IDIwMTAgNzo0NyBBTQ0K PiA+ID4gVG86IHNpcGNvcmVAaWV0Zi5vcmcNCj4gPiA+IFN1YmplY3Q6IFtzaXBjb3JlXSBHZW8g VVJJIGluIGxvY2F0aW9uLWNvbnZleWFuY2UNCj4gPiA+DQo+ID4gPiBXaGF0IGRvIHBlb3BsZSB0 aGluayBhYm91dCBoYXZpbmcgc3VwcG9ydCBmb3IgR0VPIFVSSXMgWzFdIGluIGENCj4gPiA+IEdl b2xvY2F0aW9uIGhlYWRlciBmaWVsZD8gIFNlZW1zIGxpa2UgaXQgd291bGQgYmUga2luZCBvZiBo YW5keS4uLg0KPiA+ID4NCj4gPiA+IFsxXSA8aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvcmZj NTg3MD4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4gPiBzaXBjb3JlIG1haWxpbmcgbGlzdA0KPiA+ID4gc2lwY29yZUBpZXRmLm9yZw0K PiA+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQo+ID5f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+c2lwY29y ZSBtYWlsaW5nIGxpc3QNCj4gPnNpcGNvcmVAaWV0Zi5vcmcNCj4gPmh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPiANCj4gX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gc2lwY29yZSBtYWlsaW5nIGxpc3QNCj4gc2lw Y29yZUBpZXRmLm9yZw0KPiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3Np cGNvcmUNCg== From Martin.Thomson@andrew.com Tue Jul 20 16:48:28 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 452163A6980 for ; Tue, 20 Jul 2010 16:48:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.97 X-Spam-Level: X-Spam-Status: No, score=-2.97 tagged_above=-999 required=5 tests=[AWL=-0.371, 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 laZ8Z11RkCJL for ; Tue, 20 Jul 2010 16:48:27 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 4AF003A697D for ; Tue, 20 Jul 2010 16:48:26 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:12152 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S28243750Ab0GTXsl (ORCPT ); Tue, 20 Jul 2010 18:48:41 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 20 Jul 2010 18:48:41 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 21 Jul 2010 07:48:39 +0800 From: "Thomson, Martin" To: Paul Kyzivat Date: Wed, 21 Jul 2010 07:50:48 +0800 Thread-Topic: [sipcore] composition or just indirection Thread-Index: AcsoCkunGdOyi5IuRt6DSEiFZ+ntFgAWGJFw Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB773153@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03EB772EBB@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F03EB7730BA@SISPE7MB1.commscope.com> <4C459BD7.9050007@cisco.com> In-Reply-To: <4C459BD7.9050007@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: Roger Marshall , "sipcore@ietf.org" Subject: Re: [sipcore] composition or just indirection X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 20 Jul 2010 23:48:28 -0000 PiBGcm9tOiBQYXVsIEt5eml2YXQgW21haWx0bzpwa3l6aXZhdEBjaXNjby5jb21dOg0KPiBUaG9t c29uLCBNYXJ0aW4gd3JvdGU6DQo+ID4gVGhlIEdlb2xvY2F0aW9uIGhlYWRlciBpZGVudGlmaWVz IGEgUElERiBkb2N1bWVudCBieSB2YWx1ZSBvcg0KPiA+IHJlZmVyZW5jZS4gIEEgR2VvbG9jYXRp b24gaGVhZGVyIGluZGljYXRlcyB0aGF0IGEpIHRoaXMgcGFydGljdWxhcg0KPiA+IFBJREYNCj4g PiBkb2N1bWVudCBjb250YWlucyBsb2NhdGlvbiBpbmZvcm1hdGlvbiBhbmQgYikgdGhhdCB0aGlz IGxvY2F0aW9uDQo+ID4gaW5mb3JtYXRpb24gaW4gcGFydGljdWxhciBtYXkgYmUgcmVsZXZhbnQg dG8gdGhlIHByb2Nlc3Npbmcgb2YgdGhlDQo+ID4gU0lQIHJlcXVlc3QuDQo+IA0KPiBJTU8gdGhp cyBpcyAqdG9vKiB2YWd1ZS4NCj4gDQo+IEZvciBpbnN0YW5jZSwgSSBtaWdodCB3YW50IHJlcXVl c3QgdGhhdCBhIGNhbGwgYmUgcm91dGVkICp0byogdGhlIHBob25lDQo+IGNsb3Nlc3QgdG8gc29t ZSBnZW9sb2NhdGlvbi4gVGhhdCBsb2NhdGlvbiBpcyBhbHNvIHJlbGV2YW50IHRvIHRoZQ0KPiBw cm9jZXNzaW5nIG9mIHRoZSByZXF1ZXN0LCBidXQgaW4gYW4gZW50aXJlbHkgZGlmZmVyZW50IHdh eS4NCg0KRGFtbi4gIFlvdSB3b3VsZCBoYXZlIHRvIHBvaW50IG91dCBteSBiaWcgYmxpbmQgc3Bv dC4gIEkndmUgYmVlbiBjb25jZW50cmF0aW5nIG9uIHRoZSByb3V0aW5nLWJhc2VkLW9uLWNhbGxl ci1sb2NhdGlvbiB1c2UgY2FzZSB0b28gbG9uZy4NCg0KSWYgd2UgYWxzbyBjb25zaWRlciB0aGF0 IHRoZSBsb2NhdGlvbiBuZWVkcyB0byBiZSBhdHRyaWJ1dGVkIHRvIGEgcGFydGljdWxhciBlbnRp dHksIHlvdSBjYW4gZWl0aGVyIGFkZCBzeW50YXggdGhhdCBhdHRlbXB0cyB0byBpZGVudGlmeSB0 aGUgZW50aXR5IHRoYXQgeW91IGFyZSB0YWxraW5nIGFib3V0IChhICJmcm9tIiBvciAidG8iIHBh cmFtZXRlciBtaWdodCBkbyB0aGlzKSwgb3IgeW91IGNhbiBtYWtlIHRoZSBlbnRpdHkgY29uc3Rh bnQuICBJbiB0aGUgaW50ZXJlc3Qgb2Ygc2ltcGxpY2l0eSwgdGhlIGxhdHRlciBzZWVtcyBtb3Jl IGZhc2hpb25hYmxlOg0KDQoiDQpUaGUgR2VvbG9jYXRpb24gaGVhZGVyIGlkZW50aWZpZXMgYSBz b3VyY2Ugb2YgbG9jYXRpb24gaW5mb3JtYXRpb24uICBUaGlzIG1pZ2h0IGJlIGEgUElERi1MTyBk b2N1bWVudCB0aGF0IGlzIGlkZW50aWZpZWQgYnkgdmFsdWUgb3IgcmVmZXJlbmNlLCBvciBhIGdl bzogVVJJIHRoYXQgaW5jbHVkZXMgbG9jYXRpb24gaW5mb3JtYXRpb24gZGlyZWN0bHkuDQoNCkEg R2VvbG9jYXRpb24gaGVhZGVyIGluZGljYXRlcyB0aGF0IGEpIHRoYXQgdGhpcyBsb2NhdGlvbiBp bmZvcm1hdGlvbiBpcyBzb21laG93IGFwcGxpY2FibGUgdG8gdGhlIGVudGl0eSB0aGF0IGluaXRp YXRlZCB0aGUgcmVxdWVzdCBhbmQgYikgdGhhdCB0aGlzIGxvY2F0aW9uIGluZm9ybWF0aW9uIG1p Z2h0IGJlIHJlbGV2YW50IHRvIHRoZSBwcm9jZXNzaW5nIG9mIHRoZSBTSVAgcmVxdWVzdC4NCiIN Cg0KVGhpcyBpcyBhbG1vc3QgdGhlICJib2xkIiBpbnRlcnByZXRhdGlvbiB0aGF0IHNheXMgdGhh dCB0aGlzIFRhcmdldOKAmXMgbG9jYXRpb24gc2hvdWxkIGJlIGNvbnNpZGVyZWQgdGhlIHNvdXJj ZSBvZiB0aGUgcmVxdWVzdC4gIEl0IGRvZXMgbm90IGltcGx5IHRoYXQgdGhlIFRhcmdldCBhbmQg c291cmNlIGFyZSB0aGUgc2FtZSBpZGVudGl0eS4gIE5vciBkb2VzIGl0IGV4cHJlc3NseSBzdGF0 ZSB0aGF0IHRoZSBzb3VyY2UgaXMgYWN0dWFsbHkgbG9jYXRlZCBhbnl3aGVyZSBpbiBwYXJ0aWN1 bGFyLCB0aG91Z2ggd2UncmUgd2Fsa2luZyBhIGZhaXJseSBmaW5lIGxpbmUgdGhlcmUuDQoNCi0t TWFydGluDQoNCg== From Martin.Thomson@andrew.com Tue Jul 20 17:05:15 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19EC93A6976 for ; Tue, 20 Jul 2010 17:05:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.072 X-Spam-Level: X-Spam-Status: No, score=-3.072 tagged_above=-999 required=5 tests=[AWL=-0.473, 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 pHnu7tJ27x3l for ; Tue, 20 Jul 2010 17:05:14 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id EB3B33A65A5 for ; Tue, 20 Jul 2010 17:05:13 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:46619 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S28243891Ab0GUAF1 (ORCPT ); Tue, 20 Jul 2010 19:05:27 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 20 Jul 2010 19:05:27 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Wed, 21 Jul 2010 08:05:23 +0800 From: "Thomson, Martin" To: Hannes Tschofenig , "Peterson, Jon" , "rbarnes@bbn.com" Date: Wed, 21 Jul 2010 08:07:32 +0800 Thread-Topic: [sipcore] composition or just indirection (was: location-conveyance-03 just submitted) Thread-Index: Acsn9Z2RDCwZsBDlSaKxgtwPpn6RwAAcPyAQ Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB773158@SISPE7MB1.commscope.com> References: <20100720102333.24820@gmx.net> In-Reply-To: <20100720102333.24820@gmx.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "sipcore@ietf.org" , "RMarshall@telecomsys.com" Subject: Re: [sipcore] composition or just indirection (was: location-conveyance-03 just 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: Wed, 21 Jul 2010 00:05:15 -0000 SGkgSGFubmVzLA0KDQpJbmxpbmUuLi4NCg0KPiBTdGlsbCB0cnlpbmcgdG8gY2F0Y2ggdXAgd2l0 aCB0aGUgbWFpbCB0aHJlYWQgYnV0IGEgZmV3IGJhc2ljDQo+IG9ic2VydmF0aW9uczoNCj4gDQo+ IDEpIFRoZXJlIGlzIHRoZSAnZW50aXR5JyBhdHRyaWJ1dGUgaW4gdGhlIDxwcmVzZW5jZT4gZWxl bWVudCB0aGF0DQo+IHBvaW50cyB0byB0aGUgVGFyZ2V0Lg0KPiANCj4gMikgVGhlcmUgaXMgUkZD IDU0OTEgaHR0cDovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9yZmM1NDkxLyB0aGF0DQo+IGRl c2NyaWJlcyBob3cgZGlmZmVyZW50IGxvY2F0aW9uIGNodW5rcyAoaW5jbHVkaW5nICJjb21wb3Vu ZCBsb2NhdGlvbiIpDQo+IGFyZSBpbnRlcnByZXRlZC4gSXQgYWxzbyBkZXNjcmliZXMgdGhlIG1l YW5pbmcgb2YgZGlmZmVyZW50IGxvY2F0aW9uDQo+IG9iamVjdHMgaW4gYSBQSURGLUxPLg0KDQpJ J2QgbGlrZSB0byByZWx5IG9uIDU0OTEuICBCdXQgd2UgbmVlZCB0byBnZXQgdG8gdGhlIHBvaW50 IHdoZXJlIGEgcmVjaXBpZW50IG9ubHkgcmVjZWl2ZXMgYSBzaW5nbGUgZG9jdW1lbnQuICBUaGF0 J3MgdGhlIHNuYXJsIHdlJ3JlIHRyeWluZyB0byB0ZWFzZSBvdXQuDQogDQo+IDMpIFdlIGtub3cg dGhhdCB3ZSB3YW50IHRvIHRyYW5zbWl0IG11bHRpcGxlIGxvY2F0aW9uIGNodW5rcywgYW5kDQo+ IG11bHRpcGxlIGxvY2F0aW9uIG9iamVjdHMgb2YgdGhlIHNhbWUgVGFyZ2V0LiBXZSBkbyBub3Qg c2VlbSB0byBoYXZlDQo+IHVzZSBjYXNlcyBmb3IgdHJhbnNtaXR0aW5nIGxvY2F0aW9uIG9mID4+ ZGlmZmVyZW50PDwgVGFyZ2V0cyBpbiB0aGUNCj4gc2FtZSBTSVAgbWVzc2FnZS4NCg0KSSBkb24n dCB0aGluayB0aGF0IHRoaXMgaXMgZW50aXJlbHkgY29ycmVjdC4gIFllcywgaXQncyB0cml2aWFs IHRvIGNvbnZleSBtdWx0aXBsZSBwaWVjZXMsIGJ1dCB3ZSdyZSBsb29raW5nIGZvciBhIHdheSB0 byBoYXZlIGEgc2luZ2xlIFBJREYgYnV0IHJlY29uY2lsZSB0aGF0IHdpdGggYnktcmVmZXJlbmNl IGNvbnZleWFuY2UuDQoNCj4gU28sIHRoaXMgc2hvdWxkIGFsbG93IHVzIHRvIGNhcnJ5IG9uZSBv ZiBtdWx0aXBsZSBNSU1FIGJvZGllcyB3aXRoDQo+IFBJREYtTE9zIGluIGEgU0lQIG1lc3NhZ2Ug KHJlZmVycmluZyB0byB0aGUgc2FtZSBUYXJnZXQpIGluIGEgc2luZ2xlDQo+IFNJUCBtZXNzYWdl Lg0KDQoNCj4gVGhlIGZvbGxvd2luZyBpdGVtcyBhcmUgbGVmdCBmb3IgZGlzY3Vzc2lvbnMsIEkg YmVsaWV2ZToNCj4gDQo+IC0gSG93IHRvIGVuY29kZSB0aGUgTGJ5UiAoaW4gYWRkaXRpb24gdG8g dGhlIExieVYpDQoNCkhvdyB0aGF0IGNhdCBpcyBza2lubmVkIGRlcGVuZHMgb24gdGhlIGxvZ2lj YWwgbW9kZWwgdGhhdCB3ZSBhZ3JlZSB1cG9uLiAgSXQncyBlYXN5IGVub3VnaCB0byBqdXN0IHRo cm93IGluIGFub3RoZXIgYm9keSAob3IgaGVhZGVyIGV2ZW4pLCBidXQgdGhhdCBkb2Vzbid0IGFk ZHJlc3MgdGhlIGNvbmNlcm4gdGhhdCBhIHJlY2lwaWVudC9VQVMgbWlnaHQgYmUgdW5hYmxlIHRv IG1ha2Ugc2Vuc2Ugb2YgdGhlIGluZm9ybWF0aW9uIHRoYXQgaXQgcmVjZWl2ZXMuDQoNCj4gLSBQ cm9jZWR1cmVzIGZvciBob3cgYW4gaW50ZXJtZWRpYXJ5IGF0dGFjaGVzIGEgcmVmZXJlbmNlIHRv IGEgUElERi1MTw0KDQpJIHRoaW5rIHRoYXQgdGhpcyBoYXMgYWxyZWFkeSBiZWVuIHNvbHZlZC4g IFRoZSBpbnRlcm1lZGlhcnkgc2VuZHMgYSA0MjQgd2l0aCB0aGUgcmVmZXJlbmNlIGluIGl0LCB0 aGUgVUFDIGF0dGFjaGVzIHRoZSByZWZlcmVuY2UgaWYgaXQgYWdyZWVzLiAgKEluIGFuIGVtZXJn ZW5jeSwgdGhlcmUgYXJlIG5vIHN1Y2ggbmljZXRpZXM6IHRoZSBpbnRlcm1lZGlhcnkgc3RlcHMg aW50byBhIEIyQlVBIHJvbGUuKSAgDQoNCkFuIGludGVybWVkaWFyeSBoYXMgdG8gY29tcGx5IHdp dGggYW55IGNvbnN0cmFpbnRzIHdlIHBsYWNlIG9uIHRoZSBoZWFkZXI6IG9uZSB2YWx1ZSBvciBv bmUgaGVhZGVyLCBvbmUgdmFsdWUgYW5kIG9uZSByZWZlcmVuY2UsIG9yIHdoYXRldmVyIGNvbmNs dXNpb24gd2UgY29tZSB0by4NCg0KPiAtIFdoZXRoZXIgdGhlcmUgbmVlZHMgdG8gYmUgYSByZWxh dGlvbnNoaXAgYmV0d2VlbiB0aGUgJ2VudGl0eScNCj4gYXR0cmlidXRlIGluIHRoZSA8cHJlc2Vu Y2U+IGVsZW1lbnQgYW5kIHRoZSBGcm9tIGhlYWRlciBvZiBhIFNJUA0KPiBtZXNzYWdlLg0KDQpU aGF0IGNvbWVzIGRvd24gdG8gaGVhZGVyIHNlbWFudGljcy4gIEVxdWFsaXR5IG9mIHRoZSBlbnRp dHkgYXR0cmlidXRlIGFuZCBGcm9tIGhlYWRlciBpcyBib3RoIHVubmVjZXNzYXJ5IGFuZCBkaWZm aWN1bHQgdG8gYWNoaWV2ZS4gIEEgd2Vha2VyIHJlbGF0aW9uc2hpcCBtaWdodCBiZSBuZWNlc3Nh cnksIHNlZSBteSByZXNwb25zZSB0byBQYXVsLg0KDQpJdCdzIGEgZGFtbmVkIHNoYW1lIHRoYXQg d2UgZG9uJ3QgaGF2ZSBhIGdvb2QgdW5kZXJzdGFuZGluZyBvZiB0aGUgc2VtYW50aWNzIHdlIHdh bnQgZnJvbSB0aGUgaGVhZGVyLiAgSG93IG1hbnkgeWVhcnMgaGF2ZSB3ZSBiZWVuIHdvcmtpbmcg b24gdGhpcz8NCg0KPiBJIGFtIGxlc3MgaW50ZXJlc3RlZCBpbiB0aGUgdXNlZC1mb3Itcm91dGlu ZyBvcHRpbWl6YXRpb25zIGV0Yy4NCg0KQWdyZWVkLg0KDQo+IERpZCBJIGNvcnJlY3RseSBjYXB0 dXJlIHRoZSBjaGFsbGVuZ2U/DQo+IA0KPiBDaWFvDQo+IEhhbm5lcw0K From pkyzivat@cisco.com Tue Jul 20 18:33:04 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 78C103A69C0 for ; Tue, 20 Jul 2010 18:33:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L1eULzT5dUq1 for ; Tue, 20 Jul 2010 18:33:01 -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 040553A69B9 for ; Tue, 20 Jul 2010 18:33:00 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 21 Jul 2010 01:33:16 +0000 Received: from [161.44.174.142] (dhcp-161-44-174-142.cisco.com [161.44.174.142]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6L1XGo6021521; Wed, 21 Jul 2010 01:33:16 GMT Message-ID: <4C464E5C.6000607@cisco.com> Date: Tue, 20 Jul 2010 21:33:16 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Thomson, Martin" References: <8B0A9FCBB9832F43971E38010638454F03EB772EBB@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F03EB7730BA@SISPE7MB1.commscope.com> <4C459BD7.9050007@cisco.com> <8B0A9FCBB9832F43971E38010638454F03EB773153@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03EB773153@SISPE7MB1.commscope.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Cc: Roger Marshall , "sipcore@ietf.org" Subject: Re: [sipcore] composition or just indirection X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 21 Jul 2010 01:33:04 -0000 Thomson, Martin wrote: >> From: Paul Kyzivat [mailto:pkyzivat@cisco.com]: >> Thomson, Martin wrote: >>> The Geolocation header identifies a PIDF document by value or >>> reference. A Geolocation header indicates that a) this particular >>> PIDF >>> document contains location information and b) that this location >>> information in particular may be relevant to the processing of the >>> SIP request. >> IMO this is *too* vague. >> >> For instance, I might want request that a call be routed *to* the phone >> closest to some geolocation. That location is also relevant to the >> processing of the request, but in an entirely different way. > > Damn. You would have to point out my big blind spot. I've been concentrating on the routing-based-on-caller-location use case too long. You're welcome :-) > If we also consider that the location needs to be attributed to a particular entity, you can either add syntax that attempts to identify the entity that you are talking about (a "from" or "to" parameter might do this), or you can make the entity constant. In the interest of simplicity, the latter seems more fashionable: > > " > The Geolocation header identifies a source of location information. This might be a PIDF-LO document that is identified by value or reference, or a geo: URI that includes location information directly. > > A Geolocation header indicates that a) that this location information is somehow applicable to the entity that initiated the request and b) that this location information might be relevant to the processing of the SIP request. > " > > This is almost the "bold" interpretation that says that this Target’s location should be considered the source of the request. It does not imply that the Target and source are the same identity. Nor does it expressly state that the source is actually located anywhere in particular, though we're walking a fairly fine line there. This sounds plausible to me, but I have not been following this stuff closely and so am not familiar with all the sensitivities. Thanks, Paul From James.Winterbottom@andrew.com Tue Jul 20 19:16:29 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC7B23A69AD for ; Tue, 20 Jul 2010 19:16:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.216 X-Spam-Level: X-Spam-Status: No, score=-7.216 tagged_above=-999 required=5 tests=[AWL=3.383, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mi3rZZW3wJBV for ; Tue, 20 Jul 2010 19:16:29 -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 1247B3A6A17 for ; Tue, 20 Jul 2010 19:16:28 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-5.cisco.com with ESMTP; 21 Jul 2010 02:16:44 +0000 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 o6L2FlEW011591; Wed, 21 Jul 2010 02:16:44 GMT Received: from mail pickup service by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 14:21:57 -0700 Received: from sj-iport-6.cisco.com ([171.71.176.117]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 19:18:12 -0700 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-6.cisco.com with ESMTP; 20 Jul 2010 02:18:07 +0000 Received: from sj-inbound-c.cisco.com (sj-inbound-c.cisco.com [128.107.234.206]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6K2Hq0h028448; Tue, 20 Jul 2010 02:18:07 GMT X-from-outside-Cisco: 198.135.207.242 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgMDAHOkREzGh8/yi2dsb2JhbACfbhUBAQEKCwoYIqgzmzQChSAEg32HDQ X-IronPort-AV: E=Sophos;i="4.55,230,1278288000"; d="scan'208";a="181400162" Received: from csmailgw2.commscope.com ([198.135.207.242]) by sj-inbound-c.cisco.com with ESMTP; 20 Jul 2010 02:18:06 +0000 Received: from [10.86.20.102] ([10.86.20.102]:7227 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S340104Ab0GTCSC convert rfc822-to-8bit (ORCPT + 1 other); Mon, 19 Jul 2010 21:18:02 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 19 Jul 2010 21:18:01 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 20 Jul 2010 10:17:59 +0800 From: "Winterbottom, James" To: "James M. Polk" , Paul Kyzivat Date: Tue, 20 Jul 2010 10:17:57 +0800 Thread-Topic: [sipcore] Location Conveyance Question: Multiple Location Thread-Index: Acsnrsw9C9jFzJlQRGeDMgnnMfK4QAAAvWBQ Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120E982945C@SISPE7MB1.commscope.com> References: <20100719081458.77080@gmx.net> <201007191857.o6JIv7in014515@sj-core-1.cisco.com> <2936AA57-EEDC-4B43-BE88-E5BDB5D44C8C@bbn.com> <201007191943.o6JJhIrX004288@sj-core-2.cisco.com> <4C44D2E8.8020904@cisco.com> <5A55A45AE77F5941B18E5457ECAC81880120E9829415@SISPE7MB1.commscope.com> <201007200126.o6K1Qo3n026484@sj-core-1.cisco.com> In-Reply-To: <201007200126.o6K1Qo3n026484@sj-core-1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com X-OriginalArrivalTime: 20 Jul 2010 02:18:12.0133 (UTC) FILETIME=[CD8B1550:01CB27B1] Cc: "Richard L. Barnes" , Hannes Tschofenig , "sipcore@ietf.org" Subject: Re: [sipcore] Location Conveyance Question: Multiple Location X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 21 Jul 2010 02:16:30 -0000 Thanks James James Winterbottom Global Product Manager Andrew GeoLENs IP Location Product Portfolio Email: james.winterbottom@andrew.com Phone: +61-2-42-212938 Mobile: +61-447-773-560 > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf > Of James M. Polk > Sent: Tuesday, 20 July 2010 11:27 AM > To: Winterbottom, James; Paul Kyzivat; James M. Polk > Cc: Richard L. Barnes; Hannes Tschofenig; sipcore@ietf.org > Subject: Re: [sipcore] Location Conveyance Question: Multiple Location > > James > > I logged your comment from a week ago on this, and Jon also agreed to it. > > -04 will have this explicitly allowed. > > James > > At 06:19 PM 7/19/2010, Winterbottom, James wrote: > >By the same token absoluteURI also permits pres:, sip: and sips: URI > >schemes, yet these are explicitly called out, presumably because > >there is specification work that says how to use them for acquiring > >location information. Hannes's comment, and indeed my comment made > >nearly a week ago, are simply calling for the inclusion of the http: > >and http2: URI schemes to also be included because similar > >specification work on how to use these schemes to acquire location > >information exists. > > > >If the argument is that this is covered by the absoluteURI > >component, then presumably that is all the ABNF requires, and the > >sips: sips: and pres: URI schemes can also be removed. > > > >Cheers > >James > > > > > > > > > > > -----Original Message----- > > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf > > > Of Paul Kyzivat > > > Sent: Tuesday, 20 July 2010 8:34 AM > > > To: James M. Polk > > > Cc: Richard L. Barnes; Hannes Tschofenig; sipcore@ietf.org > > > Subject: Re: [sipcore] Location Conveyance Question: Multiple Location > > > > > > > > > > > > James M. Polk wrote: > > > > At 02:12 PM 7/19/2010, Richard L. Barnes wrote: > > > >> I might be mistaken, but it looks to me as if the header ABNF would > > > >> allow the following: > > > >> > > > >> Geolocation: > > , >> foobar> > > > > > > The ABNF permits that (by virtue of allowing absoluteURI, http: is > > > permitted), but the text does not: > > > > > > The Geolocation header field has zero or one locationValue, but > > > MUST NOT contain more than one locationValue. > > > > > > > >sipcore > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From Martin.Thomson@andrew.com Tue Jul 20 21:29:43 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 26CCB3A6A86 for ; Tue, 20 Jul 2010 21:29:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.357 X-Spam-Level: X-Spam-Status: No, score=-7.357 tagged_above=-999 required=5 tests=[AWL=3.241, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfidQXog14XU for ; Tue, 20 Jul 2010 21:29:41 -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 1B8063A684E for ; Tue, 20 Jul 2010 21:29:40 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 21 Jul 2010 04:29:56 +0000 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 o6L4TYQt001400; Wed, 21 Jul 2010 04:29:57 GMT Received: from mail pickup service by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 20:47:40 -0700 Received: from xbh-rcd-201.cisco.com ([72.163.62.200]) by xbh-sjc-231.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 04:30:22 -0700 Received: from xbh-hkg-411.apac.cisco.com ([64.104.123.72]) by xbh-rcd-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 06:20:10 -0500 Received: from xbh-rcd-202.cisco.com ([72.163.62.201]) by xbh-hkg-411.apac.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 14:37:46 +0800 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-rcd-202.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 01:37:44 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 06:37:37 +0000 Received: from sj-inbound-d.cisco.com (sj-inbound-d.cisco.com [128.107.243.13]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6K6bUsS007458 for ; Tue, 20 Jul 2010 06:37:37 GMT X-from-outside-Cisco: 198.135.207.242 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApwCAOrgREzGh8/ymWdsb2JhbACBRIFcm2xhFQEBAQEBCAsKBxEipgWJNJFugloBgVRzBIN9hw0Mhz8 X-IronPort-AV: E=Sophos;i="4.55,231,1278288000"; d="scan'208,217";a="153053104" Received: from unknown (HELO csmailgw2.commscope.com) ([198.135.207.242]) by sj-inbound-d.cisco.com with ESMTP; 20 Jul 2010 06:37:36 +0000 Received: from [10.86.20.102] ([10.86.20.102]:64317 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S340156Ab0GTGhK (ORCPT ); Tue, 20 Jul 2010 01:37:10 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Tue, 20 Jul 2010 01:37:10 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 20 Jul 2010 14:37:02 +0800 From: "Thomson, Martin" To: "Peterson, Jon" , Roger Marshall , "James M. Polk" , "sipcore@ietf.org" Date: Tue, 20 Jul 2010 14:39:11 +0800 Thread-Topic: composition or just indirection (was: location-conveyance-03 just submitted) Thread-Index: Acsi+NJTa+ULYvovSE2TL/bYrSlncwAKAPJQABWWaxYADURloAAvdkeAABJoDoQAjAHMIAApbBSCABIVO7A= Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB7730BA@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03EB772EBB@SISPE7MB1.commscope.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_8B0A9FCBB9832F43971E38010638454F03EB7730BASISPE7MB1comm_" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com X-OriginalArrivalTime: 20 Jul 2010 06:37:44.0751 (UTC) FILETIME=[0F8C03F0:01CB27D6] Subject: Re: [sipcore] composition or just indirection (was: location-conveyance-03 just 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: Wed, 21 Jul 2010 04:29:43 -0000 --_000_8B0A9FCBB9832F43971E38010638454F03EB7730BASISPE7MB1comm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 UmVzb2x2aW5nIHRoZSBzZW1hbnRpY3Mgb2YgdGhlIGhlYWRlciBpcyB0aGUgYmlnZ2VzdCBwcm9i bGVtLg0KDQpNeSBvcmlnaW5hbCB2aWV3IHdhcyB0aGF0IHRoZSBpbnRlbnQgd2FzIHRvIGNvbnZl eSB0aGUgbWVzc2FnZSB0aGF0IHRoZSByZWZlcmVuY2VkIGxvY2F0aW9uIGluZm9ybWF0aW9uIGlz IGZvciB0aGUgZW50aXR5IGlkZW50aWZpZWQgaW4gdGhlIEZyb20gaGVhZGVyLiAgVGhlIGlkZWEg d2FzIHRoZSBTSVAgcmVxdWVzdCBmb3JnZWQgYSBsaW5rIGJldHdlZW4gdGhlIGlkZW50aXR5IGFu ZCB0aGUgbG9jYXRpb24gaW4gdGhlIFBJREYtTE8gZG9jdW1lbnQuDQoNCkkgd2FzIGxhdGVyIGNv bnZpbmNlZCB0aGF0IHRoaXMgc29ydCBvZiBzdHJvbmcgc2VtYW50aWMgd2FzIHVubmVjZXNzYXJ5 LiAgVGhlIGlkZWEgb2Yg4oCccmVsZXZhbmNl4oCdIGlzIGEgYmV0dGVyIHdheSBvZiBhcHByb2Fj aGluZyB0aGUgcHJvYmxlbS4NCg0KTG9jYXRpb24gY2FuIGJlIGNvbnZleWVkIGluIFNJUCBhbHJl YWR5LCBzbyBpZiB0aGUgaGVhZGVyIGlzIHRvIGhhdmUgYW55IHZhbHVlLCBpdCBuZWVkcyBhIGNs ZWFybHkgZGVmaW5lZCBzZW1hbnRpYy4gIEhvdyBhYm91dDoNCg0KVGhlIEdlb2xvY2F0aW9uIGhl YWRlciBpZGVudGlmaWVzIGEgUElERiBkb2N1bWVudCBieSB2YWx1ZSBvciByZWZlcmVuY2UuICBB IEdlb2xvY2F0aW9uIGhlYWRlciBpbmRpY2F0ZXMgdGhhdCBhKSB0aGlzIHBhcnRpY3VsYXIgUElE RiBkb2N1bWVudCBjb250YWlucyBsb2NhdGlvbiBpbmZvcm1hdGlvbiBhbmQgYikgdGhhdCB0aGlz IGxvY2F0aW9uIGluZm9ybWF0aW9uIGluIHBhcnRpY3VsYXIgbWF5IGJlIHJlbGV2YW50IHRvIHRo ZSBwcm9jZXNzaW5nIG9mIHRoZSBTSVAgcmVxdWVzdC4NCg0KVGhpcyBpcyBpbnRlbnRpb25hbGx5 IHNvZnQsIGJ1dCAoSSBiZWxpZXZlKSBub3QgdG9vIHZhZ3VlLiAgWWVzLCB5b3UgY2FuIG1ha2Ug dGhlIGxlYXAgZnJvbSB0aGlzIHRvIGNvbmNsdWRlIHRoYXQgdGhlIFRhcmdldCBhbmQgdGhlIHJl cXVlc3Qgb3JpZ2luYXRvciBhcmUgb25lIGFuZCB0aGUgc2FtZS4gIEEgc2hvcnRlciBqdW1wIHdv dWxkIGJlIHRvIHNheSB0aGF0IHRoZXNlIGVudGl0aWVzIGFyZSBhdCB0aGUgc2FtZSBsb2NhdGlv bi4gIFRoZXNlIHN0cm9uZ2VyIHNlbWFudGljcyBhcmUgdW5uZWNlc3NhcnnigKYgb3IgYXQgbGVh c3QgaGFyZCB0byBwcm92ZS4NCg0KLS0NCg0KVGhlIHJlYXNvbiB0aGF0IEkgcHJvcG9zZWQgQ29u dGVudC1Mb2NhdGlvbiBpcyBiZWNhdXNlIGl0IGRvZXMgYXdheSB3aXRoIHRoZSBpZGVhIHRoYXQg dGhlcmUgYXJlIG11bHRpcGxlIHNvdXJjZXMuICBJbnN0ZWFkLCBpdCBpZGVudGlmaWVzIGEgc2lu Z2xlIGF1dGhvcml0eSBhbmQgcmVzb3VyY2UuICBUaGF0IGF1dGhvcml0eSBtaWdodCBjb21wb3Nl IG11bHRpcGxlIHNvdXJjZXMsIGJ1dCB0aGF0IGJlY29tZXMgb3BhcXVlLiAgSWYgSSB0aGluayBv ZiBhIHNpbmdsZSBIVFRQIHJlc291cmNlLCB0aGUgaWRlYSB0aGF0IHRoZSByZXNvdXJjZSBtaWdo dCBoYXZlIGRpZmZlcmVudCByZXByZXNlbnRhdGlvbnMgZG9lc27igJl0IGNhdXNlIChtdWNoKSBj b25zdGVybmF0aW9uLg0KDQpUaGUgYmlnZ2VyIHByb2JsZW0gYXJpc2VzIHdoZW4geW91IGFsbG93 IGZyZWUgcmVpZ24gdG8gZGlmZmVyZW50IGF1dGhvcml0aWVzIHdoaWNoIGVhY2ggaGF2ZSB0aGVp ciBkaWZmZXJlbnQgdmlld3MuICBBbGxvdyB0aGUgaW5jbHVzaW9uIG9mIHN0YXRpYyBhbmQgZHlu YW1pYywgYnV0IG1ha2UgaXQgY2xlYXIgdGhhdCBib3RoIHN0YXRpYyBhbmQgZHluYW1pYyBoYXZl IHRvIGJlIHRoZSBzYW1lIHRoaW5nL3Jlc291cmNlLg0KDQpPbmNlIGEgc2luZ2xlIGF1dGhvcml0 eSBpcyBpc29sYXRlZCwgdGhlbiBhbGwgeW91IGhhdmUgdG8gd29ycnkgYWJvdXQgaXMgdGhlIGNv bnRlbnRzIG9mIHRoZSBQSURGLiAgV2UgaGF2ZSB0aGUgbWVhbnMgdG8gZGVhbCB3aXRoIHRoYXQg d2l0aCA0NDc5IChpbiBnZW5lcmFsKSBhbmQgNTQ5MSAoZm9yIGxvY2F0aW9uIHNwZWNpZmljYWxs eSkuDQoNCkFuZCB0aGUgVUFDIG1ha2VzIHRoZSBkZWNpc2lvbiBhYm91dCB3aGljaCBhdXRob3Jp dHkgdG8gbm9taW5hdGUuDQoNCi0tTWFydGluDQoNCnAucy4gTm90ZSB0aGF0IHRoZSBkZWZpbml0 aW9uIHdvcmRpbmcgYWJvdmUgd291bGQgcHJlY2x1ZGUgdGhlIHVzZSBvZiBhIGdlbzogVVJJLiAg SeKAmW0gb3BlbiB0byBtYWtpbmcgdGhlIHN0YXRlbWVudCBmdXp6aWVyLCBpZiB0aGVyZSBpcyBj b25zZW5zdXMgdGhhdCBvdGhlciBsb2NhdGlvbiBmb3JtYXRzIGFyZSBhY2NlcHRhYmxlIG9yIGRl c2lyYWJsZS4NCg0KRnJvbTogUGV0ZXJzb24sIEpvbiBbbWFpbHRvOmpvbi5wZXRlcnNvbkBuZXVz dGFyLmJpel0NClNlbnQ6IFR1ZXNkYXksIDIwIEp1bHkgMjAxMCA3OjI5IEFNDQpUbzogVGhvbXNv biwgTWFydGluOyBSb2dlciBNYXJzaGFsbDsgSmFtZXMgTS4gUG9sazsgc2lwY29yZUBpZXRmLm9y Zw0KU3ViamVjdDogUmU6IGNvbXBvc2l0aW9uIG9yIGp1c3QgaW5kaXJlY3Rpb24gKHdhczogbG9j YXRpb24tY29udmV5YW5jZS0wMyBqdXN0IHN1Ym1pdHRlZCkNCg0KDQpJ4oCZbSBzdXJlIHdl4oCZ cmUgYWxsIGdvaW5nIHRvIGhhdmUgdG8gZGlzY3VzcyB0aGlzIGEgYml0IGluIE1hYXN0cmljaHQs IGJ1dCB0aGVyZSBhcmUgYSBjb3VwbGUgYmFzaWMgcG9pbnRzIGhlcmUgSSB0aGluayB3ZSBuZWVk IHRvIHRlZSB1cC4gSSBjZXJ0YWlubHkgZGlkbuKAmXQgbWVhbiB0byBzdWdnZXN0IHRoYXQgYSBy ZXF1ZXN0IGNhbiBvbmx5IGluY2x1ZGUgYSBzaW5nbGUgbG9jYXRpb24gKGkuZS4sIHRoYXQgYW55 IGNvbnRyaWJ1dGluZyBwaWVjZSBvZiBsb2NhdGlvbiBpbmZvcm1hdGlvbiBkZXNpZ25hdGVzIHRo ZSBzYW1lIHBsYWNlLCBqdXN0IHdpdGggdmFyeWluZyBkZWdyZWVzIG9mIGFjY3VyYWN5IG9yIHRp bWVsaW5lc3Mgb3Igc29tZXRoaW5nKS4gUmF0aGVyLCBJIGJlbGlldmUgYSBwcmVzZW5jZSBkb2N1 bWVudCBkZXNjcmliZXMgYSBzaW5nbGUgZW50aXR5IOKAkyBtdWx0aXBsZSBsb2NhdGlvbnMgY29t ZSBhYm91dCBiZWNhdXNlIHZhcmlvdXMgZGV2aWNlcyBhbmQgc2VydmljZXMgYXNzb2NpYXRlZCB3 aXRoIHRoYXQgc2luZ2xlIGVudGl0eSBtYXkgYXR0cmlidXRlIHZhcmlvdXMgbG9jYXRpb25zIHRv IHRoZSBlbnRpdHkuDQoNCkdldHRpbmcgYmFjayB0byBmdW5kYW1lbnRhbHMsIHdlIGRvbuKAmXQg bmVlZCBhIEdlb2xvY2F0aW9uIGhlYWRlciBpbiBvcmRlciB0byBjYXJyeSBsb2NhdGlvbiBpbiBT SVAuIFRoZXJlIGFyZSBNSU1FIGJvZGllcyBmb3IgdGhhdCAoaW5jbHVkaW5nIENvbnRlbnQtSW5k aXJlY3Rpb24gYm9kaWVzIGZvciBMYnlSLCBvciBwZXJoYXBzIENvbnRlbnQtTG9jYXRpb24gYXMg eW91IHN1Z2dlc3QpLCBhbmQgd2UgY2FuIGluY2x1ZGUgc2V2ZW50ZWVuIGRpZmZlcmVudCBsb2Nh dGlvbiBvYmplY3RzIGlmIHdlIHdhbnQgdG8sIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciB0aGVyZSBh cmUgemVybyBvciBvbmUgb3IgZmlmdGVlbiBHZW9sb2NhdGlvbiBoZWFkZXJzLiBXZSBkb27igJl0 IG5lZWQgYSBsb2NhdGlvbiBjb252ZXlhbmNlIHNwZWNpZmljYXRpb24gb3IgYSBHZW9sb2NhdGlv biBoZWFkZXIgdG8gZW5hYmxlIHRoYXQsIFNJUCBoYXMgYWx3YXlzIGJlZW4gYWJsZSB0byBkbyBp dCwgYW5kIHlvdeKAmWxsIHN0aWxsIGJlIGFibGUgdG8gYWRkIHJhbmRvbSBNSU1FIGJvZGllcyB0 aGF0IGNvbnRhaW4gbG9jYXRpb24gaW5mb3JtYXRpb24gZXZlbiBpZiB0aGVyZSBpcyBhIEdlb2xv Y2F0aW9uIGhlYWRlciB3aGljaCBkb2VzIG5vdCBwb2ludCB0byB0aGVtLiBTbyB3aGF0IGRvZXMg dGhlIEdlb2xvY2F0aW9uIGhlYWRlciBhbmQgbG9jYXRpb24gY29udmV5YW5jZSBzcGVjaWZpY2F0 aW9uIGJ1eSB1cz8NCg0KSeKAmXZlIGFsd2F5cyBuYWl2ZWx5IHRob3VnaHQgdGhhdCB0aGUgR2Vv bG9jYXRpb24gaGVhZGVyIHByb3ZpZGVzIGEgY291cGxpbmcgYmV0d2VlbiB0aGlzIHBhcnRpY3Vs YXIgU0lQIHNlc3Npb24gYW5kIGFuIGVudGl0eSB3aG9zZSBsb2NhdGlvbiBpcyBkZXNpZ25hdGVk IGJ5IGEgUElERiBkb2N1bWVudC4gVGhlIGVudGl0eSBpcyB0aGUgZ2VvcHJpdiBUYXJnZXQsIGFu ZCBpcyBwcm9iYWJseSAodGhvdWdoIG5vdCBuZWNlc3NhcmlseSkgcmVsYXRlZCB0byB0aGUgcGFy dHkgaWRlbnRpZmllZCBieSB0aGUgY2xhc3NpYyBGcm9tIGhlYWRlciBmaWVsZCBvZiB0aGUgU0lQ IHJlcXVlc3QuIFRoZSBHZW9sb2NhdGlvbiBoZWFkZXIgdGVsbHMgdXMgdGhhdCBmb3IgdGhlIHB1 cnBvc2VzIG9mIHRoZSBTSVAgc2Vzc2lvbiBiZWluZyBuZWdvdGlhdGVkLCB0aGUgbG9jYXRpb24g b2YgdGhpcyBUYXJnZXQgaXMgc29tZWhvdyByZWxldmFudC4uLiB0aGUgYm9sZGVzdCBpbnRlcnBy ZXRhdGlvbiB3b3VsZCBiZSB0aGF0IHRoaXMgVGFyZ2V04oCZcyBsb2NhdGlvbiBzaG91bGQgYmUg Y29uc2lkZXJlZCB0aGUgc291cmNlIG9mIHRoZSByZXF1ZXN0LiBKdXN0IGF0dGFjaGluZyBsb2Nh dGlvbi1hd2FyZSBNSU1FIGJvZGllcyB3aXRob3V0IHRoZSBHZW9sb2NhdGlvbiBoZWFkZXIgdG8g U0lQIHJlcXVlc3RzIGRvZXNu4oCZdCBjb252ZXkgdGhlIHNhbWUgc2VtYW50aWNzIOKAkyB0aG9z ZSBib2RpZXMgY291bGQgbWVhbiBhbnl0aGluZywgYW5kIHByZXN1bWFibHkgdGhlIHJlY2Vpdmlu ZyBhcHBsaWNhdGlvbiB3b3VsZCBzb3J0IHRocm91Z2ggdGhlbSBhdCBpdHMgZGlzY3JldGlvbi4N Cg0KV2hlcmUgSSBnZXQgY29uZnVzZWQgaXMgd2hlbiBJIHN0YXJ0IHRyeWluZyB0byB1bmRlcnN0 YW5kIHdoYXQgaXQgd291bGQgbWVhbiBzZW1hbnRpY2FsbHkgZm9yIGEgU0lQIHNlc3Npb24gdG8g YmUgY291cGxlZCB3aXRoIG1vcmUgdGhhbiBvbmUgVGFyZ2V0LiBBZ2FpbiwgSSBjYW4gaW1hZ2lu ZSBoeXBvdGhldGljYWxseSBhIFNJUCByZXF1ZXN0IGNvbnRhaW5pbmcgdW5zb3J0ZWQgTUlNRSBi b2RpZXMgdGhhdCB0YWxrIGFib3V0IGRpZmZlcmVudCBUYXJnZXRzIHRvIGFzc2lzdCBzb21lIHNw ZWNpZmljIGFwcGxpY2F0aW9uIHRoYXQga25vd3MgaG93IHRvIHJlY29uY2lsZSB0aGVtLCBidXQg aGVyZSBJIG1lYW4gdXNpbmcgdGhlIEdlb2xvY2F0aW9uIGhlYWRlciB0byBjb3VwbGUgYSBTSVAg cmVxdWVzdCB3aXRoIGxvY2F0aW9uIGluZm9ybWF0aW9uIGFib3V0IGRpZmZlcmVudCBUYXJnZXRz LiBJcyB0aGVyZSBhY3R1YWxseSBhIHVzZSBjYXNlL3JlcXVpcmVtZW50IGZvciB0aGF0PyBJZiBu b3QsIGFuZCB3ZSBvbmx5IHdhbnQgdG8gY291cGxlIGEgU0lQIHJlcXVlc3Qgd2l0aCBvbmUgVGFy Z2V0LCB0aGVuIEkgZmFpbCB0byBzZWUgd2h5IGNvbXBvc2luZyBsb2NhdGlvbiBpbmZvcm1hdGlv biBhYm91dCB0aGUgc2FtZSBUYXJnZXQgaW50byBhIHNpbmdsZSBQSURGIGJvZHkgd291bGQgYmUg YSBwcm9ibGVtLiBIYXZpbmcgbG9jYXRpb24gaW5mb3JtYXRpb24gYWJvdXQgdGhlIHNhbWUgZW50 aXR5IGZhaWwgdG8gYmUgb3JnYW5pemVkIGluIG9uZSBib2R5IHRocm91Z2ggUkZDNDQ3OSB3b3Vs ZG7igJl0IG1ha2Ugc2Vuc2UsIGFueXdheS4NCg0KSSB0aGluayBpZiB3ZSB1bmRlcnN0YW5kIHRo ZSBzZW1hbnRpY3MgYnkgd2hpY2ggdGhlIEdlb2xvY2F0aW9uIGhlYWRlciDigJxjb3VwbGVz4oCd IFBJREYgd2l0aCBhIFNJUCBzZXNzaW9uLCB0aGVuIHdl4oCZbGwgYmV0dGVyIHVuZGVyc3RhbmQg YWxsIG9mIHRoaXMuIElmIHRoZSBHZW9sb2NhdGlvbiBoZWFkZXIgb25seSBleGlzdHMgdG8gbm90 aWZ5IGxhenkgaW50ZXJtZWRpYXJpZXMgdGhhdCB0aGVyZSBhcmUgbG9jYXRpb24tc2Vuc2l0aXZl IGJvZGllcyBpbiB0aGUgcmVxdWVzdCBvciBzb21ld2hlcmUgb3V0IG9uIHRoZSBuZXQsIHdpdGhv dXQgaW1wbHlpbmcgYW55dGhpbmcgYWJvdXQgdGhlIFRhcmdldCBvciB0aGUgcmVsYXRpb25zaGlw IG9mIHRob3NlIGxvY2F0aW9ucyB0byB0aGUgU0lQIHJlcXVlc3QsIHRoZW4gdGhpcyB3aG9sZSBz cGVjaWZpY2F0aW9uIGlzIHByb2JhYmx5IG1vcmUgdHJvdWJsZSB0aGFuIGl04oCZcyB3b3J0aCDi gJMgaXQgcmVhbGx5IHdvdWxkbuKAmXQgcHJvdmlkZSBtdWNoIGluY3JlbWVudGFsIHZhbHVlIGFi b3ZlIHRoZSBiYXNpYyBhYmlsaXR5IG9mIFNJUCB0byBjYXJyeSBhbGwgc29ydHMgb2YgYm9kaWVz LCBpbmNsdWRpbmcgbG9jYXRpb24gYm9kaWVzLiBJZiB0aGVyZSBhcmUsIGhvd2V2ZXIsIG1vcmUg YmluZGluZyBzZW1hbnRpY3MgaGVyZSwgdGhlbiB3ZSBwcm9iYWJseSB3b27igJl0IGJlIGFibGUg dG8gYWdyZWUgb24gdGhlIG5lZWQgZm9yIHNvbGl0YXJ5IG9yIG11bHRpcGxlIEdlb2xvY2F0aW9u IGhlYWRlcnMgdW50aWwgd2UgYWdyZWUgb24gd2hhdCB0aG9zZSBzZW1hbnRpY3MgYXJlLg0KDQpK b24gUGV0ZXJzb24NCk5ldVN0YXIsIEluYy4NCg0KDQpPbiA3LzE4LzEwIDc6MjUgUE0sICJUaG9t c29uLCBNYXJ0aW4iIDxNYXJ0aW4uVGhvbXNvbkBhbmRyZXcuY29tPiB3cm90ZToNCkhpIEpvbiwN Cg0KSSBhZG1pdCBhIGZhaXIgZGVncmVlIG9mIHN5bXBhdGh5IGZvciBSb2dlcuKAmXMgc3VnZ2Vz dGlvbi4gIEFmdGVyIGFsbCwgdGhlIGFiaWxpdHkgdG8gaW5jbHVkZSBtdWx0aXBsZSBsb2NhdGlv biDigJx2YWx1ZXPigJ0gaW4gdGhlIHNhbWUgU0lQIHJlcXVlc3QgaXMgYSBmZWF0dXJlIHRoYXQg aGFzIGV4aXN0ZWQgZm9yIG1hbnkgeWVhcnMuICBBIG51bWJlciBvZiBpbXBsZW1lbnRhdGlvbnMg aGF2ZSBjb21lIHRvIHJlbHkgb24gdGhpcyBtZWNoYW5pc207IHBlb3BsZSBhcmUgYnVpbGRpbmcg YW5kIGhhdmUgYnVpbHQgc29sdXRpb25zIGJhc2VkIG9uIGVhcmxpZXIgZHJhZnQsIGZ1bGx5IGF3 YXJlIG9mIHRoZSByaXNrcyBpbiBpbXBsZW1lbnRpbmcgYW4gaW50ZXJuZXQgZHJhZnQuDQoNCkF0 IHNvbWUgcG9pbnQsIGl0IG1pZ2h0IGJlIG5lY2Vzc2FyeSB0byBzd2FsbG93IGFueSBkaXNjb21m b3J0IGFuZCByZWNvZ25pemUgdGhhdCB0aGUgY29uc2VxdWVuY2VzIG9mIGFuIGltcGVyZmVjdCBz b2x1dGlvbiBhcmUgbGVzcyB0aGFuIHRoZSBjb25zZXF1ZW5jZXMgb2YgYSBjaGFuZ2Ugb2YgdGhl IG5hdHVyZSB5b3Ugc3VnZ2VzdC4NCg0KQWx0ZXJpbmcgcGVyc3BlY3RpdmUgbWlnaHQgb2ZmZXIg YSBzb2x1dGlvbi4NCg0KVGhlIGlkZWEgdGhhdCB0aGVyZSBhcmUgbXVsdGlwbGUgaXRlbXMgdGhh dCBhcmUgY29tcG9zaXRlZCBtaWdodCBiZSBjb3VudGVycHJvZHVjdGl2ZS4gIEluIHRoaXMgd29y bGQtdmlldywgeW91IGhhdmUgdG8gcmVjb25jaWxlIGEgbnVtYmVyIG9mIHBlcnNwZWN0aXZlcy4g IEluIHRoaXMsIHlvdSBhcmUgYWJzb2x1dGVseSBjb3JyZWN0OiBkb2luZyB0aGF0IGF0IHR3byBs YXllcnMgaXMgYmFkLiAgQ29tcG9zaXRpb24gaXMgYSBoYXJkIHByb2JsZW0gYWxyZWFkeS4gIE1v dmluZyBpdCBpbnRvIFNJUCBvbmx5IGNvbXBsaWNhdGVzIGl0IGZ1cnRoZXIuDQoNClRoZSBhbHRl cm5hdGl2ZSBpcyB0byBpbWFnaW5lIGEgc2luZ2xlIGxvZ2ljYWwgcmVzb3VyY2UgdGhhdCByZXBy ZXNlbnRzIHRoZSBsb2NhdGlvbiBvZiB0aGUgVGFyZ2V0LiAgQSBsb2NhdGlvbiBieSB2YWx1ZSBp cyBhIHJlcHJlc2VudGF0aW9uIG9mIHRoaXMgcmVzb3VyY2U6IGEgc25hcHNob3QuICBMb2NhdGlv biBieSByZWZlcmVuY2Ugb2ZmZXJzIGEgbWVhbnMgZm9yIGFueSBlbnRpdHkgdG8gaWRlbnRpZnkg YW5kIGFjcXVpcmUgYSB2aWV3IG9mIHRoZSByZXNvdXJjZSwgaW5kZXBlbmRlbnQgb2YgdGhhdCBz bmFwc2hvdC4gIFRoZSBhdXRob3JpdHkgZm9yIHRoZSByZXNvdXJjZSBtaWdodCBvZmZlciB0aGUg c2FtZSByZXByZXNlbnRhdGlvbiwgb3IgaXQgY291bGQgb2ZmZXIgb25lIGJldHRlciBzdWl0ZWQg dG8gdGhlIHJlY2lwaWVudC4gIFRoZSByZXByZXNlbnRhdGlvbiBtaWdodCBiZSB1cGRhdGVkLCBp dCBtaWdodCBiZSBhbHRlcmVkIGJhc2VkIG9uIGFuIGF1dGhvcml6YXRpb24gcG9saWN5LCBvciBz b21ldGhpbmcgZWxzZSAobGFuZ3VhZ2UgcHJlZmVyZW5jZXMpLiAgUmVnYXJkbGVzcyBvZiBob3cg aXQgaXMgcmVwcmVzZW50ZWQsIGl0IGlzIHN0aWxsIHRoZSBzYW1lIHJlc291cmNlLg0KDQpJbiBz aW1wbGUgdGVybXMsIHlvdSBzdGF0ZSB0aGF0IHRoZSByZXF1ZXN0IGNhbiBvbmx5IGluY2x1ZGUg YSBzaW5nbGUgX2xvY2F0aW9uXy4gIFdoZW4gYSBsb2NhdGlvbiB2YWx1ZSBhbmQgcmVmZXJlbmNl IGFyZSBib3RoIGluY2x1ZGVkLCB0aGV5IHJlcHJlc2VudCB0aGUgX3NhbWVfIGxvY2F0aW9uLg0K DQpUaGlzIGlzIHdoeSBJIHN1Z2dlc3RlZCB0aGF0IENvbnRlbnQtTG9jYXRpb24gYmUgYm9ycm93 ZWQuICBJbiBIVFRQLCBDb250ZW50LUxvY2F0aW9uIHNheXMgLSBpZiB5b3Ugd2FudCB0byBrbm93 IHdoZXJlIHRoaXMgcmVzb3VyY2UgcmVhbGx5IGxpdmVzLCBoZXJlIGlzIHdoZXJlIHlvdSBjYW4g ZmluZCBpdC4NCg0KTm93IHRoaXMgbWlnaHQgYmUgc2hlZXIgc29waGlzdHJ5LCBidXQgaXQgbWln aHQgb2ZmZXIgYSB3YXkgb3V0LiAgVGhlIGNvbXBvc2l0aW9uIHByb2JsZW1zIGFyZSBsZWZ0IG91 dCBvZiBTSVAuDQoNCuKApg0K --_000_8B0A9FCBB9832F43971E38010638454F03EB7730BASISPE7MB1comm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOnA9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206 b2ZmaWNlOnBvd2VycG9pbnQiIHhtbG5zOmE9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOmFjY2VzcyIgeG1sbnM6ZHQ9InV1aWQ6QzJGNDEwMTAtNjVCMy0xMWQxLUEyOUYtMDBBQTAw QzE0ODgyIiB4bWxuczpzPSJ1dWlkOkJEQzZFM0YwLTZEQTMtMTFkMS1BMkEzLTAwQUEwMEMxNDg4 MiIgeG1sbnM6cnM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206cm93c2V0IiB4bWxuczp6PSIj Um93c2V0U2NoZW1hIiB4bWxuczpiPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpw dWJsaXNoZXIiIHhtbG5zOnNzPSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTpzcHJl YWRzaGVldCIgeG1sbnM6Yz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6Y29tcG9u ZW50OnNwcmVhZHNoZWV0IiB4bWxuczpvZGM9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2Zm aWNlOm9kYyIgeG1sbnM6b2E9InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOmFjdGl2 YXRpb24iIHhtbG5zOmh0bWw9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1odG1sNDAiIHhtbG5z OnE9Imh0dHA6Ly9zY2hlbWFzLnhtbHNvYXAub3JnL3NvYXAvZW52ZWxvcGUvIiB4bWxuczpydGM9 Imh0dHA6Ly9taWNyb3NvZnQuY29tL29mZmljZW5ldC9jb25mZXJlbmNpbmciIHhtbG5zOkQ9IkRB VjoiIHhtbG5zOlJlcGw9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vcmVwbC8iIHhtbG5z Om10PSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC9tZWV0aW5n cy8iIHhtbG5zOngyPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS9leGNlbC8y MDAzL3htbCIgeG1sbnM6cHBkYT0iaHR0cDovL3d3dy5wYXNzcG9ydC5jb20vTmFtZVNwYWNlLnhz ZCIgeG1sbnM6b2lzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29h cC9vaXMvIiB4bWxuczpkaXI9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9zb2FwL2RpcmVjdG9yeS8iIHhtbG5zOmRzPSJodHRwOi8vd3d3LnczLm9yZy8yMDAwLzA5L3ht bGRzaWcjIiB4bWxuczpkc3A9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2lu dC9kc3AiIHhtbG5zOnVkYz0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYyIg eG1sbnM6eHNkPSJodHRwOi8vd3d3LnczLm9yZy8yMDAxL1hNTFNjaGVtYSIgeG1sbnM6c3ViPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL3NoYXJlcG9pbnQvc29hcC8yMDAyLzEvYWxlcnRz LyIgeG1sbnM6ZWM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDEvMDQveG1sZW5jIyIgeG1sbnM6c3A9 Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC8iIHhtbG5zOnNwcz0iaHR0 cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvIiB4bWxuczp4c2k9Imh0 dHA6Ly93d3cudzMub3JnLzIwMDEvWE1MU2NoZW1hLWluc3RhbmNlIiB4bWxuczp1ZGNzPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3NvYXAiIHhtbG5zOnVkY3hmPSJodHRw Oi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL2RhdGEvdWRjL3htbGZpbGUiIHhtbG5zOnVkY3AycD0i aHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9kYXRhL3VkYy9wYXJ0dG9wYXJ0IiB4bWxuczp3 Zj0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9zaGFyZXBvaW50L3NvYXAvd29ya2Zsb3cv IiB4bWxuczpkc3NzPSJodHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA2L2Rp Z3NpZy1zZXR1cCIgeG1sbnM6ZHNzaT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZp Y2UvMjAwNi9kaWdzaWciIHhtbG5zOm1kc3NpPSJodHRwOi8vc2NoZW1hcy5vcGVueG1sZm9ybWF0 cy5vcmcvcGFja2FnZS8yMDA2L2RpZ2l0YWwtc2lnbmF0dXJlIiB4bWxuczptdmVyPSJodHRwOi8v c2NoZW1hcy5vcGVueG1sZm9ybWF0cy5vcmcvbWFya3VwLWNvbXBhdGliaWxpdHkvMjAwNiIgeG1s bnM6bT0iaHR0cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4 bWxuczptcmVscz0iaHR0cDovL3NjaGVtYXMub3BlbnhtbGZvcm1hdHMub3JnL3BhY2thZ2UvMjAw Ni9yZWxhdGlvbnNoaXBzIiB4bWxuczpzcHdwPSJodHRwOi8vbWljcm9zb2Z0LmNvbS9zaGFyZXBv aW50L3dlYnBhcnRwYWdlcyIgeG1sbnM6ZXgxMnQ9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j b20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi90eXBlcyIgeG1sbnM6ZXgxMm09Imh0dHA6Ly9zY2hl bWFzLm1pY3Jvc29mdC5jb20vZXhjaGFuZ2Uvc2VydmljZXMvMjAwNi9tZXNzYWdlcyIgeG1sbnM6 cHB0c2w9Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5jb20vc2hhcmVwb2ludC9zb2FwL1NsaWRl TGlicmFyeS8iIHhtbG5zOnNwc2w9Imh0dHA6Ly9taWNyb3NvZnQuY29tL3dlYnNlcnZpY2VzL1No YXJlUG9pbnRQb3J0YWxTZXJ2ZXIvUHVibGlzaGVkTGlua3NTZXJ2aWNlIiB4bWxuczpaPSJ1cm46 c2NoZW1hcy1taWNyb3NvZnQtY29tOiIgeG1sbnM6c3Q9IiYjMTsiIHhtbG5zPSJodHRwOi8vd3d3 LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PUNvbnRl bnQtVHlwZSBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1ldGEgbmFtZT1H ZW5lcmF0b3IgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTIgKGZpbHRlcmVkIG1lZGl1bSkiPg0K PHRpdGxlPlJlOiBjb21wb3NpdGlvbiBvciBqdXN0IGluZGlyZWN0aW9uICh3YXM6IGxvY2F0aW9u LWNvbnZleWFuY2UtMDMganVzdA0Kc3VibWl0dGVkKTwvdGl0bGU+DQo8c3R5bGU+DQo8IS0tDQog LyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJy aWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0K QGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1 IDQgNCAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29Ob3JtYWwsIGxpLk1z b05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MG1tOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4i LCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6 IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMjQ0MDYxO30NCi5Nc29DaHBEZWZhdWx0 DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBh Z2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3Mi4wcHQg NzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0 aW9uMTt9DQotLT4NCjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCiA8bzpzaGFw ZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZd LS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9RU4tQVUgbGluaz1ibHVl IHZsaW5rPXB1cnBsZT4NCg0KPGRpdiBjbGFzcz1Xb3JkU2VjdGlvbjE+DQoNCjxwIGNsYXNzPU1z b05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJy aSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+UmVzb2x2aW5nIHRoZSBzZW1hbnRpY3Mg b2YgdGhlIGhlYWRlciBpcyB0aGUgYmlnZ2VzdCBwcm9ibGVtLsKgIDxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0 O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYxJz48bzpw PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K Y29sb3I6IzI0NDA2MSc+TXkgb3JpZ2luYWwgdmlldyB3YXMgdGhhdCB0aGUgaW50ZW50IHdhcyB0 byBjb252ZXkgdGhlIG1lc3NhZ2UNCnRoYXQgdGhlIHJlZmVyZW5jZWQgbG9jYXRpb24gaW5mb3Jt YXRpb24gaXMgZm9yIHRoZSBlbnRpdHkgaWRlbnRpZmllZCBpbiB0aGUNCkZyb20gaGVhZGVyLiDC oFRoZSBpZGVhIHdhcyB0aGUgU0lQIHJlcXVlc3QgZm9yZ2VkIGEgbGluayBiZXR3ZWVuIHRoZSBp ZGVudGl0eQ0KYW5kIHRoZSBsb2NhdGlvbiBpbiB0aGUgUElERi1MTyBkb2N1bWVudC48bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0 NDA2MSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCmNvbG9yOiMyNDQwNjEnPkkgd2FzIGxhdGVyIGNvbnZpbmNlZCB0aGF0IHRoaXMg c29ydCBvZiBzdHJvbmcgc2VtYW50aWMgd2FzDQp1bm5lY2Vzc2FyeS7CoCBUaGUgaWRlYSBvZiDi gJxyZWxldmFuY2XigJ0gaXMgYSBiZXR0ZXIgd2F5IG9mIGFwcHJvYWNoaW5nIHRoZQ0KcHJvYmxl bS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHls ZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0K Y29sb3I6IzI0NDA2MSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMyNDQwNjEnPkxvY2F0aW9uIGNhbiBiZSBjb252ZXll ZCBpbiBTSVAgYWxyZWFkeSwgc28gaWYgdGhlIGhlYWRlciBpcyB0bw0KaGF2ZSBhbnkgdmFsdWUs IGl0IG5lZWRzIGEgY2xlYXJseSBkZWZpbmVkIHNlbWFudGljLsKgIEhvdyBhYm91dDo8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1z aXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0 NDA2MSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwg c3R5bGU9J21hcmdpbi1sZWZ0OjM2LjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7 DQpmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO2NvbG9yOiMyNDQwNjEnPlRoZSBH ZW9sb2NhdGlvbiBoZWFkZXIgaWRlbnRpZmllcw0KYSBQSURGIGRvY3VtZW50IGJ5IHZhbHVlIG9y IHJlZmVyZW5jZS7CoCBBIEdlb2xvY2F0aW9uIGhlYWRlciBpbmRpY2F0ZXMgdGhhdCBhKSB0aGlz DQpwYXJ0aWN1bGFyIFBJREYgZG9jdW1lbnQgY29udGFpbnMgbG9jYXRpb24gaW5mb3JtYXRpb24g YW5kIGIpIHRoYXQgdGhpcyBsb2NhdGlvbg0KaW5mb3JtYXRpb24gaW4gcGFydGljdWxhciBtYXkg YmUgcmVsZXZhbnQgdG8gdGhlIHByb2Nlc3Npbmcgb2YgdGhlIFNJUCByZXF1ZXN0LjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNp emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0 MDYxJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48 c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMt c2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+VGhpcyBpcyBpbnRlbnRpb25hbGx5IHNvZnQsIGJ1dCAo SSBiZWxpZXZlKSBub3QgdG9vIHZhZ3VlLiDCoFllcywNCnlvdSBjYW4gbWFrZSB0aGUgbGVhcCBm cm9tIHRoaXMgdG8gY29uY2x1ZGUgdGhhdCB0aGUgVGFyZ2V0IGFuZCB0aGUgcmVxdWVzdA0Kb3Jp Z2luYXRvciBhcmUgb25lIGFuZCB0aGUgc2FtZS7CoCBBIHNob3J0ZXIganVtcCB3b3VsZCBiZSB0 byBzYXkgdGhhdCB0aGVzZQ0KZW50aXRpZXMgYXJlIGF0IHRoZSBzYW1lIGxvY2F0aW9uLiDCoFRo ZXNlIHN0cm9uZ2VyIHNlbWFudGljcyBhcmUgdW5uZWNlc3NhcnnigKYNCm9yIGF0IGxlYXN0IGhh cmQgdG8gcHJvdmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCmNvbG9yOiMyNDQwNjEnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYxJz4tLTxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6 MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYx Jz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3Bh biBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2Vy aWYiOw0KY29sb3I6IzI0NDA2MSc+VGhlIHJlYXNvbiB0aGF0IEkgcHJvcG9zZWQgQ29udGVudC1M b2NhdGlvbiBpcyBiZWNhdXNlIGl0IGRvZXMNCmF3YXkgd2l0aCB0aGUgaWRlYSB0aGF0IHRoZXJl IGFyZSBtdWx0aXBsZSBzb3VyY2VzLsKgIEluc3RlYWQsIGl0IGlkZW50aWZpZXMgYQ0Kc2luZ2xl IGF1dGhvcml0eSBhbmQgcmVzb3VyY2UuwqAgVGhhdCBhdXRob3JpdHkgbWlnaHQgY29tcG9zZSBt dWx0aXBsZSBzb3VyY2VzLA0KYnV0IHRoYXQgYmVjb21lcyBvcGFxdWUuwqAgSWYgSSB0aGluayBv ZiBhIHNpbmdsZSBIVFRQIHJlc291cmNlLCB0aGUgaWRlYSB0aGF0DQp0aGUgcmVzb3VyY2UgbWln aHQgaGF2ZSBkaWZmZXJlbnQgcmVwcmVzZW50YXRpb25zIGRvZXNu4oCZdCBjYXVzZSAobXVjaCkg Y29uc3Rlcm5hdGlvbi4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYxJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+VGhlIGJpZ2dl ciBwcm9ibGVtIGFyaXNlcyB3aGVuIHlvdSBhbGxvdyBmcmVlIHJlaWduIHRvIGRpZmZlcmVudA0K YXV0aG9yaXRpZXMgd2hpY2ggZWFjaCBoYXZlIHRoZWlyIGRpZmZlcmVudCB2aWV3cy7CoCBBbGxv dyB0aGUgaW5jbHVzaW9uIG9mIHN0YXRpYw0KYW5kIGR5bmFtaWMsIGJ1dCBtYWtlIGl0IGNsZWFy IHRoYXQgYm90aCBzdGF0aWMgYW5kIGR5bmFtaWMgaGF2ZSB0byBiZSB0aGUgc2FtZQ0KdGhpbmcv cmVzb3VyY2UuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNl cmlmIjsNCmNvbG9yOiMyNDQwNjEnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYxJz5PbmNlIGEgc2luZ2xlIGF1 dGhvcml0eSBpcyBpc29sYXRlZCwgdGhlbiBhbGwgeW91IGhhdmUgdG8gd29ycnkNCmFib3V0IGlz IHRoZSBjb250ZW50cyBvZiB0aGUgUElERi7CoCBXZSBoYXZlIHRoZSBtZWFucyB0byBkZWFsIHdp dGggdGhhdCB3aXRoIDQ0NzkNCihpbiBnZW5lcmFsKSBhbmQgNTQ5MSAoZm9yIGxvY2F0aW9uIHNw ZWNpZmljYWxseSkuPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5z LXNlcmlmIjsNCmNvbG9yOiMyNDQwNjEnPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt aWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYxJz5BbmQgdGhlIFVBQyBt YWtlcyB0aGUgZGVjaXNpb24gYWJvdXQgd2hpY2ggYXV0aG9yaXR5IHRvIG5vbWluYXRlLjxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250 LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjoj MjQ0MDYxJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNh bnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+LS1NYXJ0aW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250 LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+PG86cD4mbmJz cDs8L286cD48L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2Zv bnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9y OiMyNDQwNjEnPnAucy4gTm90ZSB0aGF0IHRoZSBkZWZpbml0aW9uIHdvcmRpbmcgYWJvdmUgd291 bGQgcHJlY2x1ZGUgdGhlDQp1c2Ugb2YgYSBnZW86IFVSSS4gwqBJ4oCZbSBvcGVuIHRvIG1ha2lu ZyB0aGUgc3RhdGVtZW50IGZ1enppZXIsIGlmIHRoZXJlIGlzDQpjb25zZW5zdXMgdGhhdCBvdGhl ciBsb2NhdGlvbiBmb3JtYXRzIGFyZSBhY2NlcHRhYmxlIG9yIGRlc2lyYWJsZS48bzpwPjwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXpl OjExLjBwdDtmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2 MSc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MG1tIDBtbSAwbW0gNC4wcHQn Pg0KDQo8ZGl2Pg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNC NUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwbW0gMG1tIDBtbSc+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48Yj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFt aWx5Og0KIlRhaG9tYSIsInNhbnMtc2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1F Ti1VUyBzdHlsZT0nZm9udC1zaXplOjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5z LXNlcmlmIic+IFBldGVyc29uLCBKb24NClttYWlsdG86am9uLnBldGVyc29uQG5ldXN0YXIuYml6 XSA8YnI+DQo8Yj5TZW50OjwvYj4gVHVlc2RheSwgMjAgSnVseSAyMDEwIDc6MjkgQU08YnI+DQo8 Yj5Ubzo8L2I+IFRob21zb24sIE1hcnRpbjsgUm9nZXIgTWFyc2hhbGw7IEphbWVzIE0uIFBvbGs7 IHNpcGNvcmVAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IGNvbXBvc2l0aW9uIG9y IGp1c3QgaW5kaXJlY3Rpb24gKHdhczoNCmxvY2F0aW9uLWNvbnZleWFuY2UtMDMganVzdCBzdWJt aXR0ZWQpPG86cD48L286cD48L3NwYW4+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs IHN0eWxlPSdtYXJnaW4tYm90dG9tOjEyLjBwdCc+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZToxMS4w cHQ7DQpmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiJz48YnI+DQpJ4oCZbSBzdXJl IHdl4oCZcmUgYWxsIGdvaW5nIHRvIGhhdmUgdG8gZGlzY3VzcyB0aGlzIGEgYml0IGluIE1hYXN0 cmljaHQsIGJ1dCB0aGVyZQ0KYXJlIGEgY291cGxlIGJhc2ljIHBvaW50cyBoZXJlIEkgdGhpbmsg d2UgbmVlZCB0byB0ZWUgdXAuIEkgY2VydGFpbmx5IGRpZG7igJl0DQptZWFuIHRvIHN1Z2dlc3Qg dGhhdCBhIHJlcXVlc3QgY2FuIG9ubHkgaW5jbHVkZSBhIHNpbmdsZSBsb2NhdGlvbiAoaS5lLiwg dGhhdA0KYW55IGNvbnRyaWJ1dGluZyBwaWVjZSBvZiBsb2NhdGlvbiBpbmZvcm1hdGlvbiBkZXNp Z25hdGVzIHRoZSBzYW1lIHBsYWNlLCBqdXN0DQp3aXRoIHZhcnlpbmcgZGVncmVlcyBvZiBhY2N1 cmFjeSBvciB0aW1lbGluZXNzIG9yIHNvbWV0aGluZykuIFJhdGhlciwgSSBiZWxpZXZlDQphIHBy ZXNlbmNlIGRvY3VtZW50IGRlc2NyaWJlcyBhIHNpbmdsZSBlbnRpdHkg4oCTIG11bHRpcGxlIGxv Y2F0aW9ucyBjb21lIGFib3V0DQpiZWNhdXNlIHZhcmlvdXMgZGV2aWNlcyBhbmQgc2VydmljZXMg YXNzb2NpYXRlZCB3aXRoIHRoYXQgc2luZ2xlIGVudGl0eSBtYXkNCmF0dHJpYnV0ZSB2YXJpb3Vz IGxvY2F0aW9ucyB0byB0aGUgZW50aXR5Ljxicj4NCjxicj4NCkdldHRpbmcgYmFjayB0byBmdW5k YW1lbnRhbHMsIHdlIGRvbuKAmXQgbmVlZCBhIEdlb2xvY2F0aW9uIGhlYWRlciBpbiBvcmRlciB0 bw0KY2FycnkgbG9jYXRpb24gaW4gU0lQLiBUaGVyZSBhcmUgTUlNRSBib2RpZXMgZm9yIHRoYXQg KGluY2x1ZGluZw0KQ29udGVudC1JbmRpcmVjdGlvbiBib2RpZXMgZm9yIExieVIsIG9yIHBlcmhh cHMgQ29udGVudC1Mb2NhdGlvbiBhcyB5b3UNCnN1Z2dlc3QpLCBhbmQgd2UgY2FuIGluY2x1ZGUg c2V2ZW50ZWVuIGRpZmZlcmVudCBsb2NhdGlvbiBvYmplY3RzIGlmIHdlIHdhbnQNCnRvLCByZWdh cmRsZXNzIG9mIHdoZXRoZXIgdGhlcmUgYXJlIHplcm8gb3Igb25lIG9yIGZpZnRlZW4gR2VvbG9j YXRpb24gaGVhZGVycy4NCldlIGRvbuKAmXQgbmVlZCBhIGxvY2F0aW9uIGNvbnZleWFuY2Ugc3Bl Y2lmaWNhdGlvbiBvciBhIEdlb2xvY2F0aW9uIGhlYWRlciB0bw0KZW5hYmxlIHRoYXQsIFNJUCBo YXMgYWx3YXlzIGJlZW4gYWJsZSB0byBkbyBpdCwgYW5kIHlvdeKAmWxsIHN0aWxsIGJlIGFibGUg dG8gYWRkDQpyYW5kb20gTUlNRSBib2RpZXMgdGhhdCBjb250YWluIGxvY2F0aW9uIGluZm9ybWF0 aW9uIGV2ZW4gaWYgdGhlcmUgaXMgYQ0KR2VvbG9jYXRpb24gaGVhZGVyIHdoaWNoIGRvZXMgbm90 IHBvaW50IHRvIHRoZW0uIFNvIHdoYXQgZG9lcyB0aGUgR2VvbG9jYXRpb24NCmhlYWRlciBhbmQg bG9jYXRpb24gY29udmV5YW5jZSBzcGVjaWZpY2F0aW9uIGJ1eSB1cz8gPGJyPg0KPGJyPg0KSeKA mXZlIGFsd2F5cyBuYWl2ZWx5IHRob3VnaHQgdGhhdCB0aGUgR2VvbG9jYXRpb24gaGVhZGVyIHBy b3ZpZGVzIGEgY291cGxpbmcNCmJldHdlZW4gdGhpcyBwYXJ0aWN1bGFyIFNJUCBzZXNzaW9uIGFu ZCBhbiBlbnRpdHkgd2hvc2UgbG9jYXRpb24gaXMgZGVzaWduYXRlZA0KYnkgYSBQSURGIGRvY3Vt ZW50LiBUaGUgZW50aXR5IGlzIHRoZSBnZW9wcml2IFRhcmdldCwgYW5kIGlzIHByb2JhYmx5ICh0 aG91Z2gNCm5vdCBuZWNlc3NhcmlseSkgcmVsYXRlZCB0byB0aGUgcGFydHkgaWRlbnRpZmllZCBi eSB0aGUgY2xhc3NpYyBGcm9tIGhlYWRlcg0KZmllbGQgb2YgdGhlIFNJUCByZXF1ZXN0LiBUaGUg R2VvbG9jYXRpb24gaGVhZGVyIHRlbGxzIHVzIHRoYXQgZm9yIHRoZSBwdXJwb3Nlcw0Kb2YgdGhl IFNJUCBzZXNzaW9uIGJlaW5nIG5lZ290aWF0ZWQsIHRoZSBsb2NhdGlvbiBvZiB0aGlzIFRhcmdl dCBpcyBzb21laG93DQpyZWxldmFudC4uLiB0aGUgYm9sZGVzdCBpbnRlcnByZXRhdGlvbiB3b3Vs ZCBiZSB0aGF0IHRoaXMgVGFyZ2V04oCZcyBsb2NhdGlvbg0Kc2hvdWxkIGJlIGNvbnNpZGVyZWQg dGhlIHNvdXJjZSBvZiB0aGUgcmVxdWVzdC4gSnVzdCBhdHRhY2hpbmcgbG9jYXRpb24tYXdhcmUN Ck1JTUUgYm9kaWVzIHdpdGhvdXQgdGhlIEdlb2xvY2F0aW9uIGhlYWRlciB0byBTSVAgcmVxdWVz dHMgZG9lc27igJl0IGNvbnZleSB0aGUNCnNhbWUgc2VtYW50aWNzIOKAkyB0aG9zZSBib2RpZXMg Y291bGQgbWVhbiBhbnl0aGluZywgYW5kIHByZXN1bWFibHkgdGhlIHJlY2VpdmluZw0KYXBwbGlj YXRpb24gd291bGQgc29ydCB0aHJvdWdoIHRoZW0gYXQgaXRzIGRpc2NyZXRpb24uPGJyPg0KPGJy Pg0KV2hlcmUgSSBnZXQgY29uZnVzZWQgaXMgd2hlbiBJIHN0YXJ0IHRyeWluZyB0byB1bmRlcnN0 YW5kIHdoYXQgaXQgd291bGQgbWVhbg0Kc2VtYW50aWNhbGx5IGZvciBhIFNJUCBzZXNzaW9uIHRv IGJlIGNvdXBsZWQgd2l0aCBtb3JlIHRoYW4gb25lIFRhcmdldC4gQWdhaW4sDQpJIGNhbiBpbWFn aW5lIGh5cG90aGV0aWNhbGx5IGEgU0lQIHJlcXVlc3QgY29udGFpbmluZyB1bnNvcnRlZCBNSU1F IGJvZGllcyB0aGF0DQp0YWxrIGFib3V0IGRpZmZlcmVudCBUYXJnZXRzIHRvIGFzc2lzdCBzb21l IHNwZWNpZmljIGFwcGxpY2F0aW9uIHRoYXQga25vd3MgaG93DQp0byByZWNvbmNpbGUgdGhlbSwg YnV0IGhlcmUgSSBtZWFuIHVzaW5nIHRoZSBHZW9sb2NhdGlvbiBoZWFkZXIgdG8gY291cGxlIGEg U0lQDQpyZXF1ZXN0IHdpdGggbG9jYXRpb24gaW5mb3JtYXRpb24gYWJvdXQgZGlmZmVyZW50IFRh cmdldHMuIElzIHRoZXJlIGFjdHVhbGx5IGENCnVzZSBjYXNlL3JlcXVpcmVtZW50IGZvciB0aGF0 PyBJZiBub3QsIGFuZCB3ZSBvbmx5IHdhbnQgdG8gY291cGxlIGEgU0lQIHJlcXVlc3QNCndpdGgg b25lIFRhcmdldCwgdGhlbiBJIGZhaWwgdG8gc2VlIHdoeSBjb21wb3NpbmcgbG9jYXRpb24gaW5m b3JtYXRpb24gYWJvdXQNCnRoZSBzYW1lIFRhcmdldCBpbnRvIGEgc2luZ2xlIFBJREYgYm9keSB3 b3VsZCBiZSBhIHByb2JsZW0uIEhhdmluZyBsb2NhdGlvbg0KaW5mb3JtYXRpb24gYWJvdXQgdGhl IHNhbWUgZW50aXR5IGZhaWwgdG8gYmUgb3JnYW5pemVkIGluIG9uZSBib2R5IHRocm91Z2gNClJG QzQ0Nzkgd291bGRu4oCZdCBtYWtlIHNlbnNlLCBhbnl3YXkuPGJyPg0KPGJyPg0KSSB0aGluayBp ZiB3ZSB1bmRlcnN0YW5kIHRoZSBzZW1hbnRpY3MgYnkgd2hpY2ggdGhlIEdlb2xvY2F0aW9uIGhl YWRlcg0K4oCcY291cGxlc+KAnSBQSURGIHdpdGggYSBTSVAgc2Vzc2lvbiwgdGhlbiB3ZeKAmWxs IGJldHRlciB1bmRlcnN0YW5kIGFsbCBvZiB0aGlzLiBJZg0KdGhlIEdlb2xvY2F0aW9uIGhlYWRl ciBvbmx5IGV4aXN0cyB0byBub3RpZnkgbGF6eSBpbnRlcm1lZGlhcmllcyB0aGF0IHRoZXJlIGFy ZQ0KbG9jYXRpb24tc2Vuc2l0aXZlIGJvZGllcyBpbiB0aGUgcmVxdWVzdCBvciBzb21ld2hlcmUg b3V0IG9uIHRoZSBuZXQsIHdpdGhvdXQNCmltcGx5aW5nIGFueXRoaW5nIGFib3V0IHRoZSBUYXJn ZXQgb3IgdGhlIHJlbGF0aW9uc2hpcCBvZiB0aG9zZSBsb2NhdGlvbnMgdG8NCnRoZSBTSVAgcmVx dWVzdCwgdGhlbiB0aGlzIHdob2xlIHNwZWNpZmljYXRpb24gaXMgcHJvYmFibHkgbW9yZSB0cm91 YmxlIHRoYW4NCml04oCZcyB3b3J0aCDigJMgaXQgcmVhbGx5IHdvdWxkbuKAmXQgcHJvdmlkZSBt dWNoIGluY3JlbWVudGFsIHZhbHVlIGFib3ZlIHRoZSBiYXNpYw0KYWJpbGl0eSBvZiBTSVAgdG8g Y2FycnkgYWxsIHNvcnRzIG9mIGJvZGllcywgaW5jbHVkaW5nIGxvY2F0aW9uIGJvZGllcy4gSWYN CnRoZXJlIGFyZSwgaG93ZXZlciwgbW9yZSBiaW5kaW5nIHNlbWFudGljcyBoZXJlLCB0aGVuIHdl IHByb2JhYmx5IHdvbuKAmXQgYmUgYWJsZQ0KdG8gYWdyZWUgb24gdGhlIG5lZWQgZm9yIHNvbGl0 YXJ5IG9yIG11bHRpcGxlIEdlb2xvY2F0aW9uIGhlYWRlcnMgdW50aWwgd2UNCmFncmVlIG9uIHdo YXQgdGhvc2Ugc2VtYW50aWNzIGFyZS48YnI+DQo8YnI+DQpKb24gUGV0ZXJzb248YnI+DQpOZXVT dGFyLCBJbmMuPGJyPg0KPGJyPg0KPGJyPg0KT24gNy8xOC8xMCA3OjI1IFBNLCAmcXVvdDtUaG9t c29uLCBNYXJ0aW4mcXVvdDsgJmx0OzxhDQpocmVmPSJNYXJ0aW4uVGhvbXNvbkBhbmRyZXcuY29t Ij5NYXJ0aW4uVGhvbXNvbkBhbmRyZXcuY29tPC9hPiZndDsgd3JvdGU6PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWwgc3R5bGU9J21hcmdpbi1ib3R0b206MTIuMHB0 Jz48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDsNCmZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiInPkhpIEpvbiw8YnI+DQo8YnI+DQpJIGFkbWl0IGEgZmFpciBkZWdyZWUgb2Yg c3ltcGF0aHkgZm9yIFJvZ2Vy4oCZcyBzdWdnZXN0aW9uLiAmbmJzcDtBZnRlciBhbGwsIHRoZQ0K YWJpbGl0eSB0byBpbmNsdWRlIG11bHRpcGxlIGxvY2F0aW9uIOKAnHZhbHVlc+KAnSBpbiB0aGUg c2FtZSBTSVAgcmVxdWVzdCBpcyBhDQpmZWF0dXJlIHRoYXQgaGFzIGV4aXN0ZWQgZm9yIG1hbnkg eWVhcnMuICZuYnNwO0EgbnVtYmVyIG9mIGltcGxlbWVudGF0aW9ucyBoYXZlDQpjb21lIHRvIHJl bHkgb24gdGhpcyBtZWNoYW5pc207IHBlb3BsZSBhcmUgYnVpbGRpbmcgYW5kIGhhdmUgYnVpbHQg c29sdXRpb25zDQpiYXNlZCBvbiBlYXJsaWVyIGRyYWZ0LCBmdWxseSBhd2FyZSBvZiB0aGUgcmlz a3MgaW4gaW1wbGVtZW50aW5nIGFuIGludGVybmV0DQpkcmFmdC48YnI+DQo8YnI+DQpBdCBzb21l IHBvaW50LCBpdCBtaWdodCBiZSBuZWNlc3NhcnkgdG8gc3dhbGxvdyBhbnkgZGlzY29tZm9ydCBh bmQgcmVjb2duaXplDQp0aGF0IHRoZSBjb25zZXF1ZW5jZXMgb2YgYW4gaW1wZXJmZWN0IHNvbHV0 aW9uIGFyZSBsZXNzIHRoYW4gdGhlIGNvbnNlcXVlbmNlcw0Kb2YgYSBjaGFuZ2Ugb2YgdGhlIG5h dHVyZSB5b3Ugc3VnZ2VzdC48YnI+DQo8YnI+DQpBbHRlcmluZyBwZXJzcGVjdGl2ZSBtaWdodCBv ZmZlciBhIHNvbHV0aW9uLjxicj4NCjxicj4NClRoZSBpZGVhIHRoYXQgdGhlcmUgYXJlIG11bHRp cGxlIGl0ZW1zIHRoYXQgYXJlIGNvbXBvc2l0ZWQgbWlnaHQgYmUNCmNvdW50ZXJwcm9kdWN0aXZl LiAmbmJzcDtJbiB0aGlzIHdvcmxkLXZpZXcsIHlvdSBoYXZlIHRvIHJlY29uY2lsZSBhIG51bWJl ciBvZg0KcGVyc3BlY3RpdmVzLiAmbmJzcDtJbiB0aGlzLCB5b3UgYXJlIGFic29sdXRlbHkgY29y cmVjdDogZG9pbmcgdGhhdCBhdCB0d28NCmxheWVycyBpcyBiYWQuICZuYnNwO0NvbXBvc2l0aW9u IGlzIGEgaGFyZCBwcm9ibGVtIGFscmVhZHkuICZuYnNwO01vdmluZyBpdA0KaW50byBTSVAgb25s eSBjb21wbGljYXRlcyBpdCBmdXJ0aGVyLjxicj4NCjxicj4NClRoZSBhbHRlcm5hdGl2ZSBpcyB0 byBpbWFnaW5lIGEgc2luZ2xlIGxvZ2ljYWwgcmVzb3VyY2UgdGhhdCByZXByZXNlbnRzIHRoZQ0K bG9jYXRpb24gb2YgdGhlIFRhcmdldC4gJm5ic3A7QSBsb2NhdGlvbiBieSB2YWx1ZSBpcyBhIHJl cHJlc2VudGF0aW9uIG9mIHRoaXMNCnJlc291cmNlOiBhIHNuYXBzaG90LiAmbmJzcDtMb2NhdGlv biBieSByZWZlcmVuY2Ugb2ZmZXJzIGEgbWVhbnMgZm9yIGFueSBlbnRpdHkNCnRvIGlkZW50aWZ5 IGFuZCBhY3F1aXJlIGEgdmlldyBvZiB0aGUgcmVzb3VyY2UsIGluZGVwZW5kZW50IG9mIHRoYXQg c25hcHNob3QuDQombmJzcDtUaGUgYXV0aG9yaXR5IGZvciB0aGUgcmVzb3VyY2UgbWlnaHQgb2Zm ZXIgdGhlIHNhbWUgcmVwcmVzZW50YXRpb24sIG9yIGl0DQpjb3VsZCBvZmZlciBvbmUgYmV0dGVy IHN1aXRlZCB0byB0aGUgcmVjaXBpZW50LiAmbmJzcDtUaGUgcmVwcmVzZW50YXRpb24gbWlnaHQN CmJlIHVwZGF0ZWQsIGl0IG1pZ2h0IGJlIGFsdGVyZWQgYmFzZWQgb24gYW4gYXV0aG9yaXphdGlv biBwb2xpY3ksIG9yIHNvbWV0aGluZw0KZWxzZSAobGFuZ3VhZ2UgcHJlZmVyZW5jZXMpLiAmbmJz cDtSZWdhcmRsZXNzIG9mIGhvdyBpdCBpcyByZXByZXNlbnRlZCwgaXQgaXMNCnN0aWxsIHRoZSBz YW1lIHJlc291cmNlLjxicj4NCjxicj4NCkluIHNpbXBsZSB0ZXJtcywgeW91IHN0YXRlIHRoYXQg dGhlIHJlcXVlc3QgY2FuIG9ubHkgaW5jbHVkZSBhIHNpbmdsZQ0KX2xvY2F0aW9uXy4gJm5ic3A7 V2hlbiBhIGxvY2F0aW9uIHZhbHVlIGFuZCByZWZlcmVuY2UgYXJlIGJvdGggaW5jbHVkZWQsIHRo ZXkNCnJlcHJlc2VudCB0aGUgX3NhbWVfIGxvY2F0aW9uLjxicj4NCjxicj4NClRoaXMgaXMgd2h5 IEkgc3VnZ2VzdGVkIHRoYXQgQ29udGVudC1Mb2NhdGlvbiBiZSBib3Jyb3dlZC4gJm5ic3A7SW4g SFRUUCwNCkNvbnRlbnQtTG9jYXRpb24gc2F5cyAtIGlmIHlvdSB3YW50IHRvIGtub3cgd2hlcmUg dGhpcyByZXNvdXJjZSByZWFsbHkgbGl2ZXMsDQpoZXJlIGlzIHdoZXJlIHlvdSBjYW4gZmluZCBp dC48YnI+DQo8YnI+DQpOb3cgdGhpcyBtaWdodCBiZSBzaGVlciBzb3BoaXN0cnksIGJ1dCBpdCBt aWdodCBvZmZlciBhIHdheSBvdXQuICZuYnNwO1RoZQ0KY29tcG9zaXRpb24gcHJvYmxlbXMgYXJl IGxlZnQgb3V0IG9mIFNJUC48YnI+DQo8YnI+DQo8c3BhbiBzdHlsZT0nY29sb3I6IzI0NDA2MSc+ 4oCmPC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8 L2JvZHk+DQoNCjwvaHRtbD4NCg== --_000_8B0A9FCBB9832F43971E38010638454F03EB7730BASISPE7MB1comm_-- From Hannes.Tschofenig@gmx.net Wed Jul 21 00:09:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7D6DE3A69CF for ; Wed, 21 Jul 2010 00:09:52 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat X-Spam-Flag: NO X-Spam-Score: -6.452 X-Spam-Level: X-Spam-Status: No, score=-6.452 tagged_above=-999 required=5 tests=[AWL=4.147, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xYnjXTfKQ25z for ; Wed, 21 Jul 2010 00:09:51 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1279696192-7306-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 9D7653A6922 for ; Wed, 21 Jul 2010 00:09:51 -0700 (PDT) Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 21 Jul 2010 07:10:07 +0000 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 o6L7A7Cg005152 for ; Wed, 21 Jul 2010 07:10:07 GMT Received: from mail pickup service by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 15:14:08 -0700 Received: from xbh-rcd-102.cisco.com ([72.163.62.139]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 04:04:00 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 05:37:57 -0500 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 10:37:53 +0000 Received: from sj-inbound-f.cisco.com (sj-inbound-f.cisco.com [128.107.234.207]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6KAbroT009279 for ; Tue, 20 Jul 2010 10:37:53 GMT Received: from mail.gmx.net ([213.165.64.20]) by sj-inbound-f.cisco.com with SMTP; 20 Jul 2010 10:37:52 +0000 Received: (qmail 9563 invoked by uid 0); 20 Jul 2010 10:37:51 -0000 Received: from 213.162.68.136 by www160.gmx.net with HTTP; Tue, 20 Jul 2010 12:37:50 +0200 (CEST) X-Mailer: WWW-Mail 6100 (Global Message Exchange) Date: Tue, 20 Jul 2010 05:37:50 -0500 Message-ID: <20100720103750.197770@gmx.net> In-Reply-To: <201007191843.o6JIhpLv029037@sj-core-5.cisco.com> References: <20100719081713.77060@gmx.net> <201007191843.o6JIhpLv029037@sj-core-5.cisco.com> From: "Hannes Tschofenig" To: "James Polk (jmpolk)" , Subject: Re: [sipcore] Location Conveyance Flaw: HTTP/HTTPS Location URI Scheme X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 21 Jul 2010 07:09:52 -0000 This is a multi-part message in MIME format... ------------=_1279696192-7306-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1279696192-7306-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Received: from sj-iport-1.cisco.com (sj-iport-1.cisco.com [171.71.176.70]) by core3.amsl.com (Postfix) with ESMTP id 9D7653A6922 for ; Wed, 21 Jul 2010 00:09:51 -0700 (PDT) Authentication-Results: sj-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: winmail.dat : 4194 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 21 Jul 2010 07:10:07 +0000 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 o6L7A7Cg005152 for ; Wed, 21 Jul 2010 07:10:07 GMT Received: from mail pickup service by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 15:14:08 -0700 Received: from xbh-rcd-102.cisco.com ([72.163.62.139]) by xbh-sjc-211.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 04:04:00 -0700 Received: from sj-iport-5.cisco.com ([171.68.10.87]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 05:37:57 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB27F7.9DEAB080" X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 20 Jul 2010 10:37:53 +0000 Received: from sj-inbound-f.cisco.com (sj-inbound-f.cisco.com [128.107.234.207]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6KAbroT009279 for ; Tue, 20 Jul 2010 10:37:53 GMT Received: from mail.gmx.net ([213.165.64.20]) by sj-inbound-f.cisco.com with SMTP; 20 Jul 2010 10:37:52 +0000 Received: (qmail 9563 invoked by uid 0); 20 Jul 2010 10:37:51 -0000 Received: from 213.162.68.136 by www160.gmx.net with HTTP; Tue, 20 Jul 2010 12:37:50 +0200 (CEST) X-Mailer: WWW-Mail 6100 (Global Message Exchange) X-OriginalArrivalTime: 20 Jul 2010 10:37:57.0328 (UTC) FILETIME=[9E1CBD00:01CB27F7] X-IronPort-AV: E=Sophos;i="4.55,231,1278288000"; d="scan'208";a="205324629" X-from-outside-Cisco: 213.165.64.20 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsBACsZRUzVpUAUi2dsb2JhbACDH5EIi10BAQEKCwoHDwUfpQOJNJF2gSaDGXME X-Provags-ID: V01U2FsdGVkX18X7YNP9bQXZfQg7NxM5ymnOoXiaSzQgWYGeqMwhA u6vHypPov1JML9BaKvA9y7por1p4v5QA+CQg== X-Authenticated: #29516787 X-Flags: 0001 X-GMX-UID: GhUgDS85fW47Yck5tWRo/yRudmllcsXq X-FuHaFi: 0.69999999999999996 Content-class: urn:content-classes:message Subject: Re: [sipcore] Location Conveyance Flaw: HTTP/HTTPS Location URI Scheme Date: Tue, 20 Jul 2010 05:37:50 -0500 Message-ID: <20100720103750.197770@gmx.net> In-Reply-To: <201007191843.o6JIhpLv029037@sj-core-5.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: <20100720103750.197770@gmx.net> Thread-Topic: [sipcore] Location Conveyance Flaw: HTTP/HTTPS Location URI Scheme Thread-Index: Acsn954opatxCzw6ToKHkNt/LPT0Uw== References: <20100719081713.77060@gmx.net> <201007191843.o6JIhpLv029037@sj-core-5.cisco.com> From: "Hannes Tschofenig" To: "James Polk (jmpolk)" , This is a multi-part message in MIME format. ------_=_NextPart_001_01CB27F7.9DEAB080 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 DQo+IEF0IDAzOjE3IEFNIDcvMTkvMjAxMCwgSGFubmVzIFRzY2hvZmVuaWcgd3JvdGU6DQo+ID5I aSwNCj4gPg0KPiA+VGhlIGF1dGhvcnMgKG9yIG9uZSBvZiB0aGVtIGluIHBhcnRpY3VsYXIpDQo+ IA0KPiBvbiB0aGUgSUFCIGFuZCB5b3UgY2FuJ3Qgc3RvcCBhdHRhY2tpbmcgcHVibGljbHk/DQo+ IA0KPiBobW1tbS4uLg0KPiANCg0KVGhpcyBoYXMgbm90aGluZyB0byBkbyB3aXRoIHRoZSBJQUIu IEkgYW0gYWxzbyBzdGlsbCBhIHJlZ3VsYXIgSUVURiBwYXJ0aWNpcGFudCB3aG8gbWF5IGZlZWwg dW5oYXBweS4gDQoNCg== ------_=_NextPart_001_01CB27F7.9DEAB080 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IjwLAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAENgAQAAgAAAAIAAgABBYAD AA4AAADaBwcAFAAFACUAMgACAFoBASCAAwAOAAAA2gcHABQABQAmAB8AAgBIAQEJgAEAIQAAAEJC MjAzNUFDMjcyMkNGNEQ5MUMxNTczRDI1RTFERkRCAE4HAQOQBgDEDwAANQAAAB8AGgABAAAAEgAA AEkAUABNAC4ATgBvAHQAZQAAAAAAAwA2AAAAAAAfADcAAQAAAJAAAABSAGUAOgAgAFsAcwBpAHAA YwBvAHIAZQBdACAATABvAGMAYQB0AGkAbwBuACAAQwBvAG4AdgBlAHkAYQBuAGMAZQAgAEYAbABh AHcAOgAgAEgAVABUAFAALwBIAFQAVABQAFMAIABMAG8AYwBhAHQAaQBvAG4AIAAgAFUAUgBJACAA UwBjAGgAZQBtAGUAAABAADkAAJO+mfcnywEfAD0AAQAAAAoAAABSAGUAOgAgAAAAAAAfAHAAAQAA AIgAAABbAHMAaQBwAGMAbwByAGUAXQAgAEwAbwBjAGEAdABpAG8AbgAgAEMAbwBuAHYAZQB5AGEA bgBjAGUAIABGAGwAYQB3ADoAIABIAFQAVABQAC8ASABUAFQAUABTACAATABvAGMAYQB0AGkAbwBu ACAAIABVAFIASQAgAFMAYwBoAGUAbQBlAAAAAgFxAAEAAAAWAAAAAcsn954opatxCzw6ToKHkNt/ LPT0UwAAHwAaDAEAAAAkAAAASABhAG4AbgBlAHMAIABUAHMAYwBoAG8AZgBlAG4AaQBnAAAAHwAd DgEAAACIAAAAWwBzAGkAcABjAG8AcgBlAF0AIABMAG8AYwBhAHQAaQBvAG4AIABDAG8AbgB2AGUA eQBhAG4AYwBlACAARgBsAGEAdwA6ACAASABUAFQAUAAvAEgAVABUAFAAUwAgAEwAbwBjAGEAdABp AG8AbgAgACAAVQBSAEkAIABTAGMAaABlAG0AZQAAAAIBCRABAAAAlgEAAJIBAABfAgAATFpGdWl5 UYYDAAoAcmNwZzEyNeIyA0N0ZXgFQQEDAff/CoACpAPkBxMCgA/zAFAEVj8IVQeyESUOUQMBAgBj aOEKwHNldDIGAAbDESX2MwRGE7cwEiwRMwjvCfe2OxgfDjA1ESIMYGMAUPMLCQFkMzYWUAumCuMK gAY+EMAFQDAzOjE3ARDATSA3LzE5L0EB0DEwLCBIAHBuRQeRVATwaG9mCfBpWGcgdwNgDrA6HPY+ GEhpLCBnIGdUaGUwIGF1dB+AFAAgKC8FsQIgImAfkCAioGVtqiALgCAKsXQN4HULYDxyKRz2HPYC ICOiIEmEQUIicG5kIHkIYBQgYwBwJwVAc3RvbnAicAJAANBrC4Af4HBGdQJgDeBseT8k7mj6bSoB LipAJOwc9CJABAD1KeBhBCBuICArwCgxJ4C8IGQs0APwIqAmBi4mQPcicCPgB0BzLNAncAMQAyA0 YSAYIGckkiZARVReRiQlBSAAcAVAdx+AICkAwHkgH6BlAyB1brET4HBweS3gKvp9MuAAAB8ANRAB AAAAQAAAADwAMgAwADEAMAAwADcAMgAwADEAMAAzADcANQAwAC4AMQA5ADcANwA3ADAAQABnAG0A eAAuAG4AZQB0AD4AAAAfADkQAQAAAKIAAAA8ADIAMAAxADAAMAA3ADEAOQAwADgAMQA3ADEAMwAu ADcANwAwADYAMABAAGcAbQB4AC4AbgBlAHQAPgAgADwAMgAwADEAMAAwADcAMQA5ADEAOAA0ADMA LgBvADYASgBJAGgAcABMAHYAMAAyADkAMAAzADcAQABzAGoALQBjAG8AcgBlAC0ANQAuAGMAaQBz AGMAbwAuAGMAbwBtAD4AAAAAAB8AQhABAAAAZAAAADwAMgAwADEAMAAwADcAMQA5ADEAOAA0ADMA LgBvADYASgBJAGgAcABMAHYAMAAyADkAMAAzADcAQABzAGoALQBjAG8AcgBlAC0ANQAuAGMAaQBz AGMAbwAuAGMAbwBtAD4AAAALAPIQAAAAAB8A8xABAAAAoAAAAFIAZQAlADMAQQAgAFsAcwBpAHAA YwBvAHIAZQBdACAATABvAGMAYQB0AGkAbwBuACAAQwBvAG4AdgBlAHkAYQBuAGMAZQAgAEYAbABh AHcAJQAzAEEAIABIAFQAVABQAP/4SABUAFQAUABTACAATABvAGMAYQB0AGkAbwBuACAAIABVAFIA SQAgAFMAYwBoAGUAbQBlAC4ARQBNAEwAAAALAPQQAAAAAAsA9RAAAAAACwD2EAAAAABAAAcw4qko nvcnywFAAAgwwOhUsvcnywEDAN4/6f0AAAMA8T8AAAAAHwD4PwEAAAAqAAAAUwB5AHMAdABlAG0A IABBAGQAbQBpAG4AaQBzAHQAcgBhAHQAbwByAAAAAAACAfk/AQAAAB4AAAAAAAAA3KdAyMBCEBq0 uQgAKy/hggEAAAAAAAAALgAAAB8A+j8BAAAAKgAAAFMAeQBzAHQAZQBtACAAQQBkAG0AaQBuAGkA cwB0AHIAYQB0AG8AcgAAAAAAAgH7PwEAAAAeAAAAAAAAANynQMjAQhAatLkIACsv4YIBAAAAAAAA AC4AAAADAP0/5AQAAAMAGUAAAAEAAwAaQAAAAQAfADBAAQAAADQAAABIAGEAbgBuAGUAcwAuAFQA cwBjAGgAbwBmAGUAbgBpAGcAQABnAG0AeAAuAG4AZQB0AAAAHwAxQAEAAAA0AAAASABhAG4AbgBl AHMALgBUAHMAYwBoAG8AZgBlAG4AaQBnAEAAZwBtAHgALgBuAGUAdAAAAB8AOEABAAAABAAAAC4A AAAfADlAAQAAAAQAAAAuAAAAHwB8gIYDAgAAAAAAwAAAAAAAAEYBAAAAGAAAAHIAZQB0AHUAcgBu AC0AcABhAHQAaAAAAAEAAAA4AAAAPABIAGEAbgBuAGUAcwAuAFQAcwBjAGgAbwBmAGUAbgBpAGcA QABnAG0AeAAuAG4AZQB0AD4AAAAfAG6DhgMCAAAAAADAAAAAAAAARgEAAAAsAAAAeAAtAG8AcgBp AGcAaQBuAGEAbABhAHIAcgBpAHYAYQBsAHQAaQBtAGUAAAABAAAAegAAADIAMAAgAEoAdQBsACAA MgAwADEAMAAgADEAMAA6ADMANwA6ADUANwAuADAAMwAyADgAIAAoAFUAVABDACkAIABGAEkATABF AFQASQBNAEUAPQBbADkARQAxAEMAQgBEADAAMAA6ADAAMQBDAEIAMgA3AEYANwBdAAAAAAAfAHaD hgMCAAAAAADAAAAAAAAARgEAAAAuAAAAYQB1AHQAaABlAG4AdABpAGMAYQB0AGkAbwBuAC0AcgBl AHMAdQBsAHQAcwAAAAAAAQAAAIwAAABzAGoALQBpAHAAbwByAHQALQA1AC4AYwBpAHMAYwBvAC4A YwBvAG0AOwAgAGQAawBpAG0APQBuAGUAdQB0AHIAYQBsACAAKABtAGUAcwBzAGEAZwBlACAAbgBv AHQAIABzAGkAZwBuAGUAZAApACAAaABlAGEAZABlAHIALgBpAD0AbgBvAG4AZQAAAB8AeIOGAwIA AAAAAMAAAAAAAABGAQAAABwAAAB4AC0AaQByAG8AbgBwAG8AcgB0AC0AYQB2AAAAAQAAAIAAAABF AD0AUwBvAHAAaABvAHMAOwBpAD0AIgA0AC4ANQA1ACwAMgAzADEALAAxADIANwA4ADIAOAA4ADAA MAAwACIAOwAgACAAIAAgAGQAPQAiAHMAYwBhAG4AJwAyADAAOAAiADsAYQA9ACIAMgAwADUAMwAy ADQANgAyADkAIgAAAB8AfIOGAwIAAAAAAMAAAAAAAABGAQAAACoAAAB4AC0AZgByAG8AbQAtAG8A dQB0AHMAaQBkAGUALQBjAGkAcwBjAG8AAAAAAAEAAAAcAAAAMgAxADMALgAxADYANQAuADYANAAu ADIAMAAAAB8AfYOGAwIAAAAAAMAAAAAAAABGAQAAADwAAAB4AC0AaQByAG8AbgBwAG8AcgB0AC0A YQBuAHQAaQAtAHMAcABhAG0ALQBmAGkAbAB0AGUAcgBlAGQAAAABAAAACgAAAHQAcgB1AGUAAAAA AB8AfoOGAwIAAAAAAMAAAAAAAABGAQAAADgAAAB4AC0AaQByAG8AbgBwAG8AcgB0AC0AYQBuAHQA aQAtAHMAcABhAG0ALQByAGUAcwB1AGwAdAAAAAEAAACCAAAAQQB2AHMAQgBBAEMAcwBaAFIAVQB6 AFYAcABVAEEAVQBpADIAZABzAGIAMgBKAGgAYgBBAEMARABIADUARQBJAGkAMQAwAEIAQQBRAEUA SwBDAHcAbwBIAEQAdwBVAGYAcABRAE8ASgBOAEoARgAyAGcAUwBhAEQARwBYAE0ARQAAAAAAHwAm hIYDAgAAAAAAwAAAAAAAAEYBAAAAGgAAAHgALQBwAHIAbwB2AGEAZwBzAC0AaQBkAAAAAAABAAAA vAAAAFYAMAAxAFUAMgBGAHMAZABHAFYAawBYADEAOABYADcAWQBOAFAAOQBiAFEAWABaAGYAUQBn ADcATgB4AE0ANQB5AG0AbgBPAG8AWABpAGEAUwB6AFEAZwBXAFkARwBlAHEATQB3AGgAQQAgAHUA NgB2AEgAeQBwAFAAbwB2ADEASgBNAEwAOQBCAGEASwB2AEEAOQB5ADcAcABvAHIAMQBwADQAdgA1 AFEAQQArAEMAUQBnAD0APQAgAAAAHwCjh4YDAgAAAAAAwAAAAAAAAEYBAAAAIAAAAHgALQBhAHUA dABoAGUAbgB0AGkAYwBhAHQAZQBkAAAAAQAAABQAAAAjADIAOQA1ADEANgA3ADgANwAAAB8AfImG AwIAAAAAAMAAAAAAAABGAQAAABAAAAB4AC0AZgBsAGEAZwBzAAAAAQAAAAoAAAAwADAAMAAxAAAA AAAfAH2JhgMCAAAAAADAAAAAAAAARgEAAAAUAAAAeAAtAGcAbQB4AC0AdQBpAGQAAAABAAAAQgAA AEcAaABVAGcARABTADgANQBmAFcANAA3AFkAYwBrADUAdABXAFIAbwAvAHkAUgB1AGQAbQBsAGwA YwBzAFgAcQAAAAAAHwB+iYYDAgAAAAAAwAAAAAAAAEYBAAAAEgAAAHgALQBmAHUAaABhAGYAaQAA AAAAAQAAACgAAAAwAC4ANgA5ADkAOQA5ADkAOQA5ADkAOQA5ADkAOQA5ADkAOQA2AAAACwApAAAA AAALACMAAAAAAAMABhCSW3SWAwAHEMwAAAADABAQAQAAAAMAERABAAAAHgAIEAEAAABlAAAAQVQw MzoxN0FNNy8xOS8yMDEwLEhBTk5FU1RTQ0hPRkVOSUdXUk9URTpISSxUSEVBVVRIT1JTKE9ST05F T0ZUSEVNSU5QQVJUSUNVTEFSKU9OVEhFSUFCQU5EWU9VQ0FOVFNUTwAAAAACAX8AAQAAACAAAAA8 MjAxMDA3MjAxMDM3NTAuMTk3NzcwQGdteC5uZXQ+APSc ------_=_NextPart_001_01CB27F7.9DEAB080-- ------------=_1279696192-7306-1-- From jmpolk@cisco.com Wed Jul 21 01:55:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B09913A67FC for ; Wed, 21 Jul 2010 01:55:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.463 X-Spam-Level: X-Spam-Status: No, score=-10.463 tagged_above=-999 required=5 tests=[AWL=0.136, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NpYxO5g1qPyi for ; Wed, 21 Jul 2010 01:55:26 -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 B64A63A67BD for ; Wed, 21 Jul 2010 01:55:26 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAP5SRkyrR7Hu/2dsb2JhbACfcHGkApsUhTIEhACHDw Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-4.cisco.com with ESMTP; 21 Jul 2010 08:55:42 +0000 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 o6L8tgQ5007561; Wed, 21 Jul 2010 08:55:42 GMT Received: from mail pickup service by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 12:20:43 -0700 Received: from xbh-rcd-301.cisco.com ([72.163.63.8]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 18:58:52 -0700 Received: from sj-iport-1.cisco.com ([171.71.176.70]) by xbh-rcd-301.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 20:58:48 -0500 Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-1.cisco.com with ESMTP; 20 Jul 2010 01:26:51 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6K1Qo3n026484; Tue, 20 Jul 2010 01:26:51 GMT Message-Id: <201007200126.o6K1Qo3n026484@sj-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Jul 2010 20:26:49 -0500 To: "Winterbottom, James" , Paul Kyzivat , "James M. Polk" From: "James M. Polk" In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880120E9829415@SISPE7MB1.com mscope.com> References: <20100719081458.77080@gmx.net> <201007191857.o6JIv7in014515@sj-core-1.cisco.com> <2936AA57-EEDC-4B43-BE88-E5BDB5D44C8C@bbn.com> <201007191943.o6JJhIrX004288@sj-core-2.cisco.com> <4C44D2E8.8020904@cisco.com> <5A55A45AE77F5941B18E5457ECAC81880120E9829415@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed X-OriginalArrivalTime: 20 Jul 2010 01:58:48.0424 (UTC) FILETIME=[17EB2E80:01CB27AF] Cc: "Richard L. Barnes" , Hannes Tschofenig , "sipcore@ietf.org" Subject: Re: [sipcore] Location Conveyance Question: Multiple Location X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 21 Jul 2010 08:55:30 -0000 James I logged your comment from a week ago on this, and Jon also agreed to it. -04 will have this explicitly allowed. James At 06:19 PM 7/19/2010, Winterbottom, James wrote: >By the same token absoluteURI also permits pres:, sip: and sips: URI >schemes, yet these are explicitly called out, presumably because >there is specification work that says how to use them for acquiring >location information. Hannes's comment, and indeed my comment made >nearly a week ago, are simply calling for the inclusion of the http: >and http2: URI schemes to also be included because similar >specification work on how to use these schemes to acquire location >information exists. > >If the argument is that this is covered by the absoluteURI >component, then presumably that is all the ABNF requires, and the >sips: sips: and pres: URI schemes can also be removed. > >Cheers >James > > > > > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf > > Of Paul Kyzivat > > Sent: Tuesday, 20 July 2010 8:34 AM > > To: James M. Polk > > Cc: Richard L. Barnes; Hannes Tschofenig; sipcore@ietf.org > > Subject: Re: [sipcore] Location Conveyance Question: Multiple Location > > > > > > > > James M. Polk wrote: > > > At 02:12 PM 7/19/2010, Richard L. Barnes wrote: > > >> I might be mistaken, but it looks to me as if the header ABNF would > > >> allow the following: > > >> > > >> Geolocation: > , >> foobar> > > > > The ABNF permits that (by virtue of allowing absoluteURI, http: is > > permitted), but the text does not: > > > > The Geolocation header field has zero or one locationValue, but > > MUST NOT contain more than one locationValue. > > > > >sipcore From john.elwell@siemens-enterprise.com Wed Jul 21 02:18:16 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D39643A6905 for ; Wed, 21 Jul 2010 02:18:16 -0700 (PDT) X-Quarantine-ID: X-Virus-Scanned: amavisd-new at amsl.com X-Amavis-Alert: BANNED, message contains part: multipart/mixed | application/ms-tnef,.tnef,winmail.dat X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[AWL=3.589, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] X-Amavis-Modified: Mail body modified (defanged) by core3.amsl.com Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EXfWCbyJWbry for ; Wed, 21 Jul 2010 02:18:15 -0700 (PDT) Content-Type: multipart/mixed; boundary="----------=_1279703896-22153-1" Content-Transfer-Encoding: binary MIME-Version: 1.0 Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C6ABC3A6890 for ; Wed, 21 Jul 2010 02:18:15 -0700 (PDT) Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 21 Jul 2010 09:18:32 +0000 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 o6L9IWGt025615 for ; Wed, 21 Jul 2010 09:18:32 GMT Received: from mail pickup service by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 12:22:18 -0700 Received: from xbh-rcd-102.cisco.com ([72.163.62.139]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jul 2010 04:35:20 -0700 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 06:00:14 -0500 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 11:00:12 +0000 Received: from sj-inbound-f.cisco.com (sj-inbound-f.cisco.com [128.107.234.207]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KB0CZq005717 for ; Tue, 20 Jul 2010 11:00:12 GMT Received: from m0019.fra.mmp.de.bt.com (HELO ms01.m0019.fra.mmp.de.bt.com) ([62.180.227.30]) by sj-inbound-f.cisco.com with ESMTP; 20 Jul 2010 11:00:11 +0000 Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-907710; Tue, 20 Jul 2010 13:00:09 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id B4A0D1EB82AB; Tue, 20 Jul 2010 13:00:09 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 20 Jul 2010 13:00:09 +0200 Date: Tue, 20 Jul 2010 06:00:08 -0500 Message-ID: In-Reply-To: <201007122355.o6CNt6us024310@sj-core-3.cisco.com> References: <201007122355.o6CNt6us024310@sj-core-3.cisco.com> From: "Elwell, John" To: "James Polk (jmpolk)" , Subject: Re: [sipcore] location-conveyance-03 just 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: Wed, 21 Jul 2010 09:18:16 -0000 This is a multi-part message in MIME format... ------------=_1279703896-22153-1 Content-Type: text/plain; charset="iso-8859-1" Content-Disposition: inline Content-Transfer-Encoding: 7bit WARNING: contains banned part ------------=_1279703896-22153-1 Content-Type: message/rfc822; x-spam-type=original; name="message" Content-Disposition: attachment; filename="message" Content-Transfer-Encoding: 7bit Content-Description: Original message Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by core3.amsl.com (Postfix) with ESMTP id C6ABC3A6890 for ; Wed, 21 Jul 2010 02:18:15 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-Files: winmail.dat : 4636 Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-6.cisco.com with ESMTP; 21 Jul 2010 09:18:32 +0000 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 o6L9IWGt025615 for ; Wed, 21 Jul 2010 09:18:32 GMT Received: from mail pickup service by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 12:22:18 -0700 Received: from xbh-rcd-102.cisco.com ([72.163.62.139]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 20 Jul 2010 04:35:20 -0700 Received: from sj-iport-4.cisco.com ([171.68.10.86]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 20 Jul 2010 06:00:14 -0500 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----_=_NextPart_001_01CB27FA.BAD4B300" X-MimeOLE: Produced By Microsoft Exchange V6.5 Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-4.cisco.com with ESMTP; 20 Jul 2010 11:00:12 +0000 Received: from sj-inbound-f.cisco.com (sj-inbound-f.cisco.com [128.107.234.207]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6KB0CZq005717 for ; Tue, 20 Jul 2010 11:00:12 GMT Received: from m0019.fra.mmp.de.bt.com (HELO ms01.m0019.fra.mmp.de.bt.com) ([62.180.227.30]) by sj-inbound-f.cisco.com with ESMTP; 20 Jul 2010 11:00:11 +0000 Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms01.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-907710; Tue, 20 Jul 2010 13:00:09 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id B4A0D1EB82AB; Tue, 20 Jul 2010 13:00:09 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Tue, 20 Jul 2010 13:00:09 +0200 Content-Language: en-US X-OriginalArrivalTime: 20 Jul 2010 11:00:14.0769 (UTC) FILETIME=[BB4A0A10:01CB27FA] X-IronPort-AV: E=Sophos;i="4.55,231,1278288000"; d="scan'208";a="205327952" X-from-outside-Cisco: 62.180.227.30 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: At0BABEfRUw+tOMemWdsb2JhbACgBAEBAQEBCAsKBxEipG6bL4JqgkgEixo Accept-Language: en-US acceptlanguage: en-US Content-class: urn:content-classes:message Subject: RE: [sipcore] location-conveyance-03 just submitted Date: Tue, 20 Jul 2010 06:00:08 -0500 Message-ID: In-Reply-To: <201007122355.o6CNt6us024310@sj-core-3.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] location-conveyance-03 just submitted Thread-Index: AcsiHatHUUgsdDW9RKGALMHNFk4DHwF2Vfow References: <201007122355.o6CNt6us024310@sj-core-3.cisco.com> From: "Elwell, John" To: "James Polk (jmpolk)" , This is a multi-part message in MIME format. ------_=_NextPart_001_01CB27FA.BAD4B300 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable James, These are questions for clarification at this stage, rather than = comments. The ABNF for the Geolocation header field allows multiple locationValues = and multiple routing-params, in any order. The text below seems to limit = it to 0 or 1 locationValue and 0 or 1 routing-param, and furthermore it = limits it so that the routing-param must be last. It seems this could be = expressed much more precisely, and still quite easily, in the ABNF. Of = have I misunderstood something? Although the text "The Geolocation header field has zero or one = locationValue, but=20 MUST NOT contain more than one locationValue." limits the header field to having a maximum of one locationValue, text = further down "another=20 instance of the Geolocation header" suggests that there can be multiple instances of the header field and = hence multiple locationValues. So a request can contain multiple = locationValues, but not in the same header field instance. Is this = really what is intended? Unrelated to the above, concerning the text: "Other URI schemas used in the location URI MUST be reviewed against=20 the RFC 3693 [RFC3693] criteria for a Using Protocol" Who must review? The protocol implementer? How is this testable? John > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of James M. Polk > Sent: 13 July 2010 00:55 > To: sipcore@ietf.org > Subject: [sipcore] location-conveyance-03 just submitted >=20 > SIPCORE >=20 > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio > n-conveyance-03.txt >=20 > This version is a fairly radical departure from previous versions of=20 > the (long standing) effort. This time the doc didn't grow... >=20 > We added Jon Peterson as a co-author, and he helped in Anaheim=20 > propose a significantly less complex way of specifying location=20 > conveyance for SIP. More than 95% of the doc has been rewritten by=20 > Jon and I, with a net result of 27 less pages of text (52 to 25 now). >=20 > We took out the terms and concepts of following parameters: >=20 > - inserter > - inserted-by > - used-for-routing > - host-id > - node-id >=20 > as well as limiting the number of locationValues to *ONE*, in=20 > a SIP request. >=20 > We removed the ability for SIP intermediaries to add location along=20 > the way unbeknownst to the UAC (with one infrequently used=20 > exception). In this way, location errors are only end-to-end, so=20 > there is no need to identify which entity added location to make sure=20 > the right entity reacted the right way when an error was caused by=20 > the location they inserted, and not that of another entity's inserted=20 > location (which is all very confusing). >=20 > We added the ability for a SIP intermediary to augment a location=20 > with what the UAC should send in a subsequent request, and the=20 > ability to verify this augmentation is present before successfully=20 > processing that request. This is in line with both RFCs 4479 and 5491. >=20 > Comments are appreciated >=20 > James >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore >=20 ------_=_NextPart_001_01CB27FA.BAD4B300 Content-Type: application/ms-tnef; name="winmail.dat" Content-Transfer-Encoding: base64 eJ8+IhULAQaQCAAEAAAAAAABAAEAAQeQBgAIAAAA5AQAAAAAAADoAAEIgAcAGAAAAElQTS5NaWNy b3NvZnQgTWFpbC5Ob3RlADEIAQ2ABAACAAAAAgACAAEEgAEANAAAAFJFOiBbc2lwY29yZV0gbG9j YXRpb24tY29udmV5YW5jZS0wMyBqdXN0IHN1Ym1pdHRlZADWEgEFgAMADgAAANoHBwAUAAYAAAAI AAIADAEBIIADAA4AAADaBwcAFAAGAAAADgACABIBAQmAAQAhAAAAMDU0RDRGNjYxMkM0MjE0QThD ODExOERGOTc1ODM2NkUADQcBA5AGABwRAAAxAAAAAwA2AAAAAABAADkAACxBt/onywEeAD0AAQAA AAUAAABSRTogAAAAAB4AcAABAAAAMAAAAFtzaXBjb3JlXSBsb2NhdGlvbi1jb252ZXlhbmNlLTAz IGp1c3Qgc3VibWl0dGVkAAIBcQABAAAAGwAAAAHLIh2rR1FILHQ1vUShgCzBzRZOAx8BdlX6MAAe ABoMAQAAAA0AAABFbHdlbGwsIEpvaG4AAAAAHgAdDgEAAAAwAAAAW3NpcGNvcmVdIGxvY2F0aW9u LWNvbnZleWFuY2UtMDMganVzdCBzdWJtaXR0ZWQAAgEJEAEAAAALCAAABwgAAKMOAABMWkZ1m0Fl ZgMACgByY3BnMTI14jIDQ3RleAVBAQMB9/8KgAKkA+QHEwKAD/MAUARWPwhVB7IRJQ5RAwECAGNo 4QrAc2V0MgYABsMRJfYzBEYTtzASLBEzCO8J97Y7GB8OMDURIgxgYwBQMwsJAWQzNhZQC6YgSjph B4EsCqIKhAqAVGhZB5BlIArAHlBxClBzvHRpAiAEIAIQBcBjC2A7BoEN4GEe8h5gBUB0aAUEACAe 4GFnZSwgfnIgEB4gBcAgoAORBaBtMweAAjBzLh1dEMBCTsZGH0MhgSBHZRehIAWdHiBhBIEfQAiQ bGQeYIpsF7B3BCBtdWwe8HcLUB5QJLZWB0AewR5gbhcl8CaHA2B1HvBuZy03CrEdAB0wIAuAJ/F5 ILMFsASBLiAjcg6zYiXQ3yZAIOAJ4CmQIJBvJwAHcL5pBUAsYSwBFlAFsTEnDN8n8yz1KNshQCgC ZghwIYK/BGAegSxhLDMEICxhcywQfyHRIIIovSZxHuArMScAYfse4CqQSTGRK7QgsgWgJpD3JfAz oQ7AcBggBBAJgCZxbxPQJnAwojXBYwQAJdB5/y/EHuEmIB6hLGA1gTPgAxCfN2Ep0SRCI7IqkE9m JTC0YXYeUEkmcAQAdSgQ+wSQHuBvBHAxoQeAIKEpIKo/HVpBJqBoCGBnNnD7JEIOsyIjciSPJZYT 4AQgfnoEkCwQBbECICb9IUBiFyjwCuMKgCBCUE1VU/pUB7BPQrAFoAIwC3E2hPMh00CPLiIdVDEV JEIlS58sAToRKREeYCZwYXgHcPp1MzBvOfBEPyFADrMwJawgZCZAA6AiAHBvIYPnQfcLgCDxbmMe UEiBJE/3JVNFVTqgZyEgHuA0ojIE/x6BIAADoDOhJodMJgQgTLV/JUwoER4gTHImjyeUKpBT/ywQ R+AYIB6zT+NDF1OPJ6P3QZRLITkGcx0BJTxMJjQR7zSlGCAmESogdzHyIMELgMsOsDrBZDv7VW4Y IAtg7w6wRyNM4gGgbzowIUBDES9MgASgR6I9VjodVCJP+SGDVVI6YATwHiAAwAQg/zNgNhE5FT5n YSJCgzOhGCD/R5AH0DYRIRALcTNxQfdM4hBSRkMgHCA5MyD2W2XRZhJdH4AFEA6wByHbH0NH4FUA kEexUANgLAC7F5FFVVc88DNEY/Q/KqP3NcBodCnAbVbhIlIEkGowfkgrcSDBIKMOsCDxAmBlMTv7 Sm9oC5AdaT4g6i1vIk8FEGcLgAdABdCvNeEhEW8jbqZGA2E6IOC/BSAFoXBgBuA6sFFRQAiQ3QAw LgWwR8BuplsAwAMQXSwAOnGvcrVm4E8DoEL6ZRPgbDnwOeEc8wXQKpB6UAbwa26mBmACMHGAMV1m QEpWoCogAdAxFlAw7DA6GmBuplR0EHGWcpexd3d1YmoFkHghW3Q1W2bgPmYtQxE6MHlMYi3aMGZA ajNiOqBiLFFd8QNupnd3SVBDT1JFBX8+aAJAcDovL3d1ghAucqYvXEIEoBQgLaZkIWABgHMvg3Mt cqJeLXQ2PmVupn1dLgzQdP9/Ph4QIME6MBQAIDIgwWdx7QtwcluRIWBkH/EDIAEA/QqxdAhwHlAD UjbSR5AIYO+IZ1FzbqZM4igXsEexTEL7ieApICk1kAEgF8EqkIgkLx7wWTFM4kqwY0qgaWTcbicF QAnAJkAukKB/PrpXHlFkXJEc4CBBUBQgzzrhIEKJEgWgLWEo8DzwpnIvxEZDbHBiBEFvwM8eIAdw cydqkXBvHkJxkf5nAwAf4gIwW5FW8AQRIiG1VuF4W7BhKiE58HOU0Pk3EGZ5R6I+Z26mfXgfQ4uA MSqQTUOnOTUlTKbfj7I/witACfBVQXdnEVxh3yswKiBuppJiKAJJIUAD8H8goEfRgzFVQTqgVrBI cjK+N5e0CrBO4UyjDsIoDkDnK/IOMFhRdymQz5HROxH+ayowQcE9VDCAJ+RfEwUw/1FzAhAmIkei KVOSs2BFf5heLUwSBJBnMaj/ZHSgeeuqGGHiLR9RLSjVqhg88P8e4IQwfyepcEsgAQCt6W6mvz/R ZEA4AT/RLDNfhm5IUB8rQEBhOfAnHSwBKk9O/EUqKbOvp4AiVUajv5HR/xggBGA6MEchXnMDECxg KiD/m3VcMzCACYAHMAiBK+OSAX9imAdAjWKMipiSOrArQGuno3Fkwl41VUFl8CigI/9IsguAA1BV YpdzYeNupg7A/6aSHwGjoDQgOSIgwZiRIUD/PmcEkANgFAAeYwIgW5FccfotLAAtXHEhQDGxjIkw sv8EIEsgoIFeBJAAImGZQVux/w3gNnDFQrehkgQ+ZywBAMD+a1jxiqKMim+BgaDGBltR/3wAtuXJ BJiSW8Cd8QORwXP/mIE08ZOwNgKeyWJrIYEqIH+qti/EWGIx40iBSxbGFCf/XCKq1HMnPme9EMXD iQI4Af+IgSogQxEwIGgCo6+RyLce/7SEuFkqILlCPRAiUkfRmb/3oCNbw7yWczzxJeEUECgR/ynS fpIUEL4DVUYvxEzir6f/t2UsAYiBxXIgo9i1IBQgwV81wtjyK0AfUcfSY1FRc/8wIFuClcniYl+E IHG05ogk/1wTLCFIwaAjBuCgQWXRBCAQNDQ3OSfzNTQ5njHUvwhQIkQeY2FwNuPvXeJ/Phzzfz5f 7L/tz+6a/26mdDVH8bdxmYIEAIcnej/fgTmoUIH9c8IDgS/xIr2xLG8vdDV/PH33IAAeADUQAQAA AEIAAAA8QTQ0NEEwRjgwODQ0MzQ0OTkyMDZFNzhDMTA2MjIwQ0FFQ0JBNEQ1OUBNQ0hQMDU4QS5n bG9iYWwtYWQubmV0PgAAAB4AORABAAAAMgAAADwyMDEwMDcxMjIzNTUubzZDTnQ2dXMwMjQzMTBA c2otY29yZS0zLmNpc2NvLmNvbT4AAAAeAEIQAQAAADIAAAA8MjAxMDA3MTIyMzU1Lm82Q050NnVz MDI0MzEwQHNqLWNvcmUtMy5jaXNjby5jb20+AAAACwDyEAAAAAAfAPMQAQAAAHQAAABSAEUAJQAz AEEAIABbAHMAaQBwAGMAbwByAGUAXQAgAGwAbwBjAGEAdABpAG8AbgAtAGMAbwBuAHYAZQB5AGEA bgBjAGUALQAwADMAIABqAHUAcwB0ACAAcwB1AGIAbQBpAHQAdABlAGQALgBFAE0ATAAAAAsA9BAA AAAACwD1EAAAAAALAPYQAAAAAEAABzBcrVO7+ifLAUAACDBY1Fq7+ifLAQMA3j+vbwAAAwDxPwAA AAAeAPg/AQAAABUAAABTeXN0ZW0gQWRtaW5pc3RyYXRvcgAAAAACAfk/AQAAAB4AAAAAAAAA3KdA yMBCEBq0uQgAKy/hggEAAAAAAAAALgAAAB4A+j8BAAAAFQAAAFN5c3RlbSBBZG1pbmlzdHJhdG9y AAAAAAIB+z8BAAAAHgAAAAAAAADcp0DIwEIQGrS5CAArL+GCAQAAAAAAAAAuAAAAAwD9P+QEAAAD ABlAAAABAAMAGkAAAAEAHgAwQAEAAAAjAAAAam9obi5lbHdlbGxAc2llbWVucy1lbnRlcnByaXNl LmNvbQAAHgAxQAEAAAAjAAAAam9obi5lbHdlbGxAc2llbWVucy1lbnRlcnByaXNlLmNvbQAAHgA4 QAEAAAACAAAALgAAAB4AOUABAAAAAgAAAC4AAAAeAF2AhgMCAAAAAADAAAAAAAAARgEAAAAiAAAA YwBvAG4AdABlAG4AdAAtAGwAYQBuAGcAdQBhAGcAZQAAAAAAAQAAAAYAAABlbi1VUwAAAB4AfICG AwIAAAAAAMAAAAAAAABGAQAAABgAAAByAGUAdAB1AHIAbgAtAHAAYQB0AGgAAAABAAAAJQAAADxq b2huLmVsd2VsbEBzaWVtZW5zLWVudGVycHJpc2UuY29tPgAAAAAeAG6DhgMCAAAAAADAAAAAAAAA RgEAAAAsAAAAeAAtAG8AcgBpAGcAaQBuAGEAbABhAHIAcgBpAHYAYQBsAHQAaQBtAGUAAAABAAAA PQAAADIwIEp1bCAyMDEwIDExOjAwOjE0LjA3NjkgKFVUQykgRklMRVRJTUU9W0JCNEEwQTEwOjAx Q0IyN0ZBXQAAAAAeAHaDhgMCAAAAAADAAAAAAAAARgEAAAAuAAAAYQB1AHQAaABlAG4AdABpAGMA YQB0AGkAbwBuAC0AcgBlAHMAdQBsAHQAcwAAAAAAAQAAAEYAAABzai1pcG9ydC00LmNpc2NvLmNv bTsgZGtpbT1uZXV0cmFsIChtZXNzYWdlIG5vdCBzaWduZWQpIGhlYWRlci5pPW5vbmUAAAAeAHiD hgMCAAAAAADAAAAAAAAARgEAAAAcAAAAeAAtAGkAcgBvAG4AcABvAHIAdAAtAGEAdgAAAAEAAABA AAAART1Tb3Bob3M7aT0iNC41NSwyMzEsMTI3ODI4ODAwMCI7ICAgIGQ9InNjYW4nMjA4IjthPSIy MDUzMjc5NTIiAB4AfIOGAwIAAAAAAMAAAAAAAABGAQAAACoAAAB4AC0AZgByAG8AbQAtAG8AdQB0 AHMAaQBkAGUALQBjAGkAcwBjAG8AAAAAAAEAAAAOAAAANjIuMTgwLjIyNy4zMAAAAB4AfYOGAwIA AAAAAMAAAAAAAABGAQAAADwAAAB4AC0AaQByAG8AbgBwAG8AcgB0AC0AYQBuAHQAaQAtAHMAcABh AG0ALQBmAGkAbAB0AGUAcgBlAGQAAAABAAAABQAAAHRydWUAAAAAHgB+g4YDAgAAAAAAwAAAAAAA AEYBAAAAOAAAAHgALQBpAHIAbwBuAHAAbwByAHQALQBhAG4AdABpAC0AcwBwAGEAbQAtAHIAZQBz AHUAbAB0AAAAAQAAADwAAABBdDBCQUJFZlJVdyt0T01lbVdkc2IySmhiQUNnQkFFQkFRRUJDQXNL QnhFaXBHNmJMNEpxZ2tnRWl4bwAeAICDhgMCAAAAAADAAAAAAAAARgEAAAAgAAAAYQBjAGMAZQBw AHQALQBsAGEAbgBnAHUAYQBnAGUAAAABAAAABgAAAGVuLVVTAAAAHgCBg4YDAgAAAAAAwAAAAAAA AEYBAAAAHgAAAGEAYwBjAGUAcAB0AGwAYQBuAGcAdQBhAGcAZQAAAAAAAQAAAAYAAABlbi1VUwAA AAsAKQAAAAAACwAjAAAAAAADAAYQVvpuaQMABxCHCQAAAwAQEAAAAAADABEQAQAAAB4ACBABAAAA ZQAAAEpBTUVTLFRIRVNFQVJFUVVFU1RJT05TRk9SQ0xBUklGSUNBVElPTkFUVEhJU1NUQUdFLFJB VEhFUlRIQU5DT01NRU5UU1RIRUFCTkZGT1JUSEVHRU9MT0NBVElPTkhFQURFUkYAAAAAAgF/AAEA AABCAAAAPEE0NDRBMEY4MDg0NDM0NDk5MjA2RTc4QzEwNjIyMENBRUNCQTRENTlATUNIUDA1OEEu Z2xvYmFsLWFkLm5ldD4AAADtuw== ------_=_NextPart_001_01CB27FA.BAD4B300-- ------------=_1279703896-22153-1-- From jmpolk@cisco.com Wed Jul 21 02:26:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3B6E83A6B83 for ; Wed, 21 Jul 2010 02:26:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.629 X-Spam-Level: X-Spam-Status: No, score=-9.629 tagged_above=-999 required=5 tests=[AWL=-0.426, BAYES_00=-2.599, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AiOC8neEzO95 for ; Wed, 21 Jul 2010 02:26:11 -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 724A53A6B7A for ; Wed, 21 Jul 2010 02:26:11 -0700 (PDT) Authentication-Results: sj-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AksFAIBaRkyrR7Ht/2dsb2JhbACfGlZxpCebEIJqgkgEhACHDw Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-2.cisco.com with ESMTP; 21 Jul 2010 09:26:27 +0000 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 o6L9QRIx013294; Wed, 21 Jul 2010 09:26:27 GMT Received: from mail pickup service by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC; Tue, 20 Jul 2010 12:22:54 -0700 Received: from xbh-rcd-102.cisco.com ([72.163.62.139]) by xbh-sjc-221.amer.cisco.com with Microsoft SMTPSVC(6.0.3790.3959); Mon, 19 Jul 2010 18:58:56 -0700 Received: from sj-iport-2.cisco.com ([171.71.176.71]) by xbh-rcd-102.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Mon, 19 Jul 2010 20:58:27 -0500 Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-2.cisco.com with ESMTP; 20 Jul 2010 01:24:39 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6K1N8PU005489; Tue, 20 Jul 2010 01:23:08 GMT Message-Id: <201007200123.o6K1N8PU005489@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 19 Jul 2010 20:23:07 -0500 To: "Richard L. Barnes" , "Peterson, Jon" From: "James M. Polk" In-Reply-To: <605CEAA0-91F5-4860-A2B6-7E1BAFD3D847@bbn.com> References: <605CEAA0-91F5-4860-A2B6-7E1BAFD3D847@bbn.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable X-OriginalArrivalTime: 20 Jul 2010 01:58:28.0428 (UTC) FILETIME=[0C0008C0:01CB27AF] Cc: Roger Marshall , "sipcore@ietf.org" , "Thomson, Martin" Subject: Re: [sipcore] composition or just indirection (was: location-conveyance-03 just 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: Wed, 21 Jul 2010 09:26:13 -0000 Richard Let's not forget the cost of having more than one=20 document in terms of additive bytes in the=20 request. Adding another or =20 element is not that much more data, whereas=20 adding a second or third PIDF would be a lot more. James At 04:44 PM 7/19/2010, Richard L. Barnes wrote: >While it's correct to say that one presence=20 >document describes a single entity, it's not=20 >necessarily true that multiple presence=20 >documents describe multiple=20 >entities. Regardless of how we define the=20 >entity in the session that is the target (IIRC,=20 >earlier versions said something like "the UAC=20 >that initiated the dialogue"), it seems=20 >plausible that different entities processing a=20 >SIP message might have different ideas as to the=20 >location of the target. In this case, it would=20 >seem plausible to have multiple location objects=20 >in a single message, all of which have the=20 >semantic that they're describing the location of=20 >the target (however the target is coupled to the session). > >Speaking more practically, if we accept the=20 >assertion that multiple location values will be=20 >necessary (whether in a single document or not),=20 >then it seems much cleaner to have them in=20 >separate presence documents, with separate CID=20 >URIs. I don't really see any reason for any of=20 >this to call for more than one Geolocation=20 >header, since you can just add more URIs. > > > >On Jul 19, 2010, at 5:29 PM, Peterson, Jon wrote: > >> >>I=92m sure we=92re all going to have to discuss=20 >>this a bit in Maastricht, but there are a=20 >>couple basic points here I think we need to tee=20 >>up. I certainly didn=92t mean to suggest that a=20 >>request can only include a single location=20 >>(i.e., that any contributing piece of location=20 >>information designates the same place, just=20 >>with varying degrees of accuracy or timeliness=20 >>or something). Rather, I believe a presence=20 >>document describes a single entity =96 multiple=20 >>locations come about because various devices=20 >>and services associated with that single entity=20 >>may attribute various locations to the entity. >> >>Getting back to fundamentals, we don=92t need a=20 >>Geolocation header in order to carry location=20 >>in SIP. There are MIME bodies for that=20 >>(including Content-Indirection bodies for LbyR,=20 >>or perhaps Content-Location as you suggest),=20 >>and we can include seventeen different location=20 >>objects if we want to, regardless of whether=20 >>there are zero or one or fifteen Geolocation=20 >>headers. We don=92t need a location conveyance=20 >>specification or a Geolocation header to enable=20 >>that, SIP has always been able to do it, and=20 >>you=92ll still be able to add random MIME bodies=20 >>that contain location information even if there=20 >>is a Geolocation header which does not point to=20 >>them. So what does the Geolocation header and=20 >>location conveyance specification buy us? >> >>I=92ve always naively thought that the=20 >>Geolocation header provides a coupling between=20 >>this particular SIP session and an entity whose=20 >>location is designated by a PIDF document. The=20 >>entity is the geopriv Target, and is probably=20 >>(though not necessarily) related to the party=20 >>identified by the classic From header field of=20 >>the SIP request. The Geolocation header tells=20 >>us that for the purposes of the SIP session=20 >>being negotiated, the location of this Target=20 >>is somehow relevant... the boldest=20 >>interpretation would be that this Target=92s=20 >>location should be considered the source of the=20 >>request. Just attaching location-aware MIME=20 >>bodies without the Geolocation header to SIP=20 >>requests doesn=92t convey the same semantics =96=20 >>those bodies could mean anything, and=20 >>presumably the receiving application would sort through them at its= discretion. >> >>Where I get confused is when I start trying to=20 >>understand what it would mean semantically for=20 >>a SIP session to be coupled with more than one=20 >>Target. Again, I can imagine hypothetically a=20 >>SIP request containing unsorted MIME bodies=20 >>that talk about different Targets to assist=20 >>some specific application that knows how to=20 >>reconcile them, but here I mean using the=20 >>Geolocation header to couple a SIP request with=20 >>location information about different Targets.=20 >>Is there actually a use case/requirement for=20 >>that? If not, and we only want to couple a SIP=20 >>request with one Target, then I fail to see why=20 >>composing location information about the same=20 >>Target into a single PIDF body would be a=20 >>problem. Having location information about the=20 >>same entity fail to be organized in one body=20 >>through RFC4479 wouldn=92t make sense, anyway. >> >>I think if we understand the semantics by which=20 >>the Geolocation header =93couples=94 PIDF with a=20 >>SIP session, then we=92ll better understand all=20 >>of this. If the Geolocation header only exists=20 >>to notify lazy intermediaries that there are=20 >>location-sensitive bodies in the request or=20 >>somewhere out on the net, without implying=20 >>anything about the Target or the relationship=20 >>of those locations to the SIP request, then=20 >>this whole specification is probably more=20 >>trouble than it=92s worth =96 it really wouldn=92t=20 >>provide much incremental value above the basic=20 >>ability of SIP to carry all sorts of bodies,=20 >>including location bodies. If there are,=20 >>however, more binding semantics here, then we=20 >>probably won=92t be able to agree on the need for=20 >>solitary or multiple Geolocation headers until=20 >>we agree on what those semantics are. >> >>Jon Peterson >>NeuStar, Inc. >> >> >>On 7/18/10 7:25 PM, "Thomson, Martin"=20 >><Martin.Thomson@andrew.com> wrote: >> >>Hi Jon, >> >>I admit a fair degree of sympathy for Roger=92s=20 >>suggestion. After all, the ability to include=20 >>multiple location =93values=94 in the same SIP=20 >>request is a feature that has existed for many=20 >>years. A number of implementations have come=20 >>to rely on this mechanism; people are building=20 >>and have built solutions based on earlier=20 >>draft, fully aware of the risks in implementing an internet draft. >> >>At some point, it might be necessary to swallow=20 >>any discomfort and recognize that the=20 >>consequences of an imperfect solution are less=20 >>than the consequences of a change of the nature you suggest. >> >>Altering perspective might offer a solution. >> >>The idea that there are multiple items that are=20 >>composited might be counterproductive. In this=20 >>world-view, you have to reconcile a number of=20 >>perspectives. In this, you are absolutely=20 >>correct: doing that at two layers is=20 >>bad. Composition is a hard problem=20 >>already. Moving it into SIP only complicates it further. >> >>The alternative is to imagine a single logical=20 >>resource that represents the location of the=20 >>Target. A location by value is a=20 >>representation of this resource: a=20 >>snapshot. Location by reference offers a means=20 >>for any entity to identify and acquire a view=20 >>of the resource, independent of that=20 >>snapshot. The authority for the resource might=20 >>offer the same representation, or it could=20 >>offer one better suited to the recipient. The=20 >>representation might be updated, it might be=20 >>altered based on an authorization policy, or=20 >>something else (language=20 >>preferences). Regardless of how it is=20 >>represented, it is still the same resource. >> >>In simple terms, you state that the request can=20 >>only include a single _location_. When a=20 >>location value and reference are both included,=20 >>they represent the _same_ location. >> >>This is why I suggested that Content-Location=20 >>be borrowed. In HTTP, Content-Location says -=20 >>if you want to know where this resource really=20 >>lives, here is where you can find it. >> >>Now this might be sheer sophistry, but it might=20 >>offer a way out. The composition problems are left out of SIP. >> >>I can write up a more detailed strawman, but=20 >>for now, I'll just include an example: >> >> INVITE sips:bob@biloxi.example.com SIP/2.0 >> Via: SIPS/2.0/TLS pc33.atlanta.example.com;branch=3Dz9hG4bK74bf9 >> Max-Forwards: 70 >> To: Bob bob@biloxi.example.com> >> From: Alice=20 >>= alice@atlanta.example.com>;tag=3D9fxced76s= l >> Call-ID:=20 >>= <3848276298220188511@atlanta.example.htm>3848276298220188511@atlanta.exampl= e.com >> Geolocation:=20 >> target123@atlanta.example.com> >> ;routing-allowed=3Dno >> Supported: geolocation >> Accept: application/sdp, application/pidf+xml >> CSeq: 31862 INVITE >> Contact: alice@atlanta.example.com> >> Content-Type: multipart/mixed; boundary=3Dboundary1 >> Content-Length: ... >> >> --boundary1 >> Content-Type: application/sdp >> >> ...SDP goes here >> >> --boundary1 >> Content-Type: application/pidf+xml >> Content-ID:=20 >> <target123@atlanta.example.com> >> Content-Location:=20 >> pres:alice@example.com?location/XJhbXM6eG1sOm5zOnBpZ >> >> >> ...PIDF-LO document >> --boundary1-- >> >> >>--Martin >> >>---- Original Message ---- >>From: Peterson, Jon=20 >>[mailto:jon.peterson@neustar.biz] >>Sent: Friday, 16 July 2010 4:54 PM >>To: Roger Marshall; Thomson, Martin; James M.=20 >>Polk; sipcore@ietf.org >>Subject: Re: [sipcore] location-conveyance-03 just submitted >> >> >>In the corner case (and I do think it is a=20 >>corner case) where multiple entities are=20 >>contributing different location information to=20 >>a single SIP request, I think we face a=20 >>fundamental architecture choice in this=20 >>mechanism: either it is SIP=92s job to sort out=20 >>how we understand those different locations, or=20 >>it is PIDF=92s job. Traditionally, PIDF=92s=20 >>understanding of different sources of presence=20 >>that provide potentially contradictory=20 >>information relies on the presence data model=20 >>(RFC4479), which is designed to reconcile=20 >>conditions like the one where my mobile phone=20 >>thinks I am available but my desktop thinks I=92m=20 >>offline. The presence data model moreover=20 >>differentiates between users, services and=20 >>devices in a way that is useful and apparently=20 >>applicable to location information. I am not=20 >>eager to try to replicate this in SIP headers,=20 >>including by inserting multiple such headers,=20 >>putting in markup that tries to explain the=20 >>=93source=94 of location information in SIP=20 >>headers, and so on. SIP=92s job should be to=20 >>convey the location object =96 fundamentally, the=20 >>further we diverge from =93conveyance=94 and enter=20 >>into the realm of =93integration,=94 the less comfortable I get. >> >>I understand that the subsequent use case where=20 >>there are different sources of location=20 >>information, some of which are LbrV and some of=20 >>which are LbyR, looks like a hairy one. This=20 >>is, however, a corner case of a corner case. I=20 >>really do not feel comfortable justifying the=20 >>allowance of multiple location headers in SIP=20 >>pointing to different presence objects (as=20 >>opposed to following the presence data model)=20 >>to carry the 0, 1 or 2 different locations due=20 >>to a corner case of a corner case. As I said in=20 >>my previous mail to Martin, I=92m not really sure=20 >>I even understand the requirements for an=20 >>intermediary to evaluate and reject LbyR, nor=20 >>what the best way is for presence from these=20 >>dynamic sources to be composed. If we were to=20 >>investigate the right way for presence from=20 >>those source to be composed, it might very well=20 >>be that it is the responsibility of the=20 >>compositor to insert an LbyR into the SIP=20 >>request (into the Geolocation header), and to=20 >>poll and compose a coherent PIDF document from=20 >>its dynamic and static sources =96 that is=20 >>probably the approach that most closely=20 >>parallels the traditional approaches to=20 >>presence. But we haven=92t even begun to explore=20 >>this yet. No one insisting that there will be=20 >>=93empty=94 PIDF documents just containing=20 >>references to external PIDF documents or=20 >>something. Something along those lines is one=20 >>approach of many that we would consider if we=20 >>tried to figure out how to address this in=20 >>PIDF. The question we need to decide, as I said=20 >>above, is the architecture one =96 is SIP=92s job=20 >>to convey PIDF documents, or to compose them? >> >>Jon Peterson >>NeuStar, Inc. >> >>=85 >> >>_______________________________________________ >>sipcore mailing list >>sipcore@ietf.org >>https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Wed Jul 21 11:47:19 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6F3A33A6B12 for ; Wed, 21 Jul 2010 11:47:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AfNav47CI4jW for ; Wed, 21 Jul 2010 11:47:13 -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 2DEAF3A6B04 for ; Wed, 21 Jul 2010 11:47:07 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAL/dRkyrR7H+/2dsb2JhbACfc3GnL5sRhTIEiFk Received: from sj-core-2.cisco.com ([171.71.177.254]) by sj-iport-5.cisco.com with ESMTP; 21 Jul 2010 18:47:22 +0000 Received: from [10.86.247.242] ([10.86.247.242]) by sj-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6LIlLn4002072; Wed, 21 Jul 2010 18:47:21 GMT Message-ID: <4C4740B8.3010401@cisco.com> Date: Wed, 21 Jul 2010 14:47:20 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Gonzalo Camarillo , SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 21 Jul 2010 18:47:20 -0000 Gonzallo, Sorry it took me so long, but I finally got time to read the new version carefully. This is looking good. I have a few nits, and a couple of things that might be more than nits. 3.1: nit: s/The UAS is automatically configured to reject video streams/The UAS is configured to automatically reject video streams/ 3.3: A change to the session state is considered to have been executed if an offer/answer without preconditions [RFC4032] for the stream has completed successfully or the UAs have exchanged media using the new "exchanged" is a tricky word here, and could use some added definition. A UA can know if it has *sent* media, and it can know if it has *received* media. If media has been received (and can be distinguished from the media that would have been received had the change not occurred) then that UA knows media has been exchanged. But it doesn't know if the other UA knows media has been exchanged. We want both sides to reach the same conclusion regarding the exchange of media, but I'm not sure how to assure that. So, from the perspective of one of the UAs, how do you propose that this decision be made? Is it just "I have received media according to the new sdp"? What about cases where no media is expected to be exchanged as a result of the new O/A? E.g. Suppose the change was simply from "a=sendrecv" to "a=inactive". Is the absence of packets for some period of time evidence that this is in effect? 3.4: nit: and the session parameters in the offer/answer exchange SHOULD be as close as those in the pre-re-INVITE state as possible. s/close as those/close to those/ 4.4: If the UA receives a reliable provisional response or a 2xx response to the target-refresh request, or the UA receives a request on the new local target, the remote UA has updated its remote target. The UA can consider the target refresh operation completed. It isn't sufficient to receive a request on the new target - it must be a request *within the dialog. (It might receive an out of dialog request from another source, or otherwise unrelated.) (This is covered in 4.6, but good to catch it here too.) So I suggest: If the UAC receives a reliable provisional response or a 2xx response to the target-refresh request, or the UAC receives an in-dialog request on the new target, the UAS has updated its remote target. The UAC can consider the target refresh operation completed. 4.6: nit: s/ n-dialog/ in-dialog/ In the note discussing reliable provisional responses, it might be good to reference RFC 4320 that says they MUST NOT be used for non-invite transactions. Thanks, Paul From pkyzivat@cisco.com Wed Jul 21 13:15:42 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4C1C63A6B48 for ; Wed, 21 Jul 2010 13:15:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.399 X-Spam-Level: X-Spam-Status: No, score=-10.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7CDDZxsPkcvf for ; Wed, 21 Jul 2010 13:15:41 -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 938D83A6958 for ; Wed, 21 Jul 2010 13:15:38 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANzyRkxAZnwN/2dsb2JhbACfdHGnPpsehTIEiFk Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 21 Jul 2010 20:15:53 +0000 Received: from [10.86.247.242] ([10.86.247.242]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6LKFrUB026317; Wed, 21 Jul 2010 20:15:53 GMT Message-ID: <4C475579.8010709@cisco.com> Date: Wed, 21 Jul 2010 16:15:53 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Mary Barnes , SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis-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: Wed, 21 Jul 2010 20:15:42 -0000 Mary, (Doing my pre-meeting reading. I haven't looked at this for a *long* time.) I have a question about handling the addition of H-I to responses as described in 5.2 and especially in 6.3.3 bullet 6, for parallel forked requests: Often in a parallel forking case a final response will be forwarded without yet having seen responses from all the other active branches. If so, of necessity there is only going to be partial info, or inaccurate info. Figure 1 shows some consolidation, but it leaves out a bunch of detail a about how it is done. It notes that the path not taken is canceled and an HI entry with a 487 reason. But it won't necessarily wait for the 487 response, and may not get it. There is also a possibility that more than one 200 response will be received, and again its unclear what is to be done in that case. This case can be aggravated if the request contained Request-Disposition:nocancel and the proxy honored that. Also, I see no real addressing of non-INVITE transactions. Of particular note is SUBSCRIBE, for which multiple forks can be quite important. For it, there will not be multiple 200 responses, but there may still be NOTIFYs for multiple branches, each creating a dialog. Section 6.1 (cosmetic): instead of: hi-index = "index" EQUAL 1*DIGIT *("." 1*DIGIT) mp-param = "mp" EQUAL 1*DIGIT *("." 1*DIGIT) how about: hi-index-value = 1*DIGIT *("." 1*DIGIT) hi-index = "index" EQUAL hi-index-value mp-param = "mp" EQUAL hi-index-value Thanks, Paul From pkyzivat@cisco.com Wed Jul 21 20:10:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BE3A73A6924 for ; Wed, 21 Jul 2010 20:10:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.449 X-Spam-Level: X-Spam-Status: No, score=-10.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Co3ZhTwUmGXg for ; Wed, 21 Jul 2010 20:10:30 -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 5F26D3A6843 for ; Wed, 21 Jul 2010 20:10:30 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 22 Jul 2010 03:10:47 +0000 Received: from [10.86.247.242] ([10.86.247.242]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6M3AkJl002501; Thu, 22 Jul 2010 03:10:46 GMT Message-ID: <4C47B6B6.2090009@cisco.com> Date: Wed, 21 Jul 2010 23:10:46 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "James M. Polk (E-mail)" , Jon Peterson Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-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: Thu, 22 Jul 2010 03:10:31 -0000 I finally got around to reading this version of the document. Most stuff I noticed has already been mentioned and I won't repeat. I did notice one thing I haven't seen mentioned before: Section 4.2 says that a 424 response must not be used if there was no Geolocation header in the request. What if the UAC does not understand Geolocation and inserts no Geolocation header. However an intermediary (proxy-1) *does * insert a Geolocation header. Then a downstream intermediary (proxy-2) takes issue with that and returns a 424 response. ISTM there needs to be a requirement that the intermediary inserting the Geolocation header handle any 424 errors that might result from it, thus shielding the UAC from those. Thanks, Paul From jmpolk@cisco.com Wed Jul 21 20:29:40 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 179493A68C2 for ; Wed, 21 Jul 2010 20:29:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.468 X-Spam-Level: X-Spam-Status: No, score=-10.468 tagged_above=-999 required=5 tests=[AWL=0.131, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TXLEAbETakxB for ; Wed, 21 Jul 2010 20:29:39 -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 52F363A65A6 for ; Wed, 21 Jul 2010 20:29:39 -0700 (PDT) Authentication-Results: sj-iport-4.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-1.cisco.com ([171.71.177.237]) by sj-iport-4.cisco.com with ESMTP; 22 Jul 2010 03:29:56 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by sj-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6M3TtCI013514; Thu, 22 Jul 2010 03:29:55 GMT Message-Id: <201007220329.o6M3TtCI013514@sj-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Wed, 21 Jul 2010 22:29:54 -0500 To: Paul Kyzivat , "James M. Polk (E-mail)" , Jon Peterson From: "James M. Polk" In-Reply-To: <4C47B6B6.2090009@cisco.com> References: <4C47B6B6.2090009@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-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: Thu, 22 Jul 2010 03:29:40 -0000 At 10:10 PM 7/21/2010, Paul Kyzivat wrote: >I finally got around to reading this version of the document. >Most stuff I noticed has already been mentioned and I won't repeat. >I did notice one thing I haven't seen mentioned before: > >Section 4.2 says that a 424 response must not be used if there was >no Geolocation header in the request. This was to prevent exactly the scenario you indicate below (i.e., the UAC could go belly-up). It might be considered too rigid at the moment though (the alternative you mention below). >What if the UAC does not understand Geolocation and inserts no >Geolocation header. However an intermediary (proxy-1) *does * insert >a Geolocation header. Then a downstream intermediary (proxy-2) takes >issue with that and returns a 424 response. then the UAC will receive the 424 and not have a clue what to do with it because it cannot correct something it does not understand in the first place. >ISTM there needs to be a requirement that the intermediary inserting >the Geolocation header handle any 424 errors that might result from >it, thus shielding the UAC from those. Do you think we can state this? I'm thinking from a purest protocol pov, that seems to me to break SIP's e2e model of communication, especially when involving a literal proxy - and not some other form of SIP intermediary (e.g., b2bua or sbc that are made to do just this). I was always erring on the side of caution here, but you're the big cheese now ;-) so I'm willing to go with this. James > Thanks, > Paul From gonzalo.camarillo@ericsson.com Thu Jul 22 00:13:36 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BDC653A67D7 for ; Thu, 22 Jul 2010 00:13:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.924 X-Spam-Level: X-Spam-Status: No, score=-103.924 tagged_above=-999 required=5 tests=[AWL=-1.325, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MnM1Zaczv3fd for ; Thu, 22 Jul 2010 00:13:34 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 303143A684C for ; Thu, 22 Jul 2010 00:13:33 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-47-4c47efaec17d Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 2A.1C.06895.EAFE74C4; Thu, 22 Jul 2010 09:13:50 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jul 2010 09:13:49 +0200 Received: from [131.160.126.163] ([131.160.126.163]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jul 2010 09:13:49 +0200 Message-ID: <4C47EFAD.6080204@ericsson.com> Date: Thu, 22 Jul 2010 10:13:49 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Paul Kyzivat References: <4C4740B8.3010401@cisco.com> In-Reply-To: <4C4740B8.3010401@cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2010 07:13:49.0734 (UTC) FILETIME=[6ECDB460:01CB296D] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 22 Jul 2010 07:13:36 -0000 Hi Paul, thanks for your comments. Answers inline: On 21/07/2010 9:47 PM, Paul Kyzivat wrote: > Gonzallo, > > Sorry it took me so long, but I finally got time to read the new version > carefully. > > This is looking good. I have a few nits, and a couple of things that > might be more than nits. > > 3.1: > > nit: > s/The UAS is automatically configured to reject video streams/The UAS is > configured to automatically reject video streams/ Fixed. > > 3.3: > > A change to the session state is considered to have been executed if > an offer/answer without preconditions [RFC4032] for the stream has > completed successfully or the UAs have exchanged media using the new > > "exchanged" is a tricky word here, and could use some added definition. I have done the following: OLD: ...or the UAs have exchanged media using the new parameters NEW: ...or the UA have sent or received media using the new parameters > A UA can know if it has *sent* media, and it can know if it has > *received* media. If media has been received (and can be distinguished > from the media that would have been received had the change not > occurred) then that UA knows media has been exchanged. But it doesn't > know if the other UA knows media has been exchanged. We want both sides > to reach the same conclusion regarding the exchange of media, but I'm > not sure how to assure that. You cannot do this in a simple way. For RTP over UDP media, you would need to look at the RTCP information. For TCP media, you would need to look into the TCP data (unless the media stream itself provided some type of acks). So, I think this is the best we can do without adding a level of complexity that nobody would really implement just to resolve corner cases. > So, from the perspective of one of the UAs, how do you propose that this > decision be made? Is it just "I have received media according to the new > sdp"? I have received or sent media (or both) using the new sdp. > What about cases where no media is expected to be exchanged as a result > of the new O/A? E.g. Suppose the change was simply from "a=sendrecv" to > "a=inactive". Is the absence of packets for some period of time evidence > that this is in effect? To cover all these cases, the UAs can perform a new offer/answer exchange without preconditions, as described in that section. That is the more general way to indicate that the session parameters are in use. > > 3.4: > > nit: > > and the session parameters in the offer/answer exchange SHOULD be as > close as those in the pre-re-INVITE state as possible. > > s/close as those/close to those/ Fixed. > > 4.4: > > If the UA receives a reliable provisional response or a 2xx response > to the target-refresh request, or the UA receives a request on the > new local target, the remote UA has updated its remote target. The > UA can consider the target refresh operation completed. > > It isn't sufficient to receive a request on the new target - it must be > a request *within the dialog. (It might receive an out of dialog request > from another source, or otherwise unrelated.) (This is covered in 4.6, > but good to catch it here too.) So I suggest: > > If the UAC receives a reliable provisional response or a 2xx response > to the target-refresh request, or the UAC receives an in-dialog > request on the new target, the UAS has updated its remote target. > The UAC can consider the target refresh operation completed. Fixed. > > 4.6: > > nit: > s/ n-dialog/ in-dialog/ Fixed. > > In the note discussing reliable provisional responses, it might be good > to reference RFC 4320 that says they MUST NOT be used for non-invite > transactions. I have added a reference to RFC 4320. Thanks, Gonzalo From gao.yang2@zte.com.cn Thu Jul 22 00:37:04 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 51CF43A68A2 for ; Thu, 22 Jul 2010 00:37:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.71 X-Spam-Level: X-Spam-Status: No, score=-99.71 tagged_above=-999 required=5 tests=[AWL=2.128, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 f7Tm+aU8np+H for ; Thu, 22 Jul 2010 00:37:02 -0700 (PDT) Received: from mx5.zte.com.cn (mx5.zte.com.cn [63.217.80.70]) by core3.amsl.com (Postfix) with ESMTP id 3DCB03A63C9 for ; Thu, 22 Jul 2010 00:37:01 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 205951727820181; Thu, 22 Jul 2010 15:36:25 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 83990.4786316380; Thu, 22 Jul 2010 15:37:16 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o6M7afw9024492; Thu, 22 Jul 2010 15:36:47 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4C47EFAD.6080204@ericsson.com> To: Gonzalo Camarillo MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 22 Jul 2010 15:33:07 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-22 15:36:36, Serialize complete at 2010-07-22 15:36:36 Content-Type: multipart/alternative; boundary="=_alternative 0029B91248257768_=" X-MAIL: mse2.zte.com.cn o6M7afw9024492 Cc: SIPCORE Subject: Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 22 Jul 2010 07:37:04 -0000 This is a multipart message in MIME format. --=_alternative 0029B91248257768_= Content-Type: text/plain; charset="US-ASCII" Hi Gonzalo, > > 3.3: > > > > A change to the session state is considered to have been executed if > > an offer/answer without preconditions [RFC4032] for the stream has > > completed successfully or the UAs have exchanged media using the new > > > > "exchanged" is a tricky word here, and could use some added definition. > > I have done the following: > > OLD: > ...or the UAs have exchanged media using the new parameters > > NEW: > ...or the UA have sent or received media using the new parameters > > > > A UA can know if it has *sent* media, and it can know if it has > > *received* media. If media has been received (and can be distinguished > > from the media that would have been received had the change not > > occurred) then that UA knows media has been exchanged. But it doesn't > > know if the other UA knows media has been exchanged. We want both sides > > to reach the same conclusion regarding the exchange of media, but I'm > > not sure how to assure that. > > You cannot do this in a simple way. For RTP over UDP media, you would > need to look at the RTCP information. For TCP media, you would need to > look into the TCP data (unless the media stream itself provided some > type of acks). So, I think this is the best we can do without adding a > level of complexity that nobody would really implement just to resolve > corner cases. > > > So, from the perspective of one of the UAs, how do you propose that this > > decision be made? Is it just "I have received media according to the new > > sdp"? > > I have received or sent media (or both) using the new sdp. > > > What about cases where no media is expected to be exchanged as a result > > of the new O/A? E.g. Suppose the change was simply from "a=sendrecv" to > > "a=inactive". Is the absence of packets for some period of time evidence > > that this is in effect? > > To cover all these cases, the UAs can perform a new offer/answer > exchange without preconditions, as described in that section. That is > the more general way to indicate that the session parameters are in use. I'd like to check that do you mean only the new(subsequent) O/A exchange with out precondition means commitment? as a example: Offer1/Answer1(without precondition), then the Offer2/Answer2 with the same SDP. Only the Offer2/Answer2 means commitment? then, I think the following sentence might not be proper. As this should be a defintion for the new (subsequent) O/A exchange behavior. As indicated above, the successful completion of an offer/answer exchange without preconditions indicates that the new parameters for the media stream are already considered to be in use. Thanks, 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. --=_alternative 0029B91248257768_= Content-Type: text/html; charset="US-ASCII"
Hi Gonzalo,


> > 3.3:
> >
> >     A change to the session state is considered to have been executed if
> >     an offer/answer without preconditions [RFC4032] for the stream has
> >     completed successfully or the UAs have exchanged media using the new
> >
> > "exchanged" is a tricky word here, and could use some added definition.
>
> I have done the following:
>
> OLD:
> ...or the UAs have exchanged media using the new parameters
>
> NEW:
> ...or the UA have sent or received media using the new parameters
>
>
> > A UA can know if it has *sent* media, and it can know if it has
> > *received* media. If media has been received (and can be distinguished
> > from the media that would have been received had the change not
> > occurred) then that UA knows media has been exchanged. But it doesn't
> > know if the other UA knows media has been exchanged. We want both sides
> > to reach the same conclusion regarding the exchange of media, but I'm
> > not sure how to assure that.
>
> You cannot do this in a simple way. For RTP over UDP media, you would
> need to look at the RTCP information. For TCP media, you would need to
> look into the TCP data (unless the media stream itself provided some
> type of acks). So, I think this is the best we can do without adding a
> level of complexity that nobody would really implement just to resolve
> corner cases.
>
> > So, from the perspective of one of the UAs, how do you propose that this
> > decision be made? Is it just "I have received media according to the new
> > sdp"?
>
> I have received or sent media (or both) using the new sdp.
>
> > What about cases where no media is expected to be exchanged as a result
> > of the new O/A?  E.g. Suppose the change was simply from "a=sendrecv" to
> > "a=inactive". Is the absence of packets for some period of time evidence
> > that this is in effect?
>
> To cover all these cases, the UAs can perform a new offer/answer
> exchange without preconditions, as described in that section. That is
> the more general way to indicate that the session parameters are in use.

I'd like to check that do you mean only the new(subsequent) O/A exchange with out precondition means commitment?

as a example:

Offer1/Answer1(without precondition), then the Offer2/Answer2 with the same SDP. Only the Offer2/Answer2 means commitment?

then, I think the following sentence might not be proper. As this should be a defintion for the new (subsequent) O/A exchange behavior.

As indicated above, the successful
   completion of an offer/answer exchange without preconditions
   indicates that the new parameters for the media stream are already
   considered to be in use.

Thanks,

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.
--=_alternative 0029B91248257768_=-- From gonzalo.camarillo@ericsson.com Thu Jul 22 00:57:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B789A3A69DA for ; Thu, 22 Jul 2010 00:57:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.885 X-Spam-Level: X-Spam-Status: No, score=-103.885 tagged_above=-999 required=5 tests=[AWL=-1.286, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6zmeY7jwLgxj for ; Thu, 22 Jul 2010 00:57:29 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 735FD3A63C9 for ; Thu, 22 Jul 2010 00:57:29 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-b1-4c47f9f9d7e7 Received: from esealmw126.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 71.C1.06895.9F9F74C4; Thu, 22 Jul 2010 09:57:45 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.174]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jul 2010 09:57:45 +0200 Received: from [131.160.126.163] ([131.160.126.163]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jul 2010 09:57:45 +0200 Message-ID: <4C47F9F9.3030704@ericsson.com> Date: Thu, 22 Jul 2010 10:57:45 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "gao.yang2@zte.com.cn" References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2010 07:57:45.0457 (UTC) FILETIME=[91D11E10:01CB2973] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 22 Jul 2010 07:57:30 -0000 Hi Gao, the successful completion of any offer/answer exchange without preconditions means commitment. In your example, offer/answer 1 already means commitment. Cheers, Gonzalo On 22/07/2010 10:33 AM, gao.yang2@zte.com.cn wrote: > > Hi Gonzalo, > > >> > 3.3: >> > >> > A change to the session state is considered to have been executed if >> > an offer/answer without preconditions [RFC4032] for the stream has >> > completed successfully or the UAs have exchanged media using the new >> > >> > "exchanged" is a tricky word here, and could use some added definition. >> >> I have done the following: >> >> OLD: >> ...or the UAs have exchanged media using the new parameters >> >> NEW: >> ...or the UA have sent or received media using the new parameters >> >> >> > A UA can know if it has *sent* media, and it can know if it has >> > *received* media. If media has been received (and can be distinguished >> > from the media that would have been received had the change not >> > occurred) then that UA knows media has been exchanged. But it doesn't >> > know if the other UA knows media has been exchanged. We want both sides >> > to reach the same conclusion regarding the exchange of media, but I'm >> > not sure how to assure that. >> >> You cannot do this in a simple way. For RTP over UDP media, you would >> need to look at the RTCP information. For TCP media, you would need to >> look into the TCP data (unless the media stream itself provided some >> type of acks). So, I think this is the best we can do without adding a >> level of complexity that nobody would really implement just to resolve >> corner cases. >> >> > So, from the perspective of one of the UAs, how do you propose that > this >> > decision be made? Is it just "I have received media according to the > new >> > sdp"? >> >> I have received or sent media (or both) using the new sdp. >> >> > What about cases where no media is expected to be exchanged as a result >> > of the new O/A? E.g. Suppose the change was simply from > "a=sendrecv" to >> > "a=inactive". Is the absence of packets for some period of time > evidence >> > that this is in effect? >> >> To cover all these cases, the UAs can perform a new offer/answer >> exchange without preconditions, as described in that section. That is >> the more general way to indicate that the session parameters are in use. > > I'd like to check that do you mean only the new(subsequent) O/A exchange > with out precondition means commitment? > > as a example: > > Offer1/Answer1(without precondition), then the Offer2/Answer2 with the > same SDP. Only the Offer2/Answer2 means commitment? > > then, I think the following sentence might not be proper. As this should > be a defintion for the new (subsequent) O/A exchange behavior. > > As indicated above, the successful > completion of an offer/answer exchange without preconditions > indicates that the new parameters for the media stream are already > considered to be in use. > > Thanks, > > 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. > From gao.yang2@zte.com.cn Thu Jul 22 01:05:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0F3E73A69D7 for ; Thu, 22 Jul 2010 01:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -99.696 X-Spam-Level: X-Spam-Status: No, score=-99.696 tagged_above=-999 required=5 tests=[AWL=2.142, BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 ZWcOniitzI+7 for ; Thu, 22 Jul 2010 01:05:12 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 34CB73A69E5 for ; Thu, 22 Jul 2010 01:05:09 -0700 (PDT) Received: from [10.30.17.99] by mx5.zte.com.cn with surfront esmtp id 35101727820181; Thu, 22 Jul 2010 16:04:32 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.15] with StormMail ESMTP id 83990.4786316380; Thu, 22 Jul 2010 16:05:23 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o6M81HmO067709; Thu, 22 Jul 2010 16:01:17 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4C47F9F9.3030704@ericsson.com> To: Gonzalo Camarillo MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 22 Jul 2010 15:57:39 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-22 16:01:06, Serialize complete at 2010-07-22 16:01:06 Content-Type: multipart/alternative; boundary="=_alternative 002BF82648257768_=" X-MAIL: mse2.zte.com.cn o6M81HmO067709 Cc: SIPCORE Subject: Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 22 Jul 2010 08:05:13 -0000 This is a multipart message in MIME format. --=_alternative 002BF82648257768_= Content-Type: text/plain; charset="US-ASCII" Gonzalo, > the successful completion of any offer/answer exchange without > preconditions means commitment. In your example, offer/answer 1 already > means commitment. Then, why the RTCP/TCP checked is needed for O/A without precondition? It puzzles me. Thanks, 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. --=_alternative 002BF82648257768_= Content-Type: text/html; charset="US-ASCII"
Gonzalo,

> the successful completion of any offer/answer exchange without
> preconditions means commitment. In your example, offer/answer 1 already
> means commitment.
Then, why the RTCP/TCP checked is needed for O/A without precondition?
It puzzles me.

Thanks,

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.
--=_alternative 002BF82648257768_=-- From gonzalo.camarillo@ericsson.com Thu Jul 22 01:13:35 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 77A103A677C for ; Thu, 22 Jul 2010 01:13:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.867 X-Spam-Level: X-Spam-Status: No, score=-105.867 tagged_above=-999 required=5 tests=[AWL=0.732, 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 KWb554RAPHh1 for ; Thu, 22 Jul 2010 01:13:34 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id D55B03A63D3 for ; Thu, 22 Jul 2010 01:13:33 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-ec-4c47fdbdbb01 Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id D3.34.10125.DBDF74C4; Thu, 22 Jul 2010 10:13:49 +0200 (CEST) Received: from esealmw127.eemea.ericsson.se ([153.88.254.171]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jul 2010 10:13:49 +0200 Received: from [131.160.126.163] ([131.160.126.163]) by esealmw127.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jul 2010 10:13:49 +0200 Message-ID: <4C47FDBC.3060304@ericsson.com> Date: Thu, 22 Jul 2010 11:13:48 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "gao.yang2@zte.com.cn" References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2010 08:13:49.0249 (UTC) FILETIME=[D0481B10:01CB2975] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 22 Jul 2010 08:13:35 -0000 Hi Gao, you do not need the media check if you have had an offer/answer exchange without preconditions. The sentence in the draft has an "or" separating those two conditions. Cheers, Gonzalo On 22/07/2010 10:57 AM, gao.yang2@zte.com.cn wrote: > > Gonzalo, > >> the successful completion of any offer/answer exchange without >> preconditions means commitment. In your example, offer/answer 1 already >> means commitment. > > Then, why the RTCP/TCP checked is needed for O/A without precondition? > It puzzles me. > > Thanks, > > 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. > From gao.yang2@zte.com.cn Thu Jul 22 03:28:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E4A1C3A6AF3 for ; Thu, 22 Jul 2010 03:28:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.808 X-Spam-Level: X-Spam-Status: No, score=-97.808 tagged_above=-999 required=5 tests=[AWL=-0.173, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_BASE64_TEXT=1.753, MIME_CHARSET_FARAWAY=2.45, 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 eAI4cBMREGjY for ; Thu, 22 Jul 2010 03:28:36 -0700 (PDT) Received: from mx5.zte.com.cn (mx6.zte.com.cn [63.218.89.70]) by core3.amsl.com (Postfix) with ESMTP id 2AEB03A67F0 for ; Thu, 22 Jul 2010 03:28:35 -0700 (PDT) Received: from [10.30.17.100] by mx5.zte.com.cn with surfront esmtp id 35101727820181; Thu, 22 Jul 2010 18:28:10 +0800 (CST) Received: from [10.30.3.19] by [192.168.168.16] with StormMail ESMTP id 75262.2980680612; Thu, 22 Jul 2010 18:20:47 +0800 (CST) Received: from notes_smtp.zte.com.cn ([10.30.1.239]) by mse2.zte.com.cn with ESMTP id o6MASf4P042040; Thu, 22 Jul 2010 18:28:41 +0800 (CST) (envelope-from gao.yang2@zte.com.cn) In-Reply-To: <4C47FDBC.3060304@ericsson.com> To: Gonzalo Camarillo MIME-Version: 1.0 X-Mailer: Lotus Notes Release 7.0.1 January 17, 2006 Message-ID: From: gao.yang2@zte.com.cn Date: Thu, 22 Jul 2010 18:25:00 +0800 X-MIMETrack: Serialize by Router on notes_smtp/zte_ltd(Release 6.5.4|March 27, 2005) at 2010-07-22 18:28:27, Serialize complete at 2010-07-22 18:28:27 Content-Type: multipart/alternative; boundary="=_alternative 0039756A48257768_=" X-MAIL: mse2.zte.com.cn o6MASf4P042040 Cc: SIPCORE Subject: Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 22 Jul 2010 10:28:38 -0000 This is a multipart message in MIME format. --=_alternative 0039756A48257768_= Content-Type: text/plain; charset="GB2312" Content-Transfer-Encoding: base64 SGkgR29uemFsbywNCg0KSSBhbSBnbGFkIHRvIGZpbmQgdGhhdCBpdCdzIHN0aWxsIG15IG9yaWdp YWwgdW5kZXJzdGFuZGluZy4gDQoNClRoZW4sIHRlY2huaWNhbGx5Og0KDQpXaXRob3V0IHByZWNv bmRpdGlvbjogY29tcGxldGlvbiBvZiBPL0EgYXMgY29tbWl0bWVudCBvciBVQSBoYXZlIHNlbnQg b3IgDQpyZWNlaXZlZCBtZWRpYSB1c2luZyB0aGUgbmV3IHBhcmFtZXRlcnMuDQoNCldpdGggcHJl Y29uZGl0b246IFVBUyBzZW5kIG1lZGlhL1JUQ1AvVENQIGFzIGNvbW1pdG1lbnQgb3IgYSBuZXcg Ty9BIA0Kd2l0aG91dCBwcmVjb25kaXRvbihpbiBzb21lIGNhc2VzLCBJIHRoaW5rIGEgbmV3IE8v QSBpcyBuZWNlc3NhcnksIGFzIHNvbWUgDQpwYXJhbWV0ZXJzIG1vZGlmaWNhdGlvbiBjYW4gbm90 IGJlIGNoZWNrZWQgZnJvbSBSVENQL1RDUCkuDQoNCkknZCBsaWtlIHRvIGRvdWJsZSBjaGVjayBm b3IgbXkgdW5kZXJzdGFuZGluZyBmcm9tIHlvdSwgaXMgaXQgcmlnaHQ/DQoNClRoYW5rcywNCg0K R2FvDQoNCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09DQogWmlwICAgIDogMjEw MDEyDQogVGVsICAgIDogODcyMTENCiBUZWwyICAgOigrODYpLTAyNS01Mjg3NzIxMQ0KIGVfbWFp bCA6IGdhby55YW5nMkB6dGUuY29tLmNuDQo9PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PQ0KDQoNCg0KR29uemFsbyBDYW1hcmlsbG8gPEdvbnphbG8uQ2FtYXJpbGxvQGVyaWNzc29u LmNvbT4gDQq3orz+yMs6ICBzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcNCjIwMTAtMDctMjIgMTY6 MTMNCg0KytW8/sjLDQoiZ2FvLnlhbmcyQHp0ZS5jb20uY24iIDxnYW8ueWFuZzJAenRlLmNvbS5j bj4NCrOty80NClNJUENPUkUgPHNpcGNvcmVAaWV0Zi5vcmc+DQrW98ziDQpSZTogW3NpcGNvcmVd IERpYWxvZyBzdGF0ZSAtIFNjb3BlIGluIGRyYWZ0LWlldGYtc2lwY29yZS1yZWludml0ZQ0KDQoN Cg0KDQoNCg0KSGkgR2FvLA0KDQp5b3UgZG8gbm90IG5lZWQgdGhlIG1lZGlhIGNoZWNrIGlmIHlv dSBoYXZlIGhhZCBhbiBvZmZlci9hbnN3ZXIgZXhjaGFuZ2UNCndpdGhvdXQgcHJlY29uZGl0aW9u cy4gVGhlIHNlbnRlbmNlIGluIHRoZSBkcmFmdCBoYXMgYW4gIm9yIiBzZXBhcmF0aW5nDQp0aG9z ZSB0d28gY29uZGl0aW9ucy4NCg0KQ2hlZXJzLA0KDQpHb256YWxvDQoNCk9uIDIyLzA3LzIwMTAg MTA6NTcgQU0sIGdhby55YW5nMkB6dGUuY29tLmNuIHdyb3RlOg0KPiANCj4gR29uemFsbywNCj4g DQo+PiB0aGUgc3VjY2Vzc2Z1bCBjb21wbGV0aW9uIG9mIGFueSBvZmZlci9hbnN3ZXIgZXhjaGFu Z2Ugd2l0aG91dA0KPj4gcHJlY29uZGl0aW9ucyBtZWFucyBjb21taXRtZW50LiBJbiB5b3VyIGV4 YW1wbGUsIG9mZmVyL2Fuc3dlciAxIGFscmVhZHkNCj4+IG1lYW5zIGNvbW1pdG1lbnQuDQo+IA0K PiBUaGVuLCB3aHkgdGhlIFJUQ1AvVENQIGNoZWNrZWQgaXMgbmVlZGVkIGZvciBPL0Egd2l0aG91 dCBwcmVjb25kaXRpb24/DQo+IEl0IHB1enpsZXMgbWUuDQo+IA0KPiBUaGFua3MsDQo+IA0KPiBH YW8NCj4gDQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tDQo+IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBpbmZvcm1h dGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIA0KaXMgc29sZWx5IHByb3BlcnR5IG9mIHRoZSBz ZW5kZXIncyBvcmdhbml6YXRpb24uIFRoaXMgbWFpbCBjb21tdW5pY2F0aW9uIA0KaXMgY29uZmlk ZW50aWFsLiBSZWNpcGllbnRzIG5hbWVkIGFib3ZlIGFyZSBvYmxpZ2F0ZWQgdG8gbWFpbnRhaW4g c2VjcmVjeSANCmFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMg b2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIA0Kb3RoZXJzLg0KPiBUaGlzIGVtYWlsIGFuZCBhbnkg ZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCANCmludGVuZGVk IHNvbGVseSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0 aGV5IGFyZSANCmFkZHJlc3NlZC4gSWYgeW91IGhhdmUgcmVjZWl2ZWQgdGhpcyBlbWFpbCBpbiBl cnJvciBwbGVhc2Ugbm90aWZ5IHRoZSANCm9yaWdpbmF0b3Igb2YgdGhlIG1lc3NhZ2UuIEFueSB2 aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSANCm9mIHRoZSBpbmRpdmlk dWFsIHNlbmRlci4NCj4gVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQgZm9yIHZpcnVzZXMg YW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbSANCnN5c3RlbS4NCj4gDQoNCl9fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0K c2lwY29yZUBpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z aXBjb3JlDQoNCg0KDQoNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0NClpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcyBtYWlsIGlzIHNvbGVseSBwcm9wZXJ0eSBvZiB0 aGUgc2VuZGVyJ3Mgb3JnYW5pemF0aW9uLiBUaGlzIG1haWwgY29tbXVuaWNhdGlvbiBpcyBjb25m aWRlbnRpYWwuIFJlY2lwaWVudHMgbmFtZWQgYWJvdmUgYXJlIG9ibGlnYXRlZCB0byBtYWludGFp biBzZWNyZWN5IGFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVudHMg b2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvIG90aGVycy4NClRoaXMgZW1haWwgYW5kIGFueSBmaWxl cyB0cmFuc21pdHRlZCB3aXRoIGl0IGFyZSBjb25maWRlbnRpYWwgYW5kIGludGVuZGVkIHNvbGVs eSBmb3IgdGhlIHVzZSBvZiB0aGUgaW5kaXZpZHVhbCBvciBlbnRpdHkgdG8gd2hvbSB0aGV5IGFy ZSBhZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1haWwgaW4gZXJyb3IgcGxl YXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvciBvZiB0aGUgbWVzc2FnZS4gQW55IHZpZXdzIGV4cHJl c3NlZCBpbiB0aGlzIG1lc3NhZ2UgYXJlIHRob3NlIG9mIHRoZSBpbmRpdmlkdWFsIHNlbmRlci4N ClRoaXMgbWVzc2FnZSBoYXMgYmVlbiBzY2FubmVkIGZvciB2aXJ1c2VzIGFuZCBTcGFtIGJ5IFpU RSBBbnRpLVNwYW0gc3lzdGVtLg0K --=_alternative 0039756A48257768_= Content-Type: text/html; charset="GB2312" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhpIEdvbnphbG8sPC9mb250Pg0K PGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JIGFtIGdsYWQgdG8gZmlu ZCB0aGF0IGl0J3Mgc3RpbGwgbXkNCm9yaWdpYWwgdW5kZXJzdGFuZGluZy4gPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5UaGVuLCB0ZWNobmljYWxseTo8 L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPldpdGhvdXQg cHJlY29uZGl0aW9uOiBjb21wbGV0aW9uIG9mDQpPL0EgYXMgY29tbWl0bWVudCBvciA8L2ZvbnQ+ PHR0Pjxmb250IHNpemU9Mj5VQSBoYXZlIHNlbnQgb3IgcmVjZWl2ZWQgbWVkaWENCnVzaW5nIHRo ZSBuZXcgcGFyYW1ldGVyczwvZm9udD48L3R0Pjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlm Ij4uPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj5XaXRo IHByZWNvbmRpdG9uOiBVQVMgc2VuZCBtZWRpYS9SVENQL1RDUA0KYXMgY29tbWl0bWVudCBvciBh IG5ldyBPL0Egd2l0aG91dCBwcmVjb25kaXRvbihpbiBzb21lIGNhc2VzLCBJIHRoaW5rIGENCm5l dyBPL0EgaXMgbmVjZXNzYXJ5LCBhcyBzb21lIHBhcmFtZXRlcnMgbW9kaWZpY2F0aW9uIGNhbiBu b3QgYmUgY2hlY2tlZA0KZnJvbSBSVENQL1RDUCkuPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJzYW5zLXNlcmlmIj5JJ2QgbGlrZSB0byBkb3VibGUgY2hlY2sgZm9yIG15IHVu ZGVyc3RhbmRpbmcNCmZyb20geW91LCBpcyBpdCByaWdodD88L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPlRoYW5rcyw8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkdhbzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0ic2Fucy1zZXJpZiI+PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09 PT08YnI+DQogWmlwICZuYnNwOyAmbmJzcDs6IDIxMDAxMjxicj4NCiBUZWwgJm5ic3A7ICZuYnNw OzogODcyMTE8YnI+DQogVGVsMiAmbmJzcDsgOigrODYpLTAyNS01Mjg3NzIxMTxicj4NCiBlX21h aWwgOiBnYW8ueWFuZzJAenRlLmNvbS5jbjxicj4NCj09PT09PT09PT09PT09PT09PT09PT09PT09 PT09PT09PT09PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPHRhYmxlIHdpZHRoPTEwMCU+DQo8 dHIgdmFsaWduPXRvcD4NCjx0ZCB3aWR0aD0zNSU+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2Vy aWYiPjxiPkdvbnphbG8gQ2FtYXJpbGxvICZsdDtHb256YWxvLkNhbWFyaWxsb0Blcmljc3Nvbi5j b20mZ3Q7PC9iPg0KPC9mb250Pg0KPGJyPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj63 orz+yMs6ICZuYnNwO3NpcGNvcmUtYm91bmNlc0BpZXRmLm9yZzwvZm9udD4NCjxwPjxmb250IHNp emU9MSBmYWNlPSJzYW5zLXNlcmlmIj4yMDEwLTA3LTIyIDE2OjEzPC9mb250Pg0KPHRkIHdpZHRo PTY0JT4NCjx0YWJsZSB3aWR0aD0xMDAlPg0KPHRyIHZhbGlnbj10b3A+DQo8dGQ+DQo8ZGl2IGFs aWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlmIj7K1bz+yMs8L2ZvbnQ+PC9k aXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMtc2VyaWYiPiZxdW90O2dhby55YW5nMkB6 dGUuY29tLmNuJnF1b3Q7ICZsdDtnYW8ueWFuZzJAenRlLmNvbS5jbiZndDs8L2ZvbnQ+DQo8dHIg dmFsaWduPXRvcD4NCjx0ZD4NCjxkaXYgYWxpZ249cmlnaHQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNh bnMtc2VyaWYiPrOty808L2ZvbnQ+PC9kaXY+DQo8dGQ+PGZvbnQgc2l6ZT0xIGZhY2U9InNhbnMt c2VyaWYiPlNJUENPUkUgJmx0O3NpcGNvcmVAaWV0Zi5vcmcmZ3Q7PC9mb250Pg0KPHRyIHZhbGln bj10b3A+DQo8dGQ+DQo8ZGl2IGFsaWduPXJpZ2h0Pjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNl cmlmIj7W98ziPC9mb250PjwvZGl2Pg0KPHRkPjxmb250IHNpemU9MSBmYWNlPSJzYW5zLXNlcmlm Ij5SZTogW3NpcGNvcmVdIERpYWxvZyBzdGF0ZSAtIFNjb3BlIGluDQpkcmFmdC1pZXRmLXNpcGNv cmUtcmVpbnZpdGU8L2ZvbnQ+PC90YWJsZT4NCjxicj4NCjx0YWJsZT4NCjx0ciB2YWxpZ249dG9w Pg0KPHRkPg0KPHRkPjwvdGFibGU+DQo8YnI+PC90YWJsZT4NCjxicj4NCjxicj4NCjxicj48dHQ+ PGZvbnQgc2l6ZT0yPkhpIEdhbyw8YnI+DQo8YnI+DQp5b3UgZG8gbm90IG5lZWQgdGhlIG1lZGlh IGNoZWNrIGlmIHlvdSBoYXZlIGhhZCBhbiBvZmZlci9hbnN3ZXIgZXhjaGFuZ2U8YnI+DQp3aXRo b3V0IHByZWNvbmRpdGlvbnMuIFRoZSBzZW50ZW5jZSBpbiB0aGUgZHJhZnQgaGFzIGFuICZxdW90 O29yJnF1b3Q7DQpzZXBhcmF0aW5nPGJyPg0KdGhvc2UgdHdvIGNvbmRpdGlvbnMuPGJyPg0KPGJy Pg0KQ2hlZXJzLDxicj4NCjxicj4NCkdvbnphbG88YnI+DQo8YnI+DQpPbiAyMi8wNy8yMDEwIDEw OjU3IEFNLCBnYW8ueWFuZzJAenRlLmNvbS5jbiB3cm90ZTo8YnI+DQomZ3Q7IDxicj4NCiZndDsg R29uemFsbyw8YnI+DQomZ3Q7IDxicj4NCiZndDsmZ3Q7IHRoZSBzdWNjZXNzZnVsIGNvbXBsZXRp b24gb2YgYW55IG9mZmVyL2Fuc3dlciBleGNoYW5nZSB3aXRob3V0PGJyPg0KJmd0OyZndDsgcHJl Y29uZGl0aW9ucyBtZWFucyBjb21taXRtZW50LiBJbiB5b3VyIGV4YW1wbGUsIG9mZmVyL2Fuc3dl cg0KMSBhbHJlYWR5PGJyPg0KJmd0OyZndDsgbWVhbnMgY29tbWl0bWVudC48YnI+DQomZ3Q7IDxi cj4NCiZndDsgVGhlbiwgd2h5IHRoZSBSVENQL1RDUCBjaGVja2VkIGlzIG5lZWRlZCBmb3IgTy9B IHdpdGhvdXQgcHJlY29uZGl0aW9uPzxicj4NCiZndDsgSXQgcHV6emxlcyBtZS48YnI+DQomZ3Q7 IDxicj4NCiZndDsgVGhhbmtzLDxicj4NCiZndDsgPGJyPg0KJmd0OyBHYW88YnI+DQomZ3Q7IDxi cj4NCiZndDsgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+DQomZ3Q7IFpURSBJbmZvcm1hdGlvbiBTZWN1cml0eSBOb3RpY2U6IFRoZSBp bmZvcm1hdGlvbiBjb250YWluZWQgaW4gdGhpcw0KbWFpbCBpcyBzb2xlbHkgcHJvcGVydHkgb2Yg dGhlIHNlbmRlcidzIG9yZ2FuaXphdGlvbi4gVGhpcyBtYWlsIGNvbW11bmljYXRpb24NCmlzIGNv bmZpZGVudGlhbC4gUmVjaXBpZW50cyBuYW1lZCBhYm92ZSBhcmUgb2JsaWdhdGVkIHRvIG1haW50 YWluIHNlY3JlY3kNCmFuZCBhcmUgbm90IHBlcm1pdHRlZCB0byBkaXNjbG9zZSB0aGUgY29udGVu dHMgb2YgdGhpcyBjb21tdW5pY2F0aW9uIHRvDQpvdGhlcnMuPGJyPg0KJmd0OyBUaGlzIGVtYWls IGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZA0K aW50ZW5kZWQgc29sZWx5IGZvciB0aGUgdXNlIG9mIHRoZSBpbmRpdmlkdWFsIG9yIGVudGl0eSB0 byB3aG9tIHRoZXkgYXJlDQphZGRyZXNzZWQuIElmIHlvdSBoYXZlIHJlY2VpdmVkIHRoaXMgZW1h aWwgaW4gZXJyb3IgcGxlYXNlIG5vdGlmeSB0aGUgb3JpZ2luYXRvcg0Kb2YgdGhlIG1lc3NhZ2Uu IEFueSB2aWV3cyBleHByZXNzZWQgaW4gdGhpcyBtZXNzYWdlIGFyZSB0aG9zZSBvZiB0aGUgaW5k aXZpZHVhbA0Kc2VuZGVyLjxicj4NCiZndDsgVGhpcyBtZXNzYWdlIGhhcyBiZWVuIHNjYW5uZWQg Zm9yIHZpcnVzZXMgYW5kIFNwYW0gYnkgWlRFIEFudGktU3BhbQ0Kc3lzdGVtLjxicj4NCiZndDsg PGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X188YnI+DQpzaXBjb3JlIG1haWxpbmcgbGlzdDxicj4NCnNpcGNvcmVAaWV0Zi5vcmc8YnI+DQpo dHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8YnI+DQo8YnI+DQo8 L2ZvbnQ+PC90dD4NCjxicj4NCjxicj48cHJlPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClpURSZuYnNwO0luZm9ybWF0aW9uJm5ic3A7 U2VjdXJpdHkmbmJzcDtOb3RpY2U6Jm5ic3A7VGhlJm5ic3A7aW5mb3JtYXRpb24mbmJzcDtjb250 YWluZWQmbmJzcDtpbiZuYnNwO3RoaXMmbmJzcDttYWlsJm5ic3A7aXMmbmJzcDtzb2xlbHkmbmJz cDtwcm9wZXJ0eSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7c2VuZGVyJ3MmbmJzcDtvcmdhbml6YXRp b24uJm5ic3A7VGhpcyZuYnNwO21haWwmbmJzcDtjb21tdW5pY2F0aW9uJm5ic3A7aXMmbmJzcDtj b25maWRlbnRpYWwuJm5ic3A7UmVjaXBpZW50cyZuYnNwO25hbWVkJm5ic3A7YWJvdmUmbmJzcDth cmUmbmJzcDtvYmxpZ2F0ZWQmbmJzcDt0byZuYnNwO21haW50YWluJm5ic3A7c2VjcmVjeSZuYnNw O2FuZCZuYnNwO2FyZSZuYnNwO25vdCZuYnNwO3Blcm1pdHRlZCZuYnNwO3RvJm5ic3A7ZGlzY2xv c2UmbmJzcDt0aGUmbmJzcDtjb250ZW50cyZuYnNwO29mJm5ic3A7dGhpcyZuYnNwO2NvbW11bmlj YXRpb24mbmJzcDt0byZuYnNwO290aGVycy4NClRoaXMmbmJzcDtlbWFpbCZuYnNwO2FuZCZuYnNw O2FueSZuYnNwO2ZpbGVzJm5ic3A7dHJhbnNtaXR0ZWQmbmJzcDt3aXRoJm5ic3A7aXQmbmJzcDth cmUmbmJzcDtjb25maWRlbnRpYWwmbmJzcDthbmQmbmJzcDtpbnRlbmRlZCZuYnNwO3NvbGVseSZu YnNwO2ZvciZuYnNwO3RoZSZuYnNwO3VzZSZuYnNwO29mJm5ic3A7dGhlJm5ic3A7aW5kaXZpZHVh bCZuYnNwO29yJm5ic3A7ZW50aXR5Jm5ic3A7dG8mbmJzcDt3aG9tJm5ic3A7dGhleSZuYnNwO2Fy ZSZuYnNwO2FkZHJlc3NlZC4mbmJzcDtJZiZuYnNwO3lvdSZuYnNwO2hhdmUmbmJzcDtyZWNlaXZl ZCZuYnNwO3RoaXMmbmJzcDtlbWFpbCZuYnNwO2luJm5ic3A7ZXJyb3ImbmJzcDtwbGVhc2UmbmJz cDtub3RpZnkmbmJzcDt0aGUmbmJzcDtvcmlnaW5hdG9yJm5ic3A7b2YmbmJzcDt0aGUmbmJzcDtt ZXNzYWdlLiZuYnNwO0FueSZuYnNwO3ZpZXdzJm5ic3A7ZXhwcmVzc2VkJm5ic3A7aW4mbmJzcDt0 aGlzJm5ic3A7bWVzc2FnZSZuYnNwO2FyZSZuYnNwO3Rob3NlJm5ic3A7b2YmbmJzcDt0aGUmbmJz cDtpbmRpdmlkdWFsJm5ic3A7c2VuZGVyLg0KVGhpcyZuYnNwO21lc3NhZ2UmbmJzcDtoYXMmbmJz cDtiZWVuJm5ic3A7c2Nhbm5lZCZuYnNwO2ZvciZuYnNwO3ZpcnVzZXMmbmJzcDthbmQmbmJzcDtT cGFtJm5ic3A7YnkmbmJzcDtaVEUmbmJzcDtBbnRpLVNwYW0mbmJzcDtzeXN0ZW0uDQo8L3ByZT4= --=_alternative 0039756A48257768_=-- From gonzalo.camarillo@ericsson.com Thu Jul 22 05:05:02 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5E0063A6960 for ; Thu, 22 Jul 2010 05:05:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.652 X-Spam-Level: X-Spam-Status: No, score=-104.652 tagged_above=-999 required=5 tests=[AWL=-0.503, BAYES_00=-2.599, MIME_CHARSET_FARAWAY=2.45, 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 ODxM+XPILRGP for ; Thu, 22 Jul 2010 05:05:00 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 838B33A6954 for ; Thu, 22 Jul 2010 05:05:00 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-3d-4c4833fdc694 Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 60.24.10125.DF3384C4; Thu, 22 Jul 2010 14:05:17 +0200 (CEST) Received: from esealmw128.eemea.ericsson.se ([153.88.254.176]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jul 2010 14:05:16 +0200 Received: from [131.160.126.163] ([131.160.126.163]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jul 2010 14:05:16 +0200 Message-ID: <4C4833FC.3090805@ericsson.com> Date: Thu, 22 Jul 2010 15:05:16 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "gao.yang2@zte.com.cn" References: In-Reply-To: X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=GB2312 Content-Transfer-Encoding: 8bit X-OriginalArrivalTime: 22 Jul 2010 12:05:16.0628 (UTC) FILETIME=[25CDF940:01CB2996] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 22 Jul 2010 12:05:02 -0000 Hi Gao, yes, your understanding is correct. Cheers, Gonzalo On 22/07/2010 1:25 PM, gao.yang2@zte.com.cn wrote: > > Hi Gonzalo, > > I am glad to find that it's still my origial understanding. > > Then, technically: > > Without precondition: completion of O/A as commitment or UA have sent or > received media using the new parameters. > > With preconditon: UAS send media/RTCP/TCP as commitment or a new O/A > without preconditon(in some cases, I think a new O/A is necessary, as > some parameters modification can not be checked from RTCP/TCP). > > I'd like to double check for my understanding from you, is it right? > > Thanks, > > Gao > > =================================== > Zip : 210012 > Tel : 87211 > Tel2 :(+86)-025-52877211 > e_mail : gao.yang2@zte.com.cn > =================================== > > > *Gonzalo Camarillo * > ·¢¼þÈË: sipcore-bounces@ietf.org > > 2010-07-22 16:13 > > > ÊÕ¼þÈË > "gao.yang2@zte.com.cn" > ³­ËÍ > SIPCORE > Ö÷Ìâ > Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite > > > > > > > > > Hi Gao, > > you do not need the media check if you have had an offer/answer exchange > without preconditions. The sentence in the draft has an "or" separating > those two conditions. > > Cheers, > > Gonzalo > > On 22/07/2010 10:57 AM, gao.yang2@zte.com.cn wrote: >> >> Gonzalo, >> >>> the successful completion of any offer/answer exchange without >>> preconditions means commitment. In your example, offer/answer 1 already >>> means commitment. >> >> Then, why the RTCP/TCP checked is needed for O/A without precondition? >> It puzzles me. >> >> Thanks, >> >> 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 pkyzivat@cisco.com Thu Jul 22 06:43:30 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9BAAD3A69E8 for ; Thu, 22 Jul 2010 06:43:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.479 X-Spam-Level: X-Spam-Status: No, score=-10.479 tagged_above=-999 required=5 tests=[AWL=0.120, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PMY8-Y29PP7h for ; Thu, 22 Jul 2010 06:43:28 -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 281433A69E3 for ; Thu, 22 Jul 2010 06:43:28 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 22 Jul 2010 13:43:45 +0000 Received: from [10.86.254.210] ([10.86.254.210]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6MDhiHf018770; Thu, 22 Jul 2010 13:43:45 GMT Message-ID: <4C484B10.2000907@cisco.com> Date: Thu, 22 Jul 2010 09:43:44 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "James M. Polk" References: <4C47B6B6.2090009@cisco.com> <201007220329.o6M3TtCI013514@sj-core-1.cisco.com> In-Reply-To: <201007220329.o6M3TtCI013514@sj-core-1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-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: Thu, 22 Jul 2010 13:43:30 -0000 James M. Polk wrote: > At 10:10 PM 7/21/2010, Paul Kyzivat wrote: >> I finally got around to reading this version of the document. >> Most stuff I noticed has already been mentioned and I won't repeat. >> I did notice one thing I haven't seen mentioned before: >> >> Section 4.2 says that a 424 response must not be used if there was no >> Geolocation header in the request. > > This was to prevent exactly the scenario you indicate below (i.e., the > UAC could go belly-up). It might be considered too rigid at the moment > though (the alternative you mention below). > > >> What if the UAC does not understand Geolocation and inserts no >> Geolocation header. However an intermediary (proxy-1) *does * insert a >> Geolocation header. Then a downstream intermediary (proxy-2) takes >> issue with that and returns a 424 response. > > then the UAC will receive the 424 and not have a clue what to do with it > because it cannot correct something it does not understand in the first > place. > > >> ISTM there needs to be a requirement that the intermediary inserting >> the Geolocation header handle any 424 errors that might result from >> it, thus shielding the UAC from those. > > Do you think we can state this? I'm thinking from a purest protocol > pov, that seems to me to break SIP's e2e model of communication, > especially when involving a literal proxy - and not some other form of > SIP intermediary (e.g., b2bua or sbc that are made to do just this). Well, a forking proxy can send a request one place, catch an error response from that and then send the request someplace else. And a proxy can always send an error response of its own construction. I don't see dealing with this case as any different. Proxy 1 could: - catch the 424 error and then resend the request with some different Geolocation - catch the 424 and then send some different error response back to the UAC. > I was always erring on the side of caution here, but you're the big > cheese now ;-) so I'm willing to go with this. Hmm. I don't know if I want to be a "cheese", and whatever kind of cheese I am doesn't really matter here. :-) Thanks, Paul > James > > >> Thanks, >> Paul > > From pkyzivat@cisco.com Thu Jul 22 07:05:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C67363A687F for ; Thu, 22 Jul 2010 07:05:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.499 X-Spam-Level: X-Spam-Status: No, score=-10.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eTllQ57XUQSo for ; Thu, 22 Jul 2010 07:05:51 -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 EA12B3A69F3 for ; Thu, 22 Jul 2010 07:05:49 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAKztR0xAZnwM/2dsb2JhbACfd3GmTpsfhTYEiFk Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 22 Jul 2010 14:06:02 +0000 Received: from [10.86.254.210] ([10.86.254.210]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6ME62mD005483; Thu, 22 Jul 2010 14:06:02 GMT Message-ID: <4C48504A.7030704@cisco.com> Date: Thu, 22 Jul 2010 10:06:02 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Gonzalo Camarillo References: <4C4740B8.3010401@cisco.com> <4C47EFAD.6080204@ericsson.com> In-Reply-To: <4C47EFAD.6080204@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 22 Jul 2010 14:05:52 -0000 Gonzalo Camarillo wrote: > Hi Paul, > > thanks for your comments. Answers inline: I think this is good. Just one more nit: > OLD: > ...or the UAs have exchanged media using the new parameters > > NEW: > ...or the UA have sent or received media using the new parameters s/UA have sent/UA has sent/ Thanks, Paul From gonzalo.camarillo@ericsson.com Thu Jul 22 07:07:37 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3AEE43A69F7 for ; Thu, 22 Jul 2010 07:07:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.87 X-Spam-Level: X-Spam-Status: No, score=-103.87 tagged_above=-999 required=5 tests=[AWL=-1.271, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zEnuHIdojbZO for ; Thu, 22 Jul 2010 07:07:35 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 1CA1E3A6A92 for ; Thu, 22 Jul 2010 07:07:34 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-8b-4c4850b7123f Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 0E.32.06895.7B0584C4; Thu, 22 Jul 2010 16:07:51 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jul 2010 16:07:50 +0200 Received: from [131.160.126.163] ([131.160.126.163]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Thu, 22 Jul 2010 16:07:50 +0200 Message-ID: <4C4850B7.9070702@ericsson.com> Date: Thu, 22 Jul 2010 17:07:51 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: Paul Kyzivat References: <4C4740B8.3010401@cisco.com> <4C47EFAD.6080204@ericsson.com> <4C48504A.7030704@cisco.com> In-Reply-To: <4C48504A.7030704@cisco.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 22 Jul 2010 14:07:50.0416 (UTC) FILETIME=[4500F900:01CB29A7] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 22 Jul 2010 14:07:37 -0000 Hi Paul, I have also fixed the nit you spotted below. Thanks, Gonzalo On 22/07/2010 5:06 PM, Paul Kyzivat wrote: > > > Gonzalo Camarillo wrote: >> Hi Paul, >> >> thanks for your comments. Answers inline: > > I think this is good. Just one more nit: > >> OLD: >> ...or the UAs have exchanged media using the new parameters >> >> NEW: >> ...or the UA have sent or received media using the new parameters > > s/UA have sent/UA has sent/ > > Thanks, > Paul From pkyzivat@cisco.com Thu Jul 22 09:44:16 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 058D53A6989 for ; Thu, 22 Jul 2010 09:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.524 X-Spam-Level: X-Spam-Status: No, score=-10.524 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GfvLbUKY2RtW for ; Thu, 22 Jul 2010 09:44:15 -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 D34843A6887 for ; Thu, 22 Jul 2010 09:44:14 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEALYRSExAZnwN/2dsb2JhbACfcnGmaZskhTYEiFk Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 22 Jul 2010 16:44:32 +0000 Received: from [10.86.254.210] ([10.86.254.210]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6MGiVIv005468; Thu, 22 Jul 2010 16:44:31 GMT Message-ID: <4C48756F.1020509@cisco.com> Date: Thu, 22 Jul 2010 12:44:31 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: [sipcore] draft-ietf-sipcore-keep-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 22 Jul 2010 16:44:16 -0000 Christer, I finally got around to reading the keep draftfor the first time in quite awhile. I have a few comments and questions: IMO the usage of "upstream" and "downstream" (which is ubiquitous) is confusing, because its not evident which is the high ground and which is the low ground. Normally for SIP I would assume that the sender of a request is on the high ground, with the request flowing *downstream* toward the recipient, and the response flowing *upstream* toward the sender of the request. But most of the text in this draft assumes the opposite. Perhaps this stems from a view that the "device" is on the low ground and the registrar is on the high ground. But then 4.1 further complicates this: NOTE: Usage of keep-alives is negotiated per direction. If a SIP entity has indicated willingness to receive keep-alives from its adjacent downstream SIP entity, sending of keep-alives towards the same SIP entity needs to be separately negotiated. If that negotiation were performed following the procedures in this draft then the upstream and dowstream roles would be reversed. Section 4.2.2: IIUC, the keepalive is associated with a flow as defined in 5626. Hence it isn't appropriate to use this negotiation mechanism on a registration that doesn't specify a flow. I don't see that stated anywhere. (If there was no flow, what would the keepalive state be associated *with*?) Section 4.2.3: Is there a reason *why* you can't renegotiate the dialog to eliminate the use of keepalives? (session timers are a similar concept, and they are renegotiated on/off with every reINVITE/UPDATE.) (Maybe there is a good reason - I just don't see it.) Section 4.3: The following: When a SIP entity is about to send a keep-alive, if the SIP entity at the same time is also about to send or forward a SIP request associated with the same registration or dialog, for which the keep- alive is to be sent, the SIP entity MAY choose not to send the keep- alive, as the SIP request will perform the same keep-alive action. seems pretty imprecise. Wouldn't it be more precise to state that every request sent resets the clock for when a keep-alive needs to be sent? Also, while this skipping of the explicit keep-alive makes sense to me, AFAICT it isn't consistent with -outbound-. Section 5: The following has me totally confused: SIP Outbound uses the Flow-Timer header field to indicate the server- recommended keep-alive frequency. However, it will only be sent between a UA and an edge proxy. Using the "keep" parameter, however, the sending and receiving of keep-alives might be negotiated between multiple entities on the signalling path. Since the server- recommended keep-alive frequency might vary between different SIP entities, those would have to re-write the Flow-Timer header field value. In addition, if a SIP entity does not indicate willingness to receive keep-alives from its adjacent downstream SIP entity, and receives a Flow-Timer header field in a response, it would have to remove the Flow-Timer header field from the response. This issue does not exist for the "keep" parameter, as each SIP entity has its own individual Via header field. (There are too many hypotheticals in it.) After reading this, I don't know: - can I use keep in conjunction with an outbound registration? - if so, does this alter the procedures of outbound - requiring some manipulation of the Flow-Timer value? Thanks, Paul From pkyzivat@cisco.com Thu Jul 22 12:25:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id BB63C3A67AC for ; Thu, 22 Jul 2010 12:25:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.539 X-Spam-Level: X-Spam-Status: No, score=-10.539 tagged_above=-999 required=5 tests=[AWL=0.060, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LsRruDC6g7d6 for ; Thu, 22 Jul 2010 12:25:52 -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 D458A3A67A5 for ; Thu, 22 Jul 2010 12:25:51 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAJ84SExAZnwM/2dsb2JhbACfdHGnWpsbhTYEiFk Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 22 Jul 2010 19:26:09 +0000 Received: from [10.86.254.210] ([10.86.254.210]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6MJQ3Xt026166; Thu, 22 Jul 2010 19:26:04 GMT Message-ID: <4C489B4C.2000705@cisco.com> Date: Thu, 22 Jul 2010 15:26:04 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adam Roach Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: [sipcore] draft-ietf-sipcore-rfc3265bis-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: Thu, 22 Jul 2010 19:25:53 -0000 I just got around to a careful read of 3265bis. I only have one question about section 4.1.2.4: If a subscriber is only interested in one resultant dialog, is it valid to return 481 for any NOTIFYs that arrive after the first? (That will permit it to drop state of the pending subscription without waiting for Timer N to expire.) Thanks, Paul From acooper@cdt.org Thu Jul 22 12:49:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 838173A684A for ; Thu, 22 Jul 2010 12:49:59 -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.180, 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 zGeFSXt3qNEM for ; Thu, 22 Jul 2010 12:49:58 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 3D2D13A6846 for ; Thu, 22 Jul 2010 12:49:58 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)) for sipcore@ietf.org; Thu, 22 Jul 2010 15:50:10 -0400 Message-Id: From: Alissa Cooper 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 v936) Date: Thu, 22 Jul 2010 20:50:06 +0100 X-Mailer: Apple Mail (2.936) Subject: [sipcore] Bad Location Information in draft-ietf-sipcore-location-conveyance-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: Thu, 22 Jul 2010 19:49:59 -0000 Section 4.2 of draft-ietf-sipcore-location-conveyance-03 says: A SIP intermediary can also reject a location it receives from a Target when it understands the Target to be in a different location. The proper handling of this scenario is for the SIP intermediary to include the proper location in the 424 Response. This SHOULD be included in the response as a MIME message body (i.e., a location value), rather than as a URI; however, in cases where the intermediary is willing to share location with recipients but not with a user agent, a reference might be necessary. Does this leave the Target's ability to spoof its location up to the discretion of the SIP intermediary? Thanks, Alissa From jmpolk@cisco.com Thu Jul 22 14:08:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F30CC3A6998 for ; Thu, 22 Jul 2010 14:08:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.315 X-Spam-Level: X-Spam-Status: No, score=-10.315 tagged_above=-999 required=5 tests=[AWL=0.284, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCyx9BZfcD9S for ; Thu, 22 Jul 2010 14:08:57 -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 835A93A6968 for ; Thu, 22 Jul 2010 14:08:57 -0700 (PDT) Authentication-Results: sj-iport-6.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAEtQSEyrRN+J/2dsb2JhbACfdHGnbpsehTYEhAA Received: from sj-core-3.cisco.com ([171.68.223.137]) by sj-iport-6.cisco.com with ESMTP; 22 Jul 2010 21:09:14 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by sj-core-3.cisco.com (8.13.8/8.14.3) with ESMTP id o6ML9EXv011843; Thu, 22 Jul 2010 21:09:14 GMT Message-Id: <201007222109.o6ML9EXv011843@sj-core-3.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 22 Jul 2010 16:09:13 -0500 To: Alissa Cooper , sipcore@ietf.org From: "James M. Polk" In-Reply-To: References: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] Bad Location Information in draft-ietf-sipcore-location-conveyance-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: Thu, 22 Jul 2010 21:08:59 -0000 At 02:50 PM 7/22/2010, Alissa Cooper wrote: >Section 4.2 of draft-ietf-sipcore-location-conveyance-03 says: > > A SIP intermediary can also reject a location it receives from a > Target when it understands the Target to be in a different location. > The proper handling of this scenario is for the SIP intermediary to > include the proper location in the 424 Response. This SHOULD be > included in the response as a MIME message body (i.e., a location > value), rather than as a URI; however, in cases where the > intermediary is willing to share location with recipients but not > with a user agent, a reference might be necessary. > >Does this leave the Target's ability to spoof its location up to the >discretion of the SIP intermediary? Alissa - I'm not 100% I understand the direction of your question - but here is my first try. If you're asking that an intermediary *can* prevent a Target from lying, the answer is yes. why is this prevented? Because the intermediary could be literally standing in the way of this message's progressing further into the network towards the destination, and believes (not consciously of course) that it knows better where the Target is than what is in the SIP request. The intermediary has a couple of alternatives: - it could send a 424 response with the only location it will accept in a subsequent SIP request from that Target, or - it could compose a dual location PIDF and return it to the Target to have it send in the subsequent SIP request, or - it could overwrite the existing location, unbeknownst to the Target, and deliver that to the destination UAS. The work around is to not have that intermediary in the signaling path in any subsequent SIP request - but only works *if* the Target learns that the intermediary is doing this in the first place, which wouldn't be the case (easily) if the intermediary is just overwriting the Target's location. I don't see any other way around this. If we state that this MUST NOT happen, that'll fly in the face of what IMS is defining where "UEs (i.e., UACs) aren't to be trusted with this kind of information", as just one example. Did I get your question right (even if you did or did not like the answer)? James >Thanks, >Alissa > > > > > > > > > > > > > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From rbarnes@bbn.com Thu Jul 22 16:30:48 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E1B63A6A99 for ; Thu, 22 Jul 2010 16:30:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, 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 MLQlUxJ507Wq for ; Thu, 22 Jul 2010 16:30:42 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id B84C23A6A9B for ; Thu, 22 Jul 2010 16:30:24 -0700 (PDT) Received: from [128.89.252.227] (port=53109 helo=[192.168.1.43]) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1Oc5Df-000Hs7-W6; Thu, 22 Jul 2010 19:30:28 -0400 Message-Id: From: "Richard L. Barnes" To: Alissa Cooper 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 v936) Date: Thu, 22 Jul 2010 19:30:26 -0400 References: X-Mailer: Apple Mail (2.936) Cc: sipcore@ietf.org Subject: Re: [sipcore] Bad Location Information in draft-ietf-sipcore-location-conveyance-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: Thu, 22 Jul 2010 23:30:48 -0000 Like James notes, intermediaries have always had the power to block any request they please (e.g., with the 401 Unauthorized header). In the case of location, the concern you note is just one more motivation for proxies to keep their hands off my INVITE; I don't think there's a technical solution. On Jul 22, 2010, at 3:50 PM, Alissa Cooper wrote: > Section 4.2 of draft-ietf-sipcore-location-conveyance-03 says: > > A SIP intermediary can also reject a location it receives from a > Target when it understands the Target to be in a different location. > The proper handling of this scenario is for the SIP intermediary to > include the proper location in the 424 Response. This SHOULD be > included in the response as a MIME message body (i.e., a location > value), rather than as a URI; however, in cases where the > intermediary is willing to share location with recipients but not > with a user agent, a reference might be necessary. > > Does this leave the Target's ability to spoof its location up to the > discretion of the SIP intermediary? > > Thanks, > Alissa > > > > > > > > > > > > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From Martin.Thomson@andrew.com Thu Jul 22 17:13:54 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1C9F43A695F for ; Thu, 22 Jul 2010 17:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=-0.850, 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 15FId35nrBiR for ; Thu, 22 Jul 2010 17:13:53 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id EF2313A6A03 for ; Thu, 22 Jul 2010 17:13:51 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:35336 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S342205Ab0GWAOJ (ORCPT ); Thu, 22 Jul 2010 19:14:09 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 22 Jul 2010 19:14:09 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Fri, 23 Jul 2010 08:14:05 +0800 From: "Thomson, Martin" To: Paul Kyzivat , "James M. Polk" Date: Fri, 23 Jul 2010 08:14:04 +0800 Thread-Topic: [sipcore] draft-ietf-sipcore-location-conveyance-03 Thread-Index: Acspo+08pJMmoXskShuqBN3q0CjTtwAU3ixg Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB828B8D@SISPE7MB1.commscope.com> References: <4C47B6B6.2090009@cisco.com> <201007220329.o6M3TtCI013514@sj-core-1.cisco.com> <4C484B10.2000907@cisco.com> In-Reply-To: <4C484B10.2000907@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="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-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: Fri, 23 Jul 2010 00:13:54 -0000 PiA+PiBJU1RNIHRoZXJlIG5lZWRzIHRvIGJlIGEgcmVxdWlyZW1lbnQgdGhhdCB0aGUgaW50ZXJt ZWRpYXJ5IGluc2VydGluZw0KPiA+PiB0aGUgR2VvbG9jYXRpb24gaGVhZGVyIGhhbmRsZSBhbnkg NDI0IGVycm9ycyB0aGF0IG1pZ2h0IHJlc3VsdCBmcm9tDQo+ID4+IGl0LCB0aHVzIHNoaWVsZGlu ZyB0aGUgVUFDIGZyb20gdGhvc2UuDQo+ID4NCj4gPiBEbyB5b3UgdGhpbmsgd2UgY2FuIHN0YXRl IHRoaXM/ICBJJ20gdGhpbmtpbmcgZnJvbSBhIHB1cmVzdCBwcm90b2NvbA0KPiA+IHBvdiwgdGhh dCBzZWVtcyB0byBtZSB0byBicmVhayBTSVAncyBlMmUgbW9kZWwgb2YgY29tbXVuaWNhdGlvbiwN Cj4gPiBlc3BlY2lhbGx5IHdoZW4gaW52b2x2aW5nIGEgbGl0ZXJhbCBwcm94eSAtIGFuZCBub3Qg c29tZSBvdGhlciBmb3JtDQo+IG9mDQo+ID4gU0lQIGludGVybWVkaWFyeSAoZS5nLiwgYjJidWEg b3Igc2JjIHRoYXQgYXJlIG1hZGUgdG8gZG8ganVzdCB0aGlzKS4NCg0KTm8gaGFybSBpbiBtYWtp bmcgYSBzdGF0ZW1lbnQgYWJvdXQgdGhpcy4gIE9mIGNvdXJzZSwgdGhpcyBzb3J0IG9mIGJlaGF2 aW91ciBjb3VsZCBzaW1wbHkgYmUgaW1wbGllZC4gIElmIHRoZSBpbnRlcm1lZGlhcnkgaXMgYWN0 aW5nIGFzIGEgQjJCVUEsIHdoZW4gaXQgYWRkcyBhIGZlYXR1cmUsIGl0IGNhbiAoYW5kIHNob3Vs ZCkgYWJzb3JiIHRoZSBjb25zZXF1ZW5jZXMgb2YgdGhhdC4gIEZvciBnZW9sb2NhdGlvbiwgaWYg aXQgYWRkcyB0aGUgaGVhZGVyLCBpdCBtdXN0IGJlIHByZXBhcmVkIGZvciB0aGUgY29uc2VxdWVu Y2VzIG9mIHRoYXQgKDQyNCkuDQoNCkknbGwgbGVhdmUgaXQgdG8gdGhlIGRpc2NyZXRpb24gb2Yg dGhlIGVkaXRvcnMgaG93IG11Y2ggdGhleSB3YW50IHRvIGRhbmNlIGFyb3VuZCB0aGUgc2Vuc2l0 aXZpdGllcy4gIEJ1dCB5b3UgY291bGQganVzdCBzYXk6DQoNCkFuIGludGVybWVkaWFyeSB0aGF0 IGFkZHMgYSBnZW9sb2NhdGlvbiBoZWFkZXIgTVVTVCBiZSBwcmVwYXJlZCB0byBoYW5kbGUgYW55 IGVycm9ycyB0aGF0IHRoaXMgbWlnaHQgcmVzdWx0IGluLCBpbmNsdWRpbmcgYSA0MjQgcmVzcG9u c2UuICBUaGUgaW50ZXJtZWRpYXJ5IG1pZ2h0IHRoZW4gdHJhbnNsYXRlIHRoaXMgZXJyb3IgaW50 byBhbiBlcnJvciB0aGF0IHRoZSBVQUMgaXMga25vd24gdG8gc3VwcG9ydCwgb3IuLi4NCg== From James.Winterbottom@andrew.com Thu Jul 22 17:43:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B74913A68F0 for ; Thu, 22 Jul 2010 17:43:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.699 X-Spam-Level: X-Spam-Status: No, score=-3.699 tagged_above=-999 required=5 tests=[AWL=-1.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 vmz3sQOzqJ+A for ; Thu, 22 Jul 2010 17:43:46 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 040753A6A99 for ; Thu, 22 Jul 2010 17:43:45 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:14998 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S342412Ab0GWAoC convert rfc822-to-8bit (ORCPT ); Thu, 22 Jul 2010 19:44:02 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 22 Jul 2010 19:44:02 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 23 Jul 2010 08:44:00 +0800 From: "Winterbottom, James" To: "Thomson, Martin" , Paul Kyzivat , "James M. Polk" Date: Fri, 23 Jul 2010 08:43:59 +0800 Thread-Topic: [sipcore] draft-ietf-sipcore-location-conveyance-03 Thread-Index: Acspo+08pJMmoXskShuqBN3q0CjTtwAU3ixgAAIiadA= Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120E9829833@SISPE7MB1.commscope.com> References: <4C47B6B6.2090009@cisco.com> <201007220329.o6M3TtCI013514@sj-core-1.cisco.com> <4C484B10.2000907@cisco.com> <8B0A9FCBB9832F43971E38010638454F03EB828B8D@SISPE7MB1.commscope.com> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03EB828B8D@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-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: Fri, 23 Jul 2010 00:43:52 -0000 This may be ignorance on my part, but I am going to assume that this is not the first new header added to the SIP since RFC3261, and so it is also not the first case where an error might come back from about a header that has been inserted along the way. What happens in these other cases? Cheers James > -----Original Message----- > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf > Of Thomson, Martin > Sent: Friday, 23 July 2010 10:14 AM > To: Paul Kyzivat; James M. Polk > Cc: SIPCORE > Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-03 > > > >> ISTM there needs to be a requirement that the intermediary inserting > > >> the Geolocation header handle any 424 errors that might result from > > >> it, thus shielding the UAC from those. > > > > > > Do you think we can state this? I'm thinking from a purest protocol > > > pov, that seems to me to break SIP's e2e model of communication, > > > especially when involving a literal proxy - and not some other form > > of > > > SIP intermediary (e.g., b2bua or sbc that are made to do just this). > > No harm in making a statement about this. Of course, this sort of > behaviour could simply be implied. If the intermediary is acting as a > B2BUA, when it adds a feature, it can (and should) absorb the consequences > of that. For geolocation, if it adds the header, it must be prepared for > the consequences of that (424). > > I'll leave it to the discretion of the editors how much they want to dance > around the sensitivities. But you could just say: > > An intermediary that adds a geolocation header MUST be prepared to handle > any errors that this might result in, including a 424 response. The > intermediary might then translate this error into an error that the UAC is > known to support, or... > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From pkyzivat@cisco.com Thu Jul 22 18:28:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E6A5C3A690A for ; Thu, 22 Jul 2010 18:28:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iqixqzWoTZgs for ; Thu, 22 Jul 2010 18:28:46 -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 E77803A65A5 for ; Thu, 22 Jul 2010 18:28:46 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAP6MSExAaMHG/2dsb2JhbACfZHGmZ5sJhTYEiFk Received: from syd-core-1.cisco.com ([64.104.193.198]) by sj-iport-5.cisco.com with ESMTP; 23 Jul 2010 01:29:03 +0000 Received: from [10.86.253.215] ([10.86.253.215]) by syd-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6N1T1CL010389; Fri, 23 Jul 2010 01:29:02 GMT Message-ID: <4C48F05C.8060307@cisco.com> Date: Thu, 22 Jul 2010 21:29:00 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: Adam Roach , SIPCORE Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sipcore] draft-ietf-martini-gin-05 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 01:28:48 -0000 (Still catching up on my reading) This draft is hanging together very well now. I have a few comments: Section 7.1.2.2: According to RFC5627 (gruu) section 3.2, every registration refresh generates a new temp gruu, with special rules for expiration. Does that apply here too? Or is that changed for bnc registrations? Either way, I think the implications need to be discussed. Section 7.2.1: I think there may be an issue here. Normally RFC5628 (gruu reg event) would apply here, reporting the gruus assigned. (The most recent for the temp gruu.) That could work for the pub-gruu of each implicitly registered number. But it won't work for the temp gruus - the SSP doesn't even know what those are. If there was a record for the "base" AOR, that could contain the temp-gruu template. But that is currently forbidden. Again, I think something needs to be said about this, whatever way it should work. One thing to keep in mind is that management of temp gruus can be touchy relative to registration refreshes. If the registration ever expires, even momentarily, then the previously assigned temp gruus become invalid. Only new ones obtained after reregistration are then valid. In the case of the pbx with devices registered to it, that have have been issued "derived" temp gruus, those also become invalid. The only way to be certain this hasn't happened is to subscribe to the reg event package and get gruu reg event info about the temp gruu. But that will only work if the pbx can get temp gruu info from a reg event subscription to the SSP. Sorry to be so tardy in getting this info out. I think I alluded to it earlier, but I don't think I ever provided specifics. Thanks, Paul 7.2.2 There is an out for the SSP to handle the subscriptions if it can keep a complete, accurate and up to date copy of the data, e.g. through a backend subscription.) Its even harder than that, since the pbx could apply an authorization policy to each of those AORs, restricting who can see the info, and how much of it. The SSP couldn't learn that through backend subscriptions unless it maintains a distinct backend subscription for each potential subscriber. In this section gruus again rear their ugly heads. If the pbx supports gruu, then it probably SHOULD support the gruu reg event package and return the appropriate information. From pkyzivat@cisco.com Thu Jul 22 18:40:50 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B391E3A6889 for ; Thu, 22 Jul 2010 18:40:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.544 X-Spam-Level: X-Spam-Status: No, score=-10.544 tagged_above=-999 required=5 tests=[AWL=0.055, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id seZNDiV52RFj for ; Thu, 22 Jul 2010 18:40:49 -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 2D5373A65A5 for ; Thu, 22 Jul 2010 18:40:49 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2010 01:41:06 +0000 Received: from [10.86.253.215] ([10.86.253.215]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6N1f6IM021105; Fri, 23 Jul 2010 01:41:06 GMT Message-ID: <4C48F332.9080500@cisco.com> Date: Thu, 22 Jul 2010 21:41:06 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "DOLLY, MARTIN C (ATTLABS)" References: <14C85D6CCBE92743AF33663BF5D24EBA02BD513A@gaalpa1msgusr7e.ugd.att.com> In-Reply-To: <14C85D6CCBE92743AF33663BF5D24EBA02BD513A@gaalpa1msgusr7e.ugd.att.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Cc: James.Winterbottom@andrew.com, sipcore@ietf.org, Martin.Thomson@andrew.com Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-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: Fri, 23 Jul 2010 01:40:50 -0000 SIP *does* have a compatibility mechanism. If the 424 *does* get back to an unaware UAC, then it will be treated equivalently to a 400. The problem arises if that is an insufficient way of dealing. The design of the 424 response is based on the assumption that the recipient will understand it and make a suitable retry. An unaware UAC won't do that. The words Martin offered seem sufficient to me. If the responsible proxy is satisfied with the consequences of allowing the UAC to get the 424, then that too is ok. It could be left unstated, on the assumption that it will be evident to an informed developer. But in my experience much of the stuff that seems evident to us turns out *not* to be evident to many developers. Thanks, Paul DOLLY, MARTIN C (ATTLABS) wrote: > A good protocol would have a compatibility mechanism...mmm > Martin C. Dolly > Sent to you by AT&T... America's Fastest Mobile Broadband Network. Rethink Possible. > +1.609.903.3360 > > ----- Original Message ----- > From: sipcore-bounces@ietf.org > To: Thomson, Martin ; Paul Kyzivat ; James M. Polk > Cc: SIPCORE > Sent: Thu Jul 22 20:43:59 2010 > Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-03 > > This may be ignorance on my part, but I am going to assume that this is not the first new header added to the SIP since RFC3261, and so it is also not the first case where an error might come back from about a header that has been inserted along the way. > > What happens in these other cases? > > Cheers > James > > > > > >> -----Original Message----- >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf >> Of Thomson, Martin >> Sent: Friday, 23 July 2010 10:14 AM >> To: Paul Kyzivat; James M. Polk >> Cc: SIPCORE >> Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-03 >> >>>>> ISTM there needs to be a requirement that the intermediary inserting >>>>> the Geolocation header handle any 424 errors that might result from >>>>> it, thus shielding the UAC from those. >>>> Do you think we can state this? I'm thinking from a purest protocol >>>> pov, that seems to me to break SIP's e2e model of communication, >>>> especially when involving a literal proxy - and not some other form >>> of >>>> SIP intermediary (e.g., b2bua or sbc that are made to do just this). >> No harm in making a statement about this. Of course, this sort of >> behaviour could simply be implied. If the intermediary is acting as a >> B2BUA, when it adds a feature, it can (and should) absorb the consequences >> of that. For geolocation, if it adds the header, it must be prepared for >> the consequences of that (424). >> >> I'll leave it to the discretion of the editors how much they want to dance >> around the sensitivities. But you could just say: >> >> An intermediary that adds a geolocation header MUST be prepared to handle >> any errors that this might result in, including a 424 response. The >> intermediary might then translate this error into an error that the UAC is >> known to support, or... >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From md3135@att.com Thu Jul 22 18:02:17 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 958713A6A76 for ; Thu, 22 Jul 2010 18:02:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.474 X-Spam-Level: X-Spam-Status: No, score=-106.474 tagged_above=-999 required=5 tests=[AWL=0.125, 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 5I2S3Ox2Rrtl for ; Thu, 22 Jul 2010 18:02:16 -0700 (PDT) Received: from mail120.messagelabs.com (mail120.messagelabs.com [216.82.250.83]) by core3.amsl.com (Postfix) with ESMTP id 550A93A69C6 for ; Thu, 22 Jul 2010 18:02:16 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: md3135@att.com X-Msg-Ref: server-11.tower-120.messagelabs.com!1279846952!50933812!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [144.160.20.146] Received: (qmail 24502 invoked from network); 23 Jul 2010 01:02:33 -0000 Received: from sbcsmtp7.sbc.com (HELO mlpd194.enaf.sfdc.sbc.com) (144.160.20.146) by server-11.tower-120.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Jul 2010 01:02:33 -0000 Received: from enaf.sfdc.sbc.com (localhost.localdomain [127.0.0.1]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o6N126wX000462 for ; Thu, 22 Jul 2010 21:02:06 -0400 Received: from gaalpa1msgusr7e.ugd.att.com (gaalpa1msgusr7e.ugd.att.com [135.53.26.19]) by mlpd194.enaf.sfdc.sbc.com (8.14.4/8.14.4) with ESMTP id o6N11xx6000413 for ; Thu, 22 Jul 2010 21:01:59 -0400 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, 22 Jul 2010 21:02:24 -0400 Message-ID: <14C85D6CCBE92743AF33663BF5D24EBA02BD513A@gaalpa1msgusr7e.ugd.att.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] draft-ietf-sipcore-location-conveyance-03 Thread-Index: Acspo+08pJMmoXskShuqBN3q0CjTtwAU3ixgAAIiadAAALGwzw== From: "DOLLY, MARTIN C (ATTLABS)" To: , , , X-Mailman-Approved-At: Thu, 22 Jul 2010 18:43:40 -0700 Cc: sipcore@ietf.org Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-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: Fri, 23 Jul 2010 01:02:17 -0000 QSBnb29kIHByb3RvY29sIHdvdWxkIGhhdmUgYSBjb21wYXRpYmlsaXR5IG1lY2hhbmlzbS4uLm1t bQ0KTWFydGluIEMuIERvbGx5DQpTZW50IHRvIHlvdSBieSBBVCZULi4uIEFtZXJpY2EncyBGYXN0 ZXN0IE1vYmlsZSBCcm9hZGJhbmQgTmV0d29yay4gUmV0aGluayBQb3NzaWJsZS4NCisxLjYwOS45 MDMuMzM2MA0KDQotLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiBzaXBjb3JlLWJv dW5jZXNAaWV0Zi5vcmcgPHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZz4NClRvOiBUaG9tc29uLCBN YXJ0aW4gPE1hcnRpbi5UaG9tc29uQGFuZHJldy5jb20+OyBQYXVsIEt5eml2YXQgPHBreXppdmF0 QGNpc2NvLmNvbT47IEphbWVzIE0uIFBvbGsgPGptcG9sa0BjaXNjby5jb20+DQpDYzogU0lQQ09S RSA8c2lwY29yZUBpZXRmLm9yZz4NClNlbnQ6IFRodSBKdWwgMjIgMjA6NDM6NTkgMjAxMA0KU3Vi amVjdDogUmU6IFtzaXBjb3JlXSBkcmFmdC1pZXRmLXNpcGNvcmUtbG9jYXRpb24tY29udmV5YW5j ZS0wMw0KDQpUaGlzIG1heSBiZSBpZ25vcmFuY2Ugb24gbXkgcGFydCwgYnV0IEkgYW0gZ29pbmcg dG8gYXNzdW1lIHRoYXQgdGhpcyBpcyBub3QgdGhlIGZpcnN0IG5ldyBoZWFkZXIgYWRkZWQgdG8g dGhlIFNJUCBzaW5jZSBSRkMzMjYxLCBhbmQgc28gaXQgaXMgYWxzbyBub3QgdGhlIGZpcnN0IGNh c2Ugd2hlcmUgYW4gZXJyb3IgbWlnaHQgY29tZSBiYWNrIGZyb20gYWJvdXQgYSBoZWFkZXIgdGhh dCBoYXMgYmVlbiBpbnNlcnRlZCBhbG9uZyB0aGUgd2F5Lg0KDQpXaGF0IGhhcHBlbnMgaW4gdGhl c2Ugb3RoZXIgY2FzZXM/DQoNCkNoZWVycw0KSmFtZXMNCg0KDQoNCg0KDQo+IC0tLS0tT3JpZ2lu YWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRv OnNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmDQo+IE9mIFRob21zb24sIE1hcnRp bg0KPiBTZW50OiBGcmlkYXksIDIzIEp1bHkgMjAxMCAxMDoxNCBBTQ0KPiBUbzogUGF1bCBLeXpp dmF0OyBKYW1lcyBNLiBQb2xrDQo+IENjOiBTSVBDT1JFDQo+IFN1YmplY3Q6IFJlOiBbc2lwY29y ZV0gZHJhZnQtaWV0Zi1zaXBjb3JlLWxvY2F0aW9uLWNvbnZleWFuY2UtMDMNCj4gDQo+ID4gPj4g SVNUTSB0aGVyZSBuZWVkcyB0byBiZSBhIHJlcXVpcmVtZW50IHRoYXQgdGhlIGludGVybWVkaWFy eSBpbnNlcnRpbmcNCj4gPiA+PiB0aGUgR2VvbG9jYXRpb24gaGVhZGVyIGhhbmRsZSBhbnkgNDI0 IGVycm9ycyB0aGF0IG1pZ2h0IHJlc3VsdCBmcm9tDQo+ID4gPj4gaXQsIHRodXMgc2hpZWxkaW5n IHRoZSBVQUMgZnJvbSB0aG9zZS4NCj4gPiA+DQo+ID4gPiBEbyB5b3UgdGhpbmsgd2UgY2FuIHN0 YXRlIHRoaXM/ICBJJ20gdGhpbmtpbmcgZnJvbSBhIHB1cmVzdCBwcm90b2NvbA0KPiA+ID4gcG92 LCB0aGF0IHNlZW1zIHRvIG1lIHRvIGJyZWFrIFNJUCdzIGUyZSBtb2RlbCBvZiBjb21tdW5pY2F0 aW9uLA0KPiA+ID4gZXNwZWNpYWxseSB3aGVuIGludm9sdmluZyBhIGxpdGVyYWwgcHJveHkgLSBh bmQgbm90IHNvbWUgb3RoZXIgZm9ybQ0KPiA+IG9mDQo+ID4gPiBTSVAgaW50ZXJtZWRpYXJ5IChl LmcuLCBiMmJ1YSBvciBzYmMgdGhhdCBhcmUgbWFkZSB0byBkbyBqdXN0IHRoaXMpLg0KPiANCj4g Tm8gaGFybSBpbiBtYWtpbmcgYSBzdGF0ZW1lbnQgYWJvdXQgdGhpcy4gIE9mIGNvdXJzZSwgdGhp cyBzb3J0IG9mDQo+IGJlaGF2aW91ciBjb3VsZCBzaW1wbHkgYmUgaW1wbGllZC4gIElmIHRoZSBp bnRlcm1lZGlhcnkgaXMgYWN0aW5nIGFzIGENCj4gQjJCVUEsIHdoZW4gaXQgYWRkcyBhIGZlYXR1 cmUsIGl0IGNhbiAoYW5kIHNob3VsZCkgYWJzb3JiIHRoZSBjb25zZXF1ZW5jZXMNCj4gb2YgdGhh dC4gIEZvciBnZW9sb2NhdGlvbiwgaWYgaXQgYWRkcyB0aGUgaGVhZGVyLCBpdCBtdXN0IGJlIHBy ZXBhcmVkIGZvcg0KPiB0aGUgY29uc2VxdWVuY2VzIG9mIHRoYXQgKDQyNCkuDQo+IA0KPiBJJ2xs IGxlYXZlIGl0IHRvIHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBlZGl0b3JzIGhvdyBtdWNoIHRoZXkg d2FudCB0byBkYW5jZQ0KPiBhcm91bmQgdGhlIHNlbnNpdGl2aXRpZXMuICBCdXQgeW91IGNvdWxk IGp1c3Qgc2F5Og0KPiANCj4gQW4gaW50ZXJtZWRpYXJ5IHRoYXQgYWRkcyBhIGdlb2xvY2F0aW9u IGhlYWRlciBNVVNUIGJlIHByZXBhcmVkIHRvIGhhbmRsZQ0KPiBhbnkgZXJyb3JzIHRoYXQgdGhp cyBtaWdodCByZXN1bHQgaW4sIGluY2x1ZGluZyBhIDQyNCByZXNwb25zZS4gIFRoZQ0KPiBpbnRl cm1lZGlhcnkgbWlnaHQgdGhlbiB0cmFuc2xhdGUgdGhpcyBlcnJvciBpbnRvIGFuIGVycm9yIHRo YXQgdGhlIFVBQyBpcw0KPiBrbm93biB0byBzdXBwb3J0LCBvci4uLg0KPiBfX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBzaXBjb3JlIG1haWxpbmcgbGlz dA0KPiBzaXBjb3JlQGlldGYub3JnDQo+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2lwY29yZQ0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0DQpzaXBjb3JlQGlldGYub3JnDQpodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg== From James.Winterbottom@andrew.com Thu Jul 22 18:45:23 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 19E143A690A for ; Thu, 22 Jul 2010 18:45:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.562 X-Spam-Level: X-Spam-Status: No, score=-3.562 tagged_above=-999 required=5 tests=[AWL=-0.962, 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 q8XYGef2MvT7 for ; Thu, 22 Jul 2010 18:45:17 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 8CB673A65A5 for ; Thu, 22 Jul 2010 18:45:17 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:20839 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S342368Ab0GWBpe convert rfc822-to-8bit (ORCPT ); Thu, 22 Jul 2010 20:45:34 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Thu, 22 Jul 2010 20:45:34 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Fri, 23 Jul 2010 09:45:25 +0800 From: "Winterbottom, James" To: Paul Kyzivat , "DOLLY, MARTIN C (ATTLABS)" Date: Fri, 23 Jul 2010 09:45:22 +0800 Thread-Topic: [sipcore] draft-ietf-sipcore-location-conveyance-03 Thread-Index: AcsqCCkC/eZSicZvQ2W07Pr3d5AAHQAAC2+A Message-ID: <5A55A45AE77F5941B18E5457ECAC81880120E982984D@SISPE7MB1.commscope.com> References: <14C85D6CCBE92743AF33663BF5D24EBA02BD513A@gaalpa1msgusr7e.ugd.att.com> <4C48F332.9080500@cisco.com> In-Reply-To: <4C48F332.9080500@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: 8BIT MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: James.Winterbottom@andrew.com Cc: "sipcore@ietf.org" , "Thomson, Martin" Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-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: Fri, 23 Jul 2010 01:45:23 -0000 Hi Paul, I am okay with all of that, but it seems like what is being proposed should apply to any head that a proxy may insert, rather than just something that specific to the geolocation header case. I don't for one second suggest that putting something to this effect in the location conveyance draft is a bad idea, but perhaps a general statement to the same effect would be worth adding to something like the 3261 core fixes document also. Cheers James > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > Sent: Friday, 23 July 2010 11:41 AM > To: DOLLY, MARTIN C (ATTLABS) > Cc: Winterbottom, James; Thomson, Martin; jmpolk@cisco.com; > sipcore@ietf.org > Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-03 > > SIP *does* have a compatibility mechanism. If the 424 *does* get back to > an unaware UAC, then it will be treated equivalently to a 400. > > The problem arises if that is an insufficient way of dealing. > The design of the 424 response is based on the assumption that the > recipient will understand it and make a suitable retry. An unaware UAC > won't do that. > > The words Martin offered seem sufficient to me. If the responsible proxy > is satisfied with the consequences of allowing the UAC to get the 424, > then that too is ok. > > It could be left unstated, on the assumption that it will be evident to > an informed developer. But in my experience much of the stuff that seems > evident to us turns out *not* to be evident to many developers. > > Thanks, > Paul > > DOLLY, MARTIN C (ATTLABS) wrote: > > A good protocol would have a compatibility mechanism...mmm > > Martin C. Dolly > > Sent to you by AT&T... America's Fastest Mobile Broadband Network. > Rethink Possible. > > +1.609.903.3360 > > > > ----- Original Message ----- > > From: sipcore-bounces@ietf.org > > To: Thomson, Martin ; Paul Kyzivat > ; James M. Polk > > Cc: SIPCORE > > Sent: Thu Jul 22 20:43:59 2010 > > Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-03 > > > > This may be ignorance on my part, but I am going to assume that this is > not the first new header added to the SIP since RFC3261, and so it is also > not the first case where an error might come back from about a header that > has been inserted along the way. > > > > What happens in these other cases? > > > > Cheers > > James > > > > > > > > > > > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On > Behalf > >> Of Thomson, Martin > >> Sent: Friday, 23 July 2010 10:14 AM > >> To: Paul Kyzivat; James M. Polk > >> Cc: SIPCORE > >> Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-03 > >> > >>>>> ISTM there needs to be a requirement that the intermediary inserting > >>>>> the Geolocation header handle any 424 errors that might result from > >>>>> it, thus shielding the UAC from those. > >>>> Do you think we can state this? I'm thinking from a purest protocol > >>>> pov, that seems to me to break SIP's e2e model of communication, > >>>> especially when involving a literal proxy - and not some other form > >>> of > >>>> SIP intermediary (e.g., b2bua or sbc that are made to do just this). > >> No harm in making a statement about this. Of course, this sort of > >> behaviour could simply be implied. If the intermediary is acting as a > >> B2BUA, when it adds a feature, it can (and should) absorb the > consequences > >> of that. For geolocation, if it adds the header, it must be prepared > for > >> the consequences of that (424). > >> > >> I'll leave it to the discretion of the editors how much they want to > dance > >> around the sensitivities. But you could just say: > >> > >> An intermediary that adds a geolocation header MUST be prepared to > handle > >> any errors that this might result in, including a 424 response. The > >> intermediary might then translate this error into an error that the UAC > is > >> known to support, or... > >> _______________________________________________ > >> 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 jmpolk@cisco.com Thu Jul 22 21:50:47 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E7F103A6860 for ; Thu, 22 Jul 2010 21:50:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.472 X-Spam-Level: X-Spam-Status: No, score=-10.472 tagged_above=-999 required=5 tests=[AWL=0.127, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4pERfyicaV7 for ; Thu, 22 Jul 2010 21:50:47 -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 F284F3A67FE for ; Thu, 22 Jul 2010 21:50:46 -0700 (PDT) Authentication-Results: sj-iport-5.cisco.com; dkim=neutral (message not signed) header.i=none Received: from sj-core-5.cisco.com ([171.71.177.238]) by sj-iport-5.cisco.com with ESMTP; 23 Jul 2010 04:51:05 +0000 Received: from jmpolk-wxp01.cisco.com (rcdn-jmpolk-8714.cisco.com [10.99.80.21]) by sj-core-5.cisco.com (8.13.8/8.14.3) with ESMTP id o6N4p46T029068; Fri, 23 Jul 2010 04:51:04 GMT Message-Id: <201007230451.o6N4p46T029068@sj-core-5.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Thu, 22 Jul 2010 23:51:03 -0500 To: "Thomson, Martin" , Paul Kyzivat , "James M. Polk" From: "James M. Polk" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03EB828B8D@SISPE7MB1.comms cope.com> References: <4C47B6B6.2090009@cisco.com> <201007220329.o6M3TtCI013514@sj-core-1.cisco.com> <4C484B10.2000907@cisco.com> <8B0A9FCBB9832F43971E38010638454F03EB828B8D@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-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: Fri, 23 Jul 2010 04:50:48 -0000 At 07:14 PM 7/22/2010, Thomson, Martin wrote: > > >> ISTM there needs to be a requirement that the intermediary inserting > > >> the Geolocation header handle any 424 errors that might result from > > >> it, thus shielding the UAC from those. > > > > > > Do you think we can state this? I'm thinking from a purest protocol > > > pov, that seems to me to break SIP's e2e model of communication, > > > especially when involving a literal proxy - and not some other form > > of > > > SIP intermediary (e.g., b2bua or sbc that are made to do just this). > >No harm in making a statement about this. Of course, this sort of >behaviour could simply be implied. right now it is assumed, but you're right - saying something, as long as it's accurate is better. >If the intermediary is acting as a B2BUA, when it adds a feature, it >can (and should) absorb the consequences of that. For geolocation, >if it adds the header, it must be prepared for the consequences of that (424). > >I'll leave it to the discretion of the editors how much they want to >dance around the sensitivities. But you could just say: I like this, but I'm concerned about what could happen about an intermediary that includes a geolocation header value and causes another - non-424 - error response? I'm not sure how that could come about (that is, only from the insertion of the geolocation header value). I get the intent here, but how about this refinement below >An intermediary that adds a geolocation header MUST s/MUST/SHOULD >be prepared to handle any errors that this might result in, >including a a 424 response. s/including a 424 response/and MUST handle the 424 response instead of leaving this for a UAC to potentially blindly deal with. >The intermediary might s/might/will > then translate this error into an error that the UAC is known to support (including). This is behavior paramount if the intermediary inserts the initial geolocation header value into a SIP request. >, or... here is the edited paragraph in whole, above is the editing version "An intermediary that adds a geolocation header SHOULD be prepared to handle any errors that this might result in, and MUST handle the 424 response instead of leaving this for a UAC to blindly deal with. The intermediary will then translate this error into an error that the UAC is known to support. This behavior is paramount if the intermediary inserts the initial geolocation header value into a SIP request." thoughts? James From john.elwell@siemens-enterprise.com Fri Jul 23 00:43:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D0F033A699F for ; Fri, 23 Jul 2010 00:43:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.007 X-Spam-Level: X-Spam-Status: No, score=-3.007 tagged_above=-999 required=5 tests=[AWL=-0.408, 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 o8HTZbU44yoP for ; Fri, 23 Jul 2010 00:43:20 -0700 (PDT) Received: from ms03.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 5AD163A6B08 for ; Fri, 23 Jul 2010 00:43:20 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms03.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-944957; Fri, 23 Jul 2010 09:43:37 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id 2C0A61EB82AE; Fri, 23 Jul 2010 09:43:37 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.55]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Fri, 23 Jul 2010 09:43:37 +0200 From: "Elwell, John" To: "James M. Polk" , "Thomson, Martin" , Paul Kyzivat Date: Fri, 23 Jul 2010 09:43:35 +0200 Thread-Topic: [sipcore] draft-ietf-sipcore-location-conveyance-03 Thread-Index: AcsqIrUGrKtL8PiuRbm7kfhN97vErgAFdDsg Message-ID: References: <4C47B6B6.2090009@cisco.com> <201007220329.o6M3TtCI013514@sj-core-1.cisco.com> <4C484B10.2000907@cisco.com> <8B0A9FCBB9832F43971E38010638454F03EB828B8D@SISPE7MB1.commscope.com> <201007230451.o6N4p46T029068@sj-core-5.cisco.com> In-Reply-To: <201007230451.o6N4p46T029068@sj-core-5.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] draft-ietf-sipcore-location-conveyance-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: Fri, 23 Jul 2010 07:43:21 -0000 =20 > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of James M. Polk > Sent: 23 July 2010 05:51 > To: Thomson, Martin; Paul Kyzivat; James M. Polk > Cc: SIPCORE > Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-03 >=20 > At 07:14 PM 7/22/2010, Thomson, Martin wrote: > > > >> ISTM there needs to be a requirement that the=20 > intermediary inserting > > > >> the Geolocation header handle any 424 errors that=20 > might result from > > > >> it, thus shielding the UAC from those. > > > > > > > > Do you think we can state this? I'm thinking from a=20 > purest protocol > > > > pov, that seems to me to break SIP's e2e model of communication, > > > > especially when involving a literal proxy - and not=20 > some other form > > > of > > > > SIP intermediary (e.g., b2bua or sbc that are made to=20 > do just this). > > > >No harm in making a statement about this. Of course, this sort of=20 > >behaviour could simply be implied. >=20 > right now it is assumed, but you're right - saying something, as long=20 > as it's accurate is better. >=20 > >If the intermediary is acting as a B2BUA, when it adds a feature, it=20 > >can (and should) absorb the consequences of that. For geolocation,=20 > >if it adds the header, it must be prepared for the=20 > consequences of that (424). > > > >I'll leave it to the discretion of the editors how much they want to=20 > >dance around the sensitivities. But you could just say: >=20 > I like this, but I'm concerned about what could happen about an=20 > intermediary that includes a geolocation header value and causes=20 > another - non-424 - error response? I'm not sure how that could come=20 > about (that is, only from the insertion of the geolocation header=20 > value). I get the intent here, but how about this refinement below >=20 >=20 > >An intermediary that adds a geolocation header MUST >=20 > s/MUST/SHOULD >=20 > >be prepared to handle any errors that this might result in,=20 > >including a a 424 response. >=20 > s/including a 424 response/and MUST handle the 424 response instead=20 > of leaving this for a UAC to potentially blindly deal with. >=20 > >The intermediary might >=20 > s/might/will >=20 > > then translate this error into an error that the UAC is=20 > known to support >=20 > (including). This is behavior paramount if the intermediary inserts=20 > the initial geolocation header value into a SIP request. >=20 > >, or... >=20 > here is the edited paragraph in whole, above is the editing version >=20 > "An intermediary that adds a geolocation header SHOULD > be prepared to handle any errors that this might > result in, and MUST handle the 424 response instead of > leaving this for a UAC to blindly deal with. The > intermediary will then translate this error into an > error that the UAC is known to support. This > behavior is paramount if the intermediary inserts the > initial geolocation header value into a SIP request." [JRE] I agree in principle with this proposal. Even if the UAC DOES support= location-conveyance, receipt of a 424 response when it has not included a = location in the request would be confusing, to say the least. That is what = is rather unique about a 424 response - it relates to a specific header fie= ld, whereas most other SIP responses are less specific. A 4xx response says= it is a bad request. A 424 response says it is a bad location, so the impl= ication is that by removing or rectifying the location and transmitting a n= ew request, it might be acceptable. This just doesn't make sense to a UAC t= hat has not included location in the first place. In fact, we already have in the draft the statement: "A 424 MUST NOT be sent in response=20 to a request that lacks a Geolocation header entirely, as the user=20 agent in that case may not support this extension at all." This text seems to imply that a UAC would not expect to receive a 424 if it= has not inserted Geolocation, whether or not it supports Geolocation. Instead of=20 "The intermediary will then translate this error into an error that the UAC= is known to support." perhaps we should something like: "The intermediary will then translate this error into an error that is like= ly to be meaningful to the UAC." Concerning the words: "This behavior is paramount if the intermediary inserts the initial geoloca= tion header value into a SIP request." I am not sure what value this sentence adds - can we remove it? John >=20 > thoughts? >=20 > James >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From shinji.okumura@softfront.jp Fri Jul 23 02:09:55 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 85BA93A69E0 for ; Fri, 23 Jul 2010 02:09:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -97.868 X-Spam-Level: X-Spam-Status: No, score=-97.868 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_221=2.222, 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 k3LG8tdRDMmO for ; Fri, 23 Jul 2010 02:09:54 -0700 (PDT) Received: from sf-mail.softfront.co.jp (rt1.softfront.co.jp [221.186.247.166]) by core3.amsl.com (Postfix) with ESMTP id C0D8B3A6965 for ; Fri, 23 Jul 2010 02:09:53 -0700 (PDT) Received: from localhost (localhost.localdomain [127.0.0.1]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 9893D428065; Fri, 23 Jul 2010 18:10:09 +0900 (JST) X-Virus-Scanned: amavisd-new at softfront.co.jp Received: from sf-mail.softfront.co.jp ([127.0.0.1]) by localhost (sf-mail.softfront.co.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id f7g32XUkm1Y7; Fri, 23 Jul 2010 18:10:09 +0900 (JST) Received: from softfront.jp (112.136.80.7.er.eaccess.ne.jp [112.136.80.7]) by sf-mail.softfront.co.jp (Postfix) with ESMTP id 0B3A3428064; Fri, 23 Jul 2010 18:10:08 +0900 (JST) From: OKUMURA Shinji To: Gonzalo Camarillo Date: Fri, 23 Jul 2010 18:10:10 +0900 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Mailer: HidemaruMail 5.33 (WinNT,501) In-Reply-To: <4C3EE244.8040909@ericsson.com> References: <4C317D02.2030307@ericsson.com> <4C3EE244.8040909@ericsson.com> Message-Id: <8ECB2A46DA07E4shinji.okumura@softfront.jp> Cc: SIPCORE Subject: Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 23 Jul 2010 09:09:55 -0000 Hi Gonzalo, I have some comments and questions. >3.4. UAC Behavior > In order to cope with these race condition > situations, 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 (the UAC uses the criteria in > Section 3.3 in order to decide whether or not changes have been > executed for a particular stream). As I have said many times, this restriction is excessive. I propose as follows; s/which changes have been already executed/which changes have been already executed by an UPDATE transaction/ >4.8. Race Conditions and Target Refreshes The rule for a UAS is looking good. But if a UAS sends a reliable response and an UPDATE request in order to refresh its local target, what should a UAC do? In the cases below, UA-B should not use a 18x-rel. But UA-A can not reject the 18x-rel and prohibit UA-B from using the 18x-rel. Should UA-A reject this UPDATE? or ignore a Contact of 18x-rel? Otherwise should UA-A send another UPDATE to confirm a remote target? A B | | s0|re-INVITE (offer1) |s0 |------------------------------>| | 18x-rel(answer1)| |<------------------------------| s1|PRACK |s1 |------------------------------>| | 2xx-PRA| |<------------------------------|<-+ | | | | UPDATE(m:c1)| | |<-------------\ /=============| | | \/ | | | /\ 18x-rel(m:c2)| | |<=============/ \-------------| | | | | accept UPDATE | | | | | v A B | | s0|re-INVITE (offer1) |s0 |------------------------------>| | 18x-rel(answer1)| |<------------------------------| s1|PRACK |s1 |------------------------------>| | 2xx-PRA| |<------------------------------|<-+ | | | | 18x-rel(m:c1)| | |<=============\ /-------------| | | \/ | | | /\ UPDATE(m:c2)| | |<-------------/ \=============| | | | | accept UPDATE | | | | | v >5.2. Problems with UAs Losing their Contact > On detecting some of > these errors, UAs following the rules specified in RFC 3261 [RFC3261] > will terminate the dialog. According to RFC5057, 408 affects an only transaction. Just to be sure, I think it is better to describe about RFC5057. >5.3. UAS Losing its Contact: UAC Behavior > When a UAS that moves to a new contact and loses its old contact > generates a non-2xx final response to the re-INVITE, it will not be > able to receive the ACK request. The entity receiving the response > and, thus, generating the ACK request will either get a transport > error or a timeout error, which, as described in Section 8.1.3.1 of > RFC 3261 [RFC3261], will be treated as a 503 (Service Unavailable) > response and as a 408 (Request Timeout) response, respectively. IMO It is not described in RFC3261 that a transport error for sending ACK is treated as an error for re-INVITE request. >5.5. UAC Losing its Contact: UAC Behavior Even though the UAC probably can't receive a response to the CANCEL requst, should it send CANCEL? When a UAS receives the CANCEL request, which code should it return to a UAC? 2xx or 487? Thanks, Shinji Gonzalo Camarillo Thu, 15 Jul 2010 13:26:12 +0300 >Hi, > >thanks for the feedback I have received on and off list. We seem to have >consensus on reducing the scope of the draft to session state and target >refreshes. That is great because it allows us to hugely simplify the >rules to avoid glare conditions (this is something a few of you have >requested on the list in the past). I have put together a new revision >of the draft, which you can fetch from: > >http://users.piuha.net/gonzalo/temp/draft-ietf-sipcore-reinvite-pre05-01.txt > >In addition to adjusting the scope of the draft and simplifying the >glare-related rules, I have also added a few clarifications to Section 5 >in response to Robert's AD review. > >Let me know if you have any comments. > >Thanks, > >Gonzalo > >On 05/07/2010 9:34 AM, Gonzalo Camarillo wrote: >> Hi, >> >> the re-INVITE draft talks about modifications in the session state, >> dialog state, and the dialog's remote target. While it is relatively >> well understood what we mean by session state and the dialog's remote >> target, we do not really have a good definition for dialog state. >> >> We have discussed it in the past and what people had in mind were things >> such as called party identity. However, the draft is too vague at this >> point; it should be more precise regarding which piece of "dialog state" >> the rules in the draft apply to. >> >> My suggestion would be to have the draft talk only about session state >> and the dialog's remote target, and forget about any other dialog state. >> New extensions whose parameters can be modified by re-INVITEs can >> specify their own rules, possibly referring to this draft and using the >> rules defined in it by reference. In this way, the applicability of this >> draft would be much clearer. >> >> Comments? >> >> Thanks, >> >> Gonzalo From R.Jesske@telekom.de Fri Jul 23 02:15:26 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8D46E3A69E5 for ; Fri, 23 Jul 2010 02:15:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.854 X-Spam-Level: X-Spam-Status: No, score=-4.854 tagged_above=-999 required=5 tests=[AWL=-1.605, 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 6RkHGmJfKMe5 for ; Fri, 23 Jul 2010 02:15:22 -0700 (PDT) Received: from tcmail73.telekom.de (tcmail73.telekom.de [217.243.239.135]) by core3.amsl.com (Postfix) with ESMTP id 133273A68B3 for ; Fri, 23 Jul 2010 02:15:21 -0700 (PDT) Received: from s4de8psaanq.blf.telekom.de (HELO S4DE8PSAANQ.mitte.t-com.de) ([10.151.180.166]) by tcmail71.telekom.de with ESMTP; 23 Jul 2010 11:15:23 +0200 Received: from S4DE8PSAAQB.mitte.t-com.de ([10.151.229.13]) by S4DE8PSAANQ.mitte.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Fri, 23 Jul 2010 11:15:22 +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, 23 Jul 2010 11:15:21 +0200 Message-ID: <9886E5FCA6D76549A3011068483A4BD4065E732E@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Updated 4244bis and new call flow document Thread-Index: AcsZU+hzXT6gkwZ9R0GR/L7LMR7QhgQPeS4Q References: From: To: , X-OriginalArrivalTime: 23 Jul 2010 09:15:22.0660 (UTC) FILETIME=[9423A640:01CB2A47] Subject: Re: [sipcore] Updated 4244bis and new call flow document X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 23 Jul 2010 09:15:26 -0000 Hi Mary, With regard to your question for comments/review, I went thought the = draft. For http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-01.txt=20 I have the following comments:=20 6.3.2. Privacy in the History-Info Header ... If the requestor has indicated a priv- value of "session" or "header" in the request, all History-Info entries MUST be anonymized when the request leaves a domain for which the intermediary is responsible. ... In this section it is mentioned that the entries must be anonymized when = leaving the domain. I thought that if a trust relationship between = domains are existing and the following domain secures the "privacy" then = the information could be forwarded and will then deleted by the = succeeding domain before reaching the terminating user.=20 Some regulators are requesting to pass identities until the last domain = where it is possible to execute the privacy regarding RFC3323. So I = think this is a MAY based on domain policy. And it is a MUST when the = succeeding network cannot guarantee the privacy. Or do I misunderstand the meaning of "domain for which the intermediary = is responsible" The Rest of the document looks good for me. Best Regards Roland Deutsche Telekom Netzproduktion GmbH Fixed Mobile Engineering Deutschland Roland Jesske Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt +49 6151 628-2766 (Tel.) +49 521 9210-3753 (Fax) +49 171 8618-445 (Mobil) E-Mail: r.jesske@telekom.de www.telekom.com =20 Erleben, was verbindet.=20 Deutsche Telekom Netzproduktion GmbH Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert = Matheis, Klaus Peren Handelsregister: Amtsgericht Bonn HRB 14190 Sitz der Gesellschaft: Bonn USt-IdNr. DE 814645262 Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht = jede E-Mail drucken. -----Urspr=FCngliche Nachricht----- Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im = Auftrag von Mary Barnes Gesendet: Donnerstag, 1. Juli 2010 21:31 An: SIPCORE Betreff: Re: [sipcore] Updated 4244bis and new call flow document Hi folks, I have not seen any responses to this email. So, either folks don't see any issues with the documents and 4244bis is ready for WGLC or folks have not reviewed the documents. I'm happy to assume the former, however, it would be good for folks that have read the docs to post a note on the mailing list as to whether they think 4244bis is ready for WGLC. And, if not, please detail your concerns, so that we can determine whether they warrant discussion in Maastricht. Also, opinions on how/where to progress the call flow document would be welcome. I personally do not think it's worthwhile to pursue this in DISPATCH, but it's not clear to me whether informational docs like this are under the purview of the SIPCORE charter. Since BLISS is trying to close down, it is also not appropriate to pursue the work there. Thanks, Mary. On Thu, Jun 24, 2010 at 3:11 PM, Mary Barnes = wrote: > Hi folks, > > The 4244bis draft has been updated and a separate call flow document > created per the earlier summary of proposed changes: > http://www.ietf.org/mail-archive/web/sipcore/current/msg02647.html > > http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-01.txt > = http://www.ietf.org/id/draft-barnes-sipcore-rfc4244bis-callflows-00.txt > > There are =A0two voicemail examples in the new call flow document. = =A0The > 4244bis has 3 call flows - the basic sequential forking and two > privacy examples. All the rest are now in the call flow document. > > The other changes we made were updates to the UAC, UAS and application > considerations section - adding additional text as to how the UAC and > UAS process hi-entries (including related to responses). =A0The > application considerations section now describes how the tags can be > used to derive specific information and the past guidelines were > removed since 4244bis has much definitive guidance on the normative > aspects of the header (i.e., SHOULDs replaced with MUSTs, privacy via > anonymization rather than removing entries, etc.) as summarized in > Section 11. > > Please review and provide any additional comments. We believe that > 4244bis is pretty much ready to go. We can fine tune the details in > the call flows and should be able to get that ready very soon, as > well. =A0Let us know if you see additional use cases you would like to > add. > > Thanks, > Mary et al > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From gonzalo.camarillo@ericsson.com Fri Jul 23 04:20:17 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B84493A69AC for ; Fri, 23 Jul 2010 04:20:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.846 X-Spam-Level: X-Spam-Status: No, score=-103.846 tagged_above=-999 required=5 tests=[AWL=-1.247, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O4xlyu0Q+QN0 for ; Fri, 23 Jul 2010 04:20:16 -0700 (PDT) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id 0A5D33A67FC for ; Fri, 23 Jul 2010 04:20:15 -0700 (PDT) X-AuditID: c1b4fb39-b7b91ae000001aef-07-4c497b011bdf Received: from esealmw128.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id 4A.19.06895.10B794C4; Fri, 23 Jul 2010 13:20:33 +0200 (CEST) Received: from esealmw126.eemea.ericsson.se ([153.88.254.170]) by esealmw128.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Jul 2010 13:19:47 +0200 Received: from [131.160.37.44] ([131.160.37.44]) by esealmw126.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Fri, 23 Jul 2010 13:19:47 +0200 Message-ID: <4C497AD3.8040604@ericsson.com> Date: Fri, 23 Jul 2010 14:19:47 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: OKUMURA Shinji References: <4C317D02.2030307@ericsson.com> <4C3EE244.8040909@ericsson.com> <8ECB2A46DA07E4shinji.okumura@softfront.jp> In-Reply-To: <8ECB2A46DA07E4shinji.okumura@softfront.jp> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 23 Jul 2010 11:19:47.0710 (UTC) FILETIME=[F5A7E1E0:01CB2A58] X-Brightmail-Tracker: AAAAAA== Cc: SIPCORE Subject: Re: [sipcore] Dialog state - Scope in draft-ietf-sipcore-reinvite X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 23 Jul 2010 11:20:17 -0000 Hi Shinji, thanks for your comments. Answers inline: On 23/07/2010 12:10 PM, OKUMURA Shinji wrote: > Hi Gonzalo, > > I have some comments and questions. > >> 3.4. UAC Behavior >> In order to cope with these race condition >> situations, 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 (the UAC uses the criteria in >> Section 3.3 in order to decide whether or not changes have been >> executed for a particular stream). > > As I have said many times, this restriction is excessive. > I propose as follows; > s/which changes have been already executed/which changes > have been already executed by an UPDATE transaction/ We have discussed this issue many times. At this point, we are not going to reopen all the discussions we had on this in the past. >> 4.8. Race Conditions and Target Refreshes > The rule for a UAS is looking good. But if a UAS sends a > reliable response and an UPDATE request in order to refresh > its local target, what should a UAC do? > > In the cases below, UA-B should not use a 18x-rel. > But UA-A can not reject the 18x-rel and prohibit UA-B from > using the 18x-rel. > > Should UA-A reject this UPDATE? or ignore a Contact of 18x-rel? > Otherwise should UA-A send another UPDATE to confirm a remote target? The draft identifies the problem and specifies a solution to it. Of course, a legacy UAS could act as you describe. However, such behavior would only be a problem in certain race conditions. So, I do not think it is worthwhile specifying more rules to cover that type of legacy UAS. With all the background in the draft, implementers should be able to understand what types of different behaviors they can expect from legacy UAs. > > A B > | | > s0|re-INVITE (offer1) |s0 > |------------------------------>| > | 18x-rel(answer1)| > |<------------------------------| > s1|PRACK |s1 > |------------------------------>| > | 2xx-PRA| > |<------------------------------|<-+ > | | | > | UPDATE(m:c1)| | > |<-------------\ /=============| | > | \/ | | > | /\ 18x-rel(m:c2)| | > |<=============/ \-------------| | > | | | accept UPDATE > | | | > | | v > > A B > | | > s0|re-INVITE (offer1) |s0 > |------------------------------>| > | 18x-rel(answer1)| > |<------------------------------| > s1|PRACK |s1 > |------------------------------>| > | 2xx-PRA| > |<------------------------------|<-+ > | | | > | 18x-rel(m:c1)| | > |<=============\ /-------------| | > | \/ | | > | /\ UPDATE(m:c2)| | > |<-------------/ \=============| | > | | | accept UPDATE > | | | > | | v > >> 5.2. Problems with UAs Losing their Contact >> On detecting some of >> these errors, UAs following the rules specified in RFC 3261 [RFC3261] >> will terminate the dialog. > > According to RFC5057, 408 affects an only transaction. > Just to be sure, I think it is better to describe about RFC5057. Section 5.2 of RFC 5057 states that the 408 affects a dialog usage. In this case, the invite usage. >> 5.3. UAS Losing its Contact: UAC Behavior >> When a UAS that moves to a new contact and loses its old contact >> generates a non-2xx final response to the re-INVITE, it will not be >> able to receive the ACK request. The entity receiving the response >> and, thus, generating the ACK request will either get a transport >> error or a timeout error, which, as described in Section 8.1.3.1 of >> RFC 3261 [RFC3261], will be treated as a 503 (Service Unavailable) >> response and as a 408 (Request Timeout) response, respectively. > > IMO It is not described in RFC3261 that a transport error for > sending ACK is treated as an error for re-INVITE request. As I noted before, the background material in the draft is given so that implementers understand what to expect from different legacy UAs. I am sure some UAs act as you describe and do not relate ACK errors to the re-INVITE. However, others will do that. >> 5.5. UAC Losing its Contact: UAC Behavior > > Even though the UAC probably can't receive a response to the > CANCEL requst, should it send CANCEL? Yes, because the CANCEL will allow the UAC to initiate a new re-INVITE transaction (if needed) from its new location. The CANCEL will synchronize the UAs. > When a UAS receives the CANCEL request, which code should > it return to a UAC? 2xx or 487? The UAS will apply normal CANCEL processing, which typically consists of returning a 487 to the original request and a 200 to the CANCEL. Thanks, Gonzalo From pkyzivat@cisco.com Fri Jul 23 06:11:40 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8BC7A3A66B4 for ; Fri, 23 Jul 2010 06:11:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.553 X-Spam-Level: X-Spam-Status: No, score=-10.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x34jqSFBkrzz for ; Fri, 23 Jul 2010 06:11:39 -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 616E23A657C for ; Fri, 23 Jul 2010 06:11:39 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AokGAEgySUxAZnwN/2dsb2JhbACTJYxEcaYemwyFNgSIYA Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-1.cisco.com with ESMTP; 23 Jul 2010 13:11:57 +0000 Received: from [10.86.253.215] ([10.86.253.215]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6NDBvhI004488; Fri, 23 Jul 2010 13:11:57 GMT Message-ID: <4C49951C.8050202@cisco.com> Date: Fri, 23 Jul 2010 09:11:56 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: R.Jesske@telekom.de References: <9886E5FCA6D76549A3011068483A4BD4065E732E@S4DE8PSAAQB.mitte.t-com.de> In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4065E732E@S4DE8PSAAQB.mitte.t-com.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: sipcore@ietf.org Subject: Re: [sipcore] Updated 4244bis and new call flow document X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 23 Jul 2010 13:11:40 -0000 R.Jesske@telekom.de wrote: > Hi Mary, > With regard to your question for comments/review, I went thought the draft. > > For http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-01.txt > > I have the following comments: > > > 6.3.2. Privacy in the History-Info Header > > ... > If the requestor has indicated a priv- > value of "session" or "header" in the request, all History-Info > entries MUST be anonymized when the request leaves a domain for which > the intermediary is responsible. > ... > > In this section it is mentioned that the entries must be anonymized when leaving the domain. I thought that if a trust relationship between domains are existing and the following domain secures the "privacy" then the information could be forwarded and will then deleted by the succeeding domain before reaching the terminating user. > Some regulators are requesting to pass identities until the last domain where it is possible to execute the privacy regarding RFC3323. So I think this is a MAY based on domain policy. And it is a MUST when the succeeding network cannot guarantee the privacy. > > Or do I misunderstand the meaning of "domain for which the intermediary is responsible" I'm not an expert on this, but ISTM that in the case you describe the request is not leaving the *trust* domain. But that does point out ambiguity in the text you quote. That kind of wording "domain for which the intermediary is responsible" is usually talking about *DNS* domains, not *trust* domains. So maybe that should say: ... If the requestor has indicated a priv-value of "session" or "header" in the request, all History-Info entries MUST be anonymized when the request leaves a *trust* domain for which the intermediary is responsible. ... Thanks, Paul From keith.drage@alcatel-lucent.com Fri Jul 23 06:24:50 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B8A3A3A6807 for ; Fri, 23 Jul 2010 06:24:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.147 X-Spam-Level: X-Spam-Status: No, score=-3.147 tagged_above=-999 required=5 tests=[AWL=-0.898, 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 03JIQMx7r1yu for ; Fri, 23 Jul 2010 06:24:49 -0700 (PDT) Received: from smail6.alcatel.fr (smail6.alcatel.fr [64.208.49.42]) by core3.amsl.com (Postfix) with ESMTP id 407453A67EA for ; Fri, 23 Jul 2010 06:24:48 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail6.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o6NDOoQo012852 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Fri, 23 Jul 2010 15:25:02 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Fri, 23 Jul 2010 15:24:51 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat , "R.Jesske@telekom.de" Date: Fri, 23 Jul 2010 15:24:49 +0200 Thread-Topic: [sipcore] Updated 4244bis and new call flow document Thread-Index: AcsqaKQKoBUplRvFTv+B4yK450/SgQAASTvg Message-ID: References: <9886E5FCA6D76549A3011068483A4BD4065E732E@S4DE8PSAAQB.mitte.t-com.de> <4C49951C.8050202@cisco.com> In-Reply-To: <4C49951C.8050202@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.84 Cc: "sipcore@ietf.org" Subject: Re: [sipcore] Updated 4244bis and new call flow document X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 23 Jul 2010 13:24:50 -0000 If we are going to talk about trust domains in the document, then you will = have to say what they are. For the RFC 3325 stuff there is most of a document that talks about that. M= oreover, you need to say what to "trust" the next entity to do if you do no= t do it. To give some idea of what I mean. Statements like "I will give you the iden= tity if you do not reveal it to anyone outside our area of trust" are sligh= tly different to "I trust you to implement the privacy that I otherwise wou= ld have done so if I did not trust you". regards Keith > -----Original Message----- > From: sipcore-bounces@ietf.org=20 > [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > Sent: Friday, July 23, 2010 2:12 PM > To: R.Jesske@telekom.de > Cc: sipcore@ietf.org > Subject: Re: [sipcore] Updated 4244bis and new call flow document >=20 >=20 >=20 > R.Jesske@telekom.de wrote: > > Hi Mary, > > With regard to your question for comments/review, I went=20 > thought the draft. > >=20 > > For http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-01.txt > >=20 > > I have the following comments:=20 > >=20 > >=20 > > 6.3.2. Privacy in the History-Info Header > >=20 > > ... > > If the requestor has indicated a priv- > > value of "session" or "header" in the request, all History-Info > > entries MUST be anonymized when the request leaves a=20 > domain for which > > the intermediary is responsible. > > ... > >=20 > > In this section it is mentioned that the entries must be=20 > anonymized when leaving the domain. I thought that if a trust=20 > relationship between domains are existing and the following=20 > domain secures the "privacy" then the information could be=20 > forwarded and will then deleted by the succeeding domain=20 > before reaching the terminating user.=20 > > Some regulators are requesting to pass identities until the=20 > last domain where it is possible to execute the privacy=20 > regarding RFC3323. So I think this is a MAY based on domain=20 > policy. And it is a MUST when the succeeding network cannot=20 > guarantee the privacy. > >=20 > > Or do I misunderstand the meaning of "domain for which the=20 > intermediary is responsible" >=20 > I'm not an expert on this, but ISTM that in the case you=20 > describe the request is not leaving the *trust* domain. >=20 > But that does point out ambiguity in the text you quote. That=20 > kind of wording "domain for which the intermediary is=20 > responsible" is usually talking about *DNS* domains, not=20 > *trust* domains. So maybe that should say: >=20 > ... > If the requestor has indicated a priv-value of "session" or "header" > in the request, all History-Info entries MUST be anonymized when the > request leaves a *trust* domain for which the intermediary is > responsible. > ... >=20 > Thanks, > Paul > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > = From acooper@cdt.org Fri Jul 23 06:33:57 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 433163A6861 for ; Fri, 23 Jul 2010 06:33:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.767 X-Spam-Level: X-Spam-Status: No, score=-2.767 tagged_above=-999 required=5 tests=[AWL=-0.168, 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 NET0Q+VGOOU0 for ; Fri, 23 Jul 2010 06:33:54 -0700 (PDT) Received: from mail.maclaboratory.net (mail.maclaboratory.net [209.190.215.232]) by core3.amsl.com (Postfix) with ESMTP id 910033A686B for ; Fri, 23 Jul 2010 06:33:29 -0700 (PDT) Received: from localhost ([127.0.0.1]) by mail.maclaboratory.net (using TLSv1/SSLv3 with cipher AES128-SHA (128 bits)); Fri, 23 Jul 2010 09:33:20 -0400 Message-Id: From: Alissa Cooper To: James M. Polk In-Reply-To: <201007222109.o6ML9EXv011843@sj-core-3.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Fri, 23 Jul 2010 14:33:19 +0100 References: <201007222109.o6ML9EXv011843@sj-core-3.cisco.com> X-Mailer: Apple Mail (2.936) Cc: sipcore@ietf.org Subject: Re: [sipcore] Bad Location Information in draft-ietf-sipcore-location-conveyance-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: Fri, 23 Jul 2010 13:33:57 -0000 On Jul 22, 2010, at 10:09 PM, James M. Polk wrote: > At 02:50 PM 7/22/2010, Alissa Cooper wrote: >> Section 4.2 of draft-ietf-sipcore-location-conveyance-03 says: >> >> A SIP intermediary can also reject a location it receives from a >> Target when it understands the Target to be in a different >> location. >> The proper handling of this scenario is for the SIP intermediary to >> include the proper location in the 424 Response. This SHOULD be >> included in the response as a MIME message body (i.e., a location >> value), rather than as a URI; however, in cases where the >> intermediary is willing to share location with recipients but not >> with a user agent, a reference might be necessary. >> >> Does this leave the Target's ability to spoof its location up to the >> discretion of the SIP intermediary? > > Alissa - I'm not 100% I understand the direction of your question - > but here is my first try. > > If you're asking that an intermediary *can* prevent a Target from > lying, the answer is yes. > > why is this prevented? Because the intermediary could be literally > standing in the way of this message's progressing further into the > network towards the destination, and believes (not consciously of > course) that it knows better where the Target is than what is in the > SIP request. The intermediary has a couple of alternatives: > > - it could send a 424 response with the only location it will accept > in a subsequent SIP request from that Target, or > > - it could compose a dual location PIDF and return it to the Target > to have it send in the subsequent SIP request, or > > - it could overwrite the existing location, unbeknownst to the > Target, and deliver that to the destination UAS. > > The work around is to not have that intermediary in the signaling > path in any subsequent SIP request - but only works *if* the Target > learns that the intermediary is doing this in the first place, which > wouldn't be the case (easily) if the intermediary is just > overwriting the Target's location. > > I don't see any other way around this. > > If we state that this MUST NOT happen, that'll fly in the face of > what IMS is defining where "UEs (i.e., UACs) aren't to be trusted > with this kind of information", as just one example. > > Did I get your question right (even if you did or did not like the > answer)? > Yep, and knowing the alternatives is helpful. I just wanted to make sure I was understanding right. Thanks, Alissa > James > > > >> Thanks, >> Alissa >> >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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 Fri Jul 23 07:11:52 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6DFD93A683E for ; Fri, 23 Jul 2010 07:11:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.564 X-Spam-Level: X-Spam-Status: No, score=-10.564 tagged_above=-999 required=5 tests=[AWL=0.035, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hXn6Ohl0HYmh for ; Fri, 23 Jul 2010 07:11:51 -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 93C823A6876 for ; Fri, 23 Jul 2010 07:11:50 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAA9ASUxAZnwN/2dsb2JhbACfanGmb5sBgm+CRwSIYA Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 23 Jul 2010 14:12:08 +0000 Received: from [10.86.253.215] ([10.86.253.215]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6NEC8C2028797; Fri, 23 Jul 2010 14:12:08 GMT Message-ID: <4C49A337.3010503@cisco.com> Date: Fri, 23 Jul 2010 10:12:07 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "DRAGE, Keith (Keith)" References: <9886E5FCA6D76549A3011068483A4BD4065E732E@S4DE8PSAAQB.mitte.t-com.de> <4C49951C.8050202@cisco.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "sipcore@ietf.org" , "R.Jesske@telekom.de" Subject: Re: [sipcore] Updated 4244bis and new call flow document X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 23 Jul 2010 14:11:52 -0000 Keith, You raise a good point. It forced me to go back and review 3323 and 3325. 3323 defines a "privacy service" which the UAC can use to assist it in obtaining privacy. The UAC is expected to arrange for its requests to be routed through a privacy service. The notion of trust domain is introduced in 3325. It introduces the "id" privacy value, which is to be removed at the boundary of the trust domain, but not before then. It doesn't say anything about where privacy services exist in the network. Its my assumption that there must be a privacy service on the boundary of the trust domain that acts on the "id" privacy type. But this is not explict. And even if this is implied, its hard to say if it would be a full privacy service that can be counted upon to act upon other privacy types in the request. Hence, a UAC that wishes "header" or "session" privacy has nothing better to go on than 3323, which recommends that it route its outbound request directly to a privacy service. If that privacy service is compliant with 4244bis, it will anonymize what is in the H-I header at that time. But then any entries added downstream of that point will not be anonymized. So I think there really is something wrong with the referenced text. If the use of "domain" was intended to be "trust domain" then its dependent on 3325. If it was intended to mean "DNS domain", then its still implying there is a privacy service that will magically be traversed when leaving the DNS domain. Thanks, Paul DRAGE, Keith (Keith) wrote: > If we are going to talk about trust domains in the document, then you will have to say what they are. > > For the RFC 3325 stuff there is most of a document that talks about that. Moreover, you need to say what to "trust" the next entity to do if you do not do it. > > To give some idea of what I mean. Statements like "I will give you the identity if you do not reveal it to anyone outside our area of trust" are slightly different to "I trust you to implement the privacy that I otherwise would have done so if I did not trust you". > > regards > > Keith > >> -----Original Message----- >> From: sipcore-bounces@ietf.org >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat >> Sent: Friday, July 23, 2010 2:12 PM >> To: R.Jesske@telekom.de >> Cc: sipcore@ietf.org >> Subject: Re: [sipcore] Updated 4244bis and new call flow document >> >> >> >> R.Jesske@telekom.de wrote: >>> Hi Mary, >>> With regard to your question for comments/review, I went >> thought the draft. >>> For http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-01.txt >>> >>> I have the following comments: >>> >>> >>> 6.3.2. Privacy in the History-Info Header >>> >>> ... >>> If the requestor has indicated a priv- >>> value of "session" or "header" in the request, all History-Info >>> entries MUST be anonymized when the request leaves a >> domain for which >>> the intermediary is responsible. >>> ... >>> >>> In this section it is mentioned that the entries must be >> anonymized when leaving the domain. I thought that if a trust >> relationship between domains are existing and the following >> domain secures the "privacy" then the information could be >> forwarded and will then deleted by the succeeding domain >> before reaching the terminating user. >>> Some regulators are requesting to pass identities until the >> last domain where it is possible to execute the privacy >> regarding RFC3323. So I think this is a MAY based on domain >> policy. And it is a MUST when the succeeding network cannot >> guarantee the privacy. >>> Or do I misunderstand the meaning of "domain for which the >> intermediary is responsible" >> >> I'm not an expert on this, but ISTM that in the case you >> describe the request is not leaving the *trust* domain. >> >> But that does point out ambiguity in the text you quote. That >> kind of wording "domain for which the intermediary is >> responsible" is usually talking about *DNS* domains, not >> *trust* domains. So maybe that should say: >> >> ... >> If the requestor has indicated a priv-value of "session" or "header" >> in the request, all History-Info entries MUST be anonymized when the >> request leaves a *trust* domain for which the intermediary is >> responsible. >> ... >> >> Thanks, >> Paul >> _______________________________________________ >> sipcore mailing list >> sipcore@ietf.org >> https://www.ietf.org/mailman/listinfo/sipcore >> From jgunn6@csc.com Fri Jul 23 14:39:46 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7EA1D3A67D3; Fri, 23 Jul 2010 14:39:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.17 X-Spam-Level: X-Spam-Status: No, score=-5.17 tagged_above=-999 required=5 tests=[AWL=-0.986, BAYES_40=-0.185, 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 kYk8cYscIYGR; Fri, 23 Jul 2010 14:39:43 -0700 (PDT) Received: from mail168.messagelabs.com (mail168.messagelabs.com [216.82.253.195]) by core3.amsl.com (Postfix) with ESMTP id 7596F3A67E2; Fri, 23 Jul 2010 14:39:43 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-13.tower-168.messagelabs.com!1279921200!23328064!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 10045 invoked from network); 23 Jul 2010 21:40:00 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-13.tower-168.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 23 Jul 2010 21:40:00 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id o6NLdxUM022239; Fri, 23 Jul 2010 17:39:59 -0400 In-Reply-To: References: <99619466-573D-4CEA-ACCD-3A3D262EB2B0@nostrum.com> To: Janet P Gunn MIME-Version: 1.0 X-KeepSent: 83203587:D64E8A92-85257769:0076B37E; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009 From: Janet P Gunn Message-ID: Date: Fri, 23 Jul 2010 17:39:59 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.1FP1 HF440|June 18, 2010) at 07/23/2010 05:40:26 PM, Serialize complete at 07/23/2010 05:40:26 PM Content-Type: multipart/alternative; boundary="=_alternative 007706D485257769_=" Cc: sipcore@ietf.org, sipcore-bounces@ietf.org Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Jul 2010 21:39:46 -0000 This is a multipart message in MIME format. --=_alternative 007706D485257769_= Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: base64 SGVyZSBhcmUgbXkgYWRkaXRpb25hbCBjb21tZW50cw0KDQpUaGUg4oCcYXZlcmFnZSByYXRl4oCd IG1lY2hhbmlzbSB5b3UgZGVzY3JpYmUsIGlzIHJlYWxseSBhbiBhZGFwdGl2ZS9keW5hbWljIA0K dmVyc2lvbiBvZiB0aGUg4oCcbWluaW11bSByYXRl4oCdICBtZWNoYW5pc20uICBUaGV5IGJvdGgg IGNhdXNlIG5vdGlmaWNhdGlvbnMgDQp0byBiZSBzZW50LCBldmVuIHdoZW4gdGhlcmUgaXMgbm90 aGluZyBuZXcgdG8gcmVwb3J0LiAgIFRoZSBkaWZmZXJlbmNlIGlzIA0KSE9XIE9GVEVOIHRoZXNl IG5vbWluYWwgbm90aWZpY2F0aW9ucyBhcmUgc2VudC4gIFdpdGggdGhlIG1pbmltdW0gcmF0ZSAN CmFsZ29yaXRobSwgYWxsIGl0IGxvb2tzIGF0IGlzIOKAnGhvdyBsb25nIHNpbmNlIHRoZSBsYXN0 IG5vdGlmaWNhdGlvbiB3YXMgDQpzZW504oCdLiAgVGhlIGFkYXB0aXZlL2R5bmFtaWMgbWVjaGFu aXNtIGxvb2tzIGF0IHRoZSByYXRlIG9mIG5vdGlmaWNhdGlvbnMgDQpvdmVyIGEgc3BlY2lmaWVk IHBlcmlvZCBpbiBkZXRlcm1pbmluZyB3aGVuIHRvIHNlbmQgdGhlIG5leHQgbm9taW5hbCANCm5v dGlmaWNhdGlvbi4gDQoNCkJ1dCBuZWl0aGVyIHRoZSBtaW5pbXVtIHJhdGUsIG5vciB0aGUgc28g Y2FsbGVkIGF2ZXJhZ2UgcmF0ZSwgbWVjaGFuaXNtIA0Kd2lsbCBjYXVzZSBhIG5vdGlmaWNhdGlv biB0byBiZSBidWZmZXJlZCBvciBkZWxheWVkIGJlY2F1c2UgdGhleSBhcmUgDQpjb21pbmcgdG9v IGZhc3QuDQoNClRoZSDigJxtYXhpbXVtIHJhdGXigJ0gbWVjaGFuaXNtICBjYXVzZXMgbmV3IG5v dGlmaWNhdGlvbnMgdG8gYmUgYnVmZmVyZWQgb3IgDQpkZWxheWVkLCBiYXNlZCBvbiBqdXN0IHRo ZSB0aW1lIHNpbmNlIHRoZSBsYXN0IG5vdGlmaWNhdGlvbiB3YXMgc2VudC4gIEJ1dCANCnRoZXJl IG1heSBiZSBjYXNlcyB3aGVyZSB0aGUgc3Vic2NyaWJlciB3YW50cyB0aGUgZGVsYXkgb3IgYnVm ZmVyaW5nIHRvIGJlIA0KYmFzZWQgb24gdGhlIHJhdGUgb2Ygbm90aWZpY2F0aW9ucyBvdmVyIGEg Z2l2ZW4gcGVyaW9kLg0KDQpUaGlzIGlzIHRoZSB1c2UgY2FzZSBnaXZlbiBpbiAzLjMsIGJ1dCBu b3Qgc3VwcG9ydGVkIGJ5IHNlY3Rpb24gNg0K4oCcd2FudHMgdG8gbWFrZSBhIHN1YnNjcmlwdGlv biB0aGF0IGR5bmFtaWNhbGx5IGluY3JlYXNlcyB0aGUgaW50ZXJ2YWwgDQpiZXR3ZWVuIG5vdGlm aWNhdGlvbnMgaWYgdGhlIHRhcmdldCBoYXMgc2VudCBvdXQgc2V2ZXJhbCBub3RpZmljYXRpb25z IA0KcmVjZW50bHku4oCdDQoNCkl0IHNlZW1zIHRvIG1lIHRoYXQgaXQgd291bGQgbm90IGJlIGhh cmQgdG8gY3JlYXRlIGEgbmV3IGFsZ29yaXRobSAoYW4gDQphZGFwdGl2ZS9keW5hbWljIHZlcnNp b24gb2YgdGhlIG1heGltdW0gcmF0ZSBhbGdvcml0aG0pLCBhbmFsb2dvdXMgdG8gdGhlIA0KYWxn b3JpdGhtIGluIHNlY3Rpb24gNiwgd2hpY2gg4oCcZHluYW1pY2FsbHkgY2FsY3VsYXRlcyB0aGUg bWluaW11bSB0aW1lIA0KYWxsb3dlZCBiZXR3ZWVuIHR3byBub3RpZmljYXRpb25z4oCdLCBhbmQg dGhlbiBkZWxheXMgb3IgYnVmZmVycyB0aGUgDQpub3RpZmljYXRpb24gdW50aWwgdGhhdCB0aW1l Lg0KDQpTZWMgMy00IHJlcXVpcmVtZW50cw0KDQpSZXEgMyBuZWVkcyB0byBiZSBtb2RpZmllZCBz byBpdCByZWZsZWN0cyB3aGF0IHRoZSBtZWNoYW5pc20gYWN0dWFsbHkgZG9lcw0KUGVyaGFwcyDi gJxUaGUgc3Vic2NyaWJlciBtdXN0IGJlIGFibGUgdG8gIHNldCBhbiBvYmplY3RpdmUgY2FkZW5j ZSwgd2hpY2ggDQphZGp1c3QgdGhlIG1heGltdW0gdGltZSBiZXR3ZWVuIHN1Y2Nlc3NpdmUgbm90 aWZpY2F0aW9ucyBiYXNlZCBvbiBhIG1vdmluZyANCmF2ZXJhZ2XigJ0NCg0KUmVxIDcgc2F5cw0K 4oCcVGhlIG5vdGlmaWVyIG11c3QgYmUgYWxsb3dlZCB0byB1c2UgYSBwb2xpY3kgaW4gd2hpY2gg dGhlDQogICAgICAgICAgIG1pbmltdW0gdGltZSBwZXJpb2QgYmV0d2VlbiB0d28gbm90aWZpY2F0 aW9ucyBpcyBhZGp1c3RlZA0KICAgICAgICAgICBmcm9tIHRoZSB2YWx1ZSBnaXZlbiBieSB0aGUg c3Vic2NyaWJlci7igJ0NClN1cmVseSB0aGlzIHNob3VsZCBiZQ0K4oCcVGhlIG5vdGlmaWVyIG11 c3QgYmUgYWxsb3dlZCB0byB1c2UgYSBwb2xpY3kgaW4gd2hpY2ggdGhlDQogICAgICAgICAgIG1p bmltdW0gb3IgbWF4aW11bSB0aW1lIHBlcmlvZCBiZXR3ZWVuIHR3byBub3RpZmljYXRpb25zIGlz IA0KYWRqdXN0ZWQNCiAgICAgICAgICAgZnJvbSB0aGUgdmFsdWUgZ2l2ZW4gYnkgdGhlIHN1YnNj cmliZXIu4oCdDQoNClJlcSA4IHNheXMNCuKAnG1lY2hhbmlzbXMgbXVzdCBkaXNjdXNzIGNvcm5l ciBjYXNlc+KApuKAnSBhbmQg4oCcbWVjaGFuaXNtcyBtdXN0IGluY2x1ZGUgDQpkaXNjdXNzaW9u IG9m4oCm4oCdDQpNZWNoYW5pc21zIGNhbuKAmXQg4oCcZGlzY3Vzc+KAnSBhbnl0aGluZy4NClN1 Z2dlc3Qg4oCcbWVjaGFuaXNtcyBtdXN0IGFkZHJlc3MgY29ybmVyIGNhc2Vz4oCm4oCdIGFuZCAg 4oCcbWVjaGFuaXNtcyBtdXN0IA0KYWRkcmVzcyDigKbigJ0NCg0KDQrigJxTZWMgMy41ICAgVGhl IG1heGltdW0gcmF0ZSBtZWNoYW5pc20gZm9yIFJlc291cmNlIExpc3QgU2VydmVy4oCdDQpJZiB0 aGlzIGlzLCBpbmRlZWQsIHJlc3RyaWN0ZWQgdG8gdGhlIOKAnG1heGltdW0gcmF0ZSBtZWNoYW5p c23igJ0sIGl0IHNob3VsZCANCmJlIG1vdmVkIHRvIHNlY3Rpb24gNC4gDQoNClNlYyA0LjINCldo YXQgZG9lcyB0aGlzIG1lYW4/DQrigJxTdWNoIG5vdGlmaWNhdGlvbnMgcmVzZXQgdGhlIHRpbWVy IGZvciB0aGUgbmV4dA0KICAgbm90aWZpY2F0aW9uLCBldmVuIHRob3VnaCB0aGV5IGRvIG5vdCBu ZWVkIHRvIGFiaWRlIGJ5IGl0LuKAnQ0KDQpTZWMgNC4zDQoNCkhvdyBjYW4gIHNldHRpbmcgYSBt aW5pbXVtIGludGVydmFsICDigJxpbnNpc3QgKHNpYykgYm90aA0KICAgdmVyeSBzaG9ydCBhbmQg dmVyeSBsb25nIGludGVydmFscyBiZXR3ZWVuIG5vdGlmaWNhdGlvbnMu4oCdDQoNCkl0IGlzIGNs ZWFyIHRoYXQgc2V0dGluZyBhIG1pbmltdW0gaW50ZXJ2YWwgd2l0aCBhIGxhcmdlIHZhbHVlIHdp bGwgbGVhZCANCnRvIOKAnHZlcnkgbG9uZyBpbnRlcnZhbHMgYmV0d2VlbiBub3RpZmljYXRpb25z LuKAnQ0KDQpCdXQgc2V0dGluZyBhIG1pbmltdW0gaW50ZXJ2YWwgd2l0aCBhIHNtYWxsICB2YWx1 ZSB3aWxsICBub3QgbmVjZXNzYXJpbHkgDQpsZWFkIHRvIOKAnHZlcnkgc2hvcnQgaW50ZXJ2YWxz IGJldHdlZW4gbm90aWZpY2F0aW9ucy7igJ0NCg0KU2VjdGlvbiA0LjQuMQ0KU2luY2UgZWFjaCBz dWJzY3JpYmVyIG1heSBoYXZlIGEgZGlmZmVyZW50IHZhbHVlIGZvciDigJxtaW5pbXVtLWludGVy dmFs4oCdLCANCmRvZXMgdGhlIG5vdGlmaWVyIG5lZWQgYSBzZXBhcmF0ZSBidWZmZXIgZm9yIGVh Y2ggc3Vic2NyaWJlcj8NCg0KU2VjdGlvbiA3DQrigJxtYXgtaW50ZXJ2YWwgYW5kIGF2ZXJhZ2Ut aW50ZXJ2YWw6ICBhcyBib3RoIHRoZSBwYXJhbWV0ZXJzIGFyZQ0KICAgICAgZGVzaWduZWQgYXMg bWluaW11bSByYXRlIG1lY2hhbmlzbXMsIHRoaXMgY29tYmluYXRpb24gbWFrZXMgc2Vuc2UNCiAg ICAgIG9ubHkgaW4gc29tZSBjb3JuZXIgY2FzZXMuDQoNCiAgICAgIEEgc3Vic2NyaWJlciBTSE9V TEQgY2hvb3NlIGEgIm1heC1pbnRlcnZhbCIgdmFsdWUgaGlnaGVyIHRoYW4gdGhlDQogICAgICAi YXZlcmFnZS1pbnRlcnZhbCIgdmFsdWUsIG90aGVyd2lzZSB0aGUgbm90aWZpZXIgTVVTVCBOT1Qg Y29uc2lkZXINCiAgICAgIHRoZSAibWF4LWludGVydmFsIiB2YWx1ZS7igJ0NCg0KSSBkb27igJl0 IHRoaW5rIGl0IGlzICBhIOKAnWNvcm5lciBjYXNl4oCdIGF0IGFsbC4gIFN1cHBvc2UgSSBoYXZl IGEgIGJlaGF2aW9yIA0KdGhhdCByZXN1bHRzIGluIGludGVydmFscyB3aGVyZSB0aGVyZSBhcmUg dmVyeSBmcmVxdWVudCDigJxyZWFs4oCdIHVwZGF0ZXMgDQooc2F5IG9uY2UgYSBzZWNvbmQpIGFs dGVybmF0aW5nIHdpdGggaW50ZXJ2YWxzIHdoZXJlIHRoZXJlIGFyZSBsb25nZXIgDQppbnRlcnZh bHMgYmV0d2VlbiDigJxyZWFs4oCdIHVwZGF0ZXMgKHNheSBvbiB0aGUgb3JkZXIgb2YgbWludXRl cykuIA0KDQpTdXBwb3NlIEkgd2FudCBhbiBhdmVyYWdlIChkeW5hbWljIG1pbmltdW0pIHJhdGUg b2Ygb25lIHVwZGF0ZSBwZXIgNSANCnNlY29uZHMuICBEZXBlbmRpbmcgb24gdGhlIGxlbmd0aCBv ZiB0aGUgcGVyaW9kLCBhdCB0aGUgZW5kIG9mIHRoZSANCuKAnGZyZXF1ZW50IHVwZGF0ZeKAnSBp bnRlcnZhbCwgdGhpcyBjb3VsZCByZXN1bHQgaW4gYSB2ZXJ5IGxhcmdlIHZhbHVlIG9mIHRoZSAN CuKAnHRpbWVvdXTigJ0sIHJlc3VsdGluZyBpbiAgYSBtaW51dGUgb3IgbW9yZSBiZWZvcmUgdGhl IG5leHQgDQp0aW1lb3V0LWdlbmVyYXRlZCAgdXBkYXRlLiAgSSBkb27igJl0IHdhbnQgdG8gd2Fp dCBUSEFUIGxvbmcuICBJbiBmYWN0LCBJIA0Kd2FudCBhbiB1cGRhdGUgYXQgbGVhc3Qgb25jZSBl dmVyeSAxMCBzZWNvbmRzLg0KDQpTbyBJIHNldCBteSDigJxhdmVyYWdlLWludGVydmFs4oCdIHRv IDUgc2VjLCBhbmQgbXkg4oCcbWF4aW11bSBpbnRlcnZhbOKAnSB0byAxMCANCnNlYy4NCg0KSW4g dGhlIHBlcmlvZCBpbW1lZGlhdGVseSBhZnRlciAgdGhlIGVuZCBvZiBhbiDigJxhY3RpdmXigJ0g aW50ZXJ2YWwsIEkgd2lsbCANCmdldCB0aW1lLW91dCBnZW5lcmF0ZWQgdXBkYXRlcyBldmVyeSAx MCBzZWNvbmRzIChiZWNhdXNlIHRoZSB0aW1lb3V0IA0KZ2VuZXJhdGVkIGJ5IHRoZSDigJxhdmVy YWdl4oCdIG1lY2hhbmlzbSBpcyBncmVhdGVyIHRoYW4gMTAgc2Vjb25kcykuICBCdXQgDQpvbmNl IHdlIGFyZSB3ZWxsIGludG8gdGhlIOKAnGluYWN0aXZl4oCdIGludGVydmFsLCB0aGUgdGltZW91 dCAgZ2VuZXJhdGVkIGJ5IA0KdGhlIOKAnGF2ZXJhZ2XigJ0gbWVjaGFuaXNtIHdpbGwgY29udmVy Z2UgdG8gNSBzZWNvbmRzLiAgVGhpcyBzZWVtcyB0byBtZSB0byANCmJlIGF0IGxlYXN0IGFzIHVz ZWZ1bCBhcyB0aGUgdXNlIGNhc2VzIGZvciBjb21iaW5pbmcgbWF4IGFuZCBtaW4sIG9yIG1pbiAN CmFuZCBhdmVyYWdlLg0KDQpTZXQgOC4yDQpXaGF0IGFib3V0IOKAnHBlcmlvZOKAnT8NCg0KDQpO SVRTDQoNCkkgYW0gbm90IHN1cmUgd2hhdCB5b3UgYXJlIHRyeWluZyB0byBzYXkgaGVyZSAoc2Vj IDMuMSk6DQrigJxBcHBsaWNhdGlvbiBvZiB0aGUgbWVjaGFuaXNtIGRlZmluZWQgYnkgUkZDIDU4 MzkgW1JGQzU4MzldDQogICBjYW4gYWxzbyBlbGltaW5hdGUgZm9yIHRoZSBwcmVzZW5jZSBjbGll bnQgdG8gcmVjZWl2ZSBhIChmdWxsLXN0YXRlKQ0KICAgbm90aWZpY2F0aW9uIGNhcnJ5aW5nIHRo ZSBsYXRlc3QgcmVzb3VyY2Ugc3RhdGUgYWZ0ZXIgdGhlDQogICBzdWJzY3JpcHRpb24gcmVmcmVz aC7igJ0NClBlcmhhcHMNCuKAnEFwcGxpY2F0aW9uIG9mIHRoZSBtZWNoYW5pc20gZGVmaW5lZCBi eSBSRkMgNTgzOSBbUkZDNTgzOV0NCiAgIGNhbiBhbHNvIGVsaW1pbmF0ZSB0aGUgbmVlZCBmb3Ig dGhlIHByZXNlbmNlIGNsaWVudCB0byByZWNlaXZlIGEgDQooZnVsbC1zdGF0ZSkNCiAgIG5vdGlm aWNhdGlvbiwgY2FycnlpbmcgdGhlIGxhdGVzdCByZXNvdXJjZSBzdGF0ZSwgYWZ0ZXIgdGhlDQog ICBzdWJzY3JpcHRpb24gcmVmcmVzaC7igJ0NCk9yDQrigJxBcHBsaWNhdGlvbiBvZiB0aGUgbWVj aGFuaXNtIGRlZmluZWQgYnkgUkZDIDU4MzkgW1JGQzU4MzldDQogICBjYW4gYWxzbyBlbGltaW5h dGUgdGhlIHRyYW5zbWlzc2lvbiBvZiAgYSAoZnVsbC1zdGF0ZSkNCiAgIG5vdGlmaWNhdGlvbiBj YXJyeWluZyB0aGUgbGF0ZXN0IHJlc291cmNlIHN0YXRlIHRvICB0aGUgcHJlc2VuY2UgY2xpZW50 IA0KIGFmdGVyIHRoZQ0KICAgc3Vic2NyaXB0aW9uIHJlZnJlc2gu4oCdIA0KDQogU2VjIDMuMg0K UmVwbGFjZSDigJxjcml0ZXJpYXPigJ0gd2l0aCDigJxjcml0ZXJpYeKAnSAoY3JpdGVyaWEgaXMg YWxyZWFkeSB0aGUgcGx1cmFsKS4NCg0K4oCcaS5lLiBoYXMgbm90IG1vdmVkIGF0IGxlYXN0IG4g bWV0ZXJzIHdpdGhpbiB0aGUgcGVyaW9kLuKAnSANClNob3VsZCBiZSANCuKAnGUuZy4gaGFzIG5v dCBtb3ZlZCBhdCBsZWFzdCBuIG1ldGVycyB3aXRoaW4gdGhlIHBlcmlvZC7igJ0NCg0KU2VjIDMu NA0KUmVxIDQNCkNoYW5nZSANCuKAnEl0IG11c3QgYmUgcG9zc2libGUgdG8gYXBwbHkgYWxsIHRv Z2V0aGVyLCBvciBpbiBhbnkNCiAgICAgICAgICAgY29tYmluYXRpb24sIHRoZSAibWluLWludGVy dmFsIiwgIm1heC1pbnRlcnZhbCIgYW5kICJhdmVyYWdlLQ0KICAgICAgICAgICBpbnRlcnZhbCIg bWVjaGFuaXNtcyBpbiBhIHNwZWNpZmljIHN1YnNjcmlwdGlvbi7igJ0NClRvIA0K4oCcSXQgbXVz dCBiZSBwb3NzaWJsZSB0byBhcHBseSB0aGUgIm1pbi1pbnRlcnZhbCIsICJtYXgtaW50ZXJ2YWwi IGFuZCANCiJhdmVyYWdlLQ0KICAgICAgICAgICBpbnRlcnZhbCIgbWVjaGFuaXNtcyAgYWxsIHRv Z2V0aGVyLCBvciBpbiBhbnkgIGNvbWJpbmF0aW9uLCBpbiANCmEgc3BlY2lmaWMgc3Vic2NyaXB0 aW9uLuKAnQ0KDQpSZXEgNQ0KQ2hhbmdlIA0K4oCcSXQgbXVzdCBiZSBwb3NzaWJsZSB0byB1c2Ug b2YgdGhlIGRpZmZlcmVudCByYXRlIGNvbnRyb2wgbWVjaGFuaXNtc+KApuKAnQ0KVG8NCuKAnEl0 IG11c3QgYmUgcG9zc2libGUgdG8gdXNlIGFueSBvZiB0aGUgZGlmZmVyZW50IHJhdGUgY29udHJv bCBtZWNoYW5pc21z4oCm4oCdDQoNClJlcSA2DQpDaGFuZ2Ug4oCcSXQgbXVzdCBiZSBwb3NzaWJs ZSB0byB1c2UgdGhlIGRpZmZlcmVudCByYXRlIGNvbnRyb2wgbWVjaGFuaXNtc+KApuKAnQ0KVG8N Ckl0IG11c3QgYmUgcG9zc2libGUgdG8gdXNlIGFueSBvZiB0aGUgZGlmZmVyZW50IHJhdGUgY29u dHJvbCBtZWNoYW5pc21z4oCm4oCdDQoNCg0KU2VjIDMuNQ0K4oCcV2UgY2FuIG1vZGVsIHRoZSBu b3RpZmllcg0KICAgYXMgY29uc2lzdGluZyBvZiB0aHJlZSBjb21wb25lbnRzOiB0aGUgZXZlbnQg c3RhdGUgcmVzb3VyY2UocyksIHRoZQ0KICAgUmVzb3VyY2UgTGlzdCBTZXJ2ZXIgKFJMUykgKG9y IGFueSBvdGhlciBub3RpZmllciksIGEgbm90aWZpY2F0aW9uDQogICBidWZmZXIsIGFuZCBmaW5h bGx5IHRoZSBzdWJzY3JpYmVyLCBvciB3YXRjaGVyIG9mIHRoZSBldmVudCBzdGF0ZSwgYXMNCiAg IHNob3duIGluIEZpZ3VyZSAxLuKAnQ0KDQpUaGF0IGlzIEZPVVIsIG5vdCB0aHJlZS4NCg0KU2Vj dGlvbiA3IChhdCBsZWFzdCB0d28gcGxhY2VzKQ0KDQpDaGFuZ2UgDQrigJx0byBhIHZhbHVlIGVx dWl2YWxlbnQgb3IgaGlnaGVyIHRoYW4g4oCm4oCdDQp0bw0K4oCcdG8gYSB2YWx1ZSBlcXVhbCB0 byBvciBoaWdoZXIgdGhhbuKApuKAnQ0KDQpUaGFua3MsDQoNCkphbmV0DQoNCg0KDQpzaXBjb3Jl LWJvdW5jZXNAaWV0Zi5vcmcgd3JvdGUgb24gMDcvMTkvMjAxMCAwMzozOTo1NSBQTToNCg0KPiBb aW1hZ2UgcmVtb3ZlZF0gDQo+IFJlOiBbc2lwY29yZV0gQUQgcmV2aWV3OiBkcmFmdC1pZXRmLXNp cGNvcmUtZXZlbnQtcmF0ZS1jb250cm9sLTA0DQo+IEphbmV0IFAgR3VubiANCj4gdG86IGtyaXN6 dGlhbi5raXNzDQo+IDA3LzE5LzIwMTAgMDM6NDAgUE0NCj4gU2VudCBieTogc2lwY29yZS1ib3Vu Y2VzQGlldGYub3JnDQo+DQo+ID4gDQo+ID4gSSBzdWJtaXR0ZWQgdGhlIC0wNCB2ZXJzaW9uIHRv ZGF5IGFkZHJlc3NpbmcgeW91ciBjb21tZW50czogaHR0cDovLw0KPiA+IHd3dy5pZXRmLm9yZy9p ZC9kcmFmdC1pZXRmLXNpcGNvcmUtZXZlbnQtcmF0ZS1jb250cm9sLTA0LnR4dCANCj4gDQo+IFRo YW5rIHlvdSBmb3IgaW5jbHVkaW5nIG1lIGluIHRoZSBhY2tub3dsZWRnZW1lbnRzLiANCj4gDQo+ IEkgZmluZCB0aGF0IHNvbWUsIGJ1dCBub3QgYWxsLCBvZiBteSBjb21tZW50cyBoYXZlIGJlZW4g YWRkcmVzc2VkLiANCj4gSSBhbSByZXBlYXRpbmcgdGhlIG9uZXMgd2hpY2ggc3RpbGwgY2F1c2Ug Y29uZnVzaW9uLiANCj4gDQo+IEZpcnN0IGxldCBtZSBzYXkgdGhhdCBJIHRoaW5rIHRoaXMgaXMg YSB2ZXJ5IHVzZWZ1bCBtZWNoYW5pc20uICBNeSANCj4gY29uY2VybnMgYXJlIHByaW1hcmlseSBp biB0aGUgd2F5IHRoZSBtZWNoYW5pc20gaXMgZGVzY3JpYmVkLiANCj4gDQo+IA0KPiA+V2hpbGUg 4oCcbWF4LWludGVydmFs4oCdIGlzIHN5bm9ueW1vdXMgd2l0aCDigJxtaW5pbXVtIHJhdGXigJ0s IGFuZCDigJxtaW4tDQo+IGludGVydmFs4oCdIGlzIHN5bm9ueW1vdXMgd2l0aCDigJxtYXhpbXVt IHJhdGXigJ0sIHRoZSBjb25zdGFudCBzd2l0Y2hpbmcgDQo+IGJhY2sgYW5kIGZvcnRoIGJldHdl ZW4gdGhlIHR3byBzZXRzIG9mIHRlcm1pbm9sb2d5IG1ha2VzIGl0IHZlcnkgDQo+IGRpZmZpY3Vs dCB0byBmb2xsb3cuIA0KPiANCj4gW0pQR10gdGhpcyBpcyBzdGlsbCBhbiBpc3N1ZS4gIFNlY3Rp b25zIDQsIDUsIGFuZCA2IGFyZSB0aXRsZWQgIi4uLi0NCj4gcmF0ZSBiZWhhdmlvciIsIGJ1dCBz ZWN0aW9uIDcgaXMgdGl0bGVkIC4uLi1pbnRlcnZhbC4gDQo+IA0KPiBbSlBHXSBJZiB5b3UganVz dCBjaGFuZ2UgdGhlIHRpdGxlIG9mIHNlY3Rpb24gNyB0byANCj4gVXNhZ2Ugb2YgIm1heGltdW0g cmF0ZSIsICJtaW5pbXVtIHJhdGUiIGFuZCAiYXZlcmFnZSByYXRlIiBpbiBhIA0KY29tYmluYXRp b24gDQo+IGl0IHdvdWxkIGJlIE1VQ0ggY2xlYXJlci4gDQo+IA0KPiANCj4gPlRoZSBkZXNjcmlw dGlvbiBvZiB0aGUgaW50ZW5kZWQgZWZmZWN0IG9mIHRoZSDigJxhdmVyYWdlLWludGVydmFs4oCd IGlzDQo+IHVuY2xlYXIgYW5kIGluY29uc2lzdGVudC4gDQo+IA0KPiA+SW4gdGhlIGludHJvZHVj dGlvbiwgaXQgc2F5cyANCj4g4oCcICAgYXZlcmFnZS1pbnRlcnZhbDogIHNwZWNpZmllcyBhbiBh dmVyYWdlIGNhZGVuY2UgYXQgd2hpY2ggDQo+IG5vdGlmaWNhdGlvbnMgYXJlIGRlc2lyZWQsIGlu IHNlY29uZHMu4oCdIA0KPiANCj4gW0pQR10gVGhlIEludHJvZHVjdGlvbiBTVElMTCBTQVlTIHRo aXMuIEJ1dCB0aGF0IGlzIG5vdCB3aGF0IHRoYXQgDQo+IG1lY2hhbmlzbSBkb2VzLiANCj4gDQo+ IFtKUEddIElmIHRoZSBzdWJzY3JpYmVyJ3MgZGVzaXJlZCAiYXZlcmFnZSIgaXMgIm9uZSBub3Rp ZmljYXRpb24gDQo+IGV2ZXJ5IDUgc2Vjb25kcyIsIGFuZCB0aGUgIG5vdGlmaWVyIGhhcyBhIG5v dGlmaWNhdGlvbiByZWFkeSB0byBzZW5kDQo+IGV2ZXJ5IHNlY29uZCwgaXQgaXMgZ29pbmcgdG8g c2VuZCB0aGUgbm90aWZpY2F0aW9uIG91dCBvbmNlIGEgDQo+IHNlY29uZC4gIFVuZGVyIHRoZSBk ZXNjcmliZWQgYWxnb3JpdGhtLCB0aGUgbm90aWZpZXIgd2lsbCBOT1QgZGVsYXksDQo+IG5vciBi dWZmZXIsIG5vdGlmaWNhdGlvbnMgdG8gYXBwcm9hY2ggdGhlIGRlc2lyZWQvc3BlY2lmaWVkICJh dmVyYWdlIiANCj4gDQo+IFtKUEddIEluIGZhY3QsIHRoZSBtZWNoYW5pc20gZGVzY3JpYmVkIGlu IHNlY3Rpb24gNiBpcyBhbiBBREFQVElWRSANCj4gdmFyaWFudCBvZiB0aGUgbWluaW11bS1yYXRl IChtYXhpbXVtLWludGVydmFsKSBtZWNoYW5pc20uIA0KPiANCj4gW0pQR10gUGVyc29uYWxseSwg SSB3b3VsZCBwcmVmZXIgdG8gc2VlIHRoZSBuYW1lIG9mIHRoZSBtZWNoYW5pc20gDQo+IGNoYW5n ZWQgdG8gImFkYXB0aXZlLW1pbmltdW0tcmF0ZSIgaW5zdGVhZCBvZiAiYXZlcmFnZS1yYXRlIi4g IEJ1dCANCj4gZXZlbiBpZiB5b3UgZG9uJ3QgZG8gdGhhdCwgeW91IG5lZWQgdG8gY2hhbmdlIHRo ZSB0ZXh0IHNvIHRoYXQgeW91IA0KPiBhcmUgbm8gbG9uZ2VyIG1pc3JlcHJlc2VudGluZyB0aGUg YWxnb3JpdGhtLiANCj4gDQo+IA0KPiA+SW4gc2VjdGlvbiAzLjMsIFVzZSBDYXNlIGZvciBzcGVj aWZ5aW5nIHRoZSBhdmVyYWdlIHJhdGUgb2YgDQo+IG5vdGlmaWNhdGlvbnMsIGl0IGlzIGNvbnRy YWRpY3RvcnkuICBGaXJzdCBpdCBzYXlzIA0KPiA+4oCcZHluYW1pY2FsbHkgaW5jcmVhc2VzIHRo ZSBpbnRlcnZhbCBiZXR3ZWVuIG5vdGlmaWNhdGlvbnMgaWYgdGhlIA0KPiB0YXJnZXQgaGFzIHNl bnQgb3V0IHNldmVyYWwgbm90aWZpY2F0aW9ucyA+cmVjZW50bHku4oCdICBUaGlzIGlzIGFuIA0K PiBJTkNSRUFTRSBpbiB0aGUgaW50ZXJ2YWwuIA0KPiANCj4gW0pQR10gVGhpcyB0ZXh0IGFib3V0 IHRoaXMgdXNlIGNhc2UgIEFMU08gc2F5cyAiSW4gb3JkZXIgdG8gZGVjcmVhc2UNCj4gdGhlIHBy b2Nlc3NpbmcgYW5kIG5ldHdvcmsgbG9hZCIgDQo+IA0KPiBbSlBHXSAgVGhlIHRleHQgc3RpbGwg c2F5cyB0aGlzLiAgQnV0IHRoZSBtZWNoYW5pc20gYW5kIGZvcm11bGEgeW91IA0KPiBkZXNjcmli ZSBpbiBzZWN0aW9uIDYgV0lMTCBOT1QgImluY3JlYXNlIHRoZSBpbnRlcnZhbCBiZXR3ZWVuIA0K PiBub3RpZmljYXRpb25zIGlmIHRoZSB0YXJnZXQgaGFzIHNlbnQgb3V0IHNldmVyYWwgbm90aWZp Y2F0aW9ucyANCj4gcmVjZW50bHkuIiAgSXQgb25seSBERUNSRUFTRVMgdGhlIGludGVydmFsIGJl dHdlZW4gbm90aWZpY2F0aW9ucy4gDQo+IA0KPiBbSlBHXSBJdCBpcyB0cnVlIHRoYXQgaXQgd2ls bCBERUNSRUFTRSB0aGUgaW50ZXJ2YWwgIExFU1MgaWYgdGhlcmUgDQo+IGhhdmUgYmVlbiBzZXZl cmFsIHJlY2VudCBub3RpZmljYXRpb25zLiAgQnV0IHRoYXQgaXMgcXVpdGUgZGlmZmVyZW50DQo+ IGZyb20gSU5DUkVBU0lORyB0aGUgaW50ZXJ2YWwuIA0KPiANCj4gW0pQR10gVGhpcyB0ZXh0IGFi b3V0IHRoaXMgdXNlIGNhc2UgQUxTTyBzYXlzICJJbiBvcmRlciB0byBkZWNyZWFzZSANCj4gdGhl IHByb2Nlc3NpbmcgYW5kIG5ldHdvcmsgbG9hZCIuICBUaGUgYWxnb3JpdGhtIGluIHNlY3Rpb24g NiB3aWxsIA0KPiBOT1QgImRlY3JlYXNlIHByb2Nlc3NpbmcgYW5kIG5ldHdvcmsgbG9hZC4gIEl0 IHdpbGwgSU5DUkVBU0UgDQo+IHByb2Nlc3NpbmcgYW5kIG5ldHdvcmsgbG9hZC4gDQo+IA0KPiBb SlBHXSBIZXJlIGlzIG15IHN1Z2dlc3RlZCByZXdyaXRlIG9mIHRoZSB1c2UgY2FzZSBmb3IgMy4z LCBiYXNlZCBvbg0KPiB0aGUgdXNlIGNhc2UgaW4gMy4yLCBzbyBpdCBjb3JyZXNwb25kcyB0byB0 aGUgYWxnb3JpdGhtIGluIHNlY3Rpb24gNg0KPiAoYWRkZWQgdGV4dCBpbiBBTEwgQ0FQUykuIA0K PiAgICJBIHRyYWNraW5nIGFwcGxpY2F0aW9uIGlzIG1vbml0b3JpbmcgdGhlIG1vdmVtZW50IG9m IGEgdGFyZ2V0LiANCj4gDQo+ICAgIEluIG9yZGVyIHRvIGRlY3JlYXNlIHRoZSBwcm9jZXNzaW5n IGFuZCBuZXR3b3JrIGxvYWQsIHRoZSB0cmFja2luZyANCj4gICAgYXBwbGljYXRpb24gaGFzIG1h ZGUgYSBzdWJzY3JpcHRpb24gd2l0aCBhIHNldCBvZiBsb2NhdGlvbiBmaWx0ZXJzIA0KPiAgICB0 aGF0IHNwZWNpZnkgdHJpZ2dlciBjcml0ZXJpYSwgZm9yIA0KPiAgICBleGFtcGxlLCB0byBzZW5k IGFuIHVwZGF0ZSBvbmx5IHdoZW4gdGhlIHRhcmdldCBoYXMgbW92ZWQgYXQgbGVhc3QgbiANCj4g ICAgbWV0ZXJzLiAgSG93ZXZlciwgdGhlIGFwcGxpY2F0aW9uIGlzIGFsc28gaW50ZXJlc3RlZCBp biByZWNlaXZpbmcgdGhlIA0KDQo+ICAgIGN1cnJlbnQgc3RhdGUgcGVyaW9kaWNhbGx5IGV2ZW4g aWYgdGhlIHN0YXRlIG9mIHRoZSB0YXJnZXQgaGFzIG5vdCANCj4gICAgY2hhbmdlZCBlbm91Z2gg dG8gc2F0aXNmeSBhbnkgb2YgdGhlIHRyaWdnZXIgY3JpdGVyaWEsIGUuZy4sIGhhcyBub3QgDQo+ ICAgIG1vdmVkIGF0IGxlYXN0IG4gbWV0ZXJzIHdpdGhpbiB0aGUgcGVyaW9kLiANCj4gDQo+ICAg IEhPV0VWRVIsIElGIFRIRVJFIEhBVkUgQkVFTiBGRVcgUkVDRU5UIFVQREFURVMsIFRIRSBTVUJT Q1JJQkVSIA0KPiAgICBXT1VMRCBMSUtFIE5PTUlOQUwgVVBEQVRFUyBNT1JFIEZSRVFVRU5UTFkg VEhBTiBXSEVOIFRIRVJFIEhBVkUgQkVFTiANCj4gICAgTUFOWSBSRUNFTlQgVVBEQVRFUy4gDQo+ IA0KPiAgICBJbiBvcmRlciB0byBjb250cm9sIHRoZSBhY3R1YWwgc3RhdGUsIHRoZSBsb2NhdGlv biBhcHBsaWNhdGlvbiBzZXRzIA0KPiAgICBhTiBBREFQVElWRSBtaW5pbXVtIHJhdGUgKEEgIlRJ TUUtT1VUIiBwYXJhbWV0ZXIpLCBpLmUuIGEgbWF4aW11bSANCnRpbWUgDQo+ICAgIGludGVydmFs IGJldHdlZW4gdHdvIG5vdGlmaWNhdGlvbnMsIFdISUNIIEFEQVBUUywgQkFTRUQgT04gVEhFIFJF Q0VOVCANCg0KPiAgICBISVNUT1JZIE9GIFVQREFURVMuIA0KPiANCj4gICAgV0hFTiBUSEVSRSBI QVZFIEJFRU4gQSBMT1QgT0YgUkVDRU5UIFVQREFURVMsIFRIRSANCj4gICAgQUxHT1JJVEhNIElO Q1JFQVNFUyBUSEUgIlRJTUUtT1VUIiBJTlRFUlZBTCwgU08gVEhFIENPTUJJTkFUSU9OIE9GIA0K PiAgICAiUkVBTCIgKFRSSUdHRVJFRCBCWSBVUERBVEVEIElORk9STUFUSU9OKSBBTkQgIk5PTUlO QUwiIChUUklHR0VSRUQgQlkgDQoNCj4gICAgVEhFIFRJTUUtT1VUKSBVUERBVEVTIENPTlZFUkdF IFRPIFRIRSAgU1BFQ0lGSUVEIEFWRVJBR0UgUkFURS4gDQo+IA0KPiAgICBCVVQgV0hFTiBUSEVS RSBBUkUgRlJFUVVFTlQgIlJFQUwiIFVQREFURVMsIFRIRSBBTEdPUklUSE0gRE9FUyBOT1QgDQo+ ICAgIERFTEFZIE9SIEJVRkZFUiBUSEVTRSBOT1RJRklDQVRJT05TLiAgSU4gVEhJUyBDQVNFLCBU SEUgUkFURSBPRiANClVQREFURVMgDQo+ICAgIFdJTEwgTk9UIENPTlZFUkdFIFRPIFRIRSBTUEVD SUZJRUQgQVZFUkFHRSBSQVRFLiANCj4gDQo+IFtKUEddIGFuZCBmcm9tIHRoZSBvcmlnaW5hbCAz LjMgDQo+ICAgIFRoaXMgdHlwZSBvZiByYXRlIGNvbnRyb2wgYWxsb3dzIHRoZSBub3RpZmllciB0 byBkeW5hbWljYWxseSBpbmNyZWFzZSANCg0KPiAgICB0aGUgTm90aWZpY2F0aW9uIGZyZXF1ZW5j eS4gKFJFTU9WRUQgIm9yIGRlY3JlYXNlIikgDQo+IA0KPiAgICBUaGUgdHJhY2tpbmcgYXBwbGlj YXRpb24gY2FuIGFsc28gbW9kaWZ5IHRoZSAiYXZlcmFnZS1pbnRlcnZhbCIgDQo+ICAgIHBhcmFt ZXRlciBkdXJpbmcgdGhlIGxpZmV0aW1lIG9mIHRoZSBzdWJzY3JpcHRpb24uIA0KPiANCj4gDQo+ IFtKUEddIElmIHlvdSBtYWtlIHRoZXNlIGNoYW5nZXMgdG8gdGhlIHVzZS1jYXNlLCB0aGVuIHRo ZSB1c2UgY2FzZSANCj4gd2lsbCBiZSBjb25zaXN0ZW50IHdpdGggbW9zdCBvZiB0aGUgdGV4dCBp biBzZWN0aW9uIDYuIA0KPiANCj4gPldoZW4gd2UgZ2V0IHRvIHRoZSBmb3JtdWxhZSBhbmQgdGhl IGRldGFpbGVkIG1lY2hhbmljcywgaXQgaXMgY2xlYXINCj4gdGhhdCB0aGlzIGFwcHJvYWNoIHdp bGwgb25seSBldmVyIERFQ1JFQVNFIHRoZSBpbnRlcnZhbCBiZXR3ZWVuIA0KPiBub3RpZmljYXRp b25zICAoZnJvbSB3aGF0IGl0IHdvdWxkIGJlIHdpdGhvdXQgRXZlbnQgUmF0ZSBDb250cm9sKSwg DQo+IGl0IHdpbGwgbmV2ZXIgSU5DUkVBU0UgdGhlIGludGVydmFsIGJldHdlZW4gbm90aWZpY2F0 aW9ucyAgKGZyb20gDQo+IHdoYXQgaXQgd291bGQgYmUgd2l0aG91dCBFdmVudCBSYXRlIENvbnRy b2wpLiANCj4gDQo+IFtKUEddIFRoaXMgY29tbWVudCB3aWxsIGJlIHJlc29sdmVkIGlmIHlvdSBj aGFuZ2UgdGhlIHRleHQgaW4gdGhlIFVzZSANCkNhc2UuIA0KPiANCj4gPkZ1cnRoZXJtb3JlLCBp biB0aGUgZGVzY3JpcHRpb24gb2YgdGhlIOKAnGF2ZXJhZ2UtaW50ZXJ2YWzigJ0gDQo+IG1lY2hh bmlzbSwgdGhlcmUgbmVlZHMgdG8gYmUgZWl0aGVyIGEg4oCcTVVTVOKAnSBvciBhIOKAnFNIT1VM ROKAnSB0byBlbnN1cmUNCj4gdGhhdCDigJxwZXJpb2TigJ0gaXMgR1JFQVRFUiBUSEFOIHRoZSDi gJxhdmVyYWdlLWludGVydmFs4oCdLiAgT3RoZXJ3aXNlIHRoZQ0KPiBkZXNjcmliZWQgbWVjaGFu aXNtIHdpbGwgc2VuZCBvdXQgYSBub3RpZmljYXRpb24gZXZlcnkg4oCccGVyaW9k4oCdIA0KPiBz ZWNvbmRzLCByZWdhcmRsZXNzIG9mIHRoZSB2YWx1ZSBvZiDigJxhdmVyYWdlLWludGVydmFs4oCd LiANCj4gDQo+IFtKUEddIFlvdSBhZGRyZXNzZWQgdGhpcywgd2l0aCB0aGUgdGV4dCANCj4gICAg ICAgIlRoZSB2YWx1ZSBvZiB0aGUgDQo+ICAgICAgICJwZXJpb2QiIHBhcmFtZXRlciBNVVNUIGJl IGdyZWF0ZXIgdGhhbiB0aGUgdmFsdWUgb2YgdGhlICJhdmVyYWdlLSANCg0KPiAgICAgICBpbnRl cnZhbCIgcGFyYW1ldGVyLiIgDQo+IEhvd2V2ZXIsIHNpbmNlIG9ubHkgdGhlICJhdmVyYWdlLWlu dGVydmFsIiBwYXJhbWV0ZXIgaXMgdW5kZXIgdGhlIA0KPiBjb250cm9sIG9mIHRoZSBzdWJzY3Jp YmVyLCBpdCB3b3VsZCBtYWtlIG1vcmUgc2Vuc2UgdG8gcHV0IGl0IGluIHRoZQ0KPiAiYXZlcmFn ZS1pbnRlcnZhbCIgZGVmaW5pdGlvbiwgYW5kIHNheSANCj4gICAgICAgIlRoZSB2YWx1ZSBvZiB0 aGUgImF2ZXJhZ2UtaW50ZXJ2YWwiIHBhcmFtZXRlciBNVVNUIGJlIGxlc3MgDQo+IHRoYW4gdGhl IHZhbHVlIG9mIHRoZSANCj4gICAgICAgInBlcmlvZCIgcGFyYW1ldGVyLiIgDQo+IGFuZCB0YWtl IHRoZSBjb3JyZXNwb25kaW5nICB0ZXh0IG91dCBvZiB0aGUgInBlcmlvZCIgc3BlY2lmaWNhdGlv bi4gDQo+IA0KPiBJIHdpbGwgYWxzbyBiZSBzZW5kaW5nIGFub3RoZXIgZW1haWwgd2l0aCBzb21l IG5ldyBjb21tZW50cy8NCj4gcXVlc3Rpb25zLCBhbmQgYW5vdGhlciBvbmUgd2l0aCBhIGJ1bmNo IG9mIG5pdHMuIA0KPiANCj4gVGhhbmtzLiANCj4gDQo+IEFuZCBhZ2FpbiwgSSByZWFsbHkgZG8g dGhpbmsgdGhpcyBpcyBhIHVzZWZ1bCBtZWNoYW5pc20sIHdlIGp1c3QgDQo+IG5lZWQgdG8gbWFr ZSB0aGUgdGV4dCBjb25zaXN0ZW50LiANCj4gDQo+IEphbmV0IF9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+IHNp cGNvcmVAaWV0Zi5vcmcNCj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z aXBjb3JlDQoNCg== --=_alternative 007706D485257769_= Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: base64 DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9InNhbnMtc2VyaWYiPkhlcmUgYXJlIG15IGFkZGl0aW9u YWwgY29tbWVudHM8L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmki PlRoZSDigJxhdmVyYWdlIHJhdGXigJ0gbWVjaGFuaXNtIHlvdSBkZXNjcmliZSwNCmlzIHJlYWxs eSBhbiBhZGFwdGl2ZS9keW5hbWljIHZlcnNpb24gb2YgdGhlIOKAnG1pbmltdW0gcmF0ZeKAnSAm bmJzcDttZWNoYW5pc20uDQombmJzcDtUaGV5IGJvdGggJm5ic3A7Y2F1c2Ugbm90aWZpY2F0aW9u cyB0byBiZSBzZW50LCBldmVuIHdoZW4gdGhlcmUgaXMNCm5vdGhpbmcgbmV3IHRvIHJlcG9ydC4g Jm5ic3A7IFRoZSBkaWZmZXJlbmNlIGlzIEhPVyBPRlRFTiB0aGVzZSBub21pbmFsDQpub3RpZmlj YXRpb25zIGFyZSBzZW50LiAmbmJzcDtXaXRoIHRoZSBtaW5pbXVtIHJhdGUgYWxnb3JpdGhtLCBh bGwgaXQgbG9va3MNCmF0IGlzIOKAnGhvdyBsb25nIHNpbmNlIHRoZSBsYXN0IG5vdGlmaWNhdGlv biB3YXMgc2VudOKAnS4gJm5ic3A7VGhlIGFkYXB0aXZlL2R5bmFtaWMNCm1lY2hhbmlzbSBsb29r cyBhdCB0aGUgcmF0ZSBvZiBub3RpZmljYXRpb25zIG92ZXIgYSBzcGVjaWZpZWQgcGVyaW9kIGlu DQpkZXRlcm1pbmluZyB3aGVuIHRvIHNlbmQgdGhlIG5leHQgbm9taW5hbCBub3RpZmljYXRpb24u ICZuYnNwOzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+QnV0 IG5laXRoZXIgdGhlIG1pbmltdW0gcmF0ZSwgbm9yIHRoZSBzbw0KY2FsbGVkIGF2ZXJhZ2UgcmF0 ZSwgbWVjaGFuaXNtIHdpbGwgY2F1c2UgYSBub3RpZmljYXRpb24gdG8gYmUgYnVmZmVyZWQNCm9y IGRlbGF5ZWQgYmVjYXVzZSB0aGV5IGFyZSBjb21pbmcgdG9vIGZhc3QuPC9mb250Pg0KPGJyPg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5UaGUg4oCcbWF4aW11bSByYXRl4oCdIG1l Y2hhbmlzbSAmbmJzcDtjYXVzZXMNCm5ldyBub3RpZmljYXRpb25zIHRvIGJlIGJ1ZmZlcmVkIG9y IGRlbGF5ZWQsIGJhc2VkIG9uIGp1c3QgdGhlIHRpbWUgc2luY2UNCnRoZSBsYXN0IG5vdGlmaWNh dGlvbiB3YXMgc2VudC4gJm5ic3A7QnV0IHRoZXJlIG1heSBiZSBjYXNlcyB3aGVyZSB0aGUNCnN1 YnNjcmliZXIgd2FudHMgdGhlIGRlbGF5IG9yIGJ1ZmZlcmluZyB0byBiZSBiYXNlZCBvbiB0aGUg cmF0ZSBvZiBub3RpZmljYXRpb25zDQpvdmVyIGEgZ2l2ZW4gcGVyaW9kLjwvZm9udD4NCjxicj4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+VGhpcyBpcyB0aGUgdXNlIGNhc2UgZ2l2 ZW4gaW4gMy4zLCBidXQNCm5vdCBzdXBwb3J0ZWQgYnkgc2VjdGlvbiA2PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj7igJx3YW50cyB0byBtYWtlIGEgc3Vic2NyaXB0aW9u IHRoYXQgZHluYW1pY2FsbHkNCmluY3JlYXNlcyB0aGUgaW50ZXJ2YWwgYmV0d2VlbiBub3RpZmlj YXRpb25zIGlmIHRoZSB0YXJnZXQgaGFzIHNlbnQgb3V0DQpzZXZlcmFsIG5vdGlmaWNhdGlvbnMg cmVjZW50bHku4oCdPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJp Ij5JdCBzZWVtcyB0byBtZSB0aGF0IGl0IHdvdWxkIG5vdCBiZSBoYXJkDQp0byBjcmVhdGUgYSBu ZXcgYWxnb3JpdGhtIChhbiBhZGFwdGl2ZS9keW5hbWljIHZlcnNpb24gb2YgdGhlIG1heGltdW0g cmF0ZQ0KYWxnb3JpdGhtKSwgYW5hbG9nb3VzIHRvIHRoZSBhbGdvcml0aG0gaW4gc2VjdGlvbiA2 LCB3aGljaCDigJxkeW5hbWljYWxseQ0KY2FsY3VsYXRlcyB0aGUgbWluaW11bSB0aW1lIGFsbG93 ZWQgYmV0d2VlbiB0d28gbm90aWZpY2F0aW9uc+KAnSwgYW5kIHRoZW4NCmRlbGF5cyBvciBidWZm ZXJzIHRoZSBub3RpZmljYXRpb24gdW50aWwgdGhhdCB0aW1lLjwvZm9udD4NCjxicj4NCjxicj48 Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+U2VjIDMtNCByZXF1aXJlbWVudHM8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlJlcSAzIG5lZWRzIHRvIGJlIG1v ZGlmaWVkIHNvIGl0IHJlZmxlY3RzDQp3aGF0IHRoZSBtZWNoYW5pc20gYWN0dWFsbHkgZG9lczwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+UGVyaGFwcyDigJxUaGUgc3Vi c2NyaWJlciBtdXN0IGJlIGFibGUgdG8NCiZuYnNwO3NldCBhbiBvYmplY3RpdmUgY2FkZW5jZSwg d2hpY2ggYWRqdXN0IHRoZSBtYXhpbXVtIHRpbWUgYmV0d2VlbiBzdWNjZXNzaXZlDQpub3RpZmlj YXRpb25zIGJhc2VkIG9uIGEgbW92aW5nIGF2ZXJhZ2XigJ08L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlJlcSA3IHNheXM8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6 ZT0yIGZhY2U9IkNhbGlicmkiPuKAnFRoZSBub3RpZmllciBtdXN0IGJlIGFsbG93ZWQgdG8gdXNl IGENCnBvbGljeSBpbiB3aGljaCB0aGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNh bGlicmkiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7bWluaW11bQ0K dGltZSBwZXJpb2QgYmV0d2VlbiB0d28gbm90aWZpY2F0aW9ucyBpcyBhZGp1c3RlZDwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i c3A7ICZuYnNwOyAmbmJzcDtmcm9tDQp0aGUgdmFsdWUgZ2l2ZW4gYnkgdGhlIHN1YnNjcmliZXIu 4oCdPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5TdXJlbHkgdGhpcyBz aG91bGQgYmU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPuKAnFRoZSBu b3RpZmllciBtdXN0IGJlIGFsbG93ZWQgdG8gdXNlIGENCnBvbGljeSBpbiB3aGljaCB0aGU8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJm5ic3A7bWluaW11bQ0Kb3IgbWF4aW11bSB0aW1lIHBlcmlvZCBiZXR3 ZWVuIHR3byBub3RpZmljYXRpb25zIGlzIGFkanVzdGVkPC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNw O2Zyb20NCnRoZSB2YWx1ZSBnaXZlbiBieSB0aGUgc3Vic2NyaWJlci7igJ08L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlJlcSA4IHNheXM8L2ZvbnQ+DQo8YnI+ PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPuKAnG1lY2hhbmlzbXMgbXVzdCBkaXNjdXNzIGNv cm5lciBjYXNlc+KApuKAnQ0KYW5kIOKAnG1lY2hhbmlzbXMgbXVzdCBpbmNsdWRlIGRpc2N1c3Np b24gb2bigKbigJ08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPk1lY2hh bmlzbXMgY2Fu4oCZdCDigJxkaXNjdXNz4oCdIGFueXRoaW5nLjwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ2FsaWJyaSI+U3VnZ2VzdCDigJxtZWNoYW5pc21zIG11c3QgYWRkcmVzcyBj b3JuZXINCmNhc2Vz4oCm4oCdIGFuZCAmbmJzcDvigJxtZWNoYW5pc21zIG11c3QgYWRkcmVzcyDi gKbigJ08L2ZvbnQ+DQo8YnI+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmki PuKAnFNlYyAzLjUgJm5ic3A7IFRoZSBtYXhpbXVtIHJhdGUgbWVjaGFuaXNtDQpmb3IgUmVzb3Vy Y2UgTGlzdCBTZXJ2ZXLigJ08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmki PklmIHRoaXMgaXMsIGluZGVlZCwgcmVzdHJpY3RlZCB0byB0aGUg4oCcbWF4aW11bQ0KcmF0ZSBt ZWNoYW5pc23igJ0sIGl0IHNob3VsZCBiZSBtb3ZlZCB0byBzZWN0aW9uIDQuICZuYnNwOzwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+U2VjIDQuMjwvZm9udD4N Cjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+V2hhdCBkb2VzIHRoaXMgbWVhbj88L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPuKAnFN1Y2ggbm90aWZpY2F0aW9u cyByZXNldCB0aGUgdGltZXIgZm9yDQp0aGUgbmV4dDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwO25vdGlmaWNhdGlvbiwgZXZlbiB0aG91Z2gNCnRo ZXkgZG8gbm90IG5lZWQgdG8gYWJpZGUgYnkgaXQu4oCdPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5TZWMgNC4zPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNp emU9MiBmYWNlPSJDYWxpYnJpIj5Ib3cgY2FuICZuYnNwO3NldHRpbmcgYSBtaW5pbXVtIGludGVy dmFsDQombmJzcDvigJxpbnNpc3QgKHNpYykgYm90aDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwO3Zlcnkgc2hvcnQgYW5kIHZlcnkgbG9uZyBpbnRl cnZhbHMNCmJldHdlZW4gbm90aWZpY2F0aW9ucy7igJ08L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkNhbGlicmkiPkl0IGlzIGNsZWFyIHRoYXQgc2V0dGluZyBhIG1pbmltdW0g aW50ZXJ2YWwNCndpdGggYSBsYXJnZSB2YWx1ZSB3aWxsIGxlYWQgdG8g4oCcdmVyeSBsb25nIGlu dGVydmFscyBiZXR3ZWVuIG5vdGlmaWNhdGlvbnMu4oCdPC9mb250Pg0KPGJyPg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5CdXQgc2V0dGluZyBhIG1pbmltdW0gaW50ZXJ2YWwgd2l0 aCBhIHNtYWxsDQombmJzcDt2YWx1ZSB3aWxsICZuYnNwO25vdCBuZWNlc3NhcmlseSBsZWFkIHRv IOKAnHZlcnkgc2hvcnQgaW50ZXJ2YWxzIGJldHdlZW4NCm5vdGlmaWNhdGlvbnMu4oCdPC9mb250 Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5TZWN0aW9uIDQuNC4xPC9m b250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5TaW5jZSBlYWNoIHN1YnNjcmli ZXIgbWF5IGhhdmUgYSBkaWZmZXJlbnQNCnZhbHVlIGZvciDigJxtaW5pbXVtLWludGVydmFs4oCd LCBkb2VzIHRoZSBub3RpZmllciBuZWVkIGEgc2VwYXJhdGUgYnVmZmVyDQpmb3IgZWFjaCBzdWJz Y3JpYmVyPzwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+U2Vj dGlvbiA3PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj7igJxtYXgtaW50 ZXJ2YWwgYW5kIGF2ZXJhZ2UtaW50ZXJ2YWw6ICZuYnNwO2FzDQpib3RoIHRoZSBwYXJhbWV0ZXJz IGFyZTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNw OyAmbmJzcDsgZGVzaWduZWQgYXMgbWluaW11bQ0KcmF0ZSBtZWNoYW5pc21zLCB0aGlzIGNvbWJp bmF0aW9uIG1ha2VzIHNlbnNlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJp Ij4mbmJzcDsgJm5ic3A7ICZuYnNwOyBvbmx5IGluIHNvbWUgY29ybmVyDQpjYXNlcy48L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDsgJm5i c3A7IEEgc3Vic2NyaWJlciBTSE9VTEQNCmNob29zZSBhICZxdW90O21heC1pbnRlcnZhbCZxdW90 OyB2YWx1ZSBoaWdoZXIgdGhhbiB0aGU8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNh bGlicmkiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZxdW90O2F2ZXJhZ2UtaW50ZXJ2YWwmcXVvdDsN CnZhbHVlLCBvdGhlcndpc2UgdGhlIG5vdGlmaWVyIE1VU1QgTk9UIGNvbnNpZGVyPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7ICZuYnNwOyB0aGUg JnF1b3Q7bWF4LWludGVydmFsJnF1b3Q7DQp2YWx1ZS7igJ08L2ZvbnQ+DQo8YnI+DQo8YnI+PGZv bnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPkkgZG9u4oCZdCB0aGluayBpdCBpcyAmbmJzcDthIOKA nWNvcm5lciBjYXNl4oCdDQphdCBhbGwuICZuYnNwO1N1cHBvc2UgSSBoYXZlIGEgJm5ic3A7YmVo YXZpb3IgdGhhdCByZXN1bHRzIGluIGludGVydmFscw0Kd2hlcmUgdGhlcmUgYXJlIHZlcnkgZnJl cXVlbnQg4oCccmVhbOKAnSB1cGRhdGVzIChzYXkgb25jZSBhIHNlY29uZCkgYWx0ZXJuYXRpbmcN CndpdGggaW50ZXJ2YWxzIHdoZXJlIHRoZXJlIGFyZSBsb25nZXIgJm5ic3A7aW50ZXJ2YWxzIGJl dHdlZW4g4oCccmVhbOKAnQ0KdXBkYXRlcyAoc2F5IG9uIHRoZSBvcmRlciBvZiBtaW51dGVzKS4g Jm5ic3A7PC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5TdXBw b3NlIEkgd2FudCBhbiBhdmVyYWdlIChkeW5hbWljIG1pbmltdW0pDQpyYXRlIG9mIG9uZSB1cGRh dGUgcGVyIDUgc2Vjb25kcy4gJm5ic3A7RGVwZW5kaW5nIG9uIHRoZSBsZW5ndGggb2YgdGhlDQpw ZXJpb2QsIGF0IHRoZSBlbmQgb2YgdGhlIOKAnGZyZXF1ZW50IHVwZGF0ZeKAnSBpbnRlcnZhbCwg dGhpcyBjb3VsZCByZXN1bHQNCmluIGEgdmVyeSBsYXJnZSB2YWx1ZSBvZiB0aGUg4oCcdGltZW91 dOKAnSwgcmVzdWx0aW5nIGluICZuYnNwO2EgbWludXRlIG9yDQptb3JlIGJlZm9yZSB0aGUgbmV4 dCB0aW1lb3V0LWdlbmVyYXRlZCAmbmJzcDt1cGRhdGUuICZuYnNwO0kgZG9u4oCZdCB3YW50DQp0 byB3YWl0IFRIQVQgbG9uZy4gJm5ic3A7SW4gZmFjdCwgSSB3YW50IGFuIHVwZGF0ZSBhdCBsZWFz dCBvbmNlIGV2ZXJ5DQoxMCBzZWNvbmRzLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQ2FsaWJyaSI+U28gSSBzZXQgbXkg4oCcYXZlcmFnZS1pbnRlcnZhbOKAnSB0byA1IHNl YywNCmFuZCBteSDigJxtYXhpbXVtIGludGVydmFs4oCdIHRvIDEwIHNlYy48L2ZvbnQ+DQo8YnI+ DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPkluIHRoZSBwZXJpb2QgaW1tZWRpYXRl bHkgYWZ0ZXIgJm5ic3A7dGhlDQplbmQgb2YgYW4g4oCcYWN0aXZl4oCdIGludGVydmFsLCBJIHdp bGwgZ2V0IHRpbWUtb3V0IGdlbmVyYXRlZCB1cGRhdGVzIGV2ZXJ5DQoxMCBzZWNvbmRzIChiZWNh dXNlIHRoZSB0aW1lb3V0IGdlbmVyYXRlZCBieSB0aGUg4oCcYXZlcmFnZeKAnSBtZWNoYW5pc20N CmlzIGdyZWF0ZXIgdGhhbiAxMCBzZWNvbmRzKS4gJm5ic3A7QnV0IG9uY2Ugd2UgYXJlIHdlbGwg aW50byB0aGUg4oCcaW5hY3RpdmXigJ0NCmludGVydmFsLCB0aGUgdGltZW91dCAmbmJzcDtnZW5l cmF0ZWQgYnkgdGhlIOKAnGF2ZXJhZ2XigJ0gbWVjaGFuaXNtIHdpbGwNCmNvbnZlcmdlIHRvIDUg c2Vjb25kcy4gJm5ic3A7VGhpcyBzZWVtcyB0byBtZSB0byBiZSBhdCBsZWFzdCBhcyB1c2VmdWwN CmFzIHRoZSB1c2UgY2FzZXMgZm9yIGNvbWJpbmluZyBtYXggYW5kIG1pbiwgb3IgbWluIGFuZCBh dmVyYWdlLjwvZm9udD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+U2V0 IDguMjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+V2hhdCBhYm91dCDi gJxwZXJpb2TigJ0/PC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD YWxpYnJpIj5OSVRTPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJp Ij5JIGFtIG5vdCBzdXJlIHdoYXQgeW91IGFyZSB0cnlpbmcgdG8gc2F5DQpoZXJlIChzZWMgMy4x KTo8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPuKAnEFwcGxpY2F0aW9u IG9mIHRoZSBtZWNoYW5pc20gZGVmaW5lZA0KYnkgUkZDIDU4MzkgW1JGQzU4MzldPC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7Y2FuIGFsc28gZWxp bWluYXRlIGZvciB0aGUNCnByZXNlbmNlIGNsaWVudCB0byByZWNlaXZlIGEgKGZ1bGwtc3RhdGUp PC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7bm90 aWZpY2F0aW9uIGNhcnJ5aW5nIHRoZQ0KbGF0ZXN0IHJlc291cmNlIHN0YXRlIGFmdGVyIHRoZTwv Zm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwO3N1YnNj cmlwdGlvbiByZWZyZXNoLuKAnTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJy aSI+UGVyaGFwczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+4oCcQXBw bGljYXRpb24gb2YgdGhlIG1lY2hhbmlzbSBkZWZpbmVkDQpieSBSRkMgNTgzOSBbUkZDNTgzOV08 L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDtjYW4g YWxzbyBlbGltaW5hdGUgPGk+dGhlDQpuZWVkPC9pPiBmb3IgdGhlIHByZXNlbmNlIGNsaWVudCB0 byByZWNlaXZlIGEgKGZ1bGwtc3RhdGUpPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD YWxpYnJpIj4mbmJzcDsgJm5ic3A7bm90aWZpY2F0aW9uLCBjYXJyeWluZyB0aGUNCmxhdGVzdCBy ZXNvdXJjZSBzdGF0ZSwgYWZ0ZXIgdGhlPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD YWxpYnJpIj4mbmJzcDsgJm5ic3A7c3Vic2NyaXB0aW9uIHJlZnJlc2gu4oCdPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5PcjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQ2FsaWJyaSI+4oCcQXBwbGljYXRpb24gb2YgdGhlIG1lY2hhbmlzbSBkZWZpbmVkDQpi eSBSRkMgNTgzOSBbUkZDNTgzOV08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGli cmkiPiZuYnNwOyAmbmJzcDtjYW4gYWxzbyBlbGltaW5hdGUgdGhlIHRyYW5zbWlzc2lvbg0Kb2Yg Jm5ic3A7YSAoZnVsbC1zdGF0ZSk8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGli cmkiPiZuYnNwOyAmbmJzcDtub3RpZmljYXRpb24gY2FycnlpbmcgdGhlDQpsYXRlc3QgcmVzb3Vy Y2Ugc3RhdGUgdG8gJm5ic3A7dGhlIHByZXNlbmNlIGNsaWVudCAmbmJzcDthZnRlciB0aGU8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDtzdWJzY3Jp cHRpb24gcmVmcmVzaC7igJ0gPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJD YWxpYnJpIj4mbmJzcDtTZWMgMy4yPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxp YnJpIj5SZXBsYWNlIOKAnGNyaXRlcmlhc+KAnSB3aXRoIOKAnGNyaXRlcmlh4oCdDQooY3JpdGVy aWEgaXMgYWxyZWFkeSB0aGUgcGx1cmFsKS48L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0y IGZhY2U9IkNhbGlicmkiPuKAnGkuZS4gaGFzIG5vdCBtb3ZlZCBhdCBsZWFzdCBuIG1ldGVycw0K d2l0aGluIHRoZSBwZXJpb2Qu4oCdIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2Fs aWJyaSI+U2hvdWxkIGJlIDwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+ 4oCcZS5nLiBoYXMgbm90IG1vdmVkIGF0IGxlYXN0IG4gbWV0ZXJzDQp3aXRoaW4gdGhlIHBlcmlv ZC7igJ08L2ZvbnQ+DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlNlYyAz LjQ8L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlJlcSA0PC9mb250Pg0K PGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5DaGFuZ2UgPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDYWxpYnJpIj7igJxJdCBtdXN0IGJlIHBvc3NpYmxlIHRvIGFwcGx5IGFs bCB0b2dldGhlciwNCm9yIGluIGFueTwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2Fs aWJyaSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDtjb21iaW5hdGlv biwNCnRoZSAmcXVvdDttaW4taW50ZXJ2YWwmcXVvdDssICZxdW90O21heC1pbnRlcnZhbCZxdW90 OyBhbmQgJnF1b3Q7YXZlcmFnZS08L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGli cmkiPiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7aW50ZXJ2YWwmcXVv dDsNCm1lY2hhbmlzbXMgaW4gYSBzcGVjaWZpYyBzdWJzY3JpcHRpb24u4oCdPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5UbyA8L2ZvbnQ+DQo8ZGl2IGFsaWduPWNlbnRl cj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+4oCcSXQgbXVzdCBiZSBwb3NzaWJs ZSB0byBhcHBseSB0aGUgJnF1b3Q7bWluLWludGVydmFsJnF1b3Q7LA0KJnF1b3Q7bWF4LWludGVy dmFsJnF1b3Q7IGFuZCAmcXVvdDthdmVyYWdlLTwvZm9udD48L2Rpdj4NCjxicj48Zm9udCBzaXpl PTIgZmFjZT0iQ2FsaWJyaSI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz cDtpbnRlcnZhbCZxdW90Ow0KbWVjaGFuaXNtcyAmbmJzcDthbGwgdG9nZXRoZXIsIG9yIGluIGFu eSAmbmJzcDtjb21iaW5hdGlvbiwgaW4gYSBzcGVjaWZpYw0Kc3Vic2NyaXB0aW9uLuKAnTwvZm9u dD4NCjxicj4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+UmVxIDU8L2ZvbnQ+DQo8 YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPkNoYW5nZSA8L2ZvbnQ+DQo8YnI+PGZvbnQg c2l6ZT0yIGZhY2U9IkNhbGlicmkiPuKAnEl0IG11c3QgYmUgcG9zc2libGUgdG8gdXNlIG9mIHRo ZSBkaWZmZXJlbnQNCnJhdGUgY29udHJvbCBtZWNoYW5pc21z4oCm4oCdPC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5UbzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFj ZT0iQ2FsaWJyaSI+4oCcSXQgbXVzdCBiZSBwb3NzaWJsZSB0byB1c2UgYW55IG9mIHRoZQ0KZGlm ZmVyZW50IHJhdGUgY29udHJvbCBtZWNoYW5pc21z4oCm4oCdPC9mb250Pg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5SZXEgNjwvZm9udD4NCjxicj48Zm9udCBzaXplPTIg ZmFjZT0iQ2FsaWJyaSI+Q2hhbmdlIOKAnEl0IG11c3QgYmUgcG9zc2libGUgdG8gdXNlIHRoZQ0K ZGlmZmVyZW50IHJhdGUgY29udHJvbCBtZWNoYW5pc21z4oCm4oCdPC9mb250Pg0KPGJyPjxmb250 IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5UbzwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0i Q2FsaWJyaSI+SXQgbXVzdCBiZSBwb3NzaWJsZSB0byB1c2UgYW55IG9mIHRoZSBkaWZmZXJlbnQN CnJhdGUgY29udHJvbCBtZWNoYW5pc21z4oCm4oCdPC9mb250Pg0KPGJyPg0KPGJyPg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5TZWMgMy41PC9mb250Pg0KPGJyPjxmb250IHNpemU9 MiBmYWNlPSJDYWxpYnJpIj7igJxXZSBjYW4gbW9kZWwgdGhlIG5vdGlmaWVyPC9mb250Pg0KPGJy Pjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7YXMgY29uc2lzdGluZyBv ZiB0aHJlZSBjb21wb25lbnRzOg0KdGhlIGV2ZW50IHN0YXRlIHJlc291cmNlKHMpLCB0aGU8L2Zv bnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPiZuYnNwOyAmbmJzcDtSZXNvdXJj ZSBMaXN0IFNlcnZlciAoUkxTKQ0KKG9yIGFueSBvdGhlciBub3RpZmllciksIGEgbm90aWZpY2F0 aW9uPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj4mbmJzcDsgJm5ic3A7 YnVmZmVyLCBhbmQgZmluYWxseSB0aGUgc3Vic2NyaWJlciwNCm9yIHdhdGNoZXIgb2YgdGhlIGV2 ZW50IHN0YXRlLCBhczwvZm9udD4NCjxicj48Zm9udCBzaXplPTIgZmFjZT0iQ2FsaWJyaSI+Jm5i c3A7ICZuYnNwO3Nob3duIGluIEZpZ3VyZSAxLuKAnTwvZm9udD4NCjxicj4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ2FsaWJyaSI+VGhhdCBpcyBGT1VSLCBub3QgdGhyZWUuPC9mb250Pg0KPGJy Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5TZWN0aW9uIDcgKGF0IGxlYXN0IHR3 byBwbGFjZXMpPC9mb250Pg0KPGJyPg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj5D aGFuZ2UgPC9mb250Pg0KPGJyPjxmb250IHNpemU9MiBmYWNlPSJDYWxpYnJpIj7igJx0byBhIHZh bHVlIGVxdWl2YWxlbnQgb3IgaGlnaGVyIHRoYW4NCuKApuKAnTwvZm9udD4NCjxicj48Zm9udCBz aXplPTIgZmFjZT0iQ2FsaWJyaSI+dG88L2ZvbnQ+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNh bGlicmkiPuKAnHRvIGEgdmFsdWUgZXF1YWwgdG8gb3IgaGlnaGVyIHRoYW7igKbigJ08L2ZvbnQ+ DQo8YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPlRoYW5rcyw8L2ZvbnQ+DQo8 YnI+DQo8YnI+PGZvbnQgc2l6ZT0yIGZhY2U9IkNhbGlicmkiPkphbmV0PC9mb250Pg0KPGJyPjxm b250IHNpemU9MiBmYWNlPSJzYW5zLXNlcmlmIj48YnI+DQo8L2ZvbnQ+DQo8YnI+DQo8YnI+PHR0 Pjxmb250IHNpemU9Mj5zaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmcgd3JvdGUgb24gMDcvMTkvMjAx MCAwMzozOTo1NQ0KUE06PGJyPg0KPGJyPg0KJmd0OyBbaW1hZ2UgcmVtb3ZlZF0gPGJyPg0KJmd0 OyBSZTogW3NpcGNvcmVdIEFEIHJldmlldzogZHJhZnQtaWV0Zi1zaXBjb3JlLWV2ZW50LXJhdGUt Y29udHJvbC0wNDxicj4NCiZndDsgSmFuZXQgUCBHdW5uIDxicj4NCiZndDsgdG86IGtyaXN6dGlh bi5raXNzPGJyPg0KJmd0OyAwNy8xOS8yMDEwIDAzOjQwIFBNPGJyPg0KJmd0OyBTZW50IGJ5OiBz aXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmc8L2ZvbnQ+PC90dD4NCjxicj48dHQ+PGZvbnQgc2l6ZT0y PiZndDs8YnI+DQomZ3Q7ICZndDsgPGJyPg0KJmd0OyAmZ3Q7IEkgc3VibWl0dGVkIHRoZSAtMDQg dmVyc2lvbiB0b2RheSBhZGRyZXNzaW5nIHlvdXIgY29tbWVudHM6IGh0dHA6Ly88YnI+DQomZ3Q7 ICZndDsgPC9mb250PjwvdHQ+PGEgaHJlZj0id3d3LmlldGYub3JnL2lkL2RyYWZ0LWlldGYtc2lw Y29yZS1ldmVudC1yYXRlLWNvbnRyb2wtMDQudHh0Ij48dHQ+PGZvbnQgc2l6ZT0yPnd3dy5pZXRm Lm9yZy9pZC9kcmFmdC1pZXRmLXNpcGNvcmUtZXZlbnQtcmF0ZS1jb250cm9sLTA0LnR4dDwvZm9u dD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPg0KPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFRoYW5r IHlvdSBmb3IgaW5jbHVkaW5nIG1lIGluIHRoZSBhY2tub3dsZWRnZW1lbnRzLiA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgSSBmaW5kIHRoYXQgc29tZSwgYnV0IG5vdCBhbGwsIG9mIG15IGNvbW1lbnRz IGhhdmUgYmVlbiBhZGRyZXNzZWQuDQombmJzcDs8YnI+DQomZ3Q7IEkgYW0gcmVwZWF0aW5nIHRo ZSBvbmVzIHdoaWNoIHN0aWxsIGNhdXNlIGNvbmZ1c2lvbi4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 IEZpcnN0IGxldCBtZSBzYXkgdGhhdCBJIHRoaW5rIHRoaXMgaXMgYSB2ZXJ5IHVzZWZ1bCBtZWNo YW5pc20uICZuYnNwO015DQo8YnI+DQomZ3Q7IGNvbmNlcm5zIGFyZSBwcmltYXJpbHkgaW4gdGhl IHdheSB0aGUgbWVjaGFuaXNtIGlzIGRlc2NyaWJlZC4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IDxi cj4NCiZndDsgJmd0O1doaWxlIOKAnG1heC1pbnRlcnZhbOKAnSBpcyBzeW5vbnltb3VzIHdpdGgg 4oCcbWluaW11bSByYXRl4oCdLCBhbmQNCuKAnG1pbi08YnI+DQomZ3Q7IGludGVydmFs4oCdIGlz IHN5bm9ueW1vdXMgd2l0aCDigJxtYXhpbXVtIHJhdGXigJ0sIHRoZSBjb25zdGFudCBzd2l0Y2hp bmcNCjxicj4NCiZndDsgYmFjayBhbmQgZm9ydGggYmV0d2VlbiB0aGUgdHdvIHNldHMgb2YgdGVy bWlub2xvZ3kgbWFrZXMgaXQgdmVyeSA8YnI+DQomZ3Q7IGRpZmZpY3VsdCB0byBmb2xsb3cuIDxi cj4NCiZndDsgPGJyPg0KJmd0OyBbSlBHXSB0aGlzIGlzIHN0aWxsIGFuIGlzc3VlLiAmbmJzcDtT ZWN0aW9ucyA0LCA1LCBhbmQgNiBhcmUgdGl0bGVkDQomcXVvdDsuLi4tPGJyPg0KJmd0OyByYXRl IGJlaGF2aW9yJnF1b3Q7LCBidXQgc2VjdGlvbiA3IGlzIHRpdGxlZCAuLi4taW50ZXJ2YWwuIDxi cj4NCiZndDsgPGJyPg0KJmd0OyBbSlBHXSBJZiB5b3UganVzdCBjaGFuZ2UgdGhlIHRpdGxlIG9m IHNlY3Rpb24gNyB0byA8YnI+DQomZ3Q7IFVzYWdlIG9mICZxdW90O21heGltdW0gcmF0ZSZxdW90 OywgJnF1b3Q7bWluaW11bSByYXRlJnF1b3Q7IGFuZCAmcXVvdDthdmVyYWdlDQpyYXRlJnF1b3Q7 IGluIGEgY29tYmluYXRpb24gPGJyPg0KJmd0OyBpdCB3b3VsZCBiZSBNVUNIIGNsZWFyZXIuIDxi cj4NCiZndDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDtUaGUgZGVzY3JpcHRpb24gb2YgdGhl IGludGVuZGVkIGVmZmVjdCBvZiB0aGUg4oCcYXZlcmFnZS1pbnRlcnZhbOKAnQ0KaXM8YnI+DQom Z3Q7IHVuY2xlYXIgYW5kIGluY29uc2lzdGVudC4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZndDtJ biB0aGUgaW50cm9kdWN0aW9uLCBpdCBzYXlzIDxicj4NCiZndDsg4oCcICZuYnNwOyBhdmVyYWdl LWludGVydmFsOiAmbmJzcDtzcGVjaWZpZXMgYW4gYXZlcmFnZSBjYWRlbmNlIGF0DQp3aGljaCA8 YnI+DQomZ3Q7IG5vdGlmaWNhdGlvbnMgYXJlIGRlc2lyZWQsIGluIHNlY29uZHMu4oCdIDxicj4N CiZndDsgPGJyPg0KJmd0OyBbSlBHXSBUaGUgSW50cm9kdWN0aW9uIFNUSUxMIFNBWVMgdGhpcy4g QnV0IHRoYXQgaXMgbm90IHdoYXQgdGhhdA0KPGJyPg0KJmd0OyBtZWNoYW5pc20gZG9lcy4gJm5i c3A7IDxicj4NCiZndDsgJm5ic3A7IDxicj4NCiZndDsgW0pQR10gSWYgdGhlIHN1YnNjcmliZXIn cyBkZXNpcmVkICZxdW90O2F2ZXJhZ2UmcXVvdDsgaXMgJnF1b3Q7b25lDQpub3RpZmljYXRpb24g PGJyPg0KJmd0OyBldmVyeSA1IHNlY29uZHMmcXVvdDssIGFuZCB0aGUgJm5ic3A7bm90aWZpZXIg aGFzIGEgbm90aWZpY2F0aW9uIHJlYWR5DQp0byBzZW5kPGJyPg0KJmd0OyBldmVyeSBzZWNvbmQs IGl0IGlzIGdvaW5nIHRvIHNlbmQgdGhlIG5vdGlmaWNhdGlvbiBvdXQgb25jZSBhIDxicj4NCiZn dDsgc2Vjb25kLiAmbmJzcDtVbmRlciB0aGUgZGVzY3JpYmVkIGFsZ29yaXRobSwgdGhlIG5vdGlm aWVyIHdpbGwgTk9UDQpkZWxheSw8YnI+DQomZ3Q7IG5vciBidWZmZXIsIG5vdGlmaWNhdGlvbnMg dG8gYXBwcm9hY2ggdGhlIGRlc2lyZWQvc3BlY2lmaWVkICZxdW90O2F2ZXJhZ2UmcXVvdDsNCjxi cj4NCiZndDsgPGJyPg0KJmd0OyBbSlBHXSBJbiBmYWN0LCB0aGUgbWVjaGFuaXNtIGRlc2NyaWJl ZCBpbiBzZWN0aW9uIDYgaXMgYW4gQURBUFRJVkUNCjxicj4NCiZndDsgdmFyaWFudCBvZiB0aGUg bWluaW11bS1yYXRlIChtYXhpbXVtLWludGVydmFsKSBtZWNoYW5pc20uIDxicj4NCiZndDsgPGJy Pg0KJmd0OyBbSlBHXSBQZXJzb25hbGx5LCBJIHdvdWxkIHByZWZlciB0byBzZWUgdGhlIG5hbWUg b2YgdGhlIG1lY2hhbmlzbQ0KPGJyPg0KJmd0OyBjaGFuZ2VkIHRvICZxdW90O2FkYXB0aXZlLW1p bmltdW0tcmF0ZSZxdW90OyBpbnN0ZWFkIG9mICZxdW90O2F2ZXJhZ2UtcmF0ZSZxdW90Oy4NCiZu YnNwO0J1dCA8YnI+DQomZ3Q7IGV2ZW4gaWYgeW91IGRvbid0IGRvIHRoYXQsIHlvdSBuZWVkIHRv IGNoYW5nZSB0aGUgdGV4dCBzbyB0aGF0IHlvdQ0KPGJyPg0KJmd0OyBhcmUgbm8gbG9uZ2VyIG1p c3JlcHJlc2VudGluZyB0aGUgYWxnb3JpdGhtLiA8YnI+DQomZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7 IDxicj4NCiZndDsgJmd0O0luIHNlY3Rpb24gMy4zLCBVc2UgQ2FzZSBmb3Igc3BlY2lmeWluZyB0 aGUgYXZlcmFnZSByYXRlIG9mIDxicj4NCiZndDsgbm90aWZpY2F0aW9ucywgaXQgaXMgY29udHJh ZGljdG9yeS4gJm5ic3A7Rmlyc3QgaXQgc2F5cyA8YnI+DQomZ3Q7ICZndDvigJxkeW5hbWljYWxs eSBpbmNyZWFzZXMgdGhlIGludGVydmFsIGJldHdlZW4gbm90aWZpY2F0aW9ucyBpZg0KdGhlIDxi cj4NCiZndDsgdGFyZ2V0IGhhcyBzZW50IG91dCBzZXZlcmFsIG5vdGlmaWNhdGlvbnMgJmd0O3Jl Y2VudGx5LuKAnSAmbmJzcDtUaGlzDQppcyBhbiA8YnI+DQomZ3Q7IElOQ1JFQVNFIGluIHRoZSBp bnRlcnZhbC4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFtKUEddIFRoaXMgdGV4dCBhYm91dCB0aGlz IHVzZSBjYXNlICZuYnNwO0FMU08gc2F5cyAmcXVvdDtJbiBvcmRlcg0KdG8gZGVjcmVhc2U8YnI+ DQomZ3Q7IHRoZSBwcm9jZXNzaW5nIGFuZCBuZXR3b3JrIGxvYWQmcXVvdDsgPGJyPg0KJmd0OyA8 YnI+DQomZ3Q7IFtKUEddICZuYnNwO1RoZSB0ZXh0IHN0aWxsIHNheXMgdGhpcy4gJm5ic3A7QnV0 IHRoZSBtZWNoYW5pc20gYW5kDQpmb3JtdWxhIHlvdSA8YnI+DQomZ3Q7IGRlc2NyaWJlIGluIHNl Y3Rpb24gNiBXSUxMIE5PVCAmcXVvdDtpbmNyZWFzZSB0aGUgaW50ZXJ2YWwgYmV0d2Vlbg0KPGJy Pg0KJmd0OyBub3RpZmljYXRpb25zIGlmIHRoZSB0YXJnZXQgaGFzIHNlbnQgb3V0IHNldmVyYWwg bm90aWZpY2F0aW9ucyA8YnI+DQomZ3Q7IHJlY2VudGx5LiZxdW90OyAmbmJzcDtJdCBvbmx5IERF Q1JFQVNFUyB0aGUgaW50ZXJ2YWwgYmV0d2VlbiBub3RpZmljYXRpb25zLg0KJm5ic3A7IDxicj4N CiZndDsgPGJyPg0KJmd0OyBbSlBHXSBJdCBpcyB0cnVlIHRoYXQgaXQgd2lsbCBERUNSRUFTRSB0 aGUgaW50ZXJ2YWwgJm5ic3A7TEVTUyBpZg0KdGhlcmUgPGJyPg0KJmd0OyBoYXZlIGJlZW4gc2V2 ZXJhbCByZWNlbnQgbm90aWZpY2F0aW9ucy4gJm5ic3A7QnV0IHRoYXQgaXMgcXVpdGUgZGlmZmVy ZW50PGJyPg0KJmd0OyBmcm9tIElOQ1JFQVNJTkcgdGhlIGludGVydmFsLiA8YnI+DQomZ3Q7IDxi cj4NCiZndDsgW0pQR10gVGhpcyB0ZXh0IGFib3V0IHRoaXMgdXNlIGNhc2UgQUxTTyBzYXlzICZx dW90O0luIG9yZGVyIHRvIGRlY3JlYXNlDQo8YnI+DQomZ3Q7IHRoZSBwcm9jZXNzaW5nIGFuZCBu ZXR3b3JrIGxvYWQmcXVvdDsuICZuYnNwO1RoZSBhbGdvcml0aG0gaW4gc2VjdGlvbg0KNiB3aWxs IDxicj4NCiZndDsgTk9UICZxdW90O2RlY3JlYXNlIHByb2Nlc3NpbmcgYW5kIG5ldHdvcmsgbG9h ZC4gJm5ic3A7SXQgd2lsbCBJTkNSRUFTRQ0KPGJyPg0KJmd0OyBwcm9jZXNzaW5nIGFuZCBuZXR3 b3JrIGxvYWQuIDxicj4NCiZndDsgPGJyPg0KJmd0OyBbSlBHXSBIZXJlIGlzIG15IHN1Z2dlc3Rl ZCByZXdyaXRlIG9mIHRoZSB1c2UgY2FzZSBmb3IgMy4zLCBiYXNlZA0Kb248YnI+DQomZ3Q7IHRo ZSB1c2UgY2FzZSBpbiAzLjIsIHNvIGl0IGNvcnJlc3BvbmRzIHRvIHRoZSBhbGdvcml0aG0gaW4g c2VjdGlvbg0KNjxicj4NCiZndDsgKGFkZGVkIHRleHQgaW4gQUxMIENBUFMpLiA8YnI+DQomZ3Q7 ICZuYnNwOyAmcXVvdDtBIHRyYWNraW5nIGFwcGxpY2F0aW9uIGlzIG1vbml0b3JpbmcgdGhlIG1v dmVtZW50IG9mDQphIHRhcmdldC4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtJ biBvcmRlciB0byBkZWNyZWFzZSB0aGUgcHJvY2Vzc2luZyBhbmQgbmV0d29yayBsb2FkLA0KdGhl IHRyYWNraW5nIDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2FwcGxpY2F0aW9uIGhhcyBtYWRlIGEg c3Vic2NyaXB0aW9uIHdpdGggYSBzZXQgb2YgbG9jYXRpb24NCmZpbHRlcnMgPGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7dGhhdCBzcGVjaWZ5IHRyaWdnZXIgY3JpdGVyaWEsIGZvciA8YnI+DQomZ3Q7 ICZuYnNwOyAmbmJzcDtleGFtcGxlLCB0byBzZW5kIGFuIHVwZGF0ZSBvbmx5IHdoZW4gdGhlIHRh cmdldCBoYXMgbW92ZWQNCmF0IGxlYXN0IG4gPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7bWV0ZXJz LiAmbmJzcDtIb3dldmVyLCB0aGUgYXBwbGljYXRpb24gaXMgYWxzbyBpbnRlcmVzdGVkDQppbiBy ZWNlaXZpbmcgdGhlIDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO2N1cnJlbnQgc3RhdGUgcGVyaW9k aWNhbGx5IGV2ZW4gaWYgdGhlIHN0YXRlIG9mIHRoZSB0YXJnZXQNCmhhcyBub3QgPGJyPg0KJmd0 OyAmbmJzcDsgJm5ic3A7Y2hhbmdlZCBlbm91Z2ggdG8gc2F0aXNmeSBhbnkgb2YgdGhlIHRyaWdn ZXIgY3JpdGVyaWEsDQplLmcuLCBoYXMgbm90IDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO21vdmVk IGF0IGxlYXN0IG4gbWV0ZXJzIHdpdGhpbiB0aGUgcGVyaW9kLiA8YnI+DQomZ3Q7ICZuYnNwOyA8 YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtIT1dFVkVSLCBJRiBUSEVSRSBIQVZFIEJFRU4gRkVXIFJF Q0VOVCBVUERBVEVTLCBUSEUgU1VCU0NSSUJFUg0KPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7V09V TEQgTElLRSBOT01JTkFMIFVQREFURVMgTU9SRSBGUkVRVUVOVExZIFRIQU4gV0hFTg0KVEhFUkUg SEFWRSBCRUVOIDxicj4NCiZndDsgJm5ic3A7ICZuYnNwO01BTlkgUkVDRU5UIFVQREFURVMuIDxi cj4NCiZndDsgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7SW4gb3JkZXIgdG8gY29udHJvbCB0aGUg YWN0dWFsIHN0YXRlLCB0aGUgbG9jYXRpb24gYXBwbGljYXRpb24NCnNldHMgPGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7YU4gQURBUFRJVkUgbWluaW11bSByYXRlIChBICZxdW90O1RJTUUtT1VUJnF1 b3Q7IHBhcmFtZXRlciksDQppLmUuIGEgbWF4aW11bSB0aW1lIDxicj4NCiZndDsgJm5ic3A7ICZu YnNwO2ludGVydmFsIGJldHdlZW4gdHdvIG5vdGlmaWNhdGlvbnMsIFdISUNIIEFEQVBUUywgQkFT RUQNCk9OIFRIRSBSRUNFTlQgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7SElTVE9SWSBPRiBVUERB VEVTLiAmbmJzcDsgPGJyPg0KJmd0OyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtXSEVOIFRIRVJF IEhBVkUgQkVFTiBBIExPVCBPRiBSRUNFTlQgVVBEQVRFUywgVEhFIDxicj4NCiZndDsgJm5ic3A7 ICZuYnNwO0FMR09SSVRITSBJTkNSRUFTRVMgVEhFICZxdW90O1RJTUUtT1VUJnF1b3Q7IElOVEVS VkFMLA0KU08gVEhFIENPTUJJTkFUSU9OIE9GIDxicj4NCiZndDsgJm5ic3A7ICZuYnNwOyZxdW90 O1JFQUwmcXVvdDsgKFRSSUdHRVJFRCBCWSBVUERBVEVEIElORk9STUFUSU9OKSBBTkQNCiZxdW90 O05PTUlOQUwmcXVvdDsgKFRSSUdHRVJFRCBCWSA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtUSEUg VElNRS1PVVQpIFVQREFURVMgQ09OVkVSR0UgVE8gVEhFICZuYnNwO1NQRUNJRklFRA0KQVZFUkFH RSBSQVRFLiA8YnI+DQomZ3Q7ICZuYnNwOyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtCVVQgV0hF TiBUSEVSRSBBUkUgRlJFUVVFTlQgJnF1b3Q7UkVBTCZxdW90OyBVUERBVEVTLA0KVEhFIEFMR09S SVRITSBET0VTIE5PVCA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtERUxBWSBPUiBCVUZGRVIgVEhF U0UgTk9USUZJQ0FUSU9OUy4gJm5ic3A7SU4gVEhJUyBDQVNFLA0KVEhFIFJBVEUgT0YgVVBEQVRF UyA8YnI+DQomZ3Q7ICZuYnNwOyAmbmJzcDtXSUxMIE5PVCBDT05WRVJHRSBUTyBUSEUgU1BFQ0lG SUVEIEFWRVJBR0UgUkFURS4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7IFtKUEddIGFuZCBmcm9tIHRo ZSBvcmlnaW5hbCAzLjMgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7VGhpcyB0eXBlIG9mIHJhdGUg Y29udHJvbCBhbGxvd3MgdGhlIG5vdGlmaWVyIHRvIGR5bmFtaWNhbGx5DQppbmNyZWFzZSA8YnI+ DQomZ3Q7ICZuYnNwOyAmbmJzcDt0aGUgTm90aWZpY2F0aW9uIGZyZXF1ZW5jeS4gKFJFTU9WRUQg JnF1b3Q7b3IgZGVjcmVhc2UmcXVvdDspDQo8YnI+DQomZ3Q7IDxicj4NCiZndDsgJm5ic3A7ICZu YnNwO1RoZSB0cmFja2luZyBhcHBsaWNhdGlvbiBjYW4gYWxzbyBtb2RpZnkgdGhlICZxdW90O2F2 ZXJhZ2UtaW50ZXJ2YWwmcXVvdDsNCjxicj4NCiZndDsgJm5ic3A7ICZuYnNwO3BhcmFtZXRlciBk dXJpbmcgdGhlIGxpZmV0aW1lIG9mIHRoZSBzdWJzY3JpcHRpb24uIDxicj4NCiZndDsgPGJyPg0K Jmd0OyA8YnI+DQomZ3Q7IFtKUEddIElmIHlvdSBtYWtlIHRoZXNlIGNoYW5nZXMgdG8gdGhlIHVz ZS1jYXNlLCB0aGVuIHRoZSB1c2UgY2FzZQ0KPGJyPg0KJmd0OyB3aWxsIGJlIGNvbnNpc3RlbnQg d2l0aCBtb3N0IG9mIHRoZSB0ZXh0IGluIHNlY3Rpb24gNi4gPGJyPg0KJmd0OyA8YnI+DQomZ3Q7 ICZndDtXaGVuIHdlIGdldCB0byB0aGUgZm9ybXVsYWUgYW5kIHRoZSBkZXRhaWxlZCBtZWNoYW5p Y3MsIGl0IGlzDQpjbGVhcjxicj4NCiZndDsgdGhhdCB0aGlzIGFwcHJvYWNoIHdpbGwgb25seSBl dmVyIERFQ1JFQVNFIHRoZSBpbnRlcnZhbCBiZXR3ZWVuIDxicj4NCiZndDsgbm90aWZpY2F0aW9u cyAmbmJzcDsoZnJvbSB3aGF0IGl0IHdvdWxkIGJlIHdpdGhvdXQgRXZlbnQgUmF0ZSBDb250cm9s KSwNCjxicj4NCiZndDsgaXQgd2lsbCBuZXZlciBJTkNSRUFTRSB0aGUgaW50ZXJ2YWwgYmV0d2Vl biBub3RpZmljYXRpb25zICZuYnNwOyhmcm9tDQo8YnI+DQomZ3Q7IHdoYXQgaXQgd291bGQgYmUg d2l0aG91dCBFdmVudCBSYXRlIENvbnRyb2wpLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgW0pQR10g VGhpcyBjb21tZW50IHdpbGwgYmUgcmVzb2x2ZWQgaWYgeW91IGNoYW5nZSB0aGUgdGV4dCBpbiB0 aGUNClVzZSBDYXNlLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgJmd0O0Z1cnRoZXJtb3JlLCBpbiB0 aGUgZGVzY3JpcHRpb24gb2YgdGhlIOKAnGF2ZXJhZ2UtaW50ZXJ2YWzigJ0gPGJyPg0KJmd0OyBt ZWNoYW5pc20sIHRoZXJlIG5lZWRzIHRvIGJlIGVpdGhlciBhIOKAnE1VU1TigJ0gb3IgYSDigJxT SE9VTETigJ0gdG8NCmVuc3VyZTxicj4NCiZndDsgdGhhdCDigJxwZXJpb2TigJ0gaXMgR1JFQVRF UiBUSEFOIHRoZSDigJxhdmVyYWdlLWludGVydmFs4oCdLiAmbmJzcDtPdGhlcndpc2UNCnRoZTxi cj4NCiZndDsgZGVzY3JpYmVkIG1lY2hhbmlzbSB3aWxsIHNlbmQgb3V0IGEgbm90aWZpY2F0aW9u IGV2ZXJ5IOKAnHBlcmlvZOKAnQ0KPGJyPg0KJmd0OyBzZWNvbmRzLCByZWdhcmRsZXNzIG9mIHRo ZSB2YWx1ZSBvZiDigJxhdmVyYWdlLWludGVydmFs4oCdLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsg W0pQR10gWW91IGFkZHJlc3NlZCB0aGlzLCB3aXRoIHRoZSB0ZXh0IDxicj4NCiZndDsgJm5ic3A7 ICZuYnNwOyAmbmJzcDsgJnF1b3Q7VGhlIHZhbHVlIG9mIHRoZSA8YnI+DQomZ3Q7ICZuYnNwOyAm bmJzcDsgJm5ic3A7ICZxdW90O3BlcmlvZCZxdW90OyBwYXJhbWV0ZXIgTVVTVCBiZSBncmVhdGVy DQp0aGFuIHRoZSB2YWx1ZSBvZiB0aGUgJnF1b3Q7YXZlcmFnZS0gPGJyPg0KJmd0OyAmbmJzcDsg Jm5ic3A7ICZuYnNwOyBpbnRlcnZhbCZxdW90OyBwYXJhbWV0ZXIuJnF1b3Q7IDxicj4NCiZndDsg SG93ZXZlciwgc2luY2Ugb25seSB0aGUgJnF1b3Q7YXZlcmFnZS1pbnRlcnZhbCZxdW90OyBwYXJh bWV0ZXIgaXMNCnVuZGVyIHRoZSA8YnI+DQomZ3Q7IGNvbnRyb2wgb2YgdGhlIHN1YnNjcmliZXIs IGl0IHdvdWxkIG1ha2UgbW9yZSBzZW5zZSB0byBwdXQgaXQgaW4gdGhlPGJyPg0KJmd0OyAmcXVv dDthdmVyYWdlLWludGVydmFsJnF1b3Q7IGRlZmluaXRpb24sIGFuZCBzYXkgPGJyPg0KJmd0OyAm bmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtUaGUgdmFsdWUgb2YgdGhlICZxdW90O2F2ZXJhZ2Ut aW50ZXJ2YWwmcXVvdDsNCnBhcmFtZXRlciBNVVNUIGJlIGxlc3MgPGJyPg0KJmd0OyB0aGFuIHRo ZSB2YWx1ZSBvZiB0aGUgPGJyPg0KJmd0OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmcXVvdDtwZXJp b2QmcXVvdDsgcGFyYW1ldGVyLiZxdW90OyA8YnI+DQomZ3Q7IGFuZCB0YWtlIHRoZSBjb3JyZXNw b25kaW5nICZuYnNwO3RleHQgb3V0IG9mIHRoZSAmcXVvdDtwZXJpb2QmcXVvdDsNCnNwZWNpZmlj YXRpb24uIDxicj4NCiZndDsgPGJyPg0KJmd0OyBJIHdpbGwgYWxzbyBiZSBzZW5kaW5nIGFub3Ro ZXIgZW1haWwgd2l0aCBzb21lIG5ldyBjb21tZW50cy88YnI+DQomZ3Q7IHF1ZXN0aW9ucywgYW5k IGFub3RoZXIgb25lIHdpdGggYSBidW5jaCBvZiBuaXRzLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsg VGhhbmtzLiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgQW5kIGFnYWluLCBJIHJlYWxseSBkbyB0aGlu ayB0aGlzIGlzIGEgdXNlZnVsIG1lY2hhbmlzbSwgd2UganVzdCA8YnI+DQomZ3Q7IG5lZWQgdG8g bWFrZSB0aGUgdGV4dCBjb25zaXN0ZW50LiA8YnI+DQomZ3Q7IDxicj4NCiZndDsgSmFuZXQgX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQomZ3Q7IHNp cGNvcmUgbWFpbGluZyBsaXN0PGJyPg0KJmd0OyBzaXBjb3JlQGlldGYub3JnPGJyPg0KJmd0OyA8 L2ZvbnQ+PC90dD48YSBocmVmPWh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8v c2lwY29yZT48dHQ+PGZvbnQgc2l6ZT0yPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vc2lwY29yZTwvZm9udD48L3R0PjwvYT48dHQ+PGZvbnQgc2l6ZT0yPjxicj4NCjwvZm9u dD48L3R0Pg0K --=_alternative 007706D485257769_=-- From adam@nostrum.com Sat Jul 24 07:49:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A6D483A67B6 for ; Sat, 24 Jul 2010 07:49:31 -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+xqd8vbyC+y for ; Sat, 24 Jul 2010 07:49:30 -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 6EBB83A689C for ; Sat, 24 Jul 2010 07:49:30 -0700 (PDT) Received: from dhcp-23f3.meeting.ietf.org (dhcp-23f3.meeting.ietf.org [130.129.35.243]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6OEnlmj098846 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 24 Jul 2010 09:49:48 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C4AFD8A.1070301@nostrum.com> Date: Sat, 24 Jul 2010 16:49:46 +0200 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: SIPCORE References: <4C3DC365.1060508@nostrum.com> <4C408102.6010005@nostrum.com> In-Reply-To: <4C408102.6010005@nostrum.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.35.243 is authenticated by a trusted mechanism) Cc: draft-ietf-sipcore-keep@tools.ietf.org, "sipcore-chairs@tools.ietf.org" Subject: [sipcore] Reminder: WGLC: draft-ietf-sipcore-keep X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 24 Jul 2010 14:49:31 -0000 Reminder: we're in the last week of the WGLC for this document. If you want to see it published, you need to read it and comment on this list (even if your comment is only "it looks ready to publish to me.") We have had exactly one person provide feedback so far. /a On 7/16/10 5:55 PM, Adam Roach wrote: > As an addendum: if you have read the document and think it is ready > for publication, please send an email to the list indicating this > fact. We can't request publication if the WG hasn't taken a good look > at the document. > > /a > > On 7/14/10 9:02 AM, Adam Roach wrote: >> [as chair] >> >> The author of draft-ietf-sipcore-keep believes that the document has >> no remaining open issues, and is ready to be evaluated by the IESG >> for publication. Today, we begin a three-week Working Group Last Call >> period, which ends on Wednesday, August 4th. (This WGLC is three >> weeks instead of the more traditional two to account for the upcoming >> IETF meeting). >> >> The latest version of the document can be retrieved here: >> >> http://tools.ietf.org/html/draft-ietf-sipcore-keep >> >> Any comments on the document should be sent to the SIPCORE mailing list. >> >> As a note to document reviewers: the document's author is on holiday >> through August 2nd, and will respond to any direct queries after >> returning. >> >> /a > From pkyzivat@cisco.com Sat Jul 24 08:35:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 511203A69FB for ; Sat, 24 Jul 2010 08:35:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.569 X-Spam-Level: X-Spam-Status: No, score=-10.569 tagged_above=-999 required=5 tests=[AWL=0.030, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F8XgVcmpnpBT for ; Sat, 24 Jul 2010 08:35:40 -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 230023A699F for ; Sat, 24 Jul 2010 08:35:40 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAHulSkxAZnwM/2dsb2JhbACfZXGlE5oshTYEiGQ X-IronPort-AV: E=Sophos;i="4.55,253,1278288000"; d="scan'208";a="138689326" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 24 Jul 2010 15:35:59 +0000 Received: from [10.61.85.225] (ams3-vpn-dhcp5602.cisco.com [10.61.85.225]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6OFZu8T009179; Sat, 24 Jul 2010 15:35:57 GMT Message-ID: <4C4B085B.2020309@cisco.com> Date: Sat, 24 Jul 2010 11:35:55 -0400 From: Paul Kyzivat User-Agent: Thunderbird 2.0.0.24 (Windows/20100228) MIME-Version: 1.0 To: "Christer Holmberg (JO/LMF)" References: <4C48756F.1020509@cisco.com> In-Reply-To: <4C48756F.1020509@cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: SIPCORE Subject: Re: [sipcore] draft-ietf-sipcore-keep-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 24 Jul 2010 15:35:41 -0000 [I neglected to note that these comments were made as an individual] Paul Kyzivat wrote: > Christer, > > I finally got around to reading the keep draftfor the first time in > quite awhile. I have a few comments and questions: > > IMO the usage of "upstream" and "downstream" (which is ubiquitous) is > confusing, because its not evident which is the high ground and which is > the low ground. Normally for SIP I would assume that the sender of a > request is on the high ground, with the request flowing *downstream* > toward the recipient, and the response flowing *upstream* toward the > sender of the request. But most of the text in this draft assumes the > opposite. Perhaps this stems from a view that the "device" is on the low > ground and the registrar is on the high ground. But then 4.1 further > complicates this: > > NOTE: Usage of keep-alives is negotiated per direction. If a SIP > entity has indicated willingness to receive keep-alives from its > adjacent downstream SIP entity, sending of keep-alives towards the > same SIP entity needs to be separately negotiated. > > If that negotiation were performed following the procedures in this > draft then the upstream and dowstream roles would be reversed. > > Section 4.2.2: > > IIUC, the keepalive is associated with a flow as defined in 5626. Hence > it isn't appropriate to use this negotiation mechanism on a registration > that doesn't specify a flow. I don't see that stated anywhere. > > (If there was no flow, what would the keepalive state be associated > *with*?) > > Section 4.2.3: > > Is there a reason *why* you can't renegotiate the dialog to eliminate > the use of keepalives? (session timers are a similar concept, and they > are renegotiated on/off with every reINVITE/UPDATE.) > > (Maybe there is a good reason - I just don't see it.) > > Section 4.3: > > The following: > > When a SIP entity is about to send a keep-alive, if the SIP entity at > the same time is also about to send or forward a SIP request > associated with the same registration or dialog, for which the keep- > alive is to be sent, the SIP entity MAY choose not to send the keep- > alive, as the SIP request will perform the same keep-alive action. > > seems pretty imprecise. Wouldn't it be more precise to state that every > request sent resets the clock for when a keep-alive needs to be sent? > > Also, while this skipping of the explicit keep-alive makes sense to me, > AFAICT it isn't consistent with -outbound-. > > Section 5: > > The following has me totally confused: > > SIP Outbound uses the Flow-Timer header field to indicate the server- > recommended keep-alive frequency. However, it will only be sent > between a UA and an edge proxy. Using the "keep" parameter, however, > the sending and receiving of keep-alives might be negotiated between > multiple entities on the signalling path. Since the server- > recommended keep-alive frequency might vary between different SIP > entities, those would have to re-write the Flow-Timer header field > value. In addition, if a SIP entity does not indicate willingness to > receive keep-alives from its adjacent downstream SIP entity, and > receives a Flow-Timer header field in a response, it would have to > remove the Flow-Timer header field from the response. This issue > does not exist for the "keep" parameter, as each SIP entity has its > own individual Via header field. > > (There are too many hypotheticals in it.) > > After reading this, I don't know: > > - can I use keep in conjunction with an outbound registration? > - if so, does this alter the procedures of outbound - requiring some > manipulation of the Flow-Timer value? > > Thanks, > Paul > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > From Martin.Thomson@andrew.com Sat Jul 24 12:12:33 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A88A53A68EC for ; Sat, 24 Jul 2010 12:12:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[AWL=-0.898, 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 PTY90qK5tJWF for ; Sat, 24 Jul 2010 12:12:29 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 7F3693A67D1 for ; Sat, 24 Jul 2010 12:12:29 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:37753 "EHLO ACDCE7HC1.commscope.com") by csmailgw2.commscope.com with ESMTP id S321012Ab0GXTMs (ORCPT ); Sat, 24 Jul 2010 14:12:48 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Sat, 24 Jul 2010 14:12:48 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Sun, 25 Jul 2010 03:12:45 +0800 From: "Thomson, Martin" To: "Winterbottom, James" , Paul Kyzivat , "DOLLY, MARTIN C (ATTLABS)" Date: Sun, 25 Jul 2010 03:14:55 +0800 Thread-Topic: [sipcore] draft-ietf-sipcore-location-conveyance-03 Thread-Index: AcsqCCkC/eZSicZvQ2W07Pr3d5AAHQAAC2+AAFb3G0A= Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB7734ED@SISPE7MB1.commscope.com> References: <14C85D6CCBE92743AF33663BF5D24EBA02BD513A@gaalpa1msgusr7e.ugd.att.com> <4C48F332.9080500@cisco.com> <5A55A45AE77F5941B18E5457ECAC81880120E982984D@SISPE7MB1.commscope.com> In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880120E982984D@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "sipcore@ietf.org" Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-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: Sat, 24 Jul 2010 19:12:34 -0000 V2UgY291bGQgbGVhdmUgaXQgdW5zcGVjaWZpZWQgYW5kIHJlbHkgb24gcGVvcGxlJ3MgaW50ZWxs aWdlbmNlLCBvciwgd2UgY291bGQgZG8gZXZlcnlvbmUgYSBmYXZvdXIgYW5kIGdpdmUgYSBmZXcg bGl0dGxlIGNsdWVzIGZvciBlYWNoIGFuZCBldmVyeSBuZXcgaGVhZGVyLg0KDQpDb21lIHRoZSBy ZXdyaXRlIG9mIDMyNjEgKGhhaCksIHRoaXMgY29sbGVjdGVkIHdpc2RvbSBjb3VsZCBiZSBhY2N1 bXVsYXRlZC4gIEl0IGRvZXNuJ3Qgc2VlbSBsaWtlIGEgYmlnIHByb2JsZW0gcmlnaHQgbm93Lg0K DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IFdpbnRlcmJvdHRvbSwgSmFt ZXMNCj4gU2VudDogRnJpZGF5LCAyMyBKdWx5IDIwMTAgMzo0NSBBTQ0KPiBUbzogUGF1bCBLeXpp dmF0OyBET0xMWSwgTUFSVElOIEMgKEFUVExBQlMpDQo+IENjOiBUaG9tc29uLCBNYXJ0aW47IGpt cG9sa0BjaXNjby5jb207IHNpcGNvcmVAaWV0Zi5vcmcNCj4gU3ViamVjdDogUkU6IFtzaXBjb3Jl XSBkcmFmdC1pZXRmLXNpcGNvcmUtbG9jYXRpb24tY29udmV5YW5jZS0wMw0KPiANCj4gSGkgUGF1 bCwNCj4gDQo+IEkgYW0gb2theSB3aXRoIGFsbCBvZiB0aGF0LCBidXQgaXQgc2VlbXMgbGlrZSB3 aGF0IGlzIGJlaW5nIHByb3Bvc2VkDQo+IHNob3VsZCBhcHBseSB0byBhbnkgaGVhZCB0aGF0IGEg cHJveHkgbWF5IGluc2VydCwgcmF0aGVyIHRoYW4ganVzdA0KPiBzb21ldGhpbmcgdGhhdCBzcGVj aWZpYyB0byB0aGUgZ2VvbG9jYXRpb24gaGVhZGVyIGNhc2UuDQo+IA0KPiBJIGRvbid0IGZvciBv bmUgc2Vjb25kIHN1Z2dlc3QgdGhhdCBwdXR0aW5nIHNvbWV0aGluZyB0byB0aGlzIGVmZmVjdCBp bg0KPiB0aGUgbG9jYXRpb24gY29udmV5YW5jZSBkcmFmdCBpcyBhIGJhZCBpZGVhLCBidXQgcGVy aGFwcyBhIGdlbmVyYWwNCj4gc3RhdGVtZW50IHRvIHRoZSBzYW1lIGVmZmVjdCB3b3VsZCBiZSB3 b3J0aCBhZGRpbmcgdG8gc29tZXRoaW5nIGxpa2UNCj4gdGhlIDMyNjEgY29yZSBmaXhlcyBkb2N1 bWVudCBhbHNvLg0KPiANCj4gQ2hlZXJzDQo+IEphbWVzDQo+IA0KPiANCj4gDQo+IA0KPiANCj4g PiAtLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPiA+IEZyb206IFBhdWwgS3l6aXZhdCBbbWFp bHRvOnBreXppdmF0QGNpc2NvLmNvbV0NCj4gPiBTZW50OiBGcmlkYXksIDIzIEp1bHkgMjAxMCAx MTo0MSBBTQ0KPiA+IFRvOiBET0xMWSwgTUFSVElOIEMgKEFUVExBQlMpDQo+ID4gQ2M6IFdpbnRl cmJvdHRvbSwgSmFtZXM7IFRob21zb24sIE1hcnRpbjsgam1wb2xrQGNpc2NvLmNvbTsNCj4gPiBz aXBjb3JlQGlldGYub3JnDQo+ID4gU3ViamVjdDogUmU6IFtzaXBjb3JlXSBkcmFmdC1pZXRmLXNp cGNvcmUtbG9jYXRpb24tY29udmV5YW5jZS0wMw0KPiA+DQo+ID4gU0lQICpkb2VzKiBoYXZlIGEg Y29tcGF0aWJpbGl0eSBtZWNoYW5pc20uIElmIHRoZSA0MjQgKmRvZXMqIGdldCBiYWNrDQo+IHRv DQo+ID4gYW4gdW5hd2FyZSBVQUMsIHRoZW4gaXQgd2lsbCBiZSB0cmVhdGVkIGVxdWl2YWxlbnRs eSB0byBhIDQwMC4NCj4gPg0KPiA+IFRoZSBwcm9ibGVtIGFyaXNlcyBpZiB0aGF0IGlzIGFuIGlu c3VmZmljaWVudCB3YXkgb2YgZGVhbGluZy4NCj4gPiBUaGUgZGVzaWduIG9mIHRoZSA0MjQgcmVz cG9uc2UgaXMgYmFzZWQgb24gdGhlIGFzc3VtcHRpb24gdGhhdCB0aGUNCj4gPiByZWNpcGllbnQg d2lsbCB1bmRlcnN0YW5kIGl0IGFuZCBtYWtlIGEgc3VpdGFibGUgcmV0cnkuIEFuIHVuYXdhcmUN Cj4gVUFDDQo+ID4gd29uJ3QgZG8gdGhhdC4NCj4gPg0KPiA+IFRoZSB3b3JkcyBNYXJ0aW4gb2Zm ZXJlZCBzZWVtIHN1ZmZpY2llbnQgdG8gbWUuIElmIHRoZSByZXNwb25zaWJsZQ0KPiBwcm94eQ0K PiA+IGlzIHNhdGlzZmllZCB3aXRoIHRoZSBjb25zZXF1ZW5jZXMgb2YgYWxsb3dpbmcgdGhlIFVB QyB0byBnZXQgdGhlDQo+IDQyNCwNCj4gPiB0aGVuIHRoYXQgdG9vIGlzIG9rLg0KPiA+DQo+ID4g SXQgY291bGQgYmUgbGVmdCB1bnN0YXRlZCwgb24gdGhlIGFzc3VtcHRpb24gdGhhdCBpdCB3aWxs IGJlIGV2aWRlbnQNCj4gdG8NCj4gPiBhbiBpbmZvcm1lZCBkZXZlbG9wZXIuIEJ1dCBpbiBteSBl eHBlcmllbmNlIG11Y2ggb2YgdGhlIHN0dWZmIHRoYXQNCj4gc2VlbXMNCj4gPiBldmlkZW50IHRv IHVzIHR1cm5zIG91dCAqbm90KiB0byBiZSBldmlkZW50IHRvIG1hbnkgZGV2ZWxvcGVycy4NCj4g Pg0KPiA+IAlUaGFua3MsDQo+ID4gCVBhdWwNCj4gPg0KPiA+IERPTExZLCBNQVJUSU4gQyAoQVRU TEFCUykgd3JvdGU6DQo+ID4gPiBBIGdvb2QgcHJvdG9jb2wgd291bGQgaGF2ZSBhIGNvbXBhdGli aWxpdHkgbWVjaGFuaXNtLi4ubW1tDQo+ID4gPiBNYXJ0aW4gQy4gRG9sbHkNCj4gPiA+IFNlbnQg dG8geW91IGJ5IEFUJlQuLi4gQW1lcmljYSdzIEZhc3Rlc3QgTW9iaWxlIEJyb2FkYmFuZCBOZXR3 b3JrLg0KPiA+IFJldGhpbmsgUG9zc2libGUuDQo+ID4gPiArMS42MDkuOTAzLjMzNjANCj4gPiA+ DQo+ID4gPiAtLS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQo+ID4gPiBGcm9tOiBzaXBjb3Jl LWJvdW5jZXNAaWV0Zi5vcmcgPHNpcGNvcmUtYm91bmNlc0BpZXRmLm9yZz4NCj4gPiA+IFRvOiBU aG9tc29uLCBNYXJ0aW4gPE1hcnRpbi5UaG9tc29uQGFuZHJldy5jb20+OyBQYXVsIEt5eml2YXQN Cj4gPiA8cGt5eml2YXRAY2lzY28uY29tPjsgSmFtZXMgTS4gUG9sayA8am1wb2xrQGNpc2NvLmNv bT4NCj4gPiA+IENjOiBTSVBDT1JFIDxzaXBjb3JlQGlldGYub3JnPg0KPiA+ID4gU2VudDogVGh1 IEp1bCAyMiAyMDo0Mzo1OSAyMDEwDQo+ID4gPiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIGRyYWZ0 LWlldGYtc2lwY29yZS1sb2NhdGlvbi1jb252ZXlhbmNlLTAzDQo+ID4gPg0KPiA+ID4gVGhpcyBt YXkgYmUgaWdub3JhbmNlIG9uIG15IHBhcnQsIGJ1dCBJIGFtIGdvaW5nIHRvIGFzc3VtZSB0aGF0 DQo+IHRoaXMgaXMNCj4gPiBub3QgdGhlIGZpcnN0IG5ldyBoZWFkZXIgYWRkZWQgdG8gdGhlIFNJ UCBzaW5jZSBSRkMzMjYxLCBhbmQgc28gaXQgaXMNCj4gYWxzbw0KPiA+IG5vdCB0aGUgZmlyc3Qg Y2FzZSB3aGVyZSBhbiBlcnJvciBtaWdodCBjb21lIGJhY2sgZnJvbSBhYm91dCBhIGhlYWRlcg0K PiB0aGF0DQo+ID4gaGFzIGJlZW4gaW5zZXJ0ZWQgYWxvbmcgdGhlIHdheS4NCj4gPiA+DQo+ID4g PiBXaGF0IGhhcHBlbnMgaW4gdGhlc2Ugb3RoZXIgY2FzZXM/DQo+ID4gPg0KPiA+ID4gQ2hlZXJz DQo+ID4gPiBKYW1lcw0KPiA+ID4NCj4gPiA+DQo+ID4gPg0KPiA+ID4NCj4gPiA+DQo+ID4gPj4g LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gPiA+PiBGcm9tOiBzaXBjb3JlLWJvdW5jZXNA aWV0Zi5vcmcgW21haWx0bzpzaXBjb3JlLWJvdW5jZXNAaWV0Zi5vcmddDQo+IE9uDQo+ID4gQmVo YWxmDQo+ID4gPj4gT2YgVGhvbXNvbiwgTWFydGluDQo+ID4gPj4gU2VudDogRnJpZGF5LCAyMyBK dWx5IDIwMTAgMTA6MTQgQU0NCj4gPiA+PiBUbzogUGF1bCBLeXppdmF0OyBKYW1lcyBNLiBQb2xr DQo+ID4gPj4gQ2M6IFNJUENPUkUNCj4gPiA+PiBTdWJqZWN0OiBSZTogW3NpcGNvcmVdIGRyYWZ0 LWlldGYtc2lwY29yZS1sb2NhdGlvbi1jb252ZXlhbmNlLTAzDQo+ID4gPj4NCj4gPiA+Pj4+PiBJ U1RNIHRoZXJlIG5lZWRzIHRvIGJlIGEgcmVxdWlyZW1lbnQgdGhhdCB0aGUgaW50ZXJtZWRpYXJ5 DQo+IGluc2VydGluZw0KPiA+ID4+Pj4+IHRoZSBHZW9sb2NhdGlvbiBoZWFkZXIgaGFuZGxlIGFu eSA0MjQgZXJyb3JzIHRoYXQgbWlnaHQgcmVzdWx0DQo+IGZyb20NCj4gPiA+Pj4+PiBpdCwgdGh1 cyBzaGllbGRpbmcgdGhlIFVBQyBmcm9tIHRob3NlLg0KPiA+ID4+Pj4gRG8geW91IHRoaW5rIHdl IGNhbiBzdGF0ZSB0aGlzPyAgSSdtIHRoaW5raW5nIGZyb20gYSBwdXJlc3QNCj4gcHJvdG9jb2wN Cj4gPiA+Pj4+IHBvdiwgdGhhdCBzZWVtcyB0byBtZSB0byBicmVhayBTSVAncyBlMmUgbW9kZWwg b2YgY29tbXVuaWNhdGlvbiwNCj4gPiA+Pj4+IGVzcGVjaWFsbHkgd2hlbiBpbnZvbHZpbmcgYSBs aXRlcmFsIHByb3h5IC0gYW5kIG5vdCBzb21lIG90aGVyDQo+IGZvcm0NCj4gPiA+Pj4gb2YNCj4g PiA+Pj4+IFNJUCBpbnRlcm1lZGlhcnkgKGUuZy4sIGIyYnVhIG9yIHNiYyB0aGF0IGFyZSBtYWRl IHRvIGRvIGp1c3QNCj4gdGhpcykuDQo+ID4gPj4gTm8gaGFybSBpbiBtYWtpbmcgYSBzdGF0ZW1l bnQgYWJvdXQgdGhpcy4gIE9mIGNvdXJzZSwgdGhpcyBzb3J0IG9mDQo+ID4gPj4gYmVoYXZpb3Vy IGNvdWxkIHNpbXBseSBiZSBpbXBsaWVkLiAgSWYgdGhlIGludGVybWVkaWFyeSBpcyBhY3RpbmcN Cj4gYXMgYQ0KPiA+ID4+IEIyQlVBLCB3aGVuIGl0IGFkZHMgYSBmZWF0dXJlLCBpdCBjYW4gKGFu ZCBzaG91bGQpIGFic29yYiB0aGUNCj4gPiBjb25zZXF1ZW5jZXMNCj4gPiA+PiBvZiB0aGF0LiAg Rm9yIGdlb2xvY2F0aW9uLCBpZiBpdCBhZGRzIHRoZSBoZWFkZXIsIGl0IG11c3QgYmUNCj4gcHJl cGFyZWQNCj4gPiBmb3INCj4gPiA+PiB0aGUgY29uc2VxdWVuY2VzIG9mIHRoYXQgKDQyNCkuDQo+ ID4gPj4NCj4gPiA+PiBJJ2xsIGxlYXZlIGl0IHRvIHRoZSBkaXNjcmV0aW9uIG9mIHRoZSBlZGl0 b3JzIGhvdyBtdWNoIHRoZXkgd2FudA0KPiB0bw0KPiA+IGRhbmNlDQo+ID4gPj4gYXJvdW5kIHRo ZSBzZW5zaXRpdml0aWVzLiAgQnV0IHlvdSBjb3VsZCBqdXN0IHNheToNCj4gPiA+Pg0KPiA+ID4+ IEFuIGludGVybWVkaWFyeSB0aGF0IGFkZHMgYSBnZW9sb2NhdGlvbiBoZWFkZXIgTVVTVCBiZSBw cmVwYXJlZCB0bw0KPiA+IGhhbmRsZQ0KPiA+ID4+IGFueSBlcnJvcnMgdGhhdCB0aGlzIG1pZ2h0 IHJlc3VsdCBpbiwgaW5jbHVkaW5nIGEgNDI0IHJlc3BvbnNlLg0KPiBUaGUNCj4gPiA+PiBpbnRl cm1lZGlhcnkgbWlnaHQgdGhlbiB0cmFuc2xhdGUgdGhpcyBlcnJvciBpbnRvIGFuIGVycm9yIHRo YXQNCj4gdGhlIFVBQw0KPiA+IGlzDQo+ID4gPj4ga25vd24gdG8gc3VwcG9ydCwgb3IuLi4NCj4g PiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+ ID4+IHNpcGNvcmUgbWFpbGluZyBsaXN0DQo+ID4gPj4gc2lwY29yZUBpZXRmLm9yZw0KPiA+ID4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KPiA+ID4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPiA+IHNpcGNv cmUgbWFpbGluZyBsaXN0DQo+ID4gPiBzaXBjb3JlQGlldGYub3JnDQo+ID4gPiBodHRwczovL3d3 dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmUNCg== From marianne.mohali@orange-ftgroup.com Sat Jul 24 18:09:59 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B783B3A683A for ; Sat, 24 Jul 2010 18:09:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.905 X-Spam-Level: X-Spam-Status: No, score=-0.905 tagged_above=-999 required=5 tests=[AWL=1.345, 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 O+qzoGxRGSIa for ; Sat, 24 Jul 2010 18:09:58 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (r-mail1.rd.francetelecom.com [217.108.152.41]) by core3.amsl.com (Postfix) with ESMTP id 64B883A681C for ; Sat, 24 Jul 2010 18:09:58 -0700 (PDT) Received: from r-mail1.rd.francetelecom.com (localhost.localdomain [127.0.0.1]) by localhost (Postfix) with SMTP id ADCD56C000F; Sun, 25 Jul 2010 03:10:29 +0200 (CEST) Received: from ftrdsmtp1.rd.francetelecom.fr (unknown [10.192.128.46]) by r-mail1.rd.francetelecom.com (Postfix) with ESMTP id 68D576C0005; Sun, 25 Jul 2010 03:10:29 +0200 (CEST) Received: from ftrdmel1.rd.francetelecom.fr ([10.192.128.40]) by ftrdsmtp1.rd.francetelecom.fr with Microsoft SMTPSVC(6.0.3790.3959); Sun, 25 Jul 2010 03:10:16 +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: Sun, 25 Jul 2010 03:09:24 +0200 Message-ID: In-Reply-To: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Updated 4244bis and new call flow document Thread-Index: AcsZU/jTtxJqbmI3RluR8O2hA514sgQ3DVEg References: From: To: , X-OriginalArrivalTime: 25 Jul 2010 01:10:16.0698 (UTC) FILETIME=[2475CDA0:01CB2B96] Subject: Re: [sipcore] Updated 4244bis and new call flow document X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 25 Jul 2010 01:09:59 -0000 Hi Mary and all, I have some comments on draft-ietf-sipcore-rfc4244bis-01: 1- Regarding the "hit" and "target" parameters, is it really necessary = to create both?=20 I mean the "hit" parameter seems almost useless as it has to be = removed from the R-URI just=20 after its creation (kept only in the Contact header after a 3xx). Why the hi-target couldn't be a single parameter to tag URIs? 2- =A74.1 it is said that=20 "The entries SHOULD be evaluated to determine gaps in indices,=20 which could indicate that an entry has been maliciously removed. =20 Either way, an application SHOULD be aware of potentially missing = information."=20 If the removed hi-entry is the last destination (leaf) of an = unsuccessful route (branch),=20 how is it possible, at the end, to know that there is a missing entry? 3- =A75.1.1 At the end of the second sentence, there are 2 right = parenthesis. =A76.3.1 after reference to [RFC3261], there are 2 right square = brackets. 4- =A76.1 In the rules after the header syntax, the sentence=20 "There MUST be no more than one hi-target parameter."=20 should be completed with "per hi-entry" to be more precise (as it is = the case in the previous item). 5- =A76.3.2 In the sentence=20 "This is accomplished by adding a new priv-value, history, to the Privacy header [RFC3323] indicating that a specific History-Info header entry can not be forwarded outside the domain." It should be better to complete with : To do this, the Privacy header = with the priv-value history is=20 escaped in the hi-entry corresponding to the concerned URI. 6- =A77:=20 "For example, an Automatic Call Distribution (ACD)/Call center = application that utilizes the entry prior to the first History-Info entry with = an hi-target value of "mp", ..." Do you mean the entry with the index that matches the first = History-Info entry with an hi-target value of "mp"? (instead of the = prior) 7- Appendix B.2 and B.3: what is the "p=3Dx" in the URI? Cheers, Marianne=20 -----Message d'origine----- De : sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] De la = part de Mary Barnes Envoy=E9 : jeudi 1 juillet 2010 21:31 =C0 : SIPCORE Objet : Re: [sipcore] Updated 4244bis and new call flow document Hi folks, I have not seen any responses to this email. So, either folks don't see = any issues with the documents and 4244bis is ready for WGLC or folks = have not reviewed the documents. I'm happy to assume the former, = however, it would be good for folks that have read the docs to post a = note on the mailing list as to whether they think 4244bis is ready for = WGLC. And, if not, please detail your concerns, so that we can = determine whether they warrant discussion in Maastricht. Also, opinions on how/where to progress the call flow document would be = welcome. I personally do not think it's worthwhile to pursue this in = DISPATCH, but it's not clear to me whether informational docs like this = are under the purview of the SIPCORE charter. Since BLISS is trying to = close down, it is also not appropriate to pursue the work there. Thanks, Mary. On Thu, Jun 24, 2010 at 3:11 PM, Mary Barnes = wrote: > Hi folks, > > The 4244bis draft has been updated and a separate call flow document=20 > created per the earlier summary of proposed changes: > http://www.ietf.org/mail-archive/web/sipcore/current/msg02647.html > > http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-01.txt > http://www.ietf.org/id/draft-barnes-sipcore-rfc4244bis-callflows-00.tx > t > > There are =A0two voicemail examples in the new call flow document. = =A0The=20 > 4244bis has 3 call flows - the basic sequential forking and two=20 > privacy examples. All the rest are now in the call flow document. > > The other changes we made were updates to the UAC, UAS and application = > considerations section - adding additional text as to how the UAC and=20 > UAS process hi-entries (including related to responses). =A0The=20 > application considerations section now describes how the tags can be=20 > used to derive specific information and the past guidelines were=20 > removed since 4244bis has much definitive guidance on the normative=20 > aspects of the header (i.e., SHOULDs replaced with MUSTs, privacy via=20 > anonymization rather than removing entries, etc.) as summarized in=20 > Section 11. > > Please review and provide any additional comments. We believe that=20 > 4244bis is pretty much ready to go. We can fine tune the details in=20 > the call flows and should be able to get that ready very soon, as=20 > well. =A0Let us know if you see additional use cases you would like to = > add. > > Thanks, > Mary et al > _______________________________________________ sipcore mailing list sipcore@ietf.org https://www.ietf.org/mailman/listinfo/sipcore From peter.musgrave@magorcorp.com Sun Jul 25 04:31:33 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 8A8FE3A6880 for ; Sun, 25 Jul 2010 04:31:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.224 X-Spam-Level: X-Spam-Status: No, score=-2.224 tagged_above=-999 required=5 tests=[AWL=-0.247, 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 8IC0C987WhaM for ; Sun, 25 Jul 2010 04:31:32 -0700 (PDT) Received: from mail-qy0-f172.google.com (mail-qy0-f172.google.com [209.85.216.172]) by core3.amsl.com (Postfix) with ESMTP id 6CBC73A682E for ; Sun, 25 Jul 2010 04:31:32 -0700 (PDT) Received: by qyk1 with SMTP id 1so1285552qyk.10 for ; Sun, 25 Jul 2010 04:31:52 -0700 (PDT) MIME-Version: 1.0 Received: by 10.224.19.144 with SMTP id a16mr4923771qab.346.1280057511870; Sun, 25 Jul 2010 04:31:51 -0700 (PDT) Received: by 10.229.20.198 with HTTP; Sun, 25 Jul 2010 04:31:51 -0700 (PDT) Date: Sun, 25 Jul 2010 13:31:51 +0200 Message-ID: From: Peter Musgrave To: SIPCORE Content-Type: text/plain; charset=ISO-8859-1 Subject: Re: [sipcore] draft-ietf-sipcore-keep X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 25 Jul 2010 11:31:33 -0000 Hi, I have read draft-ietf-sipcore-keep in detail for the first time. I have one questions and some Nits. Question: 7.3 Should the TRYING (not shown) from P1 to Alice have keep=30 in it? What if the 200 OK takes e.g. longer than 30sec and the NAT pinhole closes? I think the draft is in very good shape. Peter Musgrave Nits 1. s/Eventhough/Even though/ 1.3 "As specified in [RFC5626], usage keep-alives is not implicitly negotiated for such flows, why usage needs to be explicitly negotiated." Re-phrase? 4.2.1 s/The section/This section/ 4.4 para 2. This paragraph is one sentence. I read it many times - I gave up. From jmpolk@cisco.com Sun Jul 25 06:33:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0E3BF3A68C5 for ; Sun, 25 Jul 2010 06:33:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sYunc1CQgExV for ; Sun, 25 Jul 2010 06:33:12 -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 E4A9A3A6823 for ; Sun, 25 Jul 2010 06:33:11 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208";a="138860658" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2010 13:33:31 +0000 Received: from jmpolk-wxp01.cisco.com (ams3-vpn-dhcp5712.cisco.com [10.61.86.79]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6PDXURn019180; Sun, 25 Jul 2010 13:33:31 GMT Message-Id: <201007251333.o6PDXURn019180@rtp-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 25 Jul 2010 05:10:55 -0500 To: "Thomson, Martin" , "James M. Polk" , "sipcore@ietf.org" From: "James M. Polk" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E9DCD0D7@SISPE7MB1.comms cope.com> References: <201007122355.o6CNt6us024310@sj-core-3.cisco.com> <8B0A9FCBB9832F43971E38010638454F03E9DCCFFC@SISPE7MB1.commscope.com> <201007130629.o6D6Tk7F028645@sj-core-2.cisco.com> <8B0A9FCBB9832F43971E38010638454F03E9DCD0D7@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] location-conveyance-03 just 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: Sun, 25 Jul 2010 13:33:13 -0000 At 07:09 PM 7/13/2010, Thomson, Martin wrote: >Hi James, > > > > >The draft doesn=C3=A2=80=99t really justify the existence > > >of the "geolocaocation" option tag. > > > > what would justify it? > > > > the purpose of an option-tag is the ability to > > indicate support for an extension (whether > > optional or required), and to respond with > > whether or not an extension is supported or > > unsupported. This indication can be quite > > important for communicating SIP elements to > > understand support for (or not). I'm confused... > >Why is indicating support for (or requirement=20 >of) this particular feature important? If a UAC=20 >includes the header, is that not sufficient=20 >indication of support? What reason might a UAC=20 >have for requiring that the UAS supports the feature? if I hasn't answer this point, here are a couple of reasons for this - a UAS can be responding to an OPTIONS query,=20 indicating it supports geolocation too. - a UAC could include this option tag in a=20 OPTIONS request, even though it included no geolocation header value. - a UAS could need this to indicate it doesn't=20 support an extension in SIP. Sending this option=20 tag in an Unsupported header value is important in this case >One justification for Supported might be that it=20 >is not possible to send 424 without some prior=20 >acknowledgement that the code is understood by=20 >the UAC. That might be sufficient. I don't believe an Unsupported header value can=20 contain an option tag it didn't support that=20 wasn't in the SIP request it is responding to. James=20 From jmpolk@cisco.com Sun Jul 25 06:33:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 464BA3A6944 for ; Sun, 25 Jul 2010 06:33:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.555 X-Spam-Level: X-Spam-Status: No, score=-10.555 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DATE_IN_PAST_03_06=0.044, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKDpVmxpCCpm for ; Sun, 25 Jul 2010 06:33:13 -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 BCD2F3A6839 for ; Sun, 25 Jul 2010 06:33:12 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208";a="138905429" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 Jul 2010 13:33:32 +0000 Received: from jmpolk-wxp01.cisco.com (ams3-vpn-dhcp5712.cisco.com [10.61.86.79]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6PDXURp019180; Sun, 25 Jul 2010 13:33:32 GMT Message-Id: <201007251333.o6PDXURp019180@rtp-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 25 Jul 2010 05:26:02 -0500 To: "Thomson, Martin" , "James M. Polk" , "sipcore@ietf.org" From: "James M. Polk" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E9DCD1AE@SISPE7MB1.comms cope.com> References: <201007122355.o6CNt6us024310@sj-core-3.cisco.com> <8B0A9FCBB9832F43971E38010638454F03E9DCCFFC@SISPE7MB1.commscope.com> <201007130629.o6D6Tk7F028645@sj-core-2.cisco.com> <8B0A9FCBB9832F43971E38010638454F03E9DCD0D7@SISPE7MB1.commscope.com> <201007140201.o6E2138L023850@sj-core-1.cisco.com> <8B0A9FCBB9832F43971E38010638454F03E9DCD1AE@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] location-conveyance-03 just 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: Sun, 25 Jul 2010 13:33:14 -0000 At 02:08 AM 7/14/2010, Thomson, Martin wrote: > > >The use case is basically: route based on the > > >value, but provide a reference so that a PSAP > > >can get better location information later; that > > >is, updated or more accurate location. That's > > >not possible if the UAC does the dereference: > > >the location information becomes fixed. > > > > "...UAC does the dereference"? Do you mean to > > understand that the UAC inserts location towards > > an intermediary, gets a rejection 424, with the > > intermediary's version of where the UAC is - > > possibly as a location URI, and has to > > dereference that URI to compose the now dual location MIME body? > >No - I'm saying that my major issue is driven by that use >case. There is (currently) no way for any entity (UAC or >intermediary) to insert both location by value and location by >reference. There is a need for that capability. > > > We mean to have the intermediary do the > > dereference (if one is needed) and compose in the > > SIP 424 response a MIME body with both the > > server's version or both locations of the Target, > > and for that dual location single presence > > document to be copied into the next SIP request > > from that UAC (towards that same intermediary). > >Elegant as it is, this just doesn't work. The UAS (PSAP, LR, >etc...) needs to be the entity that does the dereference. They need >to do this because they know how (and when) to make this request so >that they get the information they need. If the intermediary does >the dereference, then location information is set in stone from that >point onward. specifically to this last part, if the intermediary does the composition - it in fact does know how to do this, but does not do it exactly when you may want, and you're right, this is then "in stone" without a subscription back to the UAC (geo-filters style) for any updates it needs. I'm not sure you're gonna be able to get away from this whenever a PSAP gets a value BTW. It can never be 100% certain your getting a reachable location URI for that Target, and the PSAP is in the best position to do this "get/update" function. James From jmpolk@cisco.com Sun Jul 25 06:33:15 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 915B73A6952 for ; Sun, 25 Jul 2010 06:33:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.577 X-Spam-Level: X-Spam-Status: No, score=-10.577 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrHKNWesFuBV for ; Sun, 25 Jul 2010 06:33:14 -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 59ED43A6823 for ; Sun, 25 Jul 2010 06:33:13 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208";a="138860660" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2010 13:33:33 +0000 Received: from jmpolk-wxp01.cisco.com (ams3-vpn-dhcp5712.cisco.com [10.61.86.79]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6PDXURr019180; Sun, 25 Jul 2010 13:33:33 GMT Message-Id: <201007251333.o6PDXURr019180@rtp-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 25 Jul 2010 05:37:38 -0500 To: "Thomson, Martin" , "Peterson, Jon" , "James M. Polk" , "sipcore@ietf.org" From: "James M. Polk" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03E9DCD24A@SISPE7MB1.comms cope.com> References: <8B0A9FCBB9832F43971E38010638454F03E9DCD1AE@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F03E9DCD24A@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] location-conveyance-03 just 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: Sun, 25 Jul 2010 13:33:15 -0000 At 08:33 PM 7/14/2010, Thomson, Martin wrote: >Hi Jon, > >There=E2=80=99s a number of issues here. I think that=20 >we need to disentangle them. The role of the=20 >intermediary in this dealing with this problem is a secondary concern. > >There are two primary reasons for having both=20 >value and reference: authorization and dynamism. > >Dynamism is the easiest one to pin down. It's=20 >obviously very important to the emergency=20 >scenario - the ability of a PSAP to acquire=20 >updated location information in a timely fashion=20 >is central to many of their use cases. Martin - how long are you expecting this initial=20 INVITE to go from the UAC to the PSAP? You're giving the impression that a second or two=20 matters or the UAC will be in a completely=20 different location, meaning the wrong PSAP will be contacted. Is that really probable here? If it's an infrequent case of a corner-case=20 (calling 911/112 in the first place)... >draft-ecrit-rough-loc describes a scenario where=20 >the UAC is less authorized than the UAS;=20 >intermediaries are authorized differently. In=20 >the canonical example, the UAS gets a rubbish=20 >location value and a location reference that=20 >they can't use. The rubbish location is enough=20 >to get them to a PSAP. The PSAP uses the=20 >reference because they are authorized. > >In either case, it's possible to leave the=20 >intermediary out of consideration and=20 >concentrate on the information that the UAC provides. but what about environments (or networks) that=20 don't trust the UE (or UAC) at all. I'd argue=20 that's much more probable -- because that's how 3GPP treats their phones. >The great thing with the solution that you've=20 >proposed is that this is ultimately what happens=20 >in any case. Leaving the b2bua case aside, the=20 >UAC is ultimately responsible for what Geolocation is placed in the= request. not true for 3GPP, which in theory, will be a=20 fair number of endpoints (as in more than 50% of many countries, right? How will what you're describing fit their network architecture? >The interactions with the intermediary add=20 >complexity to the scenario, including some=20 >privacy model problems, primarily with retransmission. meaning UDP vs TCP? James > I'd like to solve the easier problem first. > >--Martin > > >From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >Sent: Thursday, 15 July 2010 3:09 AM >To: Thomson, Martin; James M. Polk; sipcore@ietf.org >Subject: Re: [sipcore] location-conveyance-03 just submitted > > >[snip] > > We mean to have the intermediary do the > > dereference (if one is needed) and compose in the > > SIP 424 response a MIME body with both the > > server's version or both locations of the Target, > > and for that dual location single presence > > document to be copied into the next SIP request > > from that UAC (towards that same intermediary). > >Elegant as it is, this just doesn't work. =C2 The=20 >UAS (PSAP, LR, etc...) needs to be the entity=20 >that does the dereference. =C2 They need to do=20 >this because they know how (and when) to make=20 >this request so that they get the information=20 >they need. =C2 If the intermediary does the=20 >dereference, then location information is set in stone from that point= onward. > > I see your point, but I think the=20 >difficulty is deeper still than this. The whole=20 >use case for an intermediary providing different=20 >(or supplementary) location information above=20 >and beyond the location provided by the UAC is=20 >based on the intermediary inspecting, and=20 >disliking, the location present in the request.=20 >If that location is constantly changing, what=20 >would it mean for the intermediary to dislike=20 >it? Maybe it likes it one minute and not the=20 >next? Would it =ADever- be safe for a picky=20 >inttermediary to allow a reference to pass it,=20 >given that it couldn=E2=80=99t control what location=20 >the LR would ultimately get from it? Moreover,=20 >what if the creator of the reference authorizes=20 >the end recipient (the PSAP) but not the=20 >intermediary that wants to judge location=20 >information? I think we=E2=80=99d need to look further=20 >into the motivations here to understand the underlying requirement. > >Practically speaking, however, there are a=20 >number of potential work-arounds to enable this=20 >semantic =AD I don=E2=80=99t necessarilyy think that=20 >once the intermediary performs the dereference,=20 >then the location information must be set in=20 >stone. If you seriously want to retain the=20 >dynamism of location information, it could=20 >become the responsibility of the compositor to=20 >deliver a similarly dynamic reference, and every=20 >time someone dereferences the composed object,=20 >the compositor creates a new PIDF-LO document=20 >based on freshly dereferencing any dynamic=20 >components of the location information. Another=20 >possibility would be to specify external=20 >references in PIDF, so we could compose location=20 >information from dynamic sources by reference in=20 >the PIDF object, rather than by value. One=20 >composed object could even have a mix of=20 >by-value and by-reference location information=20 >in that case. The important thing is that we=20 >solve this down in the PIDF level, within the=20 >parameters of RFC4479, rather than trying to=20 >cobble together some relationship between=20 >devices, services and users in the Geolocation header. > >Anyway, none of this is to suggest that this is=20 >adequately specified in the current draft, or=20 >something. We=E2=80=99d need to have a more lengthy=20 >discussion about some of the issues above before=20 >figuring out what we=E2=80=99d add, though. > >Jon Peterson >NeuStar, Inc. From jmpolk@cisco.com Sun Jul 25 06:33:16 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2476C3A6969 for ; Sun, 25 Jul 2010 06:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.284 X-Spam-Level: X-Spam-Status: No, score=-10.284 tagged_above=-999 required=5 tests=[AWL=-0.285, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hpYYMN1mVIRz for ; Sun, 25 Jul 2010 06:33:14 -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 5BEE43A695B for ; Sun, 25 Jul 2010 06:33:14 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208";a="138860662" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2010 13:33:34 +0000 Received: from jmpolk-wxp01.cisco.com (ams3-vpn-dhcp5712.cisco.com [10.61.86.79]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6PDXURt019180; Sun, 25 Jul 2010 13:33:33 GMT Message-Id: <201007251333.o6PDXURt019180@rtp-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 25 Jul 2010 05:46:16 -0500 To: "Roger Marshall" , "Thomson, Martin" , "Peterson, Jon" , "James M. Polk" , From: "James M. Polk" In-Reply-To: <8C837214C95C864C9F34F3635C2A6575135CDD92@SEA-EXCHVS-2.tele comsys.com> References: <8B0A9FCBB9832F43971E38010638454F03E9DCD1AE@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F03E9DCD24A@SISPE7MB1.commscope.com> <8C837214C95C864C9F34F3635C2A6575135CDD92@SEA-EXCHVS-2.telecomsys.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [sipcore] location-conveyance-03 just 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: Sun, 25 Jul 2010 13:33:16 -0000 At 05:56 PM 7/15/2010, Roger Marshall wrote: >All: >My understanding of what this conveyance-03=20 >draft now allows for is support of location in terms of: > >LbyV if the geolocation header contains a cid=20 >URI which points to a PIDF-LO in the body >Or >LbyR if the geolocation header contains a location URI >Or >Both LbyV & LbyR _only_ if the PIDF-LO that the=20 >cid URI points to also includes an "associated"=20 >Location URI within. This is what I assume is the composite case. you can also have a composed value from two or=20 more entities proposing they know where the Target is. >If this is how it's intended to work, how then=20 >would routing be accomplished if the intention=20 >was to route on location URI, not LbyV? The intermediary would dereference the location=20 URI and receive a PIDF-LO to route the original=20 SIP request upon. The "routing-allowed" parameter=20 would need to be set to "yes" or the intermediary=20 would return a 424 with a Geolocation-Error=20 header value 302 "Permission to Route based on=20 Location Information". The UAC would then choose=20 whether or not to give permission (in a subsequent request). >The geolocation header parameter value of=20 >"routing-allowed" can only be yes or no pointing to the whole PIDF-LO: > >[from -03] > The practical implication is that when the "routing-allowed" > parameter is set to "no", if a cid:url is present in the SIP > request, intermediaries MUST NOT view the location (because it is > not for intermediaries to view), and if a location URI is present, > intermediaries MUST NOT dereference it. UAs are allowed to view > location in the SIP request even when the "routing-allowed" > parameter is set to "no". An LR MUST by default consider the > "routing-allowed" header parameter as set to "no", with no > exceptions, unless the header field value is set to "yes". > >It seems to me that a better way is to allow=20 >geolocation URIs in numbers of 0, 1, or 2, so=20 >that you could elevate the Location URI up to=20 >the geolocation header and avoid all the=20 >difficulties of not knowing what location form=20 >was routable, plus escape the overhead of=20 >embedding it into an otherwise empty PIDF-LO when using LbyR exclusively. if there is no cid-URL (meaning no PIDF-LO), the=20 one locationValue can be a location URI. This=20 also solves what your concerns are above, don't they? James >Regards, > >-roger marshall. > > >-----Original Message----- >From: sipcore-bounces@ietf.org=20 >[mailto:sipcore-bounces@ietf.org] On Behalf Of Thomson, Martin >Sent: Wednesday, July 14, 2010 6:34 PM >To: Peterson, Jon; James M. Polk; sipcore@ietf.org >Subject: Re: [sipcore] location-conveyance-03 just submitted > >Hi Jon, > >There=E2=80=99s a number of issues here. I think that=20 >we need to disentangle them. The role of the=20 >intermediary in this dealing with this problem is a secondary concern. > >There are two primary reasons for having both=20 >value and reference: authorization and dynamism. > >Dynamism is the easiest one to pin down. It's=20 >obviously very important to the emergency=20 >scenario - the ability of a PSAP to acquire=20 >updated location information in a timely fashion=20 >is central to many of their use cases. > >draft-ecrit-rough-loc describes a scenario where=20 >the UAC is less authorized than the UAS;=20 >intermediaries are authorized differently. In=20 >the canonical example, the UAS gets a rubbish=20 >location value and a location reference that=20 >they can't use. The rubbish location is enough=20 >to get them to a PSAP. The PSAP uses the=20 >reference because they are authorized. > >In either case, it's possible to leave the=20 >intermediary out of consideration and=20 >concentrate on the information that the UAC=20 >provides. The great thing with the solution=20 >that you've proposed is that this is ultimately=20 >what happens in any case. Leaving the b2bua=20 >case aside, the UAC is ultimately responsible=20 >for what Geolocation is placed in the request. > >The interactions with the intermediary add=20 >complexity to the scenario, including some=20 >privacy model problems, primarily with=20 >retransmission. I'd like to solve the easier problem first. > >--Martin > > >From: Peterson, Jon [mailto:jon.peterson@neustar.biz] >Sent: Thursday, 15 July 2010 3:09 AM >To: Thomson, Martin; James M. Polk; sipcore@ietf.org >Subject: Re: [sipcore] location-conveyance-03 just submitted > > >[snip] > > We mean to have the intermediary do the > > dereference (if one is needed) and compose in the > > SIP 424 response a MIME body with both the > > server's version or both locations of the Target, > > and for that dual location single presence > > document to be copied into the next SIP request > > from that UAC (towards that same intermediary). > >Elegant as it is, this just doesn't work. =C2 The=20 >UAS (PSAP, LR, etc...) needs to be the entity=20 >that does the dereference. =C2 They need to do=20 >this because they know how (and when) to make=20 >this request so that they get the information=20 >they need. =C2 If the intermediary does the=20 >dereference, then location information is set in stone from that point= onward. > > I see your point, but I think the=20 >difficulty is deeper still than this. The whole=20 >use case for an intermediary providing different=20 >(or supplementary) location information above=20 >and beyond the location provided by the UAC is=20 >based on the intermediary inspecting, and=20 >disliking, the location present in the request.=20 >If that location is constantly changing, what=20 >would it mean for the intermediary to dislike=20 >it? Maybe it likes it one minute and not the=20 >next? Would it =ADever- be safe foor a picky=20 >intermediary to allow a reference to pass it,=20 >given that it couldn=E2=80=99t control what location=20 >the LR would ultimately get from it? Moreover,=20 >what if the creator of the reference authorizes=20 >the end recipient (the PSAP) but not the=20 >intermediary that wants to judge location=20 >information? I think we=E2=80=99d need to look further=20 >into the motivations here to understand the underlying requirement. > >Practically speaking, however, there are a=20 >number of potential work-arounds to enable this=20 >semantic =AD I don=E2=80=99=99t necessarily think that=20 >once the intermediary performs the dereference,=20 >then the location information must be set in=20 >stone. If you seriously want to retain the=20 >dynamism of location information, it could=20 >become the responsibility of the compositor to=20 >deliver a similarly dynamic reference, and every=20 >time someone dereferences the composed object,=20 >the compositor creates a new PIDF-LO document=20 >based on freshly dereferencing any dynamic=20 >components of the location information. Another=20 >possibility would be to specify external=20 >references in PIDF, so we could compose location=20 >information from dynamic sources by reference in=20 >the PIDF object, rather than by value. One=20 >composed object could even have a mix of=20 >by-value and by-reference location information=20 >in that case. The important thing is that we=20 >solve this down in the PIDF level, within the=20 >parameters of RFC4479, rather than trying to=20 >cobble together some relationship between=20 >devices, services and users in the Geolocation header. > >Anyway, none of this is to suggest that this is=20 >adequately specified in the current draft, or=20 >something. We=E2=80=99d need to have a more lengthy=20 >discussion about some of the issues above before=20 >figuring out what we=E2=80=99d add, though. > >Jon Peterson >NeuStar, Inc. >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore > >CONFIDENTIALITY NOTICE: The information=20 >contained in this message may be privileged=20 >and/or confidential. If you are not the intended=20 >recipient, or responsible for delivering this=20 >message to the intended recipient, any review,=20 >forwarding, dissemination, distribution or=20 >copying of this communication or any=20 >attachment(s) is strictly prohibited. If you=20 >have received this message in error, please=20 >notify the sender immediately, and delete it and=20 >all attachments from your computer and network. From jmpolk@cisco.com Sun Jul 25 06:33:16 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 914583A6969 for ; Sun, 25 Jul 2010 06:33:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.213 X-Spam-Level: X-Spam-Status: No, score=-10.213 tagged_above=-999 required=5 tests=[AWL=-0.214, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1jGk1Sa4BNpm for ; Sun, 25 Jul 2010 06:33:15 -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 70F063A6880 for ; Sun, 25 Jul 2010 06:33:15 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208";a="138860663" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2010 13:33:35 +0000 Received: from jmpolk-wxp01.cisco.com (ams3-vpn-dhcp5712.cisco.com [10.61.86.79]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6PDXURv019180; Sun, 25 Jul 2010 13:33:34 GMT Message-Id: <201007251333.o6PDXURv019180@rtp-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 25 Jul 2010 05:47:40 -0500 To: "Winterbottom, James" , Roger Marshall , "Thomson, Martin" , "Peterson, Jon" , "James M. Polk" , "sipcore@ietf.org" From: "James M. Polk" In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880120E7BC053C@SISPE7MB1.com mscope.com> References: <8B0A9FCBB9832F43971E38010638454F03E9DCD1AE@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F03E9DCD24A@SISPE7MB1.commscope.com> <8C837214C95C864C9F34F3635C2A6575135CDD92@SEA-EXCHVS-2.telecomsys.com> <5A55A45AE77F5941B18E5457ECAC81880120E7BC053C@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] location-conveyance-03 just 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: Sun, 25 Jul 2010 13:33:16 -0000 The problem with 2 locationValues is they can both be values or location URIs, which gets us back into the problems of the bloated text and all it had to account for in previous versions. James At 06:39 PM 7/15/2010, Winterbottom, James wrote: >I support Roger's proposal. > > > > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf > > Of Roger Marshall > > Sent: Friday, 16 July 2010 8:56 AM > > To: Thomson, Martin; Peterson, Jon; James M. Polk; sipcore@ietf.org > > Subject: Re: [sipcore] location-conveyance-03 just submitted > > > > All: > > My understanding of what this conveyance-03 draft now allows for is > > support of location in terms of: > > > > LbyV if the geolocation header contains a cid URI which points to a PIDF- > > LO in the body > > Or > > LbyR if the geolocation header contains a location URI > > Or > > Both LbyV & LbyR _only_ if the PIDF-LO that the cid URI points to also > > includes an "associated" Location URI within. This is what I assume is > > the composite case. > > > > If this is how it's intended to work, how then would routing be > > accomplished if the intention was to route on location URI, not LbyV? > > > > The geolocation header parameter value of "routing-allowed" can only be > > yes or no pointing to the whole PIDF-LO: > > > > [from -03] > > The practical implication is that when the "routing-allowed" > > parameter is set to "no", if a cid:url is present in the SIP > > request, intermediaries MUST NOT view the location (because it is > > not for intermediaries to view), and if a location URI is present, > > intermediaries MUST NOT dereference it. UAs are allowed to view > > location in the SIP request even when the "routing-allowed" > > parameter is set to "no". An LR MUST by default consider the > > "routing-allowed" header parameter as set to "no", with no > > exceptions, unless the header field value is set to "yes". > > > > It seems to me that a better way is to allow geolocation URIs in numbers > > of 0, 1, or 2, so that you could elevate the Location URI up to the > > geolocation header and avoid all the difficulties of not knowing what > > location form was routable, plus escape the overhead of embedding it into > > an otherwise empty PIDF-LO when using LbyR exclusively. > > > > Regards, > > > > -roger marshall. > > From jmpolk@cisco.com Sun Jul 25 06:33:17 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 91A433A6972 for ; Sun, 25 Jul 2010 06:33:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.47 X-Spam-Level: X-Spam-Status: No, score=-10.47 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id edi-Kpdip-D5 for ; Sun, 25 Jul 2010 06:33:16 -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 3FB803A695B for ; Sun, 25 Jul 2010 06:33:16 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208";a="138905435" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 Jul 2010 13:33:36 +0000 Received: from jmpolk-wxp01.cisco.com (ams3-vpn-dhcp5712.cisco.com [10.61.86.79]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6PDXURx019180; Sun, 25 Jul 2010 13:33:36 GMT Message-Id: <201007251333.o6PDXURx019180@rtp-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 25 Jul 2010 06:00:18 -0500 To: "James M. Polk" , "Thomson, Martin" , "sipcore@ietf.org" From: "James M. Polk" In-Reply-To: <7.1.0.9.2.20100716015256.075f8220@cisco.com> References: <8B0A9FCBB9832F43971E38010638454F03E9DCD3E4@SISPE7MB1.commscope.com> <7.1.0.9.2.20100716015256.075f8220@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] location conveyance and error "code" parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 25 Jul 2010 13:33:17 -0000 At 02:03 AM 7/16/2010, James M. Polk wrote: >Martin > >in-line > >At 01:22 AM 7/16/2010, Thomson, Martin wrote: >>Two related non-ABNF questions about the "code" parameter in the >>Geolocation-Error header that I thought would be better separated: >> >>1. Why is called "code" if it contains text? The actual code >>(location-error-code) is the 3 digit value. It might be confusing >>talking about the "geolocation error code". Would it be better >>named to "message"? > >I think "message" would be confusing as it would be different than >the SIP response it was carried in (a 424 (Bad Location Information) >or something else). If code is completely appalling to folks, then I >think "value" could be used instead, but not "message". BTW - there are SIP response codes, Reason header cause values and Warning header codes code and cause are used in SIP header values. I'm ok with either James >>2. If I understand correctly, the "code" parameter has a value that >>is fixed based on the 3 digit code. A fixed message doesn't add >>any value [1]. If a human readable message is required, then >>allowing for arbitrary content would be more likely to be useful. >>The existing strings are useful as titles for the codes, but that's all. > >I'm not sure I agree on this one. Most everyone knows what a 404 >"Not Found" means; as a computer (rather than human) is returning >your request because of what the string says. i.e., "Not >Found". This make the meaning more final to humans much of the >time. Anyone who's browsed has received a 404 (with the text too) >and understands it. > >thus, if I understand what you are suggesting (and I may not) - I >think both the 3 digit value and the string should be present as >much as possible. That said, the string is optional, the 3 digit >value, or code, is not - for a GeolocationError at least. > >Please let me know if I've misunderstood your point #2. > >James > > >>--Martin >> >>[1] See discussion in a recent meeting on this subject. >> >> >>_______________________________________________ >>sipcore mailing list >>sipcore@ietf.org >>https://www.ietf.org/mailman/listinfo/sipcore From jmpolk@cisco.com Sun Jul 25 06:33:18 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4CD5C3A6986 for ; Sun, 25 Jul 2010 06:33:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.492 X-Spam-Level: X-Spam-Status: No, score=-10.492 tagged_above=-999 required=5 tests=[AWL=0.107, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9fuJ2wAMyCNQ for ; Sun, 25 Jul 2010 06:33:17 -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 1729E3A6823 for ; Sun, 25 Jul 2010 06:33:16 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208";a="138905436" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 Jul 2010 13:33:37 +0000 Received: from jmpolk-wxp01.cisco.com (ams3-vpn-dhcp5712.cisco.com [10.61.86.79]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6PDXUS1019180; Sun, 25 Jul 2010 13:33:36 GMT Message-Id: <201007251333.o6PDXUS1019180@rtp-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 25 Jul 2010 06:12:20 -0500 To: "Thomson, Martin" , "James M. Polk" , "sipcore@ietf.org" From: "James M. Polk" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03EB772E77@SISPE7MB1.comms cope.com> References: <8B0A9FCBB9832F43971E38010638454F03E9DCD3E4@SISPE7MB1.commscope.com> <201007160703.o6G73CcX006182@sj-core-5.cisco.com> <8B0A9FCBB9832F43971E38010638454F03EB772E77@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] location conveyance and error "code" parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 25 Jul 2010 13:33:18 -0000 At 07:33 PM 7/18/2010, Thomson, Martin wrote: >Hi James, > > > > I think "message" would be confusing as it would be different than > > the SIP response it was carried in (a 424 (Bad Location Information) > > or something else). If code is completely appalling to folks, then I > > think "value" could be used instead, but not "message". > >I don't mind what the parameter is called. "code" is confusing, >that's all. "text" is another alternative to consider. "value" >implies that the content of the parameter is valuable in some >manner, it seems a little disingenuous (see below). > > > >2. If I understand correctly, the "code" parameter has a value that > > >is fixed based on the 3 digit code. A fixed message doesn't add any > > >value [1]. If a human readable message is required, then allowing > > >for arbitrary content would be more likely to be useful. > > >The existing strings are useful as titles for the codes, but that's > > all. > > > > I'm not sure I agree on this one. Most everyone knows what a 404 "Not > > Found" means; as a computer (rather than human) is returning your > > request because of what the string says. i.e., "Not Found". This > > make the meaning more final to humans much of the time. Anyone who's > > browsed has received a 404 (with the text too) and understands it. > >The human value of the string "Not found" is debatable. If you >don't speak English, then it is even less so. After all, a browser >is capable of generating more appropriate message text. > >The code (404) contains all the required information. From this, a >user agent (or server) can generate a message that is better suited >to their audience. For instance: > > "The requested URL was not found on this server." > >Fixed text (Not found) is redundant. Variable text can be useful in >providing diagnostic information. > > > Please let me know if I've misunderstood your point #2. > >If the following is possible, then we have no problem: > > 200 OK > ... > Geolocation-Error: 301;code="Please allow me to redistribute your > location." isn't this exactly what we allow? James > > > > James > > >--Martin From jmpolk@cisco.com Sun Jul 25 06:33:20 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A35D63A6987 for ; Sun, 25 Jul 2010 06:33:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.507 X-Spam-Level: X-Spam-Status: No, score=-10.507 tagged_above=-999 required=5 tests=[AWL=0.092, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ty01yAWjLX+s for ; Sun, 25 Jul 2010 06:33:19 -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 E60583A6823 for ; Sun, 25 Jul 2010 06:33:18 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEACjaS0xAZnwM/2dsb2JhbACfXHGkXplHhTYEhAg X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208";a="138860671" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2010 13:33:39 +0000 Received: from jmpolk-wxp01.cisco.com (ams3-vpn-dhcp5712.cisco.com [10.61.86.79]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6PDXUS5019180; Sun, 25 Jul 2010 13:33:38 GMT Message-Id: <201007251333.o6PDXUS5019180@rtp-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 25 Jul 2010 06:38:16 -0500 To: "Winterbottom, James" , "Richard L. Barnes" , "sipcore@ietf.org" From: "James M. Polk" In-Reply-To: <5A55A45AE77F5941B18E5457ECAC81880120E9829412@SISPE7MB1.com mscope.com> References: <5A55A45AE77F5941B18E5457ECAC81880120E9829412@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] Geo URI in location-conveyance X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 25 Jul 2010 13:33:20 -0000 At 06:05 PM 7/19/2010, Winterbottom, James wrote: >I want this, and I want to be able to support a CID in the same header. >If we can do that in the same header, then I a more than happy to >restrict the number of geolocation headers to 1. this would result in exactly 2 locationValues, which is currently prohibited. James >Cheers >James > > > > -----Original Message----- > > From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf > > Of Richard L. Barnes > > Sent: Tuesday, 20 July 2010 7:47 AM > > To: sipcore@ietf.org > > Subject: [sipcore] Geo URI in location-conveyance > > > > What do people think about having support for GEO URIs [1] in a > > Geolocation header field? Seems like it would be kind of handy... > > > > [1] > > _______________________________________________ > > 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 jmpolk@cisco.com Sun Jul 25 06:33:21 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1D8E33A6823 for ; Sun, 25 Jul 2010 06:33:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.518 X-Spam-Level: X-Spam-Status: No, score=-10.518 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jTCnkm++2f4e for ; Sun, 25 Jul 2010 06:33:19 -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 AD9153A6985 for ; Sun, 25 Jul 2010 06:33:19 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208";a="138905444" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 Jul 2010 13:33:39 +0000 Received: from jmpolk-wxp01.cisco.com (ams3-vpn-dhcp5712.cisco.com [10.61.86.79]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6PDXUS7019180; Sun, 25 Jul 2010 13:33:39 GMT Message-Id: <201007251333.o6PDXUS7019180@rtp-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 25 Jul 2010 07:02:13 -0500 To: "Elwell, John" , "James M. Polk" , "sipcore@ietf.org" From: "James M. Polk" In-Reply-To: References: <201007122355.o6CNt6us024310@sj-core-3.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] location-conveyance-03 just 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: Sun, 25 Jul 2010 13:33:21 -0000 At 06:00 AM 7/20/2010, Elwell, John wrote: >James, > >These are questions for clarification at this stage, rather than comments. > >The ABNF for the Geolocation header field allows multiple >locationValues and multiple routing-params, in any order. The text >below seems to limit it to 0 or 1 locationValue and 0 or 1 >routing-param, and furthermore it limits it so that the >routing-param must be last. It seems this could be expressed much >more precisely, and still quite easily, in the ABNF. Of have I >misunderstood something? good catch! At this time (in -03) there is only one Geolocation header, so there is no need to look further for a "no". >Although the text "The Geolocation header field has zero or one >locationValue, but > MUST NOT contain more than one locationValue." >limits the header field to having a maximum of one locationValue, >text further down "another > instance of the Geolocation header" >suggests that there can be multiple instances of the header field >and hence multiple locationValues. this is the same catch as above - and there is only one locationValue currently. >So a request can contain multiple locationValues, but not in the >same header field instance. Is this really what is intended? > >Unrelated to the above, concerning the text: >"Other URI schemas used in the location URI MUST be reviewed against > the RFC 3693 [RFC3693] criteria for a Using Protocol" >Who must review? The protocol implementer? How is this testable? The Geopriv "Using Protocol" is from the original requirements doc from SIPPING, which is now the appendix here. It comes from RFC 3693, which Geopriv is going to revise eventually with their Geopriv Arch ID, that removes the use of this term. Geopriv Arch is only an update to 3693, and not a replacement, meaning 3693 will remain actively appropriate, so I'm kinda caught with which to align with. James >John > > > -----Original Message----- > > From: sipcore-bounces@ietf.org > > [mailto:sipcore-bounces@ietf.org] On Behalf Of James M. Polk > > Sent: 13 July 2010 00:55 > > To: sipcore@ietf.org > > Subject: [sipcore] location-conveyance-03 just submitted > > > > SIPCORE > > > > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-locatio > > n-conveyance-03.txt > > > > This version is a fairly radical departure from previous versions of > > the (long standing) effort. This time the doc didn't grow... > > > > We added Jon Peterson as a co-author, and he helped in Anaheim > > propose a significantly less complex way of specifying location > > conveyance for SIP. More than 95% of the doc has been rewritten by > > Jon and I, with a net result of 27 less pages of text (52 to 25 now). > > > > We took out the terms and concepts of following parameters: > > > > - inserter > > - inserted-by > > - used-for-routing > > - host-id > > - node-id > > > > as well as limiting the number of locationValues to *ONE*, in > > a SIP request. > > > > We removed the ability for SIP intermediaries to add location along > > the way unbeknownst to the UAC (with one infrequently used > > exception). In this way, location errors are only end-to-end, so > > there is no need to identify which entity added location to make sure > > the right entity reacted the right way when an error was caused by > > the location they inserted, and not that of another entity's inserted > > location (which is all very confusing). > > > > We added the ability for a SIP intermediary to augment a location > > with what the UAC should send in a subsequent request, and the > > ability to verify this augmentation is present before successfully > > processing that request. This is in line with both RFCs 4479 and 5491. > > > > Comments are appreciated > > > > James > > > > _______________________________________________ > > 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 jmpolk@cisco.com Sun Jul 25 06:33:22 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DC2C33A6998 for ; Sun, 25 Jul 2010 06:33:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.527 X-Spam-Level: X-Spam-Status: No, score=-10.527 tagged_above=-999 required=5 tests=[AWL=0.072, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Psz8mBZAFWgj for ; Sun, 25 Jul 2010 06:33:21 -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 EB7293A6988 for ; Sun, 25 Jul 2010 06:33:20 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208";a="138860677" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 25 Jul 2010 13:33:41 +0000 Received: from jmpolk-wxp01.cisco.com (ams3-vpn-dhcp5712.cisco.com [10.61.86.79]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6PDXUS9019180; Sun, 25 Jul 2010 13:33:40 GMT Message-Id: <201007251333.o6PDXUS9019180@rtp-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 25 Jul 2010 07:04:54 -0500 To: "Thomson, Martin" , Paul Kyzivat From: "James M. Polk" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03EB773153@SISPE7MB1.comms cope.com> References: <8B0A9FCBB9832F43971E38010638454F03EB772EBB@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F03EB7730BA@SISPE7MB1.commscope.com> <4C459BD7.9050007@cisco.com> <8B0A9FCBB9832F43971E38010638454F03EB773153@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1"; format=flowed Content-Transfer-Encoding: quoted-printable Cc: Roger Marshall , "sipcore@ietf.org" Subject: Re: [sipcore] composition or just indirection X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 25 Jul 2010 13:33:23 -0000 At 06:50 PM 7/20/2010, Thomson, Martin wrote: > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]: > > Thomson, Martin wrote: > > > The Geolocation header identifies a PIDF document by value or > > > reference. A Geolocation header indicates that a) this particular > > > PIDF > > > document contains location information and b) that this location > > > information in particular may be relevant to the processing of the > > > SIP request. > > > > IMO this is *too* vague. > > > > For instance, I might want request that a call be routed *to* the phone > > closest to some geolocation. That location is also relevant to the > > processing of the request, but in an entirely different way. > >Damn. You would have to point out my big blind=20 >spot. I've been concentrating on the=20 >routing-based-on-caller-location use case too long. > >If we also consider that the location needs to=20 >be attributed to a particular entity, you can=20 >either add syntax that attempts to identify the=20 >entity that you are talking about (a "from" or=20 >"to" parameter might do this), or you can make=20 >the entity constant. In the interest of=20 >simplicity, the latter seems more fashionable: > >" >The Geolocation header identifies a source of=20 >location information. This might be a PIDF-LO=20 >document that is identified by value or=20 >reference, or a geo: URI that includes location information directly. > >A Geolocation header indicates that a) that this=20 >location information is somehow applicable to=20 >the entity that initiated the request and b)=20 >that this location information might be relevant=20 >to the processing of the SIP request. >" I'm reading this believing someone here believes=20 part of -03 needs to replace text with the above,=20 but I'm not sure which text needs replacing from=20 this discussion. Can someone point to the paragraph in question? James >This is almost the "bold" interpretation that=20 >says that this Target=E2=80=99s location should be=20 >considered the source of the request. It does=20 >not imply that the Target and source are the=20 >same identity. Nor does it expressly state that=20 >the source is actually located anywhere in=20 >particular, though we're walking a fairly fine line there. > >--Martin From jmpolk@cisco.com Sun Jul 25 06:33:24 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EC3B23A698B for ; Sun, 25 Jul 2010 06:33:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.535 X-Spam-Level: X-Spam-Status: No, score=-10.535 tagged_above=-999 required=5 tests=[AWL=0.064, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tftMxsQC0Uga for ; Sun, 25 Jul 2010 06:33:22 -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 0DA7E3A6987 for ; Sun, 25 Jul 2010 06:33:21 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,257,1278288000"; d="scan'208";a="138905450" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-2.cisco.com with ESMTP; 25 Jul 2010 13:33:42 +0000 Received: from jmpolk-wxp01.cisco.com (ams3-vpn-dhcp5712.cisco.com [10.61.86.79]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6PDXUSB019180; Sun, 25 Jul 2010 13:33:41 GMT Message-Id: <201007251333.o6PDXUSB019180@rtp-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Sun, 25 Jul 2010 07:18:17 -0500 To: Paul Kyzivat , "DOLLY, MARTIN C (ATTLABS)" From: "James M. Polk" In-Reply-To: <4C48F332.9080500@cisco.com> References: <14C85D6CCBE92743AF33663BF5D24EBA02BD513A@gaalpa1msgusr7e.ugd.att.com> <4C48F332.9080500@cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: James.Winterbottom@andrew.com, sipcore@ietf.org, Martin.Thomson@andrew.com Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-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: Sun, 25 Jul 2010 13:33:24 -0000 I agree Paul -- adding text is a good idea to cover this scenario James At 08:41 PM 7/22/2010, Paul Kyzivat wrote: >SIP *does* have a compatibility mechanism. If the 424 *does* get >back to an unaware UAC, then it will be treated equivalently to a 400. > >The problem arises if that is an insufficient way of dealing. >The design of the 424 response is based on the assumption that the >recipient will understand it and make a suitable retry. An unaware >UAC won't do that. > >The words Martin offered seem sufficient to me. If the responsible >proxy is satisfied with the consequences of allowing the UAC to get >the 424, then that too is ok. > >It could be left unstated, on the assumption that it will be evident >to an informed developer. But in my experience much of the stuff >that seems evident to us turns out *not* to be evident to many developers. > > Thanks, > Paul > >DOLLY, MARTIN C (ATTLABS) wrote: >>A good protocol would have a compatibility mechanism...mmm >>Martin C. Dolly >>Sent to you by AT&T... America's Fastest Mobile Broadband Network. >>Rethink Possible. >>+1.609.903.3360 >>----- Original Message ----- >>From: sipcore-bounces@ietf.org >>To: Thomson, Martin ; Paul Kyzivat >>; James M. Polk >>Cc: SIPCORE >>Sent: Thu Jul 22 20:43:59 2010 >>Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-03 >>This may be ignorance on my part, but I am going to assume that >>this is not the first new header added to the SIP since RFC3261, >>and so it is also not the first case where an error might come back >>from about a header that has been inserted along the way. >>What happens in these other cases? >>Cheers >>James >> >> >> >>>-----Original Message----- >>>From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf >>>Of Thomson, Martin >>>Sent: Friday, 23 July 2010 10:14 AM >>>To: Paul Kyzivat; James M. Polk >>>Cc: SIPCORE >>>Subject: Re: [sipcore] draft-ietf-sipcore-location-conveyance-03 >>> >>>>>>ISTM there needs to be a requirement that the intermediary inserting >>>>>>the Geolocation header handle any 424 errors that might result from >>>>>>it, thus shielding the UAC from those. >>>>>Do you think we can state this? I'm thinking from a purest protocol >>>>>pov, that seems to me to break SIP's e2e model of communication, >>>>>especially when involving a literal proxy - and not some other form >>>>of >>>>>SIP intermediary (e.g., b2bua or sbc that are made to do just this). >>>No harm in making a statement about this. Of course, this sort of >>>behaviour could simply be implied. If the intermediary is acting as a >>>B2BUA, when it adds a feature, it can (and should) absorb the consequences >>>of that. For geolocation, if it adds the header, it must be prepared for >>>the consequences of that (424). >>> >>>I'll leave it to the discretion of the editors how much they want to dance >>>around the sensitivities. But you could just say: >>> >>>An intermediary that adds a geolocation header MUST be prepared to handle >>>any errors that this might result in, including a 424 response. The >>>intermediary might then translate this error into an error that the UAC is >>>known to support, or... >>>_______________________________________________ >>>sipcore mailing list >>>sipcore@ietf.org >>>https://www.ietf.org/mailman/listinfo/sipcore >>_______________________________________________ >>sipcore mailing list >>sipcore@ietf.org >>https://www.ietf.org/mailman/listinfo/sipcore From john.elwell@siemens-enterprise.com Sun Jul 25 07:07:33 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 71DD03A6839 for ; Sun, 25 Jul 2010 07:07:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.989 X-Spam-Level: X-Spam-Status: No, score=-2.989 tagged_above=-999 required=5 tests=[AWL=-0.390, 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 QEnzoNTigJ+Y for ; Sun, 25 Jul 2010 07:07:31 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id 721F73A68A0 for ; Sun, 25 Jul 2010 07:07:31 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-958899; Sun, 25 Jul 2010 16:07:33 +0200 Received: from MCHP063A.global-ad.net (unknown [172.29.37.61]) by senmx11-mx (Server) with ESMTP id 140EC1EB82AB; Sun, 25 Jul 2010 16:07:33 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP063A.global-ad.net ([172.29.37.61]) with mapi; Sun, 25 Jul 2010 16:07:33 +0200 From: "Elwell, John" To: "James M. Polk" , "sipcore@ietf.org" Date: Sun, 25 Jul 2010 16:07:31 +0200 Thread-Topic: [sipcore] location-conveyance-03 just submitted Thread-Index: Acsr/f9RTgQzRiAcRbGxayR79+qGBwABDTpw Message-ID: References: <201007122355.o6CNt6us024310@sj-core-3.cisco.com> <201007251333.o6PDXUS7019180@rtp-core-1.cisco.com> In-Reply-To: <201007251333.o6PDXUS7019180@rtp-core-1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [sipcore] location-conveyance-03 just 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: Sun, 25 Jul 2010 14:07:33 -0000 > >Unrelated to the above, concerning the text: > >"Other URI schemas used in the location URI MUST be reviewed against > > the RFC 3693 [RFC3693] criteria for a Using Protocol" > >Who must review? The protocol implementer? How is this testable? >=20 > The Geopriv "Using Protocol" is from the original requirements doc=20 > from SIPPING, which is now the appendix here. It comes from RFC 3693,=20 > which Geopriv is going to revise eventually with their Geopriv Arch=20 > ID, that removes the use of this term. Geopriv Arch is only an=20 > update to 3693, and not a replacement, meaning 3693 will remain=20 > actively appropriate, so I'm kinda caught with which to align with. [JRE] Notwithstanding the question of whether we make use of the term "Usin= g Protocol" or some other term, this doesn't address my concern. The presen= t text uses the passive voice, and therefore doesn't make it clear who must= review. John From Martin.Thomson@andrew.com Sun Jul 25 07:11:29 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id EA2433A696E for ; Sun, 25 Jul 2010 07:11:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.47 X-Spam-Level: X-Spam-Status: No, score=-3.47 tagged_above=-999 required=5 tests=[AWL=-0.871, 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 eR3dbjx-jluN for ; Sun, 25 Jul 2010 07:11:21 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 9B6223A67ED for ; Sun, 25 Jul 2010 07:11:21 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:31101 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S103279Ab0GYOLk (ORCPT ); Sun, 25 Jul 2010 09:11:40 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Sun, 25 Jul 2010 09:11:40 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Sun, 25 Jul 2010 22:11:36 +0800 From: "Thomson, Martin" To: "James M. Polk" , "Winterbottom, James" , Roger Marshall , "Peterson, Jon" , "sipcore@ietf.org" Date: Sun, 25 Jul 2010 22:13:44 +0800 Thread-Topic: [sipcore] location-conveyance-03 just submitted Thread-Index: Acsr/fx8sQEx+7H1QCW5wVRZ6+MxbwABT2IQ Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB773509@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03E9DCD1AE@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F03E9DCD24A@SISPE7MB1.commscope.com> <8C837214C95C864C9F34F3635C2A6575135CDD92@SEA-EXCHVS-2.telecomsys.com> <5A55A45AE77F5941B18E5457ECAC81880120E7BC053C@SISPE7MB1.commscope.com> <201007251333.o6PDXURv019180@rtp-core-1.cisco.com> In-Reply-To: <201007251333.o6PDXURv019180@rtp-core-1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] location-conveyance-03 just 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: Sun, 25 Jul 2010 14:11:29 -0000 PiBUaGUgcHJvYmxlbSB3aXRoIDIgbG9jYXRpb25WYWx1ZXMgaXMgdGhleSBjYW4gYm90aCBiZSB2 YWx1ZXMgb3INCj4gbG9jYXRpb24gVVJJcywgd2hpY2ggZ2V0cyB1cyBiYWNrIGludG8gdGhlIHBy b2JsZW1zIG9mIHRoZSBibG9hdGVkDQo+IHRleHQgYW5kIGFsbCBpdCBoYWQgdG8gYWNjb3VudCBm b3IgaW4gcHJldmlvdXMgdmVyc2lvbnMuDQo+IA0KPiBKYW1lcw0KDQpTYXlpbmcgImRvbid0IGRv IHRoYXQiIHdvcmtzLiAgSXQncyBhYm91dCBhcyBlZmZlY3RpdmUgYXMgYW55IG9mIHRoZSBvdGhl ciBzcGVjaWZpY2F0aW9uLXR5cGUgdG9vbHMgd2UgaGF2ZS4NCg0K From Martin.Thomson@andrew.com Sun Jul 25 07:15:35 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5ABDB3A694E for ; Sun, 25 Jul 2010 07:15:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.454 X-Spam-Level: X-Spam-Status: No, score=-3.454 tagged_above=-999 required=5 tests=[AWL=-0.855, 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 kgYVIgMrg0PV for ; Sun, 25 Jul 2010 07:15:33 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 1CAF93A68A0 for ; Sun, 25 Jul 2010 07:15:33 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:50790 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S336571Ab0GYOPx (ORCPT ); Sun, 25 Jul 2010 09:15:53 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Sun, 25 Jul 2010 09:15:53 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Sun, 25 Jul 2010 22:15:50 +0800 From: "Thomson, Martin" To: "James M. Polk" , "Peterson, Jon" , "sipcore@ietf.org" Date: Sun, 25 Jul 2010 22:18:01 +0800 Thread-Topic: [sipcore] location-conveyance-03 just submitted Thread-Index: Acsr/fvTuzQQGZrERcyHtbpGyEFTUwABLyxg Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB77350A@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03E9DCD1AE@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F03E9DCD24A@SISPE7MB1.commscope.com> <201007251333.o6PDXURr019180@rtp-core-1.cisco.com> In-Reply-To: <201007251333.o6PDXURr019180@rtp-core-1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] location-conveyance-03 just 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: Sun, 25 Jul 2010 14:15:35 -0000 SSBmZWVsIGxpa2Ugc29tZSBvZiB0aGlzIGlzIG9sZCBncm91bmQsIGJ1dCBJIGNoYWxrIHRoYXQg dXAgdG8geW91IGRvaW5nIGFsbCB0aGVzZSByZXBsaWVzIHdoaWxlIHlvdSB3ZXJlIG9mZmxpbmUu DQoNCiAoSSdsbCBub3RlIHRoYXQgc29tZSBvZiB5b3VyIHJlY2VudCByZXNwb25zZXMgYXJlIGlu IHJlc3BvbnNlIHRvIGVtYWlscyB0aGF0IHlvdSBoYXZlIGFscmVhZHkgcmVzcG9uZGVkIHRvLikN Cg0KPiA+RHluYW1pc20gaXMgdGhlIGVhc2llc3Qgb25lIHRvIHBpbiBkb3duLiAgSXQncw0KPiA+ b2J2aW91c2x5IHZlcnkgaW1wb3J0YW50IHRvIHRoZSBlbWVyZ2VuY3kNCj4gPnNjZW5hcmlvIC0g dGhlIGFiaWxpdHkgb2YgYSBQU0FQIHRvIGFjcXVpcmUNCj4gPnVwZGF0ZWQgbG9jYXRpb24gaW5m b3JtYXRpb24gaW4gYSB0aW1lbHkgZmFzaGlvbg0KPiA+aXMgY2VudHJhbCB0byBtYW55IG9mIHRo ZWlyIHVzZSBjYXNlcy4NCj4gDQo+IE1hcnRpbiAtIGhvdyBsb25nIGFyZSB5b3UgZXhwZWN0aW5n IHRoaXMgaW5pdGlhbA0KPiBJTlZJVEUgdG8gZ28gZnJvbSB0aGUgVUFDIHRvIHRoZSBQU0FQPw0K Pg0KPiBZb3UncmUgZ2l2aW5nIHRoZSBpbXByZXNzaW9uIHRoYXQgYSBzZWNvbmQgb3IgdHdvDQo+ IG1hdHRlcnMgb3IgdGhlIFVBQyB3aWxsIGJlIGluIGEgY29tcGxldGVseQ0KPiBkaWZmZXJlbnQg bG9jYXRpb24sIG1lYW5pbmcgdGhlIHdyb25nIFBTQVAgd2lsbCBiZSBjb250YWN0ZWQuDQoNCkl0 J3Mgbm90IHRoZSB0cmFuc2l0IHRpbWUgdGhhdCBpcyB0aGUgcHJvYmxlbSwgaXTigJlzIHRoZSB1 c2VzIG9mIGxvY2F0aW9uIGFmdGVyIHRoYXQuICBUaGUgY2FsbCBjYW4gY2VydGFpbmx5IGxhc3Qg bG9uZ2VyIHRoYW4gYSBmZXcgc2Vjb25kcy4NCg0KPiA+SW4gZWl0aGVyIGNhc2UsIGl0J3MgcG9z c2libGUgdG8gbGVhdmUgdGhlDQo+ID5pbnRlcm1lZGlhcnkgb3V0IG9mIGNvbnNpZGVyYXRpb24g YW5kDQo+ID5jb25jZW50cmF0ZSBvbiB0aGUgaW5mb3JtYXRpb24gdGhhdCB0aGUgVUFDIHByb3Zp ZGVzLg0KPiANCj4gYnV0IHdoYXQgYWJvdXQgZW52aXJvbm1lbnRzIChvciBuZXR3b3JrcykgdGhh dA0KPiBkb24ndCB0cnVzdCB0aGUgVUUgKG9yIFVBQykgYXQgYWxsLiBJJ2QgYXJndWUNCj4gdGhh dCdzIG11Y2ggbW9yZSBwcm9iYWJsZSAtLSBiZWNhdXNlIHRoYXQncyBob3cgM0dQUCB0cmVhdHMg dGhlaXINCj4gcGhvbmVzLg0KDQpUaGVuIHRoZXkgaGF2ZSBzb21lIHJlY29uc2lkZXJpbmcgdG8g ZG8gaW4gaG93IHRoZXkgZGVwbG95IHRoaXMgc3BlYy4gIFRoZXJlIGFyZSBtZXRob2RzIGZvciBk ZWFsaW5nIHdpdGggdGhpcyB0aGF0IG1pZ2h0IGJlIG1vcmUgcHJhY3RpY2FsIGluIHRob3NlIGVu dmlyb25tZW50cywgYnV0IGxlc3Mgc28gb24gdGhlIHdpZGVyIEludGVybmV0LiAgRGlnaXRhbCBz aWduYXR1cmVzLCBmb3IgZXhhbXBsZS4NCg0KLi4uIA0KPiA+VGhlIGludGVyYWN0aW9ucyB3aXRo IHRoZSBpbnRlcm1lZGlhcnkgYWRkDQo+ID5jb21wbGV4aXR5IHRvIHRoZSBzY2VuYXJpbywgaW5j bHVkaW5nIHNvbWUNCj4gPnByaXZhY3kgbW9kZWwgcHJvYmxlbXMsIHByaW1hcmlseSB3aXRoIHJl dHJhbnNtaXNzaW9uLg0KPiANCj4gbWVhbmluZyBVRFAgdnMgVENQPw0KIA0KTWVhbmluZyA8cmV0 cmFuc21pc3Npb24tYWxsb3dlZD4uICBJIHdvdWxkIGhvcGUgdGhhdCBwZW9wbGUga25vdyBob3cg dG8gdXNlIFVEUCBhbmQgVENQIGJ5IG5vdy4NCg0K From Martin.Thomson@andrew.com Sun Jul 25 07:17:54 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0578D3A695A for ; Sun, 25 Jul 2010 07:17:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.439 X-Spam-Level: X-Spam-Status: No, score=-3.439 tagged_above=-999 required=5 tests=[AWL=-0.840, 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 uZS9kUnhaGeG for ; Sun, 25 Jul 2010 07:17:52 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id 811993A68A0 for ; Sun, 25 Jul 2010 07:17:52 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:52838 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S337267Ab0GYOSM (ORCPT ); Sun, 25 Jul 2010 09:18:12 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Sun, 25 Jul 2010 09:18:12 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Sun, 25 Jul 2010 22:18:08 +0800 From: "Thomson, Martin" To: "James M. Polk" , "sipcore@ietf.org" Date: Sun, 25 Jul 2010 22:20:19 +0800 Thread-Topic: [sipcore] location conveyance and error "code" parameter Thread-Index: Acsr/f0pG0KOZFwFSGy9oRhMp2oQvwABj4cg Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB77350B@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03E9DCD3E4@SISPE7MB1.commscope.com> <201007160703.o6G73CcX006182@sj-core-5.cisco.com> <8B0A9FCBB9832F43971E38010638454F03EB772E77@SISPE7MB1.commscope.com> <201007251333.o6PDXUS1019180@rtp-core-1.cisco.com> In-Reply-To: <201007251333.o6PDXUS1019180@rtp-core-1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] location conveyance and error "code" parameter X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 25 Jul 2010 14:17:54 -0000 PiA+ICAgMjAwIE9LDQo+ID4gICAuLi4NCj4gPiAgIEdlb2xvY2F0aW9uLUVycm9yOiAzMDE7Y29k ZT0iUGxlYXNlIGFsbG93IG1lIHRvIHJlZGlzdHJpYnV0ZSB5b3VyDQo+ID4gbG9jYXRpb24uIg0K PiANCj4gaXNuJ3QgdGhpcyBleGFjdGx5IHdoYXQgd2UgYWxsb3c/DQoNCiBJIGRvbid0IGtub3cu ICBUaGUgdGV4dCBzb3J0LW9mIGltcGxpZXMgdGhhdCB0aGUgdGV4dCB0aGF0IHlvdSBoYXZlIHBy b3ZpZGVkIChpbiB0aGlzIGNhc2UgIiBQZXJtaXNzaW9uIFRvIFJldHJhbnNtaXQgTG9jYXRpb24g SW5mb3JtYXRpb24gdG8gYSBUaGlyZCBQYXJ0eSIpIGlzIHRoZSBvbmx5IHBlcm1pc3NpYmxlIHRl eHQuDQoNCklmIHRoYXQncyBhIG1pc3VuZGVyc3RhbmRpbmcgb24gbXkgcGFydCwgdGhlbiB3ZSdy ZSBjb29sLiAgSSdsbCBiZSBoYXBweSB0byBwcm92aWRlIGNsYXJpZnlpbmcgdGV4dCBzbyB0aGF0 IG90aGVycyBkb24ndCBjb21lIHRvIHRoZSBzYW1lICh3cm9uZykgY29uY2x1c2lvbnMuDQoNCi0t TWFydGluDQoNCg== From Martin.Thomson@andrew.com Sun Jul 25 07:38:57 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 721603A6864 for ; Sun, 25 Jul 2010 07:38:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.424 X-Spam-Level: X-Spam-Status: No, score=-3.424 tagged_above=-999 required=5 tests=[AWL=-0.825, 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 b+jolSpAD7wV for ; Sun, 25 Jul 2010 07:38:56 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 867803A6857 for ; Sun, 25 Jul 2010 07:38:56 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:46777 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S28620539Ab0GYOjP (ORCPT ); Sun, 25 Jul 2010 09:39:15 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Sun, 25 Jul 2010 09:38:15 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Sun, 25 Jul 2010 22:38:13 +0800 From: "Thomson, Martin" To: "James M. Polk" , Paul Kyzivat Date: Sun, 25 Jul 2010 22:40:24 +0800 Thread-Topic: [sipcore] composition or just indirection Thread-Index: Acsr/f+IF10+DI+ZSEm+KNE7/3XQhAABbmxA Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB77350C@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03EB772EBB@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F03EB7730BA@SISPE7MB1.commscope.com> <4C459BD7.9050007@cisco.com> <8B0A9FCBB9832F43971E38010638454F03EB773153@SISPE7MB1.commscope.com> <201007251333.o6PDXUS9019180@rtp-core-1.cisco.com> In-Reply-To: <201007251333.o6PDXUS9019180@rtp-core-1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: Roger Marshall , "sipcore@ietf.org" Subject: Re: [sipcore] composition or just indirection X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 25 Jul 2010 14:38:57 -0000 DQo+ID4iDQo+ID5UaGUgR2VvbG9jYXRpb24gaGVhZGVyIGlkZW50aWZpZXMgYSBzb3VyY2Ugb2YN Cj4gPmxvY2F0aW9uIGluZm9ybWF0aW9uLiAgVGhpcyBtaWdodCBiZSBhIFBJREYtTE8NCj4gPmRv Y3VtZW50IHRoYXQgaXMgaWRlbnRpZmllZCBieSB2YWx1ZSBvcg0KPiA+cmVmZXJlbmNlLCBvciBh IGdlbzogVVJJIHRoYXQgaW5jbHVkZXMgbG9jYXRpb24gaW5mb3JtYXRpb24gZGlyZWN0bHkuDQo+ ID4NCj4gPkEgR2VvbG9jYXRpb24gaGVhZGVyIGluZGljYXRlcyB0aGF0IGEpIHRoYXQgdGhpcw0K PiA+bG9jYXRpb24gaW5mb3JtYXRpb24gaXMgc29tZWhvdyBhcHBsaWNhYmxlIHRvDQo+ID50aGUg ZW50aXR5IHRoYXQgaW5pdGlhdGVkIHRoZSByZXF1ZXN0IGFuZCBiKQ0KPiA+dGhhdCB0aGlzIGxv Y2F0aW9uIGluZm9ybWF0aW9uIG1pZ2h0IGJlIHJlbGV2YW50DQo+ID50byB0aGUgcHJvY2Vzc2lu ZyBvZiB0aGUgU0lQIHJlcXVlc3QuDQo+ID4iDQo+IA0KPiBJJ20gcmVhZGluZyB0aGlzIGJlbGll dmluZyBzb21lb25lIGhlcmUgYmVsaWV2ZXMNCj4gcGFydCBvZiAtMDMgbmVlZHMgdG8gcmVwbGFj ZSB0ZXh0IHdpdGggdGhlIGFib3ZlLA0KPiBidXQgSSdtIG5vdCBzdXJlIHdoaWNoIHRleHQgbmVl ZHMgcmVwbGFjaW5nIGZyb20NCj4gdGhpcyBkaXNjdXNzaW9uLiBDYW4gc29tZW9uZSBwb2ludCB0 byB0aGUgcGFyYWdyYXBoIGluIHF1ZXN0aW9uPw0KDQpMZXQncyBkaXNjdXNzIHRoaXMgdG9tb3Jy b3cuICBIb3dldmVyLCBJIHRoaW5rIHRoYXQgdGhpcyBtaWdodCBiZSBhZGRlZCB0byB0aGUgdmVy eSBzdGFydCBvZiBTZWN0aW9uIDQsIHdoaWNoIGN1cnJlbnRseSBoYXMgYWxtb3N0IG5vIHRleHQu DQo= From shida@ntt-at.com Sun Jul 25 07:39:40 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 751EA3A68C6 for ; Sun, 25 Jul 2010 07:39:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[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 coUBcASCq22h for ; Sun, 25 Jul 2010 07:39:39 -0700 (PDT) Received: from gateway03.websitewelcome.com (gateway03.websitewelcome.com [74.52.223.66]) by core3.amsl.com (Postfix) with SMTP id ED89D3A6857 for ; Sun, 25 Jul 2010 07:39:38 -0700 (PDT) Received: (qmail 15968 invoked from network); 25 Jul 2010 14:46:46 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway03.websitewelcome.com with SMTP; 25 Jul 2010 14:46:46 -0000 Received: from a83-161-201-77.adsl.xs4all.nl ([83.161.201.77]:54440 helo=[10.0.0.27]) by gator465.hostgator.com with esmtpa (Exim 4.69) (envelope-from ) id 1Od2Ms-0007Et-IS; Sun, 25 Jul 2010 09:39:54 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=us-ascii From: Shida Schubert In-Reply-To: <4C475579.8010709@cisco.com> Date: Sun, 25 Jul 2010 16:39:51 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <5D37AEC3-3F8F-4D83-92E4-85B8E307E734@ntt-at.com> References: <4C475579.8010709@cisco.com> To: Paul Kyzivat X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: SIPCORE Subject: Re: [sipcore] draft-barnes-sipcore-rfc4244bis-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: Sun, 25 Jul 2010 14:39:40 -0000 Paul; Thanks for your review, comments inline.. On Jul 21, 2010, at 10:15 PM, Paul Kyzivat wrote: > Mary, >=20 > (Doing my pre-meeting reading. I haven't looked at this for a *long* = time.) >=20 > I have a question about handling the addition of H-I to responses as = described in 5.2 and especially in 6.3.3 bullet 6, for parallel forked = requests: >=20 > Often in a parallel forking case a final response will be forwarded = without yet having seen responses from all the other active branches. > If so, of necessity there is only going to be partial info, or = inaccurate info. >=20 > Figure 1 shows some consolidation, but it leaves out a bunch of detail = a about how it is done. It notes that the path not taken is canceled and = an HI entry with a 487 reason. But it won't necessarily wait for the 487 = response, and may not get it. >=20 I think the draft used to have example showing that proxy=20 would include all the responses from paralleled fork=20 brunches in H-I before it forwarded the request further.=20 I think it was changed into the way it is because when=20 a proxy forwards a request based on a response from a=20 single brunch, it is that response that triggered the request,=20 not the consolidated response, so having the partial information=20 is actually what you want.=20 > There is also a possibility that more than one 200 response will be = received, and again its unclear what is to be done in that case. This = case can be aggravated if the request contained = Request-Disposition:nocancel and the proxy honored that. Are you talking about what is to be included in the 200 responses? If so each of the 200 response will likely to have different set of=20 hi-entries with some being the same (up to where the request forked).=20 >=20 > Also, I see no real addressing of non-INVITE transactions. Of = particular note is SUBSCRIBE, for which multiple forks can be quite = important. For it, there will not be multiple 200 responses, but there = may still be NOTIFYs for multiple branches, each creating a dialog. I don't see the relevance of NOTIFY in relation to SUBSCRIBE when it=20 comes to H-I.=20 >=20 > Section 6.1 (cosmetic): >=20 > instead of: >=20 > hi-index =3D "index" EQUAL 1*DIGIT *("." 1*DIGIT) > mp-param =3D "mp" EQUAL 1*DIGIT *("." 1*DIGIT) >=20 > how about: >=20 > hi-index-value =3D 1*DIGIT *("." 1*DIGIT) > hi-index =3D "index" EQUAL hi-index-value > mp-param =3D "mp" EQUAL hi-index-value >=20 > Thanks, > Paul > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From shida@ntt-at.com Sun Jul 25 08:23:43 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B829E3A6857 for ; Sun, 25 Jul 2010 08:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.225 X-Spam-Level: X-Spam-Status: No, score=-1.225 tagged_above=-999 required=5 tests=[AWL=1.040, 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 0wN167-d97ch for ; Sun, 25 Jul 2010 08:23:42 -0700 (PDT) Received: from gateway06.websitewelcome.com (gateway06.websitewelcome.com [67.18.15.14]) by core3.amsl.com (Postfix) with SMTP id DA7933A681E for ; Sun, 25 Jul 2010 08:23:41 -0700 (PDT) Received: (qmail 18481 invoked from network); 25 Jul 2010 15:33:41 -0000 Received: from gator465.hostgator.com (69.56.174.130) by gateway06.websitewelcome.com with SMTP; 25 Jul 2010 15:33:41 -0000 Received: from a83-161-201-77.adsl.xs4all.nl ([83.161.201.77]:54591 helo=[10.0.0.27]) by gator465.hostgator.com with esmtpa (Exim 4.69) (envelope-from ) id 1Od33U-000582-Hn; Sun, 25 Jul 2010 10:23:57 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=iso-8859-1 From: Shida Schubert In-Reply-To: Date: Sun, 25 Jul 2010 17:22:08 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <91BE6A3F-5582-45CA-8668-4D00B9F9CB42@ntt-at.com> References: To: X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - gator465.hostgator.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - ntt-at.com Cc: sipcore@ietf.org Subject: Re: [sipcore] Updated 4244bis and new call flow document X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 25 Jul 2010 15:23:44 -0000 Hi Marianne; Thanks for the review, comments inline.. On Jul 25, 2010, at 3:09 AM, = wrote: > Hi Mary and all, >=20 > I have some comments on draft-ietf-sipcore-rfc4244bis-01: >=20 > 1- Regarding the "hit" and "target" parameters, is it really necessary = to create both?=20 > I mean the "hit" parameter seems almost useless as it has to be = removed from the R-URI just=20 > after its creation (kept only in the Contact header after a 3xx). > Why the hi-target couldn't be a single parameter to tag URIs? I can't clearly recall why we added this "hit" parameter but=20 we had some problems delivering the "to-be hi-entry" that=20 caused the 3xx. We talked about escaping the history-info header=20 in the contact header in 3xx so entity receiving the 3xx can construct=20= the hi-entry but decided to go with using the "hit" parameter.=20 >=20 > 2- =A74.1 it is said that=20 > "The entries SHOULD be evaluated to determine gaps in indices,=20 > which could indicate that an entry has been maliciously removed. =20 > Either way, an application SHOULD be aware of potentially missing = information."=20 > If the removed hi-entry is the last destination (leaf) of an = unsuccessful route (branch),=20 > how is it possible, at the end, to know that there is a missing entry? It's true that if a leaf at an unsuccessful forked branch isn't=20 captured there is no way to find out if there is a leaf is missing, but = you=20 will still get an hi-entry showing the unsuccessful branch with=20 a reason that triggered the request received(e.g.=20 branch that failed due to 487 for example will show up in the H-I=20 but contact address(leaf) at the end of the failed branch won't)..=20 >=20 > 3- =A75.1.1 At the end of the second sentence, there are 2 right = parenthesis. > =A76.3.1 after reference to [RFC3261], there are 2 right square = brackets. >=20 > 4- =A76.1 In the rules after the header syntax, the sentence=20 > "There MUST be no more than one hi-target parameter."=20 > should be completed with "per hi-entry" to be more precise (as it is = the case in the previous item). >=20 > 5- =A76.3.2 In the sentence=20 > "This is accomplished by adding a new priv-value, > history, to the Privacy header [RFC3323] indicating that a = specific > History-Info header entry can not be forwarded outside the = domain." > It should be better to complete with : To do this, the Privacy header = with the priv-value history is=20 > escaped in the hi-entry corresponding to the concerned URI. >=20 > 6- =A77:=20 > "For example, an Automatic Call Distribution (ACD)/Call center = application > that utilizes the entry prior to the first History-Info entry = with an > hi-target value of "mp", ..." > Do you mean the entry with the index that matches the first = History-Info entry with an hi-target value of "mp"? (instead of the = prior) I will let Mary answer this one..=20 Regards Shida >=20 > 7- Appendix B.2 and B.3: what is the "p=3Dx" in the URI? >=20 > Cheers, > Marianne=20 >=20 > -----Message d'origine----- > De : sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] De la = part de Mary Barnes > Envoy=E9 : jeudi 1 juillet 2010 21:31 > =C0 : SIPCORE > Objet : Re: [sipcore] Updated 4244bis and new call flow document >=20 > Hi folks, >=20 > I have not seen any responses to this email. So, either folks don't = see any issues with the documents and 4244bis is ready for WGLC or folks = have not reviewed the documents. I'm happy to assume the former, = however, it would be good for folks that have read the docs to post a = note on the mailing list as to whether they think 4244bis is ready for = WGLC. And, if not, please detail your concerns, so that we can = determine whether they warrant discussion in Maastricht. >=20 > Also, opinions on how/where to progress the call flow document would = be welcome. I personally do not think it's worthwhile to pursue this in = DISPATCH, but it's not clear to me whether informational docs like this = are under the purview of the SIPCORE charter. Since BLISS is trying to = close down, it is also not appropriate to pursue the work there. >=20 > Thanks, > Mary. >=20 > On Thu, Jun 24, 2010 at 3:11 PM, Mary Barnes = wrote: >> Hi folks, >>=20 >> The 4244bis draft has been updated and a separate call flow document=20= >> created per the earlier summary of proposed changes: >> http://www.ietf.org/mail-archive/web/sipcore/current/msg02647.html >>=20 >> http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-01.txt >> = http://www.ietf.org/id/draft-barnes-sipcore-rfc4244bis-callflows-00.tx >> t >>=20 >> There are two voicemail examples in the new call flow document. The=20= >> 4244bis has 3 call flows - the basic sequential forking and two=20 >> privacy examples. All the rest are now in the call flow document. >>=20 >> The other changes we made were updates to the UAC, UAS and = application=20 >> considerations section - adding additional text as to how the UAC and=20= >> UAS process hi-entries (including related to responses). The=20 >> application considerations section now describes how the tags can be=20= >> used to derive specific information and the past guidelines were=20 >> removed since 4244bis has much definitive guidance on the normative=20= >> aspects of the header (i.e., SHOULDs replaced with MUSTs, privacy via=20= >> anonymization rather than removing entries, etc.) as summarized in=20 >> Section 11. >>=20 >> Please review and provide any additional comments. We believe that=20 >> 4244bis is pretty much ready to go. We can fine tune the details in=20= >> the call flows and should be able to get that ready very soon, as=20 >> well. Let us know if you see additional use cases you would like to=20= >> add. >>=20 >> Thanks, >> Mary et al >>=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From br@brianrosen.net Sun Jul 25 11:53:16 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AA6AD3A67F8 for ; Sun, 25 Jul 2010 11:53:16 -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 U08H+3A7CyGJ for ; Sun, 25 Jul 2010 11:53:15 -0700 (PDT) Received: from ebru.winwebhosting.com (ebru.winwebhosting.com [70.87.156.98]) by core3.amsl.com (Postfix) with ESMTP id 98CDB3A69A6 for ; Sun, 25 Jul 2010 11:53:13 -0700 (PDT) Received: from [32.178.249.235] by ebru.winwebhosting.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69) (envelope-from ) id 1Od6KF-0007zq-AT; Sun, 25 Jul 2010 13:53:28 -0500 Mime-Version: 1.0 (Apple Message framework v1081) Content-Type: text/plain; charset=windows-1252 From: Brian Rosen In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03EB77350A@SISPE7MB1.commscope.com> Date: Sun, 25 Jul 2010 14:53:23 -0400 Content-Transfer-Encoding: quoted-printable Message-Id: References: <8B0A9FCBB9832F43971E38010638454F03E9DCD1AE@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F03E9DCD24A@SISPE7MB1.commscope.com> <201007251333.o6PDXURr019180@rtp-core-1.cisco.com> <8B0A9FCBB9832F43971E38010638454F03EB77350A@SISPE7MB1.commscope.com> To: "James M. Polk" , Jon Peterson X-Mailer: Apple Mail (2.1081) X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - 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 Cc: sipcore@ietf.org, Martin Thomson Subject: Re: [sipcore] location-conveyance-03 just 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: Sun, 25 Jul 2010 18:53:16 -0000 I was hoping this would settle out the right way, but alas.... First of all, I don't think value + reference from the same source is = really all that important. It can be accomplished with a reference that = returns what the value would have been to unauthenticated dereferencers. = It's more efficient to use value+reference, but not by much. However. in the end, I think (despite my being a coauthor), the = mechanism in -03 is insufficient. If you want to treat emergency call = as a corner case, that is okay, but it's an important one. I don't think intermediaries will 424 and ask the UAC to compose = something they like. I think they will drop the existing header and = replace it with what they want it to be. =20 I think the requirement is either two PIDFs in one geolocation header, = or or two parameters in one header. That get us into "used for = routing", but assuming the intermediary will 424 rather than replace is, = in my opinion, fantasy. Brian On Jul 25, 2010, at 10:18 AM, Thomson, Martin wrote: > I feel like some of this is old ground, but I chalk that up to you = doing all these replies while you were offline. >=20 > (I'll note that some of your recent responses are in response to = emails that you have already responded to.) >=20 >>> Dynamism is the easiest one to pin down. It's >>> obviously very important to the emergency >>> scenario - the ability of a PSAP to acquire >>> updated location information in a timely fashion >>> is central to many of their use cases. >>=20 >> Martin - how long are you expecting this initial >> INVITE to go from the UAC to the PSAP? >>=20 >> You're giving the impression that a second or two >> matters or the UAC will be in a completely >> different location, meaning the wrong PSAP will be contacted. >=20 > It's not the transit time that is the problem, it=92s the uses of = location after that. The call can certainly last longer than a few = seconds. >=20 >>> In either case, it's possible to leave the >>> intermediary out of consideration and >>> concentrate on the information that the UAC provides. >>=20 >> but what about environments (or networks) that >> don't trust the UE (or UAC) at all. I'd argue >> that's much more probable -- because that's how 3GPP treats their >> phones. >=20 > Then they have some reconsidering to do in how they deploy this spec. = There are methods for dealing with this that might be more practical in = those environments, but less so on the wider Internet. Digital = signatures, for example. >=20 > ...=20 >>> The interactions with the intermediary add >>> complexity to the scenario, including some >>> privacy model problems, primarily with retransmission. >>=20 >> meaning UDP vs TCP? >=20 > Meaning . I would hope that people know how = to use UDP and TCP by now. >=20 > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From keith.drage@alcatel-lucent.com Sun Jul 25 23:22:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DCAF03A683A for ; Sun, 25 Jul 2010 23:22:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.078 X-Spam-Level: X-Spam-Status: No, score=-5.078 tagged_above=-999 required=5 tests=[AWL=1.171, 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 z1YHBvPvbUBQ for ; Sun, 25 Jul 2010 23:22:30 -0700 (PDT) Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by core3.amsl.com (Postfix) with ESMTP id 7F9443A67F5 for ; Sun, 25 Jul 2010 23:22:30 -0700 (PDT) Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id o6Q6MbsH029910 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 26 Jul 2010 08:22:47 +0200 Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.45]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Mon, 26 Jul 2010 08:22:46 +0200 From: "DRAGE, Keith (Keith)" To: Paul Kyzivat Date: Mon, 26 Jul 2010 08:22:45 +0200 Thread-Topic: [sipcore] Updated 4244bis and new call flow document Thread-Index: AcsqcQ83zXMnna8cTe+hYpGDjssymABeQ3yA Message-ID: References: <9886E5FCA6D76549A3011068483A4BD4065E732E@S4DE8PSAAQB.mitte.t-com.de> <4C49951C.8050202@cisco.com> <4C49A337.3010503@cisco.com> In-Reply-To: <4C49A337.3010503@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83 Cc: "sipcore@ietf.org" , "R.Jesske@telekom.de" Subject: Re: [sipcore] Updated 4244bis and new call flow document X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 26 Jul 2010 06:22:32 -0000 I suspect the text was meant to mean trust domain as in RFC 3325. Note that it is not necessarily the RFC 3325 trust domain (different header= s can have different trust domains). But it does need to do a similar job t= o RFC 3324/3325 in defining the concept of the trust domain. regards Keith > -----Original Message----- > From: Paul Kyzivat [mailto:pkyzivat@cisco.com]=20 > Sent: Friday, July 23, 2010 3:12 PM > To: DRAGE, Keith (Keith) > Cc: R.Jesske@telekom.de; sipcore@ietf.org > Subject: Re: [sipcore] Updated 4244bis and new call flow document >=20 > Keith, >=20 > You raise a good point. It forced me to go back and review=20 > 3323 and 3325. >=20 > 3323 defines a "privacy service" which the UAC can use to=20 > assist it in obtaining privacy. The UAC is expected to=20 > arrange for its requests to be routed through a privacy service. >=20 > The notion of trust domain is introduced in 3325. It=20 > introduces the "id"=20 > privacy value, which is to be removed at the boundary of the=20 > trust domain, but not before then. It doesn't say anything=20 > about where privacy services exist in the network. Its my=20 > assumption that there must be a privacy service on the=20 > boundary of the trust domain that acts on the "id" privacy=20 > type. But this is not explict. And even if this is implied,=20 > its hard to say if it would be a full privacy service that=20 > can be counted upon to act upon other privacy types in the request. >=20 > Hence, a UAC that wishes "header" or "session" privacy has=20 > nothing better to go on than 3323, which recommends that it=20 > route its outbound request directly to a privacy service. If=20 > that privacy service is compliant with 4244bis, it will=20 > anonymize what is in the H-I header at that time. But then=20 > any entries added downstream of that point will not be anonymized. >=20 > So I think there really is something wrong with the referenced text. > If the use of "domain" was intended to be "trust domain" then=20 > its dependent on 3325. If it was intended to mean "DNS=20 > domain", then its still implying there is a privacy service=20 > that will magically be traversed when leaving the DNS domain. >=20 > Thanks, > Paul >=20 > DRAGE, Keith (Keith) wrote: > > If we are going to talk about trust domains in the=20 > document, then you will have to say what they are. > >=20 > > For the RFC 3325 stuff there is most of a document that=20 > talks about that. Moreover, you need to say what to "trust"=20 > the next entity to do if you do not do it. > >=20 > > To give some idea of what I mean. Statements like "I will=20 > give you the identity if you do not reveal it to anyone=20 > outside our area of trust" are slightly different to "I trust=20 > you to implement the privacy that I otherwise would have done=20 > so if I did not trust you". > >=20 > > regards > >=20 > > Keith > >=20 > >> -----Original Message----- > >> From: sipcore-bounces@ietf.org > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > >> Sent: Friday, July 23, 2010 2:12 PM > >> To: R.Jesske@telekom.de > >> Cc: sipcore@ietf.org > >> Subject: Re: [sipcore] Updated 4244bis and new call flow document > >> > >> > >> > >> R.Jesske@telekom.de wrote: > >>> Hi Mary, > >>> With regard to your question for comments/review, I went > >> thought the draft. > >>> For http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-01.txt > >>> > >>> I have the following comments:=20 > >>> > >>> > >>> 6.3.2. Privacy in the History-Info Header > >>> > >>> ... > >>> If the requestor has indicated a priv- > >>> value of "session" or "header" in the request, all History-Info > >>> entries MUST be anonymized when the request leaves a > >> domain for which > >>> the intermediary is responsible. > >>> ... > >>> > >>> In this section it is mentioned that the entries must be > >> anonymized when leaving the domain. I thought that if a trust=20 > >> relationship between domains are existing and the following domain=20 > >> secures the "privacy" then the information could be forwarded and=20 > >> will then deleted by the succeeding domain before reaching the=20 > >> terminating user. > >>> Some regulators are requesting to pass identities until the > >> last domain where it is possible to execute the privacy regarding=20 > >> RFC3323. So I think this is a MAY based on domain policy.=20 > And it is a=20 > >> MUST when the succeeding network cannot guarantee the privacy. > >>> Or do I misunderstand the meaning of "domain for which the > >> intermediary is responsible" > >> > >> I'm not an expert on this, but ISTM that in the case you=20 > describe the=20 > >> request is not leaving the *trust* domain. > >> > >> But that does point out ambiguity in the text you quote.=20 > That kind of=20 > >> wording "domain for which the intermediary is responsible"=20 > is usually=20 > >> talking about *DNS* domains, not > >> *trust* domains. So maybe that should say: > >> > >> ... > >> If the requestor has indicated a priv-value of "session"=20 > or "header" > >> in the request, all History-Info entries MUST be=20 > anonymized when the > >> request leaves a *trust* domain for which the intermediary is > >> responsible. > >> ... > >> > >> Thanks, > >> Paul > >> _______________________________________________ > >> sipcore mailing list > >> sipcore@ietf.org > >> https://www.ietf.org/mailman/listinfo/sipcore > >> > = From mary.ietf.barnes@gmail.com Sun Jul 25 23:37:22 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DA7FE3A69F6 for ; Sun, 25 Jul 2010 23:37:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.32 X-Spam-Level: X-Spam-Status: No, score=-2.32 tagged_above=-999 required=5 tests=[AWL=0.278, 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 pKR4YujdBT85 for ; Sun, 25 Jul 2010 23:37:21 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id CF8213A6A17 for ; Sun, 25 Jul 2010 23:35:19 -0700 (PDT) Received: by iwn38 with SMTP id 38so2717872iwn.31 for ; Sun, 25 Jul 2010 23:34:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=Pa//1+yeuigPMFkLXFghfDO865jaFekClJgyKr+xFH0=; b=SbA9pJn0IeJ1BLoUaUN3EgIdyBhrYH/rDodOLlv5qu8MJLQkIB9oFdZFkyxmXzuniF Ka/H+r7pBmFQzUY/Jk+rtd8u6iL1GBBGmjy2aCxYFjrUSuWf6GgpAXfIdVnd52BFZG4J 1Oe7x7KNFyi5jkq9VdkiiKOr3oYo/LUVrvJ9Y= 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=YVTFSOr0lKn8eqUF1LtLV2gaYoQTclDFtLV+dk641ofw8o9BIRHTa4MHXSAhORoMEo RzsN9gS17YXxQKrXyb4ukWW3s8kL7gI0VKtyOgxlvYjgWdgYovSbu8IP4U05Hql94Deh ErCgfAJ9uabdqoXR40n4BgxMs0N0BVgZ3u2ik= MIME-Version: 1.0 Received: by 10.231.146.196 with SMTP id i4mr7505692ibv.110.1280126098642; Sun, 25 Jul 2010 23:34:58 -0700 (PDT) Received: by 10.231.169.14 with HTTP; Sun, 25 Jul 2010 23:34:58 -0700 (PDT) In-Reply-To: References: <9886E5FCA6D76549A3011068483A4BD4065E732E@S4DE8PSAAQB.mitte.t-com.de> <4C49951C.8050202@cisco.com> <4C49A337.3010503@cisco.com> Date: Mon, 26 Jul 2010 01:34:58 -0500 Message-ID: From: Mary Barnes To: "DRAGE, Keith (Keith)" Content-Type: multipart/alternative; boundary=0016e64ec4cc6099c6048c449504 Cc: "sipcore@ietf.org" , "R.Jesske@telekom.de" Subject: Re: [sipcore] Updated 4244bis and new call flow document X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 26 Jul 2010 06:37:23 -0000 --0016e64ec4cc6099c6048c449504 Content-Type: text/plain; charset=ISO-8859-1 Yes - the use of trust domain in this document is intended to be that defined in RFC 3325. The use of the term "responsible domain" is based on core RFC 3261 - e.g., "....domains the proxy is configured to be responsible for" as noted in section 16.4. RFC 4244 did not introduce any new definitions or concepts wrt domains/trust domains and relies entirely on RFC3261 and RFC3325 for these concepts. I can't see that the text in RFC 4244bis contradicts with the usages of the terms defined in those RFCs. But, I might be too familiar with the doc to see that. Thanks, Mary. On Mon, Jul 26, 2010 at 1:22 AM, DRAGE, Keith (Keith) < keith.drage@alcatel-lucent.com> wrote: > I suspect the text was meant to mean trust domain as in RFC 3325. > > Note that it is not necessarily the RFC 3325 trust domain (different > headers can have different trust domains). But it does need to do a similar > job to RFC 3324/3325 in defining the concept of the trust domain. > > regards > > Keith > > > -----Original Message----- > > From: Paul Kyzivat [mailto:pkyzivat@cisco.com] > > Sent: Friday, July 23, 2010 3:12 PM > > To: DRAGE, Keith (Keith) > > Cc: R.Jesske@telekom.de; sipcore@ietf.org > > Subject: Re: [sipcore] Updated 4244bis and new call flow document > > > > Keith, > > > > You raise a good point. It forced me to go back and review > > 3323 and 3325. > > > > 3323 defines a "privacy service" which the UAC can use to > > assist it in obtaining privacy. The UAC is expected to > > arrange for its requests to be routed through a privacy service. > > > > The notion of trust domain is introduced in 3325. It > > introduces the "id" > > privacy value, which is to be removed at the boundary of the > > trust domain, but not before then. It doesn't say anything > > about where privacy services exist in the network. Its my > > assumption that there must be a privacy service on the > > boundary of the trust domain that acts on the "id" privacy > > type. But this is not explict. And even if this is implied, > > its hard to say if it would be a full privacy service that > > can be counted upon to act upon other privacy types in the request. > > > > Hence, a UAC that wishes "header" or "session" privacy has > > nothing better to go on than 3323, which recommends that it > > route its outbound request directly to a privacy service. If > > that privacy service is compliant with 4244bis, it will > > anonymize what is in the H-I header at that time. But then > > any entries added downstream of that point will not be anonymized. > > > > So I think there really is something wrong with the referenced text. > > If the use of "domain" was intended to be "trust domain" then > > its dependent on 3325. If it was intended to mean "DNS > > domain", then its still implying there is a privacy service > > that will magically be traversed when leaving the DNS domain. > > > > Thanks, > > Paul > > > > DRAGE, Keith (Keith) wrote: > > > If we are going to talk about trust domains in the > > document, then you will have to say what they are. > > > > > > For the RFC 3325 stuff there is most of a document that > > talks about that. Moreover, you need to say what to "trust" > > the next entity to do if you do not do it. > > > > > > To give some idea of what I mean. Statements like "I will > > give you the identity if you do not reveal it to anyone > > outside our area of trust" are slightly different to "I trust > > you to implement the privacy that I otherwise would have done > > so if I did not trust you". > > > > > > regards > > > > > > Keith > > > > > >> -----Original Message----- > > >> From: sipcore-bounces@ietf.org > > >> [mailto:sipcore-bounces@ietf.org] On Behalf Of Paul Kyzivat > > >> Sent: Friday, July 23, 2010 2:12 PM > > >> To: R.Jesske@telekom.de > > >> Cc: sipcore@ietf.org > > >> Subject: Re: [sipcore] Updated 4244bis and new call flow document > > >> > > >> > > >> > > >> R.Jesske@telekom.de wrote: > > >>> Hi Mary, > > >>> With regard to your question for comments/review, I went > > >> thought the draft. > > >>> For http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-01.txt > > >>> > > >>> I have the following comments: > > >>> > > >>> > > >>> 6.3.2. Privacy in the History-Info Header > > >>> > > >>> ... > > >>> If the requestor has indicated a priv- > > >>> value of "session" or "header" in the request, all History-Info > > >>> entries MUST be anonymized when the request leaves a > > >> domain for which > > >>> the intermediary is responsible. > > >>> ... > > >>> > > >>> In this section it is mentioned that the entries must be > > >> anonymized when leaving the domain. I thought that if a trust > > >> relationship between domains are existing and the following domain > > >> secures the "privacy" then the information could be forwarded and > > >> will then deleted by the succeeding domain before reaching the > > >> terminating user. > > >>> Some regulators are requesting to pass identities until the > > >> last domain where it is possible to execute the privacy regarding > > >> RFC3323. So I think this is a MAY based on domain policy. > > And it is a > > >> MUST when the succeeding network cannot guarantee the privacy. > > >>> Or do I misunderstand the meaning of "domain for which the > > >> intermediary is responsible" > > >> > > >> I'm not an expert on this, but ISTM that in the case you > > describe the > > >> request is not leaving the *trust* domain. > > >> > > >> But that does point out ambiguity in the text you quote. > > That kind of > > >> wording "domain for which the intermediary is responsible" > > is usually > > >> talking about *DNS* domains, not > > >> *trust* domains. So maybe that should say: > > >> > > >> ... > > >> If the requestor has indicated a priv-value of "session" > > or "header" > > >> in the request, all History-Info entries MUST be > > anonymized when the > > >> request leaves a *trust* domain for which the intermediary is > > >> responsible. > > >> ... > > >> > > >> Thanks, > > >> Paul > > >> _______________________________________________ > > >> sipcore mailing list > > >> sipcore@ietf.org > > >> https://www.ietf.org/mailman/listinfo/sipcore > > >> > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --0016e64ec4cc6099c6048c449504 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Yes - the use of trust domain in this document is intended to be that defined in R= FC 3325. =A0The use of the term "responsible domain" is based on = core RFC 3261 - e.g., "....domains the proxy is configured to be responsible for" as noted in sectio= n 16.4. =A0

RFC 4244 did not = introduce any new definitions or concepts wrt domains/trust domains and rel= ies entirely on RFC3261 and RFC3325 for these concepts. I can't see tha= t the text in RFC 4244bis contradicts with the usages of the terms defined = in those RFCs. But, I might be too familiar with the doc to see that.

=
Thanks,
Mary.
<= span class=3D"Apple-style-span" style=3D"white-space: pre-wrap;">

On Mon, Jul 26, 2010 at = 1:22 AM, DRAGE, Keith (Keith) <keith.drage@alcatel-lucent.com> wr= ote:
I suspect the text was meant to mean trust = domain as in RFC 3325.

Note that it is not necessarily the RFC 3325 trust domain (different header= s can have different trust domains). But it does need to do a similar job t= o RFC 3324/3325 in defining the concept of the trust domain.

regards

Keith

> -----Original Message-----
> From: Paul Kyzivat [mailto:pkyzi= vat@cisco.com]
> Sent: Friday, July 23, 2010 3:12 PM
> To: DRAGE, Keith (Keith)
> Cc: R.Jesske@telekom.de; sipcore@ietf.org
> Subject: Re: [sipcore] Updated 4244bis and new call flow document
>
> Keith,
>
> You raise a good point. It forced me to go back and review
> 3323 and 3325.
>
> 3323 defines a "privacy service" which the UAC can use to > assist it in obtaining privacy. The UAC is expected to
> arrange for its requests to be routed through a privacy service.
>
> The notion of trust domain is introduced in 3325. It
> introduces the "id"
> privacy value, which is to be removed at the boundary of the
> trust domain, but not before then. It doesn't say anything
> about where privacy services exist in the network. Its my
> assumption that there must be a privacy service on the
> boundary of the trust domain that acts on the "id" privacy > type. But this is not explict. And even if this is implied,
> its hard to say if it would be a full privacy service that
> can be counted upon to act upon other privacy types in the request. >
> Hence, a UAC that wishes "header" or "session" pri= vacy has
> nothing better to go on than 3323, which recommends that it
> route its outbound request directly to a privacy service. If
> that privacy service is compliant with 4244bis, it will
> anonymize what is in the H-I header at that time. But then
> any entries added downstream of that point will not be anonymized.
>
> So I think there really is something wrong with the referenced text. > If the use of "domain" was intended to be "trust domain= " then
> its dependent on 3325. If it was intended to mean "DNS
> domain", then its still implying there is a privacy service
> that will magically be traversed when leaving the DNS domain.
>
> =A0 =A0 =A0 Thanks,
> =A0 =A0 =A0 Paul
>
> DRAGE, Keith (Keith) wrote:
> > If we are going to talk about trust domains in the
> document, then you will have to say what they are.
> >
> > For the RFC 3325 stuff there is most of a document that
> talks about that. Moreover, you need to say what to "trust"<= br> > the next entity to do if you do not do it.
> >
> > To give some idea of what I mean. Statements like "I will > give you the identity if you do not reveal it to anyone
> outside our area of trust" are slightly different to "I trus= t
> you to implement the privacy that I otherwise would have done
> so if I did not trust you".
> >
> > regards
> >
> > Keith
> >
> >> -----Original Message-----
> >> From: sipcore-bou= nces@ietf.org
> >> [mailto:sipcore-b= ounces@ietf.org] On Behalf Of Paul Kyzivat
> >> Sent: Friday, July 23, 2010 2:12 PM
> >> To: R.Jesske@telekom.d= e
> >> Cc: sipcore@ietf.org<= br> > >> Subject: Re: [sipcore] Updated 4244bis and new call flow docu= ment
> >>
> >>
> >>
> >> R.Jesske@telekom.de wrote:
> >>> Hi Mary,
> >>> With regard to your question for comments/review, I went<= br> > >> thought the draft.
> >>> For http://www.ietf.org/id/draft-ietf-sipc= ore-rfc4244bis-01.txt
> >>>
> >>> I have the following comments:
> >>>
> >>>
> >>> 6.3.2. =A0Privacy in the History-Info Header
> >>>
> >>> ...
> >>> If the requestor has indicated a priv-
> >>> =A0 =A0value of "session" or "header"= in the request, all History-Info
> >>> =A0 =A0entries MUST be anonymized when the request leaves= a
> >> domain for which
> >>> =A0 =A0the intermediary is responsible.
> >>> ...
> >>>
> >>> In this section it is mentioned that the entries must be<= br> > >> anonymized when leaving the domain. I thought that if a trust=
> >> relationship between domains are existing and the following d= omain
> >> secures the "privacy" then the information could be= forwarded and
> >> will then deleted by the succeeding domain before reaching th= e
> >> terminating user.
> >>> Some regulators are requesting to pass identities until t= he
> >> last domain where it is possible to execute the privacy regar= ding
> >> RFC3323. So I think this is a MAY based on domain policy.
> And it is a
> >> MUST when the succeeding network cannot guarantee the privacy= .
> >>> Or do I misunderstand the meaning of "domain for whi= ch the
> >> intermediary is responsible"
> >>
> >> I'm not an expert on this, but ISTM that in the case you<= br> > describe the
> >> request is not leaving the *trust* domain.
> >>
> >> But that does point out ambiguity in the text you quote.
> That kind of
> >> wording "domain for which the intermediary is responsibl= e"
> is usually
> >> talking about *DNS* domains, not
> >> *trust* domains. So maybe that should say:
> >>
> >> =A0 ...
> >> =A0 If the requestor has indicated a priv-value of "sess= ion"
> or "header"
> >> =A0 in the request, all History-Info entries MUST be
> anonymized when the
> >> =A0 request leaves a *trust* domain for which the intermediar= y is
> >> =A0 responsible.
> >> =A0 ...
> >>
> >> =A0 =A0Thanks,
> >> =A0 =A0Paul
> >> _______________________________________________
> >> 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

--0016e64ec4cc6099c6048c449504-- From root@core3.amsl.com Mon Jul 26 00:45:02 2010 Return-Path: X-Original-To: sipcore@ietf.org Delivered-To: sipcore@core3.amsl.com Received: by core3.amsl.com (Postfix, from userid 0) id 618063A69F8; Mon, 26 Jul 2010 00:45:02 -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: <20100726074502.618063A69F8@core3.amsl.com> Date: Mon, 26 Jul 2010 00:45:02 -0700 (PDT) Cc: sipcore@ietf.org Subject: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-05.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 07:45:02 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Session Initiation Protocol Core Working Group of the IETF. Title : Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) Author(s) : G. Camarillo, et al. Filename : draft-ietf-sipcore-reinvite-05.txt Pages : 25 Date : 2010-07-26 In this document, we clarify the handling of re-INVITEs in SIP. We clarify in which situations a UAS (User Agent Server) should generate a success response and in which situations a UAS should generate an error response to a re-INVITE. Additionally, we clarify issues related to target-refresh requests. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipcore-reinvite-05.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-sipcore-reinvite-05.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2010-07-26004410.I-D@ietf.org> --NextPart-- From gonzalo.camarillo@ericsson.com Mon Jul 26 00:49:54 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id AFAD43A6A50 for ; Mon, 26 Jul 2010 00:49:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.794 X-Spam-Level: X-Spam-Status: No, score=-105.794 tagged_above=-999 required=5 tests=[AWL=0.805, 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 fQtUSBS+Nsmp for ; Mon, 26 Jul 2010 00:49:53 -0700 (PDT) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 494443A6A47 for ; Mon, 26 Jul 2010 00:49:53 -0700 (PDT) X-AuditID: c1b4fb3d-b7b90ae00000278d-26-4c4d3e3415cb Received: from esealmw129.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 13.E2.10125.43E3D4C4; Mon, 26 Jul 2010 09:50:12 +0200 (CEST) Received: from esealmw129.eemea.ericsson.se ([153.88.254.177]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jul 2010 09:50:12 +0200 Received: from [131.160.126.137] ([131.160.126.137]) by esealmw129.eemea.ericsson.se with Microsoft SMTPSVC(6.0.3790.3959); Mon, 26 Jul 2010 09:50:11 +0200 Message-ID: <4C4D3E33.1040901@ericsson.com> Date: Mon, 26 Jul 2010 09:50:11 +0200 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1.11) Gecko/20100711 Thunderbird/3.0.6 MIME-Version: 1.0 To: "sipcore@ietf.org" References: <20100726074502.618063A69F8@core3.amsl.com> In-Reply-To: <20100726074502.618063A69F8@core3.amsl.com> X-Enigmail-Version: 1.0.1 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 26 Jul 2010 07:50:11.0923 (UTC) FILETIME=[2D245230:01CB2C97] X-Brightmail-Tracker: AAAAAA== Subject: Re: [sipcore] I-D Action:draft-ietf-sipcore-reinvite-05.txt X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 07:49:54 -0000 Hi, as I just said in the (currently ongoing) face-to-face session, this revision addresses all the comments received so far and, thus, is ready for IETF LC. Cheers, Gonzalo On 26/07/2010 9:45 AM, 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 : Re-INVITE and Target-refresh Request Handling in the Session Initiation Protocol (SIP) > Author(s) : G. Camarillo, et al. > Filename : draft-ietf-sipcore-reinvite-05.txt > Pages : 25 > Date : 2010-07-26 > > In this document, we clarify the handling of re-INVITEs in SIP. We > clarify in which situations a UAS (User Agent Server) should generate > a success response and in which situations a UAS should generate an > error response to a re-INVITE. Additionally, we clarify issues > related to target-refresh requests. > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-sipcore-reinvite-05.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > Below is the data which will enable a MIME compliant mail reader > implementation to automatically retrieve the ASCII version of the > Internet-Draft. From mary.ietf.barnes@gmail.com Mon Jul 26 00:50:48 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3BFFD3A6A42 for ; Mon, 26 Jul 2010 00:50:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.341 X-Spam-Level: X-Spam-Status: No, score=-2.341 tagged_above=-999 required=5 tests=[AWL=0.257, 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 chOoeiwjn4ht for ; Mon, 26 Jul 2010 00:50:45 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id 2F40B3A6A41 for ; Mon, 26 Jul 2010 00:50:45 -0700 (PDT) Received: by iwn38 with SMTP id 38so2775130iwn.31 for ; Mon, 26 Jul 2010 00:51:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=DWhfCIRe7oa7Klcpc5kITWs7bYnEF0sl4+JNYCTWTbg=; b=qfKS2CZQgGz3ZGIjDcqkTH8QOqPkCUzRMx1vqWRQGMeJbcQsDplaHPQ5w271T/xEWP IqweBgEkRe3zTe8lV13W6VA1OKLFQcbg4UA/NRj4JXHhneVraYQlccOwL+pjXe6ITw+p A/DeC2ATGA1a4YjjAqvWYcCtcBruz/DyBHBM8= 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=lUTJCdIKJL+TZoCs9y50SWlfD0rXZxVAufOqbBYL3cJY2hKpp4W2eZYHnBTfOtlgup YdBuVefvgAn2ghjah5e4Gv6hGnKWzF/Sxdon++tMRntc1kbzLh4GbI1BgisKpqjppIAe ggTvHNDfDIP7K17dc7u7mEYDX41gFSad/SZJs= MIME-Version: 1.0 Received: by 10.231.60.5 with SMTP id n5mr8177155ibh.162.1280130665467; Mon, 26 Jul 2010 00:51:05 -0700 (PDT) Received: by 10.231.169.14 with HTTP; Mon, 26 Jul 2010 00:51:05 -0700 (PDT) In-Reply-To: <91BE6A3F-5582-45CA-8668-4D00B9F9CB42@ntt-at.com> References: <91BE6A3F-5582-45CA-8668-4D00B9F9CB42@ntt-at.com> Date: Mon, 26 Jul 2010 02:51:05 -0500 Message-ID: From: Mary Barnes To: Shida Schubert Content-Type: multipart/alternative; boundary=001485e0e55894cfd7048c45a5a6 Cc: sipcore@ietf.org Subject: Re: [sipcore] Updated 4244bis and new call flow document X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 26 Jul 2010 07:50:48 -0000 --001485e0e55894cfd7048c45a5a6 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Marianne and Shida, Responses inline below [MB]. Thanks, Mary. On Sun, Jul 25, 2010 at 10:22 AM, Shida Schubert wrote: > > Hi Marianne; > > Thanks for the review, comments inline.. > > On Jul 25, 2010, at 3:09 AM, < > marianne.mohali@orange-ftgroup.com> wrote: > > > Hi Mary and all, > > > > I have some comments on draft-ietf-sipcore-rfc4244bis-01: > > > > 1- Regarding the "hit" and "target" parameters, is it really necessary = to > create both? > > I mean the "hit" parameter seems almost useless as it has to be remove= d > from the R-URI just > > after its creation (kept only in the Contact header after a 3xx). > > Why the hi-target couldn't be a single parameter to tag URIs? > > I can't clearly recall why we added this "hit" parameter but > we had some problems delivering the "to-be hi-entry" that > caused the 3xx. We talked about escaping the history-info header > in the contact header in 3xx so entity receiving the 3xx can construct > the hi-entry but decided to go with using the "hit" parameter. > [MB] Yes, both are necessary. If you look at the last individual version of the doc, the handling for the 3xx had been changed from RFC4244 and had the redirect server adding hi-entries. However, that was broken since the redirect server cannot know whether the URIs it puts in the Contact header are actually used to retarget the request. But, the redirect server is the only entity that knows the mechanisms by which the URIs it adds to the contact were determined. So, we added the "hit" as a URI parameter for the URIs in the Contact header. Then, the proxy/entity that is actually buildin= g the hi-entries can use this information to include the right "hi-target". This really ended up making the processing far less different than RFC 424= 4 and far less complex - both good things. [/MB] > > > > > 2- =A74.1 it is said that > > "The entries SHOULD be evaluated to determine gaps in indices, > > which could indicate that an entry has been maliciously removed. > > Either way, an application SHOULD be aware of potentially missing > information." > > If the removed hi-entry is the last destination (leaf) of an unsuccessf= ul > route (branch), > > how is it possible, at the end, to know that there is a missing entry? > > It's true that if a leaf at an unsuccessful forked branch isn't > captured there is no way to find out if there is a leaf is missing, but y= ou > will still get an hi-entry showing the unsuccessful branch with > a reason that triggered the request received(e.g. > branch that failed due to 487 for example will show up in the H-I > but contact address(leaf) at the end of the failed branch won't).. > [MB] The text you are referencing has to do with how you can know that entries are missing if there are gaps in the values of the index - e.g., an entry with an index of 1.1 and then the next having a value of 1.3, etc. This actually should not occur with 4244bis since the privacy was changed t= o anonymize rather than remove. The only time that might happen is if you have a rogue proxy or a proxy that has not properly implemented 4244(-bis). This document relies on the fundamental SIP model that the proxies are trusted. That text is not referring to the case where the request for that branch does not result in a successful termination. However, the proxy should include all the information associated with that branch IF it is received before the request is successfully targeted. Note, that this gets to the point that Paul raised wrt to the need to clarify the processing for forking. For sequential forking, there is no issue, however, parallel forking introduces the possibility that the entity to which a request is successfully targeted not receiving the complete information. However, the information is complete in terms of what is available at that point in time= . As Paul highlighted, we do need to add additional normative text to describ= e the handling of the header in the case of forking. As far as the case of a 487, if a proxy supports HI then the Request-URI fo= r that branch should be included. But, since it wasn't successful that entry will not be the contact address as Shida notes. However, that is NOT considered a missing entry since the request was not sent to the contact. [/MB] > > > > > 3- =A75.1.1 At the end of the second sentence, there are 2 right > parenthesis. > > =A76.3.1 after reference to [RFC3261], there are 2 right square bracke= ts. > [MB] Will fix both of those - thanks. [/MB] > > > > > 4- =A76.1 In the rules after the header syntax, the sentence > > "There MUST be no more than one hi-target parameter." > > should be completed with "per hi-entry" to be more precise (as it is t= he > case in the previous item). > [MB] Good point - I'll clarify. [/MB] > > > > 5- =A76.3.2 In the sentence > > "This is accomplished by adding a new priv-value, > > history, to the Privacy header [RFC3323] indicating that a specif= ic > > History-Info header entry can not be forwarded outside the domain= ." > > It should be better to complete with : To do this, the Privacy header > with the priv-value history is > > escaped in the hi-entry corresponding to the concerned URI. > [MB] Okay, I'll clarify that. [/MB] > > > > 6- =A77: > > "For example, an Automatic Call Distribution (ACD)/Call center > application > > that utilizes the entry prior to the first History-Info entry wit= h > an > > hi-target value of "mp", ..." > > Do you mean the entry with the index that matches the first History-In= fo > entry with an hi-target value of "mp"? (instead of the prior) > > I will let Mary answer this one.. > [MB] Yes - that needs to be fixed. [/MB] > > Regards > Shida > > > > > 7- Appendix B.2 and B.3: what is the "p=3Dx" in the URI? > [MB] That was intended to represent a privacy header of "x", with x being any value for the privacy header with "history". However, there is no compact form for the privacy header, so really we should just show it inlin= e as we did in an earlier version. The gist of that call flow was to show tha= t rather than remove the entries they are now anonymized when they go outside the domain responsible for the Request-URI. [/MB]. > > > > Cheers, > > Marianne > > > > -----Message d'origine----- > > De : sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] De la > part de Mary Barnes > > Envoy=E9 : jeudi 1 juillet 2010 21:31 > > =C0 : SIPCORE > > Objet : Re: [sipcore] Updated 4244bis and new call flow document > > > > Hi folks, > > > > I have not seen any responses to this email. So, either folks don't see > any issues with the documents and 4244bis is ready for WGLC or folks have > not reviewed the documents. I'm happy to assume the former, however, it > would be good for folks that have read the docs to post a note on the > mailing list as to whether they think 4244bis is ready for WGLC. And, i= f > not, please detail your concerns, so that we can determine whether they > warrant discussion in Maastricht. > > > > Also, opinions on how/where to progress the call flow document would be > welcome. I personally do not think it's worthwhile to pursue this in > DISPATCH, but it's not clear to me whether informational docs like this a= re > under the purview of the SIPCORE charter. Since BLISS is trying to close > down, it is also not appropriate to pursue the work there. > > > > Thanks, > > Mary. > > > > On Thu, Jun 24, 2010 at 3:11 PM, Mary Barnes > wrote: > >> Hi folks, > >> > >> The 4244bis draft has been updated and a separate call flow document > >> created per the earlier summary of proposed changes: > >> http://www.ietf.org/mail-archive/web/sipcore/current/msg02647.html > >> > >> http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-01.txt > >> http://www.ietf.org/id/draft-barnes-sipcore-rfc4244bis-callflows-00.tx > >> t > >> > >> There are two voicemail examples in the new call flow document. The > >> 4244bis has 3 call flows - the basic sequential forking and two > >> privacy examples. All the rest are now in the call flow document. > >> > >> The other changes we made were updates to the UAC, UAS and application > >> considerations section - adding additional text as to how the UAC and > >> UAS process hi-entries (including related to responses). The > >> application considerations section now describes how the tags can be > >> used to derive specific information and the past guidelines were > >> removed since 4244bis has much definitive guidance on the normative > >> aspects of the header (i.e., SHOULDs replaced with MUSTs, privacy via > >> anonymization rather than removing entries, etc.) as summarized in > >> Section 11. > >> > >> Please review and provide any additional comments. We believe that > >> 4244bis is pretty much ready to go. We can fine tune the details in > >> the call flows and should be able to get that ready very soon, as > >> well. Let us know if you see additional use cases you would like to > >> add. > >> > >> Thanks, > >> Mary et al > >> > > _______________________________________________ > > 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 > > --001485e0e55894cfd7048c45a5a6 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Marianne and Shida,

Responses inline below [MB].
Thanks,
Mary.

On Sun, Jul 25, 2010 at 10:22 AM, Shida Schubert <shida@ntt-at.com> wrote:

Hi Marianne;

Thanks for the review, comments inline..

On Jul 25, 2010, at 3:09 AM, <marianne.mohali@orange-ftgroup.com> <marianne.mohali@orange-ftgroup.com> wrote:

> Hi Mary and all,
>
> I have some comments on draft-ietf-sipcore-rfc4244bis-01:
>
> 1- Regarding the "hit" and "target" parameters, is= it really necessary to create both?
> =A0I mean the "hit" parameter seems almost useless as it has= to be removed from the R-URI just
> =A0after its creation (kept only in the Contact header after a 3xx). > =A0Why the hi-target couldn't be a single parameter to tag URIs?
I can't clearly recall why we added this "hit" paramete= r but
we had some problems delivering the "to-be hi-entry" that
caused the 3xx. We talked about escaping the history-info header
in the contact header in 3xx so entity receiving the 3xx can construct
the hi-entry but decided to go with using the "hit" parameter.

[MB] Yes, both are necessary. If you look= at the last individual version of the doc, the handling for the 3xx had be= en changed from RFC4244 and had the redirect server adding hi-entries. Howe= ver, that was broken since the redirect server cannot know whether the URIs= it puts in the Contact header are actually used to retarget the request. B= ut, the redirect server is the only entity that knows the mechanisms by whi= ch the URIs it adds to the contact were determined. =A0So, we added the &qu= ot;hit" as a URI parameter for the URIs in the Contact header. Then, t= he proxy/entity that is actually building the hi-entries can use this infor= mation to include the right "hi-target". =A0This really ended up = making the processing far less different than RFC 4244 and far less complex= - both good things. =A0[/MB]

>
> 2- =A74.1 it is said that
> =A0"The entries SHOULD be evaluated to determine gaps in indices,=
> =A0which could indicate that an entry has been maliciously removed. > =A0Either way, an application SHOULD be aware of potentially missing i= nformation."
> If the removed hi-entry is the last destination (leaf) of an unsuccess= ful route (branch),
> how is it possible, at the end, to know that there is a missing entry?=

It's true that if a leaf at an unsuccessful forked branch isn'= ;t
captured there is no way to find out if there is a leaf is missing, but you=
will still get an hi-entry showing the unsuccessful branch with
a reason that triggered the request received(e.g.
branch that failed due to 487 for example will show up in the H-I
but contact address(leaf) at the end of the failed branch won't)..
<= /blockquote>
[MB] The text you are referencing has to do with how you c= an know that entries are missing if there are gaps in the values of the ind= ex - e.g., an entry with an index of 1.1 and then the next having a value o= f 1.3, etc. This actually should not occur with 4244bis since the privacy w= as changed to anonymize rather than remove. =A0The only time that might hap= pen is if you have a rogue proxy or a proxy that has not properly implement= ed 4244(-bis). This document relies on the fundamental SIP model that the p= roxies are trusted. That text is not referring to the case where the reques= t for that branch does not result in a successful termination. However, the= proxy should include all the information associated with that branch IF it= is received before the request is successfully targeted. Note, that this g= ets to the point that Paul raised wrt to the need to clarify the processing= for forking. For sequential forking, there is no issue, however, parallel = forking introduces the possibility that the entity to which a request is su= ccessfully targeted not receiving the complete information. However, the in= formation is complete in terms of what is available at that point in time. = As Paul highlighted, we do need to add additional normative text to describ= e the handling of the header in the case of forking.=A0

As far as the case of a 487, if a proxy supports HI the= n the Request-URI for that branch should be included. But, since it wasn= 9;t successful that entry will not be the contact address as Shida notes. H= owever, that is NOT considered a missing entry since the request was not se= nt to the contact.
=A0[/MB]
=A0

>
> 3- =A75.1.1 At the end of the second sentence, there are 2 right paren= thesis.
> =A0=A76.3.1 after reference to [RFC3261], there are 2 right square bra= ckets.
[MB] Will fix both of those - thanks. [/M= B]=A0

>
> 4- =A76.1 In the rules after the header syntax, the sentence
> =A0"There MUST be no more than one hi-target parameter."
> =A0should be completed with "per hi-entry" to be more precis= e (as it is the case in the previous item).
[MB]= Good point - I'll clarify. [/MB]
=A0
>
> 5- =A76.3.2 In the sentence
> =A0 =A0 =A0 "This is accomplished by adding a new priv-value,
> =A0 =A0 =A0 history, to the Privacy header [RFC3323] indicating that a= specific
> =A0 =A0 =A0 History-Info header entry can not be forwarded outside the= domain."
> =A0It should be better to complete with : To do this, the Privacy head= er with the priv-value history is
> =A0escaped in the hi-entry corresponding to the concerned URI.
[MB] Okay, I'll clarify that. =A0[/MB]=A0
>
> 6- =A77:
> =A0 =A0 =A0 "For example, an Automatic Call Distribution (ACD)/Ca= ll center application
> =A0 =A0 =A0 that utilizes the entry prior to the first History-Info en= try with an
> =A0 =A0 =A0 hi-target value of "mp", ..."
> =A0Do you mean the entry with the index that matches the first History= -Info entry with an hi-target value of "mp"? (instead of the prio= r)

I will let Mary answer this one..
[MB] =A0 Yes -= that needs to be fixed. [/MB]

Regards
=A0Shida

>
> 7- Appendix B.2 and B.3: what is the "p=3Dx" in the URI?
=
[MB] That was intended to represent a privacy= header of "x", with x being any value for the privacy header wit= h "history". However, there is no compact form for the privacy he= ader, so really we should just show it inline as we did in an earlier versi= on. The gist of that call flow was to show that rather than remove the entr= ies they are now anonymized when they go outside the domain responsible for= the Request-URI. [/MB].
=A0
>
> Cheers,
> Marianne
>
> -----Message d'origine-----
> De : sipcore-bounces@ietf.= org [mailto:sipcore-bounces= @ietf.org] De la part de Mary Barnes
> Envoy=E9 : jeudi 1 juillet 2010 21:31
> =C0 : SIPCORE
> Objet : Re: [sipcore] Updated 4244bis and new call flow document
>
> Hi folks,
>
> I have not seen any responses to this email. So, either folks don'= t see any issues with the documents and 4244bis is ready for WGLC or folks = have not reviewed the documents. =A0I'm happy to assume the former, how= ever, it would be good for folks that have read the docs to post a note on = the mailing list as to whether they think =A04244bis is ready for WGLC. =A0= And, if not, please detail your concerns, so that we can determine whether = they warrant discussion in Maastricht.
>
> Also, opinions on how/where to progress the call flow document would b= e welcome. =A0I personally do not think it's worthwhile to pursue this = in DISPATCH, but it's not clear to me whether informational docs like t= his are under the purview of the SIPCORE charter. =A0Since BLISS is trying = to close down, it is also not appropriate to pursue the work there.
>
> Thanks,
> Mary.
>
> On Thu, Jun 24, 2010 at 3:11 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
>> Hi folks,
>>
>> The 4244bis draft has been updated and a separate call flow docume= nt
>> created per the earlier summary of proposed changes:
>> http://www.ietf.org/mail-archive/web/sipcore= /current/msg02647.html
>>
>> http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bi= s-01.txt
>> http://www.ietf.org/id/draft-barnes-sipc= ore-rfc4244bis-callflows-00.tx
>> t
>>
>> There are =A0two voicemail examples in the new call flow document.= =A0The
>> 4244bis has 3 call flows - the basic sequential forking and two >> privacy examples. All the rest are now in the call flow document.<= br> >>
>> The other changes we made were updates to the UAC, UAS and applica= tion
>> considerations section - adding additional text as to how the UAC = and
>> UAS process hi-entries (including related to responses). =A0The >> application considerations section now describes how the tags can = be
>> used to derive specific information and the past guidelines were >> removed since 4244bis has much definitive guidance on the normativ= e
>> aspects of the header (i.e., SHOULDs replaced with MUSTs, privacy = via
>> anonymization rather than removing entries, etc.) as summarized in=
>> Section 11.
>>
>> Please review and provide any additional comments. We believe that=
>> 4244bis is pretty much ready to go. We can fine tune the details i= n
>> the call flows and should be able to get that ready very soon, as<= br> >> well. =A0Let us know if you see additional use cases you would lik= e to
>> add.
>>
>> Thanks,
>> Mary et al
>>
> _______________________________________________
> 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


--001485e0e55894cfd7048c45a5a6-- From rbarnes@bbn.com Mon Jul 26 00:59:57 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 476643A69E1 for ; Mon, 26 Jul 2010 00:59:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.449 X-Spam-Level: X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[AWL=0.150, 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 ks5mHDVhi32q for ; Mon, 26 Jul 2010 00:59:56 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 4BC143A687D for ; Mon, 26 Jul 2010 00:59:56 -0700 (PDT) Received: from [128.89.252.241] (port=49747 helo=dhcp-22e1.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OdIbg-0005fd-Mw; Mon, 26 Jul 2010 04:00:17 -0400 Message-Id: From: "Richard L. Barnes" To: "Elwell, John" 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 v936) Date: Mon, 26 Jul 2010 10:00:14 +0200 References: <201007122355.o6CNt6us024310@sj-core-3.cisco.com> <201007251333.o6PDXUS7019180@rtp-core-1.cisco.com> X-Mailer: Apple Mail (2.936) Cc: "sipcore@ietf.org" Subject: Re: [sipcore] location-conveyance-03 just 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: Mon, 26 Jul 2010 07:59:57 -0000 In addition, the proper reference is RFC 5808, which specifies requirements for location dereference mechanisms. On Jul 25, 2010, at 4:07 PM, Elwell, John wrote: >>> Unrelated to the above, concerning the text: >>> "Other URI schemas used in the location URI MUST be reviewed against >>> the RFC 3693 [RFC3693] criteria for a Using Protocol" >>> Who must review? The protocol implementer? How is this testable? >> >> The Geopriv "Using Protocol" is from the original requirements doc >> from SIPPING, which is now the appendix here. It comes from RFC 3693, >> which Geopriv is going to revise eventually with their Geopriv Arch >> ID, that removes the use of this term. Geopriv Arch is only an >> update to 3693, and not a replacement, meaning 3693 will remain >> actively appropriate, so I'm kinda caught with which to align with. > [JRE] Notwithstanding the question of whether we make use of the > term "Using Protocol" or some other term, this doesn't address my > concern. The present text uses the passive voice, and therefore > doesn't make it clear who must review. > > John > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore From mary.ietf.barnes@gmail.com Mon Jul 26 01:22:45 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id F2BE33A6885 for ; Mon, 26 Jul 2010 01:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.359 X-Spam-Level: X-Spam-Status: No, score=-2.359 tagged_above=-999 required=5 tests=[AWL=0.239, 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 fR-4mdYluoNQ for ; Mon, 26 Jul 2010 01:22:43 -0700 (PDT) Received: from mail-iw0-f172.google.com (mail-iw0-f172.google.com [209.85.214.172]) by core3.amsl.com (Postfix) with ESMTP id D928A3A6859 for ; Mon, 26 Jul 2010 01:22:42 -0700 (PDT) Received: by iwn38 with SMTP id 38so2799464iwn.31 for ; Mon, 26 Jul 2010 01:23:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=OEETQ0T3+EP89HsYb0SRIpXAC/uYKmolN3vn/bHmMrI=; b=ve4S6pKNO3QQknGIQqnapHJzwV8Yx05xAkJaqcqc8hbyHQMuhDFSHWigcl5nGuNd0W oqQPWCMDyzsns+THewdae67r4SiFewzHZGoO0sxcm1llwQNzXvLCOo8OsjwI8XYKEcCm gTBN3txaCvMBup7HHrYM3O6ukincQvhYyq9jY= 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=NoWbP7T6aMtTHtI+aEbAgkJA3mFnCsTjDBQiDuEtAoB/YBg0BPqIl0j8sqmi1fz4MV /PcOGsq8DH5kvfwjFC9sDMxU64zvqDuMmoH/PCrsDrel8mMDcqnu/TK4JEGUMvoYhHPS 0A/d7XfZ8LMJB+2mMXqZ/YQ5V8RpMQdCVyJUM= MIME-Version: 1.0 Received: by 10.231.172.83 with SMTP id k19mr8478318ibz.114.1280132583177; Mon, 26 Jul 2010 01:23:03 -0700 (PDT) Received: by 10.231.169.14 with HTTP; Mon, 26 Jul 2010 01:23:03 -0700 (PDT) In-Reply-To: <9886E5FCA6D76549A3011068483A4BD4065E732E@S4DE8PSAAQB.mitte.t-com.de> References: <9886E5FCA6D76549A3011068483A4BD4065E732E@S4DE8PSAAQB.mitte.t-com.de> Date: Mon, 26 Jul 2010 03:23:03 -0500 Message-ID: From: Mary Barnes To: R.Jesske@telekom.de Content-Type: multipart/alternative; boundary=0050450159cfe2be67048c4617b5 Cc: sipcore@ietf.org Subject: Re: [sipcore] Updated 4244bis and new call flow document X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 26 Jul 2010 08:22:45 -0000 --0050450159cfe2be67048c4617b5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Roland, That sentence is written within the context of core RFC 3261. We really didn't get into the RFC 3325 trust domain concept in RFC 4244 - in particular because RFC 3325 is informational. However, there is an UNLESS later in that section: "...,unless the processing entity knows a priori that it can rely on a downstream processing entity within its domain to apply the requested privacy or local policy allows the forwarding." So, I will include that same clause in the sentence you are concerned about= . Thanks, Mary. On Fri, Jul 23, 2010 at 4:15 AM, wrote: > Hi Mary, > With regard to your question for comments/review, I went thought the draf= t. > > For http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-01.txt > > I have the following comments: > > > 6.3.2. Privacy in the History-Info Header > > ... > If the requestor has indicated a priv- > value of "session" or "header" in the request, all History-Info > entries MUST be anonymized when the request leaves a domain for which > the intermediary is responsible. > ... > > In this section it is mentioned that the entries must be anonymized when > leaving the domain. I thought that if a trust relationship between domain= s > are existing and the following domain secures the "privacy" then the > information could be forwarded and will then deleted by the succeeding > domain before reaching the terminating user. > Some regulators are requesting to pass identities until the last domain > where it is possible to execute the privacy regarding RFC3323. So I think > this is a MAY based on domain policy. And it is a MUST when the succeedin= g > network cannot guarantee the privacy. > > Or do I misunderstand the meaning of "domain for which the intermediary i= s > responsible" > > > The Rest of the document looks good for me. > > Best Regards > > Roland > > > Deutsche Telekom Netzproduktion GmbH > Fixed Mobile Engineering Deutschland > Roland Jesske > Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt > +49 6151 628-2766 (Tel.) > +49 521 9210-3753 (Fax) > +49 171 8618-445 (Mobil) > E-Mail: r.jesske@telekom.de > www.telekom.com > > Erleben, was verbindet. > > Deutsche Telekom Netzproduktion GmbH > Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender) > Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mat= heis, > Klaus Peren > Handelsregister: Amtsgericht Bonn HRB 14190 > Sitz der Gesellschaft: Bonn > USt-IdNr. DE 814645262 > > Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht je= de > E-Mail drucken. > > > -----Urspr=FCngliche Nachricht----- > Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] Im Auftra= g > von Mary Barnes > Gesendet: Donnerstag, 1. Juli 2010 21:31 > An: SIPCORE > Betreff: Re: [sipcore] Updated 4244bis and new call flow document > > Hi folks, > > I have not seen any responses to this email. So, either folks don't > see any issues with the documents and 4244bis is ready for WGLC or > folks have not reviewed the documents. I'm happy to assume the > former, however, it would be good for folks that have read the docs to > post a note on the mailing list as to whether they think 4244bis is > ready for WGLC. And, if not, please detail your concerns, so that we > can determine whether they warrant discussion in Maastricht. > > Also, opinions on how/where to progress the call flow document would > be welcome. I personally do not think it's worthwhile to pursue this > in DISPATCH, but it's not clear to me whether informational docs like > this are under the purview of the SIPCORE charter. Since BLISS is > trying to close down, it is also not appropriate to pursue the work > there. > > Thanks, > Mary. > > On Thu, Jun 24, 2010 at 3:11 PM, Mary Barnes > wrote: > > Hi folks, > > > > The 4244bis draft has been updated and a separate call flow document > > created per the earlier summary of proposed changes: > > http://www.ietf.org/mail-archive/web/sipcore/current/msg02647.html > > > > http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-01.txt > > http://www.ietf.org/id/draft-barnes-sipcore-rfc4244bis-callflows-00.txt > > > > There are two voicemail examples in the new call flow document. The > > 4244bis has 3 call flows - the basic sequential forking and two > > privacy examples. All the rest are now in the call flow document. > > > > The other changes we made were updates to the UAC, UAS and application > > considerations section - adding additional text as to how the UAC and > > UAS process hi-entries (including related to responses). The > > application considerations section now describes how the tags can be > > used to derive specific information and the past guidelines were > > removed since 4244bis has much definitive guidance on the normative > > aspects of the header (i.e., SHOULDs replaced with MUSTs, privacy via > > anonymization rather than removing entries, etc.) as summarized in > > Section 11. > > > > Please review and provide any additional comments. We believe that > > 4244bis is pretty much ready to go. We can fine tune the details in > > the call flows and should be able to get that ready very soon, as > > well. Let us know if you see additional use cases you would like to > > add. > > > > Thanks, > > Mary et al > > > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore > --0050450159cfe2be67048c4617b5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Roland,

That sentence is written within the context of co= re RFC 3261. =A0We really didn't get into the RFC 3325 trust domain con= cept in RFC 4244 - in particular because RFC 3325 is informational. =A0Howe= ver, there is an UNLESS later in that section:
"...,unless the processing entity knows a priori that =
it can rely on a downstream processing entity within its domain to apply th=
e requested privacy or local policy allows the forwarding."



So, I will include that same clause in the sentenc=
e you are concerned about.



Thanks,
Mary.


On Fri, Jul 23, 2010 at 4:15 AM= , <R.Jesske@te= lekom.de> wrote:
Hi Mary,
With regard to your question for comments/review, I went thought the draft.=

For http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-01.= txt

I have the following comments:


6.3.2. =A0Privacy in the History-Info Header

...
If the requestor has indicated a priv-
=A0 value of "session" or "header" in the request, all= History-Info
=A0 entries MUST be anonymized when the request leaves a domain for which<= br> =A0 the intermediary is responsible.
...

In this section it is mentioned that the entries must be anonymized when le= aving the domain. I thought that if a trust relationship between domains ar= e existing and the following domain secures the "privacy" then th= e information could be forwarded and will then deleted by the succeeding do= main before reaching the terminating user.
Some regulators are requesting to pass identities until the last domain whe= re it is possible to execute the privacy regarding RFC3323. So I think this= is a MAY based on domain policy. And it is a MUST when the succeeding netw= ork cannot guarantee the privacy.

Or do I misunderstand the meaning of "domain for which the intermediar= y is responsible"


=A0The Rest of the document looks good for me.

Best Regards

Roland


Deutsche Telekom Netzproduktion GmbH
Fixed Mobile Engineering Deutschland
Roland Jesske
Heinrich-Hertz-Stra=DFe 3-7, 64295 Darmstadt
+49 6151 628-2766 (Tel.)
+49 521 9210-3753 =A0(Fax)
+49 171 8618-445 =A0(Mobil)
E-Mail: r.jesske@telekom.de
www.telekom.com
Erleben, was verbindet.

Deutsche Telekom Netzproduktion GmbH
Aufsichtsrat: Dr. Steffen Roehn (Vorsitzender)
Gesch=E4ftsf=FChrung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Mathe= is, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr. DE 814645262

Gro=DFe Ver=E4nderungen fangen klein an - Ressourcen schonen und nicht jede= E-Mail drucken.


-----Urspr=FCngliche Nachricht-----
Von: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf= .org] Im Auftrag von Mary Barnes
Gesendet: Donnerstag, 1. Juli 2010 21:31
An: SIPCORE
Betreff: Re: [sipcore] Updated 4244bis and new call flow document

Hi folks,

I have not seen any responses to this email. So, either folks don't
see any issues with the documents and 4244bis is ready for WGLC or
folks have not reviewed the documents. =A0I'm happy to assume the
former, however, it would be good for folks that have read the docs to
post a note on the mailing list as to whether they think =A04244bis is
ready for WGLC. =A0And, if not, please detail your concerns, so that we
can determine whether they warrant discussion in Maastricht.

Also, opinions on how/where to progress the call flow document would
be welcome. =A0I personally do not think it's worthwhile to pursue this=
in DISPATCH, but it's not clear to me whether informational docs like this are under the purview of the SIPCORE charter. =A0Since BLISS is
trying to close down, it is also not appropriate to pursue the work
there.

Thanks,
Mary.

On Thu, Jun 24, 2010 at 3:11 PM, Mary Barnes <mary.ietf.barnes@gmail.com> wrote:
> Hi folks,
>
> The 4244bis draft has been updated and a separate call flow document > created per the earlier summary of proposed changes:
> http://www.ietf.org/mail-archive/web/sipcore/cur= rent/msg02647.html
>
> http://www.ietf.org/id/draft-ietf-sipcore-rfc4244bis-01= .txt
> http://www.ietf.org/id/draft-barnes-sipcore= -rfc4244bis-callflows-00.txt
>
> There are =A0two voicemail examples in the new call flow document. =A0= The
> 4244bis has 3 call flows - the basic sequential forking and two
> privacy examples. All the rest are now in the call flow document.
>
> The other changes we made were updates to the UAC, UAS and application=
> considerations section - adding additional text as to how the UAC and<= br> > UAS process hi-entries (including related to responses). =A0The
> application considerations section now describes how the tags can be > used to derive specific information and the past guidelines were
> removed since 4244bis has much definitive guidance on the normative > aspects of the header (i.e., SHOULDs replaced with MUSTs, privacy via<= br> > anonymization rather than removing entries, etc.) as summarized in
> Section 11.
>
> Please review and provide any additional comments. We believe that
> 4244bis is pretty much ready to go. We can fine tune the details in > the call flows and should be able to get that ready very soon, as
> well. =A0Let us know if you see additional use cases you would like to=
> add.
>
> Thanks,
> Mary et al
>
_______________________________________________
sipcore mailing list
sipcore@ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

--0050450159cfe2be67048c4617b5-- From john.elwell@siemens-enterprise.com Mon Jul 26 01:46:50 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 58F823A6ADB for ; Mon, 26 Jul 2010 01:46:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.681 X-Spam-Level: X-Spam-Status: No, score=-1.681 tagged_above=-999 required=5 tests=[AWL=-1.682, BAYES_50=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 IQBQ4xAkiLD1 for ; Mon, 26 Jul 2010 01:46:48 -0700 (PDT) Received: from ms04.m0019.fra.mmp.de.bt.com (m0019.fra.mmp.de.bt.com [62.180.227.30]) by core3.amsl.com (Postfix) with ESMTP id E69733A6ACF for ; Mon, 26 Jul 2010 01:46:31 -0700 (PDT) Received: from senmx11-mx ([62.134.46.9] [62.134.46.9]) by ms04.m0020.fra.mmp.de.bt.com with ESMTP id BT-MMP-962393 for sipcore@ietf.org; Mon, 26 Jul 2010 10:46:49 +0200 Received: from MCHP064A.global-ad.net (unknown [172.29.37.63]) by senmx11-mx (Server) with ESMTP id A34501EB82AB for ; Mon, 26 Jul 2010 10:46:49 +0200 (CEST) Received: from MCHP058A.global-ad.net ([172.29.37.57]) by MCHP064A.global-ad.net ([172.29.37.63]) with mapi; Mon, 26 Jul 2010 10:46:49 +0200 From: "Elwell, John" To: "sipcore@ietf.org" Date: Mon, 26 Jul 2010 10:46:48 +0200 Thread-Topic: Rough notes from today's session Thread-Index: AcssnYbSQVDgW4AbRhq3Qoq0ZQHLzQ== 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] Rough notes from today's session X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 26 Jul 2010 08:46:50 -0000 Status slides Re-invite draft about to go into last call. Security flows - issue of whether it waits for SHA-256. Cullen wants to get= the present document done, and come back to SHA-256 later if needed. Needs= to be cleared up with Security ADs. Keep-alives - more review urged. RFC3265bis - doesn't seem to be objections to changes proposed last time. Cullen had a question on flows draft accompanying RFC4424bis, whether sub-a= ddressing service should be separated out. draft-ietf-sipcore-location-conveyance-03 - Jon Peterson Keith: Believes the authors did not have WG consensus to make the changes t= hat have been made to the draft. Jon explained that this was better than no= thing, because they were too late to submit individual draft. Main issue is multiple locations. The essence of the changes made is that n= ow we have a single PIDF document, which can be composed to represent multi= ple locations if needed. Keith: Asked whether his understanding was correct, that you have to go and= fetch the PIDF document to get some of the information that previously in = the header. Martin Thompson: Concerned that people have already implemented what was pr= eviously in there. May be we just have to accept duplications between body = and header. Could say that you should compose things into a single body, bu= t keep the header information too. Jon: In the past, the mechanism was optimised to having multiple locations = in the request, which might not be such a common case. Martin: Concerned more about some of the new drafts like rough-loc - interm= ediaries inserting is more a red-herring. Having just LbyR would probably w= ork, but need to be pragmatic. Brian Rosen: Doesn't like the mechanism, not because it doesn't work, but b= ecause intermediaries will still go ahead and do what they want. Mistake to= make it so hard for intermediary to add location. Jon: The trade-off is between this and the simple case. Brian: In the 1% case, should allow intermediaries to insert. Jon: The document does provide a mechanism for this, either adding LbyR or = using 424 to get it resent with LbyR. James Polk: All the old stuff has to come back in if you allow multiplexing= in the header, as per old mechanism. Arnot????: Described enterprise use case. Also pointed out that the draft h= as been his/3GPP dependency for a long time, and is holding up release of a= frozen 3GPP release. Keith: Even if there is only one location, the header needs to provide info= rmation for an entity to know whether it needs to go and look for the locat= ion. Jon: Agree that this draft doesn't provide anything not supported in the ea= rlier draft. James Polk: We have lost the inserted-by indication. But this was only ther= e to discriminate between multiple locations, and is not needed if there is= only one location. Martin: I read it that the intermediary because UAC if it wants to insert L= byR without using the 424 mechanism. Adam: If intermediary inserts information, it does it by brute force, elimi= nating existing information. But before, it just pushed the problem down to= the UAS to decide which is valid. Brian: Reason the new mechanism won't work is that intermediary does not kn= ow anything about the accuracy of the information already there, and for li= ability reasons will not kick that out in favour of its own information. Jon: Can still do so by changing the PIDF-LO. Brian: The only change we need to make is to allow multiple values, which w= e can do without re-introducing all the old parameter. Jon: Agree it is important to distinguish who added a location, device, ser= vice, user. But information is in body. Should either be in body or in head= er, not both. Easier to go with body. Brian: Making the barrier too high. Happy to recommend composing in PIDF, b= ut will not be able to enforce this as the only method. Martin: Agree with Brian. Some discussion about different bodies relating to different targets ???? Keith: Previously all information was in header to tell you wish location y= ou might want to fetch first, which might be critical in an emergency call = situation. Jon: Don't understand how the information we could put in the header would = help this. Keith: ???? Martin: What we are looking at with multiple URIs is multiple schemes, or p= erhaps multiple targets. Keith: I believe I am losing capabilities that I had in the previous draft. Jon: Need to understand requirements in this area. Hannes: Good that we shortened document, but guess that environments that K= eith is looking at they will just put it in body. Andy while people impleme= nting it would have been focusing on near-time cases, and have not done muc= h with the header. Compromise proposed that is to restore Geolocation header that has multiple= URIs, even though we would not recommend it. Brian: All the information you need is in body. Compromise seems reasonable= . Richard: Compromise seems good. Martin: Just need to say that if you add to, you must ???? Brian: If multiple PIDFs, how do I know the difference? All in PIDF. Keith: Question of how I trust the location. Hannes: For emergency case, use what you have, ask if you want confirmation= . Jon: So I would go with this compromise, whereby if the bar is just too hig= h to compose a new PIDF, you could convey multiple locations. James: Asking about other header parameters. Jon: No, we wouldn't re-introduce those parameters. Information is in the b= ody. Martin: ???? Jon: If you take the short cut of inserting multiple locations, you lose th= e semantics that would be in a composed PIDF-LO. Keith: Not OK with the statement about being responsible - can only be resp= onsible for information you insert, not responsible for the whole set of lo= cations. Jon: That is not the case here. Jon: Need to articulate exactly what the responsibility situation is. Would= be a SHOULD NOT for adding multiple location. Jonathan Lennox: ???? Jon: Anyone unclear on what the compromise is. Nobody. Hum: All in favour of going ahead with making the changes to the document t= hat Jon has just proposed as compromise. Chair: If Keith believes there is more that needs to be accomplished, need = to bring use cases along. Issue of 424 header insertion. Proposal that an entity that inserts a locat= ion must deal with any 424 response. No objection. Content-Location issue: It seems the compromise above obviates the need to = discuss this. Issue of privacy text: Probably existing privacy text is inadequate. Martin: Enough information elsewhere, and a short amount of text might be s= ufficient, referencing what exists. Error codes issue: - Skipped Geo-URI issue: Already implicitly allowed as a form of absolute-URI. Richard: Main focus of earlier comment was in context of multiple locations= , which is covered by compromise above. Adam: Good idea to mention it if you want people to use it, else they will = think it is not allowed. James: ???? Richard: ???? James: What to do about "using protocol"? Richard: Completely sufficient just to refer to existing RFC. Martin: Present text we have about RFC 3693 doesn't relate too well to what= we have in the document at moment. Needs rewrite. Keith: Was some discussion in SIP way back about URIs. Jon: In summary, we have path forward for revision of the document. draft-ietf-sipcore-event-rate-control-03: Krisztian Kiss Proposal to go ahead with what is described on slides for Event header fiel= d in 200 OK to NOTIFY. Document would be revised quite quickly. Concerning other comments, will make changes. From Martin.Thomson@andrew.com Mon Jul 26 04:55:14 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D5FCB3A680A for ; Mon, 26 Jul 2010 04:55:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.349 X-Spam-Level: X-Spam-Status: No, score=-3.349 tagged_above=-999 required=5 tests=[AWL=-0.750, 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 Xk+4U09B49sc for ; Mon, 26 Jul 2010 04:55:14 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id EE4E33A686E for ; Mon, 26 Jul 2010 04:55:13 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:4164 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S28661517Ab0GZLze (ORCPT ); Mon, 26 Jul 2010 06:55:34 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 26 Jul 2010 06:43:54 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 26 Jul 2010 19:43:52 +0800 From: "Thomson, Martin" To: "Thomson, Martin" , "James M. Polk" , Paul Kyzivat Date: Mon, 26 Jul 2010 19:43:51 +0800 Thread-Topic: [sipcore] composition or just indirection Thread-Index: Acsr/f+IF10+DI+ZSEm+KNE7/3XQhAABbmxAACxyrhA= Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB773642@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03EB772EBB@SISPE7MB1.commscope.com> <8B0A9FCBB9832F43971E38010638454F03EB7730BA@SISPE7MB1.commscope.com> <4C459BD7.9050007@cisco.com> <8B0A9FCBB9832F43971E38010638454F03EB773153@SISPE7MB1.commscope.com> <201007251333.o6PDXUS9019180@rtp-core-1.cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: Roger Marshall , "sipcore@ietf.org" Subject: Re: [sipcore] composition or just indirection X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 26 Jul 2010 11:55:14 -0000 SSB3cm90ZTogDQo+ID4gPiINCj4gPiA+VGhlIEdlb2xvY2F0aW9uIGhlYWRlciBpZGVudGlmaWVz IGEgc291cmNlIG9mDQo+ID4gPmxvY2F0aW9uIGluZm9ybWF0aW9uLiAgVGhpcyBtaWdodCBiZSBh IFBJREYtTE8NCj4gPiA+ZG9jdW1lbnQgdGhhdCBpcyBpZGVudGlmaWVkIGJ5IHZhbHVlIG9yDQo+ ID4gPnJlZmVyZW5jZSwgb3IgYSBnZW86IFVSSSB0aGF0IGluY2x1ZGVzIGxvY2F0aW9uIGluZm9y bWF0aW9uIGRpcmVjdGx5Lg0KPiA+ID4NCj4gPiA+QSBHZW9sb2NhdGlvbiBoZWFkZXIgaW5kaWNh dGVzIHRoYXQgYSkgdGhhdCB0aGlzDQo+ID4gPmxvY2F0aW9uIGluZm9ybWF0aW9uIGlzIHNvbWVo b3cgYXBwbGljYWJsZSB0bw0KPiA+ID50aGUgZW50aXR5IHRoYXQgaW5pdGlhdGVkIHRoZSByZXF1 ZXN0IGFuZCBiKQ0KPiA+ID50aGF0IHRoaXMgbG9jYXRpb24gaW5mb3JtYXRpb24gbWlnaHQgYmUg cmVsZXZhbnQNCj4gPiA+dG8gdGhlIHByb2Nlc3Npbmcgb2YgdGhlIFNJUCByZXF1ZXN0Lg0KPiA+ ID4iDQoNClRvIHRoaXMsIGl0IGhhcyBiZWVuIHN1Z2dlc3RlZCB0aGF0IHdlIGV4cGFuZCBvbiB0 aGlzIHRvIHRoZSBmb2xsb3dpbmcgZWZmZWN0Og0KDQpUaGUgc3ViamVjdCBvZiBhIFBJREYgZG9j dW1lbnQgaXMgaWRlbnRpZmllZCBpbiB0aGUgImVudGl0eSIgYXR0cmlidXRlIG9mIHRoZSBkb2N1 bWVudCBlbGVtZW50LiAgSWYgdGhpcyBpcyBpZGVudGljYWwgdG8gdGhlIGlkZW50aXR5IHByb3Zp ZGVkIGJ5IHRoZSBVQUMgaW4gdGhlIEZyb20gaGVhZGVyIG9mIHRoZSByZXF1ZXN0LCB0aGVuIHRo ZSBQSURGLUxPIGRlc2NyaWJlcyB0aGUgbG9jYXRpb24gb2YgdGhlIFVBQy4NCg0KLS1NYXJ0aW4N Cg== From Martin.Thomson@andrew.com Mon Jul 26 06:31:03 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 112C23A6C03 for ; Mon, 26 Jul 2010 06:31:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.325 X-Spam-Level: X-Spam-Status: No, score=-3.325 tagged_above=-999 required=5 tests=[AWL=-0.726, 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 6KO9ytB5Sv9y for ; Mon, 26 Jul 2010 06:30:59 -0700 (PDT) Received: from csmailgw2.commscope.com (csmailgw2.commscope.com [198.135.207.242]) by core3.amsl.com (Postfix) with ESMTP id BF98B3A6BF2 for ; Mon, 26 Jul 2010 06:30:59 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:35122 "EHLO ACDCE7HC2.commscope.com") by csmailgw2.commscope.com with ESMTP id S342082Ab0GZNbU (ORCPT ); Mon, 26 Jul 2010 08:31:20 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 26 Jul 2010 08:26:20 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 26 Jul 2010 21:26:18 +0800 From: "Thomson, Martin" To: "sipcore@ietf.org" Date: Mon, 26 Jul 2010 21:28:15 +0800 Thread-Topic: geo URI and conveyance: conclusion? Thread-Index: AcssxmcFTrI8IGTRQDOY58NCmnbZ0A== Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB77364D@SISPE7MB1.commscope.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-cr-puzzleid: {0F6F4234-4B15-49C3-82FA-A4CB60316FC8} x-cr-hashedpuzzle: OSo= BjyK ByBV CIQZ D9Kw EWGa GCTB G8FW JRyv JayJ JniE OZCD PjoK Qvlf Rfve S6/k; 2; YQBsAGUAeABhAG4AZABlAHIALgBtAGEAeQByAGgAbwBmAGUAcgBAAG4AaQBjAC4AYQB0ADsAcwBpAHAAYwBvAHIAZQBAAGkAZQB0AGYALgBvAHIAZwA=; Sosha1_v1; 7; {0F6F4234-4B15-49C3-82FA-A4CB60316FC8}; bQBhAHIAdABpAG4ALgB0AGgAbwBtAHMAbwBuAEAAYQBuAGQAcgBlAHcALgBjAG8AbQA=; Mon, 26 Jul 2010 13:28:15 GMT; ZwBlAG8AIABVAFIASQAgAGEAbgBkACAAYwBvAG4AdgBlAHkAYQBuAGMAZQA6ACAAYwBvAG4AYwBsAHUAcwBpAG8AbgA/AA== acceptlanguage: en-US Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw2.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: Alexander Mayrhofer Subject: [sipcore] geo URI and conveyance: 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, 26 Jul 2010 13:31:03 -0000 SSBtaXNzZWQgdGhlIGNvbmNsdXNpb25zIHJlZ2FyZGluZyBnZW8gVVJJLiAgSSBnb3QgdGhlIGJp dCB3aGVyZSB3ZSBkZWNpZGVkIHRoYXQgd2UgbmVlZGVkIHRvIGhhdmUgX3NvbWVfIHRleHQsIGJ1 dCBJJ20gbm90IHN1cmUgd2hhdCB3ZSBkZWNpZGVkIHdoYXQgdGhlIHRleHQgbWlnaHQgbG9vayBs aWtlLg0KDQpIZWxwIG1lPw0K From alexander.mayrhofer@nic.at Mon Jul 26 07:05:13 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A51CF3A6981 for ; Mon, 26 Jul 2010 07:05:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.467 X-Spam-Level: X-Spam-Status: No, score=-0.467 tagged_above=-999 required=5 tests=[AWL=0.964, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UZFqVItZk+x2 for ; Mon, 26 Jul 2010 07:05:12 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by core3.amsl.com (Postfix) with ESMTP id 252093A6B80 for ; Mon, 26 Jul 2010 07:05:11 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel with XWall v3.45 ; Mon, 26 Jul 2010 16:05:31 +0200 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.0.694.0; Mon, 26 Jul 2010 16:05:31 +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, 26 Jul 2010 16:05:30 +0200 Message-ID: <8BC845943058D844ABFC73D2220D46650943B104@nics-mail.sbg.nic.at> In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03EB77364D@SISPE7MB1.commscope.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: geo URI and conveyance: conclusion? Thread-Index: AcssxmcFTrI8IGTRQDOY58NCmnbZ0AABOn+g References: <8B0A9FCBB9832F43971E38010638454F03EB77364D@SISPE7MB1.commscope.com> From: Alexander Mayrhofer To: "Thomson, Martin" , X-XWALL-BCKS: auto Subject: Re: [sipcore] geo URI and conveyance: 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, 26 Jul 2010 14:05:14 -0000 > I missed the conclusions regarding geo URI. I got the bit=20 > where we decided that we needed to have _some_ text, but I'm=20 > not sure what we decided what the text might look like. Adding "geo:" to SIP Location Conveyance was actually one of the first applications that came to my mind when i started the draft. I'm more than happy to help with the text - i'm in Maastricht for the whole week for face to face discussions. Alex From rbarnes@bbn.com Mon Jul 26 07:27:20 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E686F3A6982 for ; Mon, 26 Jul 2010 07:27:20 -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 EnML52MisqQY for ; Mon, 26 Jul 2010 07:27:19 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id A1B003A6948 for ; Mon, 26 Jul 2010 07:27:19 -0700 (PDT) Received: from [128.89.252.251] (port=51728 helo=dhcp-22e1.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OdOea-0000zU-3B; Mon, 26 Jul 2010 10:27:40 -0400 Message-Id: <3F1B4843-6FB8-40FD-AF4E-3BC8141D12C5@bbn.com> From: "Richard L. Barnes" To: Alexander Mayrhofer In-Reply-To: <8BC845943058D844ABFC73D2220D46650943B104@nics-mail.sbg.nic.at> Content-Type: multipart/alternative; boundary=Apple-Mail-4--947935964 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Jul 2010 16:27:38 +0200 References: <8B0A9FCBB9832F43971E38010638454F03EB77364D@SISPE7MB1.commscope.com> <8BC845943058D844ABFC73D2220D46650943B104@nics-mail.sbg.nic.at> X-Mailer: Apple Mail (2.936) Cc: sipcore@ietf.org, "Thomson, Martin" Subject: Re: [sipcore] geo URI and conveyance: 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, 26 Jul 2010 14:27:21 -0000 --Apple-Mail-4--947935964 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit I was afraid that Alex would notice :) The concern here is about privacy, since the geo URI scheme doesn't include GEOPRIV-like rules. In fact, the privacy part of RFC 5870 has the following text: " However, if a 'geo' URI is used in a context where it identifies the location of a Target, it becomes part of a Location Object and is therefore subject to GEOPRIV rules. Therefore, when 'geo' URIs are put into such contexts, the privacy requirements of RFC 3693 MUST be met. " So in order to use a geo URI in SIP, we would need to do something about privacy rules. The only easy approach that occurs to me is to specify fixed rules that come along with putting a GEO URI in a Geolocation header. Suggested text: " Including a "geo:" URI in a Geolocation header associates that location with the entity that originated the SIP message, making it in effect a Location Object in the terms of RFC 3693. In particular, there is a need for such location objects to have privacy rules that accompany the object. A "geo:" URI in a Geolocation header is assigned a default set of privacy rules, equivalent to the default rules in RFC 4119: o retransmission-allowed: false o retention-expires: 24 hours from time of transmission o ruleset-reference: null o note-well: null " On Jul 26, 2010, at 4:05 PM, Alexander Mayrhofer wrote: >> I missed the conclusions regarding geo URI. I got the bit >> where we decided that we needed to have _some_ text, but I'm >> not sure what we decided what the text might look like. > > Adding "geo:" to SIP Location Conveyance was actually one of the first > applications that came to my mind when i started the draft. I'm more > than happy to help with the text - i'm in Maastricht for the whole > week > for face to face discussions. > > Alex > _______________________________________________ > sipcore mailing list > sipcore@ietf.org > https://www.ietf.org/mailman/listinfo/sipcore --Apple-Mail-4--947935964 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable I was afraid that Alex would = notice :)

The concern here is about privacy, since = the geo URI scheme doesn't include GEOPRIV-like rules.  In fact, = the privacy part of RFC 5870 has the following = text:
"
However, if a 'geo' URI is used in a context = where it identifies the location of a Target, it becomes part of a Location Object and is therefore subject to GEOPRIV rules. Therefore, when 'geo' URIs are put into such contexts, the privacy requirements of RFC 3693 MUST be met.
"

So in order to use a geo URI in = SIP, we would need to do something about privacy rules.  The only = easy approach that occurs to me is to specify fixed rules that come = along with putting a GEO URI in a Geolocation header.  Suggested = text:
"
Including a "geo:" URI in a Geolocation = header associates that location with the entity that originated the SIP = message, making it in effect a Location Object in the terms of RFC 3693. = In particular, there is a need for such location objects to have privacy = rules that accompany the object.  A "geo:" URI in a Geolocation = header is assigned a default set of privacy rules, equivalent to the = default rules in RFC = 4119:
  o retransmission-allowed: = false
  o retention-expires: 24 hours from time = of transmission
  o ruleset-reference: = null
  o note-well: = null
"



On = Jul 26, 2010, at 4:05 PM, Alexander Mayrhofer wrote:

I missed the conclusions = regarding geo URI.  I got the bit
where we decided that we needed to have _some_ text, but = I'm
not sure what we decided = what the text might look like.

Adding "geo:" to SIP = Location Conveyance was actually one of the first
applications that = came to my mind when i started the draft. I'm more
than happy to help = with the text - i'm in Maastricht for the whole week
for face to face = discussions.

Alex
______________________________________________= _
sipcore mailing list
sipcore@ietf.org
https://www.ietf.= org/mailman/listinfo/sipcore

<= /body>= --Apple-Mail-4--947935964-- From Martin.Thomson@andrew.com Mon Jul 26 07:40:27 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 200E03A6953 for ; Mon, 26 Jul 2010 07:40:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.312 X-Spam-Level: X-Spam-Status: No, score=-3.312 tagged_above=-999 required=5 tests=[AWL=-0.714, 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 2vc2FRPUIsiZ for ; Mon, 26 Jul 2010 07:40:25 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 917013A68DA for ; Mon, 26 Jul 2010 07:40:11 -0700 (PDT) Received: from [10.86.20.103] ([10.86.20.103]:56131 "EHLO ACDCE7HC2.commscope.com") by csmailgw1.commscope.com with ESMTP id S28669596Ab0GZOkc (ORCPT ); Mon, 26 Jul 2010 09:40:32 -0500 Received: from SISPE7HC2.commscope.com (10.97.4.13) by ACDCE7HC2.commscope.com (10.86.20.103) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 26 Jul 2010 09:34:00 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC2.commscope.com ([fe80::58c3:2447:f977:57c3%10]) with mapi; Mon, 26 Jul 2010 22:33:57 +0800 From: "Thomson, Martin" To: "Richard L. Barnes" , Alexander Mayrhofer Date: Mon, 26 Jul 2010 22:36:09 +0800 Thread-Topic: [sipcore] geo URI and conveyance: conclusion? Thread-Index: AcsszrYU/50MmBiaQFyd96B+AGG/cQAARJeQ Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB773651@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03EB77364D@SISPE7MB1.commscope.com> <8BC845943058D844ABFC73D2220D46650943B104@nics-mail.sbg.nic.at> <3F1B4843-6FB8-40FD-AF4E-3BC8141D12C5@bbn.com> In-Reply-To: <3F1B4843-6FB8-40FD-AF4E-3BC8141D12C5@bbn.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_8B0A9FCBB9832F43971E38010638454F03EB773651SISPE7MB1comm_" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Cc: "sipcore@ietf.org" Subject: Re: [sipcore] geo URI and conveyance: 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, 26 Jul 2010 14:40:27 -0000 --_000_8B0A9FCBB9832F43971E38010638454F03EB773651SISPE7MB1comm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhhdCB3YXMgcHJlY2lzZWx5IHRoZSBzYW1lIGNvbmNsdXNpb24gdGhhdCBJIGNhbWUgdG8uICBJ dOKAmXMgbm90IGVzcGVjaWFsbHkgZmxleGlibGUgYW5kIHdlIGVudGVyIHRoZSByZWFsbSBvZiBw b2xpY3kgZGVmaW5pdGlvbiB3aGVuIHdlIGRvIHNvLiAgSSBhZHZpc2UgY2F1dGlvbi4NCg0KRnJv bTogUmljaGFyZCBMLiBCYXJuZXMgW21haWx0bzpyYmFybmVzQGJibi5jb21dDQpTZW50OiBNb25k YXksIDI2IEp1bHkgMjAxMCA0OjI4IFBNDQpUbzogQWxleGFuZGVyIE1heXJob2Zlcg0KQ2M6IFRo b21zb24sIE1hcnRpbjsgc2lwY29yZUBpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtzaXBjb3JlXSBn ZW8gVVJJIGFuZCBjb252ZXlhbmNlOiBjb25jbHVzaW9uPw0KDQpJIHdhcyBhZnJhaWQgdGhhdCBB bGV4IHdvdWxkIG5vdGljZSA6KQ0KDQpUaGUgY29uY2VybiBoZXJlIGlzIGFib3V0IHByaXZhY3ks IHNpbmNlIHRoZSBnZW8gVVJJIHNjaGVtZSBkb2Vzbid0IGluY2x1ZGUgR0VPUFJJVi1saWtlIHJ1 bGVzLiAgSW4gZmFjdCwgdGhlIHByaXZhY3kgcGFydCBvZiBSRkMgNTg3MCBoYXMgdGhlIGZvbGxv d2luZyB0ZXh0Og0KIg0KSG93ZXZlciwgaWYgYSAnZ2VvJyBVUkkgaXMgdXNlZCBpbiBhIGNvbnRl eHQgd2hlcmUgaXQgaWRlbnRpZmllcyB0aGUgbG9jYXRpb24gb2YgYSBUYXJnZXQsIGl0IGJlY29t ZXMgcGFydCBvZiBhIExvY2F0aW9uIE9iamVjdCBhbmQgaXMgdGhlcmVmb3JlIHN1YmplY3QgdG8g R0VPUFJJViBydWxlcy4gVGhlcmVmb3JlLCB3aGVuICdnZW8nIFVSSXMgYXJlIHB1dCBpbnRvIHN1 Y2ggY29udGV4dHMsIHRoZSBwcml2YWN5IHJlcXVpcmVtZW50cyBvZiBSRkMgMzY5MyBNVVNUIGJl IG1ldC4NCiINCg0KU28gaW4gb3JkZXIgdG8gdXNlIGEgZ2VvIFVSSSBpbiBTSVAsIHdlIHdvdWxk IG5lZWQgdG8gZG8gc29tZXRoaW5nIGFib3V0IHByaXZhY3kgcnVsZXMuICBUaGUgb25seSBlYXN5 IGFwcHJvYWNoIHRoYXQgb2NjdXJzIHRvIG1lIGlzIHRvIHNwZWNpZnkgZml4ZWQgcnVsZXMgdGhh dCBjb21lIGFsb25nIHdpdGggcHV0dGluZyBhIEdFTyBVUkkgaW4gYSBHZW9sb2NhdGlvbiBoZWFk ZXIuICBTdWdnZXN0ZWQgdGV4dDoNCiINCkluY2x1ZGluZyBhICJnZW86IiBVUkkgaW4gYSBHZW9s b2NhdGlvbiBoZWFkZXIgYXNzb2NpYXRlcyB0aGF0IGxvY2F0aW9uIHdpdGggdGhlIGVudGl0eSB0 aGF0IG9yaWdpbmF0ZWQgdGhlIFNJUCBtZXNzYWdlLCBtYWtpbmcgaXQgaW4gZWZmZWN0IGEgTG9j YXRpb24gT2JqZWN0IGluIHRoZSB0ZXJtcyBvZiBSRkMgMzY5My4gSW4gcGFydGljdWxhciwgdGhl cmUgaXMgYSBuZWVkIGZvciBzdWNoIGxvY2F0aW9uIG9iamVjdHMgdG8gaGF2ZSBwcml2YWN5IHJ1 bGVzIHRoYXQgYWNjb21wYW55IHRoZSBvYmplY3QuICBBICJnZW86IiBVUkkgaW4gYSBHZW9sb2Nh dGlvbiBoZWFkZXIgaXMgYXNzaWduZWQgYSBkZWZhdWx0IHNldCBvZiBwcml2YWN5IHJ1bGVzLCBl cXVpdmFsZW50IHRvIHRoZSBkZWZhdWx0IHJ1bGVzIGluIFJGQyA0MTE5Og0KICBvIHJldHJhbnNt aXNzaW9uLWFsbG93ZWQ6IGZhbHNlDQogIG8gcmV0ZW50aW9uLWV4cGlyZXM6IDI0IGhvdXJzIGZy b20gdGltZSBvZiB0cmFuc21pc3Npb24NCiAgbyBydWxlc2V0LXJlZmVyZW5jZTogbnVsbA0KICBv IG5vdGUtd2VsbDogbnVsbA0KIg0KDQoNCg0KT24gSnVsIDI2LCAyMDEwLCBhdCA0OjA1IFBNLCBB bGV4YW5kZXIgTWF5cmhvZmVyIHdyb3RlOg0KDQoNCkkgbWlzc2VkIHRoZSBjb25jbHVzaW9ucyBy ZWdhcmRpbmcgZ2VvIFVSSS4gIEkgZ290IHRoZSBiaXQNCndoZXJlIHdlIGRlY2lkZWQgdGhhdCB3 ZSBuZWVkZWQgdG8gaGF2ZSBfc29tZV8gdGV4dCwgYnV0IEknbQ0Kbm90IHN1cmUgd2hhdCB3ZSBk ZWNpZGVkIHdoYXQgdGhlIHRleHQgbWlnaHQgbG9vayBsaWtlLg0KDQpBZGRpbmcgImdlbzoiIHRv IFNJUCBMb2NhdGlvbiBDb252ZXlhbmNlIHdhcyBhY3R1YWxseSBvbmUgb2YgdGhlIGZpcnN0DQph cHBsaWNhdGlvbnMgdGhhdCBjYW1lIHRvIG15IG1pbmQgd2hlbiBpIHN0YXJ0ZWQgdGhlIGRyYWZ0 LiBJJ20gbW9yZQ0KdGhhbiBoYXBweSB0byBoZWxwIHdpdGggdGhlIHRleHQgLSBpJ20gaW4gTWFh c3RyaWNodCBmb3IgdGhlIHdob2xlIHdlZWsNCmZvciBmYWNlIHRvIGZhY2UgZGlzY3Vzc2lvbnMu DQoNCkFsZXgNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f DQpzaXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lwY29yZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBp ZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0K DQo= --_000_8B0A9FCBB9832F43971E38010638454F03EB773651SISPE7MB1comm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9VVRGLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDov L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KDQo8bWV0YSBuYW1lPUdlbmVy YXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5 bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6 MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MG1tOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNw YW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMjQ0MDYxO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9 RU4tQVUgbGluaz1ibHVlIHZsaW5rPXB1cnBsZSBzdHlsZT0nd29yZC13cmFwOiBicmVhay13b3Jk Ow0KLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOy13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hp dGUtc3BhY2UnPg0KDQo8ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYxJz5UaGF0IHdhcyBwcmVjaXNlbHkgdGhlIHNhbWUg Y29uY2x1c2lvbiB0aGF0IEkgY2FtZSB0by7CoCBJdOKAmXMgbm90DQplc3BlY2lhbGx5IGZsZXhp YmxlIGFuZCB3ZSBlbnRlciB0aGUgcmVhbG0gb2YgcG9saWN5IGRlZmluaXRpb24gd2hlbiB3ZSBk byBzby7CoA0KSSBhZHZpc2UgY2F1dGlvbi48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjxwIGNs YXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseToi Q2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KY29sb3I6IzI0NDA2MSc+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KDQo8ZGl2IHN0eWxlPSdib3JkZXI6bm9uZTtib3JkZXItbGVmdDpzb2xpZCBi bHVlIDEuNXB0O3BhZGRpbmc6MG1tIDBtbSAwbW0gNC4wcHQnPg0KDQo8ZGl2Pg0KDQo8ZGl2IHN0 eWxlPSdib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzoz LjBwdCAwbW0gMG1tIDBtbSc+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48Yj48c3BhbiBsYW5nPUVO LVVTIHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5Og0KIlRhaG9tYSIsInNhbnMt c2VyaWYiJz5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz1FTi1VUyBzdHlsZT0nZm9udC1zaXpl OjEwLjBwdDsNCmZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+IFJpY2hhcmQgTC4g QmFybmVzIFttYWlsdG86cmJhcm5lc0BiYm4uY29tXSA8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5 LCAyNiBKdWx5IDIwMTAgNDoyOCBQTTxicj4NCjxiPlRvOjwvYj4gQWxleGFuZGVyIE1heXJob2Zl cjxicj4NCjxiPkNjOjwvYj4gVGhvbXNvbiwgTWFydGluOyBzaXBjb3JlQGlldGYub3JnPGJyPg0K PGI+U3ViamVjdDo8L2I+IFJlOiBbc2lwY29yZV0gZ2VvIFVSSSBhbmQgY29udmV5YW5jZTogY29u Y2x1c2lvbj88bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+SSB3YXMgYWZyYWlkIHRoYXQgQWxleCB3b3VsZCBub3RpY2UgOik8bzpwPjwvbzpwPjwvcD4N Cg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8 L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPlRoZSBjb25jZXJuIGhlcmUgaXMg YWJvdXQgcHJpdmFjeSwgc2luY2UgdGhlIGdlbyBVUkkgc2NoZW1lDQpkb2Vzbid0IGluY2x1ZGUg R0VPUFJJVi1saWtlIHJ1bGVzLiAmbmJzcDtJbiBmYWN0LCB0aGUgcHJpdmFjeSBwYXJ0IG9mIFJG QyA1ODcwDQpoYXMgdGhlIGZvbGxvd2luZyB0ZXh0OjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4N Cg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KDQo8 L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPkhvd2V2ZXIsIGlmIGEgJ2dlbycg VVJJIGlzIHVzZWQgaW4gYSBjb250ZXh0IHdoZXJlIGl0DQppZGVudGlmaWVzIHRoZSBsb2NhdGlv biBvZiBhIFRhcmdldCwgaXQgYmVjb21lcyBwYXJ0IG9mIGEgTG9jYXRpb24gT2JqZWN0IGFuZA0K aXMgdGhlcmVmb3JlIHN1YmplY3QgdG8gR0VPUFJJViBydWxlcy4gVGhlcmVmb3JlLCB3aGVuICdn ZW8nIFVSSXMgYXJlIHB1dCBpbnRvDQpzdWNoIGNvbnRleHRzLCB0aGUgcHJpdmFjeSByZXF1aXJl bWVudHMgb2YgUkZDIDM2OTMgTVVTVCBiZSBtZXQuPG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0K DQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gY2xhc3M9YXBwbGUtc3R5bGUtc3Bh bj48c3BhbiBzdHlsZT0nZm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3Iic+JnF1b3Q7PC9zcGFuPjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNz PU1zb05vcm1hbD5TbyBpbiBvcmRlciB0byB1c2UgYSBnZW8gVVJJIGluIFNJUCwgd2Ugd291bGQg bmVlZCB0byBkbw0Kc29tZXRoaW5nIGFib3V0IHByaXZhY3kgcnVsZXMuICZuYnNwO1RoZSBvbmx5 IGVhc3kgYXBwcm9hY2ggdGhhdCBvY2N1cnMgdG8gbWUNCmlzIHRvIHNwZWNpZnkgZml4ZWQgcnVs ZXMgdGhhdCBjb21lIGFsb25nIHdpdGggcHV0dGluZyBhIEdFTyBVUkkgaW4gYQ0KR2VvbG9jYXRp b24gaGVhZGVyLiAmbmJzcDtTdWdnZXN0ZWQgdGV4dDo8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+ DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mcXVvdDs8bzpwPjwvbzpwPjwvcD4NCg0K PC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5JbmNsdWRpbmcgYSAmcXVvdDtn ZW86JnF1b3Q7IFVSSSBpbiBhIEdlb2xvY2F0aW9uIGhlYWRlcg0KYXNzb2NpYXRlcyB0aGF0IGxv Y2F0aW9uIHdpdGggdGhlIGVudGl0eSB0aGF0IG9yaWdpbmF0ZWQgdGhlIFNJUCBtZXNzYWdlLA0K bWFraW5nIGl0IGluIGVmZmVjdCBhIExvY2F0aW9uIE9iamVjdCBpbiB0aGUgdGVybXMgb2YgUkZD IDM2OTMuIEluIHBhcnRpY3VsYXIsDQp0aGVyZSBpcyBhIG5lZWQgZm9yIHN1Y2ggbG9jYXRpb24g b2JqZWN0cyB0byBoYXZlIHByaXZhY3kgcnVsZXMgdGhhdCBhY2NvbXBhbnkNCnRoZSBvYmplY3Qu ICZuYnNwO0EgJnF1b3Q7Z2VvOiZxdW90OyBVUkkgaW4gYSBHZW9sb2NhdGlvbiBoZWFkZXIgaXMg YXNzaWduZWQgYQ0KZGVmYXVsdCBzZXQgb2YgcHJpdmFjeSBydWxlcywgZXF1aXZhbGVudCB0byB0 aGUgZGVmYXVsdCBydWxlcyBpbiBSRkMgNDExOTo8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoN CjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDsmbmJzcDtvJm5ic3A7cmV0cmFuc21p c3Npb24tYWxsb3dlZDogZmFsc2U8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoN CjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDsmbmJzcDtvJm5ic3A7cmV0ZW50aW9uLWV4cGlyZXM6 IDI0IGhvdXJzIGZyb20gdGltZSBvZg0KdHJhbnNtaXNzaW9uPG86cD48L286cD48L3A+DQoNCjwv ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7Jm5ic3A7byBydWxlc2V0 LXJlZmVyZW5jZTogbnVsbDxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPiZuYnNwOyZuYnNwO28gbm90ZS13ZWxsOiBudWxsPG86cD48L286cD48 L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+JnF1b3Q7PG86cD48 L286cD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCg0KPGRpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs Pk9uIEp1bCAyNiwgMjAxMCwgYXQgNDowNSBQTSwgQWxleGFuZGVyIE1heXJob2ZlciB3cm90ZTo8 bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvcD4NCg0KPGRpdj4NCg0KPGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10 b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCc+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5JIG1p c3NlZCB0aGUgY29uY2x1c2lvbnMgcmVnYXJkaW5nIGdlbyBVUkkuICZuYnNwO0kgZ290IHRoZQ0K Yml0IDxvOnA+PC9vOnA+PC9wPg0KDQo8L2Jsb2NrcXVvdGU+DQoNCjxibG9ja3F1b3RlIHN0eWxl PSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+d2hlcmUgd2UgZGVjaWRlZCB0aGF0IHdlIG5lZWRlZCB0byBoYXZlIF9zb21lXyB0ZXh0 LCBidXQgSSdtDQo8bzpwPjwvbzpwPjwvcD4NCg0KPC9ibG9ja3F1b3RlPg0KDQo8YmxvY2txdW90 ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Jz4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPm5vdCBzdXJlIHdoYXQgd2UgZGVjaWRlZCB3aGF0IHRoZSB0ZXh0IG1pZ2h0 IGxvb2sgbGlrZS48bzpwPjwvbzpwPjwvcD4NCg0KPC9ibG9ja3F1b3RlPg0KDQo8cCBjbGFzcz1N c29Ob3JtYWw+PGJyPg0KQWRkaW5nICZxdW90O2dlbzomcXVvdDsgdG8gU0lQIExvY2F0aW9uIENv bnZleWFuY2Ugd2FzIGFjdHVhbGx5IG9uZSBvZiB0aGUNCmZpcnN0PGJyPg0KYXBwbGljYXRpb25z IHRoYXQgY2FtZSB0byBteSBtaW5kIHdoZW4gaSBzdGFydGVkIHRoZSBkcmFmdC4gSSdtIG1vcmU8 YnI+DQp0aGFuIGhhcHB5IHRvIGhlbHAgd2l0aCB0aGUgdGV4dCAtIGknbSBpbiBNYWFzdHJpY2h0 IGZvciB0aGUgd2hvbGUgd2Vlazxicj4NCmZvciBmYWNlIHRvIGZhY2UgZGlzY3Vzc2lvbnMuPGJy Pg0KPGJyPg0KQWxleDxicj4NCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fPGJyPg0Kc2lwY29yZSBtYWlsaW5nIGxpc3Q8YnI+DQo8YSBocmVmPSJtYWlsdG86 c2lwY29yZUBpZXRmLm9yZyI+c2lwY29yZUBpZXRmLm9yZzwvYT48YnI+DQpodHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+ DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoN CjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2JvZHk+DQoNCjwvaHRt bD4NCg== --_000_8B0A9FCBB9832F43971E38010638454F03EB773651SISPE7MB1comm_-- From jmpolk@cisco.com Mon Jul 26 08:10:18 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7BC5C3A68CF for ; Mon, 26 Jul 2010 08:10:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.54 X-Spam-Level: X-Spam-Status: No, score=-10.54 tagged_above=-999 required=5 tests=[AWL=0.059, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BXt-b4KYJWYD for ; Mon, 26 Jul 2010 08:10:17 -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 65B523A6A84 for ; Mon, 26 Jul 2010 08:10:17 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEANpCTUxAZnwN/2dsb2JhbACfX3GoIZpQhTYEhAg X-IronPort-AV: E=Sophos;i="4.55,261,1278288000"; d="scan'208";a="139301401" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 26 Jul 2010 15:10:38 +0000 Received: from jmpolk-wxp01.cisco.com (dhcp-10-61-108-57.cisco.com [10.61.108.57]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6QFAaa3010310; Mon, 26 Jul 2010 15:10:37 GMT Message-Id: <201007261510.o6QFAaa3010310@rtp-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 26 Jul 2010 10:10:36 -0500 To: "Thomson, Martin" , "sipcore@ietf.org" From: "James M. Polk" In-Reply-To: <8B0A9FCBB9832F43971E38010638454F03EB77364D@SISPE7MB1.comms cope.com> References: <8B0A9FCBB9832F43971E38010638454F03EB77364D@SISPE7MB1.commscope.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Alexander Mayrhofer Subject: Re: [sipcore] geo URI and conveyance: 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, 26 Jul 2010 15:10:18 -0000 At 08:28 AM 7/26/2010, Thomson, Martin wrote: >I missed the conclusions regarding geo URI. I got the bit where we >decided that we needed to have _some_ text, but I'm not sure what we >decided what the text might look like. > >Help me? I believe the agreement in the room was to explicitly avoid it (i.e., "MUST NOT appear in the Geolocation header value (i.e., locationValue)"). As it's too close to being a data-URL (per Adam). James >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From alexander.mayrhofer@nic.at Mon Jul 26 08:17:24 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id DF0253A6807 for ; Mon, 26 Jul 2010 08:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.604 X-Spam-Level: X-Spam-Status: No, score=-0.604 tagged_above=-999 required=5 tests=[AWL=0.826, BAYES_00=-2.599, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 01aVfPMYH6fq for ; Mon, 26 Jul 2010 08:17:23 -0700 (PDT) Received: from mail.sbg.nic.at (mail.sbg.nic.at [83.136.33.227]) by core3.amsl.com (Postfix) with ESMTP id 66BDE3A686E for ; Mon, 26 Jul 2010 08:17:16 -0700 (PDT) Received: from nics-exch.sbg.nic.at ([10.17.175.3]) by mail.sbg.nic.at over TLS secured channel with XWall v3.45 ; Mon, 26 Jul 2010 17:17:35 +0200 Received: from nics-mail.sbg.nic.at (10.17.175.2) by NICS-EXCH.sbg.nic.at (10.17.175.3) with Microsoft SMTP Server id 14.0.694.0; Mon, 26 Jul 2010 17:17:35 +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, 26 Jul 2010 17:17:34 +0200 Message-ID: <8BC845943058D844ABFC73D2220D46650943B128@nics-mail.sbg.nic.at> In-Reply-To: <201007261510.o6QFAaa3010310@rtp-core-2.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] geo URI and conveyance: conclusion? Thread-Index: Acss1LmFCudfXwsZTqezBRaozLkaiAAAC4GQ References: <8B0A9FCBB9832F43971E38010638454F03EB77364D@SISPE7MB1.commscope.com> <201007261510.o6QFAaa3010310@rtp-core-2.cisco.com> From: Alexander Mayrhofer To: "James M. Polk" , "Thomson, Martin" , X-XWALL-BCKS: auto Subject: Re: [sipcore] geo URI and conveyance: 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, 26 Jul 2010 15:17:24 -0000 > I believe the agreement in the room was to explicitly avoid it (i.e.,=20 > "MUST NOT appear in the Geolocation header value (i.e.,=20 > locationValue)"). As it's too close to being a data-URL (per Adam). I wasn't in the room for the discussion. But i have to disagree that the geo: URI scheme is "close to being a data-URL". While the data: URI scheme has opaque semantics by definition, the geo: URI was specifically developed to have precise and unambigious semantics associated with its components, and a lot of time was spent on this. So, if "too close to data-URL" translates into "lack of semantics", than this is definitely true for the data: scheme, but definitely not for the geo: scheme. Alex From rbarnes@bbn.com Mon Jul 26 08:47:16 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A08BE3A6C25 for ; Mon, 26 Jul 2010 08:47:16 -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 cTK0GA7DIVEF for ; Mon, 26 Jul 2010 08:47:15 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.0.80]) by core3.amsl.com (Postfix) with ESMTP id 936313A6C39 for ; Mon, 26 Jul 2010 08:47:10 -0700 (PDT) Received: from [128.89.252.234] (port=51998 helo=dhcp-22e1.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OdPtr-0002Tz-5C; Mon, 26 Jul 2010 11:47:31 -0400 Message-Id: From: "Richard L. Barnes" To: "James M. Polk" In-Reply-To: <201007261510.o6QFAaa3010310@rtp-core-2.cisco.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Jul 2010 17:47:26 +0200 References: <8B0A9FCBB9832F43971E38010638454F03EB77364D@SISPE7MB1.commscope.com> <201007261510.o6QFAaa3010310@rtp-core-2.cisco.com> X-Mailer: Apple Mail (2.936) Cc: Alexander Mayrhofer , "sipcore@ietf.org" , "Thomson, Martin" Subject: Re: [sipcore] geo URI and conveyance: 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, 26 Jul 2010 15:47:16 -0000 I wouldn't say it was explicitly ruled out. We just noticed that it was inconsistent with the requirements RFC 3693/5808 in this context. What we're discussing now is how to make GEO URIs satisfy those requirements. On Jul 26, 2010, at 5:10 PM, James M. Polk wrote: > At 08:28 AM 7/26/2010, Thomson, Martin wrote: >> I missed the conclusions regarding geo URI. I got the bit where we >> decided that we needed to have _some_ text, but I'm not sure what >> we decided what the text might look like. >> >> Help me? > > I believe the agreement in the room was to explicitly avoid it > (i.e., "MUST NOT appear in the Geolocation header value (i.e., > locationValue)"). As it's too close to being a data-URL (per Adam). > > James > >> _______________________________________________ >> 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 jmpolk@cisco.com Mon Jul 26 09:02:35 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 05CFB3A6948 for ; Mon, 26 Jul 2010 09:02:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.545 X-Spam-Level: X-Spam-Status: No, score=-10.545 tagged_above=-999 required=5 tests=[AWL=0.054, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GqsamK7HGtcb for ; Mon, 26 Jul 2010 09:02:34 -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 E0BCA3A6880 for ; Mon, 26 Jul 2010 09:02:33 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,262,1278288000"; d="scan'208";a="139324253" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 26 Jul 2010 16:02:54 +0000 Received: from jmpolk-wxp01.cisco.com (dhcp-10-61-108-57.cisco.com [10.61.108.57]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6QG2rhx002347; Mon, 26 Jul 2010 16:02:54 GMT Message-Id: <201007261602.o6QG2rhx002347@rtp-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Mon, 26 Jul 2010 11:02:53 -0500 To: "Richard L. Barnes" , "James M. Polk" From: "James M. Polk" In-Reply-To: References: <8B0A9FCBB9832F43971E38010638454F03EB77364D@SISPE7MB1.commscope.com> <201007261510.o6QFAaa3010310@rtp-core-2.cisco.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Alexander Mayrhofer , "sipcore@ietf.org" , "Thomson, Martin" Subject: Re: [sipcore] geo URI and conveyance: 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, 26 Jul 2010 16:02:35 -0000 I'm not fighting you, but that's not how I remember the exchange between Jon and Adam. james At 10:47 AM 7/26/2010, Richard L. Barnes wrote: >I wouldn't say it was explicitly ruled out. We just noticed that it >was inconsistent with the requirements RFC 3693/5808 in this context. >What we're discussing now is how to make GEO URIs satisfy those >requirements. > > > >On Jul 26, 2010, at 5:10 PM, James M. Polk wrote: > >>At 08:28 AM 7/26/2010, Thomson, Martin wrote: >>>I missed the conclusions regarding geo URI. I got the bit where we >>>decided that we needed to have _some_ text, but I'm not sure what >>>we decided what the text might look like. >>> >>>Help me? >> >>I believe the agreement in the room was to explicitly avoid it >>(i.e., "MUST NOT appear in the Geolocation header value (i.e., >>locationValue)"). As it's too close to being a data-URL (per Adam). >> >>James >> >>>_______________________________________________ >>>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 rbarnes@bbn.com Mon Jul 26 09:07:31 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 08FE23A6900 for ; Mon, 26 Jul 2010 09:07:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.513 X-Spam-Level: X-Spam-Status: No, score=-2.513 tagged_above=-999 required=5 tests=[AWL=0.085, 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 psQCbJZcX7LY for ; Mon, 26 Jul 2010 09:07:27 -0700 (PDT) Received: from smtp.bbn.com (smtp.bbn.com [128.33.1.81]) by core3.amsl.com (Postfix) with ESMTP id 0C8333A682F for ; Mon, 26 Jul 2010 09:07:26 -0700 (PDT) Received: from [128.89.252.234] (port=52082 helo=dhcp-22e1.meeting.ietf.org) by smtp.bbn.com with esmtp (Exim 4.71 (FreeBSD)) (envelope-from ) id 1OdQDS-000CDE-F0; Mon, 26 Jul 2010 12:07:47 -0400 Message-Id: <131C4B82-812A-4193-86A7-0D66900732C6@bbn.com> From: "Richard L. Barnes" To: Alexander Mayrhofer , sipcore@ietf.org, Martin Thomson In-Reply-To: <3F1B4843-6FB8-40FD-AF4E-3BC8141D12C5@bbn.com> Content-Type: multipart/alternative; boundary=Apple-Mail-7--941930371 Mime-Version: 1.0 (Apple Message framework v936) Date: Mon, 26 Jul 2010 18:07:43 +0200 References: <8B0A9FCBB9832F43971E38010638454F03EB77364D@SISPE7MB1.commscope.com> <8BC845943058D844ABFC73D2220D46650943B104@nics-mail.sbg.nic.at> <3F1B4843-6FB8-40FD-AF4E-3BC8141D12C5@bbn.com> X-Mailer: Apple Mail (2.936) Subject: Re: [sipcore] geo URI and conveyance: 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, 26 Jul 2010 16:07:33 -0000 --Apple-Mail-7--941930371 Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit After chatting with Martin and Alex, here's another possibility: Clearly, a client that is capable of sending a GEO URI can just as well send a PIDF-LO document with the same information (in a lot more bits). So we can view the use of a GEO URI as an optimization, for those times when you don't need what PIDF-LO offers. Given that interpretation, you could basically say "use a GEO URI if you don't want any contraints, otherwise generate a PIDF-LO". Suggested text: " Clients embedding location in a SIP message by value typically do so by embedding a PIDF-LO message body and adding CID URI to the Geolocation header. In some cases, a location value can be expressed much more compactly using a GEO URI [RFC5870], namely when the following two conditions apply: 1. The location being expressed is a point (optionally with an uncertainty radius), and 2. The client does not wish to express privacy preferences. When used with the SIP Geolocation header, a GEO URI is equivalent to a PIDF-LO document with the following contents: o Entity: From address of SIP message o Location information: Point or circle equivalent to GEO URI (see [RFC5870] for translation) o Privacy rules: o retransmission-allowed: true o retention-expiry: unlimited (any date very far in the future) o ruleset-reference: null o note-well: null A client that wishes to express more restrictive privacy rules than these defaults should create a PIDF-LO document encoding these rules, and include the PIDF-LO document in the SIP message (rather than a GEO URI). " On Jul 26, 2010, at 4:27 PM, Richard L. Barnes wrote: > I was afraid that Alex would notice :) > > The concern here is about privacy, since the geo URI scheme doesn't > include GEOPRIV-like rules. In fact, the privacy part of RFC 5870 > has the following text: > " > However, if a 'geo' URI is used in a context where it identifies the > location of a Target, it becomes part of a Location Object and is > therefore subject to GEOPRIV rules. Therefore, when 'geo' URIs are > put into such contexts, the privacy requirements of RFC 3693 MUST be > met. > " > > So in order to use a geo URI in SIP, we would need to do something > about privacy rules. The only easy approach that occurs to me is to > specify fixed rules that come along with putting a GEO URI in a > Geolocation header. Suggested text: > " > Including a "geo:" URI in a Geolocation header associates that > location with the entity that originated the SIP message, making it > in effect a Location Object in the terms of RFC 3693. In particular, > there is a need for such location objects to have privacy rules that > accompany the object. A "geo:" URI in a Geolocation header is > assigned a default set of privacy rules, equivalent to the default > rules in RFC 4119: > o retransmission-allowed: false > o retention-expires: 24 hours from time of transmission > o ruleset-reference: null > o note-well: null > " > > > > On Jul 26, 2010, at 4:05 PM, Alexander Mayrhofer wrote: > >>> I missed the conclusions regarding geo URI. I got the bit >>> where we decided that we needed to have _some_ text, but I'm >>> not sure what we decided what the text might look like. >> >> Adding "geo:" to SIP Location Conveyance was actually one of the >> first >> applications that came to my mind when i started the draft. I'm more >> than happy to help with the text - i'm in Maastricht for the whole >> week >> for face to face discussions. >> >> Alex >> _______________________________________________ >> 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 --Apple-Mail-7--941930371 Content-Type: text/html; charset=US-ASCII Content-Transfer-Encoding: quoted-printable After chatting with Martin and = Alex, here's another possibility:

Clearly, a client = that is capable of sending a GEO URI can just as well send a PIDF-LO = document with the same information (in a lot more bits).  So we can = view the use of a GEO URI as an optimization, for those times when you = don't need what PIDF-LO offers.  Given  that interpretation, = you could basically say "use a GEO URI if you don't want any contraints, = otherwise generate a PIDF-LO".  Suggested = text:
"
Clients embedding location in a SIP message = by value typically do so by embedding a PIDF-LO message body and adding = CID URI to the Geolocation header.  In some cases, a location value = can be expressed much more compactly using a GEO URI [RFC5870], namely = when the following two conditions apply:
1. The location being = expressed is a point (optionally with an uncertainty radius), = and
2. The client does not wish to express privacy = preferences.
When used with the SIP Geolocation header, a GEO = URI is equivalent to a PIDF-LO document with the following = contents:
   o Entity: =46rom address of SIP = message
   o Location information: Point or circle = equivalent to GEO URI (see [RFC5870] for = translation)
   o Privacy = rules:
      o retransmission-allowed: = true
      o retention-expiry: unlimited = (any date very far in the future) 
     =  o ruleset-reference: null
      o = note-well: null
A client that wishes to express more = restrictive privacy rules than these defaults should create a PIDF-LO = document encoding these rules, and include the PIDF-LO document in the = SIP message (rather than a GEO = URI).
"



<= br>
On Jul 26, 2010, at 4:27 PM, Richard L. Barnes = wrote:

I was afraid that Alex = would notice :)

The concern here is about privacy, = since the geo URI scheme doesn't include GEOPRIV-like rules.  In = fact, the privacy part of RFC 5870 has the following = text:
"
However, if a 'geo' URI is used in a context = where it identifies the location of a Target, it becomes part of a = Location Object and is therefore subject to GEOPRIV rules. = Therefore, when 'geo' URIs are put into such contexts, the privacy = requirements of RFC 3693 MUST be met.
"

So in order to use a geo URI in = SIP, we would need to do something about privacy rules.  The only = easy approach that occurs to me is to specify fixed rules that come = along with putting a GEO URI in a Geolocation header.  Suggested = text:
"
Including a "geo:" URI in a Geolocation = header associates that location with the entity that originated the SIP = message, making it in effect a Location Object in the terms of RFC 3693. = In particular, there is a need for such location objects to have privacy = rules that accompany the object.  A "geo:" URI in a Geolocation = header is assigned a default set of privacy rules, equivalent to the = default rules in RFC = 4119:
  o retransmission-allowed: = false
  o retention-expires: 24 hours from time = of transmission
  o ruleset-reference: = null
  o note-well: = null
"



On = Jul 26, 2010, at 4:05 PM, Alexander Mayrhofer wrote:

I missed the conclusions = regarding geo URI.  I got the bit
where we decided that we needed to have _some_ text, but = I'm
not sure what we decided = what the text might look like.

Adding "geo:" to SIP = Location Conveyance was actually one of the first
applications that = came to my mind when i started the draft. I'm more
than happy to help = with the text - i'm in Maastricht for the whole week
for face to face = discussions.

Alex
______________________________________________= _
sipcore mailing list
sipcore@ietf.org
https://www.ietf.or= g/mailman/listinfo/sipcore

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

= --Apple-Mail-7--941930371-- From Martin.Thomson@andrew.com Mon Jul 26 09:11:49 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A45FC3A6C59 for ; Mon, 26 Jul 2010 09:11:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.301 X-Spam-Level: X-Spam-Status: No, score=-3.301 tagged_above=-999 required=5 tests=[AWL=-0.703, 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 v23tuG40KSml for ; Mon, 26 Jul 2010 09:11:43 -0700 (PDT) Received: from csmailgw1.commscope.com (csmailgw1.commscope.com [198.135.207.244]) by core3.amsl.com (Postfix) with ESMTP id 46F913A6C51 for ; Mon, 26 Jul 2010 09:11:42 -0700 (PDT) Received: from [10.86.20.102] ([10.86.20.102]:23463 "EHLO ACDCE7HC1.commscope.com") by csmailgw1.commscope.com with ESMTP id S28674315Ab0GZQMC (ORCPT ); Mon, 26 Jul 2010 11:12:02 -0500 Received: from SISPE7HC1.commscope.com (10.97.4.12) by ACDCE7HC1.commscope.com (10.86.20.102) with Microsoft SMTP Server (TLS) id 8.1.436.0; Mon, 26 Jul 2010 11:10:21 -0500 Received: from SISPE7MB1.commscope.com ([fe80::9d82:a492:85e3:a293]) by SISPE7HC1.commscope.com ([fe80::8a9:4724:f6bb:3cdf%10]) with mapi; Tue, 27 Jul 2010 00:10:18 +0800 From: "Thomson, Martin" To: "Richard L. Barnes" , Alexander Mayrhofer , "sipcore@ietf.org" Date: Tue, 27 Jul 2010 00:12:28 +0800 Thread-Topic: [sipcore] geo URI and conveyance: conclusion? Thread-Index: Acss3LLetQ0r6p4zRGukfDfE0QrM0wAAIeYw Message-ID: <8B0A9FCBB9832F43971E38010638454F03EB773653@SISPE7MB1.commscope.com> References: <8B0A9FCBB9832F43971E38010638454F03EB77364D@SISPE7MB1.commscope.com> <8BC845943058D844ABFC73D2220D46650943B104@nics-mail.sbg.nic.at> <3F1B4843-6FB8-40FD-AF4E-3BC8141D12C5@bbn.com> <131C4B82-812A-4193-86A7-0D66900732C6@bbn.com> In-Reply-To: <131C4B82-812A-4193-86A7-0D66900732C6@bbn.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_8B0A9FCBB9832F43971E38010638454F03EB773653SISPE7MB1comm_" MIME-Version: 1.0 X-BCN: Meridius 1000 Version 3.4 on csmailgw1.commscope.com X-BCN-Sender: Martin.Thomson@andrew.com Subject: Re: [sipcore] geo URI and conveyance: 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, 26 Jul 2010 16:11:49 -0000 --_000_8B0A9FCBB9832F43971E38010638454F03EB773653SISPE7MB1comm_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QSBwc2V1ZG9ueW0gd291bGQgc3VmZmljZSBmb3IgdGhlIGVudGl0eS4gIFRoZXJlIGlzIG5vIG5l ZWQgdG8gc2F5IHRoYXQgdGhlIGVudGl0eSBpZGVudGlmaWVkIGluIHRoZSBGcm9tIGhlYWRlciBp cyBhdCB0aGF0IGxvY2F0aW9uLCBvbmx5IHRoYXQgdGhlIGxvY2F0aW9uIGlzIHJlbGV2YW50IHRv IHRoZSByZXF1ZXN0Lg0KDQotLU1hcnRpbg0KDQpGcm9tOiBSaWNoYXJkIEwuIEJhcm5lcyBbbWFp bHRvOnJiYXJuZXNAYmJuLmNvbV0NClNlbnQ6IE1vbmRheSwgMjYgSnVseSAyMDEwIDY6MDggUE0N ClRvOiBBbGV4YW5kZXIgTWF5cmhvZmVyOyBzaXBjb3JlQGlldGYub3JnOyBUaG9tc29uLCBNYXJ0 aW4NClN1YmplY3Q6IFJlOiBbc2lwY29yZV0gZ2VvIFVSSSBhbmQgY29udmV5YW5jZTogY29uY2x1 c2lvbj8NCg0KQWZ0ZXIgY2hhdHRpbmcgd2l0aCBNYXJ0aW4gYW5kIEFsZXgsIGhlcmUncyBhbm90 aGVyIHBvc3NpYmlsaXR5Og0KDQpDbGVhcmx5LCBhIGNsaWVudCB0aGF0IGlzIGNhcGFibGUgb2Yg c2VuZGluZyBhIEdFTyBVUkkgY2FuIGp1c3QgYXMgd2VsbCBzZW5kIGEgUElERi1MTyBkb2N1bWVu dCB3aXRoIHRoZSBzYW1lIGluZm9ybWF0aW9uIChpbiBhIGxvdCBtb3JlIGJpdHMpLiAgU28gd2Ug Y2FuIHZpZXcgdGhlIHVzZSBvZiBhIEdFTyBVUkkgYXMgYW4gb3B0aW1pemF0aW9uLCBmb3IgdGhv c2UgdGltZXMgd2hlbiB5b3UgZG9uJ3QgbmVlZCB3aGF0IFBJREYtTE8gb2ZmZXJzLiAgR2l2ZW4g IHRoYXQgaW50ZXJwcmV0YXRpb24sIHlvdSBjb3VsZCBiYXNpY2FsbHkgc2F5ICJ1c2UgYSBHRU8g VVJJIGlmIHlvdSBkb24ndCB3YW50IGFueSBjb250cmFpbnRzLCBvdGhlcndpc2UgZ2VuZXJhdGUg YSBQSURGLUxPIi4gIFN1Z2dlc3RlZCB0ZXh0Og0KIg0KQ2xpZW50cyBlbWJlZGRpbmcgbG9jYXRp b24gaW4gYSBTSVAgbWVzc2FnZSBieSB2YWx1ZSB0eXBpY2FsbHkgZG8gc28gYnkgZW1iZWRkaW5n IGEgUElERi1MTyBtZXNzYWdlIGJvZHkgYW5kIGFkZGluZyBDSUQgVVJJIHRvIHRoZSBHZW9sb2Nh dGlvbiBoZWFkZXIuICBJbiBzb21lIGNhc2VzLCBhIGxvY2F0aW9uIHZhbHVlIGNhbiBiZSBleHBy ZXNzZWQgbXVjaCBtb3JlIGNvbXBhY3RseSB1c2luZyBhIEdFTyBVUkkgW1JGQzU4NzBdLCBuYW1l bHkgd2hlbiB0aGUgZm9sbG93aW5nIHR3byBjb25kaXRpb25zIGFwcGx5Og0KMS4gVGhlIGxvY2F0 aW9uIGJlaW5nIGV4cHJlc3NlZCBpcyBhIHBvaW50IChvcHRpb25hbGx5IHdpdGggYW4gdW5jZXJ0 YWludHkgcmFkaXVzKSwgYW5kDQoyLiBUaGUgY2xpZW50IGRvZXMgbm90IHdpc2ggdG8gZXhwcmVz cyBwcml2YWN5IHByZWZlcmVuY2VzLg0KV2hlbiB1c2VkIHdpdGggdGhlIFNJUCBHZW9sb2NhdGlv biBoZWFkZXIsIGEgR0VPIFVSSSBpcyBlcXVpdmFsZW50IHRvIGEgUElERi1MTyBkb2N1bWVudCB3 aXRoIHRoZSBmb2xsb3dpbmcgY29udGVudHM6DQogICBvIEVudGl0eTogRnJvbSBhZGRyZXNzIG9m IFNJUCBtZXNzYWdlDQogICBvIExvY2F0aW9uIGluZm9ybWF0aW9uOiBQb2ludCBvciBjaXJjbGUg ZXF1aXZhbGVudCB0byBHRU8gVVJJIChzZWUgW1JGQzU4NzBdIGZvciB0cmFuc2xhdGlvbikNCiAg IG8gUHJpdmFjeSBydWxlczoNCiAgICAgIG8gcmV0cmFuc21pc3Npb24tYWxsb3dlZDogdHJ1ZQ0K ICAgICAgbyByZXRlbnRpb24tZXhwaXJ5OiB1bmxpbWl0ZWQgKGFueSBkYXRlIHZlcnkgZmFyIGlu IHRoZSBmdXR1cmUpDQogICAgICBvIHJ1bGVzZXQtcmVmZXJlbmNlOiBudWxsDQogICAgICBvIG5v dGUtd2VsbDogbnVsbA0KQSBjbGllbnQgdGhhdCB3aXNoZXMgdG8gZXhwcmVzcyBtb3JlIHJlc3Ry aWN0aXZlIHByaXZhY3kgcnVsZXMgdGhhbiB0aGVzZSBkZWZhdWx0cyBzaG91bGQgY3JlYXRlIGEg UElERi1MTyBkb2N1bWVudCBlbmNvZGluZyB0aGVzZSBydWxlcywgYW5kIGluY2x1ZGUgdGhlIFBJ REYtTE8gZG9jdW1lbnQgaW4gdGhlIFNJUCBtZXNzYWdlIChyYXRoZXIgdGhhbiBhIEdFTyBVUkkp Lg0KIg0KDQoNCg0KDQpPbiBKdWwgMjYsIDIwMTAsIGF0IDQ6MjcgUE0sIFJpY2hhcmQgTC4gQmFy bmVzIHdyb3RlOg0KDQoNCkkgd2FzIGFmcmFpZCB0aGF0IEFsZXggd291bGQgbm90aWNlIDopDQoN ClRoZSBjb25jZXJuIGhlcmUgaXMgYWJvdXQgcHJpdmFjeSwgc2luY2UgdGhlIGdlbyBVUkkgc2No ZW1lIGRvZXNuJ3QgaW5jbHVkZSBHRU9QUklWLWxpa2UgcnVsZXMuICBJbiBmYWN0LCB0aGUgcHJp dmFjeSBwYXJ0IG9mIFJGQyA1ODcwIGhhcyB0aGUgZm9sbG93aW5nIHRleHQ6DQoiDQpIb3dldmVy LCBpZiBhICdnZW8nIFVSSSBpcyB1c2VkIGluIGEgY29udGV4dCB3aGVyZSBpdCBpZGVudGlmaWVz IHRoZSBsb2NhdGlvbiBvZiBhIFRhcmdldCwgaXQgYmVjb21lcyBwYXJ0IG9mIGEgTG9jYXRpb24g T2JqZWN0IGFuZCBpcyB0aGVyZWZvcmUgc3ViamVjdCB0byBHRU9QUklWIHJ1bGVzLiBUaGVyZWZv cmUsIHdoZW4gJ2dlbycgVVJJcyBhcmUgcHV0IGludG8gc3VjaCBjb250ZXh0cywgdGhlIHByaXZh Y3kgcmVxdWlyZW1lbnRzIG9mIFJGQyAzNjkzIE1VU1QgYmUgbWV0Lg0KIg0KDQpTbyBpbiBvcmRl ciB0byB1c2UgYSBnZW8gVVJJIGluIFNJUCwgd2Ugd291bGQgbmVlZCB0byBkbyBzb21ldGhpbmcg YWJvdXQgcHJpdmFjeSBydWxlcy4gIFRoZSBvbmx5IGVhc3kgYXBwcm9hY2ggdGhhdCBvY2N1cnMg dG8gbWUgaXMgdG8gc3BlY2lmeSBmaXhlZCBydWxlcyB0aGF0IGNvbWUgYWxvbmcgd2l0aCBwdXR0 aW5nIGEgR0VPIFVSSSBpbiBhIEdlb2xvY2F0aW9uIGhlYWRlci4gIFN1Z2dlc3RlZCB0ZXh0Og0K Ig0KSW5jbHVkaW5nIGEgImdlbzoiIFVSSSBpbiBhIEdlb2xvY2F0aW9uIGhlYWRlciBhc3NvY2lh dGVzIHRoYXQgbG9jYXRpb24gd2l0aCB0aGUgZW50aXR5IHRoYXQgb3JpZ2luYXRlZCB0aGUgU0lQ IG1lc3NhZ2UsIG1ha2luZyBpdCBpbiBlZmZlY3QgYSBMb2NhdGlvbiBPYmplY3QgaW4gdGhlIHRl cm1zIG9mIFJGQyAzNjkzLiBJbiBwYXJ0aWN1bGFyLCB0aGVyZSBpcyBhIG5lZWQgZm9yIHN1Y2gg bG9jYXRpb24gb2JqZWN0cyB0byBoYXZlIHByaXZhY3kgcnVsZXMgdGhhdCBhY2NvbXBhbnkgdGhl IG9iamVjdC4gIEEgImdlbzoiIFVSSSBpbiBhIEdlb2xvY2F0aW9uIGhlYWRlciBpcyBhc3NpZ25l ZCBhIGRlZmF1bHQgc2V0IG9mIHByaXZhY3kgcnVsZXMsIGVxdWl2YWxlbnQgdG8gdGhlIGRlZmF1 bHQgcnVsZXMgaW4gUkZDIDQxMTk6DQogIG8gcmV0cmFuc21pc3Npb24tYWxsb3dlZDogZmFsc2UN CiAgbyByZXRlbnRpb24tZXhwaXJlczogMjQgaG91cnMgZnJvbSB0aW1lIG9mIHRyYW5zbWlzc2lv bg0KICBvIHJ1bGVzZXQtcmVmZXJlbmNlOiBudWxsDQogIG8gbm90ZS13ZWxsOiBudWxsDQoiDQoN Cg0KDQpPbiBKdWwgMjYsIDIwMTAsIGF0IDQ6MDUgUE0sIEFsZXhhbmRlciBNYXlyaG9mZXIgd3Jv dGU6DQoNCg0KSSBtaXNzZWQgdGhlIGNvbmNsdXNpb25zIHJlZ2FyZGluZyBnZW8gVVJJLiAgSSBn b3QgdGhlIGJpdA0Kd2hlcmUgd2UgZGVjaWRlZCB0aGF0IHdlIG5lZWRlZCB0byBoYXZlIF9zb21l XyB0ZXh0LCBidXQgSSdtDQpub3Qgc3VyZSB3aGF0IHdlIGRlY2lkZWQgd2hhdCB0aGUgdGV4dCBt aWdodCBsb29rIGxpa2UuDQoNCkFkZGluZyAiZ2VvOiIgdG8gU0lQIExvY2F0aW9uIENvbnZleWFu Y2Ugd2FzIGFjdHVhbGx5IG9uZSBvZiB0aGUgZmlyc3QNCmFwcGxpY2F0aW9ucyB0aGF0IGNhbWUg dG8gbXkgbWluZCB3aGVuIGkgc3RhcnRlZCB0aGUgZHJhZnQuIEknbSBtb3JlDQp0aGFuIGhhcHB5 IHRvIGhlbHAgd2l0aCB0aGUgdGV4dCAtIGknbSBpbiBNYWFzdHJpY2h0IGZvciB0aGUgd2hvbGUg d2Vlaw0KZm9yIGZhY2UgdG8gZmFjZSBkaXNjdXNzaW9ucy4NCg0KQWxleA0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCnNpcGNvcmUgbWFpbGluZyBsaXN0 DQpzaXBjb3JlQGlldGYub3JnPG1haWx0bzpzaXBjb3JlQGlldGYub3JnPg0KaHR0cHM6Ly93d3cu aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlDQoNCl9fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fDQpzaXBjb3JlIG1haWxpbmcgbGlzdA0Kc2lwY29y ZUBpZXRmLm9yZzxtYWlsdG86c2lwY29yZUBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vc2lwY29yZQ0KDQo= --_000_8B0A9FCBB9832F43971E38010638454F03EB773653SISPE7MB1comm_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PE1FVEEgSFRUUC1FUVVJVj0iQ29udGVudC1UeXBlIiBDT05URU5UPSJ0ZXh0L2h0bWw7IGNoYXJz ZXQ9VVRGLTgiPg0KPGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwi IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6 dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDov L3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDov L3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQoNCjxoZWFkPg0KDQo8bWV0YSBuYW1lPUdlbmVy YXRvciBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxMiAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8c3R5 bGU+DQo8IS0tDQogLyogRm9udCBEZWZpbml0aW9ucyAqLw0KIEBmb250LWZhY2UNCgl7Zm9udC1m YW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpA Zm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAy IDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6 MiAxMSA2IDQgMyA1IDQgNCAyIDQ7fQ0KIC8qIFN0eWxlIERlZmluaXRpb25zICovDQogcC5Nc29O b3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MG1tOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1l cyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJs aW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUt cHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7 fQ0Kc3Bhbi5hcHBsZS1zdHlsZS1zcGFuDQoJe21zby1zdHlsZS1uYW1lOmFwcGxlLXN0eWxlLXNw YW47fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMjQ0MDYxO30N Ci5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6 ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0K CW1hcmdpbjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0K CXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT4NCjwvc3R5bGU+DQo8IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCiA8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJlZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0K PC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQogPG86c2hhcGVsYXlv dXQgdjpleHQ9ImVkaXQiPg0KICA8bzppZG1hcCB2OmV4dD0iZWRpdCIgZGF0YT0iMSIgLz4NCiA8 L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQoNCjxib2R5IGxhbmc9 RU4tQVUgbGluaz1ibHVlIHZsaW5rPXB1cnBsZSBzdHlsZT0nd29yZC13cmFwOiBicmVhay13b3Jk Ow0KLXdlYmtpdC1uYnNwLW1vZGU6IHNwYWNlOy13ZWJraXQtbGluZS1icmVhazogYWZ0ZXItd2hp dGUtc3BhY2UnPg0KDQo8ZGl2IGNsYXNzPVdvcmRTZWN0aW9uMT4NCg0KPHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwi c2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYxJz5BIHBzZXVkb255bSB3b3VsZCBzdWZmaWNlIGZv ciB0aGUgZW50aXR5LiDCoFRoZXJlIGlzIG5vIG5lZWQgdG8NCnNheSB0aGF0IHRoZSBlbnRpdHkg aWRlbnRpZmllZCBpbiB0aGUgRnJvbSBoZWFkZXIgaXMgYXQgdGhhdCBsb2NhdGlvbiwgb25seQ0K dGhhdCB0aGUgbG9jYXRpb24gaXMgcmVsZXZhbnQgdG8gdGhlIHJlcXVlc3QuPG86cD48L286cD48 L3NwYW4+PC9wPg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gc3R5bGU9J2ZvbnQtc2l6ZTox MS4wcHQ7Zm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCmNvbG9yOiMyNDQwNjEn PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJp ZiI7DQpjb2xvcjojMjQ0MDYxJz4tLU1hcnRpbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCg0KPHAg Y2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5 OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQpjb2xvcjojMjQ0MDYxJz48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQoNCjxkaXYgc3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk IGJsdWUgMS41cHQ7cGFkZGluZzowbW0gMG1tIDBtbSA0LjBwdCc+DQoNCjxkaXY+DQoNCjxkaXYg c3R5bGU9J2JvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRkaW5n OjMuMHB0IDBtbSAwbW0gMG1tJz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIGxhbmc9 RU4tVVMgc3R5bGU9J2ZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6DQoiVGFob21hIiwic2Fu cy1zZXJpZiInPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5nPUVOLVVTIHN0eWxlPSdmb250LXNp emU6MTAuMHB0Ow0KZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2VyaWYiJz4gUmljaGFyZCBM LiBCYXJuZXMgW21haWx0bzpyYmFybmVzQGJibi5jb21dIDxicj4NCjxiPlNlbnQ6PC9iPiBNb25k YXksIDI2IEp1bHkgMjAxMCA2OjA4IFBNPGJyPg0KPGI+VG86PC9iPiBBbGV4YW5kZXIgTWF5cmhv ZmVyOyBzaXBjb3JlQGlldGYub3JnOyBUaG9tc29uLCBNYXJ0aW48YnI+DQo8Yj5TdWJqZWN0Ojwv Yj4gUmU6IFtzaXBjb3JlXSBnZW8gVVJJIGFuZCBjb252ZXlhbmNlOiBjb25jbHVzaW9uPzxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5BZnRlciBjaGF0 dGluZyB3aXRoIE1hcnRpbiBhbmQgQWxleCwgaGVyZSdzIGFub3RoZXINCnBvc3NpYmlsaXR5Ojxv OnA+PC9vOnA+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8 L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Q2xlYXJs eSwgYSBjbGllbnQgdGhhdCBpcyBjYXBhYmxlIG9mIHNlbmRpbmcgYSBHRU8gVVJJIGNhbg0KanVz dCBhcyB3ZWxsIHNlbmQgYSBQSURGLUxPIGRvY3VtZW50IHdpdGggdGhlIHNhbWUgaW5mb3JtYXRp b24gKGluIGEgbG90IG1vcmUNCmJpdHMpLiAmbmJzcDtTbyB3ZSBjYW4gdmlldyB0aGUgdXNlIG9m IGEgR0VPIFVSSSBhcyBhbiBvcHRpbWl6YXRpb24sIGZvciB0aG9zZQ0KdGltZXMgd2hlbiB5b3Ug ZG9uJ3QgbmVlZCB3aGF0IFBJREYtTE8gb2ZmZXJzLiAmbmJzcDtHaXZlbiAmbmJzcDt0aGF0DQpp bnRlcnByZXRhdGlvbiwgeW91IGNvdWxkIGJhc2ljYWxseSBzYXkgJnF1b3Q7dXNlIGEgR0VPIFVS SSBpZiB5b3UgZG9uJ3Qgd2FudA0KYW55IGNvbnRyYWludHMsIG90aGVyd2lzZSBnZW5lcmF0ZSBh IFBJREYtTE8mcXVvdDsuICZuYnNwO1N1Z2dlc3RlZCB0ZXh0OjxvOnA+PC9vOnA+PC9wPg0KDQo8 L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPiZxdW90OzxvOnA+PC9vOnA+PC9w Pg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPkNsaWVudHMgZW1iZWRk aW5nIGxvY2F0aW9uIGluIGEgU0lQIG1lc3NhZ2UgYnkgdmFsdWUNCnR5cGljYWxseSBkbyBzbyBi eSBlbWJlZGRpbmcgYSBQSURGLUxPIG1lc3NhZ2UgYm9keSBhbmQgYWRkaW5nIENJRCBVUkkgdG8g dGhlDQpHZW9sb2NhdGlvbiBoZWFkZXIuICZuYnNwO0luIHNvbWUgY2FzZXMsIGEgbG9jYXRpb24g dmFsdWUgY2FuIGJlIGV4cHJlc3NlZCBtdWNoDQptb3JlIGNvbXBhY3RseSB1c2luZyBhIEdFTyBV UkkgW1JGQzU4NzBdLCBuYW1lbHkgd2hlbiB0aGUgZm9sbG93aW5nIHR3bw0KY29uZGl0aW9ucyBh cHBseTo8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05v cm1hbD4xLiBUaGUgbG9jYXRpb24gYmVpbmcgZXhwcmVzc2VkIGlzIGEgcG9pbnQgKG9wdGlvbmFs bHkgd2l0aA0KYW4gdW5jZXJ0YWludHkgcmFkaXVzKSwgYW5kPG86cD48L286cD48L3A+DQoNCjwv ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Mi4gVGhlIGNsaWVudCBkb2VzIG5v dCB3aXNoIHRvIGV4cHJlc3MgcHJpdmFjeSBwcmVmZXJlbmNlcy48bzpwPjwvbzpwPjwvcD4NCg0K PC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5XaGVuIHVzZWQgd2l0aCB0aGUg U0lQIEdlb2xvY2F0aW9uIGhlYWRlciwgYSBHRU8gVVJJIGlzIGVxdWl2YWxlbnQNCnRvIGEgUElE Ri1MTyBkb2N1bWVudCB3aXRoIHRoZSBmb2xsb3dpbmcgY29udGVudHM6PG86cD48L286cD48L3A+ DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7Jm5ic3A7IG8g RW50aXR5OiBGcm9tIGFkZHJlc3Mgb2YgU0lQIG1lc3NhZ2U8bzpwPjwvbzpwPjwvcD4NCg0KPC9k aXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDsmbmJzcDsgbyBMb2NhdGlv biBpbmZvcm1hdGlvbjogUG9pbnQgb3IgY2lyY2xlDQplcXVpdmFsZW50IHRvIEdFTyBVUkkgKHNl ZSBbUkZDNTg3MF0gZm9yIHRyYW5zbGF0aW9uKTxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0K PGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPiZuYnNwOyZuYnNwOyBvIFByaXZhY3kgcnVsZXM6 PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+ Jm5ic3A7Jm5ic3A7ICZuYnNwOyAmbmJzcDtvIHJldHJhbnNtaXNzaW9uLWFsbG93ZWQ6IHRydWU8 bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4m bmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNwO28gcmV0ZW50aW9uLWV4cGlyeTogdW5saW1pdGVkIChh bnkNCmRhdGUgdmVyeSBmYXIgaW4gdGhlIGZ1dHVyZSkmbmJzcDs8bzpwPjwvbzpwPjwvcD4NCg0K PC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDsmbmJzcDsgJm5ic3A7 ICZuYnNwO28gcnVsZXNldC1yZWZlcmVuY2U6IG51bGw8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+ DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDsmbmJzcDsgJm5ic3A7ICZuYnNw O28gbm90ZS13ZWxsOiBudWxsPG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+QSBjbGllbnQgdGhhdCB3aXNoZXMgdG8gZXhwcmVzcyBtb3JlIHJl c3RyaWN0aXZlIHByaXZhY3kNCnJ1bGVzIHRoYW4gdGhlc2UgZGVmYXVsdHMgc2hvdWxkIGNyZWF0 ZSBhIFBJREYtTE8gZG9jdW1lbnQgZW5jb2RpbmcgdGhlc2UNCnJ1bGVzLCBhbmQgaW5jbHVkZSB0 aGUgUElERi1MTyBkb2N1bWVudCBpbiB0aGUgU0lQIG1lc3NhZ2UgKHJhdGhlciB0aGFuIGEgR0VP DQpVUkkpLjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNv Tm9ybWFsPiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xh c3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0K PHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8L2Rpdj4N Cg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8 ZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+T24gSnVsIDI2LCAyMDEwLCBhdCA0 OjI3IFBNLCBSaWNoYXJkIEwuIEJhcm5lcyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCg0KPGRp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPkkgd2FzIGFmcmFpZCB0aGF0IEFsZXggd291bGQgbm90 aWNlIDopPG86cD48L286cD48L3A+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD5UaGUgY29uY2VybiBoZXJlIGlzIGFib3V0IHByaXZhY3ksIHNpbmNlIHRoZSBnZW8gVVJJIHNj aGVtZQ0KZG9lc24ndCBpbmNsdWRlIEdFT1BSSVYtbGlrZSBydWxlcy4gJm5ic3A7SW4gZmFjdCwg dGhlIHByaXZhY3kgcGFydCBvZiBSRkMgNTg3MA0KaGFzIHRoZSBmb2xsb3dpbmcgdGV4dDo8bzpw PjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mcXVv dDs8bzpwPjwvbzpwPjwvcD4NCg0KPC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1h bD5Ib3dldmVyLCBpZiBhICdnZW8nIFVSSSBpcyB1c2VkIGluIGEgY29udGV4dCB3aGVyZSBpdA0K aWRlbnRpZmllcyB0aGUgbG9jYXRpb24gb2YgYSBUYXJnZXQsIGl0IGJlY29tZXMgcGFydCBvZiBh IExvY2F0aW9uIE9iamVjdCBhbmQNCmlzIHRoZXJlZm9yZSBzdWJqZWN0IHRvIEdFT1BSSVYgcnVs ZXMuIFRoZXJlZm9yZSwgd2hlbiAnZ2VvJyBVUklzIGFyZSBwdXQgaW50bw0Kc3VjaCBjb250ZXh0 cywgdGhlIHByaXZhY3kgcmVxdWlyZW1lbnRzIG9mIFJGQyAzNjkzIE1VU1QgYmUgbWV0LjxvOnA+ PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IGNsYXNzPWFwcGxlLXN0eWxlLXNwYW4+PHNwYW4gc3R5bGU9J2ZvbnQtZmFtaWx5OiJDb3VyaWVy IE5ldyInPiZxdW90Ozwvc3Bhbj48L3NwYW4+PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8 ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjwvZGl2 Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+U28gaW4gb3JkZXIgdG8gdXNlIGEgZ2Vv IFVSSSBpbiBTSVAsIHdlIHdvdWxkIG5lZWQgdG8gZG8NCnNvbWV0aGluZyBhYm91dCBwcml2YWN5 IHJ1bGVzLiAmbmJzcDtUaGUgb25seSBlYXN5IGFwcHJvYWNoIHRoYXQgb2NjdXJzIHRvIG1lDQpp cyB0byBzcGVjaWZ5IGZpeGVkIHJ1bGVzIHRoYXQgY29tZSBhbG9uZyB3aXRoIHB1dHRpbmcgYSBH RU8gVVJJIGluIGENCkdlb2xvY2F0aW9uIGhlYWRlci4gJm5ic3A7U3VnZ2VzdGVkIHRleHQ6PG86 cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+JnF1 b3Q7PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3Jt YWw+SW5jbHVkaW5nIGEgJnF1b3Q7Z2VvOiZxdW90OyBVUkkgaW4gYSBHZW9sb2NhdGlvbiBoZWFk ZXINCmFzc29jaWF0ZXMgdGhhdCBsb2NhdGlvbiB3aXRoIHRoZSBlbnRpdHkgdGhhdCBvcmlnaW5h dGVkIHRoZSBTSVAgbWVzc2FnZSwNCm1ha2luZyBpdCBpbiBlZmZlY3QgYSBMb2NhdGlvbiBPYmpl Y3QgaW4gdGhlIHRlcm1zIG9mIFJGQyAzNjkzLiBJbiBwYXJ0aWN1bGFyLA0KdGhlcmUgaXMgYSBu ZWVkIGZvciBzdWNoIGxvY2F0aW9uIG9iamVjdHMgdG8gaGF2ZSBwcml2YWN5IHJ1bGVzIHRoYXQg YWNjb21wYW55DQp0aGUgb2JqZWN0LiAmbmJzcDtBICZxdW90O2dlbzomcXVvdDsgVVJJIGluIGEg R2VvbG9jYXRpb24gaGVhZGVyIGlzIGFzc2lnbmVkIGENCmRlZmF1bHQgc2V0IG9mIHByaXZhY3kg cnVsZXMsIGVxdWl2YWxlbnQgdG8gdGhlIGRlZmF1bHQgcnVsZXMgaW4gUkZDIDQxMTk6PG86cD48 L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7 Jm5ic3A7byZuYnNwO3JldHJhbnNtaXNzaW9uLWFsbG93ZWQ6IGZhbHNlPG86cD48L286cD48L3A+ DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29Ob3JtYWw+Jm5ic3A7Jm5ic3A7byZu YnNwO3JldGVudGlvbi1leHBpcmVzOiAyNCBob3VycyBmcm9tIHRpbWUgb2YNCnRyYW5zbWlzc2lv bjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PiZuYnNwOyZuYnNwO28gcnVsZXNldC1yZWZlcmVuY2U6IG51bGw8bzpwPjwvbzpwPjwvcD4NCg0K PC9kaXY+DQoNCjxkaXY+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD4mbmJzcDsmbmJzcDtvIG5vdGUt d2VsbDogbnVsbDxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPGRpdj4NCg0KPHAgY2xhc3M9 TXNvTm9ybWFsPiZxdW90OzxvOnA+PC9vOnA+PC9wPg0KDQo8ZGl2Pg0KDQo8cCBjbGFzcz1Nc29O b3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8ZGl2Pg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+DQoNCjxkaXY+DQoNCjxkaXY+ DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5PbiBKdWwgMjYsIDIwMTAsIGF0IDQ6MDUgUE0sIEFsZXhh bmRlciBNYXlyaG9mZXIgd3JvdGU6PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8cCBjbGFz cz1Nc29Ob3JtYWw+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQoNCjxkaXY+DQoNCjxibG9j a3F1b3RlIHN0eWxlPSdtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQnPg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+SSBtaXNzZWQgdGhlIGNvbmNsdXNpb25zIHJlZ2FyZGluZyBnZW8g VVJJLiAmbmJzcDtJIGdvdCB0aGUNCmJpdCA8bzpwPjwvbzpwPjwvcD4NCg0KPC9ibG9ja3F1b3Rl Pg0KDQo8YmxvY2txdW90ZSBzdHlsZT0nbWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu MHB0Jz4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPndoZXJlIHdlIGRlY2lkZWQgdGhhdCB3ZSBuZWVk ZWQgdG8gaGF2ZSBfc29tZV8gdGV4dCwgYnV0IEknbQ0KPG86cD48L286cD48L3A+DQoNCjwvYmxv Y2txdW90ZT4NCg0KPGJsb2NrcXVvdGUgc3R5bGU9J21hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJv dHRvbTo1LjBwdCc+DQoNCjxwIGNsYXNzPU1zb05vcm1hbD5ub3Qgc3VyZSB3aGF0IHdlIGRlY2lk ZWQgd2hhdCB0aGUgdGV4dCBtaWdodCBsb29rIGxpa2UuPG86cD48L286cD48L3A+DQoNCjwvYmxv Y2txdW90ZT4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxicj4NCkFkZGluZyAmcXVvdDtnZW86JnF1 b3Q7IHRvIFNJUCBMb2NhdGlvbiBDb252ZXlhbmNlIHdhcyBhY3R1YWxseSBvbmUgb2YgdGhlDQpm aXJzdDxicj4NCmFwcGxpY2F0aW9ucyB0aGF0IGNhbWUgdG8gbXkgbWluZCB3aGVuIGkgc3RhcnRl ZCB0aGUgZHJhZnQuIEknbSBtb3JlPGJyPg0KdGhhbiBoYXBweSB0byBoZWxwIHdpdGggdGhlIHRl eHQgLSBpJ20gaW4gTWFhc3RyaWNodCBmb3IgdGhlIHdob2xlIHdlZWs8YnI+DQpmb3IgZmFjZSB0 byBmYWNlIGRpc2N1c3Npb25zLjxicj4NCjxicj4NCkFsZXg8YnI+DQpfX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCnNpcGNvcmUgbWFpbGluZyBsaXN0 PGJyPg0KPGEgaHJlZj0ibWFpbHRvOnNpcGNvcmVAaWV0Zi5vcmciPnNpcGNvcmVAaWV0Zi5vcmc8 L2E+PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9z aXBjb3JlIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL3NpcGNvcmU8L2E+ PG86cD48L286cD48L3A+DQoNCjwvZGl2Pg0KDQo8L2Rpdj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFs PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8L2Rpdj4NCg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8 cCBjbGFzcz1Nc29Ob3JtYWw+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX188YnI+DQpzaXBjb3JlIG1haWxpbmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpz aXBjb3JlQGlldGYub3JnIj5zaXBjb3JlQGlldGYub3JnPC9hPjxicj4NCjxhIGhyZWY9Imh0dHBz Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vc2lwY29yZSI+aHR0cHM6Ly93d3cuaWV0 Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9zaXBjb3JlPC9hPjxvOnA+PC9vOnA+PC9wPg0KDQo8L2Rp dj4NCg0KPHAgY2xhc3M9TXNvTm9ybWFsPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KDQo8L2Rpdj4N Cg0KPC9kaXY+DQoNCjwvZGl2Pg0KDQo8L2JvZHk+DQoNCjwvaHRtbD4NCg== --_000_8B0A9FCBB9832F43971E38010638454F03EB773653SISPE7MB1comm_-- From jgunn6@csc.com Mon Jul 26 09:43:17 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5AAB83A6ADE; Mon, 26 Jul 2010 09:43:17 -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.280, 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 VEc1Bmh9k8jd; Mon, 26 Jul 2010 09:43:16 -0700 (PDT) Received: from mail63.messagelabs.com (mail63.messagelabs.com [216.82.242.83]) by core3.amsl.com (Postfix) with ESMTP id 4B4043A6A95; Mon, 26 Jul 2010 09:42:38 -0700 (PDT) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-7.tower-63.messagelabs.com!1280162577!95616487!1 X-StarScan-Version: 6.2.4; banners=-,-,- X-Originating-IP: [20.137.2.88] Received: (qmail 30639 invoked from network); 26 Jul 2010 16:42:57 -0000 Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-7.tower-63.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 26 Jul 2010 16:42:57 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id o6QGguSB017464; Mon, 26 Jul 2010 12:42:56 -0400 In-Reply-To: References: <99619466-573D-4CEA-ACCD-3A3D262EB2B0@nostrum.com> To: Janet P Gunn MIME-Version: 1.0 X-KeepSent: 94ACB9BB:9CFE31F2-8525776C:005B6D79; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009 From: Janet P Gunn Message-ID: Date: Mon, 26 Jul 2010 12:42:49 -0400 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.1FP1 HF440|June 18, 2010) at 07/26/2010 12:43:22 PM, Serialize complete at 07/26/2010 12:43:22 PM Content-Type: multipart/alternative; boundary="=_alternative 005BD1F08525776C_=" Cc: sipcore@ietf.org, sipcore-bounces@ietf.org Subject: Re: [sipcore] AD review: draft-ietf-sipcore-event-rate-control-04 X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Core Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2010 16:43:17 -0000 This is a multipart message in MIME format. --=_alternative 005BD1F08525776C_= Content-Type: text/plain; charset="US-ASCII" Just want to address one technical issue that seems to have been missed.. Who/what sets the value of "period" for the adaptive/average mechanism? What is the range and granularity of the values for "period"? Is it set separately for every subscription? Can the subscriber change it? Or does the notifier have a single value of "period" that it uses for all subscriptions, forever? Janet This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --=_alternative 005BD1F08525776C_= Content-Type: text/html; charset="US-ASCII"
Just want to address one technical issue that seems to have been missed..


Who/what sets the value of "period" for the adaptive/average mechanism?
What is the range and granularity of the values for "period"?
Is it set separately for every subscription?
Can the subscriber change it?
Or does the notifier have a single value of "period" that it uses for all subscriptions, forever?

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose. --=_alternative 005BD1F08525776C_=-- From adam@nostrum.com Mon Jul 26 14:04:41 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 2F7103A69A4 for ; Mon, 26 Jul 2010 14:04:41 -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 uhhAfHGzHOxn for ; Mon, 26 Jul 2010 14:04:40 -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 C7F693A69E1 for ; Mon, 26 Jul 2010 14:04:39 -0700 (PDT) Received: from Svantevit.local (n158.infopact.nl [212.29.185.158]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6QL4PMi015888 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 26 Jul 2010 16:04:26 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C4DF852.7030504@nostrum.com> Date: Mon, 26 Jul 2010 23:04:18 +0200 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "James M. Polk" References: <8B0A9FCBB9832F43971E38010638454F03EB77364D@SISPE7MB1.commscope.com> <201007261510.o6QFAaa3010310@rtp-core-2.cisco.com> <201007261602.o6QG2rhx002347@rtp-core-2.cisco.com> In-Reply-To: <201007261602.o6QG2rhx002347@rtp-core-2.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 212.29.185.158 is authenticated by a trusted mechanism) Cc: Alexander Mayrhofer , "Richard L. Barnes" , "sipcore@ietf.org" , "Thomson, Martin" Subject: Re: [sipcore] geo URI and conveyance: 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, 26 Jul 2010 21:04:41 -0000 It's not entirely different from what we were talking about, but it's not the main thrust, either. At least, not with respect to the point *I* was trying to make. The analogy I was making with "data:" URLs was an attempt to debunk the notion that the syntactic use of "anyURI" somehow implicitly allowed the use of a "geo:" URI. The comparison I made was to the myriad header fields in SIP that allow any URI -- such as Alert-Info -- but for which it would be patently ridiculous to include a "data:" URL. /a On 7/26/10 6:02 PM, James M. Polk wrote: > I'm not fighting you, but that's not how I remember the exchange > between Jon and Adam. > > james > > At 10:47 AM 7/26/2010, Richard L. Barnes wrote: >> I wouldn't say it was explicitly ruled out. We just noticed that it >> was inconsistent with the requirements RFC 3693/5808 in this context. >> What we're discussing now is how to make GEO URIs satisfy those >> requirements. >> >> >> >> On Jul 26, 2010, at 5:10 PM, James M. Polk wrote: >> >>> At 08:28 AM 7/26/2010, Thomson, Martin wrote: >>>> I missed the conclusions regarding geo URI. I got the bit where we >>>> decided that we needed to have _some_ text, but I'm not sure what >>>> we decided what the text might look like. >>>> >>>> Help me? >>> >>> I believe the agreement in the room was to explicitly avoid it >>> (i.e., "MUST NOT appear in the Geolocation header value (i.e., >>> locationValue)"). As it's too close to being a data-URL (per Adam). >>> >>> James >>> >>>> _______________________________________________ >>>> 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 jmpolk@cisco.com Tue Jul 27 01:25:20 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 719723A6A6E for ; Tue, 27 Jul 2010 01:25:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.553 X-Spam-Level: X-Spam-Status: No, score=-10.553 tagged_above=-999 required=5 tests=[AWL=0.046, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LPRTPmfVlaCO for ; Tue, 27 Jul 2010 01:25:19 -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 4EFF23A6BA9 for ; Tue, 27 Jul 2010 01:25:19 -0700 (PDT) Authentication-Results: rtp-iport-1.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-AV: E=Sophos;i="4.55,266,1278288000"; d="scan'208";a="139591842" Received: from rtp-core-1.cisco.com ([64.102.124.12]) by rtp-iport-1.cisco.com with ESMTP; 27 Jul 2010 08:25:41 +0000 Received: from jmpolk-wxp01.cisco.com (dhcp-10-61-108-74.cisco.com [10.61.108.74]) by rtp-core-1.cisco.com (8.13.8/8.14.3) with ESMTP id o6R8Pd72005393; Tue, 27 Jul 2010 08:25:40 GMT Message-Id: <201007270825.o6R8Pd72005393@rtp-core-1.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 27 Jul 2010 03:25:40 -0500 To: Adam Roach , "James M. Polk" From: "James M. Polk" In-Reply-To: <4C4DF852.7030504@nostrum.com> References: <8B0A9FCBB9832F43971E38010638454F03EB77364D@SISPE7MB1.commscope.com> <201007261510.o6QFAaa3010310@rtp-core-2.cisco.com> <201007261602.o6QG2rhx002347@rtp-core-2.cisco.com> <4C4DF852.7030504@nostrum.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Cc: Alexander Mayrhofer , "Richard L. Barnes" , "sipcore@ietf.org" , "Thomson, Martin" Subject: Re: [sipcore] geo URI and conveyance: 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: Tue, 27 Jul 2010 08:25:20 -0000 Adam So what are you saying? You seems to be implying something, but I can't tell if it's what I said, what Martin said or something in between? Can you give one clarifying statement about what you understand this issue to be solved as? James At 04:04 PM 7/26/2010, Adam Roach wrote: > It's not entirely different from what we were talking about, but > it's not the main thrust, either. At least, not with respect to the > point *I* was trying to make. > >The analogy I was making with "data:" URLs was an attempt to debunk >the notion that the syntactic use of "anyURI" somehow implicitly >allowed the use of a "geo:" URI. The comparison I made was to the >myriad header fields in SIP that allow any URI -- such as Alert-Info >-- but for which it would be patently ridiculous to include a "data:" URL. > >/a > >On 7/26/10 6:02 PM, James M. Polk wrote: >>I'm not fighting you, but that's not how I remember the exchange >>between Jon and Adam. >> >>james >> >>At 10:47 AM 7/26/2010, Richard L. Barnes wrote: >>>I wouldn't say it was explicitly ruled out. We just noticed that it >>>was inconsistent with the requirements RFC 3693/5808 in this context. >>>What we're discussing now is how to make GEO URIs satisfy those >>>requirements. >>> >>> >>> >>>On Jul 26, 2010, at 5:10 PM, James M. Polk wrote: >>> >>>>At 08:28 AM 7/26/2010, Thomson, Martin wrote: >>>>>I missed the conclusions regarding geo URI. I got the bit where we >>>>>decided that we needed to have _some_ text, but I'm not sure what >>>>>we decided what the text might look like. >>>>> >>>>>Help me? >>>> >>>>I believe the agreement in the room was to explicitly avoid it >>>>(i.e., "MUST NOT appear in the Geolocation header value (i.e., >>>>locationValue)"). As it's too close to being a data-URL (per Adam). >>>> >>>>James >>>> >>>>>_______________________________________________ >>>>>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 adam@nostrum.com Tue Jul 27 01:32:24 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 7CB0B3A6A79 for ; Tue, 27 Jul 2010 01:32: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 CHx014T7zZqd for ; Tue, 27 Jul 2010 01:32:14 -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 342C53A6AE5 for ; Tue, 27 Jul 2010 01:32:01 -0700 (PDT) Received: from dhcp-23f3.meeting.ietf.org (dhcp-23f3.meeting.ietf.org [130.129.35.243]) (authenticated bits=0) by nostrum.com (8.14.3/8.14.3) with ESMTP id o6R8WC97071322 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Tue, 27 Jul 2010 03:32:14 -0500 (CDT) (envelope-from adam@nostrum.com) Message-ID: <4C4E998C.8070608@nostrum.com> Date: Tue, 27 Jul 2010 10:32:12 +0200 From: Adam Roach User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.7) Gecko/20100713 Thunderbird/3.1.1 MIME-Version: 1.0 To: "James M. Polk" References: <8B0A9FCBB9832F43971E38010638454F03EB77364D@SISPE7MB1.commscope.com> <201007261510.o6QFAaa3010310@rtp-core-2.cisco.com> <201007261602.o6QG2rhx002347@rtp-core-2.cisco.com> <4C4DF852.7030504@nostrum.com> <201007270825.o6R8Pd72005393@rtp-core-1.cisco.com> In-Reply-To: <201007270825.o6R8Pd72005393@rtp-core-1.cisco.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass (nostrum.com: 130.129.35.243 is authenticated by a trusted mechanism) Cc: Alexander Mayrhofer , "Richard L. Barnes" , "sipcore@ietf.org" , "Thomson, Martin" Subject: Re: [sipcore] geo URI and conveyance: 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: Tue, 27 Jul 2010 08:32:24 -0000 A clearer summary of what I'm trying to say: if you expect "geo:" URIs to be used in SIP location conveyance, you'll need to explicitly add text saying so. The bit about them being forbidden was based on assertions from people who know far more about geopriv than I do -- they asserted that it lacked the "priv" half of "geopriv," and therefore wasn't appropriate. Martin (or Richard, I can't recall) has proposed some ways this might be fixable, and I have no opinion on that topic. /a On 7/27/10 10:25 AM, James M. Polk wrote: > Adam > > So what are you saying? > > You seems to be implying something, but I can't tell if it's what I > said, what Martin said or something in between? > > Can you give one clarifying statement about what you understand this > issue to be solved as? > > James > > At 04:04 PM 7/26/2010, Adam Roach wrote: > >> It's not entirely different from what we were talking about, but >> it's not the main thrust, either. At least, not with respect to the >> point *I* was trying to make. >> >> The analogy I was making with "data:" URLs was an attempt to debunk >> the notion that the syntactic use of "anyURI" somehow implicitly >> allowed the use of a "geo:" URI. The comparison I made was to the >> myriad header fields in SIP that allow any URI -- such as Alert-Info >> -- but for which it would be patently ridiculous to include a "data:" >> URL. >> >> /a >> >> On 7/26/10 6:02 PM, James M. Polk wrote: >>> I'm not fighting you, but that's not how I remember the exchange >>> between Jon and Adam. >>> >>> james >>> >>> At 10:47 AM 7/26/2010, Richard L. Barnes wrote: >>>> I wouldn't say it was explicitly ruled out. We just noticed that it >>>> was inconsistent with the requirements RFC 3693/5808 in this context. >>>> What we're discussing now is how to make GEO URIs satisfy those >>>> requirements. >>>> >>>> >>>> >>>> On Jul 26, 2010, at 5:10 PM, James M. Polk wrote: >>>> >>>>> At 08:28 AM 7/26/2010, Thomson, Martin wrote: >>>>>> I missed the conclusions regarding geo URI. I got the bit where we >>>>>> decided that we needed to have _some_ text, but I'm not sure what >>>>>> we decided what the text might look like. >>>>>> >>>>>> Help me? >>>>> >>>>> I believe the agreement in the room was to explicitly avoid it >>>>> (i.e., "MUST NOT appear in the Geolocation header value (i.e., >>>>> locationValue)"). As it's too close to being a data-URL (per Adam). >>>>> >>>>> James >>>>> >>>>>> _______________________________________________ >>>>>> 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 laura.liess.dt@googlemail.com Tue Jul 27 07:18:38 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 722F33A6994 for ; Tue, 27 Jul 2010 07:18:38 -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, 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 39RcON29ixEJ for ; Tue, 27 Jul 2010 07:18:37 -0700 (PDT) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id A116A3A681F for ; Tue, 27 Jul 2010 07:18:36 -0700 (PDT) Received: by eyb7 with SMTP id 7so833252eyb.31 for ; Tue, 27 Jul 2010 07:18:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:received:received:from:to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=PoVCWiETSAGGUsxVB1Esi2aJLCowPMdjw6erO30TSUY=; b=R/P8oKW2QjzKGhLrPdoYUglq938OTx9u8S7nrg0SIpTfhToRq76i+j+MgzkTqmiC4e Mt5incEITmaoA9dQP8JjWsMcXTzzoq9qA5KVlGXFAW1Ar0d8VlvGas7iQ4wBiRN8e2ZY UHouHq5rGAXp2eb4sRp4wtwqj0Odf+NZ/RKrE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=from:to:subject:date:message-id:mime-version:content-type:x-mailer :thread-index:content-language; b=lWUOkhj7ed7nq9fIdiwUukMTf9wNUSIBOmEGfDmbYDxhLZm2oG3iQ86A94lli7IzhY CZM9C+iNpJEIatvSahRHG28DC4Y44cwfsJR9V1Q/wF3zizhfKIhfqsYN6OpErF2BOANk U2U7E85uOKiv9P+UoqDFCiFR/pCrzARuRzZNI= Received: by 10.213.28.71 with SMTP id l7mr1797895ebc.87.1280240337971; Tue, 27 Jul 2010 07:18:57 -0700 (PDT) Received: from LauraLiess (dhcp-87d8.meeting.ietf.org [130.129.135.216]) by mx.google.com with ESMTPS id x54sm7625023eeh.11.2010.07.27.07.18.56 (version=SSLv3 cipher=RC4-MD5); Tue, 27 Jul 2010 07:18:57 -0700 (PDT) From: Laura Liess To: , , Date: Tue, 27 Jul 2010 16:18:55 +0200 Message-ID: <4c4eead1.ce7c0e0a.3abe.ffffdeba@mx.google.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0016_01CB2DA7.6A1C77B0" X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AcstlqWsvfVdq5JMRzCGpT81Pm0Exg== Content-Language: de X-Mailman-Approved-At: Tue, 27 Jul 2010 07:24:51 -0700 Subject: Re: [sipcore] Location Conveyance Flaw: HTTP/HTTPS Location URI Scheme X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 27 Jul 2010 14:18:38 -0000 This is a multi-part message in MIME format. ------=_NextPart_000_0016_01CB2DA7.6A1C77B0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit It would be nice if this would happen soon, because this is what people need most. Thanks a lot Laura ______________________________ Yes, this needs to be fixed. Jon Peterson NeuStar, Inc. On 7/19/10 1:17 AM, "Hannes Tschofenig" > wrote: Hi, The authors (or one of them in particular) have not managed to include support for the HTTP/HTTPS URI scheme in the draft despite the fact that the GEOPRIV working group has provided support for HTTP/HTTPS location URIs for dereferencing in HELD (and now works on the HTTP/HTTPS dereference protocol). Ciao Hannes _______________________________________________ sipcore mailing list sipcore at ietf.org https://www.ietf.org/mailman/listinfo/sipcore ------=_NextPart_000_0016_01CB2DA7.6A1C77B0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Re: [sipcore] Location Conveyance Flaw: HTTP/HTTPS Location URI = Scheme

It would be nice if this would happen = soon, because this is what people need most.

Thanks = a lot

Laura


______________________________
Yes, this needs to be fixed.

Jon Peterson
NeuStar, Inc.


On 7/19/10 1:17 AM, "Hannes Tschofenig" = <Hannes.Tschofenig at gmx.net> wrote:

Hi,

The authors (or one of them in particular) have not managed to include = support for the HTTP/HTTPS URI scheme in the draft despite the fact that = the GEOPRIV working group has provided support for HTTP/HTTPS location = URIs for dereferencing in HELD (and now works on the HTTP/HTTPS = dereference protocol).

Ciao
Hannes
_______________________________________________
sipcore mailing list
sipcore at = ietf.org
https://www.ietf.org/mailman/listinfo/sipcore

------=_NextPart_000_0016_01CB2DA7.6A1C77B0-- From jmpolk@cisco.com Tue Jul 27 07:44:43 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6CDFC3A689F for ; Tue, 27 Jul 2010 07:44:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.561 X-Spam-Level: X-Spam-Status: No, score=-10.561 tagged_above=-999 required=5 tests=[AWL=0.038, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JEtIRxpxIO98 for ; Tue, 27 Jul 2010 07:44:42 -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 47F613A6BB0 for ; Tue, 27 Jul 2010 07:44:42 -0700 (PDT) Authentication-Results: rtp-iport-2.cisco.com; dkim=neutral (message not signed) header.i=none X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AvsEAFSNTkxAZnwN/2dsb2JhbACfZnGmOptFhTYEhAk X-IronPort-AV: E=Sophos;i="4.55,268,1278288000"; d="scan'208";a="139798633" Received: from rtp-core-2.cisco.com ([64.102.124.13]) by rtp-iport-2.cisco.com with ESMTP; 27 Jul 2010 14:45:04 +0000 Received: from jmpolk-wxp01.cisco.com (dhcp-10-55-90-83.cisco.com [10.55.90.83]) by rtp-core-2.cisco.com (8.13.8/8.14.3) with ESMTP id o6REj0Eo013000; Tue, 27 Jul 2010 14:45:01 GMT Message-Id: <201007271445.o6REj0Eo013000@rtp-core-2.cisco.com> X-Mailer: QUALCOMM Windows Eudora Version 7.1.0.9 Date: Tue, 27 Jul 2010 09:45:02 -0500 To: Laura Liess , , , From: "James M. Polk" In-Reply-To: <4c4eead1.ce7c0e0a.3abe.ffffdeba@mx.google.com> References: <4c4eead1.ce7c0e0a.3abe.ffffdeba@mx.google.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii"; format=flowed Subject: Re: [sipcore] Location Conveyance Flaw: HTTP/HTTPS Location URI Scheme X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 27 Jul 2010 14:44:43 -0000 Laura This will be in the next release (i.e., -04), which shouldn't take *that* long to churn out. I already have everything from the list traffic incorporated, but that meeting yesterday was ~90 minutes just on Conveyance, so there's a lot to process with what was agreed on. I'm still verifying with folks just what was agreed to (and in what way it should be written). James At 09:18 AM 7/27/2010, Laura Liess wrote: >Content-Type: multipart/alternative; > boundary="----=_NextPart_000_0016_01CB2DA7.6A1C77B0" >Content-Language: de > >It would be nice if this would happen soon, because this is what >people need most. > >Thanks a lot > >Laura > > >______________________________ >Yes, this needs to be fixed. > >Jon Peterson >NeuStar, Inc. > > >On 7/19/10 1:17 AM, "Hannes Tschofenig" ><Hannes.Tschofenig >at gmx.net> wrote: > >Hi, > >The authors (or one of them in particular) have not managed to >include support for the HTTP/HTTPS URI scheme in the draft despite >the fact that the GEOPRIV working group has provided support for >HTTP/HTTPS location URIs for dereferencing in HELD (and now works on >the HTTP/HTTPS dereference protocol). > >Ciao >Hannes >_______________________________________________ >sipcore mailing list >sipcore >at ietf.org >https://www.ietf.org/mailman/listinfo/sipcore > >_______________________________________________ >sipcore mailing list >sipcore@ietf.org >https://www.ietf.org/mailman/listinfo/sipcore From RMarshall@telecomsys.com Wed Jul 28 01:01:46 2010 Return-Path: X-Original-To: sipcore@core3.amsl.com Delivered-To: sipcore@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D3BEE28C128 for ; Wed, 28 Jul 2010 01:01:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_46=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 9DBo4h2wnzSN for ; Wed, 28 Jul 2010 01:01:45 -0700 (PDT) Received: from sea-mimesweep-1.telecomsys.com (sea-mimesweep-1.telecomsys.com [199.165.246.12]) by core3.amsl.com (Postfix) with ESMTP id 3416D28C12B for ; Wed, 28 Jul 2010 01:01:44 -0700 (PDT) Received: from SEA-EXCHVS-2.telecomsys.com (unverified [10.32.12.7]) by sea-mimesweep-1.telecomsys.com (Clearswift SMTPRS 5.2.9) with ESMTP id ; Wed, 28 Jul 2010 01:01:32 -0700 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, 28 Jul 2010 01:01:18 -0700 Message-ID: <8C837214C95C864C9F34F3635C2A65751388A441@SEA-EXCHVS-2.telecomsys.com> In-Reply-To: <201007271445.o6REj0Eo013000@rtp-core-2.cisco.com> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [sipcore] Location Conveyance Flaw: HTTP/HTTPS Location URI Scheme Thread-Index: AcstmlTijtaS0XGqSs+UMtq/WfF6bAAjCcwQ References: <4c4eead1.ce7c0e0a.3abe.ffffdeba@mx.google.com> <201007271445.o6REj0Eo013000@rtp-core-2.cisco.com> From: "Roger Marshall" To: "James M. Polk" , "Laura Liess" , , , Subject: Re: [sipcore] Location Conveyance Flaw: HTTP/HTTPS Location URI Scheme X-BeenThere: sipcore@ietf.org X-Mailman-Version: 2.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, 28 Jul 2010 08:01:46 -0000 My take on the outcome of yesterday's meeting, some subsequent list suggestions (for geo: URI), and what more is needed: --/ geo: URI, need text that says something like, "A geo: URI is supported for use within a geolocation header if no privacy is expected. Otherwise, a geo: URI is used within a PIDF-LO construct.", and an acknowledgement that a geo: URI is already covered in the ABNF as an absolute URI as long as it contains a host.domain part. --/ geolocation header contents, already agreed that we need text to state something like, "It is assumed that geolocation header contains a single URI value, although more than one URI is possible, but, SHOULD NOT be used when it can be avoided. If, for example, an intermediary supplies additional location in preference to what is already there, the inserter assumes all responsibility for all the resultant URIs." =20 Additionally, we should discuss the details (somewhere) of how this is done. The proposal here is that we keep it general within the -conveyance draft, and put details - specific to emergency services - within a new ECRIT draft. As an example for this, w/regard to ordering, for example, is that some text would say that an inserter MUST insert the URI value before an existing URI(s), so that the LR's can be clued in as to how to consume location. This may be able to suffice for the "used-for-routing" parameter. As for parameters that have gone away. Since each URI contained has a host.domain part in the URI, the old "inserted-by" (coupled with record-route info) should be sufficient for analysis, without re-introducing the "inserted-by" parameter. The specifics of this could also be covered in a different draft. -roger marshall. -----Original Message----- From: sipcore-bounces@ietf.org [mailto:sipcore-bounces@ietf.org] On Behalf Of James M. Polk Sent: Tuesday, July 27, 2010 7:45 AM To: Laura Liess; jon.peterson@neustar.biz; Hannes.Tschofenig@gmx.net; sipcore@ietf.org Subject: Re: [sipcore] Location Conveyance Flaw: HTTP/HTTPS Location URI Scheme Laura This will be in the next release (i.e., -04), which shouldn't take=20 *that* long to churn out. I already have everything from the list=20 traffic incorporated, but that meeting yesterday was ~90 minutes just=20 on Conveyance, so there's a lot to process with what was agreed=20 on. I'm still verifying with folks just what was agreed to (and in=20 what way it should be written). James At 09:18 AM 7/27/2010, Laura Liess wrote: >Content-Type: multipart/alternative; > boundary=3D"----=3D_NextPart_000_0016_01CB2DA7.6A1C77B0" >Content-Language: de > >It would be nice if this would happen soon, because this is what=20 >people need most. > >Thanks a lot > >Laura > > >______________________________ >Yes, this needs to be fixed. > >Jon Peterson >NeuStar, Inc. > > >On 7/19/10 1:17 AM, "Hannes Tschofenig"=20 ><Hannes.Tschofenig=20 >at gmx.net> wrote: > >Hi, > >The authors (or one of them in particular) have not managed to=20 >include support for the HTTP/HTTPS URI scheme in the draft despite=20 >the fact that the GEOPRIV working group has provided support for=20 >HTTP/HTTPS location URIs for dereferencing in HELD (and now works on=20 >the HTTP/HTTPS dereference protocol). > >Ciao >Hannes >_______________________________________________ >sipcore mailing list >sipcore=20 >at 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 CONFIDENTIALITY NOTICE: The information contained in this message may be pr= ivileged and/or confidential. If you are not the intended recipient, or res= ponsible for delivering this message to the intended recipient, any review,= forwarding, dissemination, distribution or copying of this communication o= r any attachment(s) is strictly prohibited. If you have received this messa= ge in error, please notify the sender immediately, and delete it and all at= tachments from your computer and network.